WebSocket: Różnice pomiędzy wersjami

Z Wikipedii, wolnej encyklopedii
[wersja przejrzana][wersja nieprzejrzana]
Usunięta treść Dodana treść
Przebudowa artykułu (pierwsza sekcja + historia). Poprzednia wersja była wybiórczo tłumaczona z wersji angielskiej - teraz jest to tłumaczenie pełne. Dodane przypisy.
Linia 1: Linia 1:
{{Oprogramowanie infobox
'''WebSocket''' – technologia zapewniająca dwukierunkowy kanał komunikacji za pośrednictwem jednego gniazda [[TCP (protokół)|TCP]]. Stworzono ją do komunikacji [[przeglądarka internetowa|przeglądarki internetowej]] z [[serwer internetowy|serwerem internetowym]], ale równie dobrze może zostać użyta w innych aplikacjach typu [[klient-serwer|klient lub serwer]]. Została ustandaryzowana przez [[Internet Engineering Task Force]] w [[Request for Comments]] 6455<ref>{{RFC|6455}}</ref> w 2011 roku, a [[Application Programming Interface|interfejs]] WebSocket w Web [[Interface Description Language|IDL]] jest standaryzowany przez [[World Wide Web Consortium]].
| nazwa = WebSocket
| rodzaj = [[Protokół komunikacyjny]]
| logo =
| grafika =
| opis grafiki =
| autor =
| platforma sprzętowa = [[Wieloplatformowość|wieloplatformowy]]
| system operacyjny =
| język programowania =
| pierwsze wydanie =
| wersja stabilna =
| wersja testowa =
| licencja = [[Licencja BSD|2-klauzulowa licencja BSD]]
| wikibooks =
| commons = Category:WebSocket
| www = https://datatracker.ietf.org/doc/html/rfc6455
}}


'''WebSocket''' – jest [[Protokół komunikacyjny|protokołem komunikacyjnym]], zapewniającym dwukierunkowy kanał wymiany danych poprzez pojedyncze połączenie [[TCP-IP|TCP]]. Protokół WebSockets został ustandaryzowany przez IETF jako RFC 6455 w 2011 roku<ref>{{RFC|6455}}</ref>, a jego przeglądarkowe API podlega standaryzacji standaryzacji w [[World Wide Web Consortium|W3C]].
WebSocket został zaprojektowany tak, aby mógł być przesyłany przez istniejącą infrastrukturę przystosowaną do transmisji [[Hypertext Transfer Protocol|HTTP]] (czyli przez już skonfigurowane do tego celu serwery proxy, przechodził przez ustawienia zapory sieciowej jeżeli tylko dopuszczany jest ruch HTTP). Natomiast jest zaprojektowany w tym celu, aby zapewnić interakcję (czyli dwukierunkową swobodną wymianę komunikatów) pomiędzy przeglądarką internetową a serwerem. Umożliwia on serwerowi wysyłanie danych do przeglądarki nawet wtedy, jeżeli przeglądarka o te dane wcześniej nie zapyta (wystarczy, że wcześniej zestawiono odpowiedni kanał komunikacji).


WebSockets różni się od protokołu HTTP. Oba protokoły są zlokalizowane na 7 warstwie w [[Model OSI|modelu OSI]] i zależą od TCP na warstwie 4. Pomimo faktu, że są one różne, standard RFC 6455 mówi, że WebSocket został zaprojektowany do działana na portach 80 i 443 przypisanych do HTTP, a także wspierać funkcje proxy i pośredników (intermediaries). Aby osiągnąć kompatybilność z HTTP, handshake WebSocket'u wykorzystuje nagłówek HTTP Upgrade<ref>{{Cytuj |tytuł = rfc6455 |data dostępu = 2021-07-28 |opublikowany = datatracker.ietf.org |url = https://datatracker.ietf.org/doc/html/rfc6455#section-1.7}}</ref>, aby przełączyć komunikację z protokołu HTTP na WebSockets.
Znakomicie zmniejsza to obciążenie sieci, serwera i samej przeglądarki. Unika się dodatkowych komunikatów przesyłanych i przetwarzanych po obu stronach tylko dla utrzymania stałej komunikacji oraz umożliwia serwerowi przesyłanie do przeglądarki w czasie rzeczywistym nowych danych, kiedy tylko pojawią się na serwerze. Przykładowo aplikacja pocztowa działająca w przeglądarce może natychmiast wyświetlić nowy mail, który właśnie przyszedł bez potrzeby odświeżania strony przez użytkownika.

