Приведу 7 отличий, которые было бы неплохо знать.
1. Connection-oriented vs connectionless
Существует два способа установить соединение перед отправкой данных с одного устройства на другое: с установлением соединения (connection-oriented) и без установления соединения (connectionless). В первом случае создается сквозное соединение между отправителем и получателем перед передачей данных с сохранением порядка передачи пакетов. Во втором случае пакеты передаются между отправителем и получателем без создания какого-либо соединения. Пакеты проходят по разным маршрутам от отправителя к получателю, этот способ ненадежен и не гарантирует доставку пакетов.
Два вышеописанных способа соответствуют протоколам TCP и UDP.
2. Three-way handshake vs. No handshake
Трёхстороннее рукопожатие (Three-way handshake) – это метод, используемый в сети TCP/IP для создания соединения между локальным хостом/клиентом и сервером.
Почему же нам всё-таки нужно трехстороннее рукопожатие, а например не двухстороннее ;)
На самом деле все очень просто, TCP является двунаправленной связью, другими словами, обе стороны могут «говорить». Прежде чем начать «говорить» мы должны обменяться приветствием, в случае с TCP в роли приветствия выступает случайный номер (ISN), который генерирует один участник соединения и направляет второму участнику, а тот в свою очередь должен увеличить этот номер на 1 (ISN + 1) и оправить обратно, дабы первый участник убедился, что сообщение получено. То же самое проделывается и наоборот от второго к первому участнику:
Alice ---> Max SYNchronize with my Initial Sequence Number of X
Alice <--- Max I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Max SYNchronize with my Initial Sequence Number of Y
Alice ---> Max I received your syn, I ACKnowledge that I am ready for [Y+1]
Внимательные ребята могут заметить, что тут 4 события, а не 3 как указано в заголовке:
№1 Алиса выбирает ISN и СИНХРОНИЗИРУЕТ его с Максом.
№2 Макс ПОДТВЕРЖДАЕТ получение ISN.
№3 Макс выбирает ISN и СИНХРОНИЗИРУЕТ его с Алисой.
№4 Алиса ПОДТВЕРЖДАЕТ, что знает ISN.
Однако на самом деле два средних события (№2 и №3) происходят в одном и том же пакете. SYN и ACK это просто двоичные флаги внутри каждого заголовка TCP, поэтому ничто не мешает включить оба этих флага в одном и том же пакете. Таким образом, трехстороннее рукопожатие выглядит так:
Max <--- Alice SYN
Max ---> Alice SYN ACK
Max <--- Alice ACK
3. Header (20 bytes) vs. (8 bytes)
Формат заголовка TCP. Каждый заголовок TCP имеет 10 обязательных полей общим размером 20 байт (160 бит). Опционально он может включать дополнительное поле данных размером до 40 байт.
Формат заголовка UDP. Поскольку возможности UDP ограничены по сравнению с TCP, его заголовки меньше. Заголовок UDP содержит 8 байтов, включающий четыре обязательных поля.
4. Unicast & Multicast & Broadcast
Есть три варианта передачи данных по сети:
Одноадресная передача: от одного источника к одному получателю, т. е. один к одному (TCP и UDP);
Многоадресная передача: от одного источника к нескольким получателям, т. е. «один ко многим» (UDP);
Широковещательная передача: от одного источника ко всем возможным получателям, т. е. «один ко всем» (UDP).
5. Congestion control vs no congestion control
Бывает такое, вы ставите файл на закачку, и скорость медленно, но верно возрастает, затем, в какой-то момент, резко снижается, затем опять возрастает, или, например, запускаете торрент-клиент, и пинг в игре начинает сильно прыгать.
Наверняка вы винили во всем ваш роутер, либо вашего провайдера. Да они от части бывают виноваты, но виноваты ли они в данный момент?
Итак, встречайте:
TCP Congestion Control – что это?
В процессе передачи данных по сети мы можем столкнуться с перегрузкой из-за перегрузки трафика в узлах, превышающего их пропускную способность. Это приводит к потере пакетов в сети и, как следствие, может серьезно навредить работе пользователя. Хотя полностью избежать перегрузок невозможно, существуют механизмы сведения их к минимуму, чтобы предотвратить разрушительные последствия. Другими словами, у нас в арсенале есть алгоритмы, которые призваны контролировать перегрузку в TCP, например:
Медленный старт (slow start) — один из алгоритмов, который TCP использует для контроля над перегрузкой сети.
Алгоритм медленного старта работает за счёт увеличения окна TCP каждый раз, когда получено подтверждение, то есть увеличивает размер окна в зависимости от количества подтверждённых сегментов. Это происходит до тех пор, пока для какого-то сегмента не будет получено подтверждение или будет достигнуто какое-то заданное пороговое значение.
Если происходит потеря, TCP предполагает, что это связано с перегрузкой сети и принимает меры по сокращению нагрузки на сеть. Как только порог достигнут, TCP входит в фазу линейного роста (предотвращения перегрузки). В эту фазу окно увеличивается на один сегмент. Это происходит до тех пор, пока не происходит потери пакета.
Пару понятий:
Размер окна перегрузки (Congestion window size).
Отправляемые байты никогда не должны превышать размер окна перегрузки. Если скорость отправки превышает размер окна перегрузки, пакеты теряются, и отправитель вынужден передавать их повторно.
Размер окна получателя (Receiver window size).
Получатель сообщает о количестве байтов, которое он может получить, прежде чем отбрасывать пакеты. Таким образом, отправитель всегда должен отправлять количество байтов, меньше или равных размеру окна получателя, чтобы избежать повторной передачи пакетов.
6. Reliable vs lossy
В отличие от UDP, TCP обеспечивает надежную доставку пакетов:
TCP гарантирует, что данные не будут повреждены, утеряны, продублированы или доставлены не по порядку получателю, в противном случае он должен их восстановить.
TCP надежен, потому что протокол гарантирует, что все данные передаются полностью и могут быть собраны получателем в правильном порядке.
TCP достигает этой надежности, присваивая порядковый номер каждому передаваемому пакету и требуя положительного подтверждения (ACK) от получателя. Если ACK не получен в течение определенного интервала времени ожидания, данные передаются повторно. Значение тайм-аута повторной передачи TCP определяется динамически для каждого соединения на основе времени приема-передачи. Повреждённые пакеты определяются путем добавления контрольной суммы к каждому передаваемому пакету, и его последующей проверки на стороне получателя, все поврежденные пакеты отбрасываются.
7. Flow control vs No flow control
В разделе, посвящённом перегрузке сети, я уже сказал, что мы отталкиваемся от «узких» мест нашей сети при передаче данных. Так вот что же такое управление потоком TCP?
В сети для того, чтобы два сетевых хоста могли общаться друг с другом, один должен отправить пакет, а другой хост должен его получить. Может случиться так, что оба хоста имеют разные аппаратные и программные спецификации и, соответственно, их процессоры могут отличаться. Если хост-получатель имеет быстрый процессор, который может обрабатывать сообщения, отправленные отправителем с более высокой скоростью, то связь работает хорошо, и проблем не возникает. Но задумывались ли вы когда-нибудь, что произойдет, если у получателя будет более медленный процессор? В этом случае входящие сообщения будут продолжать поступать и копится в очередь получателя. Как только очередь получателя будет заполнена, сообщения начнут отбрасываться, что приведет к потере пакетов. Чтобы решить эту проблему медленного получателя и быстрого отправителя, на сцену выходит концепция управления потоком.
На графике изображен быстрый отправитель и медленный получатель:
на диаграмме получатель получает сообщение, отправленное отправителем, со скоростью 5 сообщений в секунду, а отправитель отправляет сообщения со скоростью 10 сообщений в секунду.
когда отправитель отправляет сообщение получателю, оно попадает в сетевую очередь получателя.
как только считывается сообщение из очереди, оно сразу удаляется из очереди и освобождается место.
в соответствии с указанной скоростью отправителя и получателя очередь получателя будет сокращаться, а буферное пространство будет уменьшаться со скоростью 5 сообщений в секунду. Поскольку размер буфера приемника может вместить 200 сообщений, следовательно, через 40 секунд буфер приемника заполнится.
итак, через 40 секунд сообщения начнут отбрасываться, так как для входящих сообщений не останется места.
Вот почему управление потоком становится важным для протокола TCP при передаче данных и связи.
Вывод
Есть причина, по которой TCP является наиболее часто используемым протоколом. Он надежен и гарантирует, что данные будут получены точно так же, как они были отправлены. Его проверенный на наличие ошибок поток информации может немного замедлить его работу, но в большинстве случаев задержка не является решающим фактором.
Время, когда UDP сияет ярче, чем TCP, — это когда скорость имеет решающее значение, например, при потоковой передаче видео, VPN или онлайн-играх.
Если статья показалась вам интересной, то у меня в планах еще целая серия на эту тему. Так что, если не хотите их пропустить – буду благодарен за подписку на мой ТГ-канал HowToSchool.
