Apunte de Clase del 13/11/2007 (Teoría de las Comunicaciones)

Clase 13/11

Telnet (RFC 854)

Fue creado en 1984, había terminales bobas y mainframes, todo lo calculaba el mainframe que se conectaba a una red y escupía a las terminales bobas. Había distintos tipos de terminales bobas, incompatibles entre si, de capacidades distintas. La idea de telnet es simular por la red la conexión entre el mainframe y las terminales.

El modelo teórico detrás de telnet es inventar una terminal boba modelo con capacidad limitada y que el protocolo mismo pueda hacer update de las capacidades. Se define entonces una serie de comandos genéricos para esta terminal modelo que luego se traducirán a comandos específicos de cada terminal. Yo puedo querer que una terminal mande las información de a líneas o de a caracteres, esto se puede regular con Comandos que permiten negociar características: do, don't, will y won't. Para un comando de interrumpir proceso se quiere que actúe de forma inmediata. Para eso telnet aprovecha el mecanismo de urgente de TCP y manda algo con un comando de interrupción en el medio. Al estar marcado como urgente, se sabe que se deben parsear las marcas especiales primero.

Con Telnet se define un canal transparente de 7 bits extensible (no 8 porque la mitad de las palabras se usan para distintos comandos).

Dos objetivos:

• Definir un canal de comunicaciones para otros protocolos
• El segundo es para terminal remota. A Telnet no le importa la autenticación, lo delega al servidor. Encima de todo, Telnet viaja plano (con un sniffer lees todo el tráfico que pasa). Esta es la razón principal por la que no se usa más. POP3 viaja sobre telnet, entonces el mail también es inseguro.

FTP (RFC 959)

Esencialmente es para transferir archivos.

Está compuesto por varios módulos.

• Servidor FTP (el que guarda los archivos)
• Un cliente donde está el usuario

Servidor:

• Hay un intérprete del canal de comandos por donde uno le va a dar ordenes al servidor
• Otro modulo para satisfacer los pedidos y las cuestiones de threading\\

Del lado cliente:

• Modulo para dar las órdenes
• Uno para enviar datos
• Y un interprete para automatizar varias cosas (tener comandos PUT y GET)

Esta escuchando en el puerto tcp 21 esperando datos y comandos, y los módulos reaccionan ante los comandos que uno emite.

Pasos normales de una sesión:

1. Manda los comandos de autenticación
2. El servidor responde con un código numérico (y un texto informativo para el usuario)
3. El cliente puede enviar otros comandos.

Ej: RETR /etc/passwd

• Comandos de cambio de directorio (CWD)
• de user y pass para auth (USER, PASS), QUIT
• comandos para inicializar la sesión y preparar el canal PORT-PASV-TYPE ( para especificar tipos de archivo) (hoy en día se usa solo ASCII y binario).
• LIST, STOR, RETR

Los nros que devuelve el servidor distintas cosas y pertenecen a familias según el primer nro. Ej: 3XX si la acción "va bien pero hay que hacer más cosas", 4xx y 5xx son errores temporarios (debería intentar de vuelta el comando) y permanentes (insalvable). Notar que los comandos de correo son algo parecidos.

EJ "modo activo":

CWD /Files
PORT < // Prepara al canal. Tengo que informar al servidor a dónde se va comunicar con una séxtupla con ip y port.
RETR a.txt

Nota: El canal de control puede tener ip y puerto distinto del de transferencia. MGET es la aplicación sucesiva de esto.

Ej "modo pasivo": El servidor abre activamente una conexión con el cliente y con PASV le dice a donde conectarse (es importante si hay firewalls en el medio).

Los modos no están limitados por el protocolo a activos y pasivos. Ej: Un triángulo

S1 ---> S2
 \     /
  \   /
    C

Podría copiar cosas de un servidor a otro sin pasar por el cliente. Es peligro y se sabe, se usa para piratería.

HTTP HyperText Transfer Protocol (RFC 2616)

Protocolo del servidor y del cliente state-less (ignorando las aplicaciones web que usan sesión y esas cosas, ya que son una mentira). Comunicaciones por TCP, usualmente puerto 80. Eso no significa que no se use el protocolo en otros puertos.

Mensajes

Tiene en común con SMTP y FTP los comandos de 4 letras y las respuestas de nros. Dividido así:

Pedido: Método / comando -- Recurso -- Protocolo
Headers: Semejante a los de correo (Accept, CONTENT-TYPE)
Body:

Ej: GET / HTTP/1.0

Una respuesta va a tener una estructura similar:

Respuesta: Protocolo -- Nro Error -- Texto
Header: 
Cuerpo: En MIME

Ej: HTTP/1.0 200 OK

Hay tres protocolos principales en uso:

• HTTP/0.9 (histórico, no se usa)
• HTTP/1.0 (No puede hacer servidores virtuales)
• HTTP/1.1

La versión es importante ya que al cambiar la revisión menor (el 2do nro) se supone que el protoclo debe seguir siendo compatible, aunque con posibles extensiones.

Comandos

• GET url -> "quiero cierto recurso", el servidor debería responder en el cuerpo el objeto indicado.
• HEAD -> Parecido a GET, es como "de practica", el servidor devuelve todo pero sin el cuerpo (estado, tag, hash).
• POST -> El inverso a GET. Su uso más común es el envío de formularios. El resultado es un mensaje donde hay opcionalmente un cuerpo donde, por ej, podría dar una respuesta de lo que hizo. Es para dar la información de un recurso ya hecho, no es para crear objetos (no confundir con PUT).

Urls

http://      www.dc.uba.ar  /
protocolo    servidor       recurso

• Ej: GET /Index.aspx (esto sería comunicación directa, sin pasar por un proxy)
• Ej2: GET http://www.dc.uba.ar/ (ya que el proxy puede necesitar todo)

Notar que si se desea hacer uso de servidores virtuales y no se posee el header Host (ver HTTP V1.1) es necesario enviar la ruta completa del recurso, ya que el servidor virtual no tiene manera de saber a qué dominio pertenece el recurso pedido.

Headers

Son información extra para el servidor. Se los puede aplicar al objeto que se está tratando de recibir (content type), a aspectos de la conexión o como codificación de la transferencia. Son un contenido textual como los de correo. Hay varios tipos de encabezados. Veamos algunos importantes:

• Accept (por ej, para pedir o no imágenes)
• cache control
• de Compresión
• Content length y language
• Host: para tratar con servidores virtuales y permite diferenciar distintos servidores virtuales en un mismo puerto (y obviamente servidor físico)
• Date
• User-Agent: Sirve para indicar qué navegador
• Referer: guarda desde qué link se llega al destino

Manejo de sesión

Como el protocolo es stateless, se utilizan cookies. Permiten compensar el hecho de que el protocolo no tiene estado con un archivo en el cliente. El servidor envía un texto plano al cliente el cual tiene que enviarlo al servidor en cada pedido que realice.

Autenticación

El cliente debe pedirle al usuario las credenciales. Se manda en un encabezado auth, que el servidor chequea contra sus usuarios conocidos.

• Método basic de seguridad: Enviar en base 64 el user y pass. Es inseguro frente a sniffing.
• Método diggest: Más seguro, el password no viaja directamente.

Respuesta a los pedidos

Como en FTP, hay cinco familias de errores:

1xx: Pregunta parcial
2xx: De éxito
3xx: Redirecciones
4xx: Errores del cliente (Ej: 404, 401, etc)
5xx: Errores del servidor (Ej: error interno del server 500, 503 serv sobrecargado).

Versiones

HTTP tiene dos versiones principalmente: 1.1 y 1.0. Los agregados mas importantes de 1.1 son los siguientes:

• Campo Host obligatorio, que requiere toda la URL del host al que se está realizando el pedido, para permitir el uso de servidores virtuales.
• Campo connection para persistencia, permite mantener una misma conexión TCP abierta entre el cliente y el servidor si se quieren realizar múltiples pedidos; cualquiera de las dos partes puede cerrarla. Esto evita tener que hacer un handshake TCP por cada get al servidor, y se guarda la info de control de congestion.
• Pipelining de comandos permite enviar múltiples pedidos al servidor sin esperar la respuesta de cada uno de ellos. Se usa dentro de una determinada connection. El servidor devuelve las respuestas en orden.

Caching

Los recursos tienen un atributo asociado Last Modified. Un cliente puede pedir un recurso si este fue modificado luego de una determinada fecha. Dependiendo del valor enviado por el cliente, el servidor contesta que no hubo cambios, o con el nuevo objeto. Además del campo last modified, pueden incluirse tags o hashes del archivo para hacer uso de cache.