СЕТЬ — различия между версиями
Admin (обсуждение | вклад) |
Admin (обсуждение | вклад) |
||
| (не показаны 13 промежуточных версий 2 участников) | |||
| Строка 5: | Строка 5: | ||
Мы анонсируем наши сети всем провайдерам участвующим в [[OD-EX|OD-EX]] | Мы анонсируем наши сети всем провайдерам участвующим в [[OD-EX|OD-EX]] | ||
| − | == | + | ==Потеря пакетов или latency на промежуточных хостах== |
| − | + | Если почти все хосты по дороге потеряли пакеты. Этому есть простое объяснение, оно заключается в принципе работы трассирующих програм и ротуеров: отсылается ICMP запрос и измеряется время ICMP ответа каждого промежуточного роутера (и количество ICMP запросов которые не вернулись или не успели вернутся в заданное время).Поскольку абсолютное большенство роутеров - разделены на две логические части: | |
| − | + | * 1. Аппаратный пересыльщик пакетов построеный на ASIC (application specific integral circuits eng., интегральные схемы оптимизированные под выполнения специфических операций) выполняющие основное предназначение роутера - передачу пакетов от источника получателю. | |
| − | + | ||
| − | + | ||
| − | + | * 2. Програмный маршрутизатор, отвечающий за динамическую конфигурацию всего устройства (например загрузку маршрутов в аппаратную часть), интерфейс пользователя и другие функции, в том числе - ответы на ICMP запросы к этому устройству. | |
| − | + | То, в зависимости от того чем занята вторая часть маршрутизатора - время возврата ответа от него - может варировать (и даже не укладываться в рамки), но никоим образом '''не отражает работу аппаратной части'''. | |
| − | + | Объективным результатом качества связи может считаться '''ИСКЛЮЧИТЕЛЬНО''' количество потерь и время возврата ответа от хоста - назначения, при условии 0 загрузки на нем. | |
| − | + | Иначе, если представить, что количество потерь ответов от каждого промежуточного роутера влияет на качество связи межу источником и назначением, то количество потерь на хосте-назначении было бы суммой количества всех ранее потеряных пакетов + не полученные ответы от самого хоста - была бы совершенно иная картина в отличии от того, что видите вы. | |
| − | + | ||
| − | + | ||
| − | |||
| − | + | http://www.nessoft.com/kb/24 | |
| − | + | http://en.wikipedia.org/wiki/Packet_loss<br> | |
| − | + | ==Низкая скорость загрузки== | |
| − | + | Вероятно вы проверяли скорость скачивания в 1 поток. (При этом вы могли заметить, что скорость скачивания каждого пользователя не изменялась при подключении дополнительных сессий скачивания). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Здесь играет роль размер пинга и значение параметра TCP Window операционной системы на вашем компьютере.TCP/IP как известно - протокол с коррекцией ошибок.Каждый пакет содержит в себе контрольную сумму (CRC) данных которые он несет.При создании пакета, хост-источник вычисляет CRC.Хост-получатель - принимает пакет, сравнивает полученные данные и CRC - если контрольная сумма не верна (пакет пришел с ошибками) - он перезапрашивает посылку этого пакета, если все верно - он подтверждает получение и запрашивает следующий.Естественно - что в момент отсылки-получения пакеты подтверждения/запроса на ретрансляцию - передача данных не ведется, не ведется она ровно то время которое пакет идет от хоста-назначения к хосту-источнику (а именно время того самого PING'a) - что напрямую влияет на общую скорость потока которую вы получаете. Для ускорения TCP/IP - существует понятие TCP Window - т.е. передается не 1 пакет за раз, а несколько. Количество пакетов которые передаются за раз, определяется размером TCP Window ("окна" TCP). | |
| − | + | Формула для получения оптимального размера окна, для конкретных условий сети следующая: | |
| − | При | + | Размер TCP "окна" (байт) = пропускная способность (бит/c) * задержка (секунд) / 10 |
| − | + | ''скорость 100мбит/c - 125000000'' | |
| − | + | ''100ms пинг - это 0.1 секунды'' | |
| − | + | ''деление на 10 - чтобы получить размер в байтах (допуская небольшую погрешность)'' | |
| + | Итого, '''размер окна для скорости 100 мегабит и пинге 100мс:'''размер окна = 125000000 * 0.1 / 10 = 1250000 байт | ||
| − | + | ''Размер окна по умолчанию в линуксе = 131071 байт'' | |
| − | = | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Как известно, Windows оптмизирован для работы в скоростных сетях с малым размером пинга - LAN сетях.<br>Естественно размер окна согласовывается между обоими сторонами.<br>Значение TCP Window по умолчанию можно изменить в реестре -<br>[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] | |
| − | + | ||
| − | + | ||
| − | + | Для линукса, мы можем рекомендоваться следующие настройки, для пинга 100ms, чтобы скорость в 1 поток могла достигнуть 400 и более мегабит в секунду (в зависимости от стороны получателя) на передачу.<br>В /etc/sysctl.conf добавить:<br>net.core.wmem_max = 6553600<br>net.ipv4.tcp_rmem = 4096 655360 6553600<br>net.core.rmem_max = 6553600<br>net.ipv4.tcp_wmem = 4096 655360 6553600<br>net.ipv4.tcp_window_scaling = 1 | |
| − | + | C точки зрения объективного качества каналов на 2007 год мы рекомендуем ставить:<br>net.core.wmem_max = 1940160<br>net.ipv4.tcp_rmem = 4096 194016 1940160<br>net.core.rmem_max = 1940160<br>net.ipv4.tcp_wmem = 4096 194016 1940160<br>net.ipv4.tcp_window_scaling = 1 <br> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | [[Category: | + | |
| + | [[Category:Выделенные сервера]] | ||
Текущая версия на 19:35, 23 апреля 2013
[править] ODEX
Мы можем гарантировать то, что трафик исходящий из нашего датацентра на одесских провайдеров будет идти напрямую, не через Киев.
Как будет идти трафик от конкретного одесского провайдера к нам - гарантировать мы не можем, т.к. это внутренняя политика каждого провайдера.
Мы анонсируем наши сети всем провайдерам участвующим в OD-EX
[править] Потеря пакетов или latency на промежуточных хостах
Если почти все хосты по дороге потеряли пакеты. Этому есть простое объяснение, оно заключается в принципе работы трассирующих програм и ротуеров: отсылается ICMP запрос и измеряется время ICMP ответа каждого промежуточного роутера (и количество ICMP запросов которые не вернулись или не успели вернутся в заданное время).Поскольку абсолютное большенство роутеров - разделены на две логические части:
- 1. Аппаратный пересыльщик пакетов построеный на ASIC (application specific integral circuits eng., интегральные схемы оптимизированные под выполнения специфических операций) выполняющие основное предназначение роутера - передачу пакетов от источника получателю.
- 2. Програмный маршрутизатор, отвечающий за динамическую конфигурацию всего устройства (например загрузку маршрутов в аппаратную часть), интерфейс пользователя и другие функции, в том числе - ответы на ICMP запросы к этому устройству.
То, в зависимости от того чем занята вторая часть маршрутизатора - время возврата ответа от него - может варировать (и даже не укладываться в рамки), но никоим образом не отражает работу аппаратной части.
Объективным результатом качества связи может считаться ИСКЛЮЧИТЕЛЬНО количество потерь и время возврата ответа от хоста - назначения, при условии 0 загрузки на нем.
Иначе, если представить, что количество потерь ответов от каждого промежуточного роутера влияет на качество связи межу источником и назначением, то количество потерь на хосте-назначении было бы суммой количества всех ранее потеряных пакетов + не полученные ответы от самого хоста - была бы совершенно иная картина в отличии от того, что видите вы.
http://en.wikipedia.org/wiki/Packet_loss
[править] Низкая скорость загрузки
Вероятно вы проверяли скорость скачивания в 1 поток. (При этом вы могли заметить, что скорость скачивания каждого пользователя не изменялась при подключении дополнительных сессий скачивания).
Здесь играет роль размер пинга и значение параметра TCP Window операционной системы на вашем компьютере.TCP/IP как известно - протокол с коррекцией ошибок.Каждый пакет содержит в себе контрольную сумму (CRC) данных которые он несет.При создании пакета, хост-источник вычисляет CRC.Хост-получатель - принимает пакет, сравнивает полученные данные и CRC - если контрольная сумма не верна (пакет пришел с ошибками) - он перезапрашивает посылку этого пакета, если все верно - он подтверждает получение и запрашивает следующий.Естественно - что в момент отсылки-получения пакеты подтверждения/запроса на ретрансляцию - передача данных не ведется, не ведется она ровно то время которое пакет идет от хоста-назначения к хосту-источнику (а именно время того самого PING'a) - что напрямую влияет на общую скорость потока которую вы получаете. Для ускорения TCP/IP - существует понятие TCP Window - т.е. передается не 1 пакет за раз, а несколько. Количество пакетов которые передаются за раз, определяется размером TCP Window ("окна" TCP). Формула для получения оптимального размера окна, для конкретных условий сети следующая:
Размер TCP "окна" (байт) = пропускная способность (бит/c) * задержка (секунд) / 10
скорость 100мбит/c - 125000000
100ms пинг - это 0.1 секунды
деление на 10 - чтобы получить размер в байтах (допуская небольшую погрешность)
Итого, размер окна для скорости 100 мегабит и пинге 100мс:размер окна = 125000000 * 0.1 / 10 = 1250000 байт
Размер окна по умолчанию в линуксе = 131071 байт
Как известно, Windows оптмизирован для работы в скоростных сетях с малым размером пинга - LAN сетях.
Естественно размер окна согласовывается между обоими сторонами.
Значение TCP Window по умолчанию можно изменить в реестре -
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
Для линукса, мы можем рекомендоваться следующие настройки, для пинга 100ms, чтобы скорость в 1 поток могла достигнуть 400 и более мегабит в секунду (в зависимости от стороны получателя) на передачу.
В /etc/sysctl.conf добавить:
net.core.wmem_max = 6553600
net.ipv4.tcp_rmem = 4096 655360 6553600
net.core.rmem_max = 6553600
net.ipv4.tcp_wmem = 4096 655360 6553600
net.ipv4.tcp_window_scaling = 1
C точки зрения объективного качества каналов на 2007 год мы рекомендуем ставить:
net.core.wmem_max = 1940160
net.ipv4.tcp_rmem = 4096 194016 1940160
net.core.rmem_max = 1940160
net.ipv4.tcp_wmem = 4096 194016 1940160
net.ipv4.tcp_window_scaling = 1
