Forward proxy streaming နှင့် အပြည့်အစုံ တုံ့ပြန်မှု buffering

ဒေါင်းလုဒ်တစ်ခု စောင့်နေပုံရသောအခါ ဖြစ်ရပ်သုံးခုကို ခွဲခြားပါ- တုံ့ပြန်မှု ခေါင်းစီးများ ရောက်လာခြင်း၊ ကိုယ်ထည် ဘိုက်များ ရောက်လာခြင်း၊ နှင့် application က ရလဒ်ကို အသုံးပြုနိုင် သို့မဟုတ် ပြသနိုင်ခြင်း။ spinner တစ်ခုတည်းဖြင့် မည်သည့်အရာ နောက်ကျနေသည်ကို မဖော်ထုတ်နိုင်ပါ။

ပုံမှန် streaming အဆင့်များ ထပ်နေနိုင်သည်-

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

Proxy သည် ထပ်ဆင့်ပို့နေစဉ် သင့်လျော်သော အကြောင်းအရာကို cache သို့ ရေးနိုင်သည်။ cache လုပ်ရန် ဖိုင်တစ်ခုလုံးကို စောင့်ရန် မလိုပါ။ Squid ၏ read_ahead_gap သည် ပေးပို့မှုထက် ရှေ့ရောက်နေသော ရယူမှုကို ထိန်းချုပ်သည်၊ ယင်းမှာ အခြား buffering အမျိုးအစားဖြစ်သည်။

နှေးကွေးသော client က output တန်းများကို ပြည့်စေသောအခါ backpressure သည် အထက် ဖတ်ခြင်းကို ခေတ္တ ရပ်တန့်နိုင်သည်။ Content-Length သည်လည်း buffering အပြည့်အစုံ မလိုဘဲ အရှည်ကို ပေးသည်။ HTTP/1.1 chunked encoding သည် အဆင့်ဆင့် ပေးပို့မှုကို ခွင့်ပြုသော်လည်း ရှေ့အစိတ်အပိုင်းက ဒေတာကို ချုပ်ကိုင်ထားပါက နိမ့်သော latency ကို ကတိမပေးနိုင်ပါ။

ထို့နောက် လုပ်ဆောင်မှု အဆင့်များကို စစ်ဆေးပါ။ ပြန်ရေးခြင်း သို့မဟုတ် စစ်ဆေးခြင်းသည် ကိုယ်ထည်၏ အစိတ်အပိုင်း သို့မဟုတ် တစ်ခုလုံး လိုအပ်နိုင်သည်။ ချုံ့ခြင်းနှင့် application framing သည် အသုံးဝင်သော output ကို နောက်ကျစေနိုင်သည်။ client တွင် byte array အပြည့်အစုံကို စောင့်သော နည်းလမ်းသည် နောက်ကျမှ ပြန်လာသည်၊ browser သည် မပြနိုင်မီ ဘိုက်များကို လက်ခံရနိုင်သည်။

CONNECT အောင်မြင်ပြီးနောက် သာမန် proxy သည် tunnel လုပ်ထားသော ဖိုင်၏ နောက်ဆုံး အရှည်ကို မသိဘဲ ဝန်ဆောင်မှု stream ကို ထပ်ဆင့်ပို့သည်။ buffer သို့မဟုတ် အချိန်ကန့်သတ် ဆက်တင်များ မပြောင်းမီ အထက်ပါ ပထမဆုံး ပျောက်ဆုံးနေသော ဖြစ်ရပ်ကို လိုက်နာပါ။ curl သည် လေ့လာသူဖြစ်သောအခါ ၎င်း၏ no-buffer ရွေးချယ်မှုသည် ဒေသခံ output အဆင့်ကို ပြောင်းလဲသည်။