tcp sack что это
TCP Selective Acknowledgments (SACK)
By stretch | Thursday, June 17, 2010 at 2:34 a.m. UTC
Last week, we examined how TCP uses sequence and acknowledgment numbers to keep track of data in bidirectional transit between two end hosts. However, we observed only an ideal TCP stream, where all packets are delivered to either end successfully, and in order. What happens if one goes missing?
The diagram below illustrates a TCP connection taking place between a client and server separated by a network. Time progresses vertically from top to bottom as packets are sent.
The client sends some request to the server, and the server formulates a response broken into four TCP segments (packets). The server transmits all four packets in response to the request. However, the second response packet is dropped somewhere on the network and never reaches the host. Let’s walk through what happens.
Step 1
Response segment #2 is lost.
Step 2
The client receives segment #3. Upon examining the segment’s sequence number, the client realizes this segment is out of order; there is data missing between the last segment received and this one. The client transmits a duplicate acknowledgment for packet #1 to alert the server that it has not received any (reliable) data beyond packet #1.
Step 3
As the server is not yet aware that anything is wrong (because it has not yet received the client’s duplicate acknowledgment), it continues by sending segment #4. The client realizes that it is still missing data, and repeats its behavior in step three by sending another duplicate acknowledgment for packet #1.
Step 4
The server receives the client’s first duplicate acknowledgment for packet #1. Because the client has only confirmed receipt of the first of the four segments, the server must retransmit all three remaining segments in the response.
The second duplicate acknowledgment received from the client is ignored.
Step 5
The client successfully receives and acknowledges the three remaining segments.
Enter Selective Acknowledgments
You’ve probably noticed that this design is inefficient: although only packet #2 was lost, the server was required to retransmit packets #3 and #4 as well, because the client had no way to confirm that it had received those packets.
This problem was originally addressed by RFC 1072, and more recently by RFC 2018, by introducing the selective acknowledgment (SACK) TCP option. SACKs work by appending to a duplicate acknowledgment packet a TCP option containing a range of noncontiguous data received. In other words, it allows the client to say «I only have up to packet #1 in order, but I also have received packets #3 and #4». This allows the server to retransmit only the packet(s) that were not received by the client.
Support for SACK is negotiated at the beginning of a TCP connection; if both hosts support it, it may be used. Let’s look at how our earlier example plays out with SACK enabled:
Step 1
Response segment #2 is lost.
Step 2
The client realizes it is missing a segment between segments #1 and #3. It sends a duplicate acknowledgment for segment #1, and attaches a SACK option indicating that it has received segment #3.
Step 3
The client receives segment #4 and sends another duplicate acknowledgment for segment #1, but this time expands the SACK option to show that it has received segments #3 through #4.
Step 4
The server receives the client’s duplicate ACK for segment #1 and SACK for segment #3 (both in the same TCP packet). From this, the server deduces that the client is missing segment #2, so segment #2 is retransmitted. The next SACK received by the server indicates that the client has also received segment #4 successfully, so no more segments need to be transmitted.
Step 5
The client receives segment #2 and sends an acknowledgment to indicate that it has received all data up to an including segment #4.
Enough Theory, Here’s a Capture
This packet capture contains a demonstration of SACKs in action. We know that both end hosts support selective acknowledgments by the presence of the SACK permitted option in the two SYN packets, #1 and #2.
Toward the end of the capture, we can see that packet #30 was received out of order, and the client has sent a duplicate acknowledgment in packet #31. This packet includes a SACK option indicating that the segment in packet #30 was received.
Of course, the SACK option cannot simply specify which segment(s) were received. Rather, it specifies the left and right edges of data that has been received beyond the packet’s acknowledgment number. A single SACK option can specify multiple noncontiguous blocks of data (e.g. bytes 200-299 and 400-499).
We can see this duplicate acknowledgment repeated in packets #33, #35, and #37. In each, the SACK is expanded to include the noncontiguous segments the server has continued sending. Finally, the server retransmits the missing segment in packet #38, and the client updates its acknowledgment number appropriately in packet #39.
Support PacketLife by buying stuff you don’t need!
Tcp sack что это
Рубрика WireShark — Это своего рода мануал по работе с программой анализа трафика.
Большинство статей — переведены и подготовлены для русскоязычных читателей, имеющих желание подробно ознакомиться с данной программой, но не обладающих достаточными знаниями английского языка. Все недочеты и пожелания оставляйте в комментариях.
Wireshark что такое SACK_PERM, TSval, TSecr
В SYN пакетах, которые используются в настройке сеанса рукопожатия TCP есть дополнительные параметры TCP, такие как: SACK_PERM, TSval, TSecr. Все это так называемые высокопроизводительные параметры, которые сейчас широко распространены, поскольку все современные стеки TCP знают о них и используют, особенно в средах с высокой пропускной способностью с высокой задержкой (LFN).
SACK_PERM — означает, что узел с IP «знает», как работать с так называемыми « S- выборками Ack »
Параметр Timestamps содержит два поля по четыре байта. Поле «Значение времени» (TSval) содержит текущее значение времени метки времени TCP, отправляющего эту опцию.
Поле Timestamp Echo Reply (TSecr) действует только в том случае, если бит ACK установлен в заголовке TCP. Если он действителен, он отображает значение времени, которое было отправлено удаленным TCP в поле TSval параметра Timestamps. Когда TSecr недействителен, его значение должно быть равно нулю. Значение TSecr, как правило, будет иметь самую последнюю выбранную временную отметку.
Значение временной метки, которое необходимо отправить в TSval, должно быть получено из (виртуальных) часов, которые мы называем «timestamp clock». Его значения должны быть, по крайней мере, приблизительно пропорциональны реальному времени, чтобы измерить фактическое RTT.
Интересные статьи
Сетевой разговор в Wireshark — это трафик между двумя конкретными конечными точками. Например, IP-разговор — это весь трафик между двумя IP-адресами. Окно бесед похоже на окно конечной точки. Наряду с адресами, […]
Wireshark использует язык фильтра libpcap для фильтров захвата. Ниже приведен краткий обзор синтаксиса. НЕ путайте фильтры захвата (Capture filter) ( пример : tcp port 80 ) и фильтры отображения (display […]
Меню Analyze в Wireshark содержит в себе следующие элементы:
Меню View в Wireshark содержит в себе следующие элементы: Некоторые пункты меню могут отсутствовать или называться по другому
Панель инструментов Wireshark фильтры, позволяет быстро редактировать и применять фильтры отображения. Вы можете определить фильтры с помощью Wireshark и дать им метки для последующего использования. Это может сэкономить время на запоминание […]
Меню Go в Wireshark содержит в себе следующие элементы:
How to prepare TCP
Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Первое — это диагностика проблемы, определение причин сбоя.
Взять и измерить давление, сделать пальпацию, проверить уровень масла в двигателе и так далее, и тому подобное.
А что если проблемы возникли при передаче данных в интернет/интранет-сети?
Тут, по-видимому, потребуются особые средства диагностики.
В особенности будут полезны средства, которые позволяют проводить статистический анализ большого количества данных.
Существует множество разных инструментов.
Часть из них можно найти в такой замечательной программе, как Wireshark.
В меню Statistics (Статистика) Wireshark представлен богатый набор функциональности.
При этом результаты могут представляться не только в общем, но и графическом виде.
Как раз о графическом виде и хочется поговорить.
Рассказать о наборе из пяти графиков статистики TCP StreamGraph.
Позволяют легко и эффективно проводить анализ и диагностику TCP-соединений.
Но прежде чем начинать говорить о графиках, для их лучшего понимания рассмотрим основы теории TCP.
Минимум, необходимый для общего понимания TCP StreamGraph
Ниже приведена картинка с частным случаем TCP обмена данных.
Следует рассматривать как упрощенный вариант.
В примере, нумерация сегментов начинается с единицы.
Хотя в действительности это не совсем так.
Однако то же самое показывает и Wireshark при дефолтных настройках.
Отправитель шлет два сегмента (Seq=1 и Seq=6), содержащих по пять байт данных каждый.
Получатель отвечает, что все байты до 10 получены успешно и ожидается следующий 11-й сегмент (Ack=11).
Отправитель передает еще два (Seq=11 и Seq=16), один из которых теряется в сети (Seq=11).
Получатель констатирует, что в потоке принятых данных возник разрыв.
Сообщает, что начиная с первого байта непрерывно приняты только 10 байт и он по-прежнему ждет 11-й сегмент (Ack=11).
Однако одновременно с этим в подтверждающем сегменте указывает SACK (Selective acknowledgment, выборочное подтверждение) блок, с диапазоном байт, полученных после разрыва. Благодаря SACK отправитель повторно передаст только пропавший сегмент (Seq=11). Без SACK потребовалось бы повторять Seq=16 тоже. Использование SACK должно поддерживаться обеими сторонами обмена.
А теперь рассмотрим процесс передачи данных в TCP-соединении через TCP StreamGraph в Wireshark.
Однако, чтобы не описывать графики просто так, сделаю это на простом и понятном примере.
Загружу файл с тестового сервера на свой компьютер, используя протокол HTTP.
Для этого воспользуюсь утилитой curl, а не веб-браузером.
curl поможет создать некоторые проблемы, которые увидим на графиках.
Проблемы возникнут вследствие того, что загрузка будет вестись напрямую в консоль, а не в файл.
Итак, запускаю Wireshark, включаю захват трафика.
Загружаю утилитой curl тестовый файл размером 10Мб с сервера v4.speedtest.reliableservers.com (10MBtest.bin).
Останавливаю захват трафика.
В полученном сетевом дампе Wireshark ищу HTTP пакет с GET запросом файла 10MBtest.bin и определяю номер TCP–соединения, в котором он загружался. Или ищем по фильтру tcp contains «10MBtest.bin».
Фильтрую весь трафик по номеру TCP-соединения в котором загружался тестовый файл tcp.stream==5.
А вот теперь смотрим TCP StreamGraph.
Важно знать, что все графики из TCP StreamGraph строятся по одному TCP соединению и являются направленными.
Направление указывает, в какую сторону двигался анализируемый поток данных от клиента к серверу или наоборот.
Time-Sequence Graph (Stevens)
Time-Sequence Graph (Stevens) выглядит как наклонная кривая, состоящая из точек.
Координаты каждой точки графика — это значение Sequence number TCP сегмента (ось Y — Байты) и время его захвата (ось X — секунды).
Соответственно, как говорилось ранее, учитываются только сегменты с данными одного TCP-соединения, перемещавшиеся в определенном направлении, от серверу к клиенту (загрузка, download) или наоборот (выгрузка, upload).
Согласно теории Sequence number, это номер первого байта данных сегмента в общем потоке данных.
Поэтому можно сказать, что график показывает динамику загрузки/выгрузки байт данных в TCP соединении по времени.
На любом участке легко рассчитывается скорость передачи данных, (Sequence number деленная на Time, получаем Байт/сек).
Как следствие, по изменениям наклона участков кривой можно судить об изменениях скорости передачи данных.
В идеальных условиях график выглядит как диагональная линия с большим углом наклона.
Однако на практике это не всегда так.
По аномалиям на кривой графика можно выявить задержки в передаче данных, потери сегментов и их повторные отправки (Retransmission).
На приведенном ниже примере графика во время загрузки файла возникли две схожие проблемы с остановкой передачи данных и потерей сегментов.
Горячие клавиши в Windows (краткая справка):
Пошаговое увеличение или уменьшение масштаба графика выполняется через клавиши i/o или прямым выделением участка мышью. Возврат к исходному масштабу, клавиша Home.
Пробел — превращает курсор в перекрестие с вертикальной и горизонтальной вспомогательными линиями.
Цифровые клавиши с 1 по 5 — выбор другого графика из набора.
Ctrl + правая кнопка мыши — появляется окно с увеличенным изображением участка графика из под курсора.
Щелчок мышки на любой точке графика приводит к переходу в интерфейсе Wireshark на соответствующий ей TCP пакет.
Time-Sequence Graph (tcptrace)
По внешнему виду Time-Sequence Graph (tcptrace) напоминает предыдущий график и предназначен для более полного анализа возможных проблем. В нем все так же выводятся значения Sequence number сегментов потока данных на временной шкале.
Однако добавился еще один атрибут сегмента — его размер (TCP Segment Len).
Поэтому сегменты отображаются уже не точками, а вертикальными отрезками с засечками на концах, как английская буква I — «ай». Основание отрезка это Sequence number, а длина — размер сегмента в байтах.
Также на графике выводится информация из обратного потока подтверждающих сегментов, Window (Win), Acknowledgment number (Ack) и SACK. Значения Ack отображаются ступенчатой кривой, проходящей ниже сегментов данных.
Каждая ступень, ее вершина — это момент времени прихода подтверждения об общем количестве непрерывно принятых байт получателем.
Аналогично “ступенчато” отображается размер окна принимающей стороны Win.
Кривая проходит выше потока данных.
Вершина ступени — это сумма значений Ack и Win подтверждающего сегмента.
Синими вертикальными линиями визуализируются SACK блоки.
SACK может присутствовать в подтверждении, если в сплошном потоке полученных данных возникли разрывы.
Синяя линия — это диапазон байт полученных после разрыва.
В общем виде график представляет собой “коридор” из двух ступенчатых кривых, внутри которого перемещаются сегменты с данными. Сужение «коридора» говорит об уменьшении размера окна приема (Win), расширение — об обратном.
На предыдущем графике были обнаружены две проблемы с остановкой передачи данных.
Time-Sequence Graph (tcptrace) внес ясность в причины случившегося.
Уменьшился размер окна (Win) на принимающей стороне.
Отправитель передал максимально допустимое количество сегментов с данными, чтобы не переполнить окно, и остановился.
После того, как получатель сообщил об увеличении размера окна (Window Update), передача данных возобновилась.
Throughput Graph
Throughput Graph выглядит как множество точек, иногда расположенных весьма хаотично.
Координаты каждой точки — это расчетная скорость перемещения сегмента в потоке данных (ось Y — Байт/сек) и время его захвата (ось X — секунды).
Если быть точным, для сглаживания колебаний на графике фиксируются не реальные, а усредненные значения скорости.
Используется усредняющая функция скользящего среднего (Moving Average, MA) на 20 значений за предыдущий период.
По коду Wireshark, средняя скорость N-го сегмента равна сумме длин всех сегментов от N до N-20, деленная на дельту по времени между их захватом.
Как следствие, две задержки в передаче данных, вызванные уменьшением размера окна (Win), привели к падению Throughput в проблемные моменты времени. В остальное время скорость закачки варьировалась в пределах диапазона от 1.4 до 3.4 МБайт.
Round Trip Time Graph
Round Trip Time (RTT) — это время, прошедшее между отправкой сегмента с данными и получением подтверждения о его успешной доставке.
Round Trip Time Graph показывает RTT (ось Y — секунды) по каждому сегмента из потока данных.
Идентификатором сегмента выступает его Sequence number (ось X — Байты).
При нормальных условиях большая часть точек концентрируется в нижней части графика.
В примере RTT почти все время не превышает 0.1 сек., за исключением проблемных моментов, когда RTT подскакивала до 0.4 сек.
Все графики связаны между собой формулой Throughput = Window size / RTT
Window Scaling Graph
Координаты каждой точки Window Scaling Graph — это размер окна Windowsize (ось Y — Байты) сегмента на момент времени его захвата (ось X — секунды).
В Window Scaling Graph присутствует информация о двех проблемных случаях сокращения размера окна до критичных размеров.
Это полностью подтверждает показаниями на Time-Sequence Graph.
Заключение
Ну вот, кажется, и все. Что хотел — сказал.
Информации по теме гораздо больше. В статье были изложены только основы, помогающие лучше понять графики из TCP StreamGraph, Wireshark.
Эти графики очень полезны в своем практическом применении и позволяют делать всесторонний обзор любого TCP-соединения, выявлять сетевые проблемы.
Конечно, есть и другие инструменты, подобные TCP StreamGraph, например, tcptrace, captcp.
Не стоит забывать и о IO Graph того же Wireshark. Он обладает более обширной функциональностью выходящей далеко за пределы TCP StreamGraph.
Надеюсь, статья окажется полезна всем тем, кто интересуется сетевыми технологиями или изучает протокол TCP.
Tcp sack что это
Максим КУЛЬГИН
СЕТИ #11/99
В первой части статьи были рассмотрены основы протокола ТСР, прежде всего — механизм плавающего окна. Вторая часть посвящена основным методам и алгоритмам оптимизации работы протокола, а также способам предотвращения перегрузок в сети.
Стратегии отправления и приема данных
При отсутствии данных, помеченных флагом PSH, протокол TCP на стороне отправителя имеет возможность самостоятельно назначать время передачи. Когда данные передаются модулю протокола ТСР пользовательским приложением, они записываются в передающий буфер. Протокол TCP может создавать отдельные сегменты для каждой группы данных, поступивших от приложения, либо дожидаться накопления большого объема данных и только после этого формировать и отправлять сегменты. Выбор конкретной политики отправки данных всецело зависит от требований к производительности. Если передачи сегментов происходят редко, но при этом пересылаются большие объемы данных, то накладные расходы, связанные с созданием сегмента и его обработкой, оказываются небольшими. Если же передачи осуществляются часто, а объем транспортируемых данных невелик, то система способна обеспечить быструю реакцию на изменения состояния сети.
Когда отсутствуют данные, помеченные флагом PSH, протокол TCP на стороне получателя также может самостоятельно определять время доставки данных пользовательскому приложению. Так, возможны доставка данных при получении сегментов в их исходной последовательности или занесение данных из нескольких сегментов в буфер приема. Как и в предыдущем случае, реальная схема определяется требованиями к производительности. Если данные приходят редко и имеют большие объемы, то приложение получит их не сразу. Если данные поступают часто и малыми порциями, может возникнуть избыточная и обременительная обработка информации протоколом TCP и приложением.
В том случае, когда сегменты поступают в порядке их отсылки по установленному соединению, протокол TCP помещает данные в буфер получения для доставки пользовательскому приложению. Но вполне возможно, что какие-либо сегменты будут поступать c нарушением первоначального порядка следования. Тогда протокол TCP на приемной стороне сможет принимать только те сегменты, которые приходят в порядке отправления (а остальные просто отбрасывать), либо все сегменты, чьи номера зафиксированы в окне получения (вне зависимости от порядка их поступления).
Первый из этих вариантов упрощает реализацию протокола, однако создает дополнительную нагрузку на сеть, так как отправитель, подождав некоторое время, начнет повторно передавать сегменты, которые были успешно получены, но затем отброшены из-за некорректного порядка поступления. Более того, если хотя бы один сегмент потерялся при передаче, приходится повторно посылать все последующие сегменты. При втором варианте количество повторных передач может быть снижено, но зато требуются более сложные алгоритм приема и схема буферизации данных и отслеживания порядка их поступления.
Протокол TCP поддерживает очередь отправленных сегментов, подтверждения о приеме которых еще не поступили. Согласно спецификации протокола сегмент будет передан повторно, если подтверждение не поступит в течение определенного периода. Разные реализации протокола TCP могут поддерживать три стратегии повторной передачи.
«Только первый». Поддерживается один таймер повторной передачи для всей очереди. При получении подтверждения первый сегмент удаляется из очереди повторной передачи и таймер сбрасывается. Если время таймера истекает, повторно передается сегмент из начала очереди и таймер обнуляется.
Пакетная. Также поддерживается один таймер повторной передачи для всей очереди. Когда приходит подтверждение, из очереди повторной передачи удаляются все сегменты и таймер сбрасывается. Если время таймера истекает, повторно передаются все сегменты из очереди и таймер обнуляется.
Индивидуальная. Для каждого сегмента в очереди существует отдельный таймер. При получении подтверждения из очереди повторной передачи удаляется первый сегмент, а соответствующий таймер обнуляется. По истечении времени какого-либо таймера повторно передается только соответствующий сегмент и его таймер сбрасывается.
Первая стратегия повышает эффективность передачи трафика, поскольку повторно передается лишь потерянный сегмент (или тот, чье подтверждение о приеме было потеряно). Однако из-за того, что таймер для второго сегмента в очереди не устанавливается, пока не подтвержден прием первого сегмента, могут возникать некоторые задержки. Индивидуальная стратегия решает эти проблемы ценой более сложной реализации. Использование пакетного режима также снижает вероятность длительных задержек, но способно привести к ненужным повторным передачам.
Реальная эффективность политики повторной передачи зависит от реализуемой схемы приема сегментов на стороне получателя. Если избран подход, при котором принимаются только сегменты, следующие в порядке отправления, то сегменты, поступившие после потерянного, будут отброшены. Такая схема хорошо подходит для пакетной стратегии. Если же получатель принимает все сегменты, независимо от порядка их прибытия, то оптимальными являются стратегии «только первый» и индивидуальная.
При поступлении сегмента протокол TCP на приемной стороне имеет два варианта выбора времени отправки подтверждения.
«Немедленно». Сразу после принятия данных с определенным номером последовательности передается пустой (без данных) сегмент, содержащий соответствующий номер подтверждения.
«С накоплением». Когда данные успешно приняты, отмечается необходимость в подтверждении, но последнее отправляется с очередным исходящим сегментом данных, в котором устанавливается флаг АСК. Во избежание длительных задержек устанавливается таймер окна. Если время таймера истекает до момента отсылки очередного сегмента данных, то отправителю посылается пустой сегмент, содержащий соответствующий номер подтверждения.
Пример реализации механизма SACK
Алгоритм немедленной отправки подтверждений проще в реализации и позволяет поддерживать полную информированность протокола TCP на отправляющей стороне, что минимизирует ненужные повторные передачи. В то же время его использование приводит к появлению дополнительных пустых сегментов, служащих исключительно для подтверждения успешного приема. Более того, такой подход повышает загруженность сети. Вполне возможна, например, ситуация, в которой протокол ТСР на приемной стороне получает сегмент и немедленно посылает подтверждение, а приложение вдруг расширяет свое приемное окно, инициируя тем самым передачу пустого сегмента для предоставления дополнительного лимита отправляющей стороне.
Так как описанная стратегия выдачи подтверждений сопряжена с высокими накладными расходами, обычно используется режим работы с накоплением. Следует отметить, что применение этого режима приводит к увеличению нагрузки на получающей стороне и усложняет задачу отправителя по оценке времени обращения сегментов.
Рассмотрим два расширения протокола TCP, используемых в среде Windows NT.
Выборочное подтверждение (TCP Selective Acknowledgement — SACK, RFC 2018). Это расширение сравнительно недавно одобрил консорциум IETF. Оно позволяет подтверждать прием данных не в порядке их поступления, как это было раньше, а выборочно. Подобный подход имеет два главных преимущества.
Во-первых, повышается эффективность повторной передачи сегментов ТСР благодаря сокращению времени выполнения этой процедуры. Обычно протокол TCP использует алгоритм повторной передачи, опираясь на информацию, которую он получает на основе упорядоченных подтверждений. Такой вариант вполне приемлем, однако в случае его применения для восстановления каждого потерянного сегмента требуется примерно один цикл обращения. SACK же позволяет осуществлять в одном цикле повторную передачу сразу нескольких потерянных сегментов.
| Показатель | SackOpts | TcpDelAckTicks | TcpMaxDupAcks |
| Ключ в реестре | Tcpip\Parameters | Tcpip\Parameters\Interfaces\ | Tcpip\Parameters |
| Тип записи | REG_DWORD-Boolean | REG_DWORD-Number | REG_DWORD-Number |
| Границы значений | 0, 1 (False, True) | 0-6 | 1-3 |
| Значение по умолчанию | 1 (True) | 2 (200 мс) | 2 |
Во-вторых, благодаря выборочным подтверждениям протокол TCP точнее оценивает доступную ширину полосы пропускания в условиях нескольких последовательных потерь сегментов и способен обойтись без алгоритма «Медленный старт». SACK играет важную роль в соединениях, в которых используется окно TCP большого размера. Когда работает SACK (а в Windows NT это расширение включено по умолчанию), при потере сегмента или серии сегментов получатель имеет возможность точно проинформировать отправителя о том, какие данные были приняты успешно, и указать на образовавшуюся «прореху» в потоке сегментов. Отправитель может повторно передавать только потерянные данные, а не весь их блок, в состав которого входят и успешно принятые пакеты. Для управления алгоритмом SACK служит параметр SackOpts (столбец 2 табл. 2), определенный в реестре операционной системы Windows NT 5.0.
Врезка иллюстрирует процедуру перехвата сегментов сетевым монитором (Microsoft Network Monitor). В этом примере подтверждено получение данных до номера 54857341, а также данных с номерами от 54858789 до 54861685. Данные с номерами от 54857341 до 54858789 не подтверждены. Таким образом, SACK указывает на то, что данные с номерами от 54857341 до 54858789 были пропущены и отправителю следует повторить их передачу.
Задержанное подтверждение (Delayed Acknowledgement, RFC 1122). В соответствии с этим алгоритмом подтверждения высылаются при условии, что подтверждение приема предыдущего сегмента не отправлялось и после принятия данного сегмента в течение 200 мс не поступил следующий. Значение таймера задержанного подтверждения можно устанавливать с помощью параметра TcpDelAckTicks реестра операционной системы Windows NT 5.0 (столбец 3 табл. 2); впервые он был введен в пакете обновлений Service Pack 4 для версии Windows NT 4.0.
Значения данного параметра могут меняться в диапазоне от 0 до 6, где единица соответствует 100 мс; другими словами, максимальное значение таймера равно 600 мс. Обнуление таймера запрещает использование задержанных подтверждений, что приводит к немедленным отправлениям подтверждений для каждого полученного сегмента.
Таймер повторной передачи
Протокол TCP не формирует явных негативных подтверждений, непосредственно указывающих на нарушение процедуры передачи. Вместо этого он «полагается» исключительно на положительные подтверждения и повторную передачу в тех случаях, когда подтверждение не поступает в течение определенного интервала времени. К повторной передаче сегмента приводит любое из двух событий:
В обоих случаях посылающая сторона не знает о том, что передача сегмента оказалась неудачной.
Когда сегмент принимается с ошибками либо не поступает вовсе, подтверждение ACK просто не формируется, что однозначно указывает на необходимость повторной передачи. Для принятия решения о повторной передаче используется таймер, работающий с каждым посланным сегментом. Если время таймера истекает до получения ACK для данного сегмента, отправитель должен выполнить повторную передачу.
Регулируемое время этого таймера является важным параметром протокола TCP. Если его значение будет слишком малым, то заметно участятся ненужные повторные передачи, уменьшающие полезную полосу пропускания сети, что вызовет дополнительные повторные передачи и т. д. При очень большом значении реакция протокола на потерю сегмента станет слишком медленной. Таймер должен быть установлен так, чтобы его значение немного превышало время обращения сегмента (Round Trip Time, RTT). Естественно, эта задержка зависит от множества факторов, влияние которых ощутимо даже при постоянной загрузке сети.
Существуют два способа, позволяющих установить время таймера повторной передачи. В первом случае используется фиксированное значение таймера, величина которого основывается на статистических данных, отражающих обычное поведение распределенной сети (т. е. таймер выставляется с небольшим превышением среднего значения RTT). Понятно, что такая стратегия исключает гибкое реагирование на резкие изменения условий работы сети.
Пример реализации алгоритма «Временная метка»
Второй подход опирается на адаптивную схему, которая также имеет достоинства и недостатки. Предположим, что протокол TCP постоянно отслеживает время получения подтверждений, свидетельствующих о приеме сегментов, и устанавливает значение таймера, основываясь на наблюдаемой задержке. Это значение не может полностью удовлетворять всей совокупности требований к транспортному протоколу по следующим причинам: получение сегмента иногда не подтверждается немедленно (напомним, что привилегия дается задержанным подтверждениям), при повторной передаче сегмента отправитель не знает, относится ли полученный ACK к начальному сегменту или его копии, а кроме того, условия в сети порой меняются внезапно. Эта проблема не имеет исчерпывающего решения: всегда существует некоторая неуверенность в правильности установки значения таймера повторной передачи.
Если в поведении сети произойдут какие-либо изменения, велика вероятность того, что статический таймер повторной передачи неадекватно отреагирует на них: его значение окажется либо слишком малым, либо слишком большим. Поэтому все реализации протокола TCP пытаются оценить текущее время передачи в процессе наблюдения за характером изменения задержек последних посланных сегментов. На основании этой оценки устанавливается значение таймера, которое имеет небольшое превышение над оцененным временем передачи.
| Время | Отправитель | Получатель | Протокол | Флаги | Описание |
| 0.000 | 10.57.10.32 | 10.57.9.138 | TCP | .A. | len: 1460, seq: 8043781, ack: 8153124, win: 8760 |
| 0.521 | 10.57.10.32 | 10.57.9.138 | TCP | .A. | len: 1460, seq: 8043781, ack: 8153124, win: 8760 |
| 1.001 | 10.57.10.32 | 10.57.9.138 | TCP | .A. | len: 1460, seq: 8043781, ack: 8153124, win: 8760 |
| 2.003 | 10.57.10.32 | 10.57.9.138 | TCP | .A. | len: 1460, seq: 8043781, ack: 8153124, win: 8760 |
| 4.007 | 10.57.10.32 | 10.57.9.138 | TCP | .A. | len: 1460, seq: 8043781, ack: 8153124, win: 8760 |
| 8.130 | 10.57.10.32 | 10.57.9.138 | TCP | .A. | len: 1460, seq: 8043781, ack: 8153124, win: 8760 |
Рассмотрим один из подходов, который учитывает среднее наблюдаемое время для некоторого количества посланных сегментов. Если это время достаточно точно предсказывает будущие задержки, то полученное значение таймера повторной передачи обеспечит очень хорошую производительность сети. Усредненное время можно определить, используя следующее выражение:
где RTT(i) — наблюдаемое время обращения i-го переданного сегмента, а ARTT(K) — среднее время обращения для первых K сегментов. Для удобства последующего изложения представим приведенное выражение в виде
Следует учесть, что каждый параметр в последней формуле имеет равный вес. Однако, как правило, больший вес, или большая степень доверия, присваивается самым последним замерам, поскольку они точнее всего отражают будущее поведение сети. Общий метод предсказания очередного усредненного значения времени обращения на основе предыдущей серии измерений приведен в документе RFC 793. В его основе лежит выражение
где SRTT(K) — так называемое сглаженное оцененное время обращения (Smoothed Round Trip Time). Нетрудно сравнить это выражение с предыдущим. Используя константу a (0