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 - протокол передачі Text 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:[email protected]"> послати привіт Біллу </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: [email protected]. Цей URL адреса запитує по ftp протоколу кореневу директорію хоста yahoo.com для користувачів masha з паролем kasha. А ось таку адресу mailto: //[email protected] використовується для доступу до поштової скриньки користувача masha в хості mail.ru.
Ім'я пользоваетля схоже може існувати збудують по доменному принципом, також складатися з різних елементів, між якими ставиться крапка. Наприклад mailto: //[email protected].
Як уже зазначалося, 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"
[email protected]
----------------------------- 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 запиті також відправити його серверу. Втім це вже інша літопис ...
Коментарі
Коментуючи, пам'ятайте про те, що зміст і тон Вашого повідомлення можуть зачіпати почуття реальних людей, проявляйте повагу та толерантність до своїх співрозмовників навіть у тому випадку, якщо Ви не поділяєте їхню думку, Ваша поведінка за умов свободи висловлювань та анонімності, наданих інтернетом, змінює не тільки віртуальний, але й реальний світ. Всі коменти приховані з індексу, спам контролюється.