Transport Layer

전송 계층

• 4계층
• 종단 간(프로세스 간) 통신
• TCP, UDP

계층: 기능

• 물리 계층
– 비트를 신호로 변환하고 신호에서 비트를 복구합니다.
– 인코딩/디코딩, 변조/복조
• 데이터 링크 계층
– 물리적으로 연결된 노드 간에 비트를 올바르게 전송합니다.
– 프레임 구성, 오류 검출/정정, ARQ, 매체 접근 제어
• 네트워크 계층
– 다중 네트워크를 통한 종단 간 전달 가능
– 전역 주소 지정, 라우팅, 단편화/재조립
• 전송 계층
– 프로세스 간(종단 호스트에서) 데이터를 올바르게 전송합니다.
– 신뢰성 있는 통신, 유량 제어, 혼잡 제어

프로세스 간 통신?

• 통신이 필요한 많은 프로세스(응용 프로그램)가 단일 호스트에 존재할 수 있습니다.
• 네트워크 계층은 IP 주소에 따라 패킷을 전달합니다.
– 패킷이 어느 프로세스에 속하는지는 알 수 없습니다.
• 패킷은 전송 계층의 "포트(port)"에 수신 대기 중인 프로세스에 전달됩니다.

포트

• 호스트에서 실행 중인 프로세스를 식별하는 데 사용됩니다.
• 16비트 숫자(0~65,535)
• 프로세스 간 통신에 필요한 정보 – 로컬 호스트
– 로컬 프로세스(포트 번호)
– 원격 호스트
– 원격 프로세스(포트 번호)

포트 번호

• 잘 알려진 포트
– 포트 번호 0-1023
– IP 주소를 할당하는 기관인 IANA에서 관리 – 예: 21(FTP), 22(SSH), 23(telnet), 25(SMTP), 80(HTTP)
• 등록된 포트
– 포트 번호 102449151
– IANA에서 등록되지만 강제되지는 않음
• 동적 포트
– 포트 번호 49152~65535 – 관리되지 않으며 자유롭게 사용 가능

소켓

• 프로세스 간 통신에 사용되는 데이터 구조
• 소켓 주소 = IP 주소 + 포트 번호

전송 계층 프로토콜
• 연결 지향 vs. 비연결
– 연결 지향
• 통신 전에 (논리적인) 연결을 설정합니다(TCP).
– 비연결
• 연결 없이 통신이 진행됩니다(UDP).
• 신뢰성 있음 vs. 신뢰성 없음
– 신뢰성 있음
• 메시지가 순서대로 오류 없이 수신됩니다(TCP).
– 신뢰성 없음
• 오류 제어 없이 순서를 유지하지 않습니다(UDP).

오류 제어

• 데이터 링크 계층의 오류 제어
– 물리 링크를 통과한 후 비트가 올바르게 수신됩니다.
– 호스트/라우터에서의 패킷 손실을 막을 수 없습니다.
• 목적지 도달 불가능, 시간 초과 등의 손실
• 신뢰성 있는 프로세스 간 통신을 위해 전송 계층에서도 오류 제어가 필요합니다.

• 데이터 링크에서의 오류 제어의 한계
• 전송 계층 프로토콜

전송 계층 프로토콜은 네트워크 상에서 프로세스 간의 통신을 제공합니다. 이를 위해 전송 계층은 다양한 기능과 프로토콜을 제공합니다. 몇 가지 중요한 프로토콜을 살펴보겠습니다.

1. TCP (Transmission Control Protocol): 연결 지향적이고 신뢰성 있는 프로토콜로, 전송 중 발생한 패킷 손실이나 에러를 검출하고 복구합니다. 순서가 보장되며, 중복된 패킷이나 재전송이 발생하지 않도록 합니다. TCP는 흐름 제어와 혼잡 제어 메커니즘을 사용하여 네트워크 혼잡을 관리합니다.
2. UDP (User Datagram Protocol): 비연결 지향적이고 신뢰성 없는 프로토콜로, 단순한 데이터 전송을 제공합니다. UDP는 패킷의 오류 검출만 수행하고, 순서 제어나 재전송은 하지 않습니다. 따라서 신뢰성이 중요하지 않은 응용 프로그램에서 사용됩니다.

전송 계층 프로토콜은 응용 프로그램에서 필요한 통신 요구 사항에 맞게 선택되고 사용됩니다. TCP는 웹 브라우저, 이메일, 파일 전송 등과 같이 신뢰성과 순서가 보장되어야 하는 응용 프로그램에서 주로 사용됩니다. UDP는 스트리밍, 실시간 음성 통화, DNS 등과 같이 신속한 전송이 중요한 응용 프로그램에서 사용됩니다.

전송 계층 프로토콜은 네트워크의 상위 계층에 있는 응용 프로그램과 함께 작동하여 안정적이고 효율적인 통신을 제공합니다.

UDP (User Datagram Protocol)

UDP (User Datagram Protocol)은 매우 간단한 전송 계층 프로토콜입니다. UDP는 연결을 설정하지 않으며 신뢰성을 보장하지 않는 특징을 가지고 있습니다. UDP의 기능은 다음과 같습니다:

• 포트를 통한 프로세스 분리: UDP는 포트를 사용하여 프로세스 간의 분리를 실현합니다. 이를 통해 다중화와 역다중화가 가능합니다.
• 원시적인 오류 감지: UDP는 체크섬(checksum)을 이용하여 간단한 오류 감지 기능을 수행합니다.

UDP 헤더는 다음과 같은 필드로 구성됩니다:

• 소스 포트 번호/목적지 포트 번호: 각각 16비트입니다.
• 총 길이: UDP 패킷의 길이로, IP 패킷 길이에서 IP 헤더 길이를 뺀 값입니다.
• 체크섬: 오류 감지를 위해 사용됩니다.

UDP는 연결 설정이나 해제 과정이 없으며, 목적지 IP 주소와 포트로 패킷을 전달합니다. UDP 패킷은 "데이터그램(datagrams)"이라고도 불리며, 각 데이터그램은 독립적으로 처리됩니다. 순서 번호나 중복성 검출 등의 기능은 없습니다.

UDP는 전송 계층에서 흐름 제어나 오류 제어가 필요하지 않은 응용 프로그램에서 사용됩니다. 멀티미디어 스트리밍, 흐름 제어와 오류 제어가 이미 구현된 프로세스(TFTP), 멀티캐스트 응용 프로그램, 관리 프로토콜(SNMP) 등이 UDP를 사용하는 예시입니다.

UDP의 이점은 구현이 쉽고 처리 속도가 빠르다는 것입니다. UDP와 정반대인 TCP는 신뢰성과 흐름 제어를 보장하며 복잡한 프로토콜이기 때문에 처리 속도가 상대적으로 느립니다.

TCP (Transmission Control Protocol)

TCP (Transmission Control Protocol)은 연결 지향적인 프로토콜로, 연결 설정과 해제 과정을 거칩니다. 신뢰성 있는 전달을 보장하며, 메시지는 오류 없이 목적지 프로세스에 순서대로 전달됩니다.

TCP는 스트림 전달 서비스를 제공합니다. TCP는 데이터를 바이트 스트림으로 전달하며, 각 바이트에는 일련번호가 부여됩니다.

스트림 전달 서비스
• 송신 버퍼와 수신 버퍼

TCP 세그먼트
• 바이트 스트림의 일부 + TCP 헤더
• 패킷과 유사한 구조를 갖고 있으며 "세그먼트"라고 불립니다.

TCP 연결
• TCP는 연결 지향적인 프로토콜입니다.
• TCP 연결은 두 개의 프로세스 간에 양방향 통신에 사용됩니다.
• SYN(Synchronize) : 연결 설정
• FIN(Finish) : 연결 해제

TCP: 숫자

