전송 계층 (TCP/UDP) - 신뢰성은 선택이다

지난 편 복습

3편의 핵심은 IP의 책임 범위였다. IP는 계층적 주소와 라우팅으로 패킷을 목적지 호스트까지 보내지만, 최선형 전달이라 유실·중복·순서 뒤바뀜을 복구하지 않는다.

이번 편의 질문은 두 가지다. 도착한 패킷은 어느 프로세스의 것인가? 그리고 IP가 미뤄둔 신뢰성은 누가 보장하는가?

포트: 프로세스의 주소

한 호스트 안에서는 브라우저, 메신저, 게임이 동시에 통신한다. IP 주소는 호스트까지만 식별하므로, 프로세스를 구분할 주소가 하나 더 필요하다. 이것이 포트(port), 16비트 번호다.

통신의 양 끝은 IP 주소:포트의 쌍으로 정해지며, 이 끝점을 소켓(socket) 이라고 부른다. 서버 쪽은 잘 알려진 포트(HTTP 80, HTTPS 443, DNS 53, SSH 22)에서 대기하고, 클라이언트 쪽은 운영체제가 임시 포트를 골라준다.

UDP: 거의 아무것도 하지 않는 계층

UDP(User Datagram Protocol) 의 헤더는 출발지/목적지 포트, 길이, 체크섬이 전부다. 즉 UDP는 IP의 최선형 전달에 포트 구분만 얹은 얇은 껍질이다. 연결 수립도, 재전송도, 순서 복원도 없다.

이것은 게으름이 아니라 선택지의 제공이다. 실시간 스트리밍이나 게임에서는 늦게 도착한 데이터를 재전송받는 것보다 그냥 버리는 편이 낫고, DNS처럼 질문 하나에 응답 하나로 끝나는 통신에는 연결 수립 비용 자체가 아깝다.

TCP: 신뢰성을 쌓아 올리다

TCP(Transmission Control Protocol) 는 IP의 최선형 전달 위에 신뢰성을 구축한다. 받아야 할 것은 빠짐없이, 순서대로, 정확히 한 번 전달한다는 약속이다.

연결 수립: 3-way handshake

TCP는 데이터를 보내기 전에 양쪽의 상태를 맞추는 연결(connection) 을 수립한다.

클라이언트                      서버
    | ── SYN (x로 시작할게) ──→ |
    | ←─ SYN+ACK (그래, 나는 y) |
    | ── ACK (확인) ──────────→ |
    연결 수립, 데이터 전송 시작

세 번의 왕복으로 양쪽은 서로의 시작 순서 번호(sequence number) 를 교환한다. 이후 모든 데이터는 이 번호를 기준으로 추적된다.

신뢰성: 순서 번호, ACK, 재전송

TCP는 보내는 모든 바이트에 순서 번호를 매긴다. 수신 측은 어디까지 받았는지를 ACK(acknowledgment) 로 알려주고, 순서가 어긋난 세그먼트는 버퍼에 쌓아 순서를 복원한다. 송신 측은 일정 시간 안에 ACK가 오지 않거나 같은 ACK가 반복되면 유실로 판단해 재전송한다. 3편에서 IP가 떠안지 않은 유실·중복·순서 문제가 모두 여기서 해결된다.

흐름 제어와 혼잡 제어

보내는 쪽이 무작정 빠르게 보내면 두 곳이 무너진다. 하나는 상대방이고, 하나는 네트워크다.

흐름 제어(flow control) 는 상대방을 보호한다. 수신 측이 ACK에 자신의 남은 버퍼 크기(수신 윈도우)를 실어 보내면, 송신 측은 그 이상을 보내지 않는다.

혼잡 제어(congestion control) 는 네트워크를 보호한다. 경로 중간의 라우터가 포화되면 패킷이 버려지기 시작하는데, 송신 측은 유실을 혼잡의 신호로 받아들여 전송량을 줄인다. 처음에는 조심스럽게 시작해 점점 빠르게 늘리고(slow start), 혼잡이 감지되면 물러선다. 인터넷이 수많은 TCP 연결로 붐비면서도 무너지지 않는 것은 모든 송신자가 이 규약으로 스스로를 조절하기 때문이다.

연결을 끝낼 때는 양쪽이 각자 보낼 것이 없음을 알리는 종료 절차(4-way)를 거친다.

TCP vs UDP

요약

핵심은 이것이다.

IP가 미뤄둔 신뢰성을 TCP가 구현하고, UDP는 그 비용 자체를 거부한다. 신뢰성은 의무가 아니라 선택이다.

다음 편 예고

이제 패킷은 올바른 호스트의 올바른 프로세스에, 순서대로 빠짐없이 도착한다. 남은 질문은 그 위에서 무엇을 주고받는가다. 다음 편에서는 응용 계층의 두 기둥, 이름을 주소로 바꾸는 DNS와 웹의 언어인 HTTP를 본다.