MSS წესი მუშაობს როუტერზე, მაგრამ Squid-ს ვერ აღწევს

ადმინისტრატორი FORWARD-ს TCPMSS შეზღუდვას უმატებს. პირდაპირ მარშრუტიზებული ტრაფიკი უმჯობესდება, მაგრამ ლოკალური Squid-ის ინსტანციით ჩამოტვირთვები მაინც ჩერდება. პროქსის კავშირი საიტთან უბრალოდ კლიენტის TCP კავშირი არ არის, რომელიც ამ ჯაჭვში გადის.

ჩვეულებრივ დამამთავრებელ forward პროქსში კლიენტის მხრის კავშირი ლოკალურად სრულდება. პროქსი ქმნის მეორე TCP კავშირს საწყისის ან მშობლისკენ. Linux-ზე ამ კავშირისთვის შექმნილი პაკეტები ლოკალურ გამომავალ გზას მიჰყვება.

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

ნუ ჩასვამთ PMTU რიცხვს პირდაპირ MSS-ში

ბილიკის MTU არის IP პაკეტის ზომა. TCP MSS აღწერს TCP დატვირთვას და უნდა გაითვალისწინოს შესაბამისი თავსართები. ანალოგიურად, ping-ის დატვირთვის სიგრძე არ არის IP პაკეტის სრული სიგრძე. ცნობილი 28 ბაიტის დამატება დაკავშირებულია ძირითად IPv4 ICMP echo განლაგებასთან და არა ყველა მისამართთა ოჯახთან ან ინკაფსულაციასთან.

TCPMSS სამიზნე აღწერს ცხად მნიშვნელობებს და PMTU შეზღუდვას. შეზღუდვა მაინც ეყრდნობა მარშრუტის MTU ინფორმაციას; ეს არ არის ბილიკის აღმოჩენის სიჯანსაღის დამტკიცება და არც საჭირო ICMP შეტყობინებების დაშვების შემცვლელი.

შეადარეთ სიმპტომი თეორიასაც. დასრულებული ხელის ჩამორთმევა და შემდეგ უფრო დიდ გადაცემებზე გაჩერება შეიძლება იყოს პაკეტის ზომის გამოკვლევის საფუძველი. განმეორებითი უპასუხო SYN-ები ან მყისიერი reset უფრო ფართო ახსნას მოითხოვს; პატარა პაკეტების წარუმატებლობა ზედმეტად დიდ მონაცემთა სეგმენტს არ ამტკიცებს.

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