В этом материале
Успешный ping и зависающая большая передача совместимы с MTU black hole. Маленькие пакеты проходят, а крупные теряются; отправитель не получает нужный сигнал для корректировки размера. Проверьте PMTUD, ICMP и tunnel overhead, прежде чем менять timeout или GPU.
Успешный ping и зависающая большая передача совместимы с MTU black hole. Маленькие пакеты проходят, а крупные теряются; отправитель не получает нужный сигнал для корректировки размера. Проверьте PMTUD, ICMP и tunnel overhead, прежде чем менять timeout или GPU.
Сначала отделите стадии соединения
Запишите, работает ли DNS, устанавливается ли TCP и где останавливается TLS либо передача данных. Успешный ping проверяет конкретный размер и маршрут, а не произвольный application payload. Сравните один и тот же источник и назначение: запрос с ноутбука может идти иначе, чем трафик Pod через overlay и VPN. Сохраните маршруты, interfaces, семейство IP и фактическую MTU на участках, которыми вы управляете.
Проверьте механизм PMTUD
При Path MTU Discovery крупным пакетам может требоваться соответствующее ICMP уведомление о невозможности передачи. Если такие сообщения теряются или фильтруются, TCP способен повторять данные без прогресса. RFC описывает характерный black-hole сценарий. Это гипотеза сетевого уровня, а не следствие размера файла как такового. Размер TLS records, сегментация и offload делают наблюдение сложнее: не считайте каждый большой пакет в capture доказательством того, что именно такой кадр ушёл в сеть.
Выполните ограниченное сравнение
В учебном опыте один путь содержит туннель, уменьшающий полезную MTU. Короткий запрос проходит, передача синтетического большого ответа зависает. Сравните контролируемые размеры и наблюдаемые retransmissions с ICMP на разрешённых точках. Затем повторите по пути без туннеля на стенде. Такой опыт помогает локализовать границу, но не назначает универсальную MTU для всех облаков и не требует передачи реальных пользовательских данных.
| Артефакт | Диагностическая ценность |
|---|---|
| Source/destination | Определён исследуемый маршрут |
| Interface MTU | Видна локальная конфигурация |
| ICMP observations | Проверен сигнал PMTUD |
| Retransmissions | Подтверждено отсутствие TCP прогресса |
Исправьте подтверждённый участок
Согласуйте MTU overlay/tunnel и разрешённый ICMP для используемого семейства IP. Kernel tcp_mtu_probing имеет документированные режимы и может участвовать в mitigations, но не заменяет понимания сетевого дефекта. Не включайте глобальный режим вслепую на общем узле. Сохраните исходные настройки и протестируйте изменение отдельно. Если передача ограничена congestion или application backpressure, изменение MTU может ничего не дать и отвлечь от другой причины.
Повторите крупную передачу
После изменения проверьте маленькие и большие синтетические данные тем же источником, маршрутом и клиентом. Сохраните длительность, retransmissions и наблюдения PMTUD. Успешный результат должен переживать повторное подключение и не ломать другой нужный маршрут. Итоговый артефакт связывает симптом с конкретным участком сети. Если зависание осталось на стадии сертификата без признаков потери данных, возвращайтесь к TLS диагностике отдельно: один внешний симптом не подтверждает единственную причину во всех случаях.
Сохраняйте направление передачи: асимметричный маршрут способен проявить проблему только при ответе сервера. Успешная загрузка короткого запроса не подтверждает такой же путь и допустимый размер пакета для обратного потока данных.
Связанные разборы: network and uptime; cloud egress model serving.