conexión a un host remoto

ARQUITECTURAS
CLIENTE/SERVIDOR
SERVIDORES ORIENTADOS/ NO
ORIENTADOS A CONEXIÓN
SERVIDORES ORIENTADOS A CONEXIÓN




Telnet
HTTP
FTP
SMTP




LDAP
Kerberos
RMI
RPC

NFS
SERVIDORES NO ORIENTADOS A
CONEXIÓN
SNMP
 P2P
 RPC

NFS
 DNS

TELNET
Servidores Orientados a Conexión
TELNET (TELECOMMUNICATION
NETWORK)

TELNET es un protocolo estándar siendo su número
STD de 8. Su status es recomendado. Se describe en
el RFC 854 - Especificaciones del protocolo TELNET
y RFC 855 - "TELNET Option Specifications".

El protocolo TELNET proporciona una interfaz
estandarizada, a través de la cual un programa de un
host(el cliente de TELNET) puede acceder a los
recursos de otro host (el servidor de TELNET) como
si el cliente fuera una terminal local conectada al
servidor.
TELNET ES UN PROTOCOLO BASADO EN
TRES IDEAS:



El concepto de NVT(Network Virtual Terminal) (NVT). Una
NVT es un dispositivo imaginario que posee una estructura
básica común a una amplia gama de terminales reales.
Cada host mapea las características de su propia terminal
sobre las de su correspondiente NVT, y asume todos los
demás hosts harán lo mismo.
Una perspectiva simétrica de las terminales y los procesos.
Negociación de las opciones de la terminal. El protocolo
TELNET usa el principio de opciones negociadas, ya que
muchos host pueden desear suministrar servicios
adicionales, más allá de los disponibles en la NVT. Se
pueden negociar diversas opciones
FUNCIONAMIENTO TELNET
NVT(NETWORK VIRTUAL TERMINAL)

Cuenta con un monitor o "display" y un teclado. El teclado
produce datos de salida, que se envían por la conexión
TELNET. El monitor recibe los datos de entrada que
llegan. Las características básicas de una NVT, a menos
que sean modificadas por opciones establecidas de común
acuerdo, son:
Los datos se representan en código ASCII de 7 bits,
transmitido en bytes de 8 bits.
 Es un dispositivo semi-duplex que opera en modo de buffer en
línea.
 Proporciona una función de eco local.


Todas estas opciones pueden ser negociadas por los dos hosts.
Por ejemplo, se prefiere el eco local porque la carga de la red es
inferior y el rendimiento superior pero existe la opción de usar
el eco remoto, aunque no se le requiera a ningún host.
NVT

El servidor TELNET ―escucha‖ en el puerto 23
COMANDOS TELNET
close: cerrar la conexión actual.
 display: mostrar los parámetros operativos.
 mode: trata de introducir los comandos línea a
línea.
 open: conexión con un host especificado.
 quit: salir de telnet.
 send: transmisión de caracteres especiales.
 set: establecimiento de parámetros operativos.
 status: muestra la información de estado.
 ?: muestra información de ayuda.

FTP
Servidores Orientados a Conexión
FTP



FTP es un protocolo estándar con el STD 9. Su
status es recomendado. Se describe en el RFC
959 - FTP("File Transfer Protocol").
La copia de archivos de una máquina a otra es
una de las operaciones más frecuentes. La
transferencia de datos entre cliente y servidor
puede producirse en cualquier dirección.
Para acceder a archivos remotos, el usuario debe
identificarse al servidor. En este punto el
servidor es responsable de autentificar al cliente
antes de permitir la transferencia de archivos.
DESCRIPCIÓN DE FTP


FTP usa TCP como protocolo de transporte para
proporcionar conexiones fiables entre los
extremos. Se emplean dos conexiones: la primera
es para el login y sigue el protocolo TELNET y la
segunda es para gestionar la transferencia de
datos.
En ambos extremos del enlace, la aplicación FTP
se construye con intérprete de protocolo(PI), un
proceso de transferencia de datos, y una interfaz
de usuario.


La interfaz de usuario se comunica con el PI, que
está a cargo del control de la conexión. Este
intérprete de protocolo comunica la información
necesaria a su propio sistema de archivos.
En el otro extremo de la conexión, el PI, además
de su función de responder al protocolo TELNET,
inicia la conexión de datos. Durante la
transferencia de archivos, los DTPs se ocupan de
gestionar la transferencia de datos. Una vez que
la operación del usuario se ha completado, el PI
cierra la conexión de control.
DIAGRAMA DE FUNCIONAMIENTO
OPERACIONES DE FTP

