WebSockets-protocol versus HTTP

Er zijn veel blogs en discussies over WebSocket en HTTP, en veel ontwikkelaars en sites pleiten sterk voor WebSockets, maar ik begrijp nog steeds niet waarom.

Bijvoorbeeld (argumenten van WebSocket-liefhebbers):

HTML5 Web Sockets vertegenwoordigt de volgende evolutie van webcommunicatie: een full-duplex, bidirectioneel communicatiekanaal dat via een enkele socket via het web werkt. – websocket.org

HTTP ondersteunt streaming: verzoeken om body-streaming (u gebruikt het terwijl u grote bestanden uploadt) en body-streaming van reacties.

Tijdens het maken van de verbinding met WebSocket wisselen client en server gegevens uit per frame, die elk 2 bytes zijn, vergeleken met 8 kilobytes HTTP-header bij continu pollen.

Waarom bevatten die 2 bytes geen TCP en overhead onder TCP-protocollen?

GET /about.html HTTP/1.1
Host: example.org

Dit is een HTTP-header van ~48 bytes.

HTTP chunked-codering – Chunked transfer-codering:

23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0

• Dus de overhead per stuk is niet groot.

Bovendien werken beide protocollen via TCP, dus alle TCP-problemen met langlevende verbindingen zijn er nog steeds.

Vragen:

1. Waarom is het WebSockets-protocol beter?
2. Waarom is het geïmplementeerd in plaats van het HTTP-protocol bij te werken?

Antwoord 1, autoriteit 100%

1) Waarom is het WebSockets-protocol beter?

WebSockets is beter voor situaties waarbij sprake is van communicatie met lage latentie, met name voor lage latentie voor client-naar-server-berichten. Voor server-naar-clientgegevens kunt u een redelijk lage latentie krijgen met behulp van langdurige verbindingen en gesegmenteerde overdracht. Dit helpt echter niet bij de latentie van client naar server, waarvoor een nieuwe verbinding tot stand moet worden gebracht voor elk client-naar-server-bericht.

Uw 48-byte HTTP-handshake is niet realistisch voor echte HTTP-browserverbindingen waarbij er vaak meerdere kilobytes aan gegevens worden verzonden als onderdeel van het verzoek (in beide richtingen), inclusief veel headers en cookiegegevens. Hier is een voorbeeld van een verzoek/antwoord op het gebruik van Chrome:

Voorbeeldverzoek (2800 bytes inclusief cookiegegevens, 490 bytes zonder cookiegegevens):

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]]]

Voorbeeldreactie (355 bytes):

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

Zowel HTTP als WebSockets hebben initiële verbindingshandshakes van vergelijkbare grootte, maar bij een WebSocket-verbinding wordt de initiële handshake één keer uitgevoerd en hebben kleine berichten slechts 6 bytes overhead (2 voor de header en 4 voor de maskerwaarde). De latency overhead is niet zozeer van de grootte van de headers, maar van de logica om die headers te ontleden/afhandelen/opslaan. Bovendien is de latentie bij het instellen van de TCP-verbinding waarschijnlijk een grotere factor dan de grootte of verwerkingstijd voor elk verzoek.

2) Waarom is het geïmplementeerd in plaats van het HTTP-protocol bij te werken?

Er zijn pogingen om het HTTP-protocol opnieuw te ontwerpen om betere prestaties en lagere latentie te bereiken, zoals SPDY, HTTP 2.0en QUIC. Dit zal de situatie voor normale HTTP-verzoeken verbeteren, maar het is waarschijnlijk dat WebSockets en/of WebRTC DataChannel nog steeds een lagere latentie hebben voor client-naar-server gegevensoverdracht dan het HTTP-protocol (of het zal worden gebruikt in een modus die veel lijkt op WebSockets hoe dan ook).

Bijwerken:

Hier is een raamwerk om over webprotocollen na te denken:

• TCP: laag-niveau, bidirectioneel, full-duplex en gegarandeerde ordertransportlaag. Geen browserondersteuning (behalve via plug-in/Flash).

