Ща разбираюсь с другим протоколом -   QUIC. Это гугловская разработка. IT шаманы рекомендуют включить эту фичу в браузере для улучшения работы ютуба. Но что это и как работает? Давайте разбираться. Работает он поверх udp пакетов, соответственно, не имеет ограничения на tcp соединения (идентифицируемые четвëркой: ip отправителя, порт отправителя, ip адресата, порт адресата). На практике это значит, что придя домой со смартфоном и переключившись с 4G на Wi-Fi (и выходя из дома) Вам не нужно будет переустанавливать соединение с ютубом заново. Скажу больше. Теоретически этот протокол позволяет качать трафик одновременно и по 4G, и по Wi-Fi. Также этот протокол позволяет быстрее устанавливать шифрованное соединение, чем по обычному TLS (шифрование поверх tcp), но, по-моему, это мелочь, гораздо интереснее что он даëт (какие выигрыши) в процессе работы непосредственно соединения. Сначала гугловские разработчики сделали так: прикрутили типа RAID 5 фишку к сети - увеличили на 10% размер каждого пакета избыточной информацией и теперь при потере пакета он не перезапрашивается, а восстанавливается по избыточной информации из других пакетов. Это даст выигрыш на линиях связи с ошибками, потерями пакетов, а на отличных линиях связи только на 10% ухудшит их ширину пропускания, как я понимаю. Поэтому несколько лет назад гугловцы отказались от идеи "RAID 5" в своëм протоколе. Что сделали вместо этого - пока изучаю информацию...

Отредактировано Статус (09.09.2024 17:02:08)

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

У меня свой выбор кем разбавлять.

Кто имеется в виду?

Насчëт Марины Салье. Я стараюсь не перебирать негатива, чтобы счастье из жизни не исчезло.

Продолжу про QUIC.Потеря пакетов данных — распространенная проблема в нестабильных сетях, особенно в мобильных соединениях. QUIC предлагает революционное решение этой проблемы:1. Селективное повторное отправление данныхВместо повторной отправки всего пакета данных, QUIC может повторно передать только потерянные фрагменты. Это значительно снижает объем передаваемых данных и уменьшает задержки.2. Независимая обработка потоковQUIC обрабатывает каждый поток данных независимо, что означает, что потеря пакета в одном потоке не влияет на другие потоки. Это существенно повышает общую стабильность соединения.
Мультиплексирование и решение проблемы блокировки головного узлаМультиплексирование в QUIC представляет собой значительное улучшение по сравнению с TCP:

1. Параллельная передача данных

QUIC позволяет передавать несколько потоков данных одновременно через одно соединение. Это особенно эффективно при загрузке веб-страниц, где требуется получение множества ресурсов.

2. Устранение эффекта "головной блокировки"

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

Итого. Этот протокол имеет смысл включать в нестабильных сетях, мобильных сетях и, возможно, когда осуществляется связь через континент (у сервиса отсутствуют зеркала, облако, CDN).
Теперь стало понятнее, зачем IT шаманы включают этот протокол в браузере.

Отредактировано Статус (11.09.2024 11:27:31)

Подпись автора

Ставьте лайки, их не зря придумали