Відмінності між версіями «HTTP»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
м
 
(не показано 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 для рішення конкретних задач немаловажним фактором є його поширеність. Як наслідок, цей багато різної документації по протоколу на багатьох мовах світу, вставка зручних у використанні засобів розробки в популярні IDE, підтримка протоколу як клієнта багатьма програмами і великий вибір серед хостингових компаній із серверами 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 протоколу, у якої повідомлення запиту містить тільки стартовий рядок, а повідомлення відповіді тільки тіло повідомлення.


TCP/IP