Протокол tcp работает транспортном уровне. Протоколы передачи данных TCP и UDP
В стеке протоколов TCP/IP протокол TCP (Transmission Control Protocol) работает на транспортном уровне, обеспечивая надежную транспортировку данных между прикладными процессами путем установления логического соединения.
К функциям TCP относят:
Получение и передача потока данных от вышестоящего уровня IP-модулю;
Обеспечение полнодуплексной передачи данных;
Обеспечение защиты от повреждения, потери, дублирования;
Обеспечение работы нескольких соединений;
Управление потоком данных (с помощью механизмов окна)
Формат сообщений TCP
Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, называемая сегментом, состоящая из заголовка и блока данных. Заголовок сегмента имеет следующие поля:
Порт источника (Source Port) и порт назначения (Destination Port) занимают 16 бит. Протокол TCP обеспечивает работу одновременно несколько соединений. Каждый прикладной процесс идентифицируется IP-адресом и номером порта.
|
Destination Port |
|||||||||||
|
Sequence number (SN) |
|||||||||||
|
Acknowledgment number (ASK SN) |
|||||||||||
|
Urgent Pointer |
|||||||||||
Порядковый номер (Sequence number) занимает 32 бита, указывает номер байта, который определяет смещение сегмента относительно потока отправляемых данных;
Подтвержденный номер (Acknowledgment number) занимает 32 бита, содержит максимальный номер байта в полученном сегменте, увеличенный на единицу; т.е все предыдущие байты были получены именно это значение используется в качестве квитанции;
Длина заголовка (Data Offset) занимает 4 бита, указывает длину заголовка сегмента TCP, измеренную в 32-битовых словах. Длина заголовка не фиксирована и может изменяться в зависимости от значений, устанавливаемых в поле Опции. Служит указателем на начало пол данных;
Резерв (Reserved) занимает 6 битов, поле зарезервировано для последующего использования. Заполняется нулями;
Кодовые биты (Control bits) занимают 6 битов, содержат служебную информацию о типе данного сегмента, задаваемую установкой в единицу соответствующих бит этого поля:
URG - срочное сообщение, используется если приложение обращается с запросом о срочной передаче данных. В этом случае протокол TCP, не ожидая заполнения буфера до уровня размера сегмента, немедленно передает указанные данные в сеть. Полученные из сети данные минуя буфер передаются процессу или приложению. Данная технология используется для передачи видео и аудио- данных;
ACK - квитанция на принятый сегмент;
PSH - запрос на отправку сообщения без ожидания заполнения буфера;
RST – сброс текущего соединения (при получении соединение ликвидируется, недопоставленные данные уничтожаются);
SYN - запрос на установление соединения;
FIN - признак достижения передающей стороной последнего байта в потоке передаваемых данных.
Окно (Windows) занимает 16 бит, содержит объявляемое значение размера окна в байтах;
Контрольная сумма (Checksum) занимает 16 бит, определяется для блока данных, состоящего из псевдозаголовка и самого сегмента данных. 96 –битный псевдозаголовок предшествует заголовку TCP и содержит IP-адрес отправителя, получателя, идентификатор протокола и сегмента.
Указатель срочности (Urgent Pointer) занимает 16 бит, используется совместно с кодовым битом URG и указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера;
Опции (Options) - это поле имеет переменную длину и может вообще отсутствовать, используется для решения вспомогательных задач, например, при выборе максимального размера сегмента, или передачи дайджеста MD5;
Заполнитель (Padding) может иметь переменную длину, представляет собой фиктивное поле, используемое для доведения размера заголовка до целого числа 32-битовых слов.
Порты и установление TCP-соединений
Для организации надежной передачи данных предусматривается установление логического соединения между двумя прикладными процессами. В рамках соединения осуществляется обязательное подтверждение правильности приема для всех переданных сообщений, и при необходимости выполняется повторная передача. Соединение в TCP позволяет вести передачу данных одновременно в обе стороны, то есть полнодуплексную передачу.
Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов включающих IP-адрес (номер сети и номер компьютера) и номер порта. Портам присваиваются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 - за TELNET), или произвольно выбранными локальными номерами.
Установление соединения выполняется в следующей последовательности:
1. Узел А посылает узлу В запрос на открытие порта, а также запрос процессу, с которым требуется установить соединение (active open).
2. Узел В открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.
3. Получив квитанцию, узел А открывает порт для передачи (active port) и передает запрос к противоположной стороне.
Соединение по протоколу TCP
Предположим, что узел А устанавливает соединение с узлом В. Для этого:
Узел A в сообщении TCP, посылаемому узлу B устанавливает флаг SYN и начальный порядковый номер ISN с которого будут нумероваться отправляемые данные.
Для подтверждения приема сообщения, узел B откликается посылкой TCP сегмента с установленным флагом ACK. Но вследствие того, что протокол TCP обеспечивает полнодуплексную передачу, узел B может в свою очередь запросить соединение на передачу данных с узлом А посылкой флага SYN и начального порядкового номера своих сообщений ISN.
Узел А, подтверждает получение сообщение от узла В. Так как сеанс связи можно считать установившимся, то узел А может включить свои данные, нумерация которых начинается с ISN (A)+1 в это сообщения.
Происходит передача данных между узлами А и В.
Сеанс обмена данными заканчивается процедурой закрытия, которая в заголовке последнего сегмента использует флаг FIN. Аварийный разрыв соединения происходит посылкой сообщение с битом RST, при этом все недопоставленные данные уничтожаются.
Концепция квитирования
В рамках соединения правильность передачи каждого сегмента должна подтверждаться квитанцией получателя. Квитирование - это один из традиционных методов обеспечения надежной связи. Идея квитирования состоит в следующем.
Для организации повторной передачи искаженных данных отправитель нумерует отправляемые кадры и ожидает от приемника положительную квитанцию - служебное сообщение, извещающее о том, что исходный кадр был получен и данные в нем оказались корректными. Существуют два подхода к организации процесса обмена квитанциями: с простоями и с организацией "окна".
Метод с простоями требует, чтобы узел, посылал очередной кадр, после получения квитанции (положительной или отрицательной) от получателя. Производительность обмена данными в этом методе незначительна, так как передающий узел и мог бы послать следующий кадр сразу же после отправки предыдущего, однако он обязан ждать прихода квитанции, что особенно заметно на низкоскоростных каналах связи, то есть в территориальных сетях.
В методе с организацией "окна" отправителю разрешается передать некоторое количество кадров в непрерывном режиме, без получения на эти кадры ответных квитанций. Количество кадров, которые возможно передать таким образом, называется размером окна W. При отправке кадра с номером 1 отправителю разрешается передать еще (W-1) кадров до получения квитанции на первый кадр. Если квитанция на кадр 1 не получена, то процесс передачи приостанавливается, и по истечению некоторого тайм-аута кадр 1 считается утерянным и передача его осуществляется снова. Выбор времени ожидания (тайм-аута) очередной квитанции является важной задачей, при которой необходимо учитывать скорость и надежность линий связи, их протяженность и т.д. В протоколе TCP при каждой передаче засекается время от момента отправки сегмента до прихода квитанции о его приеме. Получаемые значения усредняются с весовыми коэффициентами, возрастающими от предыдущего замера к последующему. В качестве тайм-аута выбирается среднее время оборота, умноженное на некоторый коэффициент.
Описанный алгоритм называется алгоритмом скользящего окна (при каждом получении квитанции окно перемещается (скользит), захватывая новые данные, которые разрешается передавать без подтверждения).
В протоколе TCP квитанцией (ASK SN) подтверждается правильный прием данных, отсутствие квитанции говорит о приеме искаженного сегмента, потере сегмента или квитанции. В качестве квитанции получатель отсылает сообщение (сегмент), в которое помещает число, на единицу превышающее максимальный номер байта в полученном сегменте. Если размер окна равен W, а последняя квитанция содержала значение n, то отправитель может посылать новые сегменты до тех пор, пока в очередной сегмент не попадет байт с номером n+W. Этот сегмент выходит за рамки окна, и передачу в таком случае необходимо приостановить до прихода следующей квитанции.
Изменяя величину окна, возможно, повлиять на загрузку сети. Чем больше окно, тем большую порцию неподтвержденных данных можно послать в сеть. Если сеть не справляется с нагрузкой, то протокол TCP, отправляя квитанцию, помещает в нее новый, уменьшенный размер окна. Если узел совсем отказывается от приема, то в квитанции указывается окно нулевого размера. После приема квитанции с нулевым значением окна отправитель время от времени делает контрольные попытки продолжить обмен данными. Если протокол-приемник уже готов принимать информацию, то в ответ на контрольный запрос он посылает квитанцию с указанием ненулевого размера окна.
Протокол TCP (TransmissionControlProtocol, протокол управления передачей) представляет собой надежный протокол с установлением соединения, являющийся альтернативой UDP, и отвечающий за большинство передач пользовательских данных по сетям TCP/IP, и даже внесший свой вклад в название всего набора протоколов. Протокол TCP, как определено в документе RFC 793, обеспечивает приложения всем диапазоном транспортных услуг, включая подтверждение получения пакетов, отслеживание ошибок и их исправление, а также управление потоком.
Протокол TCP предназначен для передачи относительно больших объемов информации, которая заведомо не сможет быть упакована в один пакет. Информация обычно принимает форму целых файлов, которые должны быть разделены на множественные дейтаграммы для передачи. Информация, поставляемая Транспортному уровню, в терминологии протокола TCP рассматривается как последовательность (sequence), которую протокол разбивает на сегменты (segment) для передачи по сети. Как и в случае протокола UDP, сегменты затем упаковываются в IP-дейтаграммы, которые могут преодолевать маршрут до места назначения различными способами. Поэтому, протокол TCP снабжает каждый из сегментов порядковым номером для того, чтобы система-получатель смогла собрать их воедино в правильном порядке.
Перед началом любой передачи пользовательских данных с применением протокола TCP две системы обмениваются сообщениями с целью установления соединения. Это позволяет убедиться, что система-получатель функционирует и в состоянии принять данные. Как только соединение установлено и начинается процесс передачи данных, система-получатель периодически посылает сообщения, подтверждающие прием пакетов. Эти сообщения оповещают систему-отправителя о потерянных пакетах, а также обеспечивают ее информацией, используемой при контроле скорости потока передачи.
Формат TCP –сообщения
Функции полей TCP-заголовка описаны ниже.
Порт источника (SourcePort), 2 байта. Идентифицирует номер порта передающей системы, используемый процессом, который создал информацию, переносимую TCP-сегментами. В некоторых случаях это может быть фиктивный номер порта, выделенный клиентом специально для данной транзакции.
Порт назначения (DestinationPort), 2 байта. Указывает номер порта системы назначения, на который должна быть передана информация ТСР-сегментов. Номера портов перечислены в документе "AssignedNumbers", а также в файле SERVICES каждой ТСР/1Р-системы.
Порядковый номер (SequenceNumber), 4 байта. Определяет положение конкретного сегмента по отношению ко всей последовательности данных.
Подтвержденный номер (AcknowledgmentNumber), 4 байта. Задает максимальный номер байта в сегменте, увеличенный на единицу, который подтверждающая система ожидает получить от отправителя. Используется совместно с битом управления АСК.
Смещение данных (DataOffset), 4 бита. Задает длину в 4-байтных словах, TCP-заголовка (который может содержать опции, увеличивающие его размер вплоть до 60 байт).
Зарезервировано (Reserved), 6 битов. Выделено для последующих применений.
Биты управления (ControlBits), 6 битов. Содержит шесть 1-битных флагов, выполняющих перечисленные ниже функции:
URG - показывает, что последовательность содержит срочные данные (urgentdata) и активирует поле указателя срочности;
АСК - отмечает, что сообщение является подтверждением ранее полученных данных и активирует поле номера подтверждения;
PSH - предписывает системе-получателю передать всю информацию текущей последовательности, полученную на данный момент, приложению, идентифицированному полем порта назначения, не дожидаясь поступления остальных фрагментов;
RST - инструктирует систему-получателя отбросить все сегменты текущей последовательности, полученные к настоящему моменту, и начать установление TCP-соединение заново;
SYN - используется во время процедуры установления соединения для синхронизирования нумераторов переданных данных между взаимодействующими системами;
FIN - извещает другую систему, что передача данных закончена и соединение должно быть завершено.
Окно (Window), 2 байта. Реализует механизм управления потоком протокола TCP (скользящее окно) путем объявления количества байтов, которое система-получатель может принять от системы-источника.
Контрольная сумма (Checksum), 2 байта. Содержит результат вычисления контрольной суммы с учетом TCP-заголовка, данных, а также псевдозаголовок, составленный из полей IP-адреса источника, протокола, IP-адреса назначения из IP-заголовка плюс длина всего ТСР-сообщения.
Указатель срочности (UrgentPointer), 2 байта. Задействуется совместно с битом URG, определяет данные последовательности, которые должны рассматриваться получателем как срочные.
Опции (Options), переменный размер. Может содержать дополнительные конфигурационные параметры для TCP-соединения вместе с битами выравнивания, требуемыми для того, чтобы привести размер поля до ближайшего значения, кратного 4 байтам. Возможные опции перечислены ниже.
Максимальный размер сегмента (MaximumSegmentSize). Задает размер максимального сегмента, который текущая система может получить от другой системы, соединенной с ней.
Фактормасштабаокна (Window Scale Factor). Используется для увеличения размера поля окна с 2 до 4 байтов.
Временная отметка (Timestamp). Используется для хранения временных отметок пакетов данных, которые система-получатель возвращает отправителю с целью подтверждения. Это позволяет отправителю измерять время путешествия данных в оба конца.
Данные (Data), переменный размер. Может включать в себя сегменты данных, поступившие с вершины протокольного стека, от протоколов Прикладного уровня. В пакетах SYN, АСК и FIN это поле оставляется пустым.
IPX/SPX: Для обеспечения транспортных услуг для операционной системы NovellNetWare, фирмой Novell был создан свой собственный стек протоколов, получивший общее название по наименованию протокола Сетевого уровня - IPX (InternetworkPacketExchange, межсетевой обмен пакетами). По аналогии с TCP/IP этот стек иногда также называют IPX/SPX. Вторая часть этого обозначения соотносится с SPX (SequencedPacketeXchange, последовательный обмен пакетами), протоколом, работающим на Транспортном уровне. Однако, в отличие от комбинации TCP и IP, которая повсеместно встречается в TCP/IP- сетях и предназначена в основном для доставки большого количества трафика, комплекс IPX/SPX в сетях NetWare можно встретить относительно редко.
Протоколы IPX в нескольких аспектах похожи на TCP/IP. Оба стека протоколов задействуют на Сетевом уровне ненадежные протоколы без установления соединения (IPX и IP соответственно) для переноса дейтаграмм, содержащих данные множества протоколов верхних уровней, что обеспечивает широкий спектр услуг для различных применений. Подобно IP, IPX отвечает за адресацию дейтаграмм и маршрутизацию их к месту назначения в другой сети.
Однако в отличие от TCP/IP протоколы IPX были разработаны для применения в локальных сетях, и не поддерживают той почти неограниченной масштабируемости, свойственной протоколам Интернета. IPX не обладает такой самостоятельной адресной системой, какая имеется у протокола IP. Системы в сети NetWare идентифицируют другие системы посредством аппаратных адресов, "зашитых" в платы сетевых адаптеров в сочетании с адресом сети, назначенным администратором (или ОС) во время инсталляции операционной системы.
Дейтаграммы IPX переносятся внутри стандартных кадров протокола Канального уровня точно так же, как дейтаграммы IP. Протоколы IPX не имеют собственных протоколов Канального уровня. Тем не менее, в большинстве сетей данные IPX инкапсулируются кадрами Ethernet или TokenRing.
Протокол IPX
IPX базируется на протоколе IDP (InternetworkDatagramPacket, межсетевой обмен дейтаграммами), разработанном для сетевых служб Xerox (XNS, XeroxNetworkServices). IPX обеспечивает базовые транспортные услуги без установления соединения между системами интерсети при широковещательной и однонаправленной передаче. Большая часть обычного трафика между серверами NetWare или между клиентами и серверами переносится посредством дейтаграмм IPX.
Заголовок дейтаграммы IPX имеет длину 30 байтов (для сравнения: размер заголовка IP равен 20 байтам). Назначение полей заголовка перечислено ниже.
Контрольная сумма (Checksum), 2 байта. В оригинальном заголовке IDP это поле содержит значение CRC для дейтаграммы. Так как протоколы Канального уровня сами выполняют проверку контрольных сумм, то данная функция при обработке дейтаграмм IPX не задействована и поле всегда содержит шестнадцатеричное значение ffff.
Длина (Length), 2 байта. Задает размер дейтаграммы в байтах, включая заголовок IPX и поле данных.
Управление доставкой (TransportControl), 1 байт. Это поле также известно как счетчик транзитов (hopcount). Оно фиксирует количество маршрутизаторов, через которые прошла дейтаграмма на пути к месту назначения. Передающая система сбрасывает его в 0, а каждый из маршрутизаторов при обработке дейтаграммы увеличивает значение счетчика на 1. Как только количество транзитных маршрутизаторов достигает 16, последний из них отбрасывает дейтаграмму.
Тип пакета (Packet Туре), 1 байт. Идентифицирует сервис или протокол верхнего уровня, который создал данные, переносимые дейтаграммой. Используются следующие значения:
0 - не определен;
1 - RoutingInformationProtocol (RIP, протокол информации маршрутизации);
4 - ServiceAdvertisingProtocol (SAP, протокол извещения об услугах);
5 - SequencedPacketExchange (SPX, последовательный обмен пакетами);
17 - NetWare Core Protocol (NCP, основнойпротокол NetWare).
Адрессетиназначения (Destination Network Address), 4 байта. Указывает сеть, в которой расположена система-получатель, содержит значение, выделенное администратором или операционной системой во время инсталляции NetWare.
Адрес узла назначения (DestinationNodeAddress), 6 байтов. Определяет сетевой интерфейс компьютера, которому должны быть доставлены данные, представляет собой аппаратный адрес протокола Канального уровня. Широковещательные сообщения передаются с шестнадцатеричным адресом ffffffffffff.
Сокет назначения (DestinationSocket), 2 байта. Отвечает за идентификацию процесса, выполняющегося на системе-получателе, для которого, собственно, и предназначены данные внутри дейтаграммы. Используетсяодноизследующихзначений:
0451 - NetWare Core Protocol;
0452 - Service Advertising Protocol;
0453 - Routing Information Protocol;
0455 - NetBIOS;
0456 - диагностический пакет;
0457 - пакет присваивания номера (serializationpacket);
4000-6000 - сокеты, отведенные процессам сервера;
9000 - NetWareLinkServicesProtocol;
9004 - IPXWAN Protocol.
Адрес сети источника (SourceNetworkAddress), 4 байта. Идентифицирует сеть, в которой находится система, пославшая дейтаграмму. Используется значение, выделенное администратором или операционной системой во время инсталляции NetWare.
Адрес узла источника (SourceNodeAddress), 6 байтов. Содержит аппаратный адрес протокола Канального уровня для сетевого интерфейса компьютера, который отправил дейтаграмму.
Сокет источника (SourceSocket), 2 байта. Определяет процесс, выполняющийся на локальной системе, сформировавший данные пакета. Применяются те же значения, что и для поля сокета назначения.
Данные (Data), переменной длины. Информация, сгенерированная протоколом вышележащего уровня.
Поскольку IPX является протоколом без установления соединения, для подтверждения правильности доставленных данных он полагается на протоколы верхних уровней. Тем не менее, клиенты NetWare активируют системные часы таймаута запроса, по истечении которого таймер вынуждает их повторно отправить дейтаграмму IPX, если ответ не был получен в течение заданного периода времени.
TCP (Transmission Control Protocol) – протокол управления передачей. Для обеспечения надежной доставки данных на уровне транспортного протокола в приложениях используется протокол TCP, проверяющий факт доставки данных по сети в нужном порядке. TCP – надежный, потоковый протокол, требующий создания логический соединений. Надежность TCP обеспечивает механизм подтверждения приема с повторной передачей. При использовании данного механизма повторная отправка данных будет происходить до тех пор, пока не получит от системы-адресата подтверждение, что данные были успешно переданы.
Каждый пакет содержит контрольную сумму, посредством которой получатель определяет целостность данных. Если пакет получен в целостности и сохранности, получатель отправляет источнику подтверждение. Поврежденные пакеты просто игнорируются получателем. По истечении определенного интервала времени отправитель снова выполняет передачу пакетов, для которых не были получены подтверждения.
Рассмотрим процесс так называемого “рукопожатия” – установления TCP-соединения. Со стороны клиента отправляется пакет с выставленным флагом SYN – это означает инициализацию TCP-сессии. На данном этапе хостом будет сгенерирован порт источника и порт назначения (порт источника выбирается случайно из диапазона 1024 – 655535). Порт назначения зависит от конкретной службы (http – 80, ftp – 21, pop3 – 110).
При получении пакета сервер, если он не против соединения, посылает ответный пакет с битами SYN, ACK. ACK – означает бит подтверждения. Также в TCP-заголовке сервер генерирует произвольное число Sequence number, а к числу Acknowledgment number прибавляет единицу.
Наконец хост передает пакет, подтверждающий получение данных от сервера, а также непосредственно первый блок данных.
В заголовке протокола TCP содержится поле, которое называется Sequence Number, в которое заносится номер некоторой последовательности. Так же есть поле Acknowledgment Number, которое говорит о подтверждении пакета с этим номером. Числа Sequence Number, Acknowledgment Number применяются для сохранения порядка следования данных. Но если говорить более конкретно, то Sequence Number является точкой отчета для системы нумерации байтов. Из соображений безопасности ISN следует быть случайным числом. Acknowledgment Number служит для подтверждения приема и управления потоком. Подтверждение сообщает источнику, какой объем данных получен и сколько еще данных адресат способен принять. Номер подтверждения – это порядковый номер следующего байта, ожидаемый адресатом.
Поле Windows size (размер окна) – содержит количество байт, которое способен принять адресат. Окно является указанием источнику, что можно продолжать передачу сегментов, если общий объем передаваемых байт меньше байтового окна адресата. Адресат управляет потоком байтов источника, изменяя размер окна. Нулевое окно предписывает отправителю прекратить передачу, пока не будет получено ненулевое значение окна.
Поля Source port, Destination port – порт источника, порт назначения. UGR,
Поля UGR, ACK, PSH, RST, SYN. FIN – управляющие биты:
- UGR – указатель срочности, показывает приоритет TCP-пакетов
- ACK – подтверждение, помечает этот пакет как подтверждение получения
- PSH – выталкивание, выталкивает поставленные в очередь данные из буферов
- RST – сброс, сбрасывает соединение TCP по завершению или после разрыва
- SYN – синхронизация, синхронизирует соединение
- FIN – завершение, завершает передачу данных
На рисунке ниже показан поток данных TCP с нулевым значением исходного порядкового номера. Адресат получил и подтвердил получение 2000 байт, поэтому текущий номер подтверждения ACK = 2001. Кроме того, адресат обладает возможностью принять еще 6000 байт, а поэтому предъявляет окно со значением 6000. Источник отправляет сегмент размером 2000 байт с порядковым номером SN = 4001. Для байтов 2001 и последующих еще не были получены подтверждения, однако источник продолжает передачу данных, пока не исчерпаны ресурсы окна. Если на момент заполнения окна источником для уже отправленных данных не получены подтверждения, по истечению определенного интервала времени источник повторно передает данные, начиная с первого неподтвержденного байта.
Данный метод гарантирует надежность доставки данных адресату. Кроме того, TCP отвечает за доставку полученных от IP данных соответствующему приложению. Приложение, которому предназначаются данные, обозначается 16-битным числом, номером порта. Значения исходный порт и порт назначения находятся в заголовке TCP. Корректный обмен данными с прикладным уровнем – это важная составляющая функциональности служб транспортного уровня.
Процедура закрытия TCP-соединения подразумевает освобождение памяти, выделенной для буферов и переменных, и может происходить по инициативе любой из сторон. Клиентский процесс генерирует команду закрытия соединения, которая приводит к отправке TCP-клиентом специального сегмента. В заголовке этого сегмента флаг FIN установлен в 1. Получив данный сегмент, сервер подтверждает это. Затем сервер отсылает клиенту завершающий сегмент, в котором бит FIN также установлен в 1; в свою очередь, получение этого сегмента подтверждается клиентом. После этого все ресурсы соединения на обеих сторонах освобождаются.
Подписывайтесь на нашу
Всем привет сегодня расскажу чем отличается протокол TCP от UDP. Протоколы транспортного уровня, следующие в иерархии за IP, используются для передачи данных между прикладными процессами, реализующимися в сетевых узлах. Пакет данных, поступивший от одного компьютера другому через Интернет, должен быть передан процессу-обработчику, и именно по конкретному назначению. Транспортный уровень принимает на себя ответственность за это. На этом уровне два основных протокола – TCP и UDP.
Что означают TCP и UDP
TCP – транспортный протокол передачи данных в сетях TCP/IP, предварительно устанавливающий соединение с сетью.
UDP – транспортный протокол, передающий сообщения-датаграммы без необходимости установки соединения в IP-сети.
Напоминаю, что оба протокола работают на транспортном уровне модели OSI или TCP/IP, и понимание того чем они отличаются очень важно.
Разница между протоколами TCP и UDP
Разница между протоколами TCP и UDP – в так называемой “гарантии доставки”. TCP требует отклика от клиента, которому доставлен пакет данных, подтверждения доставки, и для этого ему необходимо установленное заранее соединение. Также протокол TCP считается надежным, тогда как UDP получил даже именование “протокол ненадежных датаграмм. TCP исключает потери данных, дублирование и перемешивание пакетов, задержки. UDP все это допускает, и соединение для работы ему не требуется. Процессы, которым данные передаются по UDP, должны обходиться полученным, даже и с потерями. TCP контролирует загруженность соединения, UDP не контролирует ничего, кроме целостности полученных датаграмм.
С другой стороны, благодаря такой не избирательности и бесконтрольности, UDP доставляет пакеты данных (датаграммы) гораздо быстрее, потому для приложений, которые рассчитаны на широкую пропускную способность и быстрый обмен, UDP можно считать оптимальным протоколом. К таковым относятся сетевые и браузерные игры, а также программы просмотра потокового видео и приложения для видеосвязи (или голосовой): от потери пакета, полной или частичной, ничего не меняется, повторять запрос не обязательно, зато загрузка происходит намного быстрее. Протокол TCP, как более надежный, с успехом применяется даже в почтовых программах, позволяя контролировать не только трафик, но и длину сообщения и скорость обмена трафиком.
Давайте рассмотрим основные отличия tcp от udp.
- TCP гарантирует доставку пакетов данных в неизменных виде, последовательности и без потерь, UDP ничего не гарантирует.
- TCP нумерует пакеты при передаче, а UDP нет
- TCP работает в дуплексном режиме, в одном пакете можно отправлять информацию и подтверждать получение предыдущего пакета.
- TCP требует заранее установленного соединения, UDP соединения не требует, у него это просто поток данных.
- UDP обеспечивает более высокую скорость передачи данных.
- TCP надежнее и осуществляет контроль над процессом обмена данными.
- UDP предпочтительнее для программ, воспроизводящих потоковое видео, видеофонии и телефонии, сетевых игр.
- UPD не содержит функций восстановления данных
Примерами UDP приложений, например можно привести, передачу DNS зон, в Active Directory, там не требуется надежность. Очень часто такие вопросы любят спрашивать на собеседованиях, так, что очень важно знать tcp и udp отличия.
Заголовки TCP и UDP
Давайте рассмотрим как выглядят заголовки двух транспортных протоколов, так как и тут отличия кардинальные.
Заголовок UDP
- 16 битный порт источника > Указание порта источника для UDP необязательно. Если это поле используется, получатель может отправить ответ этому порту.
- 16 битный порт назначения > Номер порта назначения
- 16 битная длина UDP > Длина сообщения, включая заголовок и данные.
- 16 битная контрольная сумма > Контрольная сумма заголовка и данных для проверки
Заголовок TCP
- 16 битный порт источника > Номер порта источника
- 16 битный порт назначения > Номер порта назначения
- 32 битный последовательный номер > Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
- 32 битный номер подтверждения > Если установлен бит АСК поля "Управление", в данном поле содержит следующий ожидаемый последовательный номер.
- 4 бита длина заголовка > Информация о начале пакета данных.
- резерв > Резервируются для будущего использования.
- 16 битная контрольная сумма > Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
- 16 битный указатель срочности > В этом поле целевое устройство получает информацию о срочности данных.
- Параметры > Необязательные значения, которые указываются при необходимости.
Размер окна позволяет экономить трафик, рассмотрим когда его значение равно 1, тут на каждый отправленный ответ, отправитель ждет подтверждения, не совсем рационально.
При размере окна 3, отправитель отправляет уже по 3 кадра, и ждет от 4, который подразумевает, что все три кадра у него есть, +1.
Надеюсь у вас теперь есть представления об отличиях tcp udp протоколов.
На транспортном уровне работают 2 протокола: TCP и UDP.
UDP (User Datagram Protocol) - протокол пользовательских дейтаграмм. Является ненадежным протоколом передачи данных, потому что он не устанавливает и не поддерживает соединения с удаленными узлами. То есть он просто передает данные на нижестоящий уровень и дальнейшая судьба этих данных его не интересует.
Кроме того, он не исправляет ошибки в принятых данных. Если будут обнаружены ошибки, то данные сегменты будут просто уничтожены и без запроса повторной передачи.
Для чего тогда такой протокол нужен?
Он очень полезен там, где передаваемые данные очень критичны к задержкам. Например, при передаче видео и голоса. Там недопустимы задержки, но можно пожертвовать несколькими пакетами в случае обнаружения ошибок - человеческие ухо и глаз не способны заметить потерю нескольких пакетов (если, конечно, число таких пакетов не слишком велико).
Однако для передачи чувствительных данных он совсем не годится, например, при передаче файлов - в данном случае задержки допустимы, но файл должен быть доставлен целостным.
Протокол добавляет следующий заголовок к передаваемым данным
Порт отправителя - идентифицирует приложение прикладного уровня, которое хочет общаться с таким же или другим приложением по сети. Например, Skype использует порт 80. Хотя может использовать и другие порты в зависимости от настроек. То есть, если Алиса пишет сообщение Кате по Skype, то компьютер Кати, приняв сообщение, сможет по номеру порта отправителя определить какое приложение отправило данное сообщение.
Порт получателя
- идентифицирует приложение прикладного уровня, которое принимает сообщения от удаленных узлов. Иными словами, приложение “слушает” сеть на этом порту. Например, тот же Skype может принимать сообщение на порту 80. То есть, если Алиса отправит сообщение Кате на порт 80, то компьютер Кати его примет (при условии, что Skype будет в это время работать). Однако если, Алиса отправит на порт 100, а Катя слушает на порту 80, то компьютер Кати просто cбросит принятое сообщение.
А сколько всего может быть таких портов?
Всего насчитывается 65535 портов. Из них с 0 по 1023 зарезервированы под стандартные приложения, такие как FTP, SMTP, SNMP и другие. Остальные порты с 1024 и по 65535 могут быть использованы для любых других приложений. Эти порты еще называют динамическими, потому что у них нет жесткой привязки к определенному приложению и могут меняться от сеанса к сеансу.
Длина дейтаграммы
- определяет длину всего сегмента, включая и сам заголовок.
Контрольная сумма
- используется для проверки на наличие ошибок.
Как работает проверка?
Способ довольно примитивный. Передающий компьютер вычисляет контрольную сумму всего сегмента по специальному алгоритму и помещает это значение в поле Checksum. Затем принимающий компьютер вычисляет контрольную сумму данного сегмента и сравнивает с суммой в поле Checksum . Если значения совпадают, то сегмент принимается, в противном случае уничтожается.
Ничего, UDP не заботится о дальнейшей судьбе потерянных данных.
TCP (Transmission Control Protocol) - Протокол Управления Передачей. Надежный протокол передачи данных. С помощью него устанавливается и поддерживается связь с удаленными узлами, управляется скорость передачи данных, контролируются ошибки при передаче данных.
Вот как выглядит заголовок сегмента TCP
С некоторыми полями мы уже знакомы. Опишем новые поля.
Порядковый номер
- каждый байт в отправленном сегменте нумеруется для того, чтобы на приеме правильно собрать все сегменты в единый поток. Кроме того, с помощью номера контролируется весь поток данных и исправляются поврежденные сегменты.
Номер подтверждения
- чтобы убедиться, что все переданные сегменты достигли адресата используются номера подтверждения. Например, узел А отправил сегмент с порядковым номером 45 узлу В. Когда узел В примет сегмент с номером 45, то отправит узлу А пустой сегмент с подтверждающим номером 46. Узел А будет знать, что все в порядке и отправит следующий сегмент под номером 46.
Флаги
- специальные знаки-сигналы, указывающие на состояние сессии. Например, запрос на установление соединения или запрос на разрыв соединения.
Размер окна
- определяет количество байт для отправки за один раз. Принимающий узел отправит подтверждение только для последнего байта в сегменте. Таким образом не нужно отправлять подтверждение за каждый байт, экономя тем самым время и канал связи. Например, если размер окна равен 500, то передающий узел сразу же отправит 500 байт данных в сегменте. Принимающий узел, получив все 500 байт, отправит лишь одно подтверждение. Размер окна может меняться в течении всего сеанса связи для регулирования скорости передачи.
А кто устанавливает размер окна?
Оба участника соединения. Например, принимающий узел сообщает передающему узлу размер окна исходя из того, как быстро принимающий узел справляется с поступающими данными. Если он не успевает обработать данные, то уменьшает размер и окна и передающий узел обязан уменьшить объем передаваемых данных.
Чтобы лучше понять назначение всех этих полей рассмотрим принцип работы протокола на примере установления соединения.
Установление соединения (Трехэтапное квитирование)
Процесс установления связи осуществляется в 3 этапа.
Этап 1
Когда сторона А хочет установить связь со стороной В, то сторона А отправляет запрос с установленным флагом SYN. После этого узел А переходит в состояние SYN SENT. Узел В остается в состоянии LISTEN:
Вот какие данные устанавливаются в заголовке TCP (для упрощения восприятия некоторые данные опущены):
Генерируется порядковый номер ISNa = 1 и формируется запрос на установление соединения. Если по истечении таймаута со стороны В не поступает никакого ответа, то узел А снова отправит запрос узлу В.
Этап 2
Когда сторона В принимает запрос SYN, то тоже генерируется порядковый номер ISNb = 200 (в реальности номер может принимать другие значения) для своего сегмента. Для формирования ответа стороне А, узел В устанавливает 2 флага: SYN и ACK. Причем в качестве номера подтверждения берется порядковый номер сегмента стороны А и увеличивается на 1, то есть 1 + 1. Это означает, что запрос успешно принят и ожидается следующий сегмент с номером 2. После того, как сегмент отправлен, узел В переходит в состояние SYN-RECEIVED, узел А остается в состоянии SYN SENT:
Вот как выглядит запрос в сетевом анализаторе:
Если по истечении таймаута от узла А не поступит подтверждения, то узел В снова отправит свой запрос.
Этап 3
После того, как узел А примет сразу 2 флага SYN и ACK, причем ACK будет на 1 больше ISN узла А, то сторона А сразу отправит второй сегмент узлу В. ISN будет увеличен на 1. Флаг будет установлен на ACK со значением ISNb + 1, то есть 200 + 1
Вот какие данные устанавливаются в заголовке TCP:
Вот как выглядит запрос в сетевом анализаторе:
После этого соединение считается успешно установленным, то есть помечается как ESTABLISHED.
Отказ в установлении соединения
Если сторона В по каким-то причинам не может установить соединение со стороной А, то генерируется ответ с флагом RST, которой информирует о прекращении попыток установления связи:
Вот какие данные устанавливаются в заголовке TCP:
Вот как выглядит запрос в сетевом анализаторе:
Завершение связи
Когда одна из сторон желает завершить сеанс связи, то формирует запрос FIN и переходит в состояние FIN_WAIT 1
Сторона В подтверждает запрос отправкой ACK и переходит в состояние CLOSE_WAIT. Сразу же вслед посылается запрос FIN. После этого узел В переходит в состояние LAST_ACK:
Сторона А подтверждает отправкой ACK и переходит в состояние CLOSED. Когда узел В примет ACK, то также перейдет в состояние CLOSED. На этом сеанс связи завершен:
Контроль над искаженными и потерянными данными
Концепция TCP такова, что передатчик ожидает от приемника получение подтверждения успешного принятия байта. Пока передатчик не убедится, что данные успешно доставлены получателю он не будет передавать следующую порцию данных.
Однако подтверждать каждый переданный байт слишком дорогое удовольствие - растет нагрузка на сеть, значительно замедляется работа протокола.
Поэтому передатчик отправляет сразу несколько сегментов и ждет подтверждения от приемника. Приемнику в свою очередь достаточно отправить одно подтверждение на последний полученный сегмент.
Передатчик поймет, что все отправленные сегменты успешно получены и сразу же отправит очередной набор сегментов
Для реализации данного механизма и используются порядковые и подтверждающие номера. Каждый сегмент нумеруется первым байтом полезной нагрузки. Затем приемник посылает подтверждающий сегмент, где указывает номер первого байта следующего сегмента. Например, первый сегмент имеет 100 байт полезной нагрузки (заголовок не учитывается), второй сегмент - 200 байт. Первому байту первого сегмента присваивается номер 1, у первого байта второго сегмента номер соответственно равен 101 (100 + 1) и так далее
Теперь посмотрим как будет проходить передача сегментов
Вот как это выглядит в сетевом анализаторе:
Если сложить ISN = 2155299270 первого сегмента с длиной данных Len = 711, то получится ISN = 2155299981 второго сегмента. Таким способом приемник формирует ACK SN для 3-го сегмента.
С этим разобрались. Но что произойдет, если данные потеряны или искажены в процессе передачи?
Представим, что сегмент дошел до получателя, однако содержит ошибки. Это проверяется с помощью контрольной суммы. Тогда приемник сбросит искаженный сегмент и отправит подтверждение только за предпоследний сегмент. Передатчик поймет, что первые 2 сегмента получены без ошибок и снова отправит 3-й сегмент
Теперь посмотрим, что произойдет, если один сегмент не дойдет до получателя. В данном случае приемник вышлет подтверждение только за принятые сегменты. А о 3-ем сегменте он вообще ничего не знает, поэтому ничего не отправит.
Передатчик будет ждать определенное время и не дождавшись подтверждения за 3-й сегмент отправит его снова
Вот так и достигается контроль над ошибками данных.
Контроль за передачей данными (Метод скользящего окна)
Протокол TCP является дуплексным, то есть может одновременно работать на прием и передачу. Для этого на приеме и передаче устанавливаются буферы.
Передающий буфер содержит переданные, но еще не подтвержденные байты, а также байты готовые для передачи.
Приемный буфер содержит принятые байты для последующей обработки.
Но для чего нужны буферы, разве не может приемник сразу же обработать поступивший сегмент?
Буферы необходимы для постановки в очередь принятые и передаваемые данные, так как производительность приёмной и передающей систем, а также самой сети разные, то велика вероятность, что система не сможет на “лету” обработать большой объем данных.
Мы знаем, что передатчик может сразу отправить несколько сегментов данных, не дожидаясь подтверждения на каждый сегмент.
Но что делать, если передатчик передает данные с большой скоростью, а буфер приемника не успевает их всех вместить?
Тогда приемник просто сбросит новые поступающие данные и отправит подтверждения только на полученные и обработанные сегменты.
Передатчику придется повторно отправлять данные, пока не получит подтверждения успешного получения.
В данной ситуации приемник работает на пределе своих возможностей, а сеть постоянно загружена. Поэтому в TCP предусмотрен механизм контроля за передачей данных с помощью метода скользящего окна.
И как работает данный механизм?
В TCP заголовке имеется поле “Размер окна
(Window size
)”, которое указывает на то, сколько байт приемник способен принять. Иными словами это говорит о доступности буфера и наличии в нем свободного пространства для поступающих данных.
После установления соединения приемник сообщает передатчику размер окна. Например, приемник сообщил, что окно равно 5 байтам. Передатчик передаст 5 байт информации и ждет подтверждения:
В буфере передатчика в очереди на отправку стоят следующие байты, но они не будут отправлены, пока не будут подтверждены уже отправленные байты. Приемник посылает подтверждение и уведомляет о размере окна равным 5, то есть говорит: “В моем буфере есть 5 свободных мест. Пришли мне еще 5 байт.”
Окно в передающем буфере сместится на 5 байт и новая порция данных будет передана приемнику:
Теперь посмотрим, что произойдет, если приемник не успевает обработать все полученные данные и в его буфере свободное место только для 2-х байт:
Передатчик готов передать следующие 5 байт информации, так как получил подтверждение от приемника. Однако приемник также уведомил передатчик, что в приемном буфере свободно только для 2-х байт, то есть сообщает следующее: “Снижай скорость передачи. Готов принять пока 2 байта.”
И передатчик уменьшает окно и передает только 2 байта
В процессе передачи данных размер окна может постоянно меняться. Это зависит от загруженности сети и производительности передатчиков/приемников.
Что происходит, когда в буфере приемника совсем нет места?
Тогда приемник установит размер окна равным 0. Это означает прекратить передачу данных.
Как же передатчик узнает, что буфер приемника снова готов к работе?
После получения нулевого размера окна передатчик запускает специальный таймер, по истечении которого передатчик отправит пробный сегмент. Если буфер свободен, то приемник ответит на этот пробный сегмент и укажет новый размер окна, в противном случае снова укажет нулевое окно.
Итак подведем краткие итоги.
В таблице представлены сравнение протоколов UDP и TCP, а также функции, возложенные на транспортный уровень
| Функции | TCP | UDP |
| Управление потоком | Да | Нет |
| Контроль над ошибками | Да | Нет |
| Скорость | Медленный | Быстрый |
| Установление соединения | Да | Нет |
| Использование в приложениях чувствительных к задержкам данных | Нет (иногда допустимо) | Да |
| Использование в приложениях менее чувствительных к задержкам данных | Да | Да (но не всегда) |
| Регулирование скорости передачи данных | Да | Нет |
| Запрос на повторную передачу потерянного или искаженного сегмента | Да | Нет |
| Многоканальный | Да | Да Назад |
