Правило MSS працює на маршрутизаторі, але не дістає Squid
Застосовуйте логіку MTU до окремих TCP-з'єднань, які відкриває проксі, замість припущення, що кожен пакет проходить через FORWARD.
Адміністратор додає обмеження TCPMSS у FORWARD. Прямо маршрутизований трафік поліпшується, але завантаження через локальний примірник Squid усе ще зависають. З'єднання проксі із сайтом — це не просто TCP-з'єднання клієнта, що проходить цим ланцюгом.
У звичайному термінувальному forward-проксі з'єднання з боку клієнта завершується локально. Проксі створює друге TCP-з'єднання до джерела або батьківського вузла. У Linux пакети, породжені для цього з'єднання, ідуть локальним шляхом виводу.
Тому правило лише для FORWARD може бути цілком робочим і все ж промахуватися повз рукостискання, яке мало скоригувати. Перш ніж обирати точку перехоплення, намалюйте реальне з'єднання й напрямок SYN. Контейнери або окремі простори імен можуть додати ще одну маршрутизовану ділянку, тож правильне місце залежить від того, де працює процес.
Не вставляйте число PMTU прямо в MSS
MTU шляху — це розмір IP-пакета. TCP MSS описує корисне навантаження TCP і має враховувати відповідні заголовки. Так само довжина корисного навантаження ping — не повна довжина IP-пакета. Звичне додавання 28 байтів пов'язане з базовою схемою IPv4 ICMP echo, а не з будь-якою родиною адрес чи інкапсуляцією.
Ціль TCPMSS документує явні значення й обмеження PMTU. Обмеження все ще спирається на відомості MTU маршруту; це не доказ здоров'я виявлення шляху і не заміна дозволу потрібних ICMP-повідомлень.
Порівняйте й симптом із теорією. Завершене рукостискання з подальшими зупинками на великих передачах може виправдати перевірку розміру пакета. Повторювані SYN без відповіді або миттєвий reset потребують ширшого пояснення; збій дрібних пакетів не доводить завеликий сегмент даних.
Тримайте в записі окремо робоче пряме з'єднання і збійне з'єднання через проксі. Вони можуть використовувати різні джерела, маршрути й інкапсуляцію, навіть з однієї машини.