| Memòria del TFC: Creació del nucli d'un servidor Web; XicHttpd | ||
|---|---|---|
| Anterior | Capítol 1. Conceptes teòrics. | Següent |
En aquest apartat s'intenta donar una visió sintetitzada dels trets bàsics que caracteritzen el protocol HTTP. L'objectiu és utilitzar-lo de base de cara a recollir els requisits del protocol que haurà d'implementar el nostre servidor.
EL protocol de transferència d'HiperText (Hypertext Transfer Protocol) és un protocol client/servidor senzill i eficient que defineix les regles que han de seguir les comunicacions entre el servidors web i els clients (navegadors, software de descàrrega, etc.).
HTTP està basat en operacions senzilles de solicituts-respostes (Request-Response), de manera que el client envia un missatge amb les dades de la solicitut al servidor, i aquest envia un missatge de resposta al client amb les dades sobre l'estat de l'operació i el seu possible resultat. Totes les operacions poden fer referència a l'objecte de recurs sobre el que actuen, i la manera de referir-se a aquests objectes és per mitjà de la seva URL (Uniform Recource Locator).
Les característiques més rellevants són:
Tota la informació codificada en els missatges es transmet per mitjà de caràcters de 8 bits, el que permet de transmetre qualsevol tipus de recurs respectant-ne el format.
Per a transferències multimèdia se n'identifica el format per mitjà de la seva classificació MIME[1], de manera que el client sempre sap el què li arriba i com tractar-ho.
Existeixen tres comandes bàsiques: GET per demanar un recurs, POST per enviar informació al servidor i HEAD per demanar informació sobre un recurs. N'hi ha algunes més però el seu ús no està massa estès.
En l'HTTP/1.0 la persistència era opcional i es controlava per mitjà d'una capçalera especial, però en l'HTTP/1.1 s'implementa la persistència per defecte, eliminant així la sobrecàrrega en totes les connexions.
No es mantenen els estats, és a dir, cada operació s'efectua de manera independent, sense tenir en compte les transaccions anteriors, ja sigui del mateix client o de diversos.
Cada objecte sobre el que actuen les operacions és identificat per la informació de situació del final de la URL.
De qualsevol transacció HTTP sen poden distingir les següents etapes:
El client accedeix a una URL, ja sigui escrivint-la directament en el navegador, o per mitjà d'un hiperenllaç.
El client Web decodifica la URL, separant-ne les diferents parts, així n'identifica el protocol (HTTP en el nostre cas), la direcció DNS o IP del servidor, el possible port (per defecte el 80), i l'objecte demanat al servidor.
S'obre una connexió TCP/IP amb el servidor sobre el port 80 (o el que s'hagi especificat).
Es fa la petició: S'envia la comanda adient (GET, HEAD, POST, ...), seguida de la URL de l'objecte demanat, la versió del protocol, i un conjunt de capçaleres amb diferents tipus d'informació.
El servidor respon a la petició enviant un missatge de resposta que conté el codi d'estat, una serie de capçaleres entre les que destaquem el tipus MIME de la informació, seguit de la pròpia informació.
Tancament de la connexió TCP/IP.
Els coneixedors del protocol TCP/IP s'adonaran que l'HTTP explicat fins ara, fa un ús ineficient de les característiques de rendiment del TCP/IP com és l'ús de finestres de connexió: Posem per cas que el client accedeix a una plana amb quinze imatges, aleshores el client faria una petició, i s'esperaria a rebre la imatge per fer la següent petició, i així successivament fins a les quinze vegades, si a més resulta que les imatges són molt petites (de la mida d'un píxel per decorar taules per exemple), tenim que mai s'arriba a omplir la finestra TCP provocant una ineficiència considerable en l'ús de la xarxa.
El Pipelining és una tècnica prevista per a la implementació de clients i servidors que permet de multiplexar múltiples peticions, i llurs respostes en una mateixa transferència i aprofitar així les característiques d'eficiència del TCP/IP, així se soluciona el problema descrit en l'anterior pàrraf, de manera que el client faria totes les peticions encadenades l'una al darrere de l'altra sense esperar per cada una, i enviant-les totes de cop, el servidor per la seva banda prepararia les respostes en un buffer intermig, i quan tingui prou dades les enviaria al client. Cal que el servidor vigili de no fer esperar massa les respostes, òbviament no es tracta d'aprofitar l'eficiència per una banda penalitzant el rendiment per l'altra.
Veiem ara un exemple concret:
El protocol HTTP només defineix dos tipus de missatges: Les peticions o Request i les respostes o Response. Cada missatge està format per una línia d'inici, cap o més camps de capçalera i una línia en blanc indicant el final de les capçaleres, i finalment el cos del missatge si s'escau. Les capçaleres segueixen el format definit a l'[RFC 822 [9]], de manera que cada camp ocupa una línia acabada amb CRLF, i s'usa ASCII per la codificació dels caràcters.
Els missatges doncs seguiran el següent esquema:
Request.
Comanda SP URL SP Versió-HTTP CRLF Capçalera-1 CRLF Capçalera-2 CRLF ... Capçalera-n CRLF CRLF (línia buida) Cos-missatge (opcional)
Response.
Versió-HTTP SP Codi-estat SP descripció-codi CRLF Capçalera-1 CRLF Capçalera-2 CRLF ... Capçalera-n CRLF CRLF (línia buida) Cos-missatge (opcional)
On tenim que SP significa espai en blanc, i CRLF són els caràcters CR (Carry return) y LF (Line Feed)
Les comandes són aquelles operacions que el client demana sobre un recurs al servidor HTTP. La seva sintaxi és molt senzilla com s'ha vist en l'exemple de petició de l'apartat anterior:
Comanda SP URL SP Versió-HTTP CRLFEn cas que la comanda necessiti especificar alguna característica especial es fa ús de les capçaleres del missatge.
Les diferents comandes reconegudes a l'especificació del protocol [RFC 2612] són les següents:
OPTIONS. Mètode utilitzat per demanar informació sobre les opcions de comunicació disponibles en l'intercanvi de peticions/respostes sobre un recurs. D'aquesta manera el client pot determinar les opcions i/o requeriments associats a un recurs, o les capacitats del servidor sense que això impliqui actuar sobre el recurs. Per exemple, es poden determinar les comandes permeses sobre un determinat recurs, o la codificació que s'emprarà per transmetre'l.
GET. El mètode GET és el que s'utilitza per demanar qualsevol tipus de recurs, ja siguin pàgines web, imatges, o en general qualsevol tipus d'arxiu. Òbviament si l'URI fa referència a un programa o script (CGI, ASP, PHP, ...) aquest serà executat al servidor i sen retornarà la seva sortida.
HEAD. Aquest mètode és idèntic al mètode GET, excepte que no s'envia el cos del missatge, sinó només les capçaleres.
POST. Mètode utilitzat per enviar informació (o dades) al servidor, de manera que el servidor les passa al recurs identificat per l'URI (normalment un script o programa) per tal que les processi. El servidor depenent del resultat de la operació pot retornar la sortida del programa, o bé no retornar res (codi 204 No Content).
PUT. Mètode que indica que el cos del missatge s'ha de deixar a l'URI indicada en la petició, o bé reemplaçar-lo si aquest ja existeix.
DELETE. El mètode DELETE demana al servidor que elimini el recurs identificat per l'URI de la petició.
TRACE. Aquest mètode permet al client de veure quina informació rep el servidor. Posem per exemple que hi ha un proxy entre mig de la comunicació, aleshores aquest servidor intermediari, quan rep una petició del client, la reenvia al servidor ficant-li les seves pròpies capçaleres. Així si el client fa un TRACE sobre un determinat recurs, el servidor li retornarà les capçaleres que ha rebut al cos del missatge de resposta.
CONNECT. Aquesta és una comanda reservada per ser utilitzada amb els servidors proxy quan aquests poden convertir-se en un túnel dinàmicament (com ara un túnel SSL).
Les capçaleres HTTP són un conjunt de variables que s'adjunten als missatges per tal de descriure alguna característica, o de complementar-ne el significat. El format de les capçaleres és el següent:
Nom-Varialbe: SP Valor-VariableOn segons el tipus de variable, Valor-Variable pot prendre un o més valors separats per algun caràcter separador.
Les capçaleres definides al [RFC 2616] són:
Capçaleres generals.
Cache-Control Connection Date Pragma Trailer Transfer-Encoding Upgrade Via Warning
Capçaleres de les peticions (Request).
Accept Accept-Charset Accept-Encoding Accept-Language Authorization Expect From Host If-Match If-Modified-Since If-None-Match If-Range Max-Forwards Proxy-Authorization Range Referer TE User-Agent
Capçaleres de les respostes (Response).
Accept-Ranges Age ETag Location Proxy-Authenticate Retry-After Server Vary WWW-Authenticate
Capçaleres del contingut (Entity).
Allow Content-Encoding Content-Language Content-Length Content-Location Content-MD5 Content-Range Content-Type Expires Last-Modified extension-header
Com s'ha vist quan parlàvem dels missatges, la primera línia del missatge de resposta del servidor conté el codi d'estat, fent referència a la petició solicitada. Podem veure els codis d'estat definits per l'especificació del protocol a la següent taula:
Taula 1-1. Codis d'estat del servidor HTTP
| Codi | Comentari |
|---|---|
| 1xx | Informació |
| 100 | Continue |
| 101 | Switching Protocols |
| 2xx | Èxit |
| 200 | OK |
| 201 | Created |
| 202 | Accepted |
| 203 | Non-Authoritative Information |
| 204 | No Content |
| 205 | Reset Content |
| 206 | Partial Content |
| 3xx | Redirecció |
| 300 | Multiple Choices |
| 301 | Moved Permanently |
| 302 | Found |
| 303 | See Other |
| 304 | Not Modified |
| 305 | Use Proxy |
| 306 | (No utilitzat) |
| 307 | Temporary Redirect |
| 4xx | Error del client |
| 400 | Bad Request |
| 401 | Unauthorized |
| 402 | Payment Required |
| 403 | Forbidden |
| 404 | Not Found |
| 405 | Method Not Allowed |
| 406 | Not Acceptable |
| 407 | Proxy Authentication Required |
| 408 | Request Timeout |
| 409 | Conflict |
| 410 | Gone |
| 411 | Length Required |
| 412 | Precondition Failed |
| 413 | Request Entity Too Large |
| 414 | Request-URI Too Long |
| 415 | Unsuported Media Type |
| 416 | Requested Range Not Satisfiable |
| 417 | Expectation Failed |
| 5xx | Error del Servidor |
| 500 | Internal Server Error |
| 501 | Not Implemented |
| 502 | Bad Gateway |
| 503 | Service Unavailable |
| 504 | Gateway Timeout |
| 505 | HTTP Version Not Suported |
La majoria de clients Web mantenen una còpia local de les pàgines visitades anteriorment, amb la data de modificació. L'objectiu no és altre que reduir el nombre de connexions a internet, així quan el client accedeix a una web, primer es comprova si la pàgina es troba a la cau, si hi és s'envia un HEAD al servidor per comprovar la data de modificació de la plana, si és la mateixa que la que té a la cau, s'usa la còpia local, i sino es fa un GET per obtenir-ne la última versió, i a més s'actualitza el contingut de la cau.
Un servidor Proxy es situa entre el client i el servidor Web, de manera que el client es connecta al Proxy per demanar un recurs enlloc de fer-ho al servidor original, i el Proxy actua de manera molt semblant al que em explicat.
El principal avantatge d'utilitzar servidors Proxy en les organitzacions és que proporcionen un únic punt d'entrada/sortida a internet, el que permet tenir un control més eficient sobre l'ús d'internet i la seguretat, i a més sen redueix el tràfic considerablement, ja que els clients acostumen a accedir a conjunt semblant de pàgines.
Tot i això en alguns casos les cau poden tenir copies obsoletes, sobretot de pàgines generades dinàmicament. De tota manera el protocol HTTP permet de controlar certs aspectes de com gestionar les còpies de la cau per mitjà d'algunes capçaleres.
| [1] | MIME és l'acrònim de Multipurpose Internet Mail Extension. |
| [2] | Per exemple quan el tipus de transferència és "chunked" s'indica la posició de les parts que s'envien amb la capçalera Content-Range. |