Udp протокол

Порт[править]

Сетевой порт — это сетевой ресурс, отображаемый в виде числа (1-65535), которое определяет назначение входящих или исходящих сетевых потоков данных на заданном устройстве.

Если прибегнуть к аналогии, IP адрес — это адрес общежития с вахтёром, а порт — номер комнаты в этом общежитии или фамилия ее жильца.

Согласно IP, в каждом пакете присутствуют IP-адрес узла-источника и IP-адрес узла-назначения. В TCP-пакетах дополнительно указываются порт источника и порт назначения.

Например, почтовое письмо (пакет данных) имеет информацию об отправителе (порт) и информацию о получателе (фамилия или номер комнаты по конкретному адресу).

Узел назначения («вахтер»), получив пакет («письмо»), смотрит на порт назначения («фамилию или номер комнаты») и передает пакет соответствующему у себя приложению («конкретному жильцу»).

Использование портов позволяет независимо использовать TCP протокол («почтовые услуги») сразу многим приложениям на одном и том же компьютере (общежитии).

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

Сервер при запуске сообщает Операционной Системе, что хотел бы «занять» определенный порт (или несколько портов). После этого все пакеты, приходящие на компьютер к этому порту, ОС будет передавать этому серверу. Говорят, что сервер «слушает» этот порт.

Клиент, начиная соединение, запрашивает у своей ОС какой-нибудь незанятый порт во временное пользование, и указывает его в посланных пакетах как порт источника. Затем на этот порт он получит ответные пакеты от сервера.

Таким образом, сервер:

  • слушает на определённом порту, заранее известном клиенту
  • занимает этот порт всё время, пока не завершит работу
  • об IP-адресе и номере порта клиента узнаёт из приглашения, посланного клиентом

Клиент:

  • заранее знает IP-адрес и порт сервера
  • выбирает у себя произвольный порт, который освобождает после окончания соединения
  • посылает приглашение к соединению

Как работает TCP соединение

Соединение отправителя и получателя (два узла) происходит так:

1. Отправитель отсылает получателю специальный пакет, именуемый SYN, т.е. пригашает к соединению2. Получатель отвечает уже пакетом SYN-ACK, т.е. соглашается3. Отправитель отсылает спец. пакет ACK, т.е. подтверждает, что согласие получено

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

TCP порты

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

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

Есть целый ряд уже зарезервированных портов, которые являются стандартом:

Также, стоит отметить, что порты данного протокола никак не пересекаются с такими же, но у UDP. Так, например, порт: 1234 не пересечется с таким же, но у UDP.

В заключение

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

Difference between TCP and UDP

Here, are the differences between TCP and UDP

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.

TCP backlog

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

Например, если какой-то сервис, обслуживающий клиентов по сети, не справляется с нагрузкой и перестает обрабатывать новые соединения, они ставятся в очередь (backlog).

На самом деле очереди две:

  • SYN queue — очередь неустановленных соединений (получен пакет SYN, SYN-ACK еще не отправлен), размер ограничен согласно sysctl net.ipv4.tcp_max_syn_backlog;
  • Accept queue — очередь соединений, для которых получен пакет ACK (в рамках «тройного рукопожатия»), но не был выполнен accept приложением (очередь ограничивается приложением)

При достижении лимита accept queue ACK пакет удаленного хоста просто отбрасывается или отправляется RST (в зависимости от значения переменной sysctl net.ipv4.tcp_abort_on_overflow).

Наш агент снимает текущее и максимальное значение accept queue для всех listen сокетов на сервере.

Для этих метрик есть график и преднастроенный триггер, который уведомит, если backlog любого сервиса использован более чем на 90%:

Объяснение по материалам сайта CITForum

Порт – Часть сокета, указывающая логический канал ввода или вывода для процесса, имеющего дело с данными.Сокет – Адрес, который особым образом включает в себя идентификатор порта. А именно, он включает связь Internet адреса с TCP портом.

Порт – это программное понятие, которое используется клиентом или сервером для посылки или приема сообщений; порт идентифицируется 16-битовым числом. Серверные процессы обычно ассоциируются с фиксированным числом, например числом 25 для SMTP или 6000 для X Windows. Номер порта является известным, так как он требуется, помимо IP-адреса получателя, при установлении соединения с конкретным хостом и сервисом. Клиентские процессы, с другой стороны, запрашивают номер порта у операционной системы в начале работы; и номер порта является случайным, хотя в некоторых случаях он является следующим в списке свободных номеров портов.

Существует достаточно распространенное правило, согласно которому только привилегированные процессы сервера, то есть те процессы, которые работают с привилегиями суперпользователя UNIX, могут использовать порты с номерами меньше, чем 1024 ( так называемые привилегированные порты). Сервера в основном используют порты с номерами меньше, чем 1024, а клиенты как правило должны запрашивать непривилегированные порты у ОС. Хотя это правило и не является обязательным для исполнения и не требуется спецификацией протоколов TCP/IP, системы на основе BSD соблюдают его.
В протоколе TCP также, как и в UDP, для связи с прикладными процессами используются порты. Номера портам присваиваются аналогичным образом: имеются стандартные, зарезервированные номера (например, номер 21 закреплен за сервисом FTP, 23 – за telnet), а менее известные приложения пользуются произвольно выбранными локальными номерами.

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

Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта. Одна оконечная точка может участвовать в нескольких соединениях.

Установление соединения выполняется в следующей последовательности:

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

Сервисы TCP и UDP используются с помощью схемы клиент-сервер. Например, процесс сервера TELNET вначале находится в состоянии ожидания запроса установления соединения. В какой-нибудь момент времени пользователь запускает процесс клиента TELNET, который инициирует соединение с сервером TELNET. Клиент посылает данные серверу, тот читает их, и посылает обратно клиенту ответ. Клиент читает ответ и сообщает о нем пользователю. Поэтому, соединение является двунаправленным и может быть использовано как для чтения, так и для записи.

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

  • IP-адрес источника – адрес системы, которая послала пакет
  • IP-адрес получателя – адрес системы, которая принимает пакет
  • порт отправителя – порт соединения в системе-отправителе
  • порт получателя – порт соединения в системе-получателе

Сравнение

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

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

Счетчики и ошибки протоколов

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

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

Попробуем что-то понять про эти выбросы входящего трафика:

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

Попробуем посмотреть на ошибки:

А вот и наш первый пик — ошибки UDP:NoPorts (количество датаграмм, пришедших на UPD порты, которые никто не слушает)

Данный пример мы эмулировали с помощью iperf, и в первый заход не включили на сервер-приемщик пакетов на нужном порту.

Надёжность и решения проблемы перегрузок

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого кодирования (Erasure coderuen).

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

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Зачем сравнивать TCP или что с ним не так

  • packet loss — примерно 0,6% пакетов, которые мы отправляем, теряются по пути;
  • reordering — перестановка пакетов местами, в реальной жизни довольно редкое явление, но случается в 0,2% случаев;
  • jitter — когда пакеты отправляются равномерно, а приходят очередями с задержкой примерно в 50 мс.

Как вычислить RTT

RIPE Atlasбеспроводные сети популярны и нестабильны

  • Более 80% пользователей используют беспроводной интернет;
  • Параметры беспроводных сетей динамично меняются в зависимости, например, от того, что пользователь повернул за угол;
  • Беспроводные сети имеют высокие показатели packet loss, jitter, reordering;
  • Фиксированный ассиметричный канал, смена IP-адреса.

TCP в нестабильных сетях

меньше половины канала

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

Структура пакета

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности (с помощью контрольных сумм) заголовка и существенных данных. Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Биты 0 — 15 16-31
0-31 Порт отправителя (Source port) Порт получателя (Destination port)
32-63 Длина датаграммы (Length) Контрольная сумма (Checksum)
64-… Данные (Data)

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя

В этом поле указывается номер порта отправителя. Предполагается, что это значение задаёт порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, динамическим. Если источником является сервер, то его порт будет одним из «хорошо известных».

Порт получателя

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

Длина датаграммы

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт.

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (232 — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной превышающей 1500 байт нужно проверять возможность такой связи опытным путём на конкретном оборудовании.

Контрольная сумма

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

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

Сравнительная таблица TCP и UDP
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 Нет рукопожатия (протокол без установления соединения)

Измерь его правильно! Краткое описание общепринятого метода оценки производительности DB серверов

Сообщество программистов (администраторов) 1С является одним из самых замкнутых на себя.
Тот же JAVA senior без особых вопросов напишет код на PHP или на Python, если этого потребует обстановка.
1Сники же и powershell и bash и PHP и все остальное с разной степенью успешности реализуют на 1С.
В последнее время ситуация немного меняется, классическое высшее образование программистов уже не ограничивается ассемблером, бейсиком и фортраном.
Никто не падает в обморок при виде
class HelloWorld {
public static void main(String[] args) {
System.out.println(«Hello World!»);
}
}
Попробуем покуситься на тест Гилева и узнать, как без него обходятся DBA админы остального мира, слабонервных прошу удалиться, остальных прошу под кат…

Считаем соединения

Disclaimer: для иллюстрации работы с метриками в разных срезах я буду показывать наш интерфейс (dsl) работы с метриками, но это можно сделать и на opensource хранилищах.

В первую очередь мы разделяем все соединения на входящие (inbound) и исходящие (outbound) по отношению к серверу.

Каждое TCP соединения в определенный момент времени находится в одном из , разбивку по которым мы тоже сохраняем (это иногда может оказаться полезным):

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

Здесь так же видно резкое падение общего количества соединений незадолго до 11 Jun, попробуем посмотреть на соединения в разрезе listen портов:

На этом графике видно, что самое значительное падение было на порту 8014, посмотрим только 8014 (у нас в интерфейсе можно просто нажать на нужном элементе легенды):

Попробуем посмотреть, изменилось ли количество входящий соединений по всем серверам?

Выбираем серверы по маске “srv10*”:

Теперь мы видим, что количество соединений на порт 8014 не изменилось, попробуем найти на какой сервер они мигрировали:

Мы ограничили выборку только портом 8014 и сделали группировку не по порту, а по серверам.

Теперь понятно, что соединения с сервера srv101 перешли на srv102.

Приложения

Многочисленные ключевые Интернет-приложения используют UDP, в их числе — DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).

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

Предварительные условия

Используемые компоненты

Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

Cisco CallManager версии 3.3(x)

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

Условные обозначения

Дополнительные сведения о применяемых в документе обозначениях см. в статье Условные обозначения, используемые в технической документации Cisco.

Выводы

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

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

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

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