Какие факторы, кроме задержки и пропускной способности, влияют на скорость сети? - PullRequest
4 голосов
/ 09 августа 2010

Я заметил, что просмотр изображений или веб-сайтов, размещенных на серверах США (я в Европе), значительно медленнее.Основной причиной может быть задержка из-за расстояния.

Но если 1 пакету требуется n миллисекунд для приема, разве это не может быть уменьшено путем одновременной отправки большего количества пакетов?

Это действительно так?случается или пакеты отправляются один за другим?И если да, что определяет, сколько пакетов можно отправить одновременно (я думаю, что-то связанное с кабелем)?

Ответы [ 5 ]

3 голосов
/ 09 августа 2010

Но если для получения 1 пакета требуется n миллисекунд, разве это не может быть облегчено путем одновременной отправки большего количества пакетов?

Не безгранично, по стандартам TCP / IP,потому что существуют алгоритмы, которые определяют, сколько может быть в полете и еще не подтверждены, чтобы избежать перегрузки всей сети.

Это действительно происходит или пакеты отправляются один за другим?

TCP может поддерживать и поддерживает до определенного количества пакетов и данных "в полете".

И если да, то, что определяет, сколько пакетов может быть отправлено одновременно (что-то делать с кабелемя думаю)?

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

Вы можете начать изучение TCP, например wikipedia .Ваши конкретные вопросы касаются алгоритмов контроля перегрузки алгоритмов и стандарта, Википедия даст вам указатели на все соответствующие алгоритмы и RFC, но вся картина не принесет вам пользы, если вы попытаетесь начать обучение в этом месте безмного другого понимания TCP (например, его концепции управления потоком).

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

1 голос
/ 09 августа 2010

TCP использует то, что называется скользящим окном. В основном объем буферного пространства, X, получатель должен пересобрать из неупорядоченных пакетов. Отправитель может отправить X байтов после последнего подтвержденного байта, скажем, порядкового номера N. Таким образом, вы можете заполнить канал между отправителем и получателем X неподтвержденными байтами в предположении, что пакеты, скорее всего, попадут туда, а если нет, то получатель сообщит вам, не подтвердив пропущенные пакеты. На каждый ответный пакет получатель отправляет совокупное подтверждение, говоря: «У меня есть все байты до байта X». Это позволяет ему подтверждать несколько пакетов одновременно.

Представьте, что клиент отправляет 3 пакета, X, Y и Z, начиная с порядкового номера N. Из-за маршрутизации сначала прибывает Y, затем Z, а затем X. Y и Z буферизуются в стеке назначения и когда X приходит, получатель получит подтверждение N + (совокупная длина X, Y и Z). Это увеличит начало скользящего окна, позволяя клиенту отправлять дополнительные пакеты.

Это возможно с выборочным подтверждением подтверждения частей скользящего окна и попросить отправителя повторно передать только потерянные части. В классической схеме Y был потерян, отправителю пришлось бы повторно отправить Y и Z. Выборочное подтверждение означает, что отправитель может просто повторно отправить Y. Посмотрите на страницу википедии .

Что касается скорости, одна вещь, которая может замедлить вас, - это DNS. Это добавляет дополнительную информацию в оба конца, если IP не кэшируется, прежде чем вы даже сможете запросить изображение. Если это не обычный сайт, это может быть так.

TCP Иллюстрированный том 1 Ричарда Стивенса огромен, если вы хотите узнать больше. Название звучит забавно, но диаграммы пакетов и аннотированные стрелки от одного хоста к другому действительно облегчают понимание этого материала. Это одна из тех книг, из которых вы можете извлечь уроки, а затем сохранить их в качестве ссылки. Это одна из трех моих книг о сетевых проектах. альтернативный текст http://ecx.images -amazon.com / images / I / 21NraFSkMOL._SL500_AA300_.jpg

1 голос
/ 09 августа 2010

Проблема заключается в параллелизме.

Задержка не влияет напрямую на пропускную способность вашего канала.Например, самосвал по всей стране имеет ужасную задержку, но прекрасную пропускную способность, если заполнить его лентами объемом 2 ТБ.

Проблема в том, что ваш веб-браузер не может начать запрашивать информацию, пока не узнает, чтоспросить.Поэтому, когда вы загружаете веб-страницу с десятью изображениями, вам нужно подождать, пока появятся теги img, прежде чем вы сможете отправить запрос на них.Так что все заметно медленнее, не потому, что ваше соединение насыщено, а потому, что между выполнением одного запроса и следующего есть время простоя.

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

0 голосов
/ 09 августа 2010

Полагаю, параллельная передача пакетов также возможна (да ... может быть ограничение на количество отправляемых пакетов одновременно). U получит больше информации о передаче пакетов из разделов ::> переключение сообщений,коммутация пакетов, коммутация каналов и коммутация виртуальных каналов ...

0 голосов
/ 09 августа 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...