|
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 запросе также отправить его серверу. Впрочем это уже другая летопись :) ...
Дата створення/оновлення: 25.05.2018