Реферат Протокол HTTP 1.1

Страница 1 из 10 | Следующая страница

МОСКОВСЬКИЙ ДЕРЖАВНИЙ ІНСТИТУТ РАДИОТЕХНИКИ, ЭЛЕКТРОНИКИ І АВТОМАТИКИ (ТЕХНИЧЕСКИЙ УНІВЕРСИТЕТ)

ЗАЧЕТНАЯ РОБОТА

ПО

ДИСЦИПЛИНЕ

«Информационно-вычислительные мережі»

НА ТЕМУ

«Протокол HTTP 1.1»

Роботу виконав:

Студент 5-го курсу факультету Кибернетики групи ИО-1-97 Фроловичев Сергій

Викладач:

Дешко І.П.

МОСКВА 2002 р.

Оглавление

1. Запровадження. 5

1.1. Призначення. 5

1.3 Термінологія. 5

2. Загальне опис. 8

3. Параметри протоколу. 11

3.1 Версія HTTP. 11

3.2 Універсальний Идентификатор Ресурса (URI). 12

3.2.1 Загальний синтаксис. 12

3.2.2 HTTP URL. 13

3.2.3 Порівняння URI. 13

3.3 Формати даты/времени. 14

3.3.1 Повна дата. 14

3.3.2 Різниця секунд (delta seconds). 15

3.4 Кодовые таблиці (character sets). 15

3.5 Кодирования вмісту (content codings). 15

3.6 Кодирования передачі (Transfer Codings). 16

3.7 Медиатипы (Media Types). 17

3.7.1 Канонизация і визначені значення типу text. 18

3.7.2 Типи Multipart. 19

3.8 Маркеры продуктів (Product Tokens). 19

3.9 Величины якості (Quality Values). 20

3.10 Метки мов (Language Tags). 20

3.11 Метки об'єктів (Entity Tags). 21

3.12 Одиниці виміру діапазонів (Range Units). 21

4. HTTP повідомлення (HTTP Message). 22

4.1 Типи повідомлень. 22

4.2 Заголовки повідомлень. 22

4.3 Тіло cообщения. 23

4.4 Довжина повідомлення. 24

4.5 Загальні поля заголовка. 25

5. Запит (Request). 25

5.1 Строка запиту (Request-Line). 25

5.1.1 Метод (Method). 25

5.1.2 URI запиту (Request-URI). 26

5.2 Ресурс, идентифицируемый запитом. 27

5.3 Поля заголовка запиту. 28

6 Відповідь (Response). 28

6.1 Строка стану (Status-Line). 28

6.1.1 Код гніву й яка пояснює фраза. 28

6.2 Поля заголовка відповіді. 30

7 Об'єкт (Entity). 30

7.1 Поля заголовка об'єкта. 30

7.2 Тіло об'єкта. 31

7.2.1 Тип. 31

7.2.2 Довжина. 32

8 Соединения (Connections). 32

8.1 Постійні сполуки (Persistent Connections). 32

8.1.1 Мета. 32

8.1.2 Загальне опис. 32

8.1.2.1 Обговорення (Negotiation). 33

8.1.2.2 Конвейерная обробка (Pipelining). 33

8.1.3 Прокси-сервера (Proxy Servers). 33

8.1.4 Практичні міркування. 34

8.2 Вимоги до передавання повідомлень. 34

9 Визначення методів. 36

9.1 Безопасные і идемпотентные методи. 36

9.1.1 Безопасные методи. 36

9.1.2 Идемпотентные методи. 37

9.2 OPTIONS. 37

9.3 GET. 38

9.4 HEAD. 38

9.5 POST. 38

9.6 PUT. 39

9.7 DELETE. 40

9.8 TRACE. 41

10 Визначення кодів стану. 41

10.1 1xx - Інформаційні коди. 41

10.1.1 100 Продовжувати, Continue. 41

10.1.2 101 Перемикання протоколів, Switching Protocols. 42

10.2 2xx - Успішні коди. 42

10.2.1 200 OK. 42

10.2.2 201 Створено, Created. 42

10.2.3 202 Прийнято, Accepted. 43

10.2.4 203 Не авторська інформація, Non-Authoritative Information. 43

10.2.5 204 Ні вмісту, No Content. 43

10.2.6 205 Сбросить вміст, Reset Content. 43

10.2.7 206 Часткове вміст, Partial Content. 44

10.3 3xx - Перенаправление. 44

10.3.1 300 Множественный вибір, Multiple Choices. 44

10.3.2 301 Постійно переміщений, Moved Permanently. 45

