요약

  • TCP의 PUSH 기능은 이미 제공된 데이터를 전달·전송할 때 추가 애플리케이션 바이트를 무한정 기다리지 말도록 전송 계층에 요청하는 것입니다.
  • PSH는 레코드 구분자가 아닙니다. SEND 버퍼, TCP 세그먼트, 수신 버퍼, 애플리케이션 메시지의 경계가 서로 일치할 필요는 없습니다.
  • RFC 9293은 PUSH를 애플리케이션에 노출하지 않는 구현을 허용하면서도, 무한정 버퍼링하는 것은 금지하고 송신 측에 더 이상 대기 중인 데이터가 없을 때 마지막 대기 세그먼트에 PSH를 설정하도록 요구합니다.
  • 메시지 구분이 필요한 애플리케이션은 TCP 위에서 이를 직접 제공해야 하며, 패킷 캡처만으로 PSH에서 권위 있는 레코드 경계를 복원할 수 없습니다.

편지에서 스트림으로

RFC 793은 이전 TCP 사양들이 시험했던 “편지(letter)” 개념 이후에 등장했습니다. 서문은 편지 메커니즘이 푸시(push) 함수로 재기술되었다고 밝힙니다. 이 구분은 중요합니다. 편지는 전달 이후에도 남는 단위의 가장자리를 암시합니다. 반대로 PUSH는 버퍼를 통한 진행에 관한 요청이 되었습니다.

사양은 TCP 데이터를 연속적인 옥텟 스트림으로 기술합니다. 송신 구현은 애플리케이션 데이터를 수집해 편의에 따라 세그먼트로 패키징할 수 있습니다. 사용자가 PUSH를 호출하면 TCP는 대기 중인 데이터를 전송해 수신자까지 신속히 전달하도록 요청받습니다. 이 요청은 스택이 대기할 수 있는 시간을 바꾸는 것이지, 데이터 모델을 스트림에서 레코드로 바꾸지는 않습니다.

일치하지 않아도 되는 네 가지 경계

완전한 명령 하나를 담은 하나의 애플리케이션 SEND를 생각해 봅시다. PUSH가 제공되고 선택된 경우 RFC 9293에 따르면 PSH는 그 버퍼에서 만들어진 마지막 TCP 세그먼트에 배치됩니다. 이를 한정하는 단어가 곧 메커니즘입니다. TCP는 버퍼를 여러 세그먼트로 분할하거나, 다른 데이터와 결합하거나, 패킷화 과정에서 연속적인 푸시 표시를 통합할 수 있습니다.

반대쪽 끝점에서는 PSH가 도착하기 전에 수신 버퍼가 가득 찰 수 있으므로, PUSH 표시 없이 데이터가 애플리케이션에 반환될 수 있습니다. PSH가 버퍼가 차기 전에 도착하면 이 표시를 노출하는 인터페이스는 부분적으로 채워진 버퍼를 반환할 수 있습니다. 애플리케이션은 송신 측 쓰기 크기와 무관한 크기로 읽기를 수행할 수도 있습니다.

따라서 쓰기 경계, 세그먼트 경계, 수신 버퍼 경계, 애플리케이션 메시지 경계는 서로 별개의 사실입니다. TCP가 보장하는 것은 순서가 유지되는 바이트 스트림이지 이들의 정렬이 아닙니다.

이 비트가 실제로 요청하는 것

PUSH의 역사적 목적은 제출된 바이트의 전달이 필요한데 송수신 어느 한쪽이 계속 추가 데이터를 기다리는 교착 상태를 피하는 것이었습니다. RFC 793은 수신 TCP가 PUSH를 확인한 뒤 추가 바이트를 기다리지 않고 가용 데이터를 상위로 전달하도록 요구했습니다.

RFC 9293은 API 경계를 명시하면서 이 기능을 유지합니다. TCP 끝점은 애플리케이션이 SEND에서 PUSH를 설정하도록 허용할 수 있습니다. 그 옵션이 없더라도 송신 측은 데이터를 무한정 버퍼링해서는 안 되며, 더 이상 대기 중인 데이터가 없을 때 마지막 버퍼링된 세그먼트에 PSH를 설정해야 합니다. 수신 측에서는 PUSH 표시를 애플리케이션에 노출하는 것이 선택 사항입니다.

따라서 PSH는 보편적인 애플리케이션 명령으로 읽을 수 없습니다. 이는 정확한 가시성이 인터페이스에 의존하는 전송 계층 신호이며, 핵심 목적은 구분이 아니라 진행입니다.

신속함이 무제한을 뜻하지는 않음

PUSH는 바이트가 다른 모든 전송 규칙을 우회한다는 약속도 아닙니다. 흐름 제어는 여전히 피어가 수용할 수 있는 양을 제한하고, 혼잡 제어는 여전히 네트워크로의 전송을 다룹니다. RFC 9293은 Nagle 알고리즘이 PUSH와 무관하게 데이터를 버퍼링할 수 있음을 언급하며, 가능한 한 최대 크기 세그먼트를 만들도록 권고합니다.

안전한 주장은 더 좁습니다. PUSH는 애플리케이션이 가용 데이터를 옮기기 위해 TCP가 이후의 SEND 호출만을 기다리기를 원하지 않는다는 뜻입니다. 특정 패킷 수, 특정 전달 시점, 특정 읽기 완료를 보장하지는 않습니다.

구분은 여전히 TCP 위에 존재

메시지가 필요한 애플리케이션 프로토콜은 메시지를 스스로 정의해야 합니다. 길이를 접두하거나, 구분자를 사용하거나, 고정 크기 구조를 전송하거나, 다른 구분 규칙을 채택할 수 있습니다. 수신자는 그 규칙에 따라 순서가 유지되는 스트림을 파싱하며, TCP가 전송 중 바이트를 어떻게 나누었는지는 무관합니다.

이 경계는 패킷 분석에도 규율을 부여합니다. PSH가 설정된 세그먼트는 한 번의 패킷화에서 그 지점에 푸시 표시가 놓였다는 증거입니다. 송신자가 정확히 한 번의 쓰기를 수행했다거나, 수신자가 정확히 한 번의 읽기를 반환했다거나, 애플리케이션 레코드가 거기서 끝났다는 증명은 아닙니다.

출처