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

Я отслеживал трафик в течение некоторого времени, используя Wireshark. Я, наконец, столкнулся с воспроизводимой проблемой, не git pull работать с ssh . Вот как выглядел журнал Wireshark git pull :

проволочный журнал

Повторные передачи TCP всегда начинаются, когда начинается обмен ключами. Либо сервер не получает пакет от моей машины, либо моя машина не получает ответ. У меня есть ощущение, что причина этого также является причиной всех других сетевых проблем локальной сети.

Одна вещь, которую я придумал, - это длина пакета 1514 , с установленным битом «не фрагментировать», всех плохих пакетов, но маршрутизатор ЛВС настроен для MTU 1492 . Я не могу настроить маршрутизатор для MTU больше 1500 . Могут ли пакеты быть слишком большими, чтобы они застряли на маршрутизаторе?

Кроме того, похоже, что это затрагивает в основном защищенные соединения (https, ssh), но для них всегда могут потребоваться пакеты больших размеров.

Видите ли, у меня нет большого опыта работы с сетями, поэтому я надеюсь, что некоторые из вас с большим опытом смогут лучше понять это.

Изменить: Только сейчас, git pull снова работает нормально. Конфигурация MTU не может быть причиной проблем ...

|источник

2 ответа2

1

Я думаю, что дублирование подтверждения происходит только тогда, когда получатель видит пробел в порядковых номерах, что означает, что на пути к нему был отброшен пакет; поэтому проблема начинается в направлении от 192.168.0.8 к удаленному серверу. Тот факт, что, несмотря на несколько повторных передач, нет никаких подтверждений (даже дублированных подтверждений), вероятно, означает, что что-то в этом направлении полностью испорчено. (Это может означать, что удаленная сторона не может отправлять, но это не согласуется ни с дублированием подтверждения ранее, ни с последним подтверждением позже. Это означало бы, что есть 2 проблемы вместо 1.)

Вот несколько идей:

  • если соединение через плохой общедоступный Wi-Fi или 3G, то вы можете получить краткие периоды 100% отбрасывания пакетов. Проверьте одновременно с помощью другой службы и посмотрите, не повлияло ли на нее и отключение.
  • Существуют межсетевые экраны с поддержкой протоколов, которые могут занять некоторое время, чтобы решить, что вы делаете, прежде чем они решат отбросить пакеты по определенному соединению. Ваш друг использует экзотический брандмауэр, который можно отключить? Есть ли у провайдера некоторые правила использования?
  • попробуйте обновить драйверы или загрузиться с live-диска linux и посмотрите, происходит ли то же самое. Попробуйте изменить другие аспекты соединения, используя другие сервисы, чтобы сузить суть ошибки.
|источник
1

Большие пакеты с "не фрагментировать" являются нормальными. Вот как ОС выполняет обнаружение MTU - вместо того, чтобы позволить сети тихо фрагментировать пакеты, она ожидает, что будет возвращена ошибка ICMP "Требуется фрагментация" (которая будет иметь правильный MTU).

Если вы видите, что большие пакеты повторно передаются, это означает, что какой-то маршрутизатор в середине неправильно настроен и либо блокирует пакеты ошибок ICMP, либо не отправляет их при необходимости.

|источник

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