• 이 시리즈는 Computer Networking: A Top-Down Approach(7th Edition)를 읽고 각 챕터의 주요 내용을 요약하고 있습니다.
• 개인 학습 목적으로 작성한 글입니다.

컴퓨터 네트워크는 네트워크 기반 어플리케이션이 있기에 비로소 그 존재 의미가 있다.

• 이메일, 원격 접속 프로그램, 파일 전송 서비스
• WWW 기반의 검색, 전자상거래, 메신저 서비스
• VoIP 및 영상 기반 컨퍼런스 서비스; Skype, Hangout 등
• 영상 게시 및 스트리밍 서비스: Youtube, Netflix
• 다중 동시 접속 게임: Second life, WOW
• SNS 서비스: Facebook, Instagram, ...
• 위치 기반 서비스 - 데이팅, 지도, ...

이번 장에서는 네트워크 기반 어플리케이션과 관련된 아래의 주제들을 다룬다:

• application-layer의 핵심 개념
• 주요 네트워크 어플리케이션: Web, 이메일, DNS, P2P 파일 분산, 비디오 스트리밍
• 네트워크 어플리케이션의 개발: TCP, UDP, Socket 인터페이스

2.1 네트워크 어플리케이션이 가지는 주요 법칙

네트워크 어플리케이션 개발이란 결국, 네트워크 상에 존재하는 (역할 별) host가 사용할 프로그램을 개발하는 것

• web client, web server, p2p client, ...
• 여기서 말하는 application-layer의 프로그램은 end system에서 사용하는 것을 가리킨다.
  • router, switch 등의 프로그램은 network-layer 이하

이처럼 application-layer 이하는 신경쓰지 않아도 되는 상황은 네트워크 어플리케이션의 개발과 배포 속도를 빠르게 만든다.

2.1.1 네트워크 어플리케이션의 구조

여기서 말하는 어플리케이션이 구조란, 앞서 1.5.1에서 다룬 네트워크 구조(internet 프로토콜)와 별개

• 어플리케이션 개발자 입장에서는 네트워크 구조는 static하게 고정된 환경같은 것.
• 네트워크를 다룰 수 있는 API 셋을 제공받아 사용하게 된다

보통 아래 두 구조 중 하나를 따르는 것이 일반적이다:

client-server architecture

• server: 항상 켜져있는, 외부 host의 요청에 대응하여 서비스를 제공(serve)하는 host
• client: server host에 대하여 필요한 것을 요청(request)하는 host

이 구조는 아래와 같은 특징을 가진다:

• 각 client는 서로 직접적으로 통신하지 않는다. 반드시 server를 경유하게 된다.
• server는 고정된 IP를 가지고 있으며, client는 server에 언제나 요청을 보낼 수 있다.

서비스를 담당하는 서버 host가 단 한대일 경우, 해당 서비스의 사용자가 많아짐에 따라 서비스 성능이 힘에 부치게 된다. 이로 인하여 data center를 고안하고, 많은 트래픽을 감당할 수 있는 다수의 가상 서버들을 제공하는 역할을 맡는다(1.3.3에서 다룬 이야기 참조).

p2p architecture

• 개별 host가 peer로서 서로가 직접적으로 통신하는 구조. server는 소수가 존재하거나 아예 없다.
• 각 peer가 server를 거치지 않고 서로 직접 통신하므로 peer-to-peer 라 부르는 것
• 파일 공유, 화상 회의 서비스 등의 어플리케이션이 존재
• hybrid architecture: C/S 구조와 p2p 구조를 결합하여 이루어진 구조도 존재
  • ex. 각 사용자의 접속 IP를 공유하기 위한 server는 존재하지만, 실제 메시지 통신은 각 사용자가 p2p 방식으로 직접 수행하는 메시징 어플리케이션

p2p 구조 하에서는 각 peer가 client이면서 동시에 server 역할도 맡는다. 따라서 서비스 성능 확장이 용이하며(self-scalability), 비용 효율적이다. 다만, 이러한 탈중앙적(decentralized) 특성으로 인하여 보안, 성능, 안정성 측면에서 극복이 필요한 과제들도 존재한다.

2.1.2 프로세스 간 전송(Transport)

단일 운영체제 안에서 실행 중인 프로그램을 보통 프로세스(process)라 부른다.

• 이 책에서는 IPC(interprocess communication)가 아닌, 서로 다른 (또한 각기 서로 다른 운영체제를 사용하는) host 에서 실행중인 프로세스들 간의 통신을 다룬다.
• message: 두 프로세스가 네트워크를 통하여 서로 교환하는 데이터의 단위.

Client and Server processes

한 네트워크 어플리케이션은 서로 message를 주고 받는 여러 쌍의 process 세트로 구성된다. 한 쌍의 프로세스들은 각각 client와 server의 역할을 맡는다.

• 어떤 communication session이 형성되었을 때, 이 세션을 최초로 시작한 프로세스를 client라 보며, 해당 세션의 연결을 대기하는 프로세스를 server로 본다.
• 브라우저 - 웹 서버 의 구도를 떠올려보자.
• 한편, 한 process는 client 이면서 동시에 server로서 존재할 수 있다. 예를 들어 p2p 네트워크에 참여하는 process는 두 역할을 동시에 가진다.

The Interface between the Process and the Computer Network

여기서 다루고 있는 프로세스 간 통신은 네트워크를 경유하여 이루어진다. 이때 메세지를 송/수신하는 프로세스는 네트워크와 상호작용할 때 반드시 socket이라는 인터페이스를 거쳐야 한다.

socket이라는 인터페이스 창구의 존재 덕분에, 네트워크 관련 기능이 필요할 때 구현에 대한 신경쓸 것 없이 맘편하게 이용하기만 하면 된다. socket의 특징은 아래와 같다:

• application layer(L5)와 transpoort layer(L4) 사이에 존재하는 인터페이스(Figure 2.3 참조)
• socket은 프로그래밍 인터페이스(즉, 어플리케이션에서 사용 가능한 네트워크 API)로, 네트워크 어플리케이션의 통신 관련 로직은 socket을 기반으로 작성된다.
• 어플리케이션 개발자 입장에서는, 비즈니스 로직 측면에서 socket을 자유롭게 다룰 수 있지만, socket이 기반하는 네트워크 구현 관련 코어 로직은 제어할 수 없다. 즉, 철저하게 라이브러리 이용자의 입장인 것.
• 사용하는 network protocol의 종류(TCP/UDP), buffer와 segment의 크기 정도는 설정할 수 있으나 근본 로직을 바꿀 수는 없다.

Addressing Processes

프로세스 간에 네트워크 통신을 하려면 서로의 위치 형식을 규정해야 한다.

• IP: 출발/도착 host를 식별 (xxx.xxx.xxx.xxx)
• Port 번호: host 내의 특정 process에 대응. 한 host에서는 복수의 process가 동작할 수 있으므로, 이에 대한 식별이 필요하다.

2.1.3 어플리케이션이 사용할 수 있는 Transport 서비스 종류

process에서 송신된 message는 socket을 통하여 네트워크로 전달된다. socket을 통하여 L4 이후로 전달된 데이터를 목적지까지 전달하는 transport-layer 프로토콜은 그 특성과 한계에 따라 종류가 다양하다.

마치, 여행을 떠날 때 이용가능한 운송 수단이 비행기, 열차, 자동차, 도보 등 다양한 것처럼...

어떤 프로토콜을 사용해야 할까? 만들고자 하는 어플리케이션 특성에 가장 부합하는 것을 선정해야 한다. 데이터 전송 안정성, throughput, timing, security 측면에서 검토할 수 있다.

reliable data transfer

앞서 1.4.2에서 다룬 것처럼 packet은 유실될 수 있다(router buffer overflow, 일부 bit의 유실 등). 따라서, 전송된 데이터의 무결(integrity)함이 어플리케이션 차원에서 중요하다면 이를 보장할 수 있어야 하며, 이를 reliable data transfer 를 제공한다고 말한다.

packet loss가 발생해도 무방한 어플리케이션을 두고 loss-tolerant 하다고 부른다. ex. 영상 스트리밍 서비스의 경우, 약간의 튐(glitch) 정도는 넘어갈 수 있다.

throughput

throughput은 앞서 1.4.4에서 다룬 바 있다. 어플리케이션 사용시 형성되는 session들은 네트워크 대역폭을 다같이 공유하게 되므로, throughput 또한 그때그때 달라진다. 따라서, 일정 수준 이상의 throughput 이 유지되어야 한다면 이를 보장할 수 있어야 하며, 이를 guaranteed available throughput 을 제공한다고 말한다.

ex. 인터넷 전화 서비스에서 음성 인코딩이 32kbps로 이루어진다면, 이 대역폭은 최소한으로 보장되어야 서비스가 정상 서빙될 수 있다

• 이렇게 최소 보장 throughput이 정해진 앱 서비스를 bandwidth-sensitive application 이라 부른다. 이러한 서비스는 인터넷 상태 변동에 유연하게 대응하기 위한 알고리즘을 갖추고 있다. ex. 멀티미디어 서비스의 경우, 인터넷 상태가 나빠지면 자동으로 영상 화질을 낮춤.
• 반면 throughput에 민감하지 않은 서비스를 elastic application 이라 부른다.

timing

throughout과 유사하게, 데이터 송/수신의 최대 지연 시간 보장이 중요하다면 이를 보장해야 한다. ex. 실시간 화상 회의 솔루션

security

종단간 암/복호화, 데이터 무결성 검사, 종단 인증 등의 서비스를 제공할 수 있다.

2.1.4 인터넷이 제공하는 전송(Transport) 서비스

인터넷(일반적으로 TCP/IP 네트워크)는 아래의 2개 Transport 프로토콜을 제공한다.

TCP 서비스

TCP 서비스 모델은 아래의 특징을 가진다:

• connection-oriented(연결 지향) protocol
  • TCP 프로토콜에서는 두 프로세스가 application-layer(L5)의 message를 교환하기에 앞서, transport-layer(L4)를 제어하는 정보를 먼저 교환한다. 이 과정을 handshake라 부르며, 이를 통하여 연결 중의 packet loss에 대비한다.
  • 이 과정이 완료되면 두 프로세스의 socket 사이에 TCP connection 이 형성된다.
  • TCP connection은 full-duplex 란 특성을 가진다; 연결된 두 프로세스가 서로 동시에 message를 교환할 수 있다.
  • 통신이 완료되고 나면 해당 connection은 정리(tear down)되어야 한다.
• reliable data transfer(안정적 데이터 전송): TCP로 전송된 데이터 stream은 본래의 순서대로, 오류 또는 중복 bit 없이 전송되는 것이 보장된다.
• congestion control: 현재 프로세스가 사용하는 네트워크가 정체되었을 때, 네트워크가 정리될 때까지 대기한다.

Securing TCP

• TCP 자체에는 보안 서비스가 포함되지 않으므로, 민감 정보를 전송할 경우 보안 위험에 노출될 수 있다.
• 그래서 오늘날에는 TCP 연결시 SSL을 함께 적용하는 것이 보통이다. 암/복호화, 데이터 무결성 검증, 종단 인증 등 프로세스 종단간 보안 서비스가 적용된다.
• SSL은 transport-layer 프로토콜이 아닌, application-layer 수준의 프로토콜이다. 즉, 어떤 어플리케이션에서 SSL을 사용하고자 한다면 이를 어플리케이션 코드 단에서 적용해야 한다. 기존 socket API와 유사한 시그니처이지만, SSL-socket API를 사용하여 비즈니스 로직을 구현하는 식으로.

