TCP Client Server

Review

Free Download

Simple network utility that provides a TCP connection between at least two machines in order to exchange message in order to test applications, network services or firewalls

Testing network programs or services requires, among other things, a utility such as Nsasoft’s TCP Client Server. It can also be used for checking how firewalls and intrusion detection systems work.

Straightforward installation

Installing the product is an easy task that does not require any effort at all; all you have to do is follow the instructions on the screen and the processes completes in a jiffy.

The application window is simple and does not beat around the bush, with all the options available in plain sight.

Easy to work with

Working with the program is so easy that any sort of documentation would be superfluous. Most part of the application is occupied by the dialogs for sending and receiving data but there are also options for settings the current machine into server or client mode in order to exchange the messages.

When in server mode there isn’t any tinkering to be done but if set in client mode the you have to provide the address of the server to connect to.

The interaction between the two systems is logged in the lower screen and includes status of the connection and the time it was established as well as the messages exchanged between the two machines.

Additional options include cutting off the connection from both sides as well as putting the server into listening state in order to detect the addresses that want to establish a connection.

Conclusion

TCP Client Server is simple and efficient. It does not integrate more than it is absolutely necessary to set up a TCP connection between two or multiple machines and trading messages.

Свой асинхронный tcp-сервер за 15 минут с подробным разбором

Ранее я представил пару небольших постов о потенциальной роли Spring Boot 2 в реактивном программировании. После этого я получил ряд вопросов о том, как работают асинхронные операции в программировании в целом. Сегодня я хочу разобрать, что такое Non-blocking I/O и как применить это знание для создания небольшого tcp–сервера на python, который сможет обрабатывать множество открытых и тяжелых (долгих) соединений в один поток. Знание python не требуется: все будет предельно просто со множеством комментариев. Приглашаю всех желающих!

Мне, как и многим другим разработчикам, очень нравятся эксперименты, поэтому вся последующая статья будет состоять как раз из серии экспериментов и выводов, которые они несут. Предполагается, что вы недостаточно хорошо знакомы с тематикой, и будете охотно экспериментировать со мной. Исходники примеров можно найти на github.

Начнем с написания очень простого tcp–сервера. Задача сервера будет заключаться в получении и печати данных из сокета и возвращения строки Hello from server!. Примерно так это выглядит:

Здесь все довольно просто. Если вы не знакомы с понятием сокета, то вот очень простая и практическая статья. Мы создаем сокет, ловим входящие соединения и обрабатываем их согласно заданной логике. Здесь стоит обратить внимание на сообщения. При создании нового соединения с клиентом мы пишем об этом в консоль.

Хочу сразу заметить, что не стоит серьезно вникать в листинги программ до полного прочтения статьи. Совершенно нормально, если что-то будет не совсем понятно в самом начале. Просто продолжайте чтение.

Нет особого смысла в сервере без клиента. Поэтому на следующем этапе необходимо написать небольшой клиент для использования сервера:

Важной особенностью здесь является тот факт, что мы в начале устанавливаем максимально возможное количество соединений, а только потом используем их для передачи/хранения данных.

Давайте запустим сервер. Первое, что мы видим:

Это означает, что мы успешно запустили наш сервер и он готов принимать входящие запросы. Запустим клиент и сразу увидим в консоли сервера (у вас порты могут быть другими):

Что и следовало ожидать. В бесконечном цикле мы получаем новое соединение и сразу же обрабатываем данные из него. В чем тут проблема? Ранее мы использовали опцию server_socket.listen(10) для настройки сервера. Она означает максимальный размер очереди из еще не принятых подключений. Но в этом нет совершенно никакого смысла, ведь мы принимаем по одному соединению. Что предпринять в такой ситуации? На самом деле, существует несколько выходов.

1. Распараллелить с помощью потоков/процессов (для этого можно, например, использовать fork или пул). Подробнее здесь.
2. Обрабатывать запросы не по мере их подключения к серверу, а по мере наполнения этих соединений нужным количеством данных. Проще говоря, мы можем открыть сразу максимальное количество ресурсов и читать из них столько, сколько сможем (сколько необходимо на это процессорного времени в идеальном случае).

Вторая идея кажется заманчивой. Всего один поток и обработка множества соединений. Давайте посмотрим, как это будет выглядеть. Не стоит пугаться обилия кода. Если что-то сразу не понятно, то это вполне нормально. Можно попробовать запустить у себя и подебажить:

Как можно понять по выводу, мы принимаем новые коннекты и данные почти параллельно. Более того, мы не ждем данных от нового подключения. Вместо этого мы устанавливаем новое.

Как это работает?

Дело в том, что все наши операции с ресурсами (а обращение к сокету относится к этой категории) происходят через системные вызовы операционной системы. Если говорить коротко, то системные вызовы представляют собой обращение к API операционной системы.

Рассмотрим, что происходит в первом случае и во втором.

Синхронный вызов

Давайте разберем рисунок:

Первая стрелка показывает, что наше приложение обращается к операционной системе для получения данных из ресурса. Далее наша программа блокируется до появления нужного события. Минус очевиден: если у нас один поток, то другие пользователи должны ждать обработку текущего.

Асинхронный вызов

Теперь посмотрим на рисунок, который иллюстрирует асинхронный вызов:

Первая стрелка, как и в первом случае, делает запрос к ОС (операционной системе) на получение данных из ресурсов. Но посмотрите, что происходит далее. Мы не ждем данных из ресурса и продолжаем работу. Что же делать нам? Мы отдали распоряжение ОС и не ждем результат сразу. Простейшим ответом будет самостоятельно опрашивать нашу систему на наличие данных. Таким образом, мы сможем утилизировать ресурсы и не блокировать наш поток.

Но самом деле такая система не является практичной. Такое состояние, в котором мы постоянно смотрим на данные и ждем какого-то события, называется активным ожиданием. Минус очевиден: мы впустую тратим процессорное время в случае, когда информация не обновилась. Более правильным решением было бы оставить блокировку, но сделать ее «умной». Наш поток не просто ждет какого-то определенного события. Вместо этого он ожидает любое изменение данных в нашей программе. Именно так и работает функция select в нашем асинхронном сервере:

Теперь можно вернуться к реализации нашего асинхронного сервера и взглянуть на него с новым знанием. Первое, что бросается в глаза, – метод работы. Если в первом случае наша программа выполнялась “сверху вниз”, то во втором случае мы оперируем событиями. Такой подход в разработке ПО называется событийно-ориентированным (event-driven development).

Сразу стоит отметить, что такой подход не является серебряной пулей. У него имеется масса недостатков. Во-первых, такой код сложнее поддерживать и менять. Во-вторых, у нас есть и всегда будут блокирующие вызовы, которые все портят. Например, в программе выше мы воспользовались функцией print. Дело в том, что такая функция тоже обращается к ОС, следовательно, наш поток выполнения блокируется и другие источники данных терпеливо ждут.

Заключение

Выбор подхода напрямую зависит от решаемой нами задачи. Позвольте задаче самой выбрать наиболее продуктивный подход. Например, популярный Javaвеб -сервер Tomcat использует потоки. Не менее популярный сервер Nginx использует асинхронный подход. Создатели популярного веб-сервера gunicorn на python пошли по пути prefork.

Спасибо, что прочитали статью до конца! В следующий раз (уже скоро) я расскажу о прочих возможных неблокирующих ситуациях в жизни наших программ. Буду рад вас видеть и в следующих постах.

Кроссплатформенный многопоточный TCP/IP сервер на C++

Как-то раз встала задача по написанию простого и быстрого многопоточного TCP/IP сервера на C++ и при этом, чтобы работал на платформах Windows и Linux без требования как-либо изменять код за пределами класса самого сервера. Ранее, на чистом C++ без библиотек вроде Qt, Tcp-сервер не писал, и предвещал себе долгое время мучений с платформо-зависимостью. Но как оказалось всё гораздо проще чем казалось на первый взгляд, ведь в основном интерфейсы сокетов обоих систем похожи как две капли воды и различаются лишь в мелких деталях.

Итак класс сервера и клиента выглядит следующим образом:

TcpServer.h

Как можно заметить различия минимальны помимо разных подключаемых заголовочных файлов различаются разве что тип сокета — SOCKET для Windows и (как бы странно это не выглядело) int для Linux. Разница здесь лишь в том что Linux использует стандартный int для хранения данных сокета, в то время как в Windows задекларирован собственный тип который относительно архитектуры принимает разный размер и значность целочисленного типа, что можно увидеть в оригинальных заголовочных файлах:

Так же в Windows части TcpServer-хедера присутствует структура для обозначения используемой версии WinSocket — WSAData w_data; (см. WSAData)

Перейдём к реализации сервера:

TcpServer.cpp

Реализация для Linux и Windows практически идентична за исключением некотрых мест, обусловленных разве что различными структурами хранящим адреса( struct sockaddr_in/SOCKADDR_IN, struct sockaddr/SOCKADDR ) и сокеты( int/SOCKET ), а так же наличием у Windows объекта версии WinSocket( WSAData ).

Описание функций Windows TCP

В этой статье описываются функции TCP в Windows.

Оригинальная версия продукта: Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ: 224829

Аннотация

В этой статье описываются следующие функции TCP в Windows:

• Размер окна TCP
• Параметры TCP теперь поддерживаются
• Масштабирование Windows — RFC 1323
• Timestamp — RFC 1323
• Защита от завернутой последовательности номеров (PAWS)
• Селективные подтверждения (SACKS) — RFC 2018
• Поведение ретрансмиссии TCP и быстрая перетрансмиссия

Функции TCP можно изменить, изменив записи в реестре.

В следующих разделах, методах или задачах содержатся действия, которые содержат информацию о том, как изменить реестр. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
322756 Создание резервной копии и восстановление реестра Windows

Размер окна TCP

Размер окна получения TCP — это объем получаемой информации (в bytes), который можно буферить во время подключения. Отправитель может отправлять только такой объем данных, прежде чем ждать подтверждения и обновления окна от принимающего хоста. Стек Windows TCP/IP предназначен для самонастройки в большинстве сред и использует более крупные размеры окон по умолчанию, чем предыдущие версии.

Вместо использования жестко закодируемого по умолчанию размера окна TCP настраивается даже на приращения максимального размера сегмента (MSS). MsS обсуждается во время установки подключения. Настройка окна получения даже с увеличением msS увеличивает процент полноразмысных сегментов TCP, используемых при массовой передаче данных.

Размер окна получения определяется следующим образом:

1. Первый запрос на подключение, отправленный удаленному хосту, рекламирует размер окна получения 16K (16 384 bytes).
2. Когда подключение установлено, размер окна получения округление до даже приращения MSS.
3. Размер окна регулируется в четыре раза больше, чем msS, до максимального размера 64 K, если не используется параметр масштабирования окна (RFC 1323).

См. раздел «Масштабирование Windows».

Для подключений Ethernet размер окна обычно устанавливается до 17 520 bytes (16K округляется до двенадцати сегментов 1460-byte). Размер окна может уменьшаться при подключении к компьютеру, поддерживаюшем расширенные параметры головы TCP, например селективные подтверждения (SACKS) и Timestamps. Эти два параметра увеличивают размер заготавлика TCP более чем до 20 bytes, что приводит к меньшему объему данных.

В предыдущих версиях Windows NT размер окна для подключения Ethernet был 8760 bytes, или шесть сегментов 1460-byte.

Чтобы установить размер окна получения к определенному значению, добавьте значение TcpWindowSize в подкойте реестра, определенное вашей версии Windows. Для этого выполните указанные ниже действия.

Выберите > запуск, Regedit введите, а затем выберите ОК.

Расширение подкоя реестра, определенного для вашей версии Windows:

Для Windows 2000 развяжите следующую подкою: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

В Windows Server 2003 развяжите следующую подкою: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

В меню Редактирование указать значение New, а затем выберите значение DWORD.

Введите TcpWindowSize поле «Новое значение» и нажмите кнопку Ввод

Выберите Изменение в меню Изменить.

Введите нужный размер окна в поле данных Value.

Допустимый диапазон для размера окна — 0-0x3FFFC000 hexadecimal.

Это значение по умолчанию не присутствует. При добавлении значения TcpWindowSize оно переопределяет алгоритм размера окна по умолчанию, рассмотренный выше.

TcpWindowSize также можно добавить в ключ Параметры, чтобы глобально установить размер окна для всех интерфейсов.

Параметры TCP теперь поддерживаются

Ранее параметры TCP использовались в основном для ведения переговоров о максимальных размерах сегмента. В Windows параметры TCP используются для масштабирования окон, штампа времени и выборочного ACK.

Существует два типа параметров TCP:

1. Один параметр TCP octet, который используется для указать определенный вид параметра.
2. Параметр TCP с несколькими октетами, состоящий из вида параметра, длины параметра и ряда октетов параметра.

В следующем списке показаны вид, длина, имя и описание каждого варианта TCP.

Вид: 0
Длина: 1
Вариант: Конец списка опций
Описание. Используется при заполнении последнего параметра TCP.

Вид: 1
Длина: 1
Параметр: Без операции
Описание. Используется при необходимости заполнения, и в одном пакете следуют дополнительные параметры TCP.

Вид: 2
Длина: 4
Параметр: Максимальный размер сегмента
Описание. Указывает максимальный размер сегмента TCP, который можно отправить по сети.

Вид: 3
Длина: 3
Параметр: Параметр масштабирования окна
Описание. Определяет фактор масштабирования, который будет использоваться при использовании размеров окна больше 64k.

Вид: 8
Длина: 10
Параметр: Параметр «Печать времени»
Описание. Используется для вычисления времени круговой поездки (RTT) передаваемых пакетов.

Вид: 4
Длина: 2
Вариант: разрешенО TCP SACK
Описание. Информирует других хостов о том, что разрешены выборочные Acks.

Вид: 5
Длина: изменяется
Вариант: параметр TCP SACK
Описание. Используется хостами для определения того, были ли получены неупорядоченные пакеты.

Масштабирование Windows

Для более эффективного использования сетей с высокой пропускной способностью можно использовать больший размер окна TCP. Поле размеров окна TCP управляет потоком данных и ограничено 2-ми bytes или размером окна 65 535 bytes.

Так как поле размеров не может быть расширено, используется фактор масштабирования. Шкала окна TCP — это параметр, используемый для увеличения максимального размера окна с 65 535 бет до 1 гигабайта.

Параметр масштабирования окна используется только при трехшаговом рукопожатии TCP. Значение масштабирования окна представляет количество битов для переноса влево 16-битного поля размера окна. Значение масштабирования окна можно установить с 0 (без переноса) до 14.

Чтобы вычислить истинный размер окна, умножьте размер окна на 2^S, где S — это значение масштабирования.

Если размер окна 65 535 bytes с коэффициентом масштабирования окна 3.
True window size = 65535*2^3

Истинный размер окна = 524280

Следующий след сетевого монитора показывает, как используется параметр масштабирования окна:

Размер окна, используемый в фактическом трехшаговом рукопожатии, не является масштабным размером окна в разделе 2.2 RFC 1323:

«Поле Окно в syn (например, сегмент [SYN] или [SYN,ACK]) никогда не масштабируется».

Это означает, что первый пакет данных, отправленный после трехнаправного рукопожатия, является фактическим размером окна. Если есть фактор масштабирования, всегда используется начальный размер окна в 65 535 bytes. Затем размер окна умножается на коэффициент масштабирования, идентифицированный в трехшаговом рукопожатии. В таблице ниже представлены границы коэффициента масштабирования для различных размеров окна.

Фактор масштабирования	Масштабное значение	Начальное окно	Масштабировать окно
0	1	65535 или менее	65535 или менее
1	2	65535	131,070
2	4	65535	262,140
3	8	65535	524,280
4	16	65535	1,048,560
5	32	65535	2,097,120
6	64	65535	4,194,240
7	128	65535	8,388,480
8	256	65535	16,776,960
9	512	65535	33,553,920
10	1024	65535	67,107,840
11	2048	65535	134,215,680
12	4096	65535	268,431,360
13	8192	65535	536,862,720
14	16384	65535	1,073,725,440

Если размер окна в реестре вошел как 2690000000 (269M) в десятичной, то коэффициент масштабирования при трехстолевом рукопожатии составляет 13. Коэффициент масштабирования 12 позволяет только размер окна до 268 431 360 bytes (268M).

Начальный размер окна в этом примере будет вычисляться следующим образом:
65 535 bytes с коэффициентом масштабирования окна 13.
True window size = 65535*2^13
True window size = 536,862,720

Когда значение для размера окна добавляется в реестр и его размер превышает значение по умолчанию, Windows пытается использовать значение масштабирования, которое вмещает новый размер окна.

Значение Tcp1323Opts в следующем ключе реестра можно добавить для управления масштабированием окон и временем:

На панели инструментов выберите Запуск запуска и введите для > Regedit запуска редактора реестра.

В редакторе реестра выберите Изменить, указать на Новое, а затем выбрать значение DWORD.

В поле «Новое значение» введите кнопку ВВОД, а затем в Tcp1323Opts меню Изменить выберите Изменение.

Допустимый диапазон: 0, 1, 2 или 3, где:
0 (отключить параметры RFC 1323)
1 (только включена шкала окна)
2 (только включено время)
3 (включено оба варианта)

Эта запись реестра управляет 1323 разами RFC и параметрами масштабирования окон. Время и масштабирование окна включены по умолчанию, но ими можно управлять с помощью битов флага. Bit 0 управляет масштабированием окон. Bit 1 управляет временем.

Timestamps

Ранее в Стеке TCP/IP использовался один пример на окно данных, отправленных для вычисления времени в пути (RTT). При отправлении пакета был задат timer (retransmit timer) до тех пор, пока не будет получено подтверждение. Например, если размер окна в сети Ethernet составляет 64 240 bytes (44 полных сегмента), для пересчета времени в обратном пути использовался только один из 44 пакетов. С максимальным размером окна 65 535 bytes, этого коэффициента выборки было достаточно. С помощью масштабирования окна и максимального размера окна в 1 гигабайт этот показатель выборки RTT является недостаточным.

Теперь параметр TCP Timestamp можно использовать в сегментах (данные и ACK), которые считаются подходящими для стека, для операций, таких как:

С помощью этих данных RTT можно точно рассчитать с помощью больших размеров окна. RTT используется для вычисления интервалов ретрансмиссии. Для оптимальной пропускной способности необходимы точные перерывы в RTT и ретрансмиссии.

Когда в сеансе TCP используется штамп времени TCP, отправитель сеанса отправляет параметр в своем первом пакете трехсторонней рукопожатия TCP (пакет SYN). Затем любая сторона может использовать параметр TCP во время сеанса.

TCP Timestamps Option (TSopt):

Вид = 8	Длина = 10	TS Value (Tsval)	TS Echo Reply (Tsecr)
1 байт	1 байт	4 байта	4 байта

Поле параметра timestamp можно просмотреть в следе сетевого монитора, расширив поле параметров TCP, как показано ниже:

Защита от завернутой последовательности номеров (PAWS)

Поле номеров последовательности TCP ограничено 32 битами, что ограничивает количество доступных номеров последовательности. С высокой пропускной способностью сетей и большой передачи данных, можно обернуть номера последовательности, прежде чем пакет проходит по сети. Если отправлять данные по одной сети Giga-byte в секунду (Gbps), номера последовательности могут обертывание всего за 34 секунды. Если пакет задерживается, потенциально может существовать другой пакет с одинаковым номером последовательности. Чтобы избежать путаницы с дублирующими номерами последовательности, timestamp TCP используется в качестве расширения к номеру последовательности. Пакеты имеют текущие и прогрессивные отметки времени. Старый пакет имеет более старый штамп времени и удаляется.

Селективные подтверждения (SACKs)

Windows вводит поддержку функции производительности, известной как Селективное подтверждение или SACK. SACK особенно важен для подключений с большими размерами окна TCP. Перед SACK приемник мог подтвердить только последний номер последовательности полученного потока данных или «левый край» окна получения. С включенной поддержкой SACK приемник продолжает использовать номер ACK для подтверждения левого края окна получения, но он также может признавать другие блоки полученных данных по отдельности. SACK использует параметры загона TCP, как показано ниже.

SACK использует два типа TCP Options.

Параметр TCP Sack-Permitted используется только в пакете SYN (во время создания подключения TCP), чтобы указать, что он может делать выборочный ACK.

Второй параметр TCP — TCP Sack Option — содержит подтверждение для одного или нескольких блоков данных. Блоки данных идентифицированы с помощью номера последовательности в начале и в конце этого блока данных. Он также известен как левый и правый край блока данных.

Kind 4 — это параметр TCP Sack-Permitted. Вид 5 — это параметр TCP Sack. Длина — это длина в bytes этого параметра TCP.

Tcp SACK разрешено:

Вид = 4	Длина = 2
1 байт	1 байт

Параметр Tcp SACK:

Вид = 5	Длина = переменная
1 байт	Левый край первого блока до правого края первого блока . Левый край блока Nth к правому краю блока Nth

С включенной поддержкой SACK (по умолчанию) пакет или серия пакетов могут быть отброшены. Приемник сообщает отправителю, какие данные получены и где могут быть «дыры» в данных. Затем отправитель может выборочно перенаправить недостающие данные без повторной передачи уже успешно полученных блоков данных. SACK контролируется параметром реестра SackOpts.

Значение SackOpts в следующем ключе реестра можно изменить, чтобы контролировать использование селективных подтверждений:

1. На панели инструментов выберите Запуск запуска и введите для >Regedit запуска редактора реестра.
2. Найдите и выберите вышеуказанный ключ в редакторе реестра, а затем выберите Изменение в меню Редактирование.
3. Введите нужное значение в поле данных Value.

Допустимо двоичное значение — 0 или 1, по умолчанию — 1. Этот параметр контролирует, включена ли поддержка селективного ACK (SACK — RFC 2018).

Следующий след сетевого монитора иллюстрирует хост, который подтверждает все данные до номера последовательности 54857341, а также данные из последовательности номер 54858789-54861685. Отсутствующие данные от 54857341 до 548587888.

Поведение ретрансмиссии TCP и быстрая перетрансмиссия

Ретрансмиссия TCP

В качестве обзора нормального поведения ретрансмиссии TCP запускает ретрансмиссию, когда каждый исходящие сегменты передаются в Протокол Интернета (IP). Если подтверждения данных в данном сегменте до истечения срока действия времени не получено, сегмент повторно передается.

Время перерасчета (RTO) непрерывно корректируется в соответствие с характеристиками подключения с помощью расчетов Сглаженное время в пути (SRTT), как описано в RFC 793. После каждой повторной передачи этого сегмента время от времени для данного сегмента удваивается. С помощью этого алгоритма TCP настраивает себя на нормальную задержку подключения.

Быстрый перетрансмит

TCP повторно передает данные до истечения срока действия времени ретрансмиссии при некоторых обстоятельствах. Наиболее распространенной причиной является функция, известная как быстрая перенаторка. Когда приемник, который поддерживает быстрый перетрансмит, получает данные с номером последовательности, превысят текущий ожидаемый, некоторые данные, скорее всего, будут отброшены. Чтобы сообщить отправительу об этом событии, приемник немедленно отправляет ACK с номером ACK на ожидаемом номере последовательности. Он будет продолжать делать это для каждого дополнительного сегмента TCP, который приходит. Когда отправитель начинает получать поток acKs с одним и тем же номером последовательности, сегмент может быть отброшен. Отправитель немедленно повторно отправляет сегмент, который ожидает приемник, не дожидаясь истечения срока действия времени ретрансмиссии. Эта оптимизация значительно повышает производительность при частом сбросе пакетов.

По умолчанию Windows повторно передает сегмент в следующих условиях:

• Он получает три acKs для одного номера последовательности: один ACK и два дубликата.
• Номер последовательности отстает от текущего.

Это поведение можно контролировать с помощью TcpMaxDupAcks параметра реестра.

Значение TcpMaxDupAcks в следующем ключе реестра можно изменить, чтобы контролировать количество acKs, необходимых для запуска быстрых переадтрансмитов:

1. На панели инструментов выберите Запуск запуска и введите для >Regedit запуска редактора реестра.
2. Найдите и выберите вышеуказанный ключ в редакторе реестра, а затем выберите Изменение в меню Редактирование.
3. Введите нужное значение в поле данных Value.

Допустимый диапазон 1-3, значение по умолчанию — 2.

Этот параметр определяет количество дубликатов acKs, которые должны быть получены для того же количества отправленных данных последовательности, прежде чем запускается для повторного повторного запуска сегмента, который был отброшен fast retransmit в пути.