두 호스트 H1과 H2가 있을 때, 네트워크 계층은 두 호스트 중 하나의 트랜스포트 계층 세그먼트를 추출하여 H2의 트랜스포트 계층까지 전달하는 역할을 한다.

라우터는 트랜스포트 계층과 애플리케이션 계층을 지원하지 않으므로 프로토콜 스택에서 네트워크 계층의 상위 계층은 존재하지 않는다.

각 라우터에는 데이터 평면과 제어 평면이 존재한다.

• 데이터 평면 : 입력 링크에서 출력 링크로 데이터그램을 전달한다.
• 제어 평면 : 데이터그램이 출발지 호스트에서 목적지 호스트까지 전달되게끔 로컬 포워딩, 라우터별 포워딩을 대응시킨다.

💡 네트워크 계층의 근본적인 역할은 송신 호스트에서 수신 호스트로 패킷을 전달하는 것이다.

위 역할을 위한 중요한 기능 두 가지

• 포워딩(전달) : 패킷이 라우터의 입력 링크에 도달했을 때 라우터는 그 패킷을 적절한 출력 링크로 이동시켜야한다. 포워딩에서 예외적으로 한 기능은 데이터 평면에서 실행된다. 매우 짧은 시간 단위(보통 몇 나노초)를 갖기에 대표적으로 하드웨어에서 실행된다.
• 라우팅 : 송신자가 수신자에게 패킷을 전송할 때 네트워크 계층은 패킷 경로를 결정해야 한다. 이러한 경로를 계산하는 알고리즘을 라우팅 알고리즘이라고 한다. 네트워크 전반에 걸쳐 출발지에서 목적지까지 데이터그램의 종단 간 경로를 결정하여 시간이 오래걸려 소프트웨어에서 실행된다.

라우터는 도착하는 패킷 헤더의 필드값을 통해 포워딩 테이블의 내부 색인으로 사용하여 패킷을 전달한다.

포워딩 테이블 엔트리에 저장되어 있는 헤더의 값은 해당 패킷이 전달되어야 할 라우터의 외부 링크 인터페이스를 나타낸다.

라우팅 알고리즘은 각각의 모든 라우터에서 실행되며, 라우터는 포워딩과 라우팅 기능을 모두 갖고 있어야 한다.

또한, 한 라우터의 라우팅 알고리즘 기능은 다른 라우터의 라우팅 알고리즘과 소통하며 포워딩 테이블의 값을 계산한다.

이러한 소통은 라우팅 프로토콜에 따라 라우팅 정보에 포함된 라우팅 메시지를 교환하며 이루어진다.

(더 자세한 내용은 5장에서 다룬다.)

위 그림은 라우터로부터 물리적으로 분리된 원격 컨트롤러 컴퓨터와 각각의 라우터에 의해 사용될 포워딩 테이블을 분배하는 다른 접근법을 보여준다.

라우터는 원격 컨트롤러와 포워딩 테이블과 그 밖의 라우팅 정보를 포함한 메시지를 교환함으로써 소통한다.

원격 컨트롤러가 포워딩 테이블을 계산 및 배분하는 동안 라우팅 기기는 포워딩만을 수행한다.

즉, 네트워크가 소프트웨어적으로 정의되었을 때 포워딩 테이블을 계산하는 컨트롤러는 라우터와 상호작용을 하며 소프트웨어에서 실행된다.

이렇게 원격 컨트롤러가 라우터와 떨어져서 높은 신뢰성과 중복성을 갖춘 원격 데이터 센터에 위치하는 접근 방법은 SDN(software defined networking)의 중심이다.

(더 자세한 내용은 5장에서 다룬다.)

네트워크 계층 제공 서비스

• 보장된 전달: 이 서비스는 패킷이 출발지 호스트에서부터 목적지 호스트까지 도착하는 것을 보장한다.
• 지연 제한 이내의 보장된 전달: 이 서비스는 패킷의 전달을 보장할 뿐만 아니라 호스트 간의 특정 지연 제한(예: 100ms 이내) 안에 전달한다.
• 순서화 패킷 전달: 이 서비스는 패킷이 목적지에 송신된 순서대로 도착하는 것을 보장한다.
• 최소 대역폭 보장: 이 네트워크 계층 서비스는 송신과 수신 호스트 사이에 특정한 비트율의 전송 링크를 에뮬레이트한다. 송신 호스트가 비트들을 특정한 비트율 이하로 전송하는 한, 모든 패킷이 목적지 호스트까지 전달된다.
• 보안 서비스: 네트워크 계층은 모든 데이터 그램을 출발지 호스트에서는 암호화, 목적지 호스트에서는 복호화할 수 있게 하여 트랜스포트 계층의 모든 세그먼트에 대해 기밀성을 유지해야한다.

이 외에도 수많은 변형들이 있다.

인터넷 네트워크 계층은 최선형 서비스(best-effort service) 라고 알려진 서비스를 제공한다.

최선형 서비스의 특징

• 패킷을 보내는 순서대로 수신됨을 보장하지 않는다.
• 목적지까지 패킷이 전송됨을 보장하지 않는다.
• 종단 시스템 간 지연이 보장되지 않는다.
• 보장된 최소 대역폭이 없다.

이렇게 서비스를 제공하지 못하는 인터넷 네트워크 계층의 대안으로 좋은 보다 서비스 모델을 정의하고 구현했지만 인터넷 네트워크 계층은 놀라운 범위의 애플리케이션을 가능하게 할만큼 충분히 좋다고 입증되었다.

4장에서는 네트워크 계층 데이터 평면의 구성요소를 살펴본다.

위 그림을 라우터의 구조를 나타낸다.

• 입력 포트
  • 입력 포트의 맨 왼쪽과 맨 오른쪽 박스는 라우터로 들어오는 입력 링크로, 물리 계층 기능을 수행한다.
  • 또한 입력 포트는 들어오는 링크의 반대편에 있는 링크 계층과 상호 운용하기 위해 필요한 링크 계층 기능을 수행한다. 이것은 입력 및 출력 포트에서 미들박스로 표시된다.
  • 가장 중요한 기능은 입력 포트의 가장 오른쪽에서 수행되는 검색 기능이다. 여기서 포워딩 테이블을 참조하여 도착된 패킷이 스위치 구조를 통해 라우터 출력 포트를 결정한다.
  • 라우팅 프로토콜 정보를 전달하는 패킷인 제어 패킷은 입력 포트에서 라우팅 프로세서로 전달된다.
  • 여기서의 포트는 앞에서 언급한 포트와는 다르다.
• 스위치 구조
  • 스위치 구조는 라우터의 입력 포트와 출력 포트를 연결한다.
  • 라우터 내부에 포함되어 있다.
• 출력 포트
  • 출력 포트는 스위치 구조에서 수신한 패킷을 저장하고 필요한 링크 계층 및 물리 계층 기능을 수행하여 출력 링크로 패킷을 전송한다.
  • 링크가 양방향일 경우 출력 포트는 일반적으로 동일한 링크의 입력 포트와 한 쌍을 이룬다.
• 라우팅 프로세서
  • 제어평면 기능을 수행한다.
  • 전통적인 라우터에서는 라우팅 프로토콜을 실행하고 라우팅 테이블과 연결된 링크 상태 정보를 유지 관리하며 라우터의 포워딩 테이블을 계산한다.
  • SDN 라우터에서 라우팅 프로세서는 원격 컨트롤러와 통신하여 원격 컨트롤러에서 계산된 포워딩 테이블 엔트리를 수신하고 라우터의 입력 포트에 이러한 엔트리를 설치한다.
  • 네트워크 관리 기능을 수행한다.

라우터의 입력 포트, 출력 포트, 스위치 구조는 거의 항상 하드웨어로 구현된다.

제어 평면은 일반적으로 소프트웨어로 구현되며 라우팅 프로세서(일반적으로 기존 CPU)에서 실행된다.

입력 포트의 기능은 위에서 언급한 바와 같다.

입력 포트에서 수행되는 검색은 라우터 동작의 핵심이다.

라우터는 포워딩 테이블을 사용하여 도착 패킷이 스위치 구조를 통해 전달되는 출력 포트를 검색한다.

포워딩 테이블은 라우팅 프로세서에서 계산되거나 갱신되거나 원격 SDN 컨트롤러에서 수신된다.

포워딩 테이블은 라우팅 프로세서에서 맨위 그림과 같이 각 라인 카드로 복사되고, 이렇게 각 라인이 복사본을 사용하여 패킷 단위로 중앙 집중식 라우팅 프로세서를 호출하지 않게 되어 병목 현상을 피할 수 있다.

32비트의 IP 주소의 경우 포워딩 테이블을 억지로 구현한다면 모든 가능한 목적지 주소마다 하나의 엔트리가 필요하고, 이는 40억개 이상의 주소가 있어야 하므로 불가능하다.

라우터에서 0에서 3까지의 4개의 링크가 있다고 가정해보자.

목적지 주소 범위로 포워딩 테이블을 구성할 경우 4개의 엔트리를 갖는 포워딩 테이블이면 된다.

이런 형식의 포워딩 테이블에서 라우터는 패킷의 목적지 주소의 프리픽스(prefix)를 테이블의 엔트리와 매치한다.

예를 들어, 패킷의 목적지 주소가 11001000 00010111 00010110 10100001 라면 앞 21개의 비트 프리픽스가 테이블의 첫 번째 엔트리와 매치되므로 라우터는 이 패킷을 링크 인터페이스 0으로 보낸다.

11001000 00010111 00011000 10101010와 같이 처음 24비트는 2번째에 처음 21비트는 3번째에 매치되는 경우 라우터는 최장 프리픽스 매치 규칙(longest prefix matching rule)을 사용한다.

즉, 테이블에서 가장 긴 매치 엔트리를 찾고, 여기에 연관된 링크 인터페이스로 패킷을 보낸다. (이유에 대해서는 4.3절에서 다룬다.)

이러한 테이블 설계 뿐만 아니라 검색은 나노초 단위로 수행되어야 하므로 이외의 기술이 필요하다.

메모리 접속 시간에 특별한 주의를 기울여야하므로 내장형 DRAM과 빠른 SRAM 메모리가 있는 설계가 필요하다. 실제로 TCAM도 검색을 위해 자주 사용된다.

검색을 통해 패킷의 출력 포트가 결정되면 패킷을 스위치 구조로 보낼 수 있다. 일부 설계에서는 다른 입력 포트로부터 패킷이 현재 구조를 사용하고 있다면 패킷이 스위칭 구조에 들어가는 것을 일시적으로 차단할 수 있다.

앞으로 패킷의 차단, 큐잉, 스케줄링에 대해 자세히 살펴본다.

스위치 구조는 패킷이 입력 포트에서 출력 포트로 실제로 스위칭 되는 구조를 통과하므로 라우터의 핵심이다.

여기서는 여러가지 스위칭 방법을 설명한다.

초기의 라우터는 라우터 프로세서를 직접 제어해서 입력 포트와 출력 포트 사이에서 패킷을 스위칭하는 전통적인 컴퓨터다. 입력 포트와 출력 포트는 I/O 장치처럼 작동한다.

패킷 전달 과정

1. 패킷이 도착하면 입력 포트는 라우팅 프로세서에게 인터럽트를 보내 패킷을 프로세서 메모리에 복사한다.
2. 라우팅 프로세서는 헤더에서 목적지 주소를 추출한다.
3. 포워딩 테이블에서 적절한 출력 포트를 찾은 다음 패킷을 출력 포트의 버퍼에 복사한다.

위 과정에서 메모리 대역폭이 초당 최대 B인 패킷을 메모리에 쓰거나 메모리에서 읽을 수 있는 경우 전체 전달 처리량은 B/2 보다 작아야하며 목적지 포트가 다른 경우라도 공유 시스템 버스를 통해 한 번에 하나의 메모리 읽기/쓰기 작업을 수행할 수 있기 때문에 두 패킷을 동시에 전달할 수 없다.

최근의 메모리를 통해 스위칭하는 라우터는 목적지 주소를 검색하고 해당 메모리 위치에 패킷을 저장하는 것이 입력 라인 카드에서 처리함으로써 수행한다.

입력 포트는 라우팅 프로세서의 개입 없이 공유 버스를 통해 직접 출력 포트로 패킷을 전송한다.

일반적으로 미리 준비된 입력 포트 스위치 내부 레이블이 로컬 출력 포트를 나타내는 패킷에게 전송되거나 버스에 패킷을 전송하여 수행된다.

모든 출력 포트에 패킷이 수신되지만 레이블과 매치되는 포트만 패킷을 유지한다.

레이블은 버스를 통과하기 위해서만 사용되므로 출력 포트에서 제거된다.

동시에 여러 패킷이 다른 입력 포트에 있는 라우터에 도착하면 한 번에 하나의 패킷만 버스를 통과할 수 있기 때문에 하나를 제외한 모든 패킷이 대기 해야한다.

모든 패킷이 하나의 버스를 통과해야하므로 라우터의 교환 속도는 버스 속도에 의해 제한된다.

크로스바 스위치는 N개의 입력 포트를 N개의 출력 포트에 연결하는 2N 버스로 구성된 상호연결 네트워크다.

각 수직 버스는 교차점에서 각 수평 버스와 교차하며 스위치 구조 컨트롤러에 의해 언제든지 열거나 닫을 수 있다.

이를 통해 앞의 두가지 방식과 달리 크로스바 스위치는 여러 패킷을 병렬로 전달할 수 있다.

그러나 두개의 서로 다른 입력 포트에서 나오는 2개의 패킷이 동일한 출력 포트로 보내지는 경우 한번에 하나의 패킷만 특정 버스에서 전송될 수 있기 때문에 입력을 기다려야한다.

좀 더 정교한 상호연결 네트워크는 다단계 스위치 구조를 통해 각기 다른 입력 포트의 패킷이 동일한 출력 포트를 향해 동시에 전달할 수 있도록 여러 단계의 스위칭 요소를 사용한다.

위 그림의 출력 포트 처리는 출력 포트의 메모리에 저장된 패킷을 가져와서 출력 링크를 통해 전송한다. 여기에는 전송을 위한 패킷 선택 및 큐 제거, 필요한 링크 계층 및 물리 계층 전송 기능을 수행하는 것이 포함된다.

패킷 큐는 입력 포트와 출력 포트 모두에서 형성될 수 있다.

큐의 위치와 범위는 트래픽 로드, 스위치 구조의 상대 속도 및 라인 속도에 따라서 달라진다.

이 큐가 커지면 라우터의 메모리가 결국 소모될 수 있고 도착하는 패킷을 저장할 수 있는 메모리가 없을 때 패킷 손실이 발생한다.

지연 없이 구조를 통해 도착하는 모든 패킷을 전송하기에 스위치 구조가 충분히 빠르지 않으면 어떻게 될까?

이 경우에는 패킷이 스위치 구조를 통해 출력 포트로 전송되기 위해 차례를 기다려야한다.

이 큐잉의 결과를 살펴보기 위해 크로스바 스위치 구조를 가정해보자.

1. 모든 링크의 속도는 같다.
2. 입력 링크가 패킷을 받는 것과 같은 속도로 하나의 패킷을 입력 포트에서 주어진 출력 포트로 전달한다.
3. FCFS (First-Come-First-Served) 방식으로 패킷은 입력 큐에서 출력 큐로 이동된다.

출력 포트가 다르다면 여러 패킷이 병렬로 전달 가능하지만, 같다면 하나의 패킷만 지정된 출력 포트로 전송이 가능하고 나머지 패킷은 기다려야한다.

위 그림에서 왼쪽 상단 큐의 앞쪽에서 먼저 패킷을 전송한다고 가정해보자.

왼족 하단 큐의 가장 앞쪽의 패킷은 출력 포트가 같으므로 대기하여야하고, 두번째 패킷은 출력 포트가 다름에도 앞의 패킷 때문에 대기하여야한다.

이 현상은 입력 대기 중인 스위치에서의 HOL(Head-of-the-line) 차단 이라고 한다.

입력 포트와 출력 포트의 개수가 각각 N개이고 속도가 R이라 할 때, 스위치의 속도가 R보다 N배 빠르고 모든 입력 포트의 패킷이 동일한 출력 포트로 향한다고 가정해보자.

이 경우, 출력 링크에서 단일 패킷을 보내는 데 걸리는 시간에 N개의 새로운 패킷이 출력 포트에 도착한다. 출력 포트는 시간 단위에 단일 패킷만을 전송할 수 있기 때문에 N개의 도착 패킷은 출력 링크를 통한 전송 큐에서 대기 해야한다.

이때 큐의 공간이 충분하지 않을 때, 즉 메모리가 충분하지 않을 때 도착한 패킷을 삭제하거나 이미 대기 중인 하나 이상의 패킷을 제거하여 새로 도착한 패킷을 저장하기 위한 공간을 확보해야 한다.

위 그림은 출력 포트 큐잉의 예시이다.

이러한 큐잉의 결과는 출력 포트의 패킷 스케줄러가 전송 대기 중인 패킷 중 하나의 패킷을 선택하여 큐에서 제거 해야한다는 것이다. (다음 절에서 다룬다.)

몇년 동안 RFC의 버퍼의 크기에 대한 규칙은 링크 용량이 C일 때, 버퍼링의 양은 평균 왕복 시간(RTT)와 같아야 한다는 것이다.

즉, B = RTT x C 와 같은 버퍼의 양이 필요하다.

최근의 실험과 이론에서는 많은 수의 독립적인 TCP 흐름 N이 링크를 통과할 때, 필요한 버퍼링은 B = RTT x C / √N 이라고 제안하고 있다.

버퍼링이 클수록 라우터가 패킷 도착 속도의 큰 변동을 흡수하여 라우터의 패킷 손실률을 감소 시킬 수 있기 때문에 버퍼링이 낫다고 생각하는 것보다 버퍼가 클수록 큐잉 지연이 길어진다고 생각하는 편이 좋다.

예를 들어, 패킷 손실을 줄이기 위해 홉당 버퍼의 양을 10배 늘리면 종단 간 지연이 10의 배만큼 증가한다.

즉, 버퍼의 크기 증가는 패킷 손실율을 줄일 수 있지만 종단 간 지연을 증가시킬 수 있는 양날의 검이다.

네트워크 가장자리의 라우터를 생각해보자.

a는 TCP 세그먼트를 원격 게임 서버로 보내는 홈 라우터에 대한 설명이다. 게이머의 TCP 세그먼트를 포함하는 패킷을 전송하는 데 20ms가 소요되며, 큐잉 지연이 무시해도 될 정도라고 가정한다.

게임 서버 경로의 다른 곳에서 지연되며 RTT는 200ms다.

b에서와 같이 t = 0 에서 25개 패킷의 버스트가 큐에 도착한다고 가정한다.

대기 중인 패킷들 중 하나는 20ms 마다 한 번씩 전송되므로, 21 번째 패킷이 전송되고 있는 것처럼 t = 200ms에서 첫 번째 ACK가 도착한다. 이 ACK 도착은 송신자가 다른 패킷을 보내게 한다.

홈 라우터의 송신 링크 t = 220에서 다음 ACK가 도착하고, 또 다른 ACK가 도착한다. TCP 세그먼트는 게이머에 의해 해제되며, 22번째 패킷은 전송되는 큐에 놓인다.

위 과정에서 ACK 클록은 대기 중인 패킷이 있을 때마다 새 패킷이 큐에 도착하게 되고, 전송되어 홈 라우터의 송신 링크에서 큐 크기가 항상 5 패킷이 된다.

즉, 종단 간 파이프는 꽉 찼지만 큐잉 지연의 양은 일정하고 지속적이다.

결과로 게이머는 홈 네트워크에 다른 트래픽이 존재하지 않는 경우에도 지연이 지속적으로 지나치게 긴 이유를 이해하지 못하게 된다.

이러한 지속적 버퍼링으로 인한 긴 지연에 대한 위 과정을 버퍼블로트(bufferbloat)라고 한다.

이를 극복하기 위해 6장에서 연구할 케이블 네트워크용 DOCIS 3.1 표준은 AQM 메커니즘을 추가하여 대량 처리 성능을 보존했다.

링크가 현재 다른 패킷을 전송 중이면, 출력 링크 큐에 도착한 패킷은 전송을 기다린다.

도착한 패킷을 담을 버퍼 공간이 충분하지 않은 경우 도착 패킷의 공간을 확보하기 위해 큐의 패킷 폐기 정책은 패킷 손실 여부 또는 다른 패킷을 큐에서 제거할 것인지 여부를 결정한다.

FIFO 스케줄링 규칙은 출력 링크 큐에 도착한 순서와 동일한 순서로 출력 링크에서 전송할 패킷을 선택한다.

위 그림에서는 FIFO 큐의 동작을 보여준다.

우선순위 큐잉에서 출력 링크에 도착한 패킷은 우선순위 클래스로 분류된다.

실제로 네트워크 오퍼레이터는 네트워크 관리 정보를 운반하는 패킷이 사용자 트래픽보다 우선순위를 수신하도록 큐를 구성할 수 있다.

전송할 패킷을 선택할 때 전송 대기 중인 패킷으로 차 있는 상태이고 가장 높은 우선순위 클래스에서 패킷을 전송한다.

우선순위가 동일한 패킷들 중에서의 선택은 FIFO 방식으로 행해진다.

위 그림은 우선순위 클래스가 2개인 경우의 큐 동작을 보여준다.

패킷 1,3,4가 우선순위가 높기 때문에 먼저 전송된다.

이때는 비선점 우선순위 큐잉이기 때문에 패킷 4의 우선순위가 높더라도 패킷 2의 전송이 시작되면 선점하지 않고 전송이 끝난 후에야 전송이 시작된다.

라운드 로빈 큐잉 큐칙에서는 패킷은 우선순위 큐잉과 같이 클래스로 분류되지만 클래스 간에는 엄격한 서비스 우선순위가 존재하지 않으며, 라운드 로빈 스케줄러가 클래스 간에 서비스를 번갈아서 제공한다.

가장 단순한 라운드 로빈 스케줄링에서는 그저 클래스를 번갈아가면서 패킷을 전송한다.

작업 보존 큐잉 규칙의 경우 전송을 위해 큐에서 기다리는 패킷이 있다면 링크는 유휴 상태가 되는 것을 허용하지 않는다.

즉, 클래스에 패킷이 없다면 바로 시퀀스의 다음 클래스를 검사한다.

위 그림은 라운드 로빈 큐의 동작을 보여준다.

라우터에서 널리 구현된 라운드 로빈 큐잉의 일반화된 형태는 소위 WFQ(Weighted Fair Queueing) 규칙이다.

도착하는 패킷은 적절한 클래스별 대기 영역에서 분류되며 대기한다.

WFQ 스케줄러는 라운드 로빈과 같이 순환식으로 동작한다.

또한, 작업 보존 큐잉 규칙을 따른다.

WFQ는 각 클래스 i 는 가중치 w(i)를 할당 받는다.

WFQ에서는 전송할 클래스 i 패킷이 있는 동안에 클래스 i는 w(i) / ∑w(i) 만큼의 서비스 시간을 보장받으며, 이 식에서 분모 부분은 전송을 위해 큐에 패킷이 있는 모든 클래스의 합이다.

즉, 최악의 경우 모든 큐에 패킷이 있을 때도 위의 시간을 보장 받는다.

따라서 전송률 R인 링크에 대해 클래스 i는 항상 최소한 R x w(i) / ∑w(i)의 처리율을 갖는다.

패킷이 이상적인 단위 데이터라는 것과 패킷 전송이 다른 패킷을 전송하기 위해 방해되지 않는다는 사실을 고려하지 않았기 때문에 위 설명은 이상적이다.

인터넷 네트워크 계층 패킷을 데이터그램(datagram)이라고 부른다.

• 버전 번호
  • 4비트로 데이터그램의 IP 프로토콜 버전을 명시한다.
  • 라우터는 버전 번호를 확인하여 데이터그램의 나머지 부분을 어떻게 해석할지 결정한다.
  • 다른 버전의 IP는 다른 데이터그램 포맷을 사용한다.
• 헤더 길이
  • IPv4 데이터그램은 헤더에 가변 길이의 옵션을 포함하므로 이 네 비트로 IP 데이터그램에서 실제 페이로드가 시작하는 곳을 결정한다.
  • 대부분의 IPv4는 옵션을 포함하지 않으므로 대체로 IPv4 데이터그램 헤더는 20바이트다.
• 서비스 타입
  • IPv4 헤더에 포함된 서비스 타입 비트는 각기 다른 유형의 IP 데이터그램을 구별한다. 예를 들어, 실시간 데이터그램과 비실시간 트래픽을 구분하는 데 유용하다.
• 데이터그램 길이
  • 바이트로 계산한 IP 데이터그램의 전체 길이다. 총 16비트를 차지하므로 IP 데이터그램의 최대 길이는 65,535 바이트이지만 1,500보다 큰 경우는 거의 없다.
• 식별자, 플래그, 단편화 오프셋
  • IP 단편화와 관련이 있는 필드들이다.
  • 큰 IP 데이터그램이 여러 개의 작은 IP 데이터그램으로 분할된 다음 목적지로 독립적으로 전달되며, 여기서 페이로드 데이터가 최종 호스트의 트랜스포트 계층으로 전달되기 전에 다시 모인다.
• TTL(time to live)
  • 이 필드는 네트워크에서 데이터그램이 무한히 순환하지 않도록 한다(라우팅 루프). 라우터가 데이터그램을 처리할 때마다 감소하고, 이 필드가 0이 되면 데이터그램을 폐기한다.
• 프로토콜
  • 이 필드는 일반적으로 IP 데이터그램이 최종목적지에 도착했을 때만 사용된다. 이 필드값은 IP 데이터그램에서 데이터 부분이 전달될 목적지의 트랜스포트 계층의 특정 프로토콜(TCP, UDP)을 명시한다.
  • IP 데이터그램에서 이 필드는 트랜스포트 계층에서 포트 번호 필드와 역할이 유사하다.
• 헤더 체크섬
  • 헤더 체크섬은 라우터가 수신한 IP 데이터그램의 비트 오류를 탐지하는데 도움을 준다.
  • 라우터는 오류 검출된 데이터그램을 폐기한다.
  • TTL 필드와 옵션 필드의 값은 변경되므로 체크섬은 각 라우터에서 재계산되고 저장되어야 한다.
  • 트랜스 포트 계층과 네트워크 계층에서 오류 검사를 수행하는 이유
    • IP 헤더만 IP 계층에서 체크섬을 수행하지만 TCP/UDP 체크섬은 전체 TCP/UDP 세그먼트를 계산한다.
    • TCP/UDP와 IP는 동일한 프로토콜 스택에 속할 필요가 없다. 원리상 TCP는 IP가 아닌 곳 위에서도 운영될 수 있다.
• 출발지와 목적지 IP 주소
  • 출발지가 데이터그램을 생성할 때, 자신의 IP 주소를 출발지 IP 주소 필드에 삽입하고 목적지 IP 주소를 목적지 IP 주소 필드에 삽입한다.
• 옵션
  • IP 헤더 필드를 확장한다.
  • 모든 데이터그램 헤더 옵션 필드에 정보를 포함하지 않는 방법으로 오버헤드를 해결하기 위해 헤더 옵션은 거의 사용되지 않는다.
  • 데이터그램 헤더가 가변 길이로 데이터 필드 시작점을 초기에 결정할 수 없어 문제를 복잡하게 만든다.
• 데이터(페이로드)
  • 데이터그램이 존재하는 이유이자 가장 중요한 마지막 필드이다. 대부분의 경우 목적지에 전달하기 위해 트랜스포트 계층 세그먼트를 포함한다.

대부분의 IP 데이터그램은 총 20바이트(옵션은 없다고 가정)의 헤더를 갖는다.

TCP 세그먼트를 전송한다면 단편화가 되지 않은 각 데이터그램은 애플리케이션 계층의 메시지와 더불어 총 40바이트의 헤더(IP 헤더 20, TCP 헤더 20)을 전송한다.

호스트는 일반적으로 네트워크와 연결되는 하나의 링크를 갖는다.

호스트 IP가 데이터그램을 보낼 때 이 링크를 통해 데이터링크를 보낸다.

호스트와 물리적 링크 사이의 경계를 인터페이스(interface)라고 부른다.

라우터는 여러 개의 링크와 연결되고, 링크와 라우터 사이도 인터페이스(interface)로 이루어져있어 여러개의 인터페이스(interface)를 갖는다.

모든 호스트와 라우터는 IP 데이터그램을 송수신할 수 있으므로 IP는 각 호스트와 라우터 인터페이스가 IP 주소를 갖도록 요구한다.

이러한 각 인터페이스는 고유한 IP 주소를 갖는다.

따라서 기술 면에서 IP 주소는 인터페이스(interface)를 포함하는 호스트 라우터보다는 인터페이스(interface)와 관련이 있다.

각 IP 주소는 32비트 길이다. 따라서 2^32개의 주소를 사용할 수 있다. 일반적으로 주소의 각 바이트를 십진수로 표현하고 주소의 다른 바이트와 점으로 구분하는 십진 표기법을 사용한다.

인터페이스의 IP는 마음대로 선택할 수 없다. IP 주소의 일부는 연결된 서브넷이 결정한다.

왼쪽 3개의 호스트와 라우터 인터페이스는 모두 223.1.1.xxx 형식의 IP 주소를 갖는다. 또, 4개의 인터페이스가 중계하는 라우터 없이 하나의 네트워크에 서로 연결되어 있다.

이 네트워크는 이더넷 LAN으로 상호연결되고 이 경우 인터페이스는 이더넷 허브나 이더넷 스위치 또는 무선 AP로 상호연결된다.

IP 용어로 세 호스트 들의 인터페이스들과 하나의 라우터 인터페이스로 연결된 네트워크는 서브넷(subnet)을 구성한다고 말한다.

IP 주소체계는 이 서브넷에 223.1.1.0/24 라는 주소를 할당하는데 여기서 /24는 서브넷 마스크라 부르는데, 왼쪽 24비트가 서브넷 주소라는 것을 가리킨다.

위 그림에서는 3개의 서브넷을 볼 수 있다.

서브넷 IP의 정의는 여러 호스트를 라우터 인터페이스에 연결하는 이더넷 세그먼트만을 의미하는 것은 아니다.

위 그림을 보면 3개의 라우터도 점대점으로 연결되어있는 것을 볼 수 있다.

여기서는 호스트와 라우터의 연결 뿐만 아니라 라우터 간의 연결에서도 서브넷을 볼 수 있다.

총 6개의 서브넷을 찾을 수 있다.

서브넷의 정의

💡서브넷을 결정하려면 먼저 호스트나 라우터에서 각 인터페이스를 분리하고 고립된 네트워크를 만든다. 이 고립된 네트워크의 종단점은 인터페이스의 끝이 된다. 이렇게 고립된 네트워크 각각을 서브넷이라고 부른다.

위에 의하면 다수의 이더넷 세그먼트와 종단 간의 링크를 갖는 기관은 한 서브넷에서 모든 장비가 같은 서브넷 주소를 갖는 그런 서브넷을 여러개 가질 수 있다.

서로 다른 서브넷은 다른 주소를 가져야 하지만 실제로 서브넷 주소는 같은 부분이 많다.

인터넷 주소 할당 방식 중 하나다.

CIDR는 서브넷 주소 체계 표기를 일반화하고 있다.

a.b.c.d/x 형식 주소에서 최상위 비트(Most significant bit)를 의미하는 x는 IP 주소의 네트워크 부분을 구성한다.

이를 해당 주소의 프리픽스 또는 네트워크 프리픽스라고 부른다.

한 기관은 통상 연속적인 주소의 블록(공통 프리픽스를 갖는 주소 범위)을 할당 받고 기관 장비들의 IP 주소는 공통 프리픽스를 공유한다.

외부 기관의 라우터는 목적지 주소가 내부 기관인 데이터그램을 전달할 때, 단지 앞의 x 비트들만 고려한다.

a.b.c.d/x 형태의 한 엔트리만으로 기관 목적지로 패킷을 전달하는 데 충분하므로, 이런 라우터들에서 포워딩 테이블의 크기를 상당히 줄여준다.

주소의 나머지 32-x 비트들은 기관 내부에 같은 네트워크 프리픽스를 갖는 모든 장비를 구별한다.

이 비트들은 기관 내부의 라우터에서 패킷을 전달할 때 사용되며 이 하위 비트들은 추가적으로 서브넷 구조를 가질 수도 있다.

CIDR가 채택되기 전에는 IP 주소의 네트워크 부분을 8, 16, 24 비트로 제한했고 각각의 비트를 서브넷 주소로 갖는 서브넷을 각각 A, B, C 클래스 네트워크로 분류했기 때문에 이러한 주소체계는 클래스 주소체계라고 알려졌다.

그러나 서브넷 부분이 정확히 1, 2, 3 바이트여야 하는 요구사항은 중소형 크기의 네트워크로 급속히 증가하는 기관의 수를 지원하기엔 문제가 있었다.

예를 들어 클래스(/24) 서브넷은 254개의 호스트만을 제공하므로 많은 조직을 위해서는 턱없이 부족하고, 클래스(/16) 서브넷은 65634개의 호스트를 제공하여 너무 크다.

IP의 또 다른 형태인 브로드캐스트 주소 255.255.255.255가 있다.

호스트가 목적지 주소가 255.255.255.255인 데이터그램을 보내면, 이 메시지는 같은 서브넷에 있는 모든 호스트에게 전달된다.

다음으로는 한 기관에서 그들의 장비를 위한 주소 블록을 어떻게 획득하는지 알아본 후에, 이 획득한 주소 블록의 주소를 어떻게 장비에 할당하는지 살펴보겠다.

기관의 서브넷에서 사용하기 위한 IP 주소 블록을 얻기 위해, 네트워크 관리자는 먼저 이미 할당받은 주소의 큰 블록에서 주소를 제공하는 ISP와 접촉해야 한다.

ISP가 위와 같은 블럭을 할당 받았다고 할 때, ISP는 블록을 다음처럼 같은 크기의 작은 주소 블록 8개로 나누고, 이것으로 8개 조직을 지원할 수 있다.

ISP는 비영리 단체인 ICANN으로 부터 주소 블록을 할당 받는다.

ICANN의 역할은 IP 주소 할당과 DNS 루트 서버 관리다.

한 기관은 ISP로부터 주소 블록을 획득하여, 개별 IP 주소를 기관 내부의 호스트와 라우터 인터페이스에 할당한다.

라우터 인터페이스 주소에 대해, 시스템 관리자는 라우터 안에 IP 주소를 할당한다.

호스트에 IP 주소를 할당하는 것은 수동으로 구성이 가능하지만 일반적으로 동적 호스트 구성 프로토콜(DHCP)을 많이 사용한다.

DHCP는 호스트가 IP 주소를 자동으로 얻을 수 있게 하고, 서브넷 마스크, 첫 번째 홉 라우터 주소나 로컬 DNS 서버 주소 같은 추가 정보를 얻게 해준다.

DHCP는 자동으로 호스트와 연결해주는 능력 때문에 플러그 앤 플레이 프로토콜 또는 제로 구성 프로토콜이라고도 한다.

DHCP는 클라이언트-서버 프로토콜이다.

클라이언트는 일반적으로 IP 주소를 포함하며 네트워크 설정을 위한 정보를 얻고자 새롭게 도착한 호스트다.

각 서브넷은 DHCP 서버를 갖거나 없다면 해당 네트워크에 대한 DHCP 서버 주소를 알려줄 DHCP 연결 에이전트(일반적으로 라우터)가 필요하다.

위 그림은 새로운 호스트가 도착할 경우, DHCP 프로토콜의 4단계 과정을 보여준다.

• DHCP 서버 발견
  • 먼저 새롭게 도착한 호스트는 상호작용할 DHCP를 발견한다. 이것은 DHCP 발견 메시지를 사용하여 수행되며, 클라이언트는 포트 67번으로 UDP 패킷을 보낸다.
  • DHCP 클라이언트는 DHCP 발견 메시지를 포함하는 IP 데이터 그램을 생성하는데, 이 메시지 내의 목적지 IP 주소를 브로드캐스트 IP 주소 255.255.255.255로 설정하고 출발지 IP 주소는 0.0.0.0으로 설정한다.
  • 링크 계층으로 IP 데이터그램을 보내며 이 프레임은 서브넷에 연결된 모든 노드로 브로드캐스트된다.
• DHCP 서버 제공
  • DHCP 발견 메시지를 받은 DHCP 서버는 DHCP 제공 메시지를 클라이언트로 응답한다.
  • 이때에도 IP 브로드캐스트 주소를 사용하여 서브넷의 모든 노드로 이 메시지를 브로드캐스트한다.
  • 서브넷에는 여러 DHCP 서버가 존재하기 때문에, 클라이언트는 여러 DHCP 제공 메시지로부터 가장 최적의 위치에 있는 DHCP 서버를 선택한다.
  • 각각의 서버 제공 메시지는 수신된 발견 메시지의 트랜잭션 ID, 클라이언트에 제공된 IP 주소, 네트워크 마스크, IP 주소 임대 기간을 포함한다.
• DHCP 요청
  • 새롭게 도착한 클라이언트는 하나 또는 그 이상의 서버 제공자 중에서 선택할 것이고 선택된 제공자에게 파라미터 설정으로 되돌아오는 DHCP 요청 메시지로 응답한다.
• DHCP ACK
  • 서버는 DHCP 요청 메시지에 대해 요청된 파라미터를 확인하는 DHCP ACK 메시지로 응답한다.

클라이언트가 DHCP ACK을 받으면 상호작용이 종료되고 클라이언트는 임대 기간동안 할당 IP 주소를 사용할 수 있다.

DHCP는 노드가 새로운 서브넷에 연결하고자 할 때마다 새로운 IP 주소를 DHCP로부터 얻기 때문에, 이동 노드가 서브넷 사이를 이동할 때 원격 애플리케이션에 대한 TCP 연결이 유지될 수 없다는 결점이 있다.

모든 호스트가 서브넷으로부터 IP를 할당받고 할 때 네트워크가 현저하게 커지면 큰 주소 블록이 할당되어야 한다.

ISP가 이미 해당 주소 범위의 인접한 부분을 할당해버리는 등의 문제가 발생할 수 있는데 이런 경우에는 네트워크 주소 변환(NAT)으로 주소를 할당할 수 있다.

NAT 가능 라우터는 위 그림의 오른쪽처럼 홈 네트워크의 일부인 인터페이스를 갖는다.

홈 네트워크의 4개 인터페이스 모두 같은 네트워크 주소 10.0.0.0/24를 갖는다.

주소 공간 10.0.0.0/8은 사설망 또는 그림의 홈 네트워크와 같은 사설 개인 주소를 갖는 권역(realm)을 위해 RFC에 예약된 IP 주소 공간 세 부분 중의 하나다.

💡 사설 개인 주소를 갖는 권역(realm)이란 네트워크 주소들이 그 네트워크 내부에 있는 장비에게만 의미가 있는 그런 네트워크를 의미한다.

사설 개인 주소를 갖는 권역은 홈 네트워크 내부에서만 의미가 있다. 즉, 글로벌 인터넷과는 송수신할 수 없다.

NAT 가능 라우터는 외부 세계로는 하나의 IP 주소를 갖는 하나의 장비로 동작한다.

그림을 보면 홈 라우터를 떠나 인터넷으로 가는 트래픽의 출발지 IP 주소는 138.76.29.7 즉, 라우터의 출력 라우터 인터페이스의 IP 주소를 갖는다.

홈으로 들어오는 트래픽의 목적지 주소는 마찬가지로 138.76.29.7을 가져야한다.

본질적으로 NAT 가능 라우터는 외부에서 들어오는 홈 네트워크의 상세한 사항을 숨긴다.

WAN에서 같은 목적지 IP 주소를 갖는 NAT 라우터에 모든 데이터 그램이 도착하면, 라우터가 주어진 데이터그램을 전달하는 내부 호스트를 어떻게 알 수 있을까?

NAT 라우터에서 NAT 변환 테이블을 사용하고, 그 테이블에 IP 주소와 포트 번호를 포함하여 알 수 있다.

위 그림의 NAT 변환 테이블을 보며 순서대로 잘 따라가보길 바란다.

웹 서버는 내부 호스트를 모른채 WAN side의 라우터를 목적지 IP로 하여 응답하고, 라우터는 이 응답을 NAT 변환 테이블을 사용하여 알맞은 내부 호스트에 전달한다.

포트 번호는 호스트 주소 지정이 아닌 프로세스 주소 지정에 사용된다.

서버 프로세스는 잘 알려진 포트 번호에서 요청이 올 때까지 기다리고 P2P 프로토콜의 피어는 서버로서의 역할을 할 때 들어오는 연결을 수락해야 하기 때문에 홈 네트워크에서 실행되는 서버에 문제가 발생할 수 있다.

이 문제의 기술적인 해결책으로는 NAT 순회 도구가 있다.

IPv4 주소 공간이 빠르게 고갈되어가면서 IPv6 주소 체계가 개발되었다.

IPv6 중요한 변화

• 확장된 주소 기능
  • IPv6는 IP 주소 크기를 32비트에서 128비트로 확장했으므로 IP 주소가 고갈되는 일은 발생하지 않을 것이다.
  • IPv6는 유니캐스트, 멀티캐스트 주소뿐만 아니라 새로운 주소 형태인 애니캐스트 주소가 도입되었다. 애니 캐스트 주소로 명시된 데이터그램은 호스트 그룸의 어떤 이에게든 전달될 수 있다.
• 간소화된 40 바이트 헤더
  • 40 바이트 고정 길이 헤더는 라우터가 IP 데이터그램을 더 빨리 처리하게 해준다.
  • 새로운 옵션 인코딩은 유연한 옵션 처리를 가능하게 한다.
• 흐름 레이블링
  • 정의하기 어려운 흐름을 갖고있다. RFC는 "비 디폴트 품질 서비스나 실시간 서비스 같은 특별한 처리를 요청하는 송신자에 대해 특정 흐름에 속하는 패킷 레이블링"을 가능하게 한다고 설명한다. 아직 정확한 의미는 정의되지 않았지만, 언젠가 필요할 흐름 차별화를 예견하여 구현하였다.

IPv6 데이터그램 포맷은 그림과 같다.

• 버전
  • 4비트 필드는 IP 버전 번호를 인식한다. IPv6라면 6이다.
• 트래픽 클래스
  • IPv4의 TOS 필드와 비슷한 의미로 만든 8비트 필드는 흐름 내의 SMTP 이메일 같은 애플리케이션의 데이터그램보다 Volp 같은 특정 애플리케이션 데이터그램에 우선순위를 부여하는데 사용된다.
• 흐름 레이블
  • 데이터그램의 흐름을 인식하는데 사용된다.
• 페이로드 길이
  • 이 16비트 값은 IPv6 데이터그램에서 고정 길이 40바이트 패킷 헤더 뒤에 나오는 바이트 길이이며, 부호 없는 정수다.
• 다음 헤더
  • 이 필드는 데이터그램의 내용이 전달될 프로토콜을 구분한다.(TCP, UDP)
• 홉 제한
  • 라우터가 데이터그램을 전달할 때 마다 1씩 감소하고, 0이되면 데이터그램이 라우터에 의해 버려진다.
• 출발지와 목적지 주소
  • 출발지와 목적지 주소를 담고 있다.
• 데이터
  • IPv6 데이터그램의 페이로드 부분이다. 데이터그램이 목적지에 도착하면 IP 데이터그램에서 페이로드를 제거한 후, 다음 헤더 필드에 명시한 프로토콜에 전달한다.

IPv4에는 있지만 IPv6에는 없는 필드

• 단편화/재결합
  • IPv6에서는 단편화와 재결합을 출발지와 목적지만이 수행한다.
  • 라우터가 받은 IPv6 데이터그램이 너무 커서 출력 링크로 전달할 수 없다면 라우터는 데이터그램을 폐기하고 너무 크다는 ICMP 오류 메시지를 송신자에게 보낸다.
  • 송신자는 데이터를 IP 데이터그램 크기를 줄여서 다시 보낸다.
  • 라우터에서 이 기능을 수행하는 것은 시간이 오래 걸리므로 이 기능을 삭제하여 IP 전달 속도를 증가시켰다.
• 헤더 체크섬
  • 트랜스포트 계층 프로토콜과 데이터 링크 프로토콜은 체크섬을 수행하므로 IP 설계자는 네트워크 계층의 체크섬 기능이 반복되는 것으로 생략해도 될 것이라 생각하여 삭제했다.
• 옵션
  • IPv4에서도 잘 사용되지 않았던 필드가 사라지고 고정 헤더의 길이를 갖게되었다.
  • 다대신 옵션 필드는 IPv6 헤더에서 다음 헤더 중 하나가 될 수 있다.

IPv6는 IPv4 데이터그램을 보내고 라우팅하며 받을 수 있는 새 IPv6 시스템이 있는 반면에, IPv4로 구축된 시스템은 IPv6 데이터그램을 처리할 수 없다는 것에서 발생한다.

모든 인터넷 장비를 끄고 IPv4를 IPv6로 업그레이드하는 시간과 날짜를 정하는 것으로 40년 전에 실제로 NCP를 TCP로 전이하였다.

그러나 수억개의 장비가 관련된 플레그 데이는 오늘날에는 절대 불가능하다.

실제로 널리 사용하는 방법이다.

두 IPv6 노드(그림에서는 B와 E)가 IPv6 데이터그램을 사용해서 작동한다고 가정해보자.

물론 이들은 IPv4 라우터를 통해 연결되어있다. 이렇게 IPv6 노드 사이에 연결되어있는 IPv4 라우터들을 터널(tunnel)이라고 한다.

IPv6 송신 과정

1. 터널의 송신 측에 있는 IPv6 노드는 IPv6 데이터그램을 받고 IPv4 데이터그램의 데이터 필드에 이것을 넣는다.
2. IPv4 데이터그램에 목적지 주소를 터널의 수신 측에 IPv6 노드로 적어서 터널의 첫 번째 노드에 보낸다.
3. 터널 내부에 있는 IPv4라우터는 IPv4 라우터는 IPv4 데이터그램이 IPv6 데이터그램을 갖고 있다는 사실을 모른채 다른 데이터그램을 처리하는 방식으로 IPv4 데이터 그램을 처리한다.
4. 터널 수신 측에 있는 IPv6 노드는 IPv4 데이터그램을 받고 이 IPv4 데이터그램이 실제 IPv6 데이터그램임을 결정한다.
5. 다음 노드에 IPv6 데이터그램을 보낸다.

기초적인 IPv6 수용은 이루어지고 있지만 최근에 이루어진 것은 없다.

신뢰적인 데이터 전송을 구현하는 문제는 트랜스포트 계층뿐만 아니라 링크 계층과 애플리케이션 계층에서도 발생할 수 있는 문제이다.

따라서 이 절에서는 일반적인 상황에서의 신뢰적인 데이터 전송 문제를 다룬다.

신뢰적인 데이터 전송 연구의 프레임워크는 다음과 같다.

상위 계층 객체에게 제공되는 서비스 추상화는 / 데이터가 전송될 수 있는 신뢰적인 채널의 서비스 추상화다.

• 신뢰적인 채널에서는 전송된 데이터가 손상되거나 손실되지 않으며,
• 모든 데이터는 전송된 순서 그대로 전달된다.

= TCP가 인터넷 애플리케이션에게 제공하는 서비스 모델

신뢰적인 데이터 전송 프로토콜(reliable data transfer protocol)의 의무는 신뢰적인 채널의 서비스 추상화를 구현하는 것이다.

이 절에서는 점점 복잡해지는 하위 채널 모델을 고려하여 신뢰적인 데이터 전송 프로토콜의 송신자 측면과 수신자 측면을 점진적으로 개발해나간다.

논의 과정 중 채택할 한 가지 가정 : 패킷은 순서대로 전달된다. (하부 채널은 패킷의 순서를 바꾸지 않음)

위 두 가지 그림 중 b는 데이터 전송 프로토콜의 인터페이스를 나타낸다.

• 데이터 전송 프로토콜의 송신 측은 rdt_send() 호출로 위쪽으로부터 호출될 것이며, 수신 측에서는 상위 계층으로 전달될 데이터를 넘길 것이다.
  • rdt : 신뢰적인 데이터 전송(reliable data transfer) 프로토콜을 나타낸다.
  • _send : rdt의 송신 측이 호출되고 있음을 나타낸다.
• 수신 측에서 rdt_rcv()는 패킷이 채널의 수신 측으로부터 도착했을 때 호출된다.
• rdt 프로토콜이 상위 계층에 데이터를 전달하려고 할 때 deliver_data()를 호출한다.

이 절에서는 단방향 데이터 전송(unidirectional data tranfer)의 경우인 송신 측으로부터 수신 측까지의 데이터 전송만을 고려한다.

양방향(전이중) 데이터 전송(bidirectional data transfer)의 설명은 상당히 복잡하다.

단방향 데이터 전송만 생각하더라도 프로토콜의 송신 측과 수신 측이 양방향으로 패킷을 전달할 필요가 있다.

즉, rdt의 송신 측과 수신 측은 전송 데이터를 포함하는 패킷을 교환하는 것 외에 제어 패킷을 양쪽으로 전송해야 한다.

• rdt의 송신 측과 수신 측 모두 udt_send()를 호출함으로써 다른 쪽에 패킷을 전송한다.
  • udt : 비신뢰적인 데이터 전송(unreliable data transfer)을 나타냄

• 화살표는 한 상태로부터 다른 상태로의 전이를 나타낸다.
• FSM의 초기 상태는 점선 화살표로 표시된다.

• 전이를 일으키는 이벤트(event)는 변화를 표기하는 가로선 위에 나타낸다.
• 이벤트가 발생했을 때 취해지는 행동, 액션(action)은 가로선 아래에 나타낸다.

• 이벤트 발생 시 어떠한 행동도 취해지지 않거나, 어떠한 이벤트 발생 없이 행동이 취해질 때
  동작이나 이벤트가 없음을 표시하기 위해 각각 가로선 아래나 위에 기호 𝚲를 사용한다.

하위 채널이 완전히 신뢰적인 가장 간단한 경우를 고려해보자.

rdt1.0 송신자와 수신자에 대한 유한상태 머신(FSM) 정리는 아래 그림과 같다.

💡 송신자에 대해 그리고 수신자에 대해 분리된 FSM이 있다

• a는 송신자(sender)의 동작에 대한 정의
• b는 수신자(receiver)의 동작에 대한 정의

rdt1.0에서 각각의 FSM은 하나의 상태만을 가지므로, 전이는 필연적으로 그 상태로부터 자신으로 되돌아온다.

1. rdt_send(data) 이벤트에 의해
   (이 이벤트는 상위 계층 애플리케이션의 프로시저 호출(e.g., rdt_send())에 의해 발생)
   1. 상위 계층으로부터 데이터를 받아들이고
   2. 데이터를 포함한 패킷을 생성한다. (make_pkt(data))
2. 그러고 난 후 패킷을 채널로 송신한다.

1. rdt는 rdt_rcv(packet) 이벤트에 의해 하위의 채널로부터 패킷을 수신한다. : 이 이벤트는 하위 계층 프로토콜로부터의 프로시저 호출(e.g., rdt_rcv())에 의해 발생한다.
2. 패킷으로부터 데이터를 추출하고 (extract(packet, data))
3. 데이터를 상위 계층으로 전달한다. (deliver_data(data))

여기서는 데이터 단위와 패킷의 차이점이 없으며, 모든 패킷 흐름은 송신자로부터 수신자까지다.

💡 완전히 신뢰적인 채널에서는 오류가 생길 수 없으므로 수신 측이 송신 측에게 어떤 피드백(feedback)도 제공할 필요가 없다.

또한, 수신자는 송신자가 데이터를 송신하자마자 데이터를 수신할 수 있다고 가정하였다.

따라서 수신자가 송신자에게 천천히 보내라는 것을 요청할 필요가 없다.

패킷 안의 비트들이 하위 채널에서 손상되는 모델이다.

일반적으로 이러한 비트 오류는 패킷이 전송 도는 전파되거나 버퍼링될 때 네트워크의 물리적인 구성요소에서 발생한다.

• 긍정 확인응답(positive acknowledgment, “OK”)
• 부정 확인응답(negative acknowledgment, “그것을 반복해주세요”)

이러한 제어 메시지는 정확하게 수신되었는지 또는 잘못 수신되어 반복이 필요한지를 수신자가 송신자에게 알려줄 수 있게 한다.

비트 오류를 처리하기 위해 기본적으로 다음과 같은 세 가지 부가 프로토콜 기능이 ARQ 프로토콜에 요구된다.

비트 오류가 발생했을 때 수신자가 검출할 수 있는 기능이 필요하다. → checksum

이러한 기술은 수신자가 패킷 비트 오류를 검출하고 복구할 수 있게 해준다.

송신자가 수신자의 상태를 알기 위한 유일한 방법은 수신자가 송신자에게 피드백을 제공하는 것이다.

수신자의 상태 : 패킷이 정확하게 수신되었는지 아닌지 등

e.g., rdt2.0 프로토콜에서는 수신자로부터 송신자 쪽으로 ACK와 NAK 패킷들을 전송할 것이다.

• 긍정 확인 응답(ACK)
• 부정 확인 응답(NAK)

→ 이러한 패킷은 단지 한 비트 길이면 된다. (0 또는 1)

수신자에서 오류를 가지고 수신된 패킷은 송신자에 의해 재전송(retransmit)된다.

2개의 상태가 존재한다.

1. 왼쪽 상태에서 송신 측 프로토콜은 상위 계층으로부터 데이터가 전달되기를 기다린다.
   1. 송신자는 패킷 체크섬과 함께 전송될 데이터를 포함하는 패킷(sndpkt)을 생성하고,
   2. 그 패킷을 udt_send(sndpkt) 동작을 통해 전송한다.
2. rdt_sent(data) 이벤트가 발생하면,
3. 오른쪽 상태에서 송신자 프로토콜은 수신자로부터의 ACK 또는 NAK 패킷을 기다린다.
   1. 만약 ACK 패킷이 수신된다면 (rdt_rcv(rcvpkt) && isACK(rcvpkt))
      • 가장 최근에 전송된 패킷이 정확하게 수신되었음을 의미한다.
      • 따라서 프로토콜은 상위 계층으로부터 데이터를 기다리는 상태로 돌아간다.
   2. 만약 NAK가 수신된다면
      1. 프로토콜은 마지막 패킷을 재전송한다.
      2. 재전송된 데이터 패킷에 대한 응답으로 수신자에 의해 응답하는 ACK 또는 NAK를 기다린다.

rdt2.0과 같은 프로토콜은 전송 후 대기(stop-and-wait) 프로토콜이다.

💡 송신자가 ACK 또는 NAK를 기다리는 상태에 있을 때, 상위 계층으로부터 더 이상의 데이터를 전달받을 수 없다.

즉, rdt_send() 이벤트는 발생할 수 없으며, 이는 오직 송신자가 ACK를 수신하고 이 상태를 떠난 후에 발생할 것이다.

따라서 송신자는 수신자가 현재의 패킷을 정확하게 수신했음을 확신하기 전까지 새로운 데이터를 전달하지 않는다.

단일 상태를 갖는다.

패킷이 도착했을 때, 수신자는 수신된 패킷이 손상되었는지 아닌지에 따라 ACK 또는 NAK로 응답한다.

여기서는 ACK 또는 NAK 패킷이 손상될 수 있다는 가능성을 고려하지 않았다.

만약 ACK 또는 NAK가 손상되었다면, 송신자는 수신자가 전송된 데이터의 마지막 부분을 올바르게 수신했는지를 알 방법이 없다.

대안 1 : 송신자가 검출뿐만 아니라 비트 오류로부터 회복할 수 있도록 충분한 체크섬 비트들을 추가한다.

이 방식은 패킷이 손상될 수 있으나 손실되지는 않는 채널의 경우에는 즉각적으로 문제를 해결할 수 있다.

대안 2 : 송신자가 왜곡된 ACK 또는 NAK 패킷을 수신할 때 현재 데이터 패킷을 단순히 다시 송신한다.

그러나 이 방식은 송신자에게 수신자 간의 채널로 중복 패킷(duplicate packet)을 전송한다.

• 송신자 입장에서는 마지막으로 전송된 ACK 또는 NAK가 송신자에게 정확하게 수신됐는지를 알 수 없다.
• 수신자 입장에서는 도착하는 패킷이 새로운 데이터를 포함하고 있는 것인지 아니면 재전송인지를 사전에 알 수 없다.

💡 데이터 패킷에 새로운 필드를 추가하고 이 필드 안에 순서 번호(sequence number)를 삽입하는 방식으로 데이터 패킷에 송신자가 번호를 붙인다.

이는 현존하는 데이터 전송 프로토콜에 채택된 방법이다.

수신자는 수신된 패킷이 재전송인지를 결정할 때는 이 순서 번호만 확인하면 된다.

rdt2.1은 rdt2.0보다 두 배 많은 상태를 가지고 있다.

이는 아래의 2가지를 반영해야 하기 때문이다.

1. 프로토콜 상태가 현재 (송신자에 의해) 전송되고 있는지에 대한 반영
2. (수신자가) 기다리고 있는 패킷이 순서 번호 0 또는 1을 가져야 하는지에 대한 반영

프로토콜 rdt2.1은 수신자로부터 송신자까지의 긍정 확인응답과 부정 확인응답을 모두 포함한다.

• 순서가 바뀐 패킷이 수신되면, 수신자는 이미 전에 수신한 패킷에 대한 긍정 확인응답을 전송한다.
• 손상된 패킷이 수신되면, 수신자는 부정 확인응답을 전송한다.

NAK를 송신하는 것 대신에,
가장 최근에 정확하게 수신된 패킷에 대해 ACK를 송신함으로써 NAK를 송신한 것과 같은 효과를 얻을 수 있다.

즉, 같은 패킷에 대해 2개의 ACK를 수신(즉, 중복(duplicate) ACK를 수신)한 송신자는
수신자가 두 번 ACK 한 패킷의 다음 패킷을 정확하게 수신하지 못했다는 것을 알게 된다. (NAK의 의미와 동일)

rtd2.2는 rdt2.1과 다르게,

1. 수신자가 반드시 ACK 메시지에 의해 확인 응답되는 패킷의 순서 번호를 포함해야 한다.
   • 이는 수신자 FSM의 make_pkt()에 ACK, 0 또는 ACK, 1인 인수를 넣어서 수행한다.
2. 송신자는 수신된 ACK 메시지에 의해 확인응답된 패킷의 순서 번호를 반드시 검사해야만 한다.
   • 이는송신자 FSM의 isACK()에 0 또는 1인 인수를 넣어서 수행한다.

하위 채널이 패킷을 손실하는 경우도 생각해보자.

다음과 같은 두 가지 부가 내용을 프로토콜이 다루어야 한다.

1. 어떻게 패킷 손실을 검출할 것인가?
2. 패킷 손실이 발생했을 때 어떤 행동을 할 것인가?

💡 송신자에게 손실된 패킷의 검출과 회복 책임을 부여한다.

송신자가 데이터 패킷을 전송하고, 패킷 또는 수신자의 패킷에 대한 ACK를 손실했다고 가정하자.

어느 경우에서나 송신자에게는 수신자로부터 어떠한 응답도 없다.

즉, 송신자는 데이터 패킷이 손실되었는지, ACK가 손실되었는지, 패킷 또는 ACK가 단순히 지나치게 지연된 것인지를 알지 못한다.

만약 송신자가 패킷을 잃어버렸다고 확신할 정도로 충분한 시간을 기다릴 수만 있다면, 데이터 패킷은 간단하게 재전송될 수 있다.

그러나 송신자가 어떤 패킷을 손실했다는 것을 확신하기 위해 얼마나 오랫동안 기다려야 할까?

송신자는 적어도 다음의 시간만큼을 기다려야 한다.

송신자와 수신자 사이의 왕복 시간 지연(중간 라우터에서의 버퍼링을 포함) + 수신 측에서 패킷을 처리하는 데 필요한 시간

실제 상황에서 채택한 접근 방식은 이와 같다.

💡 패킷 손실이 일어났을 만한 그런 시간을 선택하여, 만일 ACK가 이 시간 안에 수신되지 않는다면 패킷은 재전송된다.

이것은 송신자 대 수신자 채널에서 중복 데이터 패킷(duplicate data packet)의 가능성을 포함하나,
프로토콜 rdt2.2에서처럼 패킷의 순서 번호를 통하여 처리가 가능하다.

시간 기반의 재전송 메커니즘을 구현하기 위해서는
주어진 시간이 지난 후에 송신자를 인터럽트(중단)할 수 있는 카운트다운 타이머(countdown timer)가 필요하다.

그러므로 송신자는 다음처럼 동작해야 한다.

1. 매 패킷(첫 번째 또는 재전송 패킷)이 송신된 시간에 타이머를 시작한다.
2. 타이머 인터럽트에 반응한다. (즉, 적당한 행동을 취함)
3. 타이머를 멈춘다.

아래의 4가지 다이어그램은 프로토콜이 패킷 손실 또는 지연 없이 어떻게 동작하는지와 손실된 데이터 패킷을 어떻게 처리하는지를 나타낸 것이다.

시간은 다이어그램의 위로부터 아래로 흐른다.

패킷에 대한 수신 시간은 전송 지연과 전파 지연 때문에 패킷 전송 시간보다 더 늦다.

패킷의 순서 번호가 0과 1이 번갈아 일어나기 때문에 프로토콜 rdt3.0은 얼터네이팅 비트 프로토콜(alternating-bit protocol)이라고 부른다.

프로토콜 rdt3.0은 기능적으로는 정확한 프로토콜이나, 오늘날의 고속 네트워크에서 누구나 이것의 성능에 만족하는 것은 아니다.

💡 rdt3.0의 핵심적인 성능 문제는 전송 후 대기(stop-and-wait) 프로토콜이라는 점 때문에 발생한다.

전송 후 대기 프로토콜은 형편없는 송신자 이용률(utilization, 또는 효율)을 갖는다.

이에 대한 해결책은 다음과 같다.

송신자에게 확인응답을 기다리기 전에 송신을 전송하도록 허용하는 것이다. = 파이프라이닝(pipelining)

즉, 많은 전송 중인 송신자-수신자 패킷을 파이프라인에 채워 넣는 것이다.

아래의 그림들을 통해 만약 확인응답들을 기다리기 전에 송신자가 3개의 패킷을 전송하도록 허용한다면
송신자의 이용률은 3배가 되리라는 것을 볼 수 있다.

즉, window size 만큼 효율이 증가한다는 것이다.

