1) Чому протокол WebSockets краще?
WebSockets краще для ситуацій, що пов'язані з низькою затримкою зв'язку, особливо з низькою затримкою для повідомлень клієнта-сервера. Для даних від сервера до клієнта ви можете отримати досить низьку затримку за допомогою тривалих з'єднань і частотної передачі. Однак це не допомагає затримці клієнта до сервера, що вимагає встановлення нового з'єднання для кожного повідомлення клієнт-сервер.
Ваша передача HTTP в 48 байтів не є реальною для реальних підключень браузера HTTP, де часто є кілька кілобайт даних, що надсилаються як частина запиту (в обох напрямках), включаючи безліч заголовків та даних cookie. Ось приклад запиту / відповіді на використання Chrome:
Приклад запиту (2800 байт, включаючи дані cookie, 490 байт без файлів cookie):
GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]
Приклад відповіді (355 байт):
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip
І HTTP, і WebSockets мають еквівалентний розмір рукостискань з початковим з'єднанням, але при з'єднанні WebSocket початкове рукостискання виконується один раз, тоді невеликі повідомлення мають лише 6 байтів накладних витрат (2 для заголовка і 4 для значення маски). Затримка накладних витрат не стільки від розміру заголовків, скільки від логіки розбору / обробки / збереження цих заголовків. Крім того, затримка налаштування з'єднання TCP, ймовірно, є більшим фактором, ніж розмір або час обробки для кожного запиту.
2) Чому він був реалізований замість оновлення протоколу HTTP?
Докладаються зусилля для перепроектування протоколу HTTP для досягнення кращої продуктивності та зниження затримки, таких як SPDY , HTTP 2.0 та QUIC . Це поліпшить ситуацію для звичайних запитів HTTP, але ймовірно, що WebSockets та / або WebRTC DataChannel все ще матимуть меншу затримку для передачі даних клієнту на сервер, ніж протокол HTTP (або він буде використовуватися в режимі, який дуже схожий на WebSockets все одно).
Оновлення :
Ось основа для роздумів про веб-протоколи:
- TCP : низькорівневий, двонаправлений, повнодуплексний і гарантований транспортний шар замовлення. Немає підтримки браузера (крім плагіна / Flash).
- HTTP 1.0 : транспортний протокол на відповідь на запит, нанесений на TCP. Клієнт робить один повний запит, сервер дає одну повну відповідь, а потім з'єднання закривається. Методи запиту (GET, POST, HEAD) мають специфічне транзакційне значення для ресурсів на сервері.
- HTTP 1.1 : підтримує характер відповіді на запит HTTP 1.0, але дозволяє з'єднанню залишатися відкритим для декількох повних запитів / повних відповідей (одна відповідь на запит). Все ще є повні заголовки у запиті та відповіді, але з'єднання повторно використовується та не закривається. HTTP 1.1 також додав деякі додаткові методи запиту (OPTIONS, PUT, DELETE, TRACE, CONNECT), які також мають специфічні транзакційні значення. Однак, як було зазначено у вступі до проекту пропозиції HTTP 2.0, трубопровід HTTP 1.1 не широко розгортається, тому це значно обмежує корисність HTTP 1.1 для вирішення затримок між браузерами та серверами.
- Довге опитування : це "хак" для HTTP (або 1.0 або 1.1), коли сервер не відповідає негайно (або лише частково відповідає заголовами) на запит клієнта. Після відповіді сервера клієнт негайно надсилає новий запит (використовуючи те саме з'єднання, якщо над HTTP 1.1).
- Потокова передача HTTP : різноманітні методи (багаточастинна / зв'язана відповідь), які дозволяють серверу надсилати більше одного відповіді на один запит клієнта. W3C стандартизує це як події, надіслані сервером, використовуючи
text/event-streamтип MIME. API браузера (що досить схоже на API WebSocket) називається API EventSource.
- Комета / серверний поштовх : це термін "парасолька", який включає як тривале опитування, так і протокол HTTP. Бібліотеки комети зазвичай підтримують декілька методик, щоб спробувати і максимально підтримувати крос-браузер і підтримку крос-сервера.
- WebSockets : транспортний рівень, вбудований у TCP, який використовує рукостискання з підтримкою HTTP Upgrade. На відміну від TCP, який є потоковим транспортом, WebSockets - це транспорт на основі повідомлень: повідомлення розміщені на дроті та повторно збираються в повному обсязі перед доставкою до програми. З'єднання WebSocket двосторонні, повнодуплексні та довговічні. Після первинного запиту / відповіді рукостискання немає трансакційної семантики і дуже мало на кожне повідомлення. Клієнт і сервер можуть надсилати повідомлення в будь-який час і повинні обробляти отримання повідомлення асинхронно.
- SPDY : Google ініціювала пропозицію розширити HTTP, використовуючи більш ефективний провідний протокол, але підтримуючи всю HTTP-семантику (запит / відповідь, cookie, кодування). SPDY вводить новий формат кадрування (з кадрами з попередньою фіксованою довжиною) і вказує спосіб накладання пар HTTP-запитів / відповідей на новий рівень кадрування. Заголовки можна стискати, а нові заголовки можна надсилати після встановлення з'єднання. Існують реальні впровадження SPDY у браузерах та серверах.
- HTTP 2.0 : має подібні цілі, ніж SPDY: зменшити затримку HTTP та накладні витрати, зберігаючи HTTP-семантику. Поточний проект походить від SPDY і визначає рукостискання з оновленнями та обрамлення даних, що дуже схоже на стандарт WebSocket для рукостискання та кадрування. Альтернативна пропозиція проекту HTTP 2.0 (httpbis-speed-mobile) фактично використовує WebSockets для транспортного рівня і додає мультиплексування SPDY та відображення HTTP як розширення WebSocket (розширення WebSocket узгоджуються під час рукостискання).
- WebRTC / CU-WebRTC : пропозиції, щоб дозволити рівний зв’язок між браузерами. Це може забезпечити низьке середнє та максимальне затримки зв'язку, оскільки основним транспортом є SDP / дейтаграма, а не TCP. Це дозволяє здійснювати доставку пакетів / повідомлень поза замовленням, що дозволяє уникнути випуску TCP затримок, спричинених скинутими пакетами, які затримують доставку всіх наступних пакетів (щоб гарантувати доставку замовлення).
- QUIC : експериментальний протокол, спрямований на зменшення затримки в Інтернеті над протоколом TCP. На поверхні QUIC дуже схожий на TCP + TLS + SPDY, реалізований на UDP. QUIC забезпечує мультиплексування та контроль потоку, еквівалентний HTTP / 2, безпеку, еквівалентну TLS, і семантику підключення, надійність та еквівалент контролю перевантаженості TCP. Оскільки TCP реалізований в ядрах операційної системи та прошивці середньої скриньки, внесення значних змін у TCP поряд із неможливим. Однак оскільки QUIC побудований на версії UDP, він не має таких обмежень. QUIC розроблений та оптимізований для HTTP / 2 семантики.
Список літератури :
- HTTP :
- Подія, надіслана сервером :
- WebSockets :
- SPDY :
- HTTP 2.0 :
- WebRTC :
- Швидкий :
