HTTP протокол - Канали передачі даних

URL
URI
URN
структура URL
протокол
авторизація
Адреса ресурсу
Шлях до ресурсу
параметри
якір
символи
Формати повідомлень запиту / відповіді
Стартовий рядок запиту
методи
метод GET
заголовки HTTP
Основні заголовки
заголовки запиту
заголовки відповіді
заголовки суті
нестандартні заголовки
Cookie
Приклад HTTP в браузері
Приклад HTTP в консолі (telnet)
Приклад HTTP в firebug
резюме
переваги

Наша взаимовыгодная связь https://banwar.org/

Протокол HTTP це основа Інтернету, через нього передається більша частина веб трафіку. Спочатку створювався для передачі гіпертекстових документів в форматі HTML, але зараз використовується для передачі будь-яких даних.

HTTP є протоколом передачі даних 4го (прикладного) рівня стека протоколів TCP / IP. Так само може виступати в ролі транспорту для інших протоколів прикладного рівня, наприклад: SOAP, XML-RPC, JSON-RPC, WebDAV. Актуальна на даний момент версія протоколу, HTTP 1.1, описана в специфікації RFC 2616 .

HTTP запит і відповідь

Основне завдання протоколу це забезпечення спілкування між безліччю веб-серверів і клієнтів. Спілкування між веб-сервером і клієнтом відбувається в два етапи: запит і відповідь. Клієнт відправляє HTTP запит на сервер, у відповідь на який отримує дані. Ініціалізатор з'єднання завжди є клієнт. Односпрямованість протоколу не дозволяє серверу посилати запити клієнтам (тільки відповідати на запити).

Кожен HTTP запит на веб-сервер не залежить від попередніх запитів, така поведінка називається - не зберігає стан . Відсутність стану робить HTTP простішим протоколом, але в разі коли це необхідно вимагає додаткових технологій, таких як Cookie.

Протокол HTTP дозволяє вказати спосіб представлення (кодування) одного і того ж ресурсу за різними параметрами: mime-типу, мови і т. Д. Завдяки цій можливості клієнт і веб-сервер можуть обмінюватися двійковими даними, хоча даний протокол є текстовим.

URL

URL (Uniform Resource Locator) - уніфікований покажчик на ресурс.

Основним об'єктом маніпуляції в HTTP є ресурс, на який вказує URL в запиті клієнта. Список всіх доступних ресурсів сайту утворюють дерево, в якому кожна гілка буде адресою URL.

Дерево доступних ресурсів сайту

Ресурси являють собою або реальні файли на сервері, наприклад: HTML, js, png, ..., або логічні суті, які генерують вміст на льоту (в момент надходження запиту), наприклад: список новин, погода, фотогалерея, каталог товарів та інше. Відповідно такі ресурси називають статичними (незмінними) або динамічними.

Ще існують абстрактні ресурси, які присутні в дорозі але цю адресу самостійно не існує, наприклад:

http://example.com/ - головна сторінка сайту
http://example.com/blog/ - список статей
http://example.com/blog/article/1 - стаття 1 в блозі
http://example.com/blog/article/ - абстрактний ресурс, який присутній в дорозі, але реально його не існує. За цим посиланням сервер поверне помилку 404 Not Found. Такі ресурси потрібні для більшої читабельності URL і семантичного поділу сутностей.

URI

URL є підмножиною ширшого терміна URI (Uniform Resource Identifier), який узагальнює вид різних ідентифікаторів.

Приклади URI:

ldap: // [2001: db8 :: 7] / c = GB? objectClass? one mailto: [email protected] news: comp.infosystems.www.servers.unix tel: + 1-816-555-1212 telnet: //192.0.2.16: 80 / ftp://ftp.is.co.za/rfc/rfc1808.txt http://www.ietf.org/rfc/rfc2396.txt urn: oasis: names: specification: docbook: dtd: xml: 4.1.2

URN

URN (Uniform Resource Name) - ідентифікує шлях до ресурсу.

приклад:

Ідентифікатор ресурсу можна представити у вигляді формули:

URI = URL + URN

Примітка

У суспільстві URI часто назвают як URL.

структура URL

Структура URL представлена на схемі нижче:

foo: //example.com: 8042 / over / there? name = ferret # nose \ _ / \ ______________ / \ _________ / \ _________ / \ __ / | | | | | схема ім'я (IP) і порт шлях запит елемент | _____________________ | __ / \ / \ urn: example: animal: ferret: nose

протокол

<схема>: // <логін>: <пароль> @ <хост>: <порт> / <URN - шлях>? <параметри> # <якір>

ws
ftp
http
https
file
mailto
xmpp

авторизація

