СЕТЬ
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
