Какие приложения использует udp выберите несколько ответов

Main next ►

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

1.Функции и услуги транспортного уровня.5

2.Концепция портов. Мультиплексирование и демультиплексирование.7

3.Протокол UDP.10

4.Протокол TCP.12

4.1.Формат TCP-пакета.13

4.2.Сессии TCP (алгоритм установления связи).16

4.3.Алгоритм скользящего окна.18

4.4.Процедура медленный старт.21

Литература.24

Транспортный уровень (TransportLayer) – обеспечивает приложениям или верхним уровням стека – прикладному, представления и сеансовому – передачу данных с той степенью надежности, которая им требуется. Модель OSI определяет пять классов транспортного сервиса от низшего класса 0 до высшего класса 4. Эти виды сервиса отличаются качеством предоставляемых услуг: срочностью, возможностью восстановления прерванной связи, наличием средств мультиплексирования нескольких соединений между различными прикладными протоколами через общий транспортный протокол, а главное – способностью к обнаружению и исправлению ошибок передачи, таких как искажение, потеря и дублирование пакетов.

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

Функции выполняемыетранспортным уровнем:

преобразование транспортного адреса в сетевой;

межоконечное мультиплексирование транспортных соединений в сетевые;

установление и разрывтранспортных соединений;

межоконечное упорядочение блоков данныхпо отдельным соединениям;

межоконечное обнаружение ошибок и необходимый контроль качества услуг;

межоконечное восстановление после ошибок;

межоконечное сегментирование, объединение и сцепление;

межоконечное управление потом данных по отдельным соединениям;

супервизорные функции;

передача срочных транспортных сервисных блоковданных.

Транспортный уровень стека TCP/IP может предоставлять вышележащему уровню два типа сервиса:

гарантированную доставку обеспечивает протоколуправления передачей (TransmissionControlProtocol, TCP);

доставку по возможности, или с максимальными усилиями, обеспечивает протокол пользовательских дейтаграмм (UserDatagramProtocol, UDP).

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

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

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

Как уже было отмечено, главная задача транспортного уровня заключается в передаче данных между прикладными процессами. Эту задачу решают протокол управления передачей(TransmissionControlProtocol, TCP) и протокол пользовательских дейтаграмм (UserDatagramProtocol, UDP). Протоколы TCP и UDP имеют много общего. Тот и другой обеспечивают интерфейс с вышележащим прикладным уровнем, передавая данные, поступающие на входной интерфейс хоста, соответствующему приложению. При этом, оба протокола используют концепции «порт» и «сокет». Оба они также поддерживают интерфейс с нижележащим сетевым уровнем IP, упаковывая свои PDU в IP-пакеты. Однако, как мы увидим далее, различий между TCP и UDP гораздо больше, чем сходств.

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

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

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

Рис. 1. Мультиплексирование и демультиплексирование на транспортном уровне.

Протоколы TCP и UDP ведут для каждого приложения две очереди: очередь пакетов, поступающих к данному приложению из сети, и очередь пакетов, отправляемых данным приложением в сеть. Пакеты, поступающие на транспортный уровень, организуются операционной системой в виде множества очередей к точкам входа различных прикладных процессов. В терминологии TCP/IP такие системные очереди называются портами, причем входная и выходная очереди одного приложения рассматриваются как один порт. Для однозначной идентификации портов им присваивают номера. Номера портов используются для адресации приложений.

Если процессы представляют собой популярные общедоступные службы, такие как FTP, telnet, HTTP, TFTP, DNS и т.п., то за ними закрепляются стандартные, назначенные номера, также называемые хорошо-известными(популярными)(wellknown) номерами портов. Так, номер 21 закреплен за службой удаленного доступа к файлам FTP, а 23 – за службой удаленного управления telnet. Назначенные номера являются уникальными в пределах Интернета и назначаются приложениям централизованно из диапазона от 0 до 1023.

