2
  1. У меня TCP-соединение (например, сессия SSH с каким-то компьютером)
  2. Сеть внезапно выходит из строя и отбрасывает все пакеты (отсоединенный кабель, вне диапазона).
  3. TCP отправляет пакеты снова и снова, повторяя попытки с увеличивающимися задержками.
  4. Я вижу проблему и подключаю кабель обратно (или как-то восстанавливаю сеть).
  5. TCP-соединение, наконец, успешно повторно отправляет некоторый пакет и продолжает работу.

Проблема в том, что мне нужно подождать некоторое время ожидания в пункте 5. Я хочу использовать мой открытый сеанс SSH сейчас и не ждать 5-10 секунд, пока он не обнаружит, что соединение снова работает.

Как заставить все TCP-соединения пересылать данные без задержек в GNU/Linux?

|источник

2 ответа2

1

Знаете ли вы, что IP-соединение было установлено во время (4)? С DHCP / WiFi / WPA / ARP / Zeroconf существует повторное согласование канала передачи данных, которое может легко занять 5 секунд между оператором и возможностью передачи даже одного IP-пакета.

Если это так, сеанс SSH, возможно, не является ограничением, и принудительная повторная отправка TCP не поможет вообще.

Обновить:

Не знаю, я не могу воспроизвести это. У меня было открытое соединение SSH между машинами .2 и .3 с .3, печатающим время для вывода в секунду каждую секунду. Две машины работают под управлением Ubuntu Lucid и подключены через скучный WAP/Switch/Router. Машины настроены на DHCP. Я вытащил кабель из машины .3 и ждал научно-точный (смотри на часы) интервал 60 секунд. Вот трассировка пакета:

No.  Time        Source                Destination           Protocol Info
  18 8.479990    192.168.2.3           192.168.2.2           SSH      Encrypted response packet len=48
  19 8.480024    192.168.2.2           192.168.2.3           TCP      56670 > ssh [ACK] Seq=1 Ack=433 Win=1002 Len=0 TSV=2804876 TSER=44100246
  20 87.619215   AsustekC_f1:59:70     Broadcast             ARP      Who has 192.168.2.2?  Tell 192.168.2.3
  21 87.619221   AsustekC_24:9c:85     AsustekC_f1:59:70     ARP      192.168.2.2 is at 00:1a:92:24:9c:85
  22 87.619527   192.168.2.3           192.168.2.2           SSH      Encrypted response packet len=48
  23 87.619545   192.168.2.2           192.168.2.3           TCP      56670 > ssh [ACK] Seq=1 Ack=481 Win=1002 Len=0 TSV=2824661 TSER=44120031

Для возобновления сеанса потребовалось около 200 микросекунд. Я использовал стандартный Wireshark для прослушивания пакетов.

|источник
0

Посмотрите на следующие записи процедур

/ Труды / системы / нетто / ipv4 /

tcp_keepalive

tcp_retries

tcp_keepalive:

Количество секунд, в течение которых соединение должно простаивать, прежде чем TCP начнет отправлять проверки активности. Это можно изменить, выполнив следующую команду

echo 20> /proc /sys /net /ipv4 /tcp_keepalive_time.

Значение по умолчанию составляет 7200 секунд (2 часа).

tcp_retries:

Количество попыток перед закрытием соединения TCP

echo 45> /proc /sys /net /ipv4 /tcp_retries2

Не уверен, действительно ли это поможет, когда дело доходит до соединения SSH, поскольку это может действительно зависеть от скорости соединения и конфигурации тайм-аута SSH.

Ура Крис

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .