Udp и tcp - в чем разница между этими протоколами?

Сравнение UDP и TCP

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

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

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

Ненадежный — при отправке сообщения UDP нельзя узнать, достигнет ли оно места назначения; он мог потеряться по пути. Нет концепции подтверждения, повторной передачи или тайм-аута.
Не упорядочено — если два сообщения отправлены одному и тому же получателю, порядок их доставки не может быть гарантирован.
Легковесный — сообщения не упорядочиваются, не отслеживаются соединения и т. Д. Это очень простой транспортный уровень, разработанный поверх IP.
Датаграммы — пакеты отправляются индивидуально и проверяются на целостность по прибытии. Пакеты имеют определенные границы, которые соблюдаются при получении; операция чтения в сокете-получателе даст все сообщение в том виде, в котором оно было изначально отправлено.
Нет контроля перегрузки — UDP сам по себе не избегает перегрузки. Меры по контролю за перегрузкой должны быть реализованы на уровне приложений или в сети.
Широковещательная рассылка — протокол UDP не требует установления соединения — отправленные пакеты могут быть адресованы для приема всеми устройствами в подсети.
Многоадресная рассылка — поддерживается режим многоадресной рассылки, при котором один пакет дейтаграммы может автоматически маршрутизироваться без дублирования группе подписчиков.

Стандарты

RFC — протокол дейтаграмм пользователя
RFC — Спецификация Интернет-протокола версии 6 (IPv6)
RFC — Джумбограммы IPv6
RFC — База управляющей информации для UDP
RFC — Рекомендации по использованию UDP

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

Tcp Udp отличия

Давайте рассмотрим основные отличия tcp от udp.

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

Примерами UDP приложений, например можно привести, передачу DNS зон, в Active Directory, там не требуется надежность

Очень часто такие вопросы любят спрашивать на собеседованиях, так, что очень важно знать tcp и udp отличия

Заголовок UDP

16 битный порт источника > Указание порта источника для UDP необязательно. Если это поле используется, получатель может отправить ответ этому порту.
16 битный порт назначения > Номер порта назначения
16 битная длина UDP > Длина сообщения, включая заголовок и данные.
16 битная контрольная сумма > Контрольная сумма заголовка и данных для проверки

Заголовок TCP

16 битный порт источника > Номер порта источника
16 битный порт назначения > Номер порта назначения
32 битный последовательный номер > Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
32 битный номер подтверждения > Если установлен бит АСК поля «Управление», в данном поле содержит следующий ожидаемый последовательный номер.
4 бита длина заголовка > Информация о начале пакета данных.
резерв > Резервируются для будущего использования.
16 битная контрольная сумма > Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
16 битный указатель срочности > В этом поле целевое устройство получает информацию о срочности данных.
Параметры > Необязательные значения, которые указываются при необходимости.

Размер окна позволяет экономить трафик, рассмотрим когда его значение равно 1, тут на каждый отправленный ответ, отправитель ждет подтверждения, не совсем рационально.

При размере окна 3, отправитель отправляет уже по 3 кадра, и ждет от 4, который подразумевает, что все три кадра у него есть, +1.

UDP (англ. User Datagram Protocol — протокол пользовательских датаграмм) — это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. Его IP-идентификатор — 0x11.

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

Сравнительная таблица протоколов

Закрепим новую информацию с помощью таблицы.

	OpenVPN	PPTP	SSTP	IPsec	WireGuard	SoftEther
Создатели	OpenVPN Technologies	Microsoft	Microsoft	Cisco и другие	Джейсон Донфилд	Университет Цукуба
Тип лицензии	GNU GPL (открытый исходный код)	Проприетарная	Проприетарная	Зависит от реализации	GNU GPL (открытый исходный код)	Apache License 2.0
Поддерживаемые платформы	Нативно не поддерживает ни одну ОС. Сторонние клиенты для настройки есть для Windows, Linux, macOS, iOS и Android	Windows, macOS, Linux и iOS без необходимости скачивать дополнительное ПО	Windows без необходимости скачивать дополнительное ПО	Windows, macOS, Linux и iOS без необходимости скачивать дополнительное ПО	Windows, macOS, Linux и iOS без необходимости скачивать дополнительное ПО	Windows, macOS, iOS, Linux и Android
Используемые порты	Любой TCP и UPD	TCP 1723	TCP 443	UDP 500, UDP 1701 (зависит от выполнимых задач)	Любой UPD	Любой TCP
Методы шифрования	Библиотека OpenSSL	Самый безопасный из доступных — MPPE	SSL	Самый безопасный из доступных — AES	Curve25519, ChaCha20, SipHash, BLAKE2 и Poly1305	SSL
Уязвимости	Не найдено	Атаки по словарю MSCHAP-V2 и Bit Flipping	Не найдено	Не найдено	Не найдено	Не найдено

