프록시를 거치는 TCP 제로 윈도: 수신 측을 식별하라

패킷 트레이스는 TCP ZeroWindow 를 보여 줍니다. 커널 설정을 바꾸기 전에 0을 알리는 끝점을 먼저 식별하세요.

그 끝점은 해당 TCP 연결에서 자신의 수신 용량을 설명하는 것입니다. 프록시 전체가 가진 대역폭을 알리는 것이 아닙니다. 제로 윈도 프로브는 송신 측이 알려진 용량이 바뀌었는지 알아보게 해 줄 뿐이며, 프로브만으로는 패킷 손실이나 고장 난 프록시를 입증하지 못합니다.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

이 둘은 별개의 TCP 대화입니다. 브라우저가 큰 응답 읽기를 멈추고 A에서 0을 알린다고 가정해 봅시다. 프록시는 자신의 버퍼가 차면서 결국 B에서 데이터를 빼내는 일을 멈출 수 있습니다. 나중에 B에서 보이는 제로 윈도는 원래 문제가 아니라 느린 클라이언트의 결과일 수 있습니다.

업로드 중에는 반대 상황도 가능합니다. 목적지 애플리케이션이 데이터 소비를 멈추면 B 쪽 윈도가 닫힐 수 있습니다. 그러면 압력이 프록시의 버퍼를 거쳐 클라이언트 쪽으로 되돌아갈 수 있습니다.

관찰을 순서대로 정리하라

1. 연결의 양 끝점과 영향을 받은 데이터 전송 방향을 기록합니다.
2. 어느 끝점이 처음으로 줄어들거나 0이 된 수신 윈도를 알렸는지 식별합니다.
3. 그 애플리케이션이 읽고 있었는지, 다른 작업에서 멈춰 있었는지, 자원에 제약을 받았는지 확인합니다.
4. 원래 원인을 지정하기 전에 프록시의 다른 연결에서의 시점을 비교합니다.

Wireshark의 윈도 분석 표시는 캡처에 대한 유용한 해석일 뿐, 모든 수신 버퍼를 늘리라는 지시가 아닙니다. 윈도 스케일링도 연결의 협상 내용을 함께 보고 해석해야 합니다.

프록시 목록에서 다른 끝점을 시도해 전송이 회복되는 것을 보는 것은 경로가 바뀌었다는 유용한 증거입니다. 그러나 그것만으로 어떤 운영체제의 TCP 구현이 결함이 있었다고 증명되지는 않습니다. 설명은 수신 프로세스와 대기가 시작된 연결에 붙여 두세요.