Modelo Cliente – Servidor

¿Qué es la arquitectura cliente-servidor?

La arquitectura cliente-servidor es una de las más populares en la construcción de
aplicaciones en la actualidad. Básicamente se llama así a toda arquitectura en la
que participan dos componentes: uno es el cliente que utiliza unos servicios, y otro
es el servidor que proporciona esos servicios. Entre ambos se tiene que efectuar
una comunicación de red, habitualmente mediante Internet.
De todos modos, estamos ante un concepto bastante amplio y genérico que
engloba multitud de tipos de aplicaciones. Para hacernos una idea, todas las
aplicaciones que se utilizan en la web son aplicaciones cliente-servidor. El cliente
sería el navegador, y el servidor sería la máquina donde están instaladas las
aplicaciones, las bases de datos y otros recursos remotos.
Actualmente en Internet se utiliza el término backend para la parte de las
aplicaciones que hace las veces de servidor y frontend para la parte de las
aplicaciones que se ejecuta en el cliente.

¿Cómo funciona el modelo cliente-servidor?

El modelo cliente-servidor es uno de los conceptos de arquitectura más comunes
en la tecnología de redes. Regula la interacción entre el cliente y el servidor.
Tareas rutinarias como el envío de peticiones HTTP a servidores web o la
transferencia de archivos por FTP son casos de uso típicos.
El modelo cliente-servidor, también conocido como “principio cliente-servidor”, es
un modelo de comunicación que permite la distribución de tareas dentro de una
red de ordenadores.
Un servidor es un hardware que proporciona los recursos necesarios para otros
ordenadores o programas, pero un servidor también puede ser un programa
informático que se comunica con los clientes. Un servidor acepta las peticiones del
cliente, las procesa y proporciona la respuesta solicitada. También existen
diferentes tipos de clientes. Un ordenador o un programa informático se comunica
con el servidor, envía solicitudes y recibe respuestas del servidor. En cuanto al
modelo cliente-servidor, representa la interacción entre el servidor y el cliente.
¿Cuáles son las características del principio cliente-servidor?
El modelo cliente-servidor tiene algunos rasgos característicos. Hay una clara
distribución de tareas entre los clientes y los servidores. El servidor es el
responsable de proporcionar los servicios. Se encarga de ejecutar los servicios
solicitados y entrega la respuesta esperada. El cliente, en cambio, utiliza y solicita
los servicios proporcionados. Finalmente, recibe la respuesta del servidor.
En el modelo cliente-servidor, un servidor sirve a varios clientes y, por ende,
procesa múltiples peticiones de diferentes clientes. Para ello, presta su servicio de
forma permanente y pasiva. Por su parte, el cliente solicita activamente los
servicios del servidor e inicia las tareas del servidor.
Siguiendo este modelo, un ordenador físico puede ser tanto cliente como servidor.
El único factor decisivo es su papel dentro de una red y el hecho de que el
ordenador envíe o reciba solicitudes de servicios y recursos.
Las normas que definen la comunicación entre clientes y servidores se comunican
en forma de protocolos. Y según la tarea, se utilizan diferentes protocolos de red
para la transmisión de datos. Además, según el ámbito de aplicación, existen
diferentes tipos de red.

¿Cuáles son las ventajas e inconvenientes del

modelo cliente-servidor?
El concepto de distribución de tareas y servicios dentro de una red basado en el
modelo cliente-servidor tiene ventajas e inconvenientes.

Ventajas
El modelo cliente-servidor es uno de los conceptos arquitectónicos más utilizados
en la tecnología de redes, dado que ofrece algunas ventajas significativas.

Administración central
La administración central es una de las principales ventajas. El servidor está en el
centro de la red. Todos los usuarios o clientes lo utilizan. Los recursos importantes,
como bases de datos, se encuentran en el servidor y son accesibles de forma
centralizada. Esto simplifica la administración y el mantenimiento de los recursos
importantes que requieren protección. La ubicación central del servidor hace que
la realización de actualizaciones sea cómoda y de bajo riesgo.

Derechos de acceso controlados globalmente

El almacenamiento central de recursos importantes permite una gestión segura y
global de los derechos de acceso. Cuando se trata de datos sensibles, es
importante saber quién puede ver los datos y quién puede manipularlos. Para
proteger los datos de la mejor manera posible, hay que establecer derechos de
acceso.

Un solo servidor para muchos clientes

El número de clientes puede ampliarse. Varios clientes trabajan simultáneamente
utilizando un único servidor. Los clientes comparten los recursos del servidor.
También es posible que el servidor esté situado en un lugar distinto al de los
clientes. Lo más importante es que el servidor y los clientes estén conectados a
través de una red. Y, por ende, no es necesario que los recursos estén en el
mismo sitio.

Otras ventajas de la arquitectura cliente-servidor son las

siguientes.
 Facilita la administración de los datos y la seguridad de la información, ya
que los servicios se encuentran en entornos de servidor completamente
controlados.
 Mejora la escalabilidad, ya que permite actualizar y ampliar ambos entornos
por separado tanto en la parte del cliente como la parte del servidor,
centralizando las necesidades de escalabilidad en el servidor donde
tenemos más capacidad de intervención.
 Permite un mantenimiento individual de las capas del software, lo que
mejora las posibilidades de actuación y las aísla ante posibles problemas.
 Mejora la flexibilidad de los usos de las aplicaciones, ya que un entorno de
servidor puede ajustarse al trabajo con varios tipos de clientes
 Permite un desarrollo menos dependiente. Ambos proyectos, cliente y
servidor pueden estar en proyectos independientes que incluso pueden ser
manejados por equipos distintos.
Inconvenientes
A pesar de las ventajas, también hay que tener en cuenta algunos inconvenientes.

Caída del servidor

Debido a la disposición centralizada y a la dependencia en un modelo cliente-
servidor, la caída del servidor conlleva la caída de todo el sistema. Si el servidor se
cae, los clientes dejan de funcionar porque no pueden recibir las respuestas
necesarias del servidor.

Recursos de un servidor
El servidor realiza las tareas que requieren muchos recursos. La demanda de
recursos de los clientes es mucho menor. Si el servidor tiene muy pocos recursos,
afecta a todos los clientes. Por eso es importante elegir un proveedor que
proporcione estos recursos de forma fiable.

Inversión de tiempo
Otro factor que no hay que subestimar es el tiempo necesario para hacer funcionar
tu servidor. Además de los conocimientos técnicos correspondientes, por ejemplo,
para proteger y configurar servidores, su uso requiere una considerable inversión
de tiempo.

También se podrían destacar estos otros inconvenientes:

 Requieren el uso de una red para funcionar
 Están expuestos en una red, pudiendo haber más posibles ataques de
seguridad

¿Cuáles son las alternativas a un modelo cliente-

servidor?
La alternativa más frecuente y tradicional al modelo de cliente-servidor es el
software denominado «standalone». En este tipo de software, un único sistema
se encarga de toda la operativa de la aplicación. Hasta hace unos años, este
modelo de software era el más predominante.
Para entender el modelo standalone podemos pensar en la antigua aplicación
«Word» de Microsoft, que se ejecutaba en el ordenador sin necesidad de estar
conectado a Internet ni depender de un servidor externo. Hoy está siendo
desplazada por su alternativa para trabajo en la nube, a la cual accedemos
mediante un cliente (el navegador) y nos conectamos con un servidor que es el
encargado de almacenar los documentos y dar soporte a los clientes.
A nivel de red también existen otras alternativas de software que no utilizan
arquitecturas cliente-servidor, como los conocidos «Peer-to-Peer» (P2P), donde
cada nodo funciona como un actor capaz de hacer a la vez tareas típicas de
servidor y de cliente.
En el modelo peer-to-peer un programa llamado peer representa a los servidores
y a los clientes simultáneamente y cumple ambas tareas. Este modelo constituye
la base del blockchain.
El modelo primario-secundario, antes conocido como “modelo maestro-
esclavo”, es otro buen ejemplo. En este modelo, la parte primaria dirige a las
partes secundarias y las coordina. La parte primaria libera recursos utilizables para
las partes secundarias y decide cuándo se encargan de determinadas tareas.

¿Cuáles son los usos y protocolos típicos del cliente-

