HTTP протокол
Для начала, выясним для себя что такое протокол вообще. Протокол - это некоторый набор правил и ключевых знаков, предназначенный для общения устройств между собой. Он необходим для того что бы компьютеры или их части могли однозначно понять друг друга.
Протокол - язык общения компьютеров в сети.
Фактически любой набор команд можно назвать протоколом, но на практике понятие протокола применяется только к так называемым сетевым протоколам - языкам общения компьютеров в сети. Каждый протокол имеет определенное назначение и поддерживается специализированным программным обеспечением.
URL, IP и DNS адреса, домены
Итак URL(Uniform Resource Locator) это полный путь документа . URL это адрес, по которому можно однозначно найти документ(файл) в сети Интернет. Та строка, которую Вы набираете в окошке "адрес" вышего браузера и есть URL адрес документа.
URL может иметь довольно сложный вид, и сотоять из различных частей. Для начала рассмотрим простейший URL:
Данный URL содержит три составляющие части : имя хоста, где находится документ, название протокола использующегося для передачи этого документа, и собственно название самого документа (имя файла плюс расширение). Основа (и единственная обязательная часть для протокола http) адреса - это имя хоста. Оно определяет ту машину на которой находится документ (в сети отдельные компьютеры именуются хостами). Каждый компьютер в сети является хостом, и имеет уникальное (в данной сети) имя. В приведенном примере rambler.ru это имя компьютера, на котором мы хотим найти документ.
Имена хостов могут задаваться двумя способами: с помощью DNS и с помощью IP адреса. IP адрес состоит из четырех чисел, разделенных точкой. Каждое число может быть в диапазоне от 0 до 255. Например 192.168.2.1 .
Однако на практике пользоваться IP адресами неудобно, поскольку числа трудны для запоминания. Поэтому была введна система доменных имен (Domain Name System - DNS), в которой каждому IP адресу ставится в соответствие какое либо имя, состоящее из букв или цифр. Так например в приведенном примере DNS имя было rambler.ru, и ему соответствует IP адрес 217.73.192.109 .
Следует отметить, что различным IP адресам всегда соответствуют различные DNS имена, но различным DNS именам могут соответствовать одинаковые IP адреса. Например такие различные DNS имена как www.rambler.ru и rambler.ru имеют один и тот же IP адрес. В URL адресах можно использовать как DNS имена, так и IP адреса. Таким образом два URL адреса http://rambler.ru/index.html и http://217.73.192.109/index.html эквивалентны. Некоторые способы задания IP адреса описаны здесь http://www.xakep.ru/post/11980/default.htm.
Заметим также, что в принципе, хост не обязан иметь доменное имя. То есть к некоторым хостам можно обратиться только по IP адресу.
Вы наверно уже обратили внимание на то, что любое DNS имя состоит из отдельных слов, разделенных точками. Каждое имя в отдельности обозначает домен к которому относится хост. Вся система DNS построена по иерархическому принципу. Все домены 1-го уровня (com,org,ru и т.д.) входят в корневой домен 0-го уровня (который обычно не пишется в DNS так как подразумевается по умолчанию). Домены второго уровня (например rambler,mail или kiev) входят в домены первого уровня и т.д. Домены в DNS записываются справа налево, в порядке увеличения уровня.
Отметим две важные особенности: 1. Домен является чисто административной единицей и не представляет собой хост. 2. IP адрес никак не зависит от домена в котором находится хост.
Таким образом система доменов введена просто для классификации сайтов по географическому или целевому признаку, и не имеет никакого отношения к физическому устройству интернета.
В привденном примере URL адреса, мы явно задавали имя интересуещего нас документа index.html, но на каждом сайте существует документ, открываемый по умолчанию. Он как правило имеет имя index.html или default.html и находится в корневой папке сайта. Если мы введем URL адрес сайта не указав при этом имя файла который нам нужен, то сервер автоматически откроет нам документ принятый по умолчанию. Таким образом адрес http://crackchat.h1.ru эквивалентен адресу http://crackchat.h1.ru/index.html. Точно так же как существует файл открываемый по умолчанию, то существует и папка принятая по умолчанию. В большинстве серверов, папка по умолчанию для HTTP документов имеет имя WWW.
После DNS в URL адресе следует имя документа к которому мы обращаемся. При этом подразумевается что этот файл находится в корневой папке. Если же это не так, то мы можем указать полный путь к документу, перечисляя вложенные папки через прямой слеш:
В данном примере мы обращаемся к файлу в папке cgi-bin/perl/ . Этот путь указан относительно корневой папки. Так, например, если путь к корневой папке f:/www, то в нашем примере мы обращаемся к файлу f:/www/cgi-bin/perl/search.pl . При этом важно учитывать следующее: поскольку большинство Web серверов построено на базе UNIX-подобных систем, то при указании пути к файлу нужно учитывать различие строчных и прописных букв. Так если бы мы обратились к файлу по URL http://rambler.ru/CGI-BIN/perl/Search.pl, то сервер бы такого файла не нашел. Различие больших и малых букв происходит только в пути к файлу, DNS же является регистронезависимым (то есть адрес rambler.ru и RAMBLER.RU эквивалентны).
Как уже отмечалось, DNS соответствует строго определнный IP адрес, но это не означает что DNS имя эквивалентно хосту, к которому мы обращаемся. Часто сам по себе хост имеет внутри себя домены более глубоких уровней. Так например сайт h1.ru является хостом в домене второго уровня, но сам содержит в себе домены третьего уровня, например crackchat.h1.ru или crosswords.h1.ru. Поэтому эти два сайта принадлежат одному хосту и имеют естественно одинаковый IP адрес! Физически, в данном случае, домены третьего уровня выглядят просто как папки на диске хоста h1.ru, и доступ к ним мог бы осуществляться например так: h1.ru/crackchat/ и h1.ru/crosswords/. Способ доступа (через домен 3-го уровня или через дисковый путь) определяется настройками сервера.
Корневая папка также считается доменом, и поэтому большинство URL адресов можно указывать в двух форматах: как с доменом www (например www.crackchat.h1.ru), так и без него (crackchat.h1.ru) - в таком случае сервер все равно автоматически направляет вас в папку www, поскольку она принята по умолчанию.
Протоколы, порты, CGI протокол
Как мы уже видели, URL адрес состоит из трех основных элементов: DNS имени, пути файла, и имени протокола. Если первых два элемента позволяют определить местонахождение документа, то протокол определяет способ доступа к документу. Иными словами, когда клиент пытается получить документ, то он должен указать серверу каким образом он (сервер) должен этот документ ему (клиенту) передать. Существует множество различных протоколов передачи данных в сети, среди них наиболее распространенные http(Hypertext Transfer Protocol - протокол передачи гипертекстовых файлов), ftp(File Transfer Protocol - протокол передачи файлов), mailto(префикс семейства почтовых протоколов), file (протокол доступа к файлам или папкам). Тип протокола определяет ту программу которая сможет обрабатывать данные в формате этого протокола. Так Internet Explorer может работать с протоколами http,file и ftp, но не может работать с протоколом mailto. Поэтому если вы наберете в вашем браузере, в строке адреса mailto:microsoft.com, то запустится специальная почтовая программа, которая может работать с данным протоколом (например Outlook Express или The Bat!). Имя протокола указывается самым первым в URL адресе и должно заканчиваться двоеточием. Регистр значения не имеет.
Среди протоколов встречаются очень причудливые например протокол res или about (для интереса можете набрать в адресной строке браузера такой адрес about:<a href="mailto:bill@microsoft.com">послать привет Биллу</a> и посмотреть что будет :). Другой интересный протокол ldap (попробуйте например ldap://microsoft.com ).
В качестве протокола для URL могут выступать не все протоколы. Так протоколы about или javascript не имеют никакого отношения к полному пути документа, и потому "адреса" с этими протоколами URL адресами не являются.
Префикс протокола указывает клиенту на каком "языке" будет происходить общение с сервером. И клиент заранее знает какая программа должна вести это общение, чего нельзя сказать о сервере. Для того что бы сервер начал "разговаривать" с нами на требуемом протокольном языке, он(сервер) должен запустить соответствующую программу, которая будет понимать этот протокол. Для решения этой задачи используют порты . Так если DNS имя или IP адрес определяют машину к которой мы обращаемся, то порт определяет программу к которой мы обращаемся на данном хосте. Порты обозначаются целым числом в диапазоне от 0 до 65535.
Каждому протоколу по умолчанию присвоен порт, по которому серверная программа будет ожидать запросы клиента. Так например, если сервер поддерживает http протокол, то соответствующая серверная программа (например Apache) будет ожидать запросы клиентов на порт 80(этот порт принят по умолчанию для http протокола). Если этот же хост поддерживает еще и ftp протокол, то другая серверная программа будет ожидать запросы на порт 21(этот порт зарезервирован для ftp протокола).
Порт к которому мы обращаемся определяется автоматически, в зависимости от того какой протокол мы выбрали в URL. Но порт можно указать и явно. Номер порта указывается через двоеточие после DNS имени или IP адреса:
В приведенном примере мы обращаемся к некой программе, "повешенной" на порт 8080, и просим у нее дать нам файл index.html по http протоколу. Если на сревере такой программы не окажется (то есть запросы на порт 8080 никакая программа не будет отслеживать), то браузер выдаст нам сообщение об ошибочном URL адресе.
Поскольку по умолчанию для серверов http принят порт 80 , то адрес http://rambler.ru:80 эквивалентен адресу http://rambler.ru. Хотя в принципе, хосты не обязаны поддерживать http именно на 80-м порту. Сервер может быть настроен например на порт 3128, и тогда для общения с этим хостом на http нужно постоянно явно указывать номер порта: http://rambler.ru:3128
При обращении к серверу иногда бывает нужно указать помимо адреса документа , еще и иднтификатор пользователя, который обращается к серверу (или к которому мы обращаемся на сервере), а также пароль доступа. URL позволяет передать такую информацию. Для этого перед DNS именем ставится знак @ перед которым указывается имя пользователя:
Как правило, для http протокола не требуется идентификация пользователя, но для таких протоколов как ftp или mailto она обязательна. Помимо имени пользователя, можно указать и пароль доступа. Пароль отделяется от имени двоеточием. Например: ftp://masha:kasha@yahoo.com. Этот URL адрес запрашивает по ftp протоколу корневую директорию хоста yahoo.com для пользователся masha с паролем kasha. А вот такой адрес mailto://masha@mail.ru используется для доступа к почтовому ящику пользователя masha в хосте mail.ru.
Имя пользоваетля также может быть постороено по доменному принципу, и состоять из различных частей, разделенных точкой. Например mailto://bill.geits@microsoft.com.
Как уже отмечалось, URL это полный путь документа. Под документом подразумевается любой файл, который может быть и текстом (например html или doc или pdf файлы), и картинкой (jpg или gif), и программой. При этом протокол http подразумевает что если в URL запрашивается текст или картинка, то их нужно передать пользователю с целью отображения их в его браузере, а если запрашивается программа или скрипт, то ее нужно запустить на сервере, и отправить пользователю результат ее работы. Сам результат может быть или текстом или картинкой. Тип результируещего документа определяется внутри самой программы, и пользователь заранее не знает какой тип документа он получит, вызывая программу. Вызов серверной программы осуществляется обычным URL адресом самой программы или скрипта. Как правило, в сети используют скрипты с расширениями .pl .php .cgi (первые два обозначают программы написанные на Perl и PHP , а последнее расширение может применятся для любых исполняемых модулей, в том числе и для Perl и PHP и EXE). Например URL адрес http://www.rambler.ru/cgi-bin/top.cgi требует запустить на хосте rambler.ru некое приложение top.cgi и передать клиенту результат работы этого приложения (например html документ или картинку).
Но от серверных приложений было бы мало толку если бы им нельзя было передавать параметры. URL это позволяет. Для передачи параметров серверным приложениям (их еще называют шлюзами ) используется формат передачи данных известный как CGI (Common Gateway Interface). Этот формат позволяет задавать входные данные программ в виде одной строки.
В приведенном примере видно, что URL вызывает некий серверный шлюз под названием search.pl и передает ему в качестве входных данных один параметр с именем user и заначением masha. CGI строка отделяется от имени скрипта знаком вопроса ?. Если скрипту необходимо передать несколько параметров, то они перечисляются последовательно через символ амперсанда &, например: http://rambler.ru/cgi-bin/perl/search.pl?user=masha&password=kasha.
Отметим следующую особенность: поскольку большинство WEB
технологий основываются на текстовых форматах данных, то рано или поздно
возникает проблема отличить команды от данных. Так например, если в
качестве параметра CGI мы захотим передать некий параметр
expression со значением C=A+B: http://site.com/script.cgi?expression=C=A+B то
такой запрос будет неправильно понят CGI поскольку второй знак =
будет восприниматься как разделитель между именем параметра и его
значением. Поэтому в CGI протоколе (как впрочем и в любом месте URL) применяется
специальная кодировка символов под названием URL Data
Format . Данная кодировка
отображает буквы латинского алфавита как они есть,
а остальные символы в виде %nn где nn - шестнадцатиричный код символа. Например символ
двойной кавычки " будет выглядеть как %22, а
символ = как %3D.
Исключение составляет символ пробела, который помимо стандартной кодировки
HTTP протокол
HTTP (Hypertext Transfer Protocol) - основной протокол используемый в Web. Несмотря на то что протокол называется протоколом передачи гипертекста (т.е. HTML), на самом деле HTTP протокол может использоваться (и используется) для передачи практически любых данных в сети. Это передача и текста и изображений и файлов. Популярность HTTP, на мой взгляд, связана с несколькими факторами: это использование достаточно универсальной URL адресации, способность передавать любые данные (как от клиента серверу так и наоборот), а также работа в режиме no-line (т.е. предача данных непосредственно между клиентом и сервером, без посредников). HTTP протокол можно назвать дуальным, в том смысле, что в системе клиент-сервер данные могут идти в двух направлениях, и от клиента к серверу и наоборот от сервера к клиенту. Однако сам синтаксис HTTP нацелен именно на передачу данных от клиента к серверу.
Итак рассмотрим простейший пример HTTP запроса. Если в адресном окошке браузера мы наберем адрес http://yandex.ru, то браузер определит IP адрес сервера yandex.ru и пошлет ему на 80-й порт такой HTTP запрос:
GET http://yandex.ru/
HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint,
*/*
Accept-Language: ru
Cookie:
yandexuid=2464977781018373381
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5;
Windows 98)
Host: yandex.ru
Referer: narod.ru
Proxy-Connection: Keep-Alive
Запрос передается в незашифрованном текстовом виде. Самая главная часть запроса расположена в первой строке: Это тип запроса (GET), URL адрес запрашиваемого документа(http://yandex.ru) и версия HTTP протокола (HTTP/1.0). Далее перечисляются параметры запроса. Каждая строка соответствует одному параметру. В начале строки идет имя параметра, затем двоеточие и значение параметра. Смысл парметров интуитивно ясен, однако опишем основные из них: Accept - тип данных, которые может принять браузер (в кодировке MIME). Accept-Language - предпочтительный язык, на котором браузер хочет принять данные. User-Agent - тип программы, которая отослала запрос. Host - DNS(или IP) имя хоста к которому адресован запрос. Cookie - кукисы (данные, которые были сохранены сервером на локальном диске клиента, при посещении данного хоста прошлый раз). Referer - хост, со странички которго мы отсылаем запрос. Так например если мы находимся на странице http://narod.ru, и нажимаем там ссылку http://yandex.ru, то запрос будут отправлен хосту yandex.ru, а поле запроса referer будет содержать имя хоста narod.ru.
Набор параметров запроса не фиксирован. Помимо приведенных, могут присутствовать и другие параметры.
Наиболее интересны такие парметры как referer и cookie. Эти параметры используются в основном для идентификации пользователя сервером.
Запрос GET может содержать данные, передаваемые клиентом серверу. они передаются непосредственно через URL адрес по CGI протоколу. Так например для входа в чат браузер может передавать серверу следующий запрос:
GET http://chat.ru/?login=Algol&pass=Algol
HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint,
*/*
Accept-Language: ru
Cookie:
yandexuid=2464977781018373381
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5;
Windows 98)
Host: yandex.ru
Referer: narod.ru
Proxy-Connection:
Keep-Alive
Кака мы видим строка запроса содержит логин и пароль пользователя, переданые через строку URL. Такой тип передачи данных серверу удобен, однако имеет ограничения на объем. Слишком большие массивы данных передавать через URL нельзя. Для таких целей существует другой тип зпросов: запрос POST. Запрос POST очень похож на GET, с той лишь разницей что данные в запросе POST передаются отдельно от самого собственно заголовка запроса. Так приведенный выше пример в варианте POST имеет вид:
POST http://chat.ru/
HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint,
*/*
Accept-Language: ru
Cookie:
yandexuid=2464977781018373381
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5;
Windows 98)
Host: yandex.ru
Referer: narod.ru
Proxy-Connection:
Keep-Alive
login=Algol&pass=Algol
Как мы видим данные о логине и пароле передаются отдельно в теле запроса. Тело запроса должно отделяться от заголовка пустой строкой. Если сервер встречает пустую строку в POST запросе, то все что идет далее он считает телом запроса (передаваемыми данными). Отметим следующее: формат даных в теле POST запроса произволен. Несмотря на то, что чаще всего применяется CGI формат, он не обязателен. Кроме того POST запрос не требует наличия тела запроса, и может передавать данные также и через URL.
Помимо CGI формата, иногда для передачи больших объемов информации (например файлов) применяют т.н. multipart формат:
POST http://photo.bigmir.net/form.php
HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint,
*/*
Referer: http://photo.bigmir.net/form.php
Accept-Language:
ru
Content-Type: multipart/form-data;
boundary=---------------------------7d20345dc
Accept-Encoding: gzip,
deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)
Host:
photo.bigmir.net
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cookie:
Ukrainian=2; BSX_TestCookie=Yes; rich_ad=1; b=1
-----------------------------7d20345dc
Content-Disposition:
form-data; name="id"
254353
-----------------------------7d20345dc
Content-Disposition:
form-data; name="d"
22
-----------------------------7d20345dc
Content-Disposition:
form-data; name="login"
Algol
-----------------------------7d20345dc
Content-Disposition:
form-data; name="passw"
Algol
-----------------------------7d20345dc
Content-Disposition:
form-data; name="email"
tps99@mail.ru
-----------------------------7d20345dc
Content-Disposition:
form-data; name="submit"
Добавить
-----------------------------7d20345dc--
Обратим внимание на строку заголовка Content-Type: multipart/form-data; boundary=---------------------------7d20345dc. Этот параметр говорит серверу о том, что клиент передает данные в формате multipart c ограничителем ---------------------------7d20345dc. Ограничитель генерируется клиентом случайным образом и необходим для того, что бы серевер мог отделить разные части посылаемые в теле запроса. Как видно, тело содержит несколько частей, которые передаются в формате ASCII (а не в Unicode как необходимо для CGI) и разделены той строкой, которая была указана в парметре Content-Type. Каждая часть содержит информацию о типе передаваемых данных и имя данной части. Удобство формата multipart в том что передаваемые данные имеют неограниченную величину и не требуют предварительного кодирования.
Помимо запросов GET и POST существуют и другие, например TRACE, PUT. Но они используются редко, и я не буду на них останавливаться.
Еще раз обращу внимание на то, что ВСЯ информация передаваемая клиентом серверу содержится в заголовке и теле запроса. Другим способом сервер не может получить информацию от клиента по HTTP протоколу.
С другой стороны и сервер может передать клиенту иформацию только в ответ на запрос. Любой обмен даными в HTTP протоколе инициируется только клиентом, сервер не может передать ничего "просто так" а только по запросу клиента.
Таким образом, если мы имеем возможность контроллировать передаваемые запросы, то мы полностью контроллируем получаемую сервером и клиентом информацию. Это удобно, так как для модификации передаваемых/запрашиваемых данных не требуется менять файлы HTML страниц, измененять файлы cookies и т.д., достаточно лишь произвести изменения в HTTP запросе и отправить его серверу. Впрочем это уже другая история :) ...
Algol
P.S. Для отлавливания HTTP заголовков отсылаемых на сервер рекомендую утитлитку Naviscope. Для изменения и отправки запросов на сервер могу предложить собственную разработку под названием InetCrack.
(C) Algol, 2002. All rights reserved.
Внимание: текст который вы видите был скачен с другого сайта.. Вся информация что здесь есть выложена только в образовательных целях..
