Устранение неполадок с высокой скоростью повторной передачи TCP
Я пытался решить проблему с сетью, которая связана с очень высокой частотой повторных передач TCP. 36 сэмплов (взятых с Wireshark 1.10.8, работающих на 32-битной Windows 7) общей продолжительностью немногим более семи часов, каждая из которых составляет от 2 до 53 минут, показывают ретрансляции, занимающие от 43 до 61 процента всей входной полосы пропускания.
Что меня смущает, так это то, что, насколько я знаю, есть только две причины такого рода проблем: нестабильная связь, отбрасывающая пакеты, и перегрузка. Я считаю, что я исключил это. Позвольте мне изложить нашу ситуацию, и я хотел бы услышать от людей, более знающих, чем я, о других направлениях расследования для решения проблемы.
Рассматриваемая сеть находится на борту корабля в море. Он использует спутниковую связь для связи с Интернетом. К сожалению, затраты на пропускную способность для этого типа связи огромны, поэтому мы застряли на скорости соединения 1 Мбит / с / 512 Кбит / с. Будучи спутниковым каналом, он работает около 650 мс. На данный момент у нас на борту около 300 человек, и все они разделяют эту трубу.
Сеть состоит из двух VLAN (одна для корабельных компьютеров, другая для гостей). Обе VLAN подключены к SonicWall TZ 215 (работает под управлением SonicOS Enhanced 5.8.1.2-6o), который контролирует канал к Интернету. Обе VLAN имеют проводных и беспроводных клиентов. Проводная сеть управляется серией гигабитных коммутаторов Cisco 2900. Беспроводная сеть обеспечивается многочисленными точками доступа Cisco (распространение сигнала на стальном корабле в море ужасно).
Моей первой мыслью было, что это проблема перегрузки, поэтому я занялся различными решениями для этого (блокирование услуг с высокой пропускной способностью, таких как видеочат и потоковая передача, подгонка корпоративного офиса к оплате за большую трубу и т. Д.). К сожалению, мы не получили большую трубу. Остальные вещи помогли немного, но не настолько, чтобы что-то изменить.
Но в эти выходные меня вернули на круги своя. Капитан попросил меня отключить гостевой доступ в интернет во время тренировки. Я воспользовался этой возможностью, чтобы сделать захват сети Wireshark, когда она не была перегружена. К моему удивлению, эта 10-минутная выборка показала, что частота повторной передачи TCP была почти идентична всем остальным захватам - 58%. За время этой выборки средняя полоса пропускания составила 98 кбит / с, поэтому она определенно не была перегружена.
Это оставляет только потерю пакета как вероятную причину. Чтобы проверить это, я пробежал двенадцать часов пингов. В конце программа сообщила о потере пакета менее 1%.
Что оставляет... что? Я не знаю. Любые дополнительные идеи будут наиболее цениться.
2 ответа
Один хороший способ обнаружить потерю - использовать поток пакетов UDP (есть различные инструменты, которые делают это, главным образом для тестирования QoS). Вы можете варьировать размер, частоту, задержку. Он должен показать вам, есть ли у вас реальная потеря.
Проверьте все перед вашей сетью. Как в: Спутниковая связь ненадежна. На физическом уровне этой стороны может быть что угодно - плохая калибровка, что угодно.
Согласно подходу Шерлока Холмса, это единственное, что осталось. Пакеты теряются, потому что они потеряли.
Чтобы проверить это, я провел двенадцать часов проверки связи. В конце программа сообщила о потере менее 1% пакетов.
Ping использует пакеты ICMP - это протокол управляющих сообщений в Интернете. ICMP предназначен для обеспечения потоков трафика (т. Е. Сообщая другим машинам, как маршрутизировать трафик), поэтому устройства ДОЛЖНЫ отдавать приоритет ICMP над другими типами пакетов.
т.е. это худший из возможных способов обнаружения перегрузки.
Раньше я испытывал нечто подобное со звуковой стеной, проверьте, что у вас такой же размер MTU пакетов. У CISCO MTU 1500, а у sonicwall - 1492, поэтому каждый пакет разбивается на два... см.: https://www.sonicwall.com/support/knowledge-base/set-mtu-in-vpn-environment-in-case-of-throughput-issues/170705131319789/
Согласитесь с тестом ping, установите бит DF и посмотрите, где заканчивается ваш MTU. Инкапсулирован ли трафик? Я представляю это через SAT, который еще больше уменьшит это. Я прослезился, когда прочитал количество пользователей для 1 Мбит / с.. насыщение загрузки повлияет на это еще больше. Я знаю, что вы мало что можете сделать, но с тем, как в наши дни оформляются страницы, вы ведете проигрышную битву. Мы пытались ограничить общедоступную беспроводную службу до 256 кбит / с для каждого клиента, и этот опыт оказался бесполезным, я даже не могу представить себе загрузку страницы с помощью модема 56k сегодня, а у вас утверждают, что 15 к 1.