Застрявшее соединение TCP в Linux
Проверьте шрифты, и кодировка - указывает Шрифт юникода.
Может быть, проблема с MTU / MSS? Маленькие начальные пакеты проходят, а большие (передача данных) где-то убиваются?
Обходной путь - немного уменьшить MTU (с обеих сторон), с 1500 до 1450, например, или использовать цель Netfilter TCPMSS только для затронутых соединений (или иначе для отдельных соединений).
Но реальное решение состоит в том, чтобы снова заставить определение MTU пути работать. Поэтому проверьте, заблокированы ли пакеты ICMP (требуется фрагментация: тип 3, код 4). Используйте tcpdump -i $ ifname -n icmp , чтобы узнать, прибывают ли такие пакеты.
Сначала я предполагаю, что это проблема масштабирования окна TCP:
https://en.wikipedia.org/wiki/TCP_window_scale_option#Possible_side_effects
Отключите его на обоих концах и посмотрите, проблема уходит. Другой вариант (как предложил Хауке) - это дефрагментация.
Вы можете использовать команду ping для проверки дефрагментации пакетов, простой HOWTO находится здесь:
http://muzso.hu/2009/05/17/how-to-determine-the-proper-mtu- size-with-icmp-pings
Изменить: пропустил слово.
Действительно, происходит дефрагментация. Это то, что IPTABLES делает для проверки пакетов. Она должна собрать их заново, чтобы проверить содержимое.
В моем случае я бы увидел периодические выпадения ping и остановки веб-браузера во время просмотра веб-страниц на системе CentOS 7, или мои PuttY сессии из окон таинственно зависали бы -- навсегда.
Я использовал вариант метода Mick, так любезно предоставленного для определения размера МТЮ. Проблема с этим методом в том, что если вы установили MTU маленький размер, то получите ложное срабатывание при фрагментации. Поэтому установите большой размер (jumbo frame/9000), а затем начните пинг-зонды. После установки MTU на 1472 (я определил правильное значение) проблема с пингом при просмотре прошла. Надеюсь, когда я следующий ssh из окон, это тоже сработает.
.