Что такое флаги в протоколе тсп. Трехэтапное Квитирование TCP - Флаги SYN и ACK. Рис. Формат заголовка TCP-пакета

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

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

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

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

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

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

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

Хотя TCP-соединения являются полнодуплексными, чтобы понять, как происходит их разъединение, лучше считать их парами симплексных соединений. Каждое симплексное соединение разрывается независимо от своего напарника. Чтобы разорвать соединение, любая из сторон может послать TCP-сегмент с установленным в единицу битом FIN, что означает, что у него больше нет данных для передачи. Когда этот TCP-сегмент получает подтверждение, это направление передачи закрывается. Тем не менее, данные могут продолжать передаваться неопределенно долго в противоположном направлении. Соединение разрывается, когда оба направления закрываются. Обычно для разрыва соединения требуются четыре TCP-сегмента: по одному с битом FIN и по одному с битом АСК в каждом направлении. Первый бит АСК и второй бит FIN могут также содержаться в одном ТСР-сегменте, что уменьшит количество сегментов до трех.

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

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

Управление передачей в TCP

Как уже было сказано ранее, управление окном в TCP не привязано напрямую к подтверждениям, как это сделано в большинстве протоколов передачи данных. Например, предположим, что у получателя есть 4096-байтовый буфер. Если отправитель передает 2048-байтовый сегмент, который успешно принимается получателем, то получатель подтверждает его получение. Однако при этом у получателя остается всего лишь 2048 байт свободного буферного пространства (пока приложение не заберет сколько-нибудь данных из буфера), о чем он и сообщает отправителю, указывая соответствующий размер окна (2048) и номер следующего ожидаемого байта.

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

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

Отправители не обязаны передавать данные сразу, как только они приходят от приложения. Также никто не требует от получателей посылать подтвержде­ния как можно скорее. Например TCP-сущность, получив от прило­жения первые 2 Кбайт данных и зная, что доступный размер окна равен 4 Кбайт, была бы совершенно права, если бы просто сохранила полученные данные в буфере до тех пор, пока не прибудут еще 2 Кбайт данных, чтобы передать сразу сегмент с 4 Кбайт полезной нагрузки. Эта свобода действий может использоваться для улучшения производительности.

Рассмотрим TELNET-соединение с интерактивным редактором, реагирующим на каждое нажатие клавиши. В худшем случае, когда символ прибывает к передающей TCP-сущности, она создает 21-байтовый TCP-сегмент и передает его IP-уровню, который, в свою очередь, посылает 41-байтовую IP-дейтаграмму.

На принимающей стороне TCP-сущность немедленно отвечает 40-байтовым подтверждением (20 байт TCP-заголовка и 20 байт IP-заголовка). Затем, когда редактор прочитает этот байт из буфера, TCP-сущность пошлет обновленную информацию о размере буфера, передвинув окно на 1 байт вправо. Размер этого пакета также составляет 40 байт. Наконец, когда редактор обработает этот символ, он отправляет обратно эхо, передаваемое 41-байтовым пакетом. Итого для каждого введенного с клавиатуры символа пересылается четыре пакета общим размером 162 байта. В условиях дефицита пропускной способности линий этот метод работы нежелателен.

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

Хотя такой метод задержки и снижает нагрузку на сеть, тем не менее, эффективность использования сети отправителем продолжает оставаться невысокой, так как каждый байт пересылается в отдельном 41-байтовом пакете. Метод, позволяющий повысить эффективность, известен как алгоритм Нагля (Nagle, 1984). Предложение Нагля звучит довольно просто: если данные поступают отправителю по одному байту, отправитель просто передает первый байт, а остальные помещает в буфер, пока не будет получено подтверждение приема первого байта. После этого можно переслать все накопленные в буфере символы в виде одного TCP-сегмента и снова начать буферизацию до получения подтверждения отосланных символов. Если пользователь вводит символы быстро, а сеть медленная, то в каждом сегменте будет передаваться значительное количество символов, таким образом, нагрузка на сеть будет существенно снижена. Кроме того, этот алгоритм позволяет посылать новый пакет, даже если число символов в буфере превышает половину размера окна или максимальный размер сегмента.

Алгоритм Нагля широко применяется различными реализациями протокола TCP, однако иногда бывают ситуации, в которых его лучше отключить. В частности, при работе приложения X-Windows в Интернете информация о перемещениях мыши пересылается на удаленный компьютер. (X-Window - это система управления окнами в большинстве ОС типа UNIX). Если буферизировать эти данные для пакетной пересылки, курсор будет перемещаться рывками с большими паузами, в результате чего пользоваться программой будет очень сложно, почти невозможно.

Еще одна проблема, способная значительно снизить производительность протокола TCP, известна под именем синдрома глупого окна (Clark, 1982). Суть проблемы состоит в том, что данные пересылаются TCP-сущностью крупными блоками, но принимающая сторона интерактивного приложения считывает их посимвольно.

Рассмотрим на примере - начальное состояние таково: TCP-буфер приемной стороны полон, и отправителю это известно (то есть размер его окна равен 0). Затем интерактивное приложение читает один символ из TCP-потока. Принимающая TCP-сущность радостно сообщает отправителю, что размер окна увеличился, и что он теперь может послать 1 байт. Отправитель повинуется и посылает 1 байт. Буфер снова оказывается полон, о чем получатель и извещает, посылая подтверждение для 1-байтового сегмента с нулевым размером окна. И так может продолжаться вечно.

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

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

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

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

Еще одна проблема получателя состоит в сегментах, полученных в неправильном порядке. Они могут храниться или отвергаться по усмотрению получателя. Разумеется, подтверждение может быть выслано, только если все данные вплоть до подтверждаемого байта получены. Если до получателя доходят сегменты О, 1, 2, 4, 5, 6 и 7, он может подтвердить получение данных вплоть до последнего байта сегмента 2. Когда у отправителя истечет время ожидания, он передаст сегмент 3 еще раз. Если к моменту прибытия сегмента 3 получатель сохранит в буфере сегменты с 4-го по 7-й, он сможет подтвердить получение всех байтов, вплоть до последнего байта сегмента 7.

Заголовок UDP всегда имеет длину 64 бита. Поля, определённые в сегменте UDP (см. рисунок) включают следующие:
1. Порт отправителя (Source port): номер порта источника(16 бит)
2. Порт получателя (Destination port): номер порта назначения (16 бит)
3. Длина сообщения (Length): длина заголовка UDP и данных UDP (16 бит)
4. Контрольная сумма (Checksum): вычисленная контрольная сумма полей заголовка и данных (16 бит)
5. Данные (Data): данные протокола вышележащего уровня (upper-layer protocol — ULP) (переменная длина)
Примеры протоколов, которые используют UDP: TFTP, SNMP, Network File System (NFS) и Domain Name System (DNS).

Заголовок TCP содержит информацию, которая определена TCP протоколом. В данном разделе описаны компоненты заголовка TCP.

Сегменты TCP передаются с помощью использования пакетов IP. Заголовок TCP следует за заголовком IP,. Это разделение допускает существование других протоколов на уровне хоста, отличных от TCP. Поля TCP заголовка включают следующие:

Порт отправителя (Source port): номер порта источника (16 бит)

Порт получателя (Destination port): номер порта назначения (16 бит)

Порядковый номер (Sequence number): порядковый номер первого октета данных
сегмента, используемый для гарантии правильного упорядочения приходящих данных
(32 бита)

Номер подтверждения (Acknowledgment number): следующий ожидаемый октет
TCP (32 бита)

Длина заголовка (Header length): количество 32-битных слов в заголовке (4 бита)

Зарезервировано (Reserved): установлено в 0 (3 бита)

Управляющие биты (Control bits): функции управления — такие как установка,
перегрузка и разрыв сеанса (9 бит). Одиночный бит, который имеет специальное
значение, часто рассматриваемое как флаг.

Окно (Window): число октетов, которое устройство согласно принять (16 бит)

Контрольная сумма (Checksum): вычисленная контрольная сумма полей заголовка и
данных (16 бит)

Указатель срочности данных (Urgent): показывает конец срочных данных (16 бит)

Опции (Options): в настоящее время определена одна опция — максимальный размер
сегмента TCP (0 или 32 бита)

Данные (Data): данные протокола вышележащего уровня (upper-layer protocol — ULP)
(переменная длина)

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

Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копирование) и другие "r-команды". Большие возможности TCP даются не бесплатно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP.

Реализация TCP, как правило, встроена в ядро системы, хотя есть и реализации TCP в контексте приложения.

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

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

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

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

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

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

Пользовательский интерфейс с TCP может выполнять такие команды как открыть (OPEN) или закрыть соединение (CLOSE), отправить (SEND) или принять (RECEIVE) данные, а также получить состояние соединения (STATUS).

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

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

Краткое описание протоколов семейства TCP/IP с расшифровкой аббревиатур

• ARP (Address Resolution Protocol, протокол определения адресов) : конвертирует 32-разрядные IP-адреса в физические адреса вычислительной сети, например, в 48-разрядные адреса Ethernet.

• FTP (File Transfer Protocol, протокол передачи файлов) : позволяет передавать файлы с одного компьютера на другой с использованием TCP-соединений. В родственном ему, но менее распространенном протоколе передачи файлов - Trivial File Transfer Protocol (TFTP) - для пересылки файлов применяется UDP, а не TCP.

• ICMP (Internet Control Message Protocol, протокол управляющих сообщений Internet) : позволяет IP-маршрутизаторам посылать сообщения об ошибках и управляющую информацию другим IP-маршрутизаторам и главным компьютерам сети. ICMP-сообщения "путешествуют" в виде полей данных IP-дейтаграмм и обязательно должны реализовываться во всех вариантах IP.

• IGMP (Internet Group Management Protocol, протокол управления группами Internet) : позволяет IP-дейтаграммам распространяться в циркулярном режиме (multicast) среди компьютеров, которые принадлежат к соответствующим группам.

• IP (Internet Protocol, протокол Internet) : низкоуровневый протокол, который направляет пакеты данных по отдельным сетям, связанным вместе с помощью маршрутизаторов для формирования Internet или интрасети. Данные "путешествуют" в форме пакетов, называемых IP-дейтаграммами.

• RARP (Reverse Address Resolution Protocol, протокол обратного преобразования адресов) : преобразует физические сетевые адреса в IP-адреса.

• SMTP (Simple Mail Transfer Protocol, простой протокол обмена электронной почтой) : определяет формат сообщений, которые SMTP-клиент, работающий на одном компьютере, может использовать для пересылки электронной почты на SMTP-сервер, запущенный на другом компьютере.

• TCP (Transmission Control Protocol, протокол управления передачей) : протокол ориентирован на работу с подключениями и передает данные в виде потоков байтов. Данные пересылаются пакетами - TCP-сегментами, - которые состоят из заголовков TCP и данных. TCP - "надежный" протокол, потому что в нем используются контрольные суммы для проверки целостности данных и отправка подтверждений, чтобы гарантировать, что переданные данные приняты без искажений.

• UDP (User Datagram Protocol, протокол пользовательских дейтаграмм) : протокол, не зависящий от подключений, который передает данные пакетами, называемыми UDP-дейтаграммами. UDP - "ненадежный" протокол, поскольку отправитель не получает информацию, показывающую, была ли в действительности принята дейтаграмма.

Состав и предназначение полей заголовка

ТСР-сегменты отправляются как IP-дейтаграммы. Заголовок TCP, следующий за IP-заголовком, содержит информацию TCP-протокола.

Source Port (16 бит). Порт отправителя.

Destination Port (16 бит). Порт получателя.

Sequence Number (32 бита). Номер кадра. Номер кадра первого октета данных в этом сегменте (за исключением пакета, где присутствует флаг SYN). Если в пакете присутствует флаг SYN, то номер данного пакета становится номером начала последовательности (ISN) и номером первого октета данных становится номер ISN+1.

Acknowledgment Number (32 бита). Поле номера кадра подтвержденного получения. Если пакет содержит установленный контрольный бит АСК, то это поле содержит номер следующего пакета данных отправителя, который ожидает получатель. При установленном соединении пакет подтверждения отправляется всегда.

Data Offset (4 бита). Поле величины смещения данных. Оно содержит количество 32-битных слов заголовка TCP-пакета. Это число определяет смещение расположения данных в пакете.

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

Флаги управления (слева направо):

• URG: Флаг срочности

• АСК: Флаг пакета, содержащего подтверждение получения

• PSH: Флаг форсированной отправки

• RST: Переустановка соединения

• SYN: Синхронизация чисел последовательности

• FIN: Флаг окончания передачи со стороны отправителя

Window (16 бит). Окно. Это поле содержит количество байт данных, которое отправитель данного сегмента может принять, отсчитанное от номера байта, указанного в поле Acknowledgment Number.

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

Urgent Pointer (16 бит). Поле указателя срочных данных. Это поле содержит значение счетчика пакетов, начиная с которого следуют пакеты повышенной срочности. Это поле принимается во внимание только в сегментах с установленным флагом URG.

Options. Поле дополнительных параметров: может быть переменной длины.

Padding. Заполнение: переменная длина. Заполнение (нулями) TCP-заголовка используется для выравнивания его по 32-битному слову.

Хотя есть и реализации TCP в контексте приложения.

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

Заголовок сегмента TCP

Порт источника

Номер последовательности

Номер последовательности выполняет две задачи:

1. Если установлен флаг SYN, то это начальное значение номера последовательности - ISN (Initial Sequence Number), и первый байт данных, которые будут переданы в следующем пакете, будет иметь номер последовательности, равный ISN + 1.
2. В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот номер последовательности.

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

Номер подтверждения

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

Смещение данных

Это поле определяет размер заголовка пакета TCP в 4-байтных (4-октетных) словах. Минимальный размер составляет 5 слов, а максимальный - 15, что составляет 20 и 60 байт соответственно. Смещение считается от начала заголовка TCP.

Зарезервировано

Зарезервировано (6 бит) для будущего использования и должно устанавливаться в ноль. Из них два (5-й и 6-й) уже определены:

• CWR (Congestion Window Reduced) - Поле «Окно перегрузки уменьшено» - флаг установлен отправителем, чтоб указать, что получен пакет с установленным флагом ECE (RFC 3168)
• ECE (ECN-Echo) - Поле «Эхо ECN» - указывает, что данный узел способен на ECN (явное уведомление перегрузки) и для указания отправителю о перегрузках в сети (RFC 3168)

Флаги (управляющие биты)

Это поле содержит 6 битовых флагов:

• URG - Поле «Указатель важности» задействовано (англ. Urgent pointer field is significant )
• ACK - Поле «Номер подтверждения» задействовано (англ. Acknowledgement field is significant )
• PSH - (англ. Push function ) инструктирует получателя протолкнуть данные, накопившиеся в приемном буфере, в приложение пользователя
• RST - Оборвать соединения, сбросить буфер (очистка буфера) (англ. Reset the connection )
• SYN - Синхронизация номеров последовательности (англ. Synchronize sequence numbers )
• FIN (англ. final , бит) - флаг, будучи установлен, указывает на завершение соединения (англ. FIN bit used for connection termination ).

Окно

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

Псевдозаголовок

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

TCP-псевдозаголовок IPv4

TCP-псевдозаголовок IPv6

• Протокол (Protocol)/Протокол верхнего уровня (Next header) - содержит в себе значение 6 (000000110 в двоичном виде, 0x6 - в шестнадцатеричном) - идентификатор TCP-протокола.
• Длина TCP-сегмента (TCP length) - содержит в себе длину TCP-сегмента в байтах (TCP-заголовок + данные; длина псевдозаголовка не учитывается).

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

Контрольная сумма

Поле контрольной суммы - это 16-битное дополнение к сумме всех 16-битных слов заголовка(включая псевдозаголовок) и данных. Если сегмент, по которому вычисляется контрольная сумма, имеет длину не кратную 16-ти битам, то длина сегмента увеличивается до кратной 16-ти, за счет дополнения к нему справа нулевых битов заполнения. Биты заполнения (0) не передаются в сообщении и служат только для расчёта контрольной суммы. При расчёте контрольной суммы значение самого поля контрольной суммы принимается равным 0.

Указатель важности

16-битовое значение положительного смещения от порядкового номера в данном сегменте. Это поле указывает порядковый номер октета, которым заканчиваются важные (urgent) данные. Поле принимается во внимание только для пакетов с установленным флагом URG.

Опции

Могут применяться в некоторых случаях для расширения протокола. Иногда используются для тестирования. На данный момент в опции практически всегда включают 2 байта NOP (в данном случае 0x01) и 10 байт, задающих timestamps . Вычислить длину поля опции можно через значение поля смещения.

Механизм действия протокола

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

• Установка соединения
• Передача данных
• Завершение соединения

Состояния сеанса TCP

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

Процесс начала сеанса TCP - обозначаемое как "рукопожатие" (handshake), состоит из 3 шагов.

1. Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN.

• Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буферы и управляющие структуры памяти) для обслуживания нового клиента.
  • В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED.
  • В случае неудачи сервер посылает клиенту сегмент с флагом RST.

2. Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK.

• Если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED.
• Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.
• Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.

3. Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED.

• В противном случае после тайм-аута он закрывает сокет и переходит в состояние CLOSED.

Процесс называется "трехэтапным согласованием" ("three way handshake"), так как несмотря на то что возможен процесс установления соединения с использованием 4 сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется 3 сегмента.

Пример базового 3-этапного согласования:

TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> --> SYN-RECEIVED 3. ESTABLISHED <-- <-- SYN-RECEIVED 4. ESTABLISHED --> --> ESTABLISHED 5. ESTABLISHED <-- <-- ESTABLISHED

В строке 2 TCP A начинает передачу сегмента SYN, говорящего об использовании номеров последовательности, начиная со 100. В строке 3 TCP B передает SYN и подтверждение для принятого SYN в адрес TCP A. Надо отметить, что поле подтверждения показывает ожидание TCP B приема номера последовательности 101, подтверждающего SYN с номером 100.

В строке 4 TCP A отвечает пустым сегментом с подтверждением ACK для сегмента SYN от TCP B; в строке 5 TCP B передает некоторые данные. Отметим, что номер последовательности сегмента в строке 5 совпадает с номером в строке 4, поскольку ACK не занимает пространства номеров последовательности (если это сделать, придется подтверждать подтверждения - ACK для ACK!).

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

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

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

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

Завершение соединения

Завершение соединения можно рассмотреть в три этапа:

1. Посылка серверу от клиента флагов FIN и ACK на завершение соединения.
2. Сервер посылает клиенту флаги ответа ACK , FIN, что соединение закрыто.
3. После получения этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK , что соединение закрыто.

Известные проблемы

Максимальный размер сегмента

TCP требует явного указания максимального размера сегмента (MSS) в случае, если виртуальное соединение осуществляется через сегмент сети, где максимальный размер блока (MTU) менее, чем стандартный MTU Ethernet (1500 байт).

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

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

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

MSS может также управляться параметрами операционной системы.

Обнаружение ошибок при передаче данных

Хотя протокол осуществляет проверку контрольной суммы по каждому сегменту, используемый алгоритм считается слабым . Так в 2008 году не обнаруженная сетевыми средствами ошибка в передаче одного бита, привела к остановке серверов системы Amazon Web Services .

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

Атаки на протокол

Основная статья: Атаки на TCP

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

Реализация

Освобождение от расчёта контрольной суммы

Многие реализации стека TCP/IP предоставляют возможности использования аппаратной поддержки для автоматического расчёта контрольной суммы в сетевом адаптере до передачи в сеть или после приёма из сети для верификации. Это может освобождать операционную систему от использования ценных тактов процессора при вычислении контрольной суммы.

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

См. также

Ссылки

• RFC 793 - Transmission Control Protocol

Литература

