Протокол tcp

TCP vs self-made UDP

• С перегрузками, когда пакетов очень много и некоторые из них дропаются из-за перегрузки каналов или оборудования.
• Высокоскоростные с большими round-trip (например когда сервер располагается относительно далеко).
• Странные — когда в сети вроде бы ничего не происходит, но пакеты все равно пропадают просто потому-что Wi-Fi точка доступа находится за стенкой.

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

Отличия HTTP 2.0

• бинарный, сжатие заголовков;
• мультиплексирование данных;
• приоритизация;
• возможна отмена загрузки;
• server push

Высокоприоритетный контент загружается раньше.Server pushReset stream

• Профилях сети: Wi-Fi, 3G, LTE.
• Профилях потребления: cтриминг (видео), мультиплексирование и приоритизация с отменой загрузки (HTTP/2) для получения контента ленты. 

Размер буфера

• пакеты 1 и 2 уже отправлены, для них получено подтверждение;
• пакеты 3, 4, 5, 6 отправлены, но результат доставки неизвестен (on-the-fly packets);
• остальные пакеты находятся в очереди.

Вывод:

Congestion control

• Flow control — это некий механизм защиты от перегрузки. Получатель говорит, на какое количество данных у него реально есть место в буфере, чтобы он был готов их принять. Если передать сверх flow control или recv window, то эти пакеты просто будут выкинуты. Задача flow control — это back pressure от нагрузки, то есть просто кто-то не успевает вычитывать данные.
• У congestion control совершенно другая задача. Механизмы схожие, но задача — спасти сеть от перегрузки.

• Если TCP window = 1, то данные передаются как на схеме слева: дожидаемся acknowledgement, отправляем следующий пакет и т.д. 
• Если TCP window = 4, то отправляем сразу пачку из четырех пакетов, дожидаемся acknowledgement и дальше работаем.

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

• Cubic — дефолтный Congestion Control с Linux 2.6. Именно он используется чаще всего и работает примитивно: потерял пакет — схлопнул окно.
• BBR — более сложный Congestion Control, который придумали в Google в 2016 году. Учитывает размер буфера.

BBR Congestion Control

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

jitterHighLoad++

Какой Congestion control выбрать

Выводы про congestion control:

• Для видео всегда хорош BBR. 
• В остальных случаях, если мы используем свой UDP-протокол, можно взять congestion control с собой.
• С точки зрения TCP можно использовать только congestion control, который есть в ядре. Если хотите реализовать свой congestion control в ядро, нужно обязательно соответствовать спецификации TCP. Невозможно раздуть acknowledgement, сделать изменения, потому что просто их нет на клиенте.

Сравнение с моделью 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:

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

Транспортный уровень

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

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

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

TCP — это протокол, ориентированный на соединение, который решает многочисленные проблемы надежности при обеспечении надежного потока байтов :

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

Новый протокол передачи управления потоком (SCTP) также является надежным транспортным механизмом с установлением соединения. Он ориентирован на поток сообщений, а не на поток байтов, как TCP, и обеспечивает несколько потоков, мультиплексированных по одному соединению. Она также обеспечивает Многодомность поддержку, в котором соединительный конец может быть представлен несколькими IP — адресами (представляющих несколько физических интерфейсов), так что , если один выходит из строя, соединение не прерывается. Первоначально он был разработан для приложений телефонии (для передачи SS7 по IP).

Надежность также может быть достигнута за счет использования IP по надежному протоколу передачи данных, например High-Level Data Link Control (HDLC).

User Datagram Protocol (UDP) является установление соединения дейтаграммы протокола. Как и IP, это ненадежный протокол, требующий максимальных усилий. Надежность достигается путем обнаружения ошибок с использованием алгоритма контрольной суммы. UDP обычно используется для таких приложений, как потоковая передача мультимедиа (аудио, видео, передача голоса по IP и т

Д.), Где своевременное поступление более важно, чем надежность, или для простых приложений запросов / ответов, таких как поиск DNS , где накладные расходы на настройку надежное соединение непропорционально велико. Транспортный протокол реального времени (RTP) — это протокол дейтаграмм, который используется поверх UDP и предназначен для данных в реальном времени, таких как потоковая передача мультимедиа .

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

Транспортный уровень модели TCP / IP или уровень хост-хост примерно соответствует четвертому уровню в модели OSI, также называемому транспортным уровнем.

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

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

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

 Explicit Congestion Notification (ECN)

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

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

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

ECN в заголовке IP

Рассмотрим, какие поля в заголовке IP и TCP используются в технологии Explicit Congestion Notification. В заголовке IP используются 2 бита в поле тип сервиса, значение 00 говорит о том, что перегрузки нет, а 11 означают что перегрузка произошла.

ECN в заголовке TCP

В заголовке TCP для этих целей используются три флага, NS, CWR, ECE.

• Получатель, который принял от маршрутизаторов заголовки IP сигнал о перегрузке, использует флаг ECE (ECN-Echo). Получатель устанавливает этот флаг в подтверждение получения сегмента, который он передает отправителю.
• Отправитель в качестве подтверждения того, что он получил сообщение о перегрузки при передаче следующего сегмента устанавливает флаг CWR (Congestion Window Reduced), который говорит о том, что размер окна управление перегрузкой уменьшен.
• Еще один флаг NS (ECN-none concealment protection) используется для защиты от случайного или злонамеренного изменения полей, который относится к технологии Explicit Congestion Notification.

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

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

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

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

Зачем сравнивать TCP или что с ним не так

• packet loss — примерно 0,6% пакетов, которые мы отправляем, теряются по пути;
• reordering — перестановка пакетов местами, в реальной жизни довольно редкое явление, но случается в 0,2% случаев;
• jitter — когда пакеты отправляются равномерно, а приходят очередями с задержкой примерно в 50 мс.

Как вычислить RTT

RIPE Atlasбеспроводные сети популярны и нестабильны

• Более 80% пользователей используют беспроводной интернет;
• Параметры беспроводных сетей динамично меняются в зависимости, например, от того, что пользователь повернул за угол;
• Беспроводные сети имеют высокие показатели packet loss, jitter, reordering;
• Фиксированный ассиметричный канал, смена IP-адреса.

TCP в нестабильных сетях

меньше половины канала

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

Реализация

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

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

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

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

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

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

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

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

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

Навигация

Выполняем атаку TCP reset против себя

Примечание: я тестировал этот процесс на OSX, но получил несколько комментариев, что в Linux он не работает нужным образом.

• Наблюдать за сетевым трафиком («сниффить» его), передаваемым между двумя жертвами
• Сниффить TCP-сегмент со включенным флагом и считать его подтверждённый номер
• Изготовить ложный TCP-сегмент со включенным флагом и порядковым номером, равным подтверждённому номеру перехваченного сегмента (стоит учесть, что это предполагает медленную передачу, иначе выбранный порядковый номер быстро устареет. (Чтобы повысить шансы на успех, можно передать несколько сегментов с большим интервалом порядковых номеров.)
• Отправить фальшивые сегменты одной или обеим жертвам, надеясь, что это приведёт к разрыву их TCP-соединения

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

2. Сниффинг трафика

• — приказывает слушать сетевой интерфейс , или localhost
• — функция фильтра, приказывающая игнорировать все пакеты, не являющиеся частью соединения двух IP-адресов localhost на порте сервера. Эта фильтрация необходима, потому что на машине есть множество других программ, использующих интерфейс . Мы хотим игнорировать все пакеты, не являющиеся частью нашего эксперимента.
• — функция, которую должна выполнять для каждого пакета, соответствующего требованиям функции . Функция в показанном выше примере просто выводит пакет на терминал. На следующем этапе мы изменим эту функцию, чтобы она также передавала сегменты .
• — количество пакетов, которое должна сниффить до выхода.

3. Отправка фальшивых пакетов

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

Дальнейшая работа

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

Окно перегрузки в TCP

Таким образом в  TCP у нас есть два типа окна. Окно управления потоком, которое мы рассматривали в статье «Протокол TCP — Управление Потоком». Размер этого окна задаются получателем, в зависимости от того сколько места в буфере, и передается отправителю в сегментах с подтверждением.

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

Назначение TCP

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

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

Причина, по которой 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

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

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

В стеке ТСР/ IР очень экономно используются возможности широковещательных рассылок. Это свойство совершенно необходимо при работе на медленных каналах связи, характерных для территориальных сетей.

Обзор

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

Приложения потоковой передачи мультимедиа в реальном времени требуют своевременной доставки информации и часто могут допускать некоторую потерю пакетов для достижения этой цели. Например, потеря пакета в аудиоприложении может привести к потере доли секунды аудиоданных, что можно сделать незаметным с помощью подходящих алгоритмов маскирования ошибок . Протокол управления передачей (TCP), хотя стандартизирована для использования протокола RTP, как правило , не используется в приложениях , RTP , поскольку TCP способствует надежности за своевременностью. Вместо этого большинство реализаций RTP построено на протоколе дейтаграмм пользователя (UDP). Другие транспортные протоколы, специально разработанные для мультимедийных сеансов, — это SCTP и DCCP , хотя по состоянию на 2012 год они не получили широкого распространения.

Протокол RTP был разработан рабочей группой Audio / Video Transport организации по стандартизации IETF. RTP используется вместе с другими протоколами, такими как H.323 и RTSP . Спецификация RTP описывает два протокола: RTP и RTCP. RTP используется для передачи мультимедийных данных, а RTCP используется для периодической отправки управляющей информации и параметров QoS.

Протокол передачи данных RTP передает данные в реальном времени. Информация, предоставляемая этим протоколом, включает временные метки (для синхронизации), порядковые номера (для обнаружения потери пакетов и переупорядочения) и формат полезной нагрузки, который указывает закодированный формат данных. Протокол управления RTCP используется для обратной связи по качеству обслуживания (QoS) и синхронизации между медиапотоками. Пропускная способность трафика RTCP по сравнению с RTP мала, обычно около 5%.

Сеансы RTP обычно инициируются между взаимодействующими одноранговыми узлами с использованием протокола сигнализации, такого как H.323, протокол инициации сеанса (SIP), RTSP или Jingle ( XMPP ). Эти протоколы могут использовать протокол описания сеанса для определения параметров сеансов.

Сеанс RTP устанавливается для каждого мультимедийного потока. Аудио- и видеопотоки могут использовать отдельные сеансы RTP, что позволяет приемнику выборочно принимать компоненты определенного потока. Конструкция RTP и RTCP не зависит от транспортного протокола. Приложения обычно используют UDP с номерами портов в непривилегированном диапазоне (от 1024 до 65535). Протокол управления Потока передачи (SCTP , ) и дейтаграммы перегрузки протокол управления (DCCP) могут быть использованы , когда надежный транспортный протокол желательно. Спецификация RTP рекомендует четные номера портов для RTP и использование следующего нечетного номера порта для соответствующего сеанса RTCP. Один порт может использоваться для RTP и RTCP в приложениях, которые мультиплексируют протоколы.

RTP используется мультимедийными приложениями в реальном времени, такими как передача голоса по IP , аудио по IP , WebRTC и телевидение по Интернет-протоколу.

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

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

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

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

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

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

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

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

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

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

Управление скоростью передачи в TCP

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

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

Заключение