Internet Applications: Internet Directory Service and World Wide Web

개요

Chapter 23은 Internet application이 실제로 작동하기 위해 필요한 두 기반 기술을 다룬다. 하나는 사람이 기억하는 이름을 network가 사용할 수 있는 주소로 바꾸는 DNS(Domain Name System)이고, 다른 하나는 Web browser와 Web server 사이에서 Web resource를 주고받는 HTTP(Hypertext Transfer Protocol)다.

이 장의 큰 흐름은 DNS directory lookup → DNS distributed hierarchical database → DNS name resolution → HTTP client/server transaction → HTTP intermediaries → HTTP message structure다. DNS는 “어디로 접속해야 하는가”를 해결하고, HTTP는 “그 resource를 어떤 request/response 형식으로 주고받을 것인가”를 해결한다.

핵심 개념

세부 정리

23.1 Internet Directory Service: DNS

DNS(Domain Name System)는 Internet host의 이름과 numerical address 사이의 mapping을 제공하는 directory lookup service다. 사용자는 www.example.com 같은 이름을 기억하지만, IP layer에서 packet을 전달하려면 numerical IP address가 필요하다. DNS는 이 간격을 메우는 Internet 필수 서비스이며, 원문은 RFC 1034와 RFC 1035로 정의된다고 설명한다.

DNS는 네 구성요소로 이루어진다.

Typical client request는 주어진 domain name에 대응하는 IP address를 찾는 것이다. E-mail server를 찾거나 Web page에 접근할 때마다 DNS name lookup이 필요하다.

Domain Names

32-bit IP address는 Internet에 붙은 device를 unique하게 식별한다. 이 address는 network number와 host address로 해석된다. 하지만 IP address만으로 Internet을 운영하면 두 가지 문제가 생긴다.

domain은 이 문제를 해결하기 위한 개념이다. 일반적으로 domain은 회사, 정부 기관 같은 하나의 administrative entity가 관리하는 host group을 뜻한다. Domain은 hierarchy로 조직되며, 하나의 domain은 여러 subordinate domain을 가질 수 있다. Domain name은 이 hierarchy를 반영한다.

Figure 23.1 · PDF p. 795 · root에서 top-level domain, subordinate domain, host leaf로 내려가는 Internet domain tree 일부

Figure 23.1에서 가장 위는 root이고, 그 아래에 Internet 전체를 포괄하는 소수의 top-level domain이 있다. 예를 들면 com, edu, gov, mil, net, org, us, country code domain 등이 있다. 하위 level은 바로 위 level name 앞에 subordinate name을 붙여 표현한다.

예시는 다음과 같다.

Tree 아래로 내려가면 결국 Internet의 specific host를 식별하는 leaf node에 도달한다. Domain name이 Internet-wide하게 unique해야 하므로 전체적인 domain name assignment는 Internet-wide organization이 관리하고, 실제 address assignment는 hierarchy 아래로 delegation된다. 예를 들어 mil domain은 큰 address group을 받고, U.S. DoD가 이를 여러 DoD organization에 나눠 host에 할당한다.

Top-level domain은 기능과 관리 주체를 대략 드러낸다. com은 commercial organizations, edu는 educational institutions, gov는 U.S. federal government agencies, net은 network support centers/ISPs, org는 nonprofit organizations, country code는 au, ca, uk 같은 ISO 2-letter country-specific domain을 의미한다. 이 목록 자체를 암기하기보다, DNS가 administrative delegation과 naming hierarchy를 동시에 표현한다는 점이 중요하다.

DNS Database와 Resource Record(RR)

DNS database는 host의 name, IP address, 기타 정보를 담은 RR(Resource Record)들의 hierarchical database다. 핵심 특징은 세 가지다.

이 구조 덕분에 DNS는 전 세계 host name/address mapping을 중앙집중식 단일 파일이 아니라, hierarchical delegation과 distributed server로 유지한다.

Figure 23.2 · PDF p. 796 · DNS Resource Record(RR)의 Domain Name, Type, Class, TTL, Rdata 구조

RR은 다음 field로 구성된다.

대표 RR type은 다음과 같다.

RR에서 TTL은 DNS scalability와 freshness 사이의 trade-off를 직접 드러낸다. Cache 시간이 길면 반복 query가 줄어 성능과 traffic 측면에서 유리하지만, record가 바뀌었을 때 stale information이 오래 남을 수 있다. TTL이 0이면 freshness는 높지만 cache benefit은 사라진다.

DNS Operation과 Name Resolution

DNS operation은 사용자가 보지 못하는 곳에서 여러 단계로 진행된다. 핵심은 user program이 domain name에 대한 IP address를 요청하면, local resolver와 name server가 database/cache를 확인하고 필요하면 다른 name server를 조회한다는 점이다.

Figure 23.3 · PDF p. 798 · user query가 resolver, local name server, foreign name server, cache를 거쳐 response로 돌아오는 DNS name resolution 흐름

일반적인 DNS lookup 흐름은 다음과 같다.

1. User program이 domain name에 대한 IP address를 요청한다.
2. Local host 또는 local ISP의 resolver module이 같은 domain의 local name server에 query를 만든다.
3. Local name server는 local database 또는 cache에 해당 name이 있는지 확인한다.
4. 있으면 즉시 IP address를 requestor에게 반환한다.
5. 없으면 root 또는 가능한 한 높은 위치의 name server에서 시작해 다른 name server들을 query한다.
6. Local name server가 response를 받으면 name/address mapping을 local cache에 저장한다. Cache 유지 시간은 retrieved RR의 Time to Live(TTL)을 따른다.
7. User program은 IP address 또는 error message를 받는다.

사용자 입장에서는 telnet locis.loc.gov 같은 command를 입력하면 DNS가 뒤에서 locis.loc.gov를 140.147.254.3 같은 IP address로 resolve한 뒤 connection이 진행된다. 이 예시는 DNS가 application protocol 자체가 아니라 application이 실제 server를 찾기 전에 호출하는 directory lookup service임을 보여준다.

Server Hierarchy와 Zone

DNS database는 Internet 곳곳의 DNS name server에 hierarchical하게 분산된다. Domain을 소유한 조직, 즉 domain name space의 subtree에 책임이 있는 조직은 name server를 운영할 수 있다. 각 name server는 domain name space의 subset인 zone으로 configured된다.

zone은 domain 안의 하나 이상의 subdomain과 associated RR collection이다. 이 data set은 해당 name server가 domain hierarchy의 그 부분에 대해 accurate RR set을 유지할 책임이 있으므로 authoritative하다고 한다.

Hierarchy는 임의 깊이까지 확장될 수 있다. 예를 들어 ibm.com domain을 담당하는 name server가 있고, 그 아래 watson.ibm.com에 대해서는 subordinate name server가 authoritative responsibility를 가질 수 있다.

Root level에는 top-level zones에 대한 책임을 공유하는 root name server들이 있다. 원문은 13개의 root name server가 replication되어 있다고 설명한다. 이 replication은 root server가 bottleneck이나 single point of failure가 되는 것을 막기 위한 구조다.

watson.ibm.com lookup 예시를 흐름으로 정리하면 다음과 같다.

1. User host의 program이 watson.ibm.com에 대한 query를 local server로 보낸다.
2. Local server cache에 있으면 IP address를 즉시 반환한다.
3. Cache에 없으면 root server에 query한다.
4. Root server는 ibm.com에 대한 NS record를 가진 server 쪽으로 request를 넘기거나 그 server 정보를 제공한다.
5. ibm.com server가 watson.ibm.com 정보를 알고 있으면 IP address를 반환한다.
6. 만약 watson.ibm.com 전용 delegated name server가 있으면 ibm.com server가 그 name server로 이어지게 하고, 최종적으로 해당 server가 IP address를 반환한다.

Typical single query는 UDP로 운반되고, group of names query는 TCP로 운반된다. DNS가 UDP와 TCP를 모두 사용할 수 있다는 점은 중요하다. 일반 조회는 작고 빠른 datagram이 유리하지만, 큰 응답이나 여러 이름 처리에는 reliable stream이 필요할 수 있다.

Recursive Technique과 Iterative Technique

Name resolution은 user host의 resolver에서 시작한다. Resolver는 local DNS name server의 name/address를 알고 있도록 configured된다. Resolver cache에 requested name이 없으면 local DNS server에 query를 보낸다. Local DNS server는 즉시 답을 주거나 다른 server들을 query한 뒤 답을 준다.

Name server A가 다른 name server B에게 DNS request를 보낸다고 하자. B가 local cache/database에서 답을 찾지 못하면 두 방식 중 하나를 사용할 수 있다.

Name server 사이 exchange에서는 iterative 또는 recursive technique이 모두 가능하다. Resolver가 보내는 request에는 recursive technique이 사용된다. 이 구분은 DNS traffic과 server burden의 분배 방식과 연결된다. Recursive 방식은 요청자가 편하지만 중간 server가 더 많은 일을 하고, iterative 방식은 요청자가 여러 server를 따라가야 하지만 각 server 부담은 작아질 수 있다.

DNS Message Format

DNS message는 query와 response에 모두 같은 format을 사용한다. 가능한 section은 header, question, answer, authority, additional records의 다섯 가지다.

Figure 23.5 · PDF p. 802 · DNS message의 header, question, answer, authority, additional records section과 QR/AA/TC/RD/RA flag 구조

Header section은 항상 존재하고 다음 field를 포함한다.

Question section은 name server에 대한 query를 담는다. 일반적으로 entry 하나만 들어간다. 각 entry는 다음으로 구성된다.

나머지 section의 의미는 다음과 같다.

DNS message format의 핵심은 “작은 header flag와 count로 query/response matching, recursion, truncation, section별 RR 개수를 모두 표현한다”는 점이다. DNS는 단순 name-to-address lookup처럼 보이지만, 실제 message는 hierarchy traversal, caching, authoritative answer, delegation을 표현할 수 있게 설계되어 있다.

23.2 Web Access: HTTP

HTTP(Hypertext Transfer Protocol)는 World Wide Web(WWW)의 foundation protocol이다. 이름만 보면 hypertext 자체를 전송하는 protocol처럼 보이지만, 원문은 이 이름이 다소 misleading하다고 설명한다. HTTP는 hypertext jump를 효율적으로 만들기 위해 필요한 information transmission protocol이며, 전송 data는 plaintext, hypertext, audio, image 등 Internet-accessible information 전반이 될 수 있다.

HTTP Overview

HTTP는 transaction-oriented client/server protocol이다. 가장 전형적인 사용은 Web browser와 Web server 사이이며, reliability를 위해 TCP를 사용한다. 하지만 HTTP 자체는 stateless protocol이다. 각 transaction은 독립적으로 취급되며, 일반적인 구현은 transaction마다 TCP connection을 열고 transaction이 끝나면 닫을 수 있다. 다만 specification이 transaction lifetime과 connection lifetime을 반드시 1:1로 강제하지는 않는다.

HTTP가 stateless인 것은 Web 사용 패턴에 잘 맞는다. 사용자가 browser로 Web page와 document sequence를 빠르게 가져오고, 그 resource들이 여러 distributed server에 있을 수 있기 때문이다. Server가 모든 client interaction history를 protocol state로 유지하지 않아도 request 단위로 response를 만들 수 있다.

HTTP 관련 주요 용어는 다음과 같다.

HTTP의 또 다른 중요한 특징은 data format flexibility다. Client는 자신이 처리할 수 있는 format의 prioritized list를 request에 넣을 수 있고, server는 적절한 format으로 응답한다. 예를 들어 image를 처리할 수 없는 text-based browser라면 server가 image를 보내지 않아 불필요한 transmission을 줄일 수 있다. 이 구조는 새로운 standardized/proprietary format 확장에도 유리하다.

HTTP Operation

Figure 23.6은 HTTP operation의 세 형태를 보여준다. Direct connection, intermediate relay chain, cache가 있는 구조를 비교해 볼 수 있다.

Figure 23.6 · PDF p. 805 · user agent와 origin server 사이의 direct HTTP operation, intermediary chain, cache 사용 예

가장 단순한 경우는 user agent가 origin server와 direct TCP connection을 여는 것이다.

1. User agent가 origin server와 TCP connection을 연다.
2. Client가 HTTP request를 보낸다.
3. Request는 method, address인 URL(Uniform Resource Locator), request parameter/client information/additional content information을 담은 MIME-like message로 구성된다.
4. Server는 requested action을 수행하려고 시도한다.
5. Server는 status information, success/error code, server/response information, possible body content를 담은 HTTP response를 반환한다.
6. TCP connection이 닫힌다.

두 번째 경우는 user agent와 origin server 사이에 end-to-end TCP connection이 없고, logically adjacent systems 사이에 여러 TCP connection이 있는 구조다. Intermediate system들은 relay 역할을 하며 request를 server 방향으로 전달하고 response를 client 방향으로 되돌린다.

세 번째 경우는 cache가 request/response transaction을 저장하는 구조다. 같은 request가 나중에 오면 origin server까지 가지 않고 cache가 stored response를 제공할 수 있다.

HTTP Intermediate Systems: Proxy, Gateway, Tunnel

HTTP specification은 세 종류의 intermediate system을 정의한다: proxy, gateway, tunnel.

Figure 23.7 · PDF p. 806 · HTTP proxy, gateway, tunnel이 firewall, non-HTTP server, blind relay 상황에서 동작하는 방식

HTTP proxy는 다른 client를 대신해 server에 request를 제시한다. Client와 상호작용할 때는 server처럼, server와 상호작용할 때는 client처럼 동작한다.

Proxy가 필요한 대표 상황은 다음과 같다.

Proxy는 URL object에 대한 request를 받고, request를 interpret/rewrite/modify한 뒤 URL에 식별된 server 쪽으로 forwarding하는 agent다.

HTTP gateway는 client에게 origin server처럼 보이는 server-side intermediary다. Proxy와 달리 client는 gateway와 통신한다는 사실을 모를 수 있다. Gateway는 다른 server를 대신해 client request를 받고, 필요하면 non-HTTP system과 통신해 결과를 HTTP에 맞는 form으로 변환한다.

Gateway 사용 상황은 다음과 같다.

HTTP tunnel은 proxy/gateway와 달리 HTTP request/response를 해석하거나 변경하지 않는다. 두 TCP connection 사이의 relay point로 동작하며, HTTP messages는 user agent와 origin server 사이에 single HTTP connection이 있는 것처럼 unchanged로 전달된다. Tunnel은 중간 system이 반드시 있어야 하지만 message contents를 이해하거나 해석하면 안 되는 상황에 쓰인다. 예를 들어 firewall을 통과하기 위해 authenticated connection을 만들고 그 connection을 HTTP transaction에 유지하는 경우가 있다.

세 intermediary를 비교하면 다음과 같다.

Cache

cache는 이전 request/response를 저장해 새 request를 처리할 수 있는 facility다. 새 request가 stored request와 equivalent하면, cache는 URL이 가리키는 resource에 다시 접근하지 않고 stored response를 제공할 수 있다. Cache는 client, server, tunnel이 아닌 intermediate system에서 동작할 수 있다.

Cache의 장점은 response time과 network bandwidth consumption을 줄이는 것이다. 그러나 모든 transaction이 cacheable한 것은 아니며, client나 server가 특정 transaction을 일정 time limit 안에서만 cache하도록 제한할 수 있다. 이 점은 DNS의 TTL과 비슷하게 freshness와 performance 사이의 trade-off를 만든다.

HTTP Messages

HTTP message의 일반 구조는 start line, 여러 header, 빈 줄, 선택적 Entity Body로 생각하면 된다. Request에서는 첫 줄이 Request Line, response에서는 첫 줄이 Status Line이다.

Figure 23.8 · PDF p. 808 · HTTP message의 Request/Status line, header 계층, Entity Body 구조

원문은 HTTP specification에서 쓰는 augmented BNF notation을 간단히 설명한 뒤 HTTP message를 다음처럼 정리한다. 여기서 CRLF는 carriage return + line feed, SP는 space, *는 repetition, [...]는 optional element를 뜻한다.

HTTP-Message  = Simple-Request | Simple-Response | Full-Request | Full-Response

Full-Request  = Request-Line
                *( General-Header | Request-Header | Entity-Header )
                CRLF
                [ Entity-Body ]

Full-Response = Status-Line
                *( General-Header | Response-Header | Entity-Header )
                CRLF
                [ Entity-Body ]

Simple-Request  = "GET" SP Request-URL CRLF
Simple-Response = [ Entity-Body ]

Simple-Request와 Simple-Response는 HTTP/0.9의 단순 형식이다. Request는 URL을 붙인 단순 GET command이고, response는 해당 URL이 식별한 정보를 담은 block이다. HTTP/1.1에서는 이 단순 형식이 권장되지 않는다. 이유는 client가 content negotiation을 할 수 없고 server도 returned entity의 media type을 식별하기 어렵기 때문이다.

Full request/response에서 각 구성요소의 역할은 다음과 같다.

모든 HTTP header는 RFC 822 스타일의 field sequence다. 각 field는 새 줄에서 시작하고, field name: field value 형태를 가진다. 이 단순한 generic format 위에 매우 많은 HTTP field와 parameter가 얹힌다.

General Header Fields

General-Header는 request와 response 양쪽에서 쓸 수 있고, transferred entity 자체가 아니라 message 처리 경로와 connection/control 성격을 설명한다.

Request Messages

Full request message는 Request-Line으로 시작하고, 그 뒤에 general/request/entity header가 오며, 마지막에 optional Entity-Body가 붙는다.

Request-Line = Method SP Request-URL SP HTTP-Version CRLF

Method는 HTTP request command이고, Request-URL은 requested resource의 URL이며, HTTP-Version은 sender가 사용하는 HTTP version이다.

HTTP/1.1 request methods는 다음처럼 구분된다.

Request-Header는 request modifier처럼 동작한다. 즉 request와 client에 관한 추가 정보와 parameter를 제공한다.

Response Messages

Full response message는 Status-Line으로 시작하고 general/response/entity header, optional entity body가 뒤따른다.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Code는 received request에 대한 결과를 나타내는 three-digit integer이고, Reason-Phrase는 그 status code에 대한 짧은 textual explanation이다.

HTTP/1.1 status code category는 다음과 같다.

Successful response에서 entity body의 의미는 method에 따라 달라진다. GET이면 requested resource content, HEAD이면 entity body 없음, POST이면 action result를 설명하거나 포함하는 entity, TRACE이면 request message 자체, 그 밖의 method에서는 action result 설명이 된다.

Response-Header는 Status-Line에 넣기 어려운 response 관련 정보를 제공한다.

Entities

entity는 request 또는 response message 안의 Entity-Header와 Entity-Body로 구성된다. Entity는 data resource를 represent할 수도 있고, request/response에 딸려 가는 추가 정보를 구성할 수도 있다. 여기서 중요한 점은 HTTP message가 단지 “문서 한 개”를 실어 나르는 구조가 아니라, method/action/status에 맞춰 resource representation, submitted data, diagnostic echo, action result 등을 담을 수 있는 envelope라는 것이다.

Entity-Header는 entity body 자체 또는 body가 없을 때 request가 식별한 resource에 대한 optional information을 제공한다.

Entity Body는 arbitrary sequence of octets다. HTTP는 text뿐 아니라 binary data, audio, images, video까지 어떤 content type도 전송할 수 있도록 설계되었다. Body octets의 의미는 세 field가 순서 있는 encoding model로 결정한다.

entity-body := Transfer-Encoding(
                 Content-Encoding(
                   Content-Type(data)
                 )
               )

data는 URL이 식별한 resource content다. Content-Type은 data를 해석하는 방식을 정하고, Content-Encoding은 저장된 representation에 적용될 수 있으며, Transfer-Encoding은 전송 과정에서 message body를 만들기 위해 적용된다. 따라서 Content-Type과 Transfer-Encoding은 둘 다 body와 관련되지만 역할이 다르다. 전자는 “무엇인가”를, 후자는 “어떻게 안전하게 실어 보냈는가”를 설명한다.

장 전체 연결 관계

이 장은 DNS와 HTTP를 별개의 application처럼 나열하지만, 실제 Web access path에서는 둘이 연속된다.

DNS는 layer architecture 관점에서 application-level directory service지만, transport와 network layer의 주소 결정에 선행된다. HTTP는 TCP 위의 application protocol이며, MIME/RFC 822 스타일 header 구조와 Chapter 22의 message format 개념을 이어받는다. Content-MD5는 Chapter 21의 hash/security 개념과 연결되고, cache freshness는 DNS TTL과 비슷한 design trade-off를 가진다.

오해하기 쉬운 내용

핵심 용어 정리

확인 질문

1. DNS가 centralized HOSTS.TXT 방식보다 확장성 있는 이유는 무엇인가?
2. RR(Resource Record)의 TTL은 DNS cache에서 어떤 trade-off를 만드는가?
3. recursive technique과 iterative technique에서 책임을 지는 주체는 어떻게 다른가?
4. HTTP가 stateless protocol이라는 말은 TCP connection을 쓰지 않는다는 뜻인가?
5. HTTP proxy, HTTP gateway, HTTP tunnel은 client/server에게 각각 어떻게 보이는가?
6. Request-Line과 Status-Line은 HTTP message에서 각각 무엇을 식별하는가?
7. Content-Type, Content-Encoding, Transfer-Encoding은 entity body 해석에서 어떤 순서와 역할을 가지는가?