• HTTP 1.0: verzoek-antwoord transportprotocol gelaagd op TCP. De client doet één volledig verzoek, de server geeft één volledig antwoord en vervolgens wordt de verbinding gesloten. De verzoekmethoden (GET, POST, HEAD) hebben een specifieke transactionele betekenis voor bronnen op de server.

• HTTP 1.1: behoudt het verzoek-antwoordkarakter van HTTP 1.0, maar zorgt ervoor dat de verbinding open blijft voor meerdere volledige verzoeken/volledige antwoorden (één antwoord per verzoek). Heeft nog steeds volledige headers in het verzoek en antwoord, maar de verbinding wordt opnieuw gebruikt en niet gesloten. HTTP 1.1 heeft ook enkele aanvullende aanvraagmethoden toegevoegd (OPTIONS, PUT, DELETE, TRACE, CONNECT) die ook specifieke transactionele betekenissen hebben. Zoals echter vermeld in de inleidingVolgens het HTTP 2.0-conceptvoorstel wordt HTTP 1.1-pipelining niet op grote schaal toegepast, dus dit beperkt het nut van HTTP 1.1 om latentie tussen browsers en servers op te lossen aanzienlijk.

• Long-poll: een soort “hack” naar HTTP (ofwel 1.0 of 1.1) waarbij de server niet onmiddellijk reageert (of slechts gedeeltelijk reageert met headers) op het verzoek van de klant . Na een serverreactie stuurt de client onmiddellijk een nieuw verzoek (met dezelfde verbinding als via HTTP 1.1).

• HTTP-streaming: een verscheidenheid aan technieken (multipart/chunked response) waarmee de server meer dan één respons op een enkel clientverzoek kan verzenden. Het W3C standaardiseert dit als Server-Sent Eventsmet behulp van een text/event-streamMIME-type. De browser-API (die redelijk vergelijkbaar is met de WebSocket-API) wordt de EventSource-API genoemd.

• Comet/server push: dit is een overkoepelende term die zowel long-poll als HTTP-streaming omvat. Comet-bibliotheken ondersteunen meestal meerdere technieken om te proberen de ondersteuning tussen verschillende browsers en servers te maximaliseren.

• WebSockets: een op transportlaag gebouwde TCP die gebruikmaakt van een HTTP-vriendelijke upgrade-handshake. In tegenstelling tot TCP, dat een streaming-transport is, is WebSockets een op berichten gebaseerd transport: berichten worden begrensd op de draad en worden volledig opnieuw samengesteld voordat ze bij de toepassing worden afgeleverd. WebSocket-verbindingen zijn bidirectioneel, full-duplex en hebben een lange levensduur. Na het eerste handshakeverzoek/-antwoord is er geen transactionele semantiek en is er zeer weinig overhead per bericht. De client en server kunnen op elk moment berichten verzenden en moeten de ontvangst van berichten asynchroon afhandelen.

• SPDY: een door Google geïnitieerd voorstel om HTTP uit te breiden met een efficiënter draadprotocol, maar met behoud van alle HTTP-semantiek (verzoek/antwoord, cookies, codering). SPDY introduceert een nieuw framing-formaat (met frames met een lengte-prefix) en specificeert een manier om HTTP-verzoek/antwoord-paren op de nieuwe framing-laag te stapelen. Headers kunnen worden gecomprimeerd en nieuwe headers kunnen worden verzonden nadat de verbinding tot stand is gebracht. Er zijn real-world implementaties van SPDY in browsers en servers.

• HTTP 2.0: heeft vergelijkbare doelen als SPDY: HTTP-latentie en overhead verminderen met behoud van HTTP-semantiek. Het huidige concept is afgeleid van SPDY en definieert een upgrade-handshake en dataframing die sterk lijkt op de WebSocket-standaard voor handshake en framing. Een alternatief HTTP 2.0-conceptvoorstel (httpbis-speed-mobility) gebruikt in feite WebSockets voor de transportlaag en voegt de SPDY-multiplexing en HTTP-mapping toe als een WebSocket-extensie (WebSocket-extensies worden onderhandeld tijdens de handshake).

• WebRTC/CU-WebRTC: voorstellen om peer-to-peer-connectiviteit tussen browsers mogelijk te maken. Dit kan communicatie met een lagere gemiddelde en maximale latentie mogelijk maken, omdat het onderliggende transport SDP/datagram is in plaats van TCP. Hierdoor kunnen pakketten/berichten buiten de bestelling worden afgeleverd, waardoor het TCP-probleem van latentiepieken wordt vermeden die worden veroorzaakt door weggevallen pakketten die de bezorging van alle volgende pakketten vertragen (om een ​​correcte bezorging te garanderen).

• QUIC: is een experimenteel protocol gericht op het verminderen van de weblatentie ten opzichte van die van TCP. Op het eerste gezicht lijkt QUIC erg op TCP+TLS+SPDY geïmplementeerd op UDP. QUIC biedt multiplexing en flow control equivalent aan HTTP/2, beveiliging equivalent aan TLS, en verbindingssemantiek, betrouwbaarheid en congestiecontrole equivalent aan TCP. Omdat TCP is geïmplementeerd in de kernels van het besturingssysteem en middlebox-firmware, is het vrijwel onmogelijk om significante wijzigingen aan te brengen in TCP. Omdat QUIC echter bovenop UDP is gebouwd, heeft het dergelijke beperkingen niet. QUIC is ontworpen en geoptimaliseerd voor HTTP/2-semantiek.

Referenties:

HTTP:

• Wikipedia HTTP-pagina
• W3C-lijst met HTTP-gerelateerde concepten/protocollen
• Lijst met IETF HTTP/1.1- en HTTP/2.0-concepten

Server-verzonden gebeurtenis:

• W3C Server-Sent Events/EventSource Kandidaataanbeveling
• W3C Server-Sent Events/EventSource Draft

WebSockets:

• IETF RFC 6455 WebSockets-protocol
• IETF RFC 6455 WebSocket Errata

SPDY:

• IETF SPDY-concept

HTTP 2.0:

• IETF HTTP 2.0 httpbis-http2 Draft
• IETF HTTP 2.0 httpbis-speed-mobility Concept
• IETF httpbis-netwerkvriendelijk concept– een ouder HTTP 2.0-gerelateerd voorstel

WebRTC:

• W3C WebRTC API-concept
• Lijst met IETF WebRTC-concepten
• IETF WebRTC-overzicht Concept
• IETF WebRTC DataChannel Draft
• Startpagina Microsoft CU-WebRTC-voorstel

QUIC:

• QUIC Chrominum-project
• IETF QUIC-concept

Antwoord 2, autoriteit 26%

U lijkt aan te nemen dat WebSocket een vervanging is voor HTTP. Het is niet. Het is een extensie.

De belangrijkste use-case van WebSockets zijn Javascript-toepassingen die in de webbrowser worden uitgevoerd en realtime gegevens van een server ontvangen. Games zijn een goed voorbeeld.

Vóór WebSockets was de enige methode voor JavaScript-toepassingen om met een server te communiceren via XmlHttpRequest. Maar deze hebben een groot nadeel: de server kan geen gegevens verzenden tenzij de client hier expliciet om heeft gevraagd.

Maar met de nieuwe WebSocket-functie kan de server gegevens verzenden wanneer hij maar wil. Dit maakt het mogelijk om browsergebaseerde games te implementeren met een veel lagere latentie en zonder lelijke hacks zoals AJAX long-polling of browser-plug-ins.

Dus waarom geen normale HTTP gebruiken met gestreamde verzoeken en antwoorden

In een opmerking bij een ander antwoord dat je voorstelde om het verzoek van de klant en de hoofdtekst van de reactie gewoon asynchroon te streamen.

