Forward proxy axını və tam cavab buferləməsi

Yükləmə gözləyirmiş kimi görünəndə üç hadisəni ayırın: cavab başlıqlarının gəlməsi, gövdə baytlarının gəlməsi və tətbiqin nəticəni istifadə edə və ya göstərə bilməsi. Yalnız spinner hansının gecikdiyini müəyyən edə bilməz.

Normal axın mərhələləri üst-üstə düşə bilər:

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

Proxy ötürərkən uyğun məzmunu keşə yaza bilər. Keşləmə bütün faylı gözləməyi tələb etmir. Squid-in read_ahead_gap parametri çatdırılmadan irəlidə gedən götürməni idarə edir ki, bu da başqa bufer növüdür.

Yavaş müştəri çıxış növbələrini doldurduqda əks təzyiq yuxarı axın oxunuşlarını müvəqqəti dayandıra bilər. Content-Length də tam bufer tələb etmədən uzunluğu verir. HTTP/1.1 chunked kodlaşdırması mərhələli çatdırılmaya icazə verir, lakin əvvəlki komponent məlumatı saxlayırsa, aşağı gecikmə vəd edə bilməz.

Sonra emal mərhələlərini yoxlayın. Yenidən yazma və ya yoxlama gövdənin bir hissəsini və ya hamısını tələb edə bilər. Sıxılma və tətbiq çərçivələməsi faydalı çıxışı gecikdirə bilər. Müştəri tərəfində tam bayt massivi gözləyən metod qayıtmadan əvvəl gözləyir, brauzer isə baytları göstərə bilmədən əvvəl qəbul edə bilər.

Uğurlu CONNECT-dən sonra adi proxy tunellənmiş faylın son uzunluğuna ehtiyac duymadan xidmət axınını ötürür. Bura və ya timeout parametrlərini dəyişməzdən əvvəl yuxarıdakı ilk çatışmayan hadisəni izləyin. curl müşahidəçi olduqda, onun no-buffer seçimi yerli çıxış mərhələsini dəyişir.