1) Dlaczego protokół WebSockets jest lepszy?
WebSockets jest lepszy w sytuacjach, w których występuje komunikacja o niskim opóźnieniu, szczególnie w przypadku małych opóźnień komunikatów między klientem a serwerem. W przypadku danych serwer-klient można uzyskać dość małe opóźnienie, korzystając z długotrwałych połączeń i transferu porcji. Nie pomaga to jednak w opóźnieniu między klientem a serwerem, co wymaga ustanowienia nowego połączenia dla każdego komunikatu klient-serwer.
Twój 48-bajtowy uścisk dłoni HTTP nie jest realistyczny w rzeczywistych połączeniach przeglądarki HTTP, w których często jest kilka kilobajtów danych wysyłanych jako część żądania (w obu kierunkach), w tym wiele nagłówków i danych cookie. Oto przykład żądania / odpowiedzi na korzystanie z Chrome:
Przykładowe żądanie (2800 bajtów, w tym dane cookie, 490 bajtów bez danych 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]]]
Przykładowa odpowiedź (355 bajtów):
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
Zarówno HTTP, jak i WebSockets mają uzgadniane początkowe połączenia o równoważnych rozmiarach, ale w przypadku połączenia WebSocket uzgadnianie początkowe jest wykonywane raz, a następnie małe wiadomości mają tylko 6 bajtów narzutu (2 dla nagłówka i 4 dla wartości maski). Opóźnienie związane z opóźnieniami nie tyle zależy od wielkości nagłówków, ile od logiki parsowania / obsługi / przechowywania tych nagłówków. Ponadto opóźnienie konfiguracji połączenia TCP jest prawdopodobnie większym czynnikiem niż rozmiar lub czas przetwarzania dla każdego żądania.
2) Dlaczego został wdrożony zamiast aktualizacji protokołu HTTP?
Podejmowane są próby przeprojektowania protokołu HTTP, aby uzyskać lepszą wydajność i mniejsze opóźnienia, takie jak SPDY , HTTP 2.0 i QUIC . Poprawi to sytuację w przypadku zwykłych żądań HTTP, ale jest prawdopodobne, że WebSockets i / lub WebRTC DataChannel nadal będą miały mniejsze opóźnienia dla przesyłania danych między klientem a serwerem niż protokół HTTP (lub będą używane w trybie przypominającym WebSockets w każdym razie).
Aktualizacja :
Oto ramy myślenia o protokołach sieciowych:
- TCP : niskopoziomowa, dwukierunkowa, pełny dupleks i gwarantowana warstwa transportu zamówień. Brak obsługi przeglądarki (z wyjątkiem wtyczki / Flasha).
- HTTP 1.0 : protokół transportowy żądanie-odpowiedź warstwowy na TCP. Klient wysyła jedno pełne żądanie, serwer daje jedną pełną odpowiedź, a następnie połączenie zostaje zamknięte. Metody żądania (GET, POST, HEAD) mają określone znaczenie transakcyjne dla zasobów na serwerze.
- HTTP 1.1 : utrzymuje charakter zapytania-odpowiedzi HTTP 1.0, ale umożliwia połączenie otwarte dla wielu pełnych żądań / pełnych odpowiedzi (jedna odpowiedź na żądanie). Nadal ma pełne nagłówki w żądaniu i odpowiedzi, ale połączenie jest ponownie używane i nie jest zamykane. HTTP 1.1 dodał także kilka dodatkowych metod żądania (OPCJE, PUT, DELETE, TRACE, CONNECT), które również mają określone znaczenie transakcyjne. Jednak, jak zauważono we wstępie do projektu propozycji HTTP 2.0, potokowanie HTTP 1.1 nie jest szeroko wdrażane, więc znacznie ogranicza to użyteczność HTTP 1.1 do rozwiązywania opóźnień między przeglądarkami a serwerami.
- Długie odpytywanie : rodzaj „włamania” do HTTP (1.0 lub 1.1), w którym serwer nie odpowiada natychmiast (lub tylko częściowo nagłówkami) na żądanie klienta. Po odpowiedzi serwera klient natychmiast wysyła nowe żądanie (używając tego samego połączenia, jeśli przez HTTP 1.1).
- Strumieniowe przesyłanie HTTP : różne techniki (odpowiedź wieloczęściowa / podzielona na porcje), które pozwalają serwerowi wysłać więcej niż jedną odpowiedź na jedno żądanie klienta. W3C standaryzuje to jako zdarzenia wysyłane przez serwer przy użyciu
text/event-streamtypu MIME. Interfejs API przeglądarki (który jest dość podobny do interfejsu WebSocket API) nazywa się interfejsem API EventSource.
- Push komety / serwera : jest to termin obejmujący zarówno dalekosiężne, jak i strumieniowe przesyłanie HTTP. Biblioteki komet zwykle obsługują wiele technik, aby zmaksymalizować obsługę wielu przeglądarek i serwerów.
- WebSockets : wbudowana warstwa transportowa TCP, która korzysta z przyjaznego protokołu HTTP Upshake. W przeciwieństwie do TCP, który jest transportem strumieniowym, WebSockets jest transportem opartym na wiadomościach: wiadomości są rozdzielane przewodowo i ponownie składane w całości przed dostarczeniem do aplikacji. Połączenia WebSocket są dwukierunkowe, full-duplex i długotrwałe. Po początkowym żądaniu / odpowiedzi uzgadniania nie ma semantyki transakcyjnej i narzut na wiadomość jest bardzo mały. Klient i serwer mogą wysyłać wiadomości w dowolnym momencie i muszą obsługiwać odbiór wiadomości asynchronicznie.
- SPDY : inicjowana przez Google propozycja rozszerzenia HTTP przy użyciu bardziej wydajnego protokołu przewodowego, ale z zachowaniem całej semantyki HTTP (żądanie / odpowiedź, pliki cookie, kodowanie). SPDY wprowadza nowy format ramkowania (z ramkami z prefiksem długości) i określa sposób warstwowania par żądania / odpowiedzi HTTP na nowej warstwie ramkowania. Nagłówki można kompresować, a nowe nagłówki można wysyłać po ustanowieniu połączenia. Istnieją rzeczywiste implementacje SPDY w przeglądarkach i serwerach.
- HTTP 2.0 : ma podobne cele jak SPDY: redukuje opóźnienia HTTP i koszty ogólne przy jednoczesnym zachowaniu semantyki HTTP. Obecna wersja robocza pochodzi z SPDY i definiuje aktualizację uzgadniania i ramkowania danych, która jest bardzo podobna do standardu WebSocket dla uzgadniania i ramkowania. Alternatywna propozycja wersji roboczej HTTP 2.0 (httpbis-speed -obility) faktycznie używa WebSockets dla warstwy transportowej i dodaje multipleksowanie SPDY i mapowanie HTTP jako rozszerzenie WebSocket (rozszerzenia WebSocket są negocjowane podczas uzgadniania).
- WebRTC / CU-WebRTC : propozycje umożliwienia łączności peer-to-peer między przeglądarkami. Może to umożliwić komunikację o niższych średnich i maksymalnych opóźnieniach, ponieważ ponieważ podstawowym transportem jest SDP / datagram, a nie TCP. Pozwala to na dostarczanie pakietów / wiadomości poza kolejnością, co pozwala uniknąć problemu z opóźnieniami TCP spowodowanymi przez upuszczone pakiety, które opóźniają dostarczenie wszystkich kolejnych pakietów (w celu zagwarantowania dostarczenia w kolejności).
- QUIC : jest eksperymentalnym protokołem mającym na celu zmniejszenie opóźnień sieci w stosunku do TCP. Na powierzchni, QUIC jest bardzo podobny do TCP + TLS + SPDY zaimplementowanego na UDP. QUIC zapewnia multipleksowanie i kontrolę przepływu równoważną HTTP / 2, bezpieczeństwo równoważne TLS oraz semantykę połączenia, niezawodność i kontrolę przeciążenia równoważną TCP. Ponieważ TCP jest zaimplementowany w jądrach systemu operacyjnego i oprogramowaniu wewnętrznym skrzynki pośredniej, wprowadzenie znacznych zmian w TCP jest prawie niemożliwe. Ponieważ jednak QUIC jest zbudowany na bazie UDP, nie ma takich ograniczeń. QUIC jest zaprojektowany i zoptymalizowany dla semantyki HTTP / 2.
Referencje :
- HTTP :
- Zdarzenie wysłane przez serwer :
- WebSockets :
- SPDY :
- HTTP 2.0 :
- WebRTC :
- QUIC :
