Устранение неполадок со скоростью сети - старый запрос

Я ищу помощь в том, что я уверен, это старый вопрос. Я оказался в ситуации стремления к более четкому пониманию пропускной способности сети, но я не могу найти информацию, которая заставляет его «щелкать»

У нас есть несколько географически распределенных серверов, работающих под различными версиями Windows. Предполагая, что мы всегда используем один хост (десктоп) в качестве источника, при копировании данных с этого хоста на другие серверы по всей стране мы видим высокую разницу в скорости. В некоторых случаях мы можем копировать данные со скоростью 12 МБ / с, в других - 0,8 МБ / с. Следует отметить, что после тестирования 8 пунктов назначения мы всегда имеем скорость 0,6–0,8 МБ / с или 11–12 МБ / с. В здании, которое нас интересует, у нас есть соединение OC-3 с нашим провайдером.

Я знаю, что в игре много переменных, но я надеялся, что эксперты здесь помогут ответить на несколько основных вопросов, которые помогут укрепить мое понимание.

1.) Для более старых машин, работающих под управлением Windows XP, server 2003 и т. Д. С Ethernet-картой 100 Мбит / с и типичной задержкой 72 мс, приемлемо ли звучание 0,8 МБ / с? Или вы думаете, что достаточно медленно, чтобы указать на проблему?

2.) Классическая «математически самая высокая скорость» «пропускная способность = окно TCP / задержка» в нашем случае рассчитывается до 0,8 МБ / с (64 КБ / 72 мс). Насколько я понимаю, это верхние границы; что вы никогда не ожидаете достичь (из-за накладных расходов), не говоря уже о превышении этой скорости. В некоторых случаях мы видим скорость 12,3 МБ / с. В сети разбросаны ускорители Steelhead. Могут ли они объяснить такую ​​более высокую скорость передачи?

3.) Предполагается, что использование SMB против SMB2 может объяснить разницу в скорости. Действительно, как и ожидалось, захваты пакетов показывают, что оба используются в зависимости от версий ОС в игре, как и следовало ожидать. Я понимаю, что определяет использование SMB2 или нет, но мне любопытно узнать, какого увеличения производительности вы можете ожидать с SMB2.

Похоже, моей проблемой является нехватка опыта и, что более важно, перспективы, с точки зрения того, что является и не является разумной скоростью сети. Может ли кто-нибудь помочь передать контекст / перспективу?

Математическая формула, на которую вы ссылаетесь, на самом деле является способом определения наиболее эффективных настроек размера окна передачи для TCP, а не фактической доступной пропускной способности. TCP использует механизм, называемый скользящими окнами, который позволяет регулировать скорости передачи в зависимости от условий сети. Идея состоит в том, что передатчик TCP будет отправлять все больше и больше данных, не требуя подтверждения от получателя. В случае потери данных объем данных, отправляемых между подтверждениями, уменьшается, что также снижает эффективную полосу пропускания.

Рассматриваемая формула фактически определяет идеальный размер этого окна передачи TCP на основе задержки и двусторонней задержки между данной парой хостов. Идея состоит в том, чтобы размер окна был таким, чтобы объем данных «в полете» соответствовал так называемому продукту с задержкой полосы пропускания. Например, если у вас 50 мегабит в секунду (6,25 мегабайта) и средняя задержка туда и обратно составляет 100 мс, у вас будет 6,25 * 0,1 = 625 килобайт данных. Это будет значение, которое TCP будет согласовывать (если настроено правильно). Поскольку характеристики задержки и пропускной способности ваших ссылок различаются, размер окна также меняется.

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

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

Попробуйте "ping -l 8092" или FTP или HTTP, чтобы проверить, является ли это проблемой SMB.

Прежде всего: какие носители вы используете для подключения компьютеров? Что нам "100mpbs"? Ethernet? Вы не можете использовать его для «географически распределенных» компьютеров, верно?

В случае «vpn через Интернет» маршрутизаторы между вашими компьютерами могут использовать разные ссылки: одна - быстрая, другая - нет. Они могут выбрать ссылку на основе многих параметров.

Пожалуйста, опишите вашу сеть.

Это также может быть проблемой MTU: несколько каналов могут иметь разные MTU.

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

1.) Максимальная пропускная способность одного сеанса TCP с задержкой 72 мс и окном 64 КБ составляет около 0,8 МБ / с, что делает эту скорость приемлемой для однопоточных копий одного сеанса, аналогичных тем, которые мы выполняли с помощью robocopy.

2.) Эта разница в скорости, по-видимому, сводится к эффективности метода передачи. В нашем случае мы использовали Robocopy и Repliweb. Я обнаружил, что robocopy использует один сеанс TCP, тогда как Repliweb может открывать несколько сеансов для отправки данных.

3.) Исследования с веб-сайта Microsoft показывают, что SMB2 имеет значительный прирост производительности по сравнению с SMB1. Там, однако, были проблемы в некоторых случаях в том , как ведет переговоры ОС , какой протокол используется, поэтому следует знать как а.) , Какие случаи SMB2 могут быть использованы, и б.) Или нет SMB2 на самом деле время используется на основе по сети захватывает.

В настоящее время, похоже, Wire-shark может определить использование протокола SMB2.

Надеюсь, это поможет. Опять же, мое понимание здесь довольно элементарно, не стесняйтесь расширяться.