По 1997 г. броузеры и серверы реализуют протокол HTTP 1.0, который определён в RFC 1245. С 1998 г. был произведён переход на HTTP 1.1, который реализован в RFC 2616. Есть попарная совместимость клиентов и серверов обоих протоколов. Оба протокола в качестве транспортного протокола используют TCP.
2.2.2. Постоянные и непостоянные соединения.
HTTP может использовать как постоянные (persistent), так и непостоянные (nonpersistent) TCP соединения.
Непостоянные соединения.
Рассмотрим шаги передачи от сервера к клиенту в случае непостоянных соединений. Пусть страница состоит из базового HTML файла и 10 JPEG рисунков, все эти 11 объектов находятся на том же самом сервере. Пусть URL-сервер имеет вид www.petrsu.ru/cs/index.html, происходит следующее:
- HTTP клиент инициирует TCP соединение к серверу www.petrsu через порт 80, который постоянно прослушивается сервером.
- HTTP клиент посылает HTTP запрос к серверу через конкретное гнездо ассоциированное с TCP соединением, которое было установлено на первом шаге. Этот запрос включает имя файла к файловой системе (структура запросов через HTTP будет рассмотрена позже).
- Сервер получает запрос через тоже самое гнездо, читает запрашиваемый объект в своей памяти, инкапсулирует его в HTTP ответ и посылает ответ клиенту через тоже самое гнездо.
- Сервер сообщает TCP о необходимости закрыть соединение (TCP реально закроет соединение, только после полного получения ответа клиентом).
- Клиент получает ответ. TCP соединение закрывается. В ответе указано, что инкапсулированным объектом является HTML файл. Клиент извлекает этот файл из ответа, выполняет синтаксический анализ HTML файла и находит там HTML ссылки на 10 JPEG рисунков.
- Первые четыре шага повторяются для каждой ссылки на JPEG объекты.
Постоянные соединения.
Для непостоянных соединений новое соединение должно быть установлено и поддерживаться для каждого запрашиваемого объекта, при этом каждый раз должны быть распределены буферы и переменные TCP, как у клиента, так и у сервера. Это может приводить к серьёзной перегрузке web-сервера, который может обслуживать запросы от сотен клиентов одновременно. Во-вторых, в силу специфики TCP значительное время затрачивается не только на передачу сообщений, но и на установку соединения. Здесь используются два RTT. В случае непостоянного соединения один RTT тратится на установку соединения, а другой на передачу объекта. Наконец каждое новое TCP соединение начинает работу в режиме slow start, чтобы не перегрузить линию связи (см. далее).
При работе в режиме постоянного соединения сервер оставляет TCP соединение открытым после посылки ответа. Последующие запросы и ответы между этими клиентом и сервером посылаются по тому же самому соединению, в частности в предыдущем примере все 11 объектов будут посланы по одному соединению.
В случае постоянного соединения сервер закроет TCP соединение, если оно не будет использоваться в течение некоторого времени (timeout interval). Величина этого интервала, а также использование постоянных и непостоянных соединений могут быть указаны, например, в файлах настройки.
2.2.3. Формат сообщения HTTP.
Существует два типа сообщений - запрос и ответ.
HTTP запрос.
GET /index.html HTTP/1.1 Host: www.petrsu.ru Connection: close User-Agent: Mozilla/4.0 Accept-Language: fr CR LF
Сообщение записано в обычном текстовом формате ASCII. После последней строки нужно поставить дополнительные CR, LF. Первая строка имеет три поля:
- поле метода
- поле URL
- поле HTTP версии
Поле метода может иметь значение GET, POST, HEAD. Большинство запросов используют метод GET. Он используется, когда обозреватель запрашивает объект, определённый с помощью URL.
Рассмотрим строки заголовка: строка, начинающая со слова HOST идентифицирует СЭВМ, где расположен объект. Строка COONECTION: close означает, что сервер не должен использовать постоянное соединение, то есть сообщает серверу, что нужно закрыть TCP соединение, после посылки запрашиваемого объекта, хотя это не является стандартным решением для HTTP 1.1. Строка USER AGENT определяет тип обозревателя, делающего запрос к серверу. Она, может быть, использоваться сервером для посылки разных версий объектов разным клиентам (при этом каждая версия определяется тем же ссылками URL). Последняя строка определяет, что пользователь предпочитает французскую версию объекта, если этой версии нет, то сервер пошлёт версию по умолчанию.
Общий формат запроса.
Клиенты HTTP используют метод POST, когда пользователь заполняет на экране формы, например, задаёт метод поиска поисковой машине. В методе POST клиент также запрашивает страницу, но содержимое страницы зависит от содержимого формы. Метод HEAD аналогичен POST. В этом случае сервер, отвечая на запрос, сохраняет объект. Метод HEAD используется для отладки.
HTTP ответ.
HTTP/1.1 200 ok Connection: close Date: Thu 06 Aug 1998 12:00:00 GMT Server: Apache/1.5.0 (Unix) Last-Modified: Mon 22 Jun 1998 09:23:24 GMT Content-Length: 6821 Content-Type: text/html CR LF данные
Ответ содержит три секции. В первой - строка статуса, во второй - шесть строк заголовка, затем тело, содержащее данные. Тело содержит запрашиваемый объект. Строка статуса имеет три поля:
- поле версии протокола
- код статуса
- соответствующее статусное сообщение
Строка CONNECTION close сообщает клиенту, что после пересылки TCP объекта соединение будет закрыто. Строка DATE определяет время и дату, когда ответ HTTP был создан и послан клиенту (время, когда объект был извлечён из памяти сервера). Строка SERVER идентифицирует тип сервера. Строка LAST MODIFIDE показывает время и дату последней модификации объекта. Следующая строка определяет количество байт посланного объекта. Строка CONTENT TYPE определяет тип посланного файла (определённого сервером, а не расширением имени файла).
Отметим, что если сервер получит запрос в формате HTTP 1.0, он не будет использовать постоянное TCP соединение, даже если он является HTTP 1.1 сервером. Вместо этого HTTP 1.1 сервер закроет TCP соединение после посылки объекта. Это необходимо, потому что HTTP 1.0 клиент ожидает, что сервер закроет соединение.
Общий формат ответа.
Этот формат похож на формат запроса. Рассмотрим пример кода статуса и фраз: 200 ok - запрос успешно обработан, информация в ответ послана; 301 Moved Permanently - объект перемещён на постоянной основе, новый URL определён в строке Location заголовка. ПО клиента должно автоматически получить объект по-новому URL; 400 Bad Request - сервер не может понять запрос (ошибка при синтаксическом анализе запроса); 404 Not Found - запрашиваемый объект не найден на сервере; 505 HTTP version not supported - указанная версия HTTP не поддерживается сервером. Чтобы увидеть реальный HTTP ответ нужно набрать что-нибудь вроде:
telnet www.karelia.ru 80 GET / HTTP/1.0
Это приведёт к открытию TCP соединения с 80 портом и с указанным хостом. После чего будет послано GET. В ответ вы увидите ответное сообщение HTTP.
