Кодирование передачи фрагментов — это механизм потоковой передачи данных, доступный в протоколе передачи гипертекста (HTTP) версии 1.1, определенном в RFC 9112 §7.1. При кодировании фрагментированной передачи поток данных делится на серию непересекающихся «фрагментов». Фрагменты отправляются и принимаются независимо друг от друга. Ни отправителю, ни получателю в любой момент времени не требуется никаких знаний о потоке данных за пределами обрабатываемого в данный момент фрагмента.
Каждому фрагменту предшествует его размер в байтах. Передача заканчивается, когда получен фрагмент нулевой длины. Ключевое слово chunked в заголовке Transfer-Encoding используется для обозначения фрагментированной передачи.
Кодирование передачи фрагментов не поддерживается в HTTP/2 , который предоставляет собственные механизмы потоковой передачи данных. [1]
Внедрение фрагментированного кодирования дало различные преимущества:
Для версии 1.1 протокола HTTP механизм фрагментированной передачи считается всегда и в любом случае приемлемым, даже если он не указан в поле заголовка запроса TE (кодирование передачи), и при использовании с другими механизмами передачи его всегда следует применять в последнюю очередь. передаваемые данные и не более одного раза. Этот метод кодирования передачи также позволяет отправлять дополнительные поля заголовка объекта после последнего фрагмента, если клиент указал параметр «трейлеры» в качестве аргумента поля TE. Исходный сервер ответа также может принять решение об отправке дополнительных трейлеров сущностей, даже если клиент не указал опцию «трейлеры» в поле запроса TE, но только если метаданные не являются обязательными (т. е. клиент может использовать полученную сущность без них). ). Всякий раз, когда используются трейлеры, сервер должен указывать их имена в поле заголовка «Трейлер»; трем типам полей заголовка специально запрещено появляться в качестве поля концевика: Transfer-Encoding , Content-Length и Trailer .
Если в HTTP-сообщении (либо в запросе, отправленном клиентом, либо в ответе сервера) указано поле Transfer-Encoding со значением « chunked », тело сообщения состоит из одного или нескольких фрагментов и одного завершающего фрагмента. с необязательным концевым перед последней последовательностью ␍␊ (т. е. возврат каретки с последующим переводом строки ).
Каждый фрагмент начинается с количества октетов встроенных в него данных, выраженного в виде шестнадцатеричного числа в ASCII , за которым следуют необязательные параметры ( расширение фрагмента ) и завершающая последовательность ␍␊, за которой следуют данные фрагмента. Чанк завершается ␍␊.
Если предусмотрены расширения фрагментов, размер фрагмента заканчивается точкой с запятой, за которым следуют параметры, каждый из которых также отделяется точкой с запятой. Каждый параметр кодируется как имя расширения, за которым следуют необязательный знак равенства и значение. Эти параметры могут использоваться, например, для дайджеста текущего сообщения или цифровой подписи или для указания предполагаемого хода передачи.
Завершающий фрагмент представляет собой специальный фрагмент нулевой длины. Он может содержать трейлер, который состоит из (возможно, пустой) последовательности полей заголовка объекта. Обычно такие поля заголовка отправляются в заголовке сообщения; однако может оказаться более эффективным определить их после обработки всего объекта сообщения. В этом случае полезно отправить эти заголовки в трейлере.
Полями заголовка, регулирующими использование трейлеров, являются TE (используются в запросах) и Trailers (используются в ответах).
HTTP-серверы часто используют сжатие для оптимизации передачи, например, с помощью Content-Encoding: gzip или Content-Encoding: deflate . Если включены как сжатие, так и фрагментированное кодирование, поток контента сначала сжимается, а затем разбивается на фрагменты; поэтому само кодирование фрагмента не сжимается, и данные в каждом фрагменте не сжимаются индивидуально. Затем удаленная конечная точка декодирует поток, объединяя фрагменты и распаковывая результат.
Следующий пример содержит три фрагмента данных размером 4, 7 и 11 (шестнадцатеричный «B») октетов.
4␍␊Wiki␍␊7␍␊pedia i␍␊B␍␊n ␍␊chunks.␍␊0␍␊␍␊
Ниже представлена аннотированная версия закодированных данных.
4␍␊ (размер блока — четыре октета) Wiki (четыре октета данных) ␍␊ (конец фрагмента)7␍␊ (размер блока семь октетов) pedia i (семь октетов данных) ␍␊ (конец фрагмента)B␍␊ (размер блока — одиннадцать октетов) n ␍␊части. (одиннадцать октетов данных) ␍␊ (конец фрагмента)0␍␊ (размер блока равен нулю октетов, блоков больше нет) ␍␊ (конец последнего фрагмента с нулевым октетом данных)
Примечание. В размер каждого фрагмента не включены два байта ␍␊, завершающие данные каждого фрагмента.
Декодирование приведенного выше примера дает следующие октеты:
Википедия в ␍␊кусках.
Байты выше обычно отображаются как
Википедия вкуски.
HTTP/2 использует кадры DATA для передачи полезных данных сообщений. Кодирование фрагментированной передачи, определенное в разделе 7.1 [HTTP/1.1], НЕ ДОЛЖНО использоваться в HTTP/2.