- Spark
- PostgrSQL
- 정합성
- httpOnly
- BigQuery
- SQL
- NoSQL
- airflow
- nextjs
- websocket
- Frontend
- DBT
- 플로이드워셜
- til
- SSAFY
- observability
- 세션
- HTTP
- 프론트엔드
- 크루스칼
- DeltaLake
- MST
- de
- 쿠키
- isr
- 네트워크
- react
- db
- 백엔드
- flink
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Today
- Total
R+7
[TIL] 차근차근 CS (1) - TCP와 UDP 본문

Today I Learned

TCP와 UDP
TCP는 정확성과 신뢰성을 최우선으로 하는 프로토콜. 연결 지향형이라 부른다. 데이터 전송 전 통신을 하기 전에 미리 논리적인 연결을 하는데, 이 작업을 3-Way Handshake라고 부른다. 전송 과정에서 패킷이 누락되거나 순서가 바뀌면 이를 감지하고 재전송을 요청해 데이터를 온전히 복구한다.
※ 3-Way Handshake는 데이터를 안전하게 주고받기 위해 3단계 과정을 통해 클라이언트와 서버가 모두 정상인지 상호 검증한다. 간단히 말하면 먼저 클라이언트에서 서버 방향 회선이 정상인지 확인하고, 이후 서버가 응답해 반대 방향 회선도 정상인지 확인하고, 최종적으로 클라이언트가 서버와 연결되었음을 알리는 과정으로 진행된다.
UDP는 신속성을 최우선으로 하는 프로토콜. 비연결형이다. 수신자의 상태와 상관 없이 데이터를 패킷 단위로 쪼개 목적지로 바로 전송한다. 데이터가 중간에 유실되거나 순서가 섞이더라도 수정, 재전송 작업을 거치지 않는다.
각 장단점이 존재한다. TCP는 데이터의 정확성을 보장하지만, 연결을 미리 설정하거나 데이터를 확인하는 과정이 필수기 때문에 전송 속도는 상대적으로 느릴 수 밖에 없다. 네트워크 자원도 더 많이 소모한다. 따라서 정확성이 중요한 웹 브라우징(HTTP/HTTPS), 파일 전송(FTP), 이메일(SMTP) 등 프로토콜의 기반이 된다.
UDP는 신뢰성은 보장하지 않지만, 부차적인 검증 과정이 생략되기에 속도가 매우 빠른데다 네트워크 부하가 적다. 따라서 신뢰성과 반응성이 중요한 실시간 스트리밍, 온라인 게임, 인터넷 전화 등에 사용된다. 또한 TCP는 일대일 연결인 유니캐스트만 지원하는 반면, UDP는 유니캐스트, 멀티캐스트, 브로드캐스트를 모두 지원한다. 목적지 주소로 패킷을 던지기만 하면 되기 때문이다.
다만 요즘은 UDP 기반의 QUIC(구글이 개발. TCP의 고질적 문제인 Head-of Line Blocking 문제를 구조적으로 해결했다. 꽤 많은 최신 웹 서비스들이 TCP 대신 QUIC을 사용한다고), WebRTC(UDP 기반 실시간 통신 환경에서 RTP/RTCP를 더해 타임스탬프를 부여. 이를 통해 패킷 재조립이 가능) 등 빠른 속도를 유지하면서도 TCP의 정확성을 담보하는 기술이 많아진 것으로 알고 있다. 물론 수십 년 간 구축된 레거시 시스템, 그리고 오랜 시간 TCP를 기반으로 최적화를 진행한 OS 커널 레벨의 경우 여전히 TCP가 유리한 것으로 알려져 있다.
※ Head-of Line Blocking는 데이터 처리 시 큐의 가장 앞에 있는 패킷 처리가 지연되거나 손실되어 그 뒤 모든 데이터 패킷들이 줄줄이 대기하게 되는 병목 현상을 말한다. QUIC은 UDP 기반이기 때문에 지연에 걸릴 일이 없다.
TCP와 UDP 헤더 구조 비교
TCP는 다음과 같이 구성된다. (20byte지만 옵션 포함 시 최대 60byte까지도 늘어남)
- Source Port (16bit): 데이터 보내는 애플리케이션 포트 번호.
- Destination Port (16bit): 데이터 받을 목적지 애플리케이션 포트 번호.
- Sequence Number (32bit): 전송 데이터 순서 지정 (분할된 데이터가 수신 측에서 순서대로 재조립되도록).
- Acknowledgment Number (32bit): 수신 측에서 정상적으로 데이터를 받았음을 송신 측에 알리고, 다음으로 받을 것으로 기대하는 데이터의 순서 번호를 명시.
- Data Offset (4bit): TCP 헤더 길이를 32비트 워드 단위로 나타냄.
- Reserved (3~6bit): 미래에 사용하려 남겨둔 필드. 기본값은 0.
- Flags (6bit): 연결 설정(SYN), 수신 확인(ACK), 종료(FIN), 재설정(RST), 푸시(PSH), 긴급(URG) 등 세션 상태 직접 제어.
- Window Size (16bit): 수신 측 버퍼 여유 용량을 송신 측에 알려 데이터 전송량을 조절하는 흐름 제어를 수행.
- Checksum (16bit): 헤더와 데이터의 무결성 검사, 전송 중 발생한 오류를 검출한다. (필수 사용)
- Urgent Pointer (16bit): URG 플래그가 설정됐을 때 긴급 데이터 위치를 나타냄.
- Options & Padding (Max 40byte): 최대 세그먼트 크기(MSS) 설정 등 부가 기능에 사용되며, 32비트 경계를 맞추기 위해 패딩을 추가할 수 있음.
UDP는 다음과 같이 구성된다. (8byte 고정)
- Source Port (16bit)
- Destination Port (16bit)
- Length (16bit): UDP 헤더(8바이트)와 실제 데이터를 모두 합친 전체 패킷의 바이트 길이.
- Checksum (16bit): 헤더와 데이터의 오류를 검출 용으로 사용. IPv4에서는 선택 사항이지만, IPv6에서는 필수로 요구된다.
Today I Listend to
'TIL' 카테고리의 다른 글
| [TIL] 차근차근 CS (5) - Keep-Alive (0) | 2026.07.13 |
|---|---|
| [TIL] 차근차근 CS (4) - DB의 역사와 발전 과정 (0) | 2026.07.11 |
| [TIL] 차근차근 CS (3) - Backend 역사와 발전 과정 (0) | 2026.07.10 |
| [TIL] 차근차근 CS (2) - Frontend 역사와 발전 과정 (0) | 2026.07.09 |
| [TIL] 차근차근 데이터 (1) - 윈도우 함수 (0) | 2026.07.08 |