Сети и системы телекоммуникаций. Погонин В.А - 89 стр.

UptoLike

ВУЗ: 

ТГТУ | Тамбов

Составители: 

Рубрика: 

Тело объекта (если оно присутствует) посылается с HTTP запросом или ответом и имеет фор-
мат и кодирование, определяемое полями заголовка объекта (entity-header fields):
entity-body = *OCTET
Тело объекта (entity-body) представлено в сообщении только тогда, когда присутствует тело
сообщения (message-body). Тело объекта (entity-body) получается из тела сообщения (message-
body) декодированием любого кодирования передачи, указанного в поле Transfer-Encoding, кото-
рое может быть применено для гарантирования безопасной и правильной передачи сообщения.
Когда в сообщении содержится тело объекта (entity-body), тип данных этого тела определяется
полями заголовка Content-Type и Content-Encoding. Они определяют двухуровневую упорядочен-
ную модель кодирования:
entity-body := Content-Encoding( Content-Type( data ) )
Тип содержимого (Content-Type) определяет медиатип лежащих в основе данных. Кодирова-
ние содержимого (Content-Encoding) может использоваться для указания любых дополнительных
кодирований содержимого, примененных к данным (обычно с целью сжатия). Кодирование со-
держимого (Content-Encoding) является свойством запрошенного ресурса. По умолчанию никако-
го кодирования не задано.
В любое HTTP/1.1 сообщение, содержащее тело объекта (entity-body) включает поле заголовка
Content-Type, определяющее медиатип этого тела. В том и только в том случае, когда медиатип не
указан в поле Content-Type, получатель может попытаться самостоятельно определить медиатип,
проверяя содержимое и/или расширение (расширения) в URL, используемого для идентификации
ресурса. Если медиатип остался нераспознан, получателю следует обрабатывать его как тип
"application/octet-stream".
Длина тела объекта (entity-body) – это длина тела сообщения (message-body), полученного по-
сле декодирования всех кодирований передачи.
9.4.8. СОЕДИНЕНИЯ (CONNECTIONS)
До введения в протокол постоянных соединений для запроса каждого URL устанавливалось
отдельное TCP соединение, что увеличивало нагрузку на HTTP сервера и вызывало перегрузку
сетей. Использование встроенных изображений и других связанных данных часто требует от кли-
ента инициировать несколько запросов к одному серверу за короткий промежуток времени.
Постоянные HTTP соединения имеют ряд преимуществ:
− открытие и закрытие меньшего количества TCP соединений экономит время центрального
процессора и память, используемую для управляющих блоков протокола TCP;
− HTTP запросы и ответы может быть конвейеризованы в соединении. Конвейерная обра-
ботка позволяет клиенту делать несколько запросов не ожидая ответа на каждый, позволяет
пользоваться единственным TCP соединением более эффективно, с меньшими затратами време-
ни;
− загрузка сети уменьшается с уменьшением числа пакетов, необходимых для открытия TCP
соединений, и, следовательно, предоставляет протоколу TCP достаточно времени для определе-
ния состояния перегрузки сети;
− HTTP может развиваться более элегантно, так как ошибки можно сообщать без закрытия
TCP соединения в качестве штрафа. Клиенты, использующие будущие версии HTTP могли бы
оптимистично пробовать новые возможности, а при связи со старым сервером, повторять запрос,
используя старую семантику после сообщения об ошибке.
Значительное отличие HTTP/1.1 от ранних версий HTTP состоит в том, что постоянные соеди-
нения являются заданным по умолчанию поведением любого HTTP соединения. То есть если не
обозначено иного, клиент может считать, что сервер поддержит постоянное соединение.
Постоянные соединения обеспечивают механизм, согласно которому клиент и сервер могут
сообщить о разрыве TCP соединения. Это сигнализируется путем использования поля заголовка
Connection.

Страницы