<схема>: // <логін>: <пароль> @ <хост>: <порт> / <URN - шлях>? <параметри> # <якір>

Адреса ресурсу

<схема>: // <логін>: <пароль> @ <хост>: <порт> / <URN - шлях>? <параметри> # <якір>

localhost: 8080
yandex.ru
213.180.204.11
127.0.0.1:6543
yandex.ru:80
192.168.0.13:22

Пара <хост>: <порт> називається INET SOCKET або просто сокет, визначає вхідну точку прикладання і ідентифікує адресу за якою з ним можна зв'язатися.

HTTP за замовчуванням використовує порт 80, це знають веб-сервера, тому його можна не вказувати.

Шлях до ресурсу

<схема>: // <логін>: <пароль> @ <хост>: <порт> / <URN - шлях>? <параметри> # <якір>

параметри

<Схема>: // <логін>: <пароль> @ <хост>: <порт> / <URN - шлях>? <параметри> # <якір>

text = foobar & from = fx3 & lr = 213

якір

<схема>: // <логін>: <пароль> @ <хост>: <порт> / <URN - шлях>? <параметри> # <якір>

Якір вказує на розташування в самому документі. приклад якоря http://lectureskpd.readthedocs.io/kpd/3.http.html#id10

символи

Латинські літери
цифри
Спеціальні символи $ -_. +! * "(),
Зарезервовані символи; /? : @ = &

символ; можна використовувати замість &

Формати повідомлень запиту / відповіді

На наступному зображенні ви можете побачити схематично оформлений процес відправлення запиту клієнтом, обробка та відправка відповіді сервером.

HTTP запит і відповідь

Давайте подивимося на структуру переданого повідомлення через HTTP:

message = <Стартовий рядок> * (<Заголовки>) CRLF [<Тіло повідомлення>]

або

<Метод> <URI> HTTP / 1.1 <Заголовки> Referer: http://www.yandex.ru/ </ Заголовки> <Тіло повідомлення> param = value & a = 1 & b = 2 & c = 3 </ Тіло повідомлення>

Між заголовком і тілом повідомлення повинна обов'язково бути присутнім порожній рядок. Заголовків може бути кілька.

Приклад запиту:

GET /ru/latest/net/http.html HTTP / 1.1 Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8 Accept-Language: en-US, en ; q = 0.5 Connection: keep-alive Host: lectureswww.readthedocs.org User-Agent: Mozilla / 5.0 (X11; Ubuntu; Linux x86_64; rv: 35.0) Gecko / 20100101 Firefox / 35.0

відповідь:

Стартовий рядок запиту

для HTTP / 0.9

для HTTP / 1.0-1.1

<Метод> <URI> HTTP / <версія>

методи

За допомогою URL, ми визначаємо точну назву хоста, з яким хочемо спілкуватися, проте яку дію нам потрібно зробити, можна повідомити тільки за допомогою HTTP методу. Звичайно ж існує кілька видів дій, які ми можемо зробити. У HTTP реалізовані найпотрібніші, які підходять під потреби більшості додатків.

Існуючі методи:

GET: отримати доступ до існуючого ресурсу. В URL перерахована вся необхідна інформація, щоб сервер зміг знайти і повернути в якості відповіді шуканий ресурс.

POST: використовується для створення нового ресурсу. POST запит зазвичай містить в собі всю потрібну інформацію для створення нового ресурсу.

PUT: оновити поточний ресурс. PUT запит містить оновлювані дані.

DELETE: служить для видалення існуючого ресурсу.

Дані методи найпопулярніші і найчастіше використовуються різними інструментами і фреймворкамі. У деяких випадках, PUT і DELETE запити відправляються за допомогою відправки POST, в змісті якого зазначено дію, яку потрібно зробити з ресурсом: створити, оновити або видалити.

Також HTTP підтримує і інші методи:

HEAD: аналогічний GET. Різниця в тому, що при даному виді запиту не передається повідомлення. Сервер отримує тільки заголовки. Використовується, наприклад, для того щоб визначити, чи був змінений ресурс.

TRACE: під час передачі запит проходить через безліч точок доступу і проксі серверів, кожен з яких вносить свою інформацію: IP, DNS. За допомогою даного методу, можна побачити всю проміжну інформацію.

OPTIONS: використовується для визначення можливостей сервера, його параметрів і конфігурації для конкретного ресурсу.

Примітка

POST vs GET

Визначити, який спосіб слід застосовувати, дуже просто. Якщо форма служить для запиту якоїсь інформації, наприклад - при пошуку, то її слід відправляти методом GET. Щоб можна було оновлювати сторінку, можна було поставити закладку і чи послати посилання одному. Якщо ж в результаті відправки форми дані записуються або змінюються на сервері, то слід їх відправляти методом POST, причому обов'язково після обробки форми треба перенаправити браузер методом GET. Так само, POST може знадобитися, якщо на сервер треба передати великий обсяг даних (у GET він сильно обмежений), а так само, якщо не слід «світити» передані дані в адресному рядку (при введенні логіна і пароля, наприклад).

В CGI скриптах

GET зазвичай передає в програму рядок, через змінну оточення.
POST передає дані через стандартний потік введення (stdin)

метод GET

GET /index.php?param=value&a=1&b=2&c=3 HTTP / 1.1 <Заголовки>

метод POST

POST /index.php HTTP / 1.1 <Заголовки> <Тіло повідомлення> param = value & a = 1 & b = 2 & c = 3 </ Тіло повідомлення>

Стартовий рядок відповіді

HTTP / <версія> <код стану> <пояснення>

коди станів

У відповідь на запит від клієнта, сервер відправляє відповідь, який містить, в тому числі, і код стану. Даний код несе в собі особливий сенс для того, щоб клієнт міг виразніше зрозуміти, як інтерпретувати відповідь:

1xx: Інформаційні повідомлення

Набір цих кодів був введений в HTTP / 1.1. Сервер може відправити запит виду: Expect: 100-continue, що означає, що клієнт ще відправляє частину запиту. Клієнти, що працюють з HTTP / 1.0 ігнорують дані заголовки.

2xx: Повідомлення про успіх

Якщо клієнт отримав код з серії 2xx, то запит пішов успішно. Найпоширеніший варіант - це 200 OK. При GET запиті, сервер відправляє відповідь в тексті листа. Також існують і інші можливі відповіді:

202 Accepted: запит прийнятий, але може не містити ресурс у відповіді. Це корисно для асинхронних запитів на стороні сервера. Сервер визначає, відправити ресурс чи ні.
204 No Content: в тілі відповіді немає повідомлення.
205 Reset Content: вказівка серверу про скиданні уявлення документа.
206 Partial Content: відповідь містить тільки частину контенту. У додаткових заголовках визначається загальна довжина контенту і інша інфа.

3xx: Перенаправлення

Своєрідне повідомлення клієнту про необхідність зробити ще одну дію. Найпоширеніший варіант застосування: перенаправити клієнт на іншу адресу.

301 Moved Permanently: ресурс тепер можна знайти по іншому URL адресою.
303 See Other: ресурс тимчасово можна знайти по іншому URL адресою. Заголовок Location містить тимчасовий URL.
304 Not Modified: сервер визначає, що ресурс не був змінений і клієнтові потрібно задіяти закешовану версію відповіді. Для перевірки ідентичності інформації використовується ETag (хеш Сутності - Enttity Tag);

4xx: Клієнтські помилки

Даний клас повідомлень використовується сервером, якщо він вирішив, що запит був відправлений з помилкою. Найбільш поширений код: 404 Not Found. Це означає, що ресурс не знайдений на сервері. Інші можливі коди:

400 Bad Request: питання було сформовано невірно.
401 Unauthorized: для здійснення запиту потрібна аутентифікація. Інформація передається через заголовок Authorization.
403 Forbidden: сервер не відкрив доступ до ресурсу.
405 Method Not Allowed: невірний HTTP метод був задіяний для того, щоб отримати доступ до ресурсу.
409 Conflict: сервер не може до кінця обробити запит, тому що намагається змінити новішу версію ресурсу. Це часто відбувається при PUT запитах.

5xx: Помилки сервера

Ряд кодів, які використовуються для визначення помилки сервера при обробці запиту. Найпоширеніший: 500 Internal Server Error. Інші варіанти:

501 Not Implemented: сервер не підтримує запитувану функціональність.
503 Service Unavailable: це може статися, якщо на сервері сталася помилка або він перевантажений. Зазвичай в цьому випадку, сервер не відповідає, а час, дане на відповідь, закінчується.

заголовки HTTP

Між заголовком і тілом повідомлення повинна обов'язково бути присутнім порожній рядок.

Заголовків може бути кілька.

Всі необхідні для функціонування HTTP заголовки описані в основних RFC документах. Якщо не вистачає існуючих, то можна вводити свої. Традиційно до імен таких додаткових заголовків додають префікс «X-» для уникнення конфлікту імен з можливо існуючими. Наприклад, як в заголовках X-Powered-By або X-Cache. Деякі розробники використовують свої індивідуальні префікси. Прикладами таких заголовків можуть служити Ms-Echo-Request і Ms-Echo-Reply, введені корпорацією Microsoft для розширення WebDAV.

приклад:

Основні заголовки

заголовки відповіді

заголовки суті

HTTP / 1.1 200 OK

Date: Mon, 17 Sep 2012 13:05:11 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache, no-store, max-age = 0, must-revalidate

Server: nginx
Vary: X-Real-SSL-Protocol

Content-Type: text / html; charset = UTF-8
Expires: Mon, 17 Sep 2012 13:05:11 GMT
Content-Encoding: gzip

Основні заголовки

General Headers ( «Основні заголовки») - повинні включатися в будь-яке повідомлення клієнта і сервера. Велика частина з них є обов'язковими.

Cache-Control Connection Date Pragma Trailer Transfer-Encoding Upgrade Via Warning

Тема Via використовується в запиті типу TRACE, і оновлюється усіма проксі-серверами.

Тема Pragma використовується для перерахування власних заголовків. Наприклад, Pragma: no-cache - це те ж саме, що Cache-Control: no-cache. Детальніше про це поговоримо в другій частині.

Тема Date використовується для зберігання дати та часу запиту / відповіді.

Тема Upgrade використовується для зміни протоколу.

Transfer-Encoding призначається для поділу відповіді на кілька фрагментів за допомогою Transfer-Encoding: chunked. Це нововведення версії HTTP / 1.1.

заголовки запиту

Request Headers ( «Заголовки запиту») - використовуються тільки в запитах клієнта.

Accept Accept-Charset Accept-Encoding Accept-Language Authorization Expect From Host If-Match If-Modified-Since If-None-Match If-Range If-Unmodified-Since Max-Forwards Proxy-Authorization Range Referer TE User-Agent

заголовки відповіді

Response Headers ( «Заголовки відповіді») - тільки для відповідей від сервера.

Accept-Ranges Age ETag Location Proxy-Authenticate Retry-After Server Vary WWW-Authenticate

заголовки суті

Allow Content-Encoding Content-Language Content-Length Content-Location Content-MD5 Content-Range Content-Type Expires Last-Modified

Entity Headers ( «Заголовки суті») - У заголовках сутностей передається мета-інформація контенту.

Всі заголовки з префіксом Content- надають інформацію про структуру, кодуванні і розмірі тіла повідомлення.

Тема Expires містить час і дату закінчення суті. Значення "never expires" означає час + 1 код з поточного моменту. Last-Modified містить час і дату останньої зміни сутності.

нестандартні заголовки

X-Frame-Options

X-Frame-Options: DENY; // заборонить завантаження через <iframe> X-Frame-Options: SAMEORIGIN; // дозволить завантаження через <iframe> але тільки якщо і <iframe>, і сторінка, його завантажують, знаходяться на одному домені

X-Requested-With

X-Requested-With: XMLHttpRequest // використовується для ідентифікації ajax запитів

пасхалка

// використовуються щоб пожартувати =) X-Awesome: If you found this header please email us about a writing job X-Konkurentam: Preved X-ServerNickName: Wolverine

Cookie

«Чарівне печиво» (magic cookie) - це невеликий набір даних, що передаються однією програмою іншій програмі. Вміст куки, як правило, не значимо для одержувача і не інтерпретується до тих пір, поки одержувач не поверне куки назад відправнику або іншій програмі.

У реальному житті куки можна порівняти з номерком в гардеробі: номерок не має власної цінності, але він дозволяє отримати взамін правильне пальто.

Кукі можуть використовуватися для ідентифікації в комп'ютерних додатках. Наприклад, при відвідуванні веб-сайту серверний додаток може залишити на комп'ютері відвідувача HTTP-куки для аутентифікації клієнта при його поверненні на сайт. Кукі є компонентом найбільш загального методу аутентифікації, що використовується в X Window System.

Деякі куки (наприклад, в протоколі HTTP) можуть мати цифровий підпис або можуть бути зашифровані, щоб зловмисники не могли підробити і передати їх відправнику для отримання несанкціонованого доступу.

Приклад HTTP в браузері

Відкриваємо браузер і пишемо адресу веб ресурсу (URI)

Стартове вікно браузера

Браузер генерує рядок запиту і відправляє його на сервер

GET /ru/latest/net/http.html HTTP / 1.1 Accept: text / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8 Accept-Encoding: gzip, deflate Accept- Language: en-US, en; q = 0.5 Connection: keep-alive Host: lectureswww.readthedocs.org User-Agent: Mozilla / 5.0 (X11; Ubuntu; Linux x86_64; rv: 35.0) Gecko / 20100101 Firefox / 35.0

HTTP запит

Сервер отримує текст запиту, обробляє його, формує відповідь на повідомлення та відправляє його клієнту.

HTTP / 1.1 200 OK Server: nginx / 1.4.6 (Ubuntu) Date: Mon, 26 Jan 2015 16:54:33 GMT Content-Type: text / html Content-Length: 48059 Last-Modified: Mon, 26 Jan 2015 16 : 22: 21 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "54c669bd-bbbb" X-Served: Nginx X-Subdomain-TryFiles: True X-Deity: hydra-lts Accept-Ranges: bytes <! DOCTYPE html > <! - [if IE 8]> <html class = "no-js lt-ie9" lang = "en"> <! [endif] -> <! - [if gt IE 8]> <! -> <html class = "no-js" lang = "en"> <! - <! [endif] -> <head> <meta charset = "utf-8"> <meta name = "viewport" content = "width = device-width, initial-scale = 1.0"> <title> Протокол HTTP & mdash; Документація Основи Веб-програмування 0.0.0 </ title> <link href = 'https://fonts.googleapis.com/css?family=Lato:400,700,400italic,700italic|Roboto+Slab:400,700|Inconsolata:400,700' rel = 'stylesheet' type = 'text / css'> <link rel = "stylesheet" href = "https://media.readthedocs.org/css/sphinx_rtd_theme.css" type = "text / css" /> <link rel = "stylesheet" href = "https://media.readthedocs.org/css/readthedocs-doc-embed.css" type = "text / css" /> <link rel = "top" title = "Документація Основи Веб-програмування 0.0.0 "href =" ../index.html "/> <link rel =" up "title =" Канали передачі даних "href =" index.html "/> <link rel =" next "title =" Мережеве програмування "href =" ../www.sync/codding.net.html "/> <link rel =" prev "title =" Мережі "href =" net.html "/> <! - RTD Extra Head - > <! - Read the Docs is acting as the canonical URL for your project. If you want to change it, more info is available in our docs: http://docs.readthedocs.org/en/latest/canonical.html -> <link rel = "canonical" href = "http: // lectureswww .readthedocs.org / ru / latest / net / http.html "/> <script type =" text / javascript "> .... </ script> </ body> </ html>

HTTP відповідь

Приклад HTTP в консолі (telnet)

У цьому прикладі зробимо все те ж саме, що і в попередньому. Тільки відправляти HTTP запит будемо за допомогою утиліти telnet .

$ Telnet readthedocs.org 80 Спроба 162.209.114.75 ... Підключено до readthedocs.org. Символ уникнення - '^]'. GET /ru/latest/net/http.html HTTP / 1.1 Прийняти: text / html, application / xhtml + xml, application / xml; q = 0,9, * / *; q = 0.8 Прийняти-Мова: en-US, en; q = 0.5 Підключення: keep-alive Ведучий: лекціїwww.readthedocs.org User-Agent: Mozilla / 5.0 (X11; Ubuntu; Linux x86_64; rv: 35.0) Gecko / 20100101 Firefox / 35.0 HTTP / 1.1 200 OK Сервер: nginx / 1.4 .6 (Ubuntu) Дата: Mon, 26 Jan 2015 16:54:33 GMT Content-Type: text / html Зміст-довжина: 48059 Останні зміни: Mon, 26 Jan 2015 16:22:21 GMT Зв'язок: keep- alive Вари: Accept-Encoding ETag: "54c669bd-bbbb" X-Served: Nginx X-субдомен-TryFiles: Правда X-божество: hydra-lts Прийняти-діапазони: байти <! DOCTYPE html> <! - [якщо IE 8]> <html class = "no-js lt-ie9" lang = "en"> <! [endif] -> <! - [якщо gt IE 8]> <! -> <html class = "no -js" lang = "en"> <! - <! [endif] -> <head> <meta charset = "utf-8"> <meta name = "viewport" content = "ширина = ширина пристрою, initial-scale = 1.0"> <title> Протокол HTTP & mdash; Документація Основи Веб-програмування 0.0.0 </ title> <link href = 'https://fonts.googleapis.com/css?family=Lato:400,700,400italic,700italic|Roboto+Slab:400,700|Inconsolata:400,700' rel = 'stylesheet' type = 'text / css'> <link rel = "stylesheet" href = "https://media.readthedocs.org/css/sphinx_rtd_theme.css" type = "text / css" /> <link rel = "stylesheet" href = "https://media.readthedocs.org/css/readthedocs-doc-embed.css" type = "text / css" /> <link rel = "top" title = "Документація Основи Веб-програми 0.0.0 "href =" ../index.html "/> <link rel =" up "title =" Каналі передачі даних "href =" index.html "/> <link rel =" next "title =" Мережеве програмування "href =" ../www.sync/codding.net.html "/> <link rel =" prev "title =" Мережі "href =" net.html "/> <! - RTD Extra Head -> <! - Читати Документи діє як канонічна URL для вашого проекту. Якщо ви хочете змінити його, більше інформації можна знайти в наших документах: http://docs.readthedocs.org/en/latest/canonical.html -> <link rel = "canonical" href = "http: // lectureswww .readthedocs.org/ ru / latest / net / http.html "/> <script type =" text / javascript "> .... </ script> </ body> </ html> З'єднання закрито зовнішнім хостом.

Для HTTPS протокола існують утиліти openssl і гнатлс :

$ openssl s_client -connect www.github.com:443 CONNECTED (00000003) глибина = 2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Висока гарантія EV Коренева CA перевірка повернення: 1 глибина = 1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Розширений сервер перевірки CA підтвердження повернення: 1 глибина = 0 businessCategory = Приватна організація, юрисдикціяC = US, юрисдикціяST = Делавер, serialNumber = 5157550 street = "88 Colin P Kelly, Jr Street", PostalCode = 94107, C = США, ST = Каліфорнія, L = Сан-Франциско, O = "GitHub, Inc." , CN = github.com перевірити повернення: 1 --- ланцюг сертифікатів 0 s: / businessCategory = Приватна організація / юрисдикціяC = США / юрисдикціяST = Delaware / serialNumber = 5157550 / street = 88 Colin P Kelly, Jr Street / postalCode = 94107 / C = US / ST = California / L = Сан-Франциско / O = GitHub, Inc./CN = github.com i: / C = США / O = DigiCert Inc / OU = www.digicert.com / CN = DigiCert SHA2 Extended Сервер перевірки CA 1 s: / C = US / O = DigiCert Inc / OU = www.digicert.com / CN = DigiCert Сервер розширеної перевірки SHA2 CA i: / C = US / O = DigiCert Inc / OU = www.digicert. кому / CN = DigiCert Висока гарантія Е.В. кореневого центру сертифікації --- сертифікат сервера ----- ----- BEGIN CERTIFICATE MIIHeTCCBmGgAwIBAgIQC / 20CQrXteZAwwsWyVKaJzANBgkqhkiG9w0BAQsFADB1 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MDMxMDAwMDAwMFoXDTE4MDUxNzEy FrBHTFxqIP6kDnxiLElBrZngtY07ietaYZVLQN / ETyqLQftsf8TecwTklbjvm8NT JqbaIVifYwqwNN + 4lRxS3F5lNlA / il12IOgbRioLI62o8G0DaEUQgHN f8vSG ----- END СЕРТИФІКАТ ----- тема = / businessCategory = Приватна організація / юрисдикціяC = США / юрисдикціяST = Delaware / serialNumber = 5157550 / street = 88 Colin P Kelly, Jr Street / PostalCode = 94107 / C = США / ST = California / L = Сан-Франциско / O = GitHub, Inc./CN = github.com issuer = / C = США / O = DigiCert Inc / OU = www.digicert.com / CN = DigiCert SHA2 Розширений сервер перевірки CA --- Сертифікат клієнта відсутній CA ім'я відправлено Дайджест підпису: SHA512 Ключ Temp сервера: ECDH, P-256, 256 біт --- Сценарій SSL прочитав 3642 байт і написав 431 байт --- Новий, TLSv1 / SSLv3, Cipher ECDHE-RSA-AES128-GCM-SHA256 Відкритий ключ сервера 2048 біт Безпечне відновлення підтримується IS Підтримка: NONE Розширення: NONE Ні ALPN переговори SSL-сесія: Протокол: TLSv1.2 Шифр: ECDHE-RSA-AES128-GCM-SHA256 Сесія ID: 5C279816840984C46727CE47615397799B95838DDEC30066F78377A ID-ctx сесії: Master-Key: B4674BDA91A35C85D235F04026FDEAFA43FE312FCE27900E4110B8C1F Key-Arg: Немає ідентифікатора PSK: немає Ім'я користувача SRP: Немає Початок: 1458670134 Тайм-аут: 300 (сек) Перевірте код повернення: 0 (ok) --- GET / HTTP / 1.1 Хост: github.com HTTP / 1.1 200 OK Сервер: GitHub.com Дата: Вт, 22 Mar 2016 18: 09: 07 GMT Тип вмісту: text / html; charset = utf-8 Передача-кодування: chunked Статус: 200 OK Кеш-кеш: no-cache Варіант: X-PJAX X-UA-сумісний: IE = Край, chrome = 1 Set-Cookie: logged_in = no; domain = .github.com; path = /; expires = Sat, 22 Mar 2036 18: 09: 07 -0000; безпечний; HttpOnly Set-Cookie: _gh_sess = eyJzZXNzaW9uX2lkIjoiMjI1YjkyOWIxYTUxMjIzZGE1ZTk2MmI2Yjg0YTQ2YjQiLCJfY3NyZl90b2tlbiI6Inc2R0x0MW1MK3hvUHFFYlhzczZYNCtoTUtwTmVUTnlvTFE5UCtZUU5yWk09In0% 3D - ae9efc5ffb8c6238d4cf0b08fb1516500fdee201; path = /; безпечний; HttpOnly X-Request-Id: 7c453b185f653a7bd0af24df209ee2b4 Час виконання: 0 .009394 Content-Security-Policy: default-src 'none'; base-uri 'self'; блок-все-змішаний зміст; child-src render.githubusercontent.com; connect-src 'self' uploads.github.com status.github.com api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com wss: //live.github.com; font-src assets-cdn.github.com; форма-дія 'self' github.com gist.github.com; кадри-предки 'none'; frame-src render.githubusercontent.com; img-src 'self' дані: assets-cdn.github.com identicons.github.com www.google-analytics.com * .ghtubusercontent.com * .gravatar.com * .wp.com * .githubusercontent.com; media-src 'none'; object-src assets-cdn.github.com; plugin-types application / x-shockwave-flash; script-src assets-cdn.github.com; style-src 'unsafe-inline' assets-cdn.github.com Строгий транспорт-безпека: max-age = 31536000; includeSubdomains; preload Public-Key-Pins: max-age = 300; pin-sha256 = "WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18 ="; pin-sha256 = "RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn / yOhI / y + ho ="; pin-sha256 = "k2v657xBsOVe1PQRwOsHsw3bsGT2VzIqz5K + 59sNQws ="; pin-sha256 = "K87oWBWM9UZfyddvDfoxL + 8lpNyoUB2ptGtn0fv6G2Q ="; pin-sha256 = "IQBnNBEiFuhj + 8x6X8XLgh01V9Ic5 / V3IRQLNFFc7v4 ="; pin-sha256 = "iie1VXtL7HzAMF + / PVPR9xzT80kQxdZeJ + zduCB3uj0 ="; pin-sha256 = "LvRiGEjRqfzurezaWuj8Wie2gyHMrW5Q06LspMnox7A ="; includeSubDomains Параметри X-Content-Type: nosniff Параметри X-Frame: заборонити X-XSS-захист: 1; mode = block Змінити: Accept-Encoding X-Served-By: a128136e4734a9f74c013356c773ece7 X-GitHub-Request-Id: 5E1FA660: 3F8D: DE52100: 56F18A36 <! DOCTYPE html> <html lang = "en" class = "" = "og: http://ogp.me/ns# fb: http://ogp.me/ns/fb# object: http://ogp.me/ns/object# стаття: http: // ogp. me / ns / article # profile: http://ogp.me/ns/profile# "> <meta charset = 'utf-8'> <посилання crossorigin =" анонімний "href =" https: // assets-cdn. "media =" all "rel =" stylesheet "/> <link crossorigin =" анонімний "href =" https://assets-cdn.github.com/assets/github-\tgithub.com/assets/frameworks-d351435b5f1e212200389237dc222f117a71a35e056adc4556b00b152a9f79c4.css d6cdc916c67f2afd181c5dd292db1fdb3e93fc18d67b4a8cdac0ef77df6b9cc9.css "ЗМІ =" все "отн =" Таблиця стилів "/> <посилання crossorigin =" анонімними "HREF =" https://assets-cdn.github.com/assets/site-cba73ccd3ee30bf3b90aaf16f1aad8d8f91886bd3bc7fa5b42abf46dd3c46210.css "ЗМІ =" все "rel =" stylesheet "/> <link as =" скрипт "href =" https: //assets-cdn.github "rel =" preload "/> <link as =" script "href =" https://assets-cdn.github.com/assets/github-ab1086948a3be528001710080ba17e4975ddb36a9379ab7dddfdb0370647b7c1.js " "preload" /> <meta http-equiv = "Сумісність з X-UA" content = "IE = край"> <meta http-equiv = "Мова вмісту" content = "en"> <meta name = "viewport" content = "width = 1020"> <title> Як люди будують програмне забезпечення · GitHub </title> <link rel = "search" type = "application / opensearchdescription + xml" href = "/opensearch.xml" title = "GitHub" > <link rel = "fluid-icon" href = "https://github.com/fluidicon.png" title = "GitHub"> <link rel = "icon-touch-icon" icon.png "> <link rel =" apple-touch-icon "розміри =" 57x57 "href =" /apple-touch-icon-57x57.png "> <link rel =" icon-touch-icon "розміри =" 60x60 "href =" /apple-touch-icon-60x60.png "> <link rel =" icon-touch-icon "розміри =" 72x72 "href =" /apple-touch-icon-72x72.pn g "> <link rel =" apple-touch-icon "розміри =" 76x76 "href =" /apple-touch-icon-76x76.png "> <link rel =" apple-touch-icon "розміри =" 114x114 " href = "/apple-touch-icon-114x114.png"> <link rel = "apple-touch-icon" розміри = "120x120" href = "/apple-touch-icon-120x120.png"> <link rel = "apple-touch-icon" sizes = "144x144" href = "/apple-touch-icon-144x144.png"> <link rel = "icon-touch-icon" розміри = "152x152" href = "/ apple-touch -icon-152x152.png "> <link rel =" icon-touch-icon "розміри =" 180x180 "href =" /apple-touch-icon-180x180.png "> <meta property =" fb: app_id "content = "1401488693436528"> $ gnutls-cli www.github.com

Приклад HTTP в firebug

FireBug - це плагіновий браузер FireFox для веб-розробників. Запускається по клавіше <F12>.

Заголовки запрос і відвета в FireBug'е з попереднього примера.

Заголовки запроса в Firebug

Тело ответа знаходиться в окремій вкладці.

Тело ответа в Firebug

резюме

Протокол HTTP це:

однонаправленный (запит / ответ)
текстовый протокол
не хранит состояния
працює на сетевому рівні тільки через TCP
може передавать будь-які дані
використовується не тільки в браузерах
обслуживает львиную долю Інтернет трафика

переваги

Простота. Протокол HTTP дозволяє легко створювати необхідні кліентські додатки.
Расширяемость . Исходные возможности протокола можна розширити, внедрив свої власні заголовки, з допомогою яких можна добитися необхідної функціональності, яка може потребувати при решенні конкретних задач. Змінимо з іншими серверами і клієнтами від цього ніякого не постраждали: вони будуть ігнорувати неизвестные им заголовки.
Распространённость . Протокол підтримується в якості клієнта багатопрофільних програм і є можливість вибору серед хостингових компаній з серверами HTTP. За цією причиною протокол широко використовує для рішень різних задач. Крім цього, існує документація на багатьох мовах, що істотно облегчить роботу з протоколом.

недоліки

Избыточность передаваемой інформації, і як слід, великий розмір повідомлень по порівнянню з передачами двоїчних даних. Це виводить внедрение кэширования на стороні клієнта, компресії передаваних даних від сервера. Також поліпшується ситуація використання прокси-серверів, що дозволяють передати інформацію клієнта з найбільш близьким сервером, що розшифровується, завдяки своїй клієнту передається не весь обсяг даних, а лише змінена їх частина.
Отсутствие навигации . У протокола відсутні засоби навігації серед ресурсів сервера. Кліент не може, як в FTP, запитати список доступних файлів. Протокол передбачає, що користується вже відомим URI інтересом його ресурсу.
Ця особливість є достатньо прозорою для користувача, але незручно для додатків, що це вимагає. Разработчики это решается вводом дополнительных компонентів. У такому випадку клієнт може бути, наприклад, веб-паук, проходячи по всьому гіперсигналам документа, і збираючи дану інформацію. Офіційний сайт компанії, наприклад, карта сайту - спеціальна сторінка з перерахунком доступних клієнтів ресурсів.
Карта сайту може бути використана як користувачем, так і роботами-пауками пошукових систем, що зменшують їхню кількість - мінімально необхідно кількість переходів з головної сторінки. Аналогічна функція використовує файли sitemap, але тільки для додатків. Ця проблема повністю розгорнута в протоколі більш високого рівня WebDAV, за допомогою якого ви можете скористатися методами PROPFIND.
Отсутствие поддержки распределённости . Ізначально протокол HTTP розраховується для вирішення типових задач, де саме за час виконання завдання потрібно займатися незнайомим часом або вогнем не прийматися в розрахунках. Проте з часів стало очевидним, що при промисловому використанні застосовуються розподілені викиди при високих навантаженнях на сервер протоколу HTTP. У зв'язку з цим з 1998 року був запропонований альтернативний протокол HTTP-NG (англ. HTTP Next Generation).

ObjectClass?
Com: 8042 / over / there?
X=1&y=2"> <a href="http://host/?
Php?
Com/css?
Com/css?

Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

HTTP протокол - Канали передачі даних

URL

URI

URN

структура URL

протокол

авторизація

Адреса ресурсу

Шлях до ресурсу

параметри

якір

символи

Формати повідомлень запиту / відповіді

Стартовий рядок запиту

методи

метод GET

метод POST

Стартовий рядок відповіді

коди станів

заголовки HTTP

Основні заголовки

заголовки запиту

заголовки відповіді

заголовки суті

нестандартні заголовки

Cookie

Приклад HTTP в браузері

Приклад HTTP в консолі (telnet)

Приклад HTTP в firebug

резюме

переваги

недоліки