પ્રોક્સી દ્વારા TCP શૂન્ય વિન્ડો: પ્રાપ્તકર્તા ઓળખો

પેકેટ ટ્રેસ કહે છે TCP ZeroWindow. કર્નલ સેટિંગ બદલતા પહેલાં શૂન્ય ઘોષિત કરતો અંતિમ બિંદુ ઓળખો.

તે અંતિમ બિંદુ આ TCP જોડાણ પરની પોતાની સ્વીકાર ક્ષમતા વર્ણવે છે. તે સમગ્ર પ્રોક્સી પાસે કેટલી બેન્ડવિડ્થ છે તે ઘોષિત કરતું નથી. શૂન્ય-વિન્ડો પ્રોબ મોકલનારને જણાવે છે કે તે ઘોષિત ક્ષમતા બદલાઈ છે કે નહીં; પ્રોબ એકલા પેકેટ નુકસાન કે તૂટેલી પ્રોક્સી સાબિત કરતા નથી.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

આ અલગ TCP વાતચીતો છે. ધારો કે બ્રાઉઝર મોટો પ્રતિભાવ વાંચવાનું બંધ કરે છે અને A પર શૂન્ય ઘોષિત કરે છે. પ્રોક્સીના પોતાના બફર ભરાતાં તે છેવટે B ખાલી કરવાનું બંધ કરી શકે છે. B પર પછીની શૂન્ય વિન્ડો મૂળ સમસ્યા નહીં પણ ધીમા ક્લાયન્ટનું પરિણામ હોઈ શકે છે.

અપલોડ દરમિયાન વિરુદ્ધ સ્થિતિ શક્ય છે. જો ગંતવ્ય એપ્લિકેશન ડેટા વાપરવાનું બંધ કરે, તો B પર તેની વિન્ડો બંધ થઈ શકે છે. પછી દબાણ પ્રોક્સીના બફર દ્વારા ક્લાયન્ટ તરફ પાછું જઈ શકે છે.

અવલોકનોને ક્રમમાં ગોઠવો

1. જોડાણના અંતિમ બિંદુઓ અને અસરગ્રસ્ત ડેટા ટ્રાન્સફરની દિશા નોંધો.
2. કયા અંતિમ બિંદુએ પહેલાં ઘટતી કે શૂન્ય સ્વીકાર વિન્ડો ઘોષિત કરી તે ઓળખો.
3. તેની એપ્લિકેશન વાંચી રહી હતી, બીજી ક્રિયા પર અટકી હતી કે સંસાધનોથી મર્યાદિત હતી તે તપાસો.
4. મૂળ કારણ નક્કી કરતા પહેલાં પ્રોક્સીના બીજા જોડાણ પરની સમયરેખા સરખાવો.

Wiresharkના વિન્ડો વિશ્લેષણ લેબલ કેપ્ચરનું ઉપયોગી અર્થઘટન છે, દરેક સ્વીકાર બફર વધારવાની સૂચના નથી. વિન્ડો સ્કેલિંગ પણ જોડાણની વાટાઘાટને ધ્યાનમાં રાખીને અર્થઘટિત કરવું જોઈએ.

પ્રોક્સી સૂચિમાંથી બીજું અંતિમ બિંદુ અજમાવીને ટ્રાન્સફર પુનઃપ્રાપ્ત થતું જોવું એ માર્ગ બદલાયો હોવાનો ઉપયોગી પુરાવો છે. પરંતુ તે પોતે સાબિત કરતું નથી કે કોઈ ઓપરેટિંગ સિસ્ટમનું TCP અમલીકરણ ખામીયુક્ત હતું. સમજૂતીને સ્વીકાર પ્રક્રિયા અને જ્યાં પ્રતીક્ષા શરૂ થઈ તે જોડાણ સાથે જોડી રાખો.