UDP 서비스

• 최소한의 서비스를 제공하는, 경량화된 transport 프로토콜
• connectionless(비연결) protocol이며, handshake 과정이 존재하지 않음
• unreliable data transfer 서비스임 - packet loss가 가능하며, message의 전송 순서가 보장되지 않음
• congestion control이 이루어지지 않음

Services Not provieded by Internet Transport Protocols

• reliable data transfer와 security 측면은, TCP와 UDP 두 프로토콜에서 비교가 가능
• 하지만 throughput과 timing 측면은 guarantee가 없다. 즉, 어플리케이션의 알고리즘 또는 디자인 측면에서 일정 수준 이상의 성능을 보장하도록 최선을 다하겠지만 반드시 라는 보장은 할 수 없는 것.
• 그래서 많은 인터넷 어플리케이션들은 대체로 TCP 기반으로 통신 기능을 구현한다 (Figure 2.5 참조)

2.1.5 Application-layer Protocols

앞서, 프로세스들은 socket을 통하여 서로 message를 교환한다고 배웠다. 그렇다면 이 message는 어떤 구조를 가지고 있을까? message의 구조(structure)을 정의하는 것이 application-layer protocol 의 역할이다.

• message type ex. 요청 / 응답
• type에 따라 message를 구성하는 다양한 형식(syntax) ex. fields
• 각각의 field들이 가지는 의미(semantics)
• 프로세스가 언제 / 어떻게 요청하고 응답하는지 그 규칙

대부분의 application-layer 프로토콜은 RFC 표준이다. 따라서 해당 규격을 준수한다면, 브라우저 또는 프로그램 종류와 무관하게 서로 message를 주고 받을 수 있게 된다. 물론, 공개되지 않고 독자적으로 사용되는 규격도 존재한다.

• "It is important to distinguish between network applications and application-layer protocols. An application-layer protocol is only one piece of a network application."
• 하나의 서비스를 완성하는 데에는 다양한 구성 요소가 필요하며, 프로토콜은 그 중 하나(하지만 아주 중요한)에 불과하다. 또한, 그러한 프로토콜은 그 쓰임과 특성에 따라 매우 다양하게 존재한다.
• 2.1.5의 가장 마지막 단락 참조

2.1.6 이 책에서 다루는 네트워크 어플리케이션의 종류

매일마다 다양한 인터넷 어플리케이션 서비스가 등장한다. 이걸 다 다룰 수는 없고, 그 중에서 가장 주류에 해당하고 또 중요한 것만 다룬다.

• Web → HTTP
• E-mail → SMTP, DNS
• P2P 파일 공유
• 비디오 스트리밍 + CDN

2.2 Web과 HTTP

• 본래 인터넷은 학자, 연구자, 대학생들만 쓰던 서비스였다.
• 그러나 1990년대에 W3와 Web 서비스가 등장하면서 저변이 크게 확대되었고 사람들의 삶의 방식을 바꿨다.
• 인터넷이라는 공간을 다양한 소규모 독립(서로 단절된) 네트워크들이 아닌, 하나의 단일한 네트워크로 통합시켰다.

사람들이 주목한 인터넷의 특성은 on-demand 이다. 기성 라디오 / TV와 같은 수동적이고 일정이 정해진 서비스가 아니라, 사용자가 원할 때 사용할 수 있다는 점이 가장 큰 매력이다. 또한 저렴한 비용으로 누구나 컨텐츠 제공자가 될 수 있으며, 오감을 자극하는 다양한 유형의 컨텐츠를 주고받을 수 있다.

2.2.1 HTTP 개요

• Web 서비스의 application-layer protocol
• client-server 구조로서 구현되며, 서로 HTTP message를 교환하여 기능을 구현.
• HTTP는 정리하면 아래의 것들을 정의한다.
  • (1) Web client가 web server에 대하여 web page를 요청하는 방식
  • (2) web server가 web page를 client에 전송하는 방식
  • HTTP 요청 - 응답 흐름의 개요는 Figure 2.6 참조

본격적인 논의에 앞서 Web에서 사용하는 주요 용어들을 정리한다.

• object: Web page(또는 document)를 구성하는 다양한 요소
• file: HTML, 이미지, 코드(js, java applet), 영상 등. file은 URL을 통하여 다루어진다.
• 웹 페이지는 페이지의 기본이 되는 base HTML file과 다양한 object로 이루어진다. 이때 base HTML file은 URL을 통하여 다른 object를 참조(가져와 사용)한다.
• URL: 해당 URL이 가리키는 object를 소유하는 server의 hostname와 해당 object의 path(경로)로 이루어진다.
  • ex. http://velog.io/@cadenzah/computer-network-02
  • 여기서 velog.io는 hostname, /@cadenzah/computer-network-02는 path를 가리킨다.
• Web browser: Web 이라는 맥락에서 보통 client 역할을 맡는 프로세스(아닐 수도 있다). client와 browser를 앞으로 혼용하여 사용
• Web server: Web 이라는 맥락에서 server 역할을 맡는 프로세스. URL로 요청 가능한 Web object를 소유한다.

HTTP는 TCP를 기반으로 동작한다.

• 브라우저와 서버가 우선 TCP 연결을 맺음 (3-way handshake)
• 해당 연결에 대하여 socket 인터페이스를 통하여 TCP 통신
• 이제 브라우저와 서버는 TCP socket을 사용하여 HTTP 요청/응답 message를 교환
• Once the client sends a message into its socket interface, the message is out of the client’s hands and is “in the hands” of TCP. ... This implies that each HTTP request message sent by a client process eventually arrives intact at the server. ... HTTP need not worry about lost data or the details of how TCP recovers from loss or reordering of data within the network. That is the job of TCP and the protocols in the lower layers of the protocol stack.

HTTP는 기본적으로 stateless(무상태) 프로토콜이며, 이를 바탕으로 web server는 성능이 닿는 한 무수한 서로 다른 요청을 받아내야 한다.

2.2.2 비지속 / 지속 연결

한번 형성된 TCP 연결을 재사용해야할까? 아니면 매번 새로운 연결을 맺어야 할까? 각각의 특성이 존재한다. HTTP는 기본적으로 persistent(지속 연결) 방식으로 동작하지만, 어플리케이션 상황에 따라 후자를 선택할 수도 있다.

HTTP with Non-Persistent Connections

• 1개의 HTML 파일과 10개의 이미지를 요청하는 p129의 예시 참조
• 이 때, 11번의 요청시 각기 11개의 TCP 연결이 별도로 맺어진다. 즉, server는 각 요청에 대한 응답이 정상 전송된 것을 확인하면 그 즉시 TCP 연결을 끊는다.

여기서는 고려하지 않았지만, 모던 브라우저는 통신의 병렬화 정도(degree of parallelism)를 제어할 수 있다. 대부분의 경우, 각 요청에 대하여 순차적으로(serial) 연결을 맺고 끊는 것이 아닌, 5~10개의 연결을 병렬로 맺고 동시에 자원을 받아오며 이를 통하여 전체적인 응답 시간을 줄인다.

round-trip time(RTT)

• 한 packet이 client의 요청으로 출발하여 server에서 응답받아 다시 client로 돌아오기까지의 시간
• propagation delay, queuing delay, packet-processing delay 가 모두 포함된다
• HTML 파일을 요청한 client(browser) 입장에서의 총 RTT는 p130을 참조

HTTP with Persistent Connections

non-persistent connection 은 매 요청마다 새 연결을 맺어야 하는데, 여기에는 아래와 같은 단점이 있다:

• TCP 연결에 필요한 buffer, variable 등을 매번 새로 구성해야 하므로 server에 부담(동시 연결이 수백개 이상이라면...?)
• TCP 연결을 맺는 데에 RTT가 소요되므로, 불필요한 시간 발생

HTTP 1.1은 persistent connection을 사용하여, 동일 client-server 요청이라면 이미 맺어진 연결을 재사용한다. 즉, 여러 연속적인 요청이 가능해진 것(pipeline).

• 여기에 더하여 HTTP/2는 한 통신에 요청과 응답을 동시에 담는(interleave; multiplex) 방식으로 더욱 성능을 개선
• HTTP 1.1과 HTTP/2의 비교: https://www.whatap.io/ko/blog/38/

2.2.3 HTTP 메시지 형식

HTTP 메시지는 요청 / 응답 두개 형식으로 나뉘며, 각각에 대한 명세가 별도로 존재한다.

HTTP 요청 메시지

# 아래는 예시
GET /@cadenzah/posts HTTP/1.1
Host: https://velog.io
Connection: close
User-agent: Mozilla/5.0
Accept-language: en

• 메시지는 사람이 읽을 수 있는 ASCII 텍스트로 작성됨
• 각 줄은 CR 및 LF로 끝남
• 각 줄의 주요 구성 (순서대로)
  • request line: 맨 첫번째 → method, URL, HTTP version
  • header lines: 그 다음으로 이어지는 4개 줄 → 헤더의 종류는 다양하며 얼마든지 더 추가 가능
    • "You might think that this header line is unnecessary, as there is already a TCP connection in place to the host. But, as we’ll see in Section 2.2.5, the information provided by the host header line is required by Web proxy caches." 즉, 중간에 proxy로 거쳐오는 node가 존재할 때 활용되는 header 또한 존재함.
    • header의 마지막은 CR/LF 만으로 이루어진 줄
  • entity body: POST 요청에서 사용되는 본문 데이터.
• request body 대신, query paramter를 사용하여 데이터를 전송할 수도 있다(?key=value).

HTTP 응답 메시지

# 아래는 예시
HTTP/1.1 200 OK
Connection: close
Date: Fri, 29 Apr 2022 19:12:42 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 29 Apr 2022 19:12:42 GMT
Content-Length: 2135
Content-Type: text/HTML
(data data data ......)

• 메시지 형식의 문법적인 구조는 요청의 그것과 유사
• 각 줄의 주요 구성
  • status line: 맨 첫번째 → HTTP version, status code, status message
  • header lines: 그 다음으로 이어지는 6개
    • Date는 응답이 전달된 시각을 나타내지만, Last-Modified는 해당 데이터가 생성 또는 수정된 마지막 시간을 나타낸다. 후자는 cache시 참조되므로 매우 중요.
    • 서브되는 데이터의 형식은 파일 자체의 확장자와 무관하게 Content-Type에 명시된 것을 우선하여 식별한다.
    • header의 마지막은 CR/LF 만으로 이루어진 줄
  • entity body: 요청에 대응하는 실제 데이터
• telnet 명령어를 사용하면 메시지를 직접 구성하여 HTTP 요청을 보내고 응답을 확인해볼 수 있다. (Press the carriage return twice after typing the last line).
• 브라우저는 현재 브라우저의 기술 스펙, 사용자 설정, 캐시 등을 바탕으로 알아서 HTTP 메시지를 구성하고 요청을 보낸다.

2.2.4 서버와의 상호작용: Cookie

HTTP 서버는 무상태(stateless)가 기본이지만, 때에 따라 state가 필요할 때가 있다. 이를 위하여 HTTP는 cookie라는 기능을 표준에 도입하였다. cookie는 한 웹 사이트(서버)가 각 사용자를 추적할 수 있도록 해준다.

cookie는 아래 4개 요소로 구성됨으로서 완성된다:

• HTTP 응답 메시지에 포함되는 Set-cookie header
• HTTP 요청 메시지에 포함되는 cookie header
• 사용자 시스템 및 브라우저에 보관되는 cookie 파일
• 서버에 유지되는 cookie 값 관련 database

흔한 웹 사이트에서 사용자 별로 Cookie를 삽입시키고, 이후 그 cookie를 활용하는 예시는 p137을 참조.


• "Note that the cookie file already has an entry for eBay(과거에 방문 이력이 있는, cookie를 사용하는 또다른 사이트), since Susan has visited that site in the past. As Susan continues to browse the Amazon site(이번에 처음 방문하는, cookie를 사용하는 사이트), each time she requests a Web page, her browser consults her cookie file, extracts her identification number for this site, and puts a cookie header line that includes the identification number in the HTTP request."
• "During the subsequent sessions, the browser passes a cookie header to the server, thereby identifying the user to the server. Cookies can thus be used to create a user session layer on top of stateless HTTP."

물론, 이러한 cookie는 사용자 맞춤 정보 제공이면서 동시에 사생활 침해이기도 하다. 이에 대한 논란은 현재도 존재.

2.2.5 Web Cache

HTTP 네트워크 관점에서 Web cache는 Proxy 서버를 뜻하며, 이 proxy는 한 HTTP 요청이 향하던 본래(origin)의 web server를 대신하여 요청 내용을 client에 반환한다. proxy는 origin이 가지고 있는 여러 자원들의 사본(copy)을 가지고 있어, 이러한 cache가 가능하다. proxy가 origin을 cache하는 양상은 Figure 2.11 참조.

• web cache는 origin과 browser 사이에서 client이자 server 의 역할을 동시에 가진다.
• web cache는 ISP 또는 LAN의 access network edge에서 구매 및 설치하여, traffic과 응답 시간을 효율화할 수 있다.
• web cache는 구성에 따라 client에 가깝게 또는 server에 가깝게 위치할 수 있다.
  • Figure 2.11은 client에 가까이 위치한 구성으로, forward-proxy 형태.
  • 반대로 server에서 cache를 운영할 수도 있는데, 이는 reverse-proxy 형태.
  • https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html
• web cache를 배치함으로써 얻는 이득은 Figure 2.12와 관련 설명을 참조.
  • cdn의 사용 사례도 등장한다. Figure 2.13 참조.

The Conditional GET

cache의 사용으로 응답시간을 줄일 수는 있으나, cache가 최신이 아닌(stale) 이슈도 해결해야 한다. 이를 해결하는 것이 HTTP의 conditional GET이며, 이를 위하여 IF-Modified-Since header를 활용한다. 요청 대상이 변경되었을 때에만 origin에 요청하여 최신 데이터를 반환하게 된다.

2.3 전자 메일

• e-mail은 인터넷 태동기부터 존재해온 대중적인 어플리케이션이며, 동시에 가장 중요하면서 활용도가 높다.
• e-mail이 본래 가지는 비동기적인 편리함과 더불어, 현대 e-mail은 하이퍼링크, HTML 텍스트, 멀티미디어의 힘으로 더욱 풍성해졌다.

e-mail은 아래의 3개 주요 요소로 구성된다.

• user agent: 사용자측 e-mail client ex. MS Outlook, Apple Mail 등
• mail server
• SMTP(Simple Mail Transfer Protocol)

이번 절에서는 송신자 Alice, 수신자 BoB 을 예시로 e-mail 시스템을 설명한다. e-mail이 인터넷 상에서 오고가는 큰 그림은 Figure 2.14를 참조.

• Alice와 Bob은 각자의 시스템에서 mail agent와 mail server를 실행한다.
• Alice가 작성한 메일은 mail agent가 메시지로 구성하고, 이 메시지는 자신의 mail server의 outgoing queue에 적재되어 대기되었다가, 적절한 때에 송신된다. 이 메시지는 수신자의 mail server 상의 mailbox로 전송된다.
• Bob이 메일을 읽고자 하면, mail agent가 Bob의 mail server의 mailbox에 요청하여, 수신한 메시지를 불러와 메일로 구성한다.
• Bob은 자신의 mailbox에 접근하고자 할 때, 인증(authentication)을 거쳐야 한다.
• Alice는 자신의 메일이 성공적으로 송신된 것을 확인하지 못하였다면, queue에 보관해둔 뒤 적절한 시간이 흐른 후 다시 시도한다(failure dealing)

위와 같은 일련의 규칙은 SMTP로 정의된다. SMTP 역시 다른 application-layer protocol과 마찬가지로 TCP 기반으로 작동한다. SMTP를 실행하는 프로세스는 client이자 server이다.

2.3.1 SMTP

SMTP는 HTTP보다 오래된 표준이다. 지금까지도 두루 쓰이는 유용한 기술이지만, 오래된 만큼 낡은 특징들도 존재한다. 예를 들어, mail message는 반드시 7-bit ASCII로 작성해야 한다 - 메일에 삽입되는 멀티미디어 컨텐츠까지도.

Figure 2.15는 mail이 전달될 때의 상황을 설명하고 있는데, 앞서 Figure 2.14를 설명할 때와 동일하므로 생략.

몇 가지 특징이 존재한다:

• mail은 항상 두 mail server 간의 일대일 직접(direct) 통신을 전제로 한다. 즉, 도중에 다른 서버를 경유하는 형태의 전송은 할 수 없다.
• mail을 주고받는 두 host 간에 TCP 연결이 맺어지고 나면, SMTP handshake 를 수행한다. 이 과정에서 client는 송신(sender)/수신(receiver) 정보를 알린다. 여기까지 마치고 나면, mail message를 보내게 된다.
• SMTP client는 자신의 outgoing queue의 메일을 다 보낼 때까지 위 과정을 반복하고, 발신을 완료하고 나면 TCP 연결을 끊는다.

SMTP handshaking 시 주고 받는 message의 구체적인 예시는 p147의 crepes.fr와 hamburger.edu 간의 메일 송수신 예시를 살펴보자.