In feite zijn WebSockets dat eigenlijk. Een poging om een ​​WebSocket-verbinding van de client te openen, lijkt in eerste instantie op een HTTP-verzoek, maar een speciale instructie in de header (Upgrade: websocket) vertelt de server om te beginnen met communiceren in deze asynchrone modus. Eerste concepten van het WebSocket-protocolwaren niet veel meer dan dat en wat handshaking om ervoor te zorgen dat de server echt begrijpt dat de client asynchroon wil communiceren. Maar toen realiseerde men zich dat proxyservers daardoor in de war zouden raken, omdat ze gewend zijn aan het gebruikelijke request/response-model van HTTP. Een mogelijk aanvalsscenariotegen proxyservers ontdekt. Om dit te voorkomen was het nodig om WebSocket-verkeer er anders uit te laten zien dan normaal HTTP-verkeer. Daarom zijn de maskeersleutels geïntroduceerd in de definitieve versie van het protocol.

Antwoord 3, autoriteit 11%

Een reguliere REST API gebruikt HTTP als het onderliggende protocol voor communicatie, dat het verzoek- en antwoordparadigma volgt, wat betekent dat de communicatie inhoudt dat de client bepaalde gegevens of bronnen van een server opvraagt, en de server reageert op die client. HTTP is echter een staatloos protocol, dus elke aanvraag-antwoordcyclus zal uiteindelijk de header- en metadata-informatie moeten herhalen. Dit brengt extra latentie met zich mee in het geval van vaak herhaalde verzoek-antwoordcycli.

Met WebSockets, hoewel de communicatie nog steeds begint als een initiële HTTP-handshake, wordt deze verder geüpgraded om het WebSockets-protocol te volgen (dwz als zowel de server als de client compatibel zijn met het protocol, aangezien niet alle entiteiten het WebSockets-protocol ondersteunen) .

Met WebSockets is het nu mogelijk om een ​​full-duplex en persistente verbinding tot stand te brengen tussen de client en een server. Dit betekent dat, in tegenstelling tot een verzoek en een antwoord, de verbinding open blijft zolang de toepassing actief is (dat wil zeggen het is persistent), en aangezien het full-duplex is, is gelijktijdige tweerichtingscommunicatie mogelijk, dwz dat de server nu in staat is om het initiëren van communicatie en ‘push’ sommige gegevens naar de klant wanneer nieuwe gegevens (waar de klant in geïnteresseerd is) beschikbaar komen.

Het Protocol van WebSockets is beletbaar en stelt u in staat het Publish-Abonneer (of PUB / SUB) Messaging Pattern te implementeren, dat het primaire concept is dat wordt gebruikt in de real-time technologieën, waarbij u in staat bent om nieuwe updates in de vorm van de server te krijgen Duw zonder dat de klant moet vragen (vernieuw de pagina) herhaaldelijk. Voorbeelden van dergelijke toepassingen zijn Uber Car’s Location Tracking, Push-meldingen, beursprijzen bijwerken in real-time, chat, multiplayer-spellen, live online samenwerkingsinstrumenten, enz.

U kunt een diepe duikartikel bekijken op WebSockets, wat de geschiedenis van dit protocol verklaart, hoe het ontstond, waar het voor wordt gebruikt en hoe u het zelf kunt implementeren.

Hier is een video van een presentatie die ik heb gedaan met Websockets en hoe ze anders zijn dan het gebruik van de reguliere rust-API’s: normalisatie en gebruikmakend van de exponentiële stijging van de gegevensstreaming

Antwoord 4, Autoriteit 6%

voor de TL; DR, hier zijn 2 cent en een eenvoudiger versie voor uw vragen:

1. WebSockets biedt deze voordelen via http:

   • Persistent Stateful Connection voor de duur van de verbinding
   • Lage latentie: bijna-real-time communicatie tussen server / klant vanwege geen overhead van herstelbare verbindingen voor elk verzoek zoals HTTP vereist.
   • Volledige duplex: zowel server als klant kunnen tegelijkertijd verzenden / ontvangen

2. Websocket en HTTP-protocol zijn ontworpen om verschillende problemen op te lossen, d.w.z. WebSocket is ontworpen om de bi-directionele communicatie te verbeteren, terwijl HTTP is ontworpen om te worden gedistribueerd met behulp van een verzoek / responsmodel. Anders dan het delen van de havens om oudere redenen (firewall / proxy-penetratie), is er niet veel voorkomende grond om ze in één protocol te combineren.

Antwoord 5, Autoriteit 4%

Waarom is het WebSockets Protocol beter?

Ik denk niet dat we ze naast elkaar kunnen vergelijken zoals die beter is. Dat zal een eerlijke vergelijking niet zijn, gewoon omdat ze twee verschillende problemen oplossen. Hun vereisten zijn anders. Het zal zijn als het vergelijken van appels voor sinaasappels. Ze zijn anders.

HTTP is een verzoek-respons-protocol. De klant (browser) wil iets, de server geeft het. Dat is. Als de Data Client wil is, kan de server streaminggegevens verzenden naar ongegrond ongewenste bufferproblemen. Hier is de belangrijkste vereiste of probleem hoe het verzoek van klanten te maken en hoe respons de bronnen (hypertext) die ze aanvragen. Dat is waar HTTP Shine.

In HTTP, alleen klantverzoeken. De server reageert alleen.

WebSocket is geen aanvraag-responsprotocol waarbij alleen de klant kan aanvragen. Het is een socket (vergelijkbaar met TCP-aansluiting). Gemiddeld nadat de verbinding open is, kan beide zijden gegevens verzenden totdat de onderstreping van TCP-verbinding gesloten is. Het is net als een normale aansluiting. Het enige verschil met TCP-aansluiting is WEBSOFFOFFOF kan op internet worden gebruikt. Op internet hebben we veel beperkingen op een normale aansluiting. De meeste firewalls blokkeren andere poorten dan 80 en 433 die HTTP gebruikt. Proxy’s en tussenpersonen zijn ook problematisch. Dus om het protocol gemakkelijker te maken om te implementeren aan bestaande infrastructuren, gebruikt WebSocket HTTP-handshake om te upgraden. Dat betekent dat wanneer de eerste keer verbinding gaat openen, de client een HTTP-verzoek heeft verzonden om de server te vertellen: “Dat is geen HTTP-aanvraag, upgrade naar Websocket Protocol”.

Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

Nadat de server het verzoek begrijpt en opgewaardeerd naar Websocket Protocol, heeft geen van de HTTP-protocollen meer toegepast.

Dus mijn antwoord is geen van beide is beter dan elkaar. Ze zijn helemaal anders.

Waarom is het geïmplementeerd in plaats van het updaten van het HTTP-protocol?

Nou, we kunnen ook alles maken onder de naam HTTP. Maar zullen we? Als het twee verschillende dingen zijn, geef ik de voorkeur aan twee verschillende namen. Hetzelfde geldt voor Hickson en Michael Carter .

Antwoord 6

De andere antwoorden lijken hier geen belangrijk aspect te raken, en dat is dat u niet vermeldt dat u als client een webbrowser moet ondersteunen. De meeste beperkingen van gewoon HTTP hierboven gaan ervan uit dat u met browser/JS-implementaties zou werken.

Het HTTP-protocol is volledig in staat tot full-duplex communicatie; het is legaal om een ​​client een POST te laten uitvoeren met een overdracht van gesegmenteerde codering en een server om een ​​antwoord te retourneren met een tekst met gesegmenteerde codering. Dit zou de overhead van de kop verwijderen tot net op de init-tijd.

Dus als alles wat je zoekt full-duplex is, zowel de client als de server bestuurt, en niet geïnteresseerd bent in extra framing/functies van WebSockets, dan zou ik zeggen dat HTTP een eenvoudigere benadering is met een lagere latentie/CPU ( hoewel de latentie voor beide slechts in microseconden of minder zou verschillen).