Протоколы tcp и udp: в чем разница

Разница и взаимосвязь между TCP / UDP и HTTP / WebScoket

Прежде всего, из вышесказанного мы можем знать, что TCP / UDP принадлежит к одному транспортному уровню, а HTTP / WebSocket принадлежит к одному транспортному уровню, поэтому мы разделим его на две группы и сравниваем их по отдельности.

TCP

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

Три рукопожатия:

  • Первое рукопожатие: клиент отправляет на сервер пакет синхронизации (seq = x) и входит в состояние SYN_SEND, ожидая подтверждения от сервера;

  • Второе рукопожатие: сервер получает пакет syn, он должен подтвердить SYN клиента (ack = x + 1), и в то же время отправить пакет SYN (seq = y), то есть пакет SYN + ACK, и сервер переходит в состояние SYN_RECV;

  • Третье рукопожатие: клиент получает пакет SYN + ACK от сервера и отправляет на сервер пакет подтверждения ACK (ack = y + 1). После отправки пакета клиент и сервер переходят в состояние ESTABLISHED, и трехстороннее рукопожатие завершается.

UDP

UDP — это протокол без установления соединения, то есть UDP не отвечает за отправку данных непосредственно на указанный IP-адрес и не гарантирует, что данные могут достигать

Разница между TCP и UDP

  • TCP ориентирован на канал, UDP ориентирован на датаграммы. TCP требует трехстороннего рукопожатия, чтобы установить канал для отправки, а UDP отправляет информацию напрямую, не устанавливая ссылку
  • Передача TCP безопасна, передача UDP небезопасна, TCP будет автоматически ретранслировать, если произойдет потеря пакета, восстановите соединение, UDP не будет
  • TCP в порядке, UDP не в порядке, прием данных TCP может быть до и после, но в итоге все полученные данные будут отсортированы, UDP — нет.
  • TCP может выполнять только связи один-к-одному, UDP может устанавливать связи один-ко-многим, многие-к-одному, многие-ко-многим и один-к-одному.
  • Заголовок TCP по умолчанию составляет 20 байтов, самый длинный — 40 байтов, а заголовок UDP — 8 байтов.
  • TCP может выполнять контроль перегрузки, но UDP не может выполнять контроль перегрузки (что такое контроль перегрузки, здесьПонимание контроля перегрузки и управления потоком)
  • Поскольку TCP передается в потоковом режиме, нет ограничений на размер передаваемых данных, а UDP передается в пакетах, а размер передачи ограничен.

в заключение

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

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

HTTP

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

Протокол WebSocket на самом деле предназначен для достиженияПолнодуплексная связь браузера и сервера, Можно сказать, оптимизировать одностороннюю короткую ссылку HTTP. То есть браузер и серверМогут отправлять информацию друг другу одновременно, могут устанавливать постоянное состояние связи, Вам нужно только устанавливать ссылку через HTTP каждый раз, когда вы ее открываете, и вы можете непрерывно передавать данные.

Сетевые протоколы 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 и пр.

Что такое протокол UDP?

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

Автором протокола UDP является Дэвид П. Рид созданный в 1980 году.

Чувствительные ко времени приложения часто используют UDP (видеоданные), так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. Также потеря одного или нескольких кадров, при передаче видеоданных по UDP, не так критична, в отличии от передачи бинарных файлов, где потеря одно пакета может привести к искажению всего файла. Еще одним преимуществом протокола UDP является то, что длина заголовка UDP составляет 4 байта, а у TCP протокола — 20 байт.

UDP сообщения инкапсулируются и передаются в IP дейтаграммы.

Эффекты

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

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

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

Недостатки

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

Как работают TCP и UDP

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

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

Протоколы UDP и TCP – в чем разница?

Несмотря на то, что протоколы UDP и TCP ориентированы на выполнение одной задачи – передачу данных, между ними существует ряд принципиальных отличий.

  1. Процесс установки соединения. В UDP в нем нет необходимости, в то время как TCP нуждается в обязательной процедуре начала сеанса, состоящей из трех этапов.
  2. Гарантия обмена трафиком. TCP отправляет запрос на предмет целостности данных – если в ответ поступает запрос о потерянных пакетах, они будут отправлены повторно. За счет этого обеспечивается абсолютная гарантия целостной передачи. Использование UDP, в свою очередь, может привести к потере некоторого количества пакетов.
  3. Управление и контроль потока. TCP осуществляет комплексный контроль и управление потоком информации, а в UDP это не нужно.
  4. Порядок доставки. Специфика TCP заключается в том, что все пакеты отправляются в формате строгой очередности. UDP доставляет сообщения в виде не упорядоченных датаграмм.
  5. Уведомление о перегрузках. Если в рамках передачи данных возникнут перегрузки, TCP отправит соответствующее уведомление. Протокол UDP не предоставляет какой-либо защиты от перегрузки.
  6. Сохранение границ переданных сообщений. Протокол TCP хоть и не может сохранить границы переданных сообщений, предоставляет гарантию их целостности. Применение протокола UDP предусматривает сохранение границ каждой пересланной датаграммы.
  7. Функция сборки и сегментации пакетов передаваемой информации. Поддерживается только в рамках протокола TCP.
  8. Процедура проверки достижимости. Является обязательной только для протокола TCP, в то время как протокол UDP физически не поддерживает ее.
  9. Взаимодействие с соединениями полуоткрытого типа. В рамках протокола TCP никогда не происходит повторная синхронизация. А вот протокол UDP устанавливает соединение методом повторной передачи запроса к конечному пользователю.