• HELO, MAIL FROM, RCPT TO, DATA, QUIT 등의 명령어가 사용됨
• SMTP에는 (HTTP의 status code와 유사하게) reply code가 있어, server response에 이를 사용할 수 있다.
• SMTP는 persistent connection을 사용하며, client가 원하는 만큼 message를 전송할 수 있다 → QUIT으로 종료
• telnet을 사용하여 SMTP server와 TCP 연결을 맺고 나면, 위 명령어를 사용하여 SMTP 통신을 시작할 수 있다 (25 port 사용)

2.3.2 HTTP와의 비교

한 host에서 또다른 host로 파일(resource 또는 mail message)을 보내기 위한 protocol이라는 점, 또한 persistent connection을 사용한다는 점은 공통점이다. 그 밖에는?

• HTTP는 pull protocol이지만, SMTP는 push protocol이다. 처음 동작을 시작하는 주체의 관점에서 생각해보자.
• SMTP는 message 형식을 반드시 7-bit ASCII로 지켜야 한다. HTTP에는 이러한 인코딩 제약은 없다. cf. Content-type header
• HTTP는 여러 자원 요청시 저마다의 message로 나눌 수 있지만, SMTP는 반드시 한 mail message에 담아야 한다.

2.3.3 Mail 메시지 형식

• mail message에 대한 메타 정보는 header line에 담기며, 이는 message body 앞에 작성된다.
• header와 body 사이에는 빈칸 한줄(CR/LF)가 위치한다.
• 여기서 다룬 header 형식과 2.3.1에서 다룬 SMTP handshake의 명령어들을 서로 혼동하지 말자
  • SMTP handshake로 발송한 mail은 여기서 다룬 mail message의 형식을 띠고 있을 것

2.3.4 Mail 접근 Protocol

Alice의 mail server에서 Bob의 mail server로 메일이 전송되고 나면, Bob은 어떻게 메일을 열람할 수 있을까? 과거엔 이랬다:

• mail server host 에 shell 접속
• mail reader 프로그램(user agent)을 실행하여 메일 내용을 열람

오늘날에는 아래와 같은 특징을 가지도록 운영된다:

• client-server 구조 바탕으로 구현된 user agent 프로그램을 사용하여 mail server에 접근한다.
• user agent와 mail server는 물리적으로 분리한다. mail server는 애초에 항상 동작해야 하였지만, 이제 user agent는 필요시(on-demand)에만 구동하면 된다.
• 여러 사용자들이 (하나의 도메인 아래에 위치한) shared mail server를 공유한다. 이 mail server는 해당 사용자들이 참여하는 LAN의 ISP가 운영한다.

여기서 user agent는 mail server로부터 어떻게 자신의 앞으로 온 메일을 가져올 수 있을까? 앞서 다룬 SMTP는 mail을 전송하는 용도이어서, user agent가 mail server로부터 mail을 받아오기 위한 protocol이 필요해진다. 이러한 목적으로 POP3, IMAP, HTTP 등을 사용할 수 있다.

• SMTP is used to transfer mail from the sender’s mail server to the recipient’s mail server; SMTP is also used to transfer mail from the sender’s user agent to the sender’s mail server.
• A mail access protocol, such as POP3, is used to transfer mail from the recipient’s mail server to the recipient’s user agent.
• Figure 2.16 참조

POP3

• 아주 간단하지만 기능이 제한적인 프로토콜
• mail server에 110 port로 TCP 연결(telnet)시 POP3 통신이 바로 실행. 인증 성공 후에는 계속 transaction을 보낼 수 있다.
• 아래 3단계로 나뉘어져 실행
  • authorization: 로그인
  • transaction: 메일 관련 주요 기능을 mail server에 요청하는 단계; 메일 데이터를 가져오고, 메일함 관리, 메일 관련 통계 조회 수행
  • update: POP3 연결 세션이 종료될 떄에 발생; 앞서 transaction에서 지정해둔 메일 제거가 실제 실행된다.
• 실제 명령어 예시는 p152 참조

IMAP

• POP3는 mail 데이터를 순수하게 로드/제거만 할 수 있는 프로토콜로, 그 이상의 부가적인 기능은 local mail client에서 직접 구현해야 하는 한계 존재
• IMAP은 POP3가 제공하는 기능 외에도 추가적인 기능을 많이 제공:
  • 폴더 개념을 전면 도입하여, '받은편지함', '보낸편지함' 등 여러 폴더 단위로 메일 관리 가능
  • mail server에 저장된 메일 데이터에 대한 폴더 검색 기능 제공
  • 단순 메일 데이터 외에, 개별 사용자에 대한 상태(user state information across IMAP session)를 서버에서 유지 가능
  • server에 메일 데이터의 일부분(i.e. header 부분만)만 요청 가능 → 낮은 대역폭시 유용

Web-Based E-mail

• 앞서 POP3와 IMAP 소개에서 사용한 local mail agent는 별도 프로그램을 사용하는 것이 필요
• 오늘날에는 브라우저에서 바로 접속 가능한 Web 기반 이메일이 대세
• mail server에 대하여 HTTP 통신을 통한 데이터 교환이 이루어진다
• 브라우저 ↔ mail server 간에는 HTTP 통신이 이루어지나, 각 mail server 간에는 여전히 SMTP가 사용됨에 유의

2.4 DNS - 인터넷의 디렉토리 서비스

인터넷 상에서는, 인터넷에 연결된 각 host들을 어떻게 식별할까? 다양한 방법들이 존재한다.

...Although each of these identifiers can be used to identify people, within a given context one identifier may be more appropriate than another. ...

• hostname: 사람이 읽을 수 있는 형식의(mnemonic) 식별자 ex. www.velog.io
  • 식별자에서 파악가능한 정보가 제한된다는 한계 존재
  • 값의 길이가 가변적이므로, router가 처리하기에 부담스러울 수 있음
