3.5.1 The TCP Connection
TCP 연결: 신뢰성 있는 데이터 전송을 위한 기반
TCP(Transmission Control Protocol)는 인터넷의 핵심적인 전송 계층 프로토콜로, 신뢰성 있는 데이터 전송을 제공한다.
TCP는 “연결 지향적(connection-oriented)“이라는 특징을 가지며, 데이터 전송 전에 두 프로세스가 서로 연결을 설정해야 한다.
이 연결 과정에서 데이터의 전송 및 수신을 위한 여러 상태 변수들이 설정된다.
1. 연결 지향적 (Connection-Oriented)의 의미
TCP가 연결 지향적이라는 것은, 데이터를 주고받기 전에 두 애플리케이션 프로세스가 반드시 **“핸드셰이크(handshake)”**를 통해 서로를 확인하고 연결을 설정해야 한다는 뜻이다.
이 과정을 통해 다음과 같은 사항들이 확립된다:
• 데이터 전송에 필요한 초기 조건.
• TCP 상태 변수 (예: 시퀀스 번호, ACK 번호 등).
중요한 점은, TCP의 연결은 논리적(logical) 연결이라는 것이다.
이는 회로 교환 방식(예: 전화 네트워크에서의 TDM/FDM)처럼 실제로 물리적인 경로를 예약하는 것이 아니다.
TCP 연결은 두 끝단(End Systems)의 TCP 소프트웨어가 상태 정보를 유지하며 수행된다.
반면, 라우터와 같은 중간 네트워크 장비는 TCP 연결 상태를 유지하지 않는다.
이 장비들은 TCP를 몰라도 되며, 단순히 IP 데이터그램을 전달할 뿐이다.
2. TCP의 주요 특징
1. 양방향(full-duplex) 통신:
TCP 연결이 설정되면 두 애플리케이션 프로세스(예: A 프로세스와 B 프로세스)는 양방향으로 동시에 데이터를 주고받을 수 있다.
즉, A에서 B로, 그리고 B에서 A로 데이터가 병렬로 흐릅니다.
2. 점대점(point-to-point) 연결:
TCP는 한 송신자와 한 수신자 사이의 통신만 지원한다.
이를 멀티캐스팅(multicasting)과 구분할 수 있습니다. TCP 연결에서는 항상 “두 호스트” 간의 통신만 가능하다.
3. TCP 연결 설정: 3단계 핸드셰이크
TCP 연결을 설정하는 대표적인 과정이 바로 **3단계 핸드셰이크(Three-Way Handshake)**이다.이 과정은 다음과 같이 이루어진다:
1
클라이언트 프로세스가 서버에 연결 요청을 보낸다. 이때, 클라이언트는 특별한 TCP 세그먼트를 보낸다(SYN 플래그가 활성화됨).
2
서버 프로세스는 요청을 수락하며 응답한다.
서버는 자신만의 초기 시퀀스 번호와 함께 또 다른 TCP 세그먼트를 클라이언트에 보낸다.(SYN + ACK).
3
클라이언트는 마지막으로 응답(Acknowledgment, ACK)을 보내 연결이 확립된다.
이 과정은 연결의 신뢰성을 확보하고 양측이 서로 데이터를 주고받을 준비가 되었음을 확인한다.
4. 데이터 전송과 TCP 버퍼
연결이 완료되면, 애플리케이션 프로세스는 데이터를 송신하기 시작한다.
데이터는 TCP 계층에서 처리되고 다음과 같은 과정을 거친다.
1. 송신 버퍼(Send Buffer):
• 클라이언트의 TCP는 데이터를 송신 버퍼에 저장하고, 이를 세그먼트(segment)로 나누어 전송한다.
• 세그먼트 크기는 **MSS(Maximum Segment Size)**에 의해 결정된다.
MSS는 데이터 링크 계층의 최대 전송 단위(MTU)를 고려하여 설정된다.
2. 수신 버퍼(Receive Buffer):
• 수신 측의 TCP는 세그먼트를 수신한 뒤 수신 버퍼에 저장한다. 여기서 데이터를 애플리케이션 계층으로 전달한다.
버퍼의 역할을 통해 TCP는 효율적이고 신뢰성 있는 데이터 흐름을 유지한다.
Figure 3.28: TCP 송신 및 수신 버퍼
이 그림은 TCP가 데이터를 전송하고 수신하는 과정에서 **송신 버퍼(Send Buffer)**와 **수신 버퍼(Receive Buffer)**의 역할을 명확히 보여준다.
1. 프로세스에서 TCP로의 데이터 흐름
• 왼쪽 상단을 보면 “Process writes data”라는 문구가 있다.
• 이는 애플리케이션 프로세스가 데이터를 생성하고 이를 TCP 계층에 전달하는 것을 나타낸다.
• 예를 들어, 웹 브라우저가 HTTP 요청을 생성하거나 이메일 클라이언트가 이메일 데이터를 작성해 송신하려는 경우가 이에 해당한다.
• 애플리케이션 프로세스는 데이터 소켓을 통해 TCP로 전달한다.
2. TCP 송신 버퍼 (Send Buffer)
• 데이터를 받은 TCP는 이를 바로 전송하지 않고, 먼저 **송신 버퍼(Send Buffer)**에 저장한다.
• 이 버퍼는 데이터를 세그먼트로 나누기 전 일시적으로 데이터를 보관한다.
• MSS(Maximum Segment Size):
• TCP는 송신 가능한 데이터의 최대 크기를 MSS로 제한한다.
• MSS는 TCP 세그먼트가 IP 데이터그램 안에 포함될 때, 링크 계층에서 허용되는 최대 전송 단위(MTU)에 맞추기 위해 설정된다.
일반적으로 이 값은 1460바이트(1500바이트 MTU에서 IP 및 TCP 헤더를 제외한 값)이다.
• 송신 버퍼의 역할:
• TCP는 데이터를 세그먼트 단위로 쪼개서 네트워크 계층(IP)에 전달한다.
• 이 과정에서 세그먼트에 TCP 헤더를 추가하고, IP 데이터그램으로 캡슐화한 뒤 전송한다.
3. TCP 수신 버퍼 (Receive Buffer)
• 네트워크를 통해 데이터를 수신한 TCP는 **수신 버퍼(Receive Buffer)**에 데이터를 저장한다.
• 그림의 오른쪽 “Process reads data”에서 볼 수 있듯이, 애플리케이션 프로세스는 이 버퍼로부터 데이터를 읽는다.
• 데이터의 흐름:
• 수신된 데이터가 세그먼트 단위로 도착하면, TCP는 이를 올바른 순서로 정렬한다.
• 예를 들어, 네트워크가 불안정하여 세그먼트가 순서대로 도착하지 않더라도, TCP는 시퀀스 번호를 확인해 올바른 순서로 데이터를 재배열한다.
• 재배열된 데이터는 애플리케이션에 전달된다.
4. 양방향(full-duplex) 데이터 흐름
• 그림은 양방향 데이터 흐름을 잘 보여준다:
• 왼쪽의 송신 버퍼는 송신 데이터를 처리하고, 오른쪽의 수신 버퍼는 수신 데이터를 처리한다.
• 송신 측의 데이터를 수신 측으로 보내는 동시에, 반대 방향으로도 데이터가 흐를 수 있다.
이 기능은 TCP가 “양방향(full-duplex)” 연결을 제공함을 나타낸다.
5. 라우터나 중간 장비에서의 처리
• 중요한 점: 이 그림에서 알 수 있듯이, TCP 연결의 상태는 송신 및 수신 끝단의 호스트에서만 유지된다.
• 중간 네트워크 장비(예: 라우터, 스위치)는 TCP 버퍼나 연결 상태를 전혀 관리하지 않는다.
• 라우터는 단순히 IP 데이터그램을 전달할 뿐이며, TCP의 동작은 송신자와 수신자 사이에서만 처리된다.
결론: 그림을 통한 TCP의 핵심 요약
• TCP는 송신과 수신 버퍼를 통해 데이터를 안정적으로 관리한다.
• 데이터는 세그먼트로 나뉘어 전송되며, 네트워크의 지연이나 손실에도 불구하고 TCP는 재전송, 정렬 등의 기능을 통해 데이터를 신뢰성 있게 전달한다.
3.5.2 TCP Segment Structure
TCP Segment Structure (TCP 세그먼트 구조)
TCP는 데이터 전송을 위해 데이터를 **세그먼트(segment)**로 나누며, 각 세그먼트는 두 가지 주요 부분으로 구성된다.
1. 헤더(Header): 제어 정보를 포함.
2. 데이터(Data): 애플리케이션이 전송하려는 실제 데이터.
헤더는 TCP의 주요 기능(연결 설정, 신뢰성 보장, 흐름 제어, 혼잡 제어 등)을 수행하기 위해 필수적인 정보를 담고 있다.
1. TCP 세그먼트의 데이터 필드
• 데이터 필드는 TCP가 애플리케이션으로부터 받은 데이터를 포함한다.
• 데이터 크기는 **MSS(Maximum Segment Size)**에 의해 제한된다.
• MSS는 네트워크 경로에서의 **MTU(Maximum Transmission Unit)**를 기준으로 계산된다.
• 예를 들어, 이미지 파일과 같은 큰 데이터는 MSS 크기로 나뉘며, 마지막 세그먼트는 MSS보다 작은 경우가 많다.
• 반대로, Telnet과 SSH 같은 상호작용 애플리케이션은 종종 작은 데이터(1바이트)를 전송한다.
2. TCP 헤더의 주요 필드
TCP 헤더는 20바이트의 고정 필드와 가변 길이의 옵션 필드로 구성된다. 여기에는 다음과 같은 중요한 정보가 포함된다.
• 32비트 시퀀스 번호(Sequence Number):
• 이 번호는 TCP가 데이터 스트림에서 바이트의 순서를 식별하는 데 사용된다.
• 송신자는 각 세그먼트가 포함하는 첫 번째 바이트의 번호를 시퀀스 번호로 설정한다.
• 32비트 확인 번호(Acknowledgment Number):
• 수신자는 이 번호를 사용해 송신자가 다음에 받을 것으로 예상하는 바이트 번호를 알려준다.
• 예를 들어, “ACK=536”은 수신자가 바이트 0~535를 성공적으로 받았음을 의미한다.
• 16비트 수신 윈도우(Receive Window):
• TCP는 이 필드를 사용해 송신자에게 수신자가 처리할 수 있는 데이터의 최대 크기를 알린다.
• 이는 TCP의 흐름 제어(flow control) 메커니즘의 핵심이다.
• 4비트 헤더 길이(Header Length):
• 헤더의 길이를 32비트 워드 단위로 지정한다.
• TCP 옵션 필드가 없으면 기본 길이는 20바이트이다.
• 옵션 필드(Options):
• 이 필드는 MSS를 협상하거나 고속 네트워크에서 윈도우 크기를 확장하는 데 사용된다.
• 또한 시간 스탬프와 같은 고급 기능도 여기에 포함된다.
• 플래그 필드(Flag Field):
• 6개의 주요 제어 비트(ACK, SYN, FIN, RST, PSH, URG)가 포함된다.
• 예:
• SYN: 연결 설정을 시작할 때 사용.
• ACK: 확인 응답을 포함.
• FIN: 연결 종료를 요청.
• RST: 비정상적인 연결 종료 요청.
• 16비트 체크섬(Checksum): 데이터의 무결성을 확인
3. Figure 3.29: TCP Segment Structure
이 그림은 TCP 세그먼트의 전체 구조를 시각적으로 보여준다. 그림의 구성 요소는 아래와 같이 나눌 수 있다:
1. Source Port #와 Destination Port #:
• 각각 송신 측과 수신 측 애플리케이션의 포트를 나타낸다.
• 다중화와 역다중화에 사용된다.
2. Sequence Number와 Acknowledgment Number:
• 송신자가 데이터의 순서를 지정하고, 수신자가 데이터를 제대로 받았는지 확인한다.
3. Header Length와 Flags:
• 헤더의 크기 및 세그먼트의 제어 상태를 정의한다.
4. Receive Window:
• 흐름 제어를 위해 송신 가능한 데이터의 크기를 나타낸다.
5. Checksum 및 Urgent Data Pointer:
• 데이터의 무결성을 보장하고 긴급 데이터의 위치를 지정한다.
6. Options 및 Data:
• 선택적인 정보와 실제 애플리케이션 데이터를 포함한다.
이 구조를 통해 TCP는 데이터 전송의 신뢰성을 확보하고, 연결 상태를 유지하며, 흐름과 혼잡을 효과적으로 관리할 수 있다.
4. 데이터 세그먼트 나누기
Figure 3.30은 파일 데이터를 TCP 세그먼트로 나누는 과정을 보여준다.
• TCP는 데이터를 연속된 바이트 스트림으로 간주한다.
• 그림에서는 파일이 500,000 바이트 크기라고 가정하며, MSS가 1,000 바이트일 경우 총 500개의 세그먼트로 나뉜다.
• 각 세그먼트는 시퀀스 번호를 통해 바이트 스트림 내 위치를 나타낸다.
• 첫 번째 세그먼트는 시퀀스 번호 0에서 시작.
• 두 번째 세그먼트는 시퀀스 번호 1,000에서 시작.
• 마지막 세그먼트는 남은 데이터(1,000 바이트 이하)를 포함한다.
5. 시퀀스 및 확인 번호의 예
Figure 3.31은 Telnet 애플리케이션에서 TCP의 시퀀스와 확인 번호의 동작을 보여준다.
예제 설명:
• Host A가 Host B에 ‘C’를 전송한다.
• 첫 번째 세그먼트:
• 시퀀스 번호: 42 (A의 첫 바이트).
• 확인 번호: 79 (B가 다음으로 기대하는 바이트).
• 두 번째 세그먼트:
• 시퀀스 번호: 79 (B의 첫 바이트).
• 확인 번호: 43 (A가 다음으로 기대하는 바이트).
• 이러한 확인 과정은 TCP의 신뢰성 있는 데이터 전송을 가능하게 한다.
TCP 세그먼트 구조의 핵심 요약
1. TCP 헤더는 데이터를 정확하고 신뢰성 있게 전송하기 위한 다양한 필드를 포함한다.
2. 시퀀스 번호와 확인 번호를 통해 데이터의 순서와 무결성을 관리한다.
3. 흐름 제어와 혼잡 제어를 위해 윈도우 크기와 체크섬 필드가 사용된다.
4. 그림(Figure 3.29~3.31)은 TCP 세그먼트 구조, 데이터 분할, 시퀀스 및 확인 번호 동작을 명확히 설명한다.
3.5.3 Round-Trip Time Estimation and Timeout
TCP는 신뢰성을 보장하기 위해 **타임아웃(timeout)**과 재전송(retransmission) 메커니즘을 사용한다.
타임아웃은 데이터 세그먼트가 손실되었거나 ACK(확인 응답)가 손실되었을 때 이를 복구하기 위해 동작한다.
1. RTT(왕복 시간) 측정: SampleRTT
TCP는 송신 세그먼트에 대해 ACK가 도착하기까지 걸린 시간을 측정하여 SampleRTT라고 정의한다.
• SampleRTT 계산 과정:
• 세그먼트가 전송된 시간 기록.
• 해당 세그먼트의 ACK가 수신되었을 때, 경과 시간을 측정.
• 모든 세그먼트에 대해 SampleRTT를 측정하지 않고, 보통 한 번에 하나의 SampleRTT를 측정한다.
• 재전송된 세그먼트는 SampleRTT 계산에서 제외됩니다(Karn의 알고리즘에 따라).
Note: SampleRTT는 네트워크의 혼잡 상태나 시스템의 부하에 따라 크게 변동될 수 있다.
2. RTT 예측: EstimatedRTT
RTT의 변동성을 줄이기 위해 TCP는 여러 SampleRTT 값을 이용해 평균 RTT 값을 계산한다.
이를 EstimatedRTT라 한다.
• 계산 공식:
• a는 가중치로, 일반적으로 이 추천된다.
• 이전 RTT 값과 새로운 SampleRTT 값 사이의 가중 평균(Exponential Weighted Moving Average)을 계산한다.
• Figure 3.32: SampleRTT와 EstimatedRTT:
• 그림에서 볼 수 있듯이, SampleRTT는 매우 변동이 심한 반면, EstimatedRTT는 비교적 매끄럽게 변동한다.
• 이는 TCP가 네트워크의 변화를 예측하며 안정적으로 동작하도록 만든다.
3. RTT 변동성 측정: DevRTT
SampleRTT의 변동성을 고려하여 TCP는 RTT의 표준 편차를 측정하는 DevRTT를 계산한다.
• DevRTT 공식:
• b = 0.25 가 추천된다.
• DevRTT는 SampleRTT와 EstimatedRTT의 차이에 대한 가중 평균으로 계산된다.
4. 타임아웃 간격 설정
타임아웃 간격은 EstimatedRTT와 DevRTT를 바탕으로 설정된다.
• 공식:
• 타임아웃 간격 설정 기준:
• RTT보다 짧으면 불필요한 재전송이 발생.
• RTT보다 지나치게 길면 복구 지연이 발생.
5. 타임아웃의 동적 관리
1. 초기 TimeoutInterval은 1초로 설정하는 것이 권장된다.RFC 6298).
2. 타임아웃이 발생할 경우, TimeoutInterval은 두 배로 증가하여 혼잡으로 인한 추가 타임아웃을 방지한다.
3. ACK가 도착하면 TimeoutInterval은 공식에 따라 다시 계산된다.
TCP의 실제 동작 (Principles in Practice)
1. 긍정적 ACK와 타이머 사용:
• TCP는 데이터가 성공적으로 수신되었는지 확인하기 위해 ACK를 사용한다.
• 세그먼트가 ACK 없이 일정 시간 동안 수신되지 않으면 재전송한다.
2. 암묵적 NAK(Negative Acknowledgment):
• 동일한 세그먼트에 대해 3개의 중복 ACK가 수신되면, 해당 세그먼트가 손실된 것으로 간주하고 재전송을 트리거한다.(빠른 재전송)
3. 파이프라이닝(pipelining):
• TCP는 여러 세그먼트를 동시에 전송하며, ACK를 기다리지 않고 새로운 세그먼트를 보낸다.
• 송신자가 보낼 수 있는 확인되지 않은 세그먼트 수는 흐름 제어 및 혼잡 제어 메커니즘에 의해 제한된다.
Figure 3.32: RTT Samples and RTT Estimates
이 그림은 TCP가 네트워크에서 SampleRTT와 EstimatedRTT를 어떻게 처리하는지 시각적으로 보여준다.
• 파란색 선: SampleRTT(실제 측정값)의 큰 변동성을 보여준다.
• 검은색 선: EstimatedRTT(평균값)는 SampleRTT를 매끄럽게 따라가며, 네트워크의 변동을 안정적으로 반영한다.
• 이를 통해 TCP가 변화하는 네트워크 상태를 효과적으로 관리할 수 있음을 알 수 있다.
요약
1. SampleRTT, EstimatedRTT, DevRTT:
• SampleRTT: 송신 세그먼트의 실제 왕복 시간.
• EstimatedRTT: SampleRTT를 기반으로 한 가중 평균.
• DevRTT: SampleRTT와 EstimatedRTT 간의 변동성 측정.
2. 타임아웃 관리:
• 타임아웃 간격은 RTT를 기준으로 설정되며, 네트워크의 변동성을 반영.
• 빠른 재전송 메커니즘과 함께 동작하여 데이터 손실 복구를 신속히 처리.
3. 그림 3.32:
• 네트워크의 변동을 시각적으로 나타내며, TCP의 예측 능력을 강조.
3.5.4 Reliable Data Transfer
인터넷의 네트워크 계층 서비스(IP 서비스)는 신뢰성이 없는 프로토콜이다.
IP는 데이터그램의 전송을 보장하지 않으며, 데이터그램이 순서대로 도착하거나 무결성을 유지하는 것도 보장하지 않는다.
라우터의 버퍼가 초과되거나 네트워크 문제로 인해 데이터그램이 목적지에 도달하지 못할 수 있으며, 데이터그램이 순서가 뒤바뀌거나 비트 오류가 발생할 수도 있다.
TCP는 이러한 IP의 비신뢰적 특성을 보완하여 신뢰성 있는 데이터 전송 서비스를 제공한다.
TCP의 신뢰성 있는 데이터 전송은 데이터가 손상되지 않고, 중복되지 않으며, 순서에 맞게 수신 측의 TCP 버퍼에 도달하도록 보장한다.
이를 통해 전송된 데이터 스트림이 송신 측에서 보낸 데이터 스트림과 정확히 일치하게 된다.
Reliable Data Transfer의 작동 원리
TCP는 신뢰성 있는 데이터 전송을 구현하기 위해 다음의 핵심 원리를 따른다.
1. 누락된 세그먼트 복구:
TCP는 수신자로부터 ACK(확인 응답)를 받아 데이터가 성공적으로 도달했는지 확인한다.
ACK가 수신되지 않으면, 해당 세그먼트가 손실되었다고 판단하여 재전송을 수행한다.
2. 시퀀스 번호를 사용한 순서 보장:
TCP는 세그먼트마다 고유의 시퀀스 번호를 부여한다.
수신자는 이 번호를 기반으로 세그먼트를 올바른 순서로 재배열한다. 순서가 맞지 않거나 누락된 세그먼트는 TCP가 감지하여 처리한다.
3. 중복 데이터 제거:
수신자가 동일한 데이터 세그먼트를 여러 번 수신하는 경우, 중복 데이터는 버려지고 단 한 번만 상위 계층으로 전달된다.
Figure 3.33: Simplified TCP Sender
Figure 3.33은 TCP 송신자의 동작을 간단히 보여주는 코드로, 세 가지 주요 이벤트를 처리한다.
1. 애플리케이션 데이터 수신:
TCP는 애플리케이션에서 데이터를 수신하면, 이를 세그먼트로 캡슐화하여 IP 계층으로 전달한다.
세그먼트에는 시퀀스 번호가 포함되며, 처음 전송 시 타이머가 시작된다.
2. 타이머 만료:
세그먼트를 전송한 후 ACK가 수신되지 않으면, 타이머가 만료된다. 이 경우, 타임아웃된 세그먼트를 재전송하고 타이머를 다시 시작한다.
3. ACK 수신:
수신자로부터 ACK가 도착하면, TCP는 해당 ACK가 확인한 데이터까지 송신이 완료되었음을 기록한다. 또한 확인되지 않은 세그먼트가 여전히 남아있다면 타이머를 다시 설정한다.
TCP의 동작 시나리오
Figure 3.34: ACK 손실 시 재전송
이 그림은 송신 측에서 전송된 세그먼트가 수신 측에 도달했지만, ACK가 송신 측으로 돌아오지 않은 상황을 보여준다.
이 경우 타임아웃이 발생하고 송신 측은 해당 세그먼트를 재전송한다. 그러나 수신 측은 이미 해당 데이터를 수신했기 때문에 이를 무시하고 ACK를 다시 보낸다.
Figure 3.35: 누적 ACK 사용
누적 ACK는 이전 시퀀스 번호까지의 데이터를 성공적으로 수신했음을 나타낸다.
예를 들어, Host A에서 두 개의 세그먼트(시퀀스 번호 92와 100)가 전송되었을 때, Host B는 누적 ACK를 통해 데이터 119까지 정상 수신했음을 알린다. 누적 ACK를 통해 일부 ACK가 손실되더라도 중복 재전송을 방지할 수 있다.
Figure 3.36: 첫 번째 세그먼트 재전송 방지
이 그림은 첫 번째 세그먼트의 ACK가 손실되었음에도, 두 번째 세그먼트의 누적 ACK가 도착함으로써 재전송을 피할 수 있는 상황을 보여준다.
Fast Retransmit
TCP는 Fast Retransmit(빠른 재전송) 메커니즘을 통해 타이머 만료를 기다리지 않고 데이터 손실을 감지한다. 동일한 데이터에 대해 3개의 중복 ACK가 수신되면, 송신 측은 해당 데이터가 손실된 것으로 판단하여 즉시 재전송한다.
Figure 3.37: Fast Retransmit 동작
이 그림은 3개의 중복 ACK가 발생한 후, 송신 측이 빠르게 손실된 세그먼트를 재전송하는 과정을 보여준다. 이를 통해 타이머 만료를 기다리는 지연을 줄이고 네트워크 효율성을 높인다.
TCP의 Go-Back-N 및 Selective Repeat
TCP는 Go-Back-N과 Selective Repeat 프로토콜의 하이브리드 방식으로 동작한다. 다음과 같은 특징을 갖는다:
• 수신자는 누락된 세그먼트를 감지하고 중복 ACK를 통해 송신자에게 이를 알린다.
• TCP의 Selective Acknowledgment(SACK) 옵션은 특정 세그먼트를 선택적으로 확인함으로써 효율성을 향상시킨다.
결론
TCP는 네트워크 계층의 신뢰성 없는 서비스를 기반으로, 데이터의 순서 보장, 중복 제거, 오류 복구를 통해 신뢰성 있는 데이터 전송을 제공한다. 이를 위해 타이머, ACK, 중복 ACK, 빠른 재전송과 같은 메커니즘을 사용한다. 이러한 원리는 인터넷의 핵심 기반으로, 현대 네트워킹 환경에서도 여전히 중요한 역할을 한다.
3.5.5 Flow Control
TCP는 연결의 양쪽 끝단에서 수신 버퍼(receive buffer)를 설정한다.
TCP 연결이 데이터 바이트를 수신하면, 올바르고 순서에 맞는 데이터는 수신 버퍼에 저장된다.
그러나 수신 애플리케이션은 데이터가 도착하는 즉시 버퍼에서 읽지 않을 수 있다.
수신 애플리케이션이 다른 작업으로 바쁘거나 도착한 데이터를 늦게 처리할 경우, 송신자가 데이터를 너무 빠르게 전송하면 수신 측의 버퍼가 넘칠 위험이 있다.
TCP는 흐름 제어(Flow Control) 서비스를 제공하여 송신자가 수신 측의 버퍼를 초과하지 않도록 한다.
흐름 제어는 송신 속도를 수신 애플리케이션의 데이터 읽기 속도와 일치시키는 역할을 한다.
이를 통해 송신자가 수신 측의 한계를 넘어서지 않도록 조율된다.
1. Flow Control의 작동 원리
TCP는 **rwnd(receive window)**라는 변수를 통해 흐름 제어를 구현한다.
rwnd는 수신 측의 남은 버퍼 공간을 송신 측에 알리기 위해 사용된다.
송신자는 rwnd 값을 기반으로 데이터 전송량을 조절하여 수신 측의 버퍼가 넘치지 않도록 한다.
수신 측에서 사용하는 주요 변수는 다음과 같다:
1. LastByteRead: 애플리케이션이 수신 버퍼에서 마지막으로 읽은 바이트의 번호.
2. LastByteRcvd: 네트워크에서 수신하여 버퍼에 저장된 마지막 바이트의 번호.
3. RcvBuffer: 수신 버퍼의 전체 크기.
rwnd는 아래 식으로 계산된다:
이 식은 수신 버퍼에서 남아 있는 공간의 크기를 나타낸다.
2. 송신 측에서의 관리
송신자는 다음 두 가지 변수를 사용하여 데이터를 관리한다:
1. LastByteSent: 송신자가 마지막으로 보낸 바이트의 번호.
2. LastByteAcked: 송신자가 ACK를 통해 확인받은 마지막 바이트의 번호.
송신자는 다음 조건을 충족해야 한다:
이를 통해 송신자는 수신 측의 버퍼 크기를 초과하지 않도록 보장한다.
Figure 3.38: Receive Window와 Receive Buffer
Figure 3.38은 수신 버퍼와 rwnd의 관계를 시각적으로 보여준다.
• RcvBuffer: 수신 버퍼의 전체 크기를 나타낸다.
• Spare Room: 아직 사용되지 않은 버퍼 공간을 의미하며, rwnd 값으로 표시된다.
• TCP는 데이터가 도착하면 이를 버퍼에 저장하고, 애플리케이션이 읽으면 버퍼 공간이 비워지며 rwnd 값이 다시 증가한다.
3. Zero Window 문제
특정 상황에서는 rwnd가 0이 되어 송신자가 데이터를 전송하지 못하는 문제가 발생할 수 있다.
예를 들어, 수신 버퍼가 가득 찼고 수신 측 애플리케이션이 데이터를 읽지 않고 있는 경우, 송신자는 데이터 전송을 멈춘다.
그러나 수신 측이 rwnd 값을 갱신하지 않으면 송신자는 언제 전송을 재개해야 할지 알 수 없다.
이를 해결하기 위해 TCP는 윈도우 프로브(Window Probe) 메커니즘을 사용한다.
송신자는 최소 1바이트의 데이터를 전송하여 수신 측의 rwnd 상태를 확인한다.
이 과정을 통해 송신자는 수신 측 버퍼가 비워졌는지 여부를 알 수 있다.
4. Flow Control과 Congestion Control의 차이
흐름 제어는 수신 측의 버퍼 오버플로를 방지하기 위한 메커니즘이다.
반면 혼잡 제어는 네트워크 혼잡을 완화하기 위한 메커니즘으로, 송신 속도를 조정하여 패킷 손실을 줄이는 데 초점이 맞춰져 있다.
두 메커니즘은 목적과 동작 방식에서 차이가 있다.
5. UDP와의 비교
UDP는 TCP와 달리 흐름 제어를 제공하지 않는다.
따라서 송신자는 수신자의 처리 속도를 고려하지 않고 데이터를 전송하며, 이는 쉽게 버퍼 오버플로와 데이터 손실로 이어질 수 있다.
UDP를 사용하는 애플리케이션은 자체적으로 흐름 제어 메커니즘을 구현해야 한다.
결론
TCP의 흐름 제어는 송신자가 수신 측의 버퍼 크기를 초과하지 않도록 보장하며, 이를 통해 데이터 전송의 안정성을 높인다. rwnd 변수와 윈도우 프로브 같은 메커니즘은 TCP 흐름 제어의 핵심 요소이다. 이 방식은 네트워크 및 애플리케이션의 안정적인 동작을 지원하며, UDP와의 차별점을 명확히 보여준다.
3.5.6 TCP Connection Management
TCP 연결 관리(TCP Connection Management)는 TCP 프로토콜에서 중요한 부분으로, 연결을 설정하고 종료하는 과정을 다룬다.
이 과정은 **3단계 핸드셰이크(Three-Way Handshake)**와 **연결 해제(Connection Teardown)**로 나뉜다.
1. TCP 연결 설정: Three-Way Handshake
TCP 연결은 클라이언트와 서버 간의 세 단계를 통해 설정된다.
1단계: 클라이언트에서 SYN 세그먼트 전송
• 클라이언트는 연결을 요청하기 위해 특별한 TCP 세그먼트를 서버로 전송한다.
• 이 세그먼트는 애플리케이션 계층 데이터를 포함하지 않으며, TCP 헤더의 SYN 플래그가 활성화된다.
• 클라이언트는 이 과정에서 **초기 시퀀스 번호(client_isn)**를 무작위로 생성하여 TCP 헤더에 포함한다.
2단계: 서버에서 SYN-ACK 세그먼트 전송
• 서버는 클라이언트의 SYN 세그먼트를 수신한 후, 수신을 확인하고 자신의 초기 시퀀스 번호(server_isn)를 포함한 SYN-ACK 세그먼트를 클라이언트로 전송한다.
• 이때 ACK 번호는 클라이언트의 초기 시퀀스 번호(client_isn)에 1을 더한 값이다.
3단계: 클라이언트에서 ACK 세그먼트 전송
• 클라이언트는 서버의 SYN-ACK 세그먼트를 수신하고, 이를 확인하는 ACK 세그먼트를 서버로 전송한다.
• 이후 클라이언트와 서버는 데이터 전송을 시작할 준비가 완료된다.
Figure 3.39: Three-Way Handshake
Figure 3.39는 Three-Way Handshake의 각 단계를 시각적으로 설명한다.
• 첫 번째 화살표는 클라이언트가 SYN 플래그를 설정하여 서버로 초기 시퀀스 번호를 보낸다.
• 두 번째 화살표는 서버가 SYN과 ACK 플래그를 설정해 응답하고 자신의 초기 시퀀스 번호를 보낸다.
• 세 번째 화살표는 클라이언트가 ACK 플래그를 설정해 서버의 시퀀스 번호를 확인한다.
2. TCP 연결 종료: Connection Teardown
TCP 연결 종료는 양방향으로 이루어진다. 각 방향에서 FIN 플래그를 사용해 연결 종료를 요청한다.
1단계: 클라이언트에서 FIN 세그먼트 전송
• 클라이언트는 더 이상 보낼 데이터가 없을 때 FIN 세그먼트를 전송한다.
2단계: 서버에서 ACK 전송
• 서버는 클라이언트의 FIN 세그먼트를 확인하는 ACK를 전송한다.
• 이후 서버도 FIN 세그먼트를 전송해 자신의 연결 종료를 요청한다.
3단계: 클라이언트에서 최종 ACK 전송
• 클라이언트는 서버의 FIN 세그먼트를 확인하는 ACK를 전송한다.
• 연결은 완전히 종료되며, 모든 자원이 해제된다.
Figure 3.40: Closing a TCP Connection
Figure 3.40은 TCP 연결 종료 과정을 보여준다.
• 클라이언트와 서버가 FIN과 ACK를 교환하며, 최종적으로 연결을 종료한다.
• 클라이언트는 TIME_WAIT 상태로 전환되어 일정 시간 동안 마지막 ACK를 재전송할 준비를 한다.
3. TCP 상태 전이(TCP State Transition)
TCP 연결 설정 및 종료는 다양한 상태 전이를 통해 관리된다.
Figure 3.41: 클라이언트의 상태 전이
1. CLOSED: 초기 상태로, 연결이 닫혀 있다.
2. SYN_SENT: SYN 세그먼트를 전송하고 서버의 응답을 기다리는 상태이다.
3. ESTABLISHED: 연결이 설정된 상태로, 데이터 전송이 이루어진다.
4. FIN_WAIT_1: 연결 종료를 요청하며 FIN 세그먼트를 전송한 상태이다.
5. FIN_WAIT_2: FIN에 대한 ACK를 받은 상태로, 상대방의 FIN을 기다린다.
6. TIME_WAIT: 최종 ACK를 전송하고 일정 시간 동안 대기한다.
Figure 3.42: 서버의 상태 전이
1. LISTEN: 클라이언트의 연결 요청을 기다리는 상태이다.
2. SYN_RCVD: SYN을 수신하고 SYN-ACK를 전송한 상태이다.
3. ESTABLISHED: 데이터 전송이 가능한 상태이다.
4. CLOSE_WAIT: FIN을 수신하고 응답을 준비하는 상태이다.
5. LAST_ACK: 마지막 ACK를 전송한 상태이다.
4. SYN Flood 공격과 방어
SYN Flood는 TCP의 취약점을 악용한 공격이다.
• 공격자는 다수의 SYN 세그먼트를 보내고, ACK를 보내지 않아 서버의 자원을 고갈시킨다.
• 방어 메커니즘으로 SYN Cookie가 사용된다.
• 서버는 SYN 세그먼트를 수신해도 자원을 할당하지 않고, 해시 함수를 이용해 SYN Cookie를 생성하여 응답한다.
• 클라이언트가 올바른 ACK를 보내면 서버는 연결을 설정한다.
결론
TCP 연결 관리는 네트워크 연결의 핵심이다. Three-Way Handshake는 연결 설정의 안정성을 보장하며, Connection Teardown은 효율적으로 자원을 해제한다. 이러한 과정을 통해 TCP는 신뢰성 있는 데이터 전송을 지원하며, SYN Flood와 같은 보안 문제도 고려된다.
'Book > COMPUTER NETWORKING A TOP-DOWN-APPROACH' 카테고리의 다른 글
| 3.7 TCP Congestion Control (3) | 2024.11.24 |
|---|---|
| 3.6 Principles of Congestion Control (0) | 2024.11.24 |
| CH3_Transport Layer (2) | 2024.10.19 |
| CH2_Application Layer(2.5~2.7) (3) | 2024.10.19 |
| CH2_Application Layer(2.3~2.4) (4) | 2024.10.14 |