סטרימינג דרך פרוקסי קדמי לעומת חציצת תגובה מלאה

כאשר הורדה נראית ממתינה, הפרידו שלושה אירועים: הגעת כותרות התגובה, הגעת בתי הגוף ויכולת היישום להשתמש בתוצאה או להציג אותה. מחוון טעינה לבדו אינו יכול לזהות איזה מהם מתעכב.

שלבי הסטרימינג הרגילים יכולים לחפוף:

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

פרוקסי יכול לכתוב תוכן מתאים למטמון תוך כדי העברה. שמירה במטמון אינה מחייבת המתנה לקובץ כולו. read_ahead_gap של Squid שולט בשליפה שמתקדמת לפני המסירה, וזהו סוג אחר של חציצה.

לחץ נגדי יכול לעצור זמנית קריאות במעלה הזרם כאשר לקוח איטי ממלא את תורי הפלט. Content-Length מספק גם את האורך בלי לדרוש חציצה מלאה. קידוד HTTP/1.1 chunked מאפשר מסירה מדורגת, אך אינו יכול להבטיח השהיה נמוכה אם רכיב קודם מחזיק בנתונים.

בדקו לאחר מכן את שלבי העיבוד. שכתוב או בדיקה עשויים להזדקק לחלק מהגוף או כולו. דחיסה ומסגור יישום יכולים לעכב פלט שימושי. בצד הלקוח, שיטה שממתינה למערך בתים מלא חוזרת מאוחר יותר, ודפדפן עשוי לקבל בתים לפני שהוא יכול להציגם.

לאחר CONNECT מוצלח, פרוקסי רגיל מעביר את זרם השירות בלי להזדקק לאורך הסופי של הקובץ המנוהר. עקבו אחר האירוע החסר הראשון שלמעלה לפני שינוי הגדרות החציצה או פסק הזמן. כאשר curl הוא הצופה, אפשרות ה-no-buffer שלו משנה את שלב הפלט המקומי.