случай медленной передачи файлов данных через Атлантику

[Joseph W. Doherty]

NB: это не актуальная проблема, хотя она действительно существовала. Ее причины и способы устранения могут встречаться и сегодня. Я привожу этот пример для практического обучения посредством обсуждения. Несколько десятилетий назад мне сообщили, что международная компания, в которой я работал, столкнулась с проблемой неожиданно низкой скорости передачи файлов через трансатлантический канал (TCP). Предпосылки этой проблемы были следующими: Компания имела около полудюжины трансатлантических «связей» T1/E1, которые использовались для подключения WAN между Европой и Америкой. Одно из назначений этого соединения — передача базы данных между Германией и восточной частью США. Все было в порядке, пока передача базы данных могла быть завершена за выходные. Однако база данных увеличилась в размере до такой степени, что для ее передачи потребовалось больше, чем выходные. Поэтому компания заменила свои «соединения» T1/E1 на дробные T3/E3. К большому удивлению, при передаче данных по новому «каналу» использовалась лишь часть доступной пропускной способности. Все было хорошо, пока размер базы данных не начал расти, и снова ее передача не могла быть завершена за выходные. Возникают следующие вопросы: 1) почему при передаче данных используется только часть пропускной способности (обычно доступно больше), и 2) что можно сделать, чтобы увеличить скорость передачи. В то время оба хоста имели гигабитные соединения, и явных проблем с качеством сети не было. Кроме того, провайдер WAN также не обнаружил никаких проблем. Итак, учитывая вышесказанное, как вы думаете, в чем заключалась основная проблема? Как бы вы устранили предложенную вами причину?

[thismarkjohnson015]

Это классическая проблема размера окна TCP / задержки (произведение пропускной способности и задержки) — на дальних линиях связи окна TCP по умолчанию были слишком малы, чтобы полностью использовать более высокую пропускную способность. Решением является включение масштабирования окна TCP и настройка размеров буферов (или использование современных стеков TCP / параллельных потоков).

[ColForbin]

Первое, что приходит на ум, — это оконный режим TCP. Однако мне также интересно узнать, какая ОС установлена на двух хостах на каждом конце, поскольку, судя по предыдущему опыту, это может иметь огромное влияние на подобную ситуацию.

[Joseph W. Doherty]

@ColForbin
написал:
Однако мне также интересно узнать, какая ОС установлена на двух хостах на каждом конце, поскольку, судя по предыдущему опыту, это может иметь огромное влияние на подобную ситуацию. Принимающей стороной был Windows Server, возможно, NT на тот момент. Не помню, какую ОС использовал отправитель. @ColForbin
написал:
Первое, что приходит на ум, — это оконный режим TCP. Отлично, продолжайте; можете ли вы более подробно объяснить?

[Joseph W. Doherty]

какая ОС установлена на двух хостах на каждом конце, так как, судя по предыдущему опыту, это может иметь огромное влияние на такой сценарий. Они могут, знаете почему?

[Kasun Bandara]

Подозрительные ограничения QoS. Некоторые компании ограничивали некоторые группы трафика, чтобы предоставить приоритетную пропускную способность для трафика в реальном времени. Иногда конфигурации контролируют трафик для выбранных приложений, даже если канал не перегружен. Кроме того, могут быть активные/резервные каналы, которые не используют все каналы для передачи трафика. Пожалуйста, оцените это и отметьте как решение/ответ, если это решило вашу проблему
. Удачи,
KB.

[Joseph W. Doherty]

@Kasun Bandara
написал:
Подозреваю ограничения QoS. Хорошее предположение, но в данном случае это не имеет значения. (Насколько я помню, QoS вообще не был настроен.) @Kasun Bandara
написал:
Кроме того, могут быть активные/резервные каналы, которые не используют все каналы для передачи трафика. Несколько «связей» T1/E1 действительно работали как Etherchannel, т. е. отдельный поток был ограничен пропускной способностью одной «связи», но после обновления до дробного «T3/E3» не было нескольких «связей», кроме одной «связи» с ее общей пропускной способностью для любого отдельного потока. Проблемный поток действительно увеличил свою скорость передачи на обновленном пути, но при этом большая часть новой (другой доступной) пропускной способности осталась неиспользованной.

[Kasun Bandara]

мм. Если это так, мы можем рассмотреть возможность проведения более серийного уровня tshoot. Надеюсь, в этом документе есть хороший набор инструкций по решению этой проблемы... https://www.cisco.com/c/en/us/support/docs/wan/t1-e1-t3-e3/14149-chapter15.html Пожалуйста, оцените этот документ и отметьте его как решение/ответ, если он помог вам решить проблему
. Удачи!
KB

[Joseph W. Doherty]

мм. Если это так, мы можем рассмотреть возможность проведения более серийного уровня тестирования. Возможно, OP не ясно дал понять, что «... не было явных проблем с качеством сети...» означало, что все «ошибки», указывающие на счетчики интерфейса, были равны нулю. Т. е. результаты устранения неполадок, как описано в вашем источнике, не выявили никаких проблем. (О, поскольку проблема была решена, можно подтвердить, что это не было что-то физическое, но, безусловно, следует учитывать физические проблемы.)

[Kasun Bandara]

Рад это слышать. Не думаю, что у вас есть какие-то данные о пакетах. Если бы они были, мы могли бы увидеть какие-либо повторные передачи, информацию на уровне приложения, такую как окно TCP (упомянутое
@ColForbin
), которая может дать подсказку, связанную с пониманием более высокого уровня. Пожалуйста, оцените это и отметьте как решение/ответ, если это решило вашу проблему
. Удачи,
KB.

[Joseph W. Doherty]

Это классическая проблема размера окна TCP / задержки (произведение пропускной способности и задержки) — на дальних линиях связи стандартные окна TCP были слишком малы, чтобы полностью использовать более высокую пропускную способность. Действительно, в этом и заключалась проблема. TCP получателя был по умолчанию (в то время) либо 12K, либо 8K (прошло столько времени, что я уже не помню, каким именно). Решением является включение масштабирования окна TCP и настройка размеров буфера (или использование современных стеков TCP/параллельных потоков). Я предложил либо использовать утилиту, которая могла бы разделить передачу на несколько потоков TCP, либо увеличить RWIN TCP приемника. Было принято последнее решение. Поскольку глобальное значение по умолчанию должно было быть изменено, я дополнительно предложил использовать настройку «всего» 64K. Это было сделано для того, чтобы избежать потенциальных проблем с (на тот момент) еще не проверенными окнами большого размера. Кроме того, поскольку это было глобальной настройкой, которая затрагивала каждый поток TCP, это несколько минимизировало потенциальную нагрузку на память. Влияние изменения на 64 КБ было заметно сразу, так как скорость передачи данных увеличилась в 5 раз; это все еще не исчерпало всю доступную пропускную способность, но, безусловно, позволило завершить передачу данных за выходные. Никаких отрицательных последствий этого изменения замечено не было. Этот случай, пожалуй, является хорошим примером того, как базовое понимание работы сетевых протоколов может помочь в решении «сетевых проблем», которые на самом деле не являются сетевыми проблемами. Для дополнительного изучения рекомендуется ознакомиться с такими темами, как BDP (произведение пропускной способности и задержки, как упомянул
@thismarkjohnson015
) и LFN (длинная и толстая сеть). Другим возможным решением могло быть использование сжатия или (в настоящее время) ускорителя WAN. Сегодня современные хосты часто имеют гораздо более крупные RWIN по умолчанию, поэтому вероятность столкнуться с такой классической проблемой BDP сегодня гораздо меньше. Спасибо всем участникам дискуссии, особенно учитывая, что эта тема форума, возможно, не так хорошо проработана, как другие темы.