streamalism.org

1. Oversikt

I denne opplæringen vil vi gå gjennom det grunnleggende om klient-server-kommunikasjon og utforske dette gjennom to populære alternativer som er tilgjengelige i dag. Vi får se hvordan WebSocket, som er en ny aktør, går mot det mer populære valget av RESTful HTTP.

2. Grunnleggende om nettverkskommunikasjon

Før vi dykker ned i detaljene til forskjellige alternativer og fordeler og ulemper, la oss raskt oppdatere landskapet i nettverkskommunikasjon. Dette vil bidra til å sette ting i perspektiv og forstå dette bedre.

Nettverkskommunikasjon kan best forstås i form av OSI-modellen (Open Systems Interconnection).

OSI-modellen deler kommunikasjonssystemet i syv abstraksjonslag:

På toppen av denne modellen er applikasjonslaget som er av vår interesse i denne opplæringen. Imidlertid vil vi diskutere noen aspekter i de fire øverste lagene mens vi sammenligner WebSocket og RESTful HTTP.

Applikasjonslaget er nærmest sluttbrukeren og er ansvarlig for grensesnittet med applikasjonene som deltar i kommunikasjonen. Det er flere populære protokoller som brukes i dette laget som FTP, SMTP, SNMP, HTTP og WebSocket.

3. Beskrive WebSocket og RESTful HTTP

Mens kommunikasjon kan skje mellom et hvilket som helst antall systemer, er vi spesielt interessert i klient-server-kommunikasjon. Mer spesifikt vil vi fokusere på kommunikasjon mellom en nettleser og en webserver. Dette er rammen vi vil bruke til å sammenligne WebSocket med RESTful HTTP.

Men før vi går videre, hvorfor ikke fort forstå hva de er!

3.1. WebSockets

Som den formelle definisjonen går, WebSocket er en kommunikasjonsprotokoll som har toveis kommunikasjon med full dupleks over en vedvarende TCP-forbindelse. Nå vil vi forstå hver del av denne uttalelsen i detalj når vi går videre.

WebSocket ble standardisert som en kommunikasjonsprotokoll av IETF som RFC 6455 i 2011. De fleste moderne nettlesere støtter i dag WebSocket-protokollen.

3.2. RESTful HTTP

Mens vi alle er klar over HTTP på grunn av dets allestedsnærværende tilstedeværelse på internett, er det også en applikasjonslagskommunikasjonsprotokoll. HTTP er en forespørselsresponsbasert protokolligjen vil vi forstå dette bedre senere i opplæringen.

REST (Representational State Transfer) er en arkitektonisk stil som setter et sett med begrensninger for HTTP for å opprette webtjenester.

4. WebSocket subprotocol

Mens WebSocket definerer en protokoll for toveiskommunikasjon mellom klient og server, det setter ingen betingelser for meldingen som skal utveksles. Dette er åpent for partene i kommunikasjonen å bli enige om som en del av forhandlinger om subprotocol.

Det er ikke praktisk å utvikle en subprotokol for ikke-trivielle applikasjoner. Heldigvis, det er mange populære subprotocols som STOMP tilgjengelig for bruk. STOMP står for Simple Text Oriented Messaging Protocol og fungerer over WebSocket. Spring Boot har førsteklasses støtte for STOMP, som vi bruker i vår veiledning.

5. Hurtigoppsett i Spring Boot

Det er ingenting bedre enn å se et fungerende eksempel. Så vi bygger enkle brukstilfeller i både WebSocket og RESTful HTTP for å utforske dem videre og deretter sammenligne dem. La oss lage en enkel server og klientkomponent for begge.

Vi oppretter en enkel klient ved hjelp av JavaScript som sender et navn. Og vi oppretter en server ved hjelp av Java som vil svare med en hilsen.

5.1. WebSocket

For å bruke WebSocket i Spring Boot, trenger vi riktig startpakke:

 org.springframework.boot spring-boot-starter-websocket 

Vi konfigurerer nå STOMP-endepunktene:

@Configuration @EnableWebSocketMessageBroker offentlig klasse WebSocketMessageBrokerConfig implementerer WebSocketMessageBrokerConfigurer {@ Override public void registerStompEndpoints (StompEndpointRegistry registry) {registry.addEndpoint ("/ ws"); } @Override public void configureMessageBroker (MessageBrokerRegistry config) {config.setApplicationDestinationPrefixes ("/ app"); config.enableSimpleBroker ("/ topic"); }}

La oss raskt definere en enkel WebSocket-server som godtar et navn og svarer med en hilsen:

@Controller offentlig klasse WebSocketController {@MessageMapping ("/ hallo") @SendTo ("/ topic / greetings") offentlig hilsenhilsen (meldingsmelding) kaster unntak {return new Greeting ("Hello," + HtmlUtils.htmlEscape (message.getName ()) + "!"); }}

Til slutt, la oss bygge klienten til å kommunisere med denne WebSocket-serveren. Når vi legger vekt på kommunikasjon mellom nettleser og server, la oss opprette en klient i JavaScript:

var stompClient = null; funksjonskobling () {stompClient = Stomp.client ('ws: // localhost: 8080 / ws'); stompClient.connect ({}, function (frame) {stompClient.subscribe ('/ topic / greetings', function (response) {showGreeting (JSON.parse (response.body) .content);});}); } funksjon sendName () {stompClient.send ("/ app / hallo", {}, JSON.stringify ({'name': $ ("# name"). val ()})); } funksjon showGreeting (melding) {$ ("# hilsener"). legg til (""+ melding +""); }

Dette fullfører vårt arbeidseksempel på en WebSocket-server og klient. Det er en HTML-side i kodelageret som gir et enkelt brukergrensesnitt å samhandle med.

Mens dette bare klør overflaten, kan WebSocket med Spring brukes til å bygge komplekse chatklienter og mer.

5.2. RESTful HTTP

Vi vil gå gjennom et lignende oppsett for RESTful service nå. Vår enkle nettjeneste vil godta en GET-forespørsel med navn og svare med en hilsen.

La oss bruke Spring Boots webstarter i stedet denne gangen:

 org.springframework.boot spring-boot-starter-web 

Nå vil vi definere et REST-endepunkt som bruker kraftig kommentarstøtte tilgjengelig på våren:

@RestController @RequestMapping (sti = "/ rest") offentlig klasse RestAPIController {@GetMapping (sti = "/ {name}", produserer = "applikasjon / json") offentlig String getGreeting (@PathVariable ("navn") Strengnavn) {return "{\" hilsen \ ": \" Hei, "+ navn +"! \ "}"; }}

Til slutt, la oss opprette en klient i JavaScript:

var request = new XMLHttpRequest () function sendName () {request.open ('GET', '// localhost: 8080 / rest /' + $ ("# name"). val (), true) request.onload = function () {var data = JSON.parse (this.response) showGreeting (data.greeting)} request.send ()} funksjon showGreeting (melding) {$ ("# hilsener"). append (""+ melding +""); }

Det er ganske mye det! Igjen er det en HTML-side i kodelageret som fungerer med et brukergrensesnitt.

Selv om det er dypt enkelt, kan det være mye mer omfattende å definere REST API for produksjonsklasse!

6. Sammenligning av WebSocket og RESTful HTTP

Etter å ha skapt minimale, men fungerende eksempler på WebSocket og RESTful HTTP, er vi nå klare til å forstå hvordan de går mot hverandre. Vi vil undersøke dette mot flere kriterier i de neste underavsnittene.

Det er viktig å merke seg at mens vi direkte kan sammenligne HTTP og WebSocket ettersom de begge er applikasjonslagsprotokoller, det er ikke naturlig å sammenligne REST mot WebSocket. Som vi så tidligere, er REST en arkitektonisk stil som utnytter HTTP for kommunikasjon.

Derfor vår sammenligning med WebSocket vil for det meste dreie seg om mulighetene eller mangelen på HTTP.

6.1. URL-ordning

En URL definerer den unike plasseringen til en nettressurs og mekanisme for å hente den. I en klient-server-kommunikasjon ønsker vi oftere enn ikke å få statiske eller dynamiske ressurser gjennom deres tilknyttede URL.

Vi er alle kjent med HTTP URL-ordningen:

// localhost: 8080 / hvile

WebSocket URL-ordningen er heller ikke mye annerledes:

ws: // localhost: 8080 / ws

I begynnelsen ser det ut til at den eneste forskjellen er tegnene før kolon, men det abstrakte mye som skjer under panseret. La oss utforske videre.

6.2. Håndtrykk

Håndtrykkrefererer til den automatiske måten å forhandle kommunikasjonsprotokoll mellom kommuniserende parter på. HTTP er en statsløs protokoll og fungerer i en forespørselsresponsmekanisme. På hver HTTP-forespørsel opprettes en TCP-forbindelse med serveren over kontakten.

Klienten venter deretter til serveren svarer med ressursen eller en feil. Neste forespørsel fra klienten gjentar alt som om forrige forespørsel aldri skjedde:

WebSocket fungerer veldig forskjellig i forhold til HTTP og starter med et håndtrykk før faktisk kommunikasjon.

La oss se hva som består av et WebSocket-håndtrykk:

I tilfelle WebSocket, klienten initierer en Protocol Handshake-forespørsel i HTTP og venter deretter til serveren svarer og godtar en oppgradering til WebSocket fra HTTP.

Siden Protocol Handshake skjer over HTTP, følger det selvfølgelig sekvensen fra forrige diagram. Men når forbindelsen er opprettet, bytter klient og server til WebSocket for videre kommunikasjon derfra.

6.3. Forbindelse

Som vi så i forrige underavsnitt, er en sterk forskjell mellom WebSocket og HTTP at WebSocket fungerer på en vedvarende TCP-tilkobling mens HTTP oppretter en ny TCP-tilkobling for hver forespørsel.

Nå er det åpenbart ikke veldig bra å opprette ny TCP-forbindelse for hver forespørsel, og HTTP har ikke vært klar over dette. Faktisk, som en del av HTTP / 1.1, ble det innført vedvarende tilkoblinger for å lindre denne mangelen på HTTP.

Likevel, WebSocket er designet fra grunnen av for å fungere med vedvarende TCP-tilkoblinger.

6.4. Kommunikasjon

Fordelen med WebSocket over HTTP er et spesifikt scenario som oppstår fra det faktum at klienten kan servere kan kommunisere på måter som ikke var mulig med god gammel HTTP.

For eksempel i HTTP sender klienten vanligvis den forespørselen, og deretter svarer serveren med forespurte data. Det er ingen generisk måte for serveren å kommunisere med klienten alene. Selvfølgelig er det utviklet mønstre og løsninger for å omgå dette som Server-Sent Events (SSE), men disse var ikke helt naturlige.

Med WebSocket jobber du med vedvarende TCP-kommunikasjon, det er mulig for server og klient begge å sende data uavhengig av hverandre, og faktisk til mange kommuniserende parter! Dette er referert til som toveiskommunikasjon.

Et annet interessant trekk ved WebSocket-kommunikasjon er at det er full dupleks. Nå mens dette begrepet kanskje høres esoterisk ut; det betyr ganske enkelt det både server og klient kan sende data samtidig. Sammenlign dette med hva som skjer i HTTP der serveren må vente til den mottar forespørselen i sin helhet før den kan svare med data.

Mens fordelene med toveiskommunikasjon og full-dupleks-kommunikasjon kanskje ikke kommer til syne umiddelbart. vi får se noen av brukssakene der de låser opp virkelig kraft.

6.5. Sikkerhet

Sist men ikke minst, både HTTP og WebSocket utnytter fordelene med TLS for sikkerhet. Mens HTTP tilbyr https som en del av deres URL-ordning for å bruke dette, har WebSocket wss som en del av URL-ordningen for samme effekt.

Så den sikre versjonen av nettadresser fra forrige underavsnitt skal se ut:

// localhost: 443 / rest wss: // localhost: 443 / ws

Sikring av enten en RESTful-tjeneste eller en WebSocket-kommunikasjon er gjenstand for mye dybde og kan ikke dekkes her. For nå, la oss bare si at begge er tilstrekkelig støttet i denne forbindelse.

6.6. Opptreden

Vi må forstå at WebSocket er en stateful protokoll der kommunikasjon skjer via en dedikert TCP-forbindelse. På den annen side er HTTP iboende en statsløs protokoll. Dette har innvirkning på hvordan disse vil prestere med lasten, men det avhenger egentlig av brukssaken.

Siden kommunikasjon via WebSocket skjer over en gjenbrukbar TCP-forbindelse, er kostnaden per melding lavere sammenlignet med HTTP. Derfor kan den nå høyere gjennomstrømning per server. Men det er en grense som en enkelt server kan skalere, og det er der WebSocket har problemer. Det er ikke lett å skalere applikasjoner horisontalt med WebSockets.

Dette er hvor HTTP skinner. Med HTTP kan hver nye forespørsel potensielt lande på en hvilken som helst server. Dette innebærer at for å øke den totale gjennomstrømningen kan vi enkelt legge til flere servere. Dette kan potensielt ikke ha noen innvirkning på applikasjonen som kjører med HTTP.

Åpenbart kan et program i seg selv trenge tilstand og økt klistrethet som kan gjøre det lettere sagt enn gjort.

7. Hvor skal vi bruke dem?

Nå har vi sett nok av RESTful service over HTTP og enkel kommunikasjon over WebSocket til å danne vår mening rundt dem. Men hvor skal vi bruke hva?

Det er viktig å huske at mens WebSocket har kommet ut av mangler i HTTP, er det faktisk ikke en erstatning for HTTP. Så de har begge sin plass og sine bruksområder. La oss raskt forstå hvordan vi kan ta en beslutning.

For det meste av scenariet der det er behov for sporadisk kommunikasjon med serveren som å få oversikt over en ansatt, er det fortsatt fornuftig å bruke REST-tjenesten over HTTP / S. Men for nyere applikasjoner på klientsiden, som et aksjekursprogram som krever sanntidsoppdateringer fra serveren, er det mye praktisk å utnytte WebSocket.

Generalisering, WebSocket er mer egnet for tilfeller der en push-basert og sanntidskommunikasjon definerer kravet mer hensiktsmessig. I tillegg WebSocket fungerer bra for scenarier der en melding må skyves til flere klienter samtidig. Dette er tilfellene der klient- og serverkommunikasjon over RESTful-tjenester vil finne det vanskelig om ikke uoverkommelig.

Ikke desto mindre må bruken av WebSocket og RESTful-tjenester over HTTP trekkes fra kravene. Som om det ikke er sølvkuler, kan vi ikke bare forvente å velge en for å løse alle problemer. Derfor må vi bruke vår visdom kombinert med kunnskap i utformingen av en effektiv kommunikasjonsmodell.

8. Konklusjon

I denne opplæringen gjennomgikk vi det grunnleggende om nettverkskommunikasjon med vekt på applikasjonslagsprotokoller HTTP og WebSocket. Vi så noen raske demonstrasjoner av WebSocket og RESTful API over HTTP i Spring Boot.

Og til slutt sammenlignet vi funksjonene i HTTP- og WebSocket-protokoller og diskuterte kort når de skulle brukes.

Som alltid er koden for eksemplene tilgjengelig på GitHub.