• IP address: 4Byte 크기 숫자값 식별자로, 해석하는 구조가 명확하게 정해져있다. 각 Byte는 0 ~ 255 사이의 값을 가리키고, 표기할 때에는 .으로 구분하여 표기한다.
  • 네트워크의 중첩(subnet) 정보 등을 알 수 있다.

2.4.1 DNS가 제공하는 서비스

DNS(domain name system)는 인터넷의 사용자인 인간과 인터넷 경로 처리를 담당하는 router의 각자 선호에 모두 부합하고자 생겨났다. DNS의 정의는 아래와 같다:

• DNS 서버들의 위계(hierarchy)를 구성하는 분산 데이터베이스
• 위의 분산 데이터베이스에 대하여 인터넷 host가 질의(query)하는 데에 사용되는 application-layer protocol

결국 주요 역할은 hostname을 IP 주소로 변환하는 것. 실제 작동시 주요 특징은 아래와 같다:

• DNS 서버를 구동하는 데에는 DNS 기능을 위한 소프트웨어인 BIND(Berkeley Internet Name Domain)를 유닉스 머신에서 사용
• UDP 통신을 사용하며, 53 port를 사용

DNS는 다른 application-layer 프로토콜에서, 사용자가 제공한 hostname의 실제 IP 주소를 얻고자할 때 사용된다. 예시는 p155 하단의 것을 참조. 예시에서 볼 수 있듯 DNS는 인터넷 어플리케이션 동작에 추가적인 지연 요소로 작용하므로, DNS는 요청 결과가 cache되도록 작동한다.

DNS는 또한 아래와 같은 기능들을 제공한다:

• host aliasing: (복잡한) hostname에 대하여 별칭 제공. 이때 원본 hostname을 canonical hostname이라 칭한다. 이 별칭을 질의하더라도 원본 hostname을 질의한 것과 동일한 결과를 반환받는다.
• mail server aliasing: (복잡한) mail server hostname에 대하여 별칭 제공.
  • MX record에 등록시, 이미 사용중인 hostname을 mail server의 hostname으로도 사용할 수 있다.
• 요청 분산(load distribution): 한 hostname에 대한 요청들을 여러 다른 IP로 분산. 사용자가 많은 대형 서비스에서 주로 이러한 방식을 채용.
  • For replicated Web servers, a set of IP addresses is thus associated with one canonical hostname.

Client-Server 패러다임 아래에서 DNS는 매우 중요한 네트워크 기능이다

DNS는

• end system 간에 client-server 모델 하에서 통신을 수행
• L4 이하의 transport protocol을 사용하여 통신 수행

한다는 점에서 다른 L5 단의 application-layer protocol과 동일하지만, 그 역할은 다른 protocol과 달리 특별하다. 다른 L5 protocol은 사용자가 직접 이용하는 인터넷 서비스를 담당하는 반면, DNS는 사용자와 인터넷 서비스 모두가 사용하는 hostname - IP 변환 기능을 제공한다. 즉, 인프라성 성격이 짙다는 것.

2.4.2 DNS 동작 개관

오늘날 네트워크 요청이 필요한 대부분의 어플리케이션은 내부적으로 DNS 질의를 사용한다. 어플리케이션 입장에서는 DNS의 내부 구현을 신경쓰지 않고 단순 사용하기만 하면 되겠지만, DNS 서비스의 구성, 그리고 (1) 어플리케이션과 DNS 간의 (2) DNS들 간의 통신 과정을 다루는 protocol은 다소 복잡하게 진화해왔다.

Thus, from the perspective of the invoking application in the user’s host, DNS is a black box providing a simple, straightforward translation service. But in fact, the black box that implements the service is complex, consisting of a large number of DNS servers distributed around the globe, ...

단순하게 구성한다면, 세상의 모든 DNS 질의를 단 하나의 DNS server가 처리(centralized design)하면 되겠지만, 그럴 경우 아래와 같은 한계가 있다.

• single point of failure
• 트래픽 부담
• DNS 서비스의 위치 문제: 어떤 client에게는 가깝겠으나, 어떤 client에게는 멀 수 있고, 이로 인한 delay가 variant하게 존재
• 유지보수의 어려움: DNS record 들은 아주 빈번하게 CRUD가 이루어진다.

위와 같은 설계는 결국 확장성이 좋지 않다. 따라서 DNS는 확장성을 최우선하여 설계되도록 발전하였다.

A Distributed, Hierarchical Database

• DNS 서버는 전세계에 걸쳐 배치되며, 각 DNS 서버들은 다함께 하나의 구조를 이룬다.
• 각 DNS 서버는 자신의 level에 따라, 한정된 개수의 record만을 가진다. 자신이 담당하지 않는 요청은 다음 level의 DNS 서버로 forward한다.
  • cf) cache로 인하여 저장하고 있는 record는 논외. 여기서 말하는 것은 DB에 저장하고 있는 항목들.
• DNS service가 hostname을 IP로 변환하는 과정의 예시는 p158 하단을 참조 - www.amazon.com의 예시

DNS 서버는 3개 level로 tier가 분류된다(Figure 2.17 참조).

• 한 hostname에 대한 DNS 질의는 각 tier class 별 DNS server를 거쳐, 최종적으로 authoritative DNS server로부터 원하는 IP 주소를 반환받게 된다.
  • 한 DNS server가 어떤 hostname에 대한 IP 주소를 최종적으로 반환해준다면, 해당 DNS server를 authoritative 하다고 부른다.
• 각 tier 별 DNS server는 그 다음 tier DNS server에 대한 IP 주소들을 보유한다.
  • authoritative DNS server는 자신이 맡는 hostname의 IP를 반환하거나, 서브도메인 등을 처리
  • subdomain에 대한 IP를 요청한 경우, authoritative DNS server가 해당 subdomain의 IP를 반환하거나, subdomain에 대한 DNS server가 개별 존재할 경우 해당 DNS server에 대한 IP를 반환한다(NS Record; p161의 cs.umass.edu예시 참조).
  • 본문에는 TLD(top-) 서버만을 언급했으나, SLD(second-) 또한 존재 ex. .co.kr에서 .co
• 다양한 회사들이 DNS 서버 유지에 자원을 투입한다.
• public service에 대하여 희망하는 hostname을 붙이고자 한다면, 해당 서비스 제공자는 해당 hostname에 대한 DNS record를 등록해야 한다.
  • ex. velog.io 로 접근이 가능하게 하려면, .io를 담당하는 TLD 서버에 쿼리했을 때 velog.io를 담당하는 authoritative DNS server의 IP 주소가 획득될 수 있도록, velog 도메인에 대한 DNS record 등록이 이루어져야 함
  • 직접 authoritative DNS server를 운영하고 TLD 서비스 쪽에 등록하거나, DNS 호스팅 서비스(ex. AWS의 Route 53)를 이용

위 3개 level에 속하지는 않지만, LAN 및 WAN에 대한 ISP 수준에서 운영하는 local DNS server도 존재하며, 오늘날 인터넷 접속 환경에서 아주 중요한 역할을 담당한다:

• 해당 네트워크에 연결된 host들이 사용할 수 있는, 네트워크에서 자체 제공되는 DNS 서비스
• 사용중인 네트워크에 local DNS server가 설정되었을 경우, 네트워크 내 host에서 발생한 DNS 질의는 반드시 해당 local DNS를 거친다. 즉, DNS 요청 처리에 대한 proxy 역할을 맡는 셈.
• local DNS server는 해당 네트워크 내의 DNS 질의에 대한 cache 역할도 맡게 되며, 이를 통한 트래픽 절감 효과는 크다.
• 요청된 hostname을 authoritative DNS server가 처리할 수 없을 경우, 해당 요청을 처리할 수 있는 DNS server로 한번 더 질의를 forward한다(p161의 예시 참조)
• Figure 2.19 참조(cse.nyu.edu가 gaia.cs.umass.edu의 IP 주소를 질의하는 과정 예시)

DNS 질의가 이루어지는 방식은 recursive와 iterative 로 두 가지가 존재한다.

• recursive: 질의를 요청한 최초 service를 대신하여, 다른 service가 해당 질의 결과를 받아오는 경우
  • Figure 2.20은 recursive query 로만 이루어져 있다.
• iterative: 질의를 요청한 최초 service가 다른 service에 forward하지 않고 질의 결과를 받는 경우

DNS 질의시 두 방식이 혼재되어 사용되는 것이 보통이다; 최초 host에서 local DNS server로 질의하는 것은 recursive이나, 이후 local DNS server는 iterative하게 처리해낸다.

DNS caching

DNS 질의시 caching을 통하여 지연 시간과 DNS 요청 횟수를 모두 절감할 수 있다. 원리는 단순하다. 동일 DNS 질의 요청에 대하여 재활용할 수 있도록, DNS 질의 내용을 서버에 일정 기간 캐싱하는 것이다.

이 전략은 모든 tier DNS server 질의에 적용된다. 예를 들어, local DNS server가 naver.com에 대한 질의를 하였을 때, root, .com, naver.com에 대한 각각의 DNS server record를 모두 cache한다. 따라서 향후 동일 서버에서 github.com을 질의하더라도 root에 대한 질의는 생략할 수 있다. 각 tier 별 DNS server들도 동일한 전략으로 cache를 수행한다.

2.4.3 DNS Record와 Message

여러 유형의 DNS server들이 형성한 DNS 분산 데이터베이스가 보관하는 데이터를 DNS resource record(RR) 라고 부른다. RR은 4개 쌍(tuple)의 형식을 가진다:

(Name, Value, Type, TTL)

• TTL(time to live): 해당 record가 cache 될 때 유효기간을 지정
• Type: Record의 유형. 유형에 따라 Name과 Value의 의미가 상이하다.
  • Type=A → Name: hostname / Value: IP 주소; 일반적인 hostname-IP 대응에 대한 record
  • Type=NS → Name: domain / Value: hostname of authoritative DNS server; DNS 질의가 계속 이어질 수 있도록 정보 제공
  • Type=CNAME → Name: hostname의 alias / Value: canonical hostname; alias 지정을 위한 record
  • Type=MX → Name: mail server에 대한 alias / Valuie: canonical name of mail server; 간편한 메일 도메인을 위한 record

NS Record의 사용 예시는 p164의 마지막 단락 참조; NS Record에서 DNS server를 지정시 hostname을 사용한다면, 해당 hostname을 위한 A Record 또한 추가되어야 한다.

DNS Messages

• DNS message는 query와 reply 두 유형으로 존재한다. 자세한 형식은 p165 참조.
• nslookup 명령어를 사용하면 DNS 질의를 직접 사용해볼 수 있다.

Inserting Records into the DNS Database

DNS Record가 DNS server에 어떤 식으로 추가되고 운영/관리될까? 아래 예시를 살펴보자:

1. 사용하고자 하는 도메인이 현재 사용중인지 확인하고, 사용 신청 및 등록 → registrar 서비스 이용
2. 등록한 도메인에 대하여 primary / secondary authoritative DNS server 정보 등록 → registrar는 도메인과 DNS 서버 정보를 기반으로, 연관된 TLD server에 A 및 NS Record가 등록되도록 조치해줌
   • 필요시 웹 서비스에 대한 A Record 또는 이메일 서비스에 대한 MX Record도 등록하여 정상 작동하도록 설정

2.5 Peer-to-Peer 파일 분산

TBD