Убедитесь, что есть потеря пакета UDP

Чтобы увидеть, имеет ли NIC пакет, вы можете использоватьВид, ищите на выходеИли жеЕсть ли соответствующее поле данных, в обычном случае числа, соответствующие этим полям, должны быть 0. Если вы видите соответствующий номер, вы объясните, что у NIC есть пакет.

Другая команда для просмотра данных потери пакета сетиЭто будет иметь его в своем выходе(Получить приемный пакет) и(Передача отправка пакета) Статистика:

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

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

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

NOTEНе количество потери пакета не равно нулю, для UDP, если существует небольшое количество потери пакета, вероятно, ожидаемое поведение, такое как скорость потерь пакетов (количество пакетов для пакетов / приема), составляет один миллион еще меньше.

Результаты теста на задержку по времени в детальном рассмотрении

Рисунок 7: Программное кодирование / декодирование – тестовая система с программным энкодером KB и декодером VLC

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

Германия – Сидней – Германия

Чтобы обеспечить доставку стабильного потока видео и аудио в Сидней из Германии с помощью RTMP протокола, размер буфера приемника на сервере Wowza Streaming Engine пришлось увеличить до 260 000 байтов. Это в четыре раза больше, чем его объем по умолчанию – 65 000 байтов. Так как в основе теста лежала передача данных туда и обратно, принимающий буфер VLC Player также пришлось увеличить с 250 мс (значение по умолчанию) до 2000 мс. Ниже этих значений качество передаваемого потока значительно ухудшалось из-за аудио и видео артефактов или даже не воспроизводилось вообще.

Германия – Калифорния – Германия

Хотя время прохождения потоком данных пути в Калифорнию туда и обратно было приблизительно равно половине такого же времени при передаче данных в Австралию, не только это время влияет на итоговую величину задержку. Поток данных обратно в Германию казалось испытывал сильный джиттер, что привело к отклонению доставки индивидуальных пакетов данных во времени. Хотя передача данных из Германии в Калифорнию работала без перебоев с использованием размера буфера по умолчанию – 65 000 байт, обратный путь потребовал увеличение буферизации до 650 мс в проигрывателе VLC Player.

Германия – Вирджиния – Германия

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

В зависимости от использования пропускной способности каналов передачи данных, ваш видеосигнал может не всегда проходить по кратчайшему интернет-пути, но быстрее, чем по прямому географическому маршруту. Хотя время передачи данных до места назначения было незначительно выше, чем в калифорнийском тесте, связь была более стабильной с меньшим джиттером и позволяла использовать меньшие объемы буферов для RTMP потоков. В этом случае видеопоток был стабильным со стандартными значениями по умолчанию – объемом буфера в 65000 байт на сервере Wowza Streaming Engine и 250 мс для проигрывателя VLC Player.

Тюрингия – Франкфурт – Тюрингия

В тесте при отправке потока данных из Тюрингии в Германии в датацентр AWS во Франкфурте, время передачи данных до места назначения и обратно (RTT) составило всего 17 мс. Задержка по времени при передаче RTMP данных туда и обратно не сильно уменьшилась по сравнению с результатами для Вирджинии или Калифорнии. Однако протокол SRT смог выиграть более одной секунды при меньшем значении времени передачи данных до пункта назначения (RTT) по сравнению с местоположениями в США.

В этих тестах, SRT протокол был в 2,5-3,2 раза быстрее по сравнению с RTMP протоколом

Рисунок 8: Результаты теста на определение задержки по времени при передаче данных туда и обратно с использованием программного энкодера и декодера

Недостатки UDP

По сравнению с TCP UDP имеет следующие недостатки:

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

Напротив, протокол TCP ориентирован на установление соединений и обеспечивает взаимодействие между подключенными к сети хостами, используя пакеты. В TCP применяются сигналы квитирования, позволяющие проверить успешность транспортировки данных.
Использование сессий. Ориентированность TCP на соединения поддерживается сеансами между хостами. TCP использует идентификатор сеанса, позволяющий отслеживать соединения между двумя хостами. UDP не имеет поддержки сеансов из-за своей природы, не ориентированной на соединения.
Надежность. UDP не гарантирует, что адресату будет доставлена только одна копия данных. Чтобы отправить конечной системе большой объем данных, UDP разбивает его на небольшие части. UDP не гарантирует, что эти части будут доставлены по назначению в том же порядке, в каком они создавались в источнике. Напротив, TCP вместе с номерами портов использует порядковые номера и регулярно отправляемые подтверждения, гарантирующие упорядоченную доставку данных.
Безопасность. TCP более защищен, чем UDP. Во многих организациях брандмауэры и маршрутизаторы не пропускают пакеты UDP. Это связано с тем, что хакеры могут воспользоваться портами UDP, не устанавливая явных соединений.
Управление потоком. В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.

