포워드 프록시 스트리밍과 전체 응답 버퍼링의 차이

다운로드가 기다리는 것처럼 보일 때는 세 가지 사건을 구분해야 합니다. 응답 헤더 도착, 본문 바이트 도착, 그리고 애플리케이션이 결과를 사용하거나 렌더링할 수 있는지입니다. 스피너만으로는 어느 단계가 지연되는지 알 수 없습니다.

정상적인 스트리밍 단계는 겹칠 수 있습니다.

origin produces a chunk → proxy forwards bytes → client consumes them

프록시는 중계하면서 해당 콘텐츠를 캐시에 기록할 수 있습니다. 캐싱에 파일 전체를 기다릴 필요는 없습니다. Squid의 read_ahead_gap 는 전달보다 앞서 진행되는 가져오기를 제어하며, 이는 또 다른 종류의 버퍼링입니다.

느린 클라이언트가 출력 큐를 채우면 배압이 업스트림 읽기를 일시적으로 멈출 수 있습니다. Content-Length 역시 전체 버퍼링 없이 길이를 알려 줍니다. HTTP/1.1 chunked 인코딩은 점진적 전달을 허용하지만, 앞선 구성 요소가 데이터를 붙잡고 있으면 낮은 지연을 보장할 수 없습니다.

다음으로 처리 단계를 살펴보십시오. 재작성이나 검사에는 본문의 일부 또는 전체가 필요할 수 있습니다. 압축과 애플리케이션 프레이밍은 유용한 출력을 지연시킬 수 있습니다. 클라이언트에서는 전체 바이트 배열을 기다리는 방식이 더 늦게 반환되고, 브라우저는 렌더링하기 전에 바이트를 받을 수 있습니다.

CONNECT가 성공한 뒤 일반 프록시는 터널링된 파일의 최종 길이를 몰라도 서비스 스트림을 중계합니다. 버퍼나 타임아웃 설정을 바꾸기 전에 위의 첫 번째 빠진 사건을 추적하십시오. curl이 관찰자일 때 그 no-buffer 옵션은 로컬 출력 단계를 바꿉니다.