HTTP ja verkkojohdot: Nykypäivän verkkoviestintätekniikoiden kyky ymmärtää

Päätetään, mitä valita seuraavalle verkkosovellusliittymäsuunnitelmallesi

Sovellusliittymille on niin paljon luokituksia. Mutta kun kyse on verkkoviestinnästä, voimme tunnistaa kaksi merkittävää API-tyyppiä - Web Service API (esimerkiksi SOAP, JSON-RPC, XML-RPC, REST) ​​ja Websocket API. Mutta mitä nämä oikeasti tarkoittavat? Sukellaan verkkoviestintäprotokollien maailmaan ja keskustellaan siitä, kuinka lopulta valita parhaat API-mekanismit.

HTTP

HTTP on Internet-yhteyden taustalla oleva viestintäprotokolla. HTTP toimii pyyntö-vastausprotokollana asiakas-palvelin -laskentamallissa. HTTP / 1.1 on yleisin HTTP-versio, jota käytetään nykyaikaisissa selaimissa ja palvelimissa. Verrattuna HTTP: n varhaisiin versioihin, tämä versio voisi toteuttaa kriittisiä suorituskyvyn optimointeja ja ominaisuuksien parannuksia, kuten jatkuvia ja liitettyjä yhteyksiä, paloitteellisia siirtoja, uusia otsikkokenttiä pyyntö / vastauskappaleessa jne. Niistä seuraavat kaksi otsikkoa ovat erittäin merkittäviä, koska suurin osa nykyaikaisista HTTP-parannuksista perustuu näihin kahteen otsikkoon.

  • Keep-Alive-otsikko asettaaksesi isäntien välisen pitkäikäisen viestinnän käytäntöjä (aikakatkaisuaika ja enimmäispyyntöjen käsittely käsittelyn aikana)
  • Päivitä otsikko vaihtaaksesi yhteyden parannettuun protokollitilaan, kuten HTTP / 2.0 (h2, h2c) tai Websockets (webocket)

Jos olet kiinnostunut tietämään, mitä nämä todella tekevät, olen dokumentoinut kaikki sinulle tärkeät tiedot alla olevaan artikkeliin.

LEVÄTÄ

Arkkitehtoninen tyyli, REST (REpresentational State Transfer) on ylivoimaisesti standardisoitu tapa strukturoida web-sovellusliittymiä pyyntöihin. REST on puhtaasti arkkitehtoninen tyyli, joka perustuu useisiin periaatteisiin. REST-periaatteita noudattavia sovellusliittymiä kutsutaan RESTful-sovellusliittymiksi. REST-sovellusliittymät käyttävät pyyntö / vastausmallia, jossa jokainen palvelimen viesti on vastaus asiakkaan viestiin. Yleensä RESTful API -sovellukset käyttävät HTTP-protokollaa siirtoprotokollanaan. Tällaisissa tapauksissa hakujen tulee käyttää GET-pyyntöjä. PUT-, POST- ja DELETE-pyyntöjä tulisi käyttää mutaatioon, luomiseen ja poistamiseen (älä käytä GET-pyyntöjä tietojen päivittämiseen).

HTTP-kysely

HTTP-kyselyssä asiakas kysyy palvelinta, joka pyytää uusia tietoja noudattamalla yhtä alla olevista mekanismeista. Äänestyskysymyksiä käyttää nykyään suurin osa sovelluksista, ja suurin osa ajasta kuluu RESTful-käytäntöjen kanssa. Käytännössä HTTP-lyhytaikaista kyselyä käytetään hyvin harvoin, ja HTTP-pikakysely tai säännöllinen kysely on aina valinta.

  • HTTP-lyhytaikainen kysely: Yksinkertainen lähestymistapa. Paljon pyyntöjä käsitellään, kun ne tulevat palvelimelle, mikä luo paljon liikennettä (käyttää resursseja, mutta vapauttaa ne heti, kun vastaus lähetetään takaisin). Koska jokainen yhteys on avoinna vain lyhyen ajan, monia yhteyksiä voidaan aika multipleksoida.
00:00:00 C-> Onko kakku valmis?
00:00:01 S-> Ei, odota.
00:00:01 C-> Onko kakku valmis?
00:00:02 S-> Ei, odota.
00:00:02 C-> Onko kakku valmis?
00:00:03 S-> Joo. Onko sinulla poika.
00:00:03 C-> Onko toinen kakku valmis?
  • HTTP-pitkä kysely: Yksi pyyntö menee palvelimelle ja asiakas odottaa vastauksen saapumista. Palvelin pitää pyynnön avoinna, kunnes uutta tietoa on saatavana (sitä ei ole vielä ratkaistu ja resurssit on estetty). Palvelintapahtuma tapahtuu viipymättä. Monimutkaisempia ja enemmän palvelinresursseja käytetty.
HTTP-pitkä kysely - vastaus pidetään, kunnes palvelimen prosessitiedot (kuva shyamapadabatabyal.wordpress.com)
12:00 00:00:00 C-> Onko kakku valmis?
12:00 00:00:03 S-> Joo. Onko sinulla poika.
12:00 00:00:03 C-> Onko toinen kakku valmis?
  • HTTP-määräaikainen kysely: Kahden pyynnön välillä on ennalta määrätty aikaero. Tämä on parannettu / hallittu versio kyselyistä. Voit vähentää palvelimen kulutusta lisäämällä aikaerää kahden pyynnön välillä. Mutta jos sinun on ilmoitettava viipymättä palvelintapahtuman tapahtuessa, tämä ei ole hyvä vaihtoehto.
Määräaikainen HTTP-kysely - pyyntö lähetetään n sekunnin välein (kuva ibm.com-sivustolta)
00:00:00 C-> Onko kakku valmis?
00:00:01 S-> Ei, odota.
00:00:03 C-> Onko kakku valmis?
00:00:04 S-> Joo. Onko sinulla poika.
00:00:06 C-> Onko toinen kakku valmis?

HTTP-suoratoisto

HTTP-suoratoisto - tarjoaa pitkäaikaisen yhteyden välitöntä ja jatkuvaa tiedonsiirtoa varten (Kuva realtimeapi.io)

Asiakas tekee HTTP-pyynnön, ja palvelin huijaa rajoittamattoman pituisen vastauksen (se on kuin ääretöntä kyselyä) .HTTP-suoratoisto on suorittava, helppo kuluttaa ja voi olla vaihtoehto verkkopalveluille.

  • Aihe: Välittäjät voivat keskeyttää yhteyden (esim. Aikakatkaisu, välittäjät palvelevat muita pyyntöjä pyöreällä tavalla). Tällaisissa tapauksissa se ei voi taata täydellistä oikeellisuutta.
00:00:00 ASIAKAS-> Tarvitsen kakkuja
00:00:01 PALVELIN-> Odota hetki.
00:00:01 PALVELIN-> Kakku-1 on prosessissa.
00:00:02 PALVELIN-> Pidä kakku-1.
00:00:02 PALVELIN-> Odota kakku-2.
00:00:03 PALVELIN-> Kakku-2 on prosessissa.
00:00:03 PALVELIN-> Sinun täytyy nauttia kakusta-1.
00:00:04 PALVELIN-> Pidä kakku-2.
00:00:04 PALVELIN-> Odota kakku-3.
00:00:05 ASIAKAS-> Tarpeeksi, olen täynnä.

SSE (palvelimen lähettämät tapahtumat / EventSource)

SSE - tapahtumia voidaan lähettää useille asiakkaille (kuva javaee.ch)
  • SSE-yhteydet voivat siirtää tietoja vain selaimeen. (viestintä tapahtuu vain palvelimelta selaimelle; selaimet voivat tilata vain palvelimen alkuperäisiä datapäivityksiä, mutta eivät voi lähettää mitään tietoja palvelimelle)
00:00:00 ASIAKAS-> Tarvitsen kakkuja
00:00:02 PALVELIN-> Pidä kakku-1.
00:00:04 PALVELIN-> Pidä kakku-2.
00:00:05 ASIAKAS-> Tarpeeksi, olen täynnä.
  • Esimerkkejä sovelluksista: Twitter-päivitykset, osakekurssit, krikettipisteet, ilmoitukset selaimeen
  • Ongelma nro 1: Jotkut selaimet eivät tue SSE: tä.
  • Ongelma 2: Avoimien yhteyksien enimmäismäärä on rajoitettu 6 tai 8 HTTP / 1.1: n kautta (selaimen version perusteella). Jos käytät HTTP / 2: ta, ongelmaa ei tule, koska yksi TCP-yhteys riittää kaikkiin pyyntöihin (HTTP / 2: n multipleksoidun tuen ansiosta).

HTTP / 2-palvelimen työntö

  • Mekanismi palvelimelle, joka työntää resurssit (tyylitaulukot, skriptit, media) ennakoivasti asiakasvälimuistiin
  • Esimerkkejä sovelluksista: sosiaalisen median syötteet, yhden sivun sovellukset
HTTP / 2 on tehokas siirtokerros, joka perustuu multipleksoituihin virroihin (kuva SessionStack.com-sivustolta) - IETF: n mukaan ”stream” on riippumaton, kaksisuuntainen kehysjakso, jota asiakkaan ja palvelimen välillä vaihdetaan HTTP / 2-yhteyden sisällä. Yksi sen pääpiirteistä on, että yksi HTTP / 2-yhteys voi sisältää useita samanaikaisesti avoimia virtauksia, jolloin molemmat päätepiste lomittavat kehyksiä useista virroista.
  • Ongelma nro 1: Välittäjät (välityspalvelimet, reitittimet, isännät) voivat halutessaan välittää tietoja asiakkaalle asianmukaisesti alkuperäispalvelimen tarkoittamalla tavalla.
  • Aihe nro 2: Yhteyksiä ei pidetä avoinna toistaiseksi. Yhteys voidaan sulkea milloin tahansa, jopa kun sisällön siirtäminen tapahtuu. Kun yhteys on suljettu ja avattu uudelleen, tämä yhteys ei voi jatkua minne se lähti.
  • Ongelma 3: Jotkut selaimet / välittäjät eivät tue Server Push -palvelua.

WebSockets

WebSockets antaa sekä palvelimelle että asiakkaalle työntää viestejä milloin tahansa ilman mitään yhteyttä aikaisempaan pyyntöön. Yksi huomattava etu verkko-verkkojen käyttämisessä on, että lähes kaikki selaimet tukevat verkko-verkko-osia.

WebSocket ratkaisee muutaman ongelman HTTP: n kanssa:

  • Kaksisuuntainen protokolla - joko asiakas / palvelin voi lähettää viestin toiselle osapuolelle (HTTP: ssä pyynnön aloittaa aina asiakas ja palvelin käsittelee vastauksen - tekemällä HTTP: stä yksisuuntaisen protokollan)
  • Kaksisuuntainen viestintä - asiakas ja palvelin voivat puhua keskenään itsenäisesti samanaikaisesti.
  • Yksi TCP-yhteys - Kun olet päivittänyt HTTP-yhteyden alussa, asiakas ja palvelin kommunikoivat saman TCP-yhteyden kautta Websocket-yhteyden koko elinkaaren ajan.
00:00:00 ASIAKAS-> Tarvitsen kakkuja
00:00:01 PALVELIN-> Odota hetki.
00:00:01 ASIAKAS-> Okei, siistiä.
00:00:02 PALVELIN-> Pidä kakku-1.
00:00:02 PALVELIN-> Odota kakku-2.
00:00:03 ASIAKAS-> Mikä tämä maku on?
00:00:03 PALVELIN-> Etkö pidä siitä?
00:00:04 PALVELIN-> Pidä kakku-2.
00:00:04 ASIAKAS-> Pidän siitä.
00:00:05 ASIAKAS-> Mutta tämä riittää.
Verkkoyhteys (kuva PubNub.comista)

Esimerkkejä sovelluksista: pikaviestintä- / chat-sovellukset, pelit, järjestelmänvalvojan käyttöliittymät

Vaikka verkkokauppojen sanotaan tukevan kaikkia selaimia, myös välittäjissä voi olla poikkeuksia:

  • Odottamaton käyttäytyminen välittäjissä: Jos verkkopisteyhteytesi kulkevat välityspalvelimien / palomuurien läpi, olet ehkä huomannut, että tällaiset yhteydet epäonnistuvat jatkuvasti. Käytä aina turvattuja verkkojoukkoja (WSS) suojauksen vähentämiseksi selvästi. Tämä tapaus selitetään hienosti täällä: Kuinka HTML5-verkkosovittimet ovat vuorovaikutuksessa välityspalvelimien kanssa ja tässäkin: WebSockets, varovaisuus !. Joten ole varovainen ja valmistaudu käsittelemään niitä käyttämällä WSS: ää ja laskemalla takaisin tukevaan protokollaan.
  • Välittäjät, jotka eivät tue verkkopaketteja: Jos WebSocket-protokollaa ei jostain syystä ole saatavana, varmista, että yhteytesi varmuuskopioi automaattisesti sopivaan pitkään kyselyvaihtoehtoon.

REST vs. verkkokaupat - täytetesti

