В настоящее время я исследую сетевые проблемы в локальной сети друга (снова). Интернет-соединение очень медленное и ненадежное, а иногда службы просто не работают.
Я некоторое время отслеживал трафик с помощью Wireshark. Наконец-то я нашел воспроизводимую проблему, git pullover ssh, которая не работала. Вот как git pullвыглядел журнал Wireshark:
Повторные передачи TCP всегда начинаются, когда инициируется обмен ключами. Либо сервер не получает пакет от моей машины, либо моя машина не получает его ответ. У меня есть ощущение, что причина этого также является причиной всех других сетевых проблем локальной сети.
Одна вещь, которую я придумал, это длина пакета 1514, при установленном бите не фрагментировать, всех плохих пакетов здесь, но маршрутизатор локальной сети настроен на MTU 1492. Я не могу настроить маршрутизатор на MTU больше 1500. Могут ли пакеты быть слишком большими, поэтому они застревают на маршрутизаторе?
Кроме того, похоже, что затронуты в основном защищенные соединения (https, ssh), но для них также могут потребоваться большие размеры пакетов.
Видите ли, у меня нет большого опыта в работе с сетями, поэтому я надеюсь, что некоторые из вас, у кого больше опыта, смогут лучше понять это.
Редактировать: Только что git pullснова работает нормально. Конфигурация MTU не может быть причиной проблем...
решение1
Большие пакеты с "нефрагментированным" являются нормой. Именно так ОС выполняет обнаружение MTU – вместо того, чтобы позволить сети тихо фрагментировать пакеты, она ожидает возврата ошибки ICMP "Требуется фрагментация" (которая будет иметь правильный MTU).
Если вы видите, что большие пакеты передаются повторно, это означает, что какой-то маршрутизатор в середине настроен неправильно и либо блокирует пакеты ошибок ICMP, либо не отправляет их при необходимости.
решение2
Я думаю, что происходит дублирование подтверждения.толькокогда получатель видит пробел в порядковых номерах, это означает, что пакет был потерян на пути к нему; поэтому проблема начинается в направлении от 192.168.0.8 к удаленному серверу. Тот факт, что нет никаких подтверждений (даже дублирующих подтверждений) обратно, несмотря на несколько повторных передач, вероятно, означает, что что-то совсем облажалось в этом направлении. (Это может означать, что удаленная сторона не может отправить, но это не согласуется ни с дублирующим подтверждением ранее, ни с фин-подтверждением позже. Это означало бы, что есть 2 проблемы вместо 1.)
Вот несколько идей:
- Если соединение осуществляется через плохой публичный Wi-Fi или 3G, то вы можете получить короткие периоды 100% потери пакетов. Проверьте, используя другой сервис в то же время, и посмотрите, влияет ли на него отключение.
- Существуют протокол-ориентированные брандмауэры, которым может потребоваться некоторое время, чтобы понять, что вы делаете, прежде чем они решат отбросить пакеты на определенном соединении. У вашего друга установлен экзотический брандмауэр, который можно отключить? Есть ли у провайдера какие-то правила использования?
- попробуйте обновить драйверы или загрузиться с linux live CD и посмотреть, произойдет ли то же самое. Попробуйте изменить другие аспекты соединения, используя другие службы, чтобы сузить круг проблем.