Redes de computadores (página 2)

Partes: 1, 2

¿Cómo se identifica el socket?
Para enviar una carta a un amigo es necesario saber su dirección para que llegue al buzón de su casa.
Cada sistema final tiene un dirección IP única de 32 bits.

P: ¿es suficiente con la dirección para hacer que llegue la carta a un amigo?
R: No, varias personas pueden estar viviendo en el misma casa.
Varios protocolos de aplicación pueden estar ejecutándose en un sistema final.
Navegador, lector de correo, Skype, …

A las direcciones IP se les asocia un nombre, que es el que se utiliza para identificar a los equipos.
Por ejemplo, www.dte.us.es = 150.214.141.196
Más sobre nombres en el apartado siguiente…
Nota

Cada protocolo de aplicación se identifica por un número de puerto.
El número de puerto usado para identificar al proceso cliente y servidor en general no coinciden.
Ej. de número de puerto:
Servidor HTTP: 80
Servidor Email: 25
Servidor DNS: 53

La ICANN (Internet Corporation for Assigned Names and Numbers), se encarga del registro de los puertos de protocolos de aplicación públicos.
http://www.iana.org/assignments/port-numbers
Existen diferentes tipos de puertos.
Un socket queda identificado por:
Dirección IP.
Número de puerto.
¿Cómo se identifica el socket?

Internet
Interfaz Usuario
Interfaz Usuario
Dir IP cliente, puerto
Ejemplo
Servidor web DTE
150.214.141.196, 80

Localhost suele tener asociado la IP 127.0.0.1, aunque puede ser otra. Más en el tema 4…
Localhost: Conectando 2 procesos del mismo sistema final
Nota
localhost: es un “nombre especial” que está asociado a una dirección IP especial que sirve para identificar al propio sistema final.
Permite probar aplicaciones en red en un único sistema final sin necesidad de estar conectado a una red.
En general permite comunicar procesos en un mismo sistema final usando los servicios de comunicaciones de Internet.

P: ¿Por qué el Servicio de Comunicación del sistema final es capaz de distinguir a cada proceso?
(Gp:) Servicio de Comunicación de Internet S.O.
(Gp:) socket1
(Gp:) proceso1
(Gp:) socket2
(Gp:) proceso2

¿Qué servicios de transporte necesito?
Perdida de datos
Algunas aplicaciones toleran algo de perdida (ej: audio, video)
Otras requieren 100% de fiabilidad (ej: login, transferencia de archivos)
Temporización
Algunas aplicaciones precisan de retardos cortos para ser 'efectivas' (ej: telefonía por internet, juegos interactivos)
Tasa de transferencia
Algunas requieren una tasa mínima para funcionar adecuadamente (ej: multimedia)
Otras, conocidas como “aplicaciones elásticas”, hacen uso de la tasa disponible en cada momento
Seguridad
Encriptación, integridad de los datos, …

Requisitos de algunas aplicaciones comunes
Aplicación

transferencia ficheros
e-mail
páginas web
audio/vídeo en
tiempo real
audio/vídeo archivado
juegos interactivos
mensajería instantánea
Pérdida datos

sin pérdidas
sin pérdidas
sin pérdidas
tolerante

tolerante
tolerante
sin pérdidas
Tasa transferencia

elástica
elástica
elástica
audio: 5kbps-1Mbps
vídeo:10kbps-5Mbps
como la anterior
varios kbps
elástica
Sensible temp.

no
no
no
Sí, 100’s ms

Sí, pocos segs
Sí, 100’s ms
Sí y no

Servicios de los protocolos de Internet
Servicio TCP:
Orientado a conexión: requiere acuerdo previo entre los procesos cliente y servidor antes de iniciar la transferencia
Transporte fiable entre procesos emisor y receptor
Control de flujo: emisor no saturará al receptor
Control de congestión: uso equitativo del ancho de banda
No provee: temporización, garantizar un ancho de banda, seguridad
Servicio UDP:
Transporte ligero, no orientado a conexión y no confiable entre procesos emisor y receptor
No provee: acuerdo previo entre procesos, fiabilidad, contol de flujo, control de congestión, temporización, ancho de banda garantizado, ni seguridad.

P: ¿Qué utilidad tiene UDP?

Ejemplos: Protocolos de aplicación y transporte
Aplicación

e-mail
acceso remoto
web
transferencia de ficheros
streaming multimedia

telefonía IP

Traducción de nombres
en direcciones IP

Protocolo delnivel de aplicación

SMTP [RFC 2821]
Telnet [RFC 854]
HTTP [RFC 2616]
FTP [RFC 959]
HTTP (ej: YouTube), RTP [RFC 1889]
SIP, RTP, propietario
(ej: Skype)

DNS [RFC 1034]

Protocolo de transporte

TCP
TCP
TCP
TCP
TCP
o UDP

usualmente UDP

TCP o UDP (usual)

DNS: Domain Name System
personas: muchos IDs:
DNI, nombre, nº seguridad social…
equipos y routers de Internet:
direcciones IP (32 bit) – sirven para direccionar datagramas
“nombre”, ej: www.google.com – usado por humanos
P: ¿cómo mapeamos entre direcciones IP y nombres y viceversa?
Domain Name System:
Base de datos distribuida implementada con una jerarquía de servidores de nombres
Protocolo de nivel de aplicación: equipos y servidores de nombres se comunican para resolver nombres (traducción de direcciones y de nombres)
nota: característica fundamental de Internet, ¡implementada en el nivel de aplicación!

DNS
¿por qué no centralizar el servicio de DNS?
Único punto de falla
Volumen de tráfico
Distancia a la base de datos
Mantenimiento
en definitiva…
¡no sería escalable!
Servicio DNS
Traducción de nombre a IP (directa)
Traducción de IP a nombre (inversa)
Creación de ”alias”
Alias de email
@dominio
Distribución de carga
Servidores web replicados: conjunto de Ips para un único nombre canónico
Usa UDP
El cliente envía mensajes al puerto 53 del servidor a través del socket.

DNS: caché y actualización entradas
Una vez que un servidor DNS aprende una traducción, ésta se guarda en una memoria caché
Las traducciones más habituales suelen estar en caché y no hace falta consultar a otros DNS.
Las entradas de la caché “caducan” tras un tiempo determinado (timeout)
Hay mecanismos de actualización y notificación entre DNS propuestos por el IETF standard
RFC 2136

DNS: ¿cómo funciona? (simplificación)
Cuando una aplicación en un sistema final consulta al servicio DNS la dirección IP asociada a un nombre de equipo, o viceversa. El servicio DNS busca en su “caché de DNS” para ver si tiene una entrada para la dirección IP o el nombre, según corresponda, puede ocurrir que…
… encuentre la entrada.
En este caso le devuelve a la aplicación la IP o el nombre.
… no encuentre la entrada.
Envía un mensaje (DNS_PDU) de “Solicitud de DNS” al servidor de DNS que tenga configurado y se espera a recibir la “Respuesta de DNS” del servidor con la información solicitada que entregará a la aplicación que solicitó su servicio.
En caso de que no sea posible resolver un nombre o una dirección IP avisa a la aplicación que solicitó su servicio
Un servidor de DNS al recibir una “Solicitud DNS” se comporta como el servicio de DNS en el sistema final, busca en su caché y consulta a otros servidores de DNS si no encuentra la información solicitada.
Nota

DNS: ¿Cómo funciona? Cont.
tiempo
tiempo
Nivel
Aplicación
Nivel
Aplicación
Servicio
Transporte
No fiable
Envío DNS_PDU
Recepción DNS_PDU
Servicio no confirmado
Envío DNS_PDU
Recepción DNS_PDU
Cliente
Servidor

WWW (World-Wide-Web)
Primero, un repaso…
Una página web contiene una serie de objetos
Esos objetos pueden ser: fichero HTML, imagen JPEG, applet Java, fichero audio,…
Consiste en un fichero base HTML que incluye objetos referenciados
Cada objeto es direccionable a través de su URL
Ejemplo de URL (Uniform Resource Locator):

(Gp:) www.informatica.us.es/index.php/organizacion-docente
(Gp:) host name
(nombre del servidor
donde está el objeto)
(Gp:) path name
(nombre de la ruta
al objeto en el servidor)

Formato del lenguaje HTML
Sirve para elaborar las páginas web, desde 1991. Se usan elementos con etiquetas entre < >. Cada elemento suele tener 4 campos: una etiq. inicio (< html>) y una etiq. cierre (< /html>), unos atributos (en la de inicio) y un contenido (entre ambas).
< !DOCTYPE html…> define inicio documento (opcional)
< html>página< /html> define inicio/fin documento
< head>cabecera< /head> el contenido de la cabecera (información “no visible” al usuario, como título, estilos, metainformación, etc…)
< body>cuerpo< /body> define el cuerpo, contiene:
de < h1> a < h6> encabezados
< table>tabla< /table> crea una tabla filas/cols
< a href=“URL”>enlace< /a> hipervínculo: al hacer click en “enlace” se solicita la página de URL.
< img src=“URL”/> imagen referenciada, el navegador la carga a continuación desde URL para visualizarla.
(Gp:) Se puede ver el código HTML de una página en elnavegador, botón derecho -> ver código fuente
(Gp:) Nota

Vistazo de HTTP
HTTP: HyperText Transfer Protocol
Protocolo de nivel de aplicación para la web
Modelo cliente/servidor
cliente: navegador que pide, recibe y muestra los objetos web
servidor: proceso que envía los objetos pedidos por los clientes
PC corriendo
IExplorer
Servidor
corriendo
servidor webApache
Linux corriendo
Firefox
Petición HTTP
Petición HTTP
Respuesta HTTP
Respuesta HTTP

Nota
Vistazo de HTTP (cont.)
Usa TCP:
El cliente inicia una conexión TCP (“crea un socket”), con el puerto 80 del servidor
El servidor acepta la conexión TCP del cliente
Se intercambian mensajes HTTP (de nivel de aplicación) el navegador web (cliente) y el servidor web (servidor)
Se cierra la conexión TCP
HTTP es “sin estado”
El servidor no guarda información acerca de las peticiones anteriores de los clientes
Los protocolos que recuerdan el estado son “complejos”:
El histórico de estados anteriores se debe mantener
Si el cliente o el servidor “caen” sus estados pueden ser inconsistentes y tienen que sincronizarse

Tipo de conexiones HTTP
HTTP no-persistente
Cómo máximo se envía un objeto por cada conexión TCP.

HTTP persistente
Se pueden enviar multiples objetos por una misma conexión TCP entre cliente y servidor.

HTTP No-persistente
Supongamos que un usuario introduce esta URL:
1a. La aplicación cliente HTTP solicita establecer una conexión TCP con el proceso servidor en el equipo www.dte.us.es al puerto 80
2. El cliente HTTP envía un mensaje de petición (qué contiene la URL) en la conexión TCP establecida. El mensaje indica que el cliente quiere el objeto /personal/smartin/lab3/referencias.html

1b. La aplicación servidora HTTP en el equipo www.dte.us.es, que estaba a la espera de conexiones TCP en el puerto 80, acepta esta conexión, notificándoselo al cliente.
3. El servidor HTTP recibe la petición, forma un mensaje de respuesta conteniendo el objeto solicitado y lo envía a través de su socket.
tiempo
(contiene texto y referencias a 13 objetos)
http://www.dte.us.es/personal/smartin/lab3/referencias.html
1a.
1b.
2.
3.
Aplicación
Cliente
Aplicación
Servidora
4. El servidor HTTP solicita cierre de la conexión TCP. (También lo ha podido hacer el cliente)
4.
5. El cliente HTTP recibe el mensaje de respuesta, conteniendo el fichero HTML, muestra el contenido y lo analiza encontrando 13 referencias a otros objetos.
6. Los pasos 1-5 se repiten para cada una de los 13 objetos (4 imágenes y 9 scripts JavaScript) con URLs distintas.
Servicio
Transporte
fiable

HTTP No-persistente: Tiempo de respuesta
RTT (Round-Trip Time, tiempo de ida y vuelta): el tiempo que tarda desde que se solicita un servicio al nivel de transporte hasta que este está completado o solicita envío mensaje petición y se empieza a recibir primeros bytes respuesta.
Tiempo de respuesta (TR):
1 RTT, inicio conexión.
1 RTT, petición HTTP y primeros bytes de respuesta HTTP.
Tiempo transmisión bytes objeto solicitado (TTO).
Petición Solicitud conexión
RTT
RTT
tiempo
tiempo
TR= 2RTT + TTO

Nivel
Aplicación
Indicación Solicitud conexión
Nivel
Aplicación
Servicio
Transporte
fiable
Respuesta Solicitud conexión
Confirmación Solicitud conexión
Envío HTTP_PDU
Recepción HTTP_PDU
Servicio confirmado
Servicio no confirmado
Envío HTTP_PDU
Recepción HTTP_PDU
TTO
Cliente
Servidor

HTTP Persistente
Inconvenientes del HTTP no-persistente:
Requiere 2 RTTs por objeto (más lo que tarde en transmitirse dicho objeto).
Sobrecarga SO con cada conexión TCP

HTTP persistente
El servidor mantiene la conexión abierta tras enviar la respuesta
Los siguientes mensajes HTTP entre el mismo cliente y el servidor se envían por la conexión abierta
El cliente envía una nueva petición cuando acaba de recibir el objeto anterior
Cada objeto referenciado tarda sólo 1 RTT (más lo que tarde en transmitirse dicho objeto).
Conexiones HTTP en paralelo:
Los navegadores a menudo abren varias conexiones TCP en paralelo para obtener los objetos referenciados más rápidamente, los cuales se piden de forma simultánea por cada conexión (sean estas persistentes o no).
Nota

Mensajes HTTP (HTTP_PDU)
Hay 2 tipos de mensajes:
Petición HTTP:
Enviada por el cliente
Transporta información necesaria (HTTP_PCI) para solicitar un objeto del servidor (HTTP_UD)
Se compone de caracteres ASCII (texto inteligible)
Respuesta HTTP:
Enviada por el servidor
Transporta si procede el objeto (HTTP_UD) solicitado por el cliente además de información de control (HTTP_PCI)

< CR>: Carriage-Return : r
< LF>: Line-Feed: n
Mensaje de Petición HTTP
Línea de petición
(comandos GET,POST, HEAD)
Líneas decabecera
r y n al principiode una línea indicanel final de las líneasde cabecera
GET /index.html HTTP/1.1rn
Host: www-net.cs.umass.edu rn
User-Agent: Firefox/3.6.10rn
Accept: text/html,Aplicación/xhtml+xmlrn
Accept-Language: en-us,en;q=0.5rn
Accept-Encoding: gzip,deflatern
Accept-Charset: ISO-8859-1,utf-8;q=0.7rn
Keep-Alive: 115rn
Connection: keep-alivern
rn
Carácter retorno-de-carro
Carácter nueva-línea
Nota
(Gp:) UD