servidor?
Una aplicación cliente-servidor típica es un servidor web. En este caso, el cliente
envía una petición al servidor web para abrir una página web concreta. El servidor
devuelve al cliente los datos solicitados. La página web se muestra en el
navegador del cliente. Para enviar peticiones HTTP se utiliza el Hypertext Transfer
Protocol.
Un servidor de correo electrónico también funciona según el principio cliente-
servidor. Cuando un cliente de correo electrónico se comunica con un servidor, el
cliente solicita y recupera los correos electrónicos que están en el servidor. El
servidor pone los correos electrónicos a disposición del cliente. Los protocolos
utilizados son SMTP, IMAP o POP y TLS.
Otra aplicación muy común es la transferencia de datos entre un cliente y un
servidor web mediante File Transfer Protocols (FTP). Este protocolo permite subir
y bajar archivos.
Componentes clave de la arquitectura cliente-servidor
Como hemos dicho antes, en las arquitecturas cliente-servidor los componentes
más importantes son el cliente y el servidor. Vamos a ver los roles de estos dos
actores.

Cliente: roles y funcionalidades

El cliente es la parte de las aplicaciones que inicia las peticiones de servicios hacia
el servidor usando la red como mecanismo de comunicación. Típicamente en el
lado del cliente encontramos todo lo que respecta a la funcionalidad que permite al
usuario interactuar con estos sistemas. Por tanto, encontramos interfaces de
usuario que pueden ser de distintos tipos.
Actualmente, lo más habitual es que la aplicación cliente se ejecute en un
navegador, en cuyo caso lo que tendremos son botones formularios y elementos
de esta índole. Sin embargo, en términos generales un cliente puede ser de
muchos tipos, mediante programas de escritorio, programas de consola, etc.

Servidor: roles y funcionalidades

El servidor, de manera genérica, es el componente que proporciona los servicios a
los clientes. Un servidor puede consistir en diversos tipos de componentes de
software instalados sobre un hardware. En cualquier caso, siempre será un
sistema que esperará las solicitudes de los clientes para procesarlas y finalmente,
entregar la respuesta a éstos.
Entre los roles de los servidores se encuentran tareas como el almacenamiento de
la información, el procesamiento de datos y el control de las reglas de negocio.
Además, dentro del concepto de servidor encontramos diversos tipos de
aplicaciones como servidores web, de correo, servidores de bases de datos, entre
muchos otros.

Comunicación entre cliente y servidor

Para la comunicación entre cliente y servidor se utilizan siempre las redes de
computadores. Sin embargo, dentro del amplio mundo de las redes, estas
comunicaciones se pueden realizar por medio de múltiples protocolos.
Entre los protocolos más utilizados se encuentra el HTTP, que es el protocolo que
sustenta la web, SMTP para el envío de correo electrónico, POP / IMAP para la
recepción del correo, o FTP para la transferencia de archivos.
Los protocolos son definiciones de los procesos y comunicaciones que se tienen
que dar entre los sistemas clientes y servidor para que estas se realicen de
manera sistemática, se pueda verificar la integridad de la información, etc.

¿Qué objetivo persigue la arquitectura cliente-servidor?

El objetivo principal de la arquitectura cliente-servidor es realizar la separación de
las funciones y responsabilidades del software en distintas capas. La separación
de responsabilidades es una de las bases sobre la que se sustenta el buen diseño
del software. Una de las separaciones más esenciales y directas viene dada
justamente por la arquitectura cliente-servidor.
Los beneficios de esta separación de responsabilidades son diversos. Entre ellos
podemos destacar la posibilidad de escalar o mantener las aplicaciones por
separado, lo que facilita también la realización de equipos de trabajo
independientes o la posibilidad de utilizar infraestructuras distintas y
especializadas en cada una de las partes del software.

¿Cómo funciona el modelo cliente-servidor?

Como ya hemos mencionado, el modelo de las aplicaciones cliente-servidor
consiste en la realización de comunicaciones para ejecución de las necesidades
del software.
En este tipo de software funciona mediante un procedimiento que incluye los
siguientes pasos:
El cliente realiza la solicitud de un recurso o un servicio al servidor. Para ello envía
una señal a través de la red, en la que entrega todas las características de la
función que requiere que se realice.
El servidor recibe la solicitud y procesa la entrada de datos enviada por el cliente,
componiendo una respuesta.
Esa respuesta se envía por la red hasta llegar al cliente que la recibe, y
generalmente, muestra una salida adecuada para el usuario.
Estas son las bases del funcionamiento de la arquitectura cliente-servidor de
manera genérica, aunque dependiendo de cada tipo de sistema distribuido, puede
haber diversas características más complejas en lo que respecta a los tipos de
solicitud, tipos de respuesta, etc.

¿Cuál es la importancia de un sistema operativo cliente-

servidor?
Los sistemas clientes servidor desempeñan un papel fundamental en la
actualidad, ya que sustentan la mayor parte de las aplicaciones que existen en
internet, así como en las redes empresariales o del hogar.
En el momento actual, en el que todos los hogares y empresas hacen uso de la
nube para la obtención de servicios de todo tipo, la arquitectura cliente-servidor
nos ofrece la base para su funcionamiento. Todas las aplicaciones web funcionan
con el modelo cliente-servidor, pero también ocurre con otros servicios de Internet
como el correo, o incluso con otros servicios populares como el streaming, las
aplicaciones móviles, etc.
Este modelo, además, nos aporta ventajas como la posibilidad de acceder a los
servicios allá donde estemos, o la seguridad de la información, ya que el servidor
es capaz de garantizar el acceso solamente a aquellas personas que realmente
disponen de los permisos adecuados.

Tipos de arquitectura cliente-servidor

Dentro de las arquitecturas cliente-servidor también existen distintas
clasificaciones que vamos a resumir.

Arquitectura de dos niveles (2-Tier)

Este es el modelo habitual de las arquitecturas clientes servidor, donde los clientes
realizan solicitudes directas sobre el servidor, sin la intervención de otros
intermediarios.
Arquitectura de tres niveles (3-Tier)
También existen arquitecturas en niveles adicionales, como 3-Tier, en las cuales
se introduce un intermediario entre el cliente y el servidor que tiene normalmente
la responsabilidad de aplicar una capa de lógica de negocio. Con ello
conseguimos una separación mayor de la responsabilidad del software, lo que
aporta adicionales ventajas a nivel de mantenibilidad y escalabilidad, a costa de
una mayor complejidad.

Otros modelos y variantes

Dentro de las arquitecturas clientes servidor también tenemos modelos más
complejos como los (n-Tier), donde se añaden capas adicionales para separar aún
más la responsabilidad del software, como por ejemplo aislar una capa de datos.

¿Qué es TCP/IP?
Es normal no pensar en cómo funciona Internet cuando visita páginas web o usa
sus aplicaciones favoritas. No obstante, mucho depende de los ordenadores,
servidores y módems que se comunican entre sí detrás del escenario. TCP/IP es
un estándar de comunicación que ayuda a que Internet funcione. Siga leyendo
para saber qué es TCP/IP, cómo funciona y las diferencias entre TCP e IP.
Además, consiga una VPN para mantener protegido todo su tráfico en Internet.
Desarrollado en los 70 por DARPA (Defense Advanced Research Projects Agency
en EE. UU.), TCP/IP empezó como uno de muchos protocolos de Internet. El
modelo TCP/IP se convirtió más adelante en el protocolo estándar de ARPAnet, el
predecesor del Internet moderno. Actualmente, TCP/IP es el estándar global para
las comunicaciones en Internet.

¿Qué hace TCP/IP?

TCP/IP determina cómo los ordenadores transfieren datos de un dispositivo a otro.
Estos datos deben ser exactos para que el receptor obtenga la misma información
enviada por el emisor.
¿Qué es TCP/IP y cómo funciona?
Para garantizar que cada comunicación llegue intacta al destino deseado, el
modelo TCP/IP divide los datos en paquetes y luego los vuelve a juntar para
formar el mensaje completo en el destino. Enviar los datos en paquetes pequeños
hace que sea más fácil mantener la exactitud que enviando todos los datos a la
vez.
Después de dividir un mensaje individual en paquetes, estos pueden recorrer
diversos caminos en caso de congestión. Es como enviar distintas tarjetas de
cumpleaños a la misma casa por correo. Las tarjetas empiezan su recorrido en su
casa, pero podría introducirlas en buzones diferentes de modo que cada una
tenga un trayecto distinto hasta la dirección del destinatario.

¿Cómo funciona el modelo TCP/IP?

Cuando envía algo por Internet, ya sea un mensaje, una foto o un archivo, el
modelo TCP/IP divide esos datos en paquetes según un procedimiento de cuatro
capas. Los datos primero atraviesan estas capas en un sentido, y luego lo hacen
en sentido contrario cuando los datos se vuelven a juntar en el destino.

Un diagrama de cómo el modelo TCP/IP divide los datos en paquetes y los envía a
través de cuatro capas distintas
El modelo TCP/IP funciona porque todo el proceso está estandarizado. Sin la
estandarización, la comunicación podría volverse impredecible y ralentizar las
operaciones, y un Internet rápido depende de la eficiencia. Como estándar global,
el modelo TCP/IP es una de las maneras más eficientes de transferir datos por
Internet.

Otros protocolos de Internet habituales

El modelo TCP/IP abarca muchos protocolos de Internet que definen cómo se
tratan y se envían los datos. Los protocolos de Internet habituales incluyen HTTP,
FTP y SMTP, y los tres se usan a menudo en combinación con el modelo TCP/IP.

 HTTP (protocolo de transferencia de hipertexto) controla el funcionamiento

de navegadores y páginas web.
 FTP (protocolo de transferencia de archivos) define cómo se envían
archivos en una red.
 SMTP (protocolo de transferencia simple de correo) se usa para enviar y
recibir correo electrónico.
Los protocolos VPN, como OpenVPN, crean redes seguras y privadas en Internet.
AVG Secure VPN usa un potente cifrado de datos para proteger su conexión a
Internet mientras oculta su dirección IP tras uno de nuestros numerosos servidores
VPN en más 50 ubicaciones de todo el mundo.

Protocolos TCP/IP
TCP/IP es una familia de protocolos de comunicación utilizados para conectar
sistemas en una red. Lleva el nombre de dos de los protocolos de la familia: TCP
(Transmission Control Protocol) y IP ( Internet Protocol ). Hypertext Transfer
Protocol (HTTP) es un miembro de la familia TCP/IP.
Los protocolos de la familia TCP/IP corresponden, en muchos casos, a las capas
del modelo OSI (Open Systems Interconnection). La Tabla 1 muestra HTTP y las
capas subyacentes de la familia TCP/IP en términos del modelo OSI. También se
muestran las capas de Arquitectura de Red de Sistemas (SNA), que
aproximadamente coinciden con las capas de OSI.
Layer OSI SNA TCP/IP

7 Aplicación Aplicación HTTP

6 Presentación Presentación (vacía)

Layer OSI SNA TCP/IP

5 Sesión Flujo de datos (vacía)

4 Transporte Transmisión TCP

3 Red Control de vía de acceso IP

2 Enlace de datos Enlace de datos Subred

1 física física Subred

Tabla| 1. Las capas de la familia de protocolos TCP/IP

Protocolo Internet (IP)

IP es un protocolo de capa de red que proporciona un servicio de transmisión de
datos sin conexión que utiliza TCP. Los datos se transmiten enlace por enlace;
una conexión de extremo a extremo nunca se configura durante la llamada. La
unidad de transmisión de datos es el datagrama.

Protocolo de control de transmisión (TCP)

TCP es un protocolo de capa de transporte que proporciona un servicio de
transmisión de datos fiable, dúplex y orientado a conexiones. La mayoría de las
aplicaciones de Internet utilizan TCP.

Protocolo de transferencia de hipertexto (HTTP)

HTTP es un protocolo de capa de aplicación que se utiliza para sistemas de
información distribuida, colaborativa e hipermedia. HTTP es el protocolo utilizado
entre clientes web y servidores web.
Muchas implementaciones TCP/IP proporcionan una interfaz de programación de
aplicaciones al protocolo TCP; es decir, a la capa de transporte. Esta interfaz se
conoce comúnmente como interfaz de sockets. La interfaz de sockets TCP/IP para
CICS es la interfaz de sockets de z/OS® Communications Server IP CICS . Se
suministra con z/OS Communications Server y forma parte integral de z/OS. No
forma parte del soporte web de CICS y no utiliza el dominio SO de CICS . z/OS
Communications Server: IP CICS Sockets Guide describe la interfaz de sockets de
CICS .

¿Qué diferencia hay entre TCP e IP?

TCP e IP son protocolos distintos para redes informáticas. La diferencia entre TCP
(protocolo de control de transmisión) e IP (protocolo de Internet) es su papel en el
proceso de transmisión de datos. IP obtiene la dirección a la que se envían los
datos (su ordenador tiene una dirección IP). TCP garantiza la entrega correcta de
los datos una vez hallada dicha dirección IP. En combinación, ambos forman el
protocolo TCP/IP.
En otras palabras, IP clasifica el correo y TCP lo envía y recibe. Aunque los dos
protocolos suelen considerarse una entidad, otros protocolos, como UDP
(protocolo de datagrama de usuario), pueden enviar datos en el sistema IP sin
usar TCP. Aun así, TCP requiere una dirección IP para enviar datos. Esa es otra
diferencia entre IP y TCP.

Capas de protocolo y el modelo de Interconexión de

Sistemas Abiertos
La mayoría de los conjuntos de protocolos de red se estructuran como series de
capas, que en ocasiones se denominan pila de protocolos. Cada capa está
diseñada para una finalidad específica. Cada capa existe tanto en los sistemas de
envío como en los de recepción. Una capa específica de un sistema envía o recibe
exactamente el mismo objeto que envía o recibe el proceso equivalente de otro
sistema. Estas actividades tienen lugar independientemente de las actividades de
las capas por encima o por debajo de la capa que se está considerando.
Básicamente, cada capa de un sistema actúa independientemente de las demás
capas del mismo sistema. Cada capa actúa en paralelo con la misma capa en
otros sistemas.

Modelo de referencia OSI

La mayoría de los conjuntos de protocolos de red se estructuran en capas. La
Organización Internacional para la Estandarización (ISO) ha diseñado el modelo
de referencia de Interconexión de Sistemas Abiertos (OSI) que utiliza capas
estructuradas. El modelo OSI describe una estructura con siete capas para las
actividades de red. Cada capa tiene asociados uno o más protocolos. Las capas
representan las operaciones de transferencia de datos comunes a todos los tipos
de transferencias de datos entre las redes de cooperación.
El modelo OSI enumera las capas de protocolos desde la superior (capa 7) hasta
la inferior (capa 1). La tabla siguiente muestra el modelo.
Tabla 1–1 Modelo de referencia de Interconexión de Sistemas Abiertos

Nº de Nombre de Descripción
capa capa

7 Aplicación Se compone de los servicios y aplicaciones de

comunicación estándar que puede utilizar todo el mundo.

6 Presentación Se asegura de que la información se transfiera al sistema

receptor de un modo comprensible para el sistema.

5 Sesión Administra las conexiones y terminaciones entre los

sistemas que cooperan.

4 Transporte Administra la transferencia de datos. Asimismo, garantiza

que los datos recibidos sean idénticos a los transmitidos.

3 Red Administra las direcciones de datos y la transferencia

entre redes.

2 Vínculo de Administra la transferencia de datos en el medio de red.

datos

1 Física Define las características del hardware de red.

El modelo de referencia OSI define las operaciones conceptuales que no son

exclusivas de un conjunto de protocolos de red particular. Por ejemplo, el conjunto
de protocolos de red OSI implementa las siete capas del modelo OSI. TCP/IP
utiliza algunas de las capas del modelo OSI. TCP/IP también combina otras capas.
Otros protocolos de red, como SNA, agregan una octava capa.

Modelo de arquitectura del protocolo TCP/IP

El modelo OSI describe las comunicaciones de red ideales con una familia de
protocolos. TCP/IP no se corresponde directamente con este modelo. TCP/IP
combina varias capas OSI en una única capa, o no utiliza determinadas capas. La
tabla siguiente muestra las capas de la implementación de Oracle Solaris de
TCP/IP. La tabla enumera las capas desde la capa superior (aplicación) hasta la
capa inferior (red física).
Tabla 1–2 Pila de protocolo TCP/IP

Ref. OSI Equivalente de capa Capa TCP/IP Ejemplos de protocolos TCP/IP

Nº de OSI
capa

5,6,7 Aplicación, sesión, Aplicación NFS, NIS, DNS, LDAP, telnet, ftp,
presentación rlogin, rsh, rcp, RIP, RDISC, SNMP
y otros.

4 Transporte Transporte TCP, UDP, SCTP

3 Red Internet IPv4, IPv6, ARP, ICMP

2 Vínculo de datos Vínculo de PPP, IEEE 802.2

datos

1 Física Red física Ethernet (IEEE 802.3), Token Ring,

RS-232, FDDI y otros.

La tabla muestra las capas de protocolo TCP/IP y los equivalentes del modelo
OSI. También se muestran ejemplos de los protocolos disponibles en cada nivel de
la pila del protocolo TCP/IP. Cada sistema que participa en una transacción de
comunicación ejecuta una única implementación de la pila del protocolo.

¿Con qué direcciones IP funciona TCP/IP?

Ya tenga una dirección IPv4 o IPv6, es muy probable que ya esté usando el
modelo TCP/IP. Este es el modelo estándar para la mayor parte de la
infraestructura de Internet. Hay distintas categorías de direcciones IP que pueden
afectar a su privacidad o a cómo funciona el protocolo (por ejemplo, direcciones IP
públicas frente a locales o estáticas frente a dinámicas), pero todas siguen el
modelo TCP/IP estándar.

Capa de red física

La capa de acceso a la red, también conocida como la capa de enlace a los datos,
gestiona la infraestructura física que permite a los ordenadores comunicarse entre
sí por Internet. Esto abarca, entre otros elementos, cables Ethernet, redes
inalámbricas, tarjetas de interfaz de red y controladores de dispositivos en el
ordenador.
La capa de acceso a la red también incluye la infraestructura técnica, como el
código que convierte datos digitales en señales transmisibles, que hacen posible
una conexión.

Capa de vínculo de datos

La capa de vínculo de datos identifica el tipo de protocolo de red del paquete, en
este caso TCP/IP. La capa de vínculo de datos proporciona también control de
errores y estructuras. Algunos ejemplos de protocolos de capa de vínculo de datos
son las estructuras Ethernet IEEE 802.2 y Protocolo punto a punto (PPP).

Capa de Internet
La capa de Internet, también conocida como capa de red o capa IP, acepta y
transfiere paquetes para la red. Esta capa incluye el potente Protocolo de Internet
(IP), el protocolo de resolución de direcciones (ARP) y el protocolo de mensajes
de control de Internet (ICMP).
Controla el flujo y el enrutamiento de tráfico para garantizar que los datos se
envían de forma rápida y correcta. Esta capa también es responsable de volver a
juntar el paquete de datos en el destino. Si hay mucho tráfico en Internet, esta
capa puede tardar un poco más en enviar un archivo, pero es menos probable que
el archivo se dañe.

Protocolo IP
El protocolo IP y sus protocolos de enrutamiento asociados son posiblemente la
parte más significativa del conjunto TCP/IP. El protocolo IP se encarga de:

 Direcciones IP: Las convenciones de direcciones IP forman parte del

protocolo IP. Cómo diseñar un esquema de direcciones IPv4 introduce las
direcciones IPv4 y Descripción general de las direcciones IPv6 las
direcciones IPv6.
 Comunicaciones de host a host: El protocolo IP determina la ruta que
debe utilizar un paquete, basándose en la dirección IP del sistema receptor.
 Formato de paquetes: el protocolo IP agrupa paquetes en unidades
conocidas como datagramas. Puede ver una descripción completa de los
 datagramas en Capa de Internet: preparación de los paquetes para la
entrega.
 Fragmentación: Si un paquete es demasiado grande para su transmisión a
través del medio de red, el protocolo IP del sistema de envío divide el
paquete en fragmentos de menor tamaño. A continuación, el protocolo IP
del sistema receptor reconstruye los fragmentos y crea el paquete original.

Protocolo ARP
El protocolo de resolución de direcciones (ARP) se encuentra conceptualmente
entre el vínculo de datos y las capas de Internet. ARP ayuda al protocolo IP a
dirigir los datagramas al sistema receptor adecuado asignando direcciones
Ethernet (de 48 bits de longitud) a direcciones IP conocidas (de 32 bits de
longitud).

Protocolo ICMP
El protocolo de mensajes de control de Internet (ICMP) detecta y registra las
condiciones de error de la red. ICMP registra:

 Paquetes soltados: Paquetes que llegan demasiado rápido para poder

procesarse.
 Fallo de conectividad: No se puede alcanzar un sistema de destino.
 Redirección: Redirige un sistema de envío para utilizar otro enrutador.

Capa de transporte
La capa de transporte TCP/IP garantiza que los paquetes lleguen en secuencia y
sin errores, al intercambiar la confirmación de la recepción de los datos y
retransmitir los paquetes perdidos. Este tipo de comunicación se conoce como
transmisión de punto a punto. Los protocolos de capa de transporte de este nivel
son el Protocolo de control de transmisión (TCP), el Protocolo de datagramas de
usuario (UDP) y el Protocolo de transmisión para el control de flujo (SCTP). Los
protocolos TCP y SCTP proporcionan un servicio completo y fiable. UDP
proporciona un servicio de datagrama poco fiable.

Protocolo TCP
TCP permite a las aplicaciones comunicarse entre sí como si estuvieran
conectadas físicamente. TCP envía los datos en un formato que se transmite
carácter por carácter, en lugar de transmitirse por paquetes discretos. Esta
transmisión consiste en lo siguiente:

 Punto de partida, que abre la conexión.

 Transmisión completa en orden de bytes.
 Punto de fin, que cierra la conexión.

TCP conecta un encabezado a los datos transmitidos. Este encabezado contiene

múltiples parámetros que ayudan a los procesos del sistema transmisor a
conectarse a sus procesos correspondientes en el sistema receptor.
TCP confirma que un paquete ha alcanzado su destino estableciendo una
conexión de punto a punto entre los hosts de envío y recepción. Por tanto, el
protocolo TCP se considera un protocolo fiable orientado a la conexión.

Protocolo SCTP
SCTP es un protocolo de capa de transporte fiable orientado a la conexión que
ofrece los mismos servicios a las aplicaciones que TCP. Además, SCTP admite
conexiones entre sistema que tienen más de una dirección, o de host múltiple. La
conexión SCTP entre el sistema transmisor y receptor se denomina asociación.
Los datos de la asociación se organizan en bloques. Dado que el protocolo SCTP
admite varios hosts, determinadas aplicaciones, en especial las que se utilizan en
el sector de las telecomunicaciones, necesitan ejecutar SCTP en lugar de TCP.

Protocolo UDP
UDP proporciona un servicio de entrega de datagramas. UDP no verifica las
conexiones entre los hosts transmisores y receptores. Dado que el protocolo UDP
elimina los procesos de establecimiento y verificación de las conexiones, resulta
ideal para las aplicaciones que envían pequeñas cantidades de datos.

Capa de aplicación
La capa de aplicaciones es el grupo de aplicaciones que permite al usuario
acceder a la red. Para la mayoría de nosotros, esto significa el correo electrónico,
las aplicaciones de mensajería y los programas de almacenamiento en la nube.
Esto es lo que el usuario final ve y con lo que interactúa al recibir y enviar datos.
Estos servicios utilizan la capa de transporte para enviar y recibir datos. Existen
varios protocolos de capa de aplicación. En la lista siguiente se incluyen ejemplos
de protocolos de capa de aplicación:

 Servicios TCP/IP estándar como los comandos ftp, tftp y telnet.

 Comandos UNIX "r", como rlogin o rsh.
 Servicios de nombres, como NIS o el sistema de nombre de dominio (DNS).
 Servicios de directorio (LDAP).
 Servicios de archivos, como el servicio NFS.
 Protocolo simple de administración de red (SNMP), que permite administrar
la red.
 Protocolo RDISC (Router Discovery Server) y protocolos RIP (Routing
Information Protocol).
 Servicios TCP/IP estándar

FTP y FTP anónimo

El Protocolo de transferencia de archivos (FTP) transfiere archivos a una red
remota y desde ella. El protocolo incluye el comando ftp y el daemon in.ftpd. FTP
permite a un usuario especificar el nombre del host remoto y las opciones de
comandos de transferencia de archivos en la línea de comandos del host local. El
daemon in.ftpd del host remoto administra las solicitudes del host local. A
diferencia de rcp, ftp funciona aunque el equipo remoto no ejecute un sistema
operativo basado en UNIX. Para realizar una conexión ftp, el usuario debe iniciar
sesión en un sistema remoto, aunque éste se haya configurado para permitir FTP
anónimo.
Puede obtener una gran cantidad de material de servidores FTP anónimos
conectados a Internet. Las universidades y otras instituciones configuran estos
servidores para ofrecer software, trabajos de investigación y otra información al
dominio público. Al iniciar sesión en este tipo de servidor, se utiliza el nombre de
inicio de sesión anonymous, que da nombre al "servidor FTP anónimo"
Este manual no describe el uso del FTP anónimo ni la configuración de servidores
FTP anónimos. Existen múltiples libros, como Conéctate al mundo de Internet.
Guía y catálogo, que describen el protocolo FTP anónimo de manera
pormenorizada. Encontrará información sobre el uso de FTP en la System
Administration Guide: Network Services. La página del comando man ftp(1)
describe todas las opciones del comando ftp que se invocan mediante el intérprete
de comandos. La página del comando man ftpd(1M) describe los servicios que
proporciona el daemon in.ftpd.

Telnet
El protocolo Telnet permite la comunicación entre los terminales y los procesos
orientados a los terminales de una red que ejecuta TCP/IP. Este protocolo se
implementa como programa telnet en los sistemas locales y como daemon
in.telnetd en los equipos remotos. Telnet proporciona una interfaz de usuario a
través de la cual se pueden comunicar dos hosts carácter por carácter o línea por
línea. Telnet incluye un conjunto de comandos que se documentan de forma
detallada en la página del comando man telnet(1).

TFTP:

El protocolo de transferencia de archivos trivial (tftp) ofrece funciones similares a

ftp, pero no establece la conexión interactiva de ftp. Como consecuencia, los
usuarios no pueden ver el contenido de un directorio ni cambiar directorios. Los
usuarios deben conocer el nombre completo del archivo que se va a copiar. La
página del comando man tftp(1) describe el conjunto de comandos tftp.

Comandos UNIX "r"

Los comandos UNIX "r" permiten a los usuarios ejecutar comandos en sus
equipos locales que se ejecutan en el host remoto. Estos comandos incluyen:

 rcp
 rlogin
 rsh

Encontrará instrucciones sobre estos comandos en las páginas del comando man
rcp(1), rlogin(1) y rsh(1).

Servicios de nombres
Oracle Solaris proporciona los siguientes servicios de nombres:
DNS:
El sistema de nombre de dominio (DNS) es el servicio de nombres que
proporciona Internet para las redes TCP/IP. DNS proporciona nombres de host al
servicio de direcciones IP. También actúa como base de datos para la
administración del correo. Para ver una descripción completa de este servicio,
consulte la System Administration Guide: Naming and Directory Services (DNS,
NIS, and LDAP). Consulte también la página del comando man
resolver(3RESOLV).
Archivos /etc : El sistema de nombres UNIX basado en host se desarrolló para
equipos UNIX autónomos y posteriormente se adaptó para el uso en red. Muchos
de los antiguos sistemas operativos y equipos UNIX siguen utilizando este
sistema, pero no resulta adecuado para redes complejas de gran tamaño.

NIS:
El Servicio de información de la red (NIS) se desarrolló independientemente de
DNS y tiene un enfoque ligeramente distinto. Mientras que DNS trata de facilitar la
comunicación con el uso de nombres de equipos en lugar de direcciones IP
numéricas, NIS se centra en facilitar la administración de la red al proporcionar
control centralizado sobre distintos tipos de información de red. NIS almacena
información sobre los nombres de equipo y las direcciones, los usuarios, la red y
los servicios de red. La información de espacio de nombres NIS se almacena en
asignaciones NIS. Para obtener más información sobre la arquitectura y
administración de NIS, consulte la System Administration Guide: Naming and
Directory Services (DNS, NIS, and LDAP).
Servicio de directorios
Oracle Solaris admite LDAP (Protocolo ligero de acceso a directorios) junto con el
servidor de directorios Sun ONE (Sun Open Net Environment), así como otros
servidores de directorios LDAP. La diferencia entre un servicio de nombres y un
servicio de directorios radica en la extensión de las funciones. Un servicio de
directorios proporciona las mismas funciones que un servicio de nombres, pero
además cuenta con funciones adicionales. Consulte la System Administration
Guide: Naming and Directory Services (DNS, NIS, and LDAP).
Servicios de archivos
El protocolo de capa de aplicación NFS proporciona servicios de archivos para
Oracle Solaris. Encontrará información completa sobre el servicio NFS en la
System Administration Guide: Network Services.

Administración de la red
El Protocolo simple de administración de red (SNMP) permite ver la distribución de
la red y el estado de los equipos clave. SNMP también permite obtener
estadísticas de red complejas del software basado en una interfaz gráfica de
usuario (GUI). Muchas compañías ofrecen paquetes de administración de red que
implementan SNMP.

Protocolos de enrutamiento
Los protocolos RIP y RDISC son dos protocolos de enrutamiento disponibles para
las redes TCP/IP. Para ver una lista completa de los protocolos de enrutamiento
disponibles para Oracle Solaris 10, consulte la Tabla 5–1 y la Tabla 5–2.
Configuración de un servidor web y un
servidor de aplicaciones en máquinas
distintas (remotas)
Última actualización : 2023-02-16

WebSphere® Application Server proporciona un plug-in de servidor web que puede

configurar para comunicarse con una marca determinada de servidor web. Aprenda a
instalar el servidor web y su plug-in de servidor web para WebSphere Application Server
en una máquina y a configurar el servidor de aplicaciones en el perfil predeterminado en
otra máquina para comunicarse con el servidor web.

Antes de empezar
Si existen varios perfiles, puede seleccionar el configurado por la herramienta de
configuración de plug-ins del servidor web. Consulte Configuración de plug-ins para
obtener una descripción del flujo de lógica que determina cómo seleccionar el perfil a
configurar.

Si la familia de productos WebSphere Application Server da soporte a una marca

determinada de servidor web, como por ejemplo IBM® HTTP Server o Microsoft Internet
Information Services (IIS), el producto WebSphere Application Server proporciona un
plug-in binario para el servidor web que debe instalar.

Si la familia de productos WebSphere Application Server no proporciona un plug-in binario

para una marca determinada de servidor web, el servidor web no está soportado. El objetivo
del plug-in binario es proporcionar el protocolo de comunicación entre el servidor web y el
servidor de aplicaciones.

Supongamos que crea un perfil nuevo y que además desea utilizar un servidor web.
Debe instalar un servidor web nuevo para el perfil nuevo, instalar plug-ins del servidor web
y utilizar la herramienta de configuración de plug-ins del servidor web para configurar el
servidor web y el servidor de aplicaciones.

Aunque el servidor web aún no esté instalado, puede instalar los plug-ins del servidor web
para su uso futuro.

Acerca de esta tarea

Instalar los plug-ins del servidor web instala el módulo de plug-ins. La herramienta
de configuración de plug-ins del servidor web configura el servidor web para
comunicarse con el servidor de aplicaciones y crea una definición de configuración del
servidor web en el servidor de aplicaciones, si es posible.
Sugerencia: Como alternativa a la utilización de la herramienta de configuración de plug-
ins de servidor web, puede utilizar la herramienta de línea de mandatos pct con un archivo
de respuestas para configurar un servidor web. Consulte Configuración de un plug-in de
servidor web utilizando la herramienta pct para obtener más información.

Este procedimiento configura el perfil del servidor de aplicaciones que es el perfil

predeterminado en la máquina. Existe una relación de uno a uno entre un servidor web y el
servidor de aplicaciones.

En este tema se describe cómo crear la topología siguiente:

Atención: Si tiene previsto añadir el nodo del servidor de aplicaciones a una célula del
gestor de despliegue pero todavía no lo ha hecho, inicie el gestor de despliegue y federe el
nodo antes de configurar el plug-in. No se puede añadir un servidor de aplicaciones con una
definición del servidor web a una célula del gestor de despliegue.
La topología siguiente se considera una topología remota porque el servidor web se
encuentra en una máquina distinta. El diagrama muestra una topología remota típica para
un entorno distribuido:
 Este tema describe la instalación de un servidor web en una máquina y el servidor de
aplicaciones en otra máquina. En esta situación, la herramienta de configuración de plug-
ins del servidor web de una máquina no puede crear la definición del servidor web en la
configuración del servidor de aplicaciones de la otra máquina.

En tal caso, la herramienta de configuración de plug-ins del servidor web crea un

script en la máquina del servidor web que puede copiarse en la máquina del servidor de
aplicaciones. Ejecute el script en la máquina del servidor de aplicaciones para crear la
definición de configuración del servidor web en la configuración del servidor de
aplicaciones.

Ejecute el procedimiento siguiente para instalar el plug-in y configurar el servidor web y el

servidor de aplicaciones.

Procedimiento
1. Instale Installation Manager en la Máquina A y la Máquina B.
2. Utilice Installation Manager para instalar WebSphere Application Server Network
Deployment en la máquina A.
3. Cree un servidor de aplicaciones autónomo en la máquina A.
4. Opcional: Cree un alias de host nuevo para el host virtual predeterminado.

Si ha configurado el servidor web para utilizar un puerto distinto del puerto 80, debe
añadir un nuevo alias de host a ese puerto para el host predeterminado. Por ejemplo,
cuando se ejecuta como usuario no root, IBM HTTP Server se configura con un
valor de puerto predeterminado de 8080.
5. Utilice Installation Manager para instalar lo siguiente en la máquina B:
o Plug-ins de servidor web para WebSphere Application Server
o Websphere Customization Toolbox
6. Utilice Installation Manager para instalar IBM HTTP Server en la máquina B o para
instalar otro servidor web soportado en la máquina B.

