Tcp window full что это

Какие параметры влияют на производительность приложений? Часть 1. TCP Window Size

Размер TCP окна (TCP Window Size) – количество октетов (начиная с номера подтверждения), которое принимающая сторона готова принять в настоящий момент без подтверждения. На стадии установления соединения рабочая станция и сервер обмениваются значениями максимального размера TCP окна (TCP Window Size), которые присутствуют в пакете и эти значения можно легко увидеть, воспользовавшись захватом трафика.

Например, если размер окна получателя равен 16384 байта, то отправитель может отправить 16384 байта без остановки. Принимая во внимание, что максимальная длина сегмента (MSS) может быть 1460 байт, то отправитель сможет передать данный объем в 12 фреймах, и затем будет ждать подтверждение доставки от получателя и информации по обновлению размера окна. Если процесс прошел без ошибок, то размер окна может быть увеличен. Таким образом, реализуется размер скользящего окна в стеке протокола TCP.

В зависимости от состояния каналов связи, размер окна может быть больше или меньше. Каналы связи могут быть высокоскоростными (большая пропускная способность) и протяженными (большая задержка и возможно потери), поэтому при небольшом размере TCP окна мы будем вынуждены отправлять один или несколько фреймов и ждать подтверждения от получателя, затем процесс повторяется. Таким образом, наши приложения будут неэффективно использовать доступную полосу пропускания. Пакетов будет много, но реального полезного трафика будет передано не много. Чтобы получить максимальную пропускную способность, необходимо использовать оптимально установленный размер передающего и принимающего окна для канала, который вы используете.

Для расчёта максимального размера окна (т.е. максимальный объем данных, которые могут передаваться одним пользователем другому в канале связи) рассчитывается по формуле:

Полоса пропускания (бит/сек) * RTT (круговое время передачи по сети) = размер окна в битах

Таким образом, если ваши два офиса соединяет канал связи в 10 Мбит/сек и круговое время составляет 85 миллисекунд, то воспользовавшись данной формулой, мы получим значение окна равное:

10 000 000 * 0,085 / 8 = 106250 байт

Размер поля Window в заголовке TCP составляет 16 бит; это означает, что узел TCP может указать максимальный размер TCP окна 65535 байт. Таким образом, максимальная пропускная способность составляет:

65535 * 8 / 0,085 = 6,2 Мбит/сек

т.е. чуть больше 50% от реально доступной полосы пропускания канала.

В современных версиях операционных систем можно увеличить размер окна TCP Window Size и включить динамическое изменение окна в зависимости от состояния канала связи. В предложении RFC 1323 дано определение масштабирования окон, позволяющего получателю указывать размер окна больше 65535 байт, что позволит применять большие размеры окон и высокоскоростные каналы передачи. Параметр TCP Window Scale указывает коэффициент масштабирования окна, который в сочетании с 16-битным полем Window в заголовке TCP может увеличивать размер окна приема до максимального значения, составляющего примерно 1 ГБ. Параметр Window Scale отправляется только в сегментах синхронизации (SYN) при установке соединения. На нашем скриншоте из WireShark он составляет 256. Устройства, общающиеся друг с другом, могут указывать разные коэффициенты масштабирования для TCP окон.

Таким образом, активировав масштабирование окон TCP и уменьшив круговое время передачи по сети, мы сможем повысить эффективность использования доступной полосы пропускания и как следствие скорость работы приложений. А проверить это можно захватив пакеты, и посмотреть о каких значениях размера окна и коэффициенте масштабирования договорились устройства в момент установки соединения. Это динамическое увеличение и уменьшение размера окна является непрерывным процессом в TCP и определяет оптимальный размер окна для каждого сеанса. В очень эффективных сетях размеры окна могут стать очень большими, потому что данные не теряются. В сетях, где сетевая инфраструктура перегружена, размер окна, вероятно, останется маленьким.

Источник

Tcp window full что это

By default, Wireshark’s TCP dissector tracks the state of each TCP session and provides additional information when problems or potential problems are detected. Analysis is done once for each TCP packet when a capture file is first opened. Packets are processed in the order in which they appear in the packet list. You can enable or disable this feature via the “Analyze TCP sequence numbers” TCP dissector preference.

For analysis of data or protocols layered on top of TCP (such as HTTP), see Section 7.8.3, “TCP Reassembly”.

Figure 7.7. “TCP Analysis” packet detail items

TCP Analysis flags are added to the TCP protocol tree under “SEQ/ACK analysis”. Each flag is described below. Terms such as “next expected sequence number” and “next expected acknowledgement number” refer to the following”:

TCP ACKed unseen segment

Set when the expected next acknowledgement number is set for the reverse direction and it’s less than the current acknowledgement number.

TCP Dup ACK #

Set when all of the following are true:

TCP Fast Retransmission

Set when all of the following are true:

Supersedes “Out-Of-Order” and “Retransmission”.

TCP Keep-Alive

Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence number, and any of SYN, FIN, or RST are set.

Supersedes “Fast Retransmission”, “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”.

TCP Keep-Alive ACK

Set when all of the following are true:

Supersedes “Dup ACK” and “ZeroWindowProbeAck”.

TCP Out-Of-Order

Set when all of the following are true:

TCP Port numbers reused

Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequence number is different than the existing conversation’s initial sequence number.

TCP Previous segment not captured

Set when the current sequence number is greater than the next expected sequence number.

TCP Spurious Retransmission

Checks for a retransmission based on analysis data in the reverse direction. Set when all of the following are true:

Supersedes “Fast Retransmission”, “Out-Of-Order”, and “Retransmission”.

TCP Retransmission

Set when all of the following are true:

TCP Window Full

Set when the segment size is non-zero, we know the window size in the reverse direction, and our segment size exceeds the window size in the reverse direction.

TCP Window Update

Set when the all of the following are true:

TCP ZeroWindow

Set when the receive window size is zero and none of SYN, FIN, or RST are set.

The window field in each TCP header advertises the amount of data a receiver can accept. If the receiver can’t accept any more data it will set the window value to zero, which tells the sender to pause its transmission. In some specific cases this is normal — for example, a printer might use a zero window to pause the transmission of a print job while it loads or reverses a sheet of paper. However, in most cases this indicates a performance or capacity problem on the receiving end. It might take a long time (sometimes several minutes) to resume a paused connection, even if the underlying condition that caused the zero window clears up quickly.

TCP ZeroWindowProbe

Set when the sequence number is equal to the next expected sequence number, the segment size is one, and last-seen window size in the reverse direction was zero.

If the single data byte from a Zero Window Probe is dropped by the receiver (not ACKed), then a subsequent segment should not be flagged as retransmission if all of the following conditions are true for that segment: * The segment size is larger than one. * The next expected sequence number is one less than the current sequence number.

This affects “Fast Retransmission”, “Out-Of-Order”, or “Retransmission”.

TCP ZeroWindowProbeAck

Set when the all of the following are true:

Supersedes “TCP Dup ACK”.

TCP Ambiguous Interpretations

Some captures are quite difficult to analyze automatically, particularly when the time frame may cover both Fast Retransmission and Out-Of-Order packets. A TCP preference allows to switch the precedence of these two interpretations at the protocol level.

Источник

Что я могу сделать, чтобы избежать TCP Zero Window / TCP Window Full на стороне приемника?

У меня есть небольшое приложение, которое отправляет файлы по сети агенту, расположенному в ОС Windows.

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

код Windows-Linux почти такой же, и довольно простой. Единственной нетривиальной операцией является setsockopt с SO_SNDBUF и значением 0xFFFF. Удаление этого кода не помогло.

может кто-нибудь, пожалуйста, помогите мне с этой проблемой?

EDIT: добавление кода отправки-похоже, что он обрабатывает правильно частичные записи:

4 ответов

не видя ваш код, я думаю.

причина, по которой Вы получаете нулевое окно в TCP, заключается в том, что нет места в буфере recv приемника.

существует несколько способов, которыми это может произойти. Одной из распространенных причин этой проблемы является отправка по локальной сети или другому относительно быстрому сетевому соединению, и один компьютер значительно быстрее, чем другой компьютер. В качестве крайнего примера, скажем, у вас есть компьютер 3GHz, отправляющий как можно быстрее гигабитный Ethernet на другую машину, на которой работает Процессор 1GHz. Поскольку отправитель может отправлять намного быстрее, чем получатель может читать, буфер recv получателя заполнится, заставляя стек TCP рекламировать нулевое окно отправителю.

теперь это может вызвать проблемы как на отправляющей, так и на принимающей стороне, если они оба не готовы иметь дело с этим. На стороне отправки это может привести к заполнению буфера отправки и вызовам для отправки либо для блокировки, либо для сбоя, если вы используя неблокирующий ввод-вывод на принимающей стороне, вы можете потратить так много времени на ввод-вывод, что приложение не имеет возможности обработать какие-либо данные и создать видимость блокировки.

редактировать

из некоторых ваших ответов и кода похоже, что ваше приложение однопоточное, и вы пытаетесь сделать неблокирующие отправки по какой-то причине. Я предполагаю, что вы устанавливаете сокет на неблокирующий в какой-то другой части кода.

в целом, я бы сказал, что это не очень хорошая идея. В идеале, если вы беспокоитесь о своем приложении, висящем на send(2) вы должны установить длительный тайм-аут в сокете, используя setsockopt и используйте отдельный поток для фактической отправки.

ваш основной поток может толкать каждый файловый дескриптор в queue используя, скажем, мьютекс boost для доступа к очереди, затем запустите 1-N потоков, чтобы сделать фактическую отправку, используя блокировку ввода-вывода с тайм-аутами отправки.

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

как правило, вы должны позвонить doSend в цикле с кусками данных, которые имеют TCP_MAXSEG размер.

на стороне приема вы можете написать аналогичную функцию блокировки recv, используя тайм-аут в отдельном потоке.

распространенной ошибкой при разработке с TCP-сокетами является неправильное предположение о поведении read()/write ().

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

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

Я попытался отключить алгоритм Нэгла (с TCP_NODELAY), и как-то это помогло. Скорость передачи намного выше, размер окна TCP не заполняется или не сбрасывается. Странно то, что когда я проверял размер окна, это не имело никакого влияния.

Источник

Wireshark [TCP Window Full] & [Zero Window]

TCP sliding window is very crucial concept in understanding how TCP behaves. In order to see how this mechanism works, I have rate limited an HTTP download and observed what happens during this scenario in which we will see reports from Wireshark that [TCP Window Full] and [TCP ZeroWindow]. The aim of this post is to try to show how wireshark understands that Window is full.

We have a web server and a client machine on this setup. We intentionally rate limit the traffic by using wget to allow us investigate this scenario.

Yes we have downloaded the the file. During the download I also took packet capture on the client side. In order to understand the behaviour, first this rate limiting needs a bit of explanation. When you set the option “–limit-rate” on wget, software in order to sustain the throughput you set, sends a TCP segment with Window Size set to 0 which literally instructs the sender to pause. As my aim is to try to understand how Wireshark notices window full situation, we are starting to investigate the packet capture right after client sends a TCP ACK with Window Size zero.

We should better zoom into particular time frame in order to understand this event easier as the whole story is developed between Pkt 181 and Pkt 200 in this capture. You need to take a look at this screenshot before going further in the article since it shows how we go from “Window Zero” to Window full state.

Packet no: 181 is sent from client with Win=0 as you can see. At that particular moment, sender knows that it isn’t allowed to send any more packets.

Packet no: 182 client this time decides to accept packets because of which sets the WindowSize to 22656 (Win=22656). What does this mean practically? As window size is a number which tells the sender that “You can send this number of bytes without expecting any acknowledgement from me“, sender resumes sending segments as fast as it can from this point on.

Packet no: 183 – 197 In a normal TCP communication you don’t see this number of segments which aren’t acknowledged. This is because of our rate limiting actually.

Now we stop the clock right after packet 197 is received i.e T=0.653210000 and take a closer look at the status of the window or we somehow take a snapshot of the receive window at this point.

Have you stopped the clock at Time = 0.653210000. Remember! client had told sender that your window is 22656Bytes. You can only send this amount with no ACK from me. What we see here is that packets from 183 to 197 didn’t receive any ACK from client (receiver). Hence number of bytes sent but not ACKed are 20272Bytes. This means sender can send 22656 – 20272 = 2280Bytes more and if doesn’t receive any feedback(ACK), then it will stop.

Packet 198: but something happens here. Receiver(client) decides to acknowledge some of the bytes by setting ACK=4109684389. What does really this mean? With this single number, Receiver is telling the Sender that “I have received all the bytes up to this byte”. By this announcement, Receiver has actually acknowledged Pkt 183 sent from the sender. Not clear? Maybe I can show it like this. Let’s open the bytes on Pkt 183 and see how the bytes are counted.

SEQ number (4109683925) is the first byte in the TCP segment which is an inclusive number and our packet’s TCP payload has 464 bytes which means the last byte number is (4109684388). Hence on the ACK Pkt 198, receiver says that it is acknowledging the last byte 4109684388 by setting the ACK to 4109684389. It is important to understand that ACK number is the next expected sequence number of the TCP segment from the other side.

Now what happens. This is really important to understand the whole topic. At the beginning of the transaction on Pkt 183, receiver had set the Window to 22656 but now on this latest ACK (Pkt 198), it is reducing the window size further to 22272 (Win=22272) hence sender should send less bytes and the below image shows both how window is sliding and reduced at the same time.

What does this snapshot of the Receive window mean?
It means sender can send 2000 Bytes more without any acknowledgement from the receiver.

Pkt 199 (1448 Bytes) and Pkt 200 (552 Bytes) are sent from the sender which fills this usable window 2000Bytes. Therefore there isn’t any available space left in the receive window and Wireshark immediately detects and displays you the message [TCP Window Full]

I must say that it is really cool! Wireshark is doing a wonderful job to help people troubleshooting network issues.
I am hoping I haven’t done any conceptual mistake here. This is how I understand this behaviour. If you have anything to add or correct, please do let me know.

Related

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN, currently living in the Netherlands and works as a Network Support Engineer. // JNCIE-SEC #223 / RHCE / PCNSE

Источник

Описание Windows TCP

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

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

Сводка

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

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

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

Размер окна TCP

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

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

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

См. раздел «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:

В следующем списке показаны вид, длина, имя и описание каждого варианта 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. Затем размер окна умножается на коэффициент масштабирования, идентифицированный в трехшаговом рукопожатии. В таблице ниже представлены границы коэффициента масштабирования для различных размеров окна.

Если размер окна в реестре вошел как 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):

Поле параметра 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 разрешено:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник