daily.log
cd ../
Network·2026-02-09·4 min read·# entry/018

전송 계층(Transport Layer): 신뢰성의 심장부, TCP와 UDP

데이터의 배달을 책임지는 전송 계층. 다중화/역다중화의 원리부터 TCP의 3-way Handshake, 그리고 신뢰성 보장 메커니즘(RDT)까지 깊이 있게 파헤칩니다.

전송 계층

애플리케이션 계층이 '무엇을 보낼까'를 고민했다면, 전송 계층은 그 데이터를 **'어떻게, 얼마나 신뢰성 있게 보낼 것인가'**를 책임지는 네트워크의 심장부입니다.

이곳은 인터넷의 두 주인공인 UDP와 TCP가 활약하는 무대이기도 합니다.

1. 전송 계층의 핵심: 프로세스 간 통신

네트워크 계층(IP)이 '컴퓨터와 컴퓨터(Host-to-Host)' 사이의 배달을 책임진다면, 전송 계층은 그 컴퓨터 안에서 실행 중인 **특정 프로세스(Process-to-Process)**까지 데이터를 배달합니다.

다중화와 역다중화 (Multiplexing & Demultiplexing)

하나의 IP 주소를 가진 컴퓨터에서 브라우저, 카톡, 유튜브가 동시에 통신할 수 있는 비결입니다.

  • 다중화 (Multiplexing): 여러 소켓에서 나오는 데이터를 모아 헤더(포트 번호 등)를 붙여 아래(IP 계층)로 내려보내는 과정입니다. (송신)
  • 역다중화 (Demultiplexing): 아래에서 올라온 데이터를 헤더의 포트 번호를 보고 올바른 소켓으로 전달하는 과정입니다. (수신)

2. UDP vs TCP: 속도냐 신뢰냐

전송 계층의 두 가지 선택지, UDP와 TCP를 비교해 봅시다.

User Datagram Protocol 전송 계층이 할 수 있는 최소한의 일만 합니다.

  • 특징: 비연결형(Handshake 없음), 확인 응답 없음, 순서 보장 안 됨. * 장점: 헤더가 가볍고 전송 속도가 매우 빠릅니다. * 용도: DNS, 실시간 스트리밍, 온라인 게임, HTTP/3(QUIC).

3. 신뢰성 있는 데이터 전송 (rdt)

하위 계층인 IP는 패킷을 잃어버리거나 비트를 깨먹을 수 있는 **'신뢰할 수 없는 채널'**입니다. TCP는 이 부실한 토대 위에서 어떻게 신뢰성을 쌓아 올릴까요?

시련과 극복 메커니즘

  1. 비트 에러 (Bit Error): "데이터가 깨졌어!"
    • 해결책: **체크섬(Checksum)**으로 데이터 무결성을 검사하고, **ACK(긍정 응답)/NAK(부정 응답)**로 재전송을 요청합니다.
  2. 패킷 손실 (Packet Loss): "데이터가 안 와!"
    • 해결책: **타이머(Timer)**를 설정합니다. 일정 시간(Timeout) 동안 응답이 없으면 잃어버린 것으로 간주하고 다시 보냅니다.
  3. 중복 패킷 (Duplicate): "아까 받은 건데?"
    • 해결책: **순서 번호(Sequence Number)**를 붙여서 중복된 데이터는 버립니다.

전송 효율의 혁명: 파이프라이닝 (Pipelining)

하나 보내고 응답을 기다리는 방식(Stop-and-Wait)은 너무 느립니다. 그래서 현대 TCP는 응답을 기다리지 않고 패킷을 쏟아붓는 파이프라이닝을 사용합니다.

  • Go-Back-N: 에러가 난 시점부터 그 뒤에 보낸 것까지 전부 다시 보냅니다. (단순함)
  • Selective Repeat: 망가진 녀석만 쏙 골라서 다시 보냅니다. (효율적, 버퍼 필요)

4. TCP 3-way Handshake 상세

TCP 통신의 시작은 "우리 이제 대화하자"라고 약속하는 3-way Handshake입니다. 이 과정의 핵심은 **초기 순서 번호(ISN)**를 동기화하는 것입니다.

1

1단계: SYN (Client → Server)

클라이언트가 서버에 접속 요청(SYN)을 보냅니다. * "내 순서 번호는 $x$야. 연결해 줘." * 상태: SYN_SENT

2

2단계: SYN-ACK (Server → Client)

서버가 요청을 수락하고 확인 응답(SYN-ACK)을 보냅니다. * "그래, $x$번 잘 받았어(ACK $x+1$). 내 순서 번호는 $y$야(SYN)." * 상태: SYN_RCVD

3

3단계: ACK (Client → Server)

클라이언트가 서버의 수락을 확인했다는 응답(ACK)을 보냅니다. * "그래, $y$번 잘 받았어(ACK $y+1$). 이제 데이터 보낼게." * 상태: ESTABLISHED (연결 성립)

Frontend Insight: RTT와 성능

이 핸드쉐이크 과정 때문에 TCP 연결을 맺는 데는 무조건 **1 RTT(왕복 시간)**가 소요됩니다. (HTTPS는 TLS까지 더해져 더 오래 걸림) 현대 브라우저는 이를 최적화하기 위해 Keep-alive(연결 재사용)나 TCP Fast Open 같은 기술을 사용합니다.

5. 연결의 종료: 4-way Handshake

연결을 끊을 때는 더 신중해야 합니다. 한쪽이 "끊자"고 해도 반대쪽은 보낼 데이터가 남아있을 수 있기 때문입니다.

따라서 FIN - ACK - FIN - ACK의 4단계 과정을 거쳐 양쪽 모두 보낼 데이터가 없음을 확인하고 연결을 종료합니다.