Strumieniowanie przez forward proxy a buforowanie całej odpowiedzi

Gdy pobieranie wydaje się czekać, oddziel trzy zdarzenia: nadejście nagłówków odpowiedzi, nadejście bajtów treści i możliwość użycia lub wyświetlenia wyniku przez aplikację. Sam wskaźnik ładowania nie wskaże, które z nich się opóźnia.

Normalne etapy strumieniowania mogą się nakładać:

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

Proxy może zapisywać odpowiednią treść do pamięci podręcznej, przekazując ją dalej. Buforowanie nie wymaga czekania na cały plik. read_ahead_gap Squida steruje pobieraniem wyprzedzającym dostarczanie, co jest innym rodzajem buforowania.

Przeciwciśnienie może tymczasowo zatrzymać odczyt w górę strumienia, gdy wolny klient zapełni kolejki wyjściowe. Content-Length również podaje długość bez pełnego buforowania. Kodowanie HTTP/1.1 chunked pozwala na dostarczanie stopniowe, ale nie gwarantuje niskiego opóźnienia, jeśli wcześniejszy komponent zatrzymuje dane.

Następnie sprawdź etapy przetwarzania. Przepisywanie lub inspekcja mogą wymagać części lub całej treści. Kompresja i ramkowanie aplikacji mogą opóźniać użyteczne wyjście. Po stronie klienta metoda oczekująca pełnej tablicy bajtów zwraca wynik później, a przeglądarka może odebrać bajty, zanim zdoła je wyświetlić.

Po udanym CONNECT zwykłe proxy przekazuje strumień usługi bez potrzeby znajomości końcowej długości tunelowanego pliku. Przed zmianą ustawień bufora lub limitu czasu prześledź pierwsze brakujące zdarzenie powyżej. Gdy obserwatorem jest curl, jego opcja no-buffer zmienia lokalny etap wyjścia.