13장 TCP가 보장하는 것과 보장하지 않는 것

파일을 보내면서 인터넷 중간의 모든 장비가 한 번도 실수하지 않기를 기대할 수는 없다. 패킷은 사라지거나 순서가 바뀌거나 중복될 수 있다. TCP는 이런 환경에서 응용 프로그램에 신뢰할 수 있는 순서 있는 바이트 스트림을 제공한다. 송신과 수신 상태를 관리하고, 확인 응답과 재전송을 사용한다. 그러나 상대가 데이터를 업무적으로 처리했다는 보장까지 제공하지는 않는다.

TCP 확인 응답을 받았다는 것은 상대 TCP가 해당 바이트를 받았다는 의미에 가깝다. 데이터베이스에 저장됐는지, 결제가 완료됐는지, 사람이 메시지를 읽었는지는 다른 계층의 문제다. 신뢰할 수 있는 전송이라는 말을 “내가 원한 결과가 반드시 한 번 발생한다”로 확대하면 분산 시스템에서 사고가 난다. 전송의 책임과 업무의 책임은 분리해야 한다.

연결의 양 끝을 구별하기

IP 주소가 장치 쪽의 위치를 식별한다면 포트는 전송 계층에서 응용 프로그램을 구분하는 데 쓰인다. TCP 연결은 출발지와 목적지의 주소·포트 조합으로 구별한다. 서버가 443 포트에서 기다리더라도 모든 사용자의 출발지 포트가 같을 필요는 없다. 클라이언트 운영체제가 임시 포트를 배정하는 것이 일반적이다.

포트가 열려 있다는 말도 범위를 밝혀야 한다. 프로그램이 특정 주소의 포트에서 듣고 있는지, 로컬 방화벽이 허용하는지, 외부 경로에서도 도달 가능한지가 다르다. 127.0.0.1에만 바인딩한 서비스는 같은 컴퓨터에서 사용할 수 있지만 외부 주소로 직접 접속할 수는 없다. 반대로 모든 인터페이스에 바인딩하면 공개 가능 범위가 넓어지므로 접근 제어를 확인해야 한다.

TCP 연결을 맺을 때 흔히 설명하는 세 번의 핸드셰이크는 양쪽이 상태를 맞추는 과정이다. 인터넷이 먼 경우 이 왕복 시간이 처음 요청의 지연에 영향을 준다. 연결을 재사용하면 매번 새로 준비하는 비용을 줄일 수 있다. 다만 오래된 연결은 중간 장비의 시간 제한으로 끊겨 있을 수 있으므로 재사용 실패를 다루는 방법도 필요하다.

두 종류의 속도 조절

흐름 제어는 수신자가 감당할 수 있는 양을 고려한다. 혼잡 제어는 네트워크가 감당할 수 있는 전송을 탐색한다. 받는 컴퓨터의 버퍼가 충분해도 경로가 혼잡하면 속도를 조절해야 하고, 경로가 비어 있어도 수신 프로그램이 읽지 않으면 계속 보낼 수 없다. “윈도 크기”라는 말이 나왔을 때 어느 상태를 뜻하는지 확인해야 한다.

TCP가 순서대로 데이터를 전달한다는 성질은 기다림도 만든다. 앞부분이 사라졌는데 뒤 데이터가 도착한 경우, 응용 프로그램에는 빠진 부분을 해결한 뒤 순서대로 제공해야 한다. 이것이 어떤 서비스에서는 안정성을 주고 어떤 실시간 상황에서는 지연 부담이 된다. 모든 응용에 같은 전송 특성이 적합한 것은 아니다.

UDP는 데이터그램 단위의 전송을 제공하며 TCP와 같은 연결 설정, 순서 보장, 재전송을 자체적으로 제공하지 않는다. 따라서 가볍게 시작할 수 있지만 필요한 신뢰성과 혼잡 제어는 그 위의 프로토콜이 설계해야 한다. UDP를 사용한다고 무조건 빠르거나 무조건 신뢰성이 없다는 표현은 부정확하다. QUIC처럼 UDP 위에 풍부한 전송 기능을 구현하는 프로토콜도 있다.

시간 초과는 위치를 알려 주지 않는다

연결 시간 초과와 응답 읽기 시간 초과는 서로 다른 상황이다. 전자는 상대에게 연결을 성립시키지 못한 경우이고 후자는 연결 이후 필요한 데이터가 제때 오지 않은 경우다. DNS 조회 시간도 따로 있다. 사용 도구가 어떤 구간에 제한을 적용하는지 확인해야 한다. 모든 시간 제한을 하나의 숫자로만 관리하면 원인을 구분하기 어렵다.

연결 거절은 대상에 도달해 거부 응답을 받았다는 단서가 될 수 있다. 시간 초과는 응답이 안 왔다는 사실을 말할 뿐, 중간에서 버렸는지 서버가 받았지만 답하지 못했는지 확정하지 못한다. 오류 메시지의 차이를 기록하되 과도한 결론을 붙이지 말자. 네트워크 진단은 불확실성을 없애는 일이 아니라 불확실성의 범위를 줄이는 일이다.

종료된 연결의 상태가 잠시 남는 것도 이상 현상은 아니다. TCP에는 지연된 패킷과 연결 재사용을 안전하게 다루기 위한 상태가 있다. 상태 이름을 보고 인터넷의 조언대로 시간을 무작정 줄이면 안정성을 해칠 수 있다. 연결을 너무 자주 만들고 버리는 프로그램 구조, 포트 자원, 중간 장비 상태를 함께 살펴야 한다.

파일 전송은 끝났는데 서비스가 실패했다고 말할 때 당황하지 말자. 전송, 프로토콜 응답, 데이터 저장, 사용자 확인은 서로 다른 완료 지점이다. 로그와 모니터링에도 그 지점을 구별해 남기면 누구의 책임인지 싸우기보다 어느 단계에서 멈췄는지 조사할 수 있다. TCP를 이해하는 가장 실용적인 방법은 그 보장을 정확한 범위 안에서 믿는 것이다.