Відмінності між версіями «HTTP»
Hiss (обговорення • внесок) м |
Hiss (обговорення • внесок) |
||
Рядок 1: | Рядок 1: | ||
+ | Протокол '''HTTP''' (Hypertext Transfer Protocol, протокол передачі гіпертекстів) — це протокол прикладного рівня для розподілених гіпертекстових інформаційних систем. Крім передачі гіпертекстів він може застосовуватися й в інших областях, таких, як сервери імен і розподілені системи керування об'єктами, але для наших цілей важливо те, що на цьому протоколі з моменту своєї появи в 1990 р. і донині базується World Wide Web. Приведений нижче короткий його опис заснований на специфікації HTTP/1.1 (RFC 2616 , червень 1999 р.). | ||
+ | |||
+ | HTTP є протоколом типу запит/відгук. Клієнт посилає серверу запит, що складається з типу запиту, URI і версії протоколу, за яких випливає повідомлення, що містить модифікатори запиту, клієнтську інформацію і, можливо, тіло запиту. Сервер відповідає рядком стану, що містить версію протоколу і код стану, за якою слідує повідомлення, що містить серверну інформацію, метаінформацію і, можливо, тіло повідомлення. | ||
+ | |||
+ | У дійсності, ситуація звичайно є більш складною через участь у процесі обміну інформацією посередників між клієнтом і сервером. Існують три таких посередники: '''''проксі-сервер, шлюз і тунель''''': | ||
+ | |||
+ | Проксі-сервер (або сервер повноважень) приймає запит клієнта, включаючи повний URI, переписує все повідомлення або частину його і передає виправлений запит серверу, зазначеному в URI. | ||
+ | |||
+ | Шлюз розташовується над сервером і при необхідності транслює запити до протоколу більш низького рівня, підтримуваний сервером. | ||
+ | |||
+ | Тунель не змінює переданих повідомлень, а використовується при передачі даних через посередника типу брандмауера (firewall). | ||
+ | |||
+ | |||
'''Переваги''' | '''Переваги''' | ||
Версія за 19:27, 8 грудня 2008
Протокол 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) для повної заміни застарілого з акцентуванням уваги саме на цій області. Ідею його необхідності підтримали великі фахівці з розподілених обчислень, але даний протокол дотепер перебуває в стадії розробки.