Redes TCP/IP bajo Unix - UTN FRLP
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Redes TCP/IP bajo Unix Conceptos básicos de Operación y Administración. por Ing. Fernando A. Cuenca (andres@bbs.frc.utn.edu.ar) Laboratorio de Sistemas - UTN Facultad Córdoba Introducción El presente trabajo persigue 2 objetivos: en primer lugar, presentar al lector las posibilidades que ofrece un ambiente de red basado en Unix; en segundo lugar, introducirlo en los conceptos básicos requeridos para administrar una red TCP/IP bajo el citado sistema operativo1. No obstante lo anterior, se hacen dos aclaraciones al lector: • Se asumirá que el lector posee conocimientos básicos de la terminología empleada en tecnología de redes (LAN vs WAN, topologías, medios de transmisión, protocolos, conmutación por paquetes, etc.). • "Lo maravilloso de los estándares es que hay muchos de donde elegir" -- Almirante Grace Murray Hooper2. Uno de los grandes mitos acerca de Unix es su nivel de estandarización. Si bien todas las diversas variantes (o flavors) de Unix comparten una filosofía común muy amplia lo cual hace posible un alto grado de similitud entre todas ellas, en el momento de afinar los detalles de la implementación suelen aparecer discrepancias (en particular, los nombres de los comandos, el formato y nombre de los parámetros, el formato de los resultados que se muestran por pantalla, etc.). Para éste articulo se tomará al sistema operativo Linux (una variante de Unix de distribución gratuita) como plataforma de referencia; será tarea del lector identificar las diferencias con su propia plataforma y realizar las adaptaciones del caso. 1 Cabe aclarar, sin embargo, que la mayoría de los conceptos que se desarrollarán en el capítulo de Administración son aplicables a casi todas las implementaciones de TCP/IP bajo otras plataformas. 2 La Almirante Grace Hooper participó en el diseño del lenguaje COBOL, durante la década del 60.
Conectándose a Unix
Terminales "bobas", Workstations y PCs
El sistema operativo Unix fue concebido en los años 70. En aquellos tiempos, el modelo
imperante para los sistemas de computación era el que llegó a
conocerse como "de tiempo compartido", en donde un equipo
central con capacidad de multiprogramación (conocido como
host) atendía simultáneamente a múltiples usuarios conectados al
mismo desde terminales remotas ubicadas en el mismo edificio o
en otras locaciones conectadas al mismo a través de una red de
Figura 1: comunicaciones.
Computador PDP-8
Dichas terminales estaban constituidas básicamente por un teclado, una pantalla y un
dispositivo de comunicaciones (usualmente de tipo serial, por
ejemplo basado en RS-232), y se denominaban "terminales
bobas" (dumb terminals) debido a que carecían por completo
de capacidad de procesamiento, mas allá de la necesaria para
tomar caracteres desde el teclado, enviarlos al equipo central
por el vínculo de comunicaciones y recibir desde él nuevos
caracteres que desplegar en la pantalla. De esta forma,
resultaban meros dispositivos de interface entre el usuario y un
proceso en ejecución en la computadora central. Figura 2: Terminal
VT100
Luego, durante el transcurso de la década del 80 y conforme los costos de la tecnología de
computación disminuían crecientemente, fue creciendo una nueva concepción tendiente a
llevar poder de procesamiento más cerca del usuario.
Por una parte, las PC (Computadoras Personales) aparecieron en escena y rápidamente
empezaron a poblar las oficinas y mas tarde los hogares. Aquellas organizaciones que se
vieron en la situación de enfrentar la coexistencia de equipos personales con centralizados
encontraron que podían aprovechar lo mejor de ambos mundos permitiendo el acceso desde
las PCs a las aplicaciones y datos corporativos corriendo bajo Unix, por medio de conexión
de las PCs al host Unix a través de conexiones seriales y la ejecución en la PC de un
software emulador de terminal. Dichos programas constituyen básicamente una terminal
boba implementada en software, que utiliza el hardware de la PC de manera tal que la
misma se comporta como si se tratara de una terminal corriente (es decir, solo procesa
entradas y salidas por teclado y pantalla, quedando el procesamiento de la aplicación en
manos del equipo central).
Por otra parte, en los ambientes de ingeniería e investigación, empezaron a aparecer potentes
computadoras personales basadas en Unix y construidas, usualmente, con tecnología RISC,
denominadas workstations (estaciones de trabajo). Si bien estos equipos corrían
básicamente el mismo Unix que los equipos centralizados, explotaban más sus capacidades
de multiprocesamiento que la de atender múltiples usuarios simultáneos; es decir, se trataba
de equipos con mucho potencial de cálculo, especialmente pensado para aplicaciones de
ingeniería o científicas, operados por un único usuario desde la consola (pantalla y teclado
conectado directamente al equipo), siendo muy poco usual que se las conectara a terminales
seriales a ser utilizadas por otros usuarios, a pesar de que el sistema operativo soportaba esta
modalidad de trabajo.
2Si bien el pasar de equipos centralizados compartidos a equipos personales individuales
trajo como beneficio un mayor poder de procesamiento y flexibilidad para los usuarios, se
llevó consigo una de las ventajas de la computación centralizada: la posibilidad de compartir
recursos. Es por ello que la década del 80 no sólo es la década de la computación personal,
sino también la de la popularización y crecimiento de las redes de área local (denominadas
LAN). La idea de interconectar equipos en redes no era nueva; sin embargo, los esfuerzos de
investigación y desarrollo en tal sentido se orientaban mas bien a la interconexión de
equipos ubicados en locaciones distantes entre sí, formando redes de área amplia
(conocidas como WAN), ya que el "área local" estaba dominada por equipos de conexión
centralizada. En el caso particular de Unix, la técnica de interconexión que se volvió
standard fue la basada en una familia de protocolos de comunicaciones denominada TCP/IP,
mediante la cual dos equipos Unix interconectados podían intercambiar datos y permitir a
usuarios conectados a uno de ellos iniciar nuevas sesiones de trabajo en el otro.
Cuando las workstations aparecieron en la escena a mediados de la década del 803, resultó
natural que estuvieran preparadas con capacidades de conectividad
en red. No obstante, el tipo de conectividad requerida no era a nivel
WAN sino a nivel LAN, a fin de que pudieran interactuar con otras
workstations y con equipos centralizados de mayor porte disponibles
en la organización. Se volvió entonces practica standard entre los
fabricantes de workstations que las mismas contaran con capacidad
de conectividad TCP/IP y hardware para conexión a una red LAN,
utilizando la norma Ethernet, que finalmente terminó por convertirse
en el standard para redes de estas características. De ésta manera, un
usuario poseedor de una workstation podría ejecutar localmente sus
aplicaciones y al mismo tiempo iniciar sesiones de trabajo remotas
Figura 3:
en los servidores corporativos (y, por supuesto, en otras
4 Workstation Sun
workstations disponibles en la red ).
Al mismo tiempo, las PCs fueron ganando terreno en el ámbito de las redes LAN (y, de
hecho, resultaron finalmente sus principales impulsores). Sin embargo, no fue hasta
mediados de los 90 con la masificación del acceso a servicios Internet (la red TCP/IP por
excelencia) que TCP/IP se volvió un componente obligado del software de red de éstas
computadoras, desplazando a otros protocolos como IPX y NetBIOS, que dominaron la
escena de las LAN entre PCs durante años. Como resultado, hoy puede utilizarse una PC de
bajo costo para acceder a servicios de datos y sesión remota sobre servidores Unix, de
manera análoga a la que se utilizaría desde una workstation.
El Sistema X-Window
Cabe mencionar finalmente otro tipo de conexión a sistemas Unix, para el cual hay que
analizar previamente el formato con que esas conexiones pueden realizarse.
Tradicionalmente, las terminales bobas fueron
dispositivos "de caracteres", que permitían
conexiones en modo texto. Las primeras terminales
eran extremadamente primitivas; denominadas "ttys
de vidrio", básicamente eran variaciones de los
teletipos (de allí la denominación "tty") y únicamente
permitían desplegar líneas de caracteres y producir
avances de carro, sin que el programador tuviera
Figura 4: Terminal "de copia dura"
o teletipo control alguno sobre el formateo y ubicación de
dichos caracteres en la pantalla. Con el tiempo, fueron
evolucionando hasta eliminar esas limitaciones (se
transformaron en terminales "de pantalla completa") y agregaron nuevas capacidades como
3
La primera workstation fue lanzada al mercado por Sun Microsystems en 1983.
4
Esta concepción del trabajo en red llevó a Sun a acuñar el slogan "The network is the
computer" ("La computadora es la Red").
3diferentes estilos (caracteres parpadeantes, remarcados, subrayados, etc.), diferentes juegos
de caracteres, caracteres gráficos, etc. Pero continuaron siendo terminales capaces de
mostrar solamente texto.
Mientras esto ocurría en el ámbito comercial, el MIT (Instituto de Tecnología de
Massachusetts) se encontraba trabajando en el Proyecto Athena. Uno de los resultados de
ese proyecto fue un "sistema de presentación gráfica distribuida". La idea consistía en
permitirle a un programa, llamado cliente, ejecutarse en una computadora y enviar su salida
(ya fuera esta texto o gráficos) por medio de enlaces TCP/IP a otro programa, llamado
servidor de ventanas (window server), en ejecución en la misma u otra computadora. Las
computadoras del cliente y el servidor podrían ser inclusive totalmente diferentes (en
hardware y/o sistema operativo), en tanto y en cuanto ambas estuvieran interconectadas de
alguna manera por TCP/IP e implementaran un protocolo especial denominado protocolo X.
El conjunto resultante se denominó Sistema X-Window, en el cual la funcionalidad de la
aplicación se divide entre el Server-X (o servidor de ventanas) que tiene a cargo la
administración de los recursos físicos de presentación (es decir, manipula los recursos del
hardware de visualización, las entradas por teclado y los eventos del mouse) al cual se
conectan múltiples Clientes-X (es decir, las aplicaciones que el usuario ejecuta sobre el
equipo central), vinculadas las mismas al Server-X por medio de enlaces TCP/IP.
Una de las aplicaciones de X-Window fue permitir la creación de un nuevo tipo de
terminales, conocidas como X-Terminals. Una X-Terminal es básicamente una terminal
boba en el sentido de que no procesa localmente las aplicaciones
del usuario, pero la principal diferencia es que le ofrecen una
interfaz gráfica altamente sofisticada. Para ello, una X-Terminal
implementa el protocolo X y cuenta con un window server.
Cuando el usuario, por medio de una X-Terminal, lanza una
aplicación, la misma se ejecuta en el host, excepto las operaciones
de dibujo sobre la pantalla y la captura de eventos de teclado y
mouse, que son ejecutadas por el Server-X localmente en la X-
Terminal. En otras palabras, cuando el Cliente-X requiere Figura 5: Terminal
desplegar algún tipo de información por pantalla, le envía una X de Tektronics
petición al Server-X para que la lleve a cabo; de la misma manera,
no es la aplicación la que realiza la lectura de teclado y la captura de eventos del mouse,
sino que dicha operación la realiza en Server-X (sobre la X-Terminal) para luego notificar al
Cliente-X (en el host) cuando los eventos eventualmente ocurren. Todo ese diálogo entre el
Cliente-X y el Server-X se materializa en forma de mensajes TCP/IP.
Por otra parte, X-Window se volvió un componente infaltable de las workstations. X-
Window es un sistema de ventanas cliente/servidor. Una de las ventajas del modelo
cliente/servidor es que puede ser implementado tanto de manera distribuida (es decir, cliente
y servidor ejecutándose en computadoras diferentes) como local (cliente y servidor
ejecutándose en la misma computadora), debido a que lo único que establece es que deben
existir dos procesos (el cliente y el servidor) unidos a través de un canal de comunicaciones.
Para el caso de X-Window, esto significa que tanto el Server-X como el Cliente-X podrían
eventualmente ejecutarse en la misma computadora, tal como ocurre en una workstation.
Finalmente, y dado que ya en el espíritu inicial de los diseñadores de X-Window estaba
embebido el concepto de independencia de plataforma entre el Cliente-X y el Server-X,
resultó natural la eventual aparición de Servidores-X para plataformas completamente
diferentes de Unix, tal como MS-Windows. Ello posibilitó utilizar una máquina Windows
como si fuera una X-Terminal, una estrategia análoga a la utilizada anteriormente por medio
de emuladores de terminal.
4En resumen...
Se han reseñado varias formas para conectarse a un host Unix:
• Por medio de una terminal boba conectada al host a través de un vínculo
serial (directo o indirecto -- como por ejemplo, un módem);
• Por medio de una PC, un programa emulador de terminal y un vínculo
serial al host (nuevamente, directo ó indirecto);
• Por medio de conexiones TCP/IP a través de una red LAN o WAN, desde
otro host Unix, una workstation, una PC o cualquier otro tipo de
computadora que cuente con software TCP/IP.
• Desde una X-Terminal o una computadora (PC, workstation, etc.) que
implemente el protocolo X5.
5
Este tipo de conexión es estrictamente otra forma de conexión TCP/IP. Se la menciona por
separado debido a que su formato es radicalmente diferente al de las conexiones TCP/IP
mas conocidas (como por ejemplo, conexiones vía telnet).
5Trabajando en una red Unix
Se discutirán a continuación algunas de las actividades más usuales que se realizan al
trabajar en el entorno de una red TCP/IP bajo Unix:
• Sesiones remotas
• Transferencia de archivos
• Ejecución remota
• Comunicación entre usuarios
A los fines de la ejemplificación, se asumirá que el entorno en el que está trabajando un
usuario cuyo login name es jperez es el que se muestra en la figura siguiente, y que
dicho usuario está actualmente conectado al host Antares, y que dispone de acceso a cuentas
de usuario en el host Canopus, ambos corriendo alguna versión de Unix:
Canopus
Red Local
Antares
Sesiones remotas
Iniciar una sesión remota significa conectarse desde una computadora a otra, a través de una
red de comunicaciones, a los fines de ejecutar procesos a la distancia. En otras palabras, por
medio de sesiones remotas es posible trabajar en una computadora operándola remotamente
desde otra, ubicada quizás a grandes distancias; a los fines prácticos, resulta equivalente a
estar sentado en la consola del sistema remoto.
En nuestro ejemplo, si el usuario jperez que se encuentra conectado a la computadora
Antares inicia una sesión remota en Canopus, a partir de ese momento todo comando que
ejecute lo hará en el procesador de Canopus.
Cabe aclarar que el acceso a un host Unix desde una terminal serial no se considera una
sesión remota, por mas lejana que se encuentre físicamente ubicada la terminal. Las sesiones
remotas entre sistemas Unix se realizan por medio de la ejecución de programas basados en
TCP/IP, como los descriptos en las secciones siguientes.
Arquitectura de una sesión remota
Los programas de sesión remota bajo Unix trabajan según un esquema cliente/servidor, en
el cual el usuario que desea iniciarla ejecuta localmente en su computadora un programa (el
cliente) al cual le indica el nombre del host en el cual se iniciará la sesión. Dicho programa
se comunica por medio de TCP/IP con otro ejecutándose en background en la computadora
de destino (el servidor), el cual, luego de autenticar la identidad del usuario y verificar que
tiene permiso para utilizar el servicio, inicia un shell para interpretar los comandos que
envíe el usuario remoto:
6Shell local
Cliente de sesión Servidor de sesión
remota remota
Shell remoto
El servidor de sesión remota asocia el shell remoto con una terminal virtual (o pseudo-tty)
cuyas entradas y salidas están asociadas a una conexión de red. Así, todo lo que el usuario
teclee en su terminal será capturado por el cliente de sesión remota y enviado a través de la
red al shell remoto; de manera similar el shell remoto enviará la salida de los comandos al
usuario por la misma conexión de red. Cuando el usuario ejecute el comando para terminar
el shell (usualmente, exit o Control-D), el shell remoto finaliza y la sesión remota se
cierra.
Sesiones remotas utilizando rlogin
rlogin es el comando de sesión remota nativo de Unix. Su sintaxis básica es la siguiente:
rlogin nombre_de_host
Al ser invocado de esa forma, rlogin intenta iniciar una sesión remota en el host indicado,
bajo el mismo nombre de usuario actual, previo ingreso de la palabra clave:
jperez@antares:$ rlogin canopus
Password:
Last login: Mon Feb 10 15:30:45 from orion.
jperez@canopus:$ _
Si la clave es ingresada correctamente, la sesión remota se inicia, rlogin informa la fecha y
origen del último ingreso al sistema y, a partir de ese momento, el usuario puede ejecutar
comandos en la máquina remota, obteniendo la salida de los mismos en el host local. Para
cerrar la sesión, basta con ingresar el comando normal para finalizar el shell remoto, por
ejemplo, exit:
jperez@canopus:$ exit
Conection closed.
jperez@antares:$ _
Si se desea iniciar una sesión remota bajo otra identidad (es decir, entrado como otro
usuario), el login name correspondiente puede indicarse utilizando el comando -l:
jperez@antares$ rlogin -l plopez canopus
Password:
plopez@canopus$ _
Como ya se dijo, rlogin pide la contraseña de la cuenta remota antes de permitir el acceso al
shell. Sin embargo, es posible configurar rlogin de manera que considere equivalentes dos
cuentas y no pida password para iniciar sesiones. Continuando con el ejemplo anterior, si el
usuario jperez tiene cuenta tanto en Antares como en Canopus, para evitar que se le pida
password al iniciar una sesión remota con rlogin deberá crear en su directorio de login de la
máquina remota un archivo llamado .rhosts, y en el mismo listar los nombres de las
7computadoras desde donde desea entrar sin password. También podría otorgar acceso libre a
otros usuarios, listando los nombres de login a continuación del nombre de máquina.
Por ejemplo, si el archivo .rhosts ubicado en el directorio de conexión de jperez en
Canopus contuviera la siguiente información:
antares
orion plopez
ello indicaría que el usuario jperez puede entrar a Canopus sin password desde Antares,
mientras que el usuario plopez podrá hacer lo mismo desde Orión.
Cabe destacar que el uso del archivo .rhosts es un serio compromiso a la seguridad de la
cuenta y es un recurso que debe ser utilizado con mucha precaución; en el ejemplo anterior,
si alguien ganara acceso a la cuenta de jperez en Antares, automáticamente podría entrar
a la cuenta de Canopus. Como medida extra de seguridad, rlogin solo prestará atención al
archivo .rhosts si el mismo solo puede ser accedido por el usuario (es decir, si su modo es
rw------- ó 600 en octal).
Sesiones remotas utilizando telnet
El comando rlogin fue diseñado teniendo en cuenta que tanto el host local como el remoto
son máquinas corriendo Unix6. A fin de permitir sesiones remotas entre equipos con
sistemas heterogéneos, fue diseñado otro protocolo denominado TELNET.
Bajo Unix, puede establecerse una conexión TELNET con el siguiente comando:
telnet nombre_de_host
La principal diferencia entre telnet y rlogin es que el primero de estos siempre pide usuario
y password para iniciar la sesión:
jperez@antares:$ telnet canopus
Trying 170.25.1.5
Connected to canopus.galaxia.org.ar
Escape character is '^]'
Login: jperez
Password:
Last login: Mon Feb 10 15:30:45 from orion.
jperez@canopus:$ _
Aquí puede verse que el usuario jperez inicia una sesión de TELNET hacia Canopus.
telnet inicialmente informa que está intentando establecer la conexión con el host remoto
(línea Trying....) y luego de unos segundos indicará que la conexión se ha establecido
con éxito (línea Connected.....). Seguidamente, telnet informa al usuario cual es el
carácter de escape, y pide el nombre de usuario y palabra clave para ingresar al host remoto.
El carácter de escape (que usualmente es Control-]) es un carácter que es interceptado por el
programa telnet ejecutándose en el host local, y no es enviado al host remoto como el resto
de los caracteres tipeados por el usuario. Se utiliza para llamar la atención del programa
telnet, el cual responde con un prompt y queda a la espera de comandos:
jperez@canopus:$ ^-]
telnet> _
6
Estrictamente, rlogin asume que ambos extremos de la conexión de red ejecutan el
demonio identd, que permite identificar el propietario de conexiones TCP.
8Existen varios comandos que pueden utilizarse aquí, pero el mas usual es el comando exit,
utilizado para cortar la conexión, o ! (signo de admiración) que permite iniciar un subshell
en el host local.
Sesiones remotas utilizando ssh
Tanto telnet como rlogin utilizan protocolos de comunicación abiertos, en el sentido de que
todos los datos se transmiten sin ningún tipo de protección por encriptado. Esto significa que
cualquier otra persona que tenga acceso al medio físico de transmisión podría (con los
conocimientos y herramientas apropiadas) interceptar las transmisiones y eventualmente
obtener todo aquello que el usuario tipea en su terminal (especialmente, el nombre de
usuario y la password) y las respuestas que envía el host remoto.
Esto hace que el uso de telnet o rlogin sea inapropiado cuando es necesario un nivel de
absoluta seguridad y privacía, especialmente cuando las comunicaciones se realizan a través
de largas distancias (por ejemplo, a través de la Internet).
Para superar esos inconvenientes, puede utilizarse como alternativa el sistema ssh (por
Secure Shell, o Shell Seguro), el cual provee de un esquema de seguridad mucho mas
sofisticado y encripta toda el intercambio de datos entre el host local y el remoto.
La sintaxis básica7 de ssh es igual a la de rlogin, es decir:
ssh [-l nombre_de_usuario] nombre_de_host
en donde la indicación del nombre de usuario (a través del parámetro -l) es opcional y se
asume el login name actual por defecto.
Transferencia de archivos
Los protocolos para transferencia de archivos permiten copiar archivos entre dos
computadoras, a través de una red. Se verán a continuación tres programas para
transferencia de archivos: ftp, rcp y scp.
Transferencia de archivos por ftp
La principal diferencia entre ftp y los otros comandos radica en el carácter interactivo de
éste comando. Esto significa que ftp funciona a la manera de un shell: primeramente
establece la conexión con el sistema remoto y luego queda a la espera de que el usuario le
indique, por medio de un lenguaje de comandos, las operaciones a realizar.
Para iniciar una sesión FTP, debe ejecutarse en comando ftp indicándole como parámetro el
nombre de la computadora remota, por ejemplo:
jperez@antares:$ ftp canopus
Connected to canopus.galaxia.org.ar
220 canopus.galaxia.org.ar FTP server ready.
Name(antares:jperez): jperez
331 Password required for jperez.
Password:
230 User andres jperez in.
Remote system type is UNIX.
Using binary mode to transfer files.
7
Ssh ofrece sofisticados mecanismos de seguridad adicionales al tradicional esquema de
seguridad basado en palabra clave, como frases clave de acceso, certificados de identidad y
varios métodos de autenticación. Para mayores detalles, refiérase a la documentación
provista por el software.
9ftp> _
Aquí, el usuario jperez inicia una conexión FTP a Canopus. Luego de indicar que la
conexión se ha establecido y que el servidor FTP se encuentra listo, ftp pide el nombre de
usuario con el que se va a ingresar al host remoto, y luego su correspondiente password. Si
la misma se ingresa correctamente, el sistema remoto informa su tipo (en este caso, UNIX) y
el modo de transferencia de archivos por defecto (en este caso, transferencia binaria) y
queda a la espera de comandos del usuario.
Adicionalmente de permitir la transferencia de archivos hacia cuentas del sistema remoto
(esto es, la conexión se establece indicando una identidad de usuario registrada en el host
remoto e ingresando la palabra clave de esa cuenta), ftp fue diseñado para permitir el acceso
de usuarios anónimos a grandes repositorios de archivos, de acceso público. Usualmente los
servidores FTP utilizan el nombre de usuario anonynmous para los accesos del público en
general, quienes deberán utilizar su dirección de correo electrónico como password:
jperez@antares:$ ftp canopus
Connected to canopus.galaxia.org.ar
220 canopus.galaxia.org.ar FTP server ready.
Name(antares:jperez): anonymous
331 Guest login ok, send your complete e-mail address as
password.
Password:
jperez@canopus.galaxia.org.ar
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> _
Los dos comandos básicos de FTP para transferencia de archivos son put (para enviar un
archivo al host remoto) y get (para obtener un archivo desde el host remoto). Ambos
operan con un único archivo indicado como parámetro, desde y hacia el directorio actual
(tanto local como remoto). Por ejemplo, el siguiente comando:
ftp> put informe.doc
local: informe.doc remote: informe.doc
200 PORT command successful.
150 Opening BINARY mode data connection for informe.doc.
226 Transfer complete.
1908642 bytes sent in 2.34 secs (13.22 Kbytes/sec)
ftp> _
transfiere el archivo informe.doc desde el directorio actual local (esto es, el directorio
desde el cual se invocó al programa ftp en el host local) al directorio actual en la
computadora remota. Luego de la transferencia, ftp informa la cantidad de bytes
transmitidos y la velocidad de la transferencia.
Por otra parte, el comando:
ftp> get informe.doc
local: informe.doc remote: informe.doc
200 PORT command successful.
150 Opening BINARY mode data connection for informe.doc.
226 Transfer complete.
1908642 bytes received in 2.34 secs (13.22 Kbytes/sec)
ftp> _
10El directorio actual en la computadora remota puede averiguarse por medio del comando
pwd:
ftp> pwd
257 "/home/jperez" is current directory.
ftp> _
y puede cambiarse utilizando el comando cd, e indicando una trayectoria absoluta o relativa
(de manera totalmente análoga al comando cd del shell):
ftp> cd documentos
250 CWD command successful.
ftp> pwd
257 "/home/jperez/documentos" is current directory.
ftp> _
FTP cuenta con un extenso juego de comandos, cuya lista puede obtenerse tipeando ?. Se
ofrece a continuación un resumen de algunos comandos de utilización frecuente:
ls Lista el contenido del directorio actual
binary Fuerza el modo de transferencia a BINARIO
ascii Fuerza el modo de transferencia a ASCII (poco recomendable!)
lcd Cambia (o muestra) el directorio actual local
delete Borra un archivo en el host remoto
hash Muestra por pantalla una marca cada cierta cantidad de bytes
transmitidos
mput Permiten realizar transferencias múltiples, por medio de la
mget utilización de comodines
prompt off Deshabilita la confirmación archivo por archivo en las
transferencias múltiples
La sesión de FTP finaliza cuando el usuario indica el comando bye:
ftp> bye
221 Goodbye.
jperez@antares:$ _
Transferencia de archivos por rcp y scp
Los comandos rcp y scp son utilerías de línea de comandos para transmitir archivos; esto es,
no reciben comandos interactivamente desde el usuario, sino que su funcionamiento se
indica por medio de parámetros en la línea de comandos del shell. Es esta característica lo
que, al contrario que ftp, los hace útiles para la programación de scripts que realicen
transferencias automáticas de archivos entre computadoras.
rcp pertenece al mismo paquete de comandos que rlogin, mientras que scp pertenece al de
ssh. Así la diferencia entre ambos radica en el nivel de seguridad: rcp transfiere los archivos
en su formato original, mientras que scp lo hace de manera encriptada.
Ambos comandos tienen la misma sintaxis:
rcp [-l nombre_de_usuario] origen destino
scp [-l nombre_de_usuario] origen destino
en donde el parámetro -l es opcional, sirviendo para acceder al host remoto bajo otro
nombre de usuario. Los parámetros origen y destino son las especificaciones
11(expresadas como trayectorias absolutas o relativas) del archivo a transmitir y la ubicación
final del mismo respectivamente; uno de ellos deberá hacer referencia a la computadora
local, mientras que el otro deberá referirse a la computadora remota. La sintaxis para
archivos remotos es la siguiente:
nombre_del_host_remoto:[[trayectoria]archivo]
Como puede verse, la única parte mandatoria es el nombre del host remoto; si el resto se
omite, el archivo transmitido será copiado bajo el mismo nombre en el directorio de login
del usuario en la computadora remota. Si el nombre de archivo se omite, la copia se hará en
el directorio remoto indicado bajo el mismo nombre; si la trayectoria especificada es
relativa, se interpretará como relativa al directorio de login del usuario en la computadora
remota.
Por ejemplo, los siguientes comandos transfieren archivos de la maquina local al host
remoto Canopus:
$ scp informe.doc canopus:
Copia el archivo informe.doc (ubicado en el directorio actual) al
directorio de login en Canopus, con el mismo nombre
$ rcp notas/informe.doc canopus:notas/
Copia el archivo informe.doc, bajo el directorio notas al directorio
notas bajo el directorio de login de la maquina remota
$ scp informe.doc canopus:/usr/informes/info1.doc
Copia el archivo informe.doc, al directorio remoto /usr/informes
con el nombre info1.doc
Para transferir desde el host remoto al host local, los comandos serían los siguientes:
$ rcp canopus:informe.doc .
$ rcp canopus:notas/informe.doc notas/
$ scp canopus:/usr/informe.doc info1.doc
scp siempre pide password antes de realizar la copia; rcp, por su parte, requiere que el
usuario haya configurado su cuenta remota para accederla sin solicitar password, por medio
del archivo .rhosts (tal como se describe en la sección de rlogin)
Ejecución remota
Los comandos para ejecución remota permiten ejecutar un único comando en un host
remoto, obteniendo su salida en el host local.
El comando tradicionalmente utilizado para este tipo de operaciones era rsh. Este comando
completa la familia formada por rlogin y rcp, y al igual que este último, requiere de la
existencia del archivo .rhosts en el directorio de conexión remoto a fin de poder operar. Su
sintaxis es la siguiente:
rsh [-l nombre_de_usuario] host comando
Por ejemplo, el siguiente comando obtiene un listado del directorio de conexión de un host
remoto:
jperez@bbs:~$ rsh canopus ls -l
total 13
drwxr-xr-x 5 jperez jperez 1024 Sep 26 11:58 GNUstep
-rw-rw-r-- 1 jperez jperez 1376 Sep 28 15:16 Xrootenv.0
drwxrwxr-x 2 jperez jperez 1024 Oct 13 16:53 bin
drwxrwxr-x 3 jperez jperez 1024 Oct 29 19:48 download
drwx------ 2 jperez jperez 1024 Sep 23 12:21 mail
12drwxrwxr-x 2 jperez jperez 1024 Jul 2 14:34 mnt
drwxr-xr-x 3 jperez jperez 1024 Jun 30 19:36 ns_imap
-rw-r--r-- 1 jperez jperez 198762 Nov 1 20:46 informe.doc
drwxrwxr-x 6 jperez jperez 1024 Oct 22 21:38 temp
drwxrwxr-x 9 jperez jperez 1024 Oct 29 19:49 trabajo
jperez@bbs:~$ _
Se aplican a este comando las mismas consideraciones de seguridad que se discutieron para
rlogin, por lo que si la seguridad es crítica, puede ser reemplazado por el comando ssh, que
ofrece un modo de funcionamiento similar:
ssh [-l nombre_de_usuario] host comando
con la diferencia que utiliza mecanismos de seguridad avanzada para autenticar al usuario y
realiza conexiones encriptadas.
Comunicación entre usuarios
Unix es un sistema de naturaleza multiusuaria, es decir, soporta múltiples usuarios
conectados simultáneamente, ejecutando procesos concurrentemente. En consecuencia,
ofrece comandos que permiten a los usuarios comunicarse entre si, ya sea en tiempo real o
de manera diferida.
Averiguando quien está conectado: finger
Antes de poder entablar una comunicación, es necesario saber quién está conectado al
sistema. Normalmente, el comando para realizar dicha operación era who. Sin embargo, este
comando solo informa acerca de los usuarios conectados al sistema local. Si se desea saber
quién está conectado a un host remoto debe utilizarse el comando finger:
jperez@antares:$ finger @canopus
[canopus.galaxia.org.ar]
Login Name Tty Idle Login Time
plopez Pedro Lopez 1 Feb 1 20:36
fcuenca Fernando Cuenca p1 20m Feb 1 14:08
arodrig Andrea Rodriguez p2 20m Feb 1 20:36
jperez@antares:$
Observar que el nombre del host remoto debe precederse de un signo @. De manera similar,
finger permite obtener información sobre un usuario (local o remoto). Por ejemplo, si se
quieren conocer los datos del usuario plopez del host local, puede utilizarse el siguiente
comando:
jperez@bbs:~$ finger plopez
Login: plopez Name: Pedro Lopez
Directory: /home/plopez Shell: /bin/sh
Last login Fri Oct 30 23:16 (ARDT) on tty1
New mail received Sun Nov 1 19:08 1998 (ARDT)
Unread since Sun Nov 1 17:45 1998 (ARDT)
finger informa el nombre completo del usuario, su directorio de login y shell, la fecha y
ubicación de la última conexión al sistema, e información sobre el correo electrónico del
usuario.
También pueden obtenerse datos de usuarios de otras computadoras, utilizando la sintaxis
usuario@computadora:
jperez@bbs:~$ finger arodrig@canopus
Login: arodrig Name: Andrea Rodriguez
Directory: /home/arodrig Shell: /bin/sh
13Last login Sun Feb 10 15:09 (ARDT) on tty5
New mail received Mon Nov 1 14:33 1998 (ARDT)
Unread since Tue Jan 24 11:14 1998 (ARDT)
Comunicándose con talk
Unix permite realizar charlas en tiempo real con usuarios conectados al sistema local o a
sistemas remotos, por medio del comando talk.
Por ejemplo, si el usuario jperez, conectado a Antares, quisiera entablar una charla con
arodrig, conectada a Canopus, debería ejecutar el siguiente comando:
talk arodrig@canopus
arodrig recibirá un aviso en su pantalla y, si desea entablar la comunicación, deberá replicar
con el siguiente comando:
talk jperez@antares
tras lo cual la conexión quedará establecida. Ambos verán en sus pantallas lo que el otro
escribe, hasta que alguno de ellos finalice la sesión con Control-C.
Correo electrónico
Talk permite comunicaciones en tiempo real; sin embargo, muchas veces es necesario
enviar un mensaje a un usuario que no se encuentra actualmente conectado. Para ello puede
utilizarse el correo electrónico.
El comando standard para enviar correo electrónico entre sistemas Unix es mail, cuya
sintaxis es la siguiente:
mail usuario[@computadora]
Obsérvese que la especificación del nombre de la computadora es opcional; si se omite, se
asumirá que se está enviando correo a otro usuario del sistema local.
Al ser ejecutado, el comando mail solicita primeramente al usuario que ingrese el tema del
mensaje, y luego lee desde la entrada standard el texto del mensaje, hasta recibir la marca de
fin de archivo (Control-D):
jperez@antares:$ mail plopez@canopus
Subject: Reunion semanal
Hola,
Le comunico que la reunión semanal tendrá lugar el
próximo miércoles a las 15 el la Sala de Reuniones D.
Por favor, concurra con el informe de avance.
^D
jperez@antares:$ _
Un problema frecuente al trabajar en una red Unix, es que los usuarios normalmente tienen
cuenta en mas de un host. Ello puede provocar que su correspondencia se vea diseminada
entre sus múltiples casillas de correo (una en cada host en los que se tiene cuenta). Para
solucionar esta situación, es posible redirigir el correo desde múltiples cuentas hacia aquella
que se usa mas frecuentemente.
Para redirigir el correo de una cuenta dada, el usuario deberá crear en el directorio de
conexión correspondiente el archivo .forward, conteniendo la dirección de correo
electrónico hacia la cual desea que los mensajes sean redirigidos. Por ejemplo, si jperez
tiene cuenta tanto en Antares como en Canopus, pero prefiere leer correo en la primera,
14deberá crear un archivo .forward en su directorio de login de Canopus, conteniendo la
siguiente línea:
jperez@antares
15Administración de una red TCP/IP
TCP/IP: una familia de protocolos
TCP/IP es un conjunto de protocolos de comunicaciones desarrollado para permitir a un
conjunto de computadoras cooperar y compartir recursos a través de una red de
comunicaciones. De entre sus muchas características, hay dos que lo han transformado en
uno de los protocolos de mayor difusión:
• Es un standard abierto, diseñado independientemente de plataformas de hardware y
software específicas. Así, TCP/IP es ideal para interconectar sistemas mas allá de lo
diferentes que éstos sean.
• Es independiente de la tecnología física que se utilice para construir la infraestructura de
la red. TCP/IP puede montarse sobre Ethernet, Token-Ring, enlaces seriales telefónicos
(dial-up links), redes X.25, y virtualmente cualquier otro medio físico de transmisión de
datos.
Arquitectura de TCP/IP8
La familia TCP/IP está formada por múltiples protocolos de diferentes propósitos. Algunos
de ellos, tales como IP, TCP y UDP constituyen el mecanismo básico de transmisión de
datos, y serán utilizados por todas las aplicaciones. Otros protocolos permiten realizar tareas
mucho más específicas, tales como transferir archivos entre computadoras (FTP), obtener
páginas o documentos de la Web (HTTP), o sincronizar la hora desde otro equipo (XNTP).
Cualquier aplicación real utilizará varios de esos protocolos. Un caso típico es el envío de
correo electrónico. En primer lugar, existe un protocolo para enviar y recibir correo
electrónico (denominado SMTP), que define una serie de comandos que una máquina envía
a la otra cuando requiere transferirle un mensaje. Esos comandos permiten especificar quien
es el autor del mensaje, a quien va dirigido y cual es el texto a enviar. Sin embargo, ese
protocolo (como todos los otros protocolos de aplicación) asume que hay alguna manera
confiable para comunicar datos entre ambas computadoras, limitándose simplemente a
definir a muy alto nivel los comandos necesarios para manejar la transmisión, pero no los
detalles acerca de como va a efectivizarse la misma. Dichos detalles son dejados en manos
de alguno de los protocolos de menor nivel, llamados protocolo de transporte: TCP o UDP.
SMTP utiliza a TCP como protocolo de transporte. TCP es responsable de asegurar que los
comandos trasmitidos lleguen al otro extremo de la comunicación, contabilizando qué ha
sido transmitido ya y retransmitiendo toda información que no haya llegado exitosamente a
destino. Si la información a transmitir es demasiado larga, TCP la segmentará en varios
paquetes que se transmitirán individualmente.
Obsérvese que esta funcionalidad se requiere para muchas aplicaciones; es por ello que
conforma un protocolo independiente en vez de formar parte de la especificación de
protocolos como SMTP. Desde el punto de vista del programador, TCP es una libraría de
rutinas que las aplicaciones utilizan cuando necesitan comunicaciones confiables con otra
computadora a través de la red.
De manera similar, TCP utiliza los servicios de IP para efectivamente desplazar los paquetes
alrededor de la red. IP constituye un protocolo de red, y es el encargado de determinar que
rutas deberán seguir los paquetes para llegar al punto de destino desde el punto de origen.
8
Adaptado principalmente de un articulo de Charles Hedrick (Rutgers Univ., New
Brunswick, N.J.) publicado en los newsgroups de Internet el 28 de Junio de 1987, y de otras
fuentes mencionadas en la Bibliografía.
16Nuevamente, IP se presenta como una librería que utilizan protocolos de transporte como
TCP al momento de enviar la información.
Esta estrategia para construir protocolos en varios niveles se denomina diseño estratificado
(o layering). Consiste en considerar a las aplicaciones, a TCP y a IP como diferentes capas,
cada una de las cuales hace uso de los servicios ofrecidos por la capa inmediatamente
inferior. En general, la arquitectura de las aplicaciones basadas en TCP/IP presentan 4
capas:
• Un protocolo de aplicación, para tareas específicas (por ejemplo, correo electrónico)
• Un protocolo de transporte, que provee servicios de extremo a extremo (como TCP o
UDP)
• El protocolo de red IP, que provee el encaminamiento de los paquetes a su destino final
• Un protocolo de enlace físico, que provee acceso al medio físico de transmisión (por
ejemplo, Ethernet o X.25)
Transmitiendo los paquetes
A fin de ejemplificar el proceso completo, supongamos que se desea transmitir un archivo
de 15000 bytes. El protocolo de aplicación especializado en transferencia de archivos
proporciona al protocolo de transporte el contenido del archivo a transmitir. La mayoría de
las redes no pueden manejar paquetes de 15000 bytes, por lo que el archivo será segmentado
en, digamos, 30 paquetes de 500 bytes cada uno, que entrega al protocolo de red para que
sean enviados individualmente al otro extremo de la comunicación. Allí, los paquetes se
reunirán para reensamblar el archivo original. Sin embargo, mientras los paquetes estén en
tránsito, la red no sabrá que existe algún tipo de relación entre ellos9. Es también posible que
el paquete número 15 llegue antes que el 14, o que algunos paquetes se pierdan en el camino
y deban ser retransmitidos. Todas estas tareas (segmentación, retransmisión y reensamblaje)
son llevadas a cabo por TCP (abreviatura de Transmission Control Protocol, o Protocolo de
Control de Transmisión), mientras que el ruteo de paquetes individuales es responsabilidad
de IP (abreviatura de Internet Protocol, o Protocolo de Inter-redes). A simple vista podría
parecer que TCP es quien hace todo el trabajo, sin embargo, el rutear un paquete desde el
origen hacia su destino puede ser una tarea muy compleja.
TCP/IP asume que la red está formada por un gran numero de redes independientes,
interconectadas entre si por dispositivos denominados gateways10, proporcionando al
usuario la capacidad para acceder a recursos ubicados en cualquiera de esas redes,
independientemente de su dispersión geográfica11. Los paquetes frecuentemente atravesarán
numerosas redes para llegar a su destino, pero el ruteo requerido para ello deberá ser
totalmente invisible para el usuario final. Todo lo que el usuario debe conocer es la
dirección IP del punto de destino, un número que identifica unívocamente a cada
computadora dentro de la inter-red.
Así, TCP entrega los paquetes a IP especificándole simplemente la dirección IP de destino
hacia donde debe enviarlos. Queda en manos de IP determinar la mejor ruta para que la
entrega se haga efectiva. Dicha ruta (continuando con el ejemplo anterior, y en el contexto
9
Más aún, la red ni siquiera sabe que los paquetes conforman un archivo.
10
En la jerga TCP/IP se denomina gateways a dispositivos que están conectados a mas de
una red, y ofrecen capacidad para rutear paquetes entre esas redes. Es decir, se trata de
ruteadores (dispositivos de nivel OSI 3) y no estrictamente de gateways (dispositivos de
nivel OSI superiores, capaces de hacer transformaciones de protocolos, formatos,
codificaciones, etc.)
11
De hecho, el término internet (con i minúscula) proviene de internetwork y se refiere a un
conjunto de redes interconectadas. No debe confundirse con Internet (con I mayúscula), que
se refiere a la red de redes de alcance global.
17de la estructura de la red de la UTN Facultad Córdoba), podría implicar que cada paquete
tenga que atravesar varios segmentos de LAN Ethernet dentro de la UTN FC, un enlace de
microondas hasta el nodo de conexión a Internet, otro hasta algún telepuerto en Buenos
Aires desde donde se establece una conexión satelital hacia los EEUU, y así sucesivamente
hasta llegar a la red de destino, en donde deberá ser ruteado internamente hasta la
computadora de destino.
Finalmente, para transmitir cada paquete, IP utiliza el protocolo de enlace físico que conoce
las particularidades para acceder al medio físico de transmisión (por ejemplo, una placa de
red Ethernet).
Multiplexación: Puertos y Sockets
En los párrafos anteriores se ha descripto el proceso para transferir información a lo largo de
una conexión TCP/IP. Sin embargo, en un momento dado podrían existir, entre las
computadoras de origen y destino, múltiples conexiones ocurriendo simultáneamente;
pensemos, por ejemplo, en varios usuarios abriendo sesiones remotas o transfiriendo
simultáneamente archivos o correo electrónico entre dos máquinas de la red.
Claramente, no es suficiente lograr que los paquetes lleguen al destino correcto; es necesario
además poder discriminar a cual conexión pertenecen de las múltiples conexiones
simultáneas que pueden existir en un momento dado.
Para identificar cada conexión, TCP asigna un número de puerto a cada una. Supongamos
que tres personas están transfiriendo archivos entre dos computadoras. TCP asignaría un
número de puerto a cada transferencia, por ejemplo, 1000, 1001 y 1002. Todos los paquetes
que se envíen como parte de una misma conexión tendrán asignado ese número como puerto
de origen. El número de puerto de origen permite también establecer una correspondencia
directa entre una conexión de red y el programa de usuario que interviene en uno de los
extremos de la conversación. En el otro extremo, habrá otro programa que recibe los datos
transmitidos, que también deberá poder asociarse a dicha conexión. Esa asociación se hace
por medio del puerto de destino que TCP asigna a cada paquete que transmite.
Cuando un programa de usuario (conocido como proceso cliente) abre una conexión de red
por medio de TCP, se le asigna (mas o menos al azar) un número de puerto. Ese programa
asume que en la otra computadora estará en ejecución otro programa (conocido como
proceso servidor o, en la jerga Unix, demonio de red) que espera recibir peticiones desde la
red. Cuando ese programa fue iniciado, su capa TCP le asignó también un número de
puerto. Obviamente, el número de puerto que se asigne a procesos servidores no puede ser
aleatorio, ya que sería imposible para los clientes saber que número especificar como puerto
de destino. Los procesos servidores se asocian, entonces, con números de puerto fijos
(llamados "números bien conocidos" -- "well-known numbers"), mientras que los procesos
cliente obtienen números de puertos aleatorios al iniciar las conexiones12.
Obsérvese que una conexión de red puede entonces identificarse unívocamente por medio
de un conjunto de 4 números: las direcciones IP de ambos extremos y los números de puerto
de origen y destino. Para el caso de las tres transferencias de archivos que se ponían como
ejemplo mas arriba, si las direcciones IP de las maquinas de origen y destino son
172.16.10.150 y 172.16.8.123, y la transferencia se hace utilizando el protocolo FTP (que
tiene asignado el número de puerto 21), cada conexión se puede identificar de la siguiente
manera:
12
No es necesario que un proceso cliente obtenga un "numero bien conocido" ya que nadie
está tratando de encontrarlo; por el contrario, es necesario que los servidores tengan esos
números a fin de que los clientes puedan conectarse a ellos.
18Dirección IP: 172.16.10.150 Dirección IP: 172.16.8.123
Conexión 1
Puerto: 1000 Puerto: 21
Dirección IP: 172.16.10.150 Dirección IP: 172.16.8.123
Conexión 2
Puerto: 1001 Puerto: 21
Dirección IP: 172.16.10.150 Dirección IP: 172.16.8.123
Conexión 3
Puerto: 1002 Puerto: 21
No pueden existir dos conexiones que compartan el mismo conjunto de números, pero es
suficiente con que al menos uno sea diferente. En el ejemplo anterior, en donde tres usuarios
transfieren archivos entre dos computadoras, dado que las computadoras involucradas en
cada transferencia son las mismas, las direcciones IP son iguales para cada conexión y todos
realizan transferencias vía FTP, por lo que el puerto de destino para las tres conexiones es el
21. Lo único que difiere es el número de puerto de origen, que permite diferenciar a los tres
usuarios.
Cada par formado por una dirección IP y un número de puerto se denomina socket
(enchufe), por lo que una conexión TCP puede verse como un canal virtual a través de una
red, "enchufada" a un socket en cada extremo. Por otra parte, el utilizar un único canal de
comunicaciones para combinar múltiples conexiones de datos se denomina multiplexación;
la información que arriba desde la red debe ser demultiplexada a fin de que cada módulo de
software reciba los paquetes que le corresponden.
De hecho, hay varios niveles de multiplexación en TCP/IP. Por una parte, TCP la utiliza
para mantener múltiples conexiones, tal como se describió previamente. Por otra parte, sin
embargo, existen otros protocolos (como UDP e ICMP) que utilizan IP como un medio para
distribuir paquetes a lo largo de la red. Cuando IP recibe paquetes entrantes desde la red,
debe poder determinar a cual protocolo de mayor nivel pasar el paquete. Esto constituye
también otra forma de demultiplexación, y se realiza por medio de la asignación a cada
paquete, por parte del IP de origen, de un numero de protocolo. Dicho número tiene un rol
similar al número de puerto, con la diferencia de que no identifica conexión sino el
protocolo de transporte que está administrando esa conexión.
El proceso de multiplexación y demultiplexación de TCP/IP se esquematiza en la siguiente
figura:
Aplicaciones Capa de Capa de Red Capa de Red Capa de Aplicaciones
(Clientes) Transporte Transporte (Servidores)
T T
C C
P P
I I
U U
P P
D D
P P
I I
C C
M M
P P
En resumen...
• Una red TCP/IP está formada por múltiples redes interconectadas por medio de
gateways. Dichos gateways pueden ser dispositivos físicos especializados (llamados
routers) o bien computadoras con múltiples adaptadores de red (llamados multihomed
hosts)
• Cada una de esas redes estará formada por máquinas individuales (los hosts de la red) o
por subredes interconectadas. Cada máquina de la red recibirá un identificador numérico
único, llamado dirección IP.
19• Las computadoras de la red ejecutarán aplicaciones que establecerán comunicaciones
entre ellas por medio de protocolos como TCP ó UDP, los cuales utilizarán el protocolo
IP para rutear paquetes de información entre el origen y el destino.
• Algunas computadoras de la red ofrecerán servicios a las demás, estableciéndose
relaciones de tipo cliente/servidor entre ellas. Los roles de cliente y servidor no son
excluyentes; una misma maquina puede al mismo tiempo ser cliente y servidor. Mas aun,
podría ocurrir que la relación cliente/servidor se dé entre dos procesos ejecutándose en la
misma máquina.
• Los procesos servidores reciben peticiones desde la red, usualmente "escuchando" en
puertos fijos de TCP (llamados números bien conocidos). Los clientes, por otra parte,
utilizan puertos TCP asignados mas o menos al azar al iniciar la conexión.
• El par formado por una dirección IP y un número de puerto se denomina socket. Una
conexión puede identificarse unívocamente por el par de sockets correspondientes al
nodo de origen y al de destino.
Direcciones IP
Clases de direcciones IP
Una dirección IP es un número, usualmente expresado por una secuencia de cuatro enteros
separados por puntos:
a.b.c.d
en donde cada uno de esos números asumen valores entre 0 y 255.
De esos cuatro números, algunos se utilizan como dirección de red y los restantes como
dirección de host. Todos los hosts que pertenezcan a la misma red deberán tener en común
la dirección de red y diferir en la dirección de host. La cantidad números que se utilicen
para la dirección de red da lugar a tres clases de direcciones IP:
Clase A a b.c.d 16777214
Clase B a.b c.d 65534
Clase C a.b.c d 254
Este esquema de direccionamiento da lugar a la existencia de unas pocas redes clase A, cada
una con algo mas de 16 millones de computadoras. En el otro extremo, habrá un número
muy grande de redes clase C, de pequeño tamaño.
Dada una dirección IP, puede determinarse a que clase pertenece examinando el valor de su
primer número:
Clase A 1 - 126
Clase B 128 - 191
Clase C 192 - 224
Así, por ejemplo, una dirección IP como 172.16.4.205 pertenece a la red clase B 172.16,
cuyo rango de direcciones va desde 172.16.1.1 hasta 172.16.255.254.
Debe hacerse notar que, si bien cada uno de los números de la dirección de host puede variar
entre 0 y 255, esos dos valores en particular no pueden asignarse como dirección a ninguna
20También puede leer
