작은 세그먼트

작은 write는 패킷 수와 지연 요구 사이에서 판단한다

1바이트 TCP payload가 실제 세그먼트로 나가면 IPv4 20B와 TCP 20B의 L3/L4 헤더를 동반한다. 다만 write 호출 크기가 곧 세그먼트 크기라는 뜻은 아니며, OS 버퍼링, Nagle, TCP_NODELAY, flush 정책에 따라 묶이거나 즉시 나갈 수 있다.

1B payload가 세그먼트가 된 경우
App data애플리케이션이 쓴 실제 데이터1B
TCP header포트, seq/ack, flags, window20B+
IPv4 header주소, TTL, protocol, checksum20B+
L3/L4 최소 비용: payload 1B + TCP 20B + IPv4 20B = 41B
효율 판단

tinygram 문제는 “payload 비율”만의 문제가 아니다. NIC interrupt, 커널 경로, 방화벽, 프록시, 로드 밸런서가 모두 패킷 단위로 일을 하므로, 작은 패킷이 많으면 처리 비용과 큐잉이 커질 수 있다.

반대로 이미 애플리케이션이 충분히 버퍼링하거나 프레임 단위 지연이 더 중요하면, Nagle을 켜는 것이 체감 품질을 떨어뜨릴 수 있다.

1. 미확인 데이터 없음 첫 작은 세그먼트는 ACK를 기다릴 대상이 없으므로 보낼 수 있다.
2. 미확인 데이터 있음 새 작은 write는 버퍼에 모아 tinygram 연속 발생을 줄인다.
3. MSS만큼 쌓임 충분히 큰 세그먼트가 되면 ACK를 기다리지 않고 전송할 수 있다.
4. 앞 데이터 ACK 수신 미확인 데이터가 해소되면 모아둔 데이터를 한 번에 보낸다.
송신자: Nagle 작은 다음 write를 ACK 전까지 보류할 수 있다.
수신자: delayed ACK ACK만 보내는 일을 줄이려고 구현별 짧은 시간 동안 기다릴 수 있다.
작은 요청/응답 지연 영구 교착은 아니지만 타이머가 풀릴 때까지 불필요한 지연이 보인다.