streamalism.org

1. Áttekintés

Ebben az oktatóanyagban áttekintjük az ügyfél-szerver kommunikáció alapjait, és ezt a ma elérhető két népszerű lehetőség segítségével vizsgáljuk meg. Meglátjuk, hogy az új belépő WebSocket hogyan áll szemben a RESTful HTTP népszerűbb választásával.

2. A hálózati kommunikáció alapjai

Mielőtt elmélyülnénk a különféle lehetőségek részleteiben, valamint azok előnyeiben és hátrányaiban, frissítsük gyorsan a hálózati kommunikáció táját. Ez segít a dolgok perspektívába helyezésében és ennek jobb megértésében.

A hálózati kommunikáció leginkább az Open Systems Interconnection (OSI) modell alapján érthető meg.

Az OSI modell az absztrakció hét rétegére osztja fel a kommunikációs rendszert:

A modell tetején található az Alkalmazás réteg, amely érdekel minket ebben az oktatóanyagban. A WebSocket és a RESTful HTTP összehasonlításakor azonban néhány szempontot a négy legfelső rétegben tárgyalunk.

Az alkalmazásréteg a legközelebb van a végfelhasználóhoz, és felelős a kommunikációban részt vevő alkalmazásokkal való interakcióért. Számos népszerű protokoll létezik ebben a rétegben, például FTP, SMTP, SNMP, HTTP és WebSocket.

3. A WebSocket és a RESTful HTTP leírása

Bár a kommunikáció bármennyi rendszer között megtörténhet, minket különösen az ügyfél-szerver kommunikáció érdekel. Pontosabban a webböngésző és a webszerver közötti kommunikációra fogunk összpontosítani. Ezt a keretet fogjuk használni a WebSocket és a RESTful HTTP összehasonlításához.

De mielőtt tovább haladnánk, miért ne érthetné meg gyorsan, hogy mik azok!

3.1. WebSockets

A hivatalos meghatározás szerint A WebSocket egy kommunikációs protokoll, amely kétirányú, teljes duplex kommunikációt tartalmaz tartós TCP kapcsolaton keresztül. Most részletesen meg fogjuk érteni a kijelentés egyes részeit.

A WebSocket-et 2011-ben az IETF RFC 6455 néven szabványosította kommunikációs protokollként. A legtöbb modern webböngésző ma támogatja a WebSocket protokollt.

3.2. RESTful HTTP

Noha mindannyian tisztában vagyunk a HTTP-vel, mivel mindenütt jelen van az interneten, egyúttal egy alkalmazási réteg kommunikációs protokoll is. A HTTP egy kérés-válasz alapú protokoll, megint jobban megértjük ezt később az oktatóanyagban.

A REST (reprezentatív állapotátvitel) olyan építészeti stílus, amely korlátozásokat állít a HTTP-re webszolgáltatások létrehozására.

4. WebSocket alprotokoll

Míg a WebSocket protokollt határoz meg az ügyfél és a szerver közötti kétirányú kommunikációhoz, nem tesz semmilyen feltételt a kicserélendő üzenetre. Ez nyitva marad a kommunikációban részt vevő felek számára, hogy megállapodjanak az alprotokoll-tárgyalások részeként.

Nem kényelmes alprotokoll kifejlesztése nem triviális alkalmazásokhoz. Szerencsére, sok népszerű alprotokoll használható, mint a STOMP. A STOMP az egyszerű szövegorientált üzenetküldési protokollt jelenti, és a WebSocketen keresztül működik. A Spring Boot első osztályú támogatást nyújt a STOMP számára, amelyet ki fogunk használni a bemutatónkban.

5. Gyors beállítás a tavaszi indításkor

Nincs annál jobb, mint egy működő példát látni. Tehát egyszerű használati eseteket építünk fel a WebSocket-ben és a RESTful HTTP-ben is, hogy tovább vizsgáljuk őket, majd összehasonlítsuk őket. Hozzunk létre egy egyszerű kiszolgáló és kliens komponenst mindkettőhöz.

Létrehozunk egy egyszerű klienst a JavaScript használatával, amely nevet küld. És létrehozunk egy szervert a Java segítségével, amely üdvözlettel válaszol.

5.1. WebSocket

A WebSocket Spring Boot használatához szükségünk lesz a megfelelő indítóra:

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

Most konfiguráljuk a STOMP végpontokat:

@Configuration @EnableWebSocketMessageBroker nyilvános osztály WebSocketMessageBrokerConfig valósítja meg a WebSocketMessageBrokerConfigurer {@Override public void registerStompEndpoints (StompEndpointRegistry registry) {register.addEndpoint ("/ ws"); } @Orride public void configureMessageBroker (MessageBrokerRegistry config) {config.setApplicationDestinationPrefixes ("/ app"); config.enableSimpleBroker ("/ topic"); }}

Határozzunk meg gyorsan egy egyszerű WebSocket kiszolgálót, amely elfogad egy nevet és üdvözlettel válaszol:

@Controller nyilvános osztály WebSocketController {@MessageMapping ("/ hello") @SendTo ("/ topic / greetings") nyilvános üdvözlő üdvözlet (Üzenet) dobja a Kivételt {return new Greeting ("Hello, + HtmlUtils.htmlEscape (message.getName) ()) + "!"); }}

Végül hozzuk létre az ügyfelet, hogy kommunikáljon ezzel a WebSocket szerverrel. Mivel a böngésző-szerver kommunikációra helyezzük a hangsúlyt, hozzunk létre egy klienst JavaScript-ben:

var stompClient = null; function connect () {stompClient = Stomp.client ('ws: // localhost: 8080 / ws'); stompClient.connect ({}, function (frame) {stompClient.subscribe ('/ topic / greetings', function (response) {showGreeting (JSON.parse (response.body) .content);});}); } function sendName () {stompClient.send ("/ app / hello", {}, JSON.stringify ({'név': $ ("# név"). val ()})); } function showGreeting (message) {$ ("# greetings"). append (""+ üzenet +""); }

Ezzel befejeződött a WebSocket szerver és kliens működő példája. A kódtárban található egy HTML oldal, amely egyszerű felhasználói felületet biztosít a kommunikációhoz.

Míg ez csak megkarcolja a felületet, a Spring szoftverrel ellátott WebSocket összetett csevegőprogramok és egyebek létrehozására használható.

5.2. RESTful HTTP

Most át fogunk menni egy hasonló beállításon a RESTful szolgáltatáshoz. Egyszerű webes szolgáltatásunk elfogad egy névvel ellátott GET kérést, és üdvözlettel válaszol.

Használjuk ezúttal a Spring Boot webes indítóját:

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

Most meghatározzunk egy REST végpontot, amely kihasználja a tavasszal elérhető, hatékony kommentálási támogatást:

@RestController @RequestMapping (path = "/ rest") public class RestAPIController {@GetMapping (path = "/ {name}", tuottaa = "application / json") public String getGreeting (@PathVariable ("name") String name) {return "{\" üdvözlet \ ": \" Hello, "+ név +"! \ "}"; }}

Végül hozzunk létre egy klienst JavaScript-ben:

var request = új XMLHttpRequest () függvény sendName () {request.open ('GET', '// localhost: 8080 / rest /' + $ ("# name"). val (), true) request.onload = function () {var data = JSON.parse (this.response) showGreeting (data.greeting)} request.send ()} function showGreeting (message) {$ ("# greetings"). append (""+ üzenet +""); }

Nagyjából ennyi! Ismét van egy HTML oldal a kódtárban, amely a felhasználói felülettel működik.

Bár az egyszerűségében mélyreható, a gyártási fokozatú REST API meghatározása sokkal kiterjedtebb feladat lehet!

6. A WebSocket és a RESTful HTTP összehasonlítása

A WebSocket és a RESTful HTTP minimális, de működőképes példáinak létrehozása után készen állunk megérteni, hogy állnak egymással. Ezt a következő alszakaszokban több szempont alapján megvizsgáljuk.

Fontos megjegyezni, hogy bár közvetlenül összehasonlíthatjuk a HTTP-t és a WebSocket-et, mivel mindkettő alkalmazásréteg-protokoll, nem természetes a REST és a WebSocket összehasonlítása. Mint korábban láttuk, a REST egy építészeti stílus, amely a HTTP-t használja a kommunikációhoz.

Ennélfogva a WebSocket-hez való összehasonlításunk többnyire a HTTP képességeire vagy azok hiányára vonatkozik.

6.1. URL-séma

URL meghatározza a webes erőforrás egyedi helyét és a lekérés mechanizmusát. Az ügyfél-szerver kommunikáció során gyakran statikus vagy dinamikus erőforrásokra törekszünk a hozzájuk tartozó URL-en keresztül.

Mindannyian ismerjük a HTTP URL sémát:

// localhost: 8080 / rest

A WebSocket URL-sémája sem sokban különbözik:

ws: // localhost: 8080 / ws

Először úgy tűnik, hogy az egyetlen különbség a kettőspont előtti karakterek között van, de sokat elvont, ami a motorháztető alatt történik. Fedezzük tovább.

6.2. Kézfogás

Kézfogása kommunikációs felek közötti kommunikációs protokoll tárgyalásának automatikus módjára utal. A HTTP hontalan protokoll, és egy kérés-válasz mechanizmusban működik. Minden HTTP-kéréskor TCP-kapcsolat jön létre a szerverrel a foglalaton keresztül.

Ezután az ügyfél megvárja, amíg a kiszolgáló válaszol az erőforrással vagy hibával. A kliens következő kérése mindent megismétel, mintha az előző kérés soha nem történt volna meg:

A WebSocket nagyon másképp működik, mint a HTTP, és kézfogással kezdődik a tényleges kommunikáció előtt.

Nézzük meg, mi foglal magában egy WebSocket kézfogást:

WebSocket esetén, az ügyfél kezdeményez egy protokoll kézfogási kérést HTTP-ben, majd megvárja, amíg a kiszolgáló válaszol a WebSocket HTTP-frissítésének elfogadására.

Természetesen, mivel a Protocol Handshake HTTP-n keresztül történik, az előző diagram sorrendjét követi. De miután a kapcsolat létrejött, onnan az ügyfél és a szerver átáll a WebSocketre a további kommunikáció érdekében.

6.3. Kapcsolat

Amint azt az előző alfejezetben láthattuk, a WebSocket és a HTTP között egy nagy különbség az, hogy a WebSocket tartós TCP kapcsolaton működik, míg a HTTP minden kéréshez új TCP kapcsolatot hoz létre.

Nyilvánvaló, hogy minden kéréshez új TCP-kapcsolat létrehozása nem túl teljesítő, és a HTTP nem tudott erről. Valójában a HTTP / 1.1 részeként állandó kapcsolatokat vezettek be a HTTP ezen hiányosságainak enyhítésére.

Mindazonáltal, A WebSocket-et az alapoktól kezdve úgy tervezték, hogy állandó TCP-kapcsolatokkal működjön.

6.4. Kommunikáció

A WebSocket előnye a HTTP-vel szemben egy speciális forgatókönyv, amely abból adódik, hogy az ügyfél képes a szerver olyan módon kommunikálni, amely nem volt lehetséges a régi jó HTTP-vel.

Például a HTTP-ben általában az ügyfél küldi el a kérést, majd a szerver a kért adatokkal válaszol. A szervernek nincs általános módja annak, hogy egyedül kommunikáljon az ügyféllel. Természetesen mintákat és megoldásokat dolgoztak ki ennek megkerülésére, mint például a Server-Sent Events (SSE), de ezek nem voltak teljesen természetesek.

A WebSocket segítségével a tartós TCP kommunikáción dolgozik, lehetséges, hogy a szerver és az ügyfél egyaránt egymástól függetlenül küld adatokat, sőt, sok kommunikáló félnek! Ezt kétirányú kommunikációnak nevezzük.

A másik érdekes tulajdonsága A WebSocket kommunikációja az, hogy full-duplex. Bár ez a kifejezés ezoterikusnak tűnhet; egyszerűen azt jelenti mind a szerver, mind az ügyfél egyszerre küldhet adatokat. Hasonlítsa össze ezt azzal, ami a HTTP-ben történik, amikor a kiszolgálónak meg kell várnia, amíg megkapja a kérést teljes egészében, mielőtt adattal válaszolhatna.

Bár a kétirányú és a teljes duplex kommunikáció előnye nem feltétlenül nyilvánvaló azonnal. látni fogunk néhány olyan felhasználási esetet, ahol valódi erőt szabadítanak fel.

6.5. Biztonság

Végül, de nem utolsó sorban, mind a HTTP, mind a WebSocket kihasználja a TLS előnyeit a biztonság érdekében. Míg a HTTP kínál https ennek használatához az URL-sémájuk részeként a WebSocket rendelkezik wss URL-séma részeként ugyanarra a hatásra.

Tehát az előző alszakasz URL-jeinek biztonságos verziójának a következőképpen kell kinéznie:

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

A RESTful szolgáltatás vagy a WebSocket kommunikáció biztosítása nagyon mély témakör, és itt nem tárgyalható. Most mondjuk el, hogy e tekintetben mindkettőt megfelelően támogatják.

6.6. Teljesítmény

Meg kell értenünk, hogy a WebSocket egy állapotprotokoll, ahol a kommunikáció dedikált TCP-kapcsolaton keresztül történik. Másrészt a HTTP eleve hontalan protokoll. Ez hatással van arra, hogy ezek hogyan fognak teljesíteni a terheléssel, de ez valóban a használati esettől függ.

Mivel a WebSocket-en keresztüli kommunikáció újrafelhasználható TCP-kapcsolaton keresztül történik, az üzenetenkénti általános költség alacsonyabb a HTTP-vel összehasonlítva. Így kiszolgálónként nagyobb átviteli sebességet érhet el. De van egy korlát, amelyig egyetlen szerver képes skálázni, és itt vannak a WebSocket problémái. Nem könnyű vízszintesen méretezni az alkalmazásokat a WebSockets segítségével.

Itt ragyog a HTTP. A HTTP használatával minden új kérés bármilyen szerverre érkezhet. Ez azt jelenti, hogy az általános átviteli sebesség növelése érdekében könnyen hozzáadhatunk további szervereket. Ennek valószínűleg nincs hatása a HTTP-vel futó alkalmazásra.

Nyilvánvaló, hogy egy alkalmazásnak szüksége lehet állapot- és munkamenet-tapadásra, ami megkönnyíti a megmondást, mint a megcsinálást.

7. Hol használjuk őket?

Most már láttunk elegendő mennyiségű RESTful szolgáltatást a HTTP-n keresztül és az egyszerű kommunikációt a WebSocketen keresztül, hogy véleményt alkothassunk róluk. De hol használjunk mit?

Fontos megjegyezni, hogy bár a WebSocket a HTTP hiányosságaiból derült ki, valójában nem a HTTP helyettesítője. Tehát mindkettőjüknek megvan a maga helye és felhasználása. Gyorsan megértsük, hogyan hozhatunk döntést.

A forgatókönyv nagy részében ahol alkalmi kommunikációra van szükség a szerverrel, például az alkalmazottak nyilvántartásának megszerzéséhez, akkor is ésszerű a REST szolgáltatást HTTP / S-n keresztül használni. De az olyan újabb kliensoldali alkalmazásokhoz, mint a részvényárfolyam-alkalmazások, amelyek valós idejű frissítéseket igényelnek a szervertől, nagyon kényelmes a WebSocket kihasználása.

Általánosító, A WebSocket alkalmasabb azokra az esetekre, amikor a push-alapú és valós idejű kommunikáció jobban meghatározza a követelményt. Ezenkívül A WebSocket jól működik olyan esetekben, amikor egy üzenetet egyszerre több ügyfélnek kell elküldeni. Ezek azok az esetek, amikor a kliens és a szerver kommunikációja a RESTful szolgáltatásokon keresztül nehézkes, ha nem is tiltó.

Ennek ellenére a WebSocket és a RESTful szolgáltatások HTTP-n keresztül történő használatát a követelményekből kell levonni. Minthogy nincsenek ezüst golyók, nem várhatjuk el, hogy minden problémát megoldunk. Ezért a hatékony kommunikációs modell megtervezéséhez bölcsességünket és tudásunkat együtt kell felhasználnunk.

8. Következtetés

Ebben az oktatóanyagban áttekintettük a hálózati kommunikáció alapjait, különös hangsúlyt fektetve a HTTP és a WebSocket alkalmazásréteg-protokollokra. Láttunk néhány gyors bemutatást a WebSocket-ről és a RESTful API-ról HTTP-n keresztül a Spring Boot-ban.

Végül összehasonlítottuk a HTTP és a WebSocket protokollok jellemzőit, és röviden megbeszéltük, hogy mikor kell használni őket.

Mint mindig, a példák kódja elérhető a GitHub oldalon.