Теория:сетевая модель tcp/ip

Библиография

• Дуглас Э. Комер . Межсетевое взаимодействие с TCP / IP — принципы, протоколы и архитектура . ISBN  86-7991-142-9
• Джозеф Г. Дэвис и Томас Ф. Ли. Протоколы и службы TCP / IP Microsoft Windows Server 2003 . ISBN  0-7356-1291-9
• Форузан, Бехруз А. (2003). Пакет протоколов TCP / IP (2-е изд.). Макгроу-Хилл. ISBN 978-0-07-246060-5.
• Крейг Хант Администрирование сети TCP / IP . О’Рейли (1998) ISBN  1-56592-322-7
• Мафер, Томас А. (1999). Основы интеллектуальной собственности . Прентис Холл. ISBN 978-0-13-975483-8.
• Иэн Маклин. Windows (R) 2000 TCP / IP Черная книга . ISBN  1-57610-687-X
• Ajit Mungale Pro .NET 1.1 Сетевое программирование . ISBN  1-59059-345-6
• В. Ричард Стивенс . Иллюстрированный TCP / IP, Том 1: Протоколы . ISBN  0-201-63346-9
• У. Ричард Стивенс и Гэри Р. Райт. Иллюстрированный TCP / IP, Том 2: Реализация . ISBN  0-201-63354-X
• В. Ричард Стивенс . Иллюстрированный TCP / IP, Том 3: TCP для транзакций , HTTP , NNTP и протоколы домена UNIX . ISBN  0-201-63495-3
• Эндрю С. Таненбаум . Компьютерные сети . ISBN  0-13-066102-3

Что такое сетевые порты

При передаче данных кроме IP-адресов отправителя и получателя пакет информации содержит в себе номера портов. Пример: 192.168.1.1:80, — в данном случае 80 — это номер порта. Порт — это некое число, которое используется при приеме и передаче данных для идентификации процесса (программы), который должен обработать данные. Так, если пакет послан на 80-й порт, то это свидетельствует, что информация предназначена серверу HTTP.

Номера портов с 1-го до 1023-й закреплены за конкретными программами (так называемые well-known-порты). Порты с номерами 1024-65 535 могут быть использованы в программах собственной разработки. При этом возможные конфликты должны решаться самими программами путем выбора свободного порта. Иными словами, порты будут распределяться динамически: возможно, что при следующем старте программа выберет иное значение порта, если, конечно, Вы вручную через настройки не задавали ей порт.

Назначение 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Р очень экономно используются возможности широковещательных рассылок. Это свойство совершенно необходимо при работе на медленных каналах связи, характерных для территориальных сетей.

Что такое 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.

В заключение

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

Порядок следования сообщений

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

Какие проблемы могут произойти? Протокол IP не сохраняет порядок следования сообщений и поэтому сегменты могут  прийти к  получателю не в том порядке в котором они были отправлены. Кроме того, некоторые сегменты могут прийти два и более раз. Рассмотрим одну из возможных причин дублирования сегментов.

Дублирование сегментов

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

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

Механизм очень простой, все сообщения нумеруются. В TCP нумеруются не сегменты, так как разные сегменты могут иметь разный размер, а байты.

В нашем примере 4 сегмента первый сегмент содержит байты от 0 до 1023, второй от 1024 до 2047 и так далее.

Нумерация байтов

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

• Например сегмент данных, байт 0, он содержит байты с 0 до 1023.
• Получатель отправляет подтверждение и в подтверждение включает номер следующего байта, который ожидается байт 1024.
• Отправитель передает следующий сегмент, включая в него номер первого байта, сегмент данных, номер первого байта 1024 содержит данные до номера байта 2047.
• Получатель отправляет подтверждение, что он ждет байт с номером 2048, если сегменты придут в неправильном порядке, то получатель по номерам байтов всегда сможет выставить их в правильной последовательности.

Дублирование сегментов

Рассмотрим как решается ситуация с дублированием сегментов.

• Отправитель включает в сегмент номер первого передаваемого байта 1024.
• Получатель отправляет подтверждение, где говорит что ждет байт в 2048.
• Но так как подтверждение не дошло, то отправитель передает тот же самый сегмент 1024.
• Однако получатель видит, что этот сегмент у него уже есть поэтому он этот сегмент игнорирует и снова отправляет подтверждение, где говорит что он ожидает байт 2048.

Сетевые протоколы UDP, TCP, ICMP

В рамках протокола TCP/IP для передачи данных используются протоколы — TCP и UDP. Многие наверняка слышали, что есть порты как TCP, так и UDP, но не все знают в чем разница и что это вообще. И так..

Передача данных по протоколу TCP (Transmission Control Protocol — Протокол Управления Передачей) предусматривает наличие подтверждений получения информации. «-Ну, мол, — получил? -Получил!» Если же передающая сторона не получит в установленные сроки необходимого подтверждения, то данные будут переданы повторно. Поэтому протокол TCP относят к протоколам, предусматривающим соединение, а UDP (User Datagram Protocol — Протокол Пользовательских Датаграмм) — нет. UDP применяется в тех случаях, когда не требуется подтверждения приема (например, DNS-запросы или IP-телефония (яркий представитель которой, — Skype) ). То есть разница заключается в наличии подтверждения приема. Казалось бы «Всего то!», но на практике это играет важную роль.

Есть еще так же протокол ICMP (Internet Control Message Protocol — межсетевой протокол управляющих сообщений), который используется для передачи данных о параметрах сети. Он включает в себя служебные типы пакетов, таки как ping, distination unreachable, TTL и пр.

Сравнение с моделью 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 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, сделать изменения, потому что просто их нет на клиенте.

Порт[править]

Сетевой порт — это сетевой ресурс, отображаемый в виде числа (1-65535), которое определяет назначение входящих или исходящих сетевых потоков данных на заданном устройстве.

Если прибегнуть к аналогии, IP адрес — это адрес общежития с вахтёром, а порт — номер комнаты в этом общежитии или фамилия ее жильца.

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

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

Узел назначения («вахтер»), получив пакет («письмо»), смотрит на порт назначения («фамилию или номер комнаты») и передает пакет соответствующему у себя приложению («конкретному жильцу»).

Использование портов позволяет независимо использовать TCP протокол («почтовые услуги») сразу многим приложениям на одном и том же компьютере (общежитии).

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

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

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

Таким образом, сервер:

• слушает на определённом порту, заранее известном клиенту
• занимает этот порт всё время, пока не завершит работу
• об IP-адресе и номере порта клиента узнаёт из приглашения, посланного клиентом

Клиент:

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

Задачи протокола ТСР

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

o мультиплексирование данных между приложениями и сетью;

o проверка целостности полученных данных;

o восстановление нарушенного порядка данных;

o подтверждение успешного получения данных;

o регулирование скорости передачи данных;

o измерение временных характеристик;

o координация повторной передачи данных, поврежденных или потерянных в процессе пересылки.

Протокол UDP

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

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

Маска подсети

Маска подсети выявляет из IP-адреса подсеть и номер хоста.

Например, IP-адрес имеет маску . В таком случае формат записи будет выглядеть так [192.168.38.2/24]. Число «24» – это количество бит в маске. Восемь бит равняется одному октету, который также может называться байтом.

Если подробнее, то маску подсети можно представить в двоичной системе счисления таким образом: . В ней имеется четыре октета, и запись состоит из «1» и «0». Если сложить количество единиц, то получим в сумме «24». К счастью, считать по единице не обязательно, ведь в одном октете – 8 значений. Видим, что три из них заполнены единицами, складываем и получаем «24».

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

Рассмотрим небольшой пример. Есть IP-адрес и маска подсети . Считаем и записываем: [192.168.46.2/24]. Теперь сопоставляем маску с IP-адресом. Те октеты маски, в которых все значения равны единице (255) оставляют соответствующие им октеты в IP-адресе без изменения. Если же в значении нули (0), то октеты в IP-адресе также становятся нулями. Таким образом, в значении адреса подсети получаем .

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

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

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

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

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

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

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

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

Выводы

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

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

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

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