[네트워크] 2. Application layer (3) - HTTP / SMTP / DNS

Reference - Computer Networking: a Top Down Approach

 

 

 

Web과 HTTP (Hypertext Transport Protocol)

 

주요 용어 정리

 

object : web page를 구성하는 요소 (HTML file, JPEG image, java applet, audio file, ...)

URL(Uniform Resource Locator) : 네트워크 상에서 리소스가 위치한 정보를 나타내는 URI, 각각의 object는 object를 소유하는 server의 hostname과 object의 path로 이루어진다.

URI(Uniform Resource Identifer) : URL, URN의 상위 개념, 인터넷 자원을 식별할 수 있는 문자열

URN(Uniform Resource Name) : URI의 표준 포맷 중 하나로, 이름으로 인터넷 리소스를 특정하는 URI (URL처럼 어떻게 접근할 것인지 명시하지 않음)

웹 페이지는 base HTML file과 다양한 object로 구성된다.

 

HTTP

 

HTTP(Hypertext Transport Protocol) = Web 서비스의 application layer protocol.

client-server 구조로, 서로 http message를 교환하여 기능을 구현한다. client가 server에 페이지를 요청하고, server가 client에게 페이지를 보내는 방식으로 동작한다.

또한 HTTP는 stateless 프로토콜이기에, client의 요청 기록에 대한 정보를 가지고 있지 않다.

 

Connection

 

HTTP는 persistent / non-persistent 두가지 연결 방식으로 동작한다.

non-persistent : 각각의 요청마다 각각의 TCP 연결이 별도로 맺어진다. 요청에 대한 응답이 오면 TCP 연결을 끊는다.

non-persistent response time : RTT(TCP connectio)+RTT(request and first few bytes) + file transmission time

persistent : 일반적으로 http는 이미 맺어진 TCP 연결을 사용한다. 동일 client-server 요청이라면, 연결 시 불필요한 overhead(RTT, TCP connection에 필요한 buffer, ...)를 줄이기 위함이다.

 

HTTP Server architecture

 

single-threaded web server : 서버가 한번에 하나의 클라이언트 요청만 처리

multi-threaded web server : 각 클라이언트 요청마다 별도의 스레드가 생성되어 동시에 처리

thread pool web server : 미리 생성된 스레드 풀을 사용하여 클라이언트 요청 처리

 

HTTP message

 

http 요청 메세지는 ASCII 텍스트로 작성되며, request / response 두 타입이 있다.

request message : 첫번째 줄은 GET, POST, HEAD commands가 있는 request line, 그 다음으로 이어지는 줄들에는 header lines가 있다. header line에는 host, user-agent, accept-language 등이 들어간다. 

각 line의 끝에는 \r\n (행의 맨 좌측으로 이동하는 Carriage Return char, 다음 행으로 내리는 Line Feed char)이 붙는다. 

header의 마지막은 /CR/LF만으로 이루어진다.  post 요청이라면 본문 데이터인 entitiy body가 붙는다.

response message : 첫번째 줄은 http version, protocol status code, status message인 status line,

그 다음으로 이어지는 줄들에는 header lines가 있다. header line에는 Date, server, last-modified 등이 있다. 

마찬가지로 header의 마지막은 /CR/LF만으로 이루어진다. 그리고 요청에 대응하는 실제 데이터인 entity body가 들어간다.

 

HTTP Response Status code

 

response message의 첫번째 줄에 들어가는 status code의 대표적인 종류는 아래 5개가 있다.

200 OK : request가 성공

301 moved permannently : request object가 이동했다. = 해당 url이 영구적으로 새로운 url로 변경되었다.

400 bad request : request message를 이해할 수 없다. = 클라이언트 요청 구문이 잘못되었다.

404 not found : request한 document가 서버에 없다.

505 HTTP version not supported : request에 사용된 http 버전을 서버가 지원하지 않는다.

 

Cookie

 

HTTP 서버는 기본적으로 stateless하지만, state가 필요할 수 있다. 이때 cookie를 통해 웹사이트(=서버)가 사용자를 추적할 수 있게 해준다. cookie는 아래 4가지 요소로 구성된다.

http response message에 포함되는 Set-cookie header (이때 사용자를 위한 ID 생성)

다음 http request에 포함되는 cookie header (이때 사용자는 다음 request에 cookie ID를 포함함)

사용자 시스템에 보관되어 사용자 브라우저에서 관리되는 cookie file (로컬에서 해당 ID를 보관)

 웹사이트(=서버)에서 유지되는 cookie database (서버에서 해당 ID를 보관)

쿠키는 인증, 장바구니, 추천 등에 활용되지만, 사생활 침해라는 단점이 있다.

 

Web caches (Proxy server)

 

HTTP 관점에서 웹 캐시는 Proxy 서버를 뜻한다. Proxy 서버는 서버와 클라이언트 사이에서의 요청과 응답을 이어서 처리해주는 중간관계자 역할이다. client이자 server의 역할을 동시에 가질 수 있으며, 이러한 이유로 Web cache는 Proxy(각 ISP)가 origin 서버 자원들의 사본을 가지고 있기에 가능해진다. 일반적으로 Web cache는 ISP(학교, 기업 등)에 저장된다.

이를 통해 client의 request에 따른 response time을 감소시키고, 네트워크 link의 traffic을 감소시킨다.

또한 많은 수의 캐시 서버가 분산되어 있기에, 자금이 부족한 CP(Contents Provider)도 server traffic을 최소화할 수 있다.

 

 Conditional Get with Web Cache

 

proxy server의 cache가 최신 state가 아닐 수 있으므로, 이를 해결하기 위해 conditional GET인 'IF-Modified-Since: <date>' header를 활용하여 요청 대상이 변경되었다면 origin에 요청하여 최신 데이터를 반환한다. 이를 통해 link utilization을 줄이고, 변경되지 않은 콘텐츠에 대해 object transmission delay를 없앨 수 있다. 물론 컨텐츠가 변경되지 않았다는 것을 알릴 때의 transmission delay가 생기지만, 전체 object의 transmission delay에 비하면 매우 적다.

 

SMTP (Simple Mail Transfer Protocol)

SMTP(Simple Mail Transfer Protocol)은 email service에 관한 프로토콜이다.

user agent(mail reader), mail server, SMTP 3개의 주요 요소로 구성된다.

 

송신자 Alice와 수신자 Bob이 있다고 가정하자. 이때 SMTP에 따른 email system을 설명하자면

1. Alice와 Bob은 각자 시스템에서 user agent와 mail server를 실행한다.

2. Alice가 메일을 작성하면 user agent가 message로 구성하고, 이는 본인 mail server의 message outgoing queue에 적재되었다가 적절한 때에 수신자의 mail server의 mailbox로 보내진다.

3. Bob은 메일을 읽을 때, authentication을 거친다.

4. 인증이 끝나면 Bob의 user agent가 mail server에 mailbox를 요청하여 수신한 message를 메일로 구성한다.

5. Alice의 메일이 송신에 실패했다면, queue에 보관해둔 뒤 얼마 후 다시 시도한다. (failure dealing)

 

SMTP의 주요 특징

 

- SMTP는 TCP 기반으로 작동하고 port 25를 사용한다. 또한 양측 모두 client이자 server다.

- SMTP는 persistent connection을 사용한다.

- mail은 항상 두 mail server간 일대일 direct transfer를 전제로 한다.

- transfer는 3단계로 구성된다. SMTP handshake - transfer of messages - closure.

- message는 7-bit ASCII로 작성되어야 한다.

- SMTP server는 end of message의 sequence로 CRLF.CRLF(\r\n.\r\n)를 쓴다.

 

Comparison with HTTP

 

- 모두 ASCII command/response이며, status code를 가짐.

- HTTP는 Pull기반(client가 데이터를 요청), SMTP는 Push기반(서버가 클라이언트에게 자동으로 전송)

- HTTP는 하나의 웹페이지를 로드하기 위해 캡슐화된 여러개의 HTTP 요청과 응답이 오간다.

- SMTP는 여러 object를 하나의 메세지로 묶어서 전송한다.

 

Mail Access Protocols

 

SMTP는 mail을 전송하고 수신자의 서버에 저장하는 역할.

user agent가 mail server로부터 mail을 받아오기 위한 프로토콜이 필요 -> POP3, IMAP, HTTP

POP3 : mail 데이터 load/delete만 가능. mail server에 110 port로 TCP 연결. authorization 후 download and delete(or keep). stateless across sessions.

IMAP : POP3에 추가적인 기능. 폴더 개념을 통해 저장된 메일 데이터 조작 가능. keep state(userID) across sessions.

HTTP : Web-based email. 위 2개는 별도 프로그램을 사용해야 함. 브라우저와 mail server간 HTTP 통신, 각각의 mail server 간에는 SMTP로 통신. 요즘은 보통 이걸 사용함.

 

DNS (Domain Name Server)

 

DNS(Domain Name Server) : name server들의 hiearchy를 구성하는 분산 데이터베이스.

Internet host의 query에 사용되는 application-layer protocol이다.

 

인터넷 상에서 연결된 각 host를 식별하는 방법. 사람과 Internet hosts, routers에 모두 적합.

사람은 SSN, name / Internet hosts, routers는 32-bit IP address로 식별.

 

DNS services

 

hostname to IP address translation : hostname과 IP주소 간 변환

host aliasing : 복잡한 hostname(=canonical)을 별칭(alias names)으로 변환

mail server aliasing : 복잡한 mail server hostname을 별칭으로 전환

load distribution : 한 hostname에 대한 요청을 다른 복제된 여러 IP로 분산. 대형 서비스에서 사용함.

 

DNS structure

 

centralized DNS가 아닌 이유

1. single point of failure

2. traffic volume

3. client 별 distance 차이에 따른 비효율성

4. 유지보수의 어려움

=> 즉, 확장성이 좋지 않아서.

 

DNS의 과정

 

따라서 DNS는 Distributed, hierarchical database의 형태이다. DNS 서버는 전세계에 걸쳐 배치되며, 각 DNS 서버들은 다함께 하나의 구조를 이룬다. 각 DNS 서버는 자신의 level에 따라 한정된 개수의 record를 가지며, 자신이 담당하지 않는 요청은 다음 하위 level의 DNS 서버로 forward 한다.

.kr나 .com 등을 TLD(Top-level Domain) server라 하며, 한 DNS가 어떤 hostname에 대한 IP 주소를 반환할 때 해당 DNS를 authoritative DNS라 한다. 이는 조직이나 service provider에 의해 유지된다.

public service에 대해 희망하는 hostname을 붙일 때(.kr 등) 서비스 제공자는 해당 hostname에 대한 DNS record를 등록해야 한다. AWS Route 53등의 DNS 호스팅 서비스로도 가능하다. ISP 수준에서 운영하는 LAN/WAN에 대한 local DNS server도 존재한다. DNS 요청 처리에 대한 proxy 역할을 맡는 셈이다. 또한 해당 네트워크 내 DNS query에 대한 cache역할을 하여 트래픽을 절감한다. 

 

DNS query 방식

 

iterated query : query를 요청한 최초 service가 다른 service에 forward하지 않고 결과를 받는 경우

 recursive : query를 요청한 최초 service를 대신하여 다른 service가 결과를 받아오는 경우 (보통 root, 해당 방식은 root server에 큰 부담을 줌)

 

DNS caching

 

모든 tier DNS에서 일정 기간동안 해당 내용을 caching하여 지연 시간을 절감할 수 있다.

 

DNS Record

 

여러 DNS server들이 형성한 DNS 분산 데이터베이스가 보관하는 데이터를 DNS resource record라 한다.

(name, value, type, TTL(=record가 cache될 때 유효기간)) 형식이다.

 

Record의 Type에 따라 Name과 value의 의미가 달라진다.

type=A -> name : hostname, value : ip 주소

type=NS -> name : domain, value : hostname of authoritative DNS

type=CNAME -> name : alias for canonical name, value : canonical hostname

type=MX -> alias for mail server name, value : canonical mail server name

 

DNS protocol, messages

 

query와 reply messages는 같은 message format을 갖는다.

message header엔 {identification: 16bit(for query, reply to query uses name), fags: query or reply / recursion desired, recursion available, reply is authoritative} 가 들어가며 그 외 name, type fileds for a query, records for authoritative servers 등 여러 message가 들어간다.

 

Inserting records into DNS Database

 

Network Solutions와 같은 기업에 DNS registrar를 이용하여 등록한다.

domain과 primary / secondary authoritative DNS의 IP를 등록하면 TLD server에 A record와 MX record가 등록되도록 도와준다.