2 장 Application Layer 2-1 2 장 Application Layer 2.1 네트워크어플리케에션의원리 2.2 Web and HTTP 2.3 FTP 2.4 전자우편 2.5 DNS 2.6 P2P 파일공유 2-2
2 장 Application Layer 이장의목적 Network application의개념과구현 Transport layer 서비스모델 클라이언트 _ 서버모델의예 Peer-Peer 모델 많이사용되는 application 관련 protocol에대해서학습한다. HTTP FTP SMTP/POP3/IMAP DNS Network application 프로그래밍방법 Socket API 2-3 Some network app E-mail Multi-user network game Web Streaming stored video clips Instanct messaging Internet TEL. Remote login Real-time video conference P2P file sharing Massive parallel computing 2-4
Creating a network app 프로그램의실행 서로다른종단시스템간에실행 네트워크위에서실행 예. Web: Web 서버와 browser 간에통신 Network core는 Network 프로그램에대해서투명하다. Network core의장치와 application 개발과는무관하다. 종단시스템으로소프트웨어를제한한다는기본설계는인터넷 application의빠른개발과전개를쉽게해준다. 2-5 2 장 Application Layer 2.1 네트워크어플리케에션의원리 2.2 Web and HTTP 2.3 FTP 2.4 전자우편 2.5 DNS 2.6 P2P 파일공유 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Web server 구축 2-6
Network application 의구조 Client-Server Peer-to-peer (P2P) Hybrid of client-server and P2P 2-7 Client-server 구조 Server 항상켜져있다. 고정 IP를갖는다. 다량의 client로부터요청을처리하기위해 server farm를구성하기도한다. ( 가상서버 ) Client Server에서비스를요청한다. 필요에따라서버에접속한다. 동적인 IP를사용하는경우도있다. Client간에직접통신하지않는다. 2-8
순수 P2P 구조 항상켜있는서버가존재하지않는다. 임의의호스트쌍이직접통신한다. Peer는필요에따라간헐적으로접속하며 IP또한바뀔수있다. 예 : 그누텔라 (Gnutella) 높은분배와분산특성 관리가어렵다. 2-9 Client-server 와 P2P 의통합구조 Napster File의전송은 P2P를이용한다. File 검색은서버를이용한다. Peer들은중앙서버에자신이가진파일의목록을등록한다. 원하는 file의위치를찾기위해서는중앙서버에질의한다. Instant messaging 두사용자간에채팅은전형적인 P2P이다. 사용자의접속여부와위치는중앙서버를이용한다. 채팅에참여하기위해서는중앙서버에 IP와자신의정보를등록한다. 대화를위해서온라인에대기중인사용자를찾기위해서는중앙서버에연결한다. 2-10
프로세스간통신 Process : 호스트에서실행중인프로그램 동일시스템의프로세스는그들은서로프로세스간통신을하게된다. inter-process communication 이라불리는이통신의규칙은종단시스템의운영체제에의해서좌우된다. 서로다른시스템간의 process 간에는 message 교환으로통신한다. Client process : Process간에통신세션에서통신을초기화한다. ( 능동적 ) Server process : 세션을시작하기위해서접속을기다린다.( 수동적 ) Note : P2P application 은 client process 와 server process 두가지기능을모두가지고있다. 2-11 Socket 두개의 process는네트워크를통해서 message를주고받는다. 이때 process는 socket을통해네트워크에 message를보내고받는다. Socket은문 (door) 에비유될수있다. 송신쪽 process는 door 바깥쪽으로 message를밀어낸다. 송신 process는네트워크를거쳐수신 process로 message가전달되는구조가문바깥쪽에있다고신뢰한다. 전달된 message는 door을통해수신 process로전달된다. API : (1) Transport protocol 선택 ; (2) 몇가지매개변수들 2-12
Addressing processes process가 message를수신하기위해서는반드시자신에대한인식정보가필요하다. 호스트들은 32bit의 unique한 IP 주소를갖는다. Q : 종단시스템의 IP 주소만으로 process 를정확히구별할수있는가? 호스트의각 process 를정확히구별하기위해서는 IP 주소와 port number 가모두필요하다. 유명한 application protocol들은특정 port number가할당되어있다. HTTP server: 80 Mail server : 25 Answer : No 동일한 host에는많은 process가존재함으로구별이불가능하다. 2-13 App-layer protocol 정의 교환되는 message 의타입 Request & response message 여러 message type의 syntax (message 내부의각 field를구별하는방법 ) Filed의 semantics ( 각 field의의미, 담고있는정보의내용 ) 언제어떻게 process가 message를전송하고응답하는지를결정하는규칙 Public domain protocol RFC 에정의되어있다. www.ietf.org RFC에서제공되는규칙에따른다면상호운영이가능하다. 예 : HTTP, SMTP Proprietary protocol 예 : KaZaA Protocol의 3요소 Timing Syntax semantics 2-14
Application 이필요로하는전송서비스 Data 손실 Application에따라서는 data의손실을허용한다. 일부 application들은데이터손실이전혀없는신뢰적인전송을요구한다. (FTP, telnet..) Timming 인터넷폰이나다자간게임같은 application들은효과적인 data 전송을위해매우낮은수준의지연만을허용한다. 엄격한시간조건을요구한다. 대역폭 (bandwidth) Bandwidth-sensitive application 효과적인전송을위해최소대역폭을보장해야된다. Elastic application 가용한대역폭을적게사용한다. 물론대역폭이많으면좋다. 2-15 다양한 application 들의요구사항 2-16
인터넷전송 protocol 이제공하는서비스 TCP service 연결지향형서비스 : message를전송하기전에 client와 server process간에전송제어정보가전달된다. 신뢰적인전송서비스 : 모든데이터가오류없이올바른순서로전달된다. 혼잡제어 : 네트워크가혼잡상태에이르면송신자가전송속도를낮춘다. (process의직접적인이득보다는인터넷전체성능향상 ) 제공되지않는서비스 최소전송률을보장하지않는다. 지연보장을하지않는다. Application에서담당한다. UDP service 비신뢰적인 data전송서비스를제공한다. ( 도착여부나순서를보장하지않는다.) 통신전에제어정보를전송하는 connection setup과정이없다. 신뢰성, 혼잡제어, 흐름제어, 지연, 최소전송률등을보장하지않는다. Q : UDP 를이용하는이유는무엇인가? A: 송신자가전송속도를네트워크혼잡에따라제어하는혼잡제어를제공하지않음으로, 비록모든 data 가전달되지못하더라도송신 process는원하는속도로 data를전송해야하는실시간 application 에사용한다. 이런 application들은최소전송률이필요하지만 data의일부손실은감수할수있기때문이다. 2-17 인터넷 app 의하위전송 protocol 2-18
2 장 Application Layer 2.1 네트워크어플리케에션의원리 2.2 Web and HTTP 2.3 FTP 2.4 전자우편 2.5 DNS 2.6 P2P 파일공유 2-19 Web and HTTP First some jargon Web page는 object로구성된다. Object는 HTML 파일, 음성파일, JPEG 파일, java applet 등이다. Web page는여러 object 로구성된 HTML 파일과여러참조개체로구성된다. 각각의 object는 URL이라는주소를가진다. URL 예 www.someschool.edu/some/pic.gif Host name path name 2-20
HTTP overview HTTP : Hyper text transfer protocol Web application layer protocol Client/server model Client : browser는웹용 client app, 질의를전달하고요구한 web page를보여주는기능을담당 Server : Web server로 client 의질의에응답하고여러 web object를 client에전송한다. HTTP 1.0 : RFC 1945 HTTP 1.1 : RFC 2068 2-21 HTTP overview Using TCP Client가먼저서버에 80번포트로 TCP 연결을시작한다. : creates socket 서버는 client로부터의접속을승낙하면접속이이루어진다. 접속이후에는 client와 server는 socket inteface를통해 TCP와연결된다. (message를주고받는다.) HTTP is stateless Server는 client의에대한어떠한상태정보도저장하지않는다. client의질의를처리만할뿐이에대한정보는저장하지않는다. Protocol이상태정보를유지하는것은매우복잡하다!! 접속에대한 hostory를저장해야한다. Client/server간의상태정보가일치하도록유지해야한다. 2-22
HTTP connections 비지속연결 (nonpersistent) 지속연결 (persistent) 각각의 object마다하나의 TCP connection을이용한다. HTTP1.0에서이용한다. Client server간에하나의 TCP connection을이용여러개의 object를전송한다. HTTP1.1에서 persistent가 default이다. 2-23 Nonpersistent HTTP 1a. Client 는 server 에 TCP connection 을시도한다. 2. Client 는 request message 를 TCP connection socket 을통해 server 에전송한다. 1b. Server 는 client 의 TCP connect 에대해서접속을허가한다. 3. Server 는요청한 object 를포함한 response message 를 client 에전송한다. 5. Client 는 response 를수신하고 message 를처리한후 TCP connection 을끊는다. 4. Server 는 TCP 에세접속을끊도록한다. ( 실제로 client 가 response 를받을때까지접속을끊지않는다.) 6. 모든 object에대해서위과정을반복한다. 2-24
응답시간 RTT 이정의 : 작은 packet 이 client 로부터 server 로갔다가다시 server 로돌아오는데걸리는시간 응답시간 TCP connection을초기화하기위한 RRT HTTP request와서버에대한응답을보내고받는데걸리는 RRT File 전송시간 전체전송시간 total = 2RTT + file trans time 2-25 Persistent HTTP Nonpersistent HTTP issues 각 object 당 2RTT가필요 OS가각각의 TCP connection에대해서자원을할당한다. 브라우저는동시에여러개의 TCP connection을연결여러 object 를처리 Persistent HTTP Server는응답을보낸후 TCP연결을유지한다. 동일 client/server강의요청과응답 message는같은 connection을이용한다. persistent without pipelining Client는 response을수신한후에만새로운 request를보낸다. 객체를수신하는데 1RTT만사용 persistent with pipelining HTTP 1.1의 default. Reference object를만나자마자계속해서 request를발생한다. 모든 object에대해서하나의 RTT 만을더필요하다. Reference object : object : 객체 2-26
HTTP request message (client) HTTP message에는 request와 response 두가지형태가있다. HTTP request message ASCII ( 읽을수있는형태 ) Request line (GET,POST,HEAD Commands) header lines GET /somdir/page.html HTTP/1.1 Host: www.somesite.edu User-agent: Mozilla/4.0 Connection: close Accept-language: kr 각라인은 CR과 LF로구별 (carriage return & line feed) 마지막줄에는추가 CR과 LF가따른다. 2-27 HTTP request 의일반형태 2-28
Uploading form input Post method Web page의특정내용은 form field 입력에의존한다. 사용자가폼필드에입력한값은개체몸체 (Entity body) 에포함된다. URL method GET method를사용할수도있다. 입력된 form field의값들은 request line의 URL field를이용전송된다. (113 page 참조 ) 2-29 Method types HTTP/1.0 GET POST HEAD HTTP message로응답은하지만요청객체는보내지않는다. 흔히개발자가디버깅에이용한다. HTTP/1.1 GET, POST, HEAD PUT URL field에 entity body에있는 upload file의경로를기술하는것 DELETE URL field에삭제하고자하는 object의경로를기술. 2-30
HTTP response message (server) Status line (Protocol, Status code, Status phrase) header lines HTTP/1.1 200K Connection: close Date: Thu, 06 AUG 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 Content-Length: 6821 Content-Type: text/html Data data data (request html file..) 2-31 HTTP response status codes 첫번째줄에있는 response message 의 status code sample 200 OK 요청이성공적이고응답이전달되었다. 301 Moved permanently 요청한 object가이동되었다. 새로운 URL은응답 message의 header에나와있다. Client는자동으로새로운 URL을추출한다. 400 Bad request 이해할수없는 request라는일반오류코드 404 Not Found 요청한문서가서버에존재하지않는다. 505 HTTP Version Not Supported 2-32
HTTP 응답확인 2-33 사용자서버간에상호작용 : 쿠키 많은 major web site 에서쿠키가사용된다. 네가지구성요소 1) HTTP 쿠키헤더가포함된 response message 2) HTTP 쿠키헤더가포함된 request message 3) 사용자 browser쪽에저장된쿠키파일 ( 사용자쪽 host와관리 ) 4) Web site의 back-end database 예제 수잔은항상동일한 PC를이용 internet에접속한다. 처음으로전자상거래를위해특정사이트에접속한다. 웹사이트에처음으로 request 들어오면웹사이트는유일한식별번호 (unique ID) 를만들고 backend database에순서에맞게 ID 를저장한다. 2-34
쿠키의상태정보저장 2-35 Cookies 쿠키의응용 Authorization Shopping carts Recommendations User session status (Web email) Cookies와 privacy Cookies는사용자에대한더많은정보를저장할수있다. 쿠키로모아진정보는제 3자에게팔수있다. Search engines use redirection & cookies to lean yet more. 쿠키는많은웹사이트를통해서특정사용자에대한정보를모으는데이용될수있다. 2-36
Web cache (proxy server) 목적 : origin server 를대신해서 client 의 reauest 를충족시킨다. Browser의모든 HTTP request 가 web cache를경유하도록설정 Browser는모든 HTTP request 를 cache에전달한다. Object in cache : cache return object Else : cache는 origin server로부터 object를전송받아서저장하고사본을 browser에전달한다. 2-37 Web cache (proxy server) Cache는 client와 server기능을모두한다. 일반적으로 cache는 ISP가구입하고설치한다. ( 대학, 회사,ISP ) Cache 를사용하는이유 Client의 request에대한응답시간을줄인다. 인터넷으로의기관접속회선상의 traffic 량을줄일수있다. 저속의접속회선을운영하는서비스하는제공자의 Content를빠르게분배할수있는기반구조를제공한다. ( 그러나 P2P는그렇지않다 ) 2-38
Cache 예제 가정 평균적인 object 크기 100,000 bit 서버와 browser간에평균 request rate는 15/sec 기관의라우터가 HTTP를요청하고응답을받는시간은 2초 결과 Lan의 utilization : 0.15 Across link의 utilization : 1 전체지연 internet delay + access delay + Lan delay Access link 의 utilization 이 1 로 Access delay 가수분단위로크다 2-39 Cache 예제 개선 Access link의대역폭을 10M bps로상향 결과 Lan의 utilization : 0.15 Across link의 utilization : 0.15 전체지연 internet delay + access delay + Lan delay = 2초 + msec+msec 경비가많이들어간다. 10 2-40
Cache 예제 Install cache Hit rate : 0.4 결과 Client request중에 60% 만 origin server에전달 Across link의 utilization은 1 에서 0.6으로감소 전체지연 internet delay + access delay + Lan delay = access delay 가 0.8 미만의작은지연에속함 2-41 Conditional GET ( 조건부 GET) 목적 : cache 내부의 object 복사본이최신것이아니라면전송하지않는다. Cache : 자신이복사본으로가지고있는 object에대한마지막수정날짜를포함한 request를서버에전송한다. If-modified-Since : <date> Server : Cache에저장된 object가최신것이라면 response에 object를포함하지않는다. HTTP/1.0 304 Not Modified 2-42
2 장 Application Layer 2.1 네트워크어플리케에션의원리 2.2 Web and HTTP 2.3 FTP 2.4 전자우편 2.5 DNS 2.6 P2P 파일공유 2-43 FTP : the file transfer protocol 원격 host로파일을송수신하는 protocol. Client-server model Client : file 송수신을시작한다. Server : 원격시스템 Ftp : RFC 959 Ftp server : port 21 2-44
FTP : 제어와 file 전송 FTP client는 21번 port를통해서서버와 control connection 을설정한다. 이제어연결을통해사용자계정과비밀번호를전송한다. Client는제어연결을통해워격지의디렉토리변경과같은명령을전송한다. 서버측은제어연결을통해파일전송을위한명령을받으면 TCP data connection을초기화한다. 하나의파일전송이끝나면 data 연결은 close된다. 다음파일전송을위해서는새로운 TCP connection을생성한다. Out of band : 파일을전송하는 connection과제어를위한 conconnection을다르게하는것. ( 반대 : in band) FTP 서버는사용자의 status를유지한다. 현재디렉토리, 인증정보 : 이로인해서버가유지할수있는전체세션의수를상당히제한한다. 2-45 FTP 명령과응답코드 Sample command 명령과응답은 7bit ASCII로 control connection을이용전송된다. USER username PASS password LIST ( 원격지디렉토리의파일의 list 요청 : 응답은 data 연결을이용한다.) RETR filename (data 연결을초기화하고요청된파일전송하기위해원격호스트를시작한다.) STOR filename ( 파일을원격호스트에저장하는데이용한다.) Sample return code 331 : username OK, password required 125 : data connection already open, transfer start 425 : can t open data connection 452 : Error writing file 2-46
2 장 Application Layer 2.1 네트워크어플리케에션의원리 2.2 Web and HTTP 2.3 FTP 2.4 전자우편 2.5 DNS 2.6 P2P 파일공유 2-47 전자우편 세가지중요한구성요소 사용자 agent Mail server SMTP (simple mail TP) User agent Mail reader라불리기도한다. Msil message를읽고쓰고전달하고저장하고구성하는등의역할을한다. 예 : Outlook, elm, Eudora Server에 message를전달하거나 server로부터수신하는역할을한다. 2-48
전자우편 : mail server Mail server Mailbox : 사용자에게온 message를저장한다. Message queue : 다른메일서버로전송될 message를임시로저장하는 queue SMTP : mail server간에 mail message를송수신하는 protocol Client : mail을보내는서버 Server : mail을받는서버 2-49 전자우편 : SMTP [RFC 2821] Client server간의 mail message는 TCP의신뢰적인데이터전송서비스를이용한다. (25번 port) 송수신하는 mail server간에는중간에어떤서버를이용하지않고반드시직접연결한다. Mail server 전송과정 Handshaking Message 전송 TCP 연결종료 Command/response Command : ASCII text Response : 응답코드와영문설명 (phrase) Message는반드시 7bit ASCII 이다. SMTP는 persistent connection이다. 2-50
메일전송과정 1) Alice는 UA를이용 message 을작성하고제공한메일주소로전송하도록한다.(Bob) 2) UA는 mail server로 message를전송한다. message는서버의 message queue에놓인다. 3) Client측 SMTP는 message queue를확인하고 TCP connection을 BOB쪽 mail server와연결한다. 4) TCP connection을이용 message를전송한다. 5) BOB 측의 mail 서버는 message를 bob의메일박스에저장한다. 6) Bob는 UA를이용 message를꺼내와서읽는다. 2-51 SMTP 전달과정예 2-52
SMTP 전달과정실습 2-53 SMTP SMTP persistent connection 을이용한다. SMTP의 message는 7 bit ASCII이다. (header & body) SMTP server는 meaage를 CRLF.CRLF로끝낸다. HTTP와비교 HTTP : pull SMTP : push (server간) Command& response모두 7bit ASCII 포맷을요구한다. HTTP는 response의각 object 를각각캡슐화한다. SMTP는여러 object를하나의 msg로만든다. 2-54
Mail message format SMTP : email msgs 를전송하기위 한protocol RFC 822 : msg의표준포맷 Header line To: From: Subject: (SMTP 명령과는다르다 ) Body Msg (only ascii) header body Blank line 2-55 Message format : multimedia extensions MIME : multimedia mail extension, RFC 2045, 2056 Msg header에 mime content type에대한 line을추가해야한다. 2-56
Mail access protocol SMTP : 수신쪽서버에 msgs를전송하기위한 protocol Mail access protocol : 수신자의메일서버로부터수신자의 UA로메일을가져오는데이용한다. POP : Post office protocol [RFC1939] Authorization and download (agent와서버간 ) IMAP : Internet mail access protocol [RFC 1730 다양한특성을가지며구현이복잡하다. 서버의 msgs를다양하게다룰수있다. HTTP : Hotmail, yahoo mail 2-57 POP3 protocol authorization phase Client commands: user : 사용자명 pass : password Server response +OK -ERR transaction phase Client list : msgs의크기의나열 retr : 지정한번호의 msg 전송요청 dele : 종료후서버의 msg 삭제요청 quit 2-58
POP3 와 IMAP POP3 앞의예제는 download and delete mode 이다. 만일 UA 에서전송된 msg를잃어버리면다시는메일을읽을수없다. download and keep 모드를사용하면여러호스트의 UA에서 msg을동시에저장하고볼수있다. POP3는 stateless로 session이유지되는동안만상태정보를저장한다. ( 특히 msg의삭제여부 ) IMAP 모든 msgs를서버의한곳에저장한다. 사용자는 msgs를 folders에연결시킬수있다. 사용자는 msgs를새폴더로옮기거나읽거나삭제할수있다. IMAP는사용자의상태정보를유지한다. 폴더의이름과어떤 msg가어떤폴더와연결되어있는가하는정보 UA가다양한방법으로 msg의구성요소에접근하는방법을제공 msg의헤더만을얻거나 mime msg의일부만을얻을수도있다. 2-59 2 장 Application Layer 2.1 네트워크어플리케에션의원리 2.2 Web and HTTP 2.3 FTP 2.4 전자우편 2.5 DNS 2.6 P2P 파일공유 2-60
DNS : Domain Name System 사람 : 많은인식정보를가진다. 주민등록번호, 이름, 여권번호 인터넷의 host, 라우터 호스트는흔히말하는 IP주소로식별된다. (network layer로 4장에서..) DNS 이름 : 사람이사용하는.. www.yahoo.com, Q : IP 와이름간에 map Domain Name System 분산 database 수많은 name server들이계층형구조로구조화되어있다. Application layer protocol 다른 app layer protocol들이 HTTP, FTP, SMTP등사용자가제공한호스트네임을 ip로변환하는데이용한다. 인터넷의가장중요한기능중의하나 Network edge에구현된다. 2-61 DNS DNS services 호스트명을 IP 주소로변환한다. 호스트에얼리아싱 (host aliasing) 정식 (canonical) 호스트명 별칭 (aliasing) 호스트명 DNS는 IP분아니라정식호스트명을얻기위해이용되기도한다. 메일서버에얼리아싱 분산부하 중복 web서버여러 IP 주소가하나의정식호스트명에연관 DNS 를중앙집중식으로하지않는이유??? 서버장애 ( 인터넷다운 ) Traffic의집중 중앙서버까지의거리 관리 확장성이전혀없다!!! (144page) 2-62
분산계층형 database Client 가 www.amazon.com 의 IP 를원하는경우 Root DNS서버에접속 com DNS server의 IP를질의한다. 응답받은 com DNS서버의 IP로 amazon.com을관리하는 DNS server 의 IP를질의한다. 응답받은 amazon.com 관리 DNS server에게 www.amazon.com의 IP를질의한다. Client는 www.amazon.com의 IP를획득한다. 2-63 Root name servers Local name 서버를찾기위해서접근한다. ( 이름을반환하는역할을수행하지않는다. root name server Contacts authoritative name server if name mapping not know Get mapping Returns mapping to local name server 2-64
TLD and Authoritative servers Top-Level domain(tld) server : com, org, net등과같은상위레벨도메인과모든국가의상위레벨도메인에대한책임이있다. net TLD : Network solutions maintains servers edu TLD : 교육 Authoritative( 책임 ) DNS server : 인터넷에접근하기쉬운 host를가진기관은호스트명을 IP로매핑하기위한 DNS 레코드를제공하는데책임 DNS서버는이레코드를갖는다. 일부서비스제공자의책임 DNS서버에이레코드를저장하도록비용을지불할수도있다. 2-65 Local Name Server 엄격한계층구조에포함되어있지않다. ISP는하나의 local name server를갖는다. Default name server 라고불린다. 호스트가 DNS 질의를보내면이것은 local name server에전달된다. Local name server는전송된질의를 DNS 서버계층으로전달하도록 proxy 를동작한다. 2-66
예 cis.poly.edu 호스트가 gaia.cs.umass.edu 서버의 IP 를알고자할때 query 1 : 재귀적질의 query 2,4,6 : 반복적질의 2-67 DNS queries recursive query: 접속한 name server에 name에대한 IP mapping 정보를찾아줄것을요구하는 query Heavy load iterated query: 접속한서버에 ip mapping 정보또는다음단계의 name 서버의주소를 query하는것 2-68
DNS caching 질의사슬에서 DNS서버가 DNS 요청에대한응답을받을때그응답을 local memory에저장한다. NDS서버는일정기간이지나면저장된정보를삭제한다. Local name server는 TLD 서버의 IP 주소를저장할수있다. 이러한caching는local DNS server가root server를우회할수있도록한다. 이러한내용은 IEFT에있다. RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html 2-69 DNS record DNS 서버들은호스트명을 IP 주소로 mapping 하기위한 RR 를저장한다. RR Resorce Records RR format : (name, value, type, ttl) Type = A Name 은호스트명 Value는 ip주소 Type = CNAME Name 은별칭호스트명 Value는정식호스트명 Type = NS Name 은도메인명 Value는책임 DNS 서버 Type = MX Value 는별칭호스트명 2-70
DNS protocol message DNS protocol : 질의와응답 msg 는 format 이동일하다. msg header (12 byte) 식별자 : 16 bit로질의에대한응답인경우이부분이복사되어질의와수신된응답간에일치를식별한다. 플래그 : 질의 (0) 인지응답 (1) 인지구별 recursion 요구플래그 Client 가재귀질의를원할때설정 recursion 가능플래그 DNS서버가재귀기능을지원하면응답에설정 책임플래그 DNS 서버가질의에대한책임서버일때응답에설정 식별자플래그질문수응답 RR수책임 RR수추가 RR수질문 ( 가변질문수 ) 답변 ( 가변 RR수 ) 책임 ( 가변 RR수 ) 추가정보 ( 가변 RR수 ) 2-71 DNS protocol message 질의이름과타입 식별자 질문수 책임 RR 수 플래그 응답 RR 수 추가 RR 수 DNS 서버로부터의응답 책임서버의 record 다른도움이되는 Record 질문 ( 가변질문수 ) 답변 ( 가변 RR수 ) 책임 ( 가변 RR수 ) 추가정보 ( 가변 RR수 ) 2-72