[혼자 공부하는 네트워크] 4장. 전송 계층

전송 계층 개요: IP의 한계와 포트

전송 계층은 네트워크 계층과 응용 계층 사이에 존재함

• IP 한계 보완: 신뢰할 수 잇는 통신과 연결형 통신 기능 제공
• 응용 계층의 프로세스 식별: 포트 번호 활용

IP 한계

• IP는 신뢰할 수 없는 (비신뢰성) 프로토콜(unreliable protocol)
  • 패킷이 수신지까지 제대로 전송되었다는 보장을 하지 않음
  • 통신 과정에서 패킷이 잘못 전송되어도 이를 확인하지 않고, 재전송도 하지 않으며, 순서대로 패킷이 도착할 것이라는 보장도 하지 않는다는 의미
  • 최선형 전달(best effort delivery)
   
• IP는 비연결형 프로토콜(connectionless protocol)
  • 송수신 호스트 간에 사전 연결 수립 작업을 거치지 않음
  • 그저 수신지를 향해 패킷을 보내기만 할 뿐
• IP 패킷의 전달 = 신뢰성이 없는 통신 + 비연결형 통신
• IP가 신뢰할 수 없는, 비연결형 통신을 하는 이유는, '성능'때문임
  • 신뢰할 수 있는 통신은 패킷을 하나하나 확인을 해야 하므로 성능에 악영향을 줄 수 있음
  • 신뢰성 있는 전송이 모든 경우에 필요한 것은 아님

ICMP: IP의 전송 특성을 보완하는 네트워크 계층 프로토콜

• IP 패킷 전송 과정에 대한 피드백 메시지 제공
• 피드백 메시지
  • 전송 과정에서 발생한 문제 상황에 대한 오류 보고
  • 네트워크에 대한 진단 정보(네트워크상의 정보 제공)
• ICMP 메시지 = 타입(type) + 코드(code)
  • 타입: ICMP 메시지 유형 번호
  • 코드: 구체적인 메시지 내용 번호
• 전송 과정에서 발생한 문제 상황에 대한 오류 보고 정보 내용

타입 이름(타입 번호)	코드 번호	코드 설명
수신지 도달 불가 (3): 특정 패킷이 수신지까지 도달할 수 없음을 나타냄	0	네트워크 도달 불가
	1	호스트 도달 불가
	2	프로토콜 도달 불가: 수신지에서 특정 프로토콜을 사용할 수 없음
	3	포트 도달 불가
	4	단편화가 필요하지만 DF가 1로 설정되어 단편화할 수 없음
시간 초과(11)	0	TTL 만료

 

• 네트워크에 대한 진단 정보 오류 보고 정보 내용

타입 이름(타입 번호)	코드 번호	코드 설명
에코 요청(8)	0	에코 요청
에코 응답(0)	0	에코 요청에 대한 응답
라우터 광고(9)	0	라우터 광고: 라우터가 호스트에게 자신을 알림

• '에코'는 ping 명령어를 사용
• ICMP는 IP의 보조일 뿐, 신뢰성의 완전 보장하지는 않음!
  • ICMP 메시지 자체가 유실되는 경우도 존재함

---

전송 계층의 프로토콜

TCP

• 연결형 통신을 가능하게 함
  • 송수신하는 동안에는 연결을 유지하고, 송수신이 끝나면 연결을 종료
• 신뢰성 있는 통신을 가능하게 함
  • 재전송을 통한 오류 제어, 흐름 제어, 혼잡 제어 등 다양한 기능들을 제공

UDP

• 신뢰할 수 없는 통신, 비연결형 통신을 가능하게 함
  • IP의 껍데기 역할
• TCP보다는 비교적 빠른 전송이 가능함

---

응용 계층을 식별하는 전송 계층

포트를 활용한 애플리케이션 식별

포트(port): 네트워크 상의 애플리케이션 식별 정보

전송 계층의 역할, 응용 계층 식별(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

위 그림에서 두 컴퓨터가 '사진 파일 패킷'을 주고 받을 때, 패킷이 특정 컴퓨터에 도달했다고 끝난게 아님. 패킷이 최종적으로 향해야 하는 곳은 컴퓨터가 실행 중인 수많은 프로그램 중 하나로 향해야 함.

하나의 컴퓨터가 여러 개의 프로그램을 수행하거나 프로그램 모두 네트워크를 이용 중일 수 있음

그렇기 때문에, 패킷이 최종적으로 향해야 하는 곳은 컴퓨터가 실행하는 특정 프로세스임

 

포트의 분류

TCP와 UDP 헤더 정보(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

패킷 내 수신지 포트와 송신지 포트를 통해 송수신지 호스트의 애플리케이션을 식별

• 16비트로 표현 가능한 포트의 수는 $2^{16}$(65536)개로, 할당 가능한 포트 번호는 0번~65535번
• 포트는 특정 유형에 따라 분류 가능함

1. 잘 알려진 포트(well-known port): 0번부터 1023번까지의 포트

• 시스템 포트
• 범용적으로 사용되는 애플리케이션 프로토콜이 일반적으로 사용하는 포트 번호를 의미

잘 알려진 포트 번호	설명
20, 21	FTP
22	SSH
23	TELNET
53	DNS
67, 68	DHCP
80	HTTP
443	HTTPS

 

2. 등록된 포트(registered port): 1024번부터 49151번까지의 포트

• 잘 알려진 포트에 비해서는 덜 범용적
• 흔히 사용되는 애플리케이션 프로토콜에 할당하기 위해 사용
• 인터넷 할당 번호 관리 기관(IANA): 잘 알려진 포트와 등록된 포트번호 관리
• 포트 번호는 권고 사항일 뿐 강제 사항은 아님

등록된 포트 번호	설명
1194	OpenVPN
1433	Microsoft SQL Server 데이터베이스
3306	MySQL 데이터베이스
6379	Redis
8080	HTTP 대체

 

3. 동적 포트(dynamic port), 사설 포트(private port), 임시 포트(ephemeral port): 49152번부터 65535번까지의 포트

• 특별히 관리되지 않는 포트 번호 범위: 자유롭게 사용 가능
• 서버는 대부분 잘 알려진 포트와 등록된 포트 사용
• 클라이언트는 대부분 동적 포트 사용함 ex)웹 브라우저

클라이언트의 동적 포트(출처 : https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

'특정 호스트'에서 실행 중인 '특정 애플리케이션 프로세스' 식별

IP 주소:포트번호 형식 ex) 192.168.0.15:8000

• IP 주소: 호스트 식별 → 192.168.0.15
• 포트 번호: 애플리케이션 프로세스 식별 → 8000

포트를 활용하는 기술: 포트 기반 NAT(=NAPT)

NAT: NAT 변환 테이블로, 네트워크 내부의 사설 IP와 네트워크 외부의 공인 IP 간의 변환하는 기술

• NAT 변환 테이블: 변환의 대상이 되는 IP 주소 쌍
• 사설 IP 주소 하나당 공인 IP 주소 하나가 대응: 많은 사설 IP 주소를 변환하기에는 무리가 있음
• 공인 IP 주소의 낭비: 사설 IP 주소의 수만큼 공인 IP 주소가 필요
• 이러한 문제는 포트를 이용해서 극복 가능함

포트 기반의 NAT, NAPT

• NAPT(Network Address Port Translation) 또는 APT(Address Port Translation)
• NAPT는 NAT 테이블에 변환할 IP 주소 쌍과 더불어 포트 번호도 함께 기록하고, 변환
• 하나의 공인 IP 주소(1)를 여러 사설 IP 주소(N)가 공유 가능
  • 사설 IP 주소: 공인 IP 주소를 N:1로 변환
  • 공인 IP 주소 수 부족 문제를 개선한 기술

NAPT(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

포트 포워딩(port forwarding)

 

네트워크 내부의 여러 호스트가 공인 IP 주소를 공유하는 상황에서 네트워크 외부에서 내부로 (원격 접속을 시도하는 등) 통신을 시작하는 상황에서, 외부 호스트 입장에서 어떤 IP 주소(및 포트)를 수신지 주소로 삼아야 하는지 결정하는 알려주는 기술이 '포트 포워딩'이다.

 

포트 포워딩은 네트워크 내 특정 호스트에 IP 주소와 포트 번호를 미리 할당하고, '해당 IP 주소:포트 번호'로써 해당 호스트에게 패킷을 전달하는 기능

• 특정 IP 주소와 포트 번호 쌍을 호스트에게 할당한 뒤, 외부 호스트에게 해당 접속 정보(IP 주소: 포트 번호 쌍)을 알려주면 됨

---

전송 계층의 가장 중요한 프로토콜: TCP와 UDP

TCP(Transmission Control Protocol)

신뢰할 수 있는 통신을 위한 연결형 프로토콜

 

TCP 통신 과정

TCP는 통신(데이터 송수신)하기 전에 연결을 수립하고 통신이 끝나면 연결을 종료

① 연결 수립

② 데이터 송수신 → 재전송을 통한 오류 제어, 흐름 제어, 혼잡 제어

③ 연결 종료

 

MSS(Maximum Segment Size) 단위: TCP로 전송할 수 있는 최대 페이로드 크기(TCP 헤더 크기는 제외)

 

TCP 세그먼트 구조

TCP 세그먼트 구조(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

1. 송신지 포트, 수신지 포트: 송수신하는 포트 번호

2. 순서 번호(sequence number): 순서 번호가 명시되는 필드

• 순서 번호: 송수신되는 세그먼트 데이터의 첫 바이트에 부여되는 번호로, 세그먼트의 올바른 송수신 순서를 보장하기 위한 번호

ex) 응용 계층으로부터 1900바이트 크기의 데이터를 전달받았다고 가정하고, MSS 단위가 500바이트라고 가정(4개의 세그먼트로 분할됨)

출처)https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s

• 순서 번호 = 초기 순서 번호 + 송신한 바이트 수
  • 초기 순서 번호(ISN, Initial Sequence Number)는 무작위 값
  • 세그먼트 B의 순서 번호는 초기 순서 번호인 100에서 500바이트 떨어진 셈이므로 600
  • 세그먼트 C의 순서 번호는 초기 순서 번호로부터 1000바이트 떨어진 1100
  • 세그먼트 D의 순서 번호는 초기 순서 번호로부터 1500바이트 떨어진 1600

출처)https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s

 

3. 확인 응답 번호(acknowledgment number): 상대 호스트가 보낸 세그먼트에 대한 응답

• 다음으로 수신하기를 기대하는 순서 번호가 명시(일반적으로 '수신한 순서 번호 + 1')
• 확인 응답 번호 값을 보내기 위해서는 제어 비트에서 승인을 나타내는 비트인 ACK 플래그를 1로 설정

출처)https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s

4. 제어 비트(control bits) 또는 플래그 비트(flag bits): 현재 세그먼트에 대한 부가 정보

• 기본적으로 8비트로 구성
  • ACK: 세그먼트의 승인을 나타내기 위한 비트
  • SYN: 연결을 수립하기 위한 비트
  • FIN: 연결을 종료하기 위한 비트

5. 윈도우(window): 수신 윈도우(한 번에 수신하고자 하는 데이터의 양)의 크기가 명시

 

TCP 연결 수립과 종료

연결 수립: 3-way handshake

• 쓰리 웨이 핸드셰이크 세 개의 단계로 이루어진 TCP의 연결 수립 과정

ex) 호스트 A와 B가 쓰리 웨이 핸드쉐이크를 한다고 가정

쓰리 웨이 핸드세이크 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

송수신 방향	세그먼트	세그먼트에 포함된 주요 정보	비유
A → B	SYN 세그먼트	- 호스트 A의 초기 순서 번호 - 1로 설정된 SYN 비트	'연결 시작합니다.'
B → A	SYN + ACK 세그먼트	- 호스트 B의 초기 순서 번호 - 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 SYN 비트 - 1로 설정된 ACK 비트	'네, 확인했습니다. 연결 시작해요!'
A → B	ACK 세그먼트	- 호스트 A의 다음 순서 번호 - 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트	'네, 확인했습니다.'

• 액티브 오픈(active open): 연결 시작 호스트의 연결 수립 과정
• 패시브 오픈(passive open): 연결 수락 호스트의 연결 수립 과정

연결 종료: 4-way handshake

송수신 호스트가 각각 한 번씩 FIN과 ACK를 주고받으며 TCP 연결 종료

포 웨이 핸드세이크 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

송수신 방향	세그먼트	세그먼트에 포함된 주요 정보	비유
A → B	FIN 세그먼트	- 1로 설정된 FIN 비트	'연결 끊을게요'
B → A	ACK 세그먼트	- 호스트 A가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트	'네, 확인했습니다'
B → A	FIN 세그먼트	- 1로 설정된 FIN 비트	'이제 연결 끊어요'
A → B	ACK 세그먼트	- 호스트 B가 전송한 세그먼트에 대한 확인 응답 번호 - 1로 설정된 ACK 비트	'네, 확인했습니다'

• 액티브 클로즈(active close): 종료 시작 호스트의 종료 과정
• 패시브 클로즈(passive close): 종료 수락 호스트의 종료 과정

TCP 상태(state)

현재 어떤 통신 과정에 있는지를 나타내는 정보로 상태를 유지하고 활용하는 TCP를 스테이트풀(stateful) 프로토콜이라고 부름

TCP 상태 종류(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 연결이 수립되지 않은 상태
  • CLOSED: 아무런 연결이 없는 상태
  • LISTEN: 일종의 연결 대기 상태(SYN 세그먼트를 기다리는 상태)
    • 서버로서 동작하는 패시브 오픈 호스트는 일반적으로 LISTEN 상태 유지
    • LISTEN 호스트에게 SYN 세그먼트를 보내면 쓰리 웨이 핸드셰이크 시작

(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 연결 수립 과정에서 주로 볼 수 있는 상태
  • SYN-SENT: 연결 요청을 보낸 뒤 대기하는 상태
    • 액티브 오픈 호스트가 SYN 세그먼트를 보낸 뒤 그에 대한 응답인 SYN+ACK 세그먼트를 기다리는 상태
  • SYN-RECEIVED
    • 패시브 오픈 호스트가 SYN+ACK 세그먼트를 보낸 뒤 그에 대한 ACK 세그먼트를 기다리는 상태
  • ESTABLISHED: 연결이 확립되었음을 나타내는 상태

• 연결 종료 과정에서 주로 볼 수 있는 상태
  • FIN-WAIT-1: 일반적으로 TCP 연결 종료 과정에 있어 FIN-WAIT-1은 연결 종료의 첫 단계
  • CLOSE-WAIT: 종료 요청인 FIN 세그먼트를 받은 패시브 클로즈 호스트가 그에 대한 응답으로 ACK 세그먼트를 보낸 후 대기하는 상태
  • FIN-WAIT-2: FIN-WAIT-2 상태에서 ACK 세그먼트를 받고 상대 호스트의 FIN 세그먼트를 기다리는 상태
  • LAST-ACK: CLOSE-WAIT 상태에서 FIN 세그먼트를 전송한 뒤 이에 대한 ACK 세그먼트를 기다리는 상태
  • TIME-WAIT: 액티브 클로즈 호스트가 FIN 세그먼트를 수신한 뒤, 이에 대한 ACK 세그먼트를 전송한 뒤 접어드는 상태
    • 패시브 클로즈 호스트는 마지막 ACK 세그먼트를 수신하면 CLOSED 상태로 전이
    • TIME-WAIT 상태의 액티브 클로즈 호스트는 일정 시간을 기다린 뒤 CLOSED 상태로 전이
  • CLOSING

• 간단한 명령어로 TCP 상태 확인 가능 → netstat

UDP(User Datagram Protocol)

TCP보다 신뢰성은 떨어지지만, 비교적 빠른 통신이 가능한 비연결형 프로토콜

UDP 구조(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

UDP 데이터 그램의 구조

• UDP는 TCP와 달리 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜
• 그래서 연결 수립 및 해제, 재전송을 통한 오류 제어, 혼잡 제어, 흐름 제어 등을 수행하지 않음
  • 전송 도중 일부 패킷 소실될 수 도 있음
• 상태를 유지하지도 않음: 스테이트리스(stateless) 프로토콜
• UDP는 TCP에 비해 적은 오버헤드로 패킷을 빠르게 처리
• 주로 실시간 스트리밍 서비스, 인터넷 전화처럼 실시간성이 강조되는 상황에서 TCP보다 더 많이 쓰임

TCP와 UDP의 전송 비교(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

---

TCP의 오류, 흐름, 혼잡 제어

TCP의 기능

• 재전송을 기반으로 다양한 오류를 제어
• 흐름 제어를 통해 처리할 수 있을 만큼의 데이터 송수신
• 혼잡 제어를 통해 네트워크가 혼잡한 정도에 따라 전송량 조절

재전송 기반 오류 제어

TCP 세그먼트의 체크섬 필드만으로 오류 검출하는 데 충분하지 않음

• 체크섬 필드는 데이터가 훼손된 여부만 나타내는 필드임
• 패킷이 유실되거나 잘못 전송되거나, 순서가 잘못 전송된 경우에는 오류 검출할 수 없음

TCP가 신뢰성을 제대로 보장하려면,

• 송신 호스트가 송신한 세그먼트에 문제가 발생했음을 인지할 수 있어야하고,
• 오류를 감지하게 되면 해당 세그먼트를 재전송할 수 있어야 함

TCP가 오류를 검출하고 재전송하는 상황

• 중복된 ACK 세그먼트를 수신했을 때

출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s

• 타임아웃이 발생했을 때
  • 호스트가 세그먼트를 전송할 때마다 재전송 타이머(retransimission timer) 시작
  • 타임아웃이 발생할 때까지 ACK 세그먼트를 받지 못하면 재전송

출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s

 

재전송 기법: ARQ(Automatic Repeat Request, 자동 재전송 요구)

• 수신 호스트의 답변(ACK)과 타임아웃을 토대로 문제를 진단하고,
• 문제가 생긴 메시지를 재전송함으로써 신뢰성을 확보하는 방식

[ARQ의 대표적인 세 가지 방식]

 

1. Stop-and-Wait ARQ

• 제대로 전달했음을 확인하기 전까지는 새로운 메시지를 보내지 않는 방식
• "송신하고, 확인 받고, 송신받고, 확인 받고, ..."
• 장점: 단순하지만, 높은 신뢰성을 보장
• 단점: 네트워크의 이용 효율이 낮아지고 성능이 저하됨
  • 송신 호스트(A): 확인 응답 받기 전에는 더 보내고 싶어도 못 보냄
  • 수신 호스트(B): 더 많은 데이터를 처리할 수 있어도 하나씩만 확인 응답
• 문제 해결 방법
  • 각 세그먼트에 대한 ACK 세그먼트가 도착하기 전이라도 여러 세그먼트를 보낼 수 있어야 함
  • 파이프라이닝(pipelining): 연속해서 메시지를 전송할 수 있는 기술

Stop-and-Wait ARQ(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

2. Go-Back-N ARQ

• 파이프라이닝 기반 ARQ 일종
• 여러 세그먼트를 전송 중 오류가 발생하면 해당 세그먼트부터 전부 재전송
• 순서 번호 n번에 대한 ACK 세그먼트는 'n번만의' 확인 응답이 아닌 'n번까지의 누적 확인 응답'(CACK, Cumulative Acknowledgment)

Go-Back-N ARQ(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

빠른 재전송(fast retransmit)
재전송 타이머가 만료되기 전이라도 세 번의 동일한 ACK 세그먼트를 받았다면 곧바로 재전송
- 타이머가 끝날 때까지 기다리는 시간을 줄일 수 있음

빠른 재전송(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

3. Selective Repeat ARQ

• 선택적으로 재전송, 각각의 패킷들에 대해 ACK 세그먼트를 보내는 방식
• Go-Back-N ARQ의 ACK 세그먼트가 누적 확인 응답이라면,
  Selective Repeat ARQ의 ACK 세그먼트는 개별 확인 응답(Selective Acknowledgment)
• 오늘날 대부분의 호스트는 Selective Repeat ARQ 지원
• Selective Repeat ARQ를 사용하지 않을 경우 Go-Back-N ARQ로 동작

Selective Repeat ARQ 전송(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

---

흐름제어

파이프라이닝 기반의 Go-Back-N ARQ/Selective Repeat ARQ 방식이 한 번에 무한히 많은 데이터를 보내고 받는 것은 불가능하다.

정상 동작하려면,

• 수신 호스트가 한 번에 얼마나 받아 처리할 수 있는지 반드시 고려해야 함
• 호스트가 한 번에 받아서 처리할 수 있는 세그먼트의 양에는 한계가 있기 때문
• 한 번에 n개의 바이트를 받아서 처리할 수 있다면 n바이트만 보내야 함

TCP 흐름제어는 송신 호스트가 수신 호스트의 처리 속도를 고려하며 송수신 속도를 균일하게 유지하는 기능이다.

• Stop-and-Wait ARQ를 사용하면 별도의 흐름 제어가 필요하지 않음
• 파이프라이닝 기반의 Go-Back-N ARQ/Selective Repeat ARQ에서는 흐름 제어 필요

TCP 흐름 제어 기법: 슬라이딩 윈도우(sliding window)

윈도우(window): 송신 호스트가 파이프라이닝할 수 있는 최대량

즉, 윈도우의 크기만큼 확인 응답을 받지 않고도 한 번에 전송 가능하다는 의미

윈도우 예시(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

ex)

 

첫 번째 세그먼트 ~ 네 번째 세그먼트까지가 확인 응답을 받지 않고도 전송할 수 있는 양

- 윈도우 크기에서 벗어난 숫자에 해당하는 세그먼트는 전송할 수 없음!

 

 

수신 호스트로부터 첫 번째 세그먼트에 대한 ACK 세그먼트를 받았다면,

윈도우는 오른쪽으로 한 칸 이동

 

 

수신 호스트로부터 두 번째 세그먼트에 대한 ACK 세그먼트를 받았다면,

윈도우가 점차 오른쪽으로 미끄러지듯 움직임

 

 

• 송신 측의 윈도우(송신 윈도우)도 있다.
  • 수신 호스트는 TCP 헤더(윈도우 필드)를 통해 송신 호스트에게 자신이 받을 데이터의 양을 알려줌
  • 송신 윈도우: 헤더로 전달받은 수신 윈도우 토대로 연산

흐름 제어(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

---

혼잡 제어

혼잡(congestion): 많은 트래픽으로 인해 패킷의 처리 속도가 늦어지거나 유실될 우려가 있는 네트워크 상황

 

TCP의 혼잡 제어(congestion control)

• 송신 호스트가 혼잡한 정도에 맞춰 유동적으로 전송량을 조절하는 기능
• 흐름 제어의 주체가 수신 호스트라면 혼잡 제어의 주체는 송신 호스트
• 혼잡 윈도우(congestion window): 혼잡 없이 전송할 수 있을 법한 데이터양
  • 혼잡 윈도우가 크면? 한 번에 전송할 수 있는 세그먼트 수가 많음
  • 혼잡 윈도우가 작으면? (네트워크가 혼잡한 상황) 한 번에 전송할 수 있는 세그먼트 수가 적음
• 수신 윈도우는 수신 호스트가 헤더로 알려줌
• 혼잡 윈도우는 송신 호스트가 알아서 직접 계산해서 알아내야 함

TCP의 혼잡 제어 알고리즘

혼잡 제어를 수행하는 일련의 방법

 

가장 기본적인 알고리즘인 AIMD(Additive Increase/Multiplicative Decrease)

• 합으로 증가, 곱으로 감소
• 혼잡이 감지되지 않는다면, 혼잡 윈도우를 RTT(Round Trip Time)마다 1씩 선형적으로 증가
  • RTT: 메시지를 전송한 뒤 그에 대한 답변을 받는 데까지 걸리는 시간
• 혼잡이 감지되면, 혼잡 윈도우를 절반으로 떨어뜨리는 동작을 반복
  • 중복된 ACK 세그먼트를 수신했을 때, 타임아웃이 발생했을 때 혼잡 감지함

AIMD를 고도화하는 혼잡 제어 알고리즘

 

1. 느린 시작(slow start) 알고리즘

 

• 혼잡 윈도우를 1부터 시작해 문제 없이 수신된 ACK 세그먼트 하나당 1씩 증가시키는 방식
• 혼잡 윈도우는 RTT마다 2배씩 지수적으로 증가: 초기 전송 속도 빠른 확보
• 느린 시작 알고리즘도 혼잡 윈도우를 늘릴 수 있는 한계가 있음
• 느린 시작 임계치(slow start threshold)라는 특정 값까지만 혼잡 윈도우 늘릴 수 있음

 

 

 

• 혼잡 윈도우 값이 계속 증가하다가,
  1. 혼잡 윈도우 크기가 느린 시작 임계치 이상이 되거나,
  2. 타임아웃이 발생하거나
  3. 세 번의 중복된 ACK 세그먼트를 수신하면
• 다음 세 가지 방법 중 하나 선택

상황 분류	방법
타임아웃 발생	혼잡 윈도우 값을 1로, 느린 시작 임계치를 혼잡이 감지되었을 시점의 혼잡 윈도우 값의 절반으로 초기화한 뒤 느린 시작 재개
혼잡 윈도우 >= 느린 시작 임계치	느린 시작 종료, 혼잡 회피 수행
세 번의 중복 ACK 발생	(빠른 재전송 후) 빠른 회복 수행

 

2. 혼잡 회피 알고리즘: RTT마다 혼잡 윈도우를 1MSS씩 증가시키는 알고리즘

• 혼잡 윈도우 크기 선형적으로 증가
• 느린 시작 임계치를 넘어서면 혼잡 여지가 있으니 조심해서 혼잡 윈도우 증가하기

혼잡 회피 알고리즘(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

3. 빠른 회복(fast recovery) 알고리즘: 세 번의 중복된 ACK 세그먼트를 수신하면, 빠른 재전송 + 빠른 회복 알고리즘

• 세 번의 중복 세그먼트 수신 vs 타임 아웃 → 타임 아웃이 더 큰 문제임
• 빠른 전송률 회복을 위해 느린 시작은 건너뛰고 혼잡 회피를 수행하는 알고리즘
• 단, 빠른 회복 도중이라도 타임아웃이 발생하면 다시 느린 시작을 수행

혼잡 제어 알고리즘 종합(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

 

ECN: 중간 노드의 도움으로 혼잡을 제어

• 혼잡 감지, 혼잡 윈도우 계산, 재전송은 오로지 송신 호스트의 몫이었음
• 혼잡을 회피하기 위해 네트워크 중간 장치(주로 라우터)의 도움을 받는 방법이 ECN임
• 호스트가 ECN을 지원할 경우, TCP/IP 헤더에 ECN 관련 비트 추가

ECN(출처: https://www.youtube.com/watch?v=k7G1wXTB8Fk&t=5s)

• 송신 호스트만 혼잡 제어를 수행할 경우 문제가 발생한 이후에 비로소 혼잡 제어
• ECN을 이용하면 수신 호스트의 ACK 세그먼트를 통해 더 빠르게 혼잡을 감지 가능