TCP/IP에서 TCP와 IP에 대해 알아보자!

윤효준·2024년 8월 11일

콤퓨타 공부

목록 보기

1/17

TCP/IP는 다른 계층인데 왜 묶어서 이야기할까?

TCP와 IP는 각각 전송 계층과 네트워크 계층에서 서로 다른 역할을 수행하지만, 인터넷 통신에서는 필수적으로 함께 사용됩니다. IP는 패킷을 출발지에서 목적지로 전달하는 역할을 하며, TCP는 신뢰성, 순서 보장, 재전송 등을 통해 신뢰성 있는 데이터 전송을 보장합니다.

즉, IP는 패킷을 전달하는 도로 시스템이라면, TCP는 신뢰성 있게 데이터를 운반하는 택배 서비스라고 할 수 있습니다. 이러한 이유로 TCP와 IP는 항상 함께 사용되며, 'TCP/IP'라는 하나의 개념으로 묶여 이야기됩니다.

IP (Internet Protocol)

1. IP의 등장 배경

인터넷이 발전하면서 다양한 네트워크 간 호환성 문제를 해결하고 데이터를 전송할 표준화된 방법이 필요해졌습니다. 그 결과 IP 프로토콜이 개발되었고, 이는 네트워크 간 패킷 전달을 담당하게 되었습니다.

2. IP에서 정의한 규약

2.1 IP 주소

IP의 핵심 개념 중 하나는 IP 주소입니다.
IP 주소는 인터넷에 연결된 각 기기(컴퓨터, 서버)를 식별하는 고유한 숫자 주소입니다.
마치 집 주소가 특정 위치를 나타내듯 IP 주소는 인터넷상에서 특정 장치의 위치를 나타냅니다.

2.1.1 IP 주소의 구성

네트워크에서 사용하는 IP 주소는 크게 IPv4와 IPv6로 나뉩니다.

2.1.1.1 IPv4

IPv4는 32비트 주소 체계를 사용하며, 4개의 옥텟(8비트 블록)으로 구성됩니다.
각 옥텟은 0에서 255 사이의 숫자로 표현되며, 점(.)으로 구분됩니다.
예를 들어, 192.168.1.1은 대표적인 IPv4 주소입니다.

2.1.1.2 IPv6

IPv4 주소가 점점 부족해지면서 등장한 IPv6는 128비트 주소 체계를 사용하며, 16진수 형식으로 표현됩니다.
주소는 8개의 16비트 블록으로 나뉘고, 각 블록은 콜론(:)으로 구분됩니다.
예를 들어, 2001:0db8:85a3:0000:0000:8a2e:0370:7334와 같은 형태입니다.

2.1.2 사설 IP 주소와 NAT(Network Address Translation)

사설 IP 주소는 특정 네트워크 내부에서만 사용되는 IP 주소로, 인터넷에서는 직접 접근할 수 없습니다.
일반적으로 가정이나 회사의 네트워크에서 사용되며, 대표적인 범위는 다음과 같습니다.

10.0.0.0 ~ 10.255.255.255 (클래스 A)
172.16.0.0 ~ 172.31.255.255 (클래스 B)
192.168.0.0 ~ 192.168.255.255 (클래스 C)

특히 192.168.1.1은 많은 가정용 라우터에서 기본 게이트웨이 주소로 사용됩니다.

2.1.2.1 공인 IP 주소와 NAT의 역할

인터넷에 직접 연결되는 모든 기기는 공인 IP 주소를 가져야 합니다.
그러나 사설 IP 주소를 사용하는 네트워크 내의 모든 기기에 공인 IP 주소를 할당하는 것은 현실적으로 어렵습니다.
IP 주소 자원이 한정적이기 때문입니다.

이 문제를 해결하기 위해 NAT(Network Address Translation, 네트워크 주소 변환)이 사용됩니다.
NAT는 사설 네트워크의 IP 주소를 공인 IP 주소로 변환하여 인터넷과의 통신을 가능하게 합니다.

하지만 NAT만으로는 해결되지 않는 문제가 있습니다.
만약 여러 기기가 동시에 같은 공인 IP 주소를 사용하여 인터넷에 접속한다면, 응답이 어떤 기기의 요청인지 구별할 수 있어야 합니다.
이를 해결하기 위해 PAT(Port Address Translation, 포트 주소 변환)이 사용됩니다.

2.1.3 라우터(Router)와 NAT

라우터는 내부 네트워크와 외부 네트워크(인터넷) 간의 데이터 흐름을 관리하는 장치입니다.
NAT 기능을 수행하며, 내부 네트워크의 기기들이 인터넷에 접속할 수 있도록 도와줍니다.

2.1.3.1 라우터의 NAT 동작 과정

내부 네트워크의 기기(192.168.1.10)가 외부 서버(example.com, 93.184.216.34)에 요청을 보냅니다.
라우터는 이 요청을 받아 공인 IP 주소(예: 203.0.113.5)로 변환하여 외부로 전송합니다.
웹 서버(93.184.216.34)는 203.0.113.5로 응답을 보냅니다.
라우터는 응답을 받아 원래 요청을 보낸 내부 기기(192.168.1.10)로 전달합니다.

이 방식은 단일 기기에서만 인터넷을 사용할 경우에는 문제가 없지만,
여러 기기가 하나의 공인 IP 주소를 공유할 경우 응답을 어떤 내부 기기로 보내야 할지 알 수 없습니다.
이를 해결하는 방법이 PAT(포트 주소 변환)입니다.

2.1.3.2 PAT(포트 주소 변환)의 필요성

만약 집에서 스마트폰, 노트북, 태블릿 등 여러 기기가 동시에 인터넷을 사용한다고 가정해 보겠습니다.
이들 기기는 모두 같은 공인 IP 주소(203.0.113.5)를 사용해야 합니다.
따라서, NAT만으로는 여러 요청을 구별할 수 없고, 라우터가 각 요청을 식별할 방법이 필요합니다.

PAT는 출발지 포트 번호(Source Port Number)를 변환하여 이를 해결합니다.
즉, 같은 공인 IP 주소를 사용하는 요청이더라도 포트 번호를 통해 개별적으로 식별할 수 있습니다.

🛠 PAT 예시 (포트 매핑)

다음과 같은 시나리오를 가정해 보겠습니다.

📍 내부 네트워크 요청

노트북 (192.168.1.10:1234) → example.com(93.184.216.34:80)
스마트폰 (192.168.1.20:5678) → example.com(93.184.216.34:80)

📍 라우터에서 변환되는 형태

노트북 요청
192.168.1.10:1234 → 203.0.113.5:50001 → example.com(93.184.216.34:80)
스마트폰 요청
192.168.1.20:5678 → 203.0.113.5:50002 → example.com(93.184.216.34:80)

라우터는 내부 기기의 원래 포트 번호(1234, 5678)를 고유한 임시 포트(50001, 50002)로 변환하여 저장합니다.

2.1.3.3 PAT을 이용한 응답 처리

웹 서버(example.com, 93.184.216.34)가 203.0.113.5의 요청을 처리하고 응답을 보냅니다.
응답 패킷의 목적지는 203.0.113.5:50001 또는 203.0.113.5:50002입니다.
라우터는 저장해둔 NAT 테이블을 확인하여, 50001 → 192.168.1.10:1234로 변환하여 전달합니다.
스마트폰의 응답(50002 → 192.168.1.20:5678)도 동일한 방식으로 내부 네트워크로 전달됩니다.

즉, 라우터는 출발지 포트 번호를 변환하고, NAT 테이블을 유지함으로써 응답을 올바른 내부 기기로 전달할 수 있습니다.

2.1.3.4 NAT 테이블 구조

라우터는 변환된 정보(NAT 매핑)를 NAT 테이블에 저장합니다.

내부 IP 주소	내부 포트	공인 IP 주소	변환된 포트	대상 IP 주소	대상 포트
192.168.1.10	1234	203.0.113.5	50001	93.184.216.34	80
192.168.1.20	5678	203.0.113.5	50002	93.184.216.34	80

이 테이블을 이용해 라우터는 응답 패킷을 올바른 내부 기기로 전달할 수 있습니다.

2.2 데이터 패킷 형식

IP 프로토콜은 데이터를 패킷(Packet)이라는 단위로 전송합니다.
패킷은 여러 필드로 구성된 헤더(Header)와 데이터(Data)로 이루어져 있습니다.

2.2.1 IP 헤더의 주요 필드

IP 헤더는 패킷의 전송 과정에서 필요한 다양한 정보를 포함하고 있습니다.
각 필드는 패킷이 올바르게 전달되고, 문제가 발생했을 때 적절히 처리될 수 있도록 돕는 역할을 합니다.

