HTTP-protokolla (HTTPS) - mikä se on? HTTP-protokolla - Mikä on HyperText Transfer Protocol

Voit vastaanottaa erilaisia ​​resursseja, kuten HTML-dokumentteja. HTTP-protokolla on Internetin tiedonvaihdon perusta. HTTP on asiakas-palvelin-kommunikaatioprotokolla, mikä tarkoittaa, että pyynnöt palvelimelle aloittaa vastaanottaja itse, yleensä verkkoselain. Tuloksena oleva lopullinen dokumentti rekonstruoidaan erilaisista osa-asiakirjoista, esimerkiksi erikseen hankitusta tekstistä, dokumentin rakenteen kuvauksesta, kuvista, videotiedostoista, skripteistä ja paljon muuta.

Asiakkaat ja palvelimet kommunikoivat vaihtamalla yksittäisiä viestejä (tietovirran sijaan). Asiakkaan, yleensä verkkoselaimen, lähettämiä viestejä kutsutaan pyynnöt, ja palvelimen lähettämät viestit kutsutaan vastauksia.

Vaikka HTTP kehitettiin 1990-luvun alussa, sitä on parannettu jatkuvasti laajennettavuuden ansiosta. HTTP on sovelluskerroksen protokolla, joka useimmiten käyttää toisen protokollan - TCP:n (tai TLS - suojatun TCP:n) - ominaisuuksia viestiensä välittämiseen, mutta mitä tahansa muuta luotettavaa kuljetusprotokollaa voidaan teoriassa käyttää tällaisten viestien toimittamiseen. Laajennettavuuden ansiosta sitä ei käytetä vain asiakkaan hypertekstidokumenttien tai kuvien ja videoiden vastaanottamiseen, vaan myös sisällön välittämiseen palvelimille esimerkiksi HTML-lomakkeilla. HTTP:n avulla voidaan myös hakea vain osia asiakirjasta verkkosivun päivittämistä varten tarpeen mukaan.

HTTP-pohjaisten järjestelmien komponentit

HTTP on asiakas-palvelin-protokolla, eli pyynnöt lähettää yksi osapuoli - user-agent (tai sen sijaan välityspalvelin). Useimmiten verkkoselain toimii käyttäjäagenttina, mutta se voi olla kuka tahansa, esimerkiksi Webissä liikkuva robotti täydentämään ja päivittämään verkkosivujen indeksointitietoja hakukoneita varten.

Jokainen yksittäinen pyyntö pyyntö) lähetetään palvelimelle, joka käsittelee sen ja palauttaa vastauksen (eng. vastaus). Näiden pyyntöjen ja vastausten välillä on lukuisia välittäjiä, joita kutsutaan proxyiksi, jotka suorittavat erilaisia ​​toimintoja ja toimivat esimerkiksi yhdyskäytävinä tai välimuistina.

Todellisuudessa selaimen ja palvelimen välillä on paljon enemmän erilaisia ​​välittäjälaitteita, joilla on jokin rooli pyynnön käsittelyssä: reitittimet, modeemit ja niin edelleen. Koska Verkko on rakennettu vuorovaikutustasojen (tasojen) järjestelmän pohjalta, nämä välittäjät ovat ”piilotettuja” verkko- ja kuljetustasoilla. Tässä kerrosjärjestelmässä HTTP vie ylimmän kerroksen, jota kutsutaan "sovellustasoksi" (tai "sovelluskerrokseksi"). Tietoa verkkokerroksista, kuten esittelystä, istunnosta, siirrosta, verkosta, linkistä ja fyysistä, ei vaadita HTTP:n kuvaamiseen ja ymmärtämiseen, vaikka se on välttämätöntä verkon toiminnan ymmärtämiseksi ja mahdollisten ongelmien diagnosoimiseksi.

Asiakas: käyttäjäagentti

Käyttäjäagentti on mikä tahansa työkalu tai laite, joka toimii käyttäjän puolesta. Tämä rooli kuuluu ensisijaisesti verkkoselaimelle; Joissakin tapauksissa käyttäjäagentit ovat ohjelmia, joita insinöörit ja verkkokehittäjät käyttävät sovellustensa virheenkorjaukseen.

Selain Aina on taho, joka käynnistää pyynnön. Palvelin ei koskaan tee tätä (vaikka verkon monien vuosien aikana on luotu mekanismeja, jotka voivat simuloida palvelimelta tulevia pyyntöjä).

Web-sivun näyttämiseksi selain lähettää ensimmäisen pyynnön saada kyseisen sivun HTML-dokumentti. Tämän jälkeen selain jäsentää tämän asiakirjan ja pyytää lisätiedostoja, jotka ovat tarpeen verkkosivun sisällön näyttämiseksi (suoritettavat skriptit, sivun asettelutiedot - CSS-tyylisivut, lisäresurssit kuvien ja videotiedostojen muodossa). Seuraavaksi selain yhdistää kaikki nämä resurssit näyttääkseen ne käyttäjälle yhtenä asiakirjana - verkkosivuna. Selaimen itsensä suorittamat skriptit voivat vastaanottaa lisäresursseja verkon kautta verkkosivun myöhemmissä käsittelyvaiheissa, ja selain päivittää käyttäjän näkemystä sivusta vastaavasti.

Verkkosivu on hypertekstidokumentti. Tämä tarkoittaa, että jotkin näytettävän tekstin osat ovat linkkejä, jotka voidaan aktivoida (yleensä napsauttamalla hiiren painiketta) uuden Web-sivun hakemiseksi ja siten näyttämiseksi. Tämän avulla käyttäjä voi ohjata käyttäjäagenttiaan Webissä liikkuessaan. Selain kääntää nämä "liikenneohjeet" HTTP-pyynnöiksi ja tulkitsee sen jälkeen HTTP-vastaukset käyttäjän luettavassa muodossa.

verkkopalvelin

Viestintäkanavan toisella puolella on palvelin, joka palvelee (eng. palvella) käyttäjä, toimittamalla hänelle asiakirjat pyynnöstä. Loppukäyttäjän näkökulmasta palvelin on aina yksi virtuaalikone, joka luo asiakirjan kokonaan tai osittain, vaikka itse asiassa se voi olla joukko palvelimia, joiden välillä kuormitus on tasapainotettu, eli pyyntöjä eri käyttäjiltä. ovat uudelleen jaettuja tai monimutkaisia ​​ohjelmistoja, jotka tiedustelevat muita tietokoneita (kuten välimuistipalvelimet, tietokantapalvelimet, verkkokaupan sovelluspalvelimet ja muut).

Palvelin ei välttämättä sijaitse yhdellä koneella ja päinvastoin - samassa koneessa voi sijaita (isännöidä) useita palvelimia. HTTP/1.1-version ja isäntäotsikon mukaan he voivat jopa jakaa saman IP-osoitteen.

Välityspalvelin

Web-selaimen ja palvelimen välillä on suuri määrä verkkosolmuja, jotka lähettävät HTTP-viestejä. Kerroksellisen rakenteensa ansiosta useimmat niistä toimivat myös kuljetusverkossa tai fyysisellä kerroksella, muuttuen läpinäkyviksi HTTP-kerrokselle ja mahdollisesti heikentäen suorituskykyä. Näitä sovellustason operaatioita kutsutaan välityspalvelin . Ne voivat olla läpinäkyviä tai eivät (muokkauspyynnöt eivät kulje niiden läpi), ja ne voivat suorittaa monia toimintoja:

  • välimuisti (välimuisti voi olla julkinen tai yksityinen, kuten selaimen välimuisti)
  • suodatus (kuten virustentorjunta, lapsilukko jne.)
  • kuormituksen tasapainotus (salli useiden palvelimien palvella erilaisia ​​pyyntöjä)
  • todennus (ohjata pääsyä eri resursseihin)
  • lokikirjaus (oikeus tallentaa tapahtumahistoriaa)

HTTP-perusteet

HTTP on yksinkertainen

Vaikka HTTP/2 on monimutkaisempi, kun HTTP-viestit kapseloidaan kehyksiin, HTTP on yleensä yksinkertainen ja ihmisen luettavissa. Ihmiset voivat lukea ja ymmärtää HTTP-viestejä, mikä helpottaa testaamista kehittäjille ja vähentää monimutkaisuutta uusille käyttäjille.

HTTP - laajennettavissa

HTTP/1.0:ssa käyttöön otettujen HTTP-otsikoiden ansiosta protokollaa oli helppo laajentaa ja kokeilla. Uusi toiminnallisuus voidaan ottaa käyttöön jopa yksinkertaisella sopimuksella asiakkaan ja palvelimen välillä uuden otsikon semantiikasta.

HTTP on tilaton, mutta sillä on istunto

HTTP on tilaton: kahden peräkkäin saman yhteyden kautta suoritettavan pyynnön välillä ei ole yhteyttä. Tämä tarkoittaa välittömästi mahdollisia ongelmia käyttäjälle, joka yrittää olla vuorovaikutuksessa tietyn sivun kanssa peräkkäin, esimerkiksi kun hän käyttää ostoskoria verkkokaupassa. Mutta vaikka HTTP-ydin on tilaton, evästeet mahdollistavat tilalliset istunnot. Otsikoiden laajennettavuuden avulla evästeet lisätään työntekijäsäikeeseen, jolloin istunto voi jakaa jonkin kontekstin tai tilan jokaisessa HTTP-pyynnössä.

HTTP ja yhteydet

Yhteyttä hallitaan kuljetuskerroksessa, joten se ylittää pohjimmiltaan HTTP:n rajat. Vaikka HTTP ei vaadi taustalla olevan siirtoprotokollan olevan yhteyspohjainen, se vaatii vain luotettavuus, tai ei kadonneita viestejä (eli ainakin virheesitys). Kahden yleisimmän Internet-siirtoprotokollan joukossa TCP on luotettava, kun taas UDP ei. HTTP luottaa myöhemmin siihen, että TCP-standardi on yhteyspohjainen, vaikka yhteyttä ei aina tarvita.

HTTP/1.0 avasi TCP-yhteyden jokaista pyyntö/vastausvaihtoa varten, ja siinä on kaksi tärkeää haittaa: yhteyden avaaminen vaatii useita viestien vaihtoja ja on siksi hidasta, vaikka se tehostuukin lähetettäessä useita viestejä tai lähetettäessä viestejä säännöllisesti: lämmin yhteydet ovat tehokkaampia kuin kylmä.

Näiden puutteiden lieventämiseksi HTTP/1.1 otti käyttöön liukuhihnan (joka osoittautui vaikeaksi toteuttaa) ja pysyviä yhteyksiä: taustalla olevaa TCP-yhteyttä voidaan ohjata osittain Yhteys-otsikon kautta. HTTP/2 otti seuraavan askeleen lisäämällä viestien multipleksoinnin yksinkertaisen yhteyden yli, mikä auttoi pitämään yhteyden lämpimänä ja tehokkaampana.

Paremman HTTP:lle sopivamman siirtoprotokollan kehittämiseksi tehdään kokeita. Google esimerkiksi kokeilee UDP:hen perustuvaa QUIC:tä tarjotakseen luotettavamman ja tehokkaamman siirtoprotokollan.

Mitä voidaan ohjata HTTP:n kautta

HTTP:n luonnollinen laajennettavuus on mahdollistanut Webin paremman hallinnan ja toimivuuden ajan myötä. Välimuisti ja todennusmenetelmät olivat HTTP-historian varhaisia ​​ominaisuuksia. Mahdollisuus lieventää alkuperäisiä rajoituksia sen sijaan lisättiin 2010-luvulla.

Seuraavat ovat yleisiä HTTP:n avulla hallittavia toimintoja.


  • Palvelin voi ohjeistaa välityspalvelimia ja asiakkaita, mitä välimuistiin tallennetaan ja kuinka kauan. Asiakas voi käskeä välimuistin välityspalvelimia ohittamaan tallennetut asiakirjat.
  • Rentouttavat lähderajoitukset
    Vakoiluohjelmien ja muiden yksityisyyttä loukkaavien tunkeutumisten estämiseksi verkkoselain käyttää tiukkaa erottelua verkkosivustojen välillä. Vain sivut alkaen sama lähde pääset käsiksi verkkosivun tietoihin. Vaikka tällaiset rajoitukset rasittavat palvelinta, HTTP-otsikot voivat lieventää tiukkaa erottelua palvelinpuolella, jolloin asiakirjasta voi tulla osa tietoa eri toimialueilta (turvallisuussyistä).
  • Todennus
    Jotkut sivut ovat vain erikoiskäyttäjien käytettävissä. Perustodennus voidaan tarjota HTTP:n kautta, joko käyttämällä WWW-Authenticate ja vastaavia otsikoita tai perustamalla erityinen istunto evästeiden avulla.
  • Välityspalvelin ja tunnelointi
    Palvelimet ja/tai asiakkaat sijaitsevat usein intranetissä ja piilottavat todelliset IP-osoitteensa muilta. HTTP-pyynnöt kulkevat välityspalvelimen kautta tämän verkon esteen ylittämiseksi. Kaikki välityspalvelimet eivät ole HTTP-välityspalvelimia. Esimerkiksi SOCKS-protokolla toimii alemmalla tasolla. Muut, kuten ftp, voidaan käsitellä näillä välityspalvelimilla.
  • Istunnot
    HTTP-evästeen avulla voit liittää pyynnön palvelimen tilaan. Tämä luo istunnon, vaikka HTTP on ytimessä tilaton protokolla. Tämä ei ole hyödyllistä vain verkkokauppojen ostoskärryille, vaan myös kaikille sivustoille, joiden avulla käyttäjä voi mukauttaa poistumista.

HTTP-virta

Kun asiakas haluaa kommunikoida palvelimen kanssa, olipa kyseessä sitten lopullinen palvelin tai välipalvelin, se seuraa näitä vaiheita:

  1. TCP-yhteyden avaaminen: TCP-yhteyttä käytetään pyynnön tai pyyntöjen lähettämiseen ja vastauksen vastaanottamiseen. Asiakas voi avata uuden yhteyden, käyttää uudelleen olemassa olevaa tai avata useita TCP-yhteyksiä palvelimeen.
  2. HTTP-viestin lähettäminen: HTTP-viestit (ennen HTTP/2:ta) ovat ihmisen luettavissa. HTTP/2:sta lähtien yksinkertaiset viestit on kapseloitu kehyksiin, mikä tekee niistä mahdotonta lukea suoraan, mutta ne pysyvät pohjimmiltaan samoina. GET / HTTP/1.1 Isäntä: sivusto Accept-Language: fr
  3. Lukee vastauksen palvelimelta: HTTP/1.1 200 OK Päiväys: la, 09.10.2010 14:28:02 GMT Palvelin: Apache Viimeksi muokattu: ti, 01.12.2009 20:18:22 GMT ETag: "51142bc1-7449-5b8b1" Hyväksy-alueet: tavua Sisältö-pituus: 29769 Sisältö-tyyppi: teksti/html
  4. Sulkee yhteyden tai käyttää sitä uudelleen lisäpyyntöjä varten.

Jos HTTP-liukuhihna on käytössä, useita pyyntöjä voidaan lähettää odottamatta ensimmäisen vastauksen vastaanottamista kokonaisuudessaan. HTTP-putkia on vaikea integroida olemassa oleviin verkkoihin, joissa vanhoja ohjelmistoja on rinnakkain nykyaikaisten versioiden kanssa. HTTP-liukuhihna korvattiin HTTP/2:ssa luotettavammilla multipleksoiduilla pyynnöillä kehyksessä.

HTTP-viestejä

HTTP/1.1 ja aiemmat HTTP-viestit ovat ihmisen luettavissa. HTTP/2:ssa nämä viestit on upotettu uuteen binaarirakenteeseen, kehykseen, joka mahdollistaa optimoinnin, kuten otsikon pakkaamisen ja multipleksoinnin. Vaikka osa alkuperäisestä HTTP-viestistä lähetettäisiin tässä HTTP-versiossa, kunkin viestin semantiikkaa ei muuteta ja asiakas luo (käytännöllisesti katsoen) uudelleen alkuperäisen HTTP-pyynnön. Se on hyödyllinen myös HTTP/2-viestien ymmärtämiseen HTTP/1.1-muodossa.

HTTP Hypertext Transfer Protocol (RFC 1945, 2068) on suunniteltu siirtämään hypertekstiasiakirjoja palvelimelta asiakkaalle. HTTP-protokolla on sovelluskerroksen protokolla. RFC:n mukaan sen siirtoprotokollan tulee olla yhteyslähtöinen protokolla, joka siirtää dataa luotettavasti eikä säilytä viestien välisiä rajoja. Käytännössä valtaosassa tapauksista HTTP:n siirtoprotokolla on TCP, jolloin HTTP-palvelin (Web-palvelin) odottaa yhteyttä asiakaspuolelta, vakiona TCP-portissa 80 ja HTTP-asiakas (verkkoselain) aloittaa. yhteys.

Web-termeissä kaikkea, mitä käyttäjä voi käyttää - asiakirjoja, kuvia, ohjelmia - kutsutaan resursseiksi. Jokaisella resurssilla on Webissä ainutlaatuinen osoite, jota kutsutaan yleiseksi resurssitunnisteeksi (URI - Universal Resource Identifier). Yleisimmässä tapauksessa URI näyttää tältä:

protokolla://user:password@host:port/path/file?paremeters#fragment

Yksittäisillä URI-kentillä on seuraava merkitys:

protokolla - sovellusprotokolla, jonka kautta resurssia käytetään;

käyttäjä - käyttäjä, jonka puolesta resurssia käytetään, tai käyttäjä itse resurssina;

salasana - käyttäjän salasana todennusta varten resurssia käytettäessä;

isäntä - IP-osoite tai palvelimen nimi, jossa resurssi sijaitsee;

portti - portin numero, jolla palvelin on käynnissä ja joka tarjoaa pääsyn resurssiin;

polku - polku resurssin sisältävään tiedostoon;

tiedosto - resurssin sisältävä tiedosto;

parametrit - parametrit resurssiohjelman käsittelemiseksi;

fragmentti - tiedoston piste, josta alkaen resurssi tulee näyttää.

Asiakkaan ja Web-palvelimen välinen vuorovaikutus tapahtuu viestejä vaihtamalla. HTTP-viestit jaetaan asiakkaan pyyntöihin palvelimelle ja palvelinvastauksiin asiakkaalle.

Pyyntö- ja vastausviesteillä on yhteinen muoto. Molemmat viestityypit näyttävät tältä: ensin on aloitusrivi, sitten ehkä yksi tai useampi otsikkokenttä, jota kutsutaan myös otsikoiksi, sitten tyhjä rivi (eli rivi, joka koostuu merkeistä CR ja LF), joka osoittaa lopun. otsikkokentistä ja sitten mahdollisesti viestin rungosta:

aloitusviiva

otsikkokenttä 1

otsikkokenttä 2

otsikkokenttä N

viestin runko

Asiakkaan ja palvelimen aloitusrivien muodot eroavat toisistaan, ja niitä käsitellään alla. Otsikoita on neljää tyyppiä:

yleiset otsikot, jotka voivat olla sekä pyynnössä että vastauksessa;

pyyntöotsikot, jotka voivat olla vain pyynnössä;

vastausotsikot, jotka voivat olla vain vastauksessa;

entiteettiotsikot, jotka viittaavat viestin runkoon ja kuvaavat sen sisältöä.

Jokainen otsikko koostuu otsikosta, kaksoispisteestä ":" ja arvosta. Tärkeimmät otsikot on esitetty taulukossa. 1.

pöytä 1

HTTP-protokollan otsikot

Otsikko

Tarkoitus

Objektien otsikot

Luetteloi palvelimen tukemat menetelmät

Sisällön koodaus

Tapa, jolla viestin runko on koodattu, esimerkiksi koon pienentämiseksi

Viestin pituus tavuina

Sisältötyyppi ja mahdollisesti joitain parametreja

Ainutlaatuinen resurssitunniste palvelimella, jonka avulla voit vertailla resursseja

Päivämäärä ja kellonaika, jolloin palvelimen resurssi muuttuu ja se on haettava uudelleen

Päivämäärä ja aika, jolloin sisältöä on viimeksi muokattu

Vastauksen otsikot

Sekuntien määrä, jonka jälkeen pyyntö on toistettava uuden sisällön saamiseksi

Resurssin URI, johon pääsy sisällön saamiseksi

Päivämäärä ja kellonaika tai sekuntien lukumäärä, jonka jälkeen pyyntö on toistettava onnistuneen vastauksen saamiseksi

Palvelinohjelmiston nimi, joka lähetti vastauksen

Pyynnön otsikot

Sisältötyypit, joita asiakas "ymmärtää" ja jota hän voi toistaa

Merkkikoodaukset, joissa asiakas voi hyväksyä tekstisisältöä

Tapa, jolla palvelin voi koodata viestin

Isäntä- ja porttinumero, josta asiakirjaa pyydetään

Jos-Muokattu-Alkaen

Jos-muutamaton-alkaen

Pyydä otsikoita resurssien ehdollista käyttöä varten

Pyydä osa asiakirjasta

Asiakasohjelmiston nimi

Yleiset otsikot

Osoittaa, että palvelin sulkee tai pitää istunnon hengissä

Päivämäärä ja kellonaika, jolloin viesti on luotu

Yksityiskohtainen kuvaus HTTP/1.0-otsikoista löytyy RFC 2068:sta.

Viestin runko sisältää todellisen välitettävän tiedon – viestin hyötykuorman. Viestin runko on oktettien (tavujen) sarja. Viestin runko voidaan koodata esimerkiksi siirrettävän tiedon vähentämiseksi, ja koodausmenetelmä ilmoitetaan Content-Encoding-objektin otsikossa.

Asiakkaalta palvelimelle lähetettävä pyyntösanoma koostuu pyyntörivistä, otsikoista (yleinen, pyynnöt, objekti) ja mahdollisesti viestin rungosta. Pyyntörivi alkaa menetelmällä, jota seuraa pyydetyn resurssin tunniste, protokollaversio ja rivin lopussa olevat merkit:

<Метод> <Идентификатор> <Версия HTTP>

Menetelmä määrittää HTTP-protokollakomennon, jota sovelletaan pyydettyyn resurssiin. Esimerkiksi GET-menetelmä osoittaa, että asiakas haluaa noutaa resurssin sisällön. Tunniste identifioi pyydetyn resurssin. HTTP-versio on merkitty seuraavalla rivillä:

HTTP/<версия>.<подверсия>

RFC 2068 esittelee HTTP/1.1-protokollan.

Katsotaanpa HTTP-protokollan päämenetelmiä.

OPTIONS-metodi pyytää tietoja yhteysvaihtoehdoista (esim. menetelmät, asiakirjatyypit, koodaukset), joita palvelin tukee pyydetylle resurssille. Tämän menetelmän avulla asiakas voi määrittää resurssiin tai palvelimen ominaisuuksiin liittyviä vaihtoehtoja ja/tai vaatimuksia suorittamatta mitään resurssille tai aiheuttamatta sen lataamista.

Jos palvelimen vastaus ei ole virhesanoma, objektiotsikot sisältävät tietoja, joita voidaan pitää yhteysvaihtoehtoina. Esimerkiksi Salli-otsikko luettelee kaikki palvelimen tietylle resurssille tukemat menetelmät.

Jos pyydetty resurssin tunniste on tähti ("*"), OPTIONS-pyynnön on tarkoitus osoittaa palvelin kokonaisuudessaan.

Jos pyydetty resurssin tunnus ei ole tähti, OPTIONS-pyyntö koskee vaihtoehtoja, jotka ovat käytettävissä, kun muodostetaan yhteys määritettyyn resurssiin.

GET-menetelmän avulla voit saada kaikki pyydettyyn resurssiin liittyvät tiedot. Useimmissa tapauksissa, jos pyydetty resurssitunnus viittaa dokumenttiin (esim. HTML-dokumenttiin, tekstidokumenttiin, grafiikkaan, videoon), palvelin palauttaa kyseisen asiakirjan sisällön (tiedoston sisällön). Jos pyydetty resurssi on sovellus (ohjelma), joka tuottaa tietoja toiminnan aikana, tämä tieto palautetaan vastausviestin rungossa, ei suoritettavan tiedoston binäärikuvana. Tätä käytetään esimerkiksi luotaessa CGI-sovelluksia. Jos pyydetyn resurssin tunniste osoittaa hakemistoon (hakemisto, kansio), niin palvelimen asetuksista riippuen joko hakemiston sisältö (tiedostoluettelo) tai jonkin tässä hakemistossa olevan tiedoston sisältö (yleensä index.html tai Default.htm). Kun kansiota pyydetään, sen nimen lopussa voi olla "/" tai ei. Jos tätä merkkiä ei ole resurssitunnisteen lopussa, palvelin antaa yhden uudelleenohjausvastauksista (tilakoodilla 301 tai 302).

Yksi GET-menetelmän muunnelma on "ehdollinen GET", jossa pyyntösanoma sisältää If-Modified-Since-, If-Unmodified-Since-, If-Match-, If-None-Match- tai If-Range-pyyntöotsikot . Ehdollinen GET-metodi pyytää objektin siirtoa vain, jos se täyttää annetuissa otsikoissa kuvatut ehdot. Jos esimerkiksi If-Modified-Since-otsikko on olemassa, pyydetyn resurssin sisältö haetaan vain, jos se ei ole muuttunut tämän otsikon arvoksi määritetyn ajankohdan jälkeen. Ehdollinen GET-menetelmä on tarkoitettu vähentämään tarpeetonta verkon kuormitusta, koska se välttää asiakkaan jo tallentamien tietojen uudelleenlataamisen.

On myös "osittainen GET", jossa pyyntösanoma sisältää Range-pyyntöotsikon. Osittainen GET pyytää, että vain osa objektista siirretään. Osittainen GET-menetelmä on suunniteltu vähentämään tarpeettomia verkon ylikuormituksia pyytämällä vain osaa objektista, kun asiakas on jo ladannut toisen osan. Range-otsikon arvo on merkkijono "bytes=", jota seuraa haettavien tavujen alue. Tavut numeroidaan 0:sta alkaen. Alueen aloitus- ja lopputavut erotetaan ”–”-merkillä. Sekä alueen alku- että lopputavut saattavat puuttua. Jos haluat saada useita alueita, ne on lueteltu pilkuilla erotettuina. Jos jotkin luetelluista alueista leikkaavat, palvelin yhdistää ne. Osittaisen GET-pyynnön vastaussanoman on sisällettävä Content-Range-otsikko, joka määrittää välitettävän alueen. Jos palvelin lähettää useita ei-päällekkäisiä alueita, Content-Type-otsikko saa erityisarvon "multypart/byteranges". Viestin runko jaetaan osiin, jotka erotetaan palvelimen luomalla erottimella ja välitetään Content-Type-otsikkoparametrina. Jokainen yksittäinen osa sisältää omat Content-Type- ja Content-Range-otsikot, joissa on tyhjä rivi ennen alueen sisältöä.

HEAD-menetelmä on identtinen GET:n kanssa, paitsi että palvelin ei palauta viestin runkoa vastauksessa. HEAD-pyynnön vastauksen HTTP-otsikoiden sisältämät tiedot ovat identtisiä saman resurssin GET-pyynnön vastauksena annettujen tietojen kanssa. Tällä menetelmällä voidaan hankkia tietoja pyyntöobjektista ilman, että välitetään suoraan objektin runkoa. HEAD-menetelmää voidaan käyttää hypertekstilinkkien testaamiseen.

POST-menetelmää käytetään pyyntöön, jossa osoitettu palvelin hyväksyy pyyntösanoman runkoon (objektiin) sisältyvät tiedot ja lähettää sen pyydetyksi resurssiksi määritellylle sovellukselle käsittelyä varten. POST on suunniteltu toteuttamaan seuraavat toiminnot yleisesti:

olemassa olevien resurssien huomautus;

viestin lähettäminen ilmoitustaulujärjestelmään (BBS), uutisryhmiin, postituslistoihin tai vastaaviin artikkeliryhmiin;

siirretään tietolohko, esimerkiksi lomakkeessa olevan syötteen tulos, käsittelyprosessiin;

Tietokantojen kyselyjen suorittaminen;

Itse asiassa POST-menetelmän suorittaman toiminnon määrittää pyydetyn resurssitunnuksen osoittama sovellus. GET-menetelmän ohella CGI-sovelluksia luotaessa käytetään POST-menetelmää. Selain voi lähettää pyyntöjä POST-menetelmällä lomakkeita lähetettäessä. Tätä varten lomakkeen sisältävän HTML-dokumentin FORM-elementillä on oltava method-attribuutti, jonka arvo on POST.

POST:n käynnistämä sovellus voi suorittaa toiminnon palvelimella, eikä sen seurauksena palauta sisältöä. Riippuen siitä, sisältääkö vastauksessa tulosta kuvaavan viestin rungon vai ei, vastauksen tilakoodi voi olla joko 200 (OK) tai 204 (ei sisältöä).

Jos palvelimella oleva resurssi on luotu, vastaus sisältää tilakoodin 201 (Luotu) ja sisältää Location vastausotsikon.

PUT-pyynnössä lähetettävän viestin runko tallennetaan palvelimelle, ja pyydetyn resurssin tunniste on tallennetun dokumentin tunniste. Jos pyydetty resurssin tunniste viittaa jo olemassa olevaan resurssiin, viestin runkoon sisältyvää objektia käsitellään palvelimella sijaitsevan resurssin muokattuna versiona. Jos uusi resurssi on luotu, palvelin ilmoittaa siitä käyttäjäagentille vastaamalla tilakoodilla 201 (Luotu).

POST- ja PUT-menetelmien ero on pyydetyn resurssin eri ID-arvo. POST-pyynnön URI identifioi resurssin, joka käsittelee viestin runkoon sisältyvän objektin. Tämä resurssi voi olla tiedot vastaanottava sovellus. Sitä vastoin PUT-pyynnön URI identifioi pyyntöön sisältyvän entiteetin sanoman rungoksi, eli käyttäjäagentti osoittaa annetun URI:n sisällytetylle resurssille.

DELETE-menetelmä pyytää palvelinta poistamaan resurssin, jolla on pyydetty tunnus. Palvelin voi hylätä tällä menetelmällä tehdyn pyynnön, jos käyttäjällä ei ole oikeutta poistaa pyydettyä resurssia.

TRACE-menetelmää käytetään palauttamaan lähetetty pyyntö HTTP-protokollatasolla. Pyynnön vastaanottaja (Web-palvelin) lähettää vastaanotetun viestin takaisin asiakkaalle vastausviestin runkotekstinä tilakoodilla 200 (OK). TRACE-pyyntö ei saa sisältää viestin tekstiosaa.

TRACE antaa asiakkaan nähdä, mitä palvelin vastaanottaa toisessa päässä, ja käyttää näitä tietoja testaukseen tai diagnostiikkaan.

Jos pyyntö onnistuu, vastaus sisältää koko pyyntösanoman vastausviestin tekstiosassa ja Content-Type-objektin otsikko on "message/http".

Yksityiskohtaiset tiedot HTTP/1.1-protokollamenetelmistä löytyvät RFC 2068:sta.

Pyyntösanoman vastaanottamisen ja tulkinnan jälkeen palvelin vastaa HTTP-vastausviestillä.

Vastauksen ensimmäinen rivi on Status-Line. Se koostuu protokollaversiosta, numeerisesta tilakoodista, selittävästä lauseesta, joka on erotettu välilyönneillä, ja rivin lopussa olevista merkeistä:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Protokollaversiolla on sama merkitys kuin pyynnössä.

Status-Code-elementti on kolminumeroinen (kolminumeroinen) kokonaislukukoodi pyynnön ymmärtämisen ja tyydyttämisen tulokseksi. Reason-Frase on lyhyt tekstikuvaus tilakoodista. Tilakoodi on tarkoitettu ohjelmiston käsiteltäväksi, ja selittävä lause on tarkoitettu käyttäjille.

Tilakoodin ensimmäinen numero määrittää vastauksen luokan. Kahdella viimeisellä numerolla ei ole erityistä roolia luokituksessa. Ensimmäisellä numerolla on 5 merkitystä:

1xx: Tietokoodit – pyyntö vastaanotettu, käsittely jatkuu.

2xx: Onnistuneet koodit - toiminto vastaanotettiin, ymmärrettiin ja käsiteltiin onnistuneesti.

3xx: Uudelleenohjauskoodit – pyynnön suorittamiseksi on suoritettava lisätoimia.

4xx: Asiakkaan virhekoodit - pyynnössä on syntaksivirhe tai sitä ei voida suorittaa loppuun.

5xx: Palvelimen virhekoodit - Palvelin ei pysty suorittamaan kelvollista pyyntöä.

Jokaisen tilakoodin selittävät lauseet on lueteltu RFC 2068:ssa ja niitä suositellaan, mutta ne voidaan korvata vastaavilla ilman protokollarajoituksia. Esimerkiksi HTTP-palvelimien lokalisoiduissa venäjänkielisissä versioissa nämä lauseet korvataan venäläisillä. Taulukossa 2 näyttää HTTP-palvelimen vastauskoodit.

taulukko 2

HTTP-palvelimen vastauskoodit

Selittävä lause mukaan

1xx: Tietokoodit

Jatkaa

2xx: Onnistuneet koodit

Ei sisältöä

Palauta sisältö

Osittainen sisältö

Osittainen sisältö

3xx: Uudelleenohjauskoodit

Siirretty tilapäisesti

Siirretty väliaikaisesti

Ei muokattu

4xx: Asiakkaan virhekoodit

Huono pyyntö

Luvaton

Ei löydetty

Menetelmä Ei Sallittu

Menetelmä Ei Sallittu

Pyynnön aikakatkaisu

Pyyntö aikakatkaistiin

Konflikti

Pituus vaaditaan

Pituus vaaditaan

Pyyntökokonaisuus on liian suuri

Pyyntöobjekti on liian suuri

Pöydän loppu. 2

Selittävä lause mukaan

Vastaava selittävä lause venäjäksi

5xx: Palvelimen virhekoodit

Sisäinen palvelinvirhe

Sisäinen palvelinvirhe

Ei toteutettu

Ei toteutettu

palvelu ei saatavilla

Palvelu ei ole käytettävissä

HTTP-versiota ei tueta

HTTP-versiota ei tueta

Yksityiskohtaiset tiedot vastauskoodeista ja näihin vastauksiin liittyvistä otsikoista löytyvät RFC 2068:sta.

Tilariviä seuraavat otsikot (yleinen, vastaus ja objekti) ja mahdollisesti viestin runko.

Yksi Web-palvelimen tärkeimmistä tehtävistä on tarjota pääsy osaan paikallista tiedostojärjestelmää. Tätä varten palvelimen asetuksissa on määritetty tietty hakemisto, joka on tämän Web-palvelimen juurihakemisto. Jos haluat julkaista asiakirjan, eli asettaa sen tällä palvelimella vierailevien käyttäjien saataville (yhteyttä siihen HTTP:n kautta), sinun on kopioitava tämä asiakirja Web-palvelimen juurihakemistoon tai johonkin sen alihakemistoista. HTTP:n kautta muodostettaessa palvelimelle luodaan käyttäjäoikeuksilla varustettu prosessi, jota ei pääsääntöisesti ole olemassa, mutta joka on erityisesti luotu palvelinresurssien katseluun. Määrittämällä tietyn käyttäjän oikeudet ja käyttöoikeudet voit hallita verkkoresurssien käyttöä.

Esittelemme sinulle kuvauksen HTTP-protokollan pääpiirteistä - verkkoprotokollasta, joka 90-luvun alusta tähän päivään sallii selaimesi ladata verkkosivuja. Tämä artikkeli on kirjoitettu niille, jotka ovat vasta aloittamassa työskentelyä tietokoneverkkojen kanssa ja kehittämässä verkkosovelluksia ja joiden on edelleen vaikea lukea virallisia määrityksiä yksin.

HTTP- laajalti käytetty tiedonsiirtoprotokolla, alun perin tarkoitettu hypertekstiasiakirjojen (eli asiakirjojen, jotka voivat sisältää linkkejä, jotka mahdollistavat navigoinnin muihin asiakirjoihin) siirtoon.

Lyhenne HTTP tarkoittaa Hypertekstin siirtoprotokolla, "hypertekstin siirtoprotokolla". OSI-määrittelyn mukaan HTTP on sovellus (ylempi, 7.) kerroksen protokolla. Protokollan nykyinen versio, HTTP 1.1, on kuvattu RFC 2616 -spesifikaatiossa.

HTTP-protokollassa käytetään asiakas-palvelin-tiedonsiirtorakennetta. Asiakassovellus luo pyynnön ja lähettää sen palvelimelle, minkä jälkeen palvelinohjelmisto käsittelee pyynnön, muodostaa vastauksen ja lähettää sen takaisin asiakkaalle. Asiakassovellus voi sitten jatkaa muiden pyyntöjen lähettämistä, jotka käsitellään samalla tavalla.

Perinteisesti HTTP-protokollalla ratkaistava tehtävä on tiedonvaihto verkkoresursseja käyttävän käyttäjäsovelluksen (yleensä verkkoselain) ja verkkopalvelimen välillä. Tällä hetkellä World Wide Web toimii HTTP-protokollan ansiosta.

HTTP:tä käytetään usein myös muiden sovelluskerroksen protokollien, kuten SOAP, XML-RPC ja WebDAV, siirtoprotokollana. Tässä tapauksessa HTTP-protokollaa sanotaan käytettävän "kuljetuksena".

Monien ohjelmistotuotteiden API edellyttää myös HTTP:n käyttöä tiedonsiirrossa - itse tieto voi olla missä tahansa muodossa, esimerkiksi XML tai JSON.

Tyypillisesti HTTP-tiedonsiirto tapahtuu TCP/IP-yhteyksien kautta. Tässä tapauksessa palvelinohjelmisto käyttää yleensä TCP-porttia 80 (ja jos porttia ei ole erikseen määritetty, asiakasohjelmisto yleensä käyttää oletusarvoisesti porttia 80 HTTP-yhteyksien avaamiseen), vaikka se voi käyttää mitä tahansa muuta.

Kuinka lähettää HTTP-pyyntö?

Helpoin tapa ymmärtää HTTP-protokolla on yrittää käyttää jotakin verkkoresurssia manuaalisesti. Kuvittele, että olet selain ja sinulla on käyttäjä, joka todella haluaa lukea Anatoli Alizarin artikkeleita.

Oletetaan, että hän kirjoitti osoitepalkkiin seuraavan:

Http://alizar.habrahabr.ru/

Näin ollen sinun on verkkoselaimena nyt muodostettava yhteys verkkopalvelimeen osoitteessa alizar.habrahabr.ru.

Voit tehdä tämän käyttämällä mitä tahansa sopivaa komentoriviohjelmaa. Esimerkiksi telnet:

Telnet alizar.habrahabr.ru 80

Selitän heti, että jos muutat yhtäkkiä mieltäsi, paina Ctrl + “]” ja sitten enter - tämä antaa sinun sulkea HTTP-yhteyden. Telnetin lisäksi voit kokeilla nc:tä (tai ncat) - makusi mukaan.

Kun olet muodostanut yhteyden palvelimeen, sinun on lähetettävä HTTP-pyyntö. Tämä on muuten erittäin helppoa - HTTP-pyynnöt voivat koostua vain kahdesta rivistä.

HTTP-pyynnön luomiseksi sinun on laadittava aloitusrivi ja asetettava myös vähintään yksi otsikko - tämä on Host-otsikko, joka on pakollinen ja sen on oltava jokaisessa pyynnössä. Tosiasia on, että verkkotunnuksen muuntaminen IP-osoitteeksi suoritetaan asiakaspuolella, ja vastaavasti, kun avaat TCP-yhteyden, etäpalvelimella ei ole tietoa siitä, mitä osoitetta yhteydelle käytettiin: se voi olla esimerkiksi osoite alizar.habrahabr.ru, habrahabr.ru tai m.habrahabr.ru - ja kaikissa näissä tapauksissa vastaus voi olla erilainen. Itse asiassa kuitenkin kaikissa tapauksissa verkkoyhteys avataan solmulla 212.24.43.44, ja vaikka alun perin yhteyttä avattaessa ei määritetty tämä IP-osoite, vaan jokin verkkotunnus, palvelimelle ei tiedoteta tästä millään tavalla - ja siksi tämä osoite on pakollinen isäntä-otsikossa.

HTTP 1.1:n aloituspyyntörivi (alkuperäinen) muodostetaan seuraavan kaavan mukaan:

Esimerkiksi (sellainen aloitusrivi voi osoittaa, että sivuston pääsivua pyydetään):

Ja tietenkään älä unohda, että mistä tahansa tekniikasta tulee paljon yksinkertaisempaa ja selkeämpää, kun aloitat sen käytön.

Onnea ja hedelmällistä oppimista!

Tunnisteet: Lisää tunnisteita

Internetin sivujen pääprotokolla on HTTP. Tätä protokollaa käytetään aina, kun vierailet uudella sivustolla, kun tekstiä tai kuvaa näytetään sivustolla, kun napsautat linkkejä.

Koko Internet perustuu HTTP:hen, vaikka useimmat käyttäjät eivät tiedä kuinka suosittu HTTP on heidän jokapäiväisessä elämässään.

HTTP on protokolla, jota käytetään hypertekstin siirtoon (HyperText Transfer Protocol).

Selaimesi ja palvelimen välinen vuorovaikutus tietojen kanssa perustuu tähän protokollaan. Yksinkertaisuuden ansiosta selain ja palvelin muodostavat yhteyden erittäin nopeasti. Mutta meidän ei tarvitse sukeltaa kaikkiin protokollan yksityiskohtiin, selitämme vain sen toiminnan perusperiaatteen.

Internetissä on monia protokollia, joita voit käyttää, HTTP on vain yksi monista, jolla on omat tehtävänsä ja tarkoituksensa.

Se on niin yksinkertaista, että olet jo perehtynyt HTTP:n – selaimesi – kanssa toimimiseen tarvittaviin ohjelmistoihin.

Selaimen nimestä riippumatta protokollan nimi lisätään aina oletusarvoisesti osoiteriville: “http://”. Et ehkä näe tätä tekstiä, jos selain piilottaa sen. Mutta sinun tarvitsee vain kopioida sivuston nimi, ja HTTP-protokolla lisätään sen mukana oikeaan paikkaan.

- Mitä etuliite "http://" tarkoittaa ennen sivuston nimeä?
- Tämä tarkoittaa, että käytät resurssia HTTP-protokollan kautta.

Miksi HTTP-protokolla luotiin?

Sen avulla välitetään hypertekstiasiakirjoja tai yksinkertaisemmin sivuja tarvitsemillamme sivustoilla.

Asiakas (selain) vastaanottaa verkkosivut ja palvelin lähettää sivut. Tätä tekniikkaa kutsutaan asiakas-palvelin-tekniikaksi.

HTTP:n ansiosta on tullut mahdolliseksi lähettää web-sivuja Internetissä. Mutta mitä itse sivut sisältävät, jotka palvelin lähettää meille? Tavallinen HTML-koodi, joka tulee selaimeen, joka pystyy vain tulkitsemaan vastaanotetut tiedot oikein ja näyttämään valmiin sivuston.

Vielä vuonna 2006 lähes puolet Pohjois-Amerikan HTTP-liikenteestä tuli äänen ja videon suoratoistosta.

Miten HTTP toimii

  1. Selain lähettää pyynnön, jossa pyydetään haluttua palvelinsivua.
  2. Palvelin vastaanottaa pyynnön ja alkaa etsiä sivua.
  3. Selain saa palvelimelta vastauksen, jossa on pyynnön tulokset:
    • Pyydetyn sivun koodi ja palvelutiedot - jos sivu löytyy.
    • Virhekoodi ja huoltotiedot vian sattuessa.

Kun selain pyytää tiedostoa, pyyntö sisältää erityisen HTTP-komennon. Jos pyydetty tiedosto on todella olemassa palvelimella, tiedosto lähetetään. Mutta vastaanottavan sivun on päätettävä, näyttääkö tiedosto näytöllä, tallennetaanko se levylle vai tehdäänkö tuloksella jotain muuta.

HTTP-protokolla käyttää verkon resurssien tunnistamiseen globaaleja URI-tunnisteita. Ero HTTP:n ja muiden protokollien välillä on, että se ei tallenna tilaansa. Toisin sanoen pyyntö-vastaus-parin välistä tilaa ei tallenneta.

HTTP ei ole ainoa Internetissä käytetty protokolla. Käytetty myös:

  • FTP (File Transfer Protocol) on tiedostonsiirtoprotokolla.
  • POP (Post Office Protocol) ja SMTP (Simple Mail Transport Protocol) - sähköpostiviestien vaihtamiseen.
  • SHTTP (Secure Hypertext Transfer Protocol) on HTTP:n salattu versio. Tämän protokollan kautta lähetettävät tiedot on salattu. Yleensä turvallisuus on tärkeää, kun arkaluontoisia tietoja vaihdetaan.

Ja muut protokollat, joilla on yksi hyvä ominaisuus - ne kaikki toimivat huomaamatta sinun ja minä.

Maaliskuu 1991 - Tim Berners-Lee ehdotti HTTP:n käyttöä.

Berners-Lee kehitti kaikki ensimmäiset Internetiin liittyvät asiat: selaimen, palvelimen, hyperlinkit, ensimmäisen verkkosivuston (info.cern.ch Voit nähdä, miltä ensimmäinen verkkosivusto näytti, kun seuraat linkkiä).

HTTP-versiot ovat parantuneet ajan myötä HTTP 1.1:stä on tullut suosittu, mikä mahdollistaa yhteyden jättämisen palvelimen ja selaimen välillä auki pitkäksi aikaa, mikä teki protokollasta tehokkaamman.

Vuonna 2015 ilmestyi HTTP/2, josta tuli binääri, ja tapa, jolla tiedot jaettiin fragmenteiksi, muuttui.

HTTP-suojaus

HTTP itsessään ei tarkoita tietojen salausta. Mutta on olemassa protokollalaajennus, joka voi pakata tietoja SSL- tai TLS-protokollaan.

HTTPS (S - Secure) on suosittu ratkaisu, joka ei salli siirretyn tiedon sieppaamista ja suojaa tietoa "man-in-the-middle" MITM- tai man-in-the-middle -hyökkäyksiltä.

MITM on pohjimmiltaan vioittunut puhelin, jonka tietoja muutetaan tarkoituksella. Asiakas tai palvelin eivät tiedä vaihdosta.

Mistä HTTP koostuu?

Olemme maininneet paljon, että palvelin ja asiakas lähettävät ja vastaanottavat pyyntöjä. Mitä nämä pyynnöt sitten sisältävät? Jokainen HTTP-viesti koostuu kolmesta osasta:

  1. Aloitusrivi, joka määrittää viestin tyypin.
  2. Otsikot, jotka kuvaavat viestin runkoa.
  3. Viestin runko, joka sisältää jo tarvittavat tiedot.

HTTP:n ominaisuuksien ansiosta he pystyivät luomaan hakukoneita, foorumeita ja verkkokauppoja. Kauppa tuli Internetiin, Internet-palveluntarjoajia ja muita yrityksiä, joiden toiminta tapahtuu Internetissä, alkoi ilmestyä. Ja kaikki kiitos HTTP-protokollan, jonka olet nyt hyvin tuttu.