Я использую ноутбук с Mac OS в типичной (то есть паршивой) беспроводной домашней сети и подключаюсь к работе через VPN. Я подключаюсь по ssh к рабочему столу Linux (Ubuntu), который у меня в офисе на работе. (Когда я говорю «я подключаюсь по ssh», я нажимаю на кнопку, которая сообщает мне, что будет использоваться 'ssh', и открывается окно «Терминал», которое позволяет войти в рабочий стол.)
Часто (до нескольких раз в день), когда я использую 'vim', 'vim' перестает отвечать, и через минуту или две соединение с моим рабочим столом разрывается, и Терминал сообщает мне, что соединение разорвано. У меня часто открыто несколько окон Терминала на моем рабочем столе одновременно, и только окно Терминала, в котором я использую 'vim', разрывается. Другие окна остаются подключенными и пригодными для использования.
Недавно я использовал tcpdump для отслеживания пакетов, идущих туда и обратно, и я зафиксировал трассировку, где мой сеанс vim завис и вышел. За пару минут до отключения пакеты с моего рабочего стола приходили с постоянно уменьшающимися размерами окна, пока мы не достигли нуля, и соединение немного позже прервалось.
Я почти мог понять это, если бы я, скажем, вошел в режим вставки и начал печатать символы, пока рабочий стол завис, и я заполнил окно, печатая, пока мой рабочий стол был испорчен. Начальный размер окна был около 12 500, и каждый набранный мной символ, похоже, генерирует 48-байтовый пакет, так что где-то около 250 символов могут заполнить буфер tcp.
Однако, когда vim зависает, это больше похоже на то, что я делаю page-down (control-f), затем вхожу в режим вставки, затем начинаю вводить несколько символов. Мои команды и символы повторяются, указывая на то, что vim получает и обрабатывает символы.
Я не совсем понимаю, где находится буфер tpc между сокетом и 'vim'. Предположительно драйвер tty на самом деле забирает символы из буфера tcp, возвращает их мне и передает их vim, а вывод vim возвращает мне. Но все эти действия извлекут байты из буфера tcp, а размер окна не станет равным нулю.
Чего я не понимаю в работе программного стека, почему размер моего окна стал равен нулю и как обойти или исправить эту проблему?
Бонусные вопросы:
1) Почему на моем рабочем столе размер окна установлен примерно на 12 500 вместо 64 Кб?
2) При использовании tcpdump на Mac я не получаю вывода, если использую выражения "host hostname", "host ipaddress" или "port 22" (где "hostname" и "ipaddress" заменяются именем или IP-адресом моего рабочего стола). Если я не указываю одно из этих выражений, я получаю много вывода, и вывод явно содержит имя хоста, IP-адрес или порт, которые я указал в командной строке. Есть ли что-то особенное на Mac, из-за чего tcpdump не работает? Есть ли стандартный способ испортить командную строку, и я не понимаю, что я прошу tcpdump сделать?
спасибо, Кс
решение1
Во-первых, размер окна TCP — это не буфер, а порог подтверждения. Узел, получающий трафик, будет отправлять пакет ACK только каждые x пакетов. В надежной сети это число должно быть как можно больше для пропускной способности — компромисс заключается в том, что если часть данных потеряна, все окно должно быть передано повторно... Обычно это заставляет стек TCP постепенно уменьшать размер окна, чтобы избежать необходимости повторно передавать так много данных в случае будущей потери пакета. Есть компонент, связанный с доступной памятью (буферы приема), но в современных системах это в основном не имеет значения.Википедия
Основная причина этой проблемы, скорее всего, заключается в плохом сетевом подключении. VPN часто могут иметь высокую задержку и/или потерю пакетов, как и беспроводные сети. В качестве эксперимента, улучшается/решается ли проблема, если вы подключаетесь через проводную линию вместо беспроводной?