Назад | Перейти на главную страницу

Устранение неполадок высокой скорости повторной передачи TCP

Я пытался устранить проблему с сетью, которая связана с очень высокой скоростью повторных передач TCP. 36 образцов (снятых с помощью Wireshark 1.10.8, работающего на 32-битной Windows 7) на общую сумму чуть более семи часов, в диапазоне от 2 до 53 минут каждая, показывают повторные передачи, занимающие от 43 до 61 процента общей входящей полосы пропускания.

Что меня сбивает с толку, так это то, что, насколько я знаю, существует только две причины такого рода проблем: нестабильная ссылка, которая отбрасывает пакеты, и перегрузка. Я считаю, что это исключил. Позвольте мне описать нашу ситуацию, и я хотел бы услышать от людей более осведомленных, чем я, о других направлениях исследования для решения проблемы.

Рассматриваемая сеть находится на борту корабля в море. Он использует спутниковую связь для связи с Интернетом. К сожалению, затраты на полосу пропускания для этого типа связи огромны, поэтому мы застряли с подключением на 1 Мбит / с / 512 Кбит / с вверх. Будучи спутниковым каналом, он проходит примерно 650 мсек. На данный момент у нас на борту около 300 человек, и все пользуются этой трубкой.

Сеть состоит из двух виртуальных локальных сетей (одна для корабельных компьютеров, а другая для гостей). Обе сети VLAN подключены к SonicWall TZ 215 (под управлением SonicOS Enhanced 5.8.1.2-6o), который управляет каналом в Интернет. Обе сети VLAN имеют проводных и беспроводных клиентов. Проводная сеть обслуживается серией гигабитных коммутаторов Cisco 2900. Беспроводная сеть обеспечивается многочисленными точками доступа Cisco (распространение сигнала на стальном корабле в море ужасно).

Моя первая мысль заключалась в том, что это проблема перегрузки, поэтому я искал различные решения для этого (блокировка сервисов с высокой пропускной способностью, таких как видеочат и потоковая передача, принуждение корпоративного офиса к оплате за больший канал и т. Д.). К сожалению, трубы побольше у нас не было. Остальные вещи немного помогли, но не настолько, чтобы реально изменить ситуацию.

Но в эти выходные я вернулся к исходной точке. Капитан попросил меня отключить гостевой доступ в Интернет во время учений. Я воспользовался этой возможностью, чтобы сделать снимок сети с помощью Wireshark, когда он не было перегружен. К моему удивлению, этот 10-минутный образец показал, что скорость повторной передачи TCP была почти идентична всем другим захватам - 58%. На протяжении этого образца средняя загрузка полосы пропускания составляла 98 кбит / с, так что это определенно было не перегружен.

Это оставляет только потерю пакетов в качестве вероятной причины. Чтобы проверить это, я провел двенадцать часов проверки связи. В конце программа сообщила о потере менее 1% пакетов.

Что оставляет ... что? Я не знаю. Любые дополнительные идеи будут очень признательны.

Один из хороших способов обнаружения потери - использование потока пакетов UDP (для этого существуют различные инструменты, в основном для тестирования QoS). Вы можете варьировать размер, частоту, задержку. Он должен показать вам, есть ли у вас реальные убытки.

Проверяйте все перед своей сетью. Как в: Спутниковая связь ненадежная. На физическом уровне с этой стороны может быть что угодно - плохая калибровка, что угодно.

В соответствии с подходом Шерлока Холмса это единственное, что осталось. Пакеты потеряны, потому что они ПОТЕРЯНЫ.

Раньше я испытывал нечто подобное со звуковой стеной, проверьте, что у вас такой же размер MTU пакетов. CISCO имеет MTU 1500, а sonicwall - 1492, поэтому каждый пакет разбивается на два ... см. https://www.sonicwall.com/support/knowledge-base/set-mtu-in-vpn-environment-in-case-of-throughput-issues/170705131319789/