Для тех приложений, которые еще не стали столь распространенными, чтобы закреплять за ними стандартные номера, номера портов назначаются разработчиками этих приложений или операционной системой локально в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему порта. После того как приложение завершит работу, выделенный ему локальный номер порта возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной ситуацией является совпадение номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnetи др.) получают динамические номера портов от ОС.

Все, что было сказано о портах, в равной степени относится к обоим протоколам транспортного уровня (TCPи UDP). В принципе нет никакой зависимости между назначением номеров для приложений, использующих протокол TCP, и приложений, работающих с протоколом UDP. Приложения, которые передают данные на уровень IPпо протоколу UDP, получают номера, называемые UDP-портами. Аналогично приложениям, обращающимся к протоколу TCP, выделяются TCP-порты. В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются TCP— и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65535 для динамических. Однако никакой связи между назначенными номерами TCP— и UDP-портов нет. Даже если номера TCP— и UDP-портов совпадают, они идентифицируют разные приложения. Например, одному приложению может быть назначен TCP-порт 1750, а другому UDP-порт 1750. В некоторых случаях, когда приложение может обращаться по выбору к протоколу TCP или UDP (например, таким приложением является DNS), ему, исходя из удобства запоминания, назначаются совпадающие номераTCP— и UDP-портов (в данном примере – это номер 53).

разговор).

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

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

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

Поля порт источника и порт получателя идентифицируют передающий и получающий процессы.

Поле длина UDPсодержит длину пакета UDP в байтах.

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

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

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

Рис. 4. Структура псевдозаголовка пакета 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 (TransmissionControlProtocol) обеспечивает надежную транспортировку данных между прикладными процессами путем установления логического соединения.

Информация, поступающая к протоколу TCP от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байтов. Поступающие данные буферизируются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом. Сегмент состоит из фиксированного 20-байтного заголовка (плюс необязательная часть), за которой могут следовать байты данных. Размер сегментов определяется программным обеспечением TCP. Оно может объединять в один сегмент данные, полученные в результате нескольких операций записи, или, наоборот, распределять результата одной записи между несколькими сегментами. Размер сегментов ограничен двумя пределами. Во-первых, каждый сегмент, включая TCP-заголовок, должен помещаться 65 515-байтное поле полезной нагрузки IP-пакета. Во-вторых, в каждой сети есть максимальная единица передачи(MTU, MaximumTransferUnit), и каждый сегмент должен помещаться в MTU. На практике размер максимальной единицы передачи составляет обычно 1500 байт (что соответствует размеру поля полезной нагрузки Ethernet), и таким образом определяется верхний предел размера сегмента.

4.1.Формат TCP-пакета

ЗаголовокTCP-сегмента содержит значительно больше полей, чем заголовок UDP, что отражает более развитые возможности первого протокола.

Рис. 5. Формат заголовка сегмента TCP.

Поле порт источника (SourcePort) занимает 2 байта и идентифицирует процесс-отправитель.

Поле порт получателя (DestinationPort) занимает 2 байтаи идентифицирует процесс-получатель.

Поля порядковый номер (SequenceNumber) (длина 4 байта) и номер подтверждения (acknowledgementnumber) (длина 4 байта) нумеруют каждый отправленный или полученный байт данных. Реализуются как целые числа без знака, которые сбрасываются, когда достигают максимального значения. Каждая сторона ведет собственную порядковую нумерацию.

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

Поле резерв (Reserved) занимает 6 бит.

Поле флаги (CodeBits) занимает 6 бит и содержит шесть 1-битовых флагов:

флаг URG (UrgentPointer – указатель точности) устанавливается в 1 в случае использования поля указатель на срочные данные;

флаг ACK (Acknowledgment – подтверждение) устанавливается в 1 в случае, если поле номер подтверждения содержит данные. В противном случае это поле игнорируется;

флаг PSH (Push– выталкивание) означает, что принимающий стек TCP должен немедленно информировать приложение о поступивших данных, а не ждать пока буфер заполнится;

флаг RST (Reset – сброс) используется для отмены соединения: из-за ошибки приложения, отказа от неверного сегмента, попытки создать соединение при отсутствии затребованного сервиса;

флаг SYN (Synchronize– синхронизация) устанавливается при инициировании соединения и синхронизациипорядкового номера;

флаг FIN (Finished – завершение) используется для разрыва соединения. Он указывает, что отправитель закончил передачу данных.

Поле размер окна (Window) (длина 2 байта)содержит количество байт, которое может быть послано после байта, получение которого уже подтверждено.

Поле контрольная сумма (Checksum) (длина 2 байта) служит для повышения надежности. Оно содержит контрольную сумму заголовка, данных и псевдозаголовка, показанного на рис. 7. При выполнении вычислений поле контрольная сумма устанавливается равным нулю, а поле данных дополняется нулевым байтом, если его длина представляет собой нечетное число. Алгоритм вычисления контрольной суммы просто складывает все 16-разрядные слова в дополнительном коде, а затем вычисляет дополнение для всей суммы. В результате, когда получатель считает контрольную сумму всего сегмента, включая поле контрольная сумма, результат дожжен быть равен нулю.

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

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

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

Поле протокол (длина 1 байт) идентифицирует протокол из заголовка пакета IP. Для TCPэто значение равно 6.

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

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

Поле параметры (options) (длина переменная, кратная 32 битам) содержит дополнительные поля, расширяющие возможности стандартного заголовка.

4.2.Сессии TCP (алгоритм установления связи)

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

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

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

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

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

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

Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN (объявление о желании принять соединение) и ACCEPT (блокирование звонящего до получения попытки соединения), либо указывая конкретный источник, либо не указывая его.

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

Когда этот сегмент прибывает в пункт назначения, TCP-сущность проверяет, выполнил ли какой-нибудь процесс примитив LISTEN, указав в качестве параметра тот же порт, который содержится в поле порт получателя. Если такого процесса нет, она отвечает отправкой сегмента с установленным битом RSTдля отказа от соединения.

Рис. 8. Установка TCP-соединения в нормальном случае (а); столкновение вызовов (б).

Если какой-либо процесс прослушивает какой-либо порт, то входящий TCP-сегмент передается этому процессу. Последний может принять соединение или отказаться от него. Если процесс принимает соединение, он отсылает в ответ подтверждение. Последовательность TCP-сегментов, посылаемых в нормальном случае, показана на рис. 8, а. Необходимо обратить внимание на то, что сегмент с установленным битом SYNзанимает 1 байт пространства порядковых номеров, что позволяет избежать неоднозначности в их подтверждениях.

Если два хоста одновременно попытаются установить соединение друг с другом, то последовательность происходящих при этом событий будет соответствовать рис. 8, б. В результате будет установлено только одно соединение, а не два, так как пара конечных точек однозначно определяет соединение. То есть если оба соединения пытаются идентифицировать себя с помощью пары (x, y) делается всего одна табличная запись для (x, y).

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

Логическое TCP-соединение однозначно идентифицируется парой сокетов.

Каждый сокет одновременно может участвовать в нескольких соединениях. Так, если (IP1, n1), (IP2, n2), (IP3, n3) – сокеты трех различных приложений, где IP1, IP2, IP3 – их IP-адреса, а n1, n2, n3 – номера их TCP-портов, то возможно образование следующих соединений:

соединение 1 – {(IP2, n2), (IP1, n1)};

соединение 2 – {(IP1, n1), (IP3, n3)};

соединение 3 – {(IP2, n2), (IP3, n3)}.

4.3.Алгоритм скользящего окна

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

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

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

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

Рис. 10. Порядковый номер и номер квитанции.

В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в которое помещает число(номер подтверждения), на единицу превышающее максимальный номер байта в полученном сегменте. Для сегментов, изображенных на рис. 10, квитанцией о получении (номером подтверждения) служат номера последнего байта каждого сегмента +1. Так для первого отправленного сегмента это будет число 34060, для второго – 36520 и т.д. Номер подтверждения часто интерпретируют как номер следующего ожидаемого байта данных.Квитанция (подтверждение) в протоколе TCPпосылается только в случае правильного приема данных, отрицательные квитанции не посылаются. Таким образом, отсутствие квитанции означает либо потерю сегмента, либо прием искаженного сегмента, либо потерю квитанции.

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

Протокол TCPявляется дуплексным, то есть в рамках одного соединения регламентируется процедураобмена данными в обе стороны. Каждая сторона одновременно выступает и как отправитель, и как получатель. У каждой стороны есть пара буферов: один – для хранения принятых сегментов, другой – для сегментов, которые только еще предстоит отправить. Кроме того, имеется буфер для хранения копий сегментов, которые были отправлены, но квитанции о получении которых еще не поступили.

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

На рис. 11 показан поток байтов, поступающих с верхнего уровня в выходной буфер протокола TCP. Из протокола байтов модуль TCP «нарезает» последовательность сегментов и готовит их для отправки другому сокету. В этом потоке можно указать несколько логических границ.Первая граница отделяет сегменты, которые уже были отправлены и на которые уже пришли квитанции. По другую сторону этой границы располагается окно размером Wбайт. Часть байтов, входящих в окно, составляют сегменты, которые уже были отправлены, но квитанции на них пока не получены. Оставшаяся часть окна – это сегменты, которые пока не отправлены, но могут быть отправлены, так как входят в пределы окна. И наконец, последняя граница указывает на начало последовательности сегментов, ни один из которых не может быть отправлен до тех пор, пока не придет очередная квитанцияи окно не будет сдвинуто вправо.

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

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

4.4.Процедура«медленный старт»

Когда в какую-либо сеть поступает больше данных, чем она способна обработать, в сети образуются заторы. Интернет в этом смысле не является исключением. Поэтому здесь мы рассмотрим алгоритм, разработанный для борьбы с перегрузкой сети. Решение, применяемое в Интернете, состоит в признании существования двух потенциальных проблем: низкой пропускной способности сети и низкой емкости получателя – и в раздельном решении обеих проблем. Для этого у каждого отправителя есть два окна: окно, предоставленное получателем, и окно перегрузки. Размер каждого из них соответствует количеству байтов, которое отправитель имеет право передать. Отправитель руководствуется минимальным из этих двух значений. Например, получатель говорит: «Посылайте мне 8 Кбайт»,но отправитель знает, что если он пошлет более 4 Кбайт, то в сети образуется затор, поэтому он посылает все же 4 Кбайта. Если же отправитель знает, что сеть способна пропустить и большее количество данных, например 32Кбайта, он передаст столько, сколько просит получатель (то есть 8 Кбайт).

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

Этот процесс экспоненциального роста продолжается до тех пор, пока не будет достигнут размер окна получателя или не будет выработан признак тайм-аута, сигнализирующий о перегрузке сети. Например, если пакеты размером 1024, 2048 и 4096 байт дошли до получателя успешно, а в ответ на передачу пакета размером 8192 байта подтверждение не пришло в установленный срок, окно перегрузки устанавливается равным 4096 байтам. Пока размер окна перегрузки остается равным 4096 байтам, более длинные пакеты не посылаются, независимо от размера окна, предоставляемого получателем. Этот алгоритм называется «медленным стартом».

1.Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы: Учебник для вузов. 3-е изд. – СПб.: Питер, 2006. – 958 с.

2.Самуйлов К. Е., Кулябов Д. С., Учебно-методическое пособие по курсу «Сети и системы телекоммуникаций». – М.: Издательство РУДН, 2005. – 55 с.

3.Таненбаум Э. Компьютерные сети. 4-е изд. – СПб.: Питер, 2003. – 992 с.

Main next ►

Источник

Поделиться:
Нет комментариев

Добавить комментарий

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.

×
Вам будет интересно