Теория:протоколы:tcp

Документы стандартов

• RFC   , стандарт 64, RTP: транспортный протокол для приложений реального времени
• RFC   , Standard 65, профиль RTP для аудио- и видеоконференций с минимальным контролем
• RFC   , Регистрация типа носителя для форматов полезной нагрузки RTP
• RFC   , Регистрация типа носителя для форматов полезной нагрузки в профиле RTP для аудио- и видеоконференций
• RFC   , Таксономия семантики и механизмов для источников протокола передачи в реальном времени (RTP)

• RFC   , формат полезной нагрузки RTP для 12-битного аудио DAT и 20- и 24-битного линейно дискретизированного аудио
• RFC   , формат полезной нагрузки RTP для видео H.264
• RFC   , Формат полезной нагрузки RTP для транспортировки элементарных потоков MPEG-4
• RFC   , формат полезной нагрузки RTP для аудио / визуальных потоков MPEG-4
• RFC   , формат полезной нагрузки RTP для видео MPEG1 / MPEG2

• RFC   , формат полезной нагрузки RTP для несжатого видео
• RFC   , формат полезной нагрузки RTP для MIDI
• RFC   , Руководство по внедрению RTP MIDI
• RFC   , формат полезной нагрузки RTP для высокоэффективного кодирования видео (HEVC)

Соединение TCP

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

Задачи соединения

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

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

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

Получатель в ответ передаёт сообщение SYN, куда включает подтверждение получения предыдущего сообщения ACK от слова acknowledge и порядковый номер байта, который он ожидает 7538, потому что на предыдущем этапе был получен байт с номером 7537.

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

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

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

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

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

Рассмотрим, как выполняется корректный разрыв соединения. Сторона, которая хочет разорвать соединение пересылает другой стороне сообщение FIN и в ответ получает сообщение ACK. Однако соединение разорвано только с одной стороны.

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

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

Дизайн приложения

Для функционального мультимедийного приложения требуются другие протоколы и стандарты, используемые вместе с RTP. Такие протоколы, как SIP, Jingle , RTSP, H.225 и H.245 , используются для инициирования, управления и завершения сеанса. Другие стандарты, такие как H.264, MPEG и H.263, используются для кодирования данных полезной нагрузки, как указано в соответствующем профиле RTP.

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

Модель OSI

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

Отдельно выделяются хосты, это устройства, где работают полезные пользовательские программы. И сетевое оборудование, такое как маршрутизаторы, коммутаторы и другие сетевые устройства. На сетевом оборудовании есть только 3 уровня: физический, канальный и сетевой. Уровни начиная с транспортного работают только на хостах. 

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

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

Способы передачи данных

Данные передаются через физическую среду тремя способами:

• Simplex.
• Half-duplex.
• Full Duplex.

Simplex – это односторонняя связь. Передача ведется только одним устройством, в то время как другое только принимает сигнал. Можно сказать, что информация транслируется только в одном направлении.

Примеры симплексной связи:

• Телевещание.
• Сигнал от спутников GPS.

Half-duplex – это двусторонняя связь. Однако только один узел может передавать сигнал в определенный момент времени. При такой связи два устройства не могут одновременно использовать один канал. Полноценная двусторонняя связь может быть невозможна физически или приводить к коллизиям. Говорится, что они конфликтуют за среду передачи. Этот режим применяется при использовании коаксиального кабеля.

Пример полудуплексной связи — общение по рации на одной частоте.

Full Duplex – полноценная двусторонняя связь. Устройства могут одновременно транслировать сигнал и производить прием. Они не конфликтуют за среду передачи. Этот режим применяется при использовании технологии Fast Ethernet и соединении с помощью витой пары.

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

Связующий слой

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

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

Канальный уровень в модели TCP / IP имеет соответствующие функции на уровне 2 модели OSI.

Что такое TCP/IP

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

Полностью пишется, как, Transmission Control Protocol/Internet Protocol, что в переводе означает — Протокол управления передачи/Интернета.

Позволяет взаимодействовать между собой устройствам, находящимся в разных сетях и с различными операционными системами, например, между Windows, Mac OS, Linux и т.д.

Название данного стека — набора правил сложилось из основных двух:

• Протокол IP — берет на себя задачу по адресации, определяет, где в передаваемых данных: адрес, содержимое.
• Протокол TCP — обеспечивает и контролирует надежную передачу информации и ее целостность.

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

Как работает TCP/IP — принцип работы

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

Так обмениваются между собой программы по сети:

Программа 1 — отправитель:
IP адрес: 192.168.0.32
Порт: 2054

Программа 2 — получатель:
IP адрес: 192.168.0.34
Порт: 2071

Пересылаемые данные пакета:
— — —

IP — это уникальный адрес компьютера. Порт — это идентификатор приложение установленного на нем. Связка, IP + порт называется — сокет.

Стек протоколов TCP/IP

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

1. Прикладной / Для приложений. Это: HTTP, SMTP, DNS, FTP и т.д. Т.е. Веб, почта, передача файлов и прочее.2. Транспортный. Это: TCP, UPD и т.д. Отвечает за связь между компьютерами и за доставку данных.3. Сетевой (межсетевой). IP, IGMP и т.д. Отвечает за адресацию.4. Канальный / Сетевые интерфейсы. Это: Ethernet, Wi-Fi, DSL.

На этом стеке и реализовано все взаимодействие пользователей в IP сетях. Также, существуют и другие стеки: OSI, IPX/SPX, IPX/SPX.

В заключение

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

Медленный старт

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

При медленном старте размер окна увеличивается на каждое подтверждение не на 1 сегмент, а на 2, благодаря этому происходит экспоненциальное увеличение размера окна. Сначала мы отправляем один сегмент, получили подтверждение, отправляем два сегмента, получили 2 подтверждения, на каждое подтверждение отправляем по два сегмента всего 4, потом 8, потом 16 и так далее. То есть несмотря на название медленный старт, размер окна увеличивается гораздо быстрее, чем при аддитивном увеличении, мультипликативном уменьшении.

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

Медленный старт и AIMD в TCP

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

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

Формат заголовка IP-пакета

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

Номер версии

Первое поле номер версии. Сейчас используется две версии протокола IP 4 и 6. Большая часть компьютеров использует IPv4. Длина  адреса в этой версии 4 байта. Формат адреса IP версии 4 мы рассматривали подробно. Проблема в том, что адресов IPv4, четыре с небольшим миллиарда, что уже сейчас не хватает для всех устройств в сети, а в будущем точно не хватит. Поэтому была предложена новая версия IPv6 в которой длина IP адреса составляет 16 байт. Сейчас эта версия вводится в эксплуатацию, но процесс занимает очень долгое время.

Длина заголовка

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

Тип сервиса

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

Общая длина

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

Время жизни

Дальше идет поле время жизни. Время жизни Time To Live или TTL — это максимальное время в течение которого пакет может перемещаться по сети. Оно введено для того чтобы пакеты не гуляли по сети бесконечно, если в конфигурации сети возникла какая-то ошибка. Например, в результате неправильной настройке маршрутизаторов в сети, может образоваться петля. Раньше, время жизни измерялось в секундах, но сейчас маршрутизаторы обрабатывают пакет значительно быстрее чем за секунду, поэтому время жизни уменьшается на единицу на каждом маршрутизаторе, и оно измеряется в количествах прохождения через маршрутизаторы по-английски (hop) от слова прыжок. Таким образом название время жизни сейчас стало уже некорректным.

Тип протокола

После времени жизни, указывается тип протокола следующего уровня. Это поле необходимо для реализации функции мультиплексирования и демультиплексирования, то есть передачи с помощью протокола IP данных от разных протоколов следующего уровня. В этом поле указывается код протокола следующего уровня, некоторые примеры кодов для TCP код 6, UDP — 17 и ICMP — 1.

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

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

IP адрес получателя и отправителя

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

Опции

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

И опция — временные метки, при установке которой, каждый маршрутизатор записывает время прохождения пакеты.

Также опции позволяют отказаться от автоматической маршрутизации, и задать маршрут отправитель:

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

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

В статье был рассмотрен протокол IP (Internet Protocol) — протокол межсетевого взаимодействия. Протокол IP является основой интернета. В OSI находится на сетевом уровне.

AIMD

В TCP для определения размера окна перегрузки используется метод аддитивного увеличения, мультипликативного уменьшения. Суть метода заключается в том, что при получении каждого подтверждения, мы прибавляем к размеру окна некоторые значения, как правило это размер одного сегмента TCP, а если перегрузка произошла, то мы умножаем размер окна на некоторые значения. Как правило это 1/2, то есть в TCP при перегрузке, размер окна уменьшается в два раза.

• Где a — максимальный размер сегмента (MSS);
• b- 1/2.

 Размер окна AIMD

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

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

Сигнал о перезагрузке

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

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

Навигация

Сравнение с моделью OSI

Три верхних уровня в модели OSI, то есть уровень приложения, уровень представления и уровень сеанса, отдельно не различаются в модели TCP/IP, которая имеет только прикладной уровень над транспортным уровнем. Хотя некоторые чистые приложения протокола OSI, такие как X.400, также объединяют их, нет требования, чтобы стек протокола TCP/IP должен накладывать монолитную архитектуру над транспортным уровнем. Например, протокол NFS-приложений работает через протокол представления данных External Data Representation (XDR), который, в свою очередь, работает по протоколу Remote Procedure Call (RPC). RPC обеспечивает надежную передачу данных, поэтому он может безопасно использовать транспорт UDP с максимальным усилием.

Различные авторы интерпретировали модель TCP/IP по-разному и не согласны с тем, что уровень связи или вся модель TCP/IP охватывает проблемы первого уровня модели OSI (физический уровень) или предполагается, что аппаратный уровень ниже уровня канала.

Несколько авторов попытались включить слои 1 и 2 модели OSI в модель TCP/IP, поскольку они обычно упоминаются в современных стандартах (например, IEEE и ITU). Это часто приводит к модели с пятью слоями, где уровень связи или уровень доступа к сети разделяются на слои 1 и 2 модели OSI.

Например, считается, что уровни сеанса и представления пакета OSI включены в прикладной уровень пакета TCP/IP. Функциональность уровня сеанса можно найти в протоколах, таких как HTTP и SMTP, и более очевидна в таких протоколах, как Telnet и протокол инициации сеанса (SIP). Функциональность уровня сеанса также реализована с нумерацией портов протоколов TCP и UDP, которые охватывают транспортный уровень в наборе TCP/IP. Функции уровня представления реализуются в приложениях TCP/IP со стандартом MIME при обмене данными.

Конфликты очевидны также в оригинальной модели OSI, ISO 7498, когда не рассматриваются приложения к этой модели, например, ISO 7498/4 Management Framework или ISO 8648 Internal Organization of the Network layer (IONL). Когда рассматриваются документы IONL и Management Framework, ICMP и IGMP определяются как протоколы управления уровнем для сетевого уровня. Аналогичным образом IONL предоставляет структуру для «зависимых от подсетей объектов конвергенции», таких как ARP и RARP.

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

К тому же, модель OSI не использует дополнительный уровень — «Internetworking» — между канальным и сетевым уровнями. Примером спорного протокола может быть ARP или STP.

Вот как традиционно протоколы TCP/IP вписываются в модель OSI:

Распределение протоколов по уровням модели OSI

	TCP/IP	OSI
7	Прикладной	Прикладной	напр., HTTP, SMTP, SNMP, FTP, Telnet, SSH, SCP, SMB, NFS, RTSP, BGP
6	Представления	напр., XDR, AFP, TLS, SSL
5	Сеансовый	напр., ISO 8327 / CCITT X.225, RPC, NetBIOS, PPTP, L2TP, ASP
4	Транспортный	Транспортный	напр., TCP, UDP, SCTP, SPX, ATP, DCCP, GRE
3	Сетевой	Сетевой	напр., IP, ICMP, IGMP, CLNP, OSPF, RIP, IPX, DDP
2	Канальный	Канальный	напр., Ethernet, Token ring, HDLC, PPP, X.25, Frame relay, ISDN, ATM, SPB, MPLS, ARP
1	Физический	напр., электрические провода, радиосвязь, волоконно-оптические провода, инфракрасное излучение

Обычно в стеке TCP/IP верхние 3 уровня модели OSI (прикладной, представления и сеансовый) объединяют в один — прикладной. Поскольку в таком стеке не предусматривается унифицированный протокол передачи данных, функции по определению типа данных передаются приложению.

Установление соединения TCP

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

Перед началом передачи каких-либо данных, согласно протоколу TCP, стороны должны установить соединение. Соединение устанавливается в три этапа (процесс «трёхкратного рукопожатия» TCP).

• Запрашивающая сторона (которая, как правило, называется клиент) отправляет SYN сегмент, указывая номер порта сервера, к которому клиент хочет подсоединиться, и исходный номер последовательности клиента (ISN).
• Сервер отвечает своим сегментом SYN, содержащим исходный номер последовательности сервера. Сервер также подтверждает приход SYN клиента с использованием ACK (ISN + 1). На SYN используется один номер последовательности.
• Клиент должен подтвердить приход SYN от сервера своим сегментов SYN, содержащий исходный номер последовательности клиента (ISN+1) и с использованием ACK (ISN+1). Бит SYN установлен в 0, так как соединение установлено.

После установления соединения TCP, эти два хоста могут передавать данные друг другу, так как TCP-соединение является полнодуплексным, они могут передавать данные одновременно. 

Транспортные протоколы

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

• ATP (Apple
  Talk
  Protocol
  – Транзакционный протокол Apple
  Talk)
  и NBP (Name
  Binding
  Protocol
  – Протокол связывания имен). Сеансовый
  и транспортный протоколы Apple
  Talk.

