Кодирование передачи по частям

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Найти источники:  «Chunked transfer encoding»  -  новости  · газеты  · книги  · ученый  · JSTOR ( июнь 2014 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

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

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

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

Обоснование [ править ]

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

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

Применимость [ править ]

Для версии 1.1 протокола HTTP механизм передачи фрагментов считается всегда и в любом случае приемлемым, даже если он не указан в TE.(кодирование передачи) поле заголовка запроса и при использовании с другими механизмами передачи всегда должно применяться к передаваемым данным последним и никогда не более одного раза. Этот метод кодирования передачи также позволяет отправлять дополнительные поля заголовка объекта после последнего фрагмента, если клиент указал параметр «трейлеры» в качестве аргумента поля TE. Сервер-источник ответа также может решить отправить дополнительные трейлеры объекта, даже если клиент не указал параметр "трейлеры" в поле запроса TE, но только если метаданные являются необязательными (т. Е. Клиент может использовать полученный объект без них. ). Каждый раз, когда используются трейлеры, сервер должен указывать их имена в поле заголовка трейлера; три типа поля заголовка специально запрещены для использования в качестве поля прицепа: Передача-кодирование, Длина содержимого и трейлер .

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

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

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

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

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

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

Использовать со сжатием [ править ]

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

Пример [ править ]

Закодированные данные [ править ]

В следующем примере показаны три фрагмента длиной 4, 6 и 14 (шестнадцатеричное "E"). Размер блока передается в виде шестнадцатеричного числа, за которым следует \ r \ n в качестве разделителя строк, за которым следует блок данных заданного размера.

4 \ r \ n (байтов для отправки)Wiki \ r \ n (данные)6 \ r \ n (байтов для отправки)pedia \ r \ n (данные)E \ r \ n (байтов для отправки)в \ r \ n\ г \ пкуски. \ r \ n (данные)0 \ r \ n (последний байт - 0)\ r \ n (конец сообщения)

Примечание: размер блока указывает размер данных блока и исключает завершающий CRLF ("\ r \ n"). В этом конкретном примере CRLF, следующий за «in», считается как два октета по отношению к размеру блока 0xE (14). CRLF в отдельной строке также считается как два октета по отношению к размеру блока. Знак точки в конце «фрагментов» является 14-м символом, поэтому он является последним символом данных в этом фрагменте. CRLF, следующий за точкой, является завершающим CRLF, поэтому он не учитывается при размере блока 0xE (14).

Декодированные данные [ править ]

Википедия вкуски.

См. Также [ править ]

• Список полей заголовка HTTP

Ссылки [ править ]