Http как работает

Вашему вниманию предлагается описание основных аспектов протокола HTTP — сетевого протокола, с начала 90-х и по сей день позволяющего вашему браузеру загружать веб-страницы. Данная статья написана для тех, кто только начинает работать с компьютерными сетями и заниматься разработкой сетевых приложений, и кому пока что сложно самостоятельно читать официальные спецификации.

HTTP — широко распространённый протокол передачи данных, изначально предназначенный для передачи гипертекстовых документов (то есть документов, которые могут содержать ссылки, позволяющие организовать переход к другим документам).

Аббревиатура HTTP расшифровывается как HyperText Transfer Protocol, «протокол передачи гипертекста». В соответствии со спецификацией OSI, HTTP является протоколом прикладного (верхнего, 7-го) уровня. Актуальная на данный момент версия протокола, HTTP 1.1, описана в спецификации RFC 2616.

Протокол HTTP предполагает использование клиент-серверной структуры передачи данных. Клиентское приложение формирует запрос и отправляет его на сервер, после чего серверное программное обеспечение обрабатывает данный запрос, формирует ответ и передаёт его обратно клиенту. После этого клиентское приложение может продолжить отправлять другие запросы, которые будут обработаны аналогичным образом.

Задача, которая традиционно решается с помощью протокола HTTP — обмен данными между пользовательским приложением, осуществляющим доступ к веб-ресурсам (обычно это веб-браузер) и веб-сервером. На данный момент именно благодаря протоколу HTTP обеспечивается работа Всемирной паутины.

Также HTTP часто используется как протокол передачи информации для других протоколов прикладного уровня, таких как SOAP, XML-RPC и WebDAV. В таком случае говорят, что протокол HTTP используется как «транспорт».

API многих программных продуктов также подразумевает использование HTTP для передачи данных — сами данные при этом могут иметь любой формат, например, XML или JSON.

Как правило, передача данных по протоколу HTTP осуществляется через TCP/IP-соединения. Серверное программное обеспечение при этом обычно использует TCP-порт 80 (и, если порт не указан явно, то обычно клиентское программное обеспечение по умолчанию использует именно 80-й порт для открываемых HTTP-соединений), хотя может использовать и любой другой.

Как отправить HTTP-запрос?

Самый простой способ разобраться с протоколом HTTP — это попробовать обратиться к какому-нибудь веб-ресурсу вручную. Представьте, что вы браузер, и у вас есть пользователь, который очень хочет прочитать статьи Анатолия Ализара.

Предположим, что он ввёл в адресной строке следующее:

http://alizar.habrahabr.ru/

Соответственно вам, как веб-браузеру, теперь необходимо подключиться к веб-серверу по адресу alizar.habrahabr.ru.

Для этого вы можете воспользоваться любой подходящей утилитой командной строки. Например, telnet:

telnet alizar.habrahabr.ru 80

Сразу уточню, что если вы вдруг передумаете, то нажмите Ctrl + «]», и затем ввод — это позволит вам закрыть HTTP-соединение. Помимо telnet можете попробовать nc (или ncat) — по вкусу.

После того, как вы подключитесь к серверу, нужно отправить HTTP-запрос. Это, кстати, очень легко — HTTP-запросы могут состоять всего из двух строчек.

Для того, чтобы сформировать HTTP-запрос, необходимо составить стартовую строку, а также задать по крайней мере один заголовок — это заголовок Host, который является обязательным, и должен присутствовать в каждом запросе. Дело в том, что преобразование доменного имени в IP-адрес осуществляется на стороне клиента, и, соответственно, когда вы открываете TCP-соединение, то удалённый сервер не обладает никакой информацией о том, какой именно адрес использовался для соединения: это мог быть, например, адрес alizar.habrahabr.ru, habrahabr.ru или m.habrahabr.ru — и во всех этих случаях ответ может отличаться. Однако фактически сетевое соединение во всех случаях открывается с узлом 212.24.43.44, и даже если первоначально при открытии соединения был задан не этот IP-адрес, а какое-либо доменное имя, то сервер об этом никак не информируется — и именно поэтому этот адрес необходимо передать в заголовке Host.

Стартовая (начальная) строка запроса для HTTP 1.1 составляется по следующей схеме:

Метод URI HTTP/Версия

Например (такая стартовая строка может указывать на то, что запрашивается главная страница сайта):

GET / HTTP/1.1

Метод (в англоязычной тематической литературе используется слово method, а также иногда слово verb — «глагол») представляет собой последовательность из любых символов, кроме управляющих и разделителей, и определяет операцию, которую нужно осуществить с указанным ресурсом. Спецификация HTTP 1.1 не ограничивает количество разных методов, которые могут быть использованы, однако в целях соответствия общим стандартам и сохранения совместимости с максимально широким спектром программного обеспечения как правило используются лишь некоторые, наиболее стандартные методы, смысл которых однозначно раскрыт в спецификации протокола.

URI (Uniform Resource Identifier, унифицированный идентификатор ресурса) — путь до конкретного ресурса (например, документа), над которым необходимо осуществить операцию (например, в случае использования метода GET подразумевается получение ресурса). Некоторые запросы могут не относиться к какому-либо ресурсу, в этом случае вместо URI в стартовую строку может быть добавлена звёздочка (астериск, символ «*»). Например, это может быть запрос, который относится к самому веб-серверу, а не какому-либо конкретному ресурсу. В этом случае стартовая строка может выглядеть так:

OPTIONS * HTTP/1.1

Версия определяет, в соответствии с какой версией стандарта HTTP составлен запрос. Указывается как два числа, разделённых точкой (например 1.1).

Для того, чтобы обратиться к веб-странице по определённому адресу (в данном случае путь к ресурсу — это «/»), нам следует отправить следующий запрос:

GET / HTTP/1.1
Host: alizar.habrahabr.ru

При этом учитывайте, что для переноса строки следует использовать символ возврата каретки (Carriage Return), за которым следует символ перевода строки (Line Feed). После объявления последнего заголовка последовательность символов для переноса строки добавляется дважды.

Впрочем, в спецификации HTTP рекомендуется программировать HTTP-сервер таким образом, чтобы при обработке запросов в качестве межстрочного разделителя воспринимался символ LF, а предшествующий символ CR, при наличии такового, игнорировался. Соответственно, на практике бо́льшая часть серверов корректно обработает и такой запрос, где заголовки отделены символом LF, и он же дважды добавлен после объявления последнего заголовка.

Если вы хотите отправить запрос в точном соответствии со спецификацией, можете воспользоваться управляющими последовательностями r и n:

echo -en "GET / HTTP/1.1rnHost: alizar.habrahabr.rurnrn" | ncat alizar.habrahabr.ru 80

Как прочитать ответ?

Стартовая строка ответа имеет следующую структуру:

HTTP/Версия Код состояния Пояснение

Версия протокола здесь задаётся так же, как в запросе.

