История изменений
Исправление Aber, (текущая версия) :
HTTP 1.1 постоянное TCP содинение, возможность отсылать множество запросов, ответы приходят последовательно. Пока не пришел ответ на запрос №1, ответы на запрос №2, №3 и №4 не придут. Также текстовый проткол.
Я не понимаю что это значит. По протоколу HTTP 1.1 можно было скачивать файлы в мультипоток в любой последовательности фрагментов. Мне кажется там можно было задать смещение с какого байта качать. Это я как некогда пользователь FlashGet говорю, с протоколом на низком уровне я не знаком.
HTTP 3 бинарнаый проткол на QUIC, потоки уже реализованы на уровне UDP. Сам QUIC расшифровывается «Quick UDP Internet Connection», является UDP с встроенным TLS.
У HTTP/2 есть недостаток, TCP соединение оперирует последовательностями пакетов, если какой пакет в последовательности потеряется то он должен быть перезапрошен, этим управляет сетевая подсистема а не прикладной кодер. Допустим другие пакеты уже прибыли и теперь где-то в сетевой подсистеме ожидает буфер байт в котором отсутствует какой-то сегмент, и пока он не придет никакого ByteStream из открытого сокета не выльется. Протокол HTTP/3 реализованный на UDP позволяет все это чуть расслабить и обрабатывать прибывающие данные по мере готовности.
Исправление Aber, :
HTTP 1.1 постоянное TCP содинение, возможность отсылать множество запросов, ответы приходят последовательно. Пока не пришел ответ на запрос №1, ответы на запрос №2, №3 и №4 не придут. Также текстовый проткол.
Я не понимаю что это значит. По протоколу HTTP 1.1 можно было скачивать файлы в мультипоток в любой последовательности фрагментов. Мне кажется там можно было задать смещение с какого байта качать. Это я как некогда пользователь FlashGet говорю, с протоколом на низком уровне я не знаком.
HTTP 3 бинарнаый проткол на QUIC, потоки уже реализованы на уровне UDP. Сам QUIC расшифровывается «Quick UDP Internet Connection», является UDP с встроенным TLS.
У HTTP/2 есть недостаток, TCP соединение оперирует последовательностями пакетов, если какой фрагмент потеряется то он должен быть перезапрошен, этим управляет сетевая подсистема а не прикладной кодер. Допустим другие пакеты уже прибыли и теперь где-то в сетевой подсистеме ожидает буфер байт в котором отсутствует какой-то сегмент, и пока он не придет никакого ByteStream из открытого сокета не выльется. Протокол HTTP/3 реализованный на UDP позволяет все это чуть расслабить и обрабатывать прибывающие данные по мере готовности.
Исправление Aber, :
HTTP 1.1 постоянное TCP содинение, возможность отсылать множество запросов, ответы приходят последовательно. Пока не пришел ответ на запрос №1, ответы на запрос №2, №3 и №4 не придут. Также текстовый проткол.
Я не понимаю что это значит. По протоколу HTTP 1.1 можно было скачивать файлы в мультипоток в любой последовательности фрагментов. Мне кажется там можно было задать смещение с какого байта качать. Это я как некогда пользователь FlashGet говорю, с протоколом на низком уровне я не знаком.
HTTP 3 бинарнаый проткол на QUIC, потоки уже реализованы на уровне UDP. Сам QUIC расшифровывается «Quick UDP Internet Connection», является UDP с встроенным TLS.
У HTTP/2 есть недостаток, TCP шлет пакеты последовательно, если какой потеряется то он должен быть перезапрошен, этим управляет сетевая подсистема а не прикладной кодер. Допустим другие пакеты уже прибыли и теперь где-то в сетевой подсистеме ожидает буфер байт в котором отсутствует какой-то сегмент, и пока он не придет никакого ByteStream из открытого сокета не выльется. Протокол HTTP/3 реализованный на UDP позволяет все это чуть расслабить и обрабатывать прибывающие данные по мере готовности.
Исправление Aber, :
HTTP 1.1 постоянное TCP содинение, возможность отсылать множество запросов, ответы приходят последовательно. Пока не пришел ответ на запрос №1, ответы на запрос №2, №3 и №4 не придут. Также текстовый проткол.
Я не понимаю что это значит. По протоколу HTTP 1.1 можно было скачивать файлы в мультипоток в любой последовательности фрагментов. Мне кажется там можно было задать смещение с какого байта качать. Это я как некогда пользователь FlashGet говорю, с протоколом на низком уровне я не знаком.
HTTP 3 бинарнаый проткол на QUIC, потоки уже реализованы на уровне UDP. Сам QUIC расшифровывается «Quick UDP Internet Connection», является UDP с встроенным TLS.
У HTTP/2 есть недостаток, TCP шлет пакеты последовательно, если какой потеряется то он должен быть перезапрошен, этим управляет сетевая подсистема а не прикладной кодер. Допустим другие пакеты уже прибыли и теперь где-то в сетевой подсистеме ожидает буфер байт в котором отсутствует какой-то сегмент, и пока он не придет никакого ByteStream из открытого сокета не выльется. Протокол HTTP/3 реализованный на UDP поставляет все это чуть расслабить и обрабатывать прибывающие данные по мере готовности.
Исходная версия Aber, :
HTTP 1.1 постоянное TCP содинение, возможность отсылать множество запросов, ответы приходят последовательно. Пока не пришел ответ на запрос №1, ответы на запрос №2, №3 и №4 не придут. Также текстовый проткол.
Я не понимаю что это значит. По протоколу HTTP 1.1 можно было скачивать файлы в мультипоток в любой последовательности фрагментов. Мне кажется там можно было задать смещение с какого байта качать. Это я как некогда пользователь FlashGet говорю, протокол вручную я не писал :)
HTTP 3 бинарнаый проткол на QUIC, потоки уже реализованы на уровне UDP. Сам QUIC расшифровывается «Quick UDP Internet Connection», является UDP с встроенным TLS.
У HTTP/2 есть недостаток, TCP шлет пакеты последовательно, если какой потеряется то он должен быть перезапрошен, этим управляет сетевая подсистема а не прикладной кодер. Допустим другие пакеты уже прибыли и теперь где-то в сетевой подсистеме ожидает буфер байт в котором отсутствует какой-то сегмент, и пока он не придет никакого ByteStream из открытого сокета не выльется. Протокол HTTP/3 реализованный на UDP поставляет все это чуть расслабить и обрабатывать прибывающие данные по мере готовности.