Algunas Cabeceras HTTP que puede enviar el cliente
Host: hostname (nombre del servidor web)
User-Agent: versión_del_navegador
Accept-xxx: lista_de_preferencias_para_xxx
Connection: keep-alive
El cliente solicita al servidor una conexión persistente al servidor
Keep-Alive: nnn
El cliente solicita al servidor el tiempo máximo de nnn segundos para las conexiones persistentes

PDU
Mensaje de Petición HTTP: formato general
línea depetición
Cuerpo
PCI
UD
UD
líneas decabecera

Subida de parámetros (de un formulario)
Una página web a menudo incluye un formulario con unos parámetros que se envían al servidor. Hay 2 métodos de envío:
Método POST:
Los parámetros se suben al servidor en el CUERPO de la petición
Método GET:
Las entradas se pasan al servidor en la propia URL, con la línea de petición (separado por “?” y “&”):

GET /buscar?monos&platanos HTTP/1.1rn
Host: www.unbuscador.comrn
….

Tipos de métodos
HTTP/1.0 (RFC-1945)
GET
POST
HEAD
Idéntico al GET, salvo que no se incluye el objeto en el cuerpo de la respuesta (sólo las cabeceras correspondientes)
HTTP/1.1 (RFC-2616)
GET, POST, HEAD
PUT
Sube el fichero en el CUERPO de la petición al path especificado en la URL
DELETE
Borra del servidor el fichero especificado en la URL

Mensaje de Respuesta HTTP
línea de estado
(protocolo,
código estado,
frase estado)
líneas decabecera
CUERPOej: archivoHTML pedido
HTTP/1.1 200 OKrn
Date: Sun, 26 Sep 2010 20:09:20 GMTrn
Server: Apache/2.0.52 (CentOS)rn
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMTrn
ETag: "17dc6-a5c-bf716880"rn
Accept-Ranges: bytesrn
Content-Length: 2652rn
Keep-Alive: timeout=10, max=100rn
Connection: Keep-Alivern
Content-Type: text/html; charset=ISO-8859-1rn
rn
data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data …
UD
PCI

Algunas Cabeceras HTTP que puede enviar el servidor
Date: fecha (en el que se envía el mensaje)
Last-Modified: fecha (en la que el objeto se modificó por última vez)
Server: versión_del_servidor
Content-Type: tipo_del_objeto (HTML, imagen, …)
Content-Length: tamaño_del_cuerpo (en bytes)
Connection: keep-alive
El servidor confirma al cliente que esa conexión será persistente
Keep-Alive: timeout=ttt, max=nnn
El servidor cerrará la conexión persistente tras ttt segundos de inactividad o tras nnn segundos en cualquier caso.

Códigos de estado (Respuesta)
200 OK
Petición exitosa, el objeto solicitado va a continuación…
301 Moved Permanently
El objeto se ha movido permanentemente, se especifica la ubicación nueva (cabecera “Location:”)
400 Bad Request
Mensaje de petición no entendido por el servidor
404 Not Found
El documento solicitado no se encuentra en el servidor
505 HTTP Version Not Supported
El código de estado aparece en la primera línea de la respuesta del servidor al cliente.
Algunos códigos habituales:

Prueba el HTTP tú mismo
1. Telnet a tu servidor Web favorito:

Abre conexión TCP al puerto 80
(puerto HTTP por defecto) de www.dte.us.es

Todo lo que escribas se envía allí
telnet www.dte.us.es 80
2. Escribe una petición GET:

GET /docencia/ HTTP/1.1
Host: www.dte.us.es

Escribe esto (con doble-enter al final) para enviar un GET request reducido a un servidor HTTP
3. Mira el mensaje de respuesta del servidor!
(o puedes usar Wireshark!)
P. ¿Qué ocurre si envío “hola”?

Cookies: manteniendo “el estado”
Muchos servicios web usan cookies
4 componentes:
1) cabecera Set-cookie: en el mensaje de respuesta
2) cabecera Cookie: en el mensaje de petición
3) archivo de cookies almacenado por el equipo del usuario y gestionado por el navegador
4) base de datos back-end en el servidor web
Ejemplo de uso:
Susana siempre accede a Internet desde su PC
Visita una tienda online (ej: Amazon) por primera vez
Al llegar las peticiones, el servidor crea:
Un ID único
Una entrada para esa ID en la base de datos back-end

Cookies: Ejemplo de uso
Servidor de
AMAZON
(Gp:) Mensaje resp. normal

(Gp:) Mensaje resp. normal

Almacén cookies
…y 1 semana después
(Gp:) Mensaje pet. Normal +
cookie: 1678
(Gp:) acciónespecíficade la cookie
(Gp:) acceso

(Gp:) ebay 8734

(Gp:) Mensaje pet. normal
(Gp:) Amazon creael ID 1678para el usuario
(Gp:) creaciónentrada

(Gp:) Mensaje resp. normal +
Set-cookie: 1678
(Gp:) ebay 8734
amazon 1678

(Gp:) Mensaje pet. normal +
cookie: 1678
(Gp:) acciónespecíficade la cookie
(Gp:) acceso

(Gp:) ebay 8734
amazon 1678

Back-end
Cliente visitaAMAZON

Cookies: discusión
Posibles aplicaciones:
autorización
carritos de la compra
recomendaciones
mantenimiento de sesión de usuario (ej: webmail)
cookies y la intimidad:
las cookies permiten a los sitios conocer mucho sobre ti
puedes estar dando información personal a esas páginas: emails, nombres, etc…
Nota

Servidor Proxy (Caché de la Web)
El navegador se configura para usar el Proxy-Caché.
Entonces se envían todas las peticiones HTTP al Proxy
objeto en la caché: se devuelve el objeto
si no: caché solicita el objeto al servidor original y lo devuelve al cliente.
Objetivo: satisfacer la petición del cliente sin involucrar al servidor web original
cliente
Proxy
server
cliente
(Gp:) Petición HTTP

(Gp:) Respuesta HTTP

Petición HTTP
Petición HTTP
servidororiginal
servidororiginal
Respuesta HTTP
Respuesta HTTP

Más acerca del Proxy
El caché actúa como cliente (del servidor original) y como servidor (del cliente)
Normalmente se instalan en los ISP (universidades, compañias, ISPs residenciales)
¿por qué es interesante?
Reducir el tiempo de respuesta de la petición del cliente
Reducir el tráfico de enlace de datos de una institución
Permitir a proveedores “pequeños” entregar de forma eficiente los contenidos (algo que también permite P2P)

GET Condicional
Proxy (o caché del navegador): especifica la fecha de la copia cacheada en la petición HTTP
If-modified-since: < date>
Servidor: en la respuesta van cabeceras y…
a) no va ningún objeto si la copia no se ha modificado…
HTTP/1.0 304 Not Modified
b) o bien se envía el objeto si está modificado, junto con la fecha de modificación:
Last-modified:< fecha>
Proxy o Caché
Servidor
Petición HTTP
If-modified-since:< fecha>
(Gp:) Respuesta HTTP
HTTP/1.0 304 Not Modified

Si el objeto NOfue modificadodespués de
< fecha>
Petición HTTP
If-modified-since:< fecha>
Respuesta HTTP
HTTP/1.0 200 OK
Last-modified:< fecha>
< data>
Que el servidor web no envíe el objeto si la caché tiene una versión actualizada del mismo
Objetivo
Si el objeto SÍfue modificadodespués de
< fecha>

Programación de Sockets
Socket API
Se introdujo en BSD4.1 UNIX, 1981
Los sockets se crean, usan y liberan de forma explícita por las aplicaciones
Paradigma cliente/servidor
2 tipos de servicios:
No fiable, orientado a datagramas (UDP)
Fiable, orientado a flujo de bytes (TCP)
Un interfaz del equipo local, creado por una aplicación y controlado por el SO (una “puerta”) por la que el proceso de aplicación puede tanto envíar/recibir mensajes a/desde otros procesos remotos (o incluso locales)
(Gp:) socket

Objetivo: aprender cómo se programa una aplicación cliente/servidor que se comunique usando sockets

Protocolo aplicación

Internet
Interfaz Usuario
Interfaz Usuario
Dir IP cliente, puerto
Servidor
Dir IP servidor, puerto
Cliente

Programación de Sockets con TCP
Socket: la interfaz entre el proceso y el protocolo de transporte extremo a extremo (TCP o UDP)
servicio TCP: transferencia fiable de un flujo de bytes (stream) de un proceso a otro
(Gp:) proceso
(Gp:) TCP con
buffers,
variables
(Gp:) socket

Controlado por el desarrollador de la aplicación
Controlado porel Sist.Operativo
Cliente o
servidor
(Gp:) proceso
(Gp:) TCP con
buffers,
variables
(Gp:) socket

Cliente oservidor
internet
Controlado por el desarrollador de la aplicación
Controlado porel Sist.Operativo

Programación de Sockets con TCP
El cliente debe contactar con el servidor
Proceso servidor debe estar corriendo primero
El servidor debe haber creado un socket (una “puerta”) que aceptará la solicitud de conexión de cualquier cliente.
El cliente para contactar
creará un socket TCP local
especificará la IP y el nº de puerto del proceso servidor
Al crearse el socket en el cliente se crea una conexión TCP con el servidor
Cuando es contactado por un cliente, el servidor TCP crea un nuevo socket para que el proceso servidor se comunique con él
Permite al servidor hablar con múltiples clientes
El nº de puerto de origen se usa para distinguir a los clientes [más en Tema 3]
Punto de vista de la aplicación
TCP provee una transferencia fiable y ordenada de bytesentre un cliente y un servidor

Interacción cliente/servidor con TCP
(Gp:) espera peticiones
de conexión entrantes
(Gp:) connectionSocket =
welcomeSocket.accept()

(Gp:) crea socket-servidor,
puerto=x, pararecibir peticiones:
(Gp:) welcomeSocket =
ServerSocket()

(Gp:) crea socket, se conecta
a hostid, puerto=x
(Gp:) clientSocket =
Socket()

(Gp:) cierra
connectionSocket
(Gp:) lee respuesta de
clientSocket
(Gp:) cierra
clientSocket

Servidor (corriendo en hostid)
Cliente
(Gp:) envia petición usando
clientSocket

(Gp:) lee petición de
connectionSocket
(Gp:) escribe respuesta a
connectionSocket

(Gp:) TCP setup

establecimiento de la conexión

hostid = IP o nombre
Enviar primitiva:
Conexión.request
Esperar primitiva:
Conexión .confirm
Enviar primitiva:
Data.request
Esperar primitiva:
Conexión.indication
Enviar primitiva:
Conexión.response
Esperar primitiva:
Data.indication

Stream de Java
stream (flujo) es una secuencia de caracteres/bytes que entran o salen a/de un proceso
input stream está conectado a una fuente de entrada de datos, como un teclado o un socket
output stream está conectado a una fuente de salida de datos, como un monitor o un socket
Ej: en el cliente vamos a usar 3 streams y 1 único socket
(Gp:) proceso
cliente
(Gp:) Socketcliente TCP
(Gp:) inputstream
(Gp:) outputstream
(Gp:) inputstream
(Gp:) monitor
(Gp:) teclado
(Gp:) de la capade transporte

a la capade transporte

Ejemplo: aplicación con sockets TCP
Aplicación de ejemplo cliente/servidor TCP:
1) el cliente lee una línea de entrada standard (inFromUser stream) , y la envía al servidor por un socket (outToServer stream)
2) el servidor lee la línea de un socket
3) el servidor convierte la línea a mayúsculas y la envía de vuelta al cliente por el socket
4) el cliente la lee del socket (inFromServer stream) y la muestra en el monitor

Ejemplo: cliente Java (TCP)
import java.io.*;
import java.net.*;
class TCPClient {

public static void main(String argv[]) throws Exception
{
String sentence;
String modifiedSentence;

BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));

Socket clientSocket = new Socket("hostname", 6789);

DataOutputStream outToServer =
new DataOutputStream(clientSocket.getOutputStream());

(Gp:) Crea
input stream

(Gp:) Crea objeto
clientSocket
de tipo Socket,
conecta al servidor

(Gp:) Crea
output stream
conectado al socket

(Gp:) Este paquete contiene las clasesSocket() y ServerSocket()

(Gp:) Nº de puerto del servidor
ICI

(Gp:) Nombre del servidor
ej: www.dte.us.es
ICI

Ejemplo: cliente Java (TCP) (cont)
BufferedReader inFromServer =
new BufferedReader(new
InputStreamReader(clientSocket.getInputStream()));

sentence = inFromUser.readLine();

outToServer.writeBytes(sentence + 'n');

modifiedSentence = inFromServer.readLine();

System.out.println("FROM SERVER: " + modifiedSentence);

clientSocket.close();

}
}
Crea
input stream
conectado al socket
Envia líneaal servidor
Lee líneadel servidor
Cierra socket
(¡cierra la puerta al salir!)
(Gp:) PDU

Enviar primitiva:
Data.request
Esperar primitiva:
Data.indication

Ejemplo: servidor Java (TCP)
import java.io.*;
import java.net.*;

class TCPServer {

public static void main(String argv[]) throws Exception
{
String clientSentence;
String capitalizedSentence;

ServerSocket welcomeSocket = new ServerSocket(6789);

while(true) {

Socket connectionSocket = welcomeSocket.accept();

BufferedReader inFromClient =
new BufferedReader(new
InputStreamReader(connectionSocket.getInputStream()));

(Gp:) El socket de acogida esperacon el método accept()al contacto de un cliente,retorna un nuevo socket

(Gp:) Crea
socket de acogida
en el puerto 6789

(Gp:) Creainput stream
conectado al socket

Ejemplo: servidor Java (TCP) (cont)

DataOutputStream outToClient =
new DataOutputStream(connectionSocket.getOutputStream());

clientSentence = inFromClient.readLine();

capitalizedSentence = clientSentence.toUpperCase() + 'n';

outToClient.writeBytes(capitalizedSentence);

connectionSocket.close();
}
}
}

Lee líneadel socket
Crea output stream conectado al socket
Escribe línea
al socket
Fin del bucle while,
vuelve y espera laconexión de otro cliente
Esperar primitiva:
Data.indication
(Gp:) PDU

(Gp:) PDU

Enviar primitiva:
Data.request

Programación de Sockets con UDP
UDP: no hay “conexión” entre cliente y servidor
Sin negociación
El cliente explícitamente adjunta la dirección IP y puerto de destino de cada mensaje (PDU) que quiera enviar.
El servicio de transporte debe pasar al servidor la dirección IP y el puerto del mensaje recibido.
UDP: los datos transmitidos pueden ser recibidos de forma desordenada, o algunos pueden perderse
(Gp:) Punto de vista de la aplicación:

UDP proporciona una transferenciano fiable de “datagramas” (grupos de bytes) entre el cliente y el servidor

Interacción cliente/servidor con UDP
(Gp:) cierra
clientSocket
(Gp:) lee datagrama de
clientSocket

(Gp:) crea socket-datagrama,

(Gp:) clientSocket =
DatagramSocket()
(Gp:) Cliente
(Gp:) crea datagrama con IP del servidor
y puerto=x; envía datagrama vía clientSocket

crea socket-datagrama,
puerto= x, parasolicitudes entrantes
serverSocket =
DatagramSocket()
(Gp:) lee solicitud de
serverSocket

(Gp:) escribe respuesta en
serverSocket
especificandodirección IPy nº de puerto

Enviar primitiva:
Data.request
Esperar primitiva:
Data.indication
hostid = IP o nombre
Servidor (corriendo en hostid)

Ejemplo: cliente (con datagramas UDP)
(Gp:) Entrada: recibe paquete (TCP recibía “streams” de bytes)
(Gp:) proceso cliente
(Gp:) Socketcliente UDP
(Gp:) Salida: envía paquete (TCP enviaba “streams” de bytes)
(Gp:) a la capade transporte
(Gp:) de la capade transporte
(Gp:) Paquete UDP
(Gp:) Paquete UDP
(Gp:) Input stream
(Gp:) monitor
(Gp:) teclado

Ejemplo: cliente Java (UDP)
import java.io.*;
import java.net.*;

class UDPClient {
public static void main(String args[]) throws Exception
{

BufferedReader inFromUser =
new BufferedReader(new InputStreamReader(System.in));

DatagramSocket clientSocket = new DatagramSocket();

InetAddress IPAddress = InetAddress.getByName("hostname");

byte[] sendData = new byte[1024];
byte[] receiveData = new byte[1024];

String sentence = inFromUser.readLine();
sendData = sentence.getBytes();
Crea
input stream
Crea socket UDP en puerto libre
Traduce nombredel servidora dirección IP
usando DNS

Ejemplo: cliente Java (UDP) (cont)
DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress, 9876);

clientSocket.send(sendPacket);

DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);

clientSocket.receive(receivePacket);

String modifiedSentence =
new String(receivePacket.getData(),0,
String(receivePacket.getLength());
System.out.println("FROM SERVER:" + modifiedSentence);
clientSocket.close();
}
}
Crea T_IDU con A_PDU a enviar,
longitud, dirección IP y nº de puerto
Envía T_IDU
Recibimos
T_IDU
(Gp:) A_PDU

(Gp:) T_ICI

Enviar primitiva:
Data.request
Esperar primitiva:
Data.indication
(Gp:) T_IDU

Creamos T_IDU
“en blanco”

Ejemplo: servidor Java (UDP)
import java.io.*;
import java.net.*;

class UDPServer {
public static void main(String args[]) throws Exception
{

DatagramSocket serverSocket = new DatagramSocket(9876);

byte[] receiveData = new byte[1024];
byte[] sendData = new byte[1024];

while(true)
{

DatagramPacket receivePacket =
new DatagramPacket(receiveData, receiveData.length);
serverSocket.receive(receivePacket);
Crea socket UDP enpuerto 9876 conocido por cliente
Creamos T_IDU
“en blanco”
Recibimos
T_IDU
Esperar primitiva:
Data.indication

Ejemplo: servidor Java (UDP) (cont)

String sentence = new String(receivePacket.getData(),0,
receivePacket.getLength());
InetAddress IPAddress = receivePacket.getAddress();

int port = receivePacket.getPort();

String capitalizedSentence = sentence.toUpperCase();

sendData = capitalizedSentence.getBytes();

DatagramPacket sendPacket =
new DatagramPacket(sendData, sendData.length, IPAddress,
port);

serverSocket.send(sendPacket);
}
}
}
Obtiene de la T_ICI la dirección IP y nº de puerto del emisor
Envía
T_IDU
Fin del bucle while,
vuelve y espera la llegada
de otro datagrama
Crea T_IDU con A_PDU a enviar, longitud, dirección IP y nº de puerto

EJERCICIOS

Pr1: ¿Verdadero o Falso?
a) Un usuario solicita una página web que consta de texto y 3 referencias a imágenes. Para obtener esa página, el cliente envía un mensaje de solicitud y recibe cuatro mensajes de respuesta.
b) Dos páginas web diferentes (www.mit.edu/research.html y www.mit.edu/students.html ) se pueden enviar a través de la misma conexión persistente.
c) Con las conexiones no persistentes entre un navegador y un servidor de origen, un único segmento TCP puede transportar dos mensajes de solicitud HTTP distintos.
d) La línea de cabecera “Date:” del mensaje de respuesta HTTP indica cuándo el objeto fue modificado por última vez.
e) Los mensajes de respuesta HTTP nunca incluyen un cuerpo de mensaje vacío.

Pr2: Aplicación-Transporte
Un cliente HTTP desea recuperar un documento web que se encuentra en una URL dada. Inicialmente, la dirección IP del servidor HTTP es desconocida.
¿Qué protocolos de la capa de aplicación y de la capa de transporte, además de HTTP, son necesarios en este escenario?

Pr3: Cabeceras Cliente HTTP
La siguiente cadena ASCII ha sido capturada cuando el navegador enviaba un mensaje GET HTTP.

Responda a las siguientes cuestiones, indicando en que parte del mensaje GET HTTP se encuentra la respuesta a la cuestión:
a) ¿Cuál es la URL del documento solicitado?
b) ¿Qué versión de HTTP se está ejecutando en el navegador?
c) ¿Solicita el navegador una conexión persistente o no?
d) ¿Cuál es la dirección IP del host que corre el navegador?
e) ¿Qué tipo de navegador envía el mensaje? ¿Por qué es necesario indicar el tipo de navegador en el mensaje?
f) ¿Cuántos bytes ocupa la HTTP_PDU enviada por el cliente?
g) ¿Cuántos bytes de HTTP_UD transporta?

Pr4: Cabeceras Servidor HTTP
La siguiente cadena muestra la respuesta devuelta por el servidor web al mensaje del problema anterior.

Responda a las siguientes cuestiones, indicando en que parte del mensaje respuesta HTTP se encuentra la respuesta a la cuestión:
a) ¿Ha encontrado el servidor el documento? ¿En qué momento se suministra la respuesta con el doc.?
b) ¿Cuándo fue modificado por última vez el documento?
c) ¿Cuántos bytes contiene el documento devuelto?
d) ¿Cuáles son los primeros 5 bytes del documento devuelto?
e) ¿Ha acordado el servidor emplear una conexión persistente? (si es que sí diga el tiempo máximo de inactividad que se permite)
f) ¿Cuántos bytes de HTTP_UD transporta?
g) ¿Cuántos bytes ocupa la HTTP_PDU enviada por el servidor?

Pr5: Tiempo de transferencia (I)
Suponga que en su navegador hace clic en un vínculo a una página web. La dirección IP correspondiente al URL asociado no está almacenada en la caché de su host local, por lo que es necesario realizar una búsqueda DNS.
Suponga que el tiempo de ida y vuelta (RTT) de la consulta al servidor DNS es RTTDNS
Suponga también que la página web asociada con el vínculo es un pequeño fichero HTML (lo que supone un tiempo de transmisión despreciable) y que no contiene referencias a otros objetos.
Sea RTT0 el tiempo RTT entre el host local y el servidor web.
¿Cuánto tiempo transcurre desde que el cliente hace clic en el vínculo hasta que recibe el objeto?

Pr6: Tiempo de transferencia (II)
Continuando con el Problema 5, suponga que el archivo base HTML hace referencia a 8 objetos muy pequeños que se encuentran en el mismo servidor.
Despreciando los tiempos de transmisión, para cargar la página web completa, ¿cuánto tiempo transcurre si se utiliza…
a) …HTTP no persistente sin conexiones TCP en paralelo?
b) …HTTP no persistente con 5 conexiones en paralelo?
c) …1 única conexión HTTP persistente?

Pr7: Proxy (I)
Supongamos una universidad
Tamaño objetos web = 100 Kbits
Tasa de peticiones media de los navegadores a los “servidores web originales” = 15 peticiones/seg
“Retardo Internet” del router superior a cualquier servidor “original” = 2 seg
Las peticiones web son pequeñas y no generan retardo.
En consecuencia tenemos:
Uso de la LAN = 15%
Uso del enlace = 100%
Al tener un uso del enlace del 100% (La/R ~ 1) las colas pueden crecen indefinidamente (y con ellas el retardo de cola).

(Gp:) Servidoresoriginales
(Gp:) Internet
(Gp:) Redinstitucional
(Gp:) 10 Mbps LAN
(Gp:) Enlace de acceso1,5 Mbps

Pr7: Proxy (II)
Propuesta de solución:
Aumentar ancho de banda del enlace a 10 Mbps

¿Uso de la LAN ?
¿Uso del enlace?
¿Retardo total medio?
¿Comentarios?

(Gp:) Servidoresoriginales
(Gp:) Internet
(Gp:) Redinstitucional
(Gp:) 10 Mbps LAN
(Gp:) Enlace de acceso10Mbps

Pr7: Proxy (III)
Otra posible solución:
Instalar proxy-caché
Supongamos tasa éxito 0.4:
40% peticiones satisfechas inmediatamente
60% peticiones satisfechas por el servidor original

¿Uso de la LAN ?
¿Uso del enlace?
¿Retardo total medio?
¿Comentarios?

Servidores
originales
Internet
Red
institutional
10 Mbps LAN
Enlace de acceso
1,5 Mbps
Proxy
institucional