7. Abra WebSphere Customization Toolbox e inicie la herramienta de

configuración de plug-ins de servidor web en la máquina con el servidor web.
8. Seleccione una ubicación de tiempo de ejecución de plug-in de servidor web.

Si la ubicación de un servidor web previamente instalado que desea utilizar no está

en la lista, realice las acciones siguientes para añadir la ubicación a su conjunto de
trabajo:

a. Pulse Añadir.
b. Escriba un nombre para la ubicación de plug-in de servidor web.
c. Efectúe una de las acciones siguientes:
 Escriba la ubicación.
 Pulse Examinar, busque la ubicación y pulse Aceptar.

9. Pulse Crear.
10. Seleccione el tipo de servidor web que está configurando y pulse Siguiente.
11. Seleccione la arquitectura del servidor web de destino instalado (64 bits o 32 bits) y
pulse Siguiente si se le solicita.
12. Pulse Examinar para seleccionar el archivo o archivos de configuración del
servidor web, verifique que el puerto del servidor web sea correcto y, a
continuación, pulse Siguiente cuando haya terminado.

Seleccione el archivo y no solamente el directorio del archivo. Algunos servidores

web tienen dos archivos de configuración y es necesario que localice los dos
archivos.

La siguiente lista muestra los archivos de configuración para los servidores web
soportados:

Apache HTTP Server

raíz_instancia/config/httpd.conf
Servidor web de Domino ®
names.nsf y Notes.jar

El asistente solicita el archivo notes.jar. El nombre real es Notes.jar.

La herramienta de configuración de plug-ins del servidor web verifica que los

archivos existen pero no los valida.

IBM HTTP Server

 raíz_IHS/conf/httpd.conf

raíz_perfil_IHS/conf/httpd.conf
Servicios de información de Internet (IIS) de Microsoft
La herramienta de configuración de plug-ins del servidor web puede determinar los
archivos que hay que editar.
Sun Java™ System Web Server (anteriormente Sun ONE Web Server y
iPlanet Web Server) Versión 6.0 y posterior
obj.conf y magnus.conf

13. Si está configurando un plug-in de servidor web HTTP de IBM , realice las acciones
siguientes.

a. Opcionalmente, configure la configuración del servidor de administración

para administrar el servidor web.

Atención: Cuando se utiliza la herramienta de configuración de plug-ins de

servidor web para configurar el servidor de administración de IBM HTTP
Server , Websphere Customization Toolbox debe ejecutarse como una
cuenta "local" con privilegios de administrador/root .

i. Seleccione Configurar servidor de administración de IBM HTTP

Server.
ii. Especifique un número de puerto en el que se comunicará el servidor
de administración HTTP de IBM .
iii. De forma opcional, seleccione Crear un ID de usuario para la
autenticación del servidor de administración de IBM y
especifique un ID de usuario y una contraseña para autenticarse en el
servidor administrativo de IBM HTTP Server desde la consola
administrativa.

b. Pulse Siguiente.

c. Especifique el ID de usuario y el grupo del sistema para

tener permiso de escritura en IBM HTTP Server, el servidor administrativo
de IBM HTTP Server y los archivos de configuración del plug-in del
servidor web.

Seleccione Crear ID y grupo de usuario de sistema exclusivo nuevo

mediante las credenciales si es necesario.

Restricción: La configuración puede fallar si especifica un nuevo

ID de usuario o nombre de grupo que supere el límite de plataforma, que
suele ser de 8 caracteres y que a veces se puede configurar.
 d. Opcionalmente, configure el servidor de administración de IBM HTTP
Server para que se ejecute como un servicio de ventana.

i. Seleccione Ejecutar IBM HTTP Server Administration Server

como un servicio de Windows.
ii. Efectúe una de las acciones siguientes:
 Seleccione Iniciar sesión como cuenta de sistema local.
 Seleccione Iniciar sesión como cuenta de usuario
especificada y especifique el ID de usuario y la contraseña
para dicha cuenta.

El ID de usuario necesita los siguientes derechos de usuario

avanzados:

 Actuar como parte del sistema operativo

 Conectarse como un servicio
iii. Elija si el tipo de arranque será automático o manual.

e. Pulse Siguiente.

14. Especifique un nombre exclusivo para la definición de servidor web y

pulse Siguiente.
15. Seleccione el escenario de la configuración.

a. Elija el escenario remoto.

b. Identifique el nombre de host o la dirección IP de la máquina A, que es la
máquina del servidor de aplicaciones.
c. Pulse Siguiente.

16. Seleccione el perfil que desea configurar con el plug-in de servidor web actual y
pulse Siguiente.

Este panel no se visualiza si ha seleccionado el escenario remoto en el paso anterior.

17. Examine el panel de resumen y pulse Configurar para empezar a configurar.

El panel le notifica que debe llevar a cabo pasos manuales para completar la
instalación y la configuración.

La herramienta de configuración de plug-ins de servidor web crea el

script configureweb_server_name en el directorio raíz_plugins/bin/ en la máquina B
(la máquina con el servidor web).
 La herramienta de configuración de plug-ins de servidor web también crea el
archivo plugin-cfg.xml en el directorio raíz_plugins/config/web_server_name .

El servidor web lee el archivo plugin-cfg.xml para determinar las aplicaciones que
el servidor de aplicaciones de la máquina A puede servir al servidor web de la
máquina B. Siempre que cambia la configuración, el servidor de aplicaciones
vuelve a generar el archivo. Cuando la regeneración tenga lugar, propague o copie
el archivo plugin-cfg.xml real de la máquina del servidor de aplicaciones a la
máquina del servidor web. Puede propagar automáticamente el archivo al producto
IBM HTTP Server .

18. Verifique el éxito de la instalación en el panel de resumen y pulse Finalizar.

Si se produce un problema y la instalación no se realiza correctamente, examine los

archivos de registros cronológicos del directorio raíz_plug-ins/logs. Corrija los
problemas y vuelva a realizar la configuración.

19. Copie el script configureweb_server_name de la máquina B (la máquina con el

servidor web) en el directorio raíz_servidor_aplicaciones /bin en la máquina A (la
máquina del servidor de aplicaciones).

nombre_servidor_web es el apodo del servidor web que se ha

especificado. nombre_servidor_web no es un nombre de proveedor, como IIS o
Apache.

En un sistema operativo como AIX® o Linux®, el archivo

es configureweb_server_name.sh. En un sistema Windows, el archivo
es configureweb_server_name.bat. Por ejemplo, en un sistema Linux con un IBM
HTTP Server denominado web_server_1 en la ubicación predeterminada,
copie plugins_root/bin/configureweb_server_1.sh de la máquina B (la máquina con
el servidor web) en el directorio app_server_root/bin de la máquina A (la máquina
del servidor de aplicaciones).

Por ejemplo, en un sistema IBM i con un IBM HTTP Server denominado

web_server_1 en la ubicación predeterminada,
copie plugins_root/bin/configureweb_server_1 de la máquina B (la máquina con el
servidor web) en el directorio app_server_root/bin de la máquina A (la máquina del
servidor de aplicaciones).

Si una plataforma es un sistema como AIX o Linux y la otra es una plataforma

Windows, copie el script desde el directorio crossPlatformScripts . Por ejemplo:
 o raíz_plugins/bin/configureweb_server_name.sh

o raíz_plugins/bin/crossPlatformScripts/windows/
configureweb_server_name.bat

o raíz_plugins/bin/configureweb_server_name
20. Compense las diferencias de codificación para evitar un error del script.

El contenido del script configureweb_server_name.bat o del

script configureweb_server_name.sh puede estar dañado si la codificación de
archivo predeterminada de las dos máquinas difiere. Este caso es posible cuando
una máquina está configurada para un entorno local de juego de caracteres de doble
byte (DBCS) y la otra máquina no.

El contenido del script configureweb_server_name puede estar dañado si la

codificación de archivo predeterminada de las dos máquinas difiere. Este caso es
posible cuando una máquina está configurada para un entorno local de juego de
caracteres de doble byte (DBCS) y la otra máquina no.

Determine la codificación de archivos y utilice uno de los procedimientos siguientes

para evitar el error. Para determinar la codificación de archivo predeterminado,
ejecute el mandato apropiado.

o Ejecute el mandato locale charmap en un sistema como AIX o Linux.

o Ejecute el mandato CHCP en una máquina Windows.

Utilice el resultado del mandato en cada máquina como valor de la

variable codificación_máquina_servidor_web y la
variable codificación_máquina_servidor_aplicaciones en uno de los procedimientos
siguientes.

Procedimientos para compensar las diferencias de codificación

o Servidor web que se ejecuta en un sistema como, por ejemplo, AIX o Linux

Supongamos que el servidor web se ejecuta en una máquina Linux y que el

servidor de aplicaciones se ejecuta en una máquina Windows. Antes de
enviar por FTP el script de configuración de definición de servidor web a la
máquina Windows en modalidad binaria, ejecute el mandato siguiente en el
sistema para codificar el archivo:
 iconv -f web_server_machine_encoding \
-t application_server_machine_encoding \
configure web_server_name .bat

Importante: el nombre del servidor Web (apodo) se utiliza en el nombre del

archivo de script. El nombre no puede contener caracteres de un juego de
caracteres de doble byte (DBCS) si se desea configurar el servidor IBM
HTTP Server para la propagación automática.

o Servidor web en ejecución en un sistema Windows

Supongamos que el servidor web se ejecuta en una máquina Windows y que

el servidor de aplicaciones se ejecuta en una máquina con un sistema como
AIX o Linux. Primero debe descargar el programa de utilidad iconv de un
tercero porque el mandato no se incluye de forma predeterminada en los
sistemas Windows. Antes de enviar por FTP el script de configuración de
definición de servidor web en modalidad binaria a un sistema como AIX o
Linux, ejecute el mandato siguiente en la máquina para codificar el archivo:

iconv -f web_server_machine_encoding \
-t application_server_machine_encoding \
configure web_server_name .sh

Por ejemplo, si la máquina de destino es z/OS®, puede utilizar este mandato

para convertir el archivo de ASCII a EBCDIC, manejando correctamente los
caracteres de fin de línea:

iconv -f ISO8859-1 -t IBM-1047 configureweb_server_name.sh > new_script_name.sh

Omita los caracteres de continuación (\) especificando el mandato en una sola línea.

Si el mandato iconv del sistema no admite la correlación de conversión, copie el

contenido del script de configuración del servidor web en un área común y péguelo
en la máquina en la que se ejecuta el servidor de aplicaciones.

Nota: Si copia un archivo .sh en un sistema operativo basado en UNIX después de

la configuración remota en un sistema operativo Windows, debe realizar chmod
755.

21. Inicie el servidor de aplicaciones en la máquina A.

Utilice el mandato startServer, por ejemplo:

o profile_root/bin/startServer.sh server1

o profile_root\bin\startServer server1
 o profile_root/bin/startServer server1
22. Inicie el servidor de administración de IBM HTTP Server.

El servidor de administración debe iniciarse para que el

script configureweb_server_name.bat/.sh pueda generar y propagar el
archivo plugin-cfg.xml. Para obtener más información, consulte Inicio y detención
del servidor de administración de IBM HTTP Server.

Si no inicia el servidor de administración, el script puede configurar el servidor

web, pero el plug-in no se propaga yPLGC0063E,PLGC0049E, yPLGC0053Ese
producen errores.

23. Abra una ventana de mandatos y cambie el directorio de perfil donde se deba
asignar el servidor web. Ejecute el script que ha copiado en la máquina A (la
máquina del servidor de aplicaciones).

Los siguientes parámetros son necesarios:

o Nombre de perfil
o (Opcional) ID de usuario administrativo
o (Opcional) Contraseña de usuario administrativo

Por ejemplo, puede escribir lo siguiente:

configurewebserver1.sh AppSrv01 my_user_ID my_Password

El servidor web se configura a través dedwsadmin.

El contenido del script configurewebserver1.sh será similar a lo siguiente:

wsadmin.bat -profileName AppSrv01 -user my_user_ID -password my_Password

-f "%WAS_HOME%\bin\configureWebserverDefinition.jacl" webserver1 IHS..

24. Desde la consola administrativa del gestor de despliegue, pulse Administración del
sistema > Guardar cambios en repositorio maestro > Sincronizar cambios con
nodos > Guardar.

25. Servidor web Domino solamente: establezca la variable de

entorno WAS_PLUGIN_CONFIG_FILE.

En plataformas como AIX o Linux, el suministro de un script al shell padre permite

que los procesos hijo hereden las variables exportadas. En sistemas Windows,
ejecute el script como ejecutaría cualquier otro mandato. El aprovisionamiento es
automático en sistemas Windows.

a. Abra una ventana de mandatos.

 b. Vaya al directorio raíz de instalación de plug-ins.
c. Emita el mandato adecuado para el
script plugins_root/bin/setupPluginCfg.sh :

 . plugins_root/bin/setupPluginCfg.sh (Tenga en
cuenta el espacio entre el periodo y el directorio raíz de instalación.)

 source plugins_root/bin/setupPluginCfg.sh

El script también está en el directorio lotus_root/notesdata en sistemas operativos

como AIX o Linux.

Emita el mandato adecuado para el script antes de iniciar el servidor web de

Domino.

26. Vuelva a generar el archivo plugin-cfg.xml en la máquina A (la máquina del

servidor de aplicaciones) utilizando la consola administrativa. Pulse Servidores >
Tipos de servidor > Servidores web. Seleccione el servidor web y pulse Generar
plug-in.

Durante la instalación de los plug-ins, el archivo plugin-cfg.xml predeterminado se

instala en la máquina B (la máquina con el servidor web) en el
directorio plugins_root/config/web_server_name . El servicio de configuración de
plug-ins del servidor web vuelve a generar el archivo plugin-
cfg.xml automáticamente. Para utilizar el archivo plugin-cfg.xml actual del servidor
de aplicaciones, propague el archivo plugin-cfg.xml como se describe en el paso
siguiente.

Este paso muestra cómo generar de nuevo el archivo plugin-cfg.xml. Los productos
WebSphere Application Server se configuran para regenerar automáticamente el
archivo cada vez que se produce un suceso significativo. Dichos sucesos incluyen la
instalación de aplicaciones en el servidor de aplicaciones y el servidor web, por
ejemplo. Crear un host virtual nuevo también puede considerarse un suceso de este
tipo.

27. Propague el archivo plugin-cfg.xml del servidor de aplicaciones al servidor web

utilizando la consola administrativa. Pulse Servidores > Servidor web. Seleccione
el servidor web y pulse Propagar plug-in. Los servidores Web que no sean IBM
HTTP Server requieren una propagación manual.

El servicio de configuración de plug-in de servidor web propaga el archivo plugin-

cfg.xml automáticamente sólo para IBM HTTP Server 8.5 . Para los demás
servidores web, propague el archivo de configuración de plug-ins copiando
manualmente el archivo plugin-cfg.xml del
directorio raíz_perfil/config/cells/nombre_célula/nodes/nombre_nodo/servers/
nombre_servidor_web de la máquina A (la máquina del servidor de aplicaciones) en
 el directorio raíz_plug-ins/config/nombre_servidor_web de la máquina B (la
máquina que tiene el servidor web).

28. Inicie el servlet Snoop para verificar la capacidad del servidor web de recuperar una
aplicación del servidor de aplicaciones.

Pruebe el entorno iniciando el servidor de aplicaciones, el servidor web y utilizando

el servlet Snoop con una dirección IP.

a. Inicie el servidor de aplicaciones.

En un entorno Network Deployment, el servlet Snoop sólo está disponible

en la célula si se ha incluido DefaultApplication al añadir el servidor de
aplicaciones a la célula. La opción -includeapps del
mandato addNode migra DefaultApplication (aplicación predeterminada) a
la célula. Si la aplicación no está presente, omita este paso.

Cambie de directorio a raíz_perfil/bin y ejecute el mandato startServer:

 ./startServer.sh server1

 startServer server1

 startServer server1
b. Inicie IBM HTTP Server o el servidor web que está utilizando.

Utilice la página 2001 o utilice el mandato STRTCPSVR

SERVER(*HTTP) HTTPSVR(instance_name ) para iniciar IBM HTTP
Server.

Utilice una ventana de mandatos para cambiar el directorio a la imagen

instalada de IBM HTTP Server o a la imagen instalada del servidor web.
Emita el mandato adecuado para iniciar el servidor web, como estos
mandatos para IBM HTTP Server:

Para iniciar IBM HTTP Server desde la línea de mandatos:

Acceda a los mandatos apache y apachectl en el

directorio IBMHttpServer/bin .

 ./apachectl start
  apache
c. Apunte el navegador a http://localhost:9080/snoop para probar el transporte
HTTP interno proporcionado por el servidor de aplicaciones. Apunte el
navegador a http://Host_name_of_Web_server_machine/snoop para probar
el plug-in de servidor web.

El puerto de transporte HTTP es 9080 de forma predeterminada y debe ser

único para cada perfil. El puerto está asociado con un sistema virtual
denominado default_host, que está configurado para albergar la aplicación
DefaultApplication. El servlet Snoop forma parte de DefaultApplication.
Cambie el puerto para que coincida con el puerto de transporte HTTP real.

d. Compruebe que el servlet Snoop se está ejecutando.

Las direcciones web deben mostrar la página Snoop Servlet - Request/Client

Information.

e. Solo IBM HTTP Server remoto:

Verifique que la función de propagación automática pueda funcionar en

un IBM HTTP Server remoto utilizando los pasos siguientes. Este
procedimiento no es necesario para servidores web locales.

i. Cree user=adminUser, password=adminPassword en el

archivo raíz_IHS /conf/admin.passwd. Por ejemplo: c:\ws\ihs85\bin\
htpasswd -cb c:\ws\ihs85\conf\admin.passwd adminUser
adminPassword
ii. Utilice la consola administrativa del gestor de despliegue de o el
servidor de aplicaciones de para especificar la información de ID de
usuario y contraseña que ha creado para el usuario administrativo de
IBM HTTP Server. Vaya a Servidores > Servidor web
> definición_servidor_web > Administración de servidor web
remoto. Defina los valores siguientes: admin Port=8008, User
Id=adminUser, Password=adminPassword.
iii. Establezca los permisos correctos de lectura/grabación para el
archivo httpd.conf y el archivo plugin-cfg.xml. Consulte el
archivo IHS_root /logs/admin_ERROR. LOG para obtener más
información.

Para la propagación automática del archivo de configuración del plug-in, es

preciso que el servidor administrativo IBM HTTP esté en ejecución. Si
gestiona un servidor IBM HTTP Server mediante la consola administrativa
de WebSphere Application Server, es posible que aparezca este error:

No se ha podido conectar al servidor de administración IHS

 Realice el procedimiento siguiente para solucionar el error:

iv. Compruebe que el servidor de administración de IBM HTTP Server

esté en ejecución.
v. Verifique que el nombre de host del servidor Web y el puerto
definidos en la consola administrativa de WebSphere Application
Server coincidan con el nombre de host y el puerto del servidor de
administración IBM HTTP Server.
vi. Compruebe que el cortafuegos no impida el acceso al servidor de
administración de IBM HTTP Server desde la consola administrativa
de WebSphere Application Server.
vii. Verifique que el ID de usuario y la contraseña especificados en la
consola administrativa de WebSphere Application Server bajo
gestión remota se crean en el archivo admin.passwd , utilizando el
mandato htpasswd .
viii. Si intenta conectarse de forma segura, compruebe que exporta el
certificado personal keydb del servidor de administración de IBM
HTTP Server a la base de datos de claves de WebSphere Application
Server como un certificado de firmante. Esta base de datos de claves
se especifica mediante la directiva com.ibm.ssl.trustStore en el
archivo sas.client.props del perfil en el que se ejecuta la consola
administrativa. Esta consideración es principalmente para los
certificados autofirmados.
ix. Si sigue teniendo problemas, consulte el archivo IBM HTTP
Server admin_ERROR. LOG y los registros de WebSphere
Application Server (archivotrace.log ) para determinar la causa del
problema.

Resultados
Este procedimiento da como resultado la instalación de los plug-ins de servidor web para
WebSphere Application Server en una máquina de servidor web. La herramienta de
configuración de plug-ins de servidor web también configura el servidor web para dar
soporte a un servidor de aplicaciones en otra máquina.

La instalación de los plug-ins del servidor web da lugar a la creación del

directorio Plugins y de varios subdirectorios. Los directorios siguientes se encuentran
entre los creados en un sistema Linux , por ejemplo:

 raíz_plug-ins/bin contiene los plug-ins binarios de todos los servidores web

admitidos
 raíz_plug-ins/logs contiene archivos de registros cronológicos
 raíz_plug-ins/properties contiene información sobre la versión

Qué hacer a continuación

Consulte Selección de una hoja de ruta y un diagrama de topología de servidor web para
obtener una visión general del procedimiento de instalación.

Consulte Configuración del servidor web para obtener más información sobre los archivos
implicados en la configuración de un servidor web.

Consulte Configuración de plug-ins para obtener información sobre la ubicación del

archivo de configuración del plug-in.

Consulte Edición de archivos de configuración de servidor web para obtener información

sobre cómo la herramienta de configuración de plug-ins de servidor web configura los
servidores web soportados.
Arquitecturas de tres niveles
Última actualización : 2023-04-04

WebSphere® Application Server proporciona la capa de lógica de aplicación en una

arquitectura de tres niveles, lo que permite a los componentes de cliente interactuar con
recursos de datos y aplicaciones heredadas.

De manera colectiva, las arquitecturas de tres niveles son modelos de programación que
permiten la distribución de la funcionalidad de la aplicación entre tres sistemas
independientes, normalmente:

 Componentes de cliente que se ejecutan en estaciones de trabajo locales (nivel uno)

 Procesos que se ejecutan en servidores remotos (nivel dos)
 Una colección discreta de bases de datos, gestores de recursos y aplicaciones de
sistema troncal (nivel tres)

En el siguiente diagrama se muestra un resumen de los tres niveles: Los niveles son lógicos.
Puede que se estén ejecutando o no en el mismo servidor físico.

Figura 1. Arquitectura de tres niveles

En la información siguiente se detallan las tres capas que se describen en el diagrama y la

comunicación, entre ellas:

 La primera capa es la responsable de la presentación y la interacción con el usuario

reside en los componentes del primer nivel. Estos componentes de cliente permiten
al usuario interactuar con los procesos del segundo nivel de forma segura e intuitiva.
WebSphere Application Server da soporte a varios tipos de cliente. Los clientes no
acceden directamente a los servicios del tercer nivel. Por ejemplo, un componente
de cliente proporciona un formulario en el que el cliente solicita los productos. El
 componente de cliente entrega este pedido a los procesos del segundo nivel, que
comprueban las bases de datos del producto y realizan las tareas que son necesarias
para la facturación y el envío.
 Los procesos del segundo nivel se conocen normalmente como la capa de la lógica
de aplicación. Estos procesos gestionan la lógica empresarial de la aplicación y
pueden acceder a los servicios del tercer nivel. La capa de la lógica de aplicación es
donde se produce la mayor parte del trabajo de los procesos. Varios componentes de
cliente pueden acceder simultáneamente a los procesos del segundo nivel, por lo
que esta capa de la lógica de aplicación debe gestionar sus propias transacciones.
 Los servicios del tercer nivel están protegidos del acceso directo de los
componentes de cliente que residen en una red segura. La interacción debe
producirse a través de los procesos del segundo nivel.

La ventaja en z/OS® es la capacidad de contraer el segundo y tercer niveles en

un entorno z/OS físico, conservando al mismo tiempo la seguridad y las ventajas
lógicas de los sistemas de nivel exclusivos.

Los tres niveles deben comunicarse entre ellos. Los protocolos abiertos estándar y las API
expuestas simplifican esta comunicación. Puede escribir componentes de cliente en
cualquier lenguaje de programación, como Java™ o C++. Estos clientes se ejecutan en
cualquier sistema operativo, hablando con la capa lógica de la aplicación. Las bases de
datos del tercer nivel pueden tener cualquier diseño, si la capa de la aplicación pueda
consultarlas y manipularlas. La clave de esta arquitectura es la capa de la lógica de
aplicación.
Enlaces
Cliente servidor
https://www.ionos.es/digitalguide/servidores/know-how/modelo-cliente-servidor/
https://www.arsys.es/blog/todo-sobre-la-arquitectura-cliente-servidor
Universidad de Valladolid, https://www.infor.uva.es › docPDF Tema 2: EL MODELO
CLIENTE/SERVIDOR

Protocolos
https://docs.oracle.com/cd/E19957-01/820-2981/6nei0r0r9/index.html
https://www.avg.com/es/signal/what-is-tcp-ip

Configuración servidor web remoto

https://www.ibm.com/docs/es/was-nd/8.5.5?topic=icwspi-configuring-web-server-
application-server-separate-machines-remote

Arquitecturas Cliente Servidor

https://www.ibm.com/docs/es/was-nd/9.0.5?topic=overview-three-tier-architectures

Vídeos
Concepto
https://m.youtube.com/watch?v=lC6JOQLIgp0 luisina
https://m.youtube.com/watch?v=49zdlyLSwhQ
Protocolo
https://m.youtube.com/watch?v=l2MihYAj0Iw luisina
https://m.youtube.com/watch?v=KbHlWaeniHE
https://m.youtube.com/watch?v=Kx41obWKrto
IP
https://m.youtube.com/watch?v=5nm3F8FJ7s4
Configuración red tipo cliente servidor
https://m.youtube.com/watch?v=S7I1Gwbxeac