Пользователь
0,0
рейтинг
15 марта 2011 в 19:20

Как получить и измерить высокоскоростное соединение по TCP

Надежная передача данных в Интернете осуществляется на базе протокола TCP (Transmission Control Protocol), спецификация к которому была опубликована почти 30 лет назад. Алгоритм TCP (RFC793), позволяет подключенному устройству адаптироваться для работы в сети на скоростях в пределах десятков мегабит в секунду и задержки до 100 секунд. С бурным развитием новых технологий передачи данных, уже через 10 лет после внедрения стало ясно что производительность протокола не будет хватать для более широких каналов.

1) Ограничения TCP


Скорость передачи данных зависит от сетевых и системных характеристик.

img1 Процесс передачи данных по сети

a) Буферы
Оригинальная конфигурация TCP ограничивает скорость передачи буфером (опция Window Size — «размер окна») и является полем размером в 2^16 байт (до 64 КБайт). Максимальная пропускная способность в данном случае:

Пример: У вас 100 мегабитное соединение к Интернету и до сервера задержка 100 мс.
Стандартным стеком TCP, максимальная скорость передачи данных не превысит 10 Мбит/сек
( 524288 бит / 0.1 сек = 5.24 Мбит/сек не смотря на то что у вас 100 мегабитный линк).

b) Bandwidth-delay product (BDP)
Производительность TCP в принципе не столько зависит от скорости канала, сколько от так называемом «bandwidth*delay product» или BDP (результат пропускная способность*задержка), который представляет собой число байт необходимых отправителю и получателю для максимального заполнения TCP соединения.
Проблемы производительности возникают в случаях так называемых «длинных и широких труб» (LFN «long fat network»), так как BDP в таком случае превышает размер окна TCP, тем самым ограничивая скорость передачи.

img2 Влияние задержки на максимальную пропускную способность TCP

Примером могут служить мобильный интернет или быстрый оптический линк.
Пример расчетов BDP:
a) широкополосный мобильный интернет: 10 Mb/s, 100 ms RTT
B×D = 10^7 b/s × 10^-1 s = 10^6 b, or 1 Mb / 125 kB
b) высокоскоростная наземной сеть: 1 Gb/s, 10 ms RTT
B×D = 10^9 b/s × 10^-2 s = 10^7 b, or 10 Mb / 1.25 MB

Рассчитать BDP можно тут.
”Размер окна” TCP должен превышать BDP для достижение максимальной нагрузки канала.

c) Protocol Overhead
По некоторым оценкам около 95% компьютеров мира подключены через технологию Ethernet.
Ethernet MTU (полезная нагрузка кадра Ethernet) = макс. 1500 bytes.
Если принять во внимание все заголовки Ethernet, IP, TCP, картина будет выглядеть так:

img3 Передача одного Ethernet кадра

Цифры указывают размер (в байтах) заголовка для определенного протокола.
IFG (Interframe gap) — обязательное межкадровое пространство.
Заголовки: preamble, frame delimiter, Ethernet header/FCS – 26 bytes, IFG – 12 bytes, IP header – 20 bytes, TCP header – 20 bytes.

Если исключить VLAN tagging, TCP timestamp и другие опциональные возможности, максимальная полезная нагрузка (Payload) TCP в сетях Ethernet будет:
Max TCP Payload= (MTU–TCP–IP) / (MTU+Ethernet+IFG) = (1500–40) / (1500+26+12) = 94.9 %

d) Задержка и потеря пакетов
Так как речь идет о надежной передачи информации, потеря пакетов в сети вынуждает TCP передавать повторно сегменты и влияет непосредственно на понижение скорости.
Зависимость скорости TCP в соотношении к потери пакетов, определяется формулой Mathis-а:

где: MSS (Maximum segment size) – максимальный размер сегмента TCP (MSS = MTU – packet headers=1460 bytes),
MTU — максимальный размер передаваемого блока нижнего уровня OSI (Ethernet MTU = 1500 bytes),
RTT — время двусторонней задержки (от одного конца к другому и назад, от англ. Round Trip Time)
Ploss — Loss probability (вероятность потерь).
Можно обратить внимание что формула не действительна с Ploss = 0. Это нормально, так как в реальном мире всегда есть потери пакетов.


img4 Влияние задержки и потеря пакетов на максимальную пропускную способность TCP

Большинство провайдеров не будет гарантировать потери менее 0.01% (1 пакет из 10`000).
Проверить статистику по протоколам можно командой “netstat –s”.

2) Оптимизация TCP


a) усовершенствования протокола
В связи с этим были разработаны расширения протокола, описанные в стандарте TCP Extensions for High Performance (RFC1323), которые призваны решить ограничения.
Среди них:
— TCP Window Scale Option: возможность увеличение Размера Окна до 2^30 (1 ГБайт),
— TCP selective acknowledgment (SACK) options: принимающая сторона указывает какие именно пакеты в потоке подтверждены (положительно или отрицательно) (RFC2018),
TCP timestamps: улучшение замеров RTT (Round Trip Time Measurement — RTTM), предотвращение накладки порядковых чисел ACK (Prevention Against Wrapped Sequence numbers — PAWS),
Path MTU discovery: определение максимального MTU на всем пути,
— Explicit Congestion Notification (ECN): указывает на перегрузку пути без сбрасывание пакетов (RFC3168).

Проверить текущие настройки TCP/IP компьютера можно здесь.

b) aдаптация oперационных систем
Несмотря на то что документ RFC1323 был опубликован в далеком 1992 году, в ОС-ы внедряли изменения не сразу.

OS Windows
Поддержка RFC1323 появилась начиная с Windows 2000 (XP, Server 2003) и для активации опции необходимо покрутить в реестре.
Системы Windows Server 2008, Vista, 7 включают новую реализацию стека протоколов TCP/IP, известную как стек протоколов TCP/IP нового поколения («Next Generation TCP/IP Stack»). Он спроектирован для того, чтобы обеспечивать сетевые технологии Windows на несколько лет вперед. Среди нововведений:
— aвтонастройка окна получения (Receive Window Auto-Tuning),
— compound TCP: решает проблему низкой производительности в сетях с высокой пропускной способностью с помощью нового алгоритма, вместо алгоритмов, использовавшихся на других платформах,
— усовершенствования для сред с высоким уровнем потерь и еще много чего.
Многие опции включены по умолчанию. Конфигурация через командную строку.

С подробными процедурами настройки для различных ОС (Windows XP, FreeBSD, Linux, Solaris, Mac OS X), можно ознакомится на сайте суперкомпьютерного центра Питтсбурга.

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

3) Измерения производительности стека TCP/IP


В сети существуют множество методов измерения скорости подключения к Интернету.
Здесь будет рассмотрен случай с использованием утилиты nuttcp («New TTCP»), так как она имеет несколько приятных преимуществ:
— простой и эффективный метод измерения пропускной способности канала через TCP или UDP,
— кроссплатформенная одно-файловая программа (CLI),
— возможность проверки эффективности локального стека TCP/IP (loopback),
— стабильная работа сервера (корректное завершения TCP сессий), без подвисаний и падений
(как в случае с iperf),
— работа клиента из NAT-а.

Немного истории: В 1980 году, Mike Muuss (автор ping-а) создал ttcp («Test TCP») — один из первых инструментов тестирования пропускной способности TCP. Многие изменения с тех пор были созданы в различных реализациях и с новыми возможностями. Nuttcp является одной из них. Последняя бета — апрель 2010.

Тестирования работает по схеме клиент-сервер.
Измеряется payload — полезная нагрузка (без заголовков).
Подключение по порту 5000. Передача данных — 5001 (и выше если указать многопоточный тест).

Сервер — достаточно указать #nuttcp -S
Клиент — можно указывать множество опций.

Пример:
Сервер FreeBSD, клиент Windows XP SP3, FastEthernet (100Mbps).
server-ip# nuttcp –S

опции клиента:
-w128 — TCP receive window size = 128 KB
-r — receiving (прием, для клиента)
-F — устраняет возможные проблемы с соединением если вы в NAT-е
-i5 — показывать результат каждые 5 секунд
-T15 — длительность тестирования (15 секунд).

TX% и RX% являются загрузкой процессора на передатчике и приемнике.

Проверка производительности железа и стека TCP/IP ОС:
C:\> nuttcp.exe -w1m 127.0.0.1
205.0625 MB / 10.00 sec = 172.0189 Mbps 19 %TX 12 %RX

Примеры результатов:
— Intel Core 2 Duo (2 core) @ 1.6 GHz/ 1 GB RAM / Windows XP = 1300/1400 Mbps
— AMD Athlon X2 Dual-Core 4600 @ 2.4 GHz/ 2 GB RAM / Windows 7 = 2000/2100 Mbps
— Intel XEON X5650 (24 cores) @ 2.67GHz/ 8 GB RAM / FreeBSD = 16600/18000 Mbps

Проверяем Download (от сервера к клиенту):
C:\> nuttcp.exe -w128 -r -F –i5 -T15 server-ip
56.0166 MB / 5.00 sec = 93.9803 Mbps
56.0575 MB / 5.00 sec = 94.0489 Mbps
56.0338 MB / 5.00 sec = 94.0090 Mbps

168.2676 MB / 15.00 sec = 94.1020 Mbps 3 %TX 10 %RX

some-unix-client# nuttcp -r -F -i5 -T15 server-ip
429.0000 MB / 5.02 sec = 717.3541 Mbps
526.0000 MB / 5.00 sec = 882.0518 Mbps

1371.1741 MB / 15.00 sec = 766.6703 Mbps 26 %TX 39 %RX 3153 host-retrans 0.29 msRTT

Проверяем Upload (от клиента к серверу):
C:\> nuttcp.exe -w128 –i5 -T15 server-ip
55.6250 MB / 5.00 sec = 93.3169 Mbps
55.8125 MB / 5.00 sec = 93.6562 Mbps
55.6875 MB / 5.00 sec = 93.4277 Mbps

167.2500 MB / 15.12 sec = 92.7664 Mbps 17 %TX 6 %RX

some-unix-client# nuttcp -i5 -T15 server-ip
422.9375 MB / 5.00 sec = 709.5294 Mbps
420.6875 MB / 5.00 sec = 705.9357 Mbps
456.3750 MB / 5.00 sec = 765.6674 Mbps

1305.3853 MB / 15.06 sec = 727.0077 Mbps 20 %TX 48 %RX 24478 host-retrans 0.29 msRTT

4) Вместо заключения


В процессе тестирования, нужно помнить что максимальная скорость отдельного TCP соединения определяется различными факторами:
— максимальная пропускная способность самого медленного участка пути,
— время между отправкой запроса и получением ответа (RTT),
— большинство задержек на больших расстояниях вызваны скоростью света в волокне (~ 200 км/мс),
— дополнительные задержки могут возникнуть в момент перегрузки сети или устройства (сервер, рутер, пк),
— автоматическое понижение скорости при обнаружении потерь пакетов (стандартный механизм TCP предотвращения перегрузок),
— отсутствие других негативных эффектов (минимальное количество ошибок битов на физическом уровне (Bit Error Rate<10^-8),
— исправность сетевой карты и корректная работа драйвера),
— один физический линк может нести множество одновременных TCP соединений,
— один хост может иметь несколько одновременных соединений, даже с тем же удаленным хостом (быстро проверить можно с TCPView или TCPEye).

Популярные speedtest-ы обычно работают в связке browser, flash + geo-локация до ближайшего доступного сервера, что создает:
— дополнительную нагрузку на локальную машину (ЦП, память) и сеть (заголовки WWW и т.п.),
— выбор сервера может быть не оптимальным,
— возможность ошибочных результатов.

И на последок, хотелось бы отметить часто встречаемые проблемы с низкой производительностью сети:
— узкое окно TCP (Window Size),
— несоответствие Ethernet Duplex,
— плохой сетевой кабель.

Ссылки по теме:
technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
fasterdata.es.net/fasterdata/host-tuning

free hit counters
@prox
карма
48,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (41)

  • 0
    У Вас есть возможность в тех же условиях проверить Compound TCP в Windows? Я когда включил на Windows 7, заметил что веб-страницы стали быстрее загружаться. Но у веб-страниц много маленьких файлов, а не один долго скачивающийся.
  • 0
    На картинке в пункте C payload не может быть равным 1500
    • 0
      это payload Ethernet-а (MTU), то есть число байт переданных высшему уровню (IP), без своих заголовков.
      Max Ethernet MTU = 1500 bytes (есть также расширения Jumbo Frames).

      Сам кадр Ethernet будет = MTU + свой заголовки.
  • 0
    Если в линукс стоит net.ipv4.tcp_moderate_rcvbuf = 1 то можно рассчитывать, что настройки оптимальны?

  • +1
    Спасибо за систематизацию и изложение в одном месте. Наглядность картинок очень радует.

    Оффтопик. И при всем при этом даже последние версии браузеров не умеют ни качать в несколько TCP соединений, ни восстанавливать закачку после обрыва связи :(. Прям когнитивный диссонанс какой-то. В субботу весь день качал XCode4 через последний хром — благодаря количеству желающих связь рвалась каждые 20 минут, и хром честно рапортовал что «Гигабайт из пяти загружен — все готово. Опять скачивать? Ой, а тако файлик уже есть. перезаписывать будем?» O_O.
    • 0
      В Опере есть встроенный клиент torrent, который этих недостатков лишен.

      Но в целом поддерживаю — хотя бы элементарное автоматическое продолжение прерванной закачки необходимо, ибо даже на хороших каналах бывают сбои загрузок.
      • 0
        offtop. У Опера, коль скоро речь идет о Mac OS, проблемы с отображением русских шрифтов в окнах комментариев. Поэтому уж лучше без нее. Я бы раскошелился на Speed Download.
      • +2
        В FF есть DownThemAll — и многопоточность, и докачка.
    • 0
      wget ))

      А вообще докачку должен еще и сервер поддерживать (но вроде сейчас все поддерживают)
      • 0
        wget


        Увы, сейчас модно динамически генерировать ссылку на скачивание, которую фиг из хрома выпилишь «откуда он это качает». А даже если и выпилишь (есть способы), то wget скачивает не файл, а html с кучкой жаваскриптовской авторизации и редиректа :(.

        Предвосхищая следующий вопрос — lynx качать начал, но размер правильно определить не смог O_O.

        А вообще докачку должен еще и сервер поддерживать (но вроде сейчас все поддерживают)


        Редкий апач не подерживает докачку :).
        • 0
          А вот сафари поддерживает докачку. wget'у надо только куки скормить, чтобы скачать.
    • 0
      В опере докачка есть. Но, как уже отписались, докачка должна быть включена и на сервере.
  • –2
    Почему у вас в окончаниях вместо «я» используется «е» и наоборот?
  • +3
    "*опции необходимо покрутить в регистре."

    Сдвиговый регистр 74hc595 одобряет! =)

    А вообще, видимо, имелось введу реестре.
    • 0
      конечно же «Windows Registry»
      поправил
  • +4
    а есть ещё полезная утилитка iperf, которая прекрасно позволяет играть и разером TCP MSS и отключением мягкого старта, да и всякие междумордия красивые для неё есть, если надо
    IPERF
  • 0
    Что-то ваша формула подвирает.

    Смотрите, пинг у нас 100мкс (0.00005с в одну сторону), буфер, допустим, 64к.

    Имеем: 65536/0.00005=1.3Гб/с.

    А я лично видел 8.5-9 гигабит при 100мкс пинге. Все настройки дефолтные, ixgbe собран с ключами, которые не мешают маршрутизации.
    • 0
      Это на дефолтном TCP стеке в один поток? Если на дефолтном, то при чем тут ixgbe (драфвер intel, специыичный для 10 гигабитной сетевой карты)?
    • 0
      Скажите, а пинг вы чем мерили? Обычная утилита ping выводит время с точностью до миллисекунд.
      • +1
        Unix'овая до микросекунд
      • 0
        Обычный пинг выводит в микросекундах.

        ping selectel.ru
        PING selectel.ru (188.93.16.18) 56(84) bytes of data.
        64 bytes from selectel.ru (188.93.16.18): icmp_req=1 ttl=57 time=0.977 ms
        64 bytes from selectel.ru (188.93.16.18): icmp_req=2 ttl=57 time=0.759 ms
        ^C
        — selectel.ru ping statistics — 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
        rtt min/avg/max/mdev = 0.759/0.868/0.977/0.109 ms
  • –1
    ой, пардон, забыл про биты.

    Вопрос, если я сделаю пинг в 1мс, я получу потолок в гигабит? Не верю.
    • 0
      речь, судя по всему, про ограничение сверху.
      • 0
        Да, я про это и говорю. Я не верю, что 1мс пинг даст лимит в чуть больше гигабита.
        • 0
          Вы не верите что лимит будет такой маленький или такой большой? В локальной сети (пинг примерно 0 мс) windows на дефолтном TCP стэке вполне способна утилизировать гигабитную сетевую карту.
          • 0
            Я не знаю, что там может виндоуз, я говорю, что не верю, что пинг в 1мс не даст возможности утилизовать 10G карточку. И разумеется, речь про линукс (при чём тут вообще винды?)
            • +1
              а вы попробуйте и сообщите о результатах
              (убедитесь что окно = 64КB и РТТ >1000 microsec. )

              так же можете проверить скорость, уменьшая окно с RTT ~ 0.0001 sec

    • +1
      В одном TCP соединении, скорее всего, так и получится.
  • 0
    Отличная серьёзная статья, спасибо автору. Однако статистику измерения скорости в конце поста рекомендую сделать табличкой, а то ж нихрена не понятно.
  • 0
    какой минимально возможный пинг у протокола TCP/IP? допустим, расстояние между компьютерами не превышает нескольких метров (до 10м).
    • 0
      ping 127.0.0.1 :)
    • 0
      Пропингуйте 127.0.0.1 :)
    • 0
      зависит от:
      — метода передачи данных (оптика, медь)
      — производительности систем (ЦП, ОС)
      — количество устройств в том же домене коллизий
      и т.д.

      реальные данные:
      1) пинг на себя же (слабая машина)
      Source address is 127.0.0.1; using ICMP echo-request
      Pinging 127.0.0.1 with 32 bytes data (60 bytes IP):
      Reply from 127.0.0.1: seq=0001 time=0.108ms TTL=64 ID=4000
      Reply from 127.0.0.1: seq=0002 time=0.094ms TTL=64 ID=4006
      Reply from 127.0.0.1: seq=0003 time=0.089ms TTL=64 ID=400a
      Reply from 127.0.0.1: seq=0004 time=0.092ms TTL=64 ID=400f

      2) пинг между 2-мя серверами подключенные через Ethernet медь (1 Gbps), ~ 30 метров между ними
      64 bytes from SOMESRVIP: icmp_seq=6 ttl=255 time=0.094 ms
      64 bytes from SOMESRVIP: icmp_seq=7 ttl=255 time=0.086 ms
      64 bytes from SOMESRVIP: icmp_seq=8 ttl=255 time=0.096 ms
      64 bytes from SOMESRVIP: icmp_seq=9 ttl=255 time=0.092 ms

      т.е. по сети получилось быстрее чем локально

      FYI:«This limitation results from the timing of the Ethernet signals on the cable and not necessarily the cable characteristics, and is, therefore, a „hard“ number.»
  • 0
    Спасибо! Будто качественную лекцию выслушил, а не статью прочел, очень интересно.
  • 0
    Очень полезная статья для тех, кто надумает организовать выделенный канал между удалёнными площадками.
  • +5
    Автор плохо разобрался в материале и сеет дезу в массы.

    1) Проблему с максимальным размером окна в 64к решили еще в 92-м году, введя в протокол флаг
    масштабирования окна TCP. Насколько мне известно, Windows штатно поддерживает его начиная с версии 2000.

    2) Проблемы с производительностью TCP в LFN-сетях связаны не с превышением размера окна TCP (см. пункт 1), а с медленным темпом «разгона» древних вариантов алгоритмов управления перегрузками TCP до нужного размера окна и их неадекватной реакцией на потери пакетов.

    3) Производительность TCP по большей части зависит от алгоритма управления перегрузками на стороне, передающей данные. В не-windows мире серверных систем уже давно используются современные варианты TCP, отлично работающие при большом BDP (например, BIC и CUBIC). Насколько мне известно, Windows начиная с 98 застряла на TCP Reno + SACK, но Compound TCP в 2008-Server призван сократить это отставание.

    К слову, для передачи больших объемов данных в сетях с большими задержками используется либо несколько параллельных потоков TCP, либо специальные варианты TCP (HSTCP, HYBLA), либо немножко другие протоколы (см., например, SABUL).

    4) Потери пакетов сильно влияют на производительность не потому, что данные приходится передавать повторно — с введением SACK передаются только потерянные сегменты, а не всё окно передачи начиная с первого неподтвержденного байта. На самом деле проблема в том, что потеря даже одного пакета в большинстве старых реализаций TCP (см. пункт 3) интерпретировалась как перегруженность сети, и протокол резко уменьшал окно передачи. В современных вариантах TCP это во многом вылечено.
    • 0
      Такое впечатление что вы прочли только пункт 1) из статьи.
      O потерях, SACK, Compound TCP в вкратце изложено, для общей картины, в пункте 2)

      и еще, вы сами себе противоречите:
      как же проблему с максимальным размером окна в 64к «решили еще в 92-м году», если «Windows… поддерживает… с версии 2000», а в XP опции по умолчанию отключены?
      • 0
        Собственно, я лишь указал на самые заметные из фактических ошибок, которые создают неправильное представление о современном положении дел с TCP. Если же речь в статье только о проблемах старых версий windows, неплохо бы указать это в заголовке.

        Фраза про 92-й год о протоколе, а не о его реализации в какой-то операционной системе.

        P.S.:
        • PAWS — не «накладка», а переполнение.
        • SACK… «положительно или отрицательно» — SACK в TCP использует только положительные подтверждения.

        Да и зачем в тегах статьи упомянута замечательная утилита iperf, если в примерах вы используете что-то другое.
        • 0
          «Да и зачем в тегах статьи упомянута замечательная утилита iperf, если в примерах вы используете что-то другое.»

          в статье указанно
  • 0
    Блин, а я всегда смеялся, когда связывают пропускную способность и пинг, а взаимосвязь, оказывается, есть. Только пинг->скорость, а не наоборот, если я правильно понял.
    А для UDP тоже существует подобный график?
  • 0
    Отличная статья, спасибо.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.