Protocol de transferència d’hipertext
En telecomunicacions i tecnologia de la informació HTTP ( protocol de transferència d’ hipertext ) és un protocol de capa d’ aplicació que s’utilitza com a sistema principal per transmetre informació al web o en una arquitectura típica client-servidor . Les especificacions del protocol són mantingudes pel World Wide Web Consortium ( W3C ). Un servidor HTTP sol escoltar les sol·licituds del client al port 80 mitjançant la capa de transport TCP .
Història
La primera versió d’HTTP, la 0.9, es remunta a finals dels anys vuitanta i va constituir, juntament amb el llenguatge HTML i les URL , el nucli bàsic de la iniciativa d’informació mundial de la World Wide Web (WWW) desenvolupada per Tim Berners-Lee al CERN de Ginebra per l'intercanvi d'informació entre la comunitat de físics d'alta energia . Abans de HTTP, el protocol de referència per a tals propòsits era el FTP més senzill i lleuger. La primera versió realment disponible del protocol, HTTP / 1.0, va ser implementada pel mateix Berners-Lee el 1991 i proposada com a RFC 1945 [1] al reguladorIETF el 1996.
Amb la difusió de NCSA Mosaic , un navegador gràfic fàcil d'utilitzar, la WWW va experimentar un èxit creixent i es van fer evidents algunes limitacions de la versió 1.0 del protocol, en particular:
- la impossibilitat d’allotjar diversos llocs web al mateix servidor ( host virtual );
- fracàs en la reutilització de les connexions disponibles;
- la insuficiència dels mecanismes de seguretat .
El protocol es va ampliar a la versió HTTP / 1.1, presentada com a RFC 2068 [2] el 1997 i posteriorment actualitzada el 1999, tal com es descriu per la RFC 2616 [3] .
La nova versió del protocol, HTTP / 2 , es va publicar a RFC 7540 [4] el maig de 2015.
Operació
HTTP és un protocol que funciona amb una arquitectura client / servidor : el client fa una sol·licitud i el servidor retorna la resposta enviada per un altre amfitrió. En un ús comú, el client correspon al navegador i al servidor a la màquina on resideix el lloc web . Per tant, hi ha dos tipus de missatges HTTP : missatges de sol·licitud i missatges de resposta.
HTTP es diferencia d'altres protocols de capa 7 , com ara FTP, ja que les connexions normalment es tanquen un cop s'ha satisfet una sol·licitud concreta (o una sèrie de sol·licituds relacionades). Aquest comportament fa que el protocol HTTP sigui ideal per a la World Wide Web, en què les pàgines sovint contenen enllaços a pàgines allotjades per altres servidors, reduint així el nombre de connexions actives limitant-les a les realment necessàries amb un augment de l’eficiència (menys càrrega i ocupació) tant al client com al servidor. Tanmateix, de vegades planteja problemes als desenvolupadors de contingut web, perquè la naturalesa sense estat de la sessió de navegació els obliga a utilitzar mètodes alternatius (normalment basats en cookies ) per mantenir l’estat de l’usuari.
Sol·licita el missatge
El missatge de sol·licitud consta de quatre parts:
- línia de sol·licitud;
- secció de capçalera (informació addicional);
- línia en blanc (CRLF: retorn de carro de 2 caràcters i alimentació de línia);
- cos (cos del missatge).
Línia de sol·licitud
La línia de sol·licitud consisteix en el mètode, l' URI i la versió del protocol. El mètode de sol·licitud, per a la versió 1.1, pot ser un dels següents:
- ACONSEGUIR
- POST
- CAP
- POSAR
- ESBORRAR
- PATCH
- Rastre
- OPCIONS
- CONNECTAR
l’ URI , identificador de recursos uniforme , indica el tema de la sol·licitud (per exemple, la pàgina web que s’obtindrà).
Els mètodes HTTP més habituals són GET , HEAD i POST . El mètode GET s’utilitza per obtenir el contingut del recurs indicat com a URI (com ara el contingut d’una pàgina HTML ). HEAD és similar a GET , però només retorna els camps de capçalera, per exemple, per comprovar la data de modificació del fitxer. Una sol·licitud amb el mètode HEAD no requereix l’ús del cos.
El mètode POST s'utilitza normalment per enviar informació al servidor (com ara dades de formulari ). En aquest cas, la URI indica el que s’envia i el cos indica el seu contingut.
Les capçaleres de la sol·licitud
Les capçaleres de sol·licitud més habituals són:
- Amfitrió : nom del servidor al qual fa referència l' URL . Es requereix a les sol·licituds compatibles amb HTTP / 1.1 perquè permet l'ús d' amfitrions virtuals basats en el nom .
- User-Agent : identificació del tipus de client: tipus de navegador, fabricant, versió ...
- Cookies: les utilitzen les aplicacions web per emmagatzemar i recuperar informació del client a llarg termini. Sovint s’utilitza per emmagatzemar un testimoni d’autenticació o per fer un seguiment de l’activitat de l’usuari.
Missatge de resposta
El missatge de resposta és textual i consta de quatre parts:
- línia d'estat ;
- secció de capçalera;
- línia en blanc (CRLF: retorn de carro de 2 caràcters i alimentació de línia);
- cos (contingut de la resposta).
Línia d'estat
La línia d'estat mostra un codi de tres dígits catalogat de la següent manera:
- 1xx: informatiu (missatges informatius)
- 2xx: satisfactòria (la sol·licitud s'ha satisfet)
- 3xx: redirecció (no hi ha resposta immediata, però la sol·licitud té sentit i se li indica com obtenir la resposta)
- 4xx: error del client (la sol·licitud no es pot satisfer perquè és incorrecta)
- 5xx: error del servidor (la sol·licitud no es pot satisfer a causa d'un problema intern del servidor)
Els codis de resposta més habituals són:
- 200 D' acord . El servidor ha proporcionat correctament el contingut a la secció del cos.
- 301 Mogut permanentment . El recurs que vam sol·licitar no es pot accedir perquè s’ha mogut permanentment.
- 302 trobats . El recurs es pot accedir amb un altre URI indicat a la capçalera Ubicació. Normalment, els navegadors fan la sol·licitud a l’URI especificat automàticament sense la interacció de l’usuari.
- 400 Sol·licitud incorrecta . El servidor no pot entendre el recurs sol·licitat.
- 404 No trobat . No s'ha trobat el recurs sol·licitat i es desconeix la seva ubicació. Això sol produir-se quan l'URI s'ha introduït incorrectament o quan el contingut s'ha eliminat del servidor.
- Error intern del servidor 500 . El servidor no pot respondre a la sol·licitud a causa d'un problema intern.
- 502 Porta d'enllaç no vàlida. El servidor web que actua com a servidor intermediari invers no va obtenir una resposta vàlida del servidor ascendent.
- La versió 505 HTTP no és compatible . La versió http no és compatible.
Les capçaleres de resposta
Les capçaleres de resposta més habituals són:
- Servidor . Indica el tipus i la versió del servidor. Es pot veure com l'equivalent de la capçalera de sol·licitud User-Agent
- Tipus de contingut . Indica el tipus de contingut retornat. La codificació d'aquest tipus (anomenat Tipus de paper) s'ha registrat a la IANA (I nternet A sSuscripción N Umber A UTORIDAD); es diuen tipus MIME (M ultimedia I nternet M ail E XTensions), la codificació dels quals es descriu al document RFC 1521 . Alguns tipus MIME habituals trobats en una resposta HTTP són:
Tipus de connexió
El client pot demanar al servidor, en el missatge de sol·licitud, que utilitzi dos tipus de comunicació.
- No persistent
- Per a cada sol·licitud i la seva resposta, s’estableix una connexió TCP dedicada.
- Persistent
- Cada sol·licitud i la seva resposta es transfereixen mitjançant la mateixa connexió TCP. Aquest és el comportament predeterminat d'HTTP 1.1.
D'una banda, les connexions no persistents introdueixen una latència addicional en comparació amb les persistents d'almenys 3 temps d'anada i tornada (RTT). De fet, al final de cada resposta del servidor es fan necessaris
- 1,5 o 2 RTT per tancar la connexió actual, amb la seva encaixada de mans final de tres o quatre passos i ACK ( encaixada de mans de tres o quatre vies ).
- 1.5 RTT per obrir la nova connexió, pels tres passos de SYN i ACK.
D’altra banda, les connexions persistents impedeixen el paral·lelisme en les comunicacions, ja que el client que té diverses sol·licituds per enviar-lo al mateix servidor es veu obligat a processar-les de manera seqüencial, una darrere l’altra. Per aquests motius, els navegadors solen explotar les complementarietats de rendiment de les dues polítiques de comunicació per maximitzar la seva eficiència: solen obrir diverses connexions TCP en paral·lel amb cada servidor, en què es comuniquen amb una estratègia persistent.
Exemples de missatges HTTP
A continuació, es mostren exemples de missatges de sol·licitud i resposta HTTP / 1.1.
Els exemples es refereixen a la recuperació de continguts d’aquesta enciclopèdia web i es poden reproduir (i per tant verificar-los) al vostre PC copiant i enganxant el text amb un client TCP (per exemple: telnet it.wikipedia.org 80
en el cas d’URL http: / /), o client TCP amb suport SSL (per exemple: openssl s_client -connect it.wikipedia.org:443
en el cas de l'URL https: //).
A efectes de reproducció, s’assenyala que:
- la capçalera només és obligatòria en la sol·licitud HTTP / 1.1 és el
Host
capçalera que conté la part de l'host de la URL (com està escrit anteriorment); - els navegadors solen afegir la capçalera
Accept-Encoding
per especificar la possibilitat de rebre la resposta en un format comprimit. La capçalera s'elimina perquè la resposta sigui llegible (per exemple:Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
); - al final de les capçaleres, una línia buida sempre és obligatòria (és a dir, dues "línies noves" consecutives)
- les parts identificades amb [...] indiquen les parts omeses
Sol·licitud GET i resposta satisfactòria
Recupereu el recurs web present a l'URL https://it.wikipedia.org/wiki/Pagina_principale
GET / wiki / HTTP main_page / 1.1
Amfitrió : it.wikipedia.org
Agent d'usuari : Mozilla / 5.0 (compatible; Konqueror / 3.2; Linux) (KHTML, com Gecko)
Accepta : text / html, image / jpeg, image / png, text / *, image / *, * / *
Accept-Charset : iso-8859-1, utf-8; q = 0,5, *; q = 0,5
Accept-Language : it
Connexió : Keep-Alive
Resposta correcta (200 OK):
HTTP / 1.1 200 OK
Dates : divendres, 22 de febrer de 2019 10:50:37 GMT
Tipus de contingut : text / html; charset = UTF-8
Longitud del contingut : 22208
Connexió : mantenir-viu
Servidor : mw1215.eqiad.wmnet
Llenguatge de contingut : it
Codificació de contingut : gzip
Darrera modificació : divendres, 22 de febrer de 2019 08:46:20 GMT
Edat : 20548
Control de memòria cau : privat, s-maxage = 0, max-age = 0, s'ha de revalidar
Varia : Acceptar-Codificar, Cookies, Autorització
[...]
<! DOCTYPE html>
< html class = "client-nojs" lang = "it" dir = "ltr" >
<Cap>
< meta charset = "UTF-8" />
< title > Wikipedia, l'enciclopèdia lliure </ title >
[...]
</ Body>
</ Html>
Sol·licitud GET i resposta de redirecció permanent
Aquí el client recupera l'URL http://it.wikipedia.org/wiki/Pagina_principale (es diferencia de l'anterior com http en lloc de https).
La sol·licitud continua sent la mateixa que a l'exemple anterior.
La resposta canvia mostrant un codi de moviment permanent (301 Moveu permanentment):
HTTP / 1.1 301 Mogut permanentment
Data : dimecres, 19 d'abril de 2017 16:50:43 GMT
Servidor : Vernís
Ubicació : https://it.wikipedia.org/wiki/Pagina_principale
Longitud del contingut : 0
Connexió : mantenir-viu
Sol·licitud POST i resposta de redirecció temporal
Aquesta és una sol·licitud POST per canviar les vostres preferències de Viquipèdia amb el tema "Cologne Blue" (la substring & wpskin = cologneblue a la primera línia del cos de sol·licitud POST)
POST / wiki / Especial: Preferències HTTP / 1.1
Amfitrió : it.wikipedia.org
Agent d'usuari : Mozilla / 5.0 (compatible; Konqueror / 3.2; Linux) (KHTML, com Gecko)
Accepta : text / html, image / jpeg, image / png, text / *, image / *, * / *
Accept-Charset : iso-8859-1, utf-8; q = 0,5, *; q = 0,5
Accept-Language : it
Connexió : Keep-Alive
Control de memòria cau : sense memòria cau
Longitud del contingut : 1291
Tipus de contingut : application / x-www-form-urlencoded
wplanguage = ca & wpgender = desconegut & wpnickname = & wpdisablemail = 1 & wpskin = coloniablue & wppopups = 0 & wpdate = predeterminat & wpServerTime = 1034 & wptimecorrection = Sistema% 7C120 & wptimecorrection-other = 02% 3A00 & wpimages = 2 & wpmultimediaviewer-enable = 1 & wpunderline = 2 & wpstubthreshold = 0 & wpmath = mathml & wpcompact-language-links = 1 & wpeditfont = default & wpuseeditwarning = 1 & wpshowtoolbar = 1 & wpusebetatoolbar = 1 & wpusebetatoolbar-c & wppreviewontop = 1 & wprcdays = 7 & wprclimit = 50 & wphidecategorization = 1 & wpwatchlistdays = 3 & wpwllimit = 250 & wpwatchlisthidecategorization = 1 & wpcirrussearch-pref-complete-profile = difús & wpgadgets% 5B% 5D = Hidden % 5D = OpenStreetMap & wpgadgets% 5B% 5D = Consells de referència & wpgadgets% 5B% 5D = WikiMiniAtlas & wpgadgets% 5B% 5D = ExternalSearch & wpecho-email-frequency = 0 & wpecho-email-format = html & wpecho-subscriptions% 5B % 5D = email-edit-user-talk & wpecho-subscriptions% 5B% 5D = subscripcions a edit-web-thank & wpecho% 5B% 5D = web-flow-discussion & wpecho-subscriptions% 5B% 5D = web-esment & wpecho-subscriptions% 5B% 5D = drets d’usuari web & wpecho-subscripcions% 5B% 5D = drets d'usuari de correu electrònic & wpecho-subscripcions% 5B% 5D = revertit a la web & wpecho-subscriptions% 5B% 5D = usuari de correu electrònic web & wpecho-cross-wiki-notifications = 1 & wpecho -show-alert = 1 & wpEdit588129009809809809807897809807897897897897 2B% 5C & title = Special% 3APreferences & wpenotifusertalkpages
La resposta HTTP de redirecció temporal (trobat 302) condueix a la pàgina d'inici de sessió
HTTP / 1.1 302 trobat
Data : dimecres, 19 d'abril de 2017 17:21:16 GMT
Tipus de contingut : text / html; charset = utf-8
Longitud del contingut : 0
Connexió : mantenir-viu
Servidor : mw2224.codfw.wmnet
Varia : Accept-Coding, X-Forwarded-Proto, Cookie, Authorization
Caduca : dijous, 1 de gener de 1970 00:00:00 GMT
Ubicació : https://it.wikipedia.org/w/index.php?title=Speciale:Entra&returnto=Speciale%3APreferenze&returntoquery=&warning=prefsnologintext2
Edat : 0
Control de memòria cau : privat, s-maxage = 0, max-age = 0, s'ha de revalidar
Sol·licituds útils a la versió 1.0
GET / HTTP / 1.0
El GET a la versió HTTP / 1.0 és convenient per als professors, es pot fer amb una sola línia perquè a la versió 1.0 del protocol no era obligatori inserir la capçalera "Host:"
Per realitzar-ho, feu el següent:
GET / HTTP / 1.0
Recordeu deixar una línia en blanc després de la sol·licitud. Espereu la resposta del servidor web ...
HEAD / HTTP / 1.0
També és molt convenient fer la sol·licitud HEAD del protocol que només retorna les capçaleres amb:
HEAD / HTTP / 1.0
Versions segures
Com que tot el trànsit HTTP és anònim i té un text clar , s'han desenvolupat diverses alternatives per garantir diferents nivells de seguretat , en termes de
- xifratge del trànsit ;
- verificació de la integritat del trànsit ;
- autenticació del servidor;
- autenticació d'usuari.
La primera proposta va venir directament de NCSA , amb versions de servidor 1.1 i client 2.2 que donaven suport a un mecanisme d’autenticació d’usuari i xifrat de dades basat en missatges en format PEM i claus PGP .
Més tard, es van estandarditzar dues versions segures del protocol HTTP anomenades SHTTP i HTTPS . El primer, basat en el correu xifrat S / MIME , ha caigut en desús i proporciona mecanismes criptogràfics a nivell de càrrega útil : les sol·licituds i les capçaleres s’intercanvien en text clar mentre que el contingut de la pàgina es xifra com una estructura MIME multipartida . En canvi, el mecanisme HTTPS, inventat per Netscape , utilitza el canal xifrat de capa de transport subjacent mitjançant SSL o TLS per evitar la intercepció de qualsevol part de la transacció. Tots dos protocols poden garantir la identitat del remitent, però només SHTTP també pot garantir la integritat del contingut després d’haver-lo emmagatzemat, per exemple, en un disc.
Transmissió HTTP
L’ús de material multimèdia a les pàgines WEB, com ara àudio o vídeo, es gestiona d’una manera completament similar a la descàrrega de fitxers, mitjançant una càrrega progressiva o una distribució progressiva , en què el fitxer es descarrega progressivament de principi a fi (a través de temps real Protocol de transmissió i protocol de transport en temps real ) i si la velocitat de bits és excessiva per a la xarxa que el transporta, es pot produir una recàrrega contínua del buffer
Per evitar aquests problemes, hi ha altres sistemes alternatius, que permeten l'adaptació del fitxer a la xarxa de l'usuari final, aquests sistemes es caracteritzen pels protocols:
- Smooth Streaming , dissenyat per Microsoft [5] [6]
- Solució de transmissió dinàmica HTTP dissenyada per Adobe
- Solució de transmissió en directe HTTP dissenyada per Apple
- Octoshape és una plataforma de transmissió multimèdia propietària que utilitza tecnologia per oferir un millor rendiment i trencar la congestió en l’ últim quilòmetre . Té la capacitat d’utilitzar un conjunt de tecnologies de multidifusió per minimitzar l’amplada de banda de qualsevol proveïdor de CDN , ISP , emissora o última milla.
D'altra banda, aquestes solucions són considerablement més complexes que les tecnologies de transmissió tradicionals. Algunes de les consideracions documentades es relacionen amb l’emmagatzematge, els costos de codificació addicionals i la dificultat per mantenir la qualitat global. També hi ha hagut algunes dinàmiques interessants al voltant de les complexes interaccions entre la lògica de velocitat de bits adaptativa que competeix amb la lògica complexa de control de flux TCP. [7] [8]
Nota
- ^ (EN) RFC 1945 sobre Internet Engineering Task Force .
- ^ (EN) RFC 2068 a Internet Engineering Task Force .
- ^ (EN) RFC 2616 a Internet Engineering Task Force .
- ^ (EN) RFC 7540 al grup de treball d'Enginyeria d'Internet .
- ^ IIS Smooth Streaming Technical Arxivat el 5 de juny de 2011 a Internet Archive .
- ^ Transmissió suau
- ↑ An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP Arxivat el 17 d'octubre de 2011 a Internet Archive .
- ^ La velocitat de bits adaptativa és la carretera de maó groc, o l'or del ximple per a la transmissió en HD? , a fierceonlinevideo.com . Consultat el 20 de setembre de 2011 (arxivat de l' original el 7 de setembre de 2011) .
Bibliografia
Articles relacionats
- No feu un seguiment de la capçalera
- Protocol de transferència de fitxers
- Túnel HTTP
- Protocol de xarxa
- SPDY
- World Wide Web Consortium
Altres projectes
-
Wikimedia Commons conté imatges o altres fitxers sobre el protocol de transferència d’hipertext
Enllaços externs
- ( EN ) Hypertext Transfer Protocol , a Encyclopedia Britannica , Encyclopædia Britannica, Inc.
Control de l'autoritat | LCCN (EN) sh97000529 · GND (DE) 4479982-2 · BNF (FR) cb12556450f (data) |
---|