• NetBIOS
  (Базовая
  сетевая система ввода вывода).
  NetBIOS
  Устанавливает соединение между
  компьютерами, а NetBEUI
  предоставляет услуги передачи данных
  для этого соединения.

• SPX (Sequenced
  Packet
  eXchange
  – Последовательный обмен пакетами) в
  NWLink.Протокол
  Novel
  NetWare,
  используемый для обеспечения доставки
  данных.

• TCP (Transmission
  Control
  Protocol
  – Протокол управления передачей).Протокол
  стека TCP/IP, отвечающий за надежную
  доставку данных.

Архитектурное решение

ОПИСАНИЕ

ip

Только что созданный сокет TCP не имеет локального или удалённого адреса и
не является полностью определённым. Для создания исходящего соединения TCP с
другим сокетом TCP используйте connect(2). Для приёма новых входящих
соединений сперва подключите сокет к локальному адресу и порту с помощью
bind(2), а затем вызовите listen(2) для перевода сокета в режим
прослушивания. После этого через новый сокет можно принимать каждое входящее
соединение с помощью accept(2). Сокет, для которого успешно отработали
accept(2) или connect(2), является полностью определённым и может
передавать данные. Данные не могут быть переданы через слушающий или ещё не
соединённый сокет.

Linux поддерживает высокопроизводительные расширения TCP RFC 1323. Они
включают в себя: защиту против оборотной последовательности номеров (PAWS),
масштабирование окна и метки времени. Масштабирование окна позволяет
использовать большие (> 64КБ) окна TCP для поддержки соединений с
большой задержкой или высокой пропускной способностью. Для их использования
необходимо увеличить размеры буферов приёма и передачи. Это можно сделать
глобально через файлы /proc/sys/net/ipv4/tcp_wmem и
/proc/sys/net/ipv4/tcp_rmem, или для отдельных сокетов, используя
параметры сокетов SO_SNDBUF и SO_RCVBUF в вызове setsockopt(2).

Максимальный размер буферов сокета объявляется, используя механизмы
SO_SNDBUF и SO_RCVBUF и ограничен значениями в файлах
/proc/sys/net/core/rmem_max и /proc/sys/net/core/wmem_max. Заметим,
что TCP в действительности бронирует в два раза больше места, чем размер
буфера, запрошенный в вызове setsockopt(2), поэтому последующий вызов
getsockopt(2) не возвратит тот же размер буфера, что был запрошен в
вызове setsockopt(2). TCP использует дополнительное пространство в
административных целях и для внутренних структур ядра, а значения в файлах в
/proc отражают большие размеры, по сравнению с действительными окнами
TCP. Для отдельных соединений размер буфера сокета должен быть установлен до
вызова listen(2) или connect(2). Дополнительную информацию смотрите в
socket(7).

TCP поддерживает срочные данные

Срочные данные используются для уведомления
принимающей стороны о том, что частью потока данных является некоторое
важное сообщение, которое должно быть обработано как можно скорее. Для
отправки срочных данных укажите параметр MSG_OOB в вызове send(2)

При
поступлении срочных данных ядро посылает сигнал SIGURG процессу или
группе процессов, который указан как «владелец» сокета с помощью
ioctl-вызовов SIOCSPGRP или FIOSETOWN (или с помощью определённой в
POSIX.1 операции F_SETOWN для fcntl(2)). Если задан параметр сокета
SO_OOBINLINE, то срочные данные будут помещены в обычный поток данных
(программа может проверить его размещение с помощью ioctl-вызова
SIOCATMARK, описанного далее), в противном случае они могут быть
получены, только если для recv(2) или recvmsg(2) установлен флаг
MSG_OOB.

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

Выводы

• Как реально работает сеть, и что TCP можно повторить поверх UDP и сделать лучше. 
• Что TCP не так плох, если его правильно настроить, но он реально сдался и больше уже почти не развивается.
• Не верьте хейтерам UDP, которые говорят, что в user space работать не будет. Все эти проблемы можно решить. Пробуйте — это ближайшее будущее.
• Если не верите, то сеть можно и нужно трогать руками. Я показывал, как почти все можно проверить.

Настраивайте протокол (TCP, UDP — неважно) под ситуацию (профиль сети + профиль нагрузки).
Используйте рецепты TCP, которые я вам рассказал: TFO, send/recv buffer, TLS1.3, CC… 
Делайте свои UDP-протоколы, если есть ресурсы. 
Если сделали свой UDP, проверьте UDP check list, что вы сделали все, что надо. Забудете какую-нибудь ерунду типа pacing, не будет работать.

Полезные ссылки

• Миллион видеозвонков в сутки или «Позвони маме!».
• Пишем свой протокол поверх UDP.
• Подкаст про сетевую оптимизацию.
• Увеличение скорости передачи данных в плохих сетях.