Отмененные НТТР-передачи

Пользователь может отменить текущую HTTP-передачу, нажав кнопку Stop или щелкпув мышью на гиперссылке, чтобы перейти на другую страницу. Операции отмены — это обычная составляющая процесса работы в Web. В некоторых случаях браузер может отображать содержимое страницы но мере ее загрузки с сервера. Это позволяет пользователю прочитать часть страницы и, возможно, щелкпуть мышью на гиперссылке до того, как страница будет загружена полио- стыо. Пользователь может щелкнуть мышью на гиперссылке до завершения загрузки изображений. В других случаях пользователь может отменить слишком медленную загрузку и нажать кнопку Reload, чтобы попытаться спова загрузить страницу. Пользователи с медленными подключениями к Internet чаще отменяют запросы. Вероятность прерывания загрузки больших ресурсов достаточно велика. В данном разделе мы объясним, почему для отмены передачи данных требуется закрыть соединение и расскажем о влиянии этого на производительность Web.

ОТСУТСТВИЕ МЕХАНИЗМА ОТМЕНЫ ПЕРЕДАЧИ ДАННЫХ В HTTP

В протоколе HTTP отсутствует механизм прерывания клиентом текущей передачи данных. Возможность отмены текущей передачи данных лежиг на границе между нрикладпым и транспортным уровнями. Включение механизма отмены передачи данных в HTTP затруднительно без привязки к какому-либо копкретиому протоколу транспортного уровня. Хотя обычно используется TCP, спецификация HTTP не связана с особенностями какого-либо протокола транспортного уровня. Другие протоколы нрикладпого уровня, например Telnet, столкнулись с теми же проблемами. В Telnet выбрано другое решение. Во время сеанса Telnet пользователь может нажать Ctrl+C или Delete, чтобы отменить текущее действие. Отправитель может использовать поле указателя срочности в заголовке TCP-пакета, чтобы привлечь внимание получателя, как описано в главе 5 (раздел 5.2.7). Это позволяет получателю избежать необходимости обрабатывать предыдущие байты сообщения. Правда, эго решение привязано к протоколу TCP.

В спецификации НТТР/1.1 можно было бы пойти но тому же пути, введя метод запроса для отмены передачи текущего сообщения. Но это осложнит обработку последовательностей запросов. Предположим, что клиент послал последовательность запросов через долговременное соединение, а после этого послал по гому же соединению запрос об отмепе передачи данных. Серверу необходимо было бы просмотреть всю очередь входящих запросов, чтобы узнать о том, что клиент послал запрос об отмепе. Если клиент послал несколько запросов последовательности, то либо серверу пришлось бы отменять все остающиеся в его очереди запросы, либо клиенту пришлось бы указывать, какие именно запросы нужно отменить. Решение этих проблем сильно усложнило бы протокол. Поэтому спецификация НТТР/1.1 не включает механизма отмены передачи данных.

В результате у Web-клиента нет эффективного способа отмены НТТР-запроса, кроме разрыва соединения, по которому был отправлен запрос. Например, пользователь отменил загрузку 20-ти мегабайтного файла, когда 5 мегабайтов уже иолу- чены. Клиент (то есть браузер) имеет выбор: разорвать соединение или получить 15 Мбайт ненужных данных. Получение данных увеличивает трафик и уменьшает пропускную способность, которая очепь пригодилась бы для выполнения следующего запроса пользователя. Все это увеличивает задержку, воспринимаемую пользователем. Соответственно, большинство реализаций Web клиентов предпочитают закрывать соединения.

ВЛИЯНИЕ ОПЕРАЦИЙ ОТМЕНЫ ПЕРЕДАЧИ ДАННЫХ НА ПРОИЗВОДИТЕЛЬНОСТЬ

Разрыв ТСР-соединения оказывает заметное влияние на производительность. Например, браузер по протоколу НТТР/1.1 установил долговременное соединение с сервером. Получив HTML-файл, браузер посылает последовательность запросов на изображения, встроенные в страницу. Предположим, что когда сервер передавал эти изображения, пользователь щелкпул мышью на гииерссылке, чтобы перейти на другую страницу того же сайта. Браузер разрывает соединение, чтобы отменить последовательность запросов. Разрыв соединения позволяет избежать получения не- пужпых изображений. Теперь, пользователь должен ждать, когда браузер установит повое соединение, чтобы получить другую страницу. Для того чтобы открыть соединение, требуется обычпая грехшаговая процедура и повторение фазы медленного старта.

Отмепа запроса может привести к дополнительным проблемам, если у запроса имеется побочный эффект. Например, запрос пользователя может создать новый ресурс, увеличить зпачепие переменной или запустить сценарий для покупки товара на сайте электронной торговли. Если соединение разрывается до того, как браузер иолучит ответ сервера, пользователь не узнает, был ли выполнен запрос или пет. HTTP не предоставляет серверу возможности в одностороннем порядке оповестить пользователя о том, что его запрос был обработай. Web-сайт может сохранить дополнительные данные, которые иозволяг клиенту узпать, был ли обработан запрос. Предположим, что пользователь посетил сайт электронной торговли и послал запрос, который добавляет товар в «магазинную тележку». Отменив запрос, пользователь не знает, был ли товар добавлен в тележку. На Web сайте может быть страница, на которой пользователь может увидеть текущее содержимое своей тележки. Это позволит пользователю узнать, был ли выполнен предыдущий запрос до того, как соединение было разорвапо. Другой вариант состоит в том, что HTML-форма может включать упикальпый номер транзакции, который позволит сценарию, обрабатывающему запрос, определить, была ли транзакция выполнена ранее.

Операция отмены передачи данных теснее связывает между собой запросы из одной последовательности в одном ТСР-соедииепии. Отмена одного запроса в последовательности приводит к отмене всех еще необработанных запросов в этой последовательности. Например, отмепа загрузки страницы прекращает загрузку всех встроенных в страницу изображений. Это совпадает с намерением пользователя отменить загрузку всей страницы, а не отдельных ее ресурсов. А теперь рассмотрим пример прокси-сервера, который посылает последовательность запросов двух клиентов по одному ТСР-соединепию с Web-сервером. Прокси-сервер сначала посылает запрос от лица клиента А, а затем — от лица клиента В. Если клиент А отмеиит свой запрос, у ирокси-сервера ес гь две возможности. Оп может сохранить соединение открытым и получить весь ответ Web-сервера клиенту А. Это неэкономно, так как ответ уже не нужен клиенту. Прокси-сервер может закрыть соединение. В таком случае серверу потребуется открыть повое соединение и повторить запрос клиента В. Оба варианты плохи. Прокси-сервер не может уйти от этой проблемы, не открывая отдельного соединения для каждого из клиентов.

Операция отмены, инициированная пользователем, не сразу останавливает передачу данных. Рассмотрим пример браузера, контактирующего напрямую с Web- сервером. Когда пользователь пажимает кнопку Stop, браузер инициирует закрытие соединения, посылая серверу пакет FIN или RST. Некоторое время сервер продолжает передавать данные клиенту. В зависимости от времени доставки пакетов и размера ответа сервера, последний может быть целиком передан клиенту до того, как сервер получит RST/FIN. Проблема обостряется, когда клиент передает запрос через прокси-сервер. В таком случае, передача НТТР-данных использует TCP-co- едииение между клиентом и прокси-сервером, а также соединение между прокси-сервером и Web-сервером. Предположим также, что соединение сервер-прокси имеет большую пропускную способность, чем соединение клиент-прокси. Это обычная ситуация, если у клиента медленное подключение. В связи с несовпадением пропускных способностей пересылка данных между Web-сервером и про- кси-сервером осуществляется быстрее, чем между прокси-сервером и клиентом.

Рассмотрим случай, когда клиент запрашивает ресурс объемом 20 мегабайтов и отменяет запрос, получив 5 мегабайтов данных. Прокси-сервер мог получить за это время весь ресурс. Пересылка оставшихся 15 мегабайтов становится бесполезной, если прокси-сервер не получит запрос на этот же ресурс в ближайшем будущем. Если бы клиент связывался с Web-сервером непосредственно, а не через прокси-сервер, сервер не передал бы лишние 15 мегабайтов. Управление трафиком не дало бы Web-серверу посылать пакеты так часто. Предотвращение передачи лишних данных требует некоторой взаимосвязи между соединениями «сервер-прокси» и «ирокси-клиент». Прокси-сервер может ограничить объем данных, получаемых им по соединению с сервером. Не читая данных во входном буфере, прокси-сервер фактически уменьшает приемное окно ТСР-соединения с сервером. В свою очередь, это ограничивает объем данных, которые сервер может передать. Выбор объема данных, которое прокси-сервер читает из входного буфера, связан с противоречием между получением лишних данных при отмене передачи данных и уменьшением задержек при нормальной передаче данных.

ЗАКРЬГГИЕ ТСР-СОЕДИНЕНИЯ

Браузер отменяет текущую передачу данных, сделав системный вызов, чтобы закрыть соединение с Web-сервером. В зависимости от браузера и операционной системы, этот вызов приведет к передаче либо пакета FIN, либо RST. Предположим, что система передает пакет FIN. Получив пакет FIN, операционная система передаст приложению Web-сервера EOF. Операционная система продолжит передавать данные из выходного буфера удаленному клиенту. Получив EOF, Web-cepвер прекращает передавать данные в выходной буфер. Данные, уже находящиеся в буфере или находящиеся в сети, будут доставлены Компьютеру клиента (па котором работает браузер). Получит ли эти дополнительные данные браузер — зависит от того, как было закрыто соединение. Если браузер закрыл копцы соединения для передачи и приема данных, то операционная система отбросит данные. Если конец для приема данных остается открытым, то операционная система передаст данные браузеру. Продолжение получения данных может быть полезно, если браузер планирует кэшировать полученное содержимое для обработки последующих запросов пользователя.

Некоторые реализации UNIX не позволяют приложениям инициировать отправку пакета RST. В них отмена запроса порождает пакет FIN, тогда как в других операционных системах возможна передача пакета RST. Получая RST, операционная система сервера отбросит все подготовленные к отправке через дапное соединение данные, включая те данные, которые Web-сервер уже записал в выходной буфер. Это одновременно и хорошо, и плохо. Плюсом является то, что такое закрытие соединения позволяет избежать передачи лишпих данных с сервера. В дополнение к этому, пакет RST заставляет операционную систему очистить и входной буфер, вместо того, чтобы передать его содержимое приложению, с которым ассоциировано соединение. Это позволит Web-серверу обойтись без чтения последовательности HTTP-запросов, которые могут находиться во входном буфере. Минусом является то, что RST не очень аккуратпо закрывает соединение. Предположим, что часть пакетов, отправленных сервером, не дошла до получателя. Получив RST, операционная система сервера не осуществляет повторную передачу утерянных пакетов.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100