Компьютерные сети

Во всех приведенных примерах мы использовали объекты, относящиеся к web-страницам: базовые HTML-файлы, изображения в формате GIF, JPEG, Java-апплеты и т. д. Мы представляли протокол HTTP в контексте web для того, чтобы обеспечить наглядность и простоту наших описаний, поскольку многие читатели наверняка хорошо знакомы с web-навигацией. Однако было бы большим упущением не отметить, что протокол HTTP также используется для передачи информации другого характера.
Читать далее »

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

Объекты cookie являются альтернативным авторизации средством идентификации пользователей. Описание cookie находится в документе RFC 2109. Обычно объекты cookie находят применение в Интернет-порталах (например, Yahoo!), электронной коммерции (например, Amazon) и рекламе (например, DoubleClick).
Технология cookie подразумевает наличие четырех основных компонентов:
□ заголовочной cookie-строки в ответном сообщении сервера;
□ заголовочной cookie-строки в запросе клиента;
□ cookie-файла, находящегося на стороне клиента и обрабатываемого браузером;
□ удаленной базы данных, расположенной на web-сайте.
Читать далее »

Вероятно, вам приходилось сталкиваться с ситуациями, когда сервер предлагал вам ввести имя пользователя и пароль для доступа к своему информационному пространству. Подобный механизм доступа называется авторизацией. Запрос и получение авторизации в HTTP зачастую производятся с помощью особых заголовков и кодов состояния. Рассмотрим следующий пример. Пусть клиент инициирует запрос объекта, причем объект находится на сервере, требующем авторизации.
Читать далее »

Мы выяснили, что HTTP-сервер не запоминает информацию о состоянии соединения. Это упрощает разработку сервера и позволяет достичь значительной производительности за счет одновременного обслуживания сотен ТСР-соединений. Тем не менее возможность распознавания пользователей сервером является весьма желательной. Причиной этому может служить необходимость разграничения прав доступа к информации, находящейся на сервере, либо предоставление каждому пользователю собственного набора информационных услуг. Протокол HTTP предусматривает два механизма идентификации пользователей: авторизацию и объекты cookie.

Ниже приведен пример типичного ответа, генерируемого HTTP-сервером.
НТТР/1.1 200 ОК Connection: close
Date: Thu. 06 Aug 1998 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon. 22 Jun 1998 09:23:24 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data …)
Читать далее »

Типичное сообщение-запрос протокола HTTP выглядит следующим образом:

GET /somediг/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language:fr

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

Описания протокола HTTP, содержащиеся в документах RFC 1945 и RFC 2616, определяют формат сообщений, предназначенных для обмена между клиентом и сервером. В HTTP существуют два типа сообщений: запросы и ответы.

Непостоянные соединения обладают рядом недостатков. Прежде всего для каждого запрашиваемого объекта должно устанавливаться новое соединение. При этом необходимо учитывать, что каждое соединение требует от протокола TCP выделения буфера, а также ряда служебных переменных как на стороне клиента, так и на стороне сервера. Учитывая то, что многие web-серверы параллельно обслуживают сотни клиентов, подобная схема серьезно затрудняет процесс взаимодействия между клиентами и сервером. Кроме того, установление соединения для каждого объекта из-за времени оборота приводит к дополнительным временным затратам.
Читать далее »

Рассмотрим, каким образом осуществляется передача web-страницы от сервера к клиенту в случае непостоянного HTTP-соединения. Предположим, что страница состоит из базового HTML-файла и десяти JPEG-изображений, находящихся на одном сервере. Пусть URL базового HTML-файла имеет вид _www.someSchooLedu/someDepartment/home.index. Процесс обмена между клиентом и сервером состоит из следующих шагов.
1. HTTP-клиент инициирует ТСР-соединение с сервером www.someSchool.edu через порт номер 80, который по умолчанию является номером порта для HTTP.
2. HTTP-клиент посылает запрос серверу через сокет, выделенный ТСР-соеди-нению, которое было установлено на шаге 1. Запрос включает путь к базовому HTML-файлу: someDepartment/home.index (чуть позже мы рассмотрим HTTP-сообщения более детально).
3. HTTP-сервер получает запрос через сокет, ассоциированный с установленным соединением, извлекает объект someDepartment/home.index, формирует ответ, включающий объект, и отсылает его клиенту через сокет.
4. HTTP-сервер закрывает ТСР-соединение (окончательный разрыв соединения происходит после того, как сервер получает информацию об успешной передаче объекта).
5. HTTP-клиент принимает ответ сервера. ТСР-соединение завершается. Клиент обрабатывает сообщение, в котором указано, что доставленный объект является базовым HTML-файлом. Клиент извлекает файл, обрабатывает его и выделяет ссылки на 10 объектов (JPEG-файлов).
6. Шаги 1-4 повторяются для каждого из 10 объектов.
Читать далее »