freepascal.ru

TCP Window size - это окно которого именно плана?
Ограничение на размер 1 пакета в сети, или ограничение на размер серии пакетов для 1 подтверждения, или еще что?

TCP это потоковый протокол.
TCP Window - это часть этого потока. Вернее TCP двунаправленный протокол поэтому у него два потока.
TCP Window Size это размер окна для текущего пакета TCP.

Когда идёт трёх этапное рукопожатие. Приемная и передающая сторона сообщают размер своих накопителей(буферов). Сообщают они это в поле TCP.WindowSize.
Если передающая сторона будет передавать больше чем размер накопителя у приемника то накопитель просто не сможет запомнить все данные что-бы отдать их приложению.
Поэтому выбирается общий наименьший размер буфера. Так как протокол двунаправленный то тут два передатчика и два приемника и у каждого свои размеры накопителей.
А далее текущий размер окна может быть ещё снижен.

или ограничение на размер серии пакетов для 1 подтверждения

Такого ограничения на подтверждение нет. Приемная сторона сообщает желаемый порядковый номер(Sequence Number) на который она пошлёт подтверждение.
Передатчик должен всё отослать и жать 2*MSL секунд подтверждения. Если подтверждения не было, то он начинает повторно отправлять данные.

Добавлено спустя 15 минут 18 секунд:
А да забыл. Ограничения на размер подтверждение нет но есть нестрогая рекомендуется выбирать не более размера MTU.
И есть требование, что если размер окна нулевой, то обязательно отправлять подтверждение.

Pavia писал(а):Приемная и передающая сторона сообщают размер своих накопителей(буферов) Сообщают они это в поле TCP.WindowSize.

Размер пакета (size), высчитывается по формуле и зависит от скорости соединения и скорости ответа о получении пакета.

Pavia писал(а):Приемная и передающая сторона сообщают размер своих накопителей(буферов). Сообщают они это в поле TCP.WindowSize.

Буферы чего именно?

Pavia писал(а):Приемная сторона сообщает желаемый порядковый номер(Sequence Number) на который она пошлёт подтверждение.

Выборочное подтверждение? Слабо верится в такое. Это ведь получается не гарантированная доставка, а вероятностная.

Pavia писал(а):Ограничения на размер подтверждение нет но есть нестрогая рекомендуется выбирать не более размера MTU.

MTU - это размер пакета. Как вяжется размер пакета с количеством покетов для подтверждения? Это же теплое и мягкое.

Все просто - это максимальное количество байтов между подтверждениями.

Буферы чего именно?

Буферы данных, потока данных TCP. Я уже написал принимающей и передающей стороны. Размер определяет приложения которое должно обрабатывать данные.
Это буферы сокета. К примеру в компоненте инди:

mirk писал(а):Выборочное подтверждение? Слабо верится в такое. Это ведь получается не гарантированная доставка, а вероятностная.

Нет, не вероятностное. Подтверждение закрывает всю последовательность байт(seqance byts) до предыдущего подтверждённого номера. Если нет подтверждения, то вся последовательность отправляется заново. Было у вас в последовательности 10 TCP пакетов вот все их вы должны повторно отправить. Причём с теми же номерами что и до этого.
Да подтверждение выборочное, но это не баг это фича: большой номер подтверждения(Acknowledgment Number) позволяет принимающей стороне работать в тихом скрытном режиме.
Но с другой стороны из-за скрытности может произойти обрыв связи. Маршрутизатор стоящий по середине может посчитать что маршрут не работающий и перестать пропускать пакеты.

mirk писал(а):MTU - это размер пакета. Как вяжется размер пакета с количеством покетов для подтверждения? Это же теплое и мягкое.

MTU это не размер пакета. Что означает буква M? Во-вторых я уже сказал что это нестрогая рекомендация.

Короче говоря частоту подтверждения надо выбирать из разумных соображений.

serbod писал(а):Все просто - это максимальное количество байтов между подтверждениями.

Смотрю трафик и вижу - в пакетах и стоит TCP Window Size=65536, а подтверждения сыпятся на каждый пакет.
ОС MS Windows 2008 Server.

Pavia писал(а):Это буферы сокета.

TCP Window Size вроде как управляет сетевой драйвер системы, а не приложение.
Боюсь буферы сокета не имеюют отношение к 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 мБайт.

Посмотрите исходники любой качалке как они динамически меняют размер принимаемых данных.

mirk писал(а):TCP Window Size вроде как управляет сетевой драйвер системы, а не приложение.Боюсь буферы сокета не имеюют отношение к TCP Window Size.

Тоже мне Фома-неверующий. Вам надо вы и проверяйте, а я макрософту верю. Читайте про SO_RCVBUF socket option

https://docs.microsoft.com/en-us/windows-hardware/drivers/network/updating-cached-variables
https://msdn.microsoft.com/en-us/library/windows/desktop/cc136103(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/windows/desktop/ms742282(v=vs.85).aspx

Да драйвер динамически меняет WindowsSize но приделы задаёт ваше приложение. Но вообще этот параметр лучше не трогать, а играться с параметром len в recv().
Кстати о птичках: Unix, Linux, embbeddet и прочие. Не все ОС поддерживают опцию SO_RCVBUF, но большинство всё же её поддерживают.

Добавлено спустя 59 минут 17 секунд:

Pavia писал(а):В len вы говорите сколько хотите получить. Это и есть через сколько байт вы отправите ACK. Делите на Windows Size получаете через сколько пакетов.

Насколько помню в виндоусе это не реализовано. Там стратегия простая для всех пакетов отправить ACK и выкинуть его из буфера драйвера.

В линухе этот вопрос очень подробно обсуждается, какие параметры более оптимальны при передаче/приеме..
Особенно действительно к IRQ разных карточек и объемы физических буферов TX/RX, все сводится к базовому значению MTU 1500, хотя оно может варьироватся от 3К~до 16К

Добавлено спустя 9 минут 43 секунды:
Некотрые сетевые карточки вообще не имели аппаратного функционала, эмуляцией занимался драйвер.

Pavia писал(а):В len вы говорите сколько хотите получить. Это и есть через сколько байт вы отправите ACK. Делите на Windows Size получаете через сколько пакетов.

При такой формулировке получается Windows Size равняется размеру пакета. Но это точно не так.
По идее надо Windows Size делить на размер пакета. Но т.к. драйвер управляет Windows Size самостоятельно (выши ссылки это подтвердили, большое спасибо за них), то просто так посчитать не получится. Но по идее не на каждый пакет. Значит поведение 1 ACK на 1 пакет не корректное, буду пробовать искать ошибку в программе.

Pavia писал(а):Насколько помню в виндоусе это не реализовано. Там стратегия простая для всех пакетов отправить ACK и выкинуть его из буфера драйвера.

В их документации написано что реализовано, надо попробовать проверить.