Jump to content

Кодирование передачи фрагментов

Кодирование передачи фрагментов — это механизм потоковой передачи данных, доступный в протоколе передачи гипертекста (HTTP) версии 1.1, определенном в RFC 9112 §7.1 . При кодировании порционной передачи поток данных делится на серию непересекающихся «фрагментов». Фрагменты отправляются и принимаются независимо друг от друга. Ни отправителю, ни получателю в любой момент времени не требуется никаких знаний о потоке данных за пределами обрабатываемого в данный момент фрагмента.

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

Кодирование передачи фрагментов не поддерживается в HTTP/2 , который предоставляет собственные механизмы потоковой передачи данных. [1]

Обоснование

[ редактировать ]

Внедрение фрагментированного кодирования дало различные преимущества:

  • Кодирование передачи фрагментов позволяет серверу поддерживать постоянное соединение HTTP для динамически генерируемого контента. В этом случае заголовок HTTP Content-Length нельзя использовать для разграничения содержимого и следующего HTTP-запроса/ответа, поскольку размер содержимого еще не известен. Преимущество кодирования фрагментов заключается в том, что нет необходимости генерировать полный контент перед записью заголовка, поскольку оно позволяет передавать контент в виде фрагментов и явно сигнализировать об окончании контента, делая соединение доступным для следующего HTTP-запроса/ответа.
  • Кодирование фрагментов позволяет отправителю отправлять дополнительные поля заголовка после тела сообщения. Это важно в тех случаях, когда значения поля не могут быть известны до тех пор, пока содержимое не будет создано, например, когда содержимое сообщения должно быть подписано цифровой подписью. Без фрагментированного кодирования отправителю пришлось бы буферизовать содержимое до его завершения, чтобы вычислить значение поля и отправить его перед содержимым.

Применимость

[ редактировать ]

Для версии 1.1 протокола HTTP механизм фрагментированной передачи считается всегда и в любом случае приемлемым, даже если он не указан в поле заголовка запроса TE (кодирование передачи), и при использовании с другими механизмами передачи его всегда следует применять в последнюю очередь. передаваемые данные и не более одного раза. Этот метод кодирования передачи также позволяет отправлять дополнительные поля заголовка объекта после последнего фрагмента, если клиент указал параметр «трейлеры» в качестве аргумента поля TE. Исходный сервер ответа также может решить отправить дополнительные трейлеры сущностей, даже если клиент не указал опцию «трейлеры» в поле запроса TE, но только если метаданные не являются обязательными (т. е. клиент может использовать полученную сущность без них). ). Всякий раз, когда используются трейлеры, сервер должен указывать их имена в поле заголовка «Трейлер»; трем типам полей заголовка специально запрещено появляться в качестве поля концевика: Transfer-Encoding , Content-Length и Trailer .

Если Поле Transfer-Encoding со значением " chunked " указывается в HTTP-сообщении (либо запросе, отправленном клиентом, либо ответе от сервера), тело сообщения состоит из одного или нескольких фрагментов и одного завершающего фрагмента с необязательным трейлером перед финальной последовательностью ␍␊ ( т.е. возврат каретки с последующим переводом строки ).

Каждый фрагмент начинается с количества октетов встроенных в него данных, выраженного в виде шестнадцатеричного числа в ASCII, за которым следуют необязательные параметры ( расширение фрагмента ) и завершающая последовательность ␍␊, за которой следуют данные фрагмента. Чанк завершается ␍␊.

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

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

Полями заголовка, регулирующими использование трейлеров, являются TE (используются в запросах) и Trailers (используются в ответах).

Использование со сжатием

[ редактировать ]

HTTP-серверы часто используют сжатие для оптимизации передачи, например Кодирование контента: gzip или Кодирование контента: deflate . Если включены как сжатие, так и фрагментированное кодирование, поток контента сначала сжимается, а затем разбивается на фрагменты; поэтому само кодирование фрагмента не сжимается, а данные в каждом фрагменте сжимаются индивидуально. Затем удаленная конечная точка декодирует поток, объединяя фрагменты и распаковывая результат.

Закодированные данные

[ редактировать ]

Следующий пример содержит три фрагмента данных размером 4, 7 и 11 (шестнадцатеричный «B») октетов.

4␍␊Wiki␍␊7␍␊pedia i␍␊B␍␊n ␍␊chunks.␍␊0␍␊␍␊

Ниже представлена ​​аннотированная версия закодированных данных.

4␍␊            (chunk size is four octets)
Wiki           (four octets of data)
␍␊             (end of chunk)

7␍␊            (chunk size is seven octets)
pedia i        (seven octets of data)
␍␊             (end of chunk)

B␍␊            (chunk size is eleven octets)
n ␍␊chunks.    (eleven octets of data)
␍␊             (end of chunk)

0␍␊            (chunk size is zero octets, no more chunks)
␍␊             (end of final chunk with zero data octets)

Примечание. В размер каждого фрагмента не включены два байта ␍␊, которыми завершаются данные каждого фрагмента.

Декодированные данные

[ редактировать ]

Декодирование приведенного выше примера дает следующие октеты:

Wikipedia in ␍␊chunks.

Байты выше обычно отображаются как

Wikipedia in 
chunks. 

См. также

[ редактировать ]
  1. ^ HTTP/2 . Июнь 2022. сек. 8.1. дои : 10.17487/RFC9113 . РФК 9113 . HTTP/2 использует кадры DATA для передачи полезных данных сообщений. Кодирование фрагментированной передачи, определенное в разделе 7.1 [HTTP/1.1], НЕ ДОЛЖНО использоваться в HTTP/2.
[ редактировать ]
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: cb2aab8e0e87405b05f83539d499867f__1718796600
URL1:https://arc.ask3.ru/arc/aa/cb/7f/cb2aab8e0e87405b05f83539d499867f.html
Заголовок, (Title) документа по адресу, URL1:
Chunked transfer encoding - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)