여덟 번째 발걸음TCP는 바이트의 순서를, UDP는 메시지의 경계를 다룬다

IP가 서버까지 패킷을 보냈다고 그 안의 어느 프로그램에 줄지는 아직 남아 있습니다. 하나의 서버에는 웹과 파일 전송, 관리 서비스가 함께 있을 수 있습니다. 전송 계층의 포트는 통신 끝점을 구분하는 번호입니다. TCP와 UDP는 각각 16비트 포트 공간을 사용하므로 같은 숫자라도 TCP 53과 UDP 53은 구별됩니다. 널리 알려진 번호는 약속된 용도를 찾는 단서지만, 그 포트에서 반드시 그 서비스만 동작한다는 보장은 아닙니다.

통신은 흔히 출발 IP·출발 포트·목적 IP·목적 포트·프로토콜이라는 다섯 정보로 구별합니다. 웹 서버가 같은 목적 포트로 여러 사용자의 요청을 받아도 상대의 주소와 임시 포트가 달라 각 흐름을 구분할 수 있습니다. NAT나 프록시를 거치면 관찰 지점에서 보이는 일부 값이 달라질 수 있어 로그를 합칠 때 위치까지 알아야 합니다. 포트 번호 자체에는 사용자의 업무 권한이나 메시지의 신뢰를 증명하는 기능이 없습니다.

TCP는 연결 양쪽의 상태를 관리하면서 순서 있는 바이트 스트림을 제공합니다. 받은 자료를 순서대로 모으고 손실을 발견하면 재전송하여 복구합니다. 응용 프로그램이 두 번 나누어 보낸 자료가 상대에게 반드시 두 번의 읽기로 나뉘어 도착하는 것은 아닙니다. 메시지의 시작과 끝은 응용 프로토콜이 길이나 구분자를 사용해 정해야 합니다. “TCP가 신뢰성 있다”는 말은 암호화되거나 상대가 정당하다는 뜻이 아니라 전송 순서와 손실 처리 같은 성질을 가리킵니다.

연결을 시작할 때의 대표적인 세 번 교환은 SYN, SYN과 ACK, ACK입니다. 양쪽의 초기 순서 번호를 교환하고 상대가 그 시작점을 받았는지 확인합니다. 헤더의 Sequence Number는 보낼 바이트의 순서, Acknowledgment Number는 다음에 기대하는 바이트 위치를 나타냅니다. SYN과 FIN도 순서 번호 공간에서 각각 한 자리를 차지합니다. ACK만 있는 세그먼트는 그것만으로 데이터 순서를 한 칸 늘리지 않습니다. 이 차이를 실제 숫자로 따라가 봅시다.

TCP의 윈도는 수신자가 받을 수 있는 양을 알려 주어 상대를 넘치게 보내지 않도록 하는 흐름 제어와 연결됩니다. 네트워크 자체의 혼잡을 줄이기 위한 혼잡 제어도 별도로 동작합니다. 느려진 전송을 볼 때 수신자의 처리 부족과 경로의 혼잡·손실을 나누는 이유입니다. 연결 종료에서는 FIN을 통해 각 방향의 전송 종료를 알릴 수 있고, RST는 연결을 즉시 중단시키는 신호로 쓰입니다. FIN 교환이 실제 화면에서 언제나 정확히 네 패킷으로 따로 보인다고 외우지는 않습니다.

UDP는 출발·목적 포트, 길이, 체크섬을 담은 기본 8바이트 헤더로 데이터그램을 전달합니다. UDP 자체는 TCP처럼 연결 설정과 순서 재조립, 재전송을 제공하지 않습니다. 대신 메시지의 경계를 유지하며 단순하게 전달합니다. 손실을 허용하거나 응용 프로그램이 필요한 복구를 선택하는 경우에 쓰일 수 있습니다. UDP를 쓰면 무조건 빠르고 안전성이 낮다고 단정할 수는 없습니다. 예를 들어 QUIC은 UDP 위에서 신뢰성 있는 전송과 암호학적 보호 등을 구현합니다. 기반 프로토콜과 그 위에 추가된 기능을 나누어 보아야 합니다.

TCP와 UDP 체크섬은 전송 오류 검출을 위한 것이며 공격자의 변조 방지와 신원 확인을 완성하지 않습니다. 이 때문에 업무에서는 TLS 등 별도 보안 프로토콜을 사용합니다. 다음 방향에서 다룰 암호화가 필요한 이유는 IP와 TCP를 익혔기 때문에 더 명확해집니다. 목적지까지 순서대로 왔다는 사실과, 진짜 상대가 보냈으며 중간에 악의적으로 바뀌지 않았다는 사실은 다른 조건입니다.

참고　[87] · [88] · [89]