Код состояния (Status Code) — три цифры (первая из которых указывает на класс состояния), которые определяют результат совершения запроса. Например, в случае, если был использован метод GET, и сервер предоставляет ресурс с указанным идентификатором, то такое состояние задаётся с помощью кода 200. Если сервер сообщает о том, что такого ресурса не существует — 404. Если сервер сообщает о том, что не может предоставить доступ к данному ресурсу по причине отсутствия необходимых привилегий у клиента, то используется код 403. Спецификация HTTP 1.1 определяет 40 различных кодов HTTP, а также допускается расширение протокола и использование дополнительных кодов состояний.

Пояснение к коду состояния (Reason Phrase) — текстовое (но не включающее символы CR и LF) пояснение к коду ответа, предназначено для упрощения чтения ответа человеком. Пояснение может не учитываться клиентским программным обеспечением, а также может отличаться от стандартного в некоторых реализациях серверного ПО.

После стартовой строки следуют заголовки, а также тело ответа. Например:

HTTP/1.1 200 OK Server: nginx/1.2.1 Date: Sat, 08 Mar 2014 22:53:46 GMT Content-Type: application/octet-stream Content-Length: 7 Last-Modified: Sat, 08 Mar 2014 22:53:30 GMT Connection: keep-alive Accept-Ranges: bytes  Wisdom   

  
 

Тело ответа следует через два переноса строки после последнего заголовка. Для определения окончания тела ответа используется значение заголовка Content-Length (в данном случае ответ содержит 7 восьмеричных байтов: слово «Wisdom» и символ переноса строки).

Но вот по тому запросу, который мы составили ранее, веб-сервер вернёт ответ не с кодом 200, а с кодом 302. Таким образом он сообщает клиенту о том, что обращаться к данному ресурсу на данный момент нужно по другому адресу.

Смотрите сами:

HTTP/1.1 302 Moved Temporarily Server: nginx Date: Sat, 08 Mar 2014 22:29:53 GMT Content-Type: text/html Content-Length: 154 Connection: keep-alive Keep-Alive: timeout=25 Location: http://habrahabr.ru/users/alizar/  <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> 

В заголовке Location передан новый адрес. Теперь URI (идентификатор ресурса) изменился на /users/alizar/, а обращаться нужно на этот раз к серверу по адресу habrahabr.ru (впрочем, в данном случае это тот же самый сервер), и его же указывать в заголовке Host.

То есть:

GET /users/alizar/ HTTP/1.1

Host: habrahabr.ru

В ответ на этот запрос веб-сервер Хабрахабра уже выдаст ответ с кодом 200 и достаточно большой документ в формате HTML.

Если вы уже успели вжиться в роль, то можете теперь прочитать полученный от сервера HTML-код, взять карандаш и блокнот, и нарисовать профайл Ализара — в принципе, именно этим бы на вашем месте браузер сейчас и занялся.

А что с безопасностью?

Сам по себе протокол HTTP не предполагает использование шифрования для передачи информации. Тем не менее, для HTTP есть распространённое расширение, которое реализует упаковку передаваемых данных в криптографический протокол SSL или TLS.

Название этого расширения — HTTPS (HyperText Transfer Protocol Secure). Для HTTPS-соединений обычно используется TCP-порт 443. HTTPS широко используется для защиты информации от перехвата, а также, как правило, обеспечивает защиту от атак вида man-in-the-middle — в том случае, если сертификат проверяется на клиенте, и при этом приватный ключ сертификата не был скомпрометирован, пользователь не подтверждал использование неподписанного сертификата, и на компьютере пользователя не были внедрены сертификаты центра сертификации злоумышленника.

На данный момент HTTPS поддерживается всеми популярными веб-браузерами.

А есть дополнительные возможности?

Протокол HTTP предполагает достаточно большое количество возможностей для расширения. В частности, спецификация HTTP 1.1 предполагает возможность использования заголовка Upgrade для переключения на обмен данными по другому протоколу. Запрос с таким заголовком отправляется клиентом. Если серверу требуется произвести переход на обмен данными по другому протоколу, то он может вернуть клиенту ответ со статусом «426 Upgrade Required», и в этом случае клиент может отправить новый запрос, уже с заголовком Upgrade.

Такая возможность используется, в частности, для организации обмена данными по протоколу WebSocket (протокол, описанный в спецификации RFC 6455, позволяющий обеим сторонам передавать данные в нужный момент, без отправки дополнительных HTTP-запросов): стандартное «рукопожатие» (handshake) сводится к отправке HTTP-запроса с заголовком Upgrade, имеющим значение «websocket», на который сервер возвращает ответ с состоянием «101 Switching Protocols», и далее любая сторона может начать передавать данные уже по протоколу WebSocket.

Что-то ещё, кстати, используют?

На данный момент существуют и другие протоколы, предназначенные для передачи веб-содержимого. В частности, протокол SPDY (произносится как английское слово speedy, не является аббревиатурой) является модификацией протокола HTTP, цель которой — уменьшить задержки при загрузке веб-страниц, а также обеспечить дополнительную безопасность.

Увеличение скорости обеспечивается посредством сжатия, приоритизации и мультиплексирования дополнительных ресурсов, необходимых для веб-страницы, чтобы все данные можно было передать в рамках одного соединения.

Опубликованный в ноябре 2012 года черновик спецификации протокола HTTP 2.0 (следующая версия протокола HTTP после версии 1.1, окончательная спецификация для которой была опубликована в 1999) базируется на спецификации протокола SPDY.

Многие архитектурные решения, используемые в протоколе SPDY, а также в других предложенных реализациях, которые рабочая группа httpbis рассматривала в ходе подготовки черновика спецификации HTTP 2.0, уже ранее были получены в ходе разработки протокола HTTP-NG, однако работы над протоколом HTTP-NG были прекращены в 1998.

На данный момент поддержка протокола SPDY есть в браузерах Firefox, Chromium/Chrome, Opera, Internet Exporer и Amazon Silk.

И что, всё?

В общем-то, да. Можно было бы описать конкретные методы и заголовки, но фактически эти знания нужны скорее в том случае, если вы пишете что-то конкретное (например, веб-сервер или какое-то клиентское программное обеспечение, которое связывается с серверами через HTTP), и для базового понимания принципа работы протокола не требуются. К тому же, всё это вы можете очень легко найти через Google — эта информация есть и в спецификациях, и в Википедии, и много где ещё.

Впрочем, если вы знаете английский и хотите углубиться в изучение не только самого HTTP, но и используемых для передачи пакетов TCP/IP, то рекомендую прочитать вот эту статью.

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

Удачи и плодотворного обучения!

habr.com

Что такое HTTP и как он работает?

Чтобы получить нужный документ в интернете, пользователю достаточно ввести в поисковую строку браузера нужный URL-адрес (тут о структуре урлов подробности), который как раз содержит название протокола HTTP (или HTTPS).

Сюда же входит имя домена (что это?), следующее за двойным слешем «//». Причем, путь (часть адреса за слешем после домена) может быть прописан как до нужной страницы сайта, так и до файла, физически находящегося в определенной директории (папке). Но это может быть и главная вебстраница, адрес которой состоит только из доменного имени:

http://goldbusinessnet.com/osnovy-html/chto-takoe-html-tegi-i-struktura-dokumenta/  http://goldbusinessnet.com/wp-content/uploads/2017/04/url.jpg  https://www.yandex.ru/

А теперь попробуем разобраться в общих чертах, как работает этот механизм. Для начала необходимо выяснить, что же такое HTTP. Это протокол, который служит для «транспортировки» информации между клиентским приложением и сервером.

Аббревиатура HTTP (HyperText Transfer Protocol) переводится с английского как «протокол передачи гипертекста». Вообще говоря, протоколов достаточно много, и каждый из них решает определенную задачу (например, тот же FTP).

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

Необходимо отметить, что передача данных по HTTP происходит посредством TCP/IP-соединения. При этом серверное приложение по умолчанию использует порт 80, хотя в некоторых случаях может применяться и другой.

TCP (Transmission Control Protocol)/IP является довольно сложной системой и включает в себя четыре уровня протоколов (прикладной, к которому и относится HTTP, транспортный, сетевой и канальный). Думаю, для общей информации этого пока достаточно, а то мы залезем в дебри.

Как осуществляется взаимодействие между клиентским приложением и сервером

Итак, мы определили, что HTTP организует передачу данных в форме гипертекста. Но как это происходит на практике? Я уже упомянул, что здесь применяется технология, заключающаяся в общении между клиентским приложением и сервером, на котором располагаются физические файлы, получаемые в чистом виде для просмотра, либо шаблоны той или иной CMS, генерирующие странички сайта «на лету».

Ну с сервером худо-бедно понятно (это просто большой компьютер, где и расположены веб-сайты), а вот что за клиентские приложения участвуют в «игре»? Но и здесь все просто. Это может быть браузер пользователя (тут о всех популярных веб-обозревателях материал), который является не чем иным как программой для поиска и просмотра информации в глобальной сети.

Я уже давал общую схему того, как, благодаря отлаженному взаимодействию серверов DNS и системы IP-адресации реализовано бесперебойное функционирование интернета, когда пользователь сети может получить доступ к любому файлу или документу (например, к странице сайта) для получения информации, которая его интересует.

Теперь немного конкретизируем действие этого механизма. После того, как юзер вбил в адресную строку URL (который, как известно содержит доменное имя конкретного вебсайта) либо перешел по ссылке с другой вебстраницы или с закладок, браузер обращается в ближайший ДНС сервер.

Там хранятся все имена доменов, каждому из которых соответствует уникальный IP адрес, связанный с сервером, на котором «живет» сайт с этим ДИ. Получив ай-пи, браузер отправляет на сервер HTTP-запрос, после чего получает ответ. Единую схему запросов и ответов при общении клиентского приложения (в нашем случае браузера) с сервером можно представить так:

«>

Между списком заголовков и телом сообщения присутствует пустая строка, которая определяется символом переноса. В случае запроса начальная строка состоит из следующих компонентов:

Метод URI HTTP/Версия  Host: site.ru

Давайте разберем вкратце все составляющие, чтобы иметь хотя бы общее представление об этом этапе взаимодействия браузера и сервера. Итак, верхняя строка:

1. Метод — указывает на действие, которое необходимо совершить с данным веб-ресурсом. Таких методов несколько, но самые распространенные среди них это GET и POST. Первый предполагает получение данных с сервера для просмотра (например, определенную страницу конкретного сайта), а второй обратную операцию, то есть отправку информации на сервер (регистрации пользователей, формы авторизации, различных сообщений и т.д.).

2. URI (унифицированный идентификатор ресурса, который является более общим понятием, чем URL) — путь до файла относительно корневой папки (почитайте, как формируются абсолютные и относительные ссылки).

3. HTTP/Версия — указывается действующая модификация протокола. На данный момент это HTTP 1.1 (вы можете ознакомиться с ее спецификацией). Однако, в черновом виде уже существует следующая версия протокола 2.0, который основан на двоичной (бинарной) системе счисления.

Нижняя строка представляет собой заголовок Host в составе HTTP-запроса, отсылаемого браузером серверу в соответствии с полученным от ДНС IP. Для чего это надо? Для идентификации нужного сайта, поскольку на вебсерверах обычно расположен не один ресурс.

Разберем наглядный пример для закрепления пройденного. Скажем, браузер получил «задание» от пользователя отобразить страничку вот с таким адресом:

http://subscribe.ru/group/

Тогда HTTP-запрос посредством метода GET может быть составлен следующим образом (в этом случае обычно тело сообщения отсутствует):

GET /group/ HTTP/1.1  Host: subscribe.ru

Для наглядности я предоставил лишь самый простой пример, включающий один заголовок Host, на самом деле, их может быть несколько. Но это не все. Ведь для полноценного общения необходим диалог, который и устанавливается после того, как на запрос браузера сервер дает ответ. Начальную строку ответа тоже можно изобразить схематически:

HTTP/Версия Код состояния Пояснение

Теперь пробежимся вкратце и по составу ответа сервера:

1. Версия HTTP указывается по аналогии с запросом.

2. Код состояния (Status Code) — три цифры, информирующие о том, каков статус документа, запрошенного браузером. Например, 200 — ОК, страница существует и будет отображена в браузере, 301 — осуществлен постоянный редирект (перенаправление) на другой урл, 404 — вебстранички по такому адресу нет (возможно, она удалена либо юзер ошибся при вводе URL).

3. Пояснение (Reason Phrase) — текст дополнения к коду ответа. В некоторых случаях пояснение может отличаться от стандартного либо отсутствовать вовсе. Это связано в том числе с настройкой ПО, размещенного на сервере.

Реальный пример? Пожалуйста. Попробуем получить ответ сервера на запрос, приведенный мною в качестве примера выше (урл «http://subscribe.ru/group/»). Он будет выглядеть так (начальная строка с заголовками):

HTTP/1.1 200 OK  Server: nginx  Date: Sat, 10 Jun 2017 06:36:38 GMT  Content-Type: text/html; charset=utf-8  Connection: keep-alive  Content-Language: ru  Set-Cookie: Subscribe::Viziter=UQkivlk7k3YO3DgjAxM2Ag==; expires=Thu, 31-Dec-37 23:55:55 GMT; domain=subscribe.ru; path=/  P3P: policyref="/w3c/p3p.xml", CP="NOI PSA OUR BUS UNI"

В данном случае отсутствуют пояснение и тело сообщения, которое при использовании метода GET может содержать, например, HTML-код запрашиваемого документа (веб-странички). В зависимости от типа приложения клиента эти разделы могут присутствовать.

Итак, резюмируем вкратце выше изложенное. Если пользователь вводит урл искомой страницы, имея ввиду получить ее содержимое для просмотра, браузер посылает GET запрос на нужный сервер и получает ответ. В результате этого общения либо (при благоприятных обстоятельствах) контент запрошенного документа будет отображен, либо нет.

В любом случае, по содержанию HTTP-ответа сервера (включая код состояния) можно получить полезную информацию, связанную с запрашиваемым документом.

Для того, чтобы выше предложенная информация без усилий ложилась в пазл, не хватает конкретного примера. Его мы рассмотрим с помощью одного из расширений Google Chrome (именно этот веб-обозреватель является моим рабочим инструментом), именуемого HTTP Headers.

Он удобен тем, что дает полную картину взаимодействия «клиент-сервер», предоставляя в «одном флаконе» содержание HTTP запроса (request) и ответа (response). Посмотрите, какой документ выдал этот плагин при переходе по ссылке с одной страницы моего блога на другую:

«>

Здесь в самом верху отмечен метод GET, с помощью которого браузер обращается к серверу, а также статус странички, отмеченный кодом состояния 200 OK, который дает понять, что сервер передал все данные в отношении запрашиваемой вебстраницы.

Интерес вызывают также HTTP Headers (заголовки), отображенные ниже. Например, пункт «Referer» дает информацию в виде урла, откуда был осуществлен переход.

Заголовок «User Agent» отражает как раз клиентское приложение, отправившее запрос вебсерверу. В данном случае это браузер, но могут быть и другие (мобильные устройства, поисковые роботы и т.д.). Данные, представленные в Юзер Агенте, необходимы серверному программному обеспечению для идентификации приложения, посылающего запрос.

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

Вот потому-то в следующей публикации я планирую поподробнее остановится на том, как просмотреть HTTP-заголовки и проверить коды ответов сервера именно на запрос робота, что исключительно важно для вебмастеров в свете SEO оптимизации ресурса. Поэтому оформляйте подписку, чтобы своевременно получить свежую статью.

goldbusinessnet.com

Структура HTTP запроса

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

1. строка запроса — указан метод запроса (HTTP-метод), URI, версия протокола;
2. заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;
3. тело сообщения — данные сообщения.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом. Например, строка запроса может выглядеть так:

Остановимся более подробно на методах запроса.

Методы HTTP

Метод указывает какая операция будет производится над ресурсом, представляет собой короткое английское слово, записанное заглавными буквами. Название метода чувствительно к регистру. В спецификации HTTP 1.1 определены следующие методы: OPTIONS, GET, HEAD, POST, PUT, PATCH, DELETE, TRACE, LINK, UNLINK. Чтобы не перегружать мозг избыточной информацией рассмотрим используемые чаще всего.

Метод GET

GET — используется для запроса содержимого указанного ресурса. Это с его помощью браузер получает HTML код конкретной страницы и все ее объекты (изображения, CSS и т.п). Тело такого запроса является пустым. Ответ может кэшироваться. GET запрос может передать параметры на сервер для уточнения запрашиваемых данных. Параметры запроса содержаться в адресе запроса, отделяются от URI знаком «?», пары параметр-значение разделяются символом «&». Подобный адрес запроса может выглядеть так:

Кроме обычных GET запросов, есть еще условные и частичные.

Условный GET

Условный GET запрос (conditional GET) предназначен для уменьшения ненужной загрузки сети, и позволяет обновлять кэшированные объекты без пересылки данных, уже сохраненных клиентом. Условный GET содержит в своем заголовке определенные условия и данные получает от сервера, только если ответ удовлетворяет запрашиваемым условиям. Спецификацией HTTP 1.1 определены условия: If-Modified-Since, If-Match, If-None-Match, If-Range. Наиболее часто ныне используется If-Modified-Since, которым задается дата и время последнего изменения объекта. При последующем обращении к данному ресурсу, браузер проверит значение этого заголовка, если он не изменился, объект возьмется из кэша клиента.

Частичный GET

Частичный GET запрос (partial GET) предназначен для уменьшения ненужной загрузки сети. Позволяет собирать объект из частей без передачи данных уже имеющихся на стороне клиента и потому запрашивает передачу только части объекта. Используется заголовок Range.

Метод POST

POST предназначен для передачи данных на сервер. Тело такого запроса обычно содержит данные. Сообщение ответа сервера на выполнение метода POST не кэшируется. Этот метод второй по популярности использования, в основном его применяют в веб формах для получения каких-то данных от пользователей ресурса (формы входа, регистрации, отправка сообщений и т.п.).

Заметка

HTTP запросы можно разделить на безопасные (когда пользователь просто запрашивает данные и не может повлиять на работу сервера) и небезопасные (когда пользователь отправляет серверу определенные данные и потенциально может повлиять на его работу).

URI и версия протокола

URI — это последовательность символов (строка), идентифицирующая абстрактный или физический ресурс.

Версия протокола служит для указания, с какой версией протокола способен работать клиент/сервер и выглядит в виде HTTP/[версия]. Сейчас большинство поддерживают версию 1.1.

Заголовки HTTP

Каждый запрос имеет как минимум свой заголовок, который сообщить серверу информацию о своей конфигурации и данные о форматах документов, которые он может принимать. Заголовок представлен в текстовом виде. Например:

Такой заголовок имеет вес равный 956b.

Каждый ответ состоит из трех частей: строка состояния (содержит три поля: версию HTTP, код состояния и описание), заголовок ответа (информация о сервере и передаваемых данных) и сами данные. Первые две части представлены тоже в текстовом виде и выглядит это примерно так:

Только первые две части в особо тяжелых случаях могут весить 0.5 килобайт.

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

Заметка

Вес передаваемых данных не влияет на размер заголовка.

Установка HTTP заголовков

Добраться до этих заголовков можно только с помощью настроек сервера и/или серверными скриптами.

При первом запросе браузером объекта (HTML страницы, картинки или любого другого) сервер присылает ответ, содержащий HTTP заголовки. Клиент их сохраняет вместе с адресом запроса. При повтором обращении по этому адресу браузер уже будет снабжен необходимыми заголовками.

Тело HTTP заголовка

Пока не нашел информации по этой части запроса, которая была бы полезной HTML кодеру, поэтому в этой статье рассматривать ее не буду.

По теме

• Как работает браузер: обмен данными с сервером.

xiper.net

Более чем за три десятка лет Интернет проник во все области деятельности человечества: его используют для того, чтобы читать книги, смотреть видео, любоваться картинками с котиками, узнавать погоду, слушать музыку и признаваться в любви. Почти весь бизнес так или иначе использует Сеть для передачи информации о сотрудниках, поступлениях товаров на склады и перевода денежных средств. Большая часть данных, которая передаётся через Сеть, использует протокол HTTP в качестве контейнера. Каждый раз, когда вы заходите на сайт, ваш браузер посылает до нескольких десятков HTTP запросов. HTTP используется для загрузки файлов из сети, программы скачивают обновления, используя этот протокол, даже интернет радио не обходится без него.

Что же привело к столь широкому распространению этого формата передачи данных?

История HTTP

HyperText Transfer Protocol был создан в CERN в 1991 году Тимом Бернерсоном-Ли, во времена, когда призрак Интернета бродил по земному шарику. Как и многие великие изобретения, он создавался не ради каких-то абстрактных целей, а ради удобства автора и решал конкретную проблему: давал доступ к гигантскому количеству информационных ресурсов лаборатории. Документацию и экспериментальные данные необходимо было не только хранить, но обеспечивать к ним доступ для сотен специалистов и институтов по всему миру. HTTP был придуман с целью упростить доступ к информации и оказался настолько удобен, что в 1993 году была опубликована спецификация HTTP/0.9, доступная каждому. В ней описывался базовый синтаксис протокола, давались определения базовым понятиям и подготавливалась почва для дальнейшего расширения протокола. Также были опубликованы исходные коды браузера (программы для просмотра гипертекста, передаваемого через HTTP) под названием, вы не поверите, WorldWideWeb:

Так мировая сеть сделала свой первый шаг.

Первоначально HTTP использовался исключительно для передачи гипертекста (текста с перекрёстными ссылками) между компьютерами, но позже оказалось, что он прекрасно подходит и для того, чтобы посылать на ПК пользователя бинарные данные — например, изображения или музыку.

В мае 1996 года, всего через три года после первого релиза, была выпущена спецификация HTTP/1.0 (RFC1945), которая расширяла исходную версию протокола, закрепляла коды ответа и вводила новый тип данных для передачи — application/octet-stream, что фактически «легализовало» передачу нетекстовых данных.

В июне 1999 года была опубликована версия протокола 1.1, которая фактически оставалась неизменной на протяжении 16 лет! Более того, она послужила основой для многих других протоколов, в частности WebSocket и WebDav.

И, наконец, 11 февраля 2015 года вышла черновая версия протокола HTTP/2. В отличие от предыдущих двух релизов, он не является переработанным HTTP/0.9, имеет не текстовый, а бинарный формат представления данных, требует обязательного шифрования и имеет множество более мелких отличий от своих предков: сжатие заголовков, использование одного TCP соединения для серии запросов, а также даёт возможность послать серверу дополнительные данные в теле ответа, превентивно отдавая ресурсы в браузер. Более подробно эта версия протокола будет рассмотрена в одной из следующих статей.

Как работает HTTP/1.1

В основе протокола HTTP лежит концепция клиент-серверной архитектуры: клиент, чаще всего браузер, делает запрос на сервер. Существует множество видов запросов, самые распространённые — это GET и POST: первый означает, что клиент хочет получить данные, а второй — что клиент хочет послать данные на сервер. Таким образом, общение между клиентом и сервером сводится к обмену сообщениями, причём всегда по принципу «клиент послал запрос — сервер прислал ответ».

Разберём модельную ситуацию: Петя зовет Колю погулять. Он открывает страничку ВК (или другой социальной сети) и пишет приглашение, после чего нажимает кнопку «Отправить». Что же происходит при этом? Браузер берёт текст приглашения Пети, упаковывает его какой-нибудь промежуточный формат (например, json) и посылает на сервер в виде POST сообщения. Если всё прошло удачно, то сервер ВК в ответ присылает сообщение с кодом 201 («CREATED» — «создано»).

Теперь мысленно обратимся к Коле, который открыл страничку своей любимой социальной сети. При этом браузер послал на сервер GET запрос. Сервер, на который Петя уже послал своё приглашение, видит, что Коля проверяет свои входящие, и отвечает на запрос сообщением, содержащим код 200 (буквально означает «OK»).

Таким образом, любое взаимодействие между сервером и клиентом можно разбить на пары «вопрос-ответ», что очень упрощает взаимодействие с веб-сервисами.

Внутреннее устройство протокола

Чем же на самом деле обмениваются клиент и сервер между собой?

Как было замечено выше, протокол HTTP до версии 2.0 (и мы будем рассматривать версию 1.1 как самую распространенную до сих пор) имеет текстовую природу. Фактически клиент посылает на сервер специальным образом составленное «письмо»:

——————————————————

GET /im HTTP/1.1
Host: vk.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close

——————————————————

Давайте разберём его построчно.

Первая строка содержит в себе название метода (GET), URI — универсальный идентификатор ресурса (/im в данном случае), и версию используемого протокола — HTTP/1.1.

После этой обязательной строки, с которой начинается любое HTTP-сообщение, идут несколько пар значений, разделённых двоеточиями. Они называются заголовками (HTTP-headers). Эти значения могут быть самыми разными, но наиболее распространенными являются Host (содержит имя сайта, наличие такого заголовка позволяет хостить несколько сайтов на одном IP адресе) и User-Agent, который по задумке должен обозначать вид используемого браузера, а на практике сложным образом описывает список поддерживаемых браузером технологий. Поле Accept определяет формат данных в ответе, который нужен клиенту, а «Connection: close» означает, что клиент хочет закрыть TCP соединение сразу после получения ответа от сервера.

Если запрос сформирован правильно, и сервер функционирует нормально, и сеть в порядке (как много этих «если»…), то в ответ на HTTP пакет от клиента придёт ответ, который выглядит примерно вот так:

——————————————————

HTTP/1.1 200 OK
Date: Wed, 27 Aug 2017 09:50:20 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 18
Connection: close

Го гулять

——————————————————

Здесь мы наблюдаем отсутствие названия метода в первой строке, и ряд новых заголовков, из которых я рекомендую обратить внимание на поле «Content-Length: 18». Это число обозначает длину данных в байтах, которые передаются после пустой строки в конце пакета (так как в заголовке Content-Type указана кодировка utf-8, то каждая буква кириллицы в сообщении занимает два байта). Таким образом мы рассмотрели простой пример работы протокола HTTP.

HTTP позволяет миллиардам людей получать доступ новостям, письмам друзей, спорам о самолёте на конвейерной ленте, смешным фотографиям котиков и данным о недавно открытом в БАКе гамма-резонансе (есть что-то трогательное в том, что HTTP по-прежнему приносит пользу на своей малой родине, ЦЕРНе). Мало какие изобретения обладают столь мощным влиянием на человечество в том объёме, как этот простенький протокол передачи структурированного текста. И, разумеется, такой протокол не мог остаться без расширений, и самым популярным из них стал HTTPS — о нем и поговорим в следующей статье.

 

www.iguides.ru

Зачем создали протокол HTTP

С его помощью передают гипертекстовые документы, а проще говоря — страницы на нужных нам сайтах.

Принимает веб-страницы клиент (браузер), а отдаёт страницы сервер. Эта технология так и называется — клиент-серверная технология.

Благодаря HTTP стало возможно передавать веб-страницы в интернете. А что же содержится в самих страницах, которые пересылает нам сервер? Обыкновенный HTML-код, который поступает в браузер, которому остается только верно интерпретировать полученную информацию и показать вам готовый сайт.

Еще в 2006 году практически половина HTTP-трафика Северной Америки складывалась из потокового звука и видео.

Как работает HTTP

1. Браузер отправляет запрос, запрашивая нужную страницу сервера.
2. Сервер получает запрос и начинает искать страницу. 
3. Браузер  получает ответ от сервера с результатами запроса:
   • Код запрашиваемой страницы и служебная информация — если страница найдена.
   • Код ошибки и служебная информация в случае сбоя.

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

Чтобы идентифицировать ресурсы в сети, протокол HTTP пользуется глобальными URI. Отличие HTTP от других протоколов — он не сохраняет свое состояние. То есть не сохраняется состояние между парой «запрос-ответ».

HTTP — это не единственный протокол, который используют в Интернете. Также используются:

• FTP (File Transfer Protocol) — протокол передачи файлов.
• POP (Post Office Protocol) и SMTP (Simple Mail Transport Protocol) — для обмена сообщениями электронной почты.
• SHTTP (Secure Hypertext Transfer Protocol) — шифрованная разновидность HTTP. Информация, которая передается по этому протоколу, кодируется. Обычно безопасность важна в случае обмена конфиденциальными данными.

И другие протоколы, у которых есть одно хорошее свойство — все они работают незаметно для нас с вами.

Март 1991 года — Тим Бернерс-Ли предложил использовать HTTP.

Именно Бернерс-Ли разработал все первое, что связано с Интернетом: браузер, сервер, гиперссылки, первый сайт (info.cern.ch) Как выглядел первый сайт, можно увидеть по ссылке. 

Версии HTTP со временем совершенствуются, популярной стала версия HTTP 1.1, которая позволяет на долгое время оставлять открытым соединение сервера с браузером, что сделало протокол более эффективным.

В 2015 году появился HTTP/2, который стал бинарным, изменились способы, которыми информацию разбивали на фрагменты.

Безопасность протокола HTTP

Сам HTTP не подразумевает шифрование информации. Но есть расширение для протокола, которое умеет упаковывать данные в протокол SSL или TLS.

HTTPS (S — Secure) — популярное решение, которое не позволяет перехватывать передаваемую информацию и защитить информацию от MITM- атак «man-in-the-middle» или атака посредника.

MITM по сути испорченный телефон, в котором информация подменяется намеренно. О подмене не знает ни клиент ни сервер.

Из чего состоит HTTP

Мы много упоминали, что сервер и клиент отправляют и получают запросы. Так что же содержится в этих запросах? Каждое сообщение HTTP состоит из трех частей:

1. Стартовая строка, которая определяет тип сообщения.
2. Заголовки, с помощью которых характеризуют тело сообщения. 
3. Тело сообщения, где содержатся уже нужные данные.

Благодаря особенностям HTTP, сумели создать поисковые машины, форумы, интернет-магазины. В интернет пришла коммерция, начали появляться интернет провайдеры и другие компании, деятельность которых проходит в сети Интернет. А все благодаря протоколу HTTP, с которым вы теперь хорошо знакомы.

vadimstroganov.com

Hypertext Transfer Protocol (или HTTP) является основой передачи данных для World Wide Web. Такие протоколы представляют собой структурированный текст, который использует логические связи (гиперссылки) между узлами, содержащими определенные данные. Таким образом, это способ обмена или передачи гипертекста.

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

Браузер является основным примером агента пользователя (клиента). Другие типы пользовательских агентов включают в себя программное обеспечение, используемое для индексации поисковыми провайдерами, мобильные приложения и другие ресурсы, которые используют или отображают веб-контент.

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

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

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

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

С другой стороны, HTTP-протокол может применять и такие методы, которые предназначены для действий, способных оказать влияние либо на сервер, либо на другие внешние ресурсы – активизировать финансовые операции или выполнить передачу электронной почты. Изредка такие способы используются веб-роботами или некоторыми сайтами и могут делать запросы вне зависимости от основной задачи.

fb.ru

В статье раскрывается сущность работы протокола HTTP, кроме этого рассказывается о разных схемах его работы. Особое внимание уделяется сущности взаимодействия браузера и сервера.

Сущность работы HTTP

В первую очередь следует вникнуть в процесс взаимодействия сервера и пользовательского браузера. Чтобы отобразить на экране страницу сайта, браузер посылает сигнал с запросом на сервер, после этого с сервера приходит закодированное содержимое сайта, которое преобразуется в привычный вид сайта. Изучение этого процесса для веб-разработчика важно тем, что вникнув в суть процесса, можно ускорить работу быстродействия своего ресурса.

Обмен данными между сервером и браузером идет через HTTP протокол. Сам браузер с точки зрения программирования является HTTP клиентом, так как он пользуется этим протоколом при отправке запросов и для получения ответных данных.

Теперь раскроем суть понятия HTTP протокол

Нас, как веб-разработчиков интересует только сам процесс обмена и вывода информации.

Синхронизированный протокол

Обмен данных осуществляется по схеме «клиент-сервер». В этой схеме клиентом называется устройство которое отправляет запрос на предоставление какой-либо информации, а сервером – система, которая принимает запрос, обрабатывает его и отправляет обратно клиенту ответ. Сам процесс взаимодействия можно разделить на два этапа: отправка HTTP-запроса и получение HTTP-ответа.

Запросы и ответы не имеют возможности передаваться одновременно, обязательно должна сохраняться синхронизация процесса. То есть передача ответа начнется только после завершения отправки запроса, работа по другому принципу невозможна. Чтобы было понятней, проведем аналогию с автобусом: вы не сможете им воспользоваться, пока он не приедет на остановку.

Как осуществляется запрос?

Процесс отправки запроса на сервер можно разбить на несколько составных частей:

1. В первую очередь осуществляется DNS-запрос, который должен преобразовать адрес сайта из URI формата в IP (числовая форма URI-адреса). Именно такой формат адреса используется в Всемирной сети.
2. После определения IP устанавливается связь между сервером и HTTP клиентом.
3. Пересылка запроса.
4. Задержка, в которую входит пересылка информации на сервер, ее обработка и отправка ответа на запрос. Программисты называют этот временной промежуток ожиданием ответа.
5. Получение ответа на запрос.

Отследить все эти этапы можно с помощью панели веб-разработчика в браузере.

Из перечня всех этапов достаточно длительным является первый. В начале развития протокол HTTP использовал устаревшую схему обработки данных, которая предусматривала разрыв связи после того, как будет получен ответ на требуемый запрос. Это очень тормозило процесс работы в интернет-пространстве. Однако, после того как вышла новая стандартизация работы протокола HTTP версии 1.1, стал доступным новый режим работы соединения — keep-alive, согласно которому связь стала неразрывной. Вследствие этого после обработки первого запроса не требуется заново проходить первый этап, а сразу переходить ко второму.

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

Такая форма работы сводит шансы сайтов к нулю в конкурентной борьбе с десктопными приложениями. Отсюда выплывает и первый способ ускорить работу сайта – нужно минимизировать количество обращений к серверу, прописанных в коде.

Параллельное HTTP соединение

Чтобы решить проблему большого времени ожидания и прерывания связи с хостом, была создана параллельная схема связи между клиентом и сервером. Другими словами можно одновременно установить соединение с несколькими хостами. Разработчики стандарта HTTP 1.1 советуют подключать не более 2 каналов соединения одновременно. Но следует учитывать, что спецификация вышла на свет еще во времена древних динозавров. Сейчас браузеры легко поддерживают связь с 4 каналами одновременно по умолчанию, а если порыться в настройках клиента, то этот показатель можно увеличить до 8.

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

Конвейерное HTTP соединение

С развитием технологий существенно начал развиваться и процесс взаимодействия сервера и браузера. Существенным прорывом в этом вопросе стало создание конвейерной схемы отправки запросов на сервер (в оригинале — HTTP pipelining). Согласно этой схеме стало возможным по одному каналу отправлять несколько запросов, не дожидаясь ответа на них. В свою очередь сервер стал отправлять ответы на каждый запрос в порядке очереди.

Благодаря этому нововведению стало также возможным сокращение количества TCP/IP-пакетов. Таким образом, можно в один такой пакет поместить несколько HTTP-запросов. Вследствие этого улучшится не только работа протокола, но и повысится эффективность функционирования сети Интернет в целом.

Подводя итог

На сегодняшний день спецификация HTTP 1.1 является морально устаревшей сводкой правил. Над ее модернизацией ведутся работы уже достаточно давно, ярким примером этого являются HTTP-NG и SPDY. Развивать HTTP можно и силами усовершенствования языка программирования сайтов HTML5. Все эти процессы позволят ускорить работу протокола, однако правило минимизации обращения к серверу, что позволит увеличить скорость работы ресурса, будет всегда актуальным.

vaden-pro.ru

13

Протокол HTTP

В середине 90-х годов очень популярной стала WWW (World Wide Web) — «Всемирная паутина». Это набор протоколов и программ для Интернета, представляющих информацию в гипертекстовом формате. Знаменитый браузер Mosaic, созданный в Национальном центре по применению супер-ЭВМ (National Center for Supercomputer Applications, NCSA), был первым графическим Web-браузером и способствовал популяризации WWW. Web разработана в 1989 году в Европейской лаборатории физики частиц (European Laboratory for Particle Physics, CERN) Тимоти Бернерсом-Ли (Timothy Berners-Lee). В настоящее время всеми стандартами, имеющими отношение к Web, ведает Консорциум World Wide Web (W3C).

Гипертекст применяется для создания документов, взаимосвязанных ссылками, — с ними легко управляться даже новичкам. В протоколах для Web в одних из первых в Интернете стали использовать гипертекст. Для упрощения и повышения эффективности работы с большими объемами непоследовательной информации. Теперь пользователю не обязательно заучивать команды базового протокола FTP, а для получения информации из Интернета не надо быть асом-программистом — достаточно просто щелкнуть ссылку на странице.

Для упаковки и передачи данных в Web применяются протоколы MIME (Multipurpose Internet Mail Extensions) и TCP/IP (Transmission Control Protocol/Internet Protocol), а также и другие, например FTP и Telnet. Специально для Web разработаны указатели URL (Uniform Resource Locator), протокол HTTP (Hypertext transfer Protocol), язык HTML (Hyper-text Markup Language) и интерфейс CGI (Common Gateway Interface).

Унифицированные указатели ресурсов (URL)

Указатель URL (Uniform Resource Locator) — это адрес сетевого ресурса. Он похож на имя файла, но дополнительно содержит имя сервера и информацию о сетевом протоколе, используемом данным ресурсом. В некоторых случаях URL включает сведения об имени пользователя, а также специальные аргументы и параметры протокола.

На Web-страницах URL используются для ссылок на другие страницы. В виде URL можно описать многие распространенные сетевые команды, указатели на файлы (доступные через FTP) и на сообщения из групп новостей Usenet (всемирной сети UNIX-систем, функционирующей как электронная доска объявлений для групп пользователей) и т.д.

Все это было доступно и раньше, но появление URL значительно упростило программы, представляющие ценную информацию в гипертекстовой среде. Действительно до эры URL процесс передачи всей информации о сервере, файле, протоколе, пользователе и аргументах был достаточно неудобен, особенно для новичков. С появлением URL значительно упростился весь механизм.

Указатель URL состоит из следующих частей:

<схема>:<специальное_имя>

где <схема> — это название схемы (используемый протокол, например http, ftp и т. д.), а <специальное_имя> — имя в формате, зависящем от используемой схемы.

Многие URL имеют следующий формат:

<протокол>://<пользователь>:<пароль>@<хост>:<порт>/<путь>

где

• <пользователь> — это имя пользователя, если оно необходимо (например, для FTP с не анонимной регистрацией);

• <пароль> — пароль этого имени пользователя;

• <хост> — доменное имя хоста, например “fictionalcorp.com“, или его IP-адрес в числовом формате вида х.х.х.х:

• <nopm> — номер IP-порта для соединения (если он не указан, используется стандартное значение для данного протокола);

• <путь> — связанные с URL данные, часто это указание подкаталога и имени файла.

Для Web-страницы URL выглядит, например, так:

http: //www.fictionalcorp.com/corpinfo/sales.html

• Фрагмент http указывает, что URL использует протокол HTTP;

• www.fictionalcorp.com — имя сервера, к которому желает подключиться пользователь;

• /corpinfo/sales.html — подкаталог и имя HTML-файла, хранящего Web-страницу.

Ниже перечислены некоторые популярные схемы:

• http Протокол HTTP

• https Протокол HTTP, зашифрованный с помощью SSL (Secure Socket Layer)

• mailto Адрес электронной почты

• ftp Протокол FTP

• news Новости Usenet

• file Имена файлов определенного хоста

• telnet Интерактивный сеанс Telnet

Более короткий URL — http://www.fictionalcorp.com — указывает на «основную страницу» этого сервера. Если явно не задано имя файла, то HTTP-серверы используют значение по умолчанию (часто это default.html или index.html). Приведенный URL можно преобразовать к более явному виду: http://www.fictiorialcorp.com/default.html.

Для протокола FTP применяется сходный синтаксис. Обращение к файлу bar.txt подкаталога /foo FТР-сервера ftp.fictionalcorp.com на языке URL выглядит следующим образом:

ftp://ftp.fictionalcorp.com/foo/bar.txt

Из-за огромной популярности World Wide Web в Интернете многие браузеры предполагают наличие префикса «http://» в URL, не содержащем явного указания протокола. Обычно имена доменов в явном виде содержат информацию о протоколе. Например, FТР-сервер компании называется ftp.fictionalcorp.com, а ее HTTP-сервер— www.fictionalcorp.com. Однако с появлением URL компания вправе использовать одно и то же имя fictionalcorp.com для обоих серверов. Тогда при использовании их ресурсов необходимо явно задавать соответствующий протокол, например ftp://fictionalcorp.com/public/foo.txt или http://fictionalcorp.com/

Частичный или относительный URL — тот, в котором не указан протокол, хост, порт или путь, а лишь относительное имя ресурса. Например, если Web-страница http://www.fictionalcorp.com/piiblic/foo/bar.html ссылается на bletch.html, это не что иное, как относительная форма от http://www.fictionalcorp. com/public/foo/bletch.html.

Как уже говорилось ранее, синтаксис URL меняется в зависимости от URL-схемы. Например, в протоколе HTTP символ «#» после имени HTML-файла обозначает точку привязки (закладку). Так, http://www.fic-tionafcorp.com/foo.html#disclaimer указывает на фрагмент disclaimer документа foo.html.

Вместо подкаталога и имени файла URL может содержать другую информацию о ресурсе. Так выгладит URL для протокола NNTP:

nntp://<хост>:<порт>/<группа_новостей>/<статья>

где <группа_новостей> — имя группы новостей, а <статья> — номер статьи.

Вообще говоря, в URL следует использовать только алфавитно-цифровые символы, так как большинство специальных символов зарезервированы или их прямое использование небезопасно. К первым относятся: «;», «/», «?», «:», «@», «=», «&». Ненадежные символы — «<», «>», «»»,«#», «%», «{», «}», «|», «», « », «-», «[», «]», «’».

Если имя ресурса содержит зарезервированный символ или символ, не принадлежащий US-ASCII, то перед использованием в URL имя надо закодировать. При кодировании символ заменяется тремя новыми — знаком процента (%) и двумя шестнадцатеричными цифрами, представляющими код заменяемого символа.

Предпосылки

Протокол HTTP — основной и достаточно простой способ передачи данных между Web-сервером и клиентом. До появления Web и HTTP для передачи файлов в Интернете в качестве протокола ввода/вывода чаще всего применяли FTP.

HTTP — это компактный, быстрый протокол ввода/вывода, работающий с URL и предназначенный для сред гипертекст/гипермедиа. В отличие от FTP, это протокол без состояний и имеет лишь несколько команд (методов). Благодаря использованию MIME, HTTP приспосабливается ко многим форматам данных и различным задачам ввода/вывода.

HTTP — клиент-серверный протокол, реализующий модель запрос/ответ. HTTP-клиент, или пользовательский агент (обычно это Web-браузер), подключается к HTTP-серверу с помощью URL и запрашивает ресурс, например HTML-документ.

Для инкапсуляции данных в этой модели применяются расширения MIME. Структура данных, пересылаемых между клиентом и сервером, напоминает электронную почту. Она состоит из тела сообщения и метаданных (заголовков сообщений). Протокол HTTP передает информацию в формате MIME. Метаданные содержат информацию, необходимую для передачи данных между HTTP-сервером и клиентом. Однако HTTP допускает двоичный формат, чего обычный MIME (из-за 7-битных ограничений почтовых шлюзов) не позволяет.

В сеансе связи, как правило, участвуют HTTP-клиенты (Web-браузеры) и HTTP-серверы (Web-серверы) и реже — прокси-серверы. Последние уступают в качестве сервера по отношению к клиенту и в качестве клиента по отношению к другому серверу, передавая исходный запрос клиента через шлюз (например, межсетевой экран между интрасетью компании и Интернетом).

Традиционно HTTP-клиенты и серверы общаются через 80-й порт TCP/IP, по умолчанию зарезервированный для HTTP. Однако могут использоваться и другие порты, явно указанные в URL. В дополнение замечу, что HTTP не предполагает применение именно TCP/IP и отлично функционирует с другими протоколами гарантированной доставки.

Web-браузер часто обрабатывает Web-страницы, состоящие из многих объектов, например, самого HTML-документа и нескольких изображений (GIF, JPEG, PNG и др.). Большинство HTTP-клиентов для чтения начального HTML-документа создают только один поток (с одним подключением к серверу), а затем еще несколько потоков (каждый с отдельным подключением к серверу) для получения остальных необходимых файлов. Соединение устанавливается по запросу клиента и разрывается после ответа сервера.

Все HTTP-транзакции имеют один общий формат. Каждый запрос клиента и ответ сервера состоит из трех частей: строки запроса (ответа), раздела заголовка и тела. Клиент инициирует транзакцию следующим образом:

1. Клиент устанавливает связь с сервером по назначенному номеру порта (по умолчанию — 80). Затем клиент посылает запрос документа, указав HTTP-команду, называемую методом, адрес документа и номер версии HTTP. Например, в запросе

GET /index.html HTTP/1.0

используется метод GET, которым с помощью версии 1.0 HTTP запрашивается документ index.html. Методы HTTP более подробно рассматриваются ниже.

2. Клиент посылает информацию заголовка (необязательную), чтобы сообщить серверу информацию о своей конфигурации и данные о форматах документов, которые он может принимать. Вся информация заголовка указывается построчно, при этом в каждой строке приводится имя и значение. Например, приведенный ниже заголовок, посланный клиентом, содержит его имя и номер версии, а также информацию о некоторых предпочтительных для клиента типах документов:

User-Agent: Mozilla/4.05 (WinNT; 1)

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

Завершается заголовок пустой строкой.

3. Послав запрос и заголовки, клиент может отправить и дополнительные данные. Эти данные используются главным образом теми CGI-программами, которые применяют метод POST. Клиенты (например, Netscape Navigator-Gold), также могут использовать их для помещения отредактированной страницы обратно на Web-сервер.

Сервер отвечает на запрос клиента следующим образом:

1. Первая часть ответа сервера — строка состояния, содержащая три поля: версию HTTP, код состояния и его описание. Поле версии содержит номер версии HTTP, которой данный сервер пользуется для передачи ответа.

Код состояния — это трехразрядное число, обозначающее результат обработки сервером запроса клиента. Описание, следующее за кодом состояния, представляет собой просто понятный для человека текст, поясняющий код состояния. Например, строка состояния

НТТР/1.0 200 OK

говорит о том, что сервер для ответа использует версию HTTP 1.0. Код состояния 200 означает, что запрос клиента был успешным, и затребованные данные будут переданы после заголовков.

2. После строки состояния сервер передает клиенту информацию заголовка, содержащую данные о самом сервере и затребованном документе. Ниже приведен пример заголовка:

Date: Fri, 10 Jan 1998 08:17:58 GMT

Server: Apache/1.2.6

Last-modified: Mon, 12 Jun 1997 21:53:08 GMT

Content-type: text/html

Content-length: 2482

Завершает заголовок пустая строка.

3. Если запрос клиента успешен, то посылаются затребованные данные. Это может быть копия файла или результат выполнения CGI-программы. Если запрос клиента удовлетворить нельзя, передаются дополнительные данные в виде понятного для пользователя разъяснения причин, по которым сервер не смог выполнить данный запрос.

В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершенной, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение, и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы — изображения, кадры, апплеты и т.д., это позволяет сэкономить время и затраты клиента, которому в противном случае пришлось бы для получения всего одной страницы многократно соединяться с одним и тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.

HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество такого правила организации взаимодействия состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI-программы должны пользоваться скрытыми полями ввода или внешними средствами, например «ключиками» (cookies) Netscape.

studfiles.net