Тема 8: HTTP з'єднання (HTTP Connections)
Привіт, читач блогу ZametkiNaPolyah.ru. Продовжимо знайомитися з протоколом HTTP в рубриці сервери і протоколи і її розділі HTTP протокол. В даному записі ми з тобою поговоримо про HTTP з'єднання і, в основному, про те, як вони реалізовані в HTTP протоколі версії 1.1. Для початку скажу, що на даний момент діють постійні HTTP з'єднання, це означає одну просту річ: за одну TCP сесію можна відправити кілька HTTP запитів і отримати стільки ж HTTP відповідей, раніше це було далеко не так. Так само в цьому записі ми торкнемося вимоги до передачі HTTP повідомлень.
HTTP з'єднання (HTTP Connections)
Постійні HTTP з'єднання (Persistent Connections HTTP)
Якщо ви хочете дізнатися все про протокол HTTP. зверніться до навігації по рубриці HTTP протокол. HTTP з'єднання або HTTP Connections на даний момент є постійним для кожного URL (читай про URI в HTTP), колись давно для кожного запиту клієнта використовувалося окреме TCP з'єднання (навіть якщо сторінка просто оновлювалася), що створювало велике навантаження на машини з HTTP серверами . тому що кожен елемент сторінки, наприклад зображення - це один або кілька запитів від клієнта до сервера.
Давайте подивимося, що дають постійні HTTP з'єднання (HTTP Connections):
- Зараз не потрібно постійно піднімати нове TCP з'єднання для запиту, тому істотно економляться ресурси серверів.
- HTTP запити клієнта і відповіді сервера можна уявити як безперервно працює конвеєр, причому паралельний, в рамках одного TCP з'єднання.
- Для установки TCP з'єднання машині клієнта і машині сервера обов'язково потрібно посилати пакети, отже, третій рівень моделі OSI був дуже завантажений, так було до появи постійного HTTP з'єднання (HTTP Connections).
Тому на даний момент все HTTP клієнти і HTTP сервери розробляються з урахуванням того, щоб працювати, використовуючи постійні HTTP з'єднання між клієнтом і сервером. У версії протоколу HTTP 1.1 будь-який клієнт за замовчуванням вважає, що йому потрібно працювати з сервером по постійному HTTP з'єднанню (Persistent Connection HTTP). Як тільки клієнт і сервер припинили спілкуватися, їм необхідно розірвати TCP з'єднання, робиться це спеціальним полем в заголовку Connection (якщо не знаєте, що таке заголовки і поля, то почитайте статтю параметри HTTP). Після того, як клієнт отримав повідомлення про розрив TCP з'єднання, він не повинен (читай про вимоги HTTP) посилати сервера заголовки.
З урахуванням того, що HTTP з'єднання постійне. клієнт може посилати кілька HTTP запитів поспіль, не очікую HTTP повідомлень від сервера, але сервер повинен посилати HTTP відповіді на повідомлення клієнта в тому порядку, в якому він отримав запити. З урахуванням того, що на даний момент використовується постійне HTTP з'єднання (HTTP Connections), сервера мають певні значення часу очікування (конкретні цифри залежать безпосередньо від налаштувань сервера), після якого вони перестають підтримувати неактивні сполуки.
Хочу зауважити, що при закритті TCP з'єднання клієнт і сервер можуть працювати асинхронно (хоча HTTP протокол за всіма визначеннями синхронний). Наприклад, ми маємо неактивне HTTP з'єднання. у сервера закінчився час очікування, і він відправляє клієнту повідомлення про те, що він рве TCP з'єднання, але в цей же самий час клієнт відправляє якийсь HTTP запит, в цьому випадку програма клієнта повинна «впоратися» без участі людини, а саме: відправити запит на установку нового HTTP з'єднання і повторити попередній запит.
Загалом, суть даного поста в тому, що на даний момент в HTTP підтримується конвеєрне постійне HTTP з'єднання з можливістю асинхронної обробки події закриття з'єднання.
Вимоги до передачі повідомлень і вибір HTTP з'єднань (HTTP Connections)
Загальні вимоги до передачі повідомлень в стандарті HTTP:
- У HTTP 1.1 серверів слід підтримувати постійні HTTP з'єднання.
- У HTTP1 клієнтам слід під час відправки повідомлення контролювати з'єднання на предмет помилок. При виявленні помилки клієнту слід негайно припинити передачу. Якщо тіло HTTP повідомлення надсилається з використанням кодування по шматках. то шматок нульової довжини можуть використовуватися для індикації передчасного кінця повідомлення.
- Протокол HTTP версії 1.1 передбачає те, що клієнт повинен вміти працювати з кодом стану 100.
Сервера версії HTTP 1.1 повинні вміти працювати з клієнтами 1.0 і нижче, при цьому сервера не повинні використовувати повідомлення з кодом стану 100. Якщо клієнт HTTP 1.1 взаємодіє з сервером 1.0. то для коректної відправки повторного запиту він повинен використовувати наступний алгоритм:
- Ініціалізувати нове з'єднання з сервером.
- Передати заголовки запиту (request-headers).
- Ініціалізувати змінну R зразковим часом передачі інформації на сервер і назад (наприклад на підставі часу встановлення з'єднання), або постійним значення в 5 секунд, якщо час передачі не доступно.
- Обчислити T = R * (2 ** N), де N - число попередніх повторів цього запиту.
- Або дочекатися від сервера відповіді з кодом помилки, або просто почекати T секунд (дивлячись що станеться раніше).
- Якщо відповіді з кодом помилки ніхто не почув, після T секунд передати тіло запиту.
- Якщо клієнт виявляє, що HTTP з'єднання було закрито передчасно, то йому потрібно повторювати починаючи з кроку 1, поки запит не буде прийнятий, або поки не буде отримано помилковий відповідь, або поки у користувача не скінчиться терпіння і він не завершить процес повторення.
Ось такі вимоги до передачі HTTP повідомлень пред'являються стандартом HTTP. На цьому ми закінчимо розгляд HTTP з'єднань. повнішу інформацію ви зможете дізнатися зі стандарту HTTP 1.1.