10.3.3 302 Тимчасово переміщений, Moved Temporarily. 45

10.3.4 303 Дивитися інший, See Other. 45

10.3.5 304 Не модифікований, Not Modified. 46

10.3.6 305 Використовуйте прокси-сервер, Use Proxy. 46

10.4 4xx - Коди помилок клієнта. 47

10.4.1 400 Зіпсований Запит, Bad Request. 47

10.4.2 401 Несанкционированно, Unauthorized. 47

10.4.3 402 Потрібна оплата, Payment Required. 47

10.4.4 403 Заборонено, Forbidden. 47

10.4.5 404 Не знайдено, Not Found. 48

10.4.6 405 Метод не скажімо, Method Not Allowed. 48

10.4.7 406 Не прийнятний, Not Acceptable. 48

10.4.8 407 Потрібна встановлення дійсності через прокси-сервер, Proxy Authentication Required. 48

10.4.9 408 Минуло час очікування запиту, Request Timeout. 49

10.4.10 409 Конфлікт, Conflict. 49

10.4.11 410 Удален, Gone. 49

10.4.12 411 Потрібна довжина, Length Required. 50

10.4.13 412 Предусловие не так, Precondition Failed. 50

10.4.14 413 Об'єкт запиту занадто великий, Request Entity Too Large. 50

10.4.15 414 URI запиту занадто довгий, Request-URI Too Long. 50

10.4.16 415 Неподдерживаемый медиатип, Unsupported Media Type. 50

10.5 5xx - Коди помилок серверу. 51

10.5.1 500 Внутрішня помилка серверу, Internal Server Error. 51

10.5.2 501 Не реалізовано, Not Implemented. 51

10.5.3 502 Помилка шлюзу, Bad Gateway. 51

10.5.4 503 Сервіс недоступний, Service Unavailable. 51

10.5.5 504 Минуло час очікування шлюзу, Gateway Timeout. 51

10.5.6 505 Не підтримувана версія HTTP, HTTP Version Not Supported. 52

11 Встановлення дійсності доступу (Access Authentication). 52

11.1 Базова схема встановлення дійсності (Basic Authentication Scheme). 53

11.2 Оглядова схема встановлення дійсності (Digest Authentication Scheme) [1]. 54

13 Кэширование в HTTP. 54

13.1 Загальна інформацію про кэшировании. 55

13.1.1 Правильність кешу. 55

13.1.2 Попередження. 56

13.1.3 Механізми управління кэшем (Cache-control Mechanisms). 57

13.1.4 Явні попередження агента користувача. 57

13.1.5 Винятки з правив і попереджень. 57

13.1.6 Контролируемое клієнтом поведінка. 58

13.2 Модель устаревания. 58

13.2.1 Устаревание, вказане сервером. 58

13.2.2 Эвристическое старіння. 59

13.2.3 Вычисление віку. 59

13.2.4 Вычисление устаревания. 61

13.2.5 Усунення суперечностей у значеннях устаревания. 62

13.2.6 Усунення протиріч між кількома відповідями. 62

13.3 Модель перевірки достовірності (validation model). 63

Библиографический список.. 65

 


1. Запровадження.

Протокол передачі гіпертексту (HTTP) - протокол прикладного рівня для розподілених, спільних, многосредных інформаційних систем. HTTP використовують у World Wide Web (WWW) починаючи з року. Першої версією HTTP, відомої як HTTP/0.9, був простий протокол передачі необроблених даних через Інтернет. За визначенням RFC 1945 HTTP/1.0 був поліпшенням цього протоколу, допускав MIME-подобный формат повідомлень, у якому метаінформацію про переданих даних, і мав модифіковану семантику запросов/ответов. Проте HTTP/1.0 недостатньо враховував особливості роботи з ієрархічними прокси-серверами (hierarchical proxies), кэшированием, постійними сполуками, і віртуальними хостами (virtual hosts). З іншого боку, швидке зростання числа в повному обсязі сумісних з протоколом HTTP/1.0 додатків, зажадав введення нової версії протоколу, де було б закладено додаткових можливостей, які чи допомогли б привести ці додатку до єдиному стандарту.

Список RFC належить до розглянутим у цій роботі питанням, приведено у розділі «Библиографический список».

 

1.1. Призначення

Протокол HTTP/1.1 містить понад суворі вимоги, ніж HTTP/1.0, гарантують надійніший роботу.

Великі інформаційні системи вимагають великої кількості функціональних можливостей, ніж просто завантаження інформації, включаючи пошук і освоєння модифікацію даних з допомогою зовнішніх інтерфейсів. HTTP надає відкритий (open-ended) набір методів, що базуються на системі посилань, які забезпечуються URI (Универсальными Идентификаторами Ресурсів). URI можуть ідентифікувати як розташування (URL), і ім'я (URN) ресурсу, якого застосовується даний метод. Повідомлення передаються в форматі, такому використовуваному електронною поштою відповідно до визначень MIME (Многоцелевых Расширений Електронної Почты).

HTTP також використовують як узагальнений протокол зв'язок між агентами користувачів (user agents) і прокси-серверами/шлюзами (proxies/gateways) чи іншими Інтернет-сервісами, зокрема такі як SMTP, NNTP, FTP, Gopher і WAIS. Отже, HTTP визначає основи многосредного доступу до ресурсів різноманітних додатків.

1.3 Термінологія.

-     Поєднання (connection).

Віртуальний канал транспортого рівня, встановлений між двома програмами з єдиною метою зв'язку.

-     Повідомлення (message).

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

-     Запит (request)

Будь-яке HTTP повідомлення, що містить запит.

-     Відповідь (response).

Будь-яке HTTP повідомлення, що містить відповідь.

-     Ресурс (resource).

Мережний об'єкт даних чи сервіс, що може бути ідентифікований URI. Ресурси може бути доступні у кількох уявленнях (наприклад на кількох мовами, у різних форматах даних, мати різний розмір чи різну розрізнювальну здатність) чи різнитися на інших параметрами.

-     Об'єкт (entity).

Інформація, передана як корисною навантаження запиту чи відповіді. Об'єкт складається з метаинформации у вигляді полів заголовка об'єкту і вмісту у формі тіла об'єкта.

-     Уявлення (representation).

Об'єкт включений у відповідь, і підпорядкований обговоренню вмісту (Content Negotiation). Може існувати кілька уявлень, пов'язаних із специфічними станами відповіді.

-     Обговорення вмісту (content negotiation).

Механізм для вибору відповідного подання в час обслуговування запиту. Уявлення об'єктів у кожному відповіді то, можливо обговореними (включаючи помилкові відповіді).

-     Варіант (variant).

Ресурс може мати одне, чи кілька уявлень, пов'язаних із нею в момент. Кожна з цих уявлень називається "варіант". Використання терміна "варіант" необов'язково передбачає, що ресурс підпорядкований обговоренню вмісту.

-     Клієнт (client)

Програма, що встановлює з'єднання з метою посилки запитів.

-     Агент користувача (user agent).

Клієнт, який ініціює запит. Зазвичай браузери, редактори, роботи (spiders), й інші інструментальні кошти користувача.

-     Сервер (server).

Додаток, яке слухає сполуки, приймає запити обслуговування і посилає відповіді. Будь-яка таку програму здатна бути як клієнтом, і сервером; наше використання даного терміна належить швидше ролі, яку програма виконує, створюючи специфічні сполуки, ніж та можливостей програми взагалі. Аналогічно, будь-який сервер може діяти як початковий сервер (origin server), прокси-сервер (proxy), шлюз (gateway) чи тунель (tunnel), змінюючи поведінка, виходячи з характері кожного запиту.

-     Початковий сервер (origin server).

Сервер, у якому даний ресурс перебуває постійно чи мусить можна створити.

-     Прокси-сервер (proxy).

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

-     Шлюз (gateway).

Сервер, котрий діє посередником для деякого іншого серверу. На відміну від проксі-сервера, шлюз отримує запити як початкового серверу для запитаного ресурсу; клієнт запиту може знати, що він з'єднується зі шлюзом.

-     Тунель (tunnel).

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

-     Кеш (cache).

Локальна пам'ять, у якій програма зберігає сообщения-ответы, і де розташовується підсистема, управляюча зберіганням, пошуком і видаленням повідомлень. Кеш зберігає відповіді, які можна збережені, аби знизити час відповіді і завантаження мережі (трафік) при майбутніх еквівалентних запитах. Будь-який клієнт чи сервер може мати кеш, але кеш неспроможна використовуватися сервером, котрий діє як тунель.

-     Кэшируемый (cachable).

Відповідь є кэшируемым, якщо кэшу дозволено зберегти копію відповідного повідомлення від використання у відповідях на наступні запити. Навіть якщо його ресурс кэшируем, можуть існувати додаткових обмежень використання кэшем збереженої копії для вихідного запиту.

-     Безпосередній (first-hand).

Відповідь вважається безпосереднім, коли він приходить безпосередньо від початкового серверу без непотрібної затримки, можливо через чи кілька прокси-серверов. Відповідь є також безпосереднім, якщо його достовірність щойно була встановлено безпосередньо початковою сервером.

-     Точне час устаревания (explicit expiration time).

Час певне початковою сервером і що показує кэшу щоб большє нє то, можливо повернутий клієнту без додаткової перевірки достовірності.

-     Эвристическое час устаревания (heuristic expiration time).

Час устаревания, призначені кэшем, а то й зазначено точний час устаревания.

-     Вік (age).

Вік відповіді - час, що минув від моменту посилання, чи успішної перевірки відповіді початковою сервером.

-     Час життя (freshness lifetime).

Відтинок часу між породженням відповіді і моментом устаревания.

-     Свіжий (fresh).

Відповідь вважається свіжим, якщо його вік ще перевищив тривалість життя.

-     Просроченнный (stale).

Відповідь вважається простроченим, якщо його вік перевищив тривалість життя.

-     Семантично прозорий (semantically transparent).

Кажуть, що кеш поводиться "семантично прозорим" чином щодо специфічного відповіді, коли використання кешу впливає і клієнта запиту, і початковий сервер, але підвищує ефективність. Коли кеш семантично прозорий, клієнт отримує такий самий відповідь (крім проміжних (hop-by-hop) заголовків), що мала б, просячи безпосередньо початковий сервер, а чи не кеш.

-     Покажчик достовірності (validator).

Елемент протоколу (наприклад, мітка об'єкта або останньої модифікації (Last-Modified time)), що використовується, аби з'ясувати, чи є яка перебуває у кэше копія еквівалентом об'єкта.

2. Загальне опис.

Протокол HTTP - це протокол запросов/ответов. Клієнт посилає по з'єднанню запит серверу, у якому: метод запиту, URI, версію протоколу, MIME-подобное повідомлення, у тому числі модифікатори запиту, клієнтську інформації і, можливо, тіло запиту. Сервер відповідає рядком стану, що включає версію протоколу повідомлення, кодом успішного виконання (чи помилки, MIME-подобным повідомленням, що містить інформацію про сервері, метаінформацію об'єкту і, можливо, тіло об'єкта.


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

Більше складна ситуація виникає, як у ланцюжку запросов/ответов присутній чи кілька посередників. Існують три основних різновиду посередників: проксі-сервера, шлюзи, тунелі. Прокси-сервер є агентом-посредником, котра отримує запити певний URI у повній формі, змінює все повідомлення або його частину і відсилає змінений запит серверу, ідентифікованого URI. Шлюз - це приймає агент, діючий хіба що до рівня вище деякого іншого сервера(ов) й за необхідності який транслює запити до протоколу основного серверу. Тунель діє і як реле (relay) між двома сполуками не змінюючи повідомлень; тунелі використовуються, коли зв'язок потрібно виробляти через посередника (наприклад firewall), яка розуміє зміст повідомлень.


На малюнку показані три посередника (A, B і З) між агентом користувача і початковою сервером. Запити і передаються через чотири окремих сполуки. Це - відмінність важливо, бо окремі опції HTTP сполуки застосовні лише у з'єднанню з найближчим не туннельным сусідом, деякі лише у кінцевим точкам ланцюжка, і деякі всім сполукам в ланцюжку. Хоча цей діаграма линейна, кожного учасника може бути задіяним у кількох з'єднаннях одночасно. Наприклад, B може отримувати запити з інших клієнтів, Не тільки від A, і/або пересилати запити серверам, відмінними від З, до того ж час, що він обробляє запит А.

Будь-яка сторона сполуки, яка діє як тунель, може використовувати внутрішній кеш в обробці запитів. Ефект кешу у тому, що ланцюжок запросов/ответов скорочується, якщо з учасників в ланцюжку має кэшированный відповідь, задовольняє даному запиту. Далі показано ланцюжок, що виникає у разі, коли B має кэшированую копію раннього відповіді O (полеченного через З) на запит, і який був кэширован ні UA, ні A.

Не всі відповіді корисно кэшировать, і деякі запити можуть утримувати модифікатори, які вказують спеціальні вимоги, управляючі поведінкою кешу.


Фактично, є широке розмаїтість архітектур і конфігурацій кэшей і прокси-серверов, розроблюваних нині чи розгорнутих в World Wide Web; ці системи включають національні ієрархії прокси-кэшей, що зберігають пропускну спроможність межокеанских каналів, системи, які поширюють на багато адрес вміст кешу, організації, які

Страница 1 из 10 | Следующая страница

Схожі реферати:

Навігація