Module 2 → Lesson 9 → Part 5 of 8
TCP и UDP простыми словами
Lesson contents
What you'll learn
Доставить пакет недостаточно
В предыдущих частях мы разобрали:
- как устройство подключается к сети;
- как данные разбиваются на пакеты;
- как маршрутизаторы передают их к сети назначения.
Но остается важный вопрос.
Представим, что Emma Lee отправляет Alex файл.
Сеть передала части 1, 2, 4, 5, а часть данных под номером 3 потерялась.
Для документа это плохо.
Если получить:
начало договора + середину + почти весь конец
отсутствующий кусок не становится менее отсутствующим.
Значит, поверх обычной доставки IP нужен механизм, который определяет:
как приложения будут обмениваться данными и что делать при потерях, задержках и изменении порядка.
Здесь появляются TCP и UDP.
IP и транспорт решают разные задачи
Очень упрощенно: данные уходят от приложения через TCP или UDP, затем через IP — в сеть.
IP в первую очередь помогает доставлять пакеты между сетями.
TCP или UDP решают другую задачу:
как организовать передачу данных между приложениями на конечных устройствах.
Что такое транспортный протокол
Два наиболее известных транспортных протокола Интернета — TCP и UDP.
Они используют разные подходы.
Начнем с TCP
TCP — Transmission Control Protocol.
Главная идея TCP:
приложение получает надежный упорядоченный поток данных, пока соединение может нормально поддерживаться.
То есть TCP старается разобраться с такими проблемами, как:
- потеря данных;
- изменение порядка;
- дублирование;
- разная скорость отправителя и получателя.
Сначала TCP устанавливает соединение
Перед обычным обменом данными стороны согласуют установление TCP-соединения.
Упрощенно: Emma говорит серверу «Хочу соединение», сервер отвечает «Хорошо, слышу тебя», а Emma подтверждает «Отлично, начинаем».
В реальном TCP это известно как three-way handshake.
Как выглядит handshake
Концептуально: клиент отправляет серверу SYN, сервер отвечает SYN-ACK, а клиент подтверждает ACK — после этого соединение считается установленным.
Запоминать три сокращения сейчас не обязательно.
Главная мысль:
перед передачей обычных данных TCP устанавливает состояние соединения между сторонами.
Что значит «соединение»
Это не означает, что между Emma и сервером появляется отдельный физический кабель.
Пакеты все так же путешествуют через обычную сеть.
TCP-соединение — это логическое состояние, которое поддерживают конечные устройства.
Например, стороны помнят:
- какие данные отправлены;
- какие получены;
- что нужно отправить повторно;
- в каком порядке собрать поток.
TCP следит за порядком
Допустим, данные отправлены в порядке 1 → 2 → 3 → 4, а сеть доставила их как 1 → 3 → 2 → 4.
TCP способен использовать служебную информацию, чтобы представить приложению данные в правильной последовательности: сеть передала 1, 3, 2, 4, а TCP восстанавливает порядок 1, 2, 3, 4, и приложение получает уже правильный поток данных.
А если часть данных потерялась?
Представим: отправлено 1 2 3 4 5, а получено 1 2 _ 4 5.
TCP способен определить, что часть ожидаемых данных отсутствует, и организовать повторную передачу.
Упрощенно: получатель сообщает «Мне не хватает данных», а отправитель повторяет необходимую часть.
Это называется retransmission — повторная передача.
- 1Sender отправляет данные 1 → 2 → 3 → 4 → 5.
- 2Receiver получает 1 → 2 → ✕ → 4 → 5 — часть данных пропала по пути.
- 3Receiver сообщает: «Мне не хватает данных» — и запрашивает недостающую часть.
- 4Sender повторяет пропавшую часть, и приложение получает полный поток 1 → 2 → 3 → 4 → 5.
Что такое подтверждение
TCP использует подтверждения получения данных.
Не нужно думать, что получатель отправляет отдельное «Спасибо!» после каждого байта.
Реальный механизм эффективнее.
Но концептуально подтверждения позволяют отправителю понимать:
какая часть потока уже дошла.
TCP не просто повторяет потерянное
У него есть и другие задачи.
Например, flow control не дает слишком быстрому отправителю завалить данными получателя, который не успевает их обрабатывать.
А congestion control адаптирует передачу к состоянию сети, чтобы не усугублять перегрузку.
Эти механизмы довольно сложны.
Нам сейчас достаточно понять:
TCP старается не просто доставить данные, но и управлять процессом надежной передачи.
Для чего это удобно
TCP хорошо подходит для сценариев, где важно получить полный корректный поток.
Например: передача файлов; работа многих прикладных протоколов; получение данных, где пропущенный фрагмент недопустим.
Если пользователь скачивает документ размером 20 MB, обычно хочется получить:
20 MB правильного документа
а не:
19,97 MB и творческую интерпретацию оставшейся части.
Но надежность имеет цену
Чтобы контролировать передачу, TCP должен:
- установить соединение;
- хранить его состояние;
- подтверждать получение;
- повторять потерянные данные;
- контролировать скорость.
Все это требует дополнительной служебной информации, обработки и иногда дополнительного времени.
И здесь появляется другой подход.
UDP
UDP — User Datagram Protocol.
UDP значительно проще.
Упрощенно: Emma отправляет данные 1, 2, 3 отдельными датаграммами одну за другой.
Нет обязательного TCP-style handshake перед каждым таким обменом.
UDP не обещает слишком многого
Сам UDP не гарантирует приложению:
- что датаграмма обязательно будет доставлена;
- что данные придут в том же порядке;
- что потерянное будет автоматически отправлено повторно;
- что одинаковая датаграмма не появится более одного раза.
То есть отправлено 1 2 3 4, а получено может быть только 1 3 4.
UDP сам по себе не говорит:
«Стоп, срочно вернемся за номером 2».
Это плохо?
Не обязательно.
Все зависит от задачи.
Представим голосовой разговор.
Emma говорит:
«Встретимся завтра в десять».
Маленькая часть аудио потерялась.
Можно выбрать один из двух вариантов.
Вариант A
Остановить воспроизведение и ждать недостающий кусок, а затем через секунду воспроизвести старый звук.
Вариант B
Продолжить получать следующий звук.
Для живого разговора иногда второй вариант полезнее.
Потому что:
своевременность может быть важнее идеальной доставки каждого фрагмента.
Поэтому UDP часто используется там, где важна задержка
Исторически и практически UDP хорошо подходит для некоторых сценариев: real-time audio/video; сетевых игр; DNS; других протоколов, которым удобна простая передача датаграмм.
Но здесь нужна важная оговорка.
UDP не означает «ненадежное приложение»
Это одна из самых распространенных ошибок.
Можно подумать: TCP = надежно, UDP = ненадежно.
Это слишком грубо.
Правильнее:
TCP предоставляет встроенные механизмы надежного упорядоченного потока.
А:
UDP сам по себе предоставляет гораздо более минимальный транспортный механизм.
Если приложению нужны дополнительные свойства, оно может реализовать их выше UDP.
Современный пример — QUIC
Некоторые современные протоколы используют UDP как основу, а необходимые механизмы надежности реализуют выше него.
Один важный пример — QUIC.
Поэтому нельзя говорить:
«UDP используется только тогда, когда потеря данных вообще не важна».
Это неверно.
И нельзя просто сказать «UDP быстрее TCP»
Еще одна популярная фраза:
UDP быстрее.
Лучше сказать точнее:
UDP имеет более простой встроенный механизм и меньший набор обязательных транспортных функций.
Но реальная скорость приложения зависит от сети, протокола приложения, алгоритмов, потерь, задержки и реализации.
Иногда система поверх UDP может быть очень сложной.
Сам факт букв UDP еще не гарантирует магическое ускорение.
Сравним TCP и UDP
| Характеристика | TCP | UDP |
|---|---|---|
| Установка соединения | Да | Нет TCP-подобного handshake |
| Встроенное упорядочивание | Да | Нет |
| Встроенная повторная передача | Да | Нет |
| Подтверждения | Да | Не в базовом UDP |
| Контроль потока | Да | Не в базовом UDP |
| Модель данных | Поток байтов | Отдельные датаграммы |
| Протокольная сложность | Выше | Ниже |
- 1TCP — connection → ordered data → acknowledgements → retransmission.
- 2UDP — datagrams → send → no built-in ordering / retransmission.
Но таблица не отвечает на вопрос:
Что лучше?
Потому что правильный вопрос:
Что нужно конкретному приложению?
TCP работает как поток
Это важное различие.
TCP предоставляет приложению поток байтов.
Например, приложение отправляет HELLO и WORLD.
Для TCP это логически часть потока данных.
Он не обязан сохранять границы двух отдельных вызовов приложения как две самостоятельные «посылки».
Приложение само определяет структуру своих сообщений.
UDP сохраняет границы датаграмм
UDP работает иначе.
Приложение отправляет отдельные датаграммы: Datagram A, Datagram B, Datagram C.
Для принимающей стороны это тоже отдельные датаграммы.
Это одно из фундаментальных различий между моделями TCP и UDP.
TCP не превращает Интернет в идеальный канал
Даже TCP не способен гарантировать:
«что бы ни произошло, данные обязательно будут доставлены».
Например: сервер выключился; сеть полностью пропала; устройство потеряло питание; соединение стало невозможно продолжать.
В таком случае TCP в конце концов сообщит приложению об ошибке.
Где находится эта логика
Вспомним путь: приложение Emma передает данные через TCP или UDP, дальше через IP и маршрутизаторы к серверу, а на стороне сервера данные снова проходят через IP, TCP или UDP и наконец попадают в приложение сервера.
Маршрутизаторы между ними обычно не занимаются восстановлением TCP-потока Emma.
TCP работает в основном между конечными сторонами соединения.
Это важный принцип:
сеть доставляет пакеты, а конечные системы реализуют значительную часть транспортной логики.
- 1Application (Emma) — формирует данные, которые нужно передать.
- 2TCP / UDP — оборачивает данные в транспортный механизм на стороне отправителя.
- 3IP и маршрутизаторы — доставляют пакеты между сетями, не участвуя в логике TCP-потока.
- 4TCP / UDP — восстанавливает поток или принимает датаграммы на стороне получателя.
- 5Application (Server) — получает данные в готовом виде.
Один компьютер одновременно ведет много разговоров
Но теперь возникает новая проблема.
На ноутбуке Emma одновременно работают: браузер; мессенджер; почтовая программа; VPN; приложение криптобиржи.
Все используют одну сетевую систему.
Пакет пришел на ноутбук.
Как операционная система понимает, какому именно приложению он предназначен?
Одного IP-адреса для этого недостаточно.
Нужен еще один идентификатор.
И здесь появляются порты.
Пока только один пример
Можно представить: IP-адрес отвечает на вопрос, какое устройство, а port — на вопрос, какой сетевой сервис на устройстве.
Это очень упрощенная модель, но она дает правильное направление.
Порты подробно разберем в следующей части.
Почему TCP и UDP важны для безопасности
Позже вы встретите правила вроде «Allow TCP 443» или «Allow UDP 51820».
Теперь эти записи уже не выглядят набором случайных символов.
Они говорят сразу о двух вещах:
- какой транспортный протокол используется;
- с каким портом связан сетевой обмен.
Это особенно важно при настройке firewall, VPN, серверов и облачных сетевых правил.
Пример из жизни
Главное, что нужно запомнить
- IP и транспортные протоколы решают разные задачи.
- TCP и UDP работают поверх IP и предоставляют приложениям разные модели обмена.
- TCP устанавливает логическое соединение и предоставляет надежный упорядоченный поток байтов.
- TCP использует подтверждения и повторную передачу потерянных данных.
- TCP также управляет потоком и реагирует на перегрузку сети.
- TCP не гарантирует доставку при полном разрушении соединения — приложение все равно может получить ошибку.
- UDP не создает TCP-подобное надежное соединение и не имеет встроенных механизмов упорядочивания и повторной передачи.
- Это не делает UDP «плохим» или автоматически ненадежным на уровне приложения.
- Дополнительные механизмы могут быть реализованы поверх UDP; важный современный пример — QUIC.
- Нельзя универсально утверждать, что «UDP быстрее TCP» — все зависит от задачи и реализации.
- TCP представляет данные как поток байтов, UDP — как отдельные датаграммы.
- Выбор транспортного протокола зависит от того, какие свойства нужны конкретному приложению.
- Чтобы отличать множество сетевых сервисов на одном устройстве, используются порты.
Что дальше
У Emma один ноутбук.
Но одновременно на нем работают: браузер; мессенджер; VPN; другие приложения.
Все они используют один сетевой интерфейс и могут обращаться к Интернету одновременно.
Значит, IP-адрес отвечает еще не на весь вопрос.
Нужно понять:
кому именно внутри устройства предназначены полученные данные?
Для этого существуют сетевые порты.
И тогда записи вроде «TCP/443» или «UDP/51820» перестанут выглядеть как секретные координаты.
Продолжаем — в следующей части — «Порты и сетевые сервисы».
- IP и транспортные протоколы решают разные задачи.
- TCP и UDP работают поверх IP и предоставляют приложениям разные модели обмена.
- TCP устанавливает логическое соединение и предоставляет надежный упорядоченный поток байтов.
- TCP использует подтверждения и повторную передачу потерянных данных.
- TCP также управляет потоком и реагирует на перегрузку сети.
- TCP не гарантирует доставку при полном разрушении соединения — приложение все равно может получить ошибку.
- UDP не создает TCP-подобное надежное соединение и не имеет встроенных механизмов упорядочивания и повторной передачи.
- Это не делает UDP «плохим» или автоматически ненадежным на уровне приложения.
- Дополнительные механизмы могут быть реализованы поверх UDP; важный современный пример — QUIC.
- Нельзя универсально утверждать, что «UDP быстрее TCP» — все зависит от задачи и реализации.
- TCP представляет данные как поток байтов, UDP — как отдельные датаграммы.
- Выбор транспортного протокола зависит от того, какие свойства нужны конкретному приложению.
- Чтобы отличать множество сетевых сервисов на одном устройстве, используются порты.
Delivering a packet is not enough
In the previous parts we covered:
- how a device connects to the network;
- how data is broken into packets;
- how routers pass them toward the destination network.
But an important question remains.
Imagine Emma Lee is sending Alex a file.
The network delivered parts 1, 2, 4, 5, but the part numbered 3 was lost.
For the document, that's bad.
If you get:
the beginning of the contract + the middle + almost all of the end
the missing piece doesn't become any less missing.
So on top of ordinary IP delivery there needs to be a mechanism that determines:
how applications will exchange data and what to do about loss, delay, and reordering.
This is where TCP and UDP come in.
IP and transport solve different tasks
Very roughly: data leaves the application through TCP or UDP, then through IP — into the network.
IP primarily helps deliver packets between networks.
TCP or UDP solve a different task:
how to organize data transfer between applications on end devices.
What a transport protocol is
The two best-known transport protocols of the Internet are TCP and UDP.
They use different approaches.
Let's start with TCP
TCP — Transmission Control Protocol.
The main idea of TCP:
the application receives a reliable ordered stream of data for as long as the connection can be maintained normally.
That is, TCP tries to deal with problems such as:
- data loss;
- reordering;
- duplication;
- different speeds of sender and receiver.
First, TCP establishes a connection
Before the regular exchange of data, the two sides negotiate the establishment of a TCP connection.
Roughly: Emma tells the server "I want a connection," the server replies "Okay, I hear you," and Emma confirms "Great, let's begin."
In real TCP this is known as the three-way handshake.
What the handshake looks like
Conceptually: the client sends the server a SYN, the server responds with SYN-ACK, and the client confirms with ACK — after that the connection is considered established.
You don't need to memorize the three abbreviations right now.
The main point:
before transferring regular data, TCP establishes connection state between the two sides.
What "connection" means
This does not mean a separate physical cable appears between Emma and the server.
Packets still travel through the ordinary network.
A TCP connection is logical state that the end devices maintain.
For example, the two sides remember:
- what data has been sent;
- what has been received;
- what needs to be resent;
- in what order to assemble the stream.
TCP keeps track of order
Suppose data is sent in the order 1 → 2 → 3 → 4, but the network delivers it as 1 → 3 → 2 → 4.
TCP can use service information to present the data to the application in the correct sequence: the network delivered 1, 3, 2, 4, and TCP restores the order 1, 2, 3, 4, so the application receives an already-correct data stream.
What if part of the data is lost?
Imagine: 1 2 3 4 5 is sent, and 1 2 _ 4 5 is received.
TCP can determine that part of the expected data is missing and arrange for it to be resent.
Roughly: the receiver reports "I'm missing data," and the sender resends the necessary part.
This is called retransmission.
- 1Sender sends data 1 → 2 → 3 → 4 → 5.
- 2Receiver gets 1 → 2 → ✕ → 4 → 5 — part of the data was lost along the way.
- 3Receiver reports: "I'm missing data" — and requests the missing part.
- 4Sender resends the missing part, and the application receives the full stream 1 → 2 → 3 → 4 → 5.
What an acknowledgement is
TCP uses acknowledgements of received data.
You shouldn't think that the receiver sends a separate "Thanks!" after every byte.
The real mechanism is more efficient.
But conceptually, acknowledgements let the sender understand:
which part of the stream has already arrived.
TCP does more than just resend what was lost
It has other tasks as well.
For example, flow control keeps a sender that's too fast from overwhelming a receiver that can't keep up with processing.
And congestion control adapts transmission to the state of the network so as not to make congestion worse.
These mechanisms are quite complex.
For now it's enough to understand:
TCP tries not just to deliver data, but also to manage the process of reliable transfer.
What this is good for
TCP works well for scenarios where getting a full, correct stream matters.
For example: file transfer; the operation of many application protocols; receiving data where a missing fragment is unacceptable.
If a user is downloading a 20 MB document, they usually want to get:
20 MB of the correct document
not:
19.97 MB and a creative interpretation of the rest.
But reliability has a cost
To control the transfer, TCP has to:
- establish a connection;
- keep its state;
- acknowledge receipt;
- resend lost data;
- control the speed.
All of this requires extra service information, processing, and sometimes extra time.
And this is where a different approach comes in.
UDP
UDP — User Datagram Protocol.
UDP is significantly simpler.
Roughly: Emma sends data 1, 2, 3 as separate datagrams, one after another.
There's no mandatory TCP-style handshake before each such exchange.
UDP doesn't promise too much
UDP itself does not guarantee the application:
- that a datagram will definitely be delivered;
- that data will arrive in the same order;
- that lost data will be automatically resent;
- that the same datagram won't show up more than once.
That is, 1 2 3 4 might be sent, and only 1 3 4 received.
UDP by itself doesn't say:
"Stop, we urgently need to go back for number 2."
Is that bad?
Not necessarily.
It all depends on the task.
Imagine a voice call.
Emma says:
"Let's meet tomorrow at ten."
A small part of the audio was lost.
You can choose one of two options.
Option A
Stop playback and wait for the missing piece, then play the old sound a second later.
Option B
Keep receiving the next sound.
For a live conversation, the second option is sometimes more useful.
Because:
timeliness can matter more than perfect delivery of every fragment.
That's why UDP is often used where latency matters
Historically and in practice, UDP suits certain scenarios well: real-time audio/video; network games; DNS; other protocols that find simple datagram delivery convenient.
But an important caveat is needed here.
UDP does not mean "an unreliable application"
This is one of the most common mistakes.
You might think: TCP = reliable, UDP = unreliable.
This is too crude.
More precisely:
TCP provides built-in mechanisms for a reliable ordered stream.
While:
UDP by itself provides a much more minimal transport mechanism.
If an application needs additional properties, it can implement them on top of UDP.
A modern example — QUIC
Some modern protocols use UDP as a foundation and implement the necessary reliability mechanisms above it.
One important example is QUIC.
So you cannot say:
"UDP is only used when data loss doesn't matter at all."
That's incorrect.
And you can't just say "UDP is faster than TCP"
Another popular phrase:
UDP is faster.
It's better to say it more precisely:
UDP has a simpler built-in mechanism and a smaller set of mandatory transport functions.
But the actual speed of an application depends on the network, the application protocol, the algorithms, loss, latency, and the implementation.
Sometimes a system built on top of UDP can be very complex.
The mere fact of the letters UDP does not by itself guarantee magical acceleration.
Comparing TCP and UDP
| Characteristic | TCP | UDP |
|---|---|---|
| Connection setup | Yes | No TCP-like handshake |
| Built-in ordering | Yes | No |
| Built-in retransmission | Yes | No |
| Acknowledgements | Yes | Not in base UDP |
| Flow control | Yes | Not in base UDP |
| Data model | Byte stream | Individual datagrams |
| Protocol complexity | Higher | Lower |
- 1TCP — connection → ordered data → acknowledgements → retransmission.
- 2UDP — datagrams → send → no built-in ordering / retransmission.
But the table doesn't answer the question:
What's better?
Because the right question is:
What does a particular application need?
TCP works as a stream
This is an important distinction.
TCP provides the application a byte stream.
For example, the application sends HELLO and WORLD.
For TCP this is logically part of the data stream.
It isn't required to preserve the boundaries of the two separate application calls as two independent "parcels."
The application itself determines the structure of its messages.
UDP preserves datagram boundaries
UDP works differently.
The application sends separate datagrams: Datagram A, Datagram B, Datagram C.
For the receiving side, these are also separate datagrams.
This is one of the fundamental differences between the TCP and UDP models.
TCP doesn't turn the Internet into a perfect channel
Even TCP cannot guarantee:
"no matter what happens, the data will definitely be delivered."
For example: the server shuts down; the network disappears entirely; the device loses power; the connection becomes impossible to continue.
In such a case, TCP will eventually report an error to the application.
Where this logic lives
Let's recall the path: Emma's application passes data through TCP or UDP, then through IP and routers to the server, and on the server side the data again passes through IP, TCP or UDP, and finally reaches the server's application.
The routers in between generally don't take part in restoring Emma's TCP stream.
TCP works mainly between the two end points of the connection.
This is an important principle:
the network delivers packets, while the end systems implement a significant part of the transport logic.
- 1Application (Emma) — forms the data that needs to be transmitted.
- 2TCP / UDP — wraps the data in a transport mechanism on the sending side.
- 3IP and routers — deliver packets between networks, without taking part in TCP-stream logic.
- 4TCP / UDP — restores the stream or accepts datagrams on the receiving side.
- 5Application (Server) — receives the data ready to use.
One computer carries on many conversations at once
But now a new problem arises.
On Emma's laptop, the following are running at the same time: a browser; a messenger; a mail client; a VPN; a crypto exchange application.
All of them use the same network system.
A packet arrives at the laptop.
How does the operating system know which application it's meant for?
An IP address alone isn't enough for this.
Another identifier is needed.
And this is where ports come in.
Just one example for now
You can picture it this way: the IP address answers the question of which device, and the port answers the question of which network service on the device.
This is a very simplified model, but it points in the right direction.
We'll go over ports in detail in the next part.
Why TCP and UDP matter for security
Later you'll come across rules like "Allow TCP 443" or "Allow UDP 51820."
By now these entries no longer look like a random set of symbols.
They tell you two things at once:
- which transport protocol is used;
- which port the network exchange is associated with.
This matters especially when configuring a firewall, VPN, servers, and cloud network rules.
A real-world example
The main thing to remember
- IP and transport protocols solve different tasks.
- TCP and UDP work on top of IP and provide applications with different exchange models.
- TCP establishes a logical connection and provides a reliable ordered byte stream.
- TCP uses acknowledgements and retransmission of lost data.
- TCP also manages flow and reacts to network congestion.
- TCP does not guarantee delivery when the connection is completely destroyed — the application can still receive an error.
- UDP does not create a TCP-like reliable connection and has no built-in ordering or retransmission mechanisms.
- This does not make UDP "bad" or automatically unreliable at the application level.
- Additional mechanisms can be implemented on top of UDP; an important modern example is QUIC.
- You cannot universally claim that "UDP is faster than TCP" — it all depends on the task and the implementation.
- TCP presents data as a byte stream, UDP as individual datagrams.
- The choice of transport protocol depends on which properties a particular application needs.
- To distinguish between the many network services on one device, ports are used.
What's next
Emma has one laptop.
But running on it at the same time are: a browser; a messenger; a VPN; other applications.
All of them use one network interface and can reach the Internet at the same time.
So the IP address doesn't yet answer the whole question.
We need to understand:
who exactly inside the device is the received data meant for?
Network ports exist for this.
And then entries like "TCP/443" or "UDP/51820" will stop looking like secret coordinates.
We continue — in the next part — "Ports and network services."
- IP and transport protocols solve different problems.
- TCP and UDP work on top of IP and give applications different exchange models.
- TCP establishes a logical connection and provides a reliable, ordered byte stream.
- TCP uses acknowledgements and retransmits lost data.
- TCP also manages flow and reacts to network congestion.
- TCP doesn't guarantee delivery if the connection is completely destroyed — the application can still get an error.
- UDP doesn't create a TCP-like reliable connection and has no built-in ordering or retransmission mechanisms.
- That doesn't make UDP "bad" or automatically unreliable at the application level.
- Additional mechanisms can be built on top of UDP; an important modern example is QUIC.
- You can't universally claim "UDP is faster than TCP" — it all depends on the task and implementation.
- TCP presents data as a byte stream, UDP as separate datagrams.
- Choosing a transport protocol depends on which properties a particular application needs.
- Ports are used to tell apart the many network services running on one device.
Δεν αρκεί να παραδοθεί το πακέτο
Στα προηγούμενα μέρη είδαμε:
- πώς μια συσκευή συνδέεται στο δίκτυο;
- πώς τα δεδομένα χωρίζονται σε πακέτα;
- πώς οι δρομολογητές τα προωθούν προς το δίκτυο προορισμού.
Όμως παραμένει ένα σημαντικό ερώτημα.
Ας φανταστούμε ότι η Emma Lee στέλνει στον Alex ένα αρχείο.
Το δίκτυο παρέδωσε τα μέρη 1, 2, 4, 5, ενώ το μέρος δεδομένων με αριθμό 3 χάθηκε.
Για το έγγραφο αυτό είναι κακό.
Αν λάβουμε:
αρχή της σύμβασης + τη μέση + σχεδόν όλο το τέλος
το κομμάτι που λείπει δεν γίνεται λιγότερο απόν.
Άρα, πάνω από τη συνηθισμένη παράδοση IP χρειάζεται ένας μηχανισμός που καθορίζει:
πώς οι εφαρμογές θα ανταλλάσσουν δεδομένα και τι θα γίνεται σε περίπτωση απώλειας, καθυστέρησης και αλλαγής σειράς.
Εδώ εμφανίζονται τα TCP και UDP.
Το IP και η μεταφορά λύνουν διαφορετικά προβλήματα
Πολύ απλοποιημένα: τα δεδομένα φεύγουν από την εφαρμογή μέσω TCP ή UDP, στη συνέχεια μέσω IP — στο δίκτυο.
Το IP βοηθά κυρίως στην παράδοση πακέτων μεταξύ δικτύων.
Το TCP ή το UDP λύνουν ένα άλλο πρόβλημα:
πώς οργανώνεται η μεταφορά δεδομένων μεταξύ εφαρμογών σε τελικές συσκευές.
Τι είναι ένα πρωτόκολλο μεταφοράς
Τα δύο πιο γνωστά πρωτόκολλα μεταφοράς του Ίντερνετ είναι το TCP και το UDP.
Χρησιμοποιούν διαφορετικές προσεγγίσεις.
Ας ξεκινήσουμε με το TCP
TCP — Transmission Control Protocol.
Η κύρια ιδέα του TCP:
η εφαρμογή λαμβάνει μια αξιόπιστη, ταξινομημένη ροή δεδομένων, όσο η σύνδεση μπορεί να διατηρείται κανονικά.
Δηλαδή, το TCP προσπαθεί να αντιμετωπίσει προβλήματα όπως:
- απώλεια δεδομένων;
- αλλαγή σειράς;
- διπλασιασμό;
- διαφορετική ταχύτητα αποστολέα και παραλήπτη.
Πρώτα το TCP δημιουργεί σύνδεση
Πριν από τη συνήθη ανταλλαγή δεδομένων, οι πλευρές συμφωνούν στη δημιουργία μιας σύνδεσης TCP.
Απλοποιημένα: η Emma λέει στον διακομιστή «Θέλω σύνδεση», ο διακομιστής απαντά «Εντάξει, σε ακούω», και η Emma επιβεβαιώνει «Ωραία, ξεκινάμε».
Στο πραγματικό TCP αυτό είναι γνωστό ως three-way handshake.
Πώς μοιάζει το handshake
Εννοιολογικά: ο πελάτης στέλνει στον διακομιστή SYN, ο διακομιστής απαντά SYN-ACK, και ο πελάτης επιβεβαιώνει με ACK — μετά από αυτό η σύνδεση θεωρείται εγκατεστημένη.
Δεν χρειάζεται προς το παρόν να απομνημονεύσετε τις τρεις συντομογραφίες.
Η κύρια σκέψη:
πριν από τη μεταφορά των συνηθισμένων δεδομένων, το TCP εγκαθιστά την κατάσταση της σύνδεσης μεταξύ των πλευρών.
Τι σημαίνει «σύνδεση»
Αυτό δεν σημαίνει ότι ανάμεσα στην Emma και τον διακομιστή εμφανίζεται ένα ξεχωριστό φυσικό καλώδιο.
Τα πακέτα εξακολουθούν να ταξιδεύουν μέσα από το συνηθισμένο δίκτυο.
Η σύνδεση TCP είναι μια λογική κατάσταση που διατηρούν οι τελικές συσκευές.
Για παράδειγμα, οι πλευρές θυμούνται:
- ποια δεδομένα έχουν σταλεί;
- ποια έχουν ληφθεί;
- τι πρέπει να σταλεί ξανά;
- με ποια σειρά να συναρμολογηθεί η ροή.
Το TCP παρακολουθεί τη σειρά
Ας υποθέσουμε ότι τα δεδομένα στάλθηκαν με τη σειρά 1 → 2 → 3 → 4, ενώ το δίκτυο τα παρέδωσε ως 1 → 3 → 2 → 4.
Το TCP μπορεί να χρησιμοποιήσει τις βοηθητικές πληροφορίες ώστε να παρουσιάσει στην εφαρμογή τα δεδομένα με τη σωστή σειρά: το δίκτυο μετέδωσε 1, 3, 2, 4, και το TCP αποκαθιστά τη σειρά 1, 2, 3, 4, και η εφαρμογή λαμβάνει πλέον τη σωστή ροή δεδομένων.
Και αν ένα μέρος των δεδομένων χαθεί;
Ας φανταστούμε: στάλθηκαν 1 2 3 4 5, και λήφθηκαν 1 2 _ 4 5.
Το TCP μπορεί να προσδιορίσει ότι ένα μέρος των αναμενόμενων δεδομένων λείπει και να οργανώσει την επανάληψη της μετάδοσης.
Απλοποιημένα: ο παραλήπτης λέει «Μου λείπουν δεδομένα», και ο αποστολέας επαναλαμβάνει το απαραίτητο κομμάτι.
Αυτό ονομάζεται retransmission — επανάληψη μετάδοσης.
- 1Ο Sender στέλνει δεδομένα 1 → 2 → 3 → 4 → 5.
- 2Ο Receiver λαμβάνει 1 → 2 → ✕ → 4 → 5 — ένα μέρος των δεδομένων χάθηκε στη διαδρομή.
- 3Ο Receiver ενημερώνει: «Μου λείπουν δεδομένα» — και ζητά το κομμάτι που λείπει.
- 4Ο Sender επαναλαμβάνει το κομμάτι που χάθηκε, και η εφαρμογή λαμβάνει την πλήρη ροή 1 → 2 → 3 → 4 → 5.
Τι είναι η επιβεβαίωση
Το TCP χρησιμοποιεί επιβεβαιώσεις λήψης δεδομένων.
Δεν χρειάζεται να σκεφτόμαστε ότι ο παραλήπτης στέλνει ξεχωριστό «Ευχαριστώ!» μετά από κάθε byte.
Ο πραγματικός μηχανισμός είναι πιο αποδοτικός.
Αλλά εννοιολογικά οι επιβεβαιώσεις επιτρέπουν στον αποστολέα να καταλαβαίνει:
ποιο μέρος της ροής έχει ήδη φτάσει.
Το TCP δεν επαναλαμβάνει απλώς ό,τι χάθηκε
Έχει και άλλα καθήκοντα.
Για παράδειγμα, το flow control δεν επιτρέπει σε έναν πολύ γρήγορο αποστολέα να κατακλύσει με δεδομένα τον παραλήπτη, ο οποίος δεν προλαβαίνει να τα επεξεργαστεί.
Ενώ το congestion control προσαρμόζει τη μετάδοση στην κατάσταση του δικτύου, ώστε να μην επιδεινώνει τη συμφόρηση.
Αυτοί οι μηχανισμοί είναι αρκετά περίπλοκοι.
Προς το παρόν αρκεί να καταλάβουμε:
το TCP προσπαθεί όχι μόνο να παραδώσει τα δεδομένα, αλλά και να διαχειριστεί τη διαδικασία της αξιόπιστης μετάδοσης.
Για ποιο σκοπό είναι βολικό αυτό
Το TCP ταιριάζει καλά σε σενάρια όπου είναι σημαντικό να ληφθεί μια πλήρης και σωστή ροή.
Για παράδειγμα: μεταφορά αρχείων· λειτουργία πολλών πρωτοκόλλων εφαρμογής· λήψη δεδομένων όπου ένα κομμάτι που λείπει δεν είναι αποδεκτό.
Αν ένας χρήστης κατεβάζει ένα έγγραφο μεγέθους 20 MB, συνήθως θέλει να λάβει:
20 MB σωστού εγγράφου
και όχι:
19,97 MB και μια δημιουργική ερμηνεία του υπόλοιπου μέρους.
Όμως η αξιοπιστία έχει κόστος
Για να ελέγχει τη μετάδοση, το TCP πρέπει:
- να εγκαθιστά σύνδεση;
- να διατηρεί την κατάστασή της;
- να επιβεβαιώνει τη λήψη;
- να επαναλαμβάνει τα δεδομένα που χάθηκαν;
- να ελέγχει την ταχύτητα.
Όλα αυτά απαιτούν επιπλέον βοηθητικές πληροφορίες, επεξεργασία και μερικές φορές επιπλέον χρόνο.
Και εδώ εμφανίζεται μια άλλη προσέγγιση.
UDP
UDP — User Datagram Protocol.
Το UDP είναι σημαντικά απλούστερο.
Απλοποιημένα: η Emma στέλνει δεδομένα 1, 2, 3 ως ξεχωριστά datagram, ένα μετά το άλλο.
Δεν υπάρχει υποχρεωτικό TCP-style handshake πριν από κάθε τέτοια ανταλλαγή.
Το UDP δεν υπόσχεται πάρα πολλά
Το ίδιο το UDP δεν εγγυάται στην εφαρμογή:
- ότι το datagram θα παραδοθεί οπωσδήποτε;
- ότι τα δεδομένα θα φτάσουν με την ίδια σειρά;
- ότι ό,τι χαθεί θα σταλεί ξανά αυτόματα;
- ότι το ίδιο datagram δεν θα εμφανιστεί περισσότερες από μία φορά.
Δηλαδή, στάλθηκαν 1 2 3 4, και μπορεί να ληφθούν μόνο 1 3 4.
Το ίδιο το UDP δεν λέει:
«Στοπ, ας γυρίσουμε επειγόντως για τον αριθμό 2».
Αυτό είναι κακό;
Όχι απαραίτητα.
Όλα εξαρτώνται από το καθήκον.
Ας φανταστούμε μια φωνητική συνομιλία.
Η Emma λέει:
«Θα συναντηθούμε αύριο στις δέκα».
Ένα μικρό κομμάτι ήχου χάθηκε.
Μπορούμε να επιλέξουμε μία από δύο επιλογές.
Επιλογή A
Να σταματήσει η αναπαραγωγή και να περιμένουμε το κομμάτι που λείπει, και μετά, ένα δευτερόλεπτο αργότερα, να αναπαραχθεί ο παλιός ήχος.
Επιλογή B
Να συνεχίσουμε να λαμβάνουμε τον επόμενο ήχο.
Για μια ζωντανή συνομιλία, μερικές φορές η δεύτερη επιλογή είναι πιο χρήσιμη.
Επειδή:
η εγκαιρότητα μπορεί να είναι πιο σημαντική από την τέλεια παράδοση κάθε κομματιού.
Γι' αυτό το UDP χρησιμοποιείται συχνά εκεί όπου η καθυστέρηση έχει σημασία
Ιστορικά και πρακτικά, το UDP ταιριάζει καλά σε ορισμένα σενάρια: real-time audio/video· δικτυακά παιχνίδια· DNS· άλλα πρωτόκολλα στα οποία βολεύει η απλή μετάδοση datagram.
Αλλά εδώ χρειάζεται μια σημαντική επιφύλαξη.
Το UDP δεν σημαίνει «αναξιόπιστη εφαρμογή»
Αυτό είναι ένα από τα πιο συνηθισμένα λάθη.
Θα μπορούσε κανείς να σκεφτεί: TCP = αξιόπιστο, UDP = αναξιόπιστο.
Αυτό είναι πολύ πρόχειρο.
Πιο σωστά:
το TCP παρέχει ενσωματωμένους μηχανισμούς αξιόπιστης, ταξινομημένης ροής.
Ενώ:
το ίδιο το UDP παρέχει έναν πολύ πιο ελάχιστο μηχανισμό μεταφοράς.
Αν μια εφαρμογή χρειάζεται επιπλέον ιδιότητες, μπορεί να τις υλοποιήσει πάνω από το UDP.
Ένα σύγχρονο παράδειγμα — QUIC
Ορισμένα σύγχρονα πρωτόκολλα χρησιμοποιούν το UDP ως βάση, ενώ τους απαραίτητους μηχανισμούς αξιοπιστίας τους υλοποιούν πάνω από αυτό.
Ένα σημαντικό παράδειγμα είναι το QUIC.
Γι' αυτό δεν μπορούμε να πούμε:
«Το UDP χρησιμοποιείται μόνο όταν η απώλεια δεδομένων δεν έχει καμία σημασία».
Αυτό είναι λάθος.
Και δεν μπορούμε απλώς να πούμε «το UDP είναι πιο γρήγορο από το TCP»
Μια ακόμη δημοφιλής φράση:
Το UDP είναι πιο γρήγορο.
Καλύτερα να πούμε με ακρίβεια:
το UDP έχει έναν απλούστερο ενσωματωμένο μηχανισμό και ένα μικρότερο σύνολο υποχρεωτικών λειτουργιών μεταφοράς.
Αλλά η πραγματική ταχύτητα της εφαρμογής εξαρτάται από το δίκτυο, το πρωτόκολλο της εφαρμογής, τους αλγορίθμους, τις απώλειες, την καθυστέρηση και την υλοποίηση.
Μερικές φορές ένα σύστημα πάνω από το UDP μπορεί να είναι πολύ περίπλοκο.
Το γεγονός και μόνο ότι υπάρχουν τα γράμματα UDP δεν εγγυάται μαγική επιτάχυνση.
Ας συγκρίνουμε το TCP και το UDP
| Χαρακτηριστικό | TCP | UDP |
|---|---|---|
| Εγκατάσταση σύνδεσης | Ναι | Όχι TCP-style handshake |
| Ενσωματωμένη ταξινόμηση | Ναι | Όχι |
| Ενσωματωμένη επανάληψη μετάδοσης | Ναι | Όχι |
| Επιβεβαιώσεις | Ναι | Όχι στο βασικό UDP |
| Έλεγχος ροής | Ναι | Όχι στο βασικό UDP |
| Μοντέλο δεδομένων | Ροή byte | Μεμονωμένα datagram |
| Πολυπλοκότητα πρωτοκόλλου | Υψηλότερη | Χαμηλότερη |
- 1TCP — connection → ordered data → acknowledgements → retransmission.
- 2UDP — datagrams → send → no built-in ordering / retransmission.
Αλλά ο πίνακας δεν απαντά στο ερώτημα:
Τι είναι καλύτερο;
Επειδή το σωστό ερώτημα είναι:
Τι χρειάζεται η συγκεκριμένη εφαρμογή;
Το TCP λειτουργεί ως ροή
Αυτή είναι μια σημαντική διαφορά.
Το TCP παρέχει στην εφαρμογή μια ροή byte.
Για παράδειγμα, η εφαρμογή στέλνει HELLO και WORLD.
Για το TCP αυτό είναι λογικά μέρος της ροής δεδομένων.
Δεν είναι υποχρεωμένο να διατηρεί τα όρια δύο ξεχωριστών κλήσεων της εφαρμογής ως δύο αυτοτελή «δέματα».
Η ίδια η εφαρμογή καθορίζει τη δομή των μηνυμάτων της.
Το UDP διατηρεί τα όρια των datagram
Το UDP λειτουργεί διαφορετικά.
Η εφαρμογή στέλνει ξεχωριστά datagram: Datagram A, Datagram B, Datagram C.
Για την πλευρά που λαμβάνει, αυτά είναι επίσης ξεχωριστά datagram.
Αυτή είναι μία από τις θεμελιώδεις διαφορές μεταξύ των μοντέλων TCP και UDP.
Το TCP δεν μετατρέπει το Ίντερνετ σε τέλειο κανάλι
Ακόμη και το TCP δεν μπορεί να εγγυηθεί:
«ό,τι κι αν συμβεί, τα δεδομένα θα παραδοθούν οπωσδήποτε».
Για παράδειγμα: ο διακομιστής έσβησε· το δίκτυο εξαφανίστηκε εντελώς· η συσκευή έχασε ρεύμα· η σύνδεση δεν μπορεί πλέον να συνεχιστεί.
Σε τέτοια περίπτωση, το TCP θα ενημερώσει τελικά την εφαρμογή για σφάλμα.
Πού βρίσκεται αυτή η λογική
Ας θυμηθούμε τη διαδρομή: η εφαρμογή της Emma μεταδίδει δεδομένα μέσω TCP ή UDP, στη συνέχεια μέσω IP και δρομολογητών προς τον διακομιστή, και στην πλευρά του διακομιστή τα δεδομένα περνούν ξανά μέσω IP, TCP ή UDP και τελικά φτάνουν στην εφαρμογή του διακομιστή.
Οι δρομολογητές ανάμεσά τους συνήθως δεν ασχολούνται με την αποκατάσταση της ροής TCP της Emma.
Το TCP λειτουργεί κυρίως μεταξύ των τελικών πλευρών της σύνδεσης.
Αυτή είναι μια σημαντική αρχή:
το δίκτυο παραδίδει πακέτα, ενώ τα τελικά συστήματα υλοποιούν σημαντικό μέρος της λογικής μεταφοράς.
- 1Application (Emma) — διαμορφώνει τα δεδομένα που πρέπει να μεταδοθούν.
- 2TCP / UDP — περιτυλίγει τα δεδομένα σε μηχανισμό μεταφοράς στην πλευρά του αποστολέα.
- 3IP και δρομολογητές — παραδίδουν πακέτα μεταξύ δικτύων, χωρίς να συμμετέχουν στη λογική της ροής TCP.
- 4TCP / UDP — αποκαθιστά τη ροή ή δέχεται τα datagram στην πλευρά του παραλήπτη.
- 5Application (Server) — λαμβάνει τα δεδομένα έτοιμα προς χρήση.
Ένας υπολογιστής κάνει ταυτόχρονα πολλές «συνομιλίες»
Όμως τώρα προκύπτει ένα νέο πρόβλημα.
Στο λάπτοπ της Emma λειτουργούν ταυτόχρονα: πρόγραμμα περιήγησης· εφαρμογή ανταλλαγής μηνυμάτων· πρόγραμμα ηλεκτρονικού ταχυδρομείου· VPN· εφαρμογή χρηματιστηρίου κρυπτονομισμάτων.
Όλα χρησιμοποιούν το ίδιο δικτυακό σύστημα.
Ένα πακέτο έφτασε στο λάπτοπ.
Πώς καταλαβαίνει το λειτουργικό σύστημα σε ποια ακριβώς εφαρμογή προορίζεται;
Μια διεύθυνση IP από μόνη της δεν αρκεί για αυτό.
Χρειάζεται ένας ακόμη αναγνωριστικός δείκτης.
Και εδώ εμφανίζονται οι θύρες (ports).
Προς το παρόν μόνο ένα παράδειγμα
Μπορούμε να φανταστούμε ότι η διεύθυνση IP απαντά στην ερώτηση ποια συσκευή, ενώ η port στην ερώτηση ποια δικτυακή υπηρεσία στη συσκευή.
Αυτό είναι ένα πολύ απλοποιημένο μοντέλο, αλλά δίνει τη σωστή κατεύθυνση.
Τις θύρες θα τις αναλύσουμε λεπτομερώς στο επόμενο μέρος.
Γιατί το TCP και το UDP είναι σημαντικά για την ασφάλεια
Αργότερα θα συναντήσετε κανόνες όπως «Allow TCP 443» ή «Allow UDP 51820».
Τώρα πια αυτές οι καταχωρίσεις δεν μοιάζουν με τυχαίο σύνολο συμβόλων.
Μας λένε ταυτόχρονα δύο πράγματα:
- ποιο πρωτόκολλο μεταφοράς χρησιμοποιείται;
- με ποια θύρα σχετίζεται η δικτυακή ανταλλαγή.
Αυτό είναι ιδιαίτερα σημαντικό κατά τη ρύθμιση firewall, VPN, διακομιστών και κανόνων δικτύου στο cloud.
Παράδειγμα από τη ζωή
Το κυριότερο που πρέπει να θυμόμαστε
- Το IP και τα πρωτόκολλα μεταφοράς λύνουν διαφορετικά προβλήματα.
- Το TCP και το UDP λειτουργούν πάνω από το IP και παρέχουν στις εφαρμογές διαφορετικά μοντέλα ανταλλαγής.
- Το TCP εγκαθιστά μια λογική σύνδεση και παρέχει μια αξιόπιστη, ταξινομημένη ροή byte.
- Το TCP χρησιμοποιεί επιβεβαιώσεις και επανάληψη μετάδοσης των δεδομένων που χάθηκαν.
- Το TCP επίσης ελέγχει τη ροή και αντιδρά στη συμφόρηση του δικτύου.
- Το TCP δεν εγγυάται την παράδοση σε περίπτωση πλήρους κατάρρευσης της σύνδεσης — η εφαρμογή μπορεί και πάλι να λάβει σφάλμα.
- Το UDP δεν δημιουργεί αξιόπιστη σύνδεση σαν του TCP και δεν έχει ενσωματωμένους μηχανισμούς ταξινόμησης και επανάληψης μετάδοσης.
- Αυτό δεν κάνει το UDP «κακό» ή αυτόματα αναξιόπιστο στο επίπεδο της εφαρμογής.
- Πρόσθετοι μηχανισμοί μπορούν να υλοποιηθούν πάνω από το UDP· ένα σημαντικό σύγχρονο παράδειγμα είναι το QUIC.
- Δεν μπορούμε να ισχυριστούμε καθολικά ότι «το UDP είναι πιο γρήγορο από το TCP» — όλα εξαρτώνται από το καθήκον και την υλοποίηση.
- Το TCP παρουσιάζει τα δεδομένα ως ροή byte, ενώ το UDP ως ξεχωριστά datagram.
- Η επιλογή του πρωτοκόλλου μεταφοράς εξαρτάται από το ποιες ιδιότητες χρειάζεται η συγκεκριμένη εφαρμογή.
- Για να διακρίνονται πολλές δικτυακές υπηρεσίες στην ίδια συσκευή, χρησιμοποιούνται οι θύρες.
Τι ακολουθεί
Η Emma έχει ένα λάπτοπ.
Αλλά ταυτόχρονα σε αυτό λειτουργούν: πρόγραμμα περιήγησης· εφαρμογή ανταλλαγής μηνυμάτων· VPN· άλλες εφαρμογές.
Όλες χρησιμοποιούν την ίδια δικτυακή διεπαφή και μπορούν να έχουν πρόσβαση στο Ίντερνετ ταυτόχρονα.
Άρα, η διεύθυνση IP δεν απαντά ακόμη σε ολόκληρο το ερώτημα.
Πρέπει να καταλάβουμε:
σε ποιον ακριβώς μέσα στη συσκευή προορίζονται τα δεδομένα που λήφθηκαν;
Για αυτό υπάρχουν οι δικτυακές θύρες.
Και τότε καταχωρίσεις όπως «TCP/443» ή «UDP/51820» θα πάψουν να μοιάζουν με μυστικές συντεταγμένες.
Συνεχίζουμε — στο επόμενο μέρος — «Θύρες και δικτυακές υπηρεσίες».
- Το IP και τα πρωτόκολλα μεταφοράς λύνουν διαφορετικά προβλήματα.
- Τα TCP και UDP λειτουργούν πάνω από το IP και προσφέρουν στις εφαρμογές διαφορετικά μοντέλα ανταλλαγής.
- Το TCP καθιερώνει μια λογική σύνδεση και παρέχει μια αξιόπιστη, ταξινομημένη ροή byte.
- Το TCP χρησιμοποιεί επιβεβαιώσεις και επαναμεταδίδει τα δεδομένα που χάθηκαν.
- Το TCP διαχειρίζεται επίσης τη ροή και αντιδρά στη συμφόρηση του δικτύου.
- Το TCP δεν εγγυάται την παράδοση αν η σύνδεση καταστραφεί εντελώς — η εφαρμογή μπορεί και πάλι να λάβει σφάλμα.
- Το UDP δεν δημιουργεί μια αξιόπιστη σύνδεση τύπου TCP και δεν διαθέτει ενσωματωμένους μηχανισμούς ταξινόμησης ή επαναμετάδοσης.
- Αυτό δεν κάνει το UDP «κακό» ή αυτόματα αναξιόπιστο στο επίπεδο της εφαρμογής.
- Πρόσθετοι μηχανισμοί μπορούν να υλοποιηθούν πάνω από το UDP· ένα σημαντικό σύγχρονο παράδειγμα είναι το QUIC.
- Δεν μπορούμε να ισχυριστούμε καθολικά ότι «το UDP είναι πιο γρήγορο από το TCP» — όλα εξαρτώνται από το καθήκον και την υλοποίηση.
- Το TCP παρουσιάζει τα δεδομένα ως ροή byte, το UDP ως ξεχωριστά datagrams.
- Η επιλογή πρωτοκόλλου μεταφοράς εξαρτάται από το ποιες ιδιότητες χρειάζεται η συγκεκριμένη εφαρμογή.
- Οι θύρες χρησιμοποιούνται για να ξεχωρίζουν τις πολλές δικτυακές υπηρεσίες σε μία συσκευή.