파이프라이닝 방식은 신뢰적인 데이터 전송 프로토콜에서 다음과 같은 중요성을 지니고 있다.

각각의 전송 중인 패킷은 유일한 순서 번호를 가져야 한다.

전송 중인 확인응답(ACK)이 안 된 패킷이 여럿 있을지도 모르기 때문이다.

최소한 ‘송신자는 전송되었으나 확인응답되지 않은 패킷’을 버퍼링해야 한다.

정확하게 수신된 패킷의 버퍼링은 수신자에게서도 필요하다.

파이프라인 오류 회복의 두 가지 기본적인 접근 방법

1. GBN(Go-Back-N) : N부터 반복
2. SR(Selective Repeat) : 선택적 반복

💡 GBN(Go-Back-N, N부터 반복) 프로토콜에서 송신자는 확인 응답을 기다리지 않고 여러 패킷을 전송(가능할 때)할 수 있다.

그러나 파이프라인에서 확인응답이 안 된 패킷의 최대 허용 수 N보다 크지 말아야 한다.

아래 그림은 GBN 프로토콜에서 송신자 관점의 순서 번호 범위를 보여준다.

• 확인응답이 안 된 가장 오래된 패킷의 순서 번호를 base로 정의한다.
• 가장 작은 순서 번호를 nextseqnum(전송될 다음 패킷의 순서 번호)으로 정의한다.

이를 통해서 순서 번호의 범위에서 4개의 간격을 식별할 수 있다.

1. 간격 [0, base-1] : 순서 번호는 이미 전송되고 확인응답이 된 패킷
2. 간격 [base, nextseqnum-1] : 송신은 되었지만 아직 확인응답되지 않은 패킷
3. 간격 [nextseqnum, base+N-1] : 상위 계층으로부터 데이터가 도착하면 바로 전송될 수 있는 패킷
4. base+N 이상
   → 파이프라인에서 확인응답이 안 된 패킷(특히, 순서 번호 base를 가진 패킷)의 확인응답이 도착할 때까지 사용될 수 없다.

전송되었지만 아직 확인응답이 안 된 패킷을 위해,
허용할 수 있는 순서 번호의 범위는 순서 번호의 범위상에서 크기가 N인 ‘윈도(window)’로 나타낸다.

• 프로토콜이 동작할 때, 이 윈도는 순서 번호 공간에서 오른쪽으로 이동(slide)된다.
• N = 윈도 크기(window size)

따라서 GBN 프로토콜은 슬라이딩 윈도 프로토콜(sliding-window protocol)이라고 부른다.

실제로 패킷의 순서 번호는 패킷 헤더 안의 고정된 길이 필드에 포함된다.

• 만약 k가 패킷 순서 번호 필드의 비트 수라면, 순서 번호의 범위는 [0, 2^k - 1]
• 순서 번호의 제한된 범위에서, 순서 번호를 포함하는 모든 계산은 모듈로(modulo) 2^k 연산을 이용한다.

• base와 nextseqnum 변수를 추가한다.
• 이러한 변수에서의 동작과 이러한 변수를 포함하는 조건부 동작을 추가한다.

GBN 송신자는 다음과 같은 세 가지 타입의 이벤트에 반응해야 한다.

1️⃣ 상위로부터의 호출

1. rdt_send()가 위로부터 호출되면, 송신자는 우선 윈도가 가득 찼는지 확인한다.
   (즉, N개의 아직 확인응답되지 않은 패킷이 있는지를 확인)
2. 만약 윈도가 가득 차 있지 않다면 패킷이 생성되고 송신되며, 변수들이 적절하게 갱신된다.
3. 만약 윈도가 가득 차 있다면, 단지 데이터를 상위 계층으로 반환한다.
   • 이는 윈도가 가득 차 있음을 가리키는 함축적인 의미이다.
   • 따라서 상위 계층은 나중에 rdt_send()를 다시 시도할 것이다.

실제적인 구현에서 송신자는 아래와 같은 방법을 사용할 것이다.

1. 이 데이터를 버퍼링한다. (그러나 즉시 송신하진 않음)
2. 오직 윈도가 가득 차 있지 않을 때만 rdt_send()를 호출하는 동기화 메커니즘을 사용한다.
   (e.g., semaphore 또는 flag)

2️⃣ ACK의 수신

GBN 프로토콜에서
순서 번호 n을 가진 패킷에 대한 확인응답은 누적 확인응답(cumulative acknowledgment)으로 인식된다.

이 누적 확인 응답은 수신 측에서 올바르게 수신된 n을 포함하여, n까지의 순서 번호를 가진 모든 패킷에 대한 확인 응답이다.

3️⃣ 타임아웃 이벤트

타이머는 손실된 데이터 또는 손실된 확인응답 패킷으로부터 회복하는 데 사용된다.

만약 타임아웃이 발생한다면, 송신자는 이전에 전송되었지만 아직 확인응답되지 않은 !!모든!! 패킷을 다시 송신한다.

위의 그림에서 송신자는
가장 오래된 ‘전송했지만, 아직 확인응답 안 된 패킷’에 대한 타이머로 생각될 수 있는 단일 타이머를 사용한다.

• 만일 한 ACK가 수신되었지만, 추가로 ‘전송했지만, 아직 확인응답 안 된 패킷’이 아직 존재한다면, 타이머를 다시 시작한다.
• 만약 아직 확인응답 안 된 패킷이 없다면, 타이머를 멈춘다.

• 만약 순서 번호 n을 가진 패킷이 오류 없이, 그리고 순서대로 수신된다면
  (= 상위 계층에 마지막으로 전달된 데이터가 순서 번호 n-1을 가진 패킷에서 온 것이라면)
  수신자는 패킷 n에 대한 ACK를 송신하고 상위 계층에 패킷의 데이터 부분을 전달한다.
• 그 외의 경우에는 수신자는 그 패킷을 버리고 가장 최근에 제대로 수신된 순서의 패킷에 대한 ACK를 재전송한다.

지금 패킷 n이 수신되어야 하지만, 그 사람 다음의 패킷 n+1이 먼저 도착했다고 가정하자.

수신자는 상위 계층에 데이터를 전달해야 한다.

데이터가 순서대로 전달되어야 하므로, 수신자는 패킷 n+1을 저장하고
나중에 패킷 n이 수신되고 전달된 후에 상위 계층에 이 패킷을 전달한다.

그러나 만일 패킷 n이 손실된다면, GBN 재전송 규칙에 따라 수신자에게는 패킷 n과 n+1이 모두 재전송될 것이다.

💡 이점 : 수신자 버퍼링이 간단하다 (수신자는 어떤 순서가 잘못된 패킷에 대해 버퍼링을 할 필요가 없다!)

• 송신자가 유지해야 하는 것
  1. 윈도 상위와 하위 경계
  2. 이 윈도 안에 있는 nextseqnum 위치
• 수신자가 유지해야 하는 것 : 다음 순서 패킷의 순서 번호

물론, 올바르게 수신된 패킷을 버리는 것의 단점은 그 패킷의 재전송이 손실되거나 왜곡될 수 있으므로 많은 재전송이 필요할 수도 있다는 것이다.

아래 그림은 윈도 크기가 4 패킷인 경우에 대한 GBN 프로토콜의 동작을 보여준다.

• 윈도 크기가 4 → 송신자는 패킷 0부터 3까지 송신한다.
• 송신을 계속하기 전에 하나 이상의 패킷이 긍정 확인응답되는 것을 기다려야 한다.

• ACK0, ACK1처럼 각각의 성공적인 ACK가 수신되었을 때
  1. 윈도는 앞으로 이동한다.
  2. 송신자는 하나의 새로운 패킷(pkt4와 pkt5, 각각)을 전송한다.
• 수신 측에서는 pkt2가 손실되었으므로 pkt3, 4, 5는 순서가 잘못된 패킷으로 발견되어 제거된다.

앞에서 본, 확장된(extended) FSM을 다시 떠올려보자.

이 구현은 발생할 수 있는 다양한 이벤트에 대한 대응으로 취할 수 있는 동작을 구현하는 다양한 절차들과 유사하다.

이러한 이벤트 기반 프로그래밍(event-based programming)에서의 다양한 프로시저들은
프로토콜 스택에서 다른 프로시저에 의해 야기되거나 인터럽트의 결과로 요청될 것이다.

송신자에서 이러한 이벤트들에 대한 예시로는 다음과 같다.

1. rdt_send()를 호출하기 위한 상위 계층 개체로부터의 호출
2. 타이머 인터럽트
3. 패킷이 도착했을 때 rdt_rcv()를 호출하기 위한 하위 계층으로부터의 호출

GBN 프로토콜은 송신자가 패킷으로 파이프라인을 채우는 것을 통해 전송 후 대기 프로토콜에서의 채널 이용률 문제를 피하도록 하였다.

그러나 GBN 자체에는 성능 문제를 겪는 시나리오들이 존재한다.

윈도 크기와 대역폭 지연(bandwidth-delay) 곱의 결과가 모두 클 때, 많은 패킷이 파이프라인에 있을 수 있다.

GBN은 패킷 하나의 오류 때문에 많은 패킷을 재전송하므로, 많은 패킷을 불필요하게 재전송하는 경우가 발생한다.

채널 오류의 확률이 증가할수록 파이프라인은 불필요한 재전송 데이터로 채워진다.

💡 SR(Selective Repeat, 선택적 반복) 프로토콜은
수신자에서 오류(손실되거나 변조된)가 발생한 패킷을 수신했다고 의심되는 패킷만을 재전송한다.

• 이를 통해서 SR는 불필요한 재전송을 피한다.
• 필요에 따라 각각의 개별적인 재전송은 수신자가 올바르게 수신된 패킷에 대한 개별적인 확인응답을 요구할 것이다.

윈도 크기 N은 파이프라인에서 아직 확인응답이 안 된 패킷 수를 제한하는 데 사용된다.

그러나 GBN과는 달리, 송신자는 윈도에 있는 몇몇 패킷에 대한 ACK를 이미 수신했을 것이다.

• SR 수신자는 패킷의 순서와는 무관하게 손상 없이 수신된 패킷에 대한 확인응답을 할 것이다.
• 빠진 패킷이 존재하는 경우
  1. 순서가 바뀐 패킷은 빠진 패킷이 수신될 때까지 버퍼에 저장하고,
     (빠진 패킷 = 아직 도착하지 않은 더 낮은 순서 번호를 가진 패킷)
  2. 빠진 패킷이 수신된 시점에서 일련의 패킷을 순서대로 상위 계층에 전달할 수 있다.
     (re-order & reassemble the packets → in-order delivery to upper layer)

1️⃣ 상위로부터 데이터 수신

상위에서 데이터가 수신될 때, SR 송신자는 패킷의 다음 순서 번호를 검사한다.

• 순서 번호가 송신자 윈도 내에 있으면 데이터는 패킷으로 송신된다.
• 그렇지 않으면 GBN처럼 버퍼에 나중에 전송하기 위해 되돌려진다.

2️⃣ 타임아웃

타이머는 손실된 패킷을 보호하기 위해 재사용된다.

그러나 타임아웃 시 오직 한 패킷만이 전송되기 때문에, 각 패킷은 자신의 논리 타이머가 있어야 한다.

3️⃣ ACK 수신

ACK가 수신되었을 때, SR 송신자는 그 ACK가 윈도 내에 있다면 그 패킷을 수신된 것으로 표기한다.

• 만약 패킷 순서 번호가 send_base와 같다면, 윈도 베이스는 가장 작은 순서 번호를 가진 아직 확인응답되지 않은 패킷으로 옮겨진다.
• 만약 윈도가 이동하고 윈도 내의 순서 번호를 가진 미전송 패킷이 있다면, 이 패킷들은 전송된다.

1️⃣ [rcv_base, rcv_base+N-1] 내의 순서 번호를 가진 패킷이 손상 없이 수신된다.

이 경우는 수신된 패킷이 수신자의 윈도에 속하는 것이며, 선택적인 ACK 패킷이 송신자에게 회신된다.

• 만약 이 패킷이 이전에 수신되지 않았던 것이라면 버퍼에 저장된다.
• 만약 이 패킷이 수신 윈도의 base와 같은 순서 번호를 가졌다면,
  이 패킷과 이전에 버퍼에 저장되어 연속적으로 번호를 가진(rcv_base로 시작하는) 패킷들은 상위 계층으로 전달된다.

2️⃣ [rcv_base-N, rcv_base-1] 내의 순서 번호를 가진 패킷이 수신된다.

이 경우에는 이 패킷이 수신자가 이전에 확인응답한 것이라도 ACK가 생성되어야 한다.

3️⃣ 그 외의 경우, 패킷을 무시한다.

1. 처음에 pkt3, 4, 5를 버퍼에 저장한다.
2. 마지막으로 pkt2가 수신되었을 때 pkt2와 함께 상위 계층에 전달한다.

SR 수신자 이벤트와 행동의 2단계 : [rcv_base-N, rcv_base-1] 내의 순서 번호를 가진 패킷이 수신된다.

여기서 수신자가 현재의 윈도 base보다 작은 특정 순서 번호를 가진 ‘이미 수신된 패킷’을 무시하지 않고 재확인 응답을 하는 것이 중요하다!

e.g.,
송신자와 수신자의 순서 번호 공간을 줬을 때, 수신자가 송신자에게 보내는 send_base 패킷에 대한 ACK가 없다면
(우리에게는 수신자가 그 패킷을 이미 수신했음이 분명하더라도) 결국 송신자는 send_base 패킷을 재전송할 것이다.

만약 수신자가 이 패킷에 대한 확인응답을 하지 않는다면, 송신자의 윈도는 결코 앞으로 이동하지 않을 것이다.

💡 송신자와 수신자는 올바른 수신과 그렇지 않은 수신에 대해 항상 같은 관점을 갖지는 않을 것이다.

→ 이는 SR 프로토콜에서 송신자와 수신자의 윈도가 항상 같지 않다는 것을 뜻한다.

송신자와 수신자 윈도 사이의 동기화 부족은 순서 번호의 한정된 범위에 직면했을 때 중대한 결과를 가져온다.

e.g.,

• 한정된 범위의 네 패킷 순서 번호 0, 1, 2, 3
• 윈도 크기 : 3

0부터 2까지의 패킷이 전송되어 올바로 수신되고, 수신자에게서 확인이 되었다고 가정하자.

그 순간에 수신자의 윈도는 각각의 순서 번호가 3, 0, 1인 4, 5, 6번째 패킷에 있다.

1. 처음 3개의 패킷에 대한 ACK가 손실되고, 송신자는 이 패킷을 재전송한다.
2. 수신자는 순서 번호가 0인 패킷(처음 보낸 패킷의 복사본)을 수신한다.

1. 처음 3개의 패킷에 대한 ACK가 모두 올바르게 전달되었다.
2. 송신자는 자신의 윈도를 앞으로 이동시켜, 각각의 순서 번호가 3, 0, 1인 4, 5, 6번째 패킷을 보낸다.
3. 순서 번호 3을 가진 패킷이 손실되고, 순서 번호 0을 가진 패킷(새로운 데이터를 포함한 패킷)은 도착한다.

수신자는 송신자의 행동을 볼 수 없다.

모든 수신자는 채널을 통해 받고, 채널을 통해 보내는 메시지의 순서를 관찰하는데, 이는 위의 두 가지 시나리오가 똑같다.

즉, 다섯 번째 패킷의 원래 전송과 첫 번째 패킷의 재전송을 구별할 방법은 없다.

윈도 크기는 SR 프로토콜에 대한 순서 번호 공간 크기의 절반보다 작거나 같아야 한다.

맨 앞에서 패킷들은 송신자와 수신자 사이의 채널 안에서 순서가 바뀔 수 없다는 가정 하에 신뢰적인 데이터 전송 프로토콜에 대한 설명을 진행하였다.

이는 일반적으로 송신자와 수신자가 단일한 물리적 선으로 연결되어 있을 때 적합한 가정이다.
하지만 둘을 연결하는 ‘채널’이 네트워크일 때는 패킷 순서 바뀜이 일어날 수 있다.

패킷 순서 바뀜 현상으로, 송신자와 수신자의 윈도가 x를 포함하지 않고 있더라도
순서 번호 또는 확인응답 번호 x를 가진 오래된 패킷의 복사본들이 생길 수 있다.

패킷 순서가 바뀌는 채널이라는 것은 본질적으로 패킷들을 버퍼에 저장하고, 나중에 어느 때나 이 패킷들을 임의로 내보낸다고 간주할 수 있다.

순서 번호가 재사용될 수 있으므로 그런 중복된 패킷들을 막을 수 있는 조치가 필요하다.

실제 방식은 송신자가 이전에 송신된 순서 번호 x를 가진 패킷들이
더는 네트워크 상에 없음을 어느 정도 ‘확신’할 때까지 순서 번호가 재사용되지 않음을 확실히 하는 것이다.

이는 패킷이 어느 일정 시간 이상으로 네트워크에서 존재할 수 없다는 가정에 의해 이루어진다.

전송된 패킷 안의 비트 오류를 발견하는 데 사용된다.

채널 안에서 패킷이 손실되었기 때문에 발생되는 패킷(또는 이것의 ACK)의 타임아웃/재전송에 사용된다.

발생 이유

1. 패킷이 지연되었지만 손실되지는 않았을 경우 (조기 타임 아웃)
2. 패킷이 수신자에 의해 수신되었으나 수신자에서 송신자로의 ACK가 손실되었을 경우

→ 수신자에 의해 수신되는 패킷은 중복으로 복사(수신)된 패킷일 수 있다.

송신자에서 수신자로 가는 데이터 패킷의 순서 번호를 붙이기 위해 사용된다.

• 수신자 패킷의 순서 번호의 간격 : 수신자가 손실된 패킷을 검사하게 한다.
• 중복된 순서 번호를 갖는 패킷 : 수신자가 패킷의 중복 복사를 검사하게 한다.

수신자가 한 패킷 또는 패킷 집합이 정확히 수신되었다는 응답을 송신자에게 하기 위해 사용된다.

• 일반적으로 패킷 또는 이미 확인응답된 패킷들의 순서 번호를 전달한다.
• 프로토콜에 따라 개별적이거나 누적된 것일 수 있다.

수신자가 패킷이 정확히 수신되지 않았다는 응답을 송신자에게 하기 위해 사용된다.

• 일반적으로 정확히 수신되지 않은 패킷의 순서 번호를 전달한다.

송신자는 주어진 범위에 있는 순서 번호를 가진 패킷만 전송하도록 제한될 수 있다.

확인응답은 없지만 허가된 패킷이 전송될 수 있으므로, 송신자의 이용률은 전송 후 대기 모드의 동작보다 증가할 수 있다.

윈도 크기는 수신자의 메시지를 수신하고 버퍼링하는 능력, 네트워크의 혼잡 정도, 또는 두 가지 모두에 근거하여 설정된다.

💡 TCP는 애플리케이션 프로세스가 데이터를 다른 프로세스에게 보내기 전에,
두 프로세스가 서로 ’핸드셰이크’를 먼저 해야 하므로 연결지향형(connection-oriented)이다.

즉, 데이터 전송을 보장하는 파라미터들을 각자 설정하기 위한 어떤 사전 세그먼트들을 보내야 한다.

TCP 연결은 두 통신 종단 시스템의 TCP에 존재하는 상태를 공유하는 논리적인 것이다.

TCP 연결은 전이중 서비스(full-duplex service)를 제공한다.

만약 호스트 A의 프로세스와 호스트 B의 프로세스 사이에 TCP 연결이 있다면,
애플리케이션 계층 데이터는 B에서 A로 흐르는 동시에 A에서 B로 흐를 수 있다.

TCP 연결은 항상 단일 송신자와 단일 수신자 사이의 점대점(point-to-point)이다.

따라서 단일 송신 동작으로 한 송신자가 여러 수신자에게 데이터를 전송하는 ‘멀티캐스팅(multicasting)’은 TCP에서는 불가능하다.

• 클라이언트 프로세스(client process) : 연결을 초기화하는 프로세스
• 서버 프로세스(server process)

(3.5.6에서 더 자세히 다룰 예정)

1. 클라이언트 애플리케이션 프로세스는 서버의 프로세스와 연결을 설정하기를 원한다고 TCP 클라이언트에게 먼저 알린다.
2. 클라이언트의 트랜스포트 계층은 서버의 TCP와의 TCP 연결 설정을 진행한다.
3. 즉, 클라이언트가 먼저 특별한 TCP 세그먼트를 보낸다.
4. 서버는 두 번째 특별한 TCP 세그먼트로 응답한다.
5. 마지막으로, 클라이언트가 세 번째 특별한 세그먼트로 다시 응답한다.

• 처음 2개의 세그먼트에는 페이로드(payload, 애플리케이션 계층 데이터)가 없다.
• 세 번째 세그먼트는 페이로드를 포함할 수 있다.

일단 TCP 연결이 설정되면, 두 애플리케이션 프로세스는 서로 데이터를 보낼 수 있다.

1. 클라이언트 프로세스는 소켓(프로세스의 관문)을 통해 데이터의 스트림을 전달한다.
2. 데이터가 관문을 통해 전달되면, 이제 데이터는 클라이언트에서 동작하고 있는 TCP에 맡겨진다.
   1. TCP는 초기 세 방향 핸드셰이크 동안 준비된 버퍼 중의 하나인 연결의 송신 버퍼(send buffer)로 데이터를 보낸다.
   2. 때때로 TCP는 송신 버퍼에서 데이터 묶음을 만들어서 네트워크로 보낸다. (TCP가 언제 버퍼된 데이터를 전송해야 하는지는 정해져 있지 않음)

세그먼트로 모아 담을 수 있는 최대 데이터 양은 최대 세그먼트 크기(maximum segment size, MSS)로 제한된다.

MSS를 결정하는 요소

• 로컬 송신 호스트에 의해 전송될 수 있는 가장 큰 링크 계층 프레임의 길이
  (최대 전송 단위(maximum transmission unit, MTU)
• TCP 세그먼트(IP 데이터그램 안에 캡슐화되었을 때)와 TCP/IP 헤더 길이(통상 40바이트)가 단일 링크 계층 프레임에 딱 맞도록 한다.

💡 MSS는 헤더를 포함하는 TCP 세그먼트의 최대 크기가 아니라, 세그먼트에 있는 애플리케이션 계층 데이터에 대한 최대 크기이다.

TCP 헤더 + 클라이언트 데이터

1. 네트워크 계층에 전달되어 네트워크 계층 IP 데이터그램 안에 각각 캡슐화된다.
2. 세그먼트는 네트워크로 송신된다.
3. TCP가 상대에게서 세그먼트를 수신했을 때, 세그먼트의 데이터는 TCP 연결의 수신 버퍼에 위치한다.
   → 애플리케이션은 이 버퍼로부터 데이터의 스트림을 읽는다.

TCP 연결의 양 끝은 각각 자신의 송신 버퍼와 수신 버퍼를 갖고 있다.

💡 즉, TCP 연결은 한쪽 호스트에서의 버퍼, 변수, 프로세스에 대한 소켓 연결과
다른 쪽 호스트에서의 버퍼, 변수, 프로세스에 대한 소켓 연결의 집합으로 이루어진다.

• 출발지와 목적지 포트 번호(source and destination port number)
• 체크섬 필드(checksum field)
• 32비트 순서 번호 필드(sequence number field)
• 32비트 확인응답 번호 필드(acknowledgement number field)
• 16비트 수신 윈도(receive window) : 흐름 제어에 사용된다.
  (수신자가 받아들이려는 바이트의 크기를 나타내는데 사용됨)
• 4비트 헤더 길이 필드(header length field) : 32비트 워드 단위로 TCP 헤더의 길이를 나타낸다.
• 옵션 필드(option field)
  • 이 필드는 선택적이고 가변적인 길이를 가진다.
  • 송신자와 수신자가 최대 세그먼트 크기(MSS)를 협상하거나 고속 네트워크에서 사용하기 위한 윈도 확장 요소로 이용된다.
• 플래그 필드(flag field) : 6비트를 포함한다.
  • ACK 비트 : 확인응답 필드에 있는 값이 유용함을 가리키는 데 사용된다.
  • RST, SYN, FIN 비트 : 연결 설정과 해제에 사용된다.
  • PSH 비트 : 이 비트가 설정되었다면 이것은 수신자가 데이터를 상위 계층에 즉시 전달해야 함을 가리킨다.
  • URG 비트
    • 이 세그먼트에서 송신 측 상위 계층 개체가 ‘긴급’으로 표시하는 데이터임을 가리킨다.
    • 이 긴급 데이터의 마지막 바이트의 위치는 16비트의 긴급 데이터 포인터 필드(urgent data pointer field)에 의해 가리켜진다.

애플리케이션 데이터의 일정량을 담는다.

MSS는 세그먼트 데이터 필드의 크기를 제한한다.

• 큰 파일 전송 시, 일반적으로 MSS 크기로 파일을 분절한다.
• 많은 대화식 애플리케이션은 MSS보다 작은 양의 데이터를 전송한다.

이 두 필드는 TCP의 신뢰적인 데이터 전송 서비스의 중대한 부분이다.

TCP는 데이터를 구조화되어 있지 않고 단지 순서대로 정렬되어 있는 바이트 스트림으로 본다.

세그먼트에 대한 순서 번호는 세그먼트에 있는 첫 번째 바이트의 바이트 스트림 번호다.

e.g.,

• 데이터 스트림은 500,000 바이트로 구성된 파일이라고 가정한다.
• MSS는 1,000 바이트
• 데이터 스트림의 첫 번째 바이트는 0으로 설정한다.

아래 그림처럼 TCP는 데이터 스트림으로부터 500개의 세그먼트들을 구성하며, 각 세그먼트가 할당받는 순서 번호는 다음과 같다.

💡 각각의 순서 번호는 적절한 TCP 세그먼트의 헤더 내부의 순서 번호 필드에 삽입된다.

TCP는 전이중 방식임을 상기하자.
(호스트 A가 호스트 B로 데이터를 송신하는 동안에 호스트 B로부터 데이터를 수신하게 해줌)

호스트 B로부터 도착한 각 세그먼트는 B로부터 A로 들어온 데이터에 대한 순서 번호를 갖는다.

💡 호스트 A가 자신의 세그먼트에 삽입하는 확인응답 번호는 호스트 A가 호스트 B로부터 기대하는 다음 바이트의 순서 번호다.

e.g.,
호스트 A가 호스트 B로부터
0 ~ 535의 바이트를 포함하는 어떤 세그먼트와 900 ~ 1,000의 바이트를 포함하는 또 다른 세그먼트를 수신했다고 가정하자.

(어떤 이유 때문인지 몰라도, 호스트 A는 그 사이 536~899의 바이트를 아직 수신하지 않았음)

호스트 A는 B의 데이터 스트림을 재생성하기 위해 536번째(와 그 다음의) 바이트를 아직 기다리고 있다.

그러므로 B에 대한 A의 다음 세그먼트이 확인응답 번호 필드에 536을 가질 것이다.

TCP는 스트림에서 첫 번째 잃어버린 바이트까지의 바이트들까지만 확인응답하기 때문에,
TCP는 누적 확인응답(cumulative acknowledgment)을 제공한다고 한다.

위 예에서 호스트 A는 세 번째 세그먼트(900~1,000 값의 바이트)를 두 번째 세그먼트(536~899 값의 바이트)가 수신되기 전에 수신했다.

즉, 세 번째 세그먼트는 순서가 틀리게 도착했다.

이 상황에서 호스트는 어떻게 행동을 할까?

TCP RFC는 TCP 연결에서 순서가 바뀐 세그먼트를 수신할 때 호스트가 어떤 행동을 취해야 하는지에 대한 어떤 규칙도 부여하지 않았고,
TCP 구현 개발자에게 맡기고 있다.

두 가지 선택지

1. 수신자가 순서가 바뀐 세그먼트를 즉시 버린다.
2. 수신자는 순서가 바뀐 데이터를 보유하고, 빈 공간에 잃어버린 데이터를 채우기 위해 기다린다.

후자가 네트워크 대역폭 관점에서는 효율적이며, 실제에서도 취하는 방법이다.

• 원격 로그인을 위해 사용되는 유명한 애플리케이션 계층 프로토콜
• TCP 상에서 실행되며, 한 쌍의 호스트들 사이에서 동작하도록 설계되었다.

호스트 A가 호스트 B로 텔넷 세션을 시작한다고 가정하자.

• 호스트 A가 세션을 시작하므로 클라이언트
• 호스트 B는 서버

💡 세그먼트의 순서 번호 = 데이터 필드 안에 있는 첫 번째 바이트의 순서 번호

• 클라이언트의 초기 순서 번호 : 42 → 클라이언트에서 송신된 첫 번째 세그먼트는 순서 번호 42를 가진다.
• 서버의 초기 순서 번호 : 79 → 서버에서 송신된 첫 번째 세그먼트는 순서 번호 79를 가질 것이다.

💡 확인응답 번호 = 호스트가 기다리는 데이터의 다음 바이트의 순서 번호

TCP 연결이 설정된 후에 어떤 데이터도 송신되기 전,

• 클라이언트는 바이트 79를 기다리고 있다.
• 서버는 바이트 42를 기다리고 있다.

사용자가 하나의 문자 ‘C’를 입력하고, 커피를 마신다고 가정하자.

위 그림처럼 3개의 세그먼트가 송신된다. = 세 방향 핸드셰이크(three-way handshake)

1️⃣ 첫 번째 세그먼트

• 클라이언트에서 서버로 송신된다.
• 순서 번호 필드 안에 42를 가진다.

2️⃣ 두 번째 세그먼트

• 서버에서 클라이언트로 송신된다.
• 두 가지 목적을 가진다.
  1. 수신하는 서버에게 데이터에 대한 확인응답을 제공
  2. 확인응답 필드 안에 43을 넣음으로써,
     (1) 서버는 클라이언트에게 바이트 42를 성공적으로 수신했고
     (2) 앞으로 바이트 43을 기다린다는 것을 말해준다.
  3. 문자 ‘C’를 반대로 반향되도록 하는 것두 번째 세그먼트는 TCP 연결의 서버-클라이언트 데이터 흐름의 최초 순서 번호인 순서 79를 갖는다.
     (이는 서버가 보내는 데이터의 맨 첫번째 바이트)
  4. → 그의 데이터 필드에 ‘C’의 ASCII 표현을 한다.

💡 클라이언트/서버 데이터에 대한 확인응답은 서버와 클라이언트 간에서 데이터를 운반하는 세그먼트 안에서 전달된다.
= 확인응답은 서버-클라이언트 데이터 세그먼트 상에서 피기백된다(piggybacked)

3️⃣ 세 번째 세그먼트

• 클라이언트에서 서버로 송신된다.
• 목적 : 서버로부터 수신한 데이터에 대한 확인응답을 하는 것
  • 이 세그먼트는 빈 데이터 필드를 갖는다.
  • 즉, 확인응답은 어떤 클라이언트-서버 데이터와 함께 피기백되지 않는다.
• 세그먼트는 확인응답 필드 안에 80을 갖는다.
  • 클라이언트가 순서 번호 79의 바이트를 통해 바이트의 스트림을 수신했기 때문이다.
  • 앞으로 80으로 시작하는 바이트를 기다린다.

이 세그먼트가 데이터를 포함하지 않는데도 순서 번호를 갖는다는 것이 이상하지만,
TCP가 순서 번호 필드를 갖고 있으므로 세그먼트 역시 어떤 순서 번호를 가져야 한다.

💡 TCP는 손실 세그먼트를 발견하기 위해 타임아웃/재전송 매커니즘을 사용한다.

타임아웃은 연결의 왕복 시간(round-trip time, RTT)보다 좀 커야 한다.

💡 왕복 시간(round-trip time, RTT) : 세그먼트가 전송된 시간부터 긍정 확인응답될 때까지의 시간

TCP가 송신자와 수신자 사이에 왕복 시간을 어떻게 예측하는지에 대하여 알아보자.

✅ SampleRTT라고 표시되는 세그먼트에 대한 RTT 샘플 : 세그먼트가 송신된 시간(IP에게 넘겨진 시간)으로부터 그 세그먼트에 대한 긍정응답이 도착한 시간까지의 시간 길이

대부분의 TCP는 한 번에 하나의 SampleRTT 측정만을 시행한다.

• 즉, 어떤 시점에서 SampleRTT는 전송되었지만 현재까지 확인응답이 없는 세그먼트 중 하나에 대해서만 측정된다.
• 이는 대략 왕복 시간마다 SampleRTT의 새로운 값을 얻게 한다.

✅ SampleRTT 값은 라우터에서의 혼잡과 종단 시스템에서의 부하 변화 때문에 세그먼트마다 다르기 때문에
대체로 RTT를 추정하기 위해 SampleRTT 값의 평균값을 채택한다.

→ TCP는 SampleRTT 값의 평균(EstimatedRTT)을 유지한다.

EstimatedRTT = (1 - α) × EstimatedRTT + α × SampleRTT
(권장되는 α의 값 : 0.125)

💡 EstimatedRTT는 SampleRTT의 가중평균(weighted average)이다.

• 이 가중평균은 예전 샘플보다 최근 샘플에 높은 가중치를 준다.
• 최신 샘플들이 네트워크상의 현재 혼잡을 더 잘 반영한다. → 지수적 가중 이동 평균(exponential weighted moving average, EWMA)

아래는 TCP 연결에 대해 α = 1/8의 값에 대한 SampleRTT 값들과 EstimatedRTT를 보여준다.

✅ DevRTT는 RTT 변화율을 의미한다.

이는 SampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지에 대한 측으로 정의한다.

DevRTT = (1 - β) × DevRTT + β × | SampleRTT - EstimatedRTT |
(권장되는 β의 값 : 0.25)

DevRTT는 SampleRTT와 EstimatedRTT 값 차이의 EWMA이다.

주어진 EstimatedRTT 와 DevRTT 값에서, TCP 타임아웃 주기에는 어떤 값이 사용되어야 하는가?

• 주기는 EstimatedRTT보다 크거나 같아야 한다.
  (그렇지 않다면 불필요한 재전송이 보내질 것)
• EstimatedRTT보다 너무 크면 안된다.
  (너무 크면 세그먼트를 잃었을 때, TCP는 세그먼트의 즉각적인 재전송을 하지 않게 됨)

→ 타임아웃값은 EstimatedRTT에 약간의 여윳값을 더한 값으로 설정하는 것이 바람직하다.

TimeoutInterval = EstimatedRTT + 4 × DevRTT

• 초기 TimeoutInterval의 값으로는 1초를 권고한다.
• 타임아웃이 발생할 때, TimeoutInterval의 값은 두 배로 하여
  조만간 확인응답할 후속 세그먼트에게 발생할 수 있는 조기 타임아웃을 피하도록 한다.

💡 TCP는 IP의 비신뢰적인 최선형 서비스에서 신뢰적인 데이터 전송 서비스(reliable data transfer service)를 제공한다.

• 프로세스가 자신의 수신 버퍼로부터 읽은 데이터 스트림이 손상되지 않음을 보장한다.
• 중복이 없다는 것과 순서가 유지된다는 것을 보장한다.

즉, 바이트 스트림은 송신자가 전송한 것과 같은 바이트 스트림이다.

타이머 관리는 상당한 오버헤드를 유발할 수 있다.

따라서 전송되었지만 확인응답이 안 된 다수의 세그먼트들이 있다고 하더라도,
권장되는 TCP 타이머 관리 절차에서는 오직 단일 재전송 타이머를 사용한다.

(이 장에서 설명하는 TCP 프로토콜은 단일 타이머를 따름)

1️⃣ 상위 애플리케이션으로부터 수신된 데이터

첫 번째 이벤트 발생으로,

1. TCP는 애플리케이션으로부터 데이터를 받고,
2. 세그먼트로 이 데이터를 캡슐화하고,
3. IP에게 이 세그먼트를 넘긴다.

• 각 세그먼트는 세그먼트의 첫 번째 데이터 바이트의 바이트 열 번호인 순서 번호를 포함한다.
• 타이머가 이미 다른 세그먼트에 대해 실행 중이 아니면, TCP는 이 세그먼트를 IP로 넘길 때 타이머를 시작한다.

2️⃣ 타이머 타임아웃

1. TCP는 타임아웃 이벤트에 대해 타임아웃을 일으킨 세그먼트를 재전송하여 응답한다.
2. 그리고 TCP의 타이머를 다시 시작한다.

3️⃣ 수신 확인응답 세그먼트(ACK) 수신

이 이벤트가 발생하면, TCP는 변수 SendBase와 ACK 값 y를 비교한다.

• SendBase : 수신 확인응답이 확인되지 않은 / 가장 오래된 바이트의 순서번호
• SendBase-1 : 수신자에게서 정확하게 차례대로 수신되었음을 알리는 마지막 바이트의 순서번호

TCP는 누적 확인응답을 사용하고, y는 y바이트 이전의 모든 바이트의 수신을 확인한다.

y > SendBase이면, ACK는 이전에 확인응답 안 된 하나 이상의 세그먼트들을 확인해준다.

1. 송신자는 자신의 SendBase 변수를 갱신한다.
2. 아직 확인응답 안 된 세그먼트들이 존재한다면 타이머를 다시 시작한다.

TCP 프로토콜이 어떻게 작동하는지 몇 가지 간단한 시나리오를 통해 알아보자.

호스트 A로부터 세그먼트가 호스트 B 측에서 수신되었음에도 B로부터 A로의 긍정 확인응답이 손실된다면

1. 타임아웃이 발생한다.
2. 호스트 A는 같은 세그먼트를 B에게 재전송한다.
3. 호스트 B의 TCP는 재송신된 세그먼트의 바이트를 버린다.

호스트 A가 연속해서 두 세그먼트를 전송한다.

호스트 A에서 타임아웃 이전에 어떠한 긍정 확인응답도 수신하지 못한다고 가정하자.

타임아웃 이벤트가 발생하면

1. 호스트 A는 순서 번호 92로 첫 번째 세그먼트를 재전송한다.
2. 타이머를 다시 시작한다.
3. 새로운 타임아웃 이전에 두 번째 세그먼트에 대한 ACK가 도착하는 한, 두 번째 세그먼트는 재전송을 하지 않을 것이다.

호스트 A가 연속해서 두 세그먼트를 전송한다.

첫 번째 세그먼트의 긍정 확인응답이 네트워크에서 분실되었지만,
첫 번째 세그먼트의 타임아웃 전에 호스트 A가 긍정 응답번호 120의 긍정 확인응답을 수신하면

• 호스트 A는 호스트 B가 119바이트까지 모든 데이터를 수신했음을 알게 된다.
• 그러므로 호스트 A는 두 세그먼트 중 어느 것도 재전송하지 않는다.

💡 TCP 확인응답은 누적되고 올바르게 수신되지만, 순서가 잘못된 세그먼트는 수신자가 개별적으로 ACK를 받지 않는다.

TCP 송신자는 전송했지만 확인응답 안 된 바이트의 가장 작은 순서 번호, SendBase와 전송될 다음 바이트의 순서 번호, NextSeqNum을 유지해야 한다.

이런 관점에서 TCP는 GBN 형태의 프로토콜과 비슷해보이나, ’TCP에서는 올바르게 수신되었지만 순서가 바뀐 세그먼트들을 버퍼링한다’는 차이점이 존재한다.

e.g.,
패킷 n < N에 대한 긍정 확인응답이 손실되었지만,
나머지 N-1개의 긍정 확인 응답들은 타임아웃 전에 송신 측에 도달했다고 가정한다.

1. GBN : 패킷 n뿐만 아니라, 연속적인 패킷 n+1, n+2, … , N 모두를 재전송한다.
2. TCP
   1. 세그먼트 n 하나만을 재전송
   2. 세그먼트 n에 대한 타임아웃 전에 세그먼트 n+1에 대한 긍정 확인 응답이 도착한다면 세그먼트를 재전송하지 않는다.

💡 TCP에서 수정제안된 선택적 확인응답(selective acknowledgment) : TCP 수신자가 마지막으로 올바로 수신된 ‘순서가 맞는’ 세그먼트에 대해 누적 확인응답을 하기보다는
‘순서가 틀린’ 세그먼트에 대해 선택적으로 확인응답을 하게 한다.

이를 선택적 재전송과 결합했을 경우, SR 프로토콜과 매우 유사하다.

따라서 TCP의 오류 복구 메커니즘은 GBN과 SR 프로토콜의 혼합으로 분류하는 것이 적당하다.

타임아웃이 유발하는 재전송의 문제 : 타임아웃의 주기가 때때로 비교적 길다.

긴 타임아웃 주기는 종단 간의 지연을 증가시키지만,
다행히도 송신자는 종종 중복 ACK에 의한 타임아웃이 일어나기 전에 패킷 손실을 발견한다.

💡 중복 ACK(duplicate ACK) : 송신자가 이미 이전에 받은 확인응답에 대한 재확인응답 세그먼트 ACK

TCP는 부정 확인응답을 사용하지 않으므로, 수신자는 송신자에게 부정 확인 응답을 보낼 수 없다.

1. TCP 수신자가 기다리는 다음 것보다 더 큰 순서 번호를 가진 세그먼트를 받았을 때, TCP 수신자는 손실 세그먼트를 찾아낼 것이다.
2. 수신자는 마지막으로 수신된 순차적인 바이트를 갖는 데이터를 그냥 다시 확인응답한다.
   즉, 중복 ACK를 생성한다.

이벤트 1️⃣
기다리는 순서 번호를 가진 ‘순서가 맞는’ 세그먼트의 도착
기다리는 순서 번호까지의 모든 데이터는 이미 확인응답된다.

TCP 수신자 동작 : 지연된 ACK

1. 또 다른 ‘순서가 맞는’ 세그먼트의 도착을 위해 500 ms까지 기다린다.
2. 만약 다음 ‘순서에 맞는’ 세그먼트가 이 기간에 도착하지 않으면, 그냥 ACK를 보낸다.

이벤트 2️⃣
기다리는 순서 번호를 가진 ‘순서가 맞는’ 세그먼트의 도착
ACK 전송을 기다리는 다른 하나의 ‘순서에 맞는’ 세그먼트가 있다.

TCP 수신자 동작 : 2개의 ‘순서가 맞는’ 세그먼트들을 ACK하기 위해, 하나의 누적된 ACK를 즉시 보낸다.

이벤트 3️⃣
기다리는 것보다 높은 순서 번호를 가진 ‘순서가 바뀐’ 세그먼트의 도착 격자가 발견된다.

TCP 수신자 동작 : 순서 번호가 다음의 기다리는 바이트(즉, 격차의 최솟값)를 나타내는 중복 ACK를 즉시 보낸다.

이벤트 4️⃣
수신 데이터에서 격차를 부분적으로 또는 모두 채우는 세그먼트의 도착

TCP 수신자 동작 : 그 세그먼트가 격차의 최솟값에서 시작한다고 하면, 즉시 ACK를 보낸다.

만약 TCP 송신자가 같은 데이터에 대해 3개의 중복 확인응답을 수신한다면,
이것은 ACK된 세그먼트의 다음 3개의 세그먼트가 분실되었음을 의미한다.

💡 3개의 중복 ACK를 수신할 때, TCP는 세그먼트의 타이머가 만료되기 이전에 손실 세그먼트를 재전송한다.

아래 그림을 보면 두 번째 세그먼트를 잃어버린 경우, 타이머가 만료되기 전에 재전송되었다.

💡 TCP는 송신자가 수신자의 버퍼를 오버플로시키는 것을 방지하기 위해 애플리케이션에게 흐름 제어 서비스(flow-control service)를 제공한다.

→ 수신하는 애플리케이션이 읽는 속도와 송신자가 전송하는 속도를 같게 한다.

TCP 송신자는 IP 네트워크에서 혼잡 때문에 억제될 수도 있다. = 혼잡 제어(congestion control)

흐름 제어와 혼잡 제어는 명백히 각기 다른 목적으로 수행된다. (잘 구별하여야 함)

💡 TCP는 수신 윈도(receive window)라는 변수를 유지하여 흐름 제어를 제공한다.

• 수신 측에서 가용한 버퍼 공간이 얼마나 되는지를 송신자에게 알려주는데 사용된다.
• TCP는 전이중(full-duplex)이므로 연결의 각 측의 송신자는 별개의 수신 윈도를 유지한다.

e.g., TCP 연결상에서 호스트 A가 호스트 B에게 큰 파일을 전송한다고 가정

1. 호스트 B는 이 연결에 수신 버퍼를 할당한다.
   (이때 할당된 수신 버퍼의 크기 : RcvBuffer)
2. 호스트 B의 애플리케이션 프로세스는 버퍼로부터 데이터를 읽으며 다음과 같은 변수들을 정의한다.
   • LastByteRead : 호스트 B의 애플리케이션 프로세스에 의해 버퍼로부터 읽힌 데이터 스트림의 마지막 바이트 번호
     • LastByteRcvd : 호스트 B에서 네트워크로부터 도착하여 수신 버퍼에 저장된 데이터 스트림의 마지막 바이트 번호
     • rwnd
     • 수신 윈도 = 버퍼의 여유 공간
     • 시간에 따라 여유 공간은 변하므로 이 변수는 동적이다.

LastByteRcvd - LastByteRead ≤ RcvBuffer

rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]

1. 호스트 B는 호스트 B가 호스트 A에게 전송하는 모든 세그먼트의 윈도 필드에 현재 rwnd 값을 설정한다.
2. 이를 통해 호스트 A에게 연결 버퍼에 얼마만큼의 여유 공간이 있는지를 알려준다.
3. 호스트 A는 두 변수 LastByteSent와 LastByteAcked를 유지한다.
4. LastByteSent - LastByteAcked = 호스트 A가 이 연결에 전송 확인응답이 안 된 데이터의 양

💡 rwnd의 값보다 작은 확인응답 안 된 데이터의 양을 유지함으로써 호스트 A는 호스트 B의 수신 버퍼에 오버플로가 발생하지 않는다는 것을 확신한다.

호스트 A는 연결된 동안 다음의 내용을 보장한다.

LastBySent - LastByteAcked ≤ rwnd

1. 호스트 B의 수신 버퍼는 rwnd = 0으로서 가득 찼고
2. 호스트 A에게 rwnd = 0이라고 알린 후 호스트 B는 호스트 A에게 전송할 것이 없는 경우

호스트 B에서의 애플리케이션 프로세스가 버퍼를 비우더라도,
TCP는 호스트 A에게 새로운 rwnd로 새로운 세그먼트를 전송하지 않는다.

즉, TCP는 전송할 데이터가 있거나, 전송해야 할 확인응답을 가진 경우에만 호스트 A에게 세그먼트를 전송할 것이다.

→ 호스트 A는 차단되고 더는 데이터를 전송할 수 없다.

따라서 TCP 명세서는 호스트 A가 호스트 B의 수신 윈도가 0일 때, 1바이트 데이터로 세그먼트를 계속해서 전송하도록 요구한다.

TCP 연결이 어떻게 설정되고 해제되는가?

하나의 호스트(클라이언트)에서 운영되는 프로세스가 다른 호스트(서버) 안의 또 다른 프로세스와 연결을 시작하길 원한다고 가정하자.

1. 클라이언트 애플리케이션 프로세스는 서버에 있는 프로세스와 연결 설정하기를 원한다는 것을 클라이언트 TCP에게 알린다.
2. 클라이언트 안의 TCP는 다음과 같은 방법으로 TCP를 이용해 서버와 TCP 연결 설정을 시작한다.

1. 클라이언트 측 TCP는 서버 TCP에게 특별한 TCP 세그먼트, SYN 세그먼트를 송신한다.
   • 애플리케이션 계층 데이터를 포함하지 않는다.
   • 세그먼트 헤더에 SYN 비트를 1로 설정한다.
2. 클라이언트는 최소 순서 번호(client_isn)를 임의로 선택하고, 최초의 TCP SYN 세그먼트의 순서 번호 필드에 이 번호를 넣는다.
3. 이 세그먼트는 IP 데이터그램 안에서 캡슐화되고 서버로 송신된다.

TCP SYN 세그먼트를 포함하는 IP 데이터그램이 서버 호스트에 도착하면,

1. 서버는 데이터그램으로부터 TCP SYN 세그먼트를 추출한다.
2. 연결에 TCP 버퍼와 변수를 할당한다.
3. 클라이언트 TCP로 연결 승인 세그먼트, SYNACK 세그먼트를 송신한다.
   • 애플리케이션 계층 데이터를 포함하지 않는다.
   • SYN 비트는 1로 설정된다.
   • TCP 세그먼트 헤더의 확인응답 필드는 client_isn+1로 설정된다.
   • 서버는 자신의 최초의 순서 번호(server_isn)를 선택하고, TCP 세그먼트 헤더의 순서 번호 필드에 이 값을 넣는다.

연결 승인 세그먼트를 수신하면,

1. 클라이언트는 연결에 버퍼와 변수를 할당한다.
2. 클라이언트 호스트는 서버로 또 다른 세그먼트를 송신한다.
   1. 클라이언트는 TCP 세그먼트 헤더의 확인응답 필드 안에 server_isn+1 값을 넣어, 서버의 연결 승인 세그먼트를 확인한다.
   2. 연결이 설정되었기 때문에 SYN 비트는 0으로 설정된다.

세 번째 단계는 클라이언트에서 서버로의 데이터를 세그먼트 페이로드에서 운반할 수 있다.

위의 세 단계가 완료되면,

• 클라이언트와 서버 호스트들은 각각 서로에게 데이터를 포함하는 세그먼트를 보낼 수 있다.
• SYN 비트는 0으로 설정된다.

TCP 연결에 참여하는 두 프로세스 중 하나가 연결을 끊을 수 있다.

연결이 끝날 때, 호스트의 ‘자원’(버퍼와 변수)는 회수된다.

1. 클라이언트 애플리케이션 프로세스는 종료 명령을 내린다.
2. 이는 클라이언트 TCP가 서버 프로세스에게 특별한 TCP 세그먼트를 보내도록 한다.
   (FIN 비트를 1로 설정)
3. 서버가 이 세그먼트를 수신하면, 서버는 클라이언트에게 확인응답 세그먼트를 보낸다.
4. 그 다음에 FIN 비트가 1로 설정된 자신의 종료 세그먼트를 송신한다.
5. 마지막으로 클라이언트는 서버의 종료 세그먼트에 확인응답을 한다.
6. 이 시점에서 두 호스트의 모든 자원은 할당이 해제된다.

TCP 연결이 존재하는 동안 각 호스트에서 동작하는 TCP 프로토콜은 다양한 TCP 상태를 두루 전이한다.

아래의 두 그림은 클라이언트가 연결 해제를 시작한다는 것을 가정한다.

1. 서버는 수신된 SYN에 대한 응답으로 연결 변수와 버퍼를 할당하고 초기화한다.
2. 그 다음, 서버는 응답으로 SYNACK을 보내고 클라이언트의 ACK 세그먼트를 기다린다.

클라이언트가 이 세 방향 핸드셰이크의 세 번째 단계를 완료하기 위한 ACK를 보내지 않으면
결국(종종 1분 이상 후에) 서버가 절반만 열린 연결을 종료하고 할당된 자원을 회수한다.

→ 이는 SYN 플러드 공격의 무대가 된다.

고전적인 서비스 거부(Denial of Service, DoS) 공격

1. 공격자는 핸드셰이크의 세 버너째 단계를 완료하지 않은 상태에서 무수한 TCP SYN 세그먼트를 보낸다.
2. 서버의 연결 자원이 반쪽 연결에 할당된다.
3. 결국 서버의 연결 자원이 소진됨에 따라 합법적인 클라이언트들이 서비스 거부가 된다.

이는 SYN 플러드 공격에 대한 방어책으로, 현재 대부분의 운영체제에 존재하고 있다.

1. 서버는 SYN에 대해 반만 열린(half-open) TCP 연결을 만들지 않고, 초기 TCP 순서 번호(쿠키, cookie)를 만든다.
   • 서버가 SYN 세그먼트를 받을 때, 그 세그먼트가 정당한 사용자로부터 또는 공격자로부터 온 것인지 구별할 수 없기 때문이다.
   • 해시 함수에 아래의 항목들을 사용하여 쿠키를 생성한다.
     • 비밀번호
     • SYN 세그먼트의 출발지와 목적지 IP 주소들과 포트번호
2. 서버는 이 특별한 초기 순서 번호를 가진 SYNACK 패킷을 보낸다.
3. 💡 서버는 SYN에 관련된 쿠키나 어떤 다른 상태 정보를 기억하지 않는다.
4. 합법적인 클라이언트는 ACK 세그먼트를 회신한다.
5. 이 ACK를 받은 서버는 ACK가 이전에 보낸 일부 SYN에 관한 것인지 확인해야 한다.
   • 이는 이전에 보낸 일부 SYN에 관한 것인지는 쿠키를 통해 확인한다.
   • 서버는 SYNACK에 있는 출발지와 목적지 IP 주소와 포트번호, 비밀번호를 사용해서 동일한 해시 함수를 실행한다.

만약 함수의 결과에 1을 더한 것이 클라이언트의 SYNACK에 있는 확인응답 번호(쿠키)와 같다면
서버는 ACK가 초기 SYN 세그먼트에 관련된 것, 즉 올바른 것이라고 결론짓는다.

→ 이후 서버는 소켓을 가지고 완전하게 열린 연결을 만든다.

만약 클라이언트가 ACK 세그먼트를 회신하지 않으면
서버가 처음의 가짜 SYN에 대해 어떤 자원도 할당하지 않았기 때문에 처음의 SYN은 서버에 해를 끼치지 못한다.

트랜스포트 계층 프로토콜은 각기 다른 호스트에서 동작하는 애플리케이션 프로세스 간의 논리적 통신(logical communication)을 제공한다.

= 애플리케이션의 관점에서 보면, 프로세스들이 동작하는 호스트들이 직접 연결된 것처럼 보인다.

아래 그림처럼, 트랜스포트 계층 프로토콜은 네트워크 라우터가 아닌 종단 시스템에서 구현된다.

1. 송신 측의 트랜스포트 계층은 송신 애플리케이션 프로세스로부터 수신한 메시지를 트랜스포트 계층 패킷으로 변환한다.
   (이는 트랜스포트 계층 세그먼트(segment)라고 부른다. : L4-PDU)
   1. 애플리케이션 메시지를 작은 조각으로 분할한다.
   2. 각각의 조각에 트랜스포트 계층 헤더를 추가한다.
2. 트랜스포트 계층은 송신 종단 시스템에 있는 네트워크 계층으로 세그먼트를 전달한다.
   • 세그먼트는 네트워크 계층 패킷(데이터그램(datagram) : L3-PDU) 안에 캡슐화되어(encapsulate) 목적지로 전달된다.
   네트워크 라우터는 오로지 데이터그램의 네트워크 계층 필드에 대해 동작한다.
   즉, 데이터그램 안에 캡슐화된 트랜스포트 계층 세그먼트의 필드를 검사하지 않는다.
3. 수신 측에서 네트워크 계층은 데이터그램으로부터 트랜스포트 계층 세그먼트를 추출하고 트랜스포트 계층으로 세그먼트를 보낸다.
4. 트랜스포트 계층은 수신 애플리케이션에서 세그먼트 내부의 데이터를 이용할 수 있도록 수신된 세그먼트를 처리한다.

네트워크 애플리케이션에서는 하나 이상의 트랜스포트 계층 프로토콜을 사용할 수 있다.

e.g., 인터넷 : TDP, UDP라는 두 가지 프로토콜을 가지고 있다.

💡 트랜스포트 계층 프로토콜은 각기 다른 호스트에서 동작하는 프로세스들 사이의 논리적 통신을 제공한다.

💡 네트워크 계층 프로토콜은 호스트들 사이의 논리적 통신을 제공한다.

• 트랜스포트 계층 프로토콜은 종단 시스템에 존재하며,
  애플리케이션 프로세스에서 네트워크 계층 사이에서 메시지를 운반하는 역할을 한다.
• 메시지가 네트워크 계층 내부에서 어떻게 이동하는지는 언급하지 않는다.
  즉, Application을 다루는(작성하거나 run 하는) 입장에서는 앞으로 이루어질 physical connection을 염려하지 않아도 된다.

1. 트랜스포트 계층이 제공할 수 있는 서비스는 하위 네트워크 계층 프로토콜의 서비스 모델에 의해 제약받는다.
2. e.g.,
   네트워크 계층 프로토콜이 호스트 사이에서 전송되는 트랜스포트 계층 세그먼트에 대한 지연 보장이나 대역폭 보장을 제공할 수 없다면,
   트랜스포트 계층 프로토콜은 프로세스끼리 전송하는 메시지에 대한 지연 보장이나 대역폭 보장을 제공할 수 없다.

1. 하위 네트워크 프로토콜이 상응하는 서비스를 제공하지 못할 때도, 특정 서비스는 트랜스포트 프로토콜에 의해 제공될 수 있다.
2. e.g.,
   하위 네트워크 프로토콜이 비신뢰적일 때, 트랜스포트 계층이 애플리케이션에게 신뢰적인 데이터 전송 서비스를 제공할 수 있다.
   (비신뢰적이다 = 패킷을 분실하거나, 손상시키거나, 복사본을 만든다)

• 신뢰적이고 연결지향형 서비스를 제공한다. (reliable data transfer)
• 혼잡 제어(congestion control) : 혼잡한 네트워크 링크에서 각 TCP 연결이 링크의 대역폭을 공평하게 공유하여 통과하도록 해준다.

• 비신뢰적이고 비연결형인 서비스를 제공한다.
• UDP 트랜스포트 프로토콜을 사용하는 애플리케이션은 허용이 되는 한, 그것이 만족하는 어떤 속도로든 전송할 수 있다.

• 세그먼트(segment) : 트랜스포트 계층 패킷을 일컫는 말
• TCP에 대한 패킷을 세그먼트(segment), UDP에 대한 패킷을 데이터그램(datagram)이라는 용어로 나타내기도 한다.

이 책에서는 TCP와 UDP 패킷을 모두 세그먼트라고 지칭, 네트워크 계층 패킷에 대해서는 데이터그램이라는 용어를 사용한다.

인터넷의 네트워크 계층 프로토콜

IP 서비스 모델은 호스트들 간에 논리적 통신을 제공하는 최선형 전달 서비스(best-effort delivery service)

즉, IP가 통신하는 호스트들 간에 세그먼트를 전달하기 위해 최대한 노력하지만, 어떤 보장도 하지 않는다.

• 세그먼트의 전달 보장 X
• 순서 보장 X
• 내부 데이터의 무결성(integrity) 보장 X

→ IP는 비신뢰적인 서비스(unreliable service)이다.

💡 각 호스트는 적어도 하나의 IP 주소를 갖고 있다.

‘호스트 대 호스트 전달’ → ‘프로세스 대 프로세스 전달’

종단 시스템 사이의 IP 전달 서비스를 / 종단 시스템에서 동작하는 두 프로세스 간의 전달 서비스로 확장한다.

이로써 무결성 검사를 제공한다.

💡 트랜스포트 계층 다중화(multiplexing)와 역다중화(demultiplexing)
네트워크 계층이 제공하는 호스트 대 호스트 전달 서비스에서
호스트에서 동작하는 애플리케이션에 대한 프로세스 대 프로세스 전달 서비스로 확장하는 과정

1. 목적지 호스트에서의 트랜스포트 계층은 바로 아래의 네트워크 계층으로부터 세그먼트를 수신한다.트랜스포트 계층은 호스트에서 동작하는 해당 애플리케이션 프로세스에게 이 세그먼트의 데이터를 전달하는 의무를 가진다.

1. 트랜스포트 계층은 세그먼트(데이터)를 중간 매개자인 소켓(socket)에게 전달한다.
   • 프로세스는 네트워크 애플리케이션의 한 부분으로서 소켓을 가지고 있다.
   • 이는 네트워크에서 프로세스로, 한 프로세스로부터 네트워크로 데이터를 전달하는 출입구 역할을 한다.
   • 각각의 소켓은 하나의 유일한 식별자, 포트 번호(port number)를 가진다.

Q. 수신한 트랜스포트 계층 세그먼트는 어떻게 적절한 소켓으로 향하는가?

각각의 트랜스포트 계층 세그먼트는 세그먼트에 필드 집합을 가지고 있으며,
트랜스포트 계층은 수신 소켓을 식별하기 위해 이러한 필드를 검사한 후 해당 소켓으로 보낸다.

트랜스포트 계층 세그먼트의 데이터를 올바른 소켓으로 전달하는 작업을 말한다.

1. 출발지 호스트에서 소켓으로 부터 데이터를 모으고,
2. 이에 대한 세그먼트를 생성하기 위해 각 데이터에 헤더 정보로 캡슐화(encapsulation) 한다.
3. 그 세그먼트들을 네트워크 계층으로 전달한다.

1. 소켓은 유일한 식별자를 갖는다. (= 포트 번호)
2. 각 세그먼트는 세그먼트가 전달될 적절한 소켓을 가리키는 특별한 필드를 갖는다.
   • 출발지 포트 번호 필드(source port number field)
   • 목적지 포트 번호 필드(destination port number field)
   
   

   

1. 호스트의 각 소켓은 포트 번호를 할당받는다.
2. 세그먼트가 호스트에 도착하면,
   1. 트랜스포트 계층은 세그먼트 안의 목적지 포트 번호를 검사하고,
   2. 그에 상응하는 소켓으로 세그먼트를 보낸다.
3. 세그먼트의 데이터는 소켓을 통해 해당되는 프로세스로 전달된다.

이는 UDP의 기본적인 동작 방식과 같다.

💡 UDP 소켓은 목적지 IP 주소와 목적지 포트 번호로 구성된 두 요소로 된 집합에 의해 식별된다.

따라서 만약 2개의 UDP 세그먼트가 같은 목적지 IP 주소와 목적지 포트 번호를 가진다면,
이 2개의 세그먼트는 같은 목적지 소켓을 통해 같은 프로세스로 향할 것이다.

그렇다면 출발지 포트 번호는 무슨 목적으로 사용되는가?

출발지 포트 번호는 ‘회신 주소’의 한 부분으로 사용된다.

아래 그림처럼, B가 A에게로 세그먼트를 보내기를 원할 때
B에서 A로 가는 세그먼트의 목적지 포트 번호는 A로부터 B로 가는 세그먼트의 출발지 포트 번호로부터 가져온다.

💡 TCP 소켓은 4개 요소의 집합(four-tuple)에 의해 식별된다.

• 출발지 IP 주소
• 출발지 포트 번호
• 목적지 IP 주소
• 목적지 포트 번호

특히, 다른 출발지 IP 주소 또는 다른 출발지 포트 번호를 가지고 도착하는 2개의 TCP 세그먼트는 2개의 다른 소켓으로 향하게 된다.
(초기 연결 설정 요청을 전달하는 TCP는 제외)

1. TCP 서버 애플리케이션은 환영(welcome) 소켓을 갖고 있다.
   이 소켓은 포트 번호 12000을 가진 TCP 클라이언트로부터 연결 설정 요청을 기다린다. (아래 그림 참고)
   

   

   
   
   
2. TCP 클라이언트는 소켓을 생성하고, 연결 설정 요청 세그먼트를 보낸다.
   • 연결 설정 요청은 목적지 포트 번호 12000과 TCP 헤더에 설정된 특별한 연결 설정 비트(3.5절에서 설명)를 가진 TCP 세그먼트를 통해 보내진다.
   • 이 세그먼트는 출발지 포트 번호를 포함하는데, 이것은 클라이언트가 선택한 번호이다.
3. 서버 프로세스로 동작하는 컴퓨터의 호스트 운영체제가 목적지 포트 12000을 포함하는 연결 요청 세그먼트를 수신하면,
   이 세그먼트를 포트 번호 12000으로 연결 수락을 기다리는 서버 프로세스로 보낸다.
4. 서버는 연결 요청 세그먼트의 4개 요소의 집합에 주목한다.
   • 새롭게 생성된 연결 소켓은 4개 요소의 집합의 네 가지 값에 의해 식별된다.
   • 따라서 그다음에 도착하는 세그먼트의 출발지 포트, 출발지 IP 주소, 목적지 포트, 목적지 IP 주소가 전부 일치하면,
     그 세그먼트는 이 소켓으로 역다중화될 것이다.
5. 서버 호스트는 동시에 존재하는 많은 TCP 소켓을 지원할 수 있다.

💡 서버는 각기 다른 클라이언트가 보낸 세그먼트를 출발지 IP 주소와 출발지 포트 번호로 구별한다.

같은 웹 서버 애플리케이션과 통신하기 위해 같은 목적지 포트 번호(80)를 이용하는 두 클라이언트에 대한 예시를 보자.

• 호스트 C가 서버 B로 2개의 HTTP 세션을 시작
• 호스트 A가 서버 B로 하나의 HTTP 세션을 시작

호스트 A, 호스트 C, 서버 B는 각자 유일한 IP 주소인 A, C, B를 각각 가지고 있다.

• 호스트 C는 2개의 출발지 포트 번호(26145, 7532)를 자신의 HTTP 연결에 할당한다.
• 호스트 A는 호스트 C와 독립적으로 출발지 포트 번호를 선택하므로, 이것 또한 HTTP 연결에 출발지 포트로 26145를 할당할 수 있다.

이렇게 하더라도, 2개의 연결은 다른 출발지 IP 주소를 가지기 때문에 서버 B는 여전히 올바르게 역다중화할 수 있다.

웹 서버는 각각의 연결에 따라서 새로운 프로세스를 만든다.

이들 프로세스는 각자 연결 소켓을 가지며, 이 연결 소켓을 통해 HTTP 요청을 수신하고, HTTP 응답을 전송한다.

그러나 연결 소켓과 프로세스 사이에 항상 일대일 대응이 이루어지는 것이 아니다.

• 오늘날의 많은 고성능 웹 서버는 하나의 프로세스만 사용한다.
• 각각의 새로운 클라이언트 연결을 위해 새로운 연결 소켓과 함께 새로운 스레드(thread)를 생성한다.

지속적인 연결의 존속 기간에 클라이언트와 서버는 같은 서버 소켓을 통해 HTTP 메시지를 교환한다.

모든 요청/응답마다 새로운 TCP 연결이 생성되고 종료된다.

💡 UDP는 트랜스포트 계층 프로토콜이 할 수 있는 최소 기능으로 동작한다.

• 다중화/역다중화 기능
• 간단한 오류 검사 기능

이외에는 IP에 아무것도 추가하지 않는다.

1. 애플리케이션 프로세스로부터 메시지를 가져와서
   다중화/역다중화 서비스에 필요한 출발지 포트 번호 필드와 목적지 포트 번호 필드를 첨부한다.
2. 출발지 호스트의 IP 주소 필드, 목적지 호스트의 IP 주소 필드를 추가한 후에
   최종 트랜스포트 계층 세그먼트를 네트워크 계층으로 넘겨준다.
3. 네트워크 계층은 트랜스포트 계층 세그먼트를 IP 데이터그램으로 캡슐화하고,
   세그먼트를 수신 호스트에게 전달한다.
4. 세그먼트가 수신 호스트에 도착한다면,
   UDP는 세그먼트의 데이터를 해당하는 애플리케이션 프로세스로 전달하기 위해 목적지 포트 번호를 사용한다.

💡 UDP는 세그먼트를 송신하기 전에 송신 트랜스포트 계층 개체들과 수신 트랜스포트 계층 개체들 사이에 핸드셰이크를 사용하지 않는다.

→ 비연결형

DNS는 전형적으로 UDP를 사용하는 애플리케이션 계층 프로토콜의 예이다.

만약 질의 호스트가 응답을 수신하지 못하면 질의를 다른 네임 서버로 송신하거나, 애플리케이션에게 응답을 수신할 수 없음을 통보한다.

많은 애플리케이션은 다음과 같은 이유로 UDP에 더 적합하다.

UDP 하에서 애플리케이션 프로세스가 데이터를 UDP에 전달하자마자
UDP는 데이터를 UDP 세그먼트로 만들고, 그 세그먼트를 즉시 네트워크 계층으로 전달한다.

실시간 애플리케이션에서는 UDP를 사용하고, 필요한 어떤 추가 기능을 구현할 수 있다.

↔︎ TCP

1. 혼잡 제어 매커니즘이 존재한다.
   즉, 목적지 호스트들과 출발지 호스트들 사이에서 하나 이상의 링크가 과도하게 혼잡해지면 트랜스포트 계층 TCP 송신자를 제한한다.
2. 신뢰적인 전달이 얼마나 오래 걸리는지에 관계없이
   목적지가 세그먼트의 수신 여부를 확인응답할 때까지 데이터의 세그먼트 재전송을 계속한다.

UDP는 TCP의 세 방향 핸드셰이크(three-way handshake)와 같은 공식적인 사전준비 없이 전송한다.

따라서 UDP는 연결을 설정하기 위한 어떤 지연도 없다.

UDP는 연결 상태를 유지하지 않으며, 연결 상태에 대한 그 어떠한 파라미터도 기록하지 않는다.

따라서 일반적으로 특정 애플리케이션 전용 서버는 애플리케이션 프로그램이 UDP에서 동작할 때
좀 더 많은 액티브 클라이언트를 수용할 수 있다.

TCP는 세그먼트마다 20바이트의 헤더 오버헤드를 갖지만, UDP는 단지 8바이트의 오버헤드를 갖는다.

UDP는 혼잡 제어(congestion control)를 하지 않는다.

💡 혼잡 제어는 네트워크가 꼭 필요한 작업을 할 수 없게 되는 폭주 상태에 빠지는 것을 막기 위해 반드시 필요하다.

만약 모두가 혼잡 제어를 사용하지 않고 높은 비트의 비디오 스트리밍을 시작한다면,

• 라우터에 많은 패킷 오버플로가 발생
  → 소수의 UDP 패킷만이 출발지-목적지 간의 경로를 무사히 통과할 것이다.
• 제어되지 않은 UDP 송신자에 의해 발생한 높은 손실률은 그 손실률을 감소시키기 위해 TCP 송신자들이 속도를 줄이도록 할 것
  → TCP 세션의 혼잡이 발생할 것이다.

UDP는 비신뢰적인 서비스를 제공하지만,
애플리케이션 자체에서 신뢰성을 제공한다면 UDP를 사용하면서 신뢰적인 데이터 전송이 가능해진다.

e.g., 구글의 크롬 브라우저에서 사용되는 QUIC(Quick UDP Internet Connection) 프로토콜

이는 기본 트랜스포트 프로토콜로 UDP를 사용하고, UDP 위에 애플리케이션 계층 프로토콜의 안정성을 구현한다.

UDP 데이터그램의 데이터 필드에 위치한다.

목적지 호스트가 목적지 종단 시스템에서 동작하는 (역다중화 기능을 수행하는) 정확한 프로세스에게 애플리케이션 데이터를 넘기게 해준다.

세그먼트에 오류가 발생했는지 검사하기 위해 수신 호스트가 사용한다.

헤더를 포함하는 UDP 세그먼트의 길이를 바이트 단위로 나타낸다.

UDP 체크섬은 세그먼트가 출발지로부터 목적지로 이동했을 때,
UDP 세그먼트 안의 비트에 대한 변경사항이 있는지 검사하여 오류 검출을 하기 위한 것이다.

1. 송신자 측에서 세그먼트 안에 있는 모든 16비트 워드의 합산에 대해 다시 1의 보수를 수행하며,
   합산 과정에 발생하는 오버플로는 윤회식 자리올림(wrap around)을 한다.
2. 이 결과값이 UDP 세그먼트의 체크섬 필드에 삽입된다.
3. 수신자에서는 체크섬을 포함한 모든 16비트 워드들이 더해진다.
4. 만약 패킷에 어떤 오류도 없다면 수신자에서의 합은 1111111111111111이 되며,
   비트 중에 0이 하나라도 있다면 패킷에 오류가 발생했다는 것이다.

출발지와 목적지 사이의 모든 링크가 오류 검사를 제공한다는 보장이 없기 때문이다.

따라서 세그먼트들이 정확하게 링크를 통해 전송되었을지라도, 세그먼트가 라우터의 메모리에 저장될 때 비트 오류가 발생할 수가 있다.

💡 UDP는 오류 검사를 제공하지만, 오류를 회복하기 위한 어떤 일도 하지 않는다.

손상된 세그먼트를 그냥 버리기도 하고, 경고와 함께 손상된 세그먼트를 애플리케이션에게 넘겨주기도 한다.
(처리 방식은 구현에 따라서 다름)

주어진 링크 간의 신뢰성과 메모리의 오류 검사가 보장되지도 않고, 종단 간의 데이터 전송 서비스가 오류 검사를 제공해야 한다면
UDP는 종단 기반으로 트랜스포트 계층에서 오류 검사를 제공해야만 한다.

→ 이것은 종단과 종단의 원칙(end-end principle)의 한 예시이다.

하위 레벨에 있는 기능들은 상위 레벨에서 이들을 제공하는 비용과 비교했을 때 중복되거나 거의 가치가 없을 수 있다.

P2P 구조는 항상 켜져있는 인프라스트럭처 서버에 최소한으로 의존하고, 간헐적으로 연결되는 호스트 쌍들(피어, peer)이 서로 직접 통신한다.

• 클라이언트-서버 파일 분배에서 서버는 파일 복사본을 각 클라이언트에게 보내려면 서버에게 커다란 부하를 주고, 많은 양의 서버 대역폭을 소비한다.
• P2P 파일 분배에서 각 피어는 수신한 파일의 임의의 부분을 다른 피어들에게 재분배할 수 있어서 서버의 분배 프로세스를 도울 수 있다.

2020년에 가장 인기 있는 P2P 파일 분배 프로토콜은 비트 토렌트(BitTorrent)다.

서버와 피어들은 접속 링크로 인터넷에 연결되어 있다.

• 서버의 접속 링크 업로드 속도를 u(s)로, i번째 피어의 접속 링크 업로드 속도는 u(i)로,
  그리고 i번째 피어의 접속 링크 다운로드 속도는 d(i)로 나타낸다.
• 또한, 분배되는 파일의 크기는 F bit로, 파일을 얻고자 하는 피어들의 수는 N으로 나타낸다.

분배 시간은 모든 N개의 피어들이 파일의 복사본을 얻는데 걸리는 시간이다.

다음 분배 시간에 대한 분석에서 클라이언트-서버와 P2P 구조 모두의 경우, 인터넷 코어가 풍부한 대역폭을 갖고 있다는 간단한 가정을 하며,
이는 모든 병목 현상은 다른 네트워크 애플리케이션에 참여하지 않아서 이들의 모든 업로드와 다운로드 접속 대역폭은 이 파일 분배에 모두 사용된다고 가정한다.

• 서버는 파일 복사본을 N개의 피어 각각에게 전송해야 한다. 따라서 서버는 NF 비트를 전송해야 한다.
  • 즉, 서버가 파일을 분배하는 시간은 적어도 NF/u(s)이다.
• d(min)이 가장 낮은 다운로드 속도를 가진 피어의 다운로드 속도를 나타낸다고 하자.
  • 가장 낮은 속도를 가진 피어는 F/d(min)초보다 적은 시간에 파일의 모든 F 비트를 얻을 수 없다.
  • 즉 최소 분배 시간은 F/d(min)이다.

즉, 분배 시간을 D(cs)라고 하면 다음과 같은 수식을 얻을 수 있다.

D(cs) ≧ max{ NF/u(s) , F/d(min)} 

위 식에서 충분히 큰 N에 대해 클라이언트-서버 분배 시간은 NF/u(s)로 주어진다는 사실을 알 수 있다. 즉, N에 따라 선형 증가한다.

여기서는 각 피어들이 서버가 파일을 분배하는 데 도움을 줄 수 있다.

특히 한 피어가 파일 데이터 일부를 수신할 때, 피어는 그 데이터를 다른 피어들에게 재분배하는 데 자신의 업로드 용량을 이용할 수 있다.

• 분배가 시작되면 서버만이 파일을 갖고 있다.
  • 이 파일이 피어 커뮤니티에 도달할 수 있도록 하기 위해, 서버는 적어도 한 번 접속 링크로 파일의 각 비트를 보내야 한다.
  • 따라서 최소 분배 시간은 적어도 F/u(s)다.
    (서버가 한 번 보낸 비트는 서버가 다시 보낼 필요가 없는데, 이는 피어들이 그들 사이에서 재분배할 수 있기 때문이다.)
• 클라이언트-서버 구조와 마찬가지로 다운로드 속도가 가장 낮은 피어는 F/d(min)초보다 적은 시간 안에 파일의 모든 F 비트를 얻을 수 없다.
  • 따라서 최소 분배시간은 적어도 F/d(min)이다.
• 마지막으로, 시스템의 전체 업로드 용량은 전체적으로 서버의 업로드 속도와 각 피어들의 속도를 더한 것이다. 이를 u(total)이라 하자.
  • 시스템은 각 피어들 각각에게 F 비트를 전달해야 한다. 이는 u(total)보다 빠르게 할 수 없다.
  • 따라서 최소 분배 시간은 NF/u(total)이다.

즉, 분배시간을 D(p2p)라고 하면 다음과 같은 수식을 얻을 수 있다.

D(p2p) ≧ max {F/u(s) , F/d(min), NF/u(total)}

위 수식들에서 하한값은 서버-클라이언트 구조에서 서버가 전송을 스케줄링 하거나,
P2P 구조에서는 각 피어가 비트를 수신하자마자 그 비트를 재분배할 수 있다고 가정하면(실제로는 chunk가 재분배된다.),
식의 하한값을 최소 분배시간으로 채택할 수 있다.

위 그래프를 통해 임의의 피어 수 N에 대해 클라이언트-서버 구조보다 P2P 구조가 더 시간이 적다는 것을 볼 수 있다.

따라서 P2P 구조를 가진 애플리케이션은 자가 확장성을 갖는다.

비트토렌트(BitTorrent)는 파일 분배를 위한 인기 있는 P2P 프로토콜이다.

비트토렌트 용어로 특정 파일의 분배에 참여하는 모든 피어의 모임을 토렌트(torrent)라고 부른다.

토렌트에 참여하는 피어들은 서로에게서 같은 크기의 청크(chunk)를 다운로드한다. (일반적으로 256KB)

• 처음으로 가입하면 그 피어에는 청크가 없지만, 시간이 지나면 점점 많은 청크를 쌓을 수 있다.
  (accumulate chunks over time from other peers)
• 피어가 청크를 다운로드할 때 또한 청크를 다른 피어들에게 업로드한다.
• 일단 한 피어가 전체 파일을 얻으면 토렌트를 떠나거나, 토렌트에 남아서 다른 피어들로 청크를 계속해서 업로드할 수 있다.

각 토렌트는 트래커(traker)라고 부르는 인프라스트럭처 노드를 갖고있다.

한 피어가 토렌트에 가입할 때 트래커에 자신을 등록하고 주기적으로 자신이 아직 토렌트에 있음을 알려, 트래커는 토렌트에 있는 피어들을 추적할 수 있다.

위의 그림을 예시로 보자.

새로운 피어 앨리스가 토렌트에 가입하면
트래커는 참여하고 있는 피어 집합에서 임의로 피어들의 부분집합(정확히는 50)을 선택하여 이 50개 피어들의 IP 주소를 앨리스에게 보낸다.

이 피어들의 목록을 얻고 나서, 앨리스는 이 목록에 있는 모든 피어와 동시에 TCP 연결을 맺고,
성공적으로 맺은 피어를 이웃 피어(neighbors)라고 부른다.

The peers fluctuate over time

churn : peers may come and go

시간이 지남에 따라 피어들 중 일부는 떠나고, 다른 피어들이 앨리스와 TCP 연결을 시도하고, 피어의 이웃 피어들은 시간에 따라 변동한다.

requesting chunks: rarest first

어느 임의의 시간 안에 앨리스는 청크의 일부를 가질 것이고, 이웃들이 어느 청크를 가지고 있는지를 알게 될 것이다.

앨리스는 이러한 정보를 바탕으로 다음 2가지 결정을 한다.

1. 이웃으로부터 어느 청크를 먼저 요구할 것인가?
2. 이웃들 중 어느 피어에게 청크를 요청할 것인가?

이때 rarest first(가장 드문 것 먼저) 기술을 사용한다.

갖고 있지 않은 청크 중에서, 이웃 가운데 가장 드문 청크를 결정하고 이를 먼저 요구하는 것이다.

이 방법을 통해 가장 드문 청크들은 더 빨리 재분배될 수 있어서 각 청크의 복사본 수가 대략적으로 동일해질 수 있다.

sending chunks: tit-for-tat

어느 요청에 응답할지 결정할 때 앨리스가 가장 빠른 속도로 그녀에게 데이터를 제공하는 이웃에게 우선순위를 주는 것이다.

• 특히, 계속해서 비트를 수신하는 속도를 측정하고 가장 빠르게 전송하는 4개의 피어를 결정하고, 이 4개의 피어에게 청크를 보냄으로써 보답한다.
• 이는 10초마다 계산하여 집합을 수정한다.

비트 토렌트 용어로 4개의 피어는 활성화되었다(unchoked)고 한다.

40초마다 위 피어를 제외하고 임의의 피어에게 청크를 보낸다.

비트 토렌트 용어로 이 피어는 낙관적으로 활성화되었다(optimistically unchoked)고 한다.

• 즉, 이제 앨리스는 임의의 피어에게 활성화될 수 있고, 활성화가 된다면 임의의 피어도 앨리스에게 활성화될 수 있다.
• 임의의 선택을 통해 고정된 피어들과만 청크를 교역하는 것이 아니라 여러 피어와 교역할 수 있게 된다.

이러한 5개의 피어 외의 모든 이웃 피어는 비활성화되어 어떤 청크도 교역하지 않는다. (choked by Alice = do not receive chunks from her)

비트 토렌트는 여기서 논의하지 않은 여러 기법들도 갖고 있다.

비디오는 이미지의 연속으로서 일반적으로 초당 24개에서 30개의 이미지로 일정한 속도로 표시된다.

압축되지 않은 디지털 인코딩된 이미지는 픽셀 단위로 구성되며, 각 픽셀은 휘도와 색상을 나타내는 여러 비트들로 인코딩된다.

비디오의 중요한 특징은 압축될 수 있다는 것인데, 비디오 품질과 비트 전송률은 서로 반비례한다.

오늘날의 상용 압축 알고리즘은 근본적으로 원하는 모든 비트 전송률로 비디오를 압축할 수 있다. (비트 전송률이 높을수록 이미지 품질이 좋다.)

네트워킹 측면에서 비디오의 가장 두드러진 특성은 높은 비트 전송률이다.

인터넷 비디오는 일반적으로 고화질 동영상을 스트리밍 하기 위해 100 kbps에서 4 Mbps 이상으로 구성된다.

4K 스트리밍은 10 Mbps 이상의 비트 전송률로 예상된다. 이는 하이엔드 동영상의 경우 트래픽과 스토리지 용량이 엄청나게 필요함을 의미한다.

연속 재생을 제공하기 위해, 네트워크는 압축된 비디오의 전송률 이상의 스트리밍 애플리케이션에 대한 평균 처리량을 제공해야 한다.

→ 압축을 사용하여 동일한 비디오를 여러 버전의 품질로 만들 수 있다.

HTTP 스트리밍에서 비디오는 HTTP 서버 내의 특정 URL을 갖는 일반적인 파일로 저장된다.

1. 클라이언트는 서버에게 TCP 연결을 설립하고 해당 URL에 대한 HTTP GET 요청을 발생시킨다.
2. 서버는 기본 네트워크 프로토콜 및 트래픽이 허용되는 대로 HTTP 응답 메시지 내에서 비디오 파일을 전송한다.
3. 애플리케이션 버퍼에 전송된 바이트가 저장된다.
4. 버퍼의 바이트 수가 미리 정해진 임계값을 초과하면 재생을 시작한다.

특히, 버퍼에서 주기적으로 비디오 프레임을 가져와 프레임을 압축 해제한 다음 사용자의 화면에 표시한다.

가용 대역폭이 달라도 똑같이 인코딩된 비디오를 전송 받는다는 문제가 있다.

이 문제로 인한 HTTP 기반 스트리밍인 DASH(Dynamic Adaptive Streaming over HTTP)가 개발되었다.

비디오는 여러가지 버전으로 인코딩 되며, 각 버전은 비트율과 품질 수준이 서로 다르다.

클라이언트는 동적으로 서로 다른 버전의 비디오를 몇 초 분량의 길이를 갖는 비디오 조각 단위로 요청한다.

가용 대역폭이 충분할 때는 높은 비트율의 비디오 버전을 요청하며, 가용 대역폭이 적을 때는 낮은 비트율의 비디오 버전을 요청한다.

즉, 클라이언트는 자신의 상황에 알맞은 비디오 버전을 요청한다.

각 비디오 버전은 HTTP 서버에 서로 다른 URL을 가지고 저장된다.

HTTP 서버는 비트율에 따른 각 버전의 URL을 제공하는 매니페스트(manifest) 파일을 갖고 있다.

클라이언트는 이 매니페스트 파일을 제공받고,
이에 따라 매번 원하는 버전의 비디오 조각 단위를 선택하여 HTTP GET 요청 메시지에 URL과 byte-range를 지정하여 요청한다.

궁극적으로 DASH는 클라이언트가 서로 다른 품질 수준을 자유롭게 변화시킬 수 있도록 허용한다.

단일 거대 데이터 센터를 구축하고 모든 비디오 자료를 데이터 센터에 저장한 뒤, 전 세계의 사용자에게 비디오 스트림을 데이터 센터로부터 직접 전송한다.

1. 클라이언트가 데이터 센터로부터 먼 지점에 있는 경우 다양한 통신 링크와 ISP를 거치게 되고,
   이 링크들 중 하나라도 비디오 소비율 보다 낮은 전송 용량을 갖는 경우 병목현상이 발생한다.
2. 인기 있는 비디오는 같은 통신 링크를 통해 여러 번 반복적으로 전송될 것이다. 동일한 바이트를 전송하는 데에 반복 비용을 지불하게 된다.
3. 한 번의 장애로 전체 서비스가 중단될 수 있다.

이러한 문제를 해결하기 위해 대부분의 비디오 스트리밍 회사들은 콘텐츠 분배 네트워크(CDN)를 이용한다.

CDN은 다수의 지점에 분산된 서버들을 운영하며, 비디오 및 다른 형태의 웹 콘텐츠 데이터의 복사본을 이러한 분산 서버에 저장한다.

사용자는 최적의 사용자 경험을 제공받을 수 있는 지점의 CDN 서버로 연결된다.

CDN은 구글처럼 사설 CDN일 수도 있으며, 제 3자가 운영하는 CDN을 통해 서비스될 수도 있다.

두 개의 철학 중 하나를 채용한다.

• Enter Deep
• Bring Home

push CDN servers deep into many access networks

Akamai에 의해 주창된 것으로서 서버 클러스터를 세계 곳곳의 접속 네트워크에 구축함으로써 ISP의 접속 네트워크로 깊숙이 들어가는 것이다.

즉, 최대한 서버를 사용자 근처에 위치시켜 링크 및 라우터를 거치는 횟수를 줄여 지연시간 및 처리율을 개선하는 것이다.

smaller number (10’s) of larger clusters in POPs near (but not within) access networks

Limelight와 다른 회사들에 의해 적용된 것으로, 좀 더 적은 수의 핵심 지점에 큰 규모의 서버 클러스터를 구축하여 ISP를 Home으로 가져오는 개념이다.

접속 ISP에 연결하는 대신, 일반적으로 CDN들은 그들의 클러스터를 인터넷 교환 지점(IXP)에 배치한다.

이에 따라 Enter Deep보다 처리율(throughput)은 더 낮고 delay가 더 걸릴 수 있지만, 회사의 입장에서는 유지 보수하기에 편하며, 비용이 적게 든다.

CDN은 콘텐츠의 복사본을 이들 클러스터에 저장하는데 모든 복사본을 유지하지는 않는다.

어떤 비디오는 인기가 거의 없거나 특정 국가에서만 인기가 있을 수 있기 때문이다.

실제로 CDN은 클러스터에 대해 사용자의 요청이 오면 중앙 서버나 다른 클러스터로부터 전송받아 사용자에게 서비스하는 동시에 복사본을 만들어 저장하는 pull 방식을 이용한다.

저장 공간이 가득 차게 되면 자주 사용되지 않는 비디오 데이터는 삭제된다.

1. 사용자가 URL을 지정하여 비디오를 요청한다.
2. CDN은 그 요청을 가로채 클라이언트에게 가장 적당한 CDN 클러스터를 선택한다.
3. 클라이언트의 요청을 해당 클러스터의 서버로 연결한다.

요청을 가로챌 때 CDN은 DNS를 활용한다. 이를 DNS redirection이라고 한다.

1. 사용자가 URL을 입력한다.
2. 사용자의 호스트는 URL의 host name에 대한 질의를 로컬 DNS로 보낸다.
3. 로컬 DNS는 host name의 책임 DNS 서버로 질의를 전달한다.
   책임 DNS 서버는 해당 질의를 CDN 서버로 연결하기 위해 CDN 서버의 책임 DNS 서버의 IP를 전달한다.
4. 로컬 DNS는 CDN 서버의 책임 DNS로 질의를 보내고, CDN 콘텐츠 서버의 IP 주소를 로컬 DNS 서버로 응답한다.
   이때 클라이언트가 콘텐츠를 전송받게 될 서버가 결정된다.
5. 로컬 DNS 서버는 사용자 호스트에게 CDN 서버의 IP 주소를 알려준다.
6. 클라이언트는 호스트가 알게된 IP 주소로 HTTP 혹은 DASH 프로토콜을 통해 비디오를 받아온다.

위 CDN이 DNS를 통해 가로채는 과정에서 CDN은 클라이언트의 로컬 DNS 서버의 IP 주소를 알게된다. 이 IP 주소에 기초해 최선의 클러스터를 선택한다.

지리적으로 가장 가까운 클러스터를 할당한다.

사용자 지리정보 데이터베이스를 이용하면 얻은 IP 주소를 지리적으로 매핑할 수 있고, 가장 가까운 클러스터를 선택하는 것이다.

대부분 잘 동작하나, 지리적으로 가까운 클러스터가 네트워크 경로의 길이 홉의 수에 따라 가장 가까운 클러스터가 아닐 수 있고,
가까운 로컬 DNS 서버를 이용하고 있지 않을 수 있기 때문에 잘 동작하지 않을 수 있다.

실시간 측정

클러스터와 클라이언트 간의 지연 및 손실 성능에 대한 주기적인 실시간 측정을 통해 현재 네트워크 상황을 반영하여 최선의 클러스터를 선택하는 것이다.

문제는 많은 로컬 DNS 서버가 이러한 측정에 응답을 하지 않도록 설정되어 있다.

• 콘텐츠 수집 : 영화를 수집하고 처리한다. 영화의 스튜디오 마스터 버전을 받아서 아마존 클라우드 시스템의 호스트에 업로드한다.
• 콘텐츠 처리 : 아마존 클라우드 시스템의 기기에서는 데스크톱 컴퓨터, 스마트폰, TV에 견결된 게임 콘솔 등 고객들의 다양한 플레이어 기기 사양에 적합하도록 각 영화의 여러가지 형식의 비디오를 생성한다. DASH를 이용하여 각 형식별로 다양한 비트율의 여러가지 버전을 생성한다.
• CDN으로 버전 업로드 : 영화의 다양한 버전이 생성되면 아마존 클라우드 시스템의 호스트는 이러한 버전을 CDN으로 업로드할 수 있다.

자체 CDN을 구축하기 위해 넷플릭스는 IXP 및 거주용 ISP 자체에서 서버 랙(rack)을 설치했다.

현재 IXP 위치에 200대 이상의 서버 렉과 서버 랙을 수용하는 수백 개의 ISP 장소도 보유하고 있다.

각각의 랙 서버에는 10 Gbps 이더넷 포트와 100 테라바이트 이상의 스토리지가 있다.

넷플릭스는 푸시 캐싱(push caching)을 사용하여 IXP 및 ISP CDN 서버를 채운다.

전체 라이브러리를 보유할 수 없는 위치의 경우, 매일매일 가장 많이 결정되는 비디오만 푸시한다.

1. 사용자가 재생할 영화를 선택한다.
2. 아마존 클라우드에서 실행 중인 넷플릭스 소프트웨어가 영화 사본을 갖고 있는 CDN 서버를 결정한다.
3. 영화가 있는 서버 중에서 클라이언트 요청에 대한 최적의 서버를 결정한다.
4. 일반적으로 로컬 ISP가 CDN 서버 랙(rack)이 있다면 해당 CDN을 사용하거나, 근처 CDN 서버가 있는 IXP를 사용한다.
5. 클라이언트는 요청된 영화의 다른 버전에 대한 URL을 가진 메니페스트 파일과 특정 서버의 IP 주소를 보낸다.
6. 클라이언트와 해당 CDN 서버는 독점 버전의 DASH를 이용하여 직접 상호작용한다.

넷플릭스는 자체 CDN을 사용하고 있기 때문에 DNS redirection을 사용할 필요가 없다.

대신 아마존 클라우드에서 실행되는 것처럼 넷플릭스 소프트웨어는 클라이언트에게 특정 CDN 서버를 사용하도록 알려준다.

또한 넷플릭스 CDN은 풀 캐싱보다 푸시 캐싱을 사용한다.

콘텐츠는 캐시 미스 중에 동적으로 사용되는 것이 아니라 사용량이 적은 시간 중 예약된 시간에 서버에 푸시한다.

넷플릭스와 마찬가지로 자체 CDN을 사용한다.

구글 역시 사용자를 특정 서버 클러스터와 연결하는 데 DNS를 사용한다.

대부분의 경우 클러스터 선택 정책은 클라이언트와 클러스터간의 RTT가 가장 적은 곳을 선택하는 것이다.