• Терри Оглтри. Модернизация и ремонт сетей = Upgrading and Repairing Networks. - 4-е изд. - М .: «Вильямс», 2005. - С. 1328. - ISBN 0-7897-2817-6
• Дуглас Камер. Сети TCP/IP, том 1. Принципы, протоколы и структура = Internetworking with TCP/IP, Vol. 1: Principles, Protocols and Architecture. - М .: «Вильямс», 2003. - С. 880. - ISBN 0-13-018380-6

• Андрей Робачевский, Сергей Немнюгин, Ольга Стесик. Операционная система UNIX. - 2-е изд. - "БХВ-Петербург", 2007. - С. 656. -

Большинство из нас знает TCP/IP как "клей", связующий Internet. Но не многие способны дать убедительное описание того, что этот протокол представляет собой и как работает. Итак, что же такое TCP/IP в действительности?

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

Понимание TCP/IP главным образом подразумевает способность разбираться в наборах таинственных протоколов, которые используются главными компьютерами TCP/IP для обмена информацией. Давайте рассмотрим некоторые из этих протоколов и выясним, что составляет оболочку TCP/IP.
Основы TCP/IP
TCP/IP - это аббревиатура термина Transmission Control Protocol/Internet Protocol (Протокол управления передачей/Протокол Internet). В терминологии вычислительных сетей протокол - это заранее согласованный стандарт, который позволяет двум компьютерам обмениваться данными. Фактически TCP/IP не один протокол, а несколько. Именно поэтому вы часто слышите, как его называют набором, или комплектом протоколов, среди которых TCP и IP - два основных.

Программное обеспечение для TCP/IP, на вашем компьютере, представляет собой специфичную для данной платформы реализацию TCP, IP и других членов семейства TCP/IP. Обычно в нем также имеются такие высокоуровневые прикладные программы, как FTP (File Transfer Protocol, Протокол передачи файлов), которые дают возможность через командную строку управлять обменом файлами по Сети.

TCP/IP - зародился в результате исследований, профинансированных Управлением перспективных научно-исследовательских разработок (Advanced Research Project Agency, ARPA) правительства США в 1970-х годах. Этот протокол был разработан с тем, чтобы вычислительные сети исследовательских центров во всем мире могли быть объединены в форме виртуальной "сети сетей" (internetwork). Первоначальная Internet была создана в результате преобразования существующего конгломерата вычислительных сетей, носивших название ARPAnet, с помощью TCP/IP.

Причина, по которой TCP/IP столь важен сегодня, заключается в том, что он позволяет самостоятельным сетям подключаться к Internet или объединяться для создания частных интрасетей. Вычислительные сети, составляющие интрасеть, физически подключаются через устройства, называемые маршрутизаторами или IP-маршрутизаторами. Маршрутизатор - это компьютер, который передает пакеты данных из одной сети в другую. В интрасети, работающей на основе TCP/IP, информация передается в виде дискретных блоков, называемых IP-пакетами (IP packets) или IP-дейтаграммами (IP datagrams). Благодаря программному обеспечению TCP/IP все компьютеры, подключенные к вычислительной сети, становятся "близкими родственниками". По существу оно скрывает маршрутизаторы и базовую архитектуру сетей и делает так, что все это выглядит как одна большая сеть. Точно так же, как подключения к сети Ethernet распознаются по 48-разрядным идентификаторам Ethernet, подключения к интрасети идентифицируются 32-разрядными IP-адресами, которые мы выражаем в форме десятичных чисел, разделенных точками (например, 128.10.2.3). Взяв IP-адрес удаленного компьютера, компьютер в интрасети или в Internet может отправить данные на него, как будто они составляют часть одной и той же физической сети.

TCP/IP дает решение проблемы данными между двумя компьютерами, подключенными к одной и той же интрасети, но принадлежащими различным физическим сетям. Решение состоит из нескольких частей, причем каждый член семейства протоколов TCP/IP вносит свою лепту в общее дело. IP - самый фундаментальный протокол из комплекта TCP/IP - передает IP-дейтаграммы по интрасети и выполняет важную функцию, называемую маршрутизацией, по сути дела это выбор маршрута, по которому дейтаграмма будет следовать из пункта А в пункт B, и использование маршрутизаторов для "прыжков" между сетями.

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

Другой важный член комплекта TCP/IP - User Datagram Protocol (UDP, протокол пользовательских дейтаграмм), который похож на TCP, но более примитивен. TCP - "надежный" протокол, потому что он обеспечивает проверку на наличие ошибок и обмен подтверждающими сообщениями чтобы данные достигали своего места назначения заведомо без искажений. UDP - "ненадежный" протокол, ибо не гарантирует, что дейтаграммы будут приходить в том порядке, в котором были посланы, и даже того, что они придут вообще. Если надежность - желательное условие, для его реализации потребуется программное обеспечение. Но UDP по-прежнему занимает свое место в мире TCP/IP, и испльзуется во многих программах. Прикладная программа SNMP (Simple Network Management Protocol, простой протокол управления сетями), реализуемый во многих воплощениях TCP/IP, - это один из примеров программ UDP.

Другие TCP/IP протоколы играют менее заметные, но в равной степени важные роли в работе сетей TCP/IP. Например, протокол определения адресов (Address Resolution Protocol, ARP) ппреобразует IP-адреса в физические сетевые адреса, такие, как идентификаторы Ethernet. Родственный протокол - протокол обратного преобразования адресов (Reverse Address Resolution Protocol, RARP) - выполняет обеспечивает обратное действие, преобразуя физические сетевые адреса в IP-адреса. Протокол управления сообщениями Internet (Internet Control Message Protocol, ICMP) представляет собой протокол сопровождения, который использует IP для обмена управляющей информацией и контроля над ошибками, относящимися к передаче пакетов IP. Например, если маршрутизатор не может передать IP-дейтаграмму, он использует ICMP, с тем чтобы информировать отправителя, что возникла проблема. Краткое описание некоторых других протоколов, которые "прячутся под зонтиком" TCP/IP, приведено во врезке.
Краткое описание протоколов семейства TCP/IP с расшифровкой аббревиатур
ARP (Address Resolution Protocol, протокол определения адресов): конвертирует 32-разрядные IP-адреса в физические адреса вычислительной сети, например, в 48-разрядные адреса Ethernet.

FTP (File Transfer Protocol, протокол передачи файлов): позволяет передавать файлы с одного компьютера на другой с использованием TCP-соединений. В родственном ему, но менее распространенном протоколе передачи файлов - Trivial File Transfer Protocol (TFTP) - для пересылки файлов применяется UDP, а не TCP.

ICMP (Internet Control Message Protocol, протокол управляющих сообщений Internet): позволяет IP-маршрутизаторам посылать сообщения об ошибках и управляющую информацию другим IP-маршрутизаторам и главным компьютерам сети. ICMP-сообщения "путешествуют" в виде полей данных IP-дейтаграмм и обязательно должны реализовываться во всех вариантах IP.

IGMP (Internet Group Management Protocol, протокол управления группами Internet): позволяет IP-дейтаграммам распространяться в циркулярном режиме (multicast) среди компьютеров, которые принадлежат к соответствующим группам.

IP (Internet Protocol, протокол Internet): низкоуровневый протокол, который направляет пакеты данных по отдельным сетям, связанным вместе с помощью маршрутизаторов для формирования Internet или интрасети. Данные "путешествуют" в форме пакетов, называемых IP-дейтаграммами.

RARP (Reverse Address Resolution Protocol, протокол обратного преобразования адресов): преобразует физические сетевые адреса в IP-адреса.

SMTP (Simple Mail Transfer Protocol, простой протокол обмена электронной почтой): определяет формат сообщений, которые SMTP-клиент, работающий на одном компьютере, может использовать для пересылки электронной почты на SMTP-сервер, запущенный на другом компьютере.

TCP (Transmission Control Protocol, протокол управления передачей): протокол ориентирован на работу с подключениями и передает данные в виде потоков байтов. Данные пересылаются пакетами - TCP-сегментами, - которые состоят из заголовков TCP и данных. TCP - "надежный" протокол, потому что в нем используются контрольные суммы для проверки целостности данных и отправка подтверждений, чтобы гарантировать, что переданные данные приняты без искажений.

UDP (User Datagram Protocol, протокол пользовательских дейтаграмм): протокол, не зависящий от подключений, который передает данные пакетами, называемыми UDP-дейтаграммами. UDP - "ненадежный" протокол, поскольку отправитель не получает информацию, показывающую, была ли в действительности принята дейтаграмма.
Архитектура TCP/IP

Проектировщики вычислительных сетей часто используют семиуровневую модель ISO/OSI (International Standards Organization/Open Systems Interconnect, Международная организация по стандартизации/ Взаимодействие открытых систем), которая описывает архитектуру сетей. Каждый уровень в этой модели соответствует одному уровню функциональных возможностей сети. В самом основании располагается физический уровень, представляющий физическую среду, по которой "путешествуют" данные, - другими словами, кабельную систему вычислительной сети. Над ним имеется канальный уровень, или уровень звена данных, функционирование которого обеспечивается сетевыми интерфейсными платами. На самом верху размещается уровень прикладных программ, где работают программы, использующие служебные функции сетей.

На рисунке показано, как TCP/IP согласуется с моделью ISO/OSI. Этот рисунок также иллюстрирует уровневое строение TCP/IP и показывает взаимосвязи между основными протоколами. При переносе блока данных из сетевой прикладной программы в плату сетевого адаптера он последовательно проходит через ряд модулей TCP/IP. При этом на каждом шаге он доукомплектовывается информацией, необходимой для эквивалентного модуля TCP/IP на другом конце цепочки. К тому моменту, когда данные попадают в сетевую плату, они представляют собой стандартный кадр Ethernet, если предположить, что сеть основана именно на этом интерфейсе. Программное обеспечение TCP/IP на приемном конце воссоздает исходные данные для принимающей программы путем захвата кадра Ethernet и прохождения его в обратном порядке по набору модулей TCP/IP. (Один из наилучших способов разобраться во внутреннем устройстве TCP/IP стоит в использовании программы-"шпиона", чтобы найти внутри кадров, "пролетающих" по сети, информацию, добавленную различными модулями TCP/IP.)

В левой части этой диаграммы показаны уровни модели ISO/OSI. Правая часть диаграммы иллюстрирует корреляцию TCP/IP с этой моделью.

Для иллюстрации роли, которую TCP/IP играет в вычислительных сетях в реальном мире, рассмотрим, что происходит, когда Web-браузер использует HTTP (HyperText Transfer Protocol, протокол передачи гипертекста) для извлечения страницы HTML-данных из Web-сервера, подключенного к Internet. Для формирования виртуального подключения к серверу браузер использует абстракцию программного обеспечения высокого уровня, называемую гнездом (socket). А чтобы извлечь страницу Web, он посылает на сервер команду GET HTTP, записывая ее в гнездо. Программное обеспечение гнезда, в свою очередь, применяет TCP для пересылки битов и байтов, составляющих команду GET на Web-сервер. TCP сегментирует данные и передает отдельные сегменты модулю IP, который пересылает сегменты в дейтаграммах на Web-сервер.

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

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

О TCP/IP можно было бы рассказать много больше, но есть три ключевых момента:
TCP/IP - это набор протоколов, которые позволяют физическим сетям объединяться вместе для образования Internet. TCP/IP соединяет индивидуальные сети для образования виртуальной вычислительной сети, в которой отдельные главные компьютеры идентифицируются не физическими адресами сетей, а IP-адресами.
В TCP/IP используется многоуровневая архитектура, которая четко описывает, за что отвечает каждый протокол. TCP и UDP обеспечивают высокоуровневые служебные функции передачи данных для сетевых программ, и оба опираются на IP при передаче пакетов данных. IP отвечает за маршрутизацию пакетов до их пункта назначения.
Данные, перемещающиеся между двумя прикладными программами, работающими на главных компьютерах Internet, "путешествуют" вверх и вниз по стекам TCP/IP на этих компьютерах. Информация, добавленная модулями TCP/IP на стороне отправителя, "разрезается" соответствующими TCP/IP-модулями на принимающем конце и используется для воссоздания исходных данных.