Почему нельзя отправлять udp-пакеты через браузер?

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!

Differences in Data Transfer Features

TCP ensures a reliable and ordered delivery of a stream of bytes from user to server or vice versa. UDP is not dedicated to end to end connections and communication does not check readiness of receiver.

Reliability

TCP is more reliable since it manages message acknowledgment and retransmissions in case of lost parts. Thus there is absolutely no missing data. UDP does not ensure that communication has reached receiver since concepts of acknowledgment, time out and retransmission are not present.

Ordering

TCP transmissions are sent in a sequence and they are received in the same sequence. In the event of data segments arriving in wrong order, TCP reorders and delivers application. In the case of UDP, sent message sequence may not be maintained when it reaches receiving application. There is absolutely no way of predicting the order in which message will be received.

Connection

TCP is a heavy weight connection requiring three packets for a socket connection and handles congestion control and reliability. UDP is a lightweight transport layer designed atop an IP. There are no tracking connections or ordering of messages.

Method of transfer

TCP reads data as a byte stream and message is transmitted to segment boundaries. UDP messages are packets which are sent individually and on arrival are checked for their integrity. Packets have defined boundaries while data stream has none.

Error Detection

UDP works on a «best-effort» basis. The protocol supports error detection via checksum but when an error is detected, the packet is discarded. Retransmission of the packet for recovery from that error is not attempted. This is because UDP is usually for time-sensitive applications like gaming or voice transmission. Recovery from the error would be pointless because by the time the retransmitted packet is received, it won’t be of any use.

TCP uses both error detection and error recovery. Errors are detected via checksum and if a packet is erroneous, it is not acknowledged by the receiver, which triggers a retransmission by the sender. This operating mechanism is called Positive Acknowledgement with Retransmission (PAR).

Протоколы передачи видео

1. потоковые протоколы;
2. cегментные протоколы.

Потоковые протоколыRTMP, webRTC, RTSP/RTPсегментных протоколов

Потоковые протоколы

он использует TCPгарантирует доставку и последовательность пакетовизъять их оттуда нельзяTCP крайне не подходит для стриминга

• 1,1 Мбит/с трафика;
• 0,1% packet loss;
• 300 мс средний RTT.

среднедневной процент потери пакетов более 3%на TCP делать не будемПротокол WebRTCпренебрегает потерямиRTP-стримингНо это очень сложно

Сегментные протоколы

MPEG-DashHLS188 байт26 млн пакетоввсегда появляется задержкарешение использовать фрагментный стриминг для трансляции не очень хорошее

• latency, который они дают между трансляцией и смотрящим;
• complexity (сложность).

Что мы хотим?

Какие есть еще варианты?

1. Многопоточность, то есть мы имеем несколько потоков — управляющий, видео, аудио.
2. Опциональная гарантия доставки — управляющий поток имеет 100% гарантию, видео нам нужно меньше всего — мы там можем дропать фрейм, аудио нам все-таки бы хотелось.
3. Приоритезация потоков — чтобы аудио уходило вперед, а управляющий вообще летел.
4. Опциональное шифрование: или все данные, или только заголовки и критичные данные.

чем меньше время ожидания, тем хуже качество

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)  # Привязка адреса и порта к сокету.

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

SCTP[править]

SCTP (Stream Control Transmission Protocol — протокол передачи с управлением потока) — протокол транспортного уровня. Выполняет те же функции, что и протоколы TCP и UDP. Но объединяет при этом их преимущества, лишает недостатков и добавляет новые возможности.

Отличия от протоколов TCP и UDP:

Основные преимущества (пояснения к таблице):

• Сохранение границ — в протоколе TCP данные передаются непрерывным потоком байт, читаются так же, поэтому программист должен сам следить за тем, как расставлять границы в этом потоке и разделать куски данных. SCTP позволяет ставить границы и обрабатывать данные пакетами, как в UDP. Но при этом гарантирует порядок доставки пакетов, обеспечивает надёжность и ориентирован на соединения. Упорядоченность пакетов, кстати, можно отключить для повышения скорости.
• Multihoming (многолинейность, множественная адресация, см. иллюстрацию ниже) — SCTP позволяет устанавливать соединение к одному серверу по разным линиям связи (например, по Wi-Fi и по Ethernet). Таким образом, если одна линия связи отвалится (скорей всего Wi-Fi), то соединение не разорвётся. Это так же позволяет передавать данные сразу по нескольким линиям, что увеличивает скорость передачи. Если в TCP одна линия связи оборвётся, то соединение будет потеряно, придётся устанавливать новое.

• Multithreading (многопоточность) — позволяет передавать несколько потоков в рамках одной ассоциации (ассоциацией в SCTP называется соединение между двумя хостами). Например в TCP данные и служебная информация передаются по одному соединению. Поэтому задержка в получении служебнной информации может быть вызвана текущей передачей данных (например, ACK может не прийти вовремя, поэтому мы пошлём дупликат). Такая проблема называется head-of-line blocking, HOL. Многопоточность позволяет передавать эти данные независимо, что приведёт к лучшему использованию доступных ресурсов.
• 4-way handshake — протокол TCP подвержен SYN-flood атакам. Злоумышленник шлёт много пакетов в короткое время для запроса TCP соединения (запрос на соединение помечен битом SYN в заголовке, поэтому и SYN-flood). Но при этом не подтверждает установление соединения. Таким образом на сервере образуются полуоткрытые соединения. Они закрываются сами по истечению таймаута. Но цель злоумышленника состоит в том, чтобы создать как можно больше таких соединений, не давая тем самым создавать новые валидные соединения из-за ограничения в их количестве на стороне сервера (сервер не может иметь бесконечное число соединений, а если сделать таймаут на обрыв слишком маленьким, то валидные соединения могут отваливаться раньше времени, что тоже нехорошо, и это всё делает syn-атаки возможными). В SCTP используется не тройное рукопожатие, а четверное (из разряда: «я хочу установить соединение — ты точно хочешь установить соединение? — да, я точно хочу установить соединение — ну тогда ладно»). Таким образом за короткий промежуток времени нельзя создать много новых соединений.

В SCTP не бывает полузакрытых соединений, как в TCP. Если мы закрываем соединение, то сразу в обе стороны.

К сожалению, несмотря на все преимущеста, протокол SCTP не получил пока широкого распространения. Это связано с инертностью (TCP работает, зачем менять?) и сложностью поддержки на аппаратном уровне (например, вся обёртка сетевых протоколов, те же фаерволы, имеют правила в духе «пропускать только UDP, TCP» пакеты; для примера можно вспомнить, как это используется в NAT).

Difference between TCP and UDP

Here are the main differences between UDP vs TCP:

Difference between UDP and TCP

TCP	UDP
It is a connection-oriented protocol.	It is a connectionless protocol.
TCP reads data as streams of bytes, and the message is transmitted to segment boundaries.	UDP messages contain packets that were sent one by one. It also checks for integrity at the arrival time.
TCP messages make their way across the internet from one computer to another.	It is not connection-based, so one program can send lots of packets to another.
TCP rearranges data packets in the specific order.	UDP protocol has no fixed order because all packets are independent of each other.
The speed for TCP is slower.	UDP is faster as error recovery is not attempted.
Header size is 20 bytes	Header size is 8 bytes.
TCP is heavy-weight. TCP needs three packets to set up a socket connection before any user data can be sent.	UDP is lightweight. There are no tracking connections, ordering of messages, etc.
TCP does error checking and also makes error recovery.	UDP performs error checking, but it discards erroneous packets.
Acknowledgment segments	No Acknowledgment segments
Using handshake protocol like SYN, SYN-ACK, ACK	No handshake (so connectionless protocol)
TCP is reliable as it guarantees delivery of data to the destination router.	The delivery of data to the destination can’t be guaranteed in UDP.
TCP offers extensive error checking mechanisms because it provides flow control and acknowledgment of data.	UDP has just a single error checking mechanism which is used for checksums.

Different Applications of TCP and UDP

TCP vs. UDP for Game Servers

For massively multiplayer online (MMO) games, developers often have to make an architectural choice between using UDP or TCP persistent connections. The advantages of TCP are persistent connections, reliability, and being able to use packets of arbitrary sizes. The biggest problem with TCP in this scenario is its congestion control algorithm, which treats packet loss as a sign of bandwidth limitations and automatically throttles the sending of packets. On 3G or Wi-Fi networks, this can cause a significant latency.

Experienced developer Christoffer Lernö weighed the pros and cons and recommends the following criteria to choose whether to use TCP or UDP for your game:

• Use HTTP over TCP for making occasional, client-initiated stateless queries when it’s OK to have an occasional delay.
• Use persistent plain TCP sockets if both client and server independently send packets but an occasional delay is OK (e.g. Online Poker, many MMOs).
• Use UDP if both client and server may independently send packets and occasional lag is not OK (e.g. Most multiplayer action games, some MMOs).

Протоколы и порты

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

Система доменных имен (DNS RFC 1034-1035: порт 53)

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

Протокол динамической конфигурации хоста (DHCP RFC 2131: порт 67/68)

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

Тривиальный протокол передачи файлов (TFP RFC 1350: порт 69)

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

Простой протокол сетевого управления (SNMP RFC 1901-1908, 3411-3418: порт 161-/162)

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

Протокол сетевого времени (NTP RFC 5905: порт 123)

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

Устройство позволяет без особых усилий устранять неполадки на разных устройствах, поскольку часы точны, что делает NTP жизненно важной частью сетевых систем

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

Что такое порты TCP и UDP?

TCP и UDP относятся к протоколу транспортного уровня, используемому для сквозной связи между двумя хостами, порты являются частью сегмента TCP или дейтаграммы UDP для правильной установки связи. Мы могли бы сказать, что «порты» — это что-то вроде «дверей» для определенной службы, независимо от того, используем ли мы TCP или UDP, поскольку оба протокола используют порты

Сами порты не опасны, порт является портом, и не имеет значения, является ли он портом 22 или портом 50505, что наиболее важно, так это использование, которое дается порту, опасно иметь порт, открытый для служба прикладного уровня, которая не защищена, потому что любой может подключиться к этой службе и использовать уязвимости или взломать нас напрямую. Конечно, всегда необходимо, чтобы если мы открыли порт для Интернета, мы контролировали трафик с помощью IDS / IPS для обнаружения возможных атак и обновляли программу, которая прослушивает этот порт

Как в TCP, так и в UDP у нас есть в общей сложности 65535 доступных портов, у нас есть классификация в зависимости от используемого номера порта, поскольку некоторые порты обычно называются «известными», и они зарезервированы для определенных приложений, хотя есть много других портов. Они обычно используются различным программным обеспечением для связи как в локальной сети, так и через Интернет. У нас также есть зарегистрированные порты и временные порты.

Известные порты

Известные порты в диапазоне от порта 0 до 1023 регистрируются и назначаются Управлением по присвоению номеров Интернета (IANA). Например, в этом списке портов есть порт 20 для FTP-Data, порт 21 для FTP-Control, порт 22 для SSH, порт 23 для Telnet, порт 80 и 443 для Интернета (HTTP и HTTPS соответственно), а также почта. port среди многих других протоколов прикладного уровня.

Зарегистрированные порты

Зарегистрированные порты варьируются от порта 1024 до порта 49151. Основное отличие этих портов состоит в том, что разные организации могут делать запросы в IANA, чтобы предоставить им определенный порт по умолчанию, и он будет назначен для использования с определенным приложением. Эти зарегистрированные порты зарезервированы, и никакая другая организация не сможет зарегистрировать их снова, однако они обычно являются «частично зарезервированными», потому что, если организация прекращает их использовать, они могут быть повторно использованы другой компанией. Наглядным примером зарегистрированного порта является 3389, который используется для RDP-подключений к удаленному рабочему столу в Windows.

Эфемерные порты

Диапазон этих портов от 49152 до 65535, этот диапазон портов используется клиентскими программами, и они постоянно используются повторно. Этот диапазон портов обычно используется при передаче на известный или зарезервированный порт с другого устройства, такого как пассивный Интернет или FTP. Например, когда мы посещаем веб-сайт, порт назначения всегда будет 80 или 443, но порт источника (чтобы данные знали, как возвращаться) использует порт эпиметра.

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

Протокол управления передачей (TCP) использует набор каналов связи, называемых портами, для управления системным обменом сообщениями между несколькими различными приложениями, работающими на одном физическом устройстве. В отличие от физических портов на компьютерах, таких как USB-порты или Ethernet-порты, TCP-порты являются виртуально программируемыми записями, пронумерованными от 0 до 65535.

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

TCP порт 0

TCP фактически не использует порт 0 для сетевого взаимодействия, но этот порт хорошо известен сетевым программистам. Программы сокетов TCP используют порт 0 по соглашению, чтобы запросить доступный порт, который будет выбран и выделен операционной системой. Это избавляет программиста от необходимости выбирать («жесткий код») номер порта, который может не сработать в данной ситуации.

TCP-порты 20 и 21

FTP-серверы используют TCP-порт 21 для управления своей стороной сеансов FTP. Сервер прослушивает команды FTP, поступающие на этот порт, и отвечает соответствующим образом. В активном режиме FTP сервер дополнительно использует порт 20 для инициирования передачи данных обратно клиенту FTP.

TCP-порт 22

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

TCP-порт 23

Порт 23 управляет telnet , текстовой системой для входа в удаленные системы. Хотя современные подходы к удаленному доступу основаны на Secure Shell на порте 22, порт 23 остается зарезервированным для более старого и менее безопасного приложения telnet.

TCP-порты 25, 110 и 143

На принимающей стороне порт 110 управляет протоколом почтовой связи версии 3, а порт 143 выделен для протокола доступа к почте через Интернет. POP3 и IMAP контролируют поток электронной почты с сервера вашего провайдера на ваш почтовый ящик.

Безопасные версии SMTP и IMAP различаются в зависимости от конфигурации, но порты 465 и 587 являются общими.

UDP порты 67 и 68

Серверы протокола динамической конфигурации хоста используют UDP-порт 67 для прослушивания запросов, в то время как клиенты DHCP обмениваются данными через UDP-порт 68.

TCP-порты 80 и 443

Возможно, самый известный порт в Интернете – TCP-порт 80 – это значение по умолчанию, которое веб-серверы HyperText Transfer Protocol прослушивают для запросов веб-браузера.

Порт 443 по умолчанию для безопасного HTTP.

UDP-порты 161 и 162

По умолчанию простой протокол управления сетью использует UDP-порт 161 для отправки и получения запросов в управляемой сети. Он использует UDP-порт 162 по умолчанию для получения прерываний SNMP от управляемых устройств.

TCP-порт 194

Несмотря на то, что такие инструменты, как приложения для обмена сообщениями на смартфонах, такие как Slack и Microsoft Teams, стали использовать Internet Relay Chat, IRC по-прежнему пользуется популярностью среди людей по всему миру. По умолчанию IRC использует порт 194.

Порты выше 1023

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

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

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

	TCP	UDP
Акроним для	Протокол управления передачей	Протокол пользовательских дейтаграмм или универсальный протокол дейтаграмм
соединение	Протокол управления передачей — это протокол, ориентированный на соединение.	Протокол пользовательских дейтаграмм — это протокол без установления соединения.
функция	Как сообщение проходит через Интернет с одного компьютера на другой. Это на основе соединения.	UDP также является протоколом, используемым при передаче или передаче сообщений. Это не основано на соединении, что означает, что одна программа может отправлять загрузку пакетов другой, и это будет концом отношений.
использование	TCP подходит для приложений, которые требуют высокой надежности, а время передачи относительно менее критично.	UDP подходит для приложений, которые нуждаются в быстрой и эффективной передаче, таких как игры. Характер UDP без сохранения состояния также полезен для серверов, которые отвечают на небольшие запросы от огромного числа клиентов.
Использование другими протоколами	HTTP, HTTP, FTP, SMTP, Telnet	DNS, DHCP, TFTP, SNMP, RIP, VOIP.
Упорядочение пакетов данных	TCP переставляет пакеты данных в указанном порядке.	UDP не имеет собственного порядка, так как все пакеты независимы друг от друга. Если заказ требуется, он должен управляться прикладным уровнем.
Скорость передачи	Скорость TCP ниже, чем UDP.	UDP работает быстрее, потому что восстановление после ошибки не предпринимается. Это протокол «лучшее из возможного».
надежность	Существует абсолютная гарантия того, что переданные данные остаются нетронутыми и поступают в том же порядке, в котором они были отправлены.	Нет никакой гарантии, что отправленные сообщения или пакеты дойдут вообще.
Размер заголовка	Размер заголовка TCP составляет 20 байт.	Размер заголовка UDP составляет 8 байт.
Общие поля заголовка	Исходный порт, порт назначения, контрольная сумма	Исходный порт, порт назначения, контрольная сумма
Потоковая передача данных	Данные считываются как поток байтов, отличительные признаки не передаются к границам сигнального сообщения (сегмента).	Пакеты отправляются индивидуально и проверяются на целостность только в случае их поступления. Пакеты имеют определенные границы, которые учитываются при получении, что означает, что операция чтения в сокете-получателе приведет к тому, что сообщение будет полностью отправлено.
Вес	TCP тяжелый. TCP требует три пакета для установки сокетного соединения, прежде чем любые пользовательские данные могут быть отправлены. TCP управляет надежностью и контролем перегрузки.	UDP легкий. Нет упорядочения сообщений, нет отслеживания соединений и т. Д. Это небольшой транспортный уровень, разработанный поверх IP.
Управление потоком данных	TCP делает управление потоком. TCP требует три пакета для установки сокетного соединения, прежде чем любые пользовательские данные могут быть отправлены. TCP управляет надежностью и контролем перегрузки.	У UDP нет опции для управления потоком
Проверка ошибок	TCP проверяет и исправляет ошибки. Ошибочные пакеты повторно передаются от источника к месту назначения.	UDP выполняет проверку ошибок, но просто отбрасывает ошибочные пакеты. Ошибка восстановления не предпринимается.
поля	1. Порядковый номер, 2. Номер ACK, 3. Смещение данных, 4. Зарезервировано, 5. Бит управления, 6. Окно, 7. Срочный указатель 8. Опции, 9. Заполнение, 10. Контрольная сумма, 11. Порт источника, 12. Порт назначения	1. Длина, 2. Порт источника, 3. Порт назначения, 4. Контрольная сумма
Подтверждение	Сегменты подтверждения	Нет подтверждения
Рукопожатие	SYN, SYN-ACK, ACK	Нет рукопожатия (протокол без установления соединения)

Недостатки UDP

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

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

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

• Использование сессий. Ориентированность TCP на соединения поддерживается сеансами между хостами. TCP использует идентификатор сеанса, позволяющий отслеживать соединения между двумя хостами. UDP не имеет поддержки сеансов из-за своей природы, не ориентированной на соединения.

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

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

• Управление потоком. В UDP управление потоком отсутствует, в результате плохо спроектированное UDP-приложение может захватить значительную часть пропускной способности сети.

TCP— Transmission Control Protocol

Обмен данными, ориентированный на соединения, может использовать надежную связь, для обеспечения которой протокол уровня 4 посылает подтверждения о получении данных и запрашивает повторную передачу, если данные не получены или искажены. Протокол TCP использует именно такую надежную связь. TCP используется в таких прикладных протоколах, как HTTP, FTP, SMTP и Telnet.

Протокол TCP требует, чтобы перед отправкой сообщения было открыто соединение. Серверное приложение должно выполнить так называемое пассивное открытие (passive open), чтобы создать соединение с известным номером порта, и, вместо того чтобы отправлять вызов в сеть, сервер переходит в ожидание поступления входящих запросов. Клиентское приложение должно выполнить активное открытие (active open), отправив серверному приложению синхронизирующий порядковый номер (SYN), идентифицирующий соединение. Клиентское приложение может использовать динамический номер порта в качестве локального порта.

Сервер должен отправить клиенту подтверждение (ACK) вместе с порядковым номером (SYN) сервера. В свою очередь клиент отвечает АСК, и соединение устанавливается.

После этого может начаться процесс отправки и получения сообщений. При получении сообщения в ответ всегда отправляется сообщение АСК. Если до получения АСК отправителем истекает тайм-аут, сообщение помещается в очередь на повторную передачу.

Поля заголовка TCP перечислены в следующей таблице:

Заголовок TCP

Поле	Длина	Описание
Порт источника	2 байта	Номер порта источника
Порт назначения	2 байта	Номер порта назначения
Последовательный номер	4 байта	Последовательный номер генерируется источником и используется назначением, чтобы переупорядочить пакеты для создания исходного сообщения и отправить подтверждение источнику.
Номер подтверждения	4 байта	Если установлен бит АСК поля «Управление», в данном поле содержится следующий ожидаемый последовательный номер.
Смещение данных	4 бита	Информация о начале пакета данных.
Резерв	6 битов	Резервируются для будущего использования.
Управление	6 битов	Биты управления содержат флаги, указывающие, верны ли поля подтверждения (АСК), указателя срочности (URG), следует ли сбрасывать соединение (RST), послан ли синхронизирующий последовательный номер (SYN) и т. д.
Размер окна	2 байта	В этом поле указывается размер приемного буфера. Используя подтверждающие сообщения, получатель может информировать отправителя о максимальном размере данных, которые тот может отправить.
Контрольная сумма	2 байта	Контрольная сумма заголовка и данных; по ней определяется, был ли искажен пакет.
Указатель срочности	2 байта	В этом поле целевое устройство получает информацию о срочности данных.
Опции	переменная	Необязательные значения, которые указываются при необходимости.
Дополнение	переменная	В поле дополнения добавляется столько нулей, чтобы заголовок заканчивался на 32-битной границе.

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

Протокол TCP имеет встроенную возможность надежной доставки. Если сообщение не отправлено корректно, мы получим сообщение об ошибке. Протокол TCP определен в RFC 793.