Відмінності між версіями «HTTP»
Hiss (обговорення • внесок) м |
Стойка (обговорення • внесок) |
||
(не показано 4 проміжні версії ще одного учасника) | |||
Рядок 1: | Рядок 1: | ||
+ | Протокол '''HTTP''' (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.). | ||
+ | |||
+ | HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення. | ||
+ | |||
+ | У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: '''''проксі-сервер, шлюз і тунель''''': | ||
+ | |||
+ | Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI. | ||
+ | |||
+ | Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером. | ||
+ | |||
+ | Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall). | ||
+ | |||
+ | |||
'''Переваги''' | '''Переваги''' | ||
Рядок 5: | Рядок 18: | ||
''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі. | ''Розширюваність'' - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі. | ||
− | ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, | + | ''Поширеність'' - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, це численність різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP. |
'''Недоліки і проблеми''' | '''Недоліки і проблеми''' | ||
Рядок 15: | Рядок 28: | ||
''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки. | ''Нема підтримки розподіленості'' - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки. | ||
+ | '''''Структура протоколу''''' | ||
+ | |||
+ | Кожне HTTP-повідомлення складається з трьох частин, що передаються в зазначеному порядку: | ||
+ | |||
+ | - Стартовий рядок (англ. Starting line) — визначає тип повідомлення; | ||
+ | |||
+ | - Заголовки (англ. Headers) — характеризують тіло повідомлення, параметри передачі та інші дані; | ||
+ | |||
+ | - Тіло повідомлення (англ. Message Body) — безпосередньо даного повідомлення. Обов'язково повинно відокремлювати від заголовків порожнім рядком. | ||
+ | |||
+ | Заголовки і тіло повідомлення можуть бути відсутні, але стартовий рядок є обов'язковим елементом, тому що вказує на тип запиту/відповіді. Виключенням є версія 0.9 протоколу, у якої повідомлення запиту містить тільки стартовий рядок, а повідомлення відповіді тільки тіло повідомлення. | ||
+ | |||
+ | |||
+ | |||
+ | [[TCP/IP]] | ||
[[category:Комп'ютерні мережі]] | [[category:Комп'ютерні мережі]] |
Поточна версія на 20:57, 13 квітня 2009
Протокол HTTP (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.).
HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення.
У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: проксі-сервер, шлюз і тунель:
Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI.
Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером.
Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall).
Переваги
Простота – протокол настільки простий у реалізації, що дозволяє з легкістю створювати не тільки клієнтські додатки, але і примітивні сервери.
Розширюваність - ви можете легко розширювати можливості протоколу завдяки упровадженню своїх власних заголовків, зберігаючи сумісність з іншими клієнтами і серверами. Вони будуть ігнорувати невідомі їм заголовки, але при цьому ви можете одержати необхідний вам функціонал при рішенні специфічної задачі.
Поширеність - при виборі протоколу HTTP для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, це численність різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами HTTP.
Недоліки і проблеми
Великий розмір повідомлень - використання текстового формату в протоколі породжує відповідний недолік: великий розмір повідомлень у порівнянні з передачею двійкових даних. Через це зростає навантаження на устаткування при формуванні, обробці і передачі повідомлень. Для розв’язанна даної проблеми до протоколу вбудовані засоби для забезпечення кешування на стороні клієнта, а також засобу компресії переданого контенту. Нормативними документами по протоколі передбачена наявність проксі-серверів, що дозволяють клієнту одержати документ із найбільш близького до нього сервера. Також до протоколу було впроваджене дельта-кодування, щоб клієнту передавався не весь документ, а тільки його змінена частина.
Відсутність «навігації» - хоча протокол розроблявся як засіб роботи з ресурсами сервера, у нього відсутні в явному виді засоби навігації серед цих ресурсів. Наприклад, клієнт не може явно запросити список доступних файлів, як у протоколі FTP. Передбачалося, що кінцевий користувач уже знає URI необхідного йому документа, закачавши який, він буде робити навігацію завдяки гіперпосиланням. Це цілком нормально і зручно для людини, але важко, коли стоять задачі автоматичної обробки й аналізу всіх ресурсів сервера без участі людини. Рішення цієї проблеми лежить цілком на плечах розробників додатків, що використовують даний протокол.
Нема підтримки розподіленості - протокол HTTP розроблявся для рішення типових побутових задач де сам по собі час обробки запиту повинен забирати незначний час або взагалі не прийматися в розрахунок. Але в промисловому використанні із застосуванням розподілених обчислень при високих навантаженнях на сервер протокол HTTP виявляється безпомічний. У 1998 році W3C запропонував альтернативний протокол HTTP-NG (англ. HTTP Next Generation) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.
Структура протоколу
Кожне HTTP-повідомлення складається з трьох частин, що передаються в зазначеному порядку:
- Стартовий рядок (англ. Starting line) — визначає тип повідомлення;
- Заголовки (англ. Headers) — характеризують тіло повідомлення, параметри передачі та інші дані;
- Тіло повідомлення (англ. Message Body) — безпосередньо даного повідомлення. Обов'язково повинно відокремлювати від заголовків порожнім рядком.
Заголовки і тіло повідомлення можуть бути відсутні, але стартовий рядок є обов'язковим елементом, тому що вказує на тип запиту/відповіді. Виключенням є версія 0.9 протоколу, у якої повідомлення запиту містить тільки стартовий рядок, а повідомлення відповіді тільки тіло повідомлення.