때로는 작업 부하를 위해 더 멀리 있는 CDN을 선택하기도 한다.

유튜브는 HTTP 스트리밍을 채용하여 사용자가 직접 버전을 선택하게 했다.

재생 위치 조정과 조기 종료로 인한 대역폭과 서버 자원의 낭비를 줄이기 위해,
유튜브는 HTTP byte-range 헤더를 이용해 목표한 분량의 선인출 데이터 이후에 추가로 전송되는 데이터 흐름을 제한한다.

네트워크 애플리케이션을 생성할 때는 두 프로그램, 클라이언트와 서버 프로그램을 작성해야 한다.

두 프로그램을 실행하면 프로세스가 생성되고, 두 프로세스가 소켓으로부터 읽고 쓰기를 통해 서로 통신한다.

클라이언트 - 서버 애플리케이션에는 두 가지 형태가 있다.

1️⃣ HTTP 등의 RFC에 정의된 표준 프로토콜을 구현하는 클라이언트-서버 애플리케이션

이 애플리케이션을 구현할 때 그 프로토콜과 연관된 port를 사용하여야 한다.

2️⃣ 개인의 독점적인 네트워크 애플리케이션으로 RFC 또는 다른 곳에 공식적으로 출판되지 않은 애플리케이션 계층 프로토콜을 채택하여 구현하는 애플리케이션

다른 독립 개발자는 이 애플리케이션과 상호작용하는 코드를 개발할 수 없다. 이 애플리케이션을 구현할 때는 잘 알려진 포트번호를 사용하지 않도록 유의해야 한다.

개발자는 TCP, UDP 프로토콜 중 어떤 프로토콜을 사용해야 하는지 각 프로토콜의 특징을 고려하여 선택해야 한다.

UDP를 사용할 때에는 송신 프로세스가 데이터의 패킷을 소켓 문 밖으로 밀어내기 전에, 먼저 패킷에 목적지 주소를 붙여넣어야 한다.

이 패킷이 송신자의 소켓을 통과한 후 인터넷은 이 목적지 주소를 이용하여 그 패킷을 인터넷을 통해 수신 프로세스에 있는 소켓으로 라우트(route)할 것이다.

패킷이 수신 소켓에 도착하면 수신 프로세스는 소켓을 통해 그 패킷을 추출하고, 다음에 패킷의 콘텐츠를 조사하여 적절한 동작을 취한다.

패킷에 목적지 주소를 포함함으로써 인터넷의 라우터는 목적지 호스트로 인터넷을 통해 패킷을 라우트할 수 있다.

호스트는 각자 IP 주소를 식별자로 갖는다.

그러나 호스트는 하나 혹은 그 이상의 소켓을 갖는 많은 네트워크 애플리케이션 프로세스를 수행하고 있을 수 있기 때문에,
목적지 호스트 내의 특정한 소켓을 식별할 필요가 있다.

소켓이 생성될 때 포트 번호라고 하는 프로세스 식별자가 소켓에 할당된다.

즉, 패킷에는 IP 주소와 포트번호로 구성된 목적지 주소가 붙게 되며, 송신자의 출발지 주소(IP와 port)도 붙게 된다.

일반적으로 이렇게 주소를 붙이는 것은 하부 운영체제가 자동으로 실행한다.

위 그림은 UDP 서비스 상에서 통신하는 클라이언트와 서버의 주요 소켓 관련 활동을 나타낸다.

1. 클라이언트는 키보드로부터 한 줄의 문자를 읽고 그 데이터를 서버로 보낸다.
2. 서버는 그 데이터를 수신하고 문자를 대문자로 변환한다.
3. 서버는 수정된 데이터를 클라이언트에게 보낸다.
4. 클라이언트는 수정된 데이터를 수신하고 그 줄을 화면에 나타낸다.

위 순서로 작동하는 간단한 클라이언트-서버 애플리케이션을 만들 예정이다.

소켓을 생성할 때는 따로 소켓의 포트 번호를 명시하지 않아도 되며, 운영체제가 이 작업을 대신 수행한다.

# socket module이다. 이 module을 통해 소켓을 생성할 수 있다.
from socket import *

#서버의 IP 혹은 서버의 호스트 이름을 할당한다.
serverName = ’hostname’

# 목적지 port 번호를 나타낸다.
serverPort = 12000

# 클라이언트 소켓을 생성한다. AF_INET은 IPv4를 사용하고 있음을 나타내고, SOCK_DGRAM은 UDP 소켓임을 의미한다.
clientSocket = socket(AF_INET, SOCK_DGRAM)

# 보낼 메시지를 입력 받는다.
message = Input(’Input lowercase sentence:’)

# 소켓으로 바이트 형태를 보내기 위해 먼저 encode()를 통해 바이트 타입으로 변환한다.
# sendTo() 메서드는 목적지 주소를 메시지에 붙이고 그 패킷을 프로세스 소켓인 clientSocket으로 보낸다.
# 클라이언트 주소도 같이 보내지는데 이는 자동으로 수행된다.
clientSocket.sendto(message.encode(),(serverName, serverPort))

# 패킷 데이터는 modifiedMessage에 저장되고, 패킷의 출발지 주소(IP, port)는 serverAddress에 할당된다.
# recvfrom() 메서드는 2048의 버퍼 크기로 받아들인다. 
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)

# 출력
print(modifiedMessage.decode())

# 소켓 닫기
clientSocket.close()

while 문을 통하여 한 번의 통신 이후에도, 계속 다음 UDP 패킷이 도착하기를 기다린다.

from socket import *

# 포트 번호
serverPort = 12000

# UDP 소켓 생성
serverSocket = socket(AF_INET, SOCK_DGRAM)

# 12000 포트 번호를 소켓에 할당한다. 이를 통해 서버 IP 주소의 12000 포트로 패킷을 보내면 해당 소켓으로 패킷이 전달된다.
serverSocket.bind((’’, serverPort))

print(”The server is ready to receive”)

while True:
    # 패킷이 서버에 도착하면 데이터는 메세지에 할당되고 패킷의 출발지 주소는 clientAddress에 저장된다.
    # 해당 주소로 서버는 응답을 어디에 보내야할지 알 수 있다.
    message, clientAddress = serverSocket.recvfrom(2048)
    
    # 바이트 데이터를 decode()하고 대문자로 변환한다.
    modifiedMessage = message.decode().upper()
    
    # 클라이언트 주소를 대문자로 변환된 메시지에 붙이고, 그 결과로 만들어진 패킷을 서버에 보낸다.
    # 서버의 주소도 같이 보내지는데 이는 자동으로 수행된다.
    serverSocket.sendto(modifiedMessage.encode(), clientAddress) 

TCP는 연결 지향 프로토콜로, 서로 데이터를 보내기 전에 먼저 TCP 연결을 설정할 필요가 있다.

TCP 연결을 생성할 때 클라이언트 소켓 주소와 서버 소켓 주소를 연결과 연관시킨다.

연결이 설정된 후 소켓을 통해 데이터를 TCP 연결로 보내면 된다.

서버 프로세스가 실행되면 클라이언트 프로세스는 서버로의 TCP 연결을 시도하는데, 이는 클라이언트 프로그램에서 TCP 소켓을 생성함으로써 가능하다.

TCP 소켓을 생성할 때, 서버에 있는 환영(welcome) 소켓의 주소(IP, port #)를 명시한다.

소켓을 생성한 후 클라이언트는 3-way handshake를 하고 서버와 TCP 연결을 설정한다. (핸드셰이킹은 프로그램에서 전혀 인지 못한다.)

핸드셰이킹 동안 서버는 해당 클라이언트에게 지정되는 새로운 소켓을 생성한다. 이를 연결 소켓이라고 한다.

애플리케이션 관점에서 볼 때 클라이언트의 소켓과 서버의 연결 소켓은 파이프에 의해 직접 연결된다.

파이프를 통해 클라이언트는 자신의 소켓으로 임의의 바이트를 보낼 수 있으며, 서버 프로세스가 그것을 수신하는 것을 TCP가 보장한다. 이는 서버 입장에서도 마찬가지이다.

위 그림은 전형적인 클라이언트-서버 TCP 연결 구조이다.

UDP 프로그램과 똑같은 기능을 하는 프로그램을 작성해보자.

주석은 UDP와 다른 부분을 위주로 작성하였다.

from socket import *

serverName = ’servername’
serverPort = 12000

# 클라이언트 소켓을 의미한다. SOCK_STREAM으로 TCP 소켓임을 명시했다.
# UDP 때와 마찬가지로 따로 출발지 주소를 명시하지 않는다. (운영체제가 대신 해준다.) 
clientSocket = socket(AF_INET, SOCK_STREAM)

# 클라이언트가 TCP 소켓을 이용하여 서버로 데이터를 보내기 전에 TCP 연결이 먼저 클라이언트와 서버 사이에 설정되어야 한다.
# 해당 라인으로 TCP 연결을 시작하고, connect() 메서드의 파라미터는 연결의 서버 쪽 주소이다.
# 이 라인이 수행된 후에 3-way handshake가 수행되고 클라이언트와 서버 간에 TCP 연결이 설정된다.
clientSocket.connect((serverName, serverPort))

sentence = raw_input(’Input lowercase sentence:’)

# 클라이언트 소켓을 통해 TCP 연결로 보낸다. UDP 소켓처럼 패킷을 명시적으로 생성하지 않으며 패킷에 목적지 주소를 붙이지 않는다.
# 대신 클라이언트 프로그램은 단순히 문자열에 있는 바이트를 TCP 연결에 제공한다.
clientSocket.send(sentence.encode())

# 서버로부터 바이트를 수신하기를 기다린다.
modifiedSentence = clientSocket.recv(1024)
print(’From Server: ’, modifiedSentence.decode())

# 연결을 닫는다. 이는 클라이언트 TCP가 서버의 TCP에게 TCP 메시지를 보내게 한다.
clientSocket.close()

from socket import *

serverPort = 12000

# TCP 소켓 생성
serverSocket = socket(AF_INET, SOCK_STREAM)

# 서버의 포트 번호를 소켓과 연관시킨다.
serverSocket.bind((’’, serverPort))

# 연관시킨 소켓은 대기하며 클라이언트가 문을 두드리기를 기다린다.
# 큐잉되는 연결의 최대 수를 나타낸다.
serverSocket.listen(1)
print(’The server is ready to receive’)

while True:
    # 클라이언트가 TCP 연결 요청을 하면 accept() 메소드를 시작해서 클라이언트를 위한 연결 소켓을 서버에 생성한다.
    # 그 뒤 클라이언트와 서버는 핸드셰이킹을 완료해서 클라이언트의 소켓과 연결 소켓 사이의 TCP 연결을 생성한다.
    connectionSocket, addr = serverSocket.accept()
    sentence = connectionSocket.recv(1024).decode()
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence.encode())
    
    # 응답을 보내고 연결 소켓을 닫는다. 그러나 환영소켓인 serverSocket이 열려있어 다른 클라이언트가 서버에 연결을 요청할 수 있다. 
    connectionSocket.close()

이 절에서는 인터넷 전자메일 구조의 중심에 있는 애플리케이션 계층 프로토콜을 알아본다.

아래 그림은 인터넷 메일 시스템의 상위 레벨 개념을 보여준다.

Three major components of Electronic mail:

• User agents
• Mail servers
• SMTP(Simple Mail Transfer Protocol)

• a.k.a. "mail reader"
• 사용자 에이전트는 사용자가 메시지를 읽고, 응답하고, 전달하고, 저장하고, 구성하게 해준다.
• 대표적으로 마이크로 소프트 아웃룩(Outlook), 애플 메일 등이 있다.

• 전자 메일 인프라스트럭처의 중심이다.
• 각 수신자는 메일 서버에 메일 박스(mailbox)를 갖고 있다.
  • 메일 박스는 수신자의 메시지를 유지하고 관리한다.
  • 일반 메시지는 송신자의 사용자 에이전트에서 전달이 시작되고, 송신자의 메일 서버를 거친 후에 수신자의 메일 서버로 전달된다.
    거기서 수신자의 메일 박스에 저장된다.
  • 전자메일 박스에 있는 메시지를 보려면 메일 서버는 사용자 계정과 비밀 번호를 이용하여 이용자를 인증하여야 한다.
• 송신자는 메일 서버의 고장에도 대처해야 한다.
  • 만약 메일을 수신자의 메일 서버로 전달할 수 없다면 그 메시지를 메시지 큐(queue)에 보관하고 나중에 그 메시지를 전달하기 위해 다시 시도한다.
  • 재시도는 약 30분마다 일어나고, 계속 실패 시에 서버는 그 메시지를 제거하고 송신자에게 통보한다.

💡 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜이다.

• SMTP는 메일을 송신자의 메일 서버로부터 수신자의 메일 서버로 전송하는 데에 TCP의 신뢰적인 데이터 전송 서비스를 이용한다.
• SMTP는 대부분의 애플리케이션 계층 프로토콜처럼, 클라이언트와 서버를 갖고 있다.
• SMTP의 클라이언트와 서버 모두가 모든 메일 서버에서 수행되고, 상대 메일로 송신할 때는 클라이언트가 되고 수신할 때는 서버가 된다.

uses TCP to reliably transfer email message from client to server, port 25

direct transfer: sending server to receiving server

SMTP에서는 모든 메일 메시지의 몸체는 단순한 7-bit ASCII여야 한다.

이 때문에 전송 용량이 제한되어 커다란 첨부 파일이나 비디오 파일을 보낼 때 문제를 일으킨다.

Three phases of transfer

1. handshaking (greeting)
2. transfer of messages (data exchange)
3. closure

1. 앨리스는 전자 메일 사용자 에이전트를 수행하고, 밥의 전자 메일 주소를 제공하여 메시지를 보내라고 명령한다.
2. 앨리스의 사용자 에이전트는 메시지를 그녀의 메일 서버에게 보내고, 그곳에서 메시지는 메시지 큐에 놓인다.
3. 앨리스의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에 있는 메시지를 본다.
   밥의 메일 서버에서 수행되고 있는 SMTP 서버에게 TCP 연결을 설정한다.
4. 초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 앨리스의 메시지를 TCP 연결로 보낸다.
5. 밥의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 밥의 메일 서버는 그 메시지를 밥의 메일 박스에 놓는다.
6. 밥은 편한 시간에 그 메시지를 읽기 위해 사용자 에이전트를 시동한다.

SMTP는 두 메일 서버가 먼 거리에 떨어져 있더라도 중간 메일 서버를 이용하지 않는다.

즉, 메시지를 보낼 때 보내는데 실패하더라도 중간 메일 서버에 저장되는 것이 아니라 송신자의 메일 서버에 남아있다.

1. 클라이언트 SMTP는 서버의 SMTP의 25번 포트로 TCP 연결을 설정한다. 서버가 죽어있다면 나중에 시도한다.
2. 연결이 설정되면, 애플리케이션 계층 핸드셰이킹을 수행한다.
   이때 SMTP 클라이언트는 송신자의 전자메일 주소와 수신자의 전자메일 주소를 제공한다.
3. 이후 클라이언트는 메시지를 보낸다. (TCP의 신뢰적인 데이터 전송 서비스에 의존)
4. 보낼 다른 메시지가 있다면 같은 TCP 연결 상에서 반복하며, 그렇지 않으면 TCP를 닫는다. (지속 연결(persistent connection))

S:  220 hamburger.edu
C:  HELO crepes.fr
S:  250 Hello crepes.fr, pleased to meet you
C:  MAIL FROM: <alice@crepes.fr>
S:  250 alice@crepes.fr ... Sender ok
C:  RCPT TO: <bob@hamburger.edu>
S:  250 bob@hamburger.edu ... Recipient ok
C:  DATA
S:  354 Enter mail, end with ”.” on a line by itself
C:  Do you like ketchup?
C:  How about pickles?
C:  .
S:  250 Message accepted for delivery
C:  QUIT
S:  221 hamburger.edu closing connection

• 클라이언트는 5개의 HELO, MAIL FROM, RCPT TO, DATA, QUIT 명령을 내린다.
• 클라이언트는 하나의 점(.)으로 된 라인을 송신하며, 그것은 서버에서 메시지의 끝을 나타낸다.
• 서버는 각 명령에 응답하며, 각 응답에는 응답 코드와 영문 설명이 있다.

SMTP는 지속 연결(persistent connection)을 사용한다.

즉, 같은 수신 메일 서버로 보내는 여러 메시지를 갖고 있다면, 같은 TCP 연결을 통해 모든 메시지를 전달할 수 있다.

telnet 명령어를 사용하면 원격 메일 서버와 위와 같은 대화를 할 수 있다.

전자메일을 보낼 때 주변 정보가 포함된 헤더(header)가 메시지 몸체(body) 앞에 오게 된다.

• 이 헤더는 RFC 5322에 정의되어 있으며, 헤더와 몸체는 CRLF로 분리된다.
• 모든 헤더는 From: 헤더라인과 To: 헤더 라인을 반드시 가져야 한다. (나머지 헤더는 선택사항이다.)

일반 메시지 헤더는 다음과 같다.

From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.

Message

• SMTP : delivery / storage to receiver's server
• Mail access protocol : retrieval from server

메일 서버가 메일 박스를 관리하고, SMTP의 클라이언트와 서버 측 모두를 수행한다.

메일 서버가 로컬 호스트에 있다면, 호스트는 언제든 도착할 수 있는 전자 메일을 수신하기 위해 항상 켜져 있어야 하고 인터넷에 연결되어 있어야 한다.

이는 대부분의 인터넷 사용자에게는 비현실적이다.

대신에 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근한다.

메일 서버는 보통 사용자들과 공유한다.

클라이언트의 사용자 에이전트는 수신자의 메일 서버로 직접 대화하지 않는다.

대신에 그림처럼 (1) 클라이언트의 사용자 에이전트는 클라이언트의 메일 서버로 전자메일 메시지를 SMTP 또는 HTTP를 이용하여 보낸다.

(2) 그리고 수신자의 메일 서버는 SMTP를 이용하여 수신자의 메일 서버로 전자메일 메시지를 중계한다.

두 단계 절차를 거치는 주요 이유는 수신자의 메일 서버를 통해 중계하지 않으면 수신자의 에이전트는 목적지 메일 서버에 도달할 수 없기 때문이다.

송신자는 전자메일을 자신의 메일 서버에 먼저 저장하고, 수신자의 메일 서버는 그 메시지를 수신자의 메일 서버로 받을 때까지 30분 마다 반복해서 보내려고 한다.

수신자는 자신의 ISP 내부의 메일 서버에 메시지를 어떻게 얻을 수 있는가?

SMTP는 push 프로토콜인 반면 메시지를 얻는 것은 pull 동작이기 때문에 다른 프로토콜을 사용하여야 한다.

두 가지 대표적인 방법

• HTTP
  • 웹 기반 전자메일이나 스마트폰 앱의 경우에 쓰인다.
  • 당연히 메일 서버는 SMTP 인터페이스와 HTTP 인터페이스 둘 다 가지고 있어야 한다.
• IMAP : RFC 3501에 정의된 인터넷 메일 접근 프로토콜

인터넷 호스트의 식별자 중 하나는 www.facebook.com, www.google.com 등의 호스트 이름(hostname)이다.

그러나 호스트의 이름은 인터넷에서의 호스트 위치에 대한 정보를 거의 제공하지 않는다.

또한, 가변 길이의 알파뉴메릭 문자로 구성되므로 라우터가 처리하는 데 어려움이 있다.

이러한 이유로 호스트는 흔히 말하는 IP 주소(IP address)로 식별된다.

IP 주소는 4 바이트로 구성되고, 계층구조를 갖는다.

• 121.7.106.83과 같은 형태로 0 ~ 255의 십진수로 표현하는 각 바이트는 점으로 구분한다.
• 계층구조여서 왼쪽에서 오른쪽으로 조사함으로써, 그 호스트가 인터넷의 어디에 위치하는지에 대한 자세한 정보를 얻을 수 있다.
  (더 자세히는 4장에서 논의한다.)

사람은 호스트 네임을 선호하지만, 라우터는 고정 길이의 계층구조를 가진 IP 주소를 선호한다.

이 차이를 절충하기 위해 호스트 이름을 IP 주소로 변환해주는 디렉터리(directory) 서비스가 필요하다.

이 서비스가 인터넷 DNS(Domain name system)의 주요 임무다. (hostname translations, address resolutions)

1. DNS 서버들의 계층구조로 구현된 분산 데이터 베이스이다.
   implemented in hierarchy of many name servers
2. 호스트가 분산 데이터 베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜이다.

DNS 서버는 주로 BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스(UNIX) 컴퓨터다.

DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용한다.

TCP의 경우 데이터 전송 시작 전에 3-way-handshaking 과정이 있는 반면, UDP는 연결 설정에 드는 비용이 없다.

DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 TCP보다 UDP가 더 적합하다.

또한, UDP는 512 bytes를 넘어가지 않는 패킷만 전송이 가능하고 오버헤드가 없어서 속도가 빠른데,
DNS가 전송하는 데이터 패킷 사이즈가 매우 작으므로 UDP가 유리하다.

이때 단순히 패킷의 사이즈가 작다고 DNS가 UDP를 채택한 것은 아니고,
전달하는 패킷의 크기가 작기 때문에 신뢰성이 보장되지 않아도 되기 때문이다. (못 받으면 다시 전달하면 된다.)

TCP는 호스트 간의 연결 상태를 유지한다.

이때 TCP의 패킷 안에는 여러 정보가 담겨 있지만, UDP는 어떤 정보도 기록하지 않고 유지할 필요도 없다.

DNS 서버는 TCP보다 많은 클라이언트를 수용할 수 있으므로 연결 상태를 유지하지 않고 정보 기록을 최소화할 수 있는 UDP를 채택하였다.

1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트를 수행한다.
2. 브라우저는 URL로부터 호스트 이름을 추출하고 그 호스트 이름을 DNS 애플리케이션의 클라이언트에 보낸다.
3. DNS 클라이언트는 DNS 서버로 호스트 이름을 포함하는 질의를 보낸다. (client queries to DNS server)
4. DNS 클라이언트는 결국 호스트 이름에 대한 IP 주소를 받게 된다.
5. 브라우저가 DNS로부터 IP 주소를 받으면,
   브라우저는 해당 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

DNS는 위 예시에서 알 수 있듯이 추가 지연을 주지만,
가까운 DNS 서버에 캐싱되어 있어서 평균 DNS 지연 뿐만 아니라 DNS 네크워크 트래픽 감소에 도움을 준다.

복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다.

relay1.west-coast.enterprise.com 같은 호스트 이름은 enterprise.com 같은 별칭을 가질 수 있다.

이 경우에 relay1.west-coast.enterprise.com를 정식 호스트 이름(canonical hostname)이라고 한다.

DNS는 호스트의 IP 주소 뿐만 아니라 제시한 별칭 호스트 이름에 대한 정식 호스트 이름을 얻기 위해 이용될 수 있다.

전자 메일 주소는 간단하지만 그 서버의 호스트 네임은 일반적으로 더 복잡하다.

load balancing among the servers

인기 있는 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖는다.

이때 여러 IP 주소가 하나의 정식 호스트 이름과 연관되어 있다. DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다.

클라이언트가 주소 집합으로 매핑하는 호스트 이름에 대한 DNS 질의를 하면, 서버는 IP 주소 집합 전체를 가지고 응답한다.

각 응답에서의 주소는 순환식으로 보낸다.

클라이언트는 대체로 주소 집합 내부의 첫 번째 IP 주소로 HTTP 요청 메시지를 보내므로, DNS의 순환 방식은 트래픽을 분산하는 효과를 낸다.

[참고] What is DNS Load Balancing?

사용자의 호스트에서 실행되는 어떤 애플리케이션이 호스트 이름을 IP 주소로 변환하려 한다고 가정하자.

과정은 다음과 같다.

1. 애플리케이션이 호스트 이름을 명시하여 DNS 클라이언트 호출한다.
2. 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보낸다.
   이때 모든 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다.
3. 응답 메시지를 애플리케이션에 전달한다.

DNS는 간단해보이지만 매우 복잡한데, 이는 전 세계에 분산된 많은 DNS 서버 뿐만 아니라
DNS 서버와 질의를 하는 호스트 사이에서 어떻게 통신하는지를 명시하는 애플리케이션 계층 프로토콜로 구성되어 있다.

why not centralize DNS?

만약 DNS가 간단한 설계로 모든 매핑을 포함하는 하나의 인터넷 네임 서버를 갖고 있다면, 수많은 호스트를 가진 오늘날 다음과 같은 문제를 일으킬 수 있다.

• 서버의 고장 : 이 네임 서버가 고장 나면, 전체 인터넷이 작동하지 않는다. (single point of failure)
• 트래픽 양의 과부하 : 단일 DNS 서버가 모든 질의를 해결해야 한다.
• 먼 거리의 중앙 집중 데이터베이스: 단일 DNS 서버가 모든 질의 클라이언트로부터 '가까울' 수만은 없다. 즉, 멀면 멀수록 모든 질의가 느려진다.
• 유지 관리
  • 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 한다.
  • 모든 새로운 호스트를 반영하기 위해 자주 갱신되어야 하고, 사용자에게 호스트를 등록할 수 있도록 허용하는 것과 관련된 인증 문제가 있다.

요약하면 중앙 집중 데이터베이스는 확장성(scalability)이 전혀 없고, 결과적으로 DNS는 분산되도록 설계되어있다.

DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하며 전세계에 분산시킨다.

• 1000개 이상의 루트 서버 인스턴스가 세계에 흩어져 있다.
• 루트 네임 서버는 TLD 서버의 IP 주소들을 제공한다.
• 인터넷 할당 번호 관리기관 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 조정된다.

• Top-Level Domain, TLD
• com, org, net 같은 상위 레벨 도메인과 kr, uk 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있다.
• Authoritative(책임) DNS 서버에 대한 IP 주소를 제공한다.

• 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.
  • 기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있다.
• 기관은 직접 자신의 책임 DNS 서버의 구현을 선택할 수 있고, 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불한다.

• 로컬 DNS 서버는 서버들의 계층 구조에 엄격하게 속하지는 않지만 DNS 구조의 중심에 있다.
• ISP는 로컬 DNS 서버를 갖고, 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공한다.
• 대체로 호스트에 가까이 있기 때문에 지연이 적다.

위 그림에서 cse.nyu.edu가 gaia.cs.umass.edu의 IP 주소를 원한다고 가정해보자.

1. 자신의 로컬 DNS 서버에 질의를 보낸다. 이때 변환하고 싶은 호스트의 이름을 같이 보낸다.
2. 로컬 DNS 서버는 그 질의 메시지를 루트 DNS 서버에게 전달한다.
3. 루트 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 목록을 로컬 DNS 서버에 보낸다.
4. 로컬 DNS 서버는 TLD 서버에 질의를 보낸다.
5. TLD 서버는 umass.edu를 인식하고, dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소로 응답한다.
6. 로컬 DNS 서버는 직접 책임 DNS 서버로 질의 메시지를 다시 보낸다.
7. 최종 gaia.cs.umass.edu의 IP 주소를 응답한다.
8. 호스트에 최종 IP 주소를 응답한다.

여기서는 총 8번의 DNS 메시지가 보내졌다.

일반적으로 TLD 서버는 위의 예시와 같이 책임 DNS 서버를 알지 않고, 책임 DNS 서버를 아는 중간 DNS 서버를 알고 있다.

즉, 해당 질의 과정 까지 포함되면 전체 10번의 메시지를 보내게 된다.

위 예는 재귀적 질의와 반복적 질의를 사용한다.

cse.nyu.edu로부터 dns.nyu.edu로 보내는 질의는 자신을 필요한 매핑을 대신하여 얻도록 dns.nyu.edu에 요구하므로 재귀적 질의이고,
나머지는 반복적 질의다.

아래 그림은 모든 질의가 재귀적인 DNS 질의 사슬을 보여준다.

일반 질의는 전형적으로 반복적 질의를 따른다.

• 재귀적 질의에서는 높은 계층에 있는 DNS server가 책임져야 하는 것들이 많다.
  • puts burden of name resolutions on contacted name server
  • heavy load at upper levels of hierarchy
• 중요한 infra를 지키는 것이 훨씬 낫기 때문에, 중요한 root name server 보단 default name server가 일을 더 하는 것이 좋다.

실제로는 DNS 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱(caching)을 사용한다.

질의 사슬에서 DNS 서버는 DNS 응답을 받았을 때 로컬 메모리에 응답에 대한 정보를 저장할 수 있다.

만약 호스트의 이름과 IP 주소 쌍이 DNS 서버에 저장되고 다른 호스트 이름으로부터 같은 질의가 DNS 서버로 도착한다면,
DNS 서버는 호스트 이름에 대한 책임이 없을 때조차 원하는 주소를 제공할 수 있다.

호스트 DNS와 IP 사이의 매핑과 호스트는 영구적이지 않기 때문에 어떤 기간(TTL, Time to Live) 이후에 저장된 정보를 제거한다.

로컬 DNS 서버는 구체적인 IP 주소 이외에도 TLD 서버의 IP를 저장하여 루트 DNS 서버를 우회할 수 있게 한다.

각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다.

DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드(Resource Records)를 저장한다.

자원 레코드는 다음과 같은 필드를 포함하는 4개의 Tuple로 되어 있다.

(Name, Value, Type, TTL)

TTL(Time to Live)은 자원 레코드의 생존 기간이다.

Name과 Value는 Type을 따른다. 즉, Type에 따라서 Name과 Value에 대한 semantic(해석법)이 달라진다.

Address
Type A 레코드는 표준 호스트 이름의 IP 주소 매핑을 제공한다.

• Name : 호스트 이름(hostname)
• Value : 호스트 이름에 대한 IP 주소

Name Server

• Name : 도메인(domain)
• Value : 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 이름

Canonical NAME

• Name : 정식 호스트 이름의 alias name
• Value : 별칭 호스트 이름 Name에 대한 정식 호스트 이름

Mail eXchange

• Value : 별칭 호스트 이름 Name을 갖는 메일 서버의 정식 이름
• MX 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용한다.

메일 서버의 정식 이름을 얻기 위해서는 MX 레코드에 대한 질의를 해야 하고, 다른 서버의 정식 이름을 얻기 위해선 CNAME 레코드에 대한 질의를 한다.

DNS 서버가 특별한 호스트 이름에 대한 책임 서버이면, 그 DNS 서버는 호스트 이름에 대한 Type A 레코드를 포함한다.

서버가 호스트 이름에 대한 책임 서버가 아니라면, 그 서버는 호스트 이름을 포함하는 DNS 서버의 IP 주소를 제공하는 Type A 레코드도 포함할 것이다.

DNS의 요청과 응답 메시지는 모두 아래 그림과 같은 포맷을 갖고 있다.

처음 12 byte의 헤더 영역 : 여러 필드를 갖고 있다.

• 첫 필드는 질의를 식별하는 16 bit의 숫자이다.
  이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.
• 플래그(flag) 필드에는 여러 개의 플래그가 있다.
  • 1 비트의 질의/응답 플래그는 메시지가 질의인지 응답인지 구분하게 한다.
  • 1 비트의 책임 플래그는 DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정된다.
  • 1 비트의 재귀 요구 플래그는 DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정된다.
  • 1 비트로 된 재귀 가능 필드는 DNS 서버가 재귀 질의를 지원하면 응답에 설정된다.
• 나머지 4개의 '개수' 필드는 헤더 다음에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.

• 질문 영역
  • 현재 질의에 대한 정보를 포함한다.
  • 질의되는 이름을 포함하는 이름 필드와, 이름에 대해 문의되는 질문 타임을 나타내는 타입 필드를 나타낸다. (A, NS 등)
• 답변 영역
  • 원래 질의된 이름에 대한 자원 레코드를 포함한다. (value, TTL)
  • 여러 개의 자원 레코드를 보낼 수 있는데, 하나의 호스트 이름이 여러 개의 IP를 가질 수 있기 때문이다. (중복 웹 서버)
• 책임 영역
  • 다른 책임 서버의 레코드를 포함한다.
• 추가 영역
  • 다른 도움이 되는 레코드를 갖고 있다.
  • 예를 들어, MX 질의에 대한 응답에서 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 갖고 있고,
    추가 영역은 정식 호스트 이름에 대한 IP 주소를 제공하는 A 레코드를 포함한다.

도메인 네임 networkutopia.com을 등록 기관(DNS registrar)에 등록한다고 가정해보자.

등록 기관(DNS registrar)은 도메인 네임의 유일성을 확인하고,
그 도메인 네임을 DNS 데이터베이스에 넣고, 그 서비스에 대한 요금을 받는 상업 기관이다.

이전에는 작은 등록기관이 독점했었지만, 이제는 많은 기관이 경쟁하고 ICANN이 이러한 여러 등록기관을 승인해준다.

도메인 네임을 어떤 등록기관에 등록할 때 등록 기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야 한다.

• 주책임 서버 : dns1.networkutopia.com / 주책임 서버 IP : 212.2.212.1
• 부책임 서버 : dns2.networkutopia.com / 부책임 서버 IP : 212.2.212.2

위와 같다고 가정하자.

이 두 책임 DNS 서버 각각에 대해 등록 기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다.

특히 주책임 서버의 경우 다음 두 개의 자원 레코드를 DNS 서버에 삽입한다.

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

또한, Type A 레코드와 메일 서버에 대한 Type MX 자원 레코드가 책임 DNS 서버에 등록되는 것을 확인한다.

이러한 모든 단계가 끝나면 여러 사람들이 웹 사이트를 방문할 수 있고, 전자메일을 보낼 수 있게 된다.

공격자는 DNS 루트 서버로 다량의 패킷을 보내려는 시도를 하여 다른 DNS 질의들이 응답을 받지 못하게 하려 한다.

실제로 이 일이 일어났지만, 많은 DNS 루트 서버들은 루트 서버로 향하는 공격자가 사용한 ICMP 핑 메시지를 블록하도록 형상화한 패킷 필터로 보호되었고,
대부분의 로컬 DNS 서버가 최상위 도메인 서버들의 IP 주소들을 캐싱하고 있어서 피해가 거의 없었다.

즉, 더 효과적인 공격은 최상위 도메인 서버를 공격하는 것이고, 실제로 최상위 도메인 서비스 제공자 Dyn에 이러한 일이 발생했다.

이는 유명 애플리케이션들이 무차별 교란되는 결과를 야기했다.

공격자는 DNS 서버로 가짜 응답을 보내어 그 서버가 자신의 캐시에 가짜 레코드를 받아들이도록 속임수를 쓴다.

이러한 공격은 웹 사용자들을 공격자의 웹사이트로 유도하는 데 이용될 수 있다.

이러한 공격을 막기 위해 DNS 보안 확장 프로토콜이 개발되어 사용되고 있다.

네트워크 애플리케이션 개발의 중심은 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다.

예를 들어, 웹 애플리케이션에는 서로 통신하는 서버(웹 서버 프로그램)와 클라이언트(사용자 호스트에서 실행되는 브라우저 프로그램)로 구별되는
두 가지 프로그램이 있다.

중요한 것은 우리가 라우터나 링크 계층 스위치처럼 네트워크 코어 장비에서 실행되는 소프트웨어까지 작성할 필요는 없다는 점이다.
(그렇게 하고 싶더라도 네트워크 코어 장비는 애플리케이션 계층에서 기능하지 않기 때문에 그렇게 할 수 없다.)

애플리케이션 구조는 네트워크 구조와 분명히 다르다.

애플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있고, 해당 애플리케이션의 특정 서비스 집합을 제공한다.

반면, 애플리케이션 구조는 애플리케이션 개발자가 설계하며, 애플리케이션이 여러 종단 시스템에서 어떻게 조직되어야 하는지를 알려준다.

• 항상 동작하고 있는 서버가 존재하고, 클라이언트라는 다른 호스트들로부터 서비스 요청을 받는다.
• 클라이언트는 서로 직접적으로 통신하지 않는다.
• 서버는 잘 알려진 고정 IP 주소를 갖는다.
• 서버가 클라이언트로부터 오는 모든 요청에 더 응답하는 것이 불가능할 때,
  많은 수의 호스트를 갖춘 데이터 센터가 강력한 가상의 서버를 생성하는 역할로 사용된다. 보통, 10만개 정도의 서버를 갖추고 있다.

• 항상 켜져있는 인프라스트럭처 서버에 최소로 의존한다. (혹은 의존하지 않는다.)
• 대신에 애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하게 한다.
• peer는 흔히 알려진 클라이언트(개인 데스크톱과 랩톱 등등)이다.
• 자가 확장성을 가진다. 예를 들어, 파일 공유 애플리케이션에서는 각 피어들이 파일을 요구하여 작업 부하가 생기지만
  각 피어들은 파일을 다른 피어들에게 분배하여 시스템에 서비스 능력을 갖춘다.
• 데이터 센터 등이 필요 없으므로 비용 효율적이다.

실제 통신하는 것은 프로그램이 아니라, 실행되고 있는 프로그램인 프로세스이다.

2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지 교환으로 서로 통신한다.

송신 프로세스는 메시지를 만들어서 보내고 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다.

클라이언트와 서버 프로세스를 다음과 같이 정의한다.

💡 두 프로세스 간의 통신 세션에서
통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트(client)라 하고,
세션을 시작하기 위해 접속을 기다리는 프로세스를 서버(server)라고 한다.

간단히 말하면, 요청을 보내는 쪽의 프로세스를 보통 클라이언트라고 하고, 요청을 받는 쪽을 서버라고 한다.

당연히 P2P 구조에서 봤듯이, 클라이언트도 서버 프로세스가 될 수 있고, 서버도 클라이언트 프로세스가 될 수 있다.

프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내고 받는다.

네트워크에서 프로세스를 집이라 한다면, 소켓은 마치 문과 같은 존재이다.

위 그림에 보이듯이, 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층간의 인터페이스다.

네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.

애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못한다.

애플리케이션 개발자의 트랜스포트 계층에 대한 통제

1. 트랜스포트 프로토콜을 선택
2. 최대 버퍼와 최대 세크먼트 크기 같은 약간의 매개변수 설정

프로세스가 다른 수행되고 있는 다른 패킷으로 프로세스를 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다.

수신 프로세스를 식별하기 위해서는 두 가지 정보가 필요하다.

1. 호스트의 주소 즉, IP 주소가 필요하다.
2. 호스트 내의 수신 프로세스를 명시하는 식별자 즉, port 번호가 필요하다. 더 자세한 내용은 3장에서 다룬다.

송신 측의 애플리케이션은 소켓을 통해 메시지를 보내고,
트랜스포트 프로토콜은 네트워크를 통해 그 메시지를 수신 프로세스의 소켓으로 이동시킬 책임이 있다.

인터넷을 포함한 많은 네트워크는 트랜스포트 프로토콜을 하나 이상 제공한다.

트랜스포트 프로토콜이 그것을 이용하는 애플리케이션에게 제공할 수 있는 4가지 서비스를 알아보자.

• 신뢰적 데이터 전송(data integrity)
• 처리율(throughput)
• 시간(timing)
• 보안(security)

1장에서 보았듯이, 패킷들은 컴퓨터 네트워크 내에서 손실될 수 있다.

이러한 데이터 손실은 위험한 결과를 초래할 수 있다.

만약 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 신뢰적 데이터 전송이라고 한다.

트랜스포트 프로토콜이 이 서비스를 제공할 때, 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는다.

트랜스포트 프로토콜이 이 서비스를 제공하지 않을 때 송신 프로세스가 보낸 데이터는 전혀 도착하지 않을 수 있다.

이러한 애플리케이션을 손실 허용 애플리케이션(실시간 비디오/오디오 애플리케이션 등이 대표적)이라고 한다.

다른 세션들이 네트워크 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변한다.

트랜스포트 프로토콜은 어느 명시된 속도에서 보장된 가용 처리율을 제공한다.

처리율 요구사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션이라 하고, 현존하는 많은 멀티미디어 애플리케이션은 대역폭에 민감하다.
(너무 처리율이 낮으면 전화같은 서비스가 불가능하다.)

반대로 요구사항이 없는 애플리케이션을 탄력적 애플리케이션(elastic apps)이라고 한다.

트랜스포트 프로토콜은 시간 보장을 제공할 수 있다.

예를 들어, 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100ms 내에 도착하게 할 수 있다.

실시간 애플리케이션에 주로 사용된다.

송신 호스트에서 트랜스포트 프로토콜은 모든 데이터를 암호화할 수 있고, 수신 호스트에서 트랜스포트 프로토콜은 모두 해독할 수 있다.

보통 TCP를 애플리케이션 계층에서 강화하여 TLS로 보안 서비스를 제공한다. (자세한 내용은 8장에서 다룬다.)

TCP 전송 프로토콜은 다음 세 가지 서비스를 제공한다.

애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하게 한다.

이 핸드 셰이킹(handshaking) 과정이 클라이언트와 서버에 패킷이 곧 도달할테니 준비하라고 알려주는 역할을 한다.

핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 말한다.

이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중 연결이라고 한다. (3장에서 더 자세히 다룬다.)

통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다.

TCP는 애플리케이션의 한 쪽이 바이트 스트림을 소켓으로 전달하면, 그 바이트 스트림이 손실되거나 중복되지 않게 수신 소켓으로 전달한다.

네트워크가 혼잡 상태에 이르면 프로세스의 속도를 낮추는 방법 (또한, 3장에서 자세히 다룬다.)

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다.

UDP는 비연결형으로 핸드셰이킹 과정이 없고, 비신뢰적인 데이터 전송 서비스를 제공하여 데이터가 전달되는 것을 보장하지 않는다.

UDP는 또한 혼잡 제어 방식을 포함하지 않아 프로세스의 속도 저하 없이 네트워크를 이용할 수 있다.

그러나 혼잡으로 인해 종단 간 처리율이 낮아져서 속도가 오히려 더 낮아질 수 있다.

TCP와 UDP는 처리율 혹은 시간 보장 서비스를 제공하지 않는다.

시간 민감 애플리케이션 같은 경우에는 이러한 처리율 및 시간 지연에 잘 대처할 수 있도록 설계되어 있다.

그러나 지연이 과도할 때는 보장이 없기 때문에 한계가 있다.

💡 애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.

이는 다음과 같은 내용을 정의한다.

• 교환 메시지의 타입
• 여러 메시지 타입의 문법(syntax)
• 필드의 의미, 즉 필드에 있는 정보의 의미(semantics)
• 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지를 결정하는 규칙

여러 애플리케이션 계층 프로토콜은 RFC에 명시되어 있어 공중 도메인에서 찾을 수 있다.

예를 들어, 만약 브라우저 개발자가 HTTP 규칙을 따른다면, HTTP 규칙을 따른 어떠한 웹 서버로부터도 웹페이지를 가져올 수 있다.

다른 많은 애플리케이션 계층 프로토콜은 독점이며 공중 도메인에서 찾을 수 없다.

애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.

예를 들어, 웹 애플리케이션은 문서 포맷 표준, 웹 브라우저, 웹 서버, 웹 애플리케이션 계층 프로토콜(HTTP)을 포함하는 여러 요소들로 구성된다.

이 책에서는 중요하고 인기 있는 5개의 애플리케이션 분야에 초점을 맞춘다.

• 웹
• 전자메일
• 디렉터리 서비스
• 비디오 스트리밍
• P2P 애플리케이션

웹은 온디맨드(on-demand) 방식으로 사용자가 원할 때 원하는 것을 수신한다.

개인은 또한, 웹 상에서 많은 정보를 얻고 상호작용할 수 있다.

웹 애플리케이션 계층 프로토콜은 웹의 중심이다.

RFC 1945, RFC 7230, RFC 7540에 정의되어 있다.

HTTP는 메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의하고 있다.

자세히 설명하기 전에 웹 전문 용어들을 알아보자.

웹 페이지들은 객체(object)로 구성된다.

객체는 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML, JPEG 이미지, 자바스크립트 등)이다.

대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체로 구성된다.

예를 들어, 웹 페이지가 HTML 텍스트와 5개의 JPEG 이미지로 구성되어 있으면, 이 웹페이지는 6개의 객체를 갖는다.

기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조한다.

URL은 객체를 갖고 있는 서버의 호스트 이름과 객체의 경로 이름을 갖고 있다.

e.g.,

http://www.school.edu/picture.gif 

• 호스트의 이름 : www.school.edu
• 경로 이름 : picture.gif

웹 브라우저(Web browser)는 HTTP의 클라이언트 측을 구현하기 때문에, 웹의 관점에서 브라우저와 클라이언트(client)라는 용어를 혼용하여 사용한다.

브라우저는 요구한 웹 페이지를 보여주고 여러가지 인터넷 항해와 구성 특성을 제공한다.

웹 서버(Web server)는 URL로 각각을 지정할 수 있는 웹 객체를 갖고 있다.

일반적으로, 사용자가 웹 페이지를 요청할 때
(1) 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메세지를 서버에게 보내고,
(2) 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지로 응답한다.

HTTP는 TCP를 전송 프로토콜로 사용한다.

1. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다.
2. 연결이 이루어지면, 브라우저와 서버 프로세스는 각각의 소켓 인터페이스를 통해 TCP로 접속한다.
3. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고, 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
   마찬가지로, HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.

이렇게 TCP를 통해 메시지를 보내면 TCP는 신뢰적인 데이터 전송 서비스를 제공하므로
모든 HTTP 요청 메시지가 궁극적으로 서버에 도착한다. (서버에서 보낸 메시지도 마찬가지다.)

HTTP는 TCP가 어떻게 손실 데이터를 복구하고, 올바른 순서로 데이터를 배열하는지 전혀 걱정할 필요가 없어 계층 구조의 장점이 드러난다.

특정 클라이언트가 몇 초 후에 같은 객체를 두 번 요청해도 서버는 전에 보냈다고 알려주지 않고 객체를 또 보낸다.

HTTP 서버는 클라이언트에 대한 정보를 유지하지 않으므로, 비상태(stateless) 프로토콜이라고 부른다.

💡 클라이언트-서버 상호작용이 TCP 상에서 발생할 때 각 요구/응답 쌍이 분리된 TCP 연결을 통해 보내지는 것을 말한다.

웹 페이지를 서버에서 클라이언트로 전송하는 단계를 살펴보자.

페이지가 기본 HTML 파일과 10개의 이미지로 구성되고, 이 11개의 객체가 같은 서버에 있다고 가정하자.

연결 수행 과정은 다음과 같다.

1. HTTP 클라이언트는 HTTP 기본 포트 80을 통해 서버로 TCP 연결을 시도한다. TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 된다.
2. HTTP 클라이언트는 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보낸다. 이 요청에 객체 경로도 포함된다.
3. HTTP 서버는 TCP 연결 소켓을 통해 요청 메시지를 받는다. 저장 장치로부터 경로의 객체를 추출한다.
   HTTP 응답 메시지에 그 객체를 캡슐화 하여 소켓을 통해 클라이언트로 보낸다.
4. HTTP 서버는 TCP에게 연결을 끊으라고 한다. (그러나 실제로 클라이언트가 응답 메시지를 올바로 받을 때까지 끊지 않는다.)
5. HTTP 클라이언트가 응답 메시지를 받으면, TCP 연결이 중단된다. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다.
   클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하여 10개의 JPEG 객체에 대한 참조를 찾는다.
6. 참조되는 JPEG 객체에 대해 1 ~ 4단계를 반복한다.

브라우저는 웹 페이지를 수신하면서, 사용자에게 그 페이지를 보여준다. 다른 브라우저는 웹 페이지를 각기 다른 방식으로 해석하여 보여준다.

HTTP는 통신 프로토콜만 정의할 뿐, 웹 페이지에 대한 관심은 없다.

사용자는 앞의 단계를 동시에 받을지 순차적으로 받을지의 동시성 정도를 조절할 수 있도록 브라우저를 구성할 수 있다.

브라우저는 여러 개의 TCP 연결을 설정하며 다중 연결상에서 웹 페이지의 각기 다른 원하는 부분을 요청할 수 있다.

HTTP 1.0은 비지속 연결을 지원한다.

클라이언트가 HTML 파일을 요청하고 그 파일이 클라이언트로 수신될 때까지의 시간을 측정해보자.

이를 위해 RTT를 알아야 하는데,
RTT(round-trip-time)란 작은 패킷이 클라이언트로부터 서버까지 가고, 다시 클라이언트로 되돌아오는 데 걸리는 시간이다.

RTT는 패킷 전파 지연, 큐잉 지연, 처리 지연 등을 포함한다. (1장에 논의되어 있다.)

사용자가 하이퍼링크를 클릭하면, 브라우저와 웹 서버 사이에서 TCP 연결을 시도한다. 이는 3-way handshake를 포함한다.

즉, 클라이언트가 서버로 작은 TCP 메시지를 보내고, 서버는 작은 메시지로 응답하고, 마지막으로 클라이언트가 다시 서버에 응답한다.

서버가 작은 메시지로 응답하면 한 RTT가 계산된다. 이때, 클라이언트는 HTTP 요청 메시지를 TCP 연결로 보내면서 세 번째 응답 부분을 함께 보낸다.

일단, 요청 메시지가 도착하면 서버는 HTML 파일을 TCP 연결로 보내고 이 요청은 또 하나의 RTT를 필요로 한다.

즉, 대략 총 응답 시간은 2RTT와 HTML 파일을 서버가 전송하는 데 걸리는 시간을 더한 것이다.

1. 각 요청 객체에 대한 새로운 연결이 설정되고 유지되어야 한다.
   • TCP 버퍼가 할당되어야 하고, TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 하는데
     이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에는 심각한 부담이다.
2. 매번 2RTT를 필요로 한다.

HTTP/1.1 지속 연결에서 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지한다. (비지속 연결도 지원한다.)

같은 클라이언트와 서버 간의 이후 요청과 응답은 같은 연결을 통해 보내진다.

즉, 같은 서버에 있는 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 보낼 수 있다.

이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들 수 있다. (파이프라이닝, pipelining)

일반적으로 HTTP 서버는 일정 기간 사용되지 않으면 연결을 닫는다.

HTTP의 디폴트 모드는 파이프라이닝을 이용한 지속 연결을 사용한다.

RFC는 HTTP 메시지 포맷을 정의한다.

다음은 전형적인 HTTP 요청 메시지이다.

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

1. ASCII 텍스트로 쓰여 있어 사람들이 읽을 수 있다.
2. 메시지가 다섯 줄로 되어 있고, 각 줄은 CR(carriage return)과 LF(line feed)로 구별된다. 마지막 줄에 이어서 CR과 LF가 따른다.

HTTP 요청 메시지의 첫 줄은 요청 라인이라 부르고, 이후의 줄들은 헤더 라인이라고 부른다.

요청 라인은 3개의 필드, 즉 방식(method) 필드, URL 필드, HTTP 버전 필드를 갖는다.

방식 필드는 GET, POST, HEAD, PUT, DELETE 등의 여러 가지 값을 가질 수 있다.

1. Host
   • 객체가 존재하는 호스트를 명시한다.
   • 이미 호스트까지 TCP 연결이 맺어져 있어 불필요하다고 생각될 수 있지만, 2.2.5절에서 나오는 웹 프록시 캐시에서 필요로 한다.
2. Connection : 이 헤더 라인을 포함함으로써, 브라우저는 서버에게 지속 연결 사용을 원하는지 비지속 연결 사용을 원하는지 전달한다.
3. User-agent : 서버에게 요청을 하는 브라우저 타입을 명시한다.
4. Accept-language : 헤더는 사용자가 객체의 어떤 언어 버전을 원하고 있음을 나타낸다.

GET일 때는 비어있고, POST일 때 사용된다.

POST 메시지로 사용자는 서버에 웹 페이지를 요청하고 있으나, 웹 페이지의 특정 내용은 사용자가 폼 필드에 무엇을 입력하는가에 달려 있다.

폼으로 생성한 요구가 반드시 POST일 필요는 없다. 대신에 흔히 요청된 URL의 입력 데이터를 전송한다.

HEAD 방식은 GET과 유사하다.

서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데, 요청 객체는 보내지 않는다. 흔히 디버깅을 위해 사용된다.

PUT 방식은 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용된다.

DELETE 방식은 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용한다.

다음은 전형적인 HTTP 응답 메시지를 보여준다.

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

상태 라인(status line)은 버전 필드와 상태 코드, 해당 상태 메시지를 갖는다.

상태 코드와 메시지

• 200 OK: 요청이 성공했고, 정보가 응답으로 보내졌다.
• 301 Moved Permanently: 요청 객체가 영원히 이동되었다. 이때, 새로운 URL은 응답 메시지의 Location 헤더에 나와있다.
• 400 Bad Request : 서버가 요청을 이해할 수 없다.
• 404 Not Found : 요청한 문서가 서버에 존재하지 않는다.
• 505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.

1. Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.
2. Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
3. Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.
4. Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
5. Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
6. Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.

HTTP 명세서는 많은 헤더라인을 정의하고 있고, 위는 그 중 일부다.

브라우저는 브라우저 타입과 여러 설정, 캐싱하고 있는지에 따라 헤더 라인을 동적으로 생성하고 웹 서버도 비슷하다.

HTTP 서버는 상태를 유지하지 않는다.

그러나 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하기 원하므로
사용자를 확인하는 것이 바람직할 때가 있는데, 이때 HTTP는 쿠키(cookie)를 사용한다.

over stateless HTTP, cookie provides a state related service layer

1. 웹 서버에 HTTP 요청 메시지를 전달한다.
2. 웹 서버는 유일한 식별 번호를 만들고 이 식별 번호로 인덱싱 되는 백엔드 데이터 베이스 안에 엔트리를 만든다.
3. HTTP 응답 메시지에 Set-cookie: 식별 번호의 헤더를 포함해서 전달한다.
4. 브라우저는 헤더를 보고, 관리하는 특정한 쿠키 파일에 그 라인을 덧붙인다.
5. 다시 동일 웹 서버에 요청을 보낼 때
   브라우저는 쿠키 파일을 참조하고 이 사이트에 대한 식별번호를 발췌하여 Cookie : 식별 번호의 헤더를 요청과 함께 보낸다.

이렇게 웹 서버는 사용자를 식별할 수 있다.

웹 캐시(cache)(프록시(proxy) 서버)는 기점 웹 서버를 대신하여 HTTP 요구를 충족시키는 개체이다.

Goal: satisfy client request without involving origin server

웹 캐시는 자체의 저장 디스크를 갖고 있어, 최근 호출된 객체의 사본을 저장 및 보존한다.

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다.
2. 웹 캐시는 객체의 사본이 저장되어 있는지 확인하고, 저장되어 있다면 클라이언트 브라우저로 HTTP 응답 메시지와 함께 객체를 전송한다.
3. 갖고 있지 않다면, 기점 서버로 TCP 연결을 설정한다.
   이후 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 기점 서버는 웹 캐시로 HTTP 응답 메시지를 보낸다.
4. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메시지를 보낸다. (이때, 이미 설정된 TCP를 통해 보낸다.)

캐시(cache)는 요청과 응답을 모두 하는 클라이언트이면서 서버이다.

• server for original requesting client
• client to origin server

일반적으로 웹 캐시는 ISP(university, company, residential ISP)가 구입하고 설치한다.

1. 클라이언트 요구에 대한 응답 시간을 줄일 수 있다.
   보통 클라이언트와 캐시 사이에 높은 속도의 연결이 설정되어 있어 웹서버 캐시에 객체를 갖고 있다면 병목 현상을 줄일 수 있다.
2. 웹 캐시는 한 기관에서 인터넷으로의 접속하는 링크 상의 웹 트래픽을 대폭 줄일 수 있다.
3. 인터넷 전체의 웹 트래픽을 실질적으로 줄여주어 모든 애플리케이션의 성능이 좋아진다.

• 평균 객체의 크기가 1 Mb이고, 기관 브라우저로부터 기점 서버에 대한 평균 요청 비율이 초당 15 요청이라고 가정하자.
• HTTP 메시지 요청이 무시할만큼 작으므로 네트워크 접속 회선에 어떤 트래픽도 발생시키지 않는다고 가정하자.
• 또한, 접속 회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답을 받을 때까지 평균 소요 시간을 2초라고 가정하자.
  통상 이러한 지연을 인터넷 지연이라고 한다.

총 응답 시간 = LAN 지연 + 접속 지연 + 인터넷 지연

LAN의 트래픽 강도는 다음과 같다.

(15 요청/초) X (1 Mb/요청) / 100 Mbps = 0.15

접속 회선(라우터와 라우터 사이)의 트래픽 강도는 다음과 같다.

(15 요청/초) X (1 Mb/요청) / 15 Mbps = 1

LAN의 트래픽 강도는 많아야 수십 ms의 지연을 야기하므로 LAN 지연을 무시할 수 있지만,
트래픽 강도가 1에 가까워지면 1.4절에서 논의한 것과 같이 회선의 지연은 매우 커지고 한없이 증가한다.

접속 회선의 접속률을 100 Mbps 수준으로 늘리면 트래픽 강도를 0.15로 낮추어 해결할 수 있겠지만, 매우 많은 비용이 들어간다.

웹 캐시를 사용한 예시를 보자.

캐시가 만족시킨 요청의 비율(hit rate)은 일반적으로 0.2 ~ 0.7이며, 이 예시에서는 0.4의 적중률을 가진다고 가정하자.

• 캐시와 클라이언트는 고속 LAN으로 연결되어 있어, 요청의 40%는 캐시에 의해(10ms 이내) 즉시 만족된다.
• 나머지 60%의 요청은 여전히 기점 서버에 의해 만족되어야 하므로 트래픽 강도는 1.0에서 0.6으로 감소한다.

일반적으로 0.8 미만의 트래픽 강도는 작은 지연에 속한다. (2초에 의하면 무시할 수 있는 수준이다.)

이들을 고려한 평균 지연은 다음과 같다.

0.4 X 0.01초 + 0.6 X 2.01초 = 1.2....

많은 캐시가 저렴한 PC에서 실행되는 공개 소프트웨어를 사용한다.

• 콘텐츠 전송 네트워크(CDN)을 통해 웹 캐시는 인터넷에서 점진적으로 중요한 역할을 하고 있다.
• CDN 회사는 인터넷 전역을 통해 많은 지역적으로 분산된 캐시를 설치하고 있으며,
  이를 통해 많은 트래픽을 지역화하고 있다. (전용 CDN을 사용하기도 한다.)

웹 캐싱이 사용자가 느끼는 응답 시간을 줄일 수 있지만, 웹 캐시 내부에 있는 복사본이 새 것이 아닐 수 있다는 문제를 야기한다.

복사본이 클라이언트에 캐싱된 이후 웹 서버에 있는 객체가 갱신되었을 수도 있기 때문이다.

💡 HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱해주는데,
이러한 방식을 조건부 GET(conditional GET) 이라고 한다.

Goal: don't send object if cache has up-to-date cached version

HTTP 요청 메시지가 (1) GET 방식을 사용하고, (2) If-modified-since 헤더를 포함한다면, 그것이 조건부 GET이다.

   브라우저의 요청을 대신해서 프록시 캐시는 요청 메시지를 웹 서버로 보낸다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com

   웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다.

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

• 캐시는 요청하는 브라우저에게 객체를 보내주고 자신에게도 객체를 저장한다.
• 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장한다는 것이다.

    일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 캐시에 저장되어 있다.
   이 객체는 지난주에 웹 서버에서 수정되었으므로, 브라우저는 조건부 GET으로 조사를 수행한다.

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

• If-modified-since 값이 일주일 전에 서버가 보낸 Last-Modified 값과 완벽히 일치한다.
• 이 조건부 GET은 서버에게 If-modified-since에 명시된 값 이후 수정된 경우에만 그 객체를 보내라고 한다.

     변경되지 않았다면,

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

• 위와 같은 응답을 보낸다.
  데이터가 변화가 없어도 객체를 보내는 것은 대역폭을 낭비하는 것이고, 특히 그 개체가 크다면 사용자가 느끼는 응답 시간이 증가된다.
• 위 응답 메시지는 클라이언트에게 요청 객체의 캐싱된 복사본을 사용하라는 것을 의미한다.

2020년 현재 주요 웹 사이트 천만 개의 40%가 HTTP/2를 지원하고 있다.

HTTP/2의 주요 목표는 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간을 줄이는 데 있으며,
요청 우선순위화, 서버 푸시, HTTP 헤더 필드의 효율적인 압축 기능 등을 제공한다.

HTTP/2는 클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경했다.

지속적인 연결을 사용할 때 웹 페이지당 오직 하나의 TCP 연결을 가짐으로써,
아래 설명하듯이 서버에서의 소켓 수를 줄이며 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가질 수 있다.

그러나 하나의 TCP 상에서 모든 웹페이지를 보내면 HOL(Head of Line) 블로킹 문제가 발생할 수 있다.

비디오 아래 수많은 작은 객체들을 포함할 때 서버와 클라이언트 사이에 저속에서 중간 속도의 병목 링크가 있다고 하자.

비디오 클립은 병목 링크를 통과하는데 오래 걸리는 반면, 작은 객체들은 비디오 클립 뒤에서 기다림이 길어진다.

즉, 비디오 클립이 객체들을 블로킹하게 된다.

HTTP/1.1에서는 여러 개의 병렬 TCP 연결을 열어서 위 문제를 해결해왔다.

TCP 혼잡 제어는 각 TCP 연결이 공정하게 병목 링크를 공유하여 같은 크기의 가용한 대역폭을 공평하게 나누게 해준다.

만일 n개의 TCP 연결이 병목 링크에서 작동하고 있다면, 각 연결은 대략 대역폭의 1/n 씩을 사용하게 된다.

하나의 웹 페이지를 전송하기 위해 여러 개의 병렬 TCP 연결을 열게 함으로써 브라우저는 일종의 속임수로 링크 대역폭의 많은 부분을 받게 된다.

많은 HTTP/1.1 브라우저들은 6개까지 병렬 TCP 연결을 열고 HOL을 막을 뿐만 아니라 더 많은 대역폭을 사용할 수 있게 한다.

HTTP/2의 주요 목표 중 하나는 하나의 웹 페이지를 전송하기 위한 병렬 TCP 연결의 수를 줄이거나 제거하는 데 있다.

이는 서버에서 열고 유지되는 데 필요한 소켓의 수를 줄일 뿐만 아니라 목표한 대로 TCP 혼잡 제어를 제어할 수 있게 하는 데 있다.

그러나 웹 페이지를 전송하기 위해 오직 하나의 TCP 연결만을 사용하게 될 경우에 HTTP/2는 HOL 블로킹을 피하기 위해 신중하게 구현된 메커니즘이 필요하다.

💡 HTTP/2 프레이밍(framing)이란, HTTP 메시지를 독립된 프레임들로 쪼개고, 인터리빙(interleaving)하고, 반대편 사이트에서 재조립하는 것이다.

예를 들어, 비디오 클립과 크기가 작은 객체 8개의 요청이 들어오면, 서버는 9개의 객체를 보내기 위한 TCP 병렬 요청을 받게된다.

이때 (1) 비디오 클립을 1000개의 프레임으로 나누고 (2) 각 객체를 2개의 프레임으로 나누어 비디오 클립으로부터 하나의 프레임을 전송한다.

이후 프레임 인터리빙을 이용하여 각 소형 객체의 첫 번째 프레임을 보내고 이를 반복하여 HOL 블로킹을 피할 수 있다.

HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립하는 것이야말로 HTTP/2의 가장 중요한 개선점이다.

프레이밍은 HTTP/2 프로토콜의 프레임으로 구현된 다른 프레이밍 서브 계층에 의해 이루어진다.

서버가 HTTP 응답을 보내고자 할 때, 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠진다.

응답의 헤더필드는 하나의 프레임이 되고, 메시지 본문은 하나의 프레임으로 쪼개진다.

응답 프레임들은 서버의 프레이밍 서브 계층에 의해 인터리빙된 후 하나의 지속적인 TCP 연결상에서 전송된다.

프레임들이 클라이언트에 도착하면 프레이밍 서브 계층에서 처음 응답메시지로 재조립되며 브라우저에 의해 처리된다. (클라이언트에서 서버로 요청할 때도 마찬가지이다.)

각 HTTP 메시지를 독립적인 프레임으로 쪼개는 것 외에도 프레이밍 서브 계층은 프레임을 바이너리 인코딩한다.

바이너리 프로토콜은 파싱하기에 효율적이고, 더 작은 프레임 크기를 갖고, 에러에 강하다.

메시지 우선순위화는 개발자들로 하여금 요청들의 상대적 우선 순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화할 수 있게 해준다.

클라이언트가 하나의 특정 서버로 동시에 여러 개의 요청을 할 때, 각 메시지에 1에서 256 사이의 가중치를 부여함으로써 요청에 우선순위를 매길 수 있다.

높은 수치일수록 높은 우선순위를 갖는다.

서버는 가장 높은 우선순위의 요청을 위한 프레임을 제일 먼저 보낼 수 있다.

클라이언트 또한 각 의존도에 따라 메시지의 ID를 지정하여 서로 다른 메시지들 간의 의존성을 나타낼 수 있다.

HTTP/2의 또 다른 특징은 서버로 하여금 특정 클라이언트 요청에 대해 여러 개의 응답을 보낼 수 있게 해주는 데 있다.

처음 요청에 대한 응답 외에도, 서버는 클라이언트의 요청 없이도 추가적인 객체를 클라이언트에게 푸시하여 보낼 수 있다.

이는 HTML 기반 페이지가 웹 페이지를 완벽하게 구동시킬 필요가 있는 객체들을 가리킬 수 있기에 가능하다.

이러한 객체에 대한 HTTP 요청을 기다리는 대신 서버는 HTML을 분석할 수 있고, 필요한 객체들을 식별할 수 있고,
해당 객체들에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 보낸다.

서버는 해당 요청들을 기다리는 데 소요되는 추가 지연을 없앤다.

트랜스 프로토콜인 QUIC(3장에서 다룬다) 위에서 작동하도록 설계된 새로운 HTTP 프로토콜로서, 완전히 표준화된 상태는 아니다.

계층구조는 크고 복잡한 시스템의 잘 정의된 특정 부분을 논의할 수 있게 해주며, 이러한 단순화는 매우 중요하다.

시스템이 계층구조를 가질 때, 그 계층이 제공하는 서비스의 구현을 변경하는 것도 매우 쉽다.

어떤 한 계층의 구현이 변하더라도 시스템의 나머지 부분은 변하지 않는다는 것이다.

💡 계층구조의 각 계층은 (1) 그 계층에서 어떤 동작을 취하고 (2) 그 계층 바로 아래 계층 서비스를 사용함으로써 서비스를 제공한다.

네트워크 프로토콜의 설계 구조를 제공하기 위해,
네트워크 설계자는 프로토콜(프로토콜을 구현하는 네트워크 하드웨어와 소프트웨어)을 계층(layer)으로 조직한다.

즉, 각각의 프로토콜은 한 계층에 속하며, 프로토콜 계층은 소프트웨어, 하드웨어 또는 둘의 통합으로 구현할 수 있다.

• 한 계층은 상위 계층에 제공하는 서비스(service)에 관심을 갖고, 이것을 계층의 서비스 모델(service model)이라고 한다.
• 각 계층은 그 계층 내부에서 어떤 동작을 수행하거나, 직접 하위 계층의 서비스를 사용한다.

다양한 계층의 프로토콜을 합하여 프로토콜 스택(protocol stack)이라고 한다.

인터넷 프로토콜 스택은 5개 계층으로 구성된다.

물리, 링크, 네트워크, 트랜스포트, 애플리케이션 계층

아래부터 1계층 ~ 5계층

💡 네트워크 애플리케이션과 애플리케이션 계층 프로토콜이 있는 곳이다.

• 인터넷의 애플리케이션 계층이 포함하는 대표적 프로토콜은 다음과 같다.
  • HTTP : 웹 문서 요청과 전송 제공
  • SMTP : 전자메일 전송 제공
  • FTP : 두 종단 시스템 간의 파일 전송 제공
• 도메인 네임 서버(domain name server, DNS)는 이 애플리케이션 계층에 존재한다.
• 애플리케이션 계층 프로토콜은 여러 종단 시스템에 분산되어 있어서
  한 종단 시스템에 있는 애플리케이션이 다른 종단 시스템에 있는 애플리케이션과 정보 패킷(메시지, message)을 교환하는 데 이 프로토콜을 사용한다.

💡 클라이언트와 서버 간에 애플리케이션 계층 메시지를 전송하는 서비스를 제공한다.

• 트랜스포트 계층 패킷 = 세그먼트(segment)
• 트랜스포트 프로토콜의 두 가지 종류로는 다음과 같으며, 이들은 애플리케이션 계층 메시지를 전달한다.
  • TCP
    • 애플리케이션에게 연결 지향형 서비스를 제공한다.
    • 목적지로의 애플리케이션 계층 메시지 전달 보장과 흐름 제어(송신자/수신자의 속도 일치)를 포함한다.
    • 긴 메시지를 짧은 메시지로 나누고, 혼잡 제어 기능을 제공한다. (네트워크가 혼잡할 때 출발지의 전송률을 줄임)
  • UDP
    • 애플리케이션에게 비연결형 서비스를 제공한다.
    • 신뢰성, 흐름 제어, 혼잡 제어를 제공하지 않는다.

💡 한 호스트에서 다른 호스트로 데이터그램(datagram, IP의 전송 단위)을 라우팅하는 책임을 진다.

즉, 출발지와 목적지 간 일련의 패킷 스위치(인터넷에서는 라우터)를 통해 데이터그램을 라우트한다.

1. 출발지 호스트에서 인터넷 트랜스포트 계층 프로토콜(TCP 또는 UDP)은 트랜스포트 계층 세그먼트와 목적지 주소를 네트워크 계층으로 전달한다.
2. 네트워크 계층은 목적지 호스트의 트랜스포트 계층으로 세그먼트를 운반하는 서비스를 제공한다.

네트워크 계층은 IP 데이터그램의 필드를 정의하며 종단 시스템과 라우터가 이 필드에 어떻게 동작하는지를 정의하는 프로토콜, IP 프로토콜을 가지고 있다.

• 오직 하나의 IP 프로토콜이 존재한다.
• 네트워크 계층을 가진 모든 인터넷 요소는 IP 프로토콜을 수행해야만 한다.

인터넷 네트워크 계층은 라우팅 프로토콜을 포함한다.

• 라우팅 프로토콜은 출발지와 목적지 사이에서 데이터그램이 이동하는 경로를 결정한다.
• 인터넷은 네트워크의 네트워크이며, 한 네트워크 내부에서 네트워크 운용자는 원하는 어떠한 라우팅 프로토콜이라도 수행할 수 있다.

💡 전체 프레임을 한 네트워크 요소에서 이웃 네트워크 요소로 이동시킨다.

링크 계층 패킷 = 프레임(frame)

경로상의 한 노드(호스트 혹은 패킷 스위치)에서 다른 노드로 패킷을 이동하기 위해 네트워크 계층은 링크 계층 서비스에 의존해야 한다.

1. 각 노드에서 네트워크 계층은 데이터그램을 아래 링크 계층으로 보내고 링크 계층은 그 데이터그램을 경로상의 다음 노드에 전달한다.
2. 다음 노드에서 링크 계층은 그 데이터그램을 상위 네트워크 계층으로 보낸다.

링크 계층에서 제공하는 서비스는 그 링크에서 채용된 특정 링크 계층 프로토콜에 의해 결정된다.

e.g., 어떤 프로토콜은 송신 노드로부터 하나의 링크를 통해 반대편에 있는 수신 노드까지 신뢰적인 전송을 제공한다. (이는 TCP의 신뢰적인 전달 서비스와는 다름)

데이터그램은 출발지에서 목적지로 가는데 여러 링크를 거치므로, 데이터그램은 경로상의 각기 다른 링크에서 다른 링크 계층 프로토콜에 의해 처리될 수 있다.

💡 프레임 내부의 각 비트를 한 노드에서 다음 노드로 이동시킨다.

이 계층의 프로토콜들은 링크에 의존하고, 더 나아가 링크의 실제 전송 매체(꼬임쌍선, 단일 모드 광케이블 등)에 의존한다.

그림은 아래 과정의 물리적 경로를 보여준다.

1. 송신 종단 시스템의 프로토콜 스택 아래로 데이터를 보내며
2. 중간의 링크 계층 스위치와 라우터의 프로토콜 스택을 위아래로 거치고
3. 수신 종단 시스템의 프로토콜 스택 상위로 보낸다.

• 이들은 둘 다 패킷 교환기다.
• 종단 시스템과 비슷하게, 라우터와 링크 계층 스위치는 네트워킹 하드웨어와 소프트웨어를 계층으로 구성한다.
• 그러나 모든 계층을 구현하지는 않고, 일반적으로 하위 계층을 구현한다.
  (그림에서는 링크 계층 스위치가 1, 2 계층을 구현하고 라우터는 1~3 계층을 구현)
• 즉, 인터넷 라우터들은 IP 프로토콜(3계층 프로토콜)을 구현할 수 있지만, 링크 계층 스위치는 불가하다.

이는 다섯 계층 모두를 구현한다.

💡 인터넷 구조가 네트워크의 ‘가장자리’에서 그 복잡성을 유지한다.

💡 각 계층에서 패킷은 헤더 필드와 페이로드 필드(payload field)라는 두 가지 형태의 필드를 갖는다.

페이로드(payload)는 일반적으로 그 계층 상위로부터의 패킷을 말한다.

1. 송신 호스트에서 애플리케이션 계층 메시지(application-layer message, 위 그림에서의 M)는 트랜스포트 계층으로 보내진다.
2. 가장 간단한 경우, 트랜스포트 계층은 메시지에 수신 측 트랜스포트 계층에서 사용될 추가 정보인 트랜스포트 계층 헤더 정보(Ht)를 더한다.

트랜스포트 계층 세그먼트(transport-layer segment) = 애플리케이션 계층 메시지 + 트랜스포트 계층 헤더 정보

• 트랜스포트 계층 세그먼트는 애플리케이션 계층 메시지를 캡슐화한다.
• 트랜스포트 계층 헤더 정보가 포함하는 내용은 다음과 같다.
  • 수신 측의 트랜스포트 계층이 그 메시지를 적절한 애플리케이션으로 보내도록 하는 정보들
  • 메시지의 비트들이 변경되었는지 아닌지를 수신자가 결정하게 하는 오류 검출 비트

1. 트랜스포트 계층은 세그먼트를 네트워크 계층으로 보낸다.
2. 네트워크 계층은 출발지와 목적지 종단 시스템 주소와 동일한 헤더 정보(Hn)를 추가하여 네트워크 계층 데이터그램(network-layer datagram)을 만든다.

1. 데이터그램은 링크 계층으로 전달된다.
2. 링크 계층도 자신의 헤더 정보를 추가하여 링크 계층 프레임(link-layer frame)을 만든다.

캡슐화 과정은 위에서 말한 것보다 더 복잡할 수 있다.

큰 메시지는 여러 개의 트랜스포트 계층 세그먼트로 분할될 수 있으며, 그들 각각은 여러 개의 네트워크 계층 데이터그램으로 분할될 수 있다.

그러고 나서 수신 측에서 각 세그먼트는 분할된 데이터그램들로 재구성되어야 한다.

인터넷의 모든 유용성과 역동성 뒤에,
‘나쁜 친구들’이 인터넷에 연결된 컴퓨터에 해를 끼리고, 사생활을 침해하고, 우리가 의존하는 인터넷 서비스를 동작하지 못하게 함으로써
일상생활을 망가트리려고 하는 어두운 면이 있다.

네트워크 보안 분야는 나쁜 친구들이 어떻게 컴퓨터 네트워크를 공격할 수 있는가와
그러한 공격으로부터 네트워크를 방어할 수 있는가, 혹은 아예 그러한 공격에 영향을 받지 않는 새로운 구조의 설계 등을 다루는 분야다.

우리는 인터넷에서 데이터를 수신/송신하기를 원하기 때문에 장치를 인터넷에 연결한다.

불행하게도 우리에게 전달되는 데이터들 중 해로운 것들도 포함되는데, 이들을 멀웨어(malware)라고 한다.
멀웨어는 우리들의 장치에 들어가서 나쁜 영향을 미친다.

e.g., 파일 삭제, 주민번호, 비밀번호, 키스트로크(keystroke, 키보드를 누르는 것) 등의 사적인 정보를 모으는 스파이웨어를 설치
→ 이러한 정보를 모아 나쁜 친구들에게 인터넷을 통해 다시 보낸다.

면역되지 않은 호스트는 수천의 비슷한 면역되지 않은 장치들로 구성된 네트워크, 즉 봇넷(botnet)에 등록될 수 있다.
나쁜 친구들은 목표로 하는 호스트에 대해 스팸 전자메일 분해 혹은 분산 DoS(Denial of Service) 공격을 위해 이 봇넷을 제어하고 이용한다.

오늘날 널리 퍼져 있는 많은 멀웨어는 자기복제(self-replicating)를 한다.
자기복제 멀웨어는 아래의 방법을 통해 기하급수적으로 퍼질 수 있다.

1. 한 호스트에 영향을 미치면, 그 호스트에서 인터넷을 통해 다른 호스트로의 엔트리를 찾는다.
2. 새롭게 영향을 받은 호스트로부터 또 다른 많은 호스트로의 엔트리를 찾는다.

네트워크, 호스트 혹은 다른 인프라스트럭처의요소들을 정상적인 사용자가 사용할 수 없게 하는 것

웹 서버, 전자메일 서버, DNS 서버, 기관 네트워크는 DoS 공격을 받을 가능성이 있다.

만약 올바른 순서의 패킷을 공격받기 쉬운 애플리케이션 혹은 운영체제에 보내면(교묘한 메시지를 보내는 것을 포함)
그 서비스는 중단되거나, 호스트가 동작을 멈출 수도 있다.

목표 호스트의 접속 링크가 동작하지 못하도록 많은 패킷을 보내서 정당한 패킷들이 그 서버에 도달하지 못하게 한다.

1.4.2절의 지연과 손실 분석 논의를 기억해보자.

만약 서버가 R bps의 접속 속도를 갖고 있다면, 공격자는 피해를 주기 위해 대략적으로 R bps의 속도로 트래픽을 전송하면 된다.

만약 R가 매우 크다면 단일 공격 소스는 서버에 나쁜 영향을 줄 수 있는 충분한 트래픽을 발생시킬 수 없다.

더 나아가, 모든 트래픽이 하나의 소스에서 방사된다면 업스트림 라우터는 그 공격을 발견할 수 있고
트래픽이 서버에 가까이 가기 전에 그 소스로부터 모든 트래픽을 차단(block)할 수 있다.

아래 그림처럼 분산 DoS(DDoS) 공격에서 공격자는 다중의 소스를 제어하고 각 소스는 목표에 트래픽을 보낸다.

이런 방법으로 모든 제어 소스에 걸친 통합 트래픽 속도가 서비스를 무능력하게 하기 위해서는 전송률이 약 R이어야 한다.

수천개의 호스트로 구성된 봇넷을 이용하는 DDoS 공격은 오늘날 매우 흔하다.

목표 호스트에 반열림(half-open) 혹은 전열림(fully open)된 TCP 연결을 설정한다.

호스트는 가짜 연결을 처리하느라 바빠서 정상적인 연결을 받아들이는 것을 중단하게 된다.

컴퓨터 네트워크 설계자는 DoS 공격을 방어하기 위해 무엇을 할 수 있는가?

→ 세 가지 유형의 DoS 공격에는 각기 다른 방어가 필요하다.

유비쿼터스(ubiquitous) 인터넷 접속은 매우 편리하고 이동 사용자를 위한 애플리케이션이 가능하지만, 인터넷 접속은 주요한 보안 취약성을 창출했다.

무선 전송장치의 근처에 수동적인 수신자 즉, 패킷 스니퍼(packet sniffer)를 위치시킴으로써 그 수신자는 전송되고 있는 모든 패킷의 사본을 얻을 수 있다.

스니퍼는 무선 뿐만 아니라, 유선 환경에서도 배치될 수 있다.
(이더넷 LAN, 케이블 접속 기술, 인터넷에 연결되는 기관의 접속 라우터 혹은 접속 링크 등)

나쁜 친구들은 이렇게 가로챈 패킷을 오프라인으로 분석하여 비밀번호, 주민등록번호, 영업 비밀 등 모든 종류의 민감한 정보를 얻을 수 있다.

패킷 스니퍼는 수동적이기 때문에, 즉 스니퍼는 채널에 패킷을 삽입하지 않기 때문에 이를 탐지하기가 어렵다.

그래서 무선 채널로 패킷을 보낼 때 어떤 나쁜 친구가 우리 패킷의 사본을 기록하고 있을 수 있다는 가능성을 받아들여야 한다.

패킷 스니핑을 방지하기 위한 가장 좋은 방어는 암호화를 포함하는 것이다. (8장에서 다룸)

임의의 출발지 주소, 패킷 내용, 목적지 주소를 갖는 패킷을 생성하고 이 패킷을 인터넷으로 보내는 것은 매우 쉽다.

가짜 출발지 주소를 가진 패킷을 인터넷으로 보내는 능력을 IP 스푸핑(spoofing)이라고 하며,
한 사용자가 다른 사용자인 것처럼 행동하는 여러 가지 방법 중 하나다.

이 문제를 해결하기 위해서는 종단 인증(end-point authentication),
즉 메시지가 실제로 와야 할 곳으로부터 온 것인지 확신할 수 있는 방법이 필요하다.

네트워크 애플리케이션과 프로토콜의 경우 어떻게 이것을 할 수 있을까? (8장에서 다룸)

인터넷은 처음에 어떻게 보안 문제에 직면하게 되었을까?

인터넷은 원래 ‘투명한 네트워크에 연결된 상호 신뢰할 수 있는 사용자 그룹’ 모델,
즉 보안이 필요 없는 모델에 기반을 둔 방식으로 설계되었다. [Blumenthal 2001]

따라서 원래 인터넷 구조의 많은 특성은 이러한 상호 신뢰를 반영하고 있다.
e.g., 한 사용자가 패킷을 다른 사용자에게 보내는 능력은 default, 사용자 식별은 default로 인증해야 하는 것보다는 선언된 액면 그대로 믿는 것이다.

그러나 오늘날 인터넷은 ‘상호 신뢰하는 사용자’를 분명히 포함하지 않는다.

그럼에도 불구하고 오늘날의 사용자들은 서로를 꼭 신뢰하지는 않을 때, 익명으로 통신하기를 원할 때,
제3자를 통해 간접적으로 통신할 때(이동 지원 에이전트, mobility-assisting agent) 등 이러한 상황에서도 여전히 통신이 필요하다.

아직 우리 앞에는 많은 보안 관련 해결 과제가 존재한다.

우리는 스니핑, 종단 위장(end-point masquerading), 중간자 공격, DDoS 공격, 멀웨어 등에 방어하는 방법을 찾아야 한다.

💡 상호 신뢰하는 사용자 간의 통신은 일반적인 것이 아니라 예외적인 것임을 명심해야 한다.

1960년대 초의 세계 주요 통신 네트워크는 전화망이었다.

전화망이 송신자에게서 수신자로 정보를 전송하는 데 회선 교환을 사용하였다. (음성이 송수신자 간에 일정한 속도로 전송된다면 이는 적절한 선택)

각 사용자가 만드는 트래픽은 집중적(bursty)이었다.

즉, 원격 컴퓨터에 명령을 내리는 활동과 응답을 기다리고 응답을 검토하는 비활동 사이의 기간이 일정하지 않았다.

세계적으로 3개의 연구 그룹이 회선 교환을 대신할 수 있는 효율적이고 견실한 방법으로서 패킷 교환의 개념을 창안하였다.

• 1967년, 로렌스 로버츠(Lawrence Roberts)는 ARPAnet에 대한 대략의 계획을 발간하였다.
  → 첫 번째 패킷 교환 컴퓨터 네트워크이자 오늘날 공중 인터넷의 직계 원조
• 1969년, 첫 번째 패킷 스위치가 UCLA에 설치되었다.
• 1972년, ARPAnet은 약 15개의 노드로 커졌다.
  ARPAnet 종단 시스템 간에 NCP(Network-Control Protocol)라고 하는 첫 번째 호스트 간(host-to-host) 프로토콜이 완성되었다. [RFC 001]

종간 간에서 프로토콜을 사용할 수 있게 되자, 애플리케이션을 개발할 수 있게 되었다.

• 1972년, 레이 톰린슨(Ray Tomlinson)이 최초의 전자메일 프로그램을 만들었다.

초기 ARPAnet은 단일 폐쇄 네트워크였다.

즉, ARPAnet 호스트와 통신하기 위해서는 다른 ARPAnet IMP에 실제로 접속해야 했다.

1970년대 중반 초, ARPAnet과 별개의 패킷 교환 네트워크들이 생겨났다.

• DARPA의 패킷 위성 [RFC 829]
• 패킷 라디오 네트워크 [Kahn 1978]
• ALOHAnet : 하와이에 위치하는 대학들을 함께 연결하는 마이크로파 네트워크 [Abramson 1970]
• Cyclades : 루이 푸장(Louis Pouzin)이 이끈 프랑스 패킷 교환 네트워크 [Think 2012]
• 시분할 네트워크 : 1960년대 후반에서 1970년대 초반의 네트워크 [Schwartz 1977]
  e.g., Tymnet, GE Information Services 네트워크

네트워크 수가 증가함에 따라
네트워크를 연결하는 포괄 구조(상호연결 네트워크, 네트워크의 네트워크)의 개발 시기가 점차 다가왔다.

이러한 구조 원리는 TCP 프로토콜로 구체화되었다.

이는 아래의 두 가지를 결합한 것이며, 오늘날의 TCP와는 매우 다르다.

• 종단 시스템의 재전송을 통한 데이터의 신뢰적인 전송 (오늘날 TCP의 일부분으로 남겨짐)
• 전달 기능 (오늘날 IP가 수행함)

패킷 음성 같은 애플리케이션을 위한 비신뢰적이고 흐름 제어가 없는 종단 간의 전송 서비스의 중요성에 대한 인식과 결합하여
TCP에 대한 초기 실험은 TCP에서 IP를 분리하도록 했고, UDP 프로토콜을 개발하였다.

TCP, UDP, IP 같은 주요 인터넷 프로토콜은 1970년대 후반에 그 개념이 자리 잡았다.

ALOHA 프로토콜[Abramson 1970]은 지리상 분산된 사용자를 하나의 방송통신매체(라디오 주파수)를 공유하게 하는
최초의 다중 접속(multiple access) 프로토콜이다.

다중 접속 프로토콜에 대한 에이브럼슨의 연구는
유선 기반 공유 브로드캐스트 네트워크를 위한 이더넷 프로토콜[Metcalfe 1976] 개발에서 멧칼프(Metcalfe)와 보그스(Boggs)에 의해 발전되었다.

즉, PC 혁명과 네트워크 폭발이 있기 훨씬 전인 25년 전, 이들은 오늘날의 PC LAN의 기초를 닦고 있었다.

• 1970년대 말까지 약 200개의 호스트가 ARPAnet에 연결되었다.
• 1980년대 말까지 공중 인터넷(네트워크 연합)에 연결된 호스트 수는 십만 개에 이르렀다.

이처럼 1980년대는 거대한 성장 시대였는데, 이러한 성장의 주요인은 대학들을 연결하는 컴퓨터 네트워크를 만드는 여러 노력이었다.

• CSNET(Computer Science Network) : ARPAnet에 접속하지 않고 대학 연구자들을 연결하기 위해 만들어졌다.
• 1986년, NSFNET(National Science Foundation Network)이 NSF이 지원하는 슈퍼컴퓨터센터에 접속 가능하도록 만들어졌다.
• 56 kbps의 초기 백본으로 시작하여 NSFNET의 백본은 1980년대 말에 1.5 Mbps로 동작하게 되었으며, 지역 네트워크를 연결하는 주요 백본이 되었다.

ARPAnet 커뮤니티에서 오늘날 인터넷 구조의 많은 구성요소가 등장했다.

• 1983년 1월 1일, APRAnet의 새로운 표준 호스트 프로토콜인 TCP/IP가 공식 설치되었다. (NCP 프로토콜을 대체)
• NCP에서 TCP/IP로의 전환[RFC 801]은 플래그 데이(flag day) 형태의 사건이었다. 즉, 모든 호스트는 같은 날 동시에 TCP로 전환해야 했다!

1980년대 후반에 호스트 기반의 혼잡 제어를 구축하기 위해 TCP에 중요한 확장이 이루어졌다. [Jacobson 1988]

• 도메인 네임 시스템(domain name system, DNS)의 개발 [RFC 1034]
• 이는 도메인(사람이 읽을 수 있는 인터넷 이름, e.g., jw.edu, euna.com)과 32비트 IP 주소 간의 매핑에 사용된다.

1980년대 초 프랑스에서는 데이터 네트워킹을 모든 가정으로 보급하려는 미니텔(Minitel) 프로젝트를 시작했다.

• 공중 패킷 교환 네트워크 (가상 회선 방식을 사용하는 X.25 프로토콜 스택에 기반을 둠)
• 미니텔 서버와 내장형 저속 모뎀을 포함하는 값싼 터미널로 구성되었다.
• 1984년, 프랑스 정부가 원하는 모든 가정에 무상으로 미니텔 단말기를 제공하고 큰 성공을 거두었다.
• 미니텔 사이트는 전화번호 사이트 같은 무료 사이트와 사용자가 사용량에 따라 요금을 받는 사설 사이트를 포함했다.

1990년대는 인터넷의 지속 발전화 상업화를 상징하는 두 사건으로 대변된다.

1. 인터넷이 원조인 ARPAnet이 더 이상 존재하지 않게 되었다. (1991년에 NSFNET 상업화 제한을 풀었음)
2. 월드와이드웹(World Wide Web, WWW)이 출현하였다.

웹은 검색, 인터넷 상거래, 소셜 네트워크 등을 포함하는 수백 가지의 새 애플리케이션을 만들고 보급하는 플랫폼으로 등장했다.

• 1989~1991년, 팀 버너스 리(Tim Berners-Lee)가 CERN에서 처음으로 만들었다. [Berners-Lee 1989]
• 웹의 네 가지 주요소(HTML, HTTP, 웹 서버, 브라우저)의 초기 버전을 개발하였다.
• 이는 1940년대의 바내바르 부시(Vannevar Bush)와 1960년대 이후의 테드 넬슨(Ted Nelson)이 개발한
  하이퍼텍스트에 관한 초기 연구의 아이디어를 바탕으로 하였다.
• 1993년 말에 약 200개의 웹 서버가 동작 중이었다.

이 시기, 여러 연구자가 GUI 인터페이스형 웹 브라우저를 개발하고 있었으며,
크고 작은 회사가 웹 서버를 운영했고 웹을 통한 상거래를 시작했다.

1990년대 후반은 인터넷의 큰 성장과 혁신의 시대이다.

세기가 끝나는 시점에서 인터넷은 다음 4개의 킬러 애플리케이션을 포함해서 수백 개의 인기 있는 애플리케이션을 지원하게 된다.

• 첨부물과 웹 접속 전자메일을 포함하는 전자메일
• 웹 브라우징과 인터넷 상거래를 포함하는 웹
• 대화상대 목록을 가진 인스턴트 메시징
• 냅스터(Napster)가 개척한 P2P를 통한 MP3 파일 공유

21세기 첫 20년 동안에 인터넷에 연결된 스마트폰과 함께 인터넷보다 사회를 더 변화시킨 기술은 없었다.

그리고 컴퓨터 네트워킹에서의 혁신은 빠른 속도로 계속되어 있다.

그러나 다음의 개발들은 특별한 관심을 끌고 있다.

• 가정에 광대역 인터넷 접속의 공격적인 구축을 목격하고 있다.
  (케이블 모뎀과 DSL뿐만 아니라 그리고 이제는 5G 무선 서비스 포함)

• 고속 무선 인터넷 접속의 빠른 보급
  • 이를 통해 네트워크에 지속적으로 접속할 수 있을 뿐만 아니라, 엘프(Yelp), 틴더(Tinder), 와즈(Waz) 같은
    새로운 위치 기반 애플리케이션이 가능해졌다.
  • 인터넷에 연결되는 무선 장치 수는 2011년에 유선 장치의 수를 초과하였다.

• 페이스북, 인스타그램, 트위터 등 온라인 소셜 네트워크는 인터넷상에 거대한 사람들의 네트워크를 생성했다.
  • API를 통해 온라인 소셜 네트워크는 모바일 결제를 포함하는 새로운 네트워크 애플리케이션과 분산 게임용 플랫폼을 생성한다.

• 1.3.3절에서 논의한 바와 같이 구글와 마이크로스프트 같은 온라인 서비스 제공자는 자신의 커다란 사설 네트워크를 구축하였다.
  • 이는 전 세계적으로 분산된 자신들의 데이터 센터를 연결할 뿐만 아니라
    하위 계층 ISP와 직접 연결(peering)함으로써 가능한 한 많은 인터넷을 우회하는 데 사용된다.
  • 그 결과 구글의 데이터 센터가 마치 사용자의 컴퓨터 내에서 동작하는 것처럼, 구글은 거의 즉각적으로 검색 결과와 전자메일 접속을 제공한다.

• 클라우드 회사는 애플리케이션에 확장 가능한 컴퓨팅과 저장 환경을 제공할 뿐만 아니라, 고성능 사설 네트워크 접속도 제공한다.
  • 많은 인터넷 상거래 회사는 ‘클라우드’에서 자신의 애플리케이션을 수행하고 있다. (아마존의 EC2, 마이크로소프트의 Azure, 알리바바 클라우드)
  • 많은 회사와 대학도 그들의 인터넷 애플리케이션(e.g., 전자메일과 웹 호스팅)을 클라우드로 이동했다.