Потокова передача через forward proxy проти буферизації всієї відповіді

Коли завантаження виглядає як очікування, розділіть три події: надходження заголовків відповіді, надходження байтів тіла й можливість застосунку використати або відобразити результат. Один індикатор завантаження не дає змоги визначити, що саме затримується.

Звичайні етапи потокової передачі можуть перекриватися:

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

Проксі може записувати придатний вміст у кеш, передаючи його далі. Кешування не потребує очікування всього файлу. read_ahead_gap у Squid керує вибиранням, що йде попереду доставки, — це інший вид буферизації.

Зворотний тиск може тимчасово зупиняти читання вище за потоком, коли повільний клієнт заповнює черги виводу. Content-Length також надає довжину без повної буферизації. Кодування HTTP/1.1 chunked дозволяє поступову доставку, але не може обіцяти низьку затримку, якщо попередній компонент утримує дані.

Далі перегляньте етапи обробки. Перезапис або перевірка можуть потребувати частини тіла чи всього тіла. Стиснення й кадрування застосунку можуть затримувати корисний вивід. На клієнті метод, що чекає на повний масив байтів, повертається пізніше, а браузер може отримати байти раніше, ніж зможе їх відобразити.

Після успішного CONNECT звичайний проксі передає потік сервісу, не потребуючи кінцевої довжини тунельованого файлу. Перш ніж змінювати налаштування буфера або тайм-ауту, простежте першу відсутню подію вище. Коли спостерігачем є curl, його параметр no-buffer змінює локальний етап виводу.