버전 : IP 프로토콜의 버전을 나타내며, IPv4인지 IPv6인지 식별합니다.
헤더 길이 : IP 헤더의 총 길이를 나타냅니다.
서비스 유형 : 패킷의 우선순위를 결정하며, 지연 시간이나 신뢰성 등에 대한 정보를 포함합니다.
총 길이 : IP 패킷의 전체 크기(Header + Data)를 나타냅니다.
식별자 : IP 패킷이 분할(프래그먼트)될 경우, 이를 재조립하는 데 사용되는 고유한 식별 값입니다.
플래그 및 오프셋 : 패킷이 여러 조각으로 나뉘었을 때, 이를 추적하고 재조립하는 데 필요한 정보를 제공합니다.
TTL (Time to Live) : 패킷이 네트워크에서 머물 수 있는 최대 시간입니다. TTL 값은 라우터를 지날 때마다 감소하며, 0이 되면 패킷은 폐기됩니다. 이는 네트워크 내에서 무한 루프에 빠지는 것을 방지하기 위한 장치입니다.
Protocol : IP 패킷 안에 담긴 데이터가 어떤 상위 계층 프로토콜(TCP, UDP)에 속하는지를 나타냅니다.
출발지 주소 : 데이터를 보내는 호스트의 IP 주소입니다.
목적지 주소 : 데이터를 받는 호스트의 IP 주소입니다.
헤더 체크섬 : IP 헤더의 무결성을 검증하는 역할을 합니다.

2.2.2 패킷 분할 및 재조립

네트워크 환경에서는 한 번에 보낼 수 있는 데이터 크기가 제한됩니다.
IP는 데이터를 전송할 때, 네트워크의 최대 전송 단위(MTU, Maximum Transmission Unit)에 맞춰 데이터를 분할할 수 있도록 규정하고 있습니다.
라우터와 같은 네트워크 장비들은 패킷이 경로를 지나는 과정에서 필요에 따라 패킷을 나누거나 합칠 수 있습니다.

2.2.3 최대 전송 단위(MTU, Maximum Transmission Unit)

MTU는 네트워크에서 한 번에 전송할 수 있는 최대 데이터 패킷 크기를 의미합니다.
MTU를 초과하는 데이터는 프래그먼트(Fragment)라는 작은 단위로 분할되어 전송됩니다.

프래그먼트(분할) : IP 패킷이 너무 커서 MTU보다 클 경우, 더 작은 단위로 쪼개어 전송합니다.
재조립 : 목적지에서는 쪼개진 패킷을 다시 원래의 데이터로 복원합니다. 이 과정은 IP 헤더의 식별자와 오프셋 필드를 통해 이루어집니다.

2.2.4 패킷 분할 과정

예를 들어, MTU 값이 1500바이트인 네트워크에서 3000바이트의 데이터를 전송해야 한다면, 패킷을 나누어야 합니다.
패킷에는 IP 헤더가 추가되는데, IPv4 헤더는 일반적으로 20바이트 크기를 차지합니다.
따라서 실질적으로 전송할 수 있는 데이터 크기는 1480바이트(1500 - 20)입니다.

이를 바탕으로 패킷을 3개로 나눌 수 있습니다.

조각 번호	헤더 크기	데이터 크기
1번 조각	20바이트	1480바이트
2번 조각	20바이트	1480바이트
3번 조각	20바이트	40바이트

각 IP 헤더에는 조각을 다시 원래 순서로 조립할 수 있도록 돕는 정보가 포함됩니다.

Identification 필드 : 원본 패킷을 식별하기 위한 고유 ID. 분할된 모든 패킷 조각은 동일한 Identification 값을 가집니다.
Fragment Offset 필드 : 원래 데이터에서 해당 조각이 어디에서 시작되는지 나타냅니다. 이 값은 8바이트 단위로 계산됩니다.
More Fragments(MF) 플래그 : 추가적인 조각이 있는지를 나타냅니다. 마지막 조각에는 MF 플래그가 설정되지 않습니다.

2.2.5 중간 경로에서의 추가 분할

패킷이 전송되는 경로의 네트워크 환경에 따라 MTU 값이 다를 수 있습니다.
예를 들어, 최초 MTU가 1500바이트인 네트워크에서 전송된 패킷이 MTU 1200바이트인 네트워크로 넘어가게 되면, 기존의 패킷도 다시 나누어져야 합니다.
이때 패킷은 추가적인 헤더를 부착한 후 목적지로 전송됩니다.

추가적인 분할을 방지하기 위해 Path MTU Discovery라는 기술이 사용됩니다.
이 방법은 데이터 전송 전에 경로 상에서 가장 작은 MTU 값을 미리 확인하고, 해당 값에 맞춰 패킷 크기를 조정하는 방식입니다.

2.2.6 패킷 재조립

패킷이 목적지에 도착하면, 분할된 조각들은 다시 원래의 패킷으로 복원됩니다.
이 과정은 보통 최종 수신 호스트에서 수행됩니다.(IP 계층이 아닌 최종 목적지의 상위 계층)

각 조각의 Identification 필드를 확인
→ 동일한 Identification 값을 가진 패킷은 하나의 원본 패킷에서 분할된 조각임을 의미합니다.
Fragment Offset 필드를 이용하여 순서를 결정
→ 각 패킷 조각이 원래 데이터에서 어디에 위치해야 하는지 확인하여 올바른 순서로 정렬합니다.
MF 플래그를 확인하여 조립 완료 여부를 결정
→ MF 플래그가 설정되지 않은 패킷을 마지막 조각으로 간주하고 조립을 마무리합니다.

2.2.7 패킷 손실과 전송 방식(TCP vs UDP)

네트워크 환경에서는 패킷이 손실될 가능성이 있습니다.
이는 네트워크 혼잡, 오류 처리 문제, 패킷 시간 초과, 라우팅 문제 등으로 인해 발생할 수 있습니다.

2.2.7.1 UDP의 경우 (비연결성 프로토콜)

UDP(User Datagram Protocol)는 연결을 설정하지 않고 데이터를 전송하는 방식입니다.
패킷이 손실되더라도 재전송을 하지 않으며, 남은 데이터를 계속 전송합니다.
예: 실시간 비디오 스트리밍, 온라인 음성 통화(VoIP) 등.

2.2.7.2 TCP의 경우 (연결성 프로토콜)

TCP(Transmission Control Protocol)는 신뢰성을 보장하는 프로토콜입니다.
패킷이 손실되었을 경우, 수신 측이 송신 측에 이를 알리고 재전송을 요청합니다.
모든 패킷이 순서대로 도착해야 하며, 중복된 패킷이 수신되면 자동으로 정리됩니다.
예: 웹 페이지 요청, 파일 다운로드 등.

3. 비연결성 및 비신뢰성

IP는 비연결성과 비신뢰성을 특징으로 한다. 즉, IP는 연결을 미리 설정하지 않고 패킷을 보내기만 하면 된다.

TCP (Transmission Control Protocol)

1. TCP의 등장 배경

인터넷이 발전하면서 데이터 전송의 신뢰성을 보장하는 방법이 필요해졌습니다.
처음에는 IP와 TCP가 하나의 프로토콜로 개발되었지만, 역할이 명확해지면서 분리되었습니다.
IP는 네트워크 계층에서 패킷을 목적지까지 전달하는 역할을 하고,
TCP는 전송 계층에서 데이터의 신뢰성을 보장하는 역할을 담당하게 되었습니다.

2. TCP에서 정의한 규약

TCP(Transmission Control Protocol)는 신뢰성 있는 데이터 전송을 보장하는 프로토콜입니다.
다음과 같은 규칙을 정의하여 안정적인 데이터 전송을 가능하게 합니다.

2.1 TCP 연결 및 데이터 전송

TCP는 데이터를 전송하기 전에 송신 측과 수신 측 간의 연결 설정이 필요합니다.
연결이 설정된 후에는 양방향 통신이 이루어지고, 데이터 전송이 완료되면 연결을 종료합니다.
이 과정을 통해 TCP는 패킷 손실 방지, 데이터 순서 보장, 재전송 기능 등을 제공하여 신뢰성을 유지합니다.

2.1.1 TCP의 주요 개념

2.1.1.1 시퀀스 번호 (Sequence Number)

TCP는 데이터를 전송할 때 각 바이트에 고유한 시퀀스 번호(Sequence Number)를 부여합니다.
이 번호를 통해 송신 측이 전송한 데이터의 위치를 추적하고, 수신 측이 받은 데이터를 올바르게 정렬할 수 있습니다.

TCP 연결이 시작되면 임의의 숫자로 시퀀스 번호가 초기화됩니다.
이후 전송되는 모든 데이터는 바이트 단위로 시퀀스 번호가 증가합니다.
수신 측은 시퀀스 번호를 확인하여 데이터가 정상적으로 도착했는지 확인할 수 있습니다.

2.1.1.2 ACK 번호 (Acknowledgment Number)

ACK 번호는 수신 측이 송신 측으로부터 받은 데이터에 대해 응답하는 값입니다.
이 번호는 다음으로 받아야 할 데이터의 시퀀스 번호를 의미합니다.

수신 측은 마지막으로 받은 데이터의 시퀀스 번호에 1을 더한 값을 ACK로 응답합니다.
이를 통해 송신 측은 이전 데이터가 정상적으로 도착했는지 확인하고, 이후 데이터를 전송할 수 있습니다.

2.2 TCP 3-Way Handshake (연결 설정)

TCP는 데이터를 전송하기 전에 3-way handshake 과정을 통해 연결을 설정합니다.
이 과정에서 송신 측과 수신 측은 서로 데이터를 주고받을 준비가 되었는지 확인합니다.

2.2.1 3-Way Handshake 과정

SYN (Synchronize)
- 송신 측(Client)이 연결 요청을 보냅니다.
- SYN 패킷에는 송신 측이 선택한 시퀀스 번호가 포함됩니다.
SYN-ACK (Synchronize-Acknowledge)
- 수신 측(Server)은 연결 요청을 수락하고 응답을 보냅니다.
- SYN-ACK 패킷에는 수신 측의 시퀀스 번호와 송신 측의 시퀀스 번호 +1(ACK 번호)이 포함됩니다.
ACK (Acknowledge)
- 송신 측(Client)은 수신 측(Server)의 응답을 확인한 후 연결이 설정되었음을 알리는 패킷을 보냅니다.
- 이 패킷에는 수신 측의 시퀀스 번호 +1이 포함된 ACK 번호가 들어갑니다.

2.2.2 3-Way Handshake 예시

송신 측(Client)이 시퀀스 번호 1000인 SYN 패킷을 수신 측(Server)에게 보냅니다.

[SYN, Seq = 1000]

수신 측(Server)은 시퀀스 번호 5000인 SYN-ACK 패킷을 송신 측(Client)으로 보냅니다.

[SYN-ACK, Seq = 5000, ACK = 1001]

송신 측(Client)은 수신 측(Server)의 응답을 확인한 후 ACK 패킷을 보냅니다.

[ACK, Seq = 1001, ACK = 5001]

송신 측(Client)                                 수신 측(Server)
   |                                                 |
   | -- [SYN, Seq = 1000] -------------------------> |
   |                                                 |
   | <------------ [SYN-ACK, Seq = 5000, ACK = 1001] |
   |                                                 |
   | -- [ACK, Seq = 1001, ACK = 5001] -------------> |
   |                                                 |

이 과정이 완료되면 TCP 연결이 설정됩니다.

2.3 데이터 전송 및 신뢰성 보장

TCP는 데이터의 정확한 전달과 순서 보장을 위해 여러 가지 메커니즘을 사용합니다.

2.3.1 데이터 분할 및 세그먼트 생성

TCP는 애플리케이션에서 받은 큰 데이터를 작은 세그먼트(segment)로 나누어 전송합니다.
각 세그먼트에는 시퀀스 번호가 포함되어 있어 데이터의 순서와 위치를 추적할 수 있습니다.

2.3.2 수신 측의 ACK 응답

수신 측(Server)은 받은 데이터를 확인한 후 ACK(확인 응답) 패킷을 송신 측(Client)으로 보냅니다.
ACK 패킷에는 다음으로 받아야 할 데이터의 시퀀스 번호가 포함됩니다.

2.3.3 데이터 재전송 및 오류 복구

데이터가 손실되거나 ACK 응답이 도착하지 않으면, 송신 측(Client)은 일정 시간이 지나면 해당 데이터를 재전송합니다.
이를 통해 손실된 데이터가 자동으로 복구되며, 신뢰성 있는 전송이 가능합니다.

2.3.4 데이터 전송 예시

송신 측(Client)이 1000바이트의 데이터를 전송한다고 가정합니다.
첫 번째 데이터 패킷은 시퀀스 번호 1001로 시작됩니다.

[데이터 패킷, Seq=1001, Length=1000]

수신 측(Server)은 데이터를 받은 후 ACK를 송신 측(Client)으로 보냅니다.

[ACK, Seq=5001, ACK=2001]

송신 측(Client)은 ACK 2001을 받으면, 다음 데이터를 전송합니다.

[데이터 패킷, Seq=2001, Length=1000]

송신 측(Client)                                 수신 측(Server)
   |                                                 |
   | ----- [데이터 패킷, Seq = 1001, Length = 1000] --> |
   |                                                 |
   | <----------- [ACK, Seq = 5001, ACK = 2001] -----|
   |                                                 |
   | ----- [데이터 패킷, Seq = 2001, Length = 1000] --> |
   |                                                 |
   | <----------- [ACK, Seq = 5001, ACK = 3001] -----|
   |                                                 |

2.4 TCP 4-Way Handshake (연결 종료)

데이터 전송이 완료되면 TCP는 4-way handshake를 통해 연결을 안전하게 종료합니다.

2.4.1 4-Way Handshake 과정

TCP는 연결을 종료할 때 4-Way Handshake 과정을 수행합니다.
이 과정에서 송신 측과 수신 측은 서로 더 이상 전송할 데이터가 없음을 확인한 후 안전하게 연결을 종료합니다.

FIN (Finish)
- 송신 측(Client)은 더 이상 데이터를 전송할 필요가 없음을 알리기 위해 FIN 패킷을 보냅니다.
- FIN 패킷에는 현재 시퀀스 번호(Seq)가 포함됩니다.
ACK (Acknowledgment)
- 수신 측(Server)은 FIN 패킷을 수신한 후, 송신 측의 FIN 요청을 확인했다는 ACK 패킷을 보냅니다.
- ACK 패킷에는 송신 측의 FIN 패킷의 시퀀스 번호 +1이 포함된 ACK 번호가 들어갑니다.
- 하지만 이 시점에서 수신 측(Server)은 아직 데이터를 전송할 수도 있기 때문에 연결이 즉시 종료되지 않습니다.
FIN (Finish)
- 수신 측(Server)도 더 이상 데이터를 전송할 필요가 없음을 알리기 위해 FIN 패킷을 보냅니다.
- 이 패킷에도 현재 시퀀스 번호(Seq)가 포함됩니다.
ACK (Acknowledgment)
- 송신 측(Client)은 수신 측(Server)의 FIN 패킷을 확인한 후 ACK 패킷을 전송합니다.
- 이 ACK 패킷에는 수신 측의 FIN 패킷의 시퀀스 번호 +1이 포함된 ACK 번호가 들어갑니다.
- 이후, 송신 측(Client)은 일정 시간 동안(TIME-WAIT 상태) 대기 후 연결을 완전히 종료합니다.

2.4.2 4-Way Handshake 예시

송신 측(Client)이 더 이상 데이터를 전송할 필요가 없음을 알리기 위해 FIN 패킷을 보냅니다.

[FIN, Seq = 3001]

수신 측(Server)은 FIN 요청을 확인하고 이를 확인하는 ACK 패킷을 보냅니다.

[ACK, Seq = 5001, ACK = 3002]

수신 측(Server)도 데이터 전송이 끝났다면, 송신 측(Client)에게 FIN 패킷을 보냅니다.

[FIN, Seq = 5002]

송신 측(Client)은 수신 측(Server)의 FIN 요청을 확인한 후, 마지막으로 ACK 패킷을 보냅니다.

[ACK, Seq = 3002, ACK = 5003]
이후, 일정 시간이 지나면 연결이 완전히 종료됩니다.

송신 측(Client)                                 수신 측(Server)
   |                                                 |
   | -- [FIN, Seq = 3001] -------------------------> |
   |                                                 |
   | <----------- [ACK, Seq = 5001, ACK = 3002] -----|
   |                                                 |
   | <------------ [FIN, Seq = 5002] --------------- |
   |                                                 |
   | -- [ACK, Seq = 3002, ACK = 5003] -------------> |
   |                                                 |

2.5 혼잡 제어

네트워크에서 많은 데이터가 동시에 전송될 경우, 네트워크 장비가 처리할 수 있는 용량을 초과하여 패킷이 손실되거나 지연이 발생하는 혼잡(Congestion) 현상이 발생할 수 있습니다.
이를 방지하기 위해 TCP는 혼잡 제어(Congestion Control) 메커니즘을 사용하여 데이터 전송 속도를 동적으로 조절합니다.

혼잡 제어는 네트워크의 최적의 성능을 유지하면서도 패킷 손실을 최소화하는 것을 목표로 합니다.
이를 위해 TCP는 혼잡 상황을 감지하고, 송신 측에서 전송 속도를 조절하는 알고리즘을 사용합니다.

2.5.1 혼잡의 개념과 필요성

2.5.1.1 혼잡이란?

네트워크에서 너무 많은 데이터가 동시에 전송될 때 발생하는 현상입니다.
네트워크 장비(라우터, 스위치 등)의 처리 용량을 초과하는 데이터가 유입되면 패킷 손실, 전송 속도 감소, 높은 지연 시간 등의 문제가 발생할 수 있습니다.

2.5.1.2 혼잡 제어의 필요성

혼잡이 발생하면 패킷이 손실되거나, 재전송이 필요해지고, 전체적인 네트워크 성능이 저하됩니다.
이 문제를 해결하기 위해 TCP는 네트워크 상태를 모니터링하면서 송신 측에서 전송할 데이터의 양을 조절하는 혼잡 제어 알고리즘을 적용합니다.

2.5.2 혼잡 제어의 주요 개념

2.5.2.1 혼잡 윈도우 (`cwnd`)

TCP에서 송신 측이 한 번에 전송할 수 있는 데이터의 양을 조절하는 변수입니다.
cwnd의 크기는 네트워크 상태에 따라 동적으로 조정됩니다.
네트워크가 원활하면 cwnd는 증가하지만, 혼잡이 감지되면 cwnd를 줄여 네트워크 부하를 완화합니다.

2.5.2.2 느린 시작 임계값 (`ssthresh`)

혼잡 윈도우(cwnd)가 빠르게 증가하는 느린 시작(Slow Start) 단계에서,
어느 지점에서 속도를 조절할지 결정하는 임계값입니다.
cwnd가 ssthresh를 초과하면 혼잡 회피(Congestion Avoidance) 단계로 전환됩니다.

2.5.3 혼잡 제어의 주요 단계

TCP의 혼잡 제어는 네트워크 상황에 따라 4가지 주요 단계로 이루어집니다.

2.5.3.1 느린 시작 (Slow Start)

TCP 연결이 처음 설정되었을 때 또는 패킷 손실로 인해 재전송이 필요할 때 적용됩니다.
이 단계에서는 송신 속도를 너무 빠르게 증가시키지 않도록 조절합니다.

✅ 동작 방식
1. 처음에는 아주 작은 cwnd 값을 설정하여 데이터 전송을 시작합니다. (cwnd = 1 MSS)
2. 수신 측에서 ACK을 받을 때마다 혼잡 윈도우(cwnd)를 기하급수적으로 증가시킵니다.
3. 하지만 ssthresh에 도달하면 혼잡 회피(Congestion Avoidance) 단계로 전환됩니다.

✅ 예시

초기 cwnd = 1 MSS → ACK 수신 후 cwnd = 2 MSS
이후 ACK을 받을 때마다 cwnd = 4 MSS, 8 MSS ...
cwnd가 ssthresh에 도달하면 혼잡 회피 단계로 전환.

2.5.3.2 혼잡 회피 (Congestion Avoidance)

느린 시작 단계를 지나 네트워크가 안정적으로 동작하는 상태에서는
패킷 손실을 방지하기 위해 송신 속도를 천천히 증가시키는 단계입니다.

✅ 동작 방식
1. cwnd가 ssthresh에 도달하면, 증가 속도를 완만하게(선형적으로) 조절합니다.
2. cwnd는 매 RTT마다 한 번씩 1 MSS만 증가합니다.
3. 만약 혼잡이 발생하면, cwnd를 줄이고 혼잡 감지(Congestion Detection) 단계로 전환합니다.

✅ 예시

cwnd = 8 MSS → 다음 RTT 후 cwnd = 9 MSS
cwnd = 9 MSS → 다음 RTT 후 cwnd = 10 MSS ...

2.5.3.3 혼잡 감지 (Congestion Detection)

네트워크가 혼잡 상태에 진입했는지 감지하는 단계입니다.
혼잡을 감지하는 방식에는 타임아웃(Time-out) 방식과 중복 ACK 방식이 있습니다.

✅ 타임아웃(Time-out)

송신한 패킷이 손실되고 ACK이 오랫동안 도착하지 않으면 혼잡이 발생한 것으로 판단합니다.
이 경우 cwnd를 최소 크기(1 MSS)로 줄이고, ssthresh를 절반으로 감소시킵니다.
이후 다시 느린 시작(Slow Start) 단계로 돌아가 속도를 조절합니다.

✅ 중복 ACK (Duplicate ACK)

송신 측이 같은 ACK을 세 번 이상 연속으로 수신하면,
중간에 패킷이 손실되었다고 판단하고 빠르게 재전송을 수행합니다.

2.5.3.4 빠른 회복 (Fast Recovery)

혼잡 감지 후, 네트워크 상태가 회복될 때까지 송신 속도를 조절하는 단계입니다.
이 과정에서는 cwnd가 급격히 감소한 후, 다시 점진적으로 증가하여 원래 속도를 회복합니다.

✅ 동작 방식
1. cwnd를 혼잡 감지 시점에서 절반 크기로 감소 (cwnd = cwnd / 2)
2. 이후 cwnd를 선형적으로 증가시키며 원래 속도를 회복합니다.
3. 만약 패킷이 손실되지 않는다면, cwnd는 다시 천천히 증가하여 혼잡 회피 단계로 돌아갑니다.

✅ 예시

기존 cwnd = 16 MSS → 혼잡 감지 → cwnd = 8 MSS (감소)
이후 RTT마다 cwnd를 9 MSS, 10 MSS, ... 식으로 회복

2.5.4 혼잡 제어 알고리즘 정리

단계	동작 방식	혼잡 윈도우 증가 방식
느린 시작 (Slow Start)	초기 연결, 패킷 손실 후 재전송	기하급수적 증가 (`cwnd = cwnd × 2`)
혼잡 회피 (Congestion Avoidance)	안정적 전송 속도 유지	선형적 증가 (`cwnd = cwnd + 1`)
혼잡 감지 (Congestion Detection)	패킷 손실 감지 (타임아웃 or 중복 ACK)	`cwnd` 감소, 재전송 수행
빠른 회복 (Fast Recovery)	혼잡 이후 속도 회복	`cwnd` 절반 감소 후, 선형 증가

윤효준

작은 문제를 하나하나 해결하며, 누군가의 하루에 선물이 되는 코드를 작성해 갑니다.

다음 포스트

TCP/IP에서 TCP와 IP에 대해 알아보자!

콤퓨타 공부

TCP/IP는 다른 계층인데 왜 묶어서 이야기할까?

IP (Internet Protocol)

1. IP의 등장 배경

2. IP에서 정의한 규약

2.1 IP 주소

2.1.1 IP 주소의 구성

2.1.1.1 IPv4

2.1.1.2 IPv6

2.1.2 사설 IP 주소와 NAT(Network Address Translation)

2.1.2.1 공인 IP 주소와 NAT의 역할

2.1.3 라우터(Router)와 NAT

2.1.3.1 라우터의 NAT 동작 과정

2.1.3.2 PAT(포트 주소 변환)의 필요성

🛠 PAT 예시 (포트 매핑)

📍 내부 네트워크 요청

📍 라우터에서 변환되는 형태

2.1.3.3 PAT을 이용한 응답 처리

2.1.3.4 NAT 테이블 구조

2.2 데이터 패킷 형식

2.2.1 IP 헤더의 주요 필드

2.2.2 패킷 분할 및 재조립

2.2.3 최대 전송 단위(MTU, Maximum Transmission Unit)

2.2.4 패킷 분할 과정

2.2.5 중간 경로에서의 추가 분할

2.2.6 패킷 재조립

2.2.7 패킷 손실과 전송 방식(TCP vs UDP)

2.2.7.1 UDP의 경우 (비연결성 프로토콜)

2.2.7.2 TCP의 경우 (연결성 프로토콜)

3. 비연결성 및 비신뢰성

TCP (Transmission Control Protocol)

1. TCP의 등장 배경

2. TCP에서 정의한 규약

2.1 TCP 연결 및 데이터 전송

2.1.1 TCP의 주요 개념

2.1.1.1 시퀀스 번호 (Sequence Number)

2.1.1.2 ACK 번호 (Acknowledgment Number)

2.2 TCP 3-Way Handshake (연결 설정)

2.2.1 3-Way Handshake 과정

2.2.2 3-Way Handshake 예시

2.3 데이터 전송 및 신뢰성 보장

2.3.1 데이터 분할 및 세그먼트 생성

2.3.2 수신 측의 ACK 응답

2.3.3 데이터 재전송 및 오류 복구

2.3.4 데이터 전송 예시

2.4 TCP 4-Way Handshake (연결 종료)

2.4.1 4-Way Handshake 과정

2.4.2 4-Way Handshake 예시

2.5 혼잡 제어

2.5.1 혼잡의 개념과 필요성

2.5.1.1 혼잡이란?

2.5.1.2 혼잡 제어의 필요성

2.5.2 혼잡 제어의 주요 개념

2.5.2.1 혼잡 윈도우 (cwnd)

2.5.2.2 느린 시작 임계값 (ssthresh)

2.5.3 혼잡 제어의 주요 단계

2.5.3.1 느린 시작 (Slow Start)

2.5.3.2 혼잡 회피 (Congestion Avoidance)

2.5.3.3 혼잡 감지 (Congestion Detection)

2.5.3.4 빠른 회복 (Fast Recovery)

2.5.4 혼잡 제어 알고리즘 정리

RESTful API에 대해 알아보자!

0개의 댓글

2.5.2.1 혼잡 윈도우 (`cwnd`)

2.5.2.2 느린 시작 임계값 (`ssthresh`)