Чем идентифицируется логическое tcp соединение

Логические соединения — основа надежности TCP

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

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

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

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

Рис. 17.6. TCP-соединение создает надежный логический канал между конечными узлами

При установлении логического соединения модули TCP договариваются между собой о параметрах процедуры обмена данными. В протоколе TCP каждая сторона соединения посылает противоположной стороне следующие параметры:

§ максимальный размер сегмента, который она готова принимать;

§ максимальный объем данных (возможно несколько сегментов), которые она разрешает другой стороне передавать в свою сторону, даже если та еще не получила квитанцию на предыдущую порцию данных (размер окна);

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

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

Соединение устанавливается по инициативе клиентской части приложения. При необхо­димости выполнить обмен данными с серверной частью приложение-клиент обращается к нижележащему протоколу TCP, который в ответ на это обращение посылает сегмент- запрос на установление соединения протоколу TCP, работающему на стороне сервера (рис. 17.7, а). В числе прочего в запросе содержится флаг SYN, установленный в 1. Получив запрос, модуль TCP на стороне сервера пытается создать «инфраструктуру» для обслуживания нового клиента. Он обращается к операционной системе с просьбой о вы­делении определенных системных ресурсов для организации буферов, таймеров, счетчиков. Эти ресурсы закрепляются за соединением с момента создания и до момента разрыва. Если на стороне сервера все необходимые ресурсы были получены и все необходимые действия выполнены, то модуль TCP посылает клиенту сегмент с флагами АСК и SYN.

Рис. 17.7. Процедура установления и разрыва логического соединения при нормальном течении процесса

В ответ клиент посылает сегмент с флагом АСК и переходит в состояние установленного логического соединения (состояние ESTABLISHED). Когда сервер получает флаг АСК, он также переходит в состояние ESTABLISHED. На этом процедура установления соеди­нения заканчивается, и стороны могут переходить к обмену данными.

Соединение может быть разорвано в любой момент по инициативе любой стороны. Для этого клиент и сервер должны обменяться сегментами FIN и АСК, в последовательности, показанной на рис. 17.7,б (здесь инициатором является клиент). Соединение считается закрытым по прошествии некоторого времени, в течение которого сторона-инициатор убеждается, что ее завершающий сигнал АСК дошел нормально и не вызвал никаких «аварийных» сообщений со стороны сервера.

Мы описали здесь процедуры установления и закрытия соединения очень схематично. Реальные протокольные модули работают в соответствии с гораздо более сложными алгоритмами, учитываю­щими всевозможные «нештатные» ситуации, такие, например, как задержки и потери сегментов, недостаточность ресурсов или неготовность сервера к установлению соединения. Кроме того, мы проигнорировали тот факт, что еще на этапе установления соединения стороны договариваются о некоторых параметрах своего взаимодействия, например о начальных номерах посылаемых ими байтов. Однако мы скоро вернемся к этим важным деталям работы протокола TCP.

Логическое TCP-соединение однозначно идентифицируется парой сокетов, определенных для этого соединения двумя взаимодействующими процессами.

Сокет одновременно может участвовать в нескольких соединениях. Так, на рис. 17.8 по­казаны три компьютера с адресами IP1, IP2, IP3. На каждом компьютере выполняется по одному приложению — APPL1, APPL2 и APPL3, сокеты которых — соответственно (IP1, n1), (IP2, n2), (IP3, nЗ), а номера TCP-портов приложений — n1, n2, nЗ.

Рис. 17.8. Один сокет может участвовать в нескольких соединениях

На рисунке показаны два логических соединения, которое установило приложение 2 с приложением 1 и приложением 3. Логические соединения идентифицируются как <(IP2, n2), (IP1, n1)>и <(IP2, n2), (IP3, n3)>соответственно. Мы видим, что в обоих соединениях участвует один и тот же сокет — (IP2, п2).

А теперь рассмотрим на примере, как протокол TCP выполняет демультиплексирование. Пусть некий поставщик услуг оказывает услугу по веб-хостингу, то есть на его компью­тере клиенты могут разворачивать свои веб-серверы. Веб-сервер основан на протоколе прикладного уровня HTTP, который передает свои сообщения в TCP-сегментах. Модуль TCP ожидает запросы от веб-клиентов (браузеров), «прослушивая» хорошо известный порт 80.

На рис. 17.9 показан вариант хостинга с двумя веб-серверами — сервером www1.model.ru, имеющим IP-адрес IP1, и сервером www2.tour.ru с адресом IP2. К каждому из них может обращаться множество клиентов, причем клиенты могут одновременно работать как с сер­вером www1, так и с сервером www2. Для каждой пары клиент-сервер протоколом TCP создается отдельное логическое соединение.

На рисунке показаны два браузера, имеющие соответственно сокеты (IP_k, n_k) и (IP_m, n_m). Пользователь браузера k обращается одновременно к серверам WWW 1 и WWW2. Нали­чие отдельных соединений для работы с каждым из этих серверов обеспечивает не только надежную доставку, но и разделение информационных потоков — у пользователя никогда не возникает вопроса, каким сервером ему была послана та или иная страница. Одновре­менно с пользователем браузера k с сервером WWW2 работает пользователь браузера т. И в этом случае отдельные логические соединения, в рамках которых идет работа обоих пользователей, позволяют изолировать их информационные потоки. На рисунке показаны буферы, количество которых определяется не числом веб-серверов и не числом клиентов, а числом логических соединений. Сообщения в эти буферы направляются в зависимости от значений сокетов как отправителя, так и получателя. Отсюда можно сделать вполне конкретный вывод.

Рис. 17.9. Демультиплексирование протокола TCP на основе соединений

Протокол TCP осуществляет демультиплексирование информации, поступающей на прикладной уровень, на основе соединений процессов или, что одно и то же, на основе идентифицирующих эти процессы пар сокетов.

Чем идентифицируется логическое tcp соединение

Транспортный уровень. Протоколы TCP, UDP.

• установление транспортного соединения;
• передача данных;
• разрыв транспортного соединения.

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

• восстанавливать порядок сегментов;
• убирать дубликаты сегментов, в каком бы виде (фрагментация) они не поступали;
• определять разумную задержку для time out для подтверждений в получении сегмента;
• устанавливать и разрывать соединения надежно;
• управлять потоком;
• управлять перегрузками.

1. Формат TCP-пакета
   Протокол управления передачей TCP (Transmission Control Protocol) является обязательным стандартом TCP/IP, который описан в документе RFC 793 «Transmission Control Protocol (TCP)» и предоставляет надежную службу доставки пакетов, ориентированную на установление соединения. Протокол TCP:
   • гарантирует доставку IP-датаграмм;
   • выполняет разбиение на сегменты и сборку больших блоков данных, отправляемых программами;
   • обеспечивает доставку сегментов данных в нужном порядке;
   • выполняет проверку целостности переданных данных с помощью контрольной суммы;
   • посылает положительные подтверждения, если данные получены успешно. Используя избирательные подтверждения, можно также посылать отрицательные подтверждения для данных, которые не были получены;
   • предлагает предпочтительный транспорт для программ, которым требуется надежная передача данных с установлением сеанса связи, например для баз данных «клиент-сервер» и программ электронной почты.

TCP основан на связи «точка-точка» между двумя узлами сети. TCP получает данные от программ и обрабатывает их как поток байтов. Байты группируются в сегменты, которым TCP присваивает последовательные номера, необходимые для правильной сборки сегментов на узле-приемнике.
Чтобы два узла TCP могли обмениваться данными, им нужно сначала установить сеанс связи друг с другом. Сеанс TCP инициализируется с помощью процесса, называемого трехэтапным установлением связи. В этом процессе синхронизируются номера последовательности и передается управляющая информация, необходимая для установления виртуального соединения между узлами.
TCP-сегменты инкапсулируются и передаются в IP-датаграммах, как показано на следующем рисунке.
Заголовок TCP-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности первого протокола. Рис. 1. Формат заголовка сегмента TCP.

• флаг URG (Urgent Pointer – указатель точности) устанавливается в 1 в случае использования поля указатель на срочные данные;
• флаг ACK (Acknowledgment – подтверждение) устанавливается в 1 в случае, если поле номер подтверждения содержит данные. В противном случае это поле игнорируется;
• флаг PSH (Push – выталкивание) означает, что принимающий стек TCP должен немедленно информировать приложение о поступивших данных, а не ждать пока буфер заполнится;
• флаг RST (Reset – сброс) используется для отмены соединения: из-за ошибки приложения, отказа от неверного сегмента, попытки создать соединение при отсутствии затребованного сервиса;
• флаг SYN (Synchronize – синхронизация) устанавливается при инициировании соединения и синхронизации порядкового номера;
• флаг FIN (Finished – завершение) используется для разрыва соединения. Он указывает, что отправитель закончил передачу данных.

Рис. 2. Структура пакета TCP при вычислении контрольной суммы.

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

Рис. 3. Структура псевдозаголовка пакета TCP.

Поле протокол (длина 1 байт) идентифицирует протокол из заголовка пакета IP. Для TCP это значение равно 6. Включение псевдозаголовка в контрольную сумму TCP помогает обнаружить неверно доставленные пакеты, хотя это нарушает иерархию протоколов, так как IP-адреса в нем принадлежат IP-уровню, а не TCP-уровню. Поле указатель на срочные данные (Urgent Pointer) (длина 2 байта) содержит смещение в байтах от текущего порядкового номера байта до места расположения срочных данных. Содержимым срочных данных занимаются вышестоящие уровни.
Поле параметры (options) (длина переменная, кратная 32 битам) содержит дополнительные поля, расширяющие возможности стандартного заголовка.

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

• соединение 1 – <(IP2, n2), (IP1, n1)>;
• соединение 2 – <(IP1, n1), (IP3, n3)>;
• соединение 3 – <(IP2, n2), (IP3, n3)>.

Рис. 5. Нумерация байтов в TCP-сегменте.

Когда отправитель посылает TCP-сегмент, он в качестве идентификатора сегмента помещает в поле порядкового номера номер первого байта данного сегмента. Так, на рис. 6 идентификаторами сегментов являются номера 32600, 34060, 36520 и т.д. На основании этих номеров TCP-получатель не только отличает данный сегмент от других, но и позиционирует полученный фрагмент относительно общего потока. Кроме того, он может сделать вывод, что полученный сегмент является дубликатом или что между двумя полученными сегментами пропущены данные и т.д.
Рис. 6. Порядковый номер и номер квитанции.

В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в которое помещает число (номер подтверждения), на единицу превышающее максимальный номер байта в полученном сегменте. Для сегментов, изображенных на рис. 6, квитанцией о получении (номером подтверждения) служат номера последнего байта каждого сегмента +1. Так для первого отправленного сегмента это будет число 34060, для второго – 36520 и т.д. Номер подтверждения часто интерпретируют как номер следующего ожидаемого байта данных. Квитанция (подтверждение) в протоколе TCP посылается только в случае правильного приема данных, отрицательные квитанции не посылаются. Таким образом, отсутствие квитанции означает либо потерю сегмента, либо прием искаженного сегмента, либо потерю квитанции.
В протоколе TCP в одном и том же сегменте могут быть помещены и данные, которые посылает приложение другой стороне, и квитанция, которой модуль TCP подтверждает получение данных.
Протокол TCP является дуплексным, то есть в рамках одного соединения регламентируется процедура обмена данными в обе стороны. Каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один – для хранения принятых сегментов, другой – для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были отправлены, но квитанции о получении которых еще не поступили.
И при установлении соединения, и в ходе передачи обе стороны, выступая в роли получателя, посылают друг другу так называемые окна приема. Каждая из сторон, получив окно приема, «понимает», сколько байтов ей разрешается отправить с момента получения последней квитанции. Другими словами, посылая окна приема, обе стороны пытаются регулировать поток байтов в свою сторону, сообщая своему «визави», какое количество байтов (начиная с номера байта, о котором уже была выслана квитанция) они готовы в настоящий момент принять.
На рис. 7 показан поток байтов, поступающих с верхнего уровня в выходной буфер протокола TCP. Из протокола байтов модуль TCP «нарезает» последовательность сегментов и готовит их для отправки другому сокету. В этом потоке можно указать несколько логических границ. Первая граница отделяет сегменты, которые уже были отправлены и на которые уже пришли квитанции. По другую сторону этой границы располагается окно размером W байт. Часть байтов, входящих в окно, составляют сегменты, которые уже были отправлены, но квитанции на них пока не получены. Оставшаяся часть окна – это сегменты, которые пока не отправлены, но могут быть отправлены, так как входят в пределы окна. И наконец, последняя граница указывает на начало последовательности сегментов, ни один из которых не может быть отправлен до тех пор, пока не придет очередная квитанция и окно не будет сдвинуто вправо.
Если размер окна равен W, а последняя по времени квитанция содержала значение N, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером N+W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции.

Рис. 7. Особенности реализации алгоритма скользящего окна в протоколе TCP.

Формат UDP-пакета
Протокол UDP, являясь дейтаграммным протоколом, реализует сервис по возможности, то есть не гарантирует доставку своих сообщений, а, следовательно, никоим образом не компенсирует ненадежность дейтаграммного протокола IP.
Единица данных протокола UDP называется UDP-пакетом или пользовательской дейтаграммой (user datagram). Каждая дейтаграмма переносит отдельное пользовательское сообщение. Это приводит к естественному ограничению: длина дейтаграммы UDP не может превышать длины поля данных протокола IP, которое, в свою очередь, ограничено размером кадра технологии нижнего уровня. Поэтому если UDP-буфер переполняется, то данные приложения отбрасываются. Заголовок UDP-пакета, состоящий из четырех 2-байтовых полей, содержит поля порт источника, порт получателя, длина UDP и контрольная сумма.

Рис. 8. Формат заголовка пакета UDP.

Рис. 10. Структура псевдозаголовка пакета UDP

Поле протокол (длина 8 бит) идентифицирует протокол из заголовка пакета IP. Для UDP это значение равно 17. Судя по простоте заголовка, протокол UDP очень сложным не является. Здесь стоит прямо сказать о том, чего UDP не делает. Итак, UDP не занимается контролем потока, контролем ошибок, повторной передачей после приема испорченного сегмента. Его функции сводятся к мультиплексированию и демультиплексированию данных между сетевым и прикладным уровнями. Для процессов, которым хочется управлять потоком, контролировать ошибки и временные интервалы, протокол UDP – это как раз то, что нужно. Одной из областей, где UDP применяется особенно широко, является область клиент-серверных приложений. Зачастую клиент посылает короткий запрос серверу и надеется получить короткий ответ. Если запрос или ответ теряется, клиент по прошествии определенного интервала может попытаться еще раз. Это позволяет не только упростить код, но и уменьшить требуемое количество сообщений по сравнению с протоколами, которым требуется начальная настройка.
Рассмотрим, как протокол UDP решает задачу демультиплексирования. Казалось бы, для этой цели достаточно использовать номера портов. Кадры, несущие UDP-дейтаграммы, прибывают на сетевой интерфейс хоста, последовательно обрабатываются протоколами стека и, наконец, поступают в распоряжение протокола UDP. UDP извлекает из заголовка номер порта назначения и передает данные на соответствующий порт соответствующему приложению, то есть выполняет демультиплексирование.
Это решение выглядит очень логично и просто, однако оно неработоспособно в ситуации, когда на одном конечном узле выполняется насколько копий одного и того же приложения. Пусть, например, на одном хосте запущены два DNS-сервера, причем оба используют для передачи своих сообщений протокол UDP. DNS-сервер имеет UDP-порт 53. В то же время у каждого из DNS-серверов могут быть свои клиенты, собственные базы данных, собственные настройки. Когда на сетевой интерфейс данного компьютера придет запрос от DNS-клиента, в UDP-дейтаграмме будет указан номер порта 53, который в равной степени относится к обоим DNS-серверам – так кому же из них протокол UDP должен передать запрос? Чтобы снять неоднозначность, применяют следующий подход. Разным копиям одного приложения, даже установленным на одном компьютере, присваивают разные IP-адреса. В данном примере DNS-сервер 1 имеет IP-адрес IP1, а DNS-сервер 2 имеет IP-адрес IP2. Таким образом, однозначно определяет прикладной процесс в сети (а тем более в пределах одного компьютера) пара (IP-адрес, номер порта UDP), называемая UDP-сокетом.

Как протокол TCP идентифицирует логические соединения?

"Протокол TCP осуществляет демультиплексирование информации, поступающей на прикладной уровень, на основе соединений процессов или, что одно и тоже, на основе идентифицирующих эти процессы пар сокетов."

Так, а что такое сокет? А это пара IP-адрес+ порт

То есть к TCP протоколу пришла инфа. Он должен в ней распознать

1)порт отправителя
2)порт получателя
3)IP-адрес отправителя
4)IP-адрес получателя

Эти четыре данные дадут два сокета-уникальное соединение, с которым TCP сопоставит буфер и запихает туда данные. А дальше уже прикладная задача из буфера будет читать. (всё это я в книжке прочёл)

Только вот закавыка какая. Не может TCP-протокол распознать IP адреса из пришедших ему данных (сегментами которые называются). Вот заголовок TCP-сегмента:

Нету там ни IP-адреса получателя, ни IP-адреса отправителя (а порты есть- два первых поля). Так как же TCP-протокол распознаёт пришедшие к нему данные? Спасибо, кто откликнется.

Реализовать на tcp сокетах переподключение к tcp серверу в случае потери соединения
Всем привет, подскажите как можно реализовать на tcp сокетах переподключение к tcp серверу в случае.

Как происходит получение данных через протокол TCP
Имеется клиент-серверное приложение: using System; using System.Collections.Generic; using.

Как можно узнать через VBA , есть ли tcp/ip протокол.
если есть, то как можно узнать , локальный ip адресс.

Как создать локальную сеть через протокол TCP\IPv6?
как создать локальную сеть через протокол TCP\IPv6? ДАНО: роутер D-LINK DIR-300 rev. B7, интернет.

Чем идентифицируется логическое tcp соединение

В стеке протоколов TCP/IP протокол TCP (Transmission Control Protocol) работает так же, как и протокол UDP, на транспортном уровне. Он обеспечивает надежную транспортировку данных между прикладными процессами путем установления логического соединения.

Сегменты TCP

Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, называемая сегментом.

В протоколе TCP предусмотрен случай, когда приложение обращается с запросом о срочной передаче данных (бит PSH в запросе установлен в 1). В этом случае протокол TCP, не ожидая заполнения буфера до уровня размера сегмента, немедленно передает указанные данные в сеть. О таких данных говорят, что они передаются вне потока — out of band.

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

Аналогичные проблемы решаются и на сетевом уровне. Для того, чтобы избежать фрагментации, должен быть выбран соответствующий максимальный размер IP-пакета. Однако при этом должны быть приняты во внимание максимальные размеры поля данных кадров (MTU) всех протоколов канального уровня, используемых в сети. Максимальный размер сегмента не должен превышать минимальное значение на множестве всех MTU составной сети.

Порты и установление TCP-соединений

В протоколе TCP также, как и в UDP, для связи с прикладными процессами используются порты. Номера портам присваиваются аналогичным образом: имеются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 — за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.

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

Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта. Одна оконечная точка может участвовать в нескольких соединениях.

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

• При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).
• После открытия порта протокол TCP на стороне процесса-инициатора посылает запрос процессу, с которым требуется установить соединение.
• Протокол TCP на приемной стороне открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.
• Для того чтобы передача могла вестись в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.
• Сторона-инициатор открывает порт для приема и возвращает квитанцию. Соединение считается установленным. Далее происходит обмен данными в рамках данного соединения.

Концепция квитирования

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

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

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

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

Рис. 6.1. Метод подтверждения корректности передачи кадров с простоем источника

Во втором методе для повышения коэффициента использования линии источнику разрешается передать некоторое количество кадров в непрерывном режиме, то есть в максимально возможном для источника темпе, без получения на эти кадры ответных квитанций. Количество кадров, которые разрешается передавать таким образом, называется размером окна. Рисунок 6.2 иллюстрирует данный метод для размера окна в W кадров. Обычно кадры при обмене нумеруются циклически, от 1 до W. При отправке кадра с номером 1 источнику разрешается передать еще W-1 кадров до получения квитанции на кадр 1. Если же за это время квитанция на кадр 1 так и не пришла, то процесс передачи приостанавливается, и по истечению некоторого тайм-аута кадр 1 считается утерянным (или квитанция на него утеряна) и он передается снова.

Рис. 6.2. Метод "окна" — непрерывная отправка пакетов

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

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

Реализация скользящего окна в протоколе TCP

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

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

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

Выбор тайм-аута

Выбор времени ожидания (тайм-аута) очередной квитанции является важной задачей, результат решения которой влияет на производительность протокола TCP.

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

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

Реакция на перегрузку сети

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

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

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

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

Формат сообщений TCP

Сообщения протокола TCP называются сегментами и состоят из заголовка и блока данных. Заголовок сегмента имеет следующие поля: