Вашему вниманию предлагается описание основных аспектов протокола 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://alizar.сайт/

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

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

Telnet alizar.сайт 80

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

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

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

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

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

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

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

Теги:

• http
• alizar
• spdy

Если вы хотели узнать, как передаются данные в интернете - эта статья для вас. Я расскажу вам все что знаю о протоколах HTTP и HTTPS, покажу разницу и отличия между ними. Приятного чтения!

HTTP 1.1 - что это за протокол?

HTTP (англ. «протокол передачи гипертекста») - сетевой протокол верхнего уровня для передачи гипертекстовых и произвольных данных в интернете.

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

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

Актуальная версия протокола - 1.1. Ее описание находится в спецификации RFC.

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

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

Более того, HTTP часто выступает как протокол-транспорт для трансфера других прикладных протоколов и их API: WebDAV, XML-RPC, REST, SOAP. Ну а данные передаваемые по API могут иметь самый разный формат: XML, JSON и другие.

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

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

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

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

Принимать участие в передаче данных могут и посредники (прокси-сервера), для того чтобы отличить прокси от конечных серверов (т.н. «исходный сервер»).

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

HTTP/2 - а это что за протокол?

Первоначальная версия протокола HTTP появилась в ЦЕРНЕ (CERN) в 1991 году. Уже в 1992 году была опубликована публичная версия HTTP 0.9 и его спецификация, благодаря чему были упорядочены правила взаимодействия между клиентскими и серверными приложениями, а также четкому разграничению функциональности.

В 1996 году появился HTTP/1.0, а современная версия протокола - HTTP/1.1 - в 1999 году. На рубеже тысячелетий, протокол HTTP научился поддерживать режим постоянного соединения, т.е. оставлять соединение открытым после того как получен ответ на запрос. Это позволило за одно соединение посылать сразу несколько запросов, а не открывать-закрывать сессию каждый раз.

Шло время и по мере развития интернета размер страниц увеличивался, росло количество запросов - требовалось все больше ресурсов. Так сформировалась потребность в новом протоколе.

И спустя шестнадцать лет, в 2015 году была опубликована финальная версия черновика спецификации следующей версии протокола - HTTP/2. Бинарный протокол HTTP/2 более подготовлен к современным реалиям, чем прародитель HTTP 1.1 потому что новый протокол решает наиболее существенную проблему передачи данных в интернете - несколько отрытых соединений.

А все потому что нынешние сайты подгружают много элементов, как со своего сервера, так и с CDN: JS-скрипты, CSS-стили, шрифты и картинки. При передаче полного комплекта файлов по протоколу HTTP 1.1 создается несколько соединений. Если мы в будущем перейдем на протокол HTTP/2 - передача будет происходить в рамках одного соединения между клиентом и сервером, что позволит существенно ускорить и оптимизировать загрузку содержимого сайта.

Ключевые особенности HTTP/2, которые будут полезны для сайтов:

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

Конечно, главное здесь это мультиплексирование потоков. Принцип работы объяснить проще простого: пакеты TCP/IP-соединения смешиваются в рамках одного соединения. Так, в смешанном режиме происходит соединение нескольких «вагонов данных» в один «состав поезда», которые разделяются «по приезду». Ранее «вагоны» были вынуждены ехать дольше и раздельно, сейчас они будут ехать вместе и быстрее.

Вышеперечисленные преимущества протокола HTTP/2 позволят веб-разработчикам дышать полной грудью и отказаться от таких «костылей» как:

• Использование большего числа родственных доменов для обеспечения установки большого количества TCP/IP-соединений (для скачивания файлов);
• Спрайты картинок - когда изображения объединяются в один файл, чтобы снизить число запросов к веб-серверу (а сам файл «раздувается» ведь в него записано больше изображений);
• Объединение CSS- и JS-файлов, которые тоже делаются для уменьшения запросов.

Последнее очевидное преимущество заключается в том, что с самим сайтом (для включения HTTP/2) ничего дополнительно делать не нужно - все работы проводятся на сервере чуть ли не в «1 клик», а для клиентов shared- и VPS-хостингов вообще пройдут незаметно.

Словом, заживем!

HTTP/2 создан и разработан на основе черновика протокола SPDY/3 (Google) и превзошел его - компания Гугл признала преимущества HTTP/2 более многообещающими и в будущем откажется от поддержки SPDY/2.

Прогнозируемое ускорение ответа сервера по протоколу HTTP/2 составит порядка 30%, - реальные тесты уже показали скорости на 19-23% выше и это не предел.

По результатам тестов компании Айри.рф, только от включения протокола HTTP/2 прирост скорости составляет 13-18% (без оптимизации). Почему это важно?

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

Прежде всего за счет поведенческих факторов. Ускорение загрузки позволяет пользователям меньше уставать и больше концентрироваться на изучении сайта: просматривать больше страниц и не покидать сайт из-за долгой загрузки (уменьшаются отказы).

Большая часть современных браузеров уже поддерживает HTTP/2 - через них проходит ~70% интернет-трафика:

• Chrome 41-52 и Chrome 46+ в Android;
• Firefox 36-48 и Firefox 41+ в Android;
• Opera 28-34 и Opera 30+ в Android;
• Safari 9 и Safari в iOS 9.1;
• IE 11 в Windows 10 и браузер Edge 12, 13.

Когда произойдет полноценный переход на HTTP/2 пока непонятно - вероятнее всего в самом ближайшем будущем. Главное что от HTTP/1.x никто не собирается поспешно отказываться. Как говорится: «Работает - не трогай».

Что значит и где применяется HTTPS-протокол?

Ну, про обмен данными по протоколу HTTP вы уже все знаете: любая передача данных осуществляется через запросы по этому протоколу-транспорту. А зачем тогда нужен HTTPS и что он из себя представляет? Ведь жили же нормально и без него?

Проблема в том что данные по HTTP не защищаются и передаются в открытом виде. Интернет - глобальная распределенная сеть узлов. И если вы передаете открытые данные по незащищенному протоколу (Wi-Fi в ТРЦ сюда тоже относится), то один из этих узлов может перехватить их.

Не специально конечно, может быть просто взлом усилиями злоумышленников. HTTPS и создан для того чтобы соединение было безопасным, а данные передавались в зашифрованном виде по криптографическому протоколу SSL/TLS. Это специальная «обертка» поверх HTTP, она шифрует данные, делая их недоступными для злоумышленников и посторонних людей.

HTTPS - англ. «безопасный протокол передачи гипертекста».

Так что в отличие от 80 порта, используемого по умолчанию в HTTP, в HTTPS используется TCP-порт 443 и есть ключ для шифрования. Ключ может быть длиной 40, 56, 128 или 256 бит, достаточный уровень безопасности на данный момент начинается со 128-битных ключей.

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

Жизненно важно использовать HTTPS в следующих сервисах:

• Электронные платежные системы (банки, электронные деньги и прочее);
• Сервисы принимающие и отправляющие приватную информацию и персональные данные, например у Яндекса это: Паспорт, Такси, Директ , Метрика, Почта, Деньги , Вебмастер и другие;
• Социальные сети и личные кабинеты в интернет-сервисах;
• Поисковые системы.

Работает HTTPS просто. Объясню на примере.

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

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

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

Все - вот так просто работает HTTPS.

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

Единственный нюанс здесь - надо знать, что вы отправляете данные именно туда, куда нужно. И что конечный пункт и является пунктом назначения. Но нужно подтвердить и точно знать, что конечный адресат существует и управляется тем самым сервером, куда отправляются данные.

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

А вот как выглядит сам сертификат:

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

Осуществляя взаимодействие «клиент-сервер» по протоколу HTTPS можно не беспокоиться за сохранность данных - вы надежно защищены от прослушивания сетевого соединения: атак снифферов и man-in-the-middle.

Что означает перечеркнутый значок HTTPS и зеленый значок HTTPS, в чем разница? В безопасности. Зеленый - безопасный, красный и перечеркнутый - небезопасный.

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

Что лучше HTTP 1.1, HTTP/2 или HTTPS?

В качестве подведения итога затрону тему предпочтительного использования протоколов.

Понятно, что на данный момент HTTP 1.1 - наиболее распространенный протокол и используется по умолчанию. Время HTTP/2 еще не пришло, но вскоре большая часть интернет-трафика будет идти через вторую версию протокола HTTP. Это упростит жизнь пользователям, потому что сайты будут загружаться быстрее. Администраторы серверов и сайтов тоже будут рады, потому что новый протоко позволяет по новому оптимизировать сайты, ускоряя загрузку и отдачу данных.

При этом, вряд ли возможно, что все сайты перейдут HTTPS, потому что для целей потребления развлекательного контента шифрование ни к чему. Да, сейчас уже 10% сайтов используют HTTPS в рейтинге наиболее посещаемых веб-ресурсов «Alexa». Но это всего десять процентов, среди которых такие гиганты как Гугл, ПейПал, Амазон, Алиэкспресс и другие. То есть множество сайтов, где не использовать HTTPS означает нарушать право интернет-пользователя на безопасность и сохранность данных.

А обычным сайтам типа блога семи блоггеров HTTPS ни к чему - нет приема персональных или платежных данных, нет регистрации и отправки важных сообщений.

Так что в ближайшем будущем мы станем постепенно отходить от HTTP 1.1 в пользу HTTP/2 и HTTPS.

HTTP (англ. Hyper Text Transfer Protocol – «протокол передачи гипертекста») - протокол передачи данных прикладного уровня, разработанный специально для обмена информацией между веб-сайтом и пользовательским агентом (браузером). Это один из тех стандартов, на которых основан весь World Wide Web. Взаимодействие поисковых систем с сайтами также проходит в рамках протокола HTTP .

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

О терминах

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

Веб-сервер (сервер) - не компьютер, стоящий в датацентре, а исполняемая на этом компьютере программа, которая принимает запросы и отправляет запрошенные документы.
Пользовательский агент (клиент, User-agent) - программа, посылающая запросы веб-серверу и получающая от него документы. Это может быть ваш браузер, а может быть и сканирующий бот поисковой системы.
Документ - любая отдельная единица информации, имеющая свой адрес в домене. По умолчанию подразумевается HTML -страница, но документами также считаются файлы рисунков, CSS , Java-скриптов и т.п.

Порядок обмена информацией

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

Стартовая строка

Заголовки

Тело сообщения

Стартовую строку и строки заголовков часто называют вместе «заголовком запроса» (или ответа).
Пример стартовой строки запроса:

GET /index.php HTTP/1.1

Передан метод запроса (GET), адрес документа внутри домена и версия протокола, которая используется.
Пример стартовой строки ответа:

HTTP/1.1 200 OK

Передана версия протокола, числовой код статуса (200) и расшифровка статуса (OK).

Заголовки

В заголовках запроса передается дополнительная информация, которая может влиять на дальнейший обмен сообщениями. Обязательно передается имя домена, из которого запрашивается документ. Также может передаваться ожидаемый медиатип документа, возможность приема в сжатом формате, ожидаемый язык для текстовых документов, название пользовательского агента, отправившего запрос. В заголовке могут также передаваться условия запроса. Например, If-Modified-Since: [метка времени] - запрашивается документ при условии, что его содержание изменилсь со времени, указанного в заголовке.

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

При невозможности передачи документа код статуса в сообщении сервера соответствует характеру ошибки, а вместо тела документа передается специальная HTML -страница с текстом сообщения об ошибке. Обратите внимание, что статус ошибки не мешает браузеру отобразить эту страницу.

Методы запроса

Протоколом в редакции RFC 2616 описано восемь методов для обращения к серверу. Но на сегодняшний день не все они реализованы для большинства веб-серверов, а обязательными к реализации признаны только два. Основные методы, которые нас интересуют и поддерживаются практически всеми веб-серверами - это GET, HEAD и POST.

Метод GET

Это самый обычный метод запроса для получения веб-страницы или другого документа. В ответ на этот запрос сервер должен отыскать (или сформировать) документ и при успешном завершении отправить его клиенту.
Формат запроса:

GET HTTP[версия протокола]

Метод HEAD

Этот метод аналогичен GET, но с одним отличием: в ответ на запрос HEAD сервер выполняет поиск (или формирование документа), но отправляет только заголовки ответа, не передавая тело сообщения. Таким способом можно проверить существование или доступность документа по данному адресу, получить всю информацию о документе, передаваемую в заголовках, не получая сам документ.
Формат запроса:

HEAD HTTP[версия протокола]

Тело сообщения в запросе отсутствует.

Метод POST

Этот метод предназначен для передачи данных на сервер - например, данные, введенные в форму, обычно передаются методом POST.
Формат запроса:

POST HTTP[версия протокола]

Поле [ URI ] содержит адрес скрипта-обработчика формы, который принимает и обрабатывает данные. В теле сообщения передаются данные, введенные в поля формы в виде [имя_поля=введенное_значение].

Коды статуса

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

1xx: Informational - информационный

Коды от 100 до 199, входящие в этот класс, информируют клиента, что запрос получен. Сообщения с такими статусами содержат только стартовую строку и (если нужно) заголовки, но не содержат тело сообщения. Отправлять что-либо в ответ на это клиент не должен.

2xx: Success - успешно

Сообщения этого класса означают, что запрос успешно получен, интерпретирован и обработан. Из этих кодов статуса нас интересует только 200 «OK» - признак нормального завершения, после которого в теле сообщения клиенту пересылается запрошенный документ.

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

заголовки?

«Протокол передачи гипертекста» - именно так переводится Благодаря его существованию, возможна связь «клиент-сервер». Если объяснить простыми словами, пользователь браузера посылает запрос, инициируя соединение с сервером. Последний, по умолчанию, ждет запрос от клиента, обрабатывает его и посылает обратно итоговую информацию или ответ. В поисковой строке пользователь «вбивает» адрес сайта, который начинается с http:// и получает результат в виде открывшейся страницы.

Когда печатается адрес сайта в соответствующей строке, браузер находит требующийся сервер с помощью DNS. Сервер распознает http заголовок (один или несколько), который посылает ему клиент, а затем выдает требуемый header. Набор обязательных состоит из уже существующих заголовков и не найденных.

В общем, http заголовки достаточно эффективные. Их не видно в HTML-кодировании, они отправляются перед запрашиваемыми сведениями. Многие заголовки автоматически высылаются сервером. Для того чтобы его отослать на языке PHP, следует воспользоваться функцией header.

Взаимодействие браузера и сайта

Схема взаимодействия браузера и сайта достаточно простая. Так, http заголовок начинает строку запроса, который далее посылается серверу. В ответ приходит нужная клиенту информация. Между прочим, http протокол уже семнадцать лет - самый используемый в Интернете. Он простой, надежный, работает быстро и гибко. Главная задача http - запрос сведений с web-сервера. Клиентом является браузер, а сервером - ligthttp, apache, nginx. Если соединение между ними произошло успешно, сервер в ответ на запрос получает нужные сведения. Информация http содержит текстовые, звуковые файлы, видео.

Протокол может быть транспортом для других. Запрос клиента состоит из трех частей:

• стартовой строки (тип сообщения);
• заголовков (параметры сообщения);
• тела информации (сообщение, которое отделяется пустой строчкой).

Стартовая строка - обязательный элемент запроса поля заголовков http. Структура запроса пользователя состоит из трех основных частей:

1. Метод. С его помощью указывается тип запроса.
2. Путь (path). Это строка URL, которая следует за доменом.
3. Используемый протокол. Он состоит из версии protocol и http.

Современные браузеры используют версию 1.1. Далее следуют заголовки в формате "Имя: значение".

HTTP-кэширование

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

Кэш имеет браузер клиента, промежуточный шлюз и прокси-сервер. Перед тем как отправить сообщение по URL, браузер проверит наличие объекта в кэше. Если объекта нет, запрос передается следующему серверу, где проверяется кэширование http заголовков на сервере nginx. Шлюзы и прокси используются разными пользователями, поэтому кэш является разделяемым.

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

Описание http заголовков

Одними из самых главных механизмов кеша считаются http заголовки expires. Эти заголовки сообщают о сроке годности предоставленной в отклике информации. В них указывается время и дата, когда кэш будет считаться устаревшим. Например, такой заголовок выглядит следующим образом: Expires: Wen, 30 Nov 2016 13:45:00 GMT. Данная структура используется почти везде, в том числе для кэширования страниц и картинок. Если пользователь выберет старую дату, сведения не будут кэшироваться.

Заголовки http proxy относятся к категории header link. Они не кэшируются по умолчанию. Чтобы кэш работал правильно, каждый URL должен соответствовать одному варианту содержимого. Если страница действует на двух языках, каждая версия должна иметь собственный URL. Заголовок vary сообщает кэшу названия заголовков запроса. К примеру, если отображение запроса зависит от браузера, серверу необходимо также отправлять заголовок. Таким образом, в кэше сохраняются разные варианты запросов и типы документов. TTP заголовок accept необходим для того чтобы составлять списки допустимых форматов используемого ресурса, с ним достаточно легко работать, так как он отсеивает ненужные.

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

HTTP заголовок authorization считается дополнительным. Когда web-страница спрашивает у клиента авторизацию, браузер отображает специальное окно с полями для ввода логина и пароля. После того как пользователь введет свои данные, браузер передает запрос http. Он содержит заголовок «авторизация».

Как увидеть заголовки?

Чтобы увидеть http заголовок, необходимо установить плагины для браузера, например, firefox:

• Firebug. Просмотреть заголовки можно во вкладке net (сеть), где выбрать all (все). Этот плагин обладает функциями, которые будут полезны веб-разработчику.
• Live http headers. Простой плагин, предназначенный для просмотров http заголовков. С его помощью вручную можно сгенерировать запрос.
• Пользователи Ghrome легко увидят заголовки, если нажмут кнопку настроек, выберут инструменты разработчика (net works).

Когда плагины будут установлены, запустите их и браузера.

Методы запросов

Методы, которые используются в HTTP, имеют сходства с инструкциями, которые передаются в виде сообщения серверу. Это специальное слово на английском языке.

• Метод GET. Его используют для запроса информации с ресурса. Именно с него начинаются все действия.
• POST. С его помощью происходит отправка данных. Например, сообщение в социальной сети или комментарий, браузер помещает в тело POST-запроса и отправляет серверу.
• HEAD. Метод имеет сходства с первым, но выполняет легкую функцию. Он запрашивает только мета-данные, исключая из ответа сообщение. Методом пользуются, если хотят получить информацию о файлах без скачивания. Его используют, если хотят проверить работоспособность ссылок на сервере.
• PUT. Загружает данные на URL. Передает большие объемы данных.
• OPTIONS. Работает с конфигурациями сервера.
• URI. Идентифицирует ресурс и содержит в себе URL.

Структура http ответа

Сервер отвечает на запросы клиента длинными сообщениями. Ответ состоит из нескольких строк, в которых указывается версия протокола, код статуса сервера (200). Он говорит о том, что изменилось на сервере за время обработки поступившего запроса:

1. Статус «двести» указывает на успешную обработку информации. После этого сервер отправляет документ клиенту. Остальные строчки запроса указывают на другую информацию о передаваемых сведениях.
2. Если файл не найден или не существует, сервер посылает клиенту код 404, его еще называют ошибкой.
3. Код 206 указывает на частичное скачивание файла, которое можно возобновить спустя время.
4. Код 401 свидетельствует об отказе в авторизации. Это означает, что запрашиваемая страница защищена паролем, который следует ввести для подтверждения входа.
5. О запрещенном доступе, говорит код 403. Запреты на просмотры, скачивание файлов или видео - распространенный ответ в Интернете.
6. Существуют также другие версии кодов: временное перемещение запрашиваемого файла, внутренняя ошибка сервера, окончательное перемещение. В этом случае, пользователь будет перенаправлен. Если появился код 500, это означает, что в работе сервера появились сбои.

URL - что это?

URL - это сердце веб-общения между клиентом и сервером. Запрос обычно отправляется через URL - единый указатель ресурсов. Структура запроса url очень проста. Она состоит из нескольких элементов: протокол http (заголовок), hoot (адрес сайта), port, resourte path и query.

Протокол доступен также для безопасного соединения https и обмена информацией. URL-адрес содержит информацию о размещении конкретного сайта в Интернете. Адрес включает в себя имя домена, путь к странице, а также ее название.

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

Активным пользователям компьютеров и разработчикам не помещает ознакомиться с некоторыми профессиональными рекомендациями, которые дают специалисты в этой области:

• Обозначайте сроки годности файлов и документов, с учетом обновлений. Статистическая информация указывается в больших значениях max-age.
• Отдельный документ должен быть доступен лишь по одному URL.
• Если обновляете файл, который будет скачиваться пользователем, измените его имя и ссылку на него. Это гарантирует скачивание нового, а не устаревшего документа.
• Заголовки Last-Modified должны соответствовать настоящей дате последних изменений содержания. Не следует пересохранять страницы и документы, если не будете их менять.
• Используйте POST-запросы лишь там, где это нужно. Сведите к минимуму работу с SSL.
• Заголовки перед отправкой сервером следует проверять плагином REDbot.

HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) был разработан как основа World Wide Web.

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

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

HTTP-запрос состоит из заголовка запроса и тела запроса, разделенных пустой строкой. Тело запроса может отсутствовать.

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

Запрос в главной строке состоит из трех частей, разделенных пробелами:

Метод (иначе говоря, команда HTTP):

GET - запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD - запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST - этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT - разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс - это путь к определенному файлу на сервере, который клиент хочет получить (или разместить - для метода PUT). Если ресурс - просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола -версия протокола HTTP, с которой работает клиентская программа.

Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

Здесь запрашивается корневой файл из корневой директории web-сервера.

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

Параметр: значениe .

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

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение)- может принимать значения Keep-Alive и close. Keep-Alive ("оставить в живых") означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером "скачать" html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.
close ("закрыть") - соединение закрывается после ответа на данный запрос.

User-Agent - значением является "кодовое обозначение" браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept - список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Это, очевидно, нужно для случая, когда сервер может выдавать один и тот же документ в разных форматах.

Значение этого параметра используется в основном CGI-скриптами для формирования ответа, адаптированного для данного браузера.

Referer - URL, с которого перешли на этот ресурс.

Host - имя хоста, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP-адресом. В этом случае имя виртуального сервера определяется по этому полю.

Accept-Language - поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.

Формат HTTP-ответа

Формат ответа очень похож на формат запроса: он также имеет заголовок и тело, разделенное пустой строкой.

Заголовок также состоит из основной строки и строк параметров, но формат основной строки отличается от таковой в заголовке запроса.

Основная строка запроса состоит из 3-х полей, разделенных пробелами:

Версия протокола - аналогичен соответствующему параметру запроса.

Код ошибки - кодовое обозначение "успешности" выполнения запроса. Код 200 означает "все нормально" (OK).

Словесное описание ошибки - "расшифровка" предыдущего кода. Например для 200 это OK, для 500 - Internal Server Error.

Наиболее употребительные параметры http-ответа:

Connection - аналогичен соответствующему параметру запроса.
Если сервер не поддерживает Keep-Alive (есть и такие), то значение Connection в ответе всегда close.

Поэтому, на мой взгляд, правильной тактикой браузера является следующая:
1. выдать в запросе Connection: Keep-Alive;
2. о состоянии соединения судить по полю Connection в ответе.

Content-Type ("тип содержимого") - содержит обозначение типа содержимого ответа.

В зависимости от значения Content-Type браузер воспринимает ответ как HTML-страницу, картинку gif или jpeg, как файл, который надо сохранить на диске, или как что-либо еще и предпринимает соответствующие действия. Значение Content-Type для браузера аналогично значению расширения файла для Windows.

Некоторые типы содержимого:

text/html - текст в формате HTML (веб-страница);
text/plain - простой текст (аналогичен "блокнотовскому");
image/jpeg - картинка в формате JPEG;
image/gif - то же, в формате GIF;
application/octet-stream - поток "октетов" (т.е. просто байт) для записи на диск.

На самом деле типов содержимого гораздо больше.

Content-Length ("длина содержимого") - длина содержимого ответа в байтах.

Last-Modified ("Модифицирован в последний раз") - дата последнего изменения документа.