• 바이트 스트림의 각 바이트는 "바이트 번호"를 가지고 있습니다.
• 스트림의 첫 번째 바이트에는 0부터 2^32-1 사이의 임의의 번호가 할당됩니다.
  • 예시
• 6,000 바이트로 구성된 바이트 스트림이 있다고 가정합니다.
• 선택된 임의의 번호가 1,057이라면, 바이트는 1,057부터 7,056까지 번호가 매겨집니다.

TCP: 숫자
• TCP 시퀀스 번호

• 각 TCP 세그먼트는 시퀀스 번호를 가지고 있습니다.
• 시퀀스 번호는 세그먼트에 포함된 첫 번째 바이트의 바이트 번호입니다.
  • 예시
• TCP 연결에서 전송해야 할 5,000 바이트가 있고, 첫 번째 바이트의 바이트 번호가 10,001이라면, 바이트 스트림을 5개의 동일한 크기로 분할할 때 세그먼트의 시퀀스 번호는 어떻게 될까요?

TCP: 숫자
• 확인 번호 (Acknowledgement number)

• 수신자는 세그먼트를 받으면 TCP-ACK 메시지를 보냅니다.
• ACK 메시지에는 확인 번호가 포함됩니다.
• 확인 번호: 누락된 바이트 없이 수신자가 마지막으로 받은 바이트의 바이트 번호 + 1
• 수신자가 기다리고 있는 "다음으로 예상되는 바이트"와 동일합니다.
• 확인 번호가 5,643이라면, 수신자가 시작부터 바이트 #5,642까지의 모든 바이트를 누락 없이 수신한 것을 의미합니다.
  • 확인 번호 예시: 바이트 스트림이 101에서 시작한다고 가정해봅시다.
• 수신자가 바이트 101, 102, 103, 106, 107, 110을 수신했다고 가정하면,
• 다음으로 예상되는 바이트는 104입니다.

TCP: 기능

• 수신자가 수신한 바이트를 처리할 수 있도록 송신 속도를 제어합니다.
• 수신자를 고려한 흐름 제어
  • 혼잡 제어
• 네트워크 혼잡 상태에 따라 송신 속도를 조절합니다.
  • 오류 제어
• 신뢰성 있는 전달을 위해 잘못된 세그먼트를 재전송합니다.

TCP 헤더
• 옵션이 없는 경우 20바이트
• 옵션이 있는 경우 최대 60바이트
• 소스 포트/목적지 포트: UDP와 동일한 방식으로 사용됩니다. (각각 16비트)
• 시퀀스 번호 (32비트)

• 세그먼트에 포함된 첫 번째 바이트의 바이트 번호 (송신자 → 수신자)
  • 확인 번호 - 다음으로 예상되는 바이트 (수신자 → 송신자)
  • TCP는 양방향입니다!
  • HLEN: 헤더 길이
• 단위: 4바이트 (IP 헤더와 유사)
  • 예약 - 사용되지 않음
  • 제어 필드
  • TCP 제어 플래그
• SYN, FIN: TCP 연결 설정/해제
• ACK: 초기 SYN 패킷을 제외하고 항상 1
• RST: 서버가 연결 해제를 원할 때 설정
• PSH: 설정되면 버퍼링된 데이터를 즉시 응용 프로그램에 전송
• URG: 이 세그먼트에는 긴급 데이터가 포함됨
  • 창 크기: 수신 측의 잔여 버퍼 크기
  • 송신자가 전송하는 데이터가 더 많으면 버퍼가 오버플로됩니다.
• 송신자는 홍보된 창 크기 이상의 데이터를 전송해서는 안 됩니다. 흐름 제어를 위해

PSH와 URG
• PSH 플래그가 설정되면 수신자는 버퍼링된 데이터를 응용 프로그램에 전송합니다.

• 원격 터미널과 같은 대화식 응용 프로그램에 사용됩니다.
  • URG 플래그가 설정되면 "긴급 데이터"가 세그먼트에 포함되어 있다는 의미입니다.
  • 긴급 데이터: 원래 바이트 스트림에 없는 데이터
• 데이터가 "긴급"하다는 의미로 세그먼트에 포함되었습니다.
  • URG 필드가 설정되면 긴급 포인터가 일반 데이터의 시작 위치를 가리킵니다.

TCP: connection setup/teardown

TCP 연결 설정
• TCP는 양방향입니다.
• 각 측은 연결을 초기화해야 합니다.
• 연결 설정: 3-way handshake (3단계 핸드쉐이크)

• 클라이언트가 서버에 SYN을 보냅니다.
• 서버가 클라이언트에 SYN+ACK를 보냅니다.
• 클라이언트가 서버에 ACK를 보냅니다.

3-way handshake (3단계 핸드쉐이크)

TCP 연결 설정
• SYN 패킷은 데이터를 전달하지 않지만 하나의 바이트 번호를 소비합니다.
• 만약 SYN 패킷의 시퀀스 번호가 8000이라면, 서버는 확인 번호로 8001을 보냅니다.
• ACK 패킷은 바이트 번호를 소비하지 않습니다.

간략 설명: SYN flooding 공격
• DoS(Denial-of-Service) 공격 중 하나입니다.
• 가짜 소스 IP 주소를 사용하여 여러 클라이언트가 서버로 SYN 패킷을 보내는 것을 가장하는 공격입니다.

• 사용자들은 서버에 연결할 수 없게 됩니다.
  • SYN flood 공격이 가능한 이유
• 서버가 SYN을 받으면 SYN+ACK를 보내고 ACK를 기다리는 상태가 됩니다. (half-open 상태)
• 서버는 반열린 상태에서 클라이언트 레코드를 저장해야 하므로 메모리를 사용합니다.

TCP 연결 해제

반닫힘 (half-close)
• 한 방향의 연결이 닫힌 상태입니다.

• 다른 방향은 여전히 열려 있습니다.
  • 클라이언트가 서버에 FIN을 보냅니다.
  • 서버는 FIN+ACK 대신에 ACK를 보냅니다.
  • 이 상태에서는 서버만 클라이언트로 데이터를 전송할 수 있습니다.
• 그 반대로는 불가능합니다.

TCP: sliding window

TCP 슬라이딩 윈도우
• 바이트는 송신 윈도우와 수신 윈도우를 사용하여 전송됩니다.

TCP 슬라이딩 윈도우
• 송신 윈도우에 관련된 변수

• LastByteAcked: 바이트를 전송하고 ACK를 받은 상태
• LastByteSent: 바이트를 전송한 상태
• LastByteWritten: 애플리케이션이 TCP로 바이트를 전송한 상태
• LastByteAcked ≤ LastByteSent ≤ LastByteWritten
  • 수신 윈도우에 관련된 변수
• LastByteRead: 애플리케이션이 TCP로부터 바이트를 읽은 상태
• NextByteExpected: 송신자로부터 받아야 하는 다음 바이트
• LastByteRcvd: 마지막으로 받은 바이트 (빠진 바이트는 고려하지 않음)
• LastByteRead < NextByteExpected ≤ LastByteRcvd + 1
  • 송신 윈도우 범위
• LastByteAcked부터 LastByteSent까지
• ACK가 도착하면 윈도우가 오른쪽으로 슬라이딩합니다.
• 더 많은 바이트를 전송할 수 있게 됩니다.
• 송신 윈도우 크기는 플로우 컨트롤과 혼잡 컨트롤에 따라 결정됩니다.
  • 송신자는 슬라이딩 윈도우 내의 바이트를 전송합니다.
• 윈도우 바깥의 바이트는 전송할 수 없습니다.
  • 슬라이딩 윈도우 왼쪽: 전송 및 확인된 바이트
  • 슬라이딩 윈도우 내부: 전송 가능한 바이트
  • 슬라이딩 윈도우 오른쪽: 전송할 수 없는 바이트
  • 슬라이딩 윈도우 크기: min(rwnd, cwnd)
  • cwnd (혼잡 윈도우): 네트워크 상태에 따라 달라집니다. • rwnd (수신 윈도우): 수신자 상태에 따라 달라집니다.
