Понятия ip фрагментация, mtu, mss, pmtud и их связь

Синдром узкого окна

Существует еще одна проблема при пересылке данных по каналам TCP, которая называется синдром узкого окна (silly window syndrome; Clark, 1982). Такого рода проблема возникает в том случае, когда данные поступают отправителю крупными блоками, а интерактивное приложение адресата считывает информацию побайтно. Предположим, что в исходный момент времени буфер адресата полон и передающая сторона знает об этом (window=0). Интерактивное приложение считывает очередной октет из TCP-потока, при этом TCP-агент адресата поcылает уведомление отправителю, разрешающее ему послать один байт. Этот байт будет послан и снова заполнит до краев буфер получателя, что вызовет отправку ACK со значением window=0. Этот процесс может продолжаться сколь угодно долго, понижая коэффициент использования канала ниже паровозного уровня.

Заголовок TCP пакета

Заголовок TCP пакета состоит из следующих полей:

Порт отправителя.
Порт получателя.
Порядковый номер в сегменте (sequence number). В целях безопасности это значение генерируется случайным образом и может быть равно от 0 до 4294967295;
Номер подтверждения (acknowledgment number). Когда мы подтверждаем определённый пакет, в нем записывается sequence number подтверждаемого пакета.
Длина заголовка (data offset). В этом поле указывается длина заголовка TCP пакета и где начинаются фактические данные.
Зарезервированное поле. Эти биты зарезервированы для будущего использования.
Флаги. Необходимы для дополнительной функциональности. Например, позволяют установить или разорвать соединение, включить или выключить защиту от перегрузки сети и тому подобное.
Размер окна (Window Size). Указывается количество байт, считая от последнего номера подтверждения, которые готов принять отправитель данного пакета. То есть, какой у него в данный момент времени размер буфера.
Контрольная сумма (Checksum). Используется для проверки на наличие ошибок при приеме или передачи пакетов. Рассчитывается с учетом заголовка (кроме контрольной суммы) и самих данных.
Указатель срочности (Urgent pointer). Используется, если стоит флаг URG. По этому значению определяются срочные данные и они сразу же передаются приложению. Остальные данные попадают в буфер.
Дополнительные опции. Необязательно, но используются почти всегда.
Заполнение (Padding). Дополняет заголовок, пока он не закончится на 32-разрядной границе. Всегда состоит только из нулей.

Флаги в заголовке TCP

NS (Nonce Sum). Защита от случайного или злонамеренного изменения флагов. Используется для улучшения работы механизма явного уведомления о перегрузке ECN (Explicit Congestion Notification).

CWR (Congestion Window Reduced). Подтверждение получения пакета с флагом ECE и включением механизма уменьшения перегрузки (Congestion Control). Этот механизм позволяет оптимизировать отправку пакетов в перегруженных сетях.

ECE (ECN-Echo). Выполняет две функции. Если соединение только устанавливается, то означает что отправитель поддерживает ECN. В другом случае, это означает перегрузку сети (или предстоящую перегрузку) для отправителя.

URG (Urgent)

Указатель важности. 0 если не используется, 1 – используется.

ACK

Устанавливается, когда принимающая сторона подтверждает полученный пакет. Чтобы отправитель знал, какие пакеты уже были доставлены получателю. При этом в поле acknowledgment number записывается номер подтверждаемого пакета.

PSH (Push). Обычно получатель не подтверждает каждый пакет при получении. Вместо этого пакеты накапливаются в буфере, пока не передадутся приложению. Данный флаг сообщает получателю, что нужно немедленно передать всё из буфера приложению и сразу же отправить подтверждение.

RST. Сообщает о немедленном разрыве соединения. При этом соединение обрывается, а буфер очищается. Самые распространенные причины отправки пакета с таким флагом:ответ на пакет, полученный для закрытого сокета;
пользователь сам прервал соединение (например, закрыв браузер, не дожидаясь ответа);
соединение не было нормально закрыто, но находится в неактивном состоянии некоторое время.

SYN. Данный флаг означает начало соединения. Он также синхронизирует начальные номера. Первый пакет, отправленный с каждой стороны, должен иметь этот флаг.

FIN. Сообщает другой стороне что все пакеты были отправлены, и соединение пора завершить.

Что такое туннель?

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

Пассажирский протокол (IP, IPX и пр.)
Несущий протокол (GRE, IP in IP)
Транспортный протокол (IP)

Инкапсуляция трафика при работе туннеля используется, в частности, для связи географически разнесенных сетей (VPN).

Роль маршрутизатора при работе PMTUD на концах туннеля

Маршрутизатор может играть две роли при работе PMTUD на концах туннеля

Первая роль включает в себя передачу пакета от машины. Действие PMTUD заключается в проверке DF флага, размера пакета и, при необходимости, отправки ICMP сообщения.
Вторая роль включает в себя работу с инкапсулированным для туннеля пакетом. Действие PMTUD заключается в уменьшении MSS TCP сегмента, если будет получена информация о том, что пакет нуждается в фрагментации.

Общая последовательность действий маршрутизатора при работе с инкапсуляцией.

Проверка наличия DF флага
Проверка размера пакета, который туннель может передать
Фрагментировать, если пакет оказался большой и не установлен DF флаг, инкапсулировать каждый фрагмент и отправить — или — сбросить пакет, если пакет оказался большим и установлен DF флаг, и отправить ICMP сообщения к источнику пакета — или — инкапсулировать пакет, если пакет не очень большой, и отправить.

Пример.

Маршрутизатор А получает пакет размером 1500 байт, отбрасывает его поскольку он больше MTU виртуального туннельного интерфейса GRE (1476 байт).
Маршрутизатор А отправляет ICMP сообщение машине источнику пакета, с информацией о максимальном MTU 1476 байт.
Машина запоминает данное значение MTU в своей таблице маршрутизации. И переотправляет пакет размером 1476 байт.
Маршрутизатор получает пакет размером 1476 байт, добавляет 24 байта GRE данных и отправляет инкапсулированный пакет размером 1500 байт в другую точку туннеля.
На пути следования инкапсулированного пакета, встречается промежуточный роутер с MTU исходящего интерфейса 1400 байт.
Промежуточный маршрутизатор видя DF флаг, сбрасывает пакет и отправляет ICMP сообщение источнику пакета (маршрутизатору А), с информацией о максимальном MTU 1400 байт.
Маршрутизатор А запоминает данное значение MTU, как MTU туннельного интерфейса размером 1376 байт.
Не получив ответа, машина переотправляет пакет размером 1476 байт.
Маршрутизатор А получает пакет размером 1476 байт, отбрасывает его поскольку он больше MTU виртуального туннельного интерфейса GRE (1376 байт).
Маршрутизатор А отправляет ICMP сообщение машине источнику пакета, с информацией о максимальном MTU 1376 байт.
Машина запоминает данное значение MTU в своей таблице маршрутизации. И переотправляет пакет размером 1376 байт.
Маршрутизатор получает пакет размером 1376 байт, добавляет 24 байта GRE данных и отправляет инкапсулированный пакет размером 1400 байт в другую точку туннеля.
Маршрутизатор B на другой стороне туннеля получает пакет, декапсулирует и отправляет по назначению.

Стоит отметить что ICMP сообщения передаются между двумя адресатами, и не передаются дальше, увеличивая кол-во шагов.

Настройка размера полезной части голосового пакета для шлюзов Cisco CallManager и IOS

Размер полезной части голосового пакета можно настроить на шлюзах Cisco CallManager и Cisco IOS.

Примечание: Если шлюз Cisco IOS настроен в качестве шлюза MGCP с помощью Cisco CallManager, все параметры кодека (тип кодека, размер полезной части пакета, обнаружение голосовой активности и т. п.) определяются приложением Cisco CallManager.

В приложении Cisco CallManager размер полезной части голосового пакета настраивается для всей системы. Этот атрибут настраивается в окне Cisco CallManager Administration (Service > Service Parameters > select_server > Cisco CallManager) с помощью трех следующих сервисных параметров:

PreferredG711MillisecondPacketSize—(Значение по умолчанию: 20 мс. Доступные значения: 10, 20 и 30 мс.)
PreferredG729MillisecondPacketSize—(Значение по умолчанию: 20 мс. Доступные значения: 10, 20, 30, 40, 50 и 60 мс.)
PreferredG723MillisecondPacketSize—(Значение по умолчанию: 30 мс. Доступные значения: 30 и 60 мс.)

В Cisco CallManager размер полезной части голосового пакета настраивается на основе выборок в миллисекундах (мс). В таблице ниже приводятся выборки в миллисекундах и соответствующие им размеры полезной части пакета для различных кодеков.

Кодек
Размер полезной части голосового пакета (мс)
Размер полезной части голосового пакета (байт)
Комментарии
G.711
20 мс (по умолчанию)
160 байт
Обратите внимание, что скорость кодеков остается постоянной. Пример

Кодек G.711 = [240 байт * 8(бит/байт)] / 30 мс = 64 Кбит/с
30 мс
240 байт
G.729
20 мс (по умолчанию)
20 байт
30 мс
30 байт
G.723
30 мс (по умолчанию)

Для шлюзов Cisco IOS в ПО Cisco IOS версии 12.0(5)T была добавлена функция, которая позволяет изменять размер полезной части VoIP-пакетов (в байтах) через интерфейс командной строки (CLI). Новая команда имеет следующий синтаксис:

IP фрагментация и обратная сборка

Длина IP пакета может достигать 64 Кбайтов, что может превышать размер фрейма (MTU) протокола нижнего уровня, в который инкапсулируется IP. Поскольку IP может передаваться по средам с разными значениями MTU, в него был встроен механизм фрагментации. Задача принимающей стороны обратно собрать фрагменты в оригинальный IP пакет.
При IP фрагментации IP пакет делится на несколько кусочков (фрагментов), оформленных таким образом, чтобы у принимающей машины была возможность их собрать в оригинальный IP пакет. Для ее работы в заголовке IP пакета используются сл. поля: адрес источника и получателя, идентификационный номер, размер пакета, смещение фрагмента и флаги: «не фрагментировать» (DF) и «у пакета еще есть фрагменты»(MF).

Проблемы с IP фрагментацией

При работе с IP фрагментацией следует помнить о нескольких особенностях.

Обратная сборка на маршрутизаторе — очень затратная задача. Задача маршрутизатора — передавать пакеты с максимальной скоростью в нужном направлении. В то время как обратная сборка подразумевает, что устройству необходимо выделить некий буфер, в который будут складываться фрагменты IP пакета, для того чтобы IP пакет собрать и передать дальше.
Другая особенность возникает из-за ненадежности сети передачи данных. Если один из фрагментов IP пакета потеряется, то тогда весь IP пакет должен быть отправлен заново; это означает еще один полный цикл фрагментации — сборки. Для примера возьмем протокол NFS. NFS по умолчанию работает с блоками размером 8192 байта, что вместе со всеми заголовками увеличивается до примерно 8500 байтов. Для передачи такого пакета по сети Ethernet, у которой размер MTU равен 1500 байтам, потребуется фрагментация пакета на шесть частей: пять по 1500 байт и один на 1100 байт. Если хотя бы один из этих фрагментов потеряется, потребуется повторная передача всего пакета, что в свою очередь означает запуск повторной фрагментации.

Обход IP фрагментации путем использования TCP MSS.

TCP Maximum Segment Size (MSS) определяет максимальный размер данных, который машина готова получить через один TCP сегмент. Сам TCP сегмент инкапсулируется в IP пакет. Значение MSS передается в заголовке TCP SYN при установлении соединения между двумя узлами (через механизм трехэтапного установления соединения). Обе стороны соединения передают значение своего MSS. В отличие от популярного заблуждения, принимаемое значение MSS не несет характер переговоров. Отправляющий хост обязан ограничить размер своих исходящих TCP сегментов значением равным или меньшим значению, сообщенному ему принимающим хостом.
Значение MSS выбирается таким образом, чтобы предотвратить IP фрагментацию. Механизм работы MSS следующий: при создании TCP соединения, машина определяет размер буфера исходящего интерфейса и MTU этого интерфейса. Дальше эти два числа сравниваются и выбирается наименьшее. Тут следует оговориться, что за MTU выбирается число по формуле MTU минус 40 байт, для учета TCP и IP заголовков. Затем выбранное число сравнивается с размером MSS, переданным принимающей стороной, и снова выберется наименьшее значение.
Пример работы MSS:

Машина А сравнивает размер своего буфера интерфейса (16 Кбайт) со значение MTU этого интерфейса (1500-40 = 1460 байт) и использует наименьшее число как MSS при отправке к машине B.
Машина B принимает значение MSS машины A (1460) и сравнивает его со значением MTU своего исходящего интерфейса (4462 — 40 = 4422 байт).
Машина B выбирает наименьшее из получившихся значений (1460) как значение MSS при отправке TCP сегментов к машине A.
Машина B сравнивает размер своего буфера интерфейса (8 Кбайт) со значение MTU этого интерфейса (4462-40 = 4422 байт) и использует наименьшее число как MSS при отправке к машине A.
Машина A принимает значение MSS машины B (4422) и сравнивает его со значение MTU своего исходящего интерфейса (1500 — 40 = 1460 байт).
Машина A выбирает наименьшее из получившихся значений (1460) как значение MSS при отправке TCP сегментов к машине B.

Таким образом MSS на обеих сторонах установлено равным 1460 байтам, это наиболее частая ситуация.
В данном примере IP фрагментация не будет происходить, поскольку в процессе установления TCP соединения, размер TCP сегментов был взят с расчетом на вмещение в MTU низлежащей сети. Однако, если IP пакет пойдет через сети с меньшим MTU, то может потребоваться фрагментация.

Передача данных в TCP

Теперь разберём пример передачи данных в уже установленном сеансе.

Клиент отравляет запрос к серверу. Поскольку данные поместились в один пакет TCP, он получил флаг PSH, чтобы сервер не ждал продолжение получения данных. При этом пакет получил 2 флага: ACK (подтвердил предыдущею передачу пакетов от сервера) и PSH.

В ответ на это сервер отправляет пакет ACK с номером успешно полученных данных.

Далее сервер обработал запрос и отправляет данные клиенту. Эти данные делятся на пакеты и отправляются сегментами.

Далее клиент подтверждает, что данные получены отправляя пакеты с флагом ACK.

Механизмы протокола HTTP

При более внимательном рассмотрении этот пример показывает, как приложения на каждом конечном компьютере (приложение веб-браузера и приложение веб-сервера) используют протокол прикладного уровня TCP/IP. Чтобы сделать запрос веб-страницы и вернуть содержимое веб-страницы, приложения используют протокол передачи гипертекста (HTTP).

HTTP не существовал до тех пор, пока Тим Бернерс-Ли не создал первый веб-браузер и веб-сервер в начале 1990-х годов. Бернерс-Ли предоставил HTTP функцию для запроса содержимого веб-страниц, а именно, предоставив веб-браузеру возможность запрашивать файлы с сервера и дав серверу возможность возвращать содержимое этих файлов. Общая логика соответствует тому, что показано на рисунке 1; на рисунке 2 показана та же идея, но с подробностями, относящимися к HTTP.

ПРИМЕЧАНИЕ. Полная версия большинства веб-адресов, также называемых унифицированными указателями ресурсов (URL, Uniform Resource Locators) или универсальными идентификаторами ресурсов (URI, Universal Resource Identifiers), начинается с букв http, что означает, что для передачи веб-страниц используется HTTP.

Рисунок 2 – HTTP запрос GET, HTTP ответ и одно сообщение только с данными

Чтобы получить веб-страницу от Гарри, Роб на этапе 1 отправляет сообщение с заголовком HTTP. Обычно протоколы используют заголовки как место для размещения информации, используемой этим протоколом. Этот HTTP заголовок включает запрос на «получение» файла. Запрос обычно содержит имя файла (в данном случае home.htm), или, если имя файла не упоминается, веб-сервер предполагает, что Бобу нужна веб-страница по умолчанию.

Шаг 2 на рисунке 2 показывает ответ веб-сервера Гарри. Сообщение начинается с HTTP заголовка с кодом состояния (200), который означает нечто простое, например, «ОК», возвращаемое в заголовке. HTTP также определяет другие коды состояния, чтобы сервер мог сообщить браузеру, сработал ли запрос (например: если вы когда-нибудь искали веб-страницу, которая не была найдена, и получили ошибку HTTP 404 «не найдена», вы получили HTTP код состояния 404). Второе сообщение также включает начальную часть запрошенного файла.

Шаг 3 на рисунке 2 показывает еще одно сообщение от веб-сервера Гарри веб-браузеру Роба, но на этот раз без HTTP заголовка. HTTP передает данные, отправляя несколько сообщений, каждое из которых является частью файла. Вместо того, чтобы тратить место на отправку повторяющихся HTTP заголовков, содержащих повторяющуюся информацию, эти дополнительные сообщения просто пропускают заголовок.

TCP против UDP в различных протоколах VPN, таких как OpenVPN

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

OpenVPN позволяет использовать протокол TCP и UDP для туннеля данных, как вы видели, TCP и UDP сильно различаются, и всегда рекомендуется использовать TCP, так как он имеет управление потоком, контроль перегрузки, контроль ошибок и многие другие функции, которые делают соединение надежным. Если вы собираетесь использовать OpenVPN, по умолчанию используется UDP, это связано с тем, что, если есть какие-либо проблемы, протоколы прикладного уровня, такие как HTTP (который использует TCP ниже), будут отвечать за выполнение повторных передач, если это было необходимо, поэтому соединение будет надежным (управление потоком, перегрузка, ошибки и т. д.), даже если зашифрованный туннель точка-точка использует UDP.

Очень важный аспект заключается в том, что сервер OpenVPN с UDP будет способен принимать больше входящих соединений одновременно, если вы используете UDP, чем если вы используете TCP, кроме того, у нас также будет большая пропускная способность, так как дополнительная «загрузка» не добавляется потому что UDP намного «легче».

Как вы видели, как TCP, так и UDP являются двумя основными интернет-протоколами, и каждый из них обрабатывает разные протоколы прикладного уровня.

В других контекстах

MTU иногда используется для описания максимальных размеров PDU на уровнях связи, отличных от сетевого.

Cisco Systems использует L2 MTU для максимального размера кадра.
Dell / Force10 использует MTU для максимального размера кадра.
Hewlett Packard использовал только MTU для максимального размера кадра, включая дополнительный тег IEEE 802.1Q .
В Juniper Networks используется несколько терминов MTU: MTU физического интерфейса ( MTU L3 плюс некоторые неуказанные накладные расходы протокола), MTU логического интерфейса (в соответствии с MTU IETF) и Максимальный MTU (максимальный настраиваемый размер кадра для jumbo-кадров).

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

Протокол UDP: что это и как работает?

Протокол UDP (протокол пользовательских дейтаграмм) является одним из основных протоколов в Интернете, он позволяет приложениям обмениваться данными с гарантиями независимо от нижних уровней модели TCP / IP. Это означает, что маршрутизаторы (сетевой уровень в модели TCP / IP) должны отправлять только дейтаграммы (единица измерения в UDP). UDP поддерживает несколько протоколов прикладного уровня, например, популярный DNS и даже протокол DHCP для автоматического получения (и предоставления) IP-адресации.

основные черты

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

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

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

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

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

Заголовок UDP

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

Сводка

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

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

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

Важно!

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

Порядок следования сообщений

Но подтверждений и повторной отправки данных недостаточно для обеспечения надежной передачи потока байт. Это защищает только от потери сегментов, но не обеспечивает сохранение порядка следования сообщений.

Какие проблемы могут произойти? Протокол IP не сохраняет порядок следования сообщений и поэтому сегменты могут прийти к получателю не в том порядке в котором они были отправлены. Кроме того, некоторые сегменты могут прийти два и более раз. Рассмотрим одну из возможных причин дублирования сегментов.

Дублирование сегментов

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

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

Механизм очень простой, все сообщения нумеруются. В TCP нумеруются не сегменты, так как разные сегменты могут иметь разный размер, а байты.

В нашем примере 4 сегмента первый сегмент содержит байты от 0 до 1023, второй от 1024 до 2047 и так далее.

Нумерация байтов

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

Например сегмент данных, байт 0, он содержит байты с 0 до 1023.
Получатель отправляет подтверждение и в подтверждение включает номер следующего байта, который ожидается байт 1024.
Отправитель передает следующий сегмент, включая в него номер первого байта, сегмент данных, номер первого байта 1024 содержит данные до номера байта 2047.
Получатель отправляет подтверждение, что он ждет байт с номером 2048, если сегменты придут в неправильном порядке, то получатель по номерам байтов всегда сможет выставить их в правильной последовательности.

Дублирование сегментов

Рассмотрим как решается ситуация с дублированием сегментов.

Отправитель включает в сегмент номер первого передаваемого байта 1024.
Получатель отправляет подтверждение, где говорит что ждет байт в 2048.
Но так как подтверждение не дошло, то отправитель передает тот же самый сегмент 1024.
Однако получатель видит, что этот сегмент у него уже есть поэтому он этот сегмент игнорирует и снова отправляет подтверждение, где говорит что он ожидает байт 2048.

Измерение производительности сети в Azure

В этой статье рассматривается ряд максимальных показателей производительности, связанных с задержкой сети и временем кругового пути (RTT) между двумя виртуальными машинами. Этот раздел содержит рекомендации по тестированию задержки и RTT, а также проверке производительности TCP и производительности сети виртуальных машин. Вы можете настроить и протестировать производительность для описанных выше параметров TCP/IP и сети, используя методы, описанные в этом разделе. Вы можете подставлять значения задержки, MTU, MSS и размера окна в приведенные выше расчеты и сравнивать теоретический максимальный уровень с фактическими значениями, наблюдаемыми во время тестирования.

Измерение времени кругового пути и потери пакетов

Производительность TCP в значительной степени зависит от RTT и потери пакетов. Служебная программа PING, доступная в Windows и Linux, является наиболее простым способом для измерения показателей RTT и потери пакетов. В выходных данных PING будет показана минимальная, максимальная и средняя задержка между источником и назначением. Также отображаются потери пакетов. PING по умолчанию использует протокол ICMP. Для проверки RTT TCP-соединения можно использовать PsPing. Дополнительные сведения см. на странице PsPing.

Измерение фактической пропускной способности TCP-соединения

NTttcp — это средство для тестирования производительности TCP-соединений виртуальной машины Linux или Windows. Вы можете изменить различные параметры TCP, а затем проверить эффект с помощью NTttcp. Для получения дополнительных сведений см. следующие ресурсы.

Измерение фактической пропускной способности виртуальной машины

Вы можете измерять производительность различных типов виртуальных машин, ускорения сети и т. д. с помощью инструмента iPerf. Инструмент iPerf также доступен в Linux и Windows. Для проверки общей пропускной способности сети iPerf может использовать протокол TCP или UDP. На тесты iPerf пропускной способности протокола TCP влияют факторы, описанные в этой статье (например, задержка и RTT). Поэтому, если нужно просто протестировать максимальную пропускную способность, UDP может показать лучшие результаты.

Дополнительные сведения вы найдете в следующих статьях:

Обнаружение проблем с эффективностью TCP

При сборе пакетов клиенты Azure могут видеть TCP-пакеты с флагами TCP (SACK, DUP ACK, RETRANSMIT и FAST RETRANSMIT), которые могут указывать на проблемы с производительностью сети. Эти пакеты прямо указывают на неэффективность сети вследствие потери пакетов. Однако потеря пакетов не обязательно связана с проблемами с производительностью Azure. Проблемы с производительностью могут возникать в результате проблем с приложениями, операционной системой или других проблем, которые могут быть не связаны с платформой Azure напрямую.

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

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

Соединение TCP

TCP для передачи данных использует соединение. Соединение нужно установить перед тем, как начать передачу данных, а после того как передача данных завершена, соединение разрывается.

Задачи соединения

Убедиться в том, что отправитель и получатель действительно хотят передавать данные друг другу
Договориться о нумерации потоков байт. С точки зрения практической реализации нельзя всегда нумеровать данные в потоке байт с нуля. Каждый раз начальное значение для нумерации байт выбираются по определенному алгоритму и отправитель и получатель должны договориться между собой какое начальное значение они будут использовать для нумерации потока байт.
При установке соединения происходит договоренность о некоторых параметрах соединения.

Установка соединения в TCP

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

Получатель в ответ передаёт сообщение SYN, куда включает подтверждение получения предыдущего сообщения ACK от слова acknowledge и порядковый номер байта, который он ожидает 7538, потому что на предыдущем этапе был получен байт с номером 7537.

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

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

Разрыв соединения в TCP

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

Протокол TCP предусматривает два варианта разрыва соединения: корректное, с помощью одностороннего разрыва соединения и сообщения FIN и разрыв из-за критической ситуации с помощью сообщения RST.

Рассмотрим, как выполняется корректный разрыв соединения. Сторона, которая хочет разорвать соединение пересылает другой стороне сообщение FIN и в ответ получает сообщение ACK. Однако соединение разорвано только с одной стороны.

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

Для разрыва соединения в критической ситуации из-за ошибок в приложении или с оборудованием используется одно сообщение RST. В этом случае соединение закрывается в обе стороны. Хотя сообщение RST предназначено для использования в критических ситуациях, некоторые протоколы используют его для быстрого закрытия соединения.