네트워크 계층에서 가장 중요한 프로토콜이 IP라면,
전송 계층에서는 TCP와 UDP가 핵심이다.
TCP(Transmission Control Protocol) 은 신뢰할 수 있는 연결형 프로토콜이다.
데이터 전송의 순서 보장, 재전송, 흐름 제어, 혼잡 제어를 수행하며
통신 단계는 연결 수립, 데이터 송수신, 연결 종료의 세 단계로 이룸.
반면, UDP(User Datagram Protocol) 은 신뢰성은 떨어지지만
비교적 빠른 통신이 가능한 비연결형 프로토콜이다.
TCP의 구조와 통신 과정
TCP는 통신 단계가 다음과 같이 구성됨.
연결 수립 (Connection Establishment)
TCP는 3-Way Handshake 과정을 거쳐 연결을 수립함.
제어 비트 중 SYN과 ACK를 사용함.
| 단계 | 송신자(Client) | 수신자(Server) | 제어 비트 |
|---|---|---|---|
| 1 | SYN 전송 (연결 요청) | SYN=1 | |
| 2 | SYN + ACK 응답 | SYN=1, ACK=1 | |
| 3 | ACK 응답 (연결 수립 완료) | ACK=1 |
이를 통해 양측이 서로의 통신 가능 상태를 확인함.
데이터 송수신 (Data Transfer)
TCP는 MSS(Maximum Segment Size) 단위로 데이터를 쪼개 전송함.
각 세그먼트에는 순서 번호(Sequence Number) 와
확인 응답 번호(Acknowledgment Number) 가 존재함.
순서 번호: 올바른 송수신 순서를 보장하기 위한 번호
확인 응답 번호: 다음으로 기대하는 바이트 번호
연결 종료 (Connection Termination)
4-Way Handshake 방식으로 종료됨.
한쪽이 FIN 세그먼트를 보내고, 상대가 이를 ACK로 응답한 뒤
반대 방향에서도 동일한 과정을 수행함.
TCP는 이러한 연결의 상태를 유지함으로써 Stateful 프로토콜이라 불림
UDP는 비연결형 통신을 수행하는 신뢰할 수 없는 프로토콜이다.
오류 제어, 혼잡 제어, 흐름 제어를 수행하지 않으며 상태도 유지하지 않음.
그만큼 처리 오버헤드가 작고 전송 속도가 빠름.
UDP 헤더는 다음 4개의 필드로 구성됨.
| 필드 | 설명 |
|---|---|
| Source Port | 송신지 포트 번호 |
| Destination Port | 수신지 포트 번호 |
| Length | 헤더 + 데이터의 전체 길이 |
| Checksum | 데이터 손상 여부 검증용 필드 |
UDP는 단순하고 빠르기 때문에
실시간성이 중요한 응용(예: 영상 스트리밍, VoIP, 온라인 게임)에 자주 사용됨.
2-Hand Shake 프로토콜도 존재할까?
2-Hand Shake로는 양측의 데이터 전송 가능 여부를 완전히 확인할 수 없음.
만약 송신 측이 SYN을 보냈는데 ACK만 받고 실제 수신 측이 응답할 수 없는 상태라면
데이터 유실이 발생할 수 있음.
3-Way Handshake는 양방향 통신 준비 상태를 모두 확인하기 위한 최소 구조임.
TCP는 양방향 통신이 가능한 Full-duplex 프로토콜임.
클라이언트와 서버가 서로의 초기 순서 번호(ISN) 를 교환해야 하며,
이 두 방향의 동기화를 위해 최소 세 단계가 필요함.
UDP의 체크섬은 어떻게 동작할까?
UDP의 체크섬은 전송 중 데이터 손상 여부를 검증하기 위한 필드이다. 송신 측은 헤더 + 데이터에 대한 16비트 1의 보수 합을 계산수신 측은 동일한 계산을 수행해 비교
불일치 시 데이터 손상으로 간주. UDP는 손상 탐지만 수행하며, 재전송은 애플리케이션 레벨에서 처리함.
PyTorch의 DistributedDataParallel(DDP) 은
TCP 기반 gRPC나 NCCL 통신 백엔드를 사용함.
전송 신뢰성이 깨질 경우 모델 파라미터 불일치가 발생할 수 있음. https://docs.pytorch.org/docs/stable/distributed.html
| 구분 | TCP | UDP |
|---|---|---|
| 연결 방식 | 연결형 | 비연결형 |
| 신뢰성 | 높음 (재전송, 순서 보장) | 낮음 (오류 탐지만 수행) |
| 속도 | 느림 | 빠름 |
| 상태 유지 | Stateful | Stateless |
| 주요 활용 | 웹, 메일, 파일 전송 | 실시간 스트리밍, 게임, VoIP |
TCP는 신뢰성을, UDP는 속도를 중시한다.
AI 시스템 설계에서는 “유실 허용 vs 지연 허용 불가” 중 어떤 가치가 더 중요한지 판단하는 것이 핵심이다.
TCP(Transmission Control Protocol)는 신뢰할 수 있는 연결형 프로토콜이다.
데이터 전송의 순서 보장, 재전송, 흐름 제어, 혼잡 제어를 수행하며, 통신 과정은 세 가지 단계로 이룸.
TCP는 전송 중 오류 검출을 위한 체크섬(checksum) 필드를 포함한다.
하지만 체크섬만으로는 완전한 신뢰성을 확보할 수 없다.
체크섬은 단순히 데이터 훼손 여부만 판단할 수 있으며, 오류가 감지되면 해당 세그먼트는 폐기된다.
즉, 수신 측이 오류를 탐지하더라도 송신 측은 데이터가 제대로 도착하지 않았음을 직접적으로 알 수 없다.
이 문제를 해결하기 위해 TCP는 ACK(acknowledgement) 와 재전송 타이머(timeout timer) 를 사용한다.
송신 호스트는 각 세그먼트를 보낸 후 타이머를 설정하고, 일정 시간 내에 ACK를 받지 못하면 해당 세그먼트를 재전송한다.
1-1. 재전송 메커니즘 (ARQ)
TCP의 재전송은 ARQ(Automatic Repeat reQuest) 방식으로 수행된다.
대표적인 세 가지 방식은 다음과 같다.
(1) Stop-and-Wait ARQ
하나의 세그먼트를 송신하고, ACK를 받은 후 다음 세그먼트를 전송하는 방식
구조가 단순하고 신뢰성이 높다
하지만 ACK를 기다리는 동안 네트워크 자원이 낭비되어 효율이 낮아질 수 있음
(2) Go-Back-N ARQ
여러 개의 세그먼트를 연속 송신하되, 오류가 발생하면 문제가 발생한 이후의 모든 세그먼트를 다시 전송
하나의 오류가 전체 전송 효율에 영향을 미침
이는 일종의 배치 단위 처리(batch processing) 와 유사함
한 단위(batch)가 실패하면 전체를 다시 수행해야 하는 형태
(3) Selective Repeat ARQ
오류가 발생한 세그먼트만 선택적으로 재전송
효율적이지만, 송신자와 수신자 모두 각 세그먼트의 순서와 상태를 개별적으로 관리해야 함
오늘날 TCP 구현에서는 selective acknowledgment(SACK) 옵션으로 이 개념이 확장되어 있음
수신 호스트는 데이터 처리 속도에 한계가 존재한다.
TCP는 수신 호스트의 처리 한계를 초과하지 않도록 전송 속도를 제어한다.
이를 흐름 제어(flow control) 라고 한다.
수신 측의 임시 저장 공간인 수신 버퍼(receive buffer) 가 가득 차면 추가 데이터를 수용할 수 없게 된다.
이러한 상태를 버퍼 오버플로(buffer overflow) 라고 한다.
2-1. 슬라이딩 윈도우(Sliding Window)
오늘날 TCP는 슬라이딩 윈도우 방식을 사용한다.
윈도우(Window)란 송신 호스트가 ACK를 기다리지 않고 한 번에 전송할 수 있는 데이터의 최대량이다.
ACK가 도착할 때마다 윈도우는 오른쪽으로 ‘슬라이드’되어 다음 데이터를 보낼 수 있게 된다.
이 방식은 신뢰성과 효율성을 모두 확보하는 데 핵심적인 역할을 함.
흐름 제어가 수신 호스트의 상태를 고려한다면,
혼잡 제어는 네트워크 전체의 상태를 고려한다.
혼잡 제어의 주체는 송신 호스트이며, 네트워크 혼잡 정도를 판단해 전송량을 조절한다.
3-1. 혼잡 윈도우(Congestion Window, cwnd)
혼잡 윈도우는 네트워크가 혼잡 없이 수용할 수 있는 데이터량을 추정한 값이다.
이는 송신 측이 스스로 계산하며, 수신 윈도우(receive window)와는 별도로 존재한다.
TCP는 네트워크 상황에 따라 혼잡 윈도우 크기를 동적으로 조정한다.
대표적인 혼잡 제어 알고리즘은 다음과 같다.
(1) AIMD (Additive Increase, Multiplicative Decrease)
네트워크가 안정적이면 전송 윈도우를 선형적으로 증가(Additive Increase)
혼잡이 감지되면 전송 윈도우를 절반으로 감소(Multiplicative Decrease)
점진적 확장과 급격한 축소를 반복하며 최적의 전송 속도를 탐색하는 방식
(2) 느린 시작 (Slow Start)
초기에 네트워크의 수용 능력을 알 수 없으므로, 작은 윈도우(보통 1 MSS)로 시작
ACK가 수신될 때마다 윈도우 크기를 지수적으로 증가시킴
혼잡 임계점(ssthresh)에 도달하면 느린 시작을 종료하고 혼잡 회피로 전환
(3) 혼잡 회피 (Congestion Avoidance)
네트워크가 혼잡하기 직전의 상태를 유지
윈도우 크기를 선형적으로 증가시키며 안정된 전송을 유지
(4) 빠른 회복 (Fast Recovery)
3개의 중복 ACK를 수신하면 타임아웃 이전에 재전송 수행
타임아웃 시 윈도우 크기를 1로 줄이는 이유는 네트워크 상태를 다시 안정적으로 재탐색하기 위함
타임아웃은 단순한 일시적 패킷 손실이 아닌 네트워크 혼잡의 가능성으로 간주되기 때문