Monografias.com > Computación > Redes
Descargar Imprimir Comentar Ver trabajos relacionados

Servicios TCP/IP




Enviado por mciacci



    1. DNS
    2. FTP
    3. DHCP
    4. WWW
    5. SMTP

    INTRODUCCIÓN

    La presente Monografía
    fue realizada con fines académicos, para ser presentada
    ante el INSTITUTO UNIVERSITARIO
    AERONÁUTICO con sede en Córdoba, Argentina. La información es en su totalidad recopilada
    de Internet y
    constituye la primera entrega de una investigación sobre Servicios
    TCP/IP, siendo la
    segunda de ellas, dichos servicios y su
    configuración para Windows NT
    4.0.

    1) DNS

    En el grupo de
    protocolos
    TCP-IP se
    encuentran los protocolos de
    resolución de nombres por direcciones IP. Estos protocolos
    permiten a las aplicaciones tener acceso a los servicios de un
    computador a
    través del uso de un nombre. Para ello debe existir un
    mecanismo que permita la resolución y asociación de
    una dirección IP por un nombre. El mecanismo de
    asociación consiste en una base de datos
    donde se encuentran las asociaciones de una dirección IP con su nombre respectivo. Y el
    mecanismo de resolución consiste en identificar cual es la
    dirección IP asociada a un nombre. De esta manera los
    computadores de la red pueden ser accesados a
    través de un nombre en vez de su dirección
    IP.

    En los comienzos de la red Internet la
    resolución de nombres por números IP se realizaba a
    través de un archivo de
    texto llamado
    hosts. Este archivo de
    texto
    contenía toda las direcciones IP asociadas al nombre
    asignado a cada computador. A
    medida que la red Internet fue creciendo este método de
    resolución de nombre por números IP fue presentando
    problemas
    debido a que el archivo hosts era administrado por el administrador de
    cada red, de esta manera no se podía garantizar que un
    administrador
    no asignara el mismo nombre a máquinas
    distintas ubicadas en redes distintas. Esto trae
    como consecuencia la colisión de nombres e inconsistencia
    del archivo hosts a lo largo de una red en crecimiento. El
    formato de este archivo de texto es el siguiente:

    Lupolo@pc-1:~$ cat /etc/hosts

    127.0.0.1 localhost pc-1

    192.168.2.1 pc-2

    En este archivo podemos observar que la dirección
    IP 127.0.0.1 está asociada con los nombres localhost y
    pc-1 y la dirección IP 192.168.2.1 está asociada
    con el nombre pc-2.

    Con el fin de resolver los problemas
    explicados anteriormente se desarrolló el protocolo de
    Sistema de
    nombres de dominios "DNS Domain
    Name System". Este protocolo es una
    base de datos distribuida
    que permite un control local
    sobre los segmentos de la base de datos en
    general, logrando que cada segmento esté disponible a lo
    largo de toda la red Internet. El sistema de
    nombres de dominios utiliza un esquema cliente servidor. El
    protocolo DNS
    está compuesto por dos programas uno
    llamado servidor de
    nombres de dominios y otro llamado resolvers. Los servidores de
    nombres de dominios contienen la base de datos de un
    segmento y dicha base de datos es accesada por los clientes a
    través de un programa conocido
    como resolvers. Los resolvers son rutinas utilizadas para tener
    acceso a la base de datos ubicada en los servidores de
    nombres de dominios con el fin de resolver la búsqueda de
    una dirección IP asociada a un nombre.

    1.1) Protocolo DNS

    En la figura 1.1 podemos observar la estructura
    gráfica de una base de datos DNS donde cada nodo es un
    nombre de dominio, Todos
    los nombres de dominios nacen a partir del dominio
    raíz, el cual se denota con un punto. A su vez cada uno de
    estos nombres de dominio puede sub-dividirse. Por ejemplo, el
    dominio .org. incluye a dos nombres de dominio caida y kernel.
    Cada uno de estos nombres de dominio tienen dos nombres de
    dominio llamados www.caida.org. y ftp.caida.org
    y www.kernel.org. y ftp.kernel.org.. Esto implica que el nombre de
    dominio www asignado a dos computadores "www.caida.org. y
    www.kernel.org." gozan de un nombre de dominio único. Cada
    uno de estos nombres de dominio son nombres de dominio
    completamente calificados "FQDN, Full Qualified Domain Name". De
    esta manera dos computadoras
    pueden tener el mismo nombre sí y sólo sí
    pertenecen a zonas distintas.

    Una zona representa las partes contiguas del
    árbol del dominio para el cual un servidor de nombres
    contiene la información completa y es autoridad del
    dominio. En la figura 1.1 podemos apreciar dos zonas Caida.org. y
    Kernel.org.. Los servidores de dominio de cada zona contienen en
    sus bases de datos la
    dirección IP asociada al nombre de dominio.

    El servidor de nombres de una zona puede delegar la
    responsabilidad del sistema de nombres de dominios
    a otro servidor de nombres de dominio con el fin de
    descentralizar la base de datos. Tal es el ejemplo de los
    servidores de nombres "." raíz presentados en la figura
    1.1. Estos servidores de nombres delegan sus zonas a los
    servidores de nombres del dominio org..

     Para ver el gráfico
    seleccione la opción "Descargar"

    Figura 1.1 Estructura
    gráfica de una base de datos DNS

    Como cada computadora
    está asociada a un nombre de dominio completamente
    calificado "FQDN" y un FQDN tiene asociado una dirección
    IP, esto implica que los servicios ofrecidos por una computadora
    pueden ser accesados a través de un nombre completamente
    calificado. El nombre de un dominio puede tener hasta 63
    caracteres de longitud y puede pertenecer a cualquiera de los 127
    niveles posibles. En el protocolo DNS no existe diferencia entre
    mayúsculas o minúsculas. Un dominio puede ser una
    computadora o puede ser un nodo del cual parten otros
    dominios.

    Un nombre de dominio es un índice dentro de la
    base de datos DNS. Los nombres indexados en un dominio son las
    rutas que conforman el espacio de nombres de dominio. El nombre
    completo asociado a una dirección IP es una secuencia de
    nombres de dominios asignados desde su nodo hasta el nodo
    raíz.

    El espacio de dominio de la red Internet está
    dividido básicamente en tres niveles: Nivel Raíz,
    Nivel Tope y Nivel secundario. En la figura 1.2 podemos observar
    el nivel jerárquico de cada uno de estos
    niveles.

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    Figura 1.2 Espacio de dominio de la red
    Internet

    Los servidores de nombres de dominio superiores, es
    decir, los servidores de nombres de raíz primarios, son
    los servidores que delegan la resolución de nombres de
    dominios por números IP a los servidores de nombres de
    dominio de nivel tope. Los nombres de dominios de nivel tope
    más comunes en la red Internet son los dominios
    genéricos:

    -. Com. Son dominios asignados a organizaciones
    comerciales. Ej. newdevices.com.

    -. Edu. Son dominios asignados a instituciones educativas. Ej.
    ucv.edu.

    -. Gov. Son dominios asignados a agencias
    gubernamentales.

    -. Net. Son dominios asignados a organizaciones
    relacionadas con la red Internet.

    -. Org. Son dominios asignados a organizaciones sin
    fines de lucro.

    Además de estos nombres de dominio incluidos en
    el nivel tope se encuentran los nombres de dominio
    geográficos basados en la nomenclatura
    ISO3166. Cada uno de estos nombres de dominio son administrados
    por cada país. Este tipo de nombres de dominio son
    organizados por localidad y son útiles para organizaciones
    y negocios que
    deseen operar en dicha localidad geográfica.

    Los servidores de nombres de dominio de nivel tope
    delegan la resolución de nombres por números IP a
    los servidores de nombres de dominio de nivel secundario. En este
    nivel se encuentran todos los nombres de dominio asignados a las
    computadoras
    que ofrecen servicios de
    Internet. Ejemplo: www.caida.org..

    Dentro del espacio de nombres de dominio de la red
    Internet se encuentra el espacio de nombres de dominio
    in-arpa.addr cuya función es
    asociar una dirección IP con un nombre de dominio de esta
    manera el usuario a partir de una dirección IP puede
    conocer el nombre de dominio asociado a dicha dirección
    IP. En este espacio de nombres de dominios la dirección IP
    se lee desde lo más especifico a lo más general;
    Por ejemplo www.caida.org. (192.172.226.123) se leeria
    123.226.172.192.in-addr.arpa. lo cual retorna en una
    búsqueda a www.caida.org..

    1.1.1) Base de datos del protocolo DNS

    Cada servidor de nombres de dominio mantiene una base de
    datos que sirve para asociar los nombres de dominios con
    direcciones IP. Está base de datos se conoce con el nombre
    de archivos de la
    zona. Cada servidor de nombres de dominio también mantiene
    una base de datos de resolución inversa. Esta base de
    datos se conoce con el nombre de archivos de
    resolución inversa de la zona.

    Ambas bases de datos
    son manejadas por un servidor de nombres, el cual responde a las
    solicitudes hechas por el resolver. El formato de dichas bases de
    datos son archivos de texto donde se definen los registros de
    recurso "Resource Records RR" que sirven para especificar la
    relación entre un nombre de dominio y una dirección
    IP además sirve para especificar en qué zona del
    espacio de nombres de dominios el servidor de nombres de dominios
    pertenece. La siguiente tabla presenta los registros de
    recursos
    más comunes para la clase IN, es decir;
    Internet.

    Nombre del Recurso

    Tipo de Registro

    Función

    Inicio de autoridad

    SOA

    Parámetros que gobiernan la
    zona

    Servidor de nombres

    NS

    Indentifica el servidor de nombres de una
    Zona.

    Dirección

    A

    Asocia un nombre con una direccion IP

    Puntero

    PTR

    Asocia una direccion IP con un nombre.
    Búsqueda inversa

    Oficinas de Correo

    MX

    Indentifica donde deben ser enviados los correos
    electrónicos del dominio

    Nombre Canonico

    CNAME

    Define un alias para un nombre ya
    definido

    Informacion de estación

    HINFO

    Utilizado para definir el hardware
    y/o Sistema
    operativo de un computador

    Servicios ofertados

    WKS

    Anuncia los servicios

    Text

    TXT

    Almacena cualquier información

    El formato de un registro de
    recurso es el siguiente:

    [nombre] [ttl] IN <tipo de registro>
    <valor>

    -. [nombre] es el nombre del objeto referenciado por
    el registro del recurso. Puede ser un nombre de estación
    o un nombre de dominio.

    -. [ttl] es el tiempo de vida
    del registro. Define la cantidad de segundos que la
    información sobre este registro puede ser mantenida en
    la memoria
    de un servidor de dominios. Si el ttl es omitido usa el ttl
    indicado por el recurso definido en la sección
    SOA.

    -. IN Identifica la clase del registro como clase
    Internet.

    -. <tipo de registro> Identifica el tipo de
    recurso de acuerdo a la tabla anterior.

    -. <valor> es
    la información específica al tipo de
    recurso.

    1.1.2) Servidores de nombres
    Autoritarios

    Cada zona goza de un servidor de nombres de dominio
    autoritario. Un servidor de nombres de dominio autoritario es la
    autoridad de
    la zona ya que contiene todos los registros de recursos de la
    zona. Un servidor de nombres de dominio autoritario se define con
    el registro de recurso NS y SOA.

    Para que el protocolo DNS sea tolerante a fallas se
    recomienda dos o más servidores de nombres de dominio
    autoritarios por zona donde al menos uno de ellos sea master. Existen diferentes tipos de
    servidores de nombres autoritario, a saber:

    -. Servidores de nombres de dominio Primario o
    Master

    -. Servidores de nombres de dominio Secundarios o
    Esclavos

    -. Servidores de nombres de dominio Recursivos o
    Cache

    El servidor que contenga los datos de la zona en su
    sistema de archivos se conoce con el nombre de servidores de
    nombres de dominio primario o master. Los servidores de nombres
    de dominio primarios cargan los datos de la zona a través
    de los archivos de la zona ubicados en el sistema de archivo del
    servidor.

    Los servidores de nombres de dominio esclavos cargan el
    contenido de la zona de otro servidor usando un proceso de
    réplica conocido como transferencia de la zona. Los datos
    se transfieren típicamente desde un servidor de nombres de
    dominio primario.

    Un servidor de nombres de dominio recursivos o cache
    utiliza búsquedas recursivas en el sistema de nombres de
    dominio con el fin de buscar la dirección IP asociada al
    nombre de dominio solicitado por el resolver y por cada
    búsqueda el servidor de nombres de dominio recursivo
    almacena el resultado en memoria "Cache"
    con el fin de acelerar futuras búsquedas. Un servidor de
    nombres de dominio recursivo es conocido también con el
    nombre de servidor de nombres de dominio cache.

    1.1.3) Métodos de
    búsqueda

    Los servidores de nombres de dominio no sólo
    pueden ofrecer al resolver los datos de la zona que tienen
    autoridad sino que pueden buscar a lo largo del espacio de
    dominios, datos sobre los que no tienen autoridad. A esto se le
    como conoce como resolución. La resolución comienza
    siempre desde los servidores de nombres de dominio superiores
    "Servidores de nombres de dominio de raíz primarios" hasta
    llegar al servidor de nombres de dominio de nivel secundario que
    tiene la información acerca de la zona solicitada por el
    resolver. El proceso de
    resolución o búsqueda puede ser de dos tipos:
    Recursiva o Iterativa.

    Una búsqueda recursiva consiste en que un
    servidor de nombres de dominios a medida que obtiene respuestas
    durante el proceso de resolución de nombres de dominios
    este va guardando los nombres y su dirección IP asociada
    en una memoria cache
    con el fin de acelerar el proceso de búsqueda si la misma
    información es solicitada nuevamente.

    Una búsqueda iterativa consiste en que el
    servidor de nombres de dominios da la mejor respuesta posible
    basado en la información contenida en los archivos de la
    zona y en la memoria cache.
    La preguntas "Queries" solicitadas a los servidores de nombres de
    dominio raíz solo pueden ser iterativas.

    En la figura 1.3 podemos observar como la computadora
    PC1 a través de una aplicación cliente que hace
    uso del protocolo HTTP, requiere
    establecer una conexión TCP, puerto de destino 80 con el
    servidor de servicios WWW cuyo nombre de dominio es
    www.debian.org.. Para poder
    establecer dicha conexión TCP, la aplicación del
    computador PC1 hace uso de la función
    gethostbyname(www.debian.org) ofrecida por la aplicación
    resolver con el fin de iniciar el proceso de resolución.
    Una vez ejecutada dicha función la aplicación
    resolver pregunta al servidor de nombres de dominio de la zona
    donde se encuentra el computador PC1 "¿Cuál es la
    dirección IP del nombre de dominio www.debian.org?" a
    partir de este momento los siguientes pasos ocurren:

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    Figura 1.3 Método de
    resolución de nombres por números IP

    -. El servidor de nombres de dominio ejecuta una
    búsqueda en los registros de recursos ubicados en la memoria
    cache y en los archivos de la zona. Si la búsqueda no
    arroja resultados, el servidor de nombres de dominios pregunta a
    los servidores de nombres de dominio raíz.

    -. Los servidores de nombres de dominio raíz
    "f.root-servers.net" responden indicando que el servidor de
    nombres de dominio de la zona debian.org. puede ser encontrado en
    el servidor de nombres de dominio org. "B.GTLD-SERVERS.NET". En
    este paso podemos apreciar como los servidores de nombres de
    dominio raíz "f.root-servers.ne" delegan las
    búsquedas a los servidores de nombres de dominio de nivel
    tope "B.GTLD-SERVERS.NET", tal como lo es el dominio org..-. El
    servidor de nombres de dominio local pregunta a los servidores de
    nombres de dominio"B.GTLD-SERVERS.NET" org. ¿cuál
    es la dirección IP del dominio www.debian.org?.. El
    servidor de nombres de dominios "B.GTLD-SERVERS.NET" org.
    encuentra que uno de los servidores de nombres de dominios de la
    zona debian.org. es administrada por el servidor de dominios
    "NS2.CISTRON.NL => IP 62.216.31.55". Esta información
    es enviada al servidor de nombres de dominio local.

    -. El servidor de nombres de dominio local pregunta al
    servidor de nombres de dominio NS2.CISTRON.NL:
    ¿Cuál es la dirección IP del nombre de
    dominio www.debian.org.? Este servidor responde con la
    dirección IP asociada al dominio www.debian.org =>
    192.25.206.10. Luego el servidor de nombres de dominio local
    almacena en la memoria cache
    www.debian.org => 192.25.206.10 y la función
    gethostbyname(www.debian.org) finaliza retornando la
    dirección asociada al nombre de dominio www.debian.org.. A
    partir de este momento la aplicación que hace uso del
    protocolo HTTP puede
    iniciar la conexión TCP, puerto 80 con el servidor de
    servicios WWW cuyo nombre de dominio es
    www.debian.org..

    Con este ejemplo pudimos demostrar que el sistema de
    nombres de dominios del protocolo DNS es una base de datos
    distribuida que permite un control local
    sobre los segmentos de la base de datos en general, logrando que
    cada segmento esté disponible a lo largo de toda la red
    Internet. El sistema de dominios de nombres utiliza un esquema
    cliente servidor.

    1.1.4) Servidores de nombres de
    dominio

    La aplicación de servicios de nombres de dominios
    más conocida he implementada en la red Internet es BIND
    "Berkeley Internet Name Domain". Esta aplicación
    actualmente es mantenida y desarrollada por la
    organización sin fines de lucro: The Internet Software Consortium
    "www.isc.org". Esta aplicación determina el lugar de los
    archivos de configuración de la zona a través de un
    archivo de configuración cuyo nombre por defecto es
    named.conf. Un ejemplo de este archivo de configuración es
    el siguiente:

    noteimporta-2:/etc/bind# more named.conf

    options {

    // La siguiente linea indica que el directorio de
    trabajo de la aplicación named "BIND es directory
    "/var/cache/bind".
    // En este directorio se guardan todos los archivos generados
    transitorios generados por named.

    directory "/var/cache/bind";

    //La siguiente linea indica que el servidor no va a
    responder de manera autoritativa si el dominio solicitado no
    existe.

    auth-nxdomain no;

    };

    //La siguienete tres lineas sirven para indicar el
    archivo de la zona raiz donde de encuentran nombres de los
    servidores raices y sus direcciones de IP asociadas.
    //

    zone "." {
    type hint; //Tipo de servidor definido para esta zona
    Cache.
    file "/etc/bind/db.root";
    };

    //Las siguientes lineas sirven para indicar el archivo
    de las zonas: localhost, 127.in-addr.arpa, 0.in-addr.arpa y
    255.in-addr.arpa

    zone "localhost" {
    type master; //Tipo de servidor definido para esta zona
    Master.
    file "/etc/bind/db.local";
    };

    zone "127.in-addr.arpa" {
    type master; //Tipo de servidor definido para esta zona
    Master
    file "/etc/bind/db.127";
    };

    zone "0.in-addr.arpa" {
    type master; //Tipo de servidor definido para esta zona
    Master
    file "/etc/bind/db.0";
    };

    zone "255.in-addr.arpa" {
    type master; //Tipo de servidor definido para esta zona
    Master
    file "/etc/bind/db.255";
    };

    Esta es la información contenida en el archivo
    db.local

    noteimporta-2:/etc/bind# more db.local

    ;
    ; BIND data file for local loopback interface

    ;
    $TTL 604800

    @ IN SOA localhost. root.localhost. (

    1 ; Serial

    604800 ; Refresh

    86400 ; Retry

    2419200 ; Expire

    604800 ) ; Negative Cache TTL

    ;
    @ IN NS localhost.

    @ IN A 127.0.0.1

    Esta es la información contenida en el archivo
    db.127

    noteimporta-2:/etc/bind# more db.127

    ;

    ; BIND reverse data file for local loopback
    interface

    ;

    $TTL 604800

    @ IN SOA localhost. root.localhost. (

    1 ; Serial

    604800 ; Refresh

    86400 ; Retry

    2419200 ; Expire

    604800 ) ; Negative Cache TTL

    ;
    @ IN NS localhost.

    1.0.0 IN PTR localhost.

    Esta es la información contenida en el archivo
    db.0

    noteimporta-2:/etc/bind# more db.0

    ;
    ; BIND reverse data file for broadcast zone

    ;
    $TTL 604800

    @ IN SOA localhost. root.localhost. (

    1 ; Serial

    604800 ; Refresh

    86400 ; Retry

    2419200 ; Expire

    604800 ) ; Negative Cache TTL

    ;

    @ IN NS localhost.

    Esta es la información contenida en el archivo
    db.255

    noteimporta-2:/etc/bind# more db.255

    ;

    ; BIND reverse data file for broadcast zone

    ;

    $TTL 604800

    @ IN SOA localhost. root.localhost. (

    1 ; Serial

    604800 ; Refresh

    86400 ; Retry

    2419200 ; Expire

    604800 ) ; Negative Cache TTL

    ;

    @ IN NS localhost.

    Los archivos de configuración presentados pueden
    ser utilizados por un servidor de nombres de dominios
    local.

    1.2) Cabecera del protocolo DNS

    1.2.1) Servidores de nombres de
    dominio

    El protocolo DNS trabaja en la capa de
    aplicación. Si el segmento a enviar es menor que 512 Bytes
    utiliza el protocolo UDP, de lo contrario utiliza el protocolo
    TCP. El número de puerto que utiliza el protocolo DNS para
    comunicarse con la capa de aplicación es el número
    53.

    Todos los mensajes generados por el protocolo DNS
    utilizan un único formato de cabecera el cual se muestra en la
    figura 1.4.

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    | ID |

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    |QR| Opcode |AA|TC|RD|RA| Z | RCODE |

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    | QDCOUNT |

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    | ANCOUNT |

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    | NSCOUNT |

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    | ARCOUNT |

    +–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+–+

    Figura 1.4 Cabecera del protocolo
    DNS

    -. ID. Es un identificador de 16 bits
    asignado por el programa. Este
    identificador se copia en la respuesta correspondiente del
    servidor de nombres y se puede usar para diferenciar respuestas
    cuando concurren múltiples consultas.

    -. QR. Flag que indica consulta(0) o
    respuesta(1).

    -. Op code. Campo de 4-bit que especifica el tipo de
    consulta:

    -. 0 consulta estándar(QUERY).

    -. 1 consulta inversa(IQUERY).

    -. 2 solicitud del estado del
    servidor(STATUS).

    -. Se reservan los otros valores para
    su uso en el futuro.

    -. AA. Flag de respuesta autoritativa. Si está
    activo es una respuesta, especifica que el servidor de nombres
    que responde tiene autoridad para el nombre de dominio enviado en
    la consulta.

    -. TC. Flag de truncado. Activo si el mensaje es
    más largo de lo que permite la línea de
    transmisión.

    -. RD. Flag de recursividad. Este bit se copia en la
    respuesta e indica al servidor de nombres una resolución
    recursiva.

    -. RA. Flag de recursividad disponible. Indica si el
    servidor de nombres soporta resolución
    recursiva.

    -. Z. 3 bits reservados para uso futuro. Deben ser
    cero.

    -. Rcode. Código
    de respuesta de 4 bits. Los posibles valores
    son:

    -. 0. Ningún error.

    -. 1. Error de formato. El servidor fue incapaz de
    interpretar el mensaje.

    -. 2. Fallo en el servidor. El mensaje no fue procesado
    debido a un problema con el servidor.

    -. 3. Error en nombre. El nombre de dominio de la
    consulta no existe. Sólo válido si el bit AA
    está activo en la respuesta.

    -. 4. No implementado. El tipo solicitado de consulta no
    está implementado en el servidor de nombres.

    -. 5. Rechazado. El servidor rechaza responder por
    razones políticas.
    Los demás valores se reservan para su usuario en el
    futuro.

    -. QDcount. Un entero sin signo de 16 bits que
    especifica el número de entradas en la sección
    "question".

    -. ANcount. Un entero sin signo de 16 bits que
    especifica el número de RRs en la sección
    "answer".

    -. NScount. Un entero sin signo de 16 bits que
    especifica el número de RRs en la sección
    "authority".

    -. ARcount. Un entero sin signo de 16 bits que
    especifica el número de RRs en la sección
    "additional records".

    1.3) Conclusiones

    El sistema de nombres de dominio del protocolo DNS es
    una base de datos distribuida que permite un control local sobre
    los segmentos de la base de datos en general, logrando que cada
    segmento esté disponible a lo largo de toda la red
    Internet. El sistema de nombres de dominios utiliza un esquema
    cliente servidor.

    2) FTP

    FTP significa File Transfer Protocol, protocolo de
    transferencia de ficheros. Es un servicio de
    Internet que permite transferencia de archivos. Se utiliza en
    modo cliente-servidor: conectados a un ordenador remoto (que
    actúa como servidor y que es un gran ordenador
    permanentemente conectado a Internet) nuestro programa (cliente)
    nos permite solicitar la transferencia de archivos en cualquiera
    de las dos direcciones.

    El servidor de archivos debe admitir las transferencias
    de tipo FTP, por lo que deberá ser un ordenador
    especialmente preparado para esta tarea. En nuestro ordenador
    necesitaremos un programa específico; hay varios muy
    populares, gratuitos, algunos incluso en castellano. A
    nuestro programa le indicaremos en primer lugar cuál es el
    servidor que vamos a utilizar.

    Algunos servidores solamente admiten conexiones
    identificadas: el usuario debe iniciar su conexión
    mediante una identificación ("login") y una clave secreta
    ("password"). En ese caso, y dependiendo del usuario, se
    podrá acceder a más o menos directorios del
    servidor. Muchos servidores de FTP también admiten la
    posibilidad de hacer una conexión no identificada,
    anónima: en tal caso debemos utilizar como identificativo
    la palabra "anonymous"; es de cortesía utilizar la
    dirección de correo
    electrónico como clave secreta, para que los
    administradores del servidor puedan llevar una estadística de los diferentes accesos
    anónimos.

    Típicamente, los programas de FTP
    muestran en dos "ventanas" los archivos correspondientes a los
    directorios elegidos en el disco local y en el servidor. Existen
    procedimientos
    para cambiar el directorio de cualquiera de los dos ordenadores.
    En el caso del servidor remoto, es posible que la
    identificación de la conexión no nos permita
    acceder a todos los directorios (esto puede ser así, tanto
    para las conexiones identificadas como para las anónimas).
    Algunos servidores nos permitirán obtener archivos
    remotos, pero no nos consentirán el envío de
    ficheros hacia el servidor. Típicamente la transferencia
    se realiza seleccionando en la lista los archivos que se desean
    transferir y pulsando en el botón correspondiente para que
    se inicie la transferencia. Es posible transferir varios archivos
    en bloque.

    Las transferencias pueden realizarse en dos modos: texto
    y binario; el primero es adecuado solo para los archivos de texto
    (ASCII o ANSI),
    mientras que el segundo es válido para todos los
    ficheros.

    Los programas más populares para realizar FTP son
    conocidos por los siguientes nombres: CuteFTP y WS_FTP. Se pueden
    conseguir fácilmente a través del Web y,
    lamentablemente, están en inglés.

    El sistema FTP está sufriendo una importante
    devaluación porque la mayoría de las
    transferencias pueden efectuarse desde páginas
    Web y utilizando el programa navegador, lo cual facilita y
    simplifica la tarea. Esto solo es válido para
    transferencias descendentes (desde el servidor remoto al
    ordenador local) y en formato "anónimo". El servicio
    Web integra
    perfectamente este modo de FTP, que es el utilizado por la
    mayoría de los usuarios.

    En cada directorio del servidor suele haber un archivo
    de texto que explica el contenido de los otros ficheros y de los
    subdirectorios. Con los programas más potentes es posible
    acceder a este fichero (en una ventana) sin necesidad de guardar
    una copia en el disco duro
    local. Los directorios pueden estar organizados por temas, por
    sistemas
    operativos o por cualquier otro criterio.

    El sistema FTP también es usado habitualmente
    para colocar las páginas
    Web en los ordenadores que se dedican a este servicio. Las
    páginas son "creadas" en el disco duro y
    luego son transferidas utilizando el sistema FTP.

    2.1) Ejecución del FTP

    Los pasos que hay que seguir para hacer FTP de una
    máquina (local) a otra (remota), son los
    siguientes:

    Entrar en la máquina local (es decir, en la que
    vamos a trabajar físicamente)

    Una vez dentro, nos conectaremos a la máquina
    remota, para lo cual haremos ftp, de una de las dos formas
    siguientes:

    % ftp nombre o dirección IP de la
    máquina remota

    o bién

    % ftp

    % FTP> open nombre o dirección IP de la
    máquina remota

    Una vez hecho esto nos preguntará el nombre de
    usuario y la palabra clave, es decir:

    Username nombre de usuario

    password palabra clave

    donde el nombre de usuario puede ser:

    El user name (login) de una cuenta en la máquina
    a la que voy a acceder; o bien

    anonymous : para poder acceder
    al servidor de ficheros de la máquina remota.
    En este caso es aconsejable (y a veces obligatorio) introducir
    como palabra clave, la dirección de correo
    electrónico.

    Una vez hecho esto, ya se ha establecido comunicación con la máquina remota a
    través de FTP; por lo que el prompt del sistema desaparece
    y aparece el prompt del FTP, que es:

    FTP> o FTP-0>

    A partir de este momento ya se pueden utilizar los
    comandos
    específicos del FTP.

    2.2) Salir de una sesión de
    FTP

    Para salir de una sesión de FTP, se pueden
    utilizar los siguientes comandos:

    close

    Termina la sesión de FTP, pero no sale del
    programa

    bye
    quit

    Termina la sesión de FTP y sale del
    programa

    2.3) Ayuda

    FTP posee varios comandos para obtener ayuda de
    cómo utilizarlo:

    ?
    help

    Dá una lista de los comandos del FTP de la
    máquina local

    help comando
    ? comando

    Dá información sobre el comando
    especificado, correspondeinte a la máquina
    local

    2.4) Ficheros y
    directorios

    A continuación se da una relación de
    comandos del FTP referentes al manejo de ficheros y
    directorios.

    lcd directorio-local

    Para moverse de un directorio a otro en la
    máquina local

    lcd unidad:

    Para cambiar de una unidad de disco a otra, en el
    caso particular de que la máquina local esa un
    PC

    cd directorio-remoto

    Para moverse de un directorio a otro en la
    máquina remota

    lls directorio-local

    Para listar el contenido de un directorio en la
    máquina local

    dir directorio-remoto
    ls directorio-remoto

    Para listar el contenido de un directorio en la
    máquina remota

    ! comando

    Para ejecutar un comando en la máquina
    local

    delete fichero-remoto

    Para borrar un fichero en la máquina
    remota

    delete ficheros-remotos

    Para borrar varios ficheros en la máquina
    remota

    rmdir directorio-remoto

    Para borrar un directorio en la máquina
    remota

    mkdir directorio-remoto

    Para crear un directorio en la máquina
    remota

    pwd

    Para saber el directorio en el que se está,
    en la máquina remota

    2.5) Transferencia de
    información

    Con FTP se puede realizar la transferencia de
    información en dos formatos diferentes: ascii y binario.
    Por defecto, la transferencia se hace en modo ascii.

     Para saber el tipo de formato que está
    activado para realizar las transferencias, se utiliza el
    comando:

    type

     Para hacer la transferencia en formato ascii
    (lo hace por defecto), se utiliza el comando:

    ascii

     

     

    o

    type ascii

     

     

     Para hacer la transferencia en formato binario,
    se utiliza el comando:

    binary

     

     

    o

    type binary

     

     

     

    2.5.1) TRANSFERENCIA DE FICHEROS DE LA MAQUINA REMOTA
    A LA LOCAL

    Para transferir un fichero de la máquina remota a
    la local, se utiliza el comando get o recv (ambos son
    equivalentes). La sintaxis es:

    get fichero-remoto

    o

    get
    (remote-file) fichero-remoto

    Si se quiere cambiar el nombre del fichero que se va a
    transferir, se pondrá:

    get fichero-remoto fichero-local

    Si se quieren transferir varios ficheros de la
    máquina remota a la local, se utiliza el comando mget. La
    sintaxis es:

    mget lista de nombres de los
    ficheros-remotos

    o

    mget
    (remote-files) lista de nombres de los
    ficheros-remotos

    Entonces:

    * si está en Interactive mode on , va a pedir
    confirmación antes de transferir cada uno de los ficheros
    especificados.

    * si está en Interactive mode off , no va a pedir
    confirmación antes de transferir cada uno de los ficheros
    especificados.

    Para cambiar de mode on a mode off, o viceversa, se
    utiliza el comando prompt, cuya sintaxis, es
    simplemente:

    prompt

    Los nombres de los ficheros van separados por blancos y
    pueden incluir los metacaracteres * e ?.

    2.5.2) TRANSFERENCIA DE FICHEROS DE LA MAQUINA LOCAL
    A LA REMOTA

    Para transferir un fichero de la máquina local a
    la remota, se utiliza el comando put o send (ambos son
    equivalentes). La sintaxis es:

    put fichero-local

    o

    put
    (File) fichero-local

    Si se quiere cambiar el nombre del fichero que se va a
    transferir, se pondrá:

    put fichero-local fichero-remoto

    send fichero-local fichero-remoto

    Si se quieren transferir varios ficheros de la
    máquina local a la remota, se utiliza el comando mput. La
    sintaxis es:

    mput lista de nombres de los
    ficheros-locales

    o

    mput
    (local-files) lista de nombres de los
    ficheros-locales

    Análogamente, al caso de transferir ficheros con
    el comando mget :

    * si está en Interactive mode on , va a pedir
    confirmación antes de transferir cada uno de los ficheros
    especificados.

    * si está en Interactive mode off , no va a pedir
    confirmación antes de transferir cada uno de los ficheros
    especificados. de los ficheros especificados.

    Para cambiar de mode on a mode off, o viceversa, se
    utiliza el comando prompt, cuya sintaxis, es
    simplemente:

    prompt

    Los nombres de los ficheros van separados por blancos y
    pueden incluir los metacaracteres * e ?.

    3) DHCP

    DHCP (Dynamic Host Configuration Protocol) son las
    siglas que identifican a un protocolo empleado para que los hosts
    (clientes) en
    una red puedan
    obtener su configuración de forma dinámica a través de un servidor del
    protocolo. Los datos así obtenidos pueden ser: la
    dirección IP, la máscara de red, la
    dirección de broadcast, las características del DNS, entre otros. El
    servicio DHCP permite acelerar y facilitar la
    configuración de muchos hosts en una red evitando en gran
    medida los posibles errores humanos.

    Con una función similar a la del DHCP, pero con
    algunas restricciones, existe el BOOTP o Internet Bootstrap
    Protocol, el cual permite también la asignación de
    la configuración de red en forma dinámica pero a partir de su
    definición estática
    para cada cliente en una base de datos en el servidor. Esta
    información a diferencia de como se hace usualmente con
    DHCP no puede ser renovada.

    Básicamente el servicio DHCP/BOOTP funciona de la
    siguiente forma. Existe un programa servidor en un host de la red
    que escucha las solicitudes de los clientes y que en su
    configuración almacena tablas de posibles direcciones IP a
    otorgar además del resto de la información. Cuando
    un cliente requiere del servicio envía una solicitud en
    forma de broadcast a través de la red. Todos los
    servidores alcanzados por la solicitud responden al cliente con
    sus respectivas propuestas, este acepta una de ellas
    haciéndoselo saber al servidor elegido, el cual le otorga
    la información requerida. Esta información se
    mantiene asociada al cliente mientras este no desactive su
    interfaz de red (posiblemente porque se apague la máquina)
    o no expire el plazo del “contrato''
    (léase time). El plazo del “contrato'' o
    renta es el tiempo en que un
    cliente DHCP mantiene como propios los datos que le otorgó
    un servidor. Este se negocia como parte del protocolo entre el
    cliente y el servidor. Una vez vencido el plazo del contrato el
    servidor puede renovar la información del cliente,
    fundamentalmente su dirección IP, y asignarle otra nueva o
    extender el plazo, manteniendo la misma información. El
    cliente puede solicitar también la renovación o
    liberación de sus Datos.

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    Figura: Representación
    simplificada del protocolo DHCP

    A continuación se listan los principales mensajes
    que se intercambian como parte del protocolo DHCP y para que se
    emplea cada uno:

    DHCPDISCOVER – mensaje de broadcast de un cliente para
    detectar los servidores.

    DHCPOFFER – mensaje de un servidor hacia un cliente con
    una oferta de
    configuración.

    DHCPREQUEST – mensaje de un cliente a un servidor
    para:

    a) aceptar la oferta de un
    servidor determinado y por ende rechazar las otras

    b) confirmar la exactitud de la información
    asignada antes del reinicio del sistema

    c) extender el contrato de una dirección IP
    determinada

    DHCPPACK – mensaje del servidor hacia un cliente para
    enviarle la configuración asignada excluyendo la
    dirección IP que ya fue aceptada.

    DHCPNAK – mensaje del servidor al cliente para indicar
    que la dirección que tiene asignada es incorrecta (por
    ejemplo, cuando el cliente cambia de subred) o que el contrato ha
    expirado.

    DHCPDECLINE – mensaje del cliente para el servidor
    indicando que aún está usando una dirección
    determinada.

    DHCPRELEASE – mensaje del cliente para el servidor para
    indicar que renuncia a la dirección otorgada y cancela lo
    que queda del contrato establecido anteriormente.

    DHCPINFORM – mensaje del cliente para el servidor para
    pedir sus parámetros de configuración excluyendo la
    dirección IP que ya tiene asignada.

    Un servidor de DHCP puede identificar a cada cliente a
    través de dos formas fundamentales:

    La dirección MAC (Media Access Control)
    de la tarjeta de red
    del cliente.

    Un identificador que le indique el cliente.

    Aunque la idea central del servicio DHCP es la
    dinamicidad de las direcciones IP asignadas no se excluye la
    posibilidad de utilizar direcciones fijas para algunos hosts que
    por sus características lo requieran, ejemplo de
    ello son las máquinas
    proveedoras de disímiles servicios como el correo
    electrónico o el DNS. Este tipo de host utilizaría
    las ventajas del servicio para obtener el resto de los datos que
    se pueden proveer mediante DHCP.

    En Linux la
    implementación del servidor de DHCP y de BOOTP la mantiene
    la ISC (Internet Software Consortium). Esta
    se empaqueta en la distribución Red Hat bajo el nombre dhcp.
    Existen además otros dos paquetes asociados a este
    servicio que implementan la parte cliente: pump y
    dhcpcd.

    3.1) Las ventajas del uso de DHCP son:

    a) solo se configura un servidor para entregar
    números IP para clientes de red

    b) se entregan todos los parámetros
    básicos de TCP/IP

    c) facilidad de configuración

    3.2) Las desventajas del uso de DHCP
    son:

    1. La seguridad
    2. Al entregar números IP dentro de la red,
      habiendo un DNS, no hay un puente intermedio entre DNS y DHCP
      directo. Es decir, hay que agregar las máquinas "a mano"
      en el DNS
    3. Mayor difusión de paquetes en la red, aunque
      hoy en día con la velocidad de
      las redes no parece
      demasiado problemático.

    4) WWW

    La tecnología World Wide
    Web surge en la Organización Europea para la Investigación Nuclear "CERN" cuando Tim
    Berners-Lee propone la necesidad de implementar un sistema de
    gerencia de la
    información a fin de solucionar la pérdida de
    información producida por la dinámica de la
    organización.

    El consorcio W3C fue creado en octubre de 1994 con el
    fin de estandardizar e implementar protocolos y especificaciones
    que promuevan:

    -. Nuevas formas de documentación de la información y
    de comunicación.

    -. La implementación de protocolos y
    especificaciones no propietarias para asegurar la
    interoperabilidad entre sistemas
    operativos.

    Desde entonces, la tecnología World Wide
    Web se ha convertido en el paradigma
    más influyente en los actuales sistemas de
    información.

    4.1) Bases de la tecnología World Wide
    Web

    La tecnología del World Wide Web es un sistema de
    información el cual esta compuesto por agentes
    interconectados. Un agente es un programa que actúa a
    nombre de otra persona, entidad,
    o proceso con el fin de intercambiar información y
    presentar la información en un formato legible al usuario.
    Por ejemplo un navegador de paginas webs es un agente (Konqueror,
    Mozilla) utilizado por el usuario para accesar las paginas webs
    que se encuentran en los agentes servidores (Apache, Tomcat,
    etc). Para que los agentes puedan intercambiar información
    y presentar la información en un formato legible al
    usuario, los agentes deben satisfacer tres
    propiedades:

    -. Representación.

    -. Identificación.

    -. Interacción.

    4.4.1) Propiedad de
    representación

    La propiedad de
    representación es utilizada para estructurar la
    información contenida en un documento Web. Esta propiedad
    utiliza una combinación de grafos en
    forma de árbol, grafos
    directos y objetos para estructurar la información. En un
    documento Web, los siguientes tipos de información pueden
    ser estructurados: Texto, imágenes y
    objetos. La información contenida en un documento Web es
    estructurada en forma de árbol donde cada nodo es
    considerado un objeto. Cada nodo puede estar compuesto por
    atributos, nodos hijos y contenido. Cada nodo es considerado una
    entidad. Una entidad un recurso que goza de identidad [3].
    Por ejemplo un documento Web es un recurso, por lo tanto todos
    los nodos contenidos en el documento Web son recursos. Un recurso
    es nombrado e identificado por la propiedad de
    identificación. Una vez identificado un recurso, los
    agentes utilizan la propiedad de interacción para accesar,
    actualizar, eliminar o intercambiar recursos entre
    agentes.

    El principal estándar internacional utilizado
    para representar la información de documentos
    electrónicos es el estándar ISO 8879. Este
    estándar es conocido con el nombre de Standard Generalized
    Mark Up Language (SGML) [5][6]. El SGML es un metalenguaje
    utilizado para definir, describir y normalizar documentos
    electrónicos basados en etiquetas. Una etiqueta es
    utilizada para dar: significado, estructura, nombre a un nodo,
    entidad y acción aplicada a la información
    etiquetada. La mayoría de las especificaciones de la
    tecnología World Wide Web son aplicaciones del SGML o
    derivan del SGML. Por ejemplo: El lenguaje
    extensible de etiquetas (Extensible Mark Up Language ) (XML) es el
    principal estándar para estructurar la información
    en la tecnología World Wide Web. Este estándar
    deriva del SGML. Las especificaciones XML permiten a
    los usuarios definir las etiquetas de un documento modelo el cual
    es utilizado para dar estructura y significado a la
    información de un documento. Un documento modelo se
    define con las especificaciones XML Schema o Document Type
    Definition [5][6][8][13]. Una vez definido un documento modelo se
    pueden crear múltiples documentos. De esta manera la
    información de un documento es estructurada y normalizada.
    Las especificaciones XML delega la función de formato o
    presentación de la información a las
    especificaciones XSL y CSS [11][15].

    4.1.2) Propiedad de
    Identificación

    La función de la propiedad de
    identificación es identificar, localizar y nombrar los
    recursos definidos por la propiedad de representación los
    cuales son almacenado en los repositorios de información
    de los agentes. Las especificaciones del RFC 2396 (URI) satisface
    la propiedad de identificación [3]. Un URI esta compuesto
    por tres definiciones:

    -. Uniformidad.

    -. Recurso.

    -. Identificador.

    La definición de Uniformidad establece el
    conjunto de reglas que definen las secuencias correctas de los
    elementos que conforman a un URI. Este conjunto de reglas
    proporciona un mecanismo común para interpretar los
    diferentes tipos de identificadores de recursos.

    La definición de recurso es el mapeo conceptual a
    un nodo. Este mapeo es visto como un grafo directo entre dos
    nodos.

    La definición de identificador es un objeto que
    actúa como referencia a algo que tiene identidad.
    Ejemplo un recurso.

    La sintaxis genérica que representa a un URI es
    la siguiente:

    <esquema>:<parte especifica del esquema
    >

    Dicha sintaxis es utilizada para definir las
    aplicaciones de un URI. Entre estas aplicaciones se encuentran
    los localizadores de recursos (URL) y nombre de recursos
    (URN).

    Un URL define a un subconjunto de URI que identifican
    los siguientes parámetros: nombre del recurso, Localidad
    del recurso y protocolo de acceso del recurso. En general la
    parte especifica del esquema de un URL es el
    siguiente:

    <Esquema>://<usuario>:<password>@<host>:<puerto>/<ruta
    del recurso>

    El parámetro <Esquema> identifica el
    protocolo de acceso del recurso. Los parámetros
    <usuario> y <password> son opcionales ya que la
    presencia de estos parámetros en un URL depende del
    protocolo de acceso del recurso. Por ejemplo el protocolo FTP
    permite el uso de estos dos parámetros. El
    parámetro <host> define el nombre de dominio
    completamente calificado del agente. [18]. El parámetro
    <puerto> identifica el número de puerto del agente.
    Y el parámetro <ruta del recurso> identifica el
    nombre del recurso.

    En la figura 1.1 podemos apreciar el siguiente URL:
    http://www.debian.org..

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    Figura 1.1 Uniform Resource Locator
    (URL)

    Este URL identifica los siguientes
    parámetros:

    -. ¿Cómo se llama el recurso (En este caso
    el documento Web)?

    Por defecto index.html

    -. ¿Dónde se puede localizar este
    recurso?

    En el directorio raíz incluido en el directorio
    virtual del servidor de páginas Web cuyo nombre de dominio
    es www.debian.org.

    -. ¿Cómo puede ser accesado el
    recurso?

    La página puede ser accesada con el protocolo
    HTTP.

    Un URL puede ser absoluto o relativo. Un URL absoluto
    identifica explícitamente el nombre del recurso, donde se
    localiza el recurso, y cómo el recurso puede ser accesado.
    Una vez que un recurso halla sido accesado, se puede utilizar un
    URL relativo para identificar los recursos de un documento. Un
    URL relativo no identifica el mecanismo de acceso primario. Por
    ejemplo, el siguiente: URI index.html#2 se puede
    clasificar como un URL relativo ya que el recurso index.html fue
    identificado y accesado por un URL absoluto, y el recurso 2
    incluido en el documento index.html es identificado por el
    siguiente fragmento URI: # 2.

    Los nombres uniformes del recurso (URN) no identifican
    la ubicación física del recurso
    mas bien son utilizados como identificadores persistentes e
    independientes de recursos y están diseñados para
    hacer factible el mapeo de nombres de recursos. La sintaxis
    genérica de un URN se puede representar de la siguiente
    manera:

    <URN> ::= "urn:" <NID> ":"
    <NSS>

    Un URN utiliza la secuencia "urn:" para identificar el
    esquema donde el parámetro NID especifica la
    identificación del espacio de nombres, y <NSS>
    especifica la secuencia del espacio de nombres de recursos de un
    documento. Una de las ventajas al utilizar un URN es la capacidad
    para el programador de nombrar sus propios recursos con el fin de
    evitar colisiones que pueden ocurrir cuando muchos documentos XML
    van a ser combinados en uno [14].

    4.1.3) Propiedad de Interacción

    Una vez que un recurso es identificado por la propiedad
    de identificación, los agentes utilizan la propiedad de
    interacción para accesar, actualizar, eliminar o
    intercambiar recursos entre agentes vía protocolos. El
    principal protocolo implementado en los agentes en la
    tecnología del World Wide Web es el protocolo (HTTP) [4].
    El protocolo http funciona a partir de solicitudes. Las
    solicitudes más comunes del protocolo http son:

    -. GET. Es una solicitud para leer un recurso.Ejemplo
    una pagina Web.

    -. PUT. Es una petición para almacenar un
    recurso.

    -. DELETE. Indica una solicitud para remover un
    recurso.

    -. POST. Es una petición que añade
    información a un recurso nombrado.

    -. HEAD. Es una petición para leer la cabecera
    de un página
    Web.

    Cada solicitud hecha por el navegador a través
    del protocolo http recibe una respuesta acompañada por un
    código
    de estado. El
    código de estado más común es el
    código 200 (OK), este código indica que el servidor
    respondió a la solicitud satisfactoriamente. Para conocer
    las solicitudes y respuestas del protocolo http ver las secciones
    9 y 10 del RFC 2616.

    4.2) Conclusiones

    La tecnología del World Wide Web es un sistema de
    información el cual esta compuesto por agentes
    interconectados.

    Un agente es un programa que actúa a nombre de
    otra persona, entidad,
    o proceso con el fin de intercambiar información y
    presentar la información en un formato legible al
    usuario.

    Para que los agentes puedan intercambiar
    información y presentar la información en un
    formato legible al usuario, los agentes deben satisfacer tres
    propiedades:

    -. Representación.

    -. Identificación.

    -. Interacción.

    El consorcio W3C fue creado en octubre de 1994 con el
    fin de estandardizar e implementar protocolos y especificaciones
    que promuevan:

    -. Nuevas formas de documentación de la
    información.

    -. Nuevas formas de comunicación.

    -. La implementación de protocolos y
    especificaciones no propietarias para asegurar la
    interoperabilidad entre sistemas
    operativos.

    5) SMTP

    El significado de las siglas de SMTP, es Protocolo
    Simple de Transmisión de Correo ("Simple Mail Transfer
    Protocol"). Este protocolo es el estándar de Internet para
    el intercambio de correo electrónico. SMTP necesita que el
    sistema de transmisión ponga a su disposición un
    canal de comunicación fiable y con entrega ordenada de
    paquetes, con lo cual, el uso del protocolo TCP en la capa de
    transporte, es
    lo adecuado. Para que dos sistemas
    intercambien correo mediante el protocolo SMTP, no es necesario
    que exista una conexión interactiva, ya que este protocolo
    usa métodos de
    almacenamiento y
    reenvío de mensajes.

    Son tres los protocolos que se aplican a un correo de
    esta clase. El termino SMTP es frecuentemente y
    erróneamente usado para referirse a la combinación
    del grupo de
    protocolos involucrados en el envío de correo
    electrónico. Esto porque los tres están
    estrechamente relacionados, pero estrictamente hablando SMTP es
    uno de los tres protocolos. Los tres protocolos son:

    ·Un estándar para el intercambio de
    correo entre dos computadores (RFC 821), el cual especifica el
    protocolo usado para enviar correo entre "host" TCP/IP. Este
    estándar es SMTP.

    ·Un estándar del formato del mensaje de
    correo, contenido en dos RFC:

    -RFC 822 describe la sintaxis del campoo de
    título o cabecera del correo electrónico y
    describe la interpretación del grupo de campos de la
    cabecera.

    -RFC 1049 describe como un conjunto de otros tipos de
    documentos, que tengan texto ASCII, y que pueden ser usados en
    el cuerpo del correo electrónico. El nombre del
    protocolo oficial para este estándar es MAIL.

    ·Un estándar para el "routing" de "mail"
    usando el sistema de nombres de dominio, descrito en RFC 974.
    El nombre oficial del protocolo para este estándar es
    DNS-MX.

    5.1) Modo de Comunicación
    SMTP

    Cuando un servidor de SMTP, requiere transmitir un
    mensaje a otro servidor SMTP, el emisor (servidor que inicia la
    sesión SMTP) establece una conexión con el receptor
    (servidor que recibe petición de establecer sesión
    SMTP). Esta conexión es unidireccional, es decir, el
    emisor puede enviar correo al receptor, pero durante esa
    conexión, el receptor no puede enviar correo al emisor. Si
    el receptor tiene que enviar correo al emisor, tiene que esperar
    a que finalice la conexión establecida y establecer otra
    en sentido contrario, cambiando los papeles de emisor y receptor.
    Una vez establecida la conexión, el emisor envía
    comandos y mensajes. Los mensajes pueden tener como destino el
    receptor o un intermediario para llegar

    a un destino más lejano. El receptor puede enviar
    al emisor respuestas y códigos de estado. Los comandos son
    cadenas de caracteres que se pueden entender fácilmente y
    las respuestas son códigos numéricos seguidos de
    una explicación del código. Por lo señalado,
    SMTP (RFC 821) está basado en entrega "end-to-end". Esto
    es diferente del principio guardar y enviar común en
    muchos sistemas de mensajería electrónica, donde el mensaje puede pasar a
    través de un numero de maquinas intermediarias su camino
    al destino final.

    Existen aplicaciones que permiten intercambiar correo
    entre el sistema de mensajería electrónica TCP/IP SMTP y el sistema de
    correo localmente usado. Estas aplicaciones son llamadas
    "Gateways" de correo ("Gateways") o "Bridges" de correo. Enviar
    correo a través de un "Gateway" puede alterar la entrega
    "end-to-end". El protocolo SMTP solo puede garantizar la entrega
    al "Gateway" y no al destino final que está localizado
    más allá de la red TCP/IP. Cuando el "Gateway" es
    usado, la transmisión SMTP "end-to-end" se realiza en
    varias partes, de "host" a "Gateway", "Gateway" a "host" o
    "Gateway" a "Gateway". El comportamiento
    más allá del "Gateway" no está especificado
    por SMTP. En la Fig. 2-1 se observa la
    comunicación a través de los
    "Gateways".

    SMTP se basa en el modelo de comunicación que se
    muestra en la
    Fig. 2-2.

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    En este modelo de comunicación en primera
    instancia un usuario establece la petición de enviar un
    mensaje a través de correo electrónico, luego el
    Emisor SMTP establece una conexión de dos hilos con el
    Receptor SMTP. El Receptor SMTP puede ser la destinación
    última o un intermediario, como es el caso del "Gateway".
    El Emisor SMTP genera comandos que son contestados por el
    Receptor SMTP.

    5.2) Flujo de Transferencia de los Mensajes de
    Correo Electrónico

    Aunque los comandos y respuestas son estrictamente
    definidos por el protocolo, el intercambio de ellos entre emisor
    y receptor resultar fácil de comprender, como se muestra
    en la Fig. 2-3a y la Fig. 2-3b.

    Todo intercambio de comandos/respuesta/datos
    (líneas de texto) son delimitados por un CRLF, los que no
    se incluyen en las Fig. 2-3a y Fig. 2-3b para facilitar la
    compresión del protocolo SMTP. Toda respuesta tiene un
    código numérico al principio de la
    línea.

    Para ver el gráfico seleccione la
    opción "Descargar" del menú superior

    El ejemplo de trasferencia se detalla a
    continuación:

    ·El Emisor SMTP establece una conexión TCP
    con el destino SMTP y luego espera que el servidor envíe
    un 220 Servicio de lectura de
    mensaje o un 421 Servicio de mensaje no habilitado, esto ultimo,
    cuando la destinación está temporalmente
    inhabilitada para procesar el mensaje.

    ·HELO (Es una abreviación de "hello") es
    enviado para que el receptor identifique si el Emisor SMTP
    está enviando su nombre de dominio. El Emisor SMTP puede
    usarlo para verificar si contactó la destinación
    SMTP correcta. Si el Emisor SMTP soporta Extensión de
    Servicios ("Service Extensions") SMTP, como está definido
    en RFC 1651 (Extensión de Servicios es explicada en
    detalle en la subsección 2.1.4), puede sustituir por un
    comando EHELO el comando HELO. El Receptor SMTP que no soporta
    Extensión de Servicios, responde con una sintaxis de error
    500, que es un comando de mensaje no reconocido. El Emisor SMTP
    debe entonces reintentar con HELO, o si el emisor no puede
    transmitir el mensaje sin uno o más de los comandos que
    son propios de Extensión de Servicios, éste debe
    enviar un mensaje QUIT.

    ·Si el Receptor SMTP soporta Extensión de
    Servicios, responde con un mensaje multilínea 250 OK, que
    incluye una lista de extensión de servicios que
    soporta.·El Emisor SMTP, luego de recibir este comando 250
    OK, inicializa la transferencia del mensaje enviando el comando
    MAIL al Receptor SMTP. Este comando contiene el "reverse-path"
    (habitualmente se utiliza para el envío del nombre de
    dominio del emisor) que puede ser usado para reportar errores.
    Esta " reverse-path" puede contener más que solamente el
    nombre de dominio de usuario (del emisor), en adición,
    éste puede contener una lista de "host" de la ruta.
    Ejemplo de esto es cuando se pasa por un "Bridge" o cuando se
    provee explícitamente información de la uta en la
    dirección de destino. Si el Receptor SMTP acepta responde
    con un 250 OK.

    ·El segundo paso del intercambio de mensajes a
    través de correo electrónico, consiste en proveer
    al servidor SMTP la destinación para el mensaje. Se
    realiza enviando uno o más comandos RCPT TO:forward-path.
    Cada uno de estos envíos es contestado por parte del
    Receptor SMTP con un 250 OK, si la destinación es conocida
    por el servidor, o un 550 NO, si tal usuario no es
    conocido.

    ·Cuando todos los comandos RCPT son enviados, el
    Emisor SMTP emite un comando DATA para notificar al Receptor SMTP
    que el contenido del mensaje será el siguiente
    envío. El Receptor SMTP responde con 354 Start mail input,
    end with CRLF CRLF. Esta secuencia final es la que el Emisor SMTP
    utiliza cuando termina el envío de datos del mensaje a
    transferir.

    ·El cliente ahora envía las líneas
    de datos, una a una, finalizando con la secuencia CRLF.CRLF,
    secuencia que el Receptor SMTP responde con un 250 OK o un
    mensaje de error si es que algo ha fallado.

    ·Luego se tienen algunas opciones:

    -El Emisor SMTP no tiene más mensajes qque
    enviar, por lo que se finaliza la conexión con un comando
    QUIT, a lo cual el Receptor SMTP responde con 221 Service closing
    transmission channel.

    -Si el Emisor SMTP no tiene más mensajes que
    enviar, pero quiere recibir mensajes del otro extremo. Este
    envía el comando TURN. Los dos extremos de la
    comunicación SMTP ahora cambian roles de
    Emisor/Receptor y el nuevo Emisor SMTP (Anterior Receptor SMTP)
    puede enviar mensajes partiendo del paso 3 del esquema mostrado
    en la Fig. 2-3a.

    -Si el Emisor SMTP tiene otro mensaje ppara enviar
    retorna al paso 3 y envía un comando MAIL.

     

    Ciacci Miguel

    Facultad de Educación a
    Distancia

    Ingeniería de Sistemas

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter