Pull to refresh

Comments 20

Как интересно построена эволюция сетевых протоколов и форматов хранения данных:


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


Если формат построен на UDP то как устроены ссылки на ранее посланные данные, если данные могли и не пройти.

Тебе ответ о том, были данные или нет, всё-равно придёт (или не придёт, если пакет потерялся, но тогда будет timeout-event). Просто на транспортном уровне это будет несколько дешевле.

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

Подозреваю, что в случае стабильного соединения это всё равно будет в плюс.

Ниже в комментариях отметили что tcp как раз теряет эффективность на нестабильных каналах радиосвязи.
И использование udp и новый протокол http позволит решать такие проблемы более эффективно, с учетом как раз особенностей интернета на мобильных устройствах.

Уточнение: tcp теряет эффективность на гибридных каналах связи.


Если наш канал связи — куча оптики вокруг земного шара (высокий пинг, околонулевые потери), TCP использует компенсирует пинг увеличенным размером окна отправки и неплохо работает.


Если наш канал связи — радиоканал (низкий пинг, высокие потери), то TCP не может поднять размер окна, но при низком пинге это и не нужно.


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

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

сильно не вчитывайтесь, т.к. автор похоже слабо понимает о чём пишет или лепет из разных статьей с сильными сокращениями. http 1 открывал множество соединений потому что это сильно упрощало реализацию. http2 сервер стал на много сложнее и использует одно соединение для передачи фрагментов разных ресурсов (да и ещё с приоритетами). но с tcp есть проблема в мобильных сетях (особенно когда вы едете на машине) + он сильно привязан к железу - роутерам, свичам и т.д., по-этому реализовать разные механизмы управления скоростью передачи (контролем канала) сложно, в сам tcp протокол это встроено, но то что работает хорошо для проводной сети дома не очень подходит для мобильной. так что приходится это всё переизбирать и вешать на udp. поищите доклад тех директора vk если интересна тема

Да, пожалуй в Ваш комментарий суть вопроса открывает совсем с другой стороны.
Статью Александра нашел, буду читать.

Да потому что в статье написан бред. Эксперименты по тюнингу tcp для современных сетей идут непрерывно, в том числе и силами goggle.
Основное отличие между quic и tcp — первый реализуется в userspace, за счёт этого adoption изменений может быть гораздо более быстрым, не нужно ждать обновления операционных систем, достаточно обновить приложение (и вспоминаем, что chrome и сам отлично обновляется).

Первая версия протокола http требовала завершения запроса в соединении

Если речь про HTTP/1.1 то это не правда ведь. В 1997 уже был RFC.

Это про закрытие соединения. Если бы я написал требует закрытия соединения, то да.

Вы очень витиевато написали. Как насчет:

Первая версия протокола http требовала дожидаться получения ответа перед отправлением следующего запрос в рамках одного соединения.

Формально это кстати неправда, но фактически к сожалению так и было.

Спасибо, ваша формулировка лучше.

Использую её, если не против.

На хабре есть отличные переоводы статей про HTTP/3 (один, два и три). После их прочтения некоторая часть лапши спадает с ушей. Особенно в части того, как все заживём. Спецификация HTTP/3 слишком сложна (грамотных реализаций мало, будет куча проблем неполной совместимости со стандартом и т.п.). Кроме того, груз легаси- серверов, клиентов и промежуточных устройств слишком велик, чтобы этот переход прошёл в обозримой перспективе. Это как IPv6: идея хорошая, но никак не взлетает из-за инерции рынка.

Что вы понимаете под прохождением перехода? Клиент соединяется с сервером, если они оба поддерживают HTTP/3, всё переход прошел. Другой клиент не поддерживает? Ну так кто-то пользуется 0.9, если не жмёт. Какая разница?

Ozon.ru использует третью версию, например.

В целом есть статистика, например - https://w3techs.com/technologies/history_overview/site_element/all

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

Кто-то жалуется на невозможность внедрения, а кто-то уже в проде использует по полной.

Не стал читать статью по причине: неправильное использование мема.

Sign up to leave a comment.

Articles