Что обеспечивает транспортный протокол

Протокол доставки пользовательских дейтаграмм UDP

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

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

Зарезервированные и дешёвые UDP-порты

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

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

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

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

Назначение номеров портов прикладным процессам осуществляется или централизовано, в случае если эти процессы являются популярные общедоступные сервисы, типа сервиса удаленного доступа к файлам TFTP (Trivial FTP ) либо сервиса удаленного управления telnet, или локально для тех сервисов, каковые еще не стали столь распространенными, дабы за ними закреплять стандартные (зарезервированные) номера.

Централизованное присвоение сервисам номеров портов выполняется организацией Internet Assigned Numbers Authority. Эти номера после этого закрепляются и опубликовываются в стандартах Internet. К примеру, вышеупомянутому сервису удаленного доступа к файлам TFTP присвоен обычный номер порта 69.

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

демультиплексирование и Мультиплексирование запросов протоколом UDP

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

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

Распределение протоколом UDP поступающих от сетевого уровня пакетов между комплектом высокоуровневых сервисов, идентифицированных номерами портов, именуется демультиплексированием.

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

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

Поле source port — номер порта процесса-отправителя.
Поле destination направляться — номер порта процесса-получателя.
Поле message length — протяженность UDP-пакета в байтах.
Поле checksum — контрольная сумма UDP-пакета.

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

Контрольное суммирование

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

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

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

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

Отметим еще, что эти, отправляемые прикладным процессом через модуль UDP. достигают места назначения как единое целое. К примеру, в случае если процесс-отправитель создаёт 5 записей в UDP-порт, то процесс-получатель обязан будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочтённого.

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

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

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

Протокол надежной доставки сообщений TCP

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

Протокол TCP употребляется в тех случаях, в то время, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости применять повторные передачи и таймауты для обеспечения надежности. самые типичными прикладными процессами, применяющими TCP. являются FTP и TELNET. Помимо этого, TCP применяют совокупность X-Window, rcp (remote copy — удаленное копирование) и другие r-команды. Довольно широкие возможности TCP даются не безвозмездно.

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

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

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

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

Порт источника (SOURS PORT) занимает 2 байта, идентифицирует процесс-отправитель;
Порт назначения (DESTINATION PORT) занимает 2 байта, идентифицирует процесс-получатель;
Последовательный номер (SEQUENCE NUMBER) занимает 4 байта, показывает номер байта, определяющий смещение сегмента относительно потока отправляемых данных;
Подтвержденный номер (ACKNOWLEDGEMENT NUMBER) занимает 4 байта, содержит большой номер байта в взятом сегменте, увеличенный на единицу; именно это значение употребляется в качестве квитанции;
Протяженность заголовка (HLEN) занимает 4 бита, показывает длину заголовка сегмента TCP, измеренную в 32-битовых словах. Протяженность заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле Опции ;
Резерв (RESERVED) занимает 6 битов, поле зарезервировано для применения;
Кодовые биты (CODE BITS) занимают 6 битов, содержат служебную данные о типе данного сегмента, задаваемую установкой в единицу соответствующих бит этого поля:

URG — срочное сообщение;
ACK — квитанция на принятый сегмент;
PSH — запрос на отправку сообщения без ожидания заполнения буфера;
RST — запрос на восстановление соединения;
SYN — сообщение применяемое для синхронизации счетчиков переданных данных при установлении соединения;
FIN — показатель успехи передающей стороной последнего байта в потоке передаваемых данных.

Окно (WINDOW) занимает 2 байта, содержит объявляемое значение размера окна в байтах;

Контрольная сумма (CHECKSUM) занимает 2 байта, рассчитывается по сегменту;

Указатель срочности (URGENT POINTER) занимает 2 байта, употребляется совместно с кодовым битом URG, говорит о конце данных, каковые нужно безотлагательно принять, не обращая внимания на переполнение буфера;

Опции (OPTIONS) — это поле имеет переменную длину и может по большому счету отсутствовать, большая величина поля 3 байта; употребляется для ответа запасных задач, к примеру, при выборе большого размера сегмента;

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

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

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

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

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

Большой размер сегмента не должен быть больше минимальное значение на множестве всех MTU составной сети.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.4. Способ подтверждения корректности передачи кадров с простоем источника

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

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

Рис.5. Способ окна — постоянная отправка пакетов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Финансовая жизнь