Эффекты

Как уникальный протокол, протокол User Datagram Protocol имеет свои плюсы и минусы. Некоторые из наиболее распространенных, с которыми вы столкнетесь, объясняются ниже.

Преимущества

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

Недостатки

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

SSTP

Secure Socket Tunneling Protocol — модифицированная версия PPTP. Эдакая надстройка старого протокола, которая должна была стать не только духовным продолжением ранее существовавшей технологии, но и исправлением всех ошибок, допущенных в «предыдущей версии».

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

Помогает SSL-шифрование. При подключении к SSTP вся информация отправляется через TCP-порт 443. Такой подход делает его полезным при необходимости создавать безопасные подключения со странами, где большая часть VPN-сервисов заблокирована или запрещена законом.

Многочисленные тестирования показали, что SSTP может передавать данные на высокой скорости (если канал свободен) и быстро восстанавливать соединение, если то неожиданно оборвалось. По этим показателям протокол стремится к OpenVPN, но не дотягивает ввиду некоторых ограничений технологии.

Secure Socket Tunneling Protocol доступен на операционных системах Windows, Linux и BSD, но поддерживается ограниченным количеством сервисов. Их тяжело найти, а еще они зачастую обходятся дороже альтернатив. Отсюда и скромная аудитория SSTP, которая и не планирует расти в ближайшем будущем из-за продвинутости конкурентов.

Применяемый

Размер буфера UDP системы упоминается выше, параметр регулировки SYSCTL — это просто максимальная допустимая система, каждое приложение должно устанавливать значение размера буфера сокета при создании сокета.

Система Linux поставит принятые пакеты в буфер сокета, а приложение постоянно читает пакеты из буфера. Таким образом, есть два и приложения, связанные с приложениями, которые влияют на размер размера буфера разъема и приложение прочитал пакет.

В течение первого вопроса вы можете установить размер буфера приема розетки, когда приложение инициализирует сокет, например, следующий код устанавливает буфер сокета до 20 МБ:

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

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

Для приложений пакеты обработки должны принимать асинхронный путь

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

TCP vs self-made UDP. Final fighting

Send/recv buffer: для своего протокола можно делать mutable buffer, с TCP будут проблемы с buffer bloat.
Congestion control вы можете использовать существующие. У UDP они любые.
Новый Congestion control трудно добавить в TCP, потому что нужно модифицировать acknowledgement, вы не можете это сделать на клиенте.
Мультиплексирование — критичная проблема. Случается head-of-line blocking, при потере пакета вы не можете мультиплексировать в TCP. Поэтому HTTP2.0 по TCP не должен давать серьезного прироста.
Случаи, когда вы можете получить установку соединения за 0-RTT в TCP крайне редки, порядка 5 %, и порядка 97 % для self-made UDP.

IP Migration — не такая важная фича, но в случае сложных подписок и хранения состояния на сервере она однозначно нужна, но в TCP никак не реализована.
Nat unbinding не в пользу UDP. В этом случае в UDP надо часто делать ping-pong пакеты.
Packet pacing в UDP простой, пока нет оптимизации, в TCP эта опция не работает.
MTU и исправление ошибок и там, и там примерно сравнимы.
По скорости TCP, конечно, быстрее, чем UDP сейчас, если вы раздаете тонну трафика. Но зато какие-то оптимизации очень долго доставляются.

Выбираем UDP!

Сканирование заблокированных портов

Это позволяет определить, какие порты используются и каким приложением, но не сообщает нам, какие порты активно блокируются брандмауэром Windows.

Еще раз откройте меню «Пуск» и найдите CMD.
Кликните правой кнопкой мыши CMD и запустите от имени администратора.
В открытой командной строке введите:

netsh firewall show state

Это отображение заблокированных и открытых портов в соответствии с конфигурацией вашего брандмауэра Windows.

Вы увидите примечание о том, что эта команда устарела, но новая команда не показывает нам нужную информацию. Так что на данный момент использование команды «show state» по-прежнему является самым быстрым и простым способом получить информацию о порте.

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

Откройте меню «Пуск» и найдите CMD.
Теперь кликните правой кнопкой мыши CMD и запустите от имени администратора.
В открытой командной строке введите:

netstat -ano | findstr -i SYN_SENT

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