Al usar FTP, el usuario realizará alguna de las
siguientes operaciones:






Conexión a un host remoto
Selección de un directorio
Listado de archivos disponibles para una
transferencia
Especificación del modo de transferencia
Copiar archivos de o a el host remoto
Desconectar del host remoto
CONEXIÓN A UN HOST REMOTO

comandos:

Open


User


Identifica al ID del usuario remoto
Pass


Selecciona el host remoto de inicia la sesión con el login
Autentifica al usuario
Site

Envía información al host remoto utilizado para
proporcionar servicios específicos para ese host
ESPECIFICACIÓN DEL MODO DE
TRANSFERENCIA

La transferencia de datos entre sistemas diferentes suele requerir
transformaciones de los datos como parte del proceso de
transferencia. El usuario ha de decidir dos aspectos de la
manipulación de los datos:



La forma en qué se transferirán los bits.
Las distintas representaciones de los datos en la arquitectura del sistema.
Esto se controla por medio de dos subcomandos:





Mode :Especifica si el archivo se ha de tratar como si tuviera estructura de
registros o como un flujo de bytes.
Block :Se respetan las separaciones lógicas entre registros.
Stream: El archivo se trata como un flujo de bytes. Esta es la opción por defecto, y
proporciona una transferencia más eficiente, pero puede que no produzca los
resultados deseados cuando se trabaja con un archivos estructurados por registros.
Type: Especifica el conjunto de caracteres usado para los datos.
 ASCII Indica que ambos host están basados en ASCII, o que si uno está basado
en ASCII y el otro en EBCDIC, se debería realizar una traducción ASCIIEBCDIC. EBCDIC Indica que ambos host se basan en EBCDIC. Image Indica
que los datos deben tratarse como bits contiguos empaquetados en bytes de 8
bits.
Debido a que estos subcomandos no cubren todas las posibles
diferencias entre sistemas, el subcomando SITE está disponible para
lanzar comandos dependientes del sistema.
COPIA DE ARCHIVOS

Get (mget)


Put (mput)


Copia un archivo del host local al host remoto.
Finalización de la sesión de transferencia
Quit


Copia un archivo del host remoto al host local.
Desconecta del host remoto y cierra el FTP. Algunas
implementaciones usan el subcomando BYE.
Close

Desconecta del host remoto pero deja al cliente FTP
ejecutándose. Se puede lanzar un comando open para
trabajar con otro host remoto
FTP ANONYMOUS



El FTP anonymous es un SERVICIO ESPECIAL que
te permite, SIN TENER UN 'USERID' o CUENTA
en un servidor, para poder acceder a su sistema de
archivos.
Esta es, de hecho, la manera mas cómoda (después de
las páginas WEB) de permitir que todo el mundo
tenga acceso a cierta información.
Si una máquina posee servicio 'FTP anonymous'
solamente con teclear la palabra "anonymous" anónimo en inglés - cuando dicha máquina pregunte
por tu usuario, tendrás acceso a ese sistema
CÓDIGOS DE RESPUESTA


Con el fin de gestionar estas operaciones, el cliente y el servidor mantienen
un diálogo por medio de TELNET. El cliente lanza comandos, y el servidor
contesta con códigos de respuesta. Las respuestas incluyen también
comentarios para el usuario, pero el cliente usa sólo los códigos.
Los códigos de respuesta tienen tres dígitos, siendo el primero el más
significante.
DETALLE PRIMER DÍGITO

1** Respuesta preliminar positiva. Se ha iniciado la acción
requerida; se espera otra respuesta del server antes de seguir con una
nueva orden.

2** Respuesta de finalización positiva. La acción requerida se ha
completado satisfactoriamente. Se puede iniciar una nueva orden.

3** Respuesta intermedia positiva. La orden se ha aceptado, pero se
está pendiente de recibir más información para completarla. El
usuario debería enviar otra orden indicando esta información. Esta
respuesta se utiliza en órdenes que deben ir en secuencia.

4** Respuesta de finalización negativa transitoria. La orden no se ha
aceptado y la acción requerida no se ha llevado a cabo, pero la
condición de error es temporal y se puede solicitar la acción de nuevo.

5** Respuesta de finalización negativa permanente. La orden no se
ha aceptado y la acción requerida no ha tenido lugar.
SEGUNDO DÍGITO, 6 OPCIONES






*0* Sintáxis. Estas respuestas se refieren a errores
de sintaxis, órdenes correctas sintácticamente pero
que no encajan en ninguna otra categoría, órdenes no
implementadas o superfluas.
*1* Información. Estas son respuestas a solicitudes
de información como STATUS o HELP.
*2* Conexiones. Respuestas referidas a las
conexiones de control y de datos.
*3* Autenticación y cuenta. Respuestas para el
proceso de entrada al sistema y procedimientos de
cuenta.
*4* Sin especificar aún.
*5* Sistema de archivos. Estas respuestas indican
el estado del sistema de archivos en el servidor según
se realizan transferencias u otras acciones sobre el
sistema de archivos.
HTTP
Servidores Orientados a Conexión
INTRODUCCIÓN



El protocolo estándar de comunicaciones entre
servidores y clientes Web es el HTTP("Hypertext
Transfer Protocol"), que es un borrador de
estándar de Internet. RFC 2616
Es un protocolo orientado a transacciones y sigue
el esquema petición-respuesta entre un cliente y
un servidor.
Al cliente que efectúa la petición (generalmente
un navegador o una araña web) se lo conoce como
"user agent" (agente del usuario).
UNA TRANSACCIÓN HTTP CONSISTE
BÁSICAMENTE EN:

Conexión


Solicitud


El envío por parte del cliente de un mensaje de
solicitud al servidor.
Respuesta


El establecimiento de una conexión del cliente con el
servidor. El puerto por default es el puerto bien
conocido 80, pero el URL puede especificar otros
puertos no reservados.
El envío por parte del servidor de una respuesta al
cliente.
Cierre

El cierre de la conexión por parte del cliente y el
servidor.
HTML



El lenguaje estándar de marcas para documentos
Web es HTML ("Hypertext Markup Language"),
que es un borrador de estándar de Internet y
actualmente varios grupos de trabajo del IETF
están trabajando en él.
HTML es un derivado de SGML("Standard
Generalized Markup Language").
Para crear un documento Web hay que usar las
marcas HTML que constituyen la estructura
lógica del documento, por ejemplo, cabeceras,
listas y párrafos.
ESTRUCTURA BÁSICA DE UN DOCUMENTO
HMTL
<HTML> <!– Inicio de document o-->
<HEAD> <!-- Encabezado documento-->
<TITLE>Este es un ejemplo</TITLE>
</HEAD> <!–Fin de la sección de encabezado-->
<BODY> <!– Inicio del cuerpo de texto-->
<!—Contenido -->
</BODY> <!– Fin del cuerpo -->
</HTML> <!– Fin del documento -->
<html>
<head>
<title>Bienvenido a eMotherEarth.com</title>
</head>
<body>
<h1>Bienvenido a eMotherEarth.com</h1>
<p>
<h3>Tu primera tienda en donde podrás comprar
Productos para la Tierra </h3>
<p>
Favor de escribir tu información:
<p>
<form action="catalog" method="post">
<p>Nombre: <input type="text" name="username">
<p><input type="submit" name="Submit" value="Login">
</form>
</body>
</html>
URL



URL es un protocolo estándar de Internet y se
puede encontrar en el RFC 1738.
El contexto global para construir nuevos
esquemas para codificar nombres y direcciones de
objetos en Internet se describe en el RFC
informacional 1630.
Este RFC describe el término URI(Universal
Resource Identifiers) como un modelo más teórico
para diseñar estos esquemas.
URI

Los URIs que se refieren a una dirección
objeto(dirección IP e información de la ruta de
acceso)mapeados a un método de acceso conocido
usando un protocolo de red existente como HTTP
o FTP se conocen como URLs. Por lo tanto, un
URL es una forma específica de un URI. En
general, los URLs se escriben del modo siguiente:
<scheme>:<scheme-specificpart>
URL, ESQUEMAS DEFINIDOS

Los siguientes esquemas son ejemplos incluidos
en el RFC:








ftp - "File Transfer protocol"
http - "HyperText Transfer Protocol"
gopher - El protocolo Gopher
mailto - Dirección de Correo Electrónico
news - "USENET news"
nntp - "USENET news" usando acceso NNTP
telnet - Sesiones interactivas
file - Nombres de archivos específicos de un host
• DESCRITOS EN EL RFC 1738
URL CON IP


Mientras que la sintaxis para el resto del URL puede
variar dependiendo del esquema seleccionado.
Los esquemas que implican el uso directo de un
protocolo basado en IP usan una sintaxis común para
la parte <scheme-specific data>,

Comienza por "//" para indicar que sigue la sintaxis
estándar de Internet:
//<user>:<password>@<host>:<port>/<url-path>

Las siguientes partes pueden ser excluidas
"<user>:<password>@", ":<password>", ":<port>", y
"/<url-path>" se pueden excluir.
URL DE HTTP

Según la definición anterior, el URL de HTTP tiene este
aspecto:
http://<host>:<port>/<path>?<searchpart>
Donde:
 host


port


El número de puerto al que conectar. Si este parámetro se omite en un
URL de HTTP, es 80 por defecto.
path


El nombre de dominio completo de un host o una dirección IP en
formato decimal.
Especifica un selector HTTP, una ruta a un documento HTML, por
ejemplo. ?
searchpart

Registra de consulta("query string") indicada con "?".
COMANDOS

GET


HEAD


Envía datos al programa ubicado en la URL
especificada
PUT


Solicita el encabezado del recurso ubicado en la URL
especificada
POST


Solicita el recurso ubicado en la URL especificada
Envía datos a la URL especificada
DELETE

Borra el recurso ubicado en la URL especificada
FORMATO DE PETICIÓN Y RESPUESTA

En el caso de que la petición se haga con el protocolo
HTTP/1.0 o con el protocolo HTTP/1.1 la petición sigue el
formato:
Línea de petición
*(Cabeceras)
CRLF
[Contenido]
GET / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; enUS; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive
POST
POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7.6) Gecko/20050225
Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
RESPUESTAS
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122
<html>
<head>
<title>Wrox Homepage</title>
</head>
<body>
<!-- body goes here -->
</body>
</html>
CABECERAS GENERALES


Los campos de este tipo de cabeceras se aplican tanto
a las peticiones como a las respuestas, pero no al
contenido de los mensajes.
Estas cabeceras son:







Cache-Control, son directivas que se han de tener en
cuenta a la hora de mantener el contenido en una caché.
Connection, permite especificar opciones requeridas para
una conexión.
Date, representa la fecha y la hora a la que se creó el
mensaje.
Pragma, usado para incluir directivas de implementación.
Transfer-Encoding, indica la codificación aplicada al
contenido.
Upgrade, permite al cliente especificar protocolos que
soporta.
Via, usado por pasarelas y proxies para indicar los pasos
seguidos
CABECERAS DE PETICIÓN
















Accept, indican el tipo de respuesta que acepta. Accept-Charset, indica los
conjuntos de caracteres que acepta.
Accept-Encoding, que tipo de codificación acepta.
Accept-Language, tipo de lenguaje de la respuesta que se prefiere.
Authorization, el agente de usuario quiere autentificarse con el servidor.
From, contiene la dirección de correo que controla en agente de usuario.
Host, especifica la máquina y el puerto del recurso pedido.
If-Modified-Since, para el GET condicional.
If-Match, para el GET condicional.
If-None-Match, para el GET condicional.
If-Range, para el GET condicional.
If-Unmodified-Since, para el GET condicional.
Max-Forwards, indica el máximo número de elementos por los que pasa.
Proxy-Authorization, permite que el cliente se identifique a un proxy.
Range, establece un rango de bytes del contenido.
Referer, indica la dirección donde obtuvo la URI de la petición.
User-Agent, información sobre el agente que genera la petición.
CABECERAS DE RESPUESTA








Age, estimación del tiempo transcurrido desde que se creó
la respuesta. Location, se usa par a redirigir la petición a
otra URI.
Proxy-Authenticate, ante una respuesta con el código
407 (autentificación proxy requerida), indica el esquema de
autentificación.
Public, da la lista de métodos soportados por el servidor.
Retry-After, ante un servicio no disponible da una fecha
para volver a intentarlo.
Server, información sobre el servidor que maneja las
peticiones.
Vary, indica que hay varias respuestas y el servidor ha
escogido una.
Warning, usada para aportar información adicional sobre
el estado de la respuesta.
WWW-Authenticate, indica el esquema de autentificación
y los parámetros aplicables a la URI.
CABECERAS DE ENTIDAD











Allow, da los métodos soportados por el recurso designado por la
URI. Content-Base, indica la URI base para resolver las URI
relativas.
Content-Encoding, indica una codificación adicional aplicada al
contenido (a parte de la aplicada por el tipo).
Content-Language, describe el idioma del contenido.
Content-Length, indica el tamaño del contenido del mensaje.
Content-Location, da información sobre la localización del recurso
que da el contenido del mensaje.
Content-MD5, es un resumen en formato MD5 (RFC 1864) para
chequear la integridad del contenido.
Content-Range, en un GET parcial, indica la posición del contenido.
Content-Type, indica el tipo de contenido que es.
Etag, define una marca para el contenido asociado.
Expires, indica la fecha a partir de la cual la respuesta deja de ser
válida.
Last-Modified, indica la fecha de la última modificación.
CÓDIGOS DE ESTADO






El código de estado es un número de 3 dígitos que indica si
la petición ha sido atendida satisfactoriamente o no, y en
caso de no haber sido atendida, indica la causa. Los códigos
se dividen en cinco clases definidas por el primer dígito del
código de estado. Así tenemos:
1xx: Informativo. La petición se recibe y sigue el proceso.
Esta familia de respuestas indican una respuesta
provisional. Este tipo de respuesta está formada por la
línea de estado y las cabeceras. Un servidor envía este tipo
de respuesta en casos experimentales.
2xx: Éxito. La acción requerida por la petición ha sido
recibida, entendida y aceptada.
3xx: Redirección. Para completar la petición se han de
tomar más acciones.
4xx: Error del cliente. La petición no es sintácticamente
correcta y no se puede llevar a cabo.
5xx: Error del servidor. El servidor falla al atender la
petición que aparentemente es correcta.
EJEMPLOS DE CÓDIGOS DE ESTADO



















100, continuar.
101, cambio de protocolo.
200, éxito.
201, creado.
202, aceptado.
203, información no autoritativa.
204, sin contenido.
205, contenido reestablecido.
206, contenido parcial.
300, múltiples elecciones.
301, movido permanentemente.
302, movido temporalmente.
303, ver otros.
304, no modificado.
305, usar proxy.
400, petición errónea.
401, no autorizado.
402, pago requerido.
403, prohibido.


















404, no encontrado.
405, método no permitido.
406, no se puede aceptar.
407, se requiere autentificación proxy.
408, límite de tiempo de la petición.
409, conflicto.
410, gone.
411, tamaño requerido.
412, falla una precondición.
413, contenido de la petición muy largo.
414, URI de la petición muy largo.
415, campo media type requerido.
500, error interno del servidor.
501, no implementado.
502, puerta de enlace errónea.
503, servicio no disponible.
504, tiempo límite de la puerta de enlace.
505, versión de protocolo HTTP no
soportada.
SERVIDORES HTTP O SERVIDORES WEB

Apache (Jakarta Project)

IIS (Internet Information Server)

GWS (Google Web Server)

Cherokee
EVOLUCIÓN EN HTTP



Los primeros sitios web no eran sino colecciones de
páginas web enlazadas entre ellas por el Lenguaje
HTML.
Hoy en día, los sitios web incluyen multimedia,
aplicaciones de comercio electrónico, y otro tipo de
sofisticadas aplicaciones basadas en Web como voz IP
y banca online.
Además de los avances en contenido, se han producido
avances en las tecnologías de servidores web, como el
desarrollo de servidores de aplicaciones, y tecnologías
de creación dinámica de contenido, como las páginas
JSP y las páginas ASP.
ARQUITECTURA 2-CAPAS (CLIENTE/SERVIDOR)
ARQUITECTURA DE N-CAPAS (2-CAPAS)
Ideal para generación de contenido dinámico
Servidores de aplicaciones (Java) utilizan servlets
en Java
REQUERIMIENTOS DE EJECUCIÓN DE
LOS SERVLETS JAVA



.
Los Servlets de Java requieren algún conocimiento
previo de Java y HTML
Las aplicaciones web y las páginas web que requieran
iniciación de servlets deben ejecutarse en servidores
web con contenedores web integrados, como el
servidor web WebSphere o un contenedor solitario de
servlets como el Tomcat .
Los Servlets también pueden ejecutarse en servidores
de aplicación con contenedores web integrados como
el Servidor BEA WebLogic .