Может ли TCP повторно передавать рукопожатие, когда оно теряется при транспортировке? - PullRequest
0 голосов
/ 17 июня 2011

Я видел большое количество неудачных соединений между двумя хостами в моей интрасети (назовите их клиент и сервер).

Используя netstat на обеих машинах, я вижу соответствующие номера портов, где конец сервера находится в состоянии SYN_RECV, а клиент - в SYN_SENT.

Моя интерпретация заключается в том, что сервер ответил на SYN клиента с помощью SYN, ACK, но этот пакет был потерян. Рукопожатие нарушено, соединение с сокетом находится в неполном состоянии, и я вижу, что время ожидания клиента истекло через 20-45 секунд.

У меня вопрос: предлагает ли TCP способ для сервера повторно передать SYN, ACK через некоторый интервал? Это хорошая или плохая идея?

Дополнительные сведения о системе, если применимо: оба конца RHEL5, ssh успешно выполняется, ping теряет 100%, traceroute успешно выполняется. Клиент построен на OpenOrb (Java), сервер - Mico (C ++).

1 Ответ

2 голосов
/ 22 июня 2011

Флаги SYN и FIN считаются частью пространства последовательности и надежно передаются (поэтому ответ на ваш ближайший вопрос «да, это так, по умолчанию»).

Тем не менее, я думаю, что вы действительно хотите копать немного глубже, потому что:

Если у вас есть большое количество неудачных соединений на хостах в вашей интрасети, это указывает на проблему в сети - обычно у вас должно быть низкое, если таковое имеется, соединение, которое застряло в этих состояниях. Повторная передача будет означать, что ваше соединение будет работать в течение 2,4,8, ... секунд (хотя не обязательно - зависит от стека TCP. Тем не менее, ничего приятного для пользователей).

Я бы посоветовал запустить tcpdump или wireshark на обоих хостах и ​​отследить, где происходит потеря пакетов - и исправить это.

На старом оборудовании частой причиной может быть несоответствие дуплекса на некоторой паре устройств в тракте (неправильно определено или неправильно задано). Некоторыми другими причинами могут быть проблемы с драйвером или плохой кабель (недостаточно плохой, чтобы вызвать полное отключение, но достаточно плохой, чтобы вызвать периодические отключения).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...