• 광고된 윈도우

TCP 슬라이딩 윈도우: 예시
• 수신 호스트 B는 5,000바이트 크기의 버퍼를 가지고 있습니다.
• 현재 버퍼에는 처리되지 않은 데이터가 1,000바이트 들어 있습니다.
• B의 광고된 윈도우(rwnd)는 얼마입니까?
• 5000–1000=4000
• rwnd가 3,000바이트이고, cwnd가 3,500바이트인 경우
• 결과적인 윈도우 크기는 어떻게 됩니까?

• min(rwnd, cwnd) = 3,000

TCP

TCP
• 연결 지향적인 프로토콜

• 연결 설정: 3-way handshake
• 연결 해제
  • 슬라이딩 윈도우
• 윈도우 내의 바이트는 전송될 수 있음
• 바이트가 확인되면 윈도우가 오른쪽으로 이동함
  • 목표
• 신뢰성 있는 전달
• 빠른 전달

슬라이딩 윈도우 크기
• 송신 속도는 슬라이딩 윈도우 크기에 의존함
• 큰 슬라이딩 윈도우 → 송신자는 바이트를 빠르게 전송함
• 작은 슬라이딩 윈도우 → 송신자는 바이트를 느리게 전송함
• 그렇다면 왜 항상 큰 슬라이딩 윈도우를 사용하지 않을까요?
• 송신 속도가 너무 빠른 경우

• 라우터에서 패킷이 손실될 수 있음
• 수신자에서 패킷이 손실될 수 있음
• 패킷 손실 → 재전송 → 대역폭 낭비
  • 송신 속도가 너무 느린 경우
• 대역폭 낭비
  • 적절한 크기는 어떻게 결정할까요?

Sliding Window Control

흐름 제어
• 수신자는 자신의 수신 버퍼에 얼마나 많은 공간이 남았는지 송신자에게 알림

• TCP 헤더의 '윈도우 크기' 필드
• 송신자는 이를 RWND(수신 윈도우)로 기록함

윈도우 크기 스케일
• 윈도우 크기 필드는 16비트로 최대 65535바이트까지 표현 가능
• 65535바이트는 윈도우 크기로는 너무 작음
• TCP 옵션에서 윈도우 스케일을 정의할 수 있음

• 윈도우 크기가 65535이고 스케일 값이 3인 경우, RWND는 65535 x 2^3 = 524280이 됨
• 최대 윈도우 스케일 값: 14

Silly Window Syndrome

• 수신 버퍼가 거의 가득 참
• 작은 advertised window(예: 10바이트)
• 송신자는 매우 작은 TCP 세그먼트를 전송함
• 작은 세그먼트 → 큰 오버헤드

• 고정 헤더(IP: 20바이트, TCP: 20바이트)
• 예: 10바이트 데이터 + 40바이트 헤더 → 80%의 오버헤드!!

세그먼트 크기
• 큰 세그먼트가 좋음
• 최대 세그먼트 크기(MSS) - 시스템 매개변수

• 기본값은 운영 체제에 의해 결정됨
• 헤더 크기와 MTU를 고려함
  • 예시
• MTU = 1500바이트
• IP 헤더(옵션 없음): 20바이트
• TCP 헤더(옵션 없음): 20바이트
• MSS: 1500 - 20 - 20 = 1460바이트

Silly Window Syndrome에 대한 해결책

• Nagle 알고리즘(송신자)

• 세그먼트 크기가 MSS보다 작을 경우 전송을 지연시킴
  • Clark 알고리즘(수신자)
• 수신 버퍼 공간이 특정 임계값 이하인 경우, 버퍼 공간이 회복될 때까지 0을 advertised window로 보냄

Nagle의 알고리즘

• 응용 프로그램이 전송할 데이터를 생성할 때
• 사용 가능한 데이터와 윈도우가 MSS보다 크거나 같으면 전체 세그먼트를 전송함
• 그렇지 않으면

• 데이터를 버퍼에 저장하고 타이머를 설정함
• 타이머가 만료되면 세그먼트 크기가 작더라도 데이터를 전송함

혼잡 제어
• 수신자의 버퍼가 비어 있더라도 라우터에서 세그먼트가 손실될 수 있음
• 라우터의 입력 속도가 출력 속도보다 빠른 경우, 버퍼가 가득 차서 지연이 증가함
• 마지막으로 버퍼가 오버플로우되면 패킷이 손실됨
• 부하가 높아지면 딜레이가 증가함. 부하가 용량에 도달하면 딜레이가 무한대가 됨
• 부하가 높아지면 처리량이 감소함

혼잡 제어: 목표
• 슬라이딩 윈도우 크기 → 부하
• 최상의 처리량을 달성하기 위해 부하를 제어함

혼잡 제어: 방법
• 라우터는 피드백을 제공할 수 없음
• TCP 혼잡 제어 방식: 경험을 통한 접근

• 혼잡 없음 → CWND(혼잡 윈도우) 증가
• 혼잡 발생 → CWND 감소
  • 혼잡의 표시 = 패킷 손실
• 가정: 패킷 손실은 다른 방법으로 발생하기 어렵다는 가정
• 이 가정은 무선 LAN(Wi-Fi)에서는 성립하지 않을 수 있음

혼잡 제어: 기본 사항
• 제어 변수: CWND

• 슬라이딩 윈도우 크기: min(RWND, CWND)
  • 단위: MSS(최대 세그먼트 크기)
  • 초기 CWND: 1 MSS
  • 초기 단계: SLOW START

느린 시작 단계
• 각 세그먼트가 ACK될 때마다 CWND를 1 MSS씩 증가시킴
• CWND는 지수적으로 증가함 → 빠른 증가
느린 시작 단계
• 각 MSS 전송(ACK)마다 CWND가 1 MSS씩 증가됨
• 각 RTT마다 CWND가 두 배로 증가함 - 지수적인 증가
느린 시작 단계
• CWND가 증가함에 따라 송신 속도도 증가함
• 어느 시점에서는 혼잡이 불가피하게 발생함 → 패킷 손실

Congestion Control

혼잡 제어
• 수신자의 버퍼가 비어 있더라도 라우터에서 세그먼트가 손실될 수 있음
• 라우터의 입력 속도가 출력 속도보다 빠른 경우, 버퍼가 가득 차서 지연이 증가함
• 마지막으로 버퍼가 오버플로우되면 패킷이 손실됨
• 부하가 높아지면 딜레이가 증가함. 부하가 용량에 도달하면 딜레이가 무한대가 됨
• 부하가 높아지면 처리량이 감소함

혼잡 제어: 목표
• 슬라이딩 윈도우 크기를 조절하여 부하를 제어함
• 최상의 처리량을 달성하기 위해 부하를 제어함

혼잡 제어: 방법
• 라우터는 피드백을 제공할 수 없음
• TCP 혼잡 제어 방식: 경험을 통한 접근

• 혼잡 없음 → CWND(혼잡 윈도우) 증가
• 혼잡 발생 → CWND 감소
  • 혼잡의 표시 = 패킷 손실
• 가정: 패킷 손실은 다른 방법으로 발생하기 어렵다는 가정
• 이 가정은 무선 LAN(Wi-Fi)에서는 성립하지 않을 수 있음

혼잡 제어: 기본 사항
• 제어 변수: CWND

• 슬라이딩 윈도우 크기: min(RWND, CWND)
  • 단위: MSS(최대 세그먼트 크기)
  • 초기 CWND: 1 MSS
  • 초기 단계: 느린 시작(Slow Start)

느린 시작 단계
• 각 세그먼트가 ACK될 때마다 CWND를 1 MSS씩 증가시킴
• CWND는 지수적으로 증가함 → 빠른 증가

타임아웃
• 각 TCP 세그먼트마다 송신자는 타이머를 유지함
• 일정 시간 동안 ACK를 받지 못하면 타임아웃이 발생함
• 타임아웃이 발생하면 해당 세그먼트는 손실된 것으로 간주됨

• 송신자는 세그먼트를 재전송함

느린 시작과 타임아웃
• 타임아웃이 발생하면
• SSThresh는 CWND/2로 설정됨

• SSThresh: 느린 시작 임계값
  • CWND는 1로 설정됨
  • 느린 시작 단계를 재시작함

느린 시작과 SSThresh
• 타임아웃 후에 CWND는 다시 증가함
• CWND가 SSThresh에 도달하면 느린 시작 단계가 종료됨
• 송신자는 혼잡 회피 단계로 들어감

혼잡 회피 단계
• 각 RTT마다 CWND를 1 MSS씩 증가시킴
• CWND += MSS * (MSS / CWND)
• 가산 증가(Additive Increase)
• 세그먼트 손실이 발생할 때까지 혼잡 회피 단계가 계속됨

혼잡 회피 단계
• 느린 시작: 지수적인 증가
• 혼잡 회피: 가산적인 증가

기본 CWND 동작

Timeout

타이머
• 송신자는 세그먼트를 보내고 일정 시간(재전송 시간 초과, RTO) 동안 ACK를 기다림
• ACK가 도착하면 타이머가 제거됨
• 타이머가 만료되기 전에 ACK가 도착하지 않으면 타임아웃이 발생하고 세그먼트가 재전송됨

재전송 시간 초과
• 송신자는 얼마나 오래 기다려야 할까요?
• RTO가 너무 짧으면

• 세그먼트가 손실되지 않았는데도 타임아웃이 발생할 수 있음
  • RTO가 너무 길면
• 세그먼트가 손실된 경우 송신자가 재전송하기 전에 너무 많은 시간을 낭비함
  • 적절한 RTO는 무엇인가요?

적절한 RTO
• 적절한 RTO: RTT(라운드 트립 타임) + 여유시간

• 여유시간은 RTT 변동을 처리하기 위해 필요함
  • TCP는 종단 간 프로토콜이므로 RTT를 정확히 알기는 어렵습니다.
  • RTT는 시간에 따라 다를 수 있음
• 중간 라우터 상태에 따라 달라짐
  • RTT를 어떻게 추정해야 할까요?
  • 적절한 여유시간은 어떻게 설정해야 할까요?

RTT 추정

• 초기 알고리즘

• 데이터를 보내고 ACK를 수신하여 RTT를 측정
  • 측정된 RTT를 "샘플 RTT"라고 함
• 지수 평균화를 사용하여 "추정 RTT" 계산
  • 추정 RTT = a 추정 RTT + (1-a) 샘플 RTT
• RTO = 2 * 추정 RTT
  • 여유시간을 추가하기 위해 추정 RTT의 두 배를 사용함

RTT 추정

• 지수 평균화
• a=7/8인 경우

타임아웃

• 초기 알고리즘: 문제점

• 세그먼트가 재전송되고 ACK가 수신되면 ACK가 원래 세그먼트인지 재전송된 세그먼트인지 알 수 없음
  • RTT 계산이 꼬일 수 있음

타임아웃
• Karn/Partridge 알고리즘

• 세그먼트가 재전송되면 해당 세그먼트에 대한 ACK를 SampleRTT로 사용하지 않음
• 지수 백오프
  • 타임아웃이 발생하면 RTO ← 2 * RTO
  • 왜 지수 백오프를 사용하는가?
• 지연이 갑자기 증가하면 모든 세그먼트가 재전송되고 타임아웃이 업데이트되지 않을 수 있음

타임아웃

• Jacobson/Karels 알고리즘

• RTT 변동을 고려함
  • 변동이 작으면 RTO를 작게 설정(작은 여유시간)
  • 변동이 크면 RTO를 크게 설정(큰 여유시간)
• 차이 = SampleRTT - 추정 RTT
• 추정 RTT = 추정 RTT + (δ * 차이)
• 편차 = 편차 + δ(|차이| - 편차)
  • δ는 0과 1 사이의 값
• RTO = 추정 RTT + 4 * 편차

Fast Retransmission and Fast Recovery

빠른 재전송
• 세그먼트가 손실되면 타임아웃이 발생하기 전에 송신자에게 알려짐
• 그러나 타임아웃이 발생하기까지 시간이 오래 걸림 - 시간 낭비
• 빠른 재전송은 세그먼트 손실을 빠르게 감지하고 세그먼트를 재전송하기 위한 방법을 제공함

빠른 재전송
• 중복 ACK
• 세그먼트에 대한 세 개의 중복 ACK - 세그먼트가 손실되었다고 간주 - 세그먼트 재전송
• 왜 세 개인가?

• IP 계층에서 순서가 바뀔 수 있음
• 따라서 단일 중복 ACK는 세그먼트 손실을 의미하지 않을 수 있음
• 세 개의 중복 ACK가 세그먼트 손실 없이 생성될 수도 있지만, 그럴 가능성은 낮음

세그먼트 손실의 표시
• 타임아웃
• 세 개의 중복 ACK
• Slow Start + 혼잡 회피 + 빠른 재전송 = TCP Tahoe (1988)

빠른 복구
• 세그먼트 손실이 감지되면 CWND가 1로 재설정됨 - 송신 속도 갑작스러운 감소
• 3개의 중복 ACK로 세그먼트 손실이 감지되면 슬로우 스타트로 돌아가지 않고 혼잡 회피 단계부터 다시 시작
• SSThresh ← CWND/2
• CWND ← SSThresh
• TCP Tahoe + 빠른 복구 → TCP Reno (1990)

TCP 혼잡 제어
• 타임아웃 → 슬로우 스타트
• 빠른 재전송 → 혼잡 회피

CWND 동작

TCP Options

TCP 옵션
• 최대 40바이트
• 각 옵션에는 KIND 및 LENGTH 필드가 있음

• Kind: 옵션 유형
• Length: 옵션의 바이트 수

TCP 타임스탬프
• 명시적인 RTT 측정
• 송신자는 세그먼트를 보내기 전에 송신 시간을 타임스탬프로 표시함
• 수신자는 ACK에 송신 시간을 복사함
• 송신자는 ACK를 받으면 송신 시간과 현재 시간을 비교하여 RTT를 계산함

TCP 타임스탬프: 필드
• Kind: 이 옵션이 어떤 옵션인지 나타냄

• TCP 타임스탬프의 인덱스는 8임
  • Length: 이 옵션의 바이트 수
• TCP 타임스탬프는 10바이트임
  • Tsval: 이 세그먼트가 송신자로부터 보내진 시간
  • Tsecr: 수신자가 Tsval을 ACK 세그먼트에 복사함
  • Tsval 및 Tsecr의 단위는 시스템에 따라 다름

TCP 타임스탬프: 동작
Time = 100 Time = 130
RTT = 130 – 100 = 30

TCP SACK
• 선택적인 확인
• 수신자가 정확히 어떤 세그먼트를 수신했는지 송신자에게 알려줌
• 송신자는 재전송해야 할 세그먼트를 확인할 수 있음

TCP SACK: 옵션 필드
• Kind=5
• Length=최대 40바이트
• 타임스탬프 옵션(10바이트)이 존재하는 경우 최대 30바이트

TCP SACK: 동작
• LeftEdge+RightEdge → 하나의 블록
• 블록은 수신된 세그먼트를 나타냄
• 예시: 세그먼트 1, 3, 7이 손실됨