How TCP and UDP work

A TCP connection is established via a , which is a process of initiating and acknowledging a connection. Once the connection is established data transfer can begin. After transmission, the connection is terminated by closing of all established virtual circuits.

UDP uses a simple transmission model without implicit hand-shaking dialogues for guaranteeing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Unlike TCP, UDP is compatible with packet broadcasts (sending to all on local network) and multicasting (send to all subscribers).

Что такое маска адреса (подсеть)

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

Маска — это параметр, который сообщает программному обеспечению о том, сколько компьютеров объединено в данную группу (подсеть). Маска адреса имеет такую же структуру как и сам IP-адрес: это набор из четырех групп чисел, каждое из которых может быть в диапазоне от 0 до 255. При этом, чем меньше значение маски, тем больше компьютеров объединено в данную подсеть. Для сетей небольших компаний маска обычно имеет вид 255.255.255.x (например, 255.255.255.224). Маска сети присваивается компьютеру одновременно с IP-адресом. Так, например, сеть 192.168.0.0 с маской 255.255.255.0 может содержать в себе компьютеры с адресами от 192.168.0.1 до 192.168.254. А сеть 192.168.0.0 с маской 255.255.255.128 допускает адреса от 192.168.0.1 до 192.168.0.127. Думаю, смысл понятен. Как правило сети с небольшим возможным числом компьютеров используются провайдерами с целью экономии IP-адресов. Например, клиенту, может быть назначен адрес с маской 255.255.255.252. Такая подсеть содержит в себе только два компьютера.

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

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

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

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

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

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

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

bind()¶

См.также

  • http://unixhelp.ed.ac.uk/CGI/man-cgi?bind+2

Связывает сокет с конкретным адресом. Когда сокет создается при помощи socket(), он ассоциируется с некоторым семейством адресов, но не с конкретным адресом. До того как сокет сможет принять входящие соединения, он должен быть связан с адресом. bind() принимает три аргумента:

  1. sockfd — дескриптор, представляющий сокет при привязке
  2. serv_addr — указатель на структуру sockaddr, представляющую адрес, к которому привязываем.
  3. addrlen — поле socklen_t, представляющее длину структуры sockaddr.

Примечание

Возвращает 0 при успехе и −1 при возникновении ошибки.

Пример на Си

#include <sys/types.h>
#include <sys/socket.h>

int bind(int sockfd, const struct sockaddr *my_addr, socklen_t addrlen);

Пример на Python

server_address = ('localhost', 8080)
sock_obj.bind(server_address)  # Привязка адреса и порта к сокету.

Автоматическое получение имени хоста.

Как добиться надежного UDP

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

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

То есть сказать,Реализуйте механизм подтверждения, механизм повторной передачи и механизм подтверждения окна на уровне приложений.Если вы не используете стек протокола Linux и механизм верхнего сокета, вы должны реализовать передачу надежности путем захвата пакетов и гапсов, а затем необходимо реализовать:

  • Целостность данных -> Добавить 16 или 32-битное поле проверки CRC
  • Doodle -> плюс серийный номер пакета SEQ (номер)
  • Paining -> необходимо подтвердить и повторные механизмы повторной передачи, просто похоже на TCP ACK

Такие как:

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

Справочная статья:Как добиться УДП надежная коробка передач。

В настоящее время следующие процедуры с открытым исходным кодом используют UDP для реализации надежной передачи данных, которая является RUDP, RTP и UDT соответственно.

  • RUDP: RUDP предоставляет набор улучшений качества обслуживания данных, таких как контроль за перегрузкой, повторный механизм и алгоритм сервера разбавления, тем самым представляя перед клиентом RTP (местоположение в реальном времени) в случае потери пакетов и заложенности сети, высоким Качественный RTP поток. Несмотря на то, что не мешают характеристикам в реальном времени протокола, надежный механизм контроля заторов UDP позволяет поведению контроля потока в режиме TCP;
  • RTP: Протокол транспорта в реальном времени (RTP) предоставляет данные с функциями в реальном времени и аналоговые данные в реальном времени, такие как интерактивные видеоустройства или аналоговые данные. Приложения, как правило, работают RTP на UDP для использования их нескольких узлов и проверки услуг; оба протокола обеспечивают функцию протоколов транспортных слоев. Однако RTP можно использовать с другими подходящими базовыми сетями или транспортными протоколами. Если базовая сеть предоставляет многоадресный режим, RTP может использовать многоадресную таблицу для передачи данных в несколько направлений;
  • UDT: протокол передачи данных на основе UDP (UDT) — это протокол передачи интернет-данных. Основная цель UDT состоит в том, чтобы поддержать масштабные передачи данных по скоростной широкому пространстве сети, а стандартный протокол передачи данных в Интернете очень плохой в сети высокой пропускной способности. Как предполагает имя, UDT построен выше UDP и вводит новые механизмы контроля заложений и механизмов надежности данных. UDT — это двусторонняя протокол приложений для подключения. Он также поддерживает надежную передачу данных и частично надежную передачу данных Datagram. Поскольку UDT полностью реализован на UDP, он также может быть применен к другим приложениям, кроме высокоскоростной передачи данных, таких как технология Point-Point (P2P), проникновение брандмауэра, передача данных мультимедийных данных и многое другое.

Справочная статья:Как UDP реализует передачу надежности?。

Это связь между интервью:Сводная информация об интервью — Сеть。

Выводы

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

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

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

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector