Как работает интернет. Часть 6 | Назначение протокола http

Итак, теперь мы уже более-менее разобрались с адресами сайтов, со всеми четырьмя. Но вот беда – мы знаем, куда нужно посылать какие-либо данные, но мы понятия не имеем, а что, собственно, туда посылать. Нет, мы знаем, что нужно попросить что-то вроде «Google, дай свою главную страницу», но ведь компьютер человеческого языка не понимает, ему надо все формально и на «своем языке».

Эти «языки» которые понимает компьютер, называются «протоколы». И сегодня нас будет интересовать протокол HTTP – именно по данному протоколу можно попросить сайт отдать какую-нибудь страничку.

Но прежде чем что-то просить, неплохо бы определиться, а что нам вернут в ответ? Очевидно, сайт. Но сайт «в каком виде»? Не вернется же картинка с изображением сайта в фотошопе? Конечно, нет. Вернется некий текст, также по протоколу HTTP, в котором будет другой текст, на другом языке, называемом HTML (и не только HTML). Это очень большой язык, поэтому даже стандарт на него занимает более 1000 страниц, поэтому более плотно им мы займемся позднее, но сейчас для нас главное не это – главное то, что в языках HTTP и HTML все описывается в виде текста. То есть, на наш HTTP-запрос сайта google.ru (например), в ответ Гугль должен вернуть какой-то файл с текстом. Позже, когда мы изучим много чего еще, мы вернемся и расшифруем, что же нам вернулось, но пока это для нас будет просто «некий текст».

Чтобы мы сами могли что-то отправить по протоколу HTTP, нам нужна программа, называемая telnet – она позволяет нам соединяться с другими компьютерами и посылать им команды. Если у вас Windows XP, просто нажмите на кнопку « ПУСК», введите в строке telnet, и нажмите « Enter». В Windows 7, Telnet нужно сначала «включить». Идем в Панель Управления, далее «Программы и компоненты», «Включение или отключение компонентов Windows», затем выбрать «Клиент Telnet», и нажать « OK». Затем точно так же можно нажать « ПУСК» и ввести в строке telnet.

Появится окошко, где мы можем вводить команды. Введем одну из них - «open google.ru 80». Эта команда означает – «подключиться к сайту google.ru на порт 80» (как мы помним, у сайтов стандартный порт номер 80). И… Ничего вроде бы не появилось. Нет, на самом деле появилось, но просто вы этого не видите. Ваш компьютер подключился к google.ru, и ждет от вас какую-нибудь команду. Дадим ее – «GET / HTTP/1.1», и два раза нажмем «Enter». В ответ вывалится множество английского непонятного текста, и (может быть) сообщение, что «подключение к узлу утеряно».

Поздравляю вас, вы только что сами поработали в роли браузера – запросили главную страницу google.ru, и получили ее по протоколу HTTP. Собственно, эта команда – GET, и ответ, который вам пришел – все они описаны в стандарте на протокол HTTP, который находится здесь – https://tools.ietf.org/html/rfc2616 (да, на английском, так как это международный стандарт). В частности, можно увидеть, что пункт 9.3 как раз называется GET, и что еще есть POST, PUT и еще куча других.

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

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

HTTP считает сайт неким «устройством хранения» со своими файлами и каталогами. Например, если вы наберете «GET /aa/bb/ii.html», то в ответ вы получите файл ii.html, находящийся в каталоге bb, который находится в каталоге aa, который находится в том каталоге, который сервер считает для сайта корневым каталогом.

Кроме файлов, можно запрашивать и каталоги. Например, если вы наберете «GET /aa/bb/», то получите некий файл из каталога bb. Какой именно – определяет сервер. Обычно это либо index.html, либо index.php (но не обязательно).

Теперь разберемся, как передать запрашиваемой странице параметры. Их можно передавать несколькими способами.

Первый способ – это GET (который мы и использовали в статье 6). В этом случае, после имени файла можно добавить вопросительный знак, записать имя параметра, знак равно, и значение параметра. Например, «GET https://yandex.ru?xxx=yyy». В этом случае сервер yandex.ru узнает, что ему передали параметр xxx, который равен yyy. А что, если нам нужно передать несколько параметров? Тогда нужно разделить их символом «&». Например
«GET https://yandex.ru?par1=val1&par2=val2». В чем достоинство такого метода? Не нужно придумывать ничего лишнего – все параметры уже в адресе страницы. А в чем недостаток? Во-первых, все параметры видно пользователю, а если параметров десяток, да еще и длинных, строка запроса получится длинная, и пользователь может просто растеряться, глянув в такой длинный адрес. Да и по телефону его не продиктуешь.

Второй метод – это POST. В данном методе вы запрашиваете просто нужную вам страницу «POST https://yandex.ru», потом нажимаете Enter (1 раз), затем вводите еще одну строку «Content-Length: 10» (что означает, что вы хотите передать еще 10 байт с параметрами, вы можете заменить 10 на любое нужное вам число), затем нажать Enter 2 раза, и ввести 10 байт с параметрами (в таком же виде, par1=val1&par2=val2&…). Enter в конце нажимать не надо, сервер сам поймет, что запрос закончился, когда кончится длина, которую вы указали. Минусы POST – пользователь не видит, что передается сайту. Иногда это хорошо, а иногда плохо. Плюсы POST – можно передавать много данных (сколько именно, определяет сам сервер). Если, например, вы хотите создать сайт, куда можно загружать видео, как, например, ВКонтакте, метод GET вам явно не подойдет, так как браузер просто не переварит адрес сайта из миллиарда букв, а вот POST запросто.

Третий метод – это Cookie. На самом деле, это не способ «передать любые свои данные сайту», это метод «передать данные сайту, которые он сам сохранил». Например, у вас есть сайт Интернет-магазина, и вы хотите, чтобы если пользователь закрыл браузер, а потом открыл снова, то ему не надо было бы вводить пароль заново, и чтобы его корзина покупок осталась полной. Для этого вам нужно сохранить данные об этом. Где? Прямо на компьютере пользователя. Но согласитесь, вы бы разрешили сайту сохранять что ни попадя на вашем компьютере? А вдруг он вирус вам сохранит? Поэтому было придумано стандартное решение для таких ситуаций – Cookie. Сайт в ответе на ваш запрос HTTP может передать вам инструкцию Set-Cookie. Когда браузер получает такую инструкцию, он сохраняет данные сайта в специальную папочку на вашем компьютере (разную для разных браузеров). А затем, когда он в следующий раз будет запрашивать сайт, он также после «GET https://internet-magazin.ru» добавит еще одну строчку
«Cookie: xxx=yyy; zzz=aaa», где перечислит те данные, которые сам сайт же и сохранил. Таким образом, ваш Интернет-магазин сможет «узнать пользователя в лицо» и показать ему его корзину.

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

Итак, теперь мы знаем, как запросить что-то у сервера по протоколу HTTP. Что же приходит нам в ответ? В ответ нам приходит также несколько «заголовков», из которых первый должен содержать код ответа. Например, «HTTP/1.1 200 OK».

Как мы видим, сначала идет версия HTTP (та, которую вы указали в запросе), затем код ответа (200), а затем буквенное описание ответа (OK). Буквенное описание ответа нужно только для человека, компьютер его никак не воспринимает. Возникает вопрос – зачем же оно нужно, если человек почти никогда и запросов HTTP-то не делает? Все делает браузер, а как именно, мы же все равно не видим. На самом деле, это иногда очень помогает. Например, не грузится у нас страница, мы смотрим (вручную) ответ от сервера, а там какое-нибудь «Server Bandwith Exceeded, try again later», и сразу понимаем, что просто сервер перегружен (если, конечно, вы знаете английский).

Код 200 – самый приятный, и (как видно выше), означает OK. Код 404 – самый понятный – означает, что такой страницы (файла) на сервере нет. Код 301 означает, что в этом месте была страничка, но она была перемещена (и сервер скажем вам ее новое месторасположение), а код 401 – что для доступа на данную страницу необходима авторизация (например, ввод логина и пароля). Есть также множество других кодов, означающих разные вещи.

Итак, допустим, что нам пришел код 200, и все ОК. Далее нам придут несколько строчек, описывающих различную служебную информацию, например, текущую дату «Date: Wed, 11 Feb 2009 11:20:59 GMT», имя программы, которая нас обслуживает «Server: Apache», тип возвращаемого ответа и его кодировка (мы уже говорили, что странички создаются на языке HTML) – «Content-Type: text/html; charset=utf-8», размер ответа «Content-Length: 1234», в общем, все, что сервер пожелает нам сообщить.

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

Если нам пришел код 301, о том, что страничка перемещена, то после первой строки, например, «HTTP/1.1 301 Moved Permanently», нам придет еще и строчка, указывающая, где теперь находится документ, к примеру, «Location: https://yandex.ru/newlocation/». В этом случае браузер просто прочитает это месторасположение, и отправит еще один запрос по этому адресу.

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

Теперь, когда мы познакомились с протоколом HTTP, может возникнуть вполне закономерный вопрос – мы знаем что надо отправлять (HTTP-запрос), мы знаем, куда нужно его отправлять (например, на сайт https://yandex.ru), мы знаем на какой порт нужно его отправлять (он стандартный, 80). Но ведь от нас нет прямого провода до Москвы, где и находится компьютер yandex.ru?

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

Конечно же нет. HTTP это вообще достаточно простой протокол, который и умеет-то только запрашивать странички и возвращать ответы. Для того, чтобы отправить то, что он «насочинял», протокол HTTP отдает все им созданное другому протоколу, TCP.

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

Протоколы могут «инкапсулироваться» друг в друга. Что это значит? Это значит, что в одном протоколе есть поле «данные», и в это поле вставляется другой протокол. Примерно так:

Это значит, что, на самом деле, самым главным является отнюдь не протокол HTTP, как мы думали ранее, наоборот, он является самым «наименее значимым». Главным является протокол Ethernet, так как именно он осуществляет передачу данных по проводам. Но чтобы передать что-то по проводам, нужно знать, ЧТО передавать. На самом деле передается еще один протокол, IP. Именно этот протокол отвечает за IP-адреса, передачу пакетов и их доставку. Что же за пакеты доставляет протокол IP? А доставляет он протокол TCP. Протокол TCP осуществляет установку соединения, поддержание его, коррекцию ошибок, и многие другие вещи. Но что же передает протокол TCP в своем «соединении»? Он передает протокол HTTP. А что находится в протоколе HTTP? А в протоколе HTTP, как мы уже знаем, находятся запросы сайтов и ответы сервера.

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

Некоторые протоколы из этого списка мы уже знаем, например, HTTP, а некоторые нет – IMAP, FTP, и другие (не волнуйтесь, скоро мы их изучим). Главное понять принцип инкапсуляции – между серверами посылаются не данные HTTP, а пакет Ethernet, в котором находятся данные IP, в которых находятся данные TCP, в которых находятся данные HTTP.

Что же делает сервер, когда получает такой «слоеный пирог»? Обратную операцию. Откусывает заголовок Ethernet, и читает в нем какой протокол ему ждать дальше. Видит, что IP. Читает заголовок IP (кстати, именно там записано, какой это IP – IPv4 или IPv6), видит, что дальше идет TCP, и отбрасывает IP. Читает заголовок TCP, видит, что дальше идет HTTP, отбрасывает заголовок TCP. Читает HTTP, видит, что нужна страница такая-то, получает ее (что тоже довольно неочевидно, у нас будет много статей по поводу того, как сервер получает нужный файл), и… отправляет обратно.

Отправляет обратно он точно так же. Берет HTTP-ответ, кладет его в пакет TCP, получившийся симбиоз кладет в пакет IP, что получилось – в пакет Ethernet, и его отправляет по проводу какому-либо компьютеру.

Кстати… а какому? Если для нас, домашних пользователей, вполне логично выходить в Интернет через некий «шлюз», то вряд ли Яндекс или Гугл имеют какой-то шлюз, через который они выходят в Интернет. Если бы это было так, то ему достаточно было бы сломаться, и Яндекса или Гугла стало бы не видно в Интернете. Конечно, это не так. За маршрутизацию в Интернете отвечают другие протоколы, например, OSPF или BGP.
Их мы тоже будем рассматривать, но уже гораздо позже.

А как же шифрование? В последнее время, особенно после скандала с АНБ, многие задумываются о том, будут ли их пакеты зашифрованы. Да, и тут есть свои протоколы, например TLS, IPSec, HTTPS. Но это тоже позже. А вот в следующей статье мы будем разбирать протокол TCP, и смотреть, как же в него можно встроить тот HTTP-запрос, который нам нужен.

Понравилась полезная статья? Подпишитесь на RSS и получайте больше нужной информации!

Комментарии

Добавить новый RSS

ы   |2013-10-12 22:43:14 Фраза: "языках HTTP и HTML" не верна. HTTP - протокол, а HTML - язык Ответ 2   0

Оставить комментарий
Имя:
Email:	не уведомлятьуведомлять
Тема:
	Пожалуйста, введите проверочный код, который Вы видите на картинке.

3.26 Copyright (C) 2008 Compojoom.com / Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved."