การสตรีมผ่านพร็อกซีขาเปรียบเทียบกับการบัฟเฟอร์การตอบกลับทั้งหมด

เมื่อการดาวน์โหลดดูเหมือนรอ ให้แยกสามเหตุการณ์: การมาถึงของส่วนหัวการตอบกลับ การมาถึงของไบต์เนื้อหา และความสามารถของแอปในการใช้หรือแสดงผลลัพธ์ ตัวหมุนเพียงอย่างเดียวไม่สามารถระบุได้ว่าสิ่งใดล่าช้า

ขั้นตอนการสตรีมปกติสามารถคาบเกี่ยวกันได้:

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

พร็อกซีสามารถเขียนเนื้อหาที่เข้าเกณฑ์ลงแคชขณะส่งต่อ การแคชไม่ต้องรอไฟล์ทั้งหมด read_ahead_gap ของ Squid ควบคุมการดึงข้อมูลที่วิ่งนำหน้าการส่งมอบ ซึ่งเป็นการบัฟเฟอร์อีกชนิดหนึ่ง

แรงดันย้อนกลับสามารถหยุดการอ่านต้นทางชั่วคราวเมื่อไคลเอนต์ที่ช้าเติมคิวขาออกจนเต็ม Content-Length ก็ให้ความยาวโดยไม่ต้องบัฟเฟอร์ทั้งหมด การเข้ารหัส HTTP/1.1 chunked อนุญาตการส่งมอบทีละส่วน แต่ไม่สามารถรับประกันความหน่วงต่ำได้หากองค์ประกอบก่อนหน้าถือข้อมูลไว้

จากนั้นตรวจสอบขั้นตอนการประมวลผล การเขียนใหม่หรือการตรวจสอบอาจต้องใช้เนื้อหาบางส่วนหรือทั้งหมด การบีบอัดและการจัดกรอบแอปอาจทำให้เอาต์พุตที่มีประโยชน์ล่าช้า ฝั่งไคลเอนต์ วิธีที่รอไบต์อาร์เรย์ทั้งหมดจะคืนค่าช้ากว่า และเบราว์เซอร์อาจได้รับไบต์ก่อนที่จะแสดงได้

หลัง CONNECT สำเร็จ พร็อกซีทั่วไปส่งต่อสตรีมของบริการโดยไม่ต้องรู้ความยาวสุดท้ายของไฟล์ที่อุโมงค์ ติดตามเหตุการณ์แรกที่หายไปข้างต้นก่อนเปลี่ยนการตั้งค่าบัฟเฟอร์หรือหมดเวลา เมื่อ curl เป็นผู้สังเกต ตัวเลือก no-buffer จะเปลี่ยนขั้นตอนเอาต์พุตภายใน