TCP ნულოვანი ფანჯარა პროქსის გავლით: ამოიცანით მიმღები

პაკეტების კვალი აჩვენებს TCP ZeroWindow. ბირთვის პარამეტრის შეცვლამდე ამოიცანით ის ბოლო წერტილი, რომელიც ნულს აცხადებს.

ეს ბოლო წერტილი აღწერს თავის მიღების უნარს ამ TCP კავშირზე. ის არ აცხადებს, რამდენი გამტარობა აქვს მთელ პროქსის. ნულოვანი ფანჯრის შემოწმება გამგზავნს საშუალებას აძლევს გაიგოს, შეიცვალა თუ არა გამოცხადებული უნარი; შემოწმება მარტო არ ამტკიცებს პაკეტების დაკარგვას ან გაფუჭებულ პროქსის.

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

ეს ცალკეული TCP საუბრებია. დავუშვათ, ბრაუზერი წყვეტს დიდი პასუხის კითხვას და A-ზე ნულს აცხადებს. პროქსი საბოლოოდ შეიძლება შეწყვიტოს B-ის დაცლა, როცა მისი ბუფერები ივსება. B-ზე მოგვიანებით ნანახი ნულოვანი ფანჯარა შეიძლება ნელი კლიენტის შედეგი იყოს და არა საწყისი პრობლემა.

საპირისპირო მდგომარეობა ატვირთვის დროსაც შესაძლებელია. თუ დანიშნულების აპლიკაცია წყვეტს მონაცემების მოხმარებას, მისი ფანჯარა B-ზე შეიძლება დაიხუროს. წნევა შემდეგ შეიძლება უკან, კლიენტისკენ გადავიდეს პროქსის ბუფერებით.

დაალაგეთ დაკვირვებები

1. ჩაწერეთ კავშირის ბოლო წერტილები და დაზარალებული მონაცემთა გადაცემის მიმართულება.
2. განსაზღვრეთ, რომელმა ბოლო წერტილმა გამოაცხადა პირველად მცირდებადი ან ნულოვანი მიღების ფანჯარა.
3. შეამოწმეთ, მისი აპლიკაცია კითხულობდა, შეჩერებული იყო სხვა ოპერაციაზე თუ რესურსებით შეზღუდული.
4. შეადარეთ დრო პროქსის მეორე კავშირზე, სანამ საწყის მიზეზს მიაწერთ.

Wireshark-ის ფანჯრის ანალიზის ნიშნები ჩანაწერის სასარგებლო ინტერპრეტაციაა და არა მითითება ყველა მიღების ბუფერის გაზრდაზე. ფანჯრის მასშტაბიც კავშირის მოლაპარაკების გათვალისწინებით უნდა განიმარტოს.

პროქსების სიიდან სხვა ბოლო წერტილის გამოცდა და გადაცემის აღდგენის დანახვა სასარგებლო მტკიცებულებაა, რომ გზა შეიცვალა. თავისთავად ის არ ამტკიცებს, რომ რომელიმე ოპერაციული სისტემის TCP რეალიზაცია ნაკლოვანი იყო. შეინარჩუნეთ ახსნა მიმღებ პროცესსა და იმ კავშირთან, სადაც ლოდინი დაიწყო.