წინა პროქსი TCP სეგმენტების საზღვრებს არ ინახავს

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

წინა პროქსის ჩვეულებრივ ორი კავშირი აქვს:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

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

სამი საზღვარი, რომელიც ცალკე უნდა შევინარჩუნოთ

ერთი წაკითხვა შეიძლება შეიცავდეს სათაურის ნაწილს, მთელ სათაურს სხეულის ბაიტებთან ერთად, ან მონაცემებს, რომლებიც ერთზე მეტ აპლიკაციის დონის საზღვარს კვეთს. TCP „HTTP პასუხის დასასრულს“ წარმატებული წაკითხვის დასასრულს არ აკავშირებს.

ამიტომ HTTP/1.1 პარსერი აგროვებს სათაურებს და იყენებს სხეულის ჩარჩოვნების შესაბამის წესებს, მათ შორის სიგრძეს, გადაცემის კოდირებას ან დაშვებულ კავშირის დახურვას. HTTP/2 ჩარჩო პროტოკოლური სტრუქტურაა, რომელსაც თავად შეუძლია TCP სეგმენტების გადაკვეთა; ეს ქსელური პაკეტის სხვა სახელი არ არის.

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

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