Protocol de transferència d’hipertext

Desambiguació : aquí es refereix "HTTP". Si busqueu altres significats, consulteu HTTP (desambiguació) .

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

El mateix tema en detall: codis d’estat HTTP .

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:
  • document HTML text / html
  • text / text Document de format sense format
  • document XML text / xml
  • imatge / jpeg imatge en format JPEG

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

Bibliografia

• RFC 1945 (especificació HTTP 1.0)
• RFC 2616 (especificacions HTTP 1.1)

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.

Portal d’Internet

Portal Telemàtic