Jos teet suorituskyvyn testin REST- ja Web-verkkokauppoille, saatat huomata, että verkkokaupat toimivat paremmin, kun läsnä on suuria kuormia. Tämä ei välttämättä tarkoita, että REST on tehoton. Henkilökohtainen mielipiteeni on, että REST-verrattuna verkkokaupoihin on kuin omenoiden ja appelsiinien vertaaminen. Nämä kaksi ominaisuutta ratkaisevat kaksi erilaista ongelmaa, eikä niitä voida verrata yksinkertaisella täytetestillä kuten tämä:

Ensimmäisessä kaaviossa REST-yleiskustannukset kasvavat sanomien lukumäärään nähden, koska monet TCP-yhteydet on aloitettava ja lopetettava ja että monet HTTP-otsikot on lähetettävä ja vastaanotettava. Toisessa kaaviossa REST-päätepisteen käsittelypyynnön / vastauksen käsittelykustannukset ovat vähäiset ja suurin osa ajasta vietetään yhteyden aloittamiseen / lopettamiseen ja HTTP-semantiikan kunnioittamiseen. (Perf-testi ja analyysi osoitteesta arungupta.me)

Sinun tulisi kuitenkin nyt ymmärtää, että verkkopöydät ovat loistava valinta käsitellä pitkäaikaista kaksisuuntaista tiedonsiirtoa lähes reaaliajassa, kun taas REST on erinomainen satunnaiseen viestintään. Verkkokauppojen käyttö on huomattava investointi, joten satunnaisten yhteyksien ylenmääräisyys.

Webhooksit (palvelimien väliseen viestintään)

Jos haluat saada tietoja sovellusliittymästäsi tietojen muuttamisesta, kyselyn on oltava ensimmäinen mieleesi tuleva vaihtoehto. Mutta palvelimien välisessä kommunikoinnissa kyselyjen tehottomuus maksaa meille paljon (keskimäärin 98,5% kyselyistä menee hukkaan).

Webhooks - yksinkertainen tapa lähettää tietoja palvelimien välillä, joilla ei ole pitkäaikaisia ​​kyselyyhteyksiä (Kuva realtimeapi.io)

Webhooksit ovat tämän ongelman pelastaja. Muista tässä, että viestintä tapahtuu yleensä palvelimien välillä. Ensin lähettäjäsolmu rekisteröi takaisinsoitto-URL-osoitteen vastaanottosolmussa / -solmuissa etukäteen. Kun tapahtuma tapahtuu lähettäjän puolella, webhook laukaistaan ​​ja lähettää tapahtumaobjektin uudella datalla HTTP POST -pyynnönä vastaanottosolmulle / -solmille käyttämällä kussakin niistä rekisteröityjä takaisinsoitto-URL-osoitteita.

Hienoa on, että sekä lähettäjän että vastaanottajan solmujen palvelimen kuormitusta voidaan vähentää rajusti webhooksilla. Se varmistaa paremman käyttökokemuksen, kun taas kehittäjät voivat käyttää palvelupisteitäsi merkityksellisiin asioihin kuluttamatta kyselyjä.

Verkkohakkeja käytetään yleensä lähettämään ilmoituksia ja tilamuutoksia palvelimien välillä, kun tapahtuma tapahtuu. Esimerkiksi, kun käyttäjä lopettaa tilauksen napsauttamalla sähköpostia napsauttamalla sitä palvelimelle ja käyttäjän tilaustapahtuma tapahtuu, tämä tapahtuma laukaisee vastaavat verkkohakut ja he ilmoittavat kaikille palvelimille / palveluille, jotka käyttäjän on nyt peruuttanut palvelustaan. (Kuva kloudymail.com)
  • Sovellusmallit: Ilmoitukset, kun uusi käyttäjä rekisteröi tai nykyinen käyttäjä päivittää olemassa olevan profiiliasetus
  • Ongelma: Kehittäjien on vaikea määrittää verkkohokoja ja laajentaa HTTP-palveluita.

Mitä käyttää seuraavassa sovellusliittymässäsi?

Käytettävä tekniikka riippuu siitä, mikä on järkevämpää hakemuksesi yhteydessä. Toki, voit käyttää joitain temppuja simuloidaksesi yhden tekniikan käyttäytymistä toisen kanssa, mutta yleensä on edullista käyttää sitä, joka sopii paremmin viestintämalliisi, kun sitä käytetään kirjan mukaan.

HTTP / 1.1 vs. HTTP / 2: Nämä ovat siirtoprotokollia. HTTP / 2: n monipuolinen kyky on suuri, mutta sitä ei tueta vielä kaikkialla. Varmista tällaisissa tapauksissa, että HTTP / 2: sta ja HTTP / 1.1: stä palaaminen ei aiheuta sotkua sovellukseesi. Tiedonsiirtoon HTTP / 1.1 on edelleen hyvä valinta.

RESTful API -sovellukset: Toistaiseksi RESTful API -sovellukset ovat kunnossa web-sovelluksia varten. Mutta käydään keskusteluja parempien tapojen etsinnästä. Esimerkki on tämä käsite - “Korvaa RESTful API -sovellukset JSON-Purella”. Pidän ideasta, itse asiassa JSON on kehittäjäystävällinen ja voit tehdä sen kanssa ihmeitä. Mutta tiedätkö, nämä kehittävät konsepteja.

JSON vs. XML: Käytä JSON: ta. Se on trendi, ja niin mukava käsitellä myös.

HTTP-kysely: Tämä on vanha, mutta silti loistava valinta käsitellä sovellusliittymiä. Jos tietosi muuttuvat usein tai reaaliajassa, älä käytä lyhytpyyntöä, käytä vain verkko-verkkoja, mikä on parempi tekniikka reaaliaikaisesti. Käytä aina pitkää ja säännöllistä kyselyä asianmukaisesti (REST-periaatteilla).

HTTP-suoratoisto: Tämä on hyvä sovelluksissa, kuten uutisten / sosiaalisen median syötteissä, osake- / tulostaulukoissa, tweeteissä jne. Mutta käytännössä ihmiset käyttävät verkkosovelluksia kuin HTTP-suoratoisto.

HTTP / 2 Server Push on hieno tapa lähettää resursseja asiakkaalle hallitummalla tavalla. Mutta kaikki välittäjät ja selaimet eivät tue tätä. Varmista, että käsittelet sulavasti tällaisia ​​varmuuskopioita.

Palvelimen lähettämät tapahtumat ovat melko uusi tekniikka, jota kaikki tärkeimmät selaimet eivät vielä tue, joten se ei ole vielä vaihtoehto vakavalle yritystason verkkosovellukselle (kyllä, olen samaa mieltä siitä, että voit huijata tämän tekniikan toimimaan).

WebSockets tarjoaa rikkaamman protokollan kaksisuuntaisen, kaksipuolisen tiedonsiirron suorittamiseen. Kaksisuuntaisen kanavan käyttäminen on houkuttelevampaa esimerkiksi peleille, viestisovelluksille, yhteistyötyökaluille, vuorovaikutteisille kokemuksille (ml. Mikrovuorovaikutukset) ja tapauksille, joissa tarvitset reaaliaikaisia ​​päivityksiä molempiin suuntiin.

Verkkohahmot eroavat kaikista yllä mainituista tekniikoista, koska ne ratkaisevat hyvin erityisen ongelman. Jos palvelimesi täytyy kommunikoida usein ja / tai kaksisuuntaisesti, etsi verkkosivustoja. Jos palvelimet kommunikoivat satunnaisesti, käytä REST-puheluita. Jos palvelimien on kommunikoitava yksisuuntaisesti tapahtumalaukaisimella, siirry verkkosivustoihin. Älä käytä kyselyjä tietojen tai tilan muutosten tarkistamiseen, se on hukkaa.

Mitään vinkkejä?

️ Välityspalvelimet ja välittäjät ovat hulluja. He syövät paketit tai aikakatkaisun odottamatta. Ole tietoinen siitä ja käsittele sitä sulavasti.

️ Käytä suojattuja kuljetusprotokollia (HTTPS tai WSS) käsittelemään viestintääsi. Välittäjillä on silloin vähemmän vaikutuksia yhteytesi. Ja se on turvallista.

️ Kehittäjät rakastavat verkkohuippuja. Mutta varmista, että käytät sitä oikein.

️ Sinun ei todellakaan tarvitse omaksua uusinta tekniikkaa aina, varsinkin kun luot yritystason sovelluksia. Varmista, että kaikki infrastruktuurit tukevat käyttämääsi tekniikkaa. Ja jos infrastruktuuri ei tue tekniikkaasi / arkkitehtuuria, varmista, että se palautuu tekniikkaan, joka toimii vain kaikkialla ja kaikki toimii sulavasti ja vähentyneillä ominaisuuksilla.

Viitteet:

  • REST vs WebSocket -vertailu ja vertailuarvot
  • Lyhyet ja pitkät kyselyt reaaliaikaisiin verkkosovelluksiin?
  • Aloittaminen reaaliajassa