Protokół WebSocket umożliwia interakcję między przeglądarką internetową (lub inną aplikacją kliencką), a serwerem sieciowym przy niższym obciążeniu niż alternatywne rozwiązania [[Dupleks (telekomunikacja)|półdupleksowe]], takie jak np. odpytywanie HTTP (polling), ułatwiając przy tym znacznie przesyłanie danych w czasie rzeczywistym do i z serwera. Jest to możliwe dzięki zapewnieniu znormalizowanego sposobu wysyłania przez serwer treści do klienta bez uprzedniego żądania klienta i umożliwienia przesyłania komunikatów tam i z powrotem przy zachowaniu aktywnego połączenia. W ten sposób między klientem, a serwerem może odbywać się dwukierunkowa wymiana danych. Komunikacja odbywa się zwykle przez port TCP o numerze 443 (lub 80 w przypadku połączeń niezabezpieczonych), co jest korzystne w środowiskach, które blokują połączenia dla aplikacji innych niż przeglądarki internetowe (np. klienty Torrent, IRC). Przed pojawieniem się WebSocket'ów podobną dwukierunkową komunikację przeglądarka-serwer osiągano w niestandardowy sposób, wykorzystując technologie takie jak Comet czy [[Adobe Flash Player]].<ref>{{Cytuj |tytuł = Adobe Flash Platform * Sockets |data dostępu = 2021-07-28 |opublikowany = help.adobe.com |url = https://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-181c51321220efd9d1c-8000.html |cytat = TCP connections require a “client” and a “server.” Flash Player can create client sockets. |język = en-US}}</ref>

Większość współczesnych przeglądarek obsługuje WebSocket'y, w tym m.in: [[Google Chrome|Google Chrome,]] [[Firefox]], [[Microsoft Edge]], [[Internet Explorer]], [[Safari (przeglądarka)|Safari]] i [[Opera (przeglądarka)|Opera]].<ref>{{Cytuj |tytuł = WebSockets - Lista Web API {{!}} MDN |data dostępu = 2021-07-28 |opublikowany = developer.mozilla.org |url = https://developer.mozilla.org/pl/docs/Web/API/WebSockets_API |język = en-US}}</ref>

W przeciwieństwie do protokołu HTTP, WebSocket zapewnia komunikację w pełnym [[Dupleks (telekomunikacja)|dupleksie]]. Dodatkowo WebSocket umożliwia przesyłanie wiadomości na wierzchu protokołu TCP. Sam protokół TCP obsługuje strumienie bajtów bez wbudowanej koncepcji wiadomości. Przed WebSocket komunikacja na porcie 80 w pełnym dupleksie była osiągalna przy użyciu kanałów Comet, jednak implementacja Comet nie jest trywialna, a ze względu na uzgadnianie TCP i obciążenie nagłówka HTTP jest nieefektywna w przypadku małych wiadomości. Protokół WebSocket ma na celu rozwiązanie tych problemów bez naruszania założeń bezpieczeństwa sieci.

Specyfikacja protokołu WebSocket definiuje <code>ws</code> (WebSocket) i <code>wss</code> (WebSocket Secure) jako dwa nowe schematy [[Uniform Resource Identifier|jednolitego identyfikatora zasobów]] (URI), które są używane odpowiednio do połączeń nieszyfrowanych i szyfrowanych. <ref>{{Cytuj |tytuł = Uniform Resource Identifier (URI) Schemes |data dostępu = 2021-07-28 |opublikowany = www.iana.org |url = http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml |język = en-us}}</ref> Oprócz nazwy schematu i fragmentu (tj. # nie jest obsługiwany), pozostałe komponenty URI są zdefiniowane tak, aby używały ogólnej składni URI.<ref>{{Cytuj |autor = Ian Fette |tytuł = rfc6455 |data dostępu = 2021-07-28 |opublikowany = datatracker.ietf.org |url = https://datatracker.ietf.org/doc/html/rfc6455#section-3}}</ref>

Wykorzystując narzędzia developera w przeglądarce, twórcy stron mogą sprawdzić zarówno handshake WebSocket'u, jak i poszczególne paczki (frames). <ref>{{Cytuj |autor = Vanessa Wang |rozdział = APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools |tytuł = The Definitive Guide to HTML5 WebSocket |isbn = 978-1-4302-4740-1 |wydawca = Apress}}</ref>

== Historia ==
WebSocket'y zostały po raz pierwszy wymienione jako TCPConnection w bazowej specyfikacji [[HTML5]], jako symbol zastępczy dla [[Interfejs programowania aplikacji|interfejsu]] (API) gniazda, opartego o protokół [[TCP-IP|TCP]].<ref>{{Cytuj |tytuł = HTML 5 |data dostępu = 2021-07-28 |opublikowany = www.w3.org |url = https://www.w3.org/TR/2008/WD-html5-20080610/comms.html#tcp-connections}}</ref> W czerwcu 2008 roku Michael Carter przeprowadził serię dyskusji w wyniku których powstała pierwsza wersja protokołu znanego obecnie jako WebSocket. <ref>{{Cytuj |tytuł = [whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg@whatwg.org from June 2008) |data dostępu = 2021-07-28 |opublikowany = lists.w3.org |url = https://lists.w3.org/Archives/Public/public-whatwg-archive/2008Jun/0165.html |język = en-us}}</ref>

Nazwa „WebSocket” została ukuta przez Iana Hicksona i Michaela Cartera podczas współpracy na kanale IRC #whatwg, <ref>{{Cytuj |tytuł = IRC logs: freenode / #whatwg / 20080618 |data dostępu = 2021-07-28 |opublikowany = krijnhoetmer.nl |url = https://krijnhoetmer.nl/irc-logs/whatwg/20080618.html |język = en-us}}</ref> a następnie włączona do specyfikacji HTML5 przez samego Hicksona. W grudniu 2009 r. Google Chrome 4 została pierwszą przeglądarką z pełną obsługą nową standardu, z domyślnie włączonym API WebSocket. <ref>{{Cytuj |tytuł = Web Sockets Now Available In Google Chrome |data dostępu = 2021-07-28 |opublikowany = Chromium Blog |url = https://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html |język = en}}</ref> Rozwój protokołu WebSocket został następnie przeniesiony z grup [[World Wide Web Consortium|W3C]] i [[Web Hypertext Application Technology Working Group|WHATWG]] do [[Internet Engineering Task Force|IETF]] w lutym 2010.

Po zakończeniu prac nad protokołem i jego domyślnym włączeniu w większości przeglądarek, standard <nowiki>RFC 6455</nowiki> został sfinalizowany przez Iana Fettera w grudniu 20211 roku.

<nowiki>RFC 7692</nowiki> wprowadził rozszerzenie kompresji wiadomości do WebSocket przy użyciu algorytmu DEFLATE.


== Przeglądarki wspierające WebSocket ==
== Przeglądarki wspierające WebSocket ==

Wersja z 20:32, 28 lip 2021

WebSocket
Platforma sprzętowa wieloplatformowy
Rodzaj Protokół komunikacyjny
Licencja 2-klauzulowa licencja BSD
Strona internetowa

WebSocket – jest protokołem komunikacyjnym, zapewniającym dwukierunkowy kanał wymiany danych poprzez pojedyncze połączenie TCP. Protokół WebSockets został ustandaryzowany przez IETF jako RFC 6455 w 2011 roku[1], a jego przeglądarkowe API podlega standaryzacji standaryzacji w W3C.

WebSockets różni się od protokołu HTTP. Oba protokoły są zlokalizowane na 7 warstwie w modelu OSI i zależą od TCP na warstwie 4. Pomimo faktu, że są one różne, standard RFC 6455 mówi, że WebSocket został zaprojektowany do działana na portach 80 i 443 przypisanych do HTTP, a także wspierać funkcje proxy i pośredników (intermediaries). Aby osiągnąć kompatybilność z HTTP, handshake WebSocket'u wykorzystuje nagłówek HTTP Upgrade[2], aby przełączyć komunikację z protokołu HTTP na WebSockets.

Protokół WebSocket umożliwia interakcję między przeglądarką internetową (lub inną aplikacją kliencką), a serwerem sieciowym przy niższym obciążeniu niż alternatywne rozwiązania półdupleksowe, takie jak np. odpytywanie HTTP (polling), ułatwiając przy tym znacznie przesyłanie danych w czasie rzeczywistym do i z serwera. Jest to możliwe dzięki zapewnieniu znormalizowanego sposobu wysyłania przez serwer treści do klienta bez uprzedniego żądania klienta i umożliwienia przesyłania komunikatów tam i z powrotem przy zachowaniu aktywnego połączenia. W ten sposób między klientem, a serwerem może odbywać się dwukierunkowa wymiana danych. Komunikacja odbywa się zwykle przez port TCP o numerze 443 (lub 80 w przypadku połączeń niezabezpieczonych), co jest korzystne w środowiskach, które blokują połączenia dla aplikacji innych niż przeglądarki internetowe (np. klienty Torrent, IRC). Przed pojawieniem się WebSocket'ów podobną dwukierunkową komunikację przeglądarka-serwer osiągano w niestandardowy sposób, wykorzystując technologie takie jak Comet czy Adobe Flash Player.[3]

Większość współczesnych przeglądarek obsługuje WebSocket'y, w tym m.in: Google Chrome, Firefox, Microsoft Edge, Internet Explorer, Safari i Opera.[4]

W przeciwieństwie do protokołu HTTP, WebSocket zapewnia komunikację w pełnym dupleksie. Dodatkowo WebSocket umożliwia przesyłanie wiadomości na wierzchu protokołu TCP. Sam protokół TCP obsługuje strumienie bajtów bez wbudowanej koncepcji wiadomości. Przed WebSocket komunikacja na porcie 80 w pełnym dupleksie była osiągalna przy użyciu kanałów Comet, jednak implementacja Comet nie jest trywialna, a ze względu na uzgadnianie TCP i obciążenie nagłówka HTTP jest nieefektywna w przypadku małych wiadomości. Protokół WebSocket ma na celu rozwiązanie tych problemów bez naruszania założeń bezpieczeństwa sieci.

Specyfikacja protokołu WebSocket definiuje ws (WebSocket) i wss (WebSocket Secure) jako dwa nowe schematy jednolitego identyfikatora zasobów (URI), które są używane odpowiednio do połączeń nieszyfrowanych i szyfrowanych. [5] Oprócz nazwy schematu i fragmentu (tj. # nie jest obsługiwany), pozostałe komponenty URI są zdefiniowane tak, aby używały ogólnej składni URI.[6]

Wykorzystując narzędzia developera w przeglądarce, twórcy stron mogą sprawdzić zarówno handshake WebSocket'u, jak i poszczególne paczki (frames). [7]

Historia

WebSocket'y zostały po raz pierwszy wymienione jako TCPConnection w bazowej specyfikacji HTML5, jako symbol zastępczy dla interfejsu (API) gniazda, opartego o protokół TCP.[8] W czerwcu 2008 roku Michael Carter przeprowadził serię dyskusji w wyniku których powstała pierwsza wersja protokołu znanego obecnie jako WebSocket. [9]

Nazwa „WebSocket” została ukuta przez Iana Hicksona i Michaela Cartera podczas współpracy na kanale IRC #whatwg, [10] a następnie włączona do specyfikacji HTML5 przez samego Hicksona. W grudniu 2009 r. Google Chrome 4 została pierwszą przeglądarką z pełną obsługą nową standardu, z domyślnie włączonym API WebSocket. [11] Rozwój protokołu WebSocket został następnie przeniesiony z grup W3C i WHATWG do IETF w lutym 2010.

Po zakończeniu prac nad protokołem i jego domyślnym włączeniu w większości przeglądarek, standard RFC 6455 został sfinalizowany przez Iana Fettera w grudniu 20211 roku.

RFC 7692 wprowadził rozszerzenie kompresji wiadomości do WebSocket przy użyciu algorytmu DEFLATE.

Przeglądarki wspierające WebSocket

WebSocket został zaimplementowany w przeglądarkach: Firefox 4, Google Chrome 4, Opera 11, Internet Explorer 10 oraz Safari 5 (również w mobilnym Safari dla iOS 4.2). Z powodu luk w zabezpieczeniach WebSocket został domyślnie wyłączony w Firefoksie 4 i Operze 11 do czasu ich naprawienia[12][13]. Aktualnie wszystkie najpopularniejsze przeglądarki wspierają tę technologię[14].

Układ URI

Specyfikacja WebSocket definiuje dwa nowe schematy URI, ws: i wss:, dla nieszyfrowanych i szyfrowanych połączeń. Dalsza część URI jest podobna jak w przypadku składni URI dla HTTP, z drobnymi wyjątkami (np. znak "#" nie jest traktowany jako oznaczenie początku fragmentu).

Nawiązywanie połączenia

Zasada działania jest taka, że przeglądarka nawiązuje połączenie za pomocą standardowego protokołu HTTP z portem 443 lub 80, po czym wysyła specjalny nagłówek HTTP Upgrade informujący o tym, że dalsza komunikacja w ramach tego połączenia ma być realizowana przy pomocy kanału WebSocket.

Zobacz też

Przypisy

  1. I. Fette, A. Melnikov, The WebSocket Protocol, RFC 6455, IETF, grudzień 2011, DOI10.17487/RFC6455, ISSN 2070-1721, OCLC 943595667 (ang.).
  2. rfc6455 [online], datatracker.ietf.org [dostęp 2021-07-28].
  3. Adobe Flash Platform * Sockets [online], help.adobe.com [dostęp 2021-07-28], Cytat: TCP connections require a “client” and a “server.” Flash Player can create client sockets. (ang.).
  4. WebSockets - Lista Web API | MDN [online], developer.mozilla.org [dostęp 2021-07-28] (ang.).
  5. Uniform Resource Identifier (URI) Schemes [online], www.iana.org [dostęp 2021-07-28] (ang.).
  6. Ian Fette, rfc6455 [online], datatracker.ietf.org [dostęp 2021-07-28].
  7. APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools, [w:] Vanessa Wang, The Definitive Guide to HTML5 WebSocket, Apress, ISBN 978-1-4302-4740-1.
  8. HTML 5 [online], www.w3.org [dostęp 2021-07-28].
  9. [whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg@whatwg.org from June 2008) [online], lists.w3.org [dostęp 2021-07-28] (ang.).
  10. IRC logs: freenode / #whatwg / 20080618 [online], krijnhoetmer.nl [dostęp 2021-07-28] (ang.).
  11. Web Sockets Now Available In Google Chrome [online], Chromium Blog [dostęp 2021-07-28] (ang.).
  12. Wpis na blogu Firefoksa dotyczący zablokowania WebSocket
  13. Wpis na blogu Opery dotyczący zablokowania WebSocket. [dostęp 2010-12-15]. [zarchiwizowane z tego adresu (2010-12-15)].
  14. Can I use Web Sockets [online], caniuse.com [dostęp 2017-11-15] (ang.).