Tcp windows size что это
Re: Пояснение по TCP Window size
TCP это потоковый протокол.
TCP Window — это часть этого потока. Вернее TCP двунаправленный протокол поэтому у него два потока.
TCP Window Size это размер окна для текущего пакета TCP.
Когда идёт трёх этапное рукопожатие. Приемная и передающая сторона сообщают размер своих накопителей(буферов). Сообщают они это в поле TCP.WindowSize.
Если передающая сторона будет передавать больше чем размер накопителя у приемника то накопитель просто не сможет запомнить все данные что-бы отдать их приложению.
Поэтому выбирается общий наименьший размер буфера. Так как протокол двунаправленный то тут два передатчика и два приемника и у каждого свои размеры накопителей.
А далее текущий размер окна может быть ещё снижен.
Такого ограничения на подтверждение нет. Приемная сторона сообщает желаемый порядковый номер(Sequence Number) на который она пошлёт подтверждение.
Передатчик должен всё отослать и жать 2*MSL секунд подтверждения. Если подтверждения не было, то он начинает повторно отправлять данные.
Добавлено спустя 15 минут 18 секунд:
А да забыл. Ограничения на размер подтверждение нет но есть нестрогая рекомендуется выбирать не более размера MTU.
И есть требование, что если размер окна нулевой, то обязательно отправлять подтверждение.
Re: Пояснение по TCP Window size
Re: Пояснение по TCP Window size
Буферы чего именно?
Выборочное подтверждение? Слабо верится в такое. Это ведь получается не гарантированная доставка, а вероятностная.
Re: Пояснение по TCP Window size
Re: Пояснение по TCP Window size
Буферы данных, потока данных TCP. Я уже написал принимающей и передающей стороны. Размер определяет приложения которое должно обрабатывать данные.
Это буферы сокета. К примеру в компоненте инди:
Нет, не вероятностное. Подтверждение закрывает всю последовательность байт(seqance byts) до предыдущего подтверждённого номера. Если нет подтверждения, то вся последовательность отправляется заново. Было у вас в последовательности 10 TCP пакетов вот все их вы должны повторно отправить. Причём с теми же номерами что и до этого.
Да подтверждение выборочное, но это не баг это фича: большой номер подтверждения(Acknowledgment Number) позволяет принимающей стороне работать в тихом скрытном режиме.
Но с другой стороны из-за скрытности может произойти обрыв связи. Маршрутизатор стоящий по середине может посчитать что маршрут не работающий и перестать пропускать пакеты.
MTU это не размер пакета. Что означает буква M? Во-вторых я уже сказал что это нестрогая рекомендация.
Короче говоря частоту подтверждения надо выбирать из разумных соображений.
Re: Пояснение по TCP Window size
Смотрю трафик и вижу — в пакетах и стоит TCP Window Size=65536, а подтверждения сыпятся на каждый пакет.
ОС MS Windows 2008 Server.
Re: Пояснение по TCP Window size
int recv(
_In_ SOCKET s,
_Out_ char *buf,
_In_ int len,
_In_ int flags
);
В len вы говорите сколько хотите получить. Это и есть через сколько байт вы отправите ACK. Делите на Windows Size получаете через сколько пакетов.
Просто никто мегабайты не указывает вот оно и сыпется на каждый пакет. Типично указывают килобайт ну не больше 64 кб.
Если указать мегабайт то есть вероятность нарваться на ошибку передачи. А вероятность ошибки высокая для примера 10 раз в секунду.
У меня интернет 15 мбит/с тобишь 2 мб в секунду. Я гарантированно словлю 5 ошибок на мегабайт. А значит принимающая сторона не пошлёт подтверждение, а отправляющая будет крутиться в бесконечном цикле снова и снова пытаясь отправить данные. Но статистика вещь упрямая.
Вот какой размер передачи следует выбрать? Ясно что лучше в 5 раз меньше и того имеем 204 кб. А если мы сидим на DSL модеме? Помниться у меня тогда 1 ошибка на 32 кбита была.
Там надо ещё меньше указывать. Типичным значением является MTU 1400 байт.
А почему сразу не выбрать маленький размер принимаемых данных? Это скажется на производительности Пока Ie7 тянул со скоростью 7-9 мБайт/с Опера9 тянула 11-12 мБайт.
Посмотрите исходники любой качалке как они динамически меняют размер принимаемых данных.
Тоже мне Фома-неверующий. Вам надо вы и проверяйте, а я макрософту верю. Читайте про SO_RCVBUF socket option
Да драйвер динамически меняет WindowsSize но приделы задаёт ваше приложение. Но вообще этот параметр лучше не трогать, а играться с параметром len в recv().
Кстати о птичках: Unix, Linux, embbeddet и прочие. Не все ОС поддерживают опцию SO_RCVBUF, но большинство всё же её поддерживают.
Добавлено спустя 59 минут 17 секунд:
Как оценить пропускную способность TCP между серверами
Итак, вы только что получили сервер с гарантированным выделенным каналом на 1Гбит/с (или более) и были неприятно удивлены, обнаружив относительно медленный трансфер файлов. Прежде чем писать в техподдержку и искать неполадки в сети, оцените реальную пропускную способность TCP от одного хоста до другого.
Следует выделить два наиболее важных фактора для успешной передачи данных по протоколу TCP:
- размер TCP-окна — количество байт, которое одна из сторон готова принять без подтверждения;
- круговая задержка (латентность) передачи-приема — время, затраченное на отправку пакета и подтверждение его доставки.
Если вы знаете оба этих показателя, то с легкостью рассчитаете максимально возможную пропускную способность между двумя хостами вне зависимости от ширины полосы пропускания.
Формула расчета пропускной способности TCP
Пропускная способность TCP (бит/с) = Размер TCP-окна (бит) / Круговая латентность (с)
Разберем на простом примере. Имеется гигабитный Ethernet-канал между серверами с круговой задержкой 30 мс. Необходимо отправить большой файл с одного сервера на другой сервер по протоколу FTP. На какую реальную пропускную способность можно рассчитывать?
Сначала необходимо перевести размер TCP-окна из байтов в биты. В данном случае будет задействовано стандартное TCP-окно Windows-машины размером 64 КБ = 65 536 Б = 65 536 * 8 = 524 288 бит.
Затем необходимо взять размер TCP-окна в битах и разделить его на круговую латентность канала, выраженную в секундах. Для целей данных расчетов 30 мс превращается в 0.030 с.
Максимальная пропускная способность TCP = 524 288 бит / 0.030 с = 17 476 266 бит/с = 17.4 Мбит/с
Таким образом, несмотря на тот факт, что между двумя серверами имеется гигабитная Ethernet-связь, при передаче файлов нельзя рассчитывать более чем на 17 Мбит/с.
Как можно сделать сеть быстрее? Ответ очевиден: увеличить размер TCP-окна и/или сократить задержку сигнала.
Для того чтобы согласовать больший размер TCP-окна, требуется индивидуальная ручная настройка каждого сервера. Это, в свою очередь, приводит к следующему вопросу: какой размер TCP-окна можно считать оптимальным? Чтобы выяснить это, необходимо провести обратные вычисления, опираясь на ширину полосы пропускания.
Формула для расчета оптимального размера TCP-окна
Размер TCP-окна (байт) = Размер TCP-окна (бит) / 8 = Пропускная способность (бит/с) * Круговая латентность (с) / 8
В вышеобозначенном примере для гигабитного Ethernet-маршрута между серверами с круговой задержкой 30 мс, получается следующее значение:
Иными словами, если сконфигурировать оба сервера на TCP-окно в 3 750 КБ, FTP-соединение полностью заполнит полосу пропускания и достигнет пропускной способности в 1 Гбит/с.
Следует знать, что увеличение размера TCP-окна имеет свои недостатки.
Во-первых, это потребует больше памяти для буферизации серверов, которая необходима для хранения неподтвержденных данных на случай их повторной отправки.
Во-вторых, увеличенный размер TCP-окна может повлечь за собой большее количество потерянных пакетов, которые, в свою очередь, требуют повторной передачи всего окна. Это может негативно сказаться на производительности. Для решения этой проблемы в стеке TCP/IP сервера может быть активирована опция «выборочные подтверждения», которая по умолчанию выключена.
Один из вариантов решения проблемы — размещение WAN-акселераторов — ускорителей глобальной сети на каждом конце линии. Они:
- открывают увеличенное TCP-окно;
- предоставляют возможность тонкой оптимизации протокола TCP (например, выборочные подтверждения только между акселераторами);
- не требуют специальной настройки серверов или дополнительной буферной памяти;
- могут использовать особые функции прикладного уровня модели OSI (Layer 7 — доступ к сетевым службам) для сокращения круговой задержки.
Латентность
Уменьшить задержку сигнала? Возможно ли это в принципе? Мы не в состоянии преодолеть скорость света, а, значит, никак не можем повлиять на время прохождения сигналом заданного расстояния.
Оптимальный способ оптимизации, опять же, заключается в установке WAN-ускорителя на каждом конце линии, который передает полученные TCP-пакеты локальному серверу, тем самым «обманывая» его на предмет реальной скорости трансфера данных. Локальный сервер принимает моментальные подтверждения ускорителя вместо того, чтобы ждать заторможенный отклик удаленного сервера. Это избавляет нас от необходимости корректировки размера TCP-окна на самих серверах.
Пара WAAS-устройств используют увеличенный размер TCP-окна и выборочные подтверждения на всем участке линии между ними.
Кроме того, WAAS эффективно очищают TCP-поток от избыточных резервных данных, обеспечивая чрезвычайно высокий уровень компрессии (сжатия). Каждый акселератор запоминает ранее просмотренные данные. Если дублирующий фрагмент возникает повторно, он удаляется и заменяется крошечной 2-байтовой меткой. Эта миниатюрная метка распознается удаленным ускорителем, который вставляет вместо нее оригинальный фрагмент данных перед отправкой трафика на локальный сервер.
Подтвержденный на практике результат оптимизации — более высокая пропускная способность линии между серверами без какой-либо специальной TCP-настройки локальных серверов.
Формула для расчета максимальной допустимой задержки для заданной пропускной способности
Пример. На участке между двумя удаленными серверами необходимо гарантировать пропускную способность FTP 10 Гбит/с, используя стандартный размер TCP-окна (64 КБ). Какая максимальная задержка сигнала допустима?
Круговая латентность (мс) = Размер TCP-окна (бит) / Требуемая пропускная способность (бит/с)
Что делать?
В принципе, вы можете и не увеличивать TCP-окно и не устанавливать WAN-ускорители. Просто используйте многопоточность и вы сможете использовать канал на 100% его пропускной способности!
Tcp windows size что это
Введение:
Термины:
MTU — Maximum Transmission Unit.
Это максимальный размер пакета данных, который может быть передан за один физический кадр по протоколу TCP/IP. Дело в том, что данные от компьютера к компьютеру в Интернете идут не сплошным потоком, а этими самыми кадрами — пакетами строго определенного размера.
При этом слишком большой пакет в пути, скорее всего, будет фрагментироваться и заполняться «воздухом», «балластом», что негативно скажется на эффективности связи. Так, если ваш провайдер имеет установки MTU=576, а у вас в Windows задано MTU=1500, то каждый ваш пакет будет им разбиваться на три по 576 байт: 576+576+576=1728 — то есть, 228 байт балласта будут добавляться к каждому вашему пакету. Но даже если провайдер тоже имеет MTU=1500, то при связи с удаленным сервером вполне может попасться маршрутизатор с меньшим значением MTU и пакеты опять-таки будут фрагментироваться, замедляя передачу данных.
MSS — Maximum Segment Size — это еще один параметр протокола TCP, определяющий самый большой сегмент данных TCP, которые могут быть переданы за один раз. То есть, MTU = MSS + заголовки TCP/IP. Для заголовка тоже имеется общепринятый размер — это 40 байт (20 байт IP и 20 байт TCP), следовательно, обычно MSS = MTU — 40. Этот параметр не устанавливается, а вычисляется:)
RWIN — Receive Window — окно приема, размер буфера, в котором накапливается содержимое области данных (MSS) нескольких полученных пакетов, прежде чем передается дальше, например, в браузер. При недостаточном размере этого буфера иногда происходит его переполнение, и поступающие пакеты отвергаются и теряются. Размер RWIN обязательно должен быть кратен MSS и обычно для лучшей эффективности модемного соединения рекомендуется его устанавливать равным 4 — 8 MSS. Однако, чрезмерно большой размер буфера также нежелателен, особенно на плохих линиях — при потере всего одного пакета в случае сбоя на линии будет повторно затребован не один потерянный пакет, а все пакеты из этого буфера, что займет некоторое время.
TTL — Time To Live — время жизни — количество хопов, то есть промежуточных серверов, через которые может пройти ваш пакет в поисках своего места назначения. Каждый такой сервер добавляет единицу к специальному счетчику в заголовке вашего пакета, и когда счетчик достигает максимально разрешенного значения, пакет считается заблудившимся и прекращает свое существование. По умолчанию TTL равен 32, что сегодня явно недостаточно для разросшегося Интернета — нередки случаи, когда удаленный сервер находится более чем в 32 переходах, поэтому TTL следует увеличить как минимум до 64.
——————————————————
Таким образом, логично считать, что большие пакеты в итоге все-таки предпочтительнее, и если ваш провайдер настроил свои серверы и маршрутизаторы на большие пакеты, то надо стремиться использовать это на всю катушку.
Итак, надо определить MTU провайдера (оператора). Определяем вручную: Только сначала надо установить MTU равным 1500б. это можно сделать и вручную в реестре, но лучше (чтобы и остальные параметры также править) использовать спец. проги, например
MTUspeed .
После этого мерием MTU прова.
В командной строке:
PING -f -l 1500 ххх.ххх.ххх.ххх, где «ххх.ххх.ххх.ххх» — IP-адрес тестируемого сервера, а «-I» — это буква L, а не единица. -l это размер буфера отправки(1500). -f это флаг запрещающий фрагментацию пакета.
Например, у меня получилось так:
PING -f -l 1472 mail.ru
Обмен пакетами с mail.ru [194.67.57.51] по 1472 байт:
Ответ от 194.67.57.51: число байт=1472 время=3617мс TTL=249
Ответ от 194.67.57.51: число байт=1472 время=3315мс TTL=249
Ответ от 194.67.57.51: число байт=1472 время=3271мс TTL=249
PING -f -l 1473 mail.ru
Обмен пакетами с mail.ru [194.67.57.51] по 1473 байт:
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Но это не значит, что MTU прова 1472б. Ping прибавляет к нашим данным заголовок — IP (20 Байтов) и ICMP (8 Байтов). Итак, MTU прова 1500б .
Несмотря на то, что программ, предназначенных якобы для двукратного улучшения связи одним кликом мыши — пруд пруди. И тут, как вы можете сами понять, совсем не факт, что MTU=576, которое везде рекомендуется западными программистами и экспертами, будет оптимальным и для нас в России. Наши провайдеры сплошь и рядом выбирают для себя MTU=1500, а при «пинговании» удаленных серверов мы обнаруживаем, что пакет такого размера, вопреки всем утверждениям, проходит чаще всего нефрагментированным.
Для остальных параметров не считаю нужным ничего писать:) потому что они не так спорны как MTU.
Читайте также
Подключаем ReadyBoost Один из самых простых и недорогих способов ускорить работу Vista…
используют разное ядро существуют разные драйвера, оптимизированные под каждую систему…
Похоже, что многостраничные инструкции на тему того, как создать загрузочную флешку и…
В этой статье хочу рассказать вам о бесспорно хорошей и необходимой функции Windows –…
работать с AIMP для windows 7 стало намного удобнее и приятнее. Если вы впервые слышите…
Подпишись на нашу группу в контакте и будь в курсе обновлений: