Capa d'aplicació

De castillowiki
Saltar a: navegación, buscar

En el model TCP/IP, la capa d'aplicació és el nivell més alt del model de capes TCP/IP i també del model OSI, tot i que ofereixen serveis diferents. El model OSI defineix, en els nivells més alts, a part de la capa d'aplicació, les capes de sessió i presentació. A TCP/IP, la capa d'aplicació reflecteix la funcionalitat de les tres capes esmentades del model OSI.


UDP encapsulation.png

Introducció

La capa d'aplicació és l'encarregada de fer d'interfície entre l'usuari i la xarxa. Interactua directament amb els programes d'aplicació dels usuaris, fent ús de protocols d'alt nivell que resolen aspectes de representació, codificació i control de diàleg.

En aquesta capa apareixen diferents protocols que donen suport a les tasques de xarxa més comunes. Són els següents:

  • HTTP: Hypertext Transfer Protocol. Proporciona el servei de pàgines web, mitjançant el qual podem sol·licitar-les a un servidor i visualitzar-les en navegadors clients.
  • FTP: File Transfer Protocol. Aquest protocol permet l'accés al sistema de directoris d'un ordinador remot, així com l'enviament, la descàrrega i la pujada de fitxers. Com a mesura de seguretat, l'accés a aquests directoris està protegit per un sistema de control d'accés de l'estil usuari-contrasenya.
  • SMTP: Simple Mail Transport Protocol. Proporciona el servei de correu electrònic, permetent així l'enviament de missatges a altres usuaris de la xarxa. Aquests missatges s'envien primer a uns equip servidors especials (servidors de correu), des d'on poden ser descarregats pel destinatari final.
  • DNS: Domain Name Service. Proporciona el servei de traducció de noms de domini en direccions IP reals.
  • TELNET: Protocol de Servei de Connexió Remota. És un emulador de terminal que permet accedir als recursos i executar programes en un ordinador remot, actuant sobre ell com si hi estiguéssim físicament connectats.
  • TFTP: Trival File Transfer Protocol. Semblant al protocol FTP, però més simple. No implementa el sistema de control d'accés.
  • DHCP (Dynamic Host Configuration Protocol - Protocol de configuració dinàmica d'amfitrió).
  • NAT (Network Address Translation - Traducció de direcció de xarxa).
  • POP (Post Office Protocol) para correu electrònic.
  • SSH (Secure SHell)

Estudi d'un protocol (HTTP)

El protocol de transferència d'hipertext o HTTP (HyperText Transfer Protocol) estableix el protocol per a l'intercanvi de documents d'hipertext i multimèdia al web. Apareix el 1990 amb la versió referida com a HTTP/0.9 com un protocol pensat per a la transferència simple de dades a través d'Internet. No és fins a la versió referida com a HTTP/1.0 quan els missatges transferits són enviats en format MIME, el que implica l'enviament de metainformació conjuntament amb les dades transferides així com la capacitat de precisar el propòsit de les consultes (requests en anglès) entre el client i el servidor.

La versió actual d'HTTP és la 1.1 i està especificada en el document [RFC-2616].

HTTP disposa d'una variant xifrada mitjançant SSL anomenada HTTPS.

Funcionament

HTTP segueix un model client-servidor on el client (generalment un navegador) inicia la petició d'informació establint una connexió TCP/IP al port 80 d'una màquina remota. El servidor espera una petició (consulta o request) amb el mètode i la versió del protocol utilitzat: p.ex. "GET / HTTP/1.2". A continuació, mitjançant una semàntica específica, s'envien una sèrie de capçaleres amb extensions MIME que donen metainformació sobre el tipus de document multimèdia demanat, estat de connexió, etc. a un recurs d'Internet, la referència al qual es fa mitjançant les URI (Universal Resource Identifier), com a lloc mitjançant URL (Universal Resource Locator) o com a nom mitjançant URN (Universal Resource Name).

La resposta del servidor és un Acknowledge seguit del fitxer demanat, un missatge d'error, etc. El mètode GET és el més comú i permet fer lectures de pàgines, però també existeixen POST, PUT, etc.

La connexió establerta és tancada al finalitzar la transferència i la informació no és emmagatzemada enlloc. Aquesta característica ha fet proliferar l'ús de Cookies com a sistema per guardar paquets d'informació útils sobre cada usuari i així fer possible que el servidor el reconegui en quan torni a fer-li una consulta.

Missatge de petició

El missatge de petició està format per:

  • Línia de petició, com GET /images/logo.gif HTTP/1.1, que sol·licita un recurs anomenat /images/logo.gif al servidor
  • Capçaleres, com ara Accept-Language: ca (En el cas de HTTP/1.1 cal dir el HOST)
  • Una línia en blanc
  • El cos del missatge (opcional)

Exemple:

GET / HTTP/1.1 
host: web.simarro

La línia de petició i les capçaleres han d'acabar totes amb <CR><LF> (és a dir, Carriage Return (retorn de carro) seguit per un Line Feed). La línia en blanc només ha de ser <CR><LF>, sense cap espai. En el protocol HTTP/1.1 totes les capçaleres, excepte Host, són opcionals.

Una línia de petició que només contingui la ruta del fitxer és acceptada pels servidors per tal de mantenir la compatibilitat amb els clients HTTP anteriors a l'especificació HTTP/1.0 .

Mètodes de petició

Mètodes segons l'especificació RFC 2616 que correspon a HTTP/1.1 .

L'HTTP defineix vuit maneres (a vegades anomenats "verbs") d'indicar l'acció destijada que s'ha de dur a terme sobre el recurs. El que el recurs representa depèn de la implementació de cada servidor. Normalment però, aquest recurs és el contingut d'un fitxer, o la sortida d'un executable resident al servidor.

HEAD
Sol·licita una resposta, idèntica a la que es generaria amb una consulta GET, però sense el cos de la resposta. Aquesta comanda és útil per aconseguir les meta-dades incloses en la capçalera de la resposta, sense haver-se d'enviar tot el contingut.
GET
Sol·licita una representació del recurs especificat. Noti's que GET no s'ha d'usar per operacions que tinguin efectes col·laterals, com ara accions sobre aplicacions web. La raó és que el GET escriu les dades en la URI. Exemple: /index.php?page=main&lang=es
POST
Envia dades per a ser processades (p. ex, en un formulari HTML) a un recurs específic. Les dades s'inclouen en el cos de la petició. Això pot implicar la creació d'un nou recurs o l'actualització d'aquest si ja existeix (o ambdós).
PUT
Apuja una representació del recurs especificat. Els hostings compartits no solen tindre habilitat PUT. Però en teoría és millor que POST per a penjar alguna cosa, ja que es crea un socket en el servidor i la càrrega és més directa.
DELETE
Esborra el recurs especificat.
TRACE
Retorna la consulta rebuda, perquè el client pugui veure quines coses estan afegint o canviant els servidors intermitjos.
OPTIONS
Retorna els mètodes HTTP que el servidor suporta per a una URL determinada. Es pot fer servir per esbrinar la funcionalitat del servidor web enlloc d'un recurs específic.
CONNECT
Converteix la connexió de petició en un túnel TCP/IP transparent, normalment per facilitar comunicacions xifrades amb SSL (HTTPS) a través d'un proxy HTTP no xifrat.

Els servidors han d'implementar com a mínim els mètodes GET i HEAD HTTP 1.1 Section 5.1.1 i, quan sigui possible, també el mètode OPTIONS.