Comments 41
У Вас есть возможность в тех же условиях проверить Compound TCP в Windows? Я когда включил на Windows 7, заметил что веб-страницы стали быстрее загружаться. Но у веб-страниц много маленьких файлов, а не один долго скачивающийся.
На картинке в пункте C payload не может быть равным 1500
Если в линукс стоит net.ipv4.tcp_moderate_rcvbuf = 1 то можно рассчитывать, что настройки оптимальны?
Спасибо за систематизацию и изложение в одном месте. Наглядность картинок очень радует.
Оффтопик. И при всем при этом даже последние версии браузеров не умеют ни качать в несколько TCP соединений, ни восстанавливать закачку после обрыва связи :(. Прям когнитивный диссонанс какой-то. В субботу весь день качал XCode4 через последний хром — благодаря количеству желающих связь рвалась каждые 20 минут, и хром честно рапортовал что «Гигабайт из пяти загружен — все готово. Опять скачивать? Ой, а тако файлик уже есть. перезаписывать будем?» O_O.
Оффтопик. И при всем при этом даже последние версии браузеров не умеют ни качать в несколько TCP соединений, ни восстанавливать закачку после обрыва связи :(. Прям когнитивный диссонанс какой-то. В субботу весь день качал XCode4 через последний хром — благодаря количеству желающих связь рвалась каждые 20 минут, и хром честно рапортовал что «Гигабайт из пяти загружен — все готово. Опять скачивать? Ой, а тако файлик уже есть. перезаписывать будем?» O_O.
В Опере есть встроенный клиент torrent, который этих недостатков лишен.
Но в целом поддерживаю — хотя бы элементарное автоматическое продолжение прерванной закачки необходимо, ибо даже на хороших каналах бывают сбои загрузок.
Но в целом поддерживаю — хотя бы элементарное автоматическое продолжение прерванной закачки необходимо, ибо даже на хороших каналах бывают сбои загрузок.
wget ))
А вообще докачку должен еще и сервер поддерживать (но вроде сейчас все поддерживают)
А вообще докачку должен еще и сервер поддерживать (но вроде сейчас все поддерживают)
wget
Увы, сейчас модно динамически генерировать ссылку на скачивание, которую фиг из хрома выпилишь «откуда он это качает». А даже если и выпилишь (есть способы), то wget скачивает не файл, а html с кучкой жаваскриптовской авторизации и редиректа :(.
Предвосхищая следующий вопрос — lynx качать начал, но размер правильно определить не смог O_O.
А вообще докачку должен еще и сервер поддерживать (но вроде сейчас все поддерживают)
Редкий апач не подерживает докачку :).
В опере докачка есть. Но, как уже отписались, докачка должна быть включена и на сервере.
Почему у вас в окончаниях вместо «я» используется «е» и наоборот?
"*опции необходимо покрутить в регистре."
Сдвиговый регистр 74hc595 одобряет! =)
А вообще, видимо, имелось введу реестре.
Сдвиговый регистр 74hc595 одобряет! =)
А вообще, видимо, имелось введу реестре.
а есть ещё полезная утилитка iperf, которая прекрасно позволяет играть и разером TCP MSS и отключением мягкого старта, да и всякие междумордия красивые для неё есть, если надо
IPERF
IPERF
Что-то ваша формула подвирает.
Смотрите, пинг у нас 100мкс (0.00005с в одну сторону), буфер, допустим, 64к.
Имеем: 65536/0.00005=1.3Гб/с.
А я лично видел 8.5-9 гигабит при 100мкс пинге. Все настройки дефолтные, ixgbe собран с ключами, которые не мешают маршрутизации.
Смотрите, пинг у нас 100мкс (0.00005с в одну сторону), буфер, допустим, 64к.
Имеем: 65536/0.00005=1.3Гб/с.
А я лично видел 8.5-9 гигабит при 100мкс пинге. Все настройки дефолтные, ixgbe собран с ключами, которые не мешают маршрутизации.
Это на дефолтном TCP стеке в один поток? Если на дефолтном, то при чем тут ixgbe (драфвер intel, специыичный для 10 гигабитной сетевой карты)?
Скажите, а пинг вы чем мерили? Обычная утилита ping выводит время с точностью до миллисекунд.
Unix'овая до микросекунд
Обычный пинг выводит в микросекундах.
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
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мс, я получу потолок в гигабит? Не верю.
речь, судя по всему, про ограничение сверху.
Да, я про это и говорю. Я не верю, что 1мс пинг даст лимит в чуть больше гигабита.
Вы не верите что лимит будет такой маленький или такой большой? В локальной сети (пинг примерно 0 мс) windows на дефолтном TCP стэке вполне способна утилизировать гигабитную сетевую карту.
В одном TCP соединении, скорее всего, так и получится.
Отличная серьёзная статья, спасибо автору. Однако статистику измерения скорости в конце поста рекомендую сделать табличкой, а то ж нихрена не понятно.
какой минимально возможный пинг у протокола TCP/IP? допустим, расстояние между компьютерами не превышает нескольких метров (до 10м).
ping 127.0.0.1 :)
Пропингуйте 127.0.0.1 :)
зависит от:
— метода передачи данных (оптика, медь)
— производительности систем (ЦП, ОС)
— количество устройств в том же домене коллизий
и т.д.
реальные данные:
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.»
— метода передачи данных (оптика, медь)
— производительности систем (ЦП, ОС)
— количество устройств в том же домене коллизий
и т.д.
реальные данные:
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.»
UFO just landed and posted this here
Очень полезная статья для тех, кто надумает организовать выделенный канал между удалёнными площадками.
Автор плохо разобрался в материале и сеет дезу в массы.
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 это во многом вылечено.
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 это во многом вылечено.
Такое впечатление что вы прочли только пункт 1) из статьи.
O потерях, SACK, Compound TCP в вкратце изложено, для общей картины, в пункте 2)
и еще, вы сами себе противоречите:
как же проблему с максимальным размером окна в 64к «решили еще в 92-м году», если «Windows… поддерживает… с версии 2000», а в XP опции по умолчанию отключены?
O потерях, SACK, Compound TCP в вкратце изложено, для общей картины, в пункте 2)
и еще, вы сами себе противоречите:
как же проблему с максимальным размером окна в 64к «решили еще в 92-м году», если «Windows… поддерживает… с версии 2000», а в XP опции по умолчанию отключены?
Собственно, я лишь указал на самые заметные из фактических ошибок, которые создают неправильное представление о современном положении дел с TCP. Если же речь в статье только о проблемах старых версий windows, неплохо бы указать это в заголовке.
Фраза про 92-й год о протоколе, а не о его реализации в какой-то операционной системе.
P.S.:
Да и зачем в тегах статьи упомянута замечательная утилита iperf, если в примерах вы используете что-то другое.
Фраза про 92-й год о протоколе, а не о его реализации в какой-то операционной системе.
P.S.:
- PAWS — не «накладка», а переполнение.
- SACK… «положительно или отрицательно» — SACK в TCP использует только положительные подтверждения.
Да и зачем в тегах статьи упомянута замечательная утилита iperf, если в примерах вы используете что-то другое.
Блин, а я всегда смеялся, когда связывают пропускную способность и пинг, а взаимосвязь, оказывается, есть. Только пинг->скорость, а не наоборот, если я правильно понял.
А для UDP тоже существует подобный график?
А для UDP тоже существует подобный график?
Отличная статья, спасибо.
Sign up to leave a comment.
Как получить и измерить высокоскоростное соединение по TCP