• No se han encontrado resultados

ARQUITECTURAS CLIENTE/SERVIDOR

N/A
N/A
Protected

Academic year: 2021

Share "ARQUITECTURAS CLIENTE/SERVIDOR"

Copied!
51
0
0

Texto completo

(1)

A

RQUITECTURAS

(2)

S

ERVIDORES ORIENTADOS

/ N

O ORIENTADOS A CONEXIÓN

(3)

S

ERVIDORES

O

RIENTADOS A CONEXIÓN  Telnet  HTTP  FTP  SMTP  LDAP  Kerberos  RMI  RPC  NFS

(4)

S

ERVIDORES

N

O

O

RIENTADOS A

C

ONEXIÓN  SNMP  P2P  RPC  NFS  DNS

(5)

TELNET

(6)

TELNET (TEL

ECOMMUNICATION

NET

WORK

)

 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.

(7)

T

ELNET 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

(8)
(9)

NVT(N

ETWORK

V

IRTUAL

T

ERMINAL

)

 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.

(10)

NVT

(11)

C

OMANDOS

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.

(12)

FTP

(13)

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.

(14)

D

ESCRIPCIÓ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.

(15)

 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.

(16)
(17)

O

PERACIONES 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

(18)

C

ONEXIÓN A UN HOST REMOTO

 comandos:

 Open

 Selecciona el host remoto de inicia la sesión con el login  User

 Identifica al ID del usuario remoto  Pass

 Autentifica al usuario  Site

 Envía información al host remoto utilizado para proporcionar servicios específicos para ese host

(19)

E

SPECIFICACIÓ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 ASCII-EBCDIC. EBCDIC Indica que ambos host se basan en ASCII-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.

(20)

C

OPIA DE

ARCHIVOS

 Get (mget)

 Copia un archivo del host remoto al host local.  Put (mput)

 Copia un archivo del host local al host remoto.

Finalización de la sesión de transferencia

 Quit

 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

(21)

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

(22)

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

(23)

D

ETALLE 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

(24)

S

EGUNDO 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.

(25)
(26)

HTTP

(27)

I

NTRODUCCIÓ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).

(28)

U

NA TRANSACCIÓN

HTTP

CONSISTE

BÁSICAMENTE EN

:

 Conexión

 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.

 Solicitud

 El envío por parte del cliente de un mensaje de

solicitud al servidor.

 Respuesta

 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

(29)

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.

(30)

E

STRUCTURA 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 -->

(31)

<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>

(32)

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.

(33)

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-specific-part>

(34)

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

(35)

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.

(36)

URL

DE

HTTP

 Según la definición anterior, el URL de HTTP tiene este

aspecto:

http://<host>:<port>/<path>?<searchpart>

Donde:

 host

 El nombre de dominio completo de un host o una dirección IP en

formato decimal.

 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

 Especifica un selector HTTP, una ruta a un documento HTML, por

ejemplo. ?

 searchpart

(37)

C

OMANDOS

 GET

 Solicita el recurso ubicado en la URL especificada

 HEAD

 Solicita el encabezado del recurso ubicado en la URL

especificada

 POST

 Envía datos al programa ubicado en la URL

especificada

 PUT

 Envía datos a la URL especificada

 DELETE

(38)

F

ORMATO DE

P

ETICIÓN Y

R

ESPUESTA

 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; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

(39)

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

(40)

R

ESPUESTAS

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>

(41)

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

(42)

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.

(43)

C

ABECERAS DE

R

ESPUESTA

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

(44)

C

ABECERAS 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.

(45)

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

(46)

E

JEMPLOS 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

(47)

S

ERVIDORES

HTTP

O

S

ERVIDORES

WEB

 Apache (Jakarta Project)

 IIS (Internet Information Server)

 GWS (Google Web Server)

(48)

E

VOLUCIÓ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.

(49)
(50)

A

RQUITECTURA DE

N-

CAPAS

(2-

CAPAS

)

Ideal para generación de contenido dinámico

Servidores de aplicaciones (Java) utilizan servlets en Java

(51)

R

EQUERIMIENTOS DE

E

JECUCIÓN DE

LOS

S

ERVLETS

J

AVA

 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 .

Referencias

Documento similar

• Si el cliente envía un token de acceso válido a este servidor de recursos falso, el servidor puede usar dicho token para acceder a otros servicios en nombre del

Teniendo en cuenta la comunicación entre el cliente y el servidor central, detallando como se realizará el proceso de sincronización, particularizando como se lleva a

abstracción de recursos, donde cada petición HTTP contiene toda la información necesaria para responder a la petición, sin necesidad de que el cliente ni el servidor

El diagrama de despliegue para este sistema incluye la representación de una PC que realiza la función de servidor y una o más PCs Cliente conectadas al Servidor por medio

El servidor de peticiones retorna la unidad de tra- bajo creada para el cliente (ver caso de uso Atender Tarea Asignada por el Servidor Central. Sección Crear una Unidad de

Otro ejemplo son las “Librerías de cliente/servidor” que son las que permiten hacer llamadas a funciones del servidor desde el cliente usando las funciones JavaScript

Si se realiza un estudio de la Telefonía Móvil, las Comunicaciones Inalámbricas, la arquitectura Cliente – Servidor, así como de las tendencias actuales de las plataformas

Se indica, para cada flujo y sentido (cliente-servidor y servidor-cliente para los juegos, sólo este último para el streaming, punto a punto para VoIP), tanto el tamaño medio de