You are on page 1of 173

1

Introduction And Overview

1.1 Growth Of Computer Networking

Redes informticas ha crecido enormemente. Desde la dcada de 1970, equipo


commun-icaciones ha cambiado de un tema de investigacin esotrica a una parte esencial
de la infraestruc-tura. Networking es utilizado en cada aspecto del negocio, incluyendo la
publicidad, la produccin, el transporte, la planificacin, facturacin y contabilidad. Por
consiguiente, la mayora de las corporaciones han mul-tiple redes. Las escuelas, en todos
los niveles, desde la enseanza primaria hasta el nivel de posgrado, estn utilizando las
redes informticas para proporcionar a los estudiantes y profesores con acceso instantneo
a la informacin en lnea. Autoridades federales, estatales y locales de las oficinas del
gobierno usan redes, como lo hacen las organizaciones militares. En resumen, las redes
informticas estn en todas partes.
El crecimiento y los usos de la Internet mundial estn entre los ms interesantes y
ex-citando fenmenos en redes. En 1980, la Internet fue un proyecto de investigacin que
participar en una docena de sitios. Hoy en da, Internet se ha convertido en un sistema de
comunicacin de produccin que llega a todos los poblados del mundo. Muchos usuarios
tienen acceso de alta velocidad a Internet a travs de mdem por cable, DSL o tecnologas
inalmbricas.
El advenimiento y la utilidad de la red ha creado dramticos cambios econmicos.
Redes de datos de teletrabajo ha hecho disponible a los individuos y ha cambiado la
comunicacin empresarial. Adems, toda una industria surgi que desarrolla redes tech-
nologies, productos y servicios. La importancia de las redes de computadoras se ha
producido una demanda en todos los sectores para personas con ms experiencia en redes.
Las empresas necesitan trabajadores para planificar, adquirir, instalar, operar y administrar
el hardware y software sys tem que constituyen las redes de computadoras y las internets.
Adems, el programa informtico-ming ya no est restringido a equipos individuales -
Programacin de redes es re-

a lo largo de este texto, que siga la convencin de escribir Internet con mayscula "i" para denotar la Internet
global.
1
2 Introduccin y presentacin Cap. 1

Quired porque todos los programadores se espera para disear e implementar el software
de aplicacin que pueden comunicarse con aplicaciones de otros equipos.

1.2 Why Networking Seems Complex

Debido a que las redes de computadoras es un activo, estimulante campo, el asunto


parece com-plex. Existen muchas tecnologas, y cada tecnologa tiene caractersticas que
lo distinguen de los dems. Las compaas siguen para crear productos y servicios de redes
comerciales, a menudo mediante el uso de tecnologas en los nuevos medios no
convencionales. Por ltimo, la red parece complejo porque las tecnologas pueden ser
combinados e interconectados de muchas maneras.
Las redes de computadoras pueden ser especialmente confuso para un principiante,
porque no existe una sola teora subyacente que explica la relacin entre todas las partes.
Varios orga-nizaciones han creado estndares de red, pero algunas normas son
incompatibles con otros. Diversas organizaciones y grupos de investigacin han intentado
definir modelos conceptuales que captan la esencia y explicar los matices entre sistemas
de hardware y software de red, sino porque el conjunto de tecnologas es diverso y cambia
rpidamente, los modelos son tan simplista que no distinguen entre los detalles o tan
compleja que no ayudan a simplificar el tema.
La falta de coherencia en el campo ha producido otro reto para principiantes: en lugar
de una terminologa uniforme para los conceptos de redes, varios grupos de cada intento
de crear su propia terminologa. Los investigadores se aferran a cientficamente precisa
terminologa. Marketing Corporativo de grupos suelen asociar un producto con un trmino
tcnico genrico o inventar nuevos trminos meramente distinguir sus productos o
servicios de los de competiciones-tores. Por lo tanto, trminos tcnicos se confunden
fcilmente con los nombres de los productos populares. Para aadir ms confusin, los
profesionales utilizan a veces un trmino tcnico de tecnologas-gy cuando se refiere a una
funcin anloga de otra tecnologa. En consecuencia, ad-dition a un amplio conjunto de
trminos y acrnimos que contiene muchos sinnimos, jerga de red contiene trminos que
son a menudo abreviada, mal utilizados o asociadas con los productos.

1.3 The Five Key Aspects Of Networking

Para dominar la complejidad de las redes, es importante obtener un amplio apoyo en


tierra que incluye cinco aspectos fundamentales de la asignatura:

Programacin de red y aplicaciones de red


Las comunicaciones de datos
Y las tecnologas de red de conmutacin de paquetes
El internetworking con TCP /IP
Los conceptos de redes y tecnologas adicionales
Sec. 1.3 Los cinco aspectos clave de las redes 3

1.3.1 Programacin de red y aplicaciones de red

La red de servicios e instalaciones que los usuarios invocan son proporcionados por
cada aplicacin de software - un programa de aplicacin en una computadora se comunica
a travs de una red con un programa de aplicacin que se est ejecutando en otro ordenador.
Los servicios de aplicacin de red abarcan una amplia gama que incluye correo electrnico,
transferencia de archivos, navegacin web, tele-llamadas telefnicas de voz, bases de datos
distribuidas, y audio y videoconferencias. Aunque cada aplicacin ofrece un servicio
especfico con su propia forma de interfaz de usuario, todas las aplicaciones pueden
comunicarse a travs de una sola red compartida. La disponibilidad de un sistema unificado
de subyacen-ing red que admite todas las aplicaciones hace un programador de trabajo
mucho ms fcil ser causa de un programador slo necesita conocer una interfaz para la
red y un conjunto bsico de funciones - el mismo conjunto de funciones se usan en todos
los programas de aplicacin que se comunican a travs de una red.
Como veremos, es posible comprender las aplicaciones de la red, e incluso es posible
escribir cdigo que se comunica a travs de una red, sin comprender las tecnologas de
hardware y software que se utiliza para transferir datos desde una aplicacin a otra. Puede
parecer que una vez que un programador masters la interfaz, no hay ms conocimiento del
trabajo en red es necesaria. Sin embargo, la red es anlogo a la programacin convencional
pro-gramacin. Aunque un programador puede crear aplicaciones convencionales sin bajo
data, compiladores, sistemas operativos, arquitectura de computadores, conocimiento de
los sistemas subyacentes puede ayudar a un programador crear ms fiable, correcto y
eficiente de los programas. Igualmente, el conocimiento de la red subyacente sistema
permite un programa-mer a escribir un mejor cdigo. El punto puede resumirse:

Un programador que entiende los mecanismos y tecnologas de red


subyacentes pueden escribir aplicaciones de red que son ms reli-able,
correcta y eficiente.

1.3.2 Las comunicaciones de datos

El trmino para las comunicaciones de datos se refiere al estudio de los mecanismos


de bajo nivel y las tecnologas utilizadas para enviar informacin a travs de un medio de
comunicacin fsica, tales como cables, ondas de radio, o haz de luz. Las comunicaciones
de datos es principalmente el dominio de la ingeniera elctrica, que estudia cmo disear
y construir una amplia gama de sistemas de comunicacin. Las comunicaciones de datos
se centra en las formas de utilizar los fenmenos fsicos para transferir informacin. Por lo
tanto, muchas de las ideas bsicas que se derivan de las propiedades de la materia y la
energa que han sido estudiados por los fsicos. Por ejemplo, veremos que las fibras pticas
utilizadas para transferencia de datos de alta velocidad se basan en las propiedades de la
luz y su reflejo en un lmite entre dos tipos de materia.
Porque aborda los conceptos fsicos, las comunicaciones de datos puede parecer algo
irrelevante para nuestra comprensin de las redes. En particular, porque muchos de los
trminos y conceptos que se refieren a fenmenos fsicos, el sujeto puede slo parecen
tiles para en-
4 Introduccin y presentacin Cap. 1

Gineers que disean las instalaciones de transmisin de bajo nivel. Por ejemplo, la
modulacin tech-niques que utilizan formas de energa fsica, tales como la radiacin
electromagntica, para transportar en formacin parecen ser irrelevantes para el diseo y
el uso de protocolos. Sin embargo, veremos que varios conceptos fundamentales que
surgen a partir de las comunicaciones de datos que influyen en el diseo de muchos niveles
de protocolo. En el caso de modulacin, el concepto de ancho de banda se relaciona
directamente con el rendimiento de la red.
Como un caso especfico, las comunicaciones de datos se introduce la nocin de
multiplexado que permite que la informacin procedente de varias fuentes para ser
combinadas para la transmisin a travs de un medio compartido y luego separado para la
entrega a mltiples destinos. Veremos que el multiplexado no se limita a la transmisin
fsica - la mayora de los protocolos incluyen algn tipo de multiplexacin. Asimismo,
introdujo el concepto de cifrado en comunicaciones de datos constituye la base de la
mayora de las redes de seguridad. As, podemos resumir la importancia:

Aunque se trata con muchos detalles de bajo nivel, comunicaciones de


datos proporciona un fundamento de conceptos sobre los que el resto de
la red se ha construido.

1.3.3 y las tecnologas de red de conmutacin de paquetes

En la dcada de 1960, un nuevo concepto ha revolucionado las comunicaciones de


datos: La conmutacin de paquetes. Principios de las redes de comunicacin han
evolucionado a partir de sistemas telegrfico y telefnico que conecta un par de hilos de
cable fsico entre dos partes para formar un circuito de comunicacin. Aunque la conexin
mecnica de los cables est siendo reemplazado por interruptores electrnicos, el
paradigma subyacente sigue siendo el mismo: formar un circuito y luego enviar la
informacin a travs del circuito. Conmutacin de paquetes de red ha cambiado de manera
fundamental, y sent las bases de la moderna Internet: en lugar de formar un circuito
dedicado, pack-et de conmutacin permite varios emisores para transmitir datos a travs
de una red compartida. La conmutacin de paquetes se basa en los mismos mecanismos de
comunicaciones de datos fundamentales como el sistema telefnico, pero utiliza los
mecanismos subyacentes de una manera nueva. La conmutacin de paquetes divide los
datos en bloques pequeos, llamados paquetes, e incluye una identificacin de la en-
tendido destinatario en cada paquete. Dispositivos de toda la red cada uno tiene
informacin acerca de cmo llegar a cada destino posible. Cuando un paquete llega a uno
de los de-vicios, el dispositivo elije un camino a travs del cual enviar el paquete, de modo
que el paquete finalmente llega al destino correcto.
En teora, la conmutacin de paquetes es sencillo. Sin embargo, muchos diseos son
posi-ble, en funcin de las respuestas a preguntas bsicas. Cmo debe ser un destino
identi-zos, y cmo puede un remitente Busque la identificacin de un destino? cun
grande debera ser un paquete? Cmo puede una red reconocen el final de un paquete y el
comienzo de otro paquete? Si muchos equipos estn enviando a travs de una red, cmo
puede su coordi-nate para garantizar que cada una recibe una justa oportunidad para enviar?
Cmo puede ser adaptado de conmutacin de paquetes para redes inalmbricas? Cmo
pueden ser diseadas para tecnologas de red
Sec. 1.3 Los cinco aspectos clave de las redes 5

Satisfacer varios requisitos para la velocidad, la distancia y el costo econmico? Se han


propuesto muchas respuestas, y muchas de las tecnologas de conmutacin de paquetes han
sido creados. De hecho, cuando uno estudia las redes de conmutacin de paquetes, una
conclusin fundamental:

Porque cada tecnologa de red se crea para satisfacer diversos


requisitos de para la velocidad, la distancia y el costo econmico,
existen muchas tecnologas de conmutacin de paquetes. Tecnologas
difieren en detalles como el tamao de los paquetes y el mtodo utilizado
para identificar a un destinatario.

1.3.4 El Internetworking con TCP/IP

En la dcada de 1970, otra revolucin en las redes de computadoras surgieron: el


concepto de Internet. Muchos investigadores que investigaron la conmutacin de paquetes
busc un paquete nico-et tecnologa de conmutacin que podra hacer frente a todas las
necesidades. En 1973, Vinton Cerf y Robert Kahn observ que ninguna tecnologa de
conmutacin de paquetes llegaran a satisfacer todas las necesidades, especialmente porque
sera posible construir tecnologas de baja capacidad para hogares u oficinas a muy bajo
costo. La solucin, dijo, era dejar de tratar de encontrar una mejor solucin y, en su lugar,
explorar la interconexin de conmutacin de paquetes muchos tecno-tecnologas en un
conjunto funcional. Se propone que un conjunto de normas se desarroll para tal
interconexin, y las consiguientes normas pas a ser conocido como el TCP /IP en Internet
Protocol Suite (generalmente abreviado TCP /IP). El concepto, conocido ahora como inter-
networking, es muy potente. Proporciona la base de la Internet mundial, y constituye una
parte importante del estudio de las redes de computadoras.
Una de las principales razones del xito de TCP /IP estndares radica en su toler-ance
de heterogeneidad. En lugar de intentar dictar detalles acerca de las tecnologas de
conmutacin de paquetes, como tamaos de paquetes o el mtodo utilizado para identificar
un destino, TCP /IP toma un enfoque de virtualizacin que define una red independiente
de paquete y un esquema de identificacin de red independiente y, a continuacin,
especifica cmo los paquetes virtuales estn asignadas a cada posible red subyacente.
Curiosamente, TCP /IP la capacidad de tolerar nuevas redes de conmutacin de
paquetes es un ma-jor motivacin para la continua evolucin de las tecnologas de
conmutacin de paquetes. Como la Internet crece, los equipos se vuelven ms poderosos y
aplicaciones enviar ms datos, especialmente imgenes grficas y de vdeo. Para dar cabida
a aumentos en el uso, ingenieros inventar nuevas tecnologas que pueden transmitir ms
datos y procesar ms paquetes en un momento dado. A medida que se inventaron, las
nuevas tecnologas estn incorporadas en el Internet junto con ex-tant tecnologas. Es decir,
debido a que el Internet tolera la heterogeneidad, los ingenieros pueden experimentar con
nuevas tecnologas de red sin interrumpir las redes existentes. Para resumir:
6 Introduccin y presentacin Cap. 1

La Internet est formada por la interconexin de mltiples redes de


conmutacin de paquetes. El Internetworking es sustancialmente ms
potente que un pecado-gle tecnologa networking porque el enfoque
permite nuevas tecno-tecnologas para ser incorporados en cualquier
momento, sin requerir la sustitucin-cin de las viejas tecnologas.

1.4 Public And Private Parts Of The Internet

A pesar de que funciona como un nico sistema de comunicacin, Internet se


compone de piezas que pertenecen y son operados por personas u organizaciones. Para
ayudar a clarificar propio-ciacin y propsito, de la industria de networking utiliza los
trminos " red pblica y la red privada.

1.4.1 Red pblica

Una red pblica se ejecuta como un servicio que est disponible para los suscriptores.
Cualquier individu-al o corporacin que paga la cuota de suscripcin pueden usar la red.
Una empresa que ofrece servicio de comunicacin es conocido como un proveedor de
servicios. El concepto de un proveedor de servicios es muy amplia, y se extiende ms all
de los proveedores de servicios de Internet (ISP). De hecho, la terminologa se origin con
empresas que ofrecen servicio telefnico de voz analgica. Para resumir:

Una red pblica es propiedad de un proveedor de servicio, y ofrece


servicio a cualquier individuo u organizacin que paga la cuota de
suscripcin.

Es importante entender que el trmino pblico se refiere a la disponibilidad general


de servicio, no de los datos transferidos. En particular, muchas redes pblicas siguen
estrictas normativas gubernamentales que requieren que el proveedor para proteger la
comunicacin desde el inun-tendido snooping. El punto es:

El trmino significa un servicio pblico est disponible para el pblico


en general; los datos transferidos a travs de una red pblica no es
revelado a los forasteros.

1.4.2 Red Privada

Una red privada es controlada por un grupo en particular. Aunque pueda parecer
sencillo, la distincin entre lo pblico y lo privado partes de Internet puede ser sutil porque
el control no siempre implica la propiedad. Por ejemplo, si una empresa arrienda un circuito
de datos de un proveedor y luego limita el uso del circuito a empresa traf-fic, el circuito
pasa a formar parte de la red privada de la empresa. El punto es:
Sec. 1.4 Partes pblicas y privadas de Internet 7

Una red se dice que si el uso privado de la red est restringido a un solo
grupo. Una red privada puede incluir los circuitos arrendados a partir
de un pro-vider.

Los proveedores de equipos de redes Redes privadas se dividen en cuatro categoras:

Consumidor
Oficina pequea/oficina domstica (SOHO)
Small-To-Medium Business (SMB)
Grandes empresas

Porque las categoras se refieren a ventas y marketing, la terminologa est vagamente


de una multa. Aunque es posible dar una descripcin cualitativa de cada tipo, uno no puede
encontrar una definicin exacta. As, los prrafos siguientes proporcionan una amplia
caracterizacin de tamao y propsito, en lugar de las medidas detalladas.
Consumidor. Una de las formas menos costosas de red privada consta de una red de
rea local (LAN) que posee un individuo - si una persona compra un switch LAN barato y
utiliza el interruptor para conectar una impresora a un PC, el individuo ha creado una red
privada. Anlogamente, un router inalmbrico constituye una red privada que un
consumidor puede pur-Chase e instalar.
Oficina pequea/oficina domstica (SOHO). Una red SOHO es ligeramente ms
grande que una red de consumidores. Una tpica red SOHO conecta dos o ms equipos,
una o ms impresoras, un router que se conecta a Internet, y posiblemente en otros
dispositivos, como una caja registradora. La mayora de instalaciones de SOHO incluyen
una batera de alimentacin de reserva y otros mecanismos que les permiten operar sin
interrupcin.
Small-To y medianas empresas (Pymes). Una red SMB puede conectar muchos
comput-ers en varias oficinas en un edificio, y tambin puede incluir equipos en una
produccin fa-cility (por ejemplo, en un departamento de envos). A menudo una red SMB
contiene varios conmutadores de capa 2 interconectadas por routers, utiliza una conexin
a Internet de banda ancha, y podr incluir en los puntos de acceso inalmbrico.
Gran Empresa. Una gran empresa red proporciona la infraestructura necesaria para
una gran corporacin. Una tpica gran empresa red conecta varios sitios geogrficos con
varios edificios en cada sitio, utiliza muchos routers y switches de Capa 2, y tiene dos o
ms conexiones de alta velocidad a Internet. Las redes empresariales suelen incluir tanto
las tecnologas inalmbricas y cableadas.
Para resumir:
Una red privada puede servir a un consumidor individual, una
pequea oficina, una pequea a mediana empresa, o una gran
empresa.
8 Introduccin y presentacin Cap. 1

1.5 Networks, Interoperability, And Standards

La comunicacin siempre implica al menos dos entidades, uno que enva la


informacin y otro que lo recibe. De hecho, veremos que la mayora de la conmutacin de
paquetes de comunicacin sistemas contienen entidades intermedias (es decir, dispositivos
que reenviar los paquetes). La im-portant punto a tener en cuenta es que para que la
comunicacin sea exitosa, todas las entidades en una red debe ponerse de acuerdo sobre
cmo la informacin estar representada y comunicados. Acuerdos de comunicacin
involucra muchos detalles. Por ejemplo, cuando dos entidades se comunican a travs de
una red cableada, ambas partes deben estar de acuerdo con los voltajes que se utiliza, la
manera exacta en que las seales elctricas que se utilizan para representar datos, los
procedimientos utilizados para iniciar y llevar a cabo la comunicacin y el formato de los
mensajes.
Utilizamos el trmino interoperabilidad para referirse a la capacidad de las dos
entidades a comuni-cate, y decir que si dos entidades pueden comunicarse sin ningn
malentendido, puedan interoperar correctamente. Comunicacin para asegurarse de que
todas las partes estn de acuerdo en los detalles y seguir el mismo conjunto de reglas, un
conjunto de especificaciones exactas es escrito. A summar-ize:

Comunicacin implica varias entidades que deben acordar los detalles


que van desde el voltaje elctrico utilizado para el formato y el
significado de los mensajes. Para asegurar que las entidades pueden
interoperar correctamente, reglas para todos los aspectos de la
comunicacin estn escritas.

Siguiente Terminologa diplomtica, utilizamos el trmino Communication


Protocol, protocolo de redo protocolo para referirse a una especificacin para la
comunicacin de red. Especifica un protocolo dado detalles de bajo nivel, tales como el
tipo de transmisin de radio utilizado en una red inalmbrica, o se describe un mecanismo
de alto nivel como los mensajes que dos programas de aplicacin exchange. Nos dice que
un protocolo puede definir un procedimiento que ha de seguirse durante un intercambio.
Uno de los aspectos ms importantes de un protocolo se refiere a situaciones en las que un
error o se produce una condicin inesperada. As, un protocolo usualmente explica las
acciones apropiadas a tomar para cada posible condicin anormal (por ej., la respuesta es
la esperada, pero la respuesta no llega). Para resumir:

Un protocolo de comunicacin especifica los detalles para un aspecto


de com-ordenador comunicacin, incluyendo acciones a ser tomadas
cuando los errores o imprevistos. Un protocolo dado puede especificar
detalles de bajo nivel, como la tensin y las seales que se van a utilizar,
o elementos de alto nivel, tales como el formato de los mensajes que los
programas de aplicacin de Exchange.
Sec. 1.6 Los conjuntos de protocolos y modelos de capas 9

1.6 Protocol Suites And Layering Models

Un conjunto de protocolos que deben construirse con cuidado para garantizar que el
sistema de comunicacin resultante es completa y eficaz. Para evitar la duplicacin de
esfuerzos, por ejemplo, cada protocolo debe manejar una parte de la comunicacin no
gestionadas por otros protocolos. Cmo se puede garantizar que los protocolos funcionan
bien juntos? La respuesta yace en el diseo general del plan: en lugar de crear cada
protocolo en aislamiento, los protocolos estn diseados en completa, cooperativa
establece las llamadas suites o familias. Cada protocolo en una suite controla un aspecto
de la comunicacin; juntos, los protocolos en una suite cubren todos los aspectos de
comunicacin, incluidos los fallos de hardware y otras condiciones excepcionales.
Adems, toda la suite est diseado para permitir que los protocolos para trabajar juntos
Effi-suficiente.
La abstraccin fundamental utilizado para recoger los protocolos en un todo unificado
es conocido como un modelo de capas. En esencia, un modelo de capas describe cmo
todos los aspectos de un problema de comunicacin puede ser dividida en trozos que
trabajan juntos. Cada pieza es conocida como una capa; la terminologa surge porque los
protocolos en una suite estn organizados en una secuencia lineal. Dividir en capas de
protocolos protocolo ayuda tanto a diseadores e im-plementors gestionar la complejidad
por lo que les permite concentrarse en un aspecto de la comunicacin en un momento dado.
La figura 1.1 ilustra el concepto mostrando las capas del modelo utilizado con los
protocolos de Internet. La apariencia visual de las cifras utilizadas para ilustrar layering ha
conducido al trmino coloquial stack. El trmino se utiliza para referirse al protocolo
software en una com-ordenador, como en "hace que el equipo funcione de la pila TCP/IP?".

Aplicacin
Capa 5
La capa
Transporte
4
La capa
Internet
3
La capa
Interfaz de red
2
La capa
Fsica
1

Figura 1.1 el modelo de capas se utiliza con los protocolos de Internet (TCP/IP).

Los captulos posteriores nos ayudar a comprender la estratificacin por explicar los
protocolos de detalle. Por ahora, es suficiente para conocer el propsito de cada capa y
cmo se utilizan los protocolos de comunicacin. Las siguientes secciones resumen el
papel de las capas; una seccin posterior examina cmo los datos pasan a travs de las
capas cuando los equipos se comunican.
10 Introduccin y presentacin Cap. 1

Capa 1: Fsica

Los protocolos de la capa fsica subyacente especificar detalles acerca del medio de
transmisin y el hardware asociado. Todas las especificaciones relacionadas con
propiedades elctricas, frecuencias de radio, y las seales que pertenecen a la capa 1.

Capa 2: Interfaz de red

Los protocolos de la capa de interfaz de red especificar detalles acerca de la


comunicacin entre las capas superiores de los protocolos que, generalmente, se aplican en
el software y la red subyacente, que se implementa en el hardware. Especificaciones acerca
de las direcciones de red y el tamao mximo de paquete que puede soportar una red,
protocolos utilizados para acceder al medio subyacente, y direcciones de hardware
pertenecen a la capa 2.

Capa 3: Internet

Los protocolos de la capa de Internet constituyen la base fundamental de la Internet.


Protocolos de la Capa 3 especificar la comunicacin entre dos equipos a travs de Internet
(es decir, a travs de varias redes interconectadas). La estructura de direccionamiento de
Internet, el formato de los paquetes de Internet, el mtodo para dividir un gran paquete de
Internet en paquetes ms pequeos para la transmisin, y los mecanismos de reporte de
errores pertenece a la capa 3.

Capa 4: Transporte

Los protocolos de la capa de transporte proporciona para la comunicacin desde un


programa de aplicacin en una computadora con un programa de aplicacin en otro.
Especificaciones que controlan la tasa mxima a un receptor puede aceptar los datos, los
mecanismos para evitar la congestin de la red y tcnicas para asegurar que se reciban
todos los datos en el orden correcto pertenece a la capa 4.

Capa 5: Aplicacin

Los protocolos de la capa superior de la pila TCP/IP especifica cmo un par de


aplicaciones interactan cuando se comunican. Protocolos de la Capa 5 se especifican los
detalles sobre el formato y el significado de los mensajes que las aplicaciones pueden
intercambiar, as como procedimientos que se fol-lowed durante la comunicacin.
Especificaciones para el intercambio de mensajes de correo electrnico, transferencia de
archivos, navegacin por internet, servicios telefnicos, video y teleconferencias todos
pertenecen a la capa 5.
algunas publicaciones utilizan el trmino vnculo de datos en lugar de la interfaz de red. En una seccin
posterior, veremos que la ambigedad puede surgir otro modelo utiliza capas de enlace de datos de capa 2.
Sec. 1.7 Cmo pasa a travs de las capas de datos 11

1.7 How Data Passes Through Layers

Capas no es simplemente un concepto abstracto que ayuda a entender los protocolos.


En su lugar, siga las implementaciones del protocolo modelo de capas al pasar la salida de
un protocolo en una capa a la entrada de un protocolo de la capa siguiente. Adems, para
lograr la eficiencia en lugar de copiar todo un paquete, un par de protocolos en capas
adyacentes pasar un puntero al paquete. Por lo tanto, pasa entre las capas de datos de
manera eficiente.
Para comprender cmo funcionan los protocolos, considere dos ordenadores
conectados a una red. La figura 1.2 ilustra protocolos estratificados en los dos equipos.
Como muestra la figura, cada equipo contiene un conjunto de protocolos en capas. Cuando
una aplicacin enva datos, los datos se colocan en un paquete y el paquete saliente pasa
por cada capa de protocolos. Una vez que haya pasado a travs de todas las capas de
protocolos en el ordenador emisor, el paquete deja el ordenador y se transmiten a travs de
la red subyacente de phys-ical. Cuando llega al equipo receptor, el paquete pasa a travs
de las capas de protocolos. Si la aplicacin en el equipo receptor enva una respuesta, se
invierte el proceso. Es decir, una respuesta pasa a travs de las capas en su camino de
salida, y a travs de las capas en el ordenador que recibe la respuesta.

Equipo 1 Equipo 2
Aplicacin Aplicacin

Transporte Transporte

Internet Internet

Net. Interface Net. Interface

Red

La figura 1.2 ilustra cmo pasan los datos entre capas de protocolo cuando el
com-puters comunicarse a travs de una red. Cada equipo dispone
de un conjunto de protocolos de capas de datos y pasa a travs de
cada capa.
La figura muestra slo una red. Cuando estudiamos la arquitectura de Internet, aprenderemos acerca de
mediar entre los dispositivos llamados routers y ver cmo operan los protocolos de capas en Internet.
12 Introduccin y presentacin Cap. 1

1.8 Headers And Layers

Vamos a aprender que cada capa de protocolo de software que realiza clculos en
asegurarse de que los mensajes llegan como se esperaba. Para realizar estos clculos, el
software de protocolo en las dos mquinas deben intercambiar informacin. Para hacerlo,
cada capa en el ordenador emisor antepone la informacin adicional en el paquete; la capa
de protocolo correspondiente en el equipo receptor quita y utiliza la informacin adicional.
Informacin adicional aadida por un protocolo es conocida como un encabezado.
Para entender cmo los encabezados aparecen, piense en un paquete que viaja a travs de
la red entre los dos equipos en la Figura 1.2. Se agregan encabezados por protocolo
software como los datos pasan a travs de las capas del equipo remitente. Es decir, la capa
de transporte antepone un encabezado y, a continuacin, la capa de Internet antepone un
encabezado, y as sucesivamente. Por lo tanto, si tenemos en cuenta que un paquete
atraviese la red, los encabezados aparecen en el orden en que figura 1.3 il-lustrates.

1: Cabecera fsica (es posible, aunque no probable)

2: Cabezal de interfaz de red

3: Encabezado de Internet

4: Encabezado de transporte

La aplicacin enva mensaje

Figura 1.3 El protocolo anidados los encabezados que aparecen en un paquete


como el paquete viaja a travs de una red entre dos ordenadores. En
el diagrama, el comienzo del paquete (el primer bit enviados a travs
de la red subyacente) se muestra a la izquierda.

Aunque la figura muestra los encabezados del mismo tamao, en la prctica los
encabezados no son de tamao uniforme, y una cabecera de la capa fsica es opcional.
Vamos a entender la razn de la disparidad de tamao cuando examinamos contenido del
encabezado. Asimismo, veremos que la capa fsica generalmente especifica cmo las
seales se utiliza para transmitir datos. As, uno no espera encontrar una cabecera de la
capa fsica.
Sec. 1.9 ISO y las siete capas del modelo de referencia OSI 13

1.9 ISO and the OSI Seven Layer Reference Model

Al mismo tiempo, los protocolos de Internet se estn elaborando dos grandes


organismos de normas formado conjuntamente una alternativa de modelo de referencia. Se
cre tambin un conjunto de relaciones entre los protocolos de red. Las organizaciones son:
Organizacin Internacional para la Estandarizacin (ISO)
Unin Internacional de Telecomunicaciones, telecomunicaciones
El Sector de Normalizacin de la UIT (UIT-T)
El modelo de capas ISO es conocido como el Open Systems Interconnection Reference
Model Seven-Layer. Confusin en la terminologa porque el acrnimo de la proto-cols,
OSI, y las siglas de la organizacin, ISO, son similares. Uno es probable encontrar
referencias a ambos el modelo OSI de siete capas y el modelo de capas ISO de siete. La
figura 1.4 ilustra las siete capas del modelo.

Aplicacin
Capa 7

Presentacin
Capa 6
Perodo de
Sesiones
Capa 5
La capa
Transporte
4
La capa
Red
3
La capa
Enlace de
datos
2
La capa
Fsica
1

Figura 1.4 el modelo OSI de siete capas estandarizado por ISO.

1.10 The Inside Scoop

Como la mayora de las organizaciones de normas, la ISO y la UIT utiliza un proceso


que a disposicin de fechas como muchos puntos de vista como sea posible al crear un
estndar. Como resultado, algunos stan-algunas normas pueden parecen haber sido
diseadas por un comit hacer concesiones polticas ms que por ingenieros y cientficos.
Las siete capas del modelo de referencia es controver-sial. De hecho comenzar como un
compromiso poltico. Adems, el modelo y los protocolos OSI fueron diseados como
competidores en los protocolos de Internet.
La ISO y la UIT son enormes cuerpos de estndares que manejan el sistema telefnico
mundial y otras normas mundiales. Los protocolos de Internet y modelo de referencia
fueron
cuando la norma se cre por primera vez, la UIT fue conocido como el Comit Consultivo para la
internacin-AL de Telfonos y Telgrafos (CCITT).
14 Introduccin y presentacin Cap. 1

Creada por un pequeo grupo de aproximadamente una docena de investigadores. Es fcil


ver por qu el stan-normas Las organizaciones podran estar seguros de que podan dictar
un conjunto de protocolos y todos pasaran lejos de protocolos diseados por los
investigadores. En un momento, incluso el gobierno de los EE.UU. estaba convencido de
que TCP /IP debera ser reemplazado por proto-OSI cols.

Finalmente, se hizo evidente que la tecnologa TCP /IP era tcnicamente superior a la
OSI, y en cuestin de pocos aos, los esfuerzos para desarrollar e implementar protocolos
OSI fueron suprimidos. Organismos de Normalizacin se quedaron con el modelo de siete
capas, que no en-clude una capa de Internet. Por lo tanto, durante muchos aos, aboga por
el modelo de siete capas han intentado estirar las definiciones para coincidir con TCP/IP.
Argumentan que la capa tres podra considerarse una capa de Internet y que unos protocolos
de apoyo pueden ser colocados en las capas 5 y 6. Quizs la mayor parte humorstica de la
historia es que muchos ingenieros todava se refieren a aplicaciones como protocolos de
capa 7, incluso cuando saben que las capas 5 y 6 estn vacas e innecesarias.

1.11 Remainder Of The Text

El texto est dividido en cinco partes principales. Despus de una breve introduccin,
los captulos de la primera parte introducir aplicaciones de red y la programacin en red.
Los lectores que tengan acceso a un ordenador son animados a construir y usar programas
de aplicacin que utilizan la Internet mientras leen el texto. Los restantes cuatro partes
explican cmo funcionan las tecnologas subyacentes. La segunda parte describe las
comunicaciones de datos y la trans-sin de informacin. Explica cmo la energa elctricos
y electromagnticos pueden ser utilizados para transportar informacin a travs de cables
o por el aire, y muestra cmo se transmiten los datos.
En la tercera parte del texto se centra en la conmutacin de paquetes y paquetes de
tecnologas. Esto explica por qu las redes informticas utilizan paquetes, describe el
formato general de paquetes, paquetes examina cmo estn codificados para la transmisin,
y muestra cmo cada paquete es para-protegidos a travs de la red a su destino. La tercera
parte del texto tambin presenta las categoras bsicas de las redes informticas, como las
redes de rea local (LAN) y redes de rea amplia (WAN). Se caracteriza las propiedades
de cada categora y discute exmenes ple tecnologas.
La cuarta parte del texto abarca internetworking y los asociados inter-TCP/IP conjunto
de protocolos de red. El texto explica la estructura de la Internet y el protocolo TCP/IP
proto-cols. Explica el esquema de direccionamiento IP, y describe el mapeo entre las
direcciones de Internet y direcciones de hardware subyacente. Tambin trata de
enrutamiento y protocolos de enrutamiento de Internet. La cuarta parte contiene una
descripcin de varios con-cepts fundamentales, entre ellas: la encapsulacin, la
fragmentacin, la congestin y control de flujo, con-nections virtual, traduccin de
direcciones, bootstrapping, IPv6 y diversos protocolos.
La quinta parte del texto abarca una variedad de temas restantes que pertenecen a la
red como un todo en lugar de piezas individuales. Despus de un captulo sobre la red ren-
mance, captulos cubren las tecnologas emergentes, seguridad de red y gestin de red.
Sec. 1.12 Resumen 15

1.12 Summary

El gran conjunto de tecnologas, productos y sistemas de interconexin hacer trabajo


en red de un tema complejo. Hay cinco aspectos clave: aplicaciones de red y trabajar en
red, programacin, comunicaciones de datos y tecnologas de redes de conmutacin de
paquetes-gies, el internetworking con TCP /IP y temas que se aplican en las capas, tales
como la seguridad y la administracin de la red.
Porque varias entidades participan en la comunicacin, debern acordar de colas,
incluyendo caractersticas elctricas, tales como tensin as como el formato y la media-
cin de todos los mensajes. Para asegurar la interoperabilidad, cada entidad est construido
para obedecer un conjunto de protocolos de comunicacin que especifique todos los
detalles necesarios para la comunicacin. Para asegurarse de que los protocolos trabajan
juntos y manejar todos los aspectos de comunicacin, todo un conjunto de protocolos est
diseado al mismo tiempo. La abstraccin central alrededor del cual se construyen proto-
cols se denomina modelo de capas. Estratificacin permite reducir la complejidad
permitiendo que un ingeniero para centrarse en un aspecto de la comunicacin en un
momento dado sin preocuparse por otros aspectos. Los protocolos TCP/IP utilizados en
Internet siguen un modelo de referencia de cinco capas; las compaas telefnicas y de la
Organizacin Internacional de Normalizacin pro-plantea un modelo de referencia de siete
capas.

Ejercicios

1.1 Las razones para el crecimiento de Internet en los ltimos aos.


1.2 Lista diez industrias que dependen de las redes de computadoras.
1.3 Segn el texto, es posible desarrollar aplicaciones de Internet sin la comprensin de la
arquitectura de Internet y de las tecnologas? Justifique su respuesta.
1.4 A qu aspectos de las redes de comunicaciones de datos hace referencia?
1.5 Qu es la conmutacin de paquetes, y por qu es pertinente para la conmutacin de paquetes
de Internet?
1.6 Proporcione una breve historia de la Internet que describe cundo y cmo se inici.
1.7 Qu es la interoperabilidad y por qu es importante en el Internet?
1.8 Qu es un protocolo de comunicacin? Conceptualmente, qu dos aspectos de la
comunicacin no especifica un protocolo?
1.9 Qu es un conjunto de protocolos, y cul es la ventaja de una suite?
1.10 Describir el modelo de capas TCP/IP, y explicar cmo se derivan.
1.11 Enumerar las capas del modelo TCP/IP, y dar una breve explicacin de cada uno de ellos.
1.12 Explicar cmo se agregan y quitan cabeceras como los datos pasan a travs de un modelo de
capas.
1.13 Haga una lista de los principales organismos de normalizacin que crear estndares para
comunicaciones de datos y redes informticas.
1.14 Dar una breve explicar de las capas del modelo de Interconexin de sistemas abiertos ISO.
Contenido del captulo
4.1. Introduccin, 49
4.2 Protocolos Application-Layer, 49
4.3 Representacin y transferencia, 50
4.4. Protocolos Web, 51
4.5 Representacin de documentos HTML, 52
4.6 Los Localizadores Uniformes de Recursos e
hipervnculos, 54
4.7 Transferencia de documentos web con HTTP, 55
4.8 El almacenamiento en cach de los navegadores, 57
4.9 Arquitectura de explorador, 59
4.10 Protocolo de transferencia de archivos (FTP), 59
4.11 Comunicacin FTP Paradigma, 60
4.12 Correo electrnico 63
4.13 El Protocolo simple de transferencia de correo (SMTP),
64
4.14 Proveedores de Servicios de Internet (ISP), servidores de
correo y Acceso al correo, 66
4.15 Protocolos de acceso al correo (POP, IMAP), 67
4.16 Representacin de correo electrnico estndar
(RFC2822), MIME, 67
4.17 El Sistema de nombres de dominio (DNS), 69
4.18. Los nombres de dominio que comienza con www, 71
4.19 La jerarqua del DNS y el modelo de servidor, 72
4.20 Resolucin de nombres, 72
4.21 El almacenamiento en cach de los servidores DNS, 74
4.22 Tipos de entradas de DNS, 75
4.23 Los alias y registros de recursos CNAME, 76
4.24 Abreviaturas y el DNS, 76
4.25 Nombres de Dominio Internacionalizados, 77
4.26 Representaciones extensible (XML), 78
4.27 Resumen, 79
4

Traditional
Internet Applicatio
ns

4.1 Introduction

En el captulo anterior se presentan los temas de programacin de red y aplicaciones


de Internet. El captulo explica que servicios de Internet estn definidas por programas de
aplicacin, y caracteriza el modelo cliente-servidor que tales programas utilizar para
interactuar. El captulo tambin abarca la API de socket.
Este captulo contina con el examen de las aplicaciones de Internet. El captulo de
multas el concepto de un protocolo de transferencia, y explica cmo las aplicaciones
implementan protocolos de transferencia. Por ltimo, el captulo considera las aplicaciones
estndar de Internet, y se describe el protocolo de transferencia de cada uno de los usos.

4.2 Application-Layer Protocols

Cuando un programador crea dos aplicaciones que se comunican a travs de una red,
el programador especifica los detalles, tales como:

La sintaxis y la semntica de los mensajes que pueden ser intercambiados


Si el cliente o el servidor inicia la interaccin
Medidas a adoptar si surge un error
Cmo los dos lados saber cuando finalice la comunicacin
49
50 Aplicaciones de Internet tradicionales
Cap. 4

En Especificar detalles de la comunicacin, un programador define una capa de aplicacin


pro-tocol. Hay dos tipos generales de los protocolos de capa de aplicacin que dependen
de la en-tendido utilice:

La comunicacin privada. Un programador crea un par de


aplicaciones que tenga abiertas que se comunican a travs de Internet
con la intencin de que el par es para uso privado. En la mayora de
los casos, la interaccin entre las dos aplicaciones es sencillo, lo que
significa que un programador puede elegir escribir cdigo sin escribir
un protocolo formal especifi-catin.
Servicio estandarizado. Un servicio de Internet que se define con la
ex-pectation que muchos programadores crear server software para
ofrecer el servicio o software cliente para acceder al servicio. En tales
casos, el protocolo de capa de aplicacin debe estar documentado
inde-dent de cualquier aplicacin, y la especificacin debe ser
precisas y sin ambigedades, de modo que todos los clientes y
servidores pueden interoperar correctamente.

El tamao de una especificacin del protocolo depende de la complejidad del servicio;


las especificaciones para un servicio trivial puede caber en una sola pgina de texto. Por
ejemplo, los protocolos de Internet incluyen un servicio estandarizado de aplicaciones
conocidas como el da que al-bajos un cliente para encontrar la fecha y hora local en una
ubicacin del servidor. El protocolo es sencillo: un cliente forma una conexin a un
servidor, el servidor enva una representacin ASCII de la fecha y la hora, y el servidor
cierra la conexin. Por ejemplo, un servidor puede enviar una cadena como:

Sat Sep 9 20:18:37 2008

El cliente lee los datos de la conexin hasta el final del archivo se encuentra.
Para resumir:

Para permitir que las aplicaciones de servicios estandarizados para


interoperar, un estndar de protocolo de capa de aplicacin creado es
independiente de cualquier aplicacin.

4.3 Representation And Transfer

Los protocolos de capa de aplicacin especifica dos aspectos de la interaccin: la


representacin y la transferencia. Figura 4.1 explica la distincin.
Sec. 4.3Representation y transferencia 51

Aspecto Descripcin
Representacin de Sintaxis de elementos de datos que se
datos. intercambian, especficos
Formulario utilizado durante la transferencia,
traduccin de enteros,
Caracteres y archivos entre ordenadores
La transferencia de Interaccin entre el cliente y el servidor, el
datos mensaje
Sintaxis y semntica, intercambio vlidos y no
vlidos
Manejo de errores, la terminacin de la relacin
de interaccin

Figura 4.1 Dos aspectos clave de un protocolo de capa de aplicacin.

Para un servicio bsico, un nico protocolo estndar puede especificar ambos


aspectos; ms com-plex de uso de servicios estndares de protocolo independiente para
especificar cada aspecto. Por ejemplo, el protocolo da descrito anteriormente utiliza un
nico estndar para especificar que la fecha y la hora se representan como una cadena
ASCII, y que la transferencia se compone de un servidor que enva la cadena y, a
continuacin, cerrar la conexin. La siguiente seccin explica que la web utiliza protocolos
separados para describir la sintaxis de la pgina web y la pgina web de transferencia.
Protocolo diseadores hacen la distincin clara:

Por convencin, la palabra transferencia en el ttulo de un protocolo de


capa de aplicacin significa que el protocolo especifica el aspecto de la
transferencia de datos de comunicacin.

4.4 Web Protocols

La World Wide Web es uno de los servicios ms usados en Internet. Ser causa de la
Web es complejo, muchos estndares de protocolo han sido ideadas para especificar vari-
ous aspectos y detalles. La figura 4.2 muestra las tres normas fundamentales.

Standard Finalidad
Lenguaje de marcado Una representacin estndar utilizado para
de hipertexto especificar el
Lenguaje (HTML) El contenido y el diseo de una pgina web

Uniform Resource Una representacin que especifica el estndar


El formato y el significado de los identificadores
Localizador (URL) de pgina web
Protocolo de
transferencia de Un protocolo de transferencia que especifica
hipertexto cmo el navegador
Interacta con un servidor web para transferir
Protocolo (HTTP). datos

Figura 4.2 tres normas clave que el servicio World Wide Web utiliza.
52 Aplicaciones de Internet tradicionales
Cap. 4

4.5 Document Representation With HTML

El Lenguaje de marcado de hipertexto (HTML) es un estndar de representacin que


speci-fies la sintaxis de una pgina web. El cdigo HTML tiene las siguientes
caractersticas generales:

Utiliza una representacin textual


Describe las pginas que contienen contenido multimedia
Sigue un paradigma ms que de procedimiento declarativo
Proporciona las especificaciones de marcado en lugar de formato
Permite un hipervnculo para ser incorporado en un objeto arbitrario
Permite un documento para incluir metadatos

Aunque un documento HTML se compone de un archivo de texto, el lenguaje permite


un pro-grammer arbitrariamente complejas para especificar una pgina web que contiene
grficos, audio y video, as como de texto. De hecho, para ser exactos, los diseadores
deben haber utilizado hyper-medios en el nombre en lugar de hipertexto HTML porque
permite que un objeto arbitrario, como una imagen, que contienen un enlace a otra pgina
web (a veces llamado un hipervnculo).
HTML est clasificado como porque el lenguaje declarativo slo permite especificar
qu se va a hacer, no cmo hacerlo. HTML est clasificado como un lenguaje de
marcado porque slo proporciona pautas generales para mostrar y no incluye el formato
detallado en structions. Por ejemplo, permite que una pgina HTML para especificar el
nivel de importancia de una partida, pero HTML no requiere que el autor para especificar
la fuente, tipo de fuente, tamao de punto, o el espaciado de la rbrica. En esencia, un
explorador elige mostrar todos los detalles. El uso de un lenguaje de marcado es importante
porque permite que un navegador para adaptar la pgina al mostrar el hardware subyacente.
Por ejemplo, una pgina puede ser formateado para una de resolucin alta o baja resolucin
de pantalla, una pantalla grande o un pequeo dispositivo de mano como un iPhone o PDA.
Para resumir:

Lenguaje de marcado de hipertexto es una representacin estndar para


las pginas web. Para permitir que una pgina se muestre en un
dispositivo arbitrarios, HTML proporciona pautas generales para la
pantalla y permite a un explorador para seleccionar detalles.

Para especificar el marcado, HTML utiliza etiquetas incrustadas en el documento. Las


etiquetas, que constan de un trmino encerrada por menor que y mayor que , smbolos
proporcionan una estructura para el documento, as como sugerencias de formato.
Controlar todas las etiquetas de la pantalla; el espacio en blanco (es decir, ex-tra lneas y
caracteres en blanco) pueden insertarse en cualquier punto del documento HTML sin
ningn efecto sobre la versin con formato que muestra un navegador.
Por ejemplo, un documento HTML comienza con la etiqueta <html>, y termina con
la etiqueta </html>. El par de etiquetas <HEAD> y </HEAD> El soporte de la cabeza,
mientras que el par de

las extensiones HTML han sido creados no permite la especificacin de un exacto de la fuente, tipo de letra,
tamao y formato.
Sec. Representacin 4.5Document con HTML. 53

Etiquetas <CUERPO> y </BODY> el soporte del cuerpo. En la cabeza, las


etiquetas <Title> y </TI-TLE> soporte el texto que constituye el ttulo del
documento. La figura 4.3 ilustra la forma general de un documento HTML.

<html>
<HEAD>
<TITLE>
Texto que constituye el
ttulo del documento </title>
</HEAD>
<body>
Cuerpo del documento aparece aqu
</BODY>
</html>

Figura 4.3 La forma general de un documento HTML.

HTML utiliza la etiqueta IMG para codificar una referencia a una imagen externa.
Por ejemplo, la etiqueta:
<IMG SRC="casa_icon.gif">

Especifica que el archivo house_icon.gif contiene una imagen que el navegador debe
insertar en el documento. Los parmetros adicionales se pueden especificar en una etiqueta
IMG para especificar la alineacin-cin de la figura con el texto de alrededor. Por ejemplo,
la figura 4.4 ilustra la salida para el siguiente cdigo HTML, que alinea el texto con la parte
central de la figura:

Aqu hay un icono de una casa. <IMG SRC="casa_icon.gif" align=middle>

Un navegador coloca la imagen verticalmente para que el texto quede alineado con el
centro de la imagen.

Aqu hay un icono de una casa.

La figura 4.4 ilustra la figura la alineacin en HTML.


HTML no distingue entre maysculas y minsculas en las etiquetas; las maysculas se utiliza en exam-
APA para el nfasis.
54 Aplicaciones de Internet tradicionales
Cap. 4

4.6 Uniform Resource Locators And Hyperlinks

La Web usa un formulario sintctico conocido como un Uniform Resource


Locator (URL) para especificar una pgina web. La forma general de una URL es:

Protocolo://nombre_equipo:puerto/DOCUMENT_nombre%parmetros

Donde es el nombre del protocolo El protocolo utilizado para acceder al


documento, nombre_equipo es el nombre de dominio del equipo en el que se encuentra el
documento,
: Puerto es un nmero de puerto de protocolo facultativo en el que est escuchando el
servidor, Document_name es el nombre opcional del documento en el equipo especificado
y %parmetros ofrecen parmetros opcionales para la pgina.
Por ejemplo, la URL

http://www.netbook.cs.purdue.edu/toc/toc01.htm

Especifica el protocolo http, un equipo llamado www.netbook.cs.purdue.edu, y un archivo


llamado /toc toc01.htm.
Url tpico que escribe un usuario omite muchas de las piezas. Por ejemplo, la
direccin URL:

www.netbook.cs.purdue.edu

Omite el protocolo (http es asumido), el puerto 80 (se supone), el nombre del documento
(index.html se supone) y parmetros (ninguno es asumido).
Una direccin URL contiene la informacin que el navegador necesita para recuperar
una pgina. El navegador utiliza los caracteres separadores colon, Slash, y porcentaje, para
dividir la URL en cuatro com-ponentes: un protocolo, un nombre de equipo, nombre del
documento, y de los parmetros. El explorador utiliza el nombre de equipo y el puerto de
protocolo para formar una conexin con el servidor en el que se encuentra la pgina, y
utiliza el nombre del documento y los parmetros para solicitar una pgina especfica.
En HTML, la etiqueta delimitadora utiliza direcciones URL para proporcionar una
capacidad de hipervnculo (es decir, la habilidad para enlazar desde un documento web a
otro). En el siguiente ejemplo se muestra un documento HTML con un ancla que rodea el
nombre Prentice Hall:

Este libro est publicado por


<A HREF="http://www.prenhall.com">
Prentice Hall, </a> uno de
Las grandes editoriales de libros de informtica.
El ancla hace referencia al URL http://www.prenhall.com. cuando se visualizan en una
pantalla, la entrada produce HTML:

Este libro est publicado por Prentice Hall, uno de los


grandes editores de libros de informtica.
Sec. 4.7 Transferencia de documentos web con HTTP 55

4.7 Web Document Transfer With HTTP

El Protocolo de transferencia de hipertexto (HTTP) es el protocolo de transferencia


principal que el navegador utiliza para interactuar con un servidor web. En trminos del
modelo cliente-servidor, el navegador es un cliente que extrae el nombre del servidor desde
una URL y contacta con el servidor. La mayora de las direcciones URL contienen una
explcita referencia a protocolo de http://, u omitir el protocolo alto-gether, en cuyo caso
se supone que es HTTP.
HTTP puede caracterizarse como sigue:

Utiliza mensajes de control textual


Transfiere archivos de datos binarios
Puede descargar o cargar datos
Incorpora caching

Una vez que se establece una conexin, el navegador enva una peticin HTTP al
servidor.
La figura 4.5 muestra los cuatro principales tipos de peticin:

Solicitud Descripcin
Solicita un documento; el servidor responde enviando el
estado
Obtener
Informacin seguida por una copia del documento
Solicita informacin de estado; el servidor responde enviando
Jefe
La informacin de estado, pero no enva una copia del
documento

Enva los datos a un servidor; el servidor aade los datos a un


POST
Elemento especificado (por ejemplo, un mensaje se adjunta a
una lista).
Enva los datos a un servidor, el servidor utiliza los datos
completamente
Poner
Sustituir el elemento especificado (es decir, sobrescribe los
datos anteriores)

Figura 4.5 Los cuatro principales tipos de peticin HTTP.

La forma ms comn de la interaccin comienza cuando un navegador solicita una


pgina desde el servidor. El navegador enva una solicitud GET a travs de la conexin y
el servidor responde enviando un encabezado, una lnea en blanco, y el documento
solicitado. En HTTP, un re-Quest y un cabezal usado en una respuesta cada constan de
informacin textual. Por ejemplo, una solicitud GET tiene la siguiente forma:

GET /tema version CRLF


56 Aplicaciones de Internet tradicionales
Cap. 4

Donde el elemento proporciona la direccin URL del elemento


solicitado, versin especifica una versin del protocolo (normalmente HTTP/1.0 o
HTTP/1.1), y CRLF indica dos caracteres ASCII, retorno de carro y salto de lnea, que se
utiliza para indicar el final de una lnea de texto.
Informacin sobre la versin de HTTP es importante porque permite que el protocolo
para cambiar y siguen siendo compatibles. Por ejemplo, cuando un navegador que usa la
versin 1.0 del protocolo interacta con un servidor que usa una versin posterior, el
servidor vuelve a la versin anterior del protocolo y formula una respuesta en
consecuencia. Para resumir:

Cuando se usa HTTP, el navegador enva informacin de versin que


permite a un servidor para elegir la versin ms alta del protocolo que
ellos entiendan.

La primera lnea de un encabezado de respuesta contiene un cdigo de estado que


indica al navegador si el servidor maneja la solicitud. Si la solicitud estuviera mal formado
o la re-quested tema no estaba disponible, el Cdigo de situacin agudiza el problema. Por
ejemplo, el servidor devuelve el conocido cdigo de estado 404 si el artculo solicitado no
se ha encontrado. Cuando se honra a una peticin, el servidor devuelve un cdigo de
estado 200; lneas adicionales del cabezal darme ms informacin sobre el tema, como su
longitud, cundo fue la ltima vez que se modific y el tipo de contenido. La figura 4.6
muestra el formato general de las lneas de un encabezado de respuesta bsica.

HTTP/1.0 cdigo
STATUS_status_string server: Server_CRLF
CRLF de identificacin : fecha Last-
Modified_Document_se_changed CRLF Content-
Length: datasize CRLF Content-
Type: document_tipo Crlf Crlf

Figura 4.6 el formato general de las lneas de un encabezado de respuesta bsica.

El estado del campo_code es un valor numrico representado como una cadena de


caracteres de dgitos decimales que denota un status, status_string es una explicacin
correspondiente para un hu-man para leer. La figura 4.7 muestra algunos ejemplos de
cdigos de estado comnmente utilizados y cadenas.
Campo Identificacin_servidor contiene una cadena descriptiva que da una descripcin
legible del servidor, incluyendo posiblemente el nombre de dominio del servidor.
El datasize campo en la cabecera Content-Length especifica el tamao del elemento de
datos que sigue, los AMUMA-ured en bytes. El campo tipo_documento contiene una
cadena que informa al navegador sobre el contenido del documento. La cadena contiene
dos artculos separados por una barra inclinada: el tipo de documento y su representacin.
Por ejemplo, cuando el servidor devuelve un documento HTML,
el documento_type es text/html, y cuando el servidor devuelve un archivo JPEG, el tipo
es imagen/ jpeg.
Sec. 4.7 Transferencia de documentos web con HTTP 57

Cdigo de Cadena de estado


estado correspondiente
200 OK
400 Solicitud incorrecta

404 No encontrado

Figura 4.7 Algunos ejemplos de cdigos de estado utilizados en HTTP.

En la figura 4.8 se muestra un ejemplo de salida de un servidor web Apache. El tema


siendo re-quested es un archivo de texto que contiene 16 caracteres (es decir, el texto Esto
es una prueba ms de un caracter de nueva lnea ). Aunque la solicitud GET especifica la
versin 1.0 de HTTP, el servidor ejecuta la versin 1.1. El servidor devuelve nueve lneas
de encabezado, una lnea en blanco, y el contenido del archivo.

HTTP/1.1 200 OK
Fecha: Sat, 15 Mar 2008 07:35:25 GMT
Servidor: Apache/1.3.37 (Unix).
Last-Modified: Tue, 1 de enero de 2008 12:03:37
GMT
ETag: "78595-81-3883bbe9"
Aceptar intervalos: bytes
Content-Length: 16
Conexin: cerrar
Content-Type: text/plain

Esto es una prueba.

La figura 4.8 muestra una respuesta HTTP del servidor web Apache.

4.8 Caching In Browsers

Cach proporciona una optimizacin importante para acceder a la web porque los
usuarios tienden a visitar los mismos sitios web repetidamente. Gran parte del contenido
en un determinado sitio Web consta de imgenes de gran tamao que utilizan el formato
de imagen grfica (GIF) o conjuntos de codificacin de imagen JPEGestndares de grupo
( ). Esas imgenes contienen a menudo antecedentes o banners que no cambian con
frecuencia. La idea clave es:
Un navegador puede reducir significativamente los tiempos de descarga
por guardar una copia de cada imagen en una memoria cach en el disco
del usuario y el uso de la copia en cach.
58 Aplicaciones de Internet tradicionales
Cap. 4

Surge la pregunta: qu ocurre si el documento en el servidor web los cambios


despus de un navegador almacena una copia en su cach? Es decir, cmo se puede saber
si un navegador su copia en cach est caducado? La respuesta en la Figura 4.8 contiene
una pista: el encabezado Last-Modified. Cuando un navegador obtiene un documento
desde un servidor web, el encabezado especifica la ltima vez que se cambi el documento.
Un navegador guarda la informacin de fecha Last-Modified junto con la copia almacenada
en cach. Antes de que se utiliza un documento de la cach local, un navegador realiza
una peticin al servidor de cabeza y compara la fecha de ltima modificacin de la copia
del servidor a la fecha Last-Modified de la copia en cach. Si la versin en cach est
caducado, el navegador descarga la nueva versin. 4.1 resume el algoritmo de la cach.

4.1 Algoritmo

Dada:
Una direccin URL de un elemento en una pgina web
Obtener:
Una copia de la pgina.
Mtodo:
Si (elemento no est en la cach local) {
Emitir una solicitud GET y coloque una copia en
la cach; } else {
Asunto solicitud HEAD al servidor.
Si (elemento de la cach est actualizada) {
Utilice el elemento almacenado en cach.
} else {
Emitir una solicitud GET y coloque una copia en la memoria
cach.
}
}

4.1 Algoritmo de almacenamiento en cach en un navegador usado para reducir los


tiempos de descarga.

El algoritmo omite varios detalles menores. Por ejemplo, HTTP permite a un sitio
web para incluir un encabezado no-cache que especifica un tema determinado no debe ser
almacenado en cach. En las operacio-nes, los navegadores no almacenar en cach objetos
pequeos porque el tiempo para descargar el tema con una solicitud GET es
aproximadamente la misma que el tiempo para hacer una peticin HEAD y mantener-ing
muchos objetos pequeos en una cach cach puede aumentar los tiempos de bsqueda.
Sec. 4.9 Arquitectura de explorador 59

4.9 Browser Architecture

Porque ofrece servicios generales y admite una interfaz grfica, un explorador es


compleja. Por supuesto, un navegador debe comprender un navegador HTTP, pero tambin
ofrece soporte para otros protocolos. En particular, dado que una direccin URL puede
especificar un protocolo, un navegador debe contener cdigo de cliente para cada uno de
los protocolos utilizados. Para cada servicio, el navegador debe saber cmo interactuar con
un servidor y cmo interpretar las respuestas. Por ejemplo, un navegador debe saber cmo
acceder al servicio FTP se discutirn en el prximo sec-cin. La figura 4.9 ilustra los
componentes que incluye un navegador.

De entrada HTML D
Ratn y Controller Intrprete R
Salida
Teclado Yo
Enviad
V oa
Mostra
E r
Otros
Intrprete R

HTTP Otros
Cliente Cliente

Interfaz de red

La comunicacin a travs de Internet

Figura 4.9 Estructura de un navegador que pueda tener acceso a varios servicios.

4.10 File Transfer Protocol (FTP)

Un archivo de almacenamiento es el pilar fundamental de la abstraccin. Porque un


archivo puede contener un objeto arbitrario (por ejemplo, un documento, una hoja de
clculo, programa informtico, grfico, imagen o datos), FA-cility que enva una copia de
un archivo desde un ordenador a otro proporciona un potente mecanismo para el
intercambio de datos. Utilizamos el trmino " Transferencia de archivo para ese servicio.
Transferencia de archivos a travs de Internet es complicado porque los ordenadores
son heterogene organizativas, lo que significa que cada sistema operativo define
representaciones, tipo de archivo informa-cin, nomenclatura y mecanismos de acceso de
archivo. En algunos equipos, la extensin
. Jpg es usado para una imagen JPEG, y en otros, la extensin es .jpeg. En algunos
sistemas,
60 Aplicaciones de Internet tradicionales
Cap. 4

Cada lnea de un archivo de texto se termina con un carcter de avance de lnea, mientras
que otros sys tem requieren retorno de carro seguido AVLNEA. Algunos sistemas
utilizan slash
(/) Como un separador en los nombres de archivo, y otros utilizan una barra invertida (\).
Adems, un sistema operacional-ing puede definir un conjunto de cuentas de usuario que
son cada dado el derecho de acceso a los archivos cer-tain. Sin embargo, la informacin de
la cuenta difiere entre ordenadores, por lo que el usuario X en un equipo no es el mismo
que el usuario X en otro.
El ms ampliamente implementada en el servicio de transferencia de archivos de
Internet utiliza el protocolo de transferencia de archivos (FTP). FTP puede ser
characteristized como:

El contenido de archivos arbitrarios. FTP puede transferir cualquier


tipo de datos, INCLUD-ing documentos, imgenes, msica o vdeo
almacenado.
Transferencia bidireccional. FTP se puede utilizar para descargar
archivos (transferir desde el servidor al cliente) o cargar archivos
(transferir desde el servidor al cliente).

Soporte para la autenticacin y la propiedad. El FTP permite que


cada archivo tiene la propiedad y las restricciones al acceso, y honra
la restringir-ciones.

Capacidad de navegar por las carpetas. FTP permite a un cliente


obtener el con-carpas de un directorio (es decir, una carpeta).
Controle los mensajes textuales. Como muchos otros servicios de
aplicacin de Internet, el control de mensajes intercambiados entre un
cliente y servidor FTP se envan como texto ASCII.

Acomoda la heterogeneidad. FTP oculta los detalles de cada uno de


los sistemas operativos de ordenador, y puede transferir una copia de
un archivo arbitrario entre un par de equipos.

Porque son pocos los usuarios lanzar una aplicacin de FTP, el protocolo suele ser
invisible. Sin embargo, FTP se invoca automticamente por el navegador cuando un
usuario solicita un archivo de carga.

4.11 FTP Communication Paradigm


Uno de los aspectos ms interesantes del FTP que surge de la forma en que un cliente
y un servidor, interactuar. En general, el enfoque parece bastante sencillo: un cliente
establece una conexin con un servidor FTP y enva una serie de peticiones que el servidor
responde. A diferencia de HTTP, un servidor FTP no enviar respuestas a travs de la misma
conexin por la que el cliente enva solicitudes. En su lugar, la conexin original, llamado
el cliente crea una conexin de control, est reservada para los comandos. Cada vez que
necesita el servidor para cargar o descargar un archivo, el servidor abre una nueva
conexin. Para distinguirlos de la conexin de control, las conexiones utilizadas para
transferir archivos se denominan conexiones de datos.
Sec. 4.11 Paradigma de comunicacin FTP 61

Sorprendentemente, FTP invierte la relacin cliente-servidor para conexiones de


datos. Es decir, cuando se abre una conexin de datos, el cliente acta como un servidor
(es decir, la espera para la conexin de datos) y el servidor acta como un cliente (es decir,
inicia la conexin de datos). Despus de que ha sido utilizado para una transferencia de
datos, la conexin se cierra. Si el cliente enva otra solicitud, el servidor abre una nueva
conexin de datos. La figura 4.10 muestra la interaccin.

Cliente Server

Conexin de un control de formularios de cliente

Cliente enva solicitudes de directorios a travs de la conexin de control

Los formularios de servidor de una conexin de datos

El servidor enva el listado de directorios a travs de la conexin de datos

El servidor cierra la conexin de datos

Cliente enva solicitud de descarga a travs de la conexin de control

Los formularios de servidor de una conexin de datos

El servidor enva una copia del archivo a travs de la conexin de datos

El servidor cierra la conexin de datos

El cliente enva un comando QUIT sobre conexin de control

El cliente cierra la conexin de control

Figura 4.10 Ilustracin de conexiones FTP durante una sesin tpica.

La cifra omite varios detalles importantes. Por ejemplo, despus de crear la conexin
de control, un cliente debe iniciar sesin en el servidor. FTP ofrece un comando de usuario
que enva el cliente para proporcionar un nombre de usuario, y un pase de comando que
enva el cliente a pro-vide una contrasea. El servidor enva una respuesta de estado
numrico sobre el control connec-
62 Aplicaciones de Internet tradicionales
Cap. 4

Cin para dejar saber al cliente si la conexin se ha realizado correctamente. Un cliente


slo puede enviar otros comandos despus de un inicio de sesin es correcto.
Otro detalle importante se refiere al nmero de puerto de protocolo que se utiliza para
una conexin de datos. Qu nmero de puerto de protocolo debe especificar un servidor
cuando se conecta con el cliente? El protocolo FTP ofrece una interesante respuesta: antes
de realizar una solicitud al servidor, un cliente asigna un puerto del protocolo en su sistema
operativo local y enva el nmero de puerto para el servidor. Es decir, el cliente se une al
puerto a la espera de una conexin y, a continuacin, transmite un comando PORT a travs
de la conexin de control para informar al servidor acerca de el nmero de puerto utilizado.
Algoritmo 4.2 resume los pasos.

4.2 Algoritmo

Dada:
Una conexin de control FTP
Lograr:
La transmisin de un elemento de datos a travs de una conexin de
datos FTP
Mtodo:
El cliente enva una solicitud para un archivo especfico sobre
control de la conexin; el servidor recibe la solicitud.
El cliente asigna un puerto de protocolo local, llmese X;
El cliente se vincula al puerto X y se prepara para aceptar una
conexin.
Cliente enva "PUERTO X" al servidor de control de la conexin.
El servidor recibe el comando PORT y solicitud de datos elemento;
Cliente se espera para una conexin de datos en el puerto X y acepta;
Server crea una conexin de datos al puerto X en el equipo del
cliente.
El servidor enva el archivo solicitado a travs de la conexin de
datos.
El servidor cierra la conexin de datos.

4.2 Algoritmo de pasos que un cliente y servidor FTP para usar una conexin de datos.

La transmisin de informacin sobre puertos entre un par de aplicaciones puede


resultar en nocuous, pero no lo es, y la tcnica no funciona bien en todas las situaciones.
En especial-lar, la transmisin de un nmero de puerto de protocolo fallar si uno de los
dos extremos se encuentra detrs de un dispositivo NAT (Network Address Translation),
como un enrutador inalmbrico utilizado en un hogar o una oficina pequea. El captulo
23 explica que el FTP es una excepcin - soporta FTP, un dispositivo NAT reconoce una
conexin de control FTP, inspecciona el contenido de la conexin, y vuelve a los valores
de un comando PORT.

al acceder a archivos pblicos, un cliente utiliza el inicio de sesin annimo, que consta del nombre de
usuario y contrasea annimo invitado.
Sec. 4.12 Correo electrnico 63

4.12 Electronic Mail

Aunque los servicios como la mensajera instantnea se han vuelto populares, el


correo electrnico sigue siendo uno de los ms ampliamente utilizados en aplicaciones de
Internet. Porque fue concebido antes de per-sonal ordenadores y PDA de mano estaban
disponibles, el correo electrnico fue diseado para permitir a un usuario de un equipo
enviar un mensaje directamente a un usuario en otro equipo. La figura 4.11 ilustra la
arquitectura, y Algoritmo 4.3 enumera las medidas adoptadas.

Transferencia Internet
directa

Figura 4.11 La configuracin original del correo con transferencia directa de un


Ordenador del remitente directamente a un ordenador del destinatario.

4.3 Algoritmo

Dada:
Comunicacin por correo electrnico de un usuario a otro.
Proporcionar:
La transmisin de un mensaje para el destinatario.
Mtodo:
Invoca la aplicacin de interfaz de usuario y genera un
mensaje de correo electrnico de usuario x@destino
.com;
Programa de interfaz de correo electrnico del usuario para
la transferencia de mensajes de colas; programa de
transferencia de correo en el ordenador del usuario examina
la
Colas de correo saliente, y encuentra el mensaje;
Se abre el programa de transferencia de correo respecto al destino
.com;
Programa de transferencia de correo utiliza SMTP para transferir el
mensaje.
Programa de transferencia de correo cierra la conexin.
Servidor de correo en .com de destino recibe el mensaje y
coloca una copia en el buzn del usuario x;
Usuario x en el destino .com ejecuta programa de interfaz de
correo, que muestra el buzn del usuario, incluido el nuevo
mensaje.

Algoritmo 4.3 Medidas tomadas para enviar mensajes de correo electrnico en el


paradigma original.
64 Aplicaciones de Internet tradicionales
Cap. 4

Como indica el algoritmo, incluso el software de correo electrnico pronto se dividi


en dos concepto-tually piezas separadas:
Una aplicacin de interfaz de correo electrnico
Un programa de transferencia de correo

Un usuario invoca la aplicacin de la interfaz de correo electrnico directamente. La


interfaz proporciona mecanismos que permiten que un usuario para componer y editar los
mensajes salientes, as como leer y procesar el correo entrante. La interfaz de correo
electrnico aplicacin no actuar como cliente o servidor, y no transferir mensajes a otros
usuarios. En su lugar, la interfaz de la aplicacin lee los mensajes desde el buzn de correo
del usuario (es decir, un archivo en el equipo del usuario) y depsitos de mensajes salientes
en una cola de correo saliente (normalmente una carpeta en el disco del usuario).
Programas separados conocidos como un programa de transferencia de correo y
un servidor de correo manejar la transferencia. El programa de transferencia de correo
acta como cliente para enviar un mensaje al servidor de correo en el equipo de destino; el
servidor de correo acepta mensajes entrantes y depsitos cada una en el buzn de correo
del usuario correspondiente.
Las especificaciones utilizadas para correo electrnico de Internet se puede dividir en
tres grandes categoras, como muestra la figura 4.12.

Tipo Descripcin
Protocolo utilizado para mover una copia de
Transferencia un correo electrnico
Mensaje de un equipo a otro
Un protocolo que permite a un usuario
Acceso acceder a su
Buzn de correo y ver o enviar mensajes de
correo electrnico

Representacin Un protocolo que especifica el formato de un


Cuando el mensaje de correo electrnico
almacenado en disco

Figura 4.12 Los tres tipos de protocolos utilizados con el correo electrnico.

4.13 The Simple Mail Transfer Protocol (SMTP)

El Simple Mail Transfer Protocol (SMTP) es el protocolo estndar de transferencia de


correo que un programa utiliza para transferir un mensaje de correo electrnico a travs de
Internet a un servidor. SMTP puede caracterizarse como:
Sigue un arroyo paradigma
Utiliza mensajes de control textual
Slo transfiere mensajes de texto
Permite a un remitente para especificar los nombres de los destinatarios y
verificar cada nombre
Enva una copia de un mensaje determinado
Sec. 4.13 El Protocolo simple de transferencia de correo (SMTP) 65

El aspecto ms inesperado de SMTP surge de su restriccin al contenido textual. Una


seccin ms adelante explica el estndar MIME que permite incluir archivos adjuntos de
correo electrnico como imgenes grficas o archivos binarios, pero el mecanismo SMTP
subyacente es restringir-ed al texto.
El segundo aspecto de SMTP se centra en su capacidad para enviar un nico mensaje
a mul-tiple destinatarios en un equipo determinado. El protocolo permite a un cliente para
una lista de los usuarios de uno en uno y, a continuacin, enviar una sola copia de un
mensaje para todos los usuarios de la lista. Es decir, un cliente enva un mensaje "Tengo
un mensaje de correo electrnico a un usuario", y el servidor responde "OK" o "No existe
ese usuario aqu". De hecho, cada servidor SMTP mensaje comienza con un cdigo
numrico; por lo tanto, las respuestas son del tipo "250 OK" o "550 No existe ese usuario
aqu". Figura 4.13 da un ejemplo de sesin SMTP que se produce cuando un mensaje de
correo electrnico se transfiere del usuario John_Q_Smith en el equipo example.edu para
dos usuarios en el equipo somewhere.com

Servidor: 220 somewhere.com Simple Mail Transfer Service Ready

Cliente: HELO example.edu


Servidor:: 250 OK
Cliente: MAIL FROM:<John_Q_Smith@example.edu>
Servidor: 250 OK

Cliente: RCPT TO:<Mathew_Doe@somewhere.com>


Servidor: 550 No existe ese usuario aqu

Cliente: RCPT TO:<Paul_Jones@somewhere.com>


Servidor: 250 OK

Cliente: Datos
Servidor: 354 entrada Start Mail; terminar con <CR><LF>.<CR><LF>
Cliente: ...enva el cuerpo del mensaje de correo electrnico,
que pueden contener
Cliente: ...arbitrariamente muchas lneas de texto
Cliente: <CR><LF>.<CR><LF>
Servidor: 250 OK

Cliente: Salir
Servidor: 221 somewhere.com cerrando el canal de transmisin

La figura 4.13 muestra un ejemplo de sesin SMTP.

En la figura, cada lnea est etiquetada : cliente o servidor: para indicar si el servidor
o el cliente enva la lnea; el protocolo no incluye las etiquetas. El HELO my com permite
que el cliente se autentifique enviando su nombre de dominio. Finalmente, la
notacin <CR><LF> indica un retorno de carro seguido por un salto de lnea (es decir, un
final de lnea). As, el cuerpo de un mensaje de correo electrnico se termina con una lnea
que consta de un perodo con ningn otro texto o espaciado.
66 Aplicaciones de Internet tradicionales
Cap. 4

El trmino simple en el nombre implica que SMTP est simplificado. Porque un


prede-cessor a SMTP era increblemente compleja, los diseadores han eliminado las
caractersticas innecesarias y se concentr en los aspectos bsicos.

4.14 ISPs, Mail Servers, And Mail Access

Como el Internet se ampli para incluir a los consumidores, surgi un nuevo


paradigma para el correo electrnico. Porque la mayora de los usuarios dejar su ordenador
funcionando continuamente y no sabe cmo configurar y administrar un servidor de correo
electrnico ISP, comenz a ofrecer servicios de correo electrnico. En esencia, un ISP
ejecuta un servidor de correo electrnico y proporciona un buzn para cada suscriptor. En
lugar de los tradicionales de software de correo electrnico, cada uno de los ISP
proporciona una interfaz de software que permite a un usuario de ac-ceso su buzn de
correo. La figura 4.14 muestra la disposicin.

Acceso a Acceso a
correo correo
electrnico Server Server electrnico
En ISP SMTP
Protocolo Protocolo
utilizado usado Internet En ISP utilizado

Figura 4.14 Un correo electrnico configuracin donde un ISP ejecuta un


servidor de correo electrnico y proporciona a los usuarios acceso
a un buzn de correo.

Acceso a correo electrnico sigue uno de dos formas:

Un objetivo especial de aplicacin de la interfaz de correo


electrnico
Un navegador web que acceda a una pgina web por correo
electrnico

El navegador web enfoque es sencillo: un ISP proporciona una pgina web especial
que muestra los mensajes de un buzn de correo del usuario. Por lo tanto, un usuario inicia
un explorador web estndar y accede al ISP. La pgina web solicita al usuario un
identificador de inicio de sesin y la contrasea que el servidor web utiliza para identificar
el buzn del usuario. El servidor web recupera mes-sabios desde el buzn, y muestra los
mensajes como una pgina web. La principal ventaja de utilizar una pgina web para correo
electrnico surge de la habilidad para leer el correo electrnico desde cualquier ordenador
- un usuario no necesita ejecutar una aplicacin de interfaz de correo especial.
La ventaja de utilizar una aplicacin de correo especial radica en la posibilidad de
descargar todo un buzn en un equipo local. La descarga es particularmente importante
para los usuarios mviles que tienen un ordenador porttil. Cuando el porttil est
conectado a Internet, un usuario puede ejecutar un programa de correo electrnico que
descarga todo un buzn de correo en el ordenador porttil. A continuacin, el usuario puede
procesar el correo electrnico cuando el porttil est desconectado de Internet (p. ej.,
mientras que el del avin). Una vez recuperada la conectividad de Internet, el software en
el ordenador porttil se comunica con el servidor del proveedor de servicios de Internet
(ISP) para cargar el correo electrnico que el usuario ha creado y descargar los nuevos
mensajes que hayan llegado en el buzn del usuario.
Sec. 4.15 Protocolos de acceso al correo (POP, IMAP) 67

4.15 Mail Access Protocols (POP, IMAP)

Se han creado los protocolos que proporcionan acceso al correo electrnico. Un


protocolo de acceso est dis-tinct desde un protocolo de transferencia porque el acceso slo
afecta a un nico usuario interactuar con un nico buzn, mientras que la transferencia de
protocolos permiten a un usuario enviar correo a otros usuarios. Protocolos de acceso
tienen las siguientes caractersticas:

Proporcionar acceso a un buzn de usuario


Permitir que un usuario pueda ver los encabezados, descargar, eliminar o enviar
mensajes individuales
El cliente se ejecuta en el ordenador personal del usuario
Se ejecuta en un equipo servidor que almacena el buzn de correo del usuario

La capacidad para ver una lista de los mensajes sin necesidad de descargar el contenido del
mensaje es especialmente til en los casos en que el vnculo entre un usuario y un servidor
de correo es lento. Por ejemplo, si un usuario navega en un telfono celular puede mirar
los encabezados y eliminar el spam sin tener que esperar para descargar el contenido del
mensaje.
Una variedad de mecanismos han sido propuestos para acceder al correo electrnico.
Algunos ISPs ofrecen software de acceso gratuito por correo electrnico a sus suscriptores.
Adems, dos protocolos de acceso de correo electrnico estndar se han creado. La figura
4.15 muestra los nombres de protocolo estndar.

Acrnimo Ampliacin
Protocolo de oficina de correos
POP3 versin 3

IMAP Internet Mail Access Protocol

Figura 4.15 Los dos protocolos de acceso de correo electrnico estndar.

A pesar de ofrecer los mismos servicios bsicos, los dos protocolos difieren en
muchos de colas. En particular, cada uno ofrece su propio mecanismo de autenticacin que
un usuario sigue a identificarse. La autenticacin es necesaria para asegurarse de que un
usuario no accede al buzn de otro usuario.

4.16 Email Representation Standards (RFC2822, MIME)


Dos importantes existen normas de representacin de correo electrnico:

Formato de mensaje de correo RFC2822 Multi-


purpose Internet Mail Extensions (MIME).
68 Aplicaciones de Internet tradicionales
Cap. 4

Formato de mensaje de correo RFC2822. El estndar de formato de mensaje de correo


toma su nombre del documento de estndares de IETF Request For Comments 2822. El
formato es sencillo: un mensaje de correo electrnico es representado como un archivo de
texto y consta de una seccin de encabezado, una lnea en blanco, y un cuerpo. Lneas de
cabecera tienen el siguiente formato:

Palabras clave: informacin

Cuando el conjunto de palabras clave est definido para incluir desde:, a, Asunto:, Cc:y as
sucesivamente. Adems, el cabezal las lneas que comienzan con mayscula X puede
agregarse sin afectar el procesamiento del correo. As, un mensaje de correo electrnico
puede incluir una lnea de cabecera aleatorias tales como:

X-peor-TV-Muestra: cualquier reality show

Multi-purpose Internet Mail Extensions (MIME). Recordar que SMTP slo admite
mensajes de texto. El estndar MIME ampla la funcionalidad de correo electrnico para
permitir la transferencia de datos que no sean de texto en un mensaje. MIME especifica
cmo un archivo binario puede ser encod-ed en caracteres imprimibles, incluido en un
mensaje, y decodificados por el receptor.
Aunque se introdujo una norma de codificacin Base64 que se ha vuelto muy popular,
no restringir la codificacin MIME para un formulario especfico. En su lugar, MIME
permite a un remitente y un receptor a elegir una codificacin que es conveniente. Para
especificar el uso de la ENCOD-ing, el remitente incluye lneas adicionales en el
encabezado del mensaje. Adems, MIME permite a un remitente para dividir un mensaje
en varias partes y para especificar una codificacin para cada parte por separado. Por lo
tanto, con mimo, un usuario puede enviar un mensaje de texto y adjuntar una imagen
grfica, una hoja de clculo y un clip de audio, cada uno con su propia encod-ing. El sistema
receptor del mensaje puede decidir cmo procesar los archivos adjuntos (por ejemplo,
guardar una copia en el disco o mostrar una copia).
De hecho, MIME aade dos lneas a un encabezado de correo electrnico: uno para
declarar que MIME se ha utilizado para crear el mensaje y otro para especificar cmo la
informacin MIME es in-cluida en el cuerpo. Por ejemplo, las lneas de cabecera:

MIME-Version: 1.0
Content-Type: multipart/mixed;
Fronteras=Mime_SEPARATOR

Especificar que el mensaje fue compuesta utilizando la versin 1.0 de MIME, y que una
lnea de con-tencin mime_SEPARATOR aparecer en el cuerpo antes de cada parte del
mensaje. Cuando MIME es utilizado para enviar un mensaje de texto estndar, la segunda
lnea se convierte en:
Content-Type: text/plain

MIME es compatible con los sistemas de correo electrnico que no entienda el


estndar MIME o codificacin. Por supuesto, esos sistemas no tienen forma de extraer
archivos adjuntos que no son de texto - que tratan el cuerpo como un solo bloque de texto.
Para resumir:
Sec. 4.16 Representacin de correo electrnico estndar (RFC2822, MIME). 69

El estndar MIME inserta lneas de encabezado adicional para permitir


a los no-texto-tachments para ser enviado en un mensaje de correo
electrnico. Un accesorio es en-codificado como cartas imprimibles, y
un separador de lnea aparece antes de cada accesorio.

4.17 Domain Name System (DNS)

El Sistema de nombres de dominio (DNS) proporciona un servicio que asigna nombres


simblicos legibles para las direcciones de los equipos. Navegadores, software de correo
electrnico, y la mayora de las dems aplicaciones de Inter-net use el DNS. El sistema
proporciona un ejemplo interesante de la interaccin cliente-servidor porque el mapeo no
es realizado por un nico servidor. En su lugar, la informacin de nomenclatura se
distribuyen entre un gran conjunto de servidores situados en sitios a travs del Internet.
Siempre que un programa de aplicacin necesita traducir un nombre, la aplicacin se
convierte en un cliente del sistema de nombres. El cliente enva un mensaje de solicitud a
un servidor de nombres, que encuentra la direccin correspondiente y enva un mensaje de
respuesta. Si no se puede responder a una peticin, un servidor de nombres temporalmente
se convierte en el cliente de otro servidor de nombres, hasta que se encuentre un servidor
que puede responder a la solicitud.
Sintcticamente, cada nombre se compone de una secuencia de segmentos de alfa-
numrico-ed separado por puntos. Por ejemplo, un ordenador en el Departamento de
Ciencias de la computacin en la Universidad de Purdue tiene el nombre de dominio:

Mordred.cs .purdue.edu.

Y un equipo de Cisco, ha incorporado el nombre de dominio:

Anakin .cisco .com

Los nombres de dominio son jerrquicos, con la parte ms significativa del nombre
de la derecha. Ms a la izquierda de un nombre de segmento (mordred y anakin en los
ejemplos) es el nombre de un equipo individual. Otros segmentos en un nombre de dominio
que identificar el grupo que es propietario del nombre. Por ejemplo, el segmento
de purdue da el nombre de una universidad, y Cisco da el nombre de una compaa. DNS
no especificar el nmero de segmentos de un nombre. En su lugar, cada organizacin puede
elegir cuntos segmentos a utilizar para com-puters dentro de la organizacin y qu
representan los segmentos.
El Sistema de nombres de dominio no especifica valores para el segmento ms
importante, lo que se llama un dominio de nivel superior (TLD). Los dominios de nivel
superior son controladas por la Corporacin de Internet para la Asignacin de Nombres y
Nmeros (ICANN), en el que se designa a uno o varios registradores de dominios para
administrar un dominio de nivel superior y aprobar los nombres especficos. Algunos
TLD genrico, lo que significa que generalmente estn disponibles. Otros TLD est
restringida a determinados grupos o agencias gubernamentales. La figura 4.16 muestra
exmenes ple dominios DNS de nivel superior.
70 Internet ApplicationsChap tradicionales. 4

Nombre de
dominio Asignada a
Aero La industria del transporte areo
Arpa Dominio de la infraestructura
Asia Para o sobre Asia
Biz Las empresas
Com Las organizaciones comerciales
Coop Las asociaciones cooperativas
Edu. Instituciones educativas
Gov Gobierno de los Estados Unidos
Info Informacin
Organizaciones de tratados
Int internacionales
Los administradores de recursos
Empleos humanos
Mil Militares de los Estados Unidos
Mobi Proveedores de contenido mvil
Museo Museos
Nombre Las personas
Los principales centros de
Net soporte de red
Las organizaciones no
Org. comerciales
Pro Profesionales Acreditados
Viajes Viajes y Turismo
Cdigo del pas Una nacin soberana

Figura 4.16 Ejemplo los dominios de nivel superior y el grupo al que cada uno
est como firmado.

Una organizacin aplica para un nombre debajo de uno de los dominios de nivel
superior. Por ejemplo, la mayora de las corporaciones estadounidenses elegir registrarse
bajo el dominio com. As, una corporacin llamado foobar pueden solicitar ser dominio
asignado foobar bajo el dominio de nivel superior com. Una vez que la solicitud es
aprobada, Foobar Corporation ser asignado el dominio:
Foobar.com
Una vez que el nombre se ha asignado otra organizacin denominada Foobar puede
solicitar foobar .biz o foobar .org, pero no foobar .com. Adems, una vez foobar .com
Sec. 4.17 El Sistema de nombres de dominio (DNS). 71

Asignado, el Foobar Corporation puede elegir cuntos niveles adicionales para agregar y
el significado de cada uno. As, si Foobar tiene ubicaciones en la costa Este y Oeste, se
pueden encontrar nombres tales como:
Computer1.Este-costa.foobar.com

Foobar o pueden optar por una jerarqua de nombres relativamente plana con todos los
equipos identificados por su nombre y el nombre del dominio de la compaa:
Computer1.foobar.com

Adems de la estructura familiar, el DNS permite a las organizaciones utilizar un


registro geogrfico. Por ejemplo, la Corporacin para las iniciativas nacionales de
investigacin registrado el dominio:
Cnri .reston . nos va .

Debido a que la corporacin se encuentra en la localidad de Reston, Virginia, en los


Estados Unidos.
Por lo tanto, los nombres de los equipos a la corporacin termina en .nosotros en lugar de
a .com.
Algunos pases extranjeros han adoptado una combinacin de espacios geogrficos y
nombres de dominio de organizacin. Por ejemplo, las universidades en el Reino Unido
registrarse bajo el dominio:
Ac.uk

Donde ac es una abreviatura para el sector acadmicoy oficial de UK es el cdigo de pas


para el Reino Unido.

4.18 Domain Names That Begin With www

Muchas organizaciones asignar los nombres de dominio que reflejan el servicio un


equipo pro-porciona. Por ejemplo, un ordenador que ejecuta un servidor para el protocolo
de transferencia de archivos podra ser llamado:
Ftp .foobar.com

Igualmente, en un equipo que ejecuta un servidor web, puede ser llamado:

www .foobar.com

Dichos nombres son nemotcnica, pero no son necesarios. En particular, el uso de


la www para dar nombre a los equipos que ejecutan un servidor web es simplemente una
convencin, un equipo arbitrario puede ejecutar un servidor web, incluso si el nombre de
dominio del equipo no contiene www. Adems, un equipo que tiene un nombre de dominio
a partir de www no es necesario para ejecutar un servidor web. El punto es:
72 Aplicaciones de Internet tradicionales
Cap. 4

Utilizando la primera etiqueta en un nombre de dominio para denotar un


servicio (por ejemplo, www)
Es simplemente una convencin para ayudar a los seres humanos.

4.19 The DNS Hierarchy And Server Model

Una de las caractersticas principales del sistema de nombres de dominio es la


autonoma: el sistema est diseado para permitir que cada organizacin para asignar
nombres a equipos o para cambiar esos nombres sin informar a una autoridad central. Para
lograr autonoma, cada organizacin est autorizada a operar sus servidores DNS por parte
de la jerarqua. Por lo tanto, Purdue Univer-sity opera un servidor de nombres que terminan
en purdue.edu, e IBM Corporation opera un servidor de nombres que terminan
en ibm .com. Cada servidor DNS contiene informacin que vincula el servidor a otros
servidores de nombres de dominio hacia arriba y hacia abajo en la jerarqua. Adems, un
servidor dado pueden replicarse, tal que varias copias fsicas del servidor existentes. La
replicacin es especialmente til para servidores muy utilizados, como los servidores
raz que proporcionan informacin acerca de los dominios de nivel superior. En tales casos,
los administradores deben garantizar que todas las copias son coordinadas de forma que
proporcionan exactamente la misma informacin.
Cada organizacin es libre para elegir los detalles de sus servidores. Por ejemplo, una
empresa pequea que slo tiene unos pocos equipos pueden contratar a un ISP para ejecutar
un servidor DNS. Una gran organizacin que ejecuta su propio servidor pueden elegir
colocar todos los nombres de la organizacin en un nico servidor fsico, o puede optar por
dividir sus nombres entre varios servidores. Por ejemplo, en la figura 4.17 ilustra cmo la
hipottica Foobar cor-poration estructura podra elegir servidores si la empresa tena una
divisin de caramelos y una divisin de jabn.

4.20 Name Resolution

La traduccin de un nombre de dominio a una direccin se denomina resolucin de


nombres, y el nombre se dice que est resuelto a una direccin. Software para realizar la
traduccin es conocido como resolucin de nombre (o simplemente solucionador). En el
socket API, por ejemplo, el solucionador es invocado por llamar a la
funcin gethostbyname. La resolucin se convierte en un cliente, se pone en contacto con
un servidor DNS, y devuelve una respuesta a la persona que llama.
Cada resolucin est configurado con la direccin de uno o ms servidores de nombre
de dominio local. La resolucin constituye un mensaje de peticin de DNS, enva el
mensaje al servidor local, y espera a que el servidor DNS para enviar un mensaje de
respuesta que contiene la respuesta. Una resolucin puede elegir utilizar la corriente o el
paradigma del mensaje cuando communicat-ing con un servidor DNS; la mayora de los
interpretadores que estn configurados para usar un mensaje paradigma ser-causa que
impone menos sobrecarga para una pequea peticin.
Como un ejemplo de resolucin de nombre, examinar la jerarqua de servidores que
figura 4,17una muestra, y asumir un equipo en la divisin de jabn genera una solicitud de
nombre chocolate.candy.foobar .com. La resolucin ser configurado para enviar la
solicitud al servidor DNS local (es decir, el servidor de foobar .com). Aunque no responda
a la solicitud, el servidor sabe que contacte con el servidor para candy.foobar .com, que
puede gen-erate una respuesta.

La importancia de ponerse en contacto con un servidor local primero se harn evidentes cuando hablamos
de almacenamiento en cach.
Sec. 4.20 Resolucin de nombres 73

Com Servidor raz

Servidor
para
Servidor para Foobar Foobar .com
Candy.foobar .com

Caramelo
s Jabn

Peanut Almond Nuez

(a)

Com Servidor raz

Servidor para
Foobar
Foobar .com

Caramelos Jabn

Servidor para
Peanut Almond Nuez
Nogales .candy.foobar .com

(b)

La figura 4.17 una hipottica jerarqua DNS y dos posibles asignaciones de


nombres a los servidores.
74 Aplicaciones de Internet tradicionales
Cap. 4

4.21 Caching In DNS Servers

La localidad de referencia, principio que constituye la base para el almacenamiento


en cach se aplica a la
El Sistema de nombres de dominio de dos formas:

Espacial: Un usuario tiende a buscar los nombres de los equipos


locales con ms frecuencia que los nombres de los equipos remotos
Temporal: Un usuario tiende a buscar el mismo conjunto de
nombres de dominio repetidamente

Ya hemos visto cmo explota DNS localidad espacial: una resolucin de nombre
contactos de un servidor local primero. Para explotar la localidad temporal, un servidor
DNS cachs todas las bsquedas. Al-gorithm 4.4 resume el proceso.

4.4 Algoritmo

Dada:
Un mensaje de solicitud de una resolucin de nombre DNS
Proporcionar:
Un mensaje de respuesta que contiene la direccin
Mtodo:
Extraer el nombre, N, de la solicitud
Si ( server es una autoridad para N ) {
Formulario y enviar una respuesta al
solicitante; else if ( Respuesta a n se encuentra
en la cach ) {
Formulario y enviar una respuesta al
solicitante; else { /* necesita buscar una
respuesta */
Si ( Servidor Autoridad de n es conocido ) {
Enviar la solicitud a la autoridad servidor;
} Else {
Enviar solicitud al servidor raz.
}
Recibir respuesta y poner en cach;
Formulario y enviar una respuesta al solicitante;
}

4.4 Algoritmo de pasos tiene un servidor DNS para resolver el nombre.


Sec. 4.21 El almacenamiento en cach de los servidores DNS 75

De acuerdo con el algoritmo, cuando llega una solicitud para un nombre fuera el
conjunto para que el servidor es una autoridad, ms los resultados de la interaccin cliente-
servidor. El servidor de manera temporal se convierte en un cliente de otro servidor de
nombres. Cuando el servidor devuelve una respuesta, el servidor original guarda en cach
la respuesta y enva una copia de la respuesta a la resolucin de que la solicitud ha llegado.
As pues, adems de conocer la direccin de todos los servidores en la jerarqua, cada
servidor DNS debe saber la direccin de un servidor raz.

La cuestin fundamental en todo el cach se refiere a la duracin de los elementos de


tiempo deben ser almacenados - si un elemento es demasiado largo en cach, el tema
quedarn obsoletos. El DNS resuelve el problema organizando un servidor autoritativo
para especificar un tiempo de espera de cach para cada elemento. Por lo tanto, cuando un
servidor local busca un nombre, la respuesta consta de un registro de recursos que
especifica un tiempo de espera de cach, as como una respuesta. Cuando un servidor
almacena en cach una respuesta, el servidor honra el tiempo de espera especificado en el
registro de recursos. El punto es:

Debido a que cada registro de recursos DNS generadas por un servidor


autoritativo especifica un tiempo de espera de cach, los elementos
pueden ser retirados de una cach DNS cuando se vuelven obsoletos.

Almacenamiento en cach de DNS no se detiene con los servidores: una resolucin


puede almacenar en cach los artculos. De hecho, el solucionador de software en la
mayora de los sistemas informticos cachs de las respuestas de las bsquedas DNS, lo
que significa que las sucesivas peticiones para el mismo nombre no necesita utilizar la red
porque la resolucin puede satisfacer la peticin de la cach en el disco local.

4.22 Types Of DNS Entries

Cada entrada en una base de datos DNS consta de tres elementos: un nombre de
dominio, un tipo de registro, y un valor. El tipo de registro especifica cmo el valor se
interpreta (por ejemplo, que el valor es una direccin IP). Lo que es ms importante, de
una consulta enviada a un servidor DNS especifica un nombre de dominio y un tipo; el
servidor slo devuelve un enlace que coincida con el tipo de consulta.
El tipo principal asigna un nombre de dominio a una direccin IP. Se clasifican esos
enlaces DNS como tipo A, y escriba una bsqueda es utilizado por aplicaciones
como FTP, ping, o un navegador. DNS admite varios otros tipos, incluyendo el tipo MX que
especifica un correo eX-cambiador. Cuando se busca el nombre en una direccin de correo
electrnico, SMTP usa tipo MX. La respuesta que el servidor devuelve coincida con el tipo
solicitado. As, un sistema de correo electrnico recibirn una respuesta que coincida con
el tipo MX. El punto importante es:

Cada entrada de un servidor DNS tiene un tipo. Cuando una resolucin


busca un nombre, la resolucin especifica el tipo que se desea, y el
servidor DNS devuelve slo las entradas que coincidan con el tipo
especificado.
76 Aplicaciones de Internet tradicionales
Cap. 4

El sistema de tipo DNS puede producir resultados inesperados debido a la direccin


devuelta puede depender del tipo. Por ejemplo, una empresa puede decidir utilizar el
nombre corporation .com tanto para servicios web y de correo electrnico. Con el DNS,
es posible para la corporacin para dividir el trabajo entre los distintos equipos mediante
la asignacin de un tipo de bsquedas en un ordenador y tipo MX bsquedas a otra. La
desventaja de ese sistema es que parece ilgico para el ser humano - es posible enviar
correo electrnico a corporation .com incluso si no es posible acceder al servidor web o
hacer ping a la com-ordenador.

4.23 Aliases And CNAME Resource Records

El DNS ofrece un tipo CNAME que es anlogo a un enlace simblico en un archivo


sys tem - la entrada proporciona un alias para otra entrada de DNS. Para entender cmo los
alias pueden ser tiles, supongamos Foobar Corporation tiene dos equipos
denominados hobbes .foobar .com y calvin .foobar .com. Tambin suponga que Foobar
decide ejecutar un servidor web en el equipo hobbes, y quiere seguir la convencin de usar
el nombre de www para el equipo que ejecuta el servidor web de la organizacin. A pesar
de que la organizacin podra elegir cambiar nombre de equipo hobbes, existe una solucin
mucho ms fcil: la organizacin puede crear una entrada CNAME
para www .foobar .com que apunte a Hobbes. Cuando una resolucin enva una solicitud
para www .foobar .com, el servidor devuelve el equipo ad-vestido de Hobbes.
El uso de alias es especialmente til porque permite que una organizacin para
cambiar el ordenador utilizado para un servicio concreto sin cambiar los nombres o ad-
vestidos de las computadoras. Por ejemplo, foobar Corporation puede mover su servicio
web de ordenador a ordenador hobbes calvin moviendo el servidor y cambiar el registro
CNAME en el DNS server - los dos equipos conservan sus nombres originales y las
direcciones IP. El uso de alias tambin permite a una organizacin para asociar varios alias
con un solo equipo. As, Foobar corporation puede ejecutar un servidor FTP y un servidor
web en el mismo equipo, y puede crear registros CNAME:
www .foobar.com
Ftp .foobar.com

4.24 Abbreviations And The DNS

El DNS no incorpore abreviaturas - un servidor slo responde a un nombre completo.


Sin embargo, la mayora de los interpretadores puede ser configurado con una serie de
sufijos que permiten a un usuario para abreviar los nombres. Por ejemplo, cada resolucin
en Foobar Corporation podra programarse para buscar un nombre dos veces: una vez con
ningn cambio y una vez con el sufijo foobar .com anexado. Si un usuario introduce un
nombre de dominio completo, el servidor local devolver la direccin, y el procesamiento
continuar. Si un usuario introduce un nombre abreviado, el
Sec. 4.24 Abreviaturas y el DNS 77

Solucionador primero intentar resolver el nombre y recibirn un error porque no existe tal
nombre. El solucionador entonces intentar anexar un sufijo y buscando el nombre
resultante. Porque una resolucin se ejecuta en el ordenador personal del usuario, este
enfoque permite a cada usuario elegir el orden en el que son juzgados los sufijos.
Por supuesto, lo que permite que cada usuario pueda configurar su solucionador para
manejar abreviaturas tiene una desventaja: el nombre de un determinado usuario puede
diferir del otro nombre de usuario. As, si los nombres de los usuarios se comunican entre
s (por ejemplo, mediante el envo de un nombre de dominio en un mensaje de correo
electrnico), cada uno debe ser cuidadoso para especificar nombres completos y no
abbrevi-aciones.

4.25 Internationalized Domain Names

Porque utiliza el conjunto de caracteres ASCII, el DNS no puede almacenar nombres


de alfabetos que no estn representados en ASCII. En particular, en idiomas como el Ruso,
Griego, Chino y Japons cada contienen caracteres para los cuales no existe representacin
ASCII. Muchas lenguas europeas utilice marcas diacrticas que no puede ser representado
en ASCII.
Durante aos, el IETF debatieron modificaciones y ampliaciones de los DNS a
disposicin da internacional de nombres de dominio. Despus de examinar muchas de las
propuestas, el IETF eligi un enfoque conocido como Internacionalizacin de nombres de
dominio en aplicaciones (IDNA). En lugar de modificar el DNS subyacente, IDNA usa
ASCII para almacenar todos los nombres. Es decir que, cuando se le asigna un nombre de
dominio que contiene un carcter no ASCII, IDNA convierte el nombre en una secuencia
de caracteres ASCII, y almacena el resultado en el DNS. Cuando un usuario busca el
nombre, la misma traduccin se aplica a convertir el nombre en una cadena ASCII y la
cadena ASCII resultante se coloca en una consulta DNS. En esencia, IDNA se basa en
aplicaciones para traducir entre el conjunto de caracteres internacionales que ve un usuario
interno y el formato ASCII utilizados en el DNS.
Las reglas para traducir los nombres de dominio internacionales son complejos y
utilizar ONU-icode. En esencia, la traduccin se aplica a cada etiqueta en el nombre de
dominio, y los resultados de las etiquetas del formulario:

Xn--,

Donde xn-- est reservada, una cadena de cuatro caracteres que indica la etiqueta es un
nombre internacional, es el subconjunto de caracteres de la etiqueta original que puede
ser representado en ASCII, y es una cadena de caracteres ASCII adicionales que indican
una aplicacin IDNA cmo insertar caracteres no ASCII en para formar la versin
imprimible de la etiqueta.
Las ltimas versiones de los navegadores utilizados, Firefox e Internet Explorer,
puede aceptar y mostrar los nombres de dominio no ASCII porque cada implemento IDNA.
Si una aplicacin no aplicar IDNA, la salida puede parecer extrao para un usuario. Es
decir, cuando una aplicacin que no implemente IDNA muestra un nombre de dominio
internacional, el usuario ver la forma interna se ilustra arriba, incluyendo la cadena
inicial xn-- y las partes subsiguientes y .

La traduccin algoritmo utilizado para codificar las etiquetas no-ASCII es conocido como el algoritmo de
enclenque, y la cadena resultante se conoce como Punycode.
78 Aplicaciones de Internet tradicionales
Cap. 4

Para resumir:

El IDNA estndar para los nombres de dominio internacionales codifica


cada la-bel como una cadena ASCII, y se basa en aplicaciones para
traducir entre el conjunto de caracteres que el usuario espera la versin
codificada y almacenada en el DNS.

4.26 Extensible Representations (XML)

Los protocolos de aplicacin tradicionales contemplados en este captulo cada


emplean una representacin fija. Es decir, el protocolo de aplicacin especifica un conjunto
exacto de los mensajes que el cliente y el servidor pueden intercambiar as como la forma
exacta de datos que acompaa al mensaje. La desventaja principal de un determinado
enfoque nace de la dificultad de hacer cambios. Por ejemplo, porque el correo electrnico
normas de restringir el contenido de los mensajes de texto, se necesitaba un cambio
importante para agregar las extensiones MIME.
La alternativa a una representacin fija es un sistema extensible que permite a un
remitente para especificar el formato de los datos. Un estndar para la representacin
extensible ha llegado a ser ampliamente aceptado: el XML ( Extensible Markup Language).
XML se parece a HTML en el sentido de que ambos idiomas incruste etiquetas en un
documento de texto. A diferencia de HTML, las etiquetas XML no estn especificados a
priori y no corresponden a los comandos de formato. En su lugar, XML describe la
estructura de datos y proporciona nombres para cada campo. Las etiquetas en XML estn
bien equilibradas, cada aparicin de una etiqueta <X> debe ser fol-lowed por una
ocurrencia de </X>. Adems, puesto que XML no asigna ningn significado para
etiquetas, nombres de etiquetas se pueden crear como sea necesario. En particular, los
nombres de etiquetas puede ser seleccionado para hacer fcil de analizar datos o acceso.
Por ejemplo, si dos empresas acuerdan intercambiar directorios telefnicos corporativos,
pueden definir un formato XML que tiene elementos de datos, como el nombre de un
empleado, nmero de telfono y oficina. Las empresas pueden optar por dividir an ms
un nombre en un apellido y un nombre. La figura 4.18 muestra un ejemplo.

<Direccin>
<nombre>
<Primero> John </primera>
<ltima> Pblico </ltimo>
</Name>
<OFFICE> Habitacin 320 </Oficina>
<> telfono 765-555-1234
</telfono> </address>
La figura 4.18 muestra un ejemplo de XML para una libreta de telfonos de la empresa.
Sec. 4.27 Resumen 79

4.27 Summary

Los protocolos de capa de aplicacin, necesarios para la normalizacin de los


servicios, definir la representacin de datos y la transferencia de datos de los aspectos de
la comunicacin. Representacin protocolos utilizados con la World Wide Web incluyen
el Lenguaje de marcado de hipertexto (HTML) y el URL estndar. El protocolo de
transferencia de web, el cual es conocido como el Protocolo de transferencia de hipertexto
(HTTP), especifica cmo un navegador se comunica con un servidor web para descargar o
cargar el contenido. A fin de acelerar las descargas, un explorador almacena en cach el
contenido de la pgina y utiliza un comando HTTP HEAD para solicitar informacin sobre
el estado de la pgina. Si la versin en cach sigue siendo actual, el explorador utiliza la
versin en cach; de lo contrario, el navegador-demanda una solicitud GET para descargar
una copia nueva.
HTTP utiliza mensajes textuales. Cada respuesta desde un servidor comienza con un
encabezado que describe la respuesta. Lneas de la cabecera comienzan con un valor
numrico, representados como dgitos ASCII, que indica el estado (por ejemplo, si una
peticin es un error). Los datos mnimos que FOL-el encabezado puede contener valores
binarios arbitrarios.
El Protocolo de transferencia de archivos (FTP) se utiliza con frecuencia para la
descarga del archivo. Re-FTP requiere un cliente para iniciar una sesin en el sistema del
servidor FTP; admite un inicio de sesin annimo y contrasea guest para acceso a archivos
pblicos. El aspecto ms interesante del FTP que surge de su inusual uso de conexiones.
Un cliente establece una conexin de control que se utiliza para enviar una serie de
comandos. Cuando un servidor necesita enviar datos (por ejemplo, la descarga de un
archivo o el listado de un directorio), el servidor acta como un cliente y el cliente acta
como un servidor. Es decir, el servidor inicia una nueva conexin de datos al cliente. Una
vez que un archivo ha sido enviado, se cierra la conexin de datos.
Tres tipos de los protocolos de capa de aplicacin se utilizan con correo electrnico:
transferencia, la representacin y el acceso. El Protocolo simple de transferencia de correo
sirve como clave de transferencia SMTP estndar; slo puede transferir un mensaje textual.
Hay dos repre-cin estndares para correo electrnico: RFC 2822 define el formato de
mensaje de correo electrnico a un encabezado y cuerpo separados por una lnea en blanco.
El Multi-purpose Internet Mail Extensions (MIME) estndar que define un mecanismo para
enviar archivos binarios como archivos adjuntos a un mensaje de correo electrnico. Inserta
lneas de encabezado MIME adicionales que indican el receptor cmo interpretar el
mensaje. MIME requiere un emisor para codificar un archivo como texto imprimible.
Protocolos de acceso a correo electrnico, como POP3 e IMAP, permitir que un
usuario pueda acceder a un buzn de correo. El acceso se ha vuelto popular debido a un
suscriptor puede permitir a un proveedor de servicios de Internet (ISP) para ejecutar un
servidor de correo electrnico y mantener el buzn de correo del usuario.
El Sistema de nombres de dominio (DNS) proporciona asignacin automatizada de
nombres legibles para las direcciones de los equipos. Se compone de muchos servidores
DNS que cada control una parte del espacio de nombres. Los servidores estn dispuestos
en una jerarqua y un servidor conoce las ubicaciones de servidores en la jerarqua.
El DNS utiliza la cach para mantener la eficiencia; cuando un servidor autoritativo
pro-porciona una respuesta, cada servidor que transfiere la respuesta tambin coloca una
copia en su cach. Para evitar las copias en cach de convertirse en obsoletos, la autoridad
de un nombre especifica cunto tiempo se puede almacenar en cach el nombre.
80 Aplicaciones de Internet tradicionales
Cap. 4

Ejercicios

4.1. Qu detalles de un protocolo de aplicacin especificar?


4.2 Por qu es un protocolo de servicio estandarizados documentados independientes de una
aplicacin?
4.3 Cules son los dos aspectos clave de la aplicacin de los protocolos, y qu incluyen cada
una?
4.4. Dar ejemplos de protocolos de la web que ilustran cada uno de los dos aspectos de un protocolo
de aplicacin.
4.5 Resumir las caractersticas de HTML.
4.6 Cules son las cuatro partes de una URL, y qu puntuacin se utiliza para separar las partes?
4.7 Cules son los cuatro tipos de peticin HTTP, y cuando es utilizado cada uno?
4.8 Cmo saber si un navegador una solicitud HTTP es sintcticamente incorrecto o si el elemento
referenciado no existe?
4.9 Qu es la memoria cach del explorador, y por qu se usa el almacenamiento en cach?
4.10 Describir los pasos de una toma del navegador para determinar si desea utilizar un elemento
de su cach.
4.11 Puede utilizar un navegador distinto de HTTP protocolos de transferencia? Explicar.
4.12 Cuando un usuario solicita un listado de directorios FTP, cuntas conexiones TCP estn
formados? Explicar.
4.13 Verdadero o falso: cuando un usuario ejecuta una aplicacin de FTP, la aplicacin acta como
cliente y servidor. Explique su respuesta.
4.14 Un Servidor FTP Cmo saber el nmero de puerto que se utiliza para una conexin de
datos?
4.15 Segn el paradigma de correo electrnico original, un usuario puede recibir mensajes de correo
electrnico si el ordenador del usuario no ejecutar un servidor de correo? Explicar.
4.16 Enumerar los tres tipos de protocolos utilizados con el correo electrnico, y describir cada
uno.
4.17 Cules son las caractersticas de SMTP?
4.18. SMTP puede transferir un mensaje de correo electrnico que contenga un punto en una lnea
por s mismo? Por qu o por qu no?
4.19 Donde es un protocolo de acceso de correo electrnico utiliza?
4.20 Cules son los dos principales protocolos de acceso de correo electrnico?
4.21 Por qu se invent MIME?
4.22 Cul es el objetivo general del sistema de nombres de dominio?
4.23 Suponiendo que la ISO ha asignado n cdigos de pas, cuntos dominios de nivel superior
existen?
4.24 Verdadero o falso: un servidor web debe tener un nombre de dominio que comienza con
www. Explicar.
4.25 Verdadero o falso: una empresa multi-nacional puede elegir dividir su jerarqua de nombres de
dominio, de tal manera que la empresa tiene un servidor de nombre de dominio en Europa, uno
en Asia y uno en Amrica del Norte.
4.26 Cuando un servidor de nombres de dominio, enve una solicitud a un servidor autoritativo y
cuando va a contestar la peticin sin enviar al servidor autoritativo?
4.27 Verdadero o falso: Un servidor DNS puede devolver una direccin IP diferente para un
determinado nombre, dependiendo de si la bsqueda especifica de servicio web o de correo
electrnico. Explicar.
Ejercicios 81

4.28 El estndar de IDNA, exigen cambios en los servidores DNS? En los clientes DNS?
Explicar.
4.29 Buscar en la web para informarse sobre la bsqueda DNS iterativo. Bajo qu circunstancias
se itera-tivo lookup utiliza?
4.30 Cmo permitir que una aplicacin XML para especificar campos tales como nombre y
direccin?
21

IP: Internet Addressing

21.1 Introduction

En el captulo anterior se explica la arquitectura fsica de la Internet en el que los


routers interconectar redes fsicas. Este captulo comienza una descripcin del protocolo
software que hace que la Internet parece ser un sistema de comunicacin sin fisuras. El
captulo presenta el esquema de direccionamiento utilizado por el Protocolo de
Internet (IPv4), y discute el uso de mscaras de direccin classless y direccionamiento de
subred.
Los prximos captulos ampliar la descripcin de IP. Cada uno de ellos considere uno
de los aspectos del protocolo en detalle. Como grupo, los captulos definen el protocolo IP
y ex-plain cmo el software de IP permite a los equipos intercambiar paquetes a travs de
Internet.

21.2 Addresses For The Virtual Internet

Recuerde del Captulo 20 que la meta de internetworking es proporcionar un sistema


de comunicacin fluida. Para lograr el objetivo, el software de protocolo debe ocultar los
detalles de redes fsicas y ofrecer la ilusin de una sola gran red. Desde el punto de vista
de una aplicacin virtual, el Internet funciona como cualquier otra red, permitiendo
comput-ers para enviar y recibir paquetes. La principal diferencia entre Internet y una red
physi-cal es que Internet es una abstraccin imaginada por sus diseadores y creado
enteramente por el software de protocolo. As, los diseadores eligieron direcciones,
formatos de paquetes, y las tcnicas de ejecucin independiente de los detalles del
hardware subyacente.
Direccionamiento es un componente crtico de la abstraccin de Internet. Para dar el
aparecer-ance de una sola red, todos los ordenadores host debe utilizar un esquema de
direccionamiento uniforme, y cada direccin debe ser nica. Aunque cada equipo tiene una
direccin MAC, tal ad-
salvo que se indique lo contrario, la direccin de Protocolo de Internet e IP se refieren a la versin 4 de
IP en todo el texto.

345
346 IP: Direcciones en Internet Cap. 21

Los vestidos no son suficientes, ya que la Internet puede incluir varias tecnologas de red
y cada tecnologa define sus propias direcciones MAC.
Para garantizar la uniformidad, el direccionamiento IP define un esquema de
direccionamiento que es inde-dent de las direcciones MAC. Las direcciones IP se utilizan
como destinos en el internet anlogo a la manera en que las direcciones MAC son utilizados
como destinos en una red LAN. Para enviar un paquete a travs de Internet, el remitente
coloca la direccin IP del destino del paquete, y pasa el paquete de software de protocolo
IP para el reenvo. Software de protocolo IP utiliza la direccin IP de destino cuando se
reenva el paquete a travs de Internet en el equipo de destino.
La ventaja del direccionamiento IP reside en la uniformidad: un par arbitrario de los
programas de aplicacin pueden comunicarse sin saber el tipo de hardware de red o MAC
ad-vestidos utilizado. La ilusin es tan completa que algunos usuarios se sorprenden al
saber que las direcciones IP son suministrados por el software de protocolo y no forman
parte de la red subyacente. Curiosamente, aprenderemos que muchas capas de software del
protocolo IP se utiliza ad-vestidos. Para resumir:

Para proporcionar direccionamiento uniforme en el Internet, IP define


un esquema de direccionamiento abstracta que asigna a cada host una
nica direccin de protocolo; las aplicaciones utilizan las direcciones
IP para comunicarse.

21.3 The IP Addressing Scheme

El estndar IP especifica que cada host tiene asignado un nico nmero de 32 bits
conocido como direccin de Protocolo de Internet del host, direccin IPo direccin de
Internet. Cuando se enva un paquete a travs de Internet, el remitente debe especificar su
propia direccin IP de 32 bits (la direccin de origen), as como la direccin del destinatario
(la direccin de destino).
Para resumir:

Una direccin de Internet (direccin IP) es un nico nmero binario de


32 bits como firmado para un host y utilizado para la comunicacin
con el host.

21.4 The IP Address Hierarchy

Anloga a la de direccionamiento jerrquico con WAN, cada direccin IP de 32 bits


se divide en dos partes: un prefijo y un sufijo. En lugar de identificar un paquete
conmutador, un prefijo IP identifica la red fsica a la que est conectado el host. Un sufijo
IP identifica un equipo especfico en la red. Es decir, cada red fsica en el internet se le
asigna un nico nmero de la red. El nmero de red aparece como un prefijo en la direccin
IP de cada ordenador conectado a la red, y cada equipo de una red fsica determinada se le
asigna un nico sufijo.
Los tres trminos son usados como sinnimos intercambiables.
Sec. 21.4 La jerarqua de direcciones IP 347

Para garantizar la singularidad, no hay dos redes en Internet se le puede asignar el


mismo nmero de red y no hay dos equipos en una red determinada puede asignarse el
mismo sufijo. Por ejemplo, si un internet contiene tres redes, podran asignarse net-trabajar
los nmeros 1, 2y 3. Tres equipos conectados a la red 1 pueden asignarse suf-fija de 1, 3y 5,
mientras que tres equipos conectados a la red 2 pueden asignarse sufijos 1, 2y 3. Los valores
asignados no necesitan ser contiguas.
El punto importante es que el esquema de direccionamiento IP garantiza dos
propiedades:

A cada equipo se le asigna una direccin nica (es decir, una sola
direccin nunca se asigna a ms de un equipo).
Aunque las asignaciones de nmero de red debe ser coordinado
global-ly, sufijos pueden asignarse localmente sin la coordinacin
global.

La primera propiedad est garantizada porque una direccin IP contiene un prefijo y


un sufijo. Si dos equipos estn conectados a redes fsicas diferentes, los prefijos como
firmado a sus direcciones sern diferentes. Si dos equipos estn conectados a la misma red
fsica, sus direcciones tienen distintos sufijos. As, la direccin asignada a un com-
ordenador es nico.

21.5 Original Classes Of IP Addresses

Una vez que se eligi un tamao para las direcciones IP y decidi dividir cada
direccin en dos partes, los diseadores de IP tuvo que determinar cuntos bits para colocar
en cada parte. El prefijo es necesario disponer de suficientes bits para permitir que un
nmero de red nico para ser asignado a cada red fsica en Internet. El sufijo es necesario
disponer de suficientes bits para permitir que cada equipo conectado a una red a la que se
debe asignar un sufijo nico. Simple eleccin no fue posible porque la adicin de bits a una
Parte significa restar bits desde el otro. Choos-ing un prefijo grande acomoda muchas
redes, pero limita el tamao de cada red; elegir un sufijo grande significa que cada red
fsica puede contener muchos equipos, pero limita el nmero total de redes.
Porque el Internet incluye tecnologas de red arbitraria, contiene unas pocas grandes
redes fsicas y muchas redes pequeas. Por consiguiente, los diseadores eligieron un
esquema de direccionamiento para acomodar una combinacin de redes grandes y
pequeas. El plan original, lo que se conoce como direccionamiento IP classful, divide el
espacio de direcciones IP en tres clases de primaria, donde cada clase tiene un tamao
diferente prefijo y sufijo.
Los primeros cuatro bits de una direccin determinada de la clase a la que pertenece
la direccin, y especific cmo el resto de la direccin se divide en prefijo y sufijo. La
figura 21.1 muestra las cinco clases de direcciones, el lder de bits utilizados para identificar
cada clase, y la divisin entre el prefijo y el sufijo. La cifra sigue la convencin utilizada
en los protocolos TCP/IP de bits de numeracin de izquierda a derecha y la utilizacin de
cero para el primer bit.
348 IP: Direcciones en Internet Cap. 21

Bits 0 1 2 3 4 8 16 24 31
Clase A 0 Prefijo Sufijo

Clase B 1 0 Prefijo Sufijo

La clase C 1 1 0 Prefijo Sufijo

La clase D 1 1 1 0 Direccin de multidifusin

La clase E 1 1 1 1 Reservado (No asignado)


Las cinco clases de direcciones IP en la original combinacin de
Figura 21.1 classful.

Aunque el rgimen classful ha sido reemplazado, las direcciones de clase D se utilizan


todava para multidifusin, lo que permite la entrega a un conjunto de equipos. Cada
direccin de multidifusin corresponde a un grupo de equipos. Una vez que se ha
establecido el grupo de multidifusin, una copia de cualquier paquete enviado a la
direccin de multidifusin se entregar a cada host en el grupo. En la prctica, nunca ha
sido de multidifusin de Internet disponible en todo el mundo, lo que significa que la
multidifusin est restringido a sitios individuales.
Podemos resumir:

El esquema de direccionamiento IP original direcciones dividida en


clases. Las direcciones de clase D se utilizan todava para multidifusin,
pero la multidifusin no funciona en todo el mundo.

21.6 Dotted Decimal Notation

Aunque las direcciones IP son nmeros de 32 bits, los usuarios no escribir o leer los
valores en binario. En su lugar, a la hora de interactuar con el usuario, el software utiliza
una notacin ms con-venient del ser humano para comprender. Llama la notacin decimal
con puntos, la forma expresa cada seccin 8 bits de un nmero de 32 bits como un valor
decimal y utiliza perodos para separar las secciones. La figura 21.2 muestra ejemplos de
nmeros binarios y el equivalente de la notacin decimal con puntos.
Sec. 21,6 de la notacin decimal con
puntos 349

32 -b i t Bi nary nmero Equ i va l ent Dot t ed dec l ima


10000001 00110100 00000110 00000000 129 . 52 . 6 . 0

11000000 00000101 00110000 00000011 192 . 5 . 48 . 3

00001010 00000010 00000000 00100101 10 . 2 . 0 . 37

10000000 00001010 00000010 00000011 128 . 10 . 2 . 3

10000000 10000000 11111111 00000000 128 . 128 . 255 . 0

Figura 21.2 Ejemplos de nmeros binarios de 32 bits y su equivalente en


notacin decimal con puntos.

Trata cada decimal punteada cada octeto (8 bits) como un valor binario sin signo
entero. Como ejemplo final de la figura muestra el valor ms pequeo posible, 0, se produce
cuando todos los bits de un octeto son cero, y el mayor valor posible, 255, se produce
cuando todos los bits de un octeto son uno. Por lo tanto, el rango de direcciones en formato
decimal con puntos 0.0.0.0 a 255.255.255.255. Las direcciones de multidifusin, clase D,
ocupan el rango de 224.0.0.0 a 239.255.255.255.
Para resumir:

La notacin decimal con puntos es una forma sintctica que utiliza el


software IP para expresar valores binarios de 32 bits al interactuar con
los seres humanos. Decimal punteada representa cada octeto en decimal
y utiliza un punto para separar octetos.

21.7 Division Of The Address Space

El original sistema classful, que fue elaborado antes de que la PC fue inventado, antes
de que las LAN estuvieran ampliamente disponibles, y antes de que la mayora de las
empresas tenan una red informtica, divide el espacio de direcciones en tamaos
desiguales. Los diseadores eligieron una reparticin desigual para acomodar una variedad
de escenarios. Por ejemplo, aunque se limita a 128 net-works, una clase contiene la mitad
de todas las direcciones. La motivacin era permitir a los principales proveedores de
servicios de Internet (ISP) a cada uno desplegar una gran red que conecta a millones de
ordenadores. Asimismo, la motivacin para la clase C era permitir que una organizacin
tenga unos ordenadores conectados en una red LAN. Figura 21.3 resume el nmero
mximo de redes disponibles en cada clase y el nmero mximo de hosts por red.
IP utiliza el trmino octeto en lugar de porque el tamao de bytes, un byte depende del equipo. As, a
pesar de bytes de 8 bits se han convertido en un estndar de facto, el octeto es inequvoca.
350 IP: Direcciones en Internet Cap. 21

Direccin Bits en Nmero mximo Bits en Nmero mximo de


La clase Prefijo De Redes Sufijo Hosts por red
Un 7 128 24 16777216

B 14 16384 16 65536

C 21 2097152 8 256

Figura 21.3 El nmero de redes y hosts por red en cada uno de los originales
de tres clases de direcciones IP principal.

21.8 Authority For Addresses

Cada prefijo asignado a un individuo en la red Internet debe ser nico. Por lo tanto
una organizacin central, la Corporacin de Internet para la Asignacin de Nombres y
Nmeros (ICANN), ha sido establecido para administrar la asignacin de direcciones y
resolver las controversias. ICANN no asignar prefijos individuales. En su lugar, la ICANN
autoriza un conjunto de registradores para hacerlo. Los registradores hacer bloques de
direcciones disponibles para proveedores de servicios de Internet (ISP), que proporcionan
direcciones para los suscriptores. Por lo tanto, para obtener un prefijo, una corporacin
generalmente con-tactos un ISP.

21.9 Subnet And Classless Addressing

Como la Internet creci, el esquema de direccionamiento classful original se convirti


en una limitacin. Todo el mundo exige una direccin de clase A o B para que tuvieran
suficientes direcciones para el futuro crecimiento; muchas direcciones fueron usados.
Aunque muchas de las direcciones de Clase C permaneci, algunos grupos queran ellos.
Dos nuevos mecanismos fueron inventadas para superar esta limitacin:

Direccionamiento de subred
El direccionamiento sin clases

Los dos mecanismos estn tan estrechamente relacionadas que pueden considerarse
parte de una sola abstraccin: En lugar de tener tres clases de direcciones distintas,
permiten la divi-sin entre el prefijo y el sufijo que ocurren en un lmite arbitrario de bits.
Direccionamiento de subred se utiliz inicialmente dentro de las grandes organizaciones
que conectados a la Internet global, y el direccionamiento sin clases ampli el enfoque de
toda la Internet.
Para comprender la motivacin para el uso de un lmite arbitrario, considere un ISP
que manos fuera de prefijos. Supongamos que un cliente del ISP solicita un prefijo de una
red que contiene 35 hosts. Cuando direccionamiento classful fue utilizado, el ISP puede
asignar un

El captulo 23 se explica cmo un equipo obtiene un sufijo nico.


Sec. 21.9 Y direccionamiento de subred Classless 351

La clase C prefijo. De hecho, slo cuatro bits de host sufijo se necesita para representar
todos los posibles valores de host, lo que significa que 219 de los 254 posibles sufijos nunca
seran asignados a los hosts. En otras palabras, la mayora de las direcciones de Clase C
se desperdicia espacio. Classless ad-dressing proporciona una mejor solucin permitiendo
que el proveedor de servicios de Internet (ISP) para asignar un prefijo de 26 bits de largo.
As, el sufijo es de 6 bits, lo que significa que slo 27 direcciones sern usados.
Otra manera de mirar la situacin es asumir que el ISP posee una clase C prefijo.
Direccionamiento classful asigna todo el prefijo a una organizacin. Con classless ad-
vestidor, sin embargo, el ISP puede dividirse el prefijo ya en varios prefijos, y como signo
de cada uno de ellos a un suscriptor. La figura 21.4 muestra cmo el direccionamiento sin
clases permite a un ISP para dividir un prefijo de clase C en cuatro ya que cada uno de los
prefijos para acomodar una red de hasta 62 hosts.

Prefijo de 24 bits

0 1 2 24 31
110 X
(a)

Prefijo de 26 bits

110 X 00

110 X 01

110 X 10

110 X 11
(b)

Figura 21.4 (a) un prefijo de clase C, y b) el mismo prefijo dividido en cuatro


classless prefijos.

En la figura, la porcin de host de cada prefijo se muestra en gris. Las direcciones de


Clase C original tiene ocho bits de sufijo, y cada una de las direcciones sin clases tiene seis
bits de sufijo. Suponiendo que el prefijo de clase C original era nico, cada uno de los
prefijos sin clases tambin ser nico. As, en lugar de desperdiciar direcciones, el ISP
puede asignar cada una de las cuatro classless prefijos a un suscriptor.

El nmero 254 se plantea porque una direccin de clase C tiene 256 posibles sufijos y todos los 0s y 1s-
suf correcciones estn reservados para el broadcast de subred como se describe ms adelante en este captulo.
352 IP: Direcciones en Internet Cap. 21

21.10 Address Masks

Cmo puede una direccin IP se dividen en un lmite arbitrario? Classless esquemas


de direccionamiento de subred y requieren que los hosts y routers que procesar direcciones
para almacenar una pieza adicional de informacin: un valor que especifica el lmite exacto
entre el prefijo de red y el host sufijo. Para marcar el lmite, IP utiliza un valor de 32 bits
conocido como una mscara de direccin, que fue originalmente llamado mscara de
subred. Una mscara de direccin tiene una bits para marcar el prefijo de red y 0 bits para
marcar la parte del host.
Por qu almacenar el tamao lmite como una mscara de bits? Una mscara facilita
el procesamiento eficiente. En particular, veremos que cuando manejan un paquete IP, los
hosts y los enrutadores deben comparar el prefijo de red de la direccin a un valor en sus
tablas de reenvo. La representacin de mscara de bits realiza la comparacin eficaz. Para
ver cmo, supongamos un router recibe una direccin de destino, D, un prefijo de red
representada como un valor de 32 bits, N, y una mscara de direccin de 32 bits, M. Es
decir, suponga el comienzo de n bits contienen un prefijo de red, y los bits restantes se han
ajustado a cero. Para probar si el destino se encuentra en la red especificada, el router
comprueba la condicin:

N == (D & M)

Es decir, el router utiliza la mscara con una "lgica" y operacin para establecer los bits
de host de la direccin D a cero y, a continuacin, compara el resultado con el prefijo de
red N.
Como ejemplo, considere el siguiente prefijo de red de 32 bits:

10000000 00001010 00000000 00000000

Que tiene el valor decimal punteada 128.10.0.0. Tambin la posibilidad de una m scara de
32 bits que uno tiene diecisis bits seguido por 16 bits cero, que pueden estar indicados en
fracciones decimales como
255.255.0.0:

11111111 11111111 00000000 00000000

Ahora considere una direccin de destino de 32 bits 128.10.2.3, que tiene un equivalente
binario de:

10000000 00001010 00000010 00000011

Un y lgico entre la direccin de destino y la mscara de direccin extrae el alto orden de


16 bits, lo que produce el resultado binario:
10000000 00001010 00000000 00000000

Que es igual a la red 128.10.0.0 prefijo.


Sec. 21.11 La notacin CIDR 353

21.11 CIDR Notation

El esquema de direccionamiento sin clases se conoce formalmente como Classless


Inter-Domain Routing (CIDR). El nombre es desafortunado porque slo CIDR especifica
el direccionamiento y el reenvo. Cuando el esquema de direccionamiento CIDR fue
creado, los diseadores queran hacer fcil para un humano para especificar una mscara.
Para comprender la dificultad, considerar la mscara necesaria para el ejemplo de la figura
21,4b, que tiene 26 bits 1 seguido de seis bits 0. En el punto decimal, la mscara es:

255.255.255.192

Para facilitar a los seres humanos para especificar e interpretar los valores de mscara,
se ampli la notacin decimal con puntos. En la versin extendida, que es lo que se conoce
como notacin CIDR, una direccin y una mscara puede ser especificado por dar una
direccin decimal punteada, seguido por una barra y un nmero decimal que especifica el
nmero de contiguos, justificado a la izquierda uno de los bits de la mscara. Es decir, la
forma general es:
Ddd.ddd.ddd.ddd / m

Donde ddd es el valor decimal de un octeto de la direccin, y m es el nmero de bits de la


mscara. As, uno podra escribir lo siguiente:

192.5.48.69 / 26

Que especifica una mscara de 26 bits. La figura 21.5 muestra las mscaras de direccin
en notacin CIDR junto con el equivalente decimal con puntos de cada uno. Tenga en
cuenta que algunas de las mscaras de direcciones CIDR corresponden a las asignaciones
classful original.

21.12 A CIDR Example

Como un ejemplo de CIDR, asumir un ISP tiene el siguiente bloque de direcciones


disponible para asignar:
128.211.0.0 / 16

Tambin suponga que el ISP tiene dos clientes, un cliente necesita doce direcciones IP y
otras necesidades del cliente 9. El ISP puede asignar un prefijo CIDR de cliente:

128.211.0.16 / 28

Y puede asignar el otro cliente:


128.211.0.32 / 28
354 IP: Internet AddressingChap. 21

Mscara de
Longitud (CIDR) direccin Notas
Todos 0s (equivalente a
/0 0 . 0 . 0 . 0 ninguna mscara)
/1 128 . 0 . 0 . 0
/2 192 . 0 . 0 . 0
/3 224 . 0 . 0 . 0
/4 240 . 0 . 0 . 0
/5 248 . 0 . 0 . 0
/6 252 . 0 . 0 . 0
/7 254 . 0 . 0 . 0
/8 255 . 0 . 0 . 0 Una mscara de clase original
/9 255 . 128 . 0 . 0
/ 10 255 . 192 . 0 . 0
/ 11 255 . 224 . 0 . 0
/ 12 255 . 240 . 0 . 0
/ 13 255 . 248 . 0 . 0
/ 14 255 . 252 . 0 . 0
/ 15 255 . 254 . 0 . 0
Mscara de Clase B
/ 16 255 . 255 . 0 . 0 originales
/ 17 255 . 255 . 128 . 0
/ 18 255 . 255 . 192 . 0
/ 19 255 . 255 . 224 . 0
/ 20 255 . 255 . 240 . 0
/ 21 255 . 255 . 248 . 0
/ 22 255 . 255 . 252 . 0
/ 23 255 . 255 . 254 . 0
/ 24 255 . 255 . 255 . 0 Mscara de clase C original
/ 25 255 . 255 . 255 . 128
/ 26 255 . 255 . 255 . 192
/ 27 255 . 255 . 255 . 224
/ 28 255 . 255 . 255 . 240
/ 29 255 . 255 . 255 . 248
/ 30 255 . 255 . 255 . 252
/ 31 255 . 255 . 255 . 254
Todos 1s (mscara)
/ 32 255 . 255 . 255 . 255 especficos del host
Figura 21.5 una lista de mscaras de direccin en notacin CIDR y en notacin decimal.
Sec. 21.12 Un ejemplo CIDR 355

Aunque tanto los clientes tienen la misma mscara de tamao (28 bits), los prefijos
difieren.
El valor binario asignado a un cliente es:

10000000 11010011 00000000 0001 0000

Y el valor binario asignado a otro cliente es:

10000000 11010011 00000000 0010 0000

Por lo tanto, no hay ambigedad: cada cliente tiene un prefijo nico. Lo que es ms
importante, el ISP conserva la mayora de la direccin original de bloque, que se pueden
asignar a otros clientes.

21.13 CIDR Host Addresses

Considere la posibilidad de calcular el rango de direcciones en un bloque CIDR. Una


vez que un proveedor de servicios de Internet (ISP) asigna un prefijo CIDR de un cliente,
el cliente puede asignar direcciones de host. Por ejemplo, sup-pose una organizacin
asignada 128.211.0.16 / 28 como se ha descrito anteriormente. Figura 21.6 il-lustrates que
la organizacin tendr cuatro bits para utilizar como un campo de direccin de host, y
muestra las direcciones ms altas y ms bajas tanto en notacin decimal y binario. Los
exmenes ple evita asignar todos los 1s y 0s direcciones de host.

0 Prefijo de red 128.211.0.16 / 28 28 31


. . .

. . .

. .
0 0 0 0 0 0 0 0 0 0 0 10 0 00
.

1 0 0 0 0 0 0 0 .. 1 1 0 1 0 0 1 1 .. ..

. . .

Direccin mscara
0 255.255.255.240 28 31
. . .

. . .

. .
1 1 1 1 1 1 1 1 1 1 1 10 0 00
.

1 1 1 1 1 1 1 1 .. 1 1 1 1 1 1 1 1 .. ..

. . .

Bajo la direccin de host


0 128.211.0.17 28 31
. . .

. . .

. .
0 0 0 0 0 0 0 0 0 0 0 10 0 01
.

1 0 0 0 0 0 0 0 .. 1 1 0 1 0 0 1 1 .. ..

. . .

Mayor Direccin de host


0 128.211.0.30 28 31
. . .

. . .

. .
0 0 0 0 0 0 0 0 0 0 0 11 1 10
.

1 0 0 0 0 0 0 0 .. 1 1 0 1 0 0 1 1 .. ..

. . .
Figura 21.6 Ejemplo de direccionamiento CIDR para un ejemplo / 28 prefijo.
356 IP: Direcciones en Internet Cap. 21

La figura 21.6 muestra una desventaja de direccionamiento sin clases - porque el host
sufijo puede comenzar en un lmite arbitrario, los valores no son fciles de leer, en notacin
decimal. Por ejemplo, cuando se combina con el prefijo de red, los catorce-suf host posibles
correcciones como resultado valores decimales punteados
desde 128.211.0.17 128.211.0.30 mediante.

21.14 Special IP Addresses

Adems de asignar una direccin a cada equipo, es conveniente tener ad-vestidos que
puede ser usado para denotar las redes o conjuntos de equipos. IP define un conjunto
especial de abordar las formas que estn reservadas. Es decir, direcciones especiales nunca
son asignados a los hosts. Esta seccin describe la sintaxis y la semntica de cada
formulario de direccin especial.

Direccin de red 21.14.1

Una de las motivaciones para la definicin de formularios especiales de direccin


puede verse en la figura 21.6 - es conveniente disponer de una direccin que puede ser
usado para denotar el prefijo como firmado a una red determinada. Reservas IP host la
direccin cero, y lo utiliza para denotar una red. As, la direccin 128.211.0.16 / 28 denota
una red debido a que los bits ms all de la 28 son cero. Una direccin de red no debe
aparecer como la direccin de destino en un paquete.

21.14.2 Direccin de difusin dirigida

A veces, es conveniente enviar una copia de un paquete a todos los hosts en una red
fsica. Para simplificar la radiodifusin, IP define una direccin de difusin dirigida a cada
red fsica. Cuando se enva un paquete a una direccin de difusin dirigida de la red, una
sola copia del paquete viaja a travs de Internet hasta que llega a la red especificada.
Despus, el paquete se entrega a todos los hosts de la red.
La direcci n de broadcast dirigida por una red est formada por la adicin de un sufijo
que con-sists de todos los 1 bits del prefijo de red. As, el host sufijo que consta de todos
los 1 bits est reservado: si un administrador asigna inadvertidamente los queridos sufijo a
un equipo especfico, el software puede funcionar mal.
Cmo funciona el trabajo de broadcast? Si el hardware de red admite la emisin, un
broadcast dirigido ser entregado mediante la capacidad de difusin del hardware. Si una
red no tiene soporte de hardware para broadcast, el software debe enviar una copia del
paquete a cada host de la red.
La seccin 21,16 analiza la direccin de broadcast de Berkeley, que es una excepcin no estndar.
Sec. 21.14 Direcciones IP especiales 357

21.14.3 Direccin de difusin limitada

El trmino se refiere a una difusin limitada difusin en una red directamente


conectada; informalmente, decimos que la transmisin est limitada a un nico "cable".
Difusin limitada se utiliza durante el arranque del sistema en un ordenador que no conocen
an el nmero de red.
Se reserva la direccin IP consta de treinta y dos bits 1 para referirse a la difusin
limitada.
Por lo tanto, IP transmitir cualquier paquete enviado a la direccin de unos a travs de la
red local.

21.14.4 Esta direccin de equipo

Debido a que cada paquete contiene la direccin de Internet de la fuente, as como la


des-tination, un equipo necesita saber su direccin IP antes de poder enviar o recibir
paquetes de Internet. En el captulo 23, aprenderemos que contiene los protocolos TCP/IP
de un equipo puede utilizar para obtener su direccin IP automticamente cuando se inicia
el equipo. Curiosamente, el inicio del uso de protocolos IP para comunicarse. Al utilizar
estos protocolos de inicio, un comput-er puede suministrar una correcta direccin IP de
origen. Para tratar estos casos, IP se reserva el ad-vestido que consta de todos los ceros
para significar este equipo.

21.14.5 direccin loopback

IP define una direccin de bucle se utiliza para probar las aplicaciones en red. Los
programadores suelen utilizar loopback para depuracin preliminar despus de una
aplicacin de red ha sido creada. Para realizar la prueba de bucle invertido, un programador
debe tener dos programas de aplicacin que estn pensados para comunicarse a travs de
una red. Cada aplicacin incluye el cdigo necesario para interactuar con el software del
protocolo TCP/IP. En lugar de la ejecucin de cada programa en un ordenador
independiente, el programador ejecuta ambos programas en un nico equipo y les da
instrucciones para que utilice una direccin de bucle en la comunicacin. Cuando una
aplicacin enva datos a otro, los datos se desplaza hacia abajo en la pila de protocolos para
el software IP, que se enva hacia arriba a travs de la pila de protocolo para el segundo
programa. As, el pro-grammer puede probar rpidamente la lgica del programa sin
necesidad de tener dos equipos y sin enviar paquetes a travs de una red.
Se reserva el prefijo de red IP 127 / 8 para uso con bucle invertido. La direccin de
host utilizado con 127 es irrelevante - todas las direcciones de host son tratados de la misma
manera. Por convencin, los programadores suelen usar host nmero 1,
haciendo 127.0.0.1 el bucle ms populares ad-vestido.
Durante las pruebas de loopback paquetes no dejar nunca un ordenador - el software
IP para pabellones de paquetes desde una aplicacin a otra. Por consiguiente, la direccin
de bucle invertido no aparece nunca en un paquete viaja a travs de una red.
358 IP: Direcciones en Internet Cap. 21

21.15 Summary Of Special IP Addresses

La tabla en la figura 21.7 se resume la direccin IP especial formas.

Prefijo Sufijo Tipo de direccin Finalidad


Todos- Utilizado durante el
Todos-0s 0s Este equipo bootstrap
Todos-
Red 0s Red Identifica una red
Todos- Difusin en net
Red 1s La difusin dirigida especificado
Todos-
Todos-1s 1s Difusin limitada Difusin en red local
Cualquie
127 / 8 r Loopback Prueba

Figura 21.7 Resumen de la direccin IP especial formas.

Dijimos que direcciones especiales estn reservados y nunca debe ser asignada a los
equipos host. Adems, cada direccin especial est restringido a ciertos usos. Por ejemplo,
una direccin de difusin nunca debe aparecer como direccin de origen, y el todo-0s
direccin no debe utilizarse despus de un host finaliza el procedimiento de inicio y ha
obtenido una direccin IP.

21.16 The Berkeley Broadcast Address Form

La Universidad de California en Berkeley, elaborado y distribuido una pronta


aplicacin de protocolos TCP/IP como parte de BSD UNIX. La aplicacin BSD contenida
una caracterstica no estndar que ha afectado a muchos posteriores implementaciones. En
lugar de utilizar un host sufijo de todos aquellos dirigidos a representar una direccin de
broadcast, el Berkeley implementacin usa un host sufijo que contiene todos ceros (es
decir, idntico a la direccin de red). La direccin es conocida informalmente
como Berkeley difusin.
Lamentablemente, muchos fabricantes de equipo deriva sus principios el software
TCP/IP desde la aplicacin de Berkeley, y pocos sitios an usar Berkeley broadcast. Las
implementaciones de TCP/IP suelen incluir un parmetro de configuracin que puede
seleccionar entre el estndar TCP/IP y la forma de Berkeley; muchas implementaciones
estn diseados para aceptar tanto estndar como Berkeley direccin de difusin
formularios. As, un administrador de red debe elegir la forma que se usa en cada red de
difusin dirigida (si est permitido).
BSD son las siglas de Berkeley Software Distribution.
Sec. 21,17 Los routers y el principio de direccionamiento IP 359

21.17 Routers And The IP Addressing Principle

Adems de asignar una direccin de Internet para cada host, el protocolo de Internet
especifica que los routers deben ser direcciones IP asignadas. De hecho, cada router como
firm dos o ms direcciones IP, una para cada red a la que el router se conecta. Para
entender por qu, recordar dos hechos:

Un router tiene conexiones a mltiples redes fsicas.


Cada direccin IP consta de un prefijo que especifica una red fsica.

Por lo tanto, una nica direccin IP no es suficiente para un router ya que cada router
que se conecta a varias redes y cada red tiene un prefijo nico. El esquema de IP puede ser
ex-plained por un principio fundamental:

Una direccin IP no identifica a un ordenador especfico. En su lugar,


cada direccin IP identifica una conexin entre un equipo y una red. Un
equipo con varias conexiones de red (por ejemplo, un router) debe tener
asignada una direccin IP para cada conexin.

La figura 21.8 ilustra la idea con un ejemplo que muestra las direcciones IP asignadas a
dos routers que conecte las tres redes.

Ethernet 131.108.0.0 / 16

El router 1 Red Wi-Fi


223.240.129.0 / 24
131.108.99.5 223.240.129.2

223.240.129.17
El router 2
78.0.0.17

78.0.0.0 WAN / 8

La figura 21.8 muestra un ejemplo de las direcciones IP asignadas a dos routers.


360 IP: Direcciones en Internet Cap. 21

IP no requieren que el mismo sufijo se asignar a todas las interfaces de un router. En


la figura, por ejemplo, el router que conecta la red Ethernet y Wi-Fi sufijos
tiene 99,5 (conexin a Ethernet) y 2 (conexin a la red Wi-Fi). Sin embargo, IP no impide
utilizando el mismo sufijo para todas las conexiones. As, el ex-amplia muestra que el
administrador ha decidido usar el mismo sufijo, 17, tanto para inter-faces del router que se
conecta a la red Wi-Fi de la WAN. Como cuestin prctica, utilizando el mismo sufijo
puede ayudar a las personas que gestionan las redes, porque un solo nmero es ms fcil
de recordar.

21.18 Multi-Homed Hosts

Un host puede conectarse a mltiples redes? S. Un equipo host con mltiples


conexiones de red se dice ser multitarjeta. Multi-homing se utiliza a veces para en-arruga
fiabilidad - si una red falla, el host puede llegar todava a Internet a travs de la segunda
conexin. Alternativamente, multi-homing es utilizado para aumentar el rendimiento -
Conexiones a mltiples redes pueden hacer que sea posible enviar el trfico directamente
y evitar los routers, que a veces estn congestionadas. Como un router, un host mltiple
tiene varias direcciones de protocolo, uno para cada conexin de red.

21.19 Summary

Para dar la apariencia de una gran red ininterrumpida, Internet utiliza un esquema de
direccionamiento uniforme. A cada equipo se le asigna una direccin IP nica; todas las
aplicaciones que tenga abiertas de Internet utilizan la direccin cuando se comunica con el
ordenador.
El Protocolo de Internet especifica el direccionamiento. Divide cada direccin IP de
Internet en una jerarqua de dos niveles: un prefijo identifica la red a la que se conecta un
equipo y un sufijo identifica un equipo especfico en la red. Para asegurarse de que las
direcciones sean nicos en un dado internet, una autoridad central asigna prefijos de red.
Una vez que se ha asignado un prefijo, un administrador de red local asigna a cada host en
la red un sufijo nico.
Una direccin IP es un nmero de 32 bits. El esquema de direccionamiento original
dividido ad-vestidos en clases; la clase de multidifusin se utiliza todava. Classless y
direccionamiento de subred al-bajo el lmite entre el prefijo y el sufijo que ocurren en un
lmite arbitrario de bits. Para hacerlo, la subred y el direccionamiento sin clases (CIDR)
almacenar una m scara de 32 bits junto con cada anuncio-vestido. La mscara tiene un
valor de 1 para cada bit en el prefijo y el valor 0 para cada bit en el sufijo.

El estndar IP especifica un conjunto de direcciones reservadas que tienen un


significado especial. Direcciones especiales puede utilizarse para especificar loopback
(utilizado para el ensayo), la direccin de una red de difusin en la red fsica local y difusin
en una red remota.
Aunque es conveniente pensar en una direccin IP como especificar un equipo, cada
direccin IP identifica una conexin entre un equipo y una red. Routers y
Sec.
21.19 Resumen
361

Hosts multitarjeta, que tienen conexiones a mltiples redes fsicas, cada uno tiene
varias direcciones IP.

Ejercicios

21.1 IP podra ser rediseado para utilizar direcciones de hardware en lugar de las
direcciones de 32 bits que utiliza actualmente? Por qu o por qu no?
21.2 Cul es la jerarqua de direcciones de Internet permiten que un administrador
local para hacerlo?
21.3 En el esquema de direccionamiento classful original, fue posible determinar la
clase de un ad-vestir desde la propia direccin? Explicar.
21.4 Escribir un programa de computador que acepta una direccin decimal punteada
como entrada y muestra una cadena de 32 bits.
21.5 Escribir un programa de computador que lee una direccin IP en formato decimal
con puntos y disuadir a las minas si la direccin es una direccin de multidifusin.
21.6 Escribir un programa de ordenador que traduce entre slash y notacin CIDR
equivalente valor decimal punteada.
21.7 Si un ISP le asigna un bloque de direcciones / 28, cuntos ordenadores puede
asignar una direccin?
21.8 Si un ISP ofrece un bloque de direccin / 17 para n dlares mensuales y un
bloque de direccin / 16
1,5 N dlares por mes, que tiene el costo ms barato por ordenador?
21.9 Es el prefijo CIDR 1.2.3.4 / 29 vlida? Por qu o por qu no?
21.10 Supongamos que un ISP con un / 24 bloque de direcciones. Explicar si aceptar una
solicitud de un cliente que necesita direcciones para 255 ordenadores. (Sugerencia:
considere las direcciones especiales).
21.11 Supongamos que usted es un proveedor de servicios de Internet (ISP) que posee un
bloque de direccin / 22. Mostrar la asignacin de CIDR que usara para asignar
bloques de direcciones a cuatro clientes que necesitan direcciones para 60 com-
puters cada uno.
21.12 Supongamos que usted es un proveedor de servicios de Internet (ISP) que posee un
bloque de direccin / 22. Puede dar cabida a las peticiones de seis clientes que
necesitan direcciones para 9, 15, 20, 41, 128 y 260 computadoras,
respectivamente? Si es as, cmo? Si no es as, explicar por qu.
21.13 Escribir un programa de computador que lee una direccin en notacin CIDR e
imprime el resultado-ing direccin y mscara en binario.
21.14 Escribir un programa de computador que lee como entrada un prefijo de red CIDR
y una solicitud para un nmero de hosts. Asumir que la solicitud ha sido dada a los
ISP que posee el prefijo, y asignar un prefijo CIDR que acomoda la solicitud sin
perder ad-vestidos.
21.15 Escribir un programa de computador que lee una direccin de host de 32 bits y una
m scara de 32 bits en notacin CIDR e indica si la direccin es una de las
direcciones especiales.
21,16 Cul es la direccin de broadcast de Berkeley?
21,17 Cuntas direcciones IP se asignan a un router? Explicar.

Contenido del captulo


25.1 Introduccin, 419
25.2 Protocolos de transporte y End-To-End, 419 Comunicacin
25.3 El Protocolo de datagrama de usuario, 420
25.4 El paradigma orientado a conexi n, 421
25.5 Interfaz Message-Oriented, 421
25.6 Comunicacin UDP semntica, 422
25.7 Modos de interaccin y difusin, entrega 423
25.8 Endpoint con protocolo de identificacin de los nmeros de
puerto, 424
25.9 Formato de datagramas UDP, 424
25.10 La suma de comprobacin UDP y la pseudo Cabecera, 425
25.11 Encapsulacin UDP, 426
25.12 Resumen, 426
25

UDP: Datagram
Transport Service

25.1 Introduction

Los captulos anteriores describen el servicio de entrega de paquetes sin conexin


proporcionada por IP y el protocolo paralelo utilizado para informar de los errores. Este
captulo examina el UDP, uno de los dos principales protocolos de capa de transporte que
se usa en Internet y la nica conexin sin servicio de transporte. En el captulo se analiza
el formato de paquete UDP UDP y los modos pueden ser utilizados. Veremos que aunque
UDP es eficiente y flexible, que tiene la propiedad de ing-surpris mediante entrega de mejor
esfuerzo semntica. Adems de debatir sobre UDP, el captulo comprende el importante
concepto de nmeros de puerto de protocolo.
El siguiente captulo sigue el debate centrado en el otro gran protocolo de la capa de
transporte TCP. Los captulos posteriores hablar de Internet y de gestin de la red de
enrutamiento, cada uno de los cuales utiliza protocolos de transporte.

25.2 Transport Protocols And End-To-End Communication

En los captulos anteriores muestran, el Protocolo Internet proporciona un servicio de


entrega de paquetes que abarque Internet (es decir, puede pasar un datagrama desde el host
que realiza el envo, a travs de una o varias redes fsicas, para el receptor). A pesar de su
capacidad para pasar el trfico a travs de Internet, IP carece de una caracterstica esencial:
IP no puede distinguir entre varios programas de aplicacin ejecutndose en un host
determinado. Si un usuario ejecuta una aplicacin de correo electrnico y un navegador
web al mismo tiempo o ejecuta varias copias de una aplicacin determinada, deben ser
capaces de comunicarse de forma independiente.
419
420 Servicio de transporte de datagramas UDP:
Cap. 25

IP es incapaz de soportar mltiples aplicaciones porque los campos en el encabezado


del datagrama slo identifican a los equipos. Esto es, desde el punto de vista del IP, la
fuente y el desti-nacin campos en un datagrama identifique un equipo host, una direccin
IP no contiene ad-ditional bits para identificar un programa de aplicacin en el host.
Decimos que la propiedad intelectual trata a un equipo como un punto final de
comunicacin. En contraste, los protocolos de capa de transporte son conocidos como
de extremo a extremo porque los protocolos Un protocolo de transporte permite a un
individuo de apli-cacin programa para ser un punto final de comunicacin. En lugar de
aadir caractersticas adicionales a IP para identificar las aplicaciones, los diseadores de
los protocolos TCP /IP coloca de extremo a extremo en una capa independiente de
protocolos de capa 4.

25.3 The User Datagram Protocol

Como veremos, el TCP /IP suite contiene dos protocolos de transporte, el usuario da-
tagram ( protocoloUDP) y el Protocolo de control de transmisin (TCP), que difieren
radicalmente en el servicio que ofrecen a las aplicaciones. UDP es menos complejo y ms
fcil de entender. La sencillez y facilidad de comprensin vienen con un costo - UDP no
proporciona el tipo de servicio que se espera de una aplicacin tpica.
UDP pueden caracterizarse como:

De extremo a extremo. UDP es un protocolo de transporte que puede


distinguir entre varios programas de aplicacin ejecutndose en un
equipo determinado.
Sin conexi n. La interfaz que proporciona a las aplicaciones UDP
sigue un paradigma orientado a conexi n.
Orientado a Mensajes. Una aplicacin que utiliza UDP enva y re-
ceives mensajes individuales.
Best-effort. UDP ofrece aplicaciones de la misma entrega de mejor
esfuerzo semntica como IP.
Interaccin arbitrario. UDP permite que una aplicacin enve a
muchas otras aplicaciones, recibe desde muchas otras aplicaciones, o
com-municate exactamente con otra aplicacin.
Independiente del sistema operativo. UDP proporciona un medio de
identificar-cin de programas de aplicacin que no depende de los
identificadores utilizados por el sistema operativo local.

La caracterstica ms importante de la UDP, su mejor esfuerzo, semntica surge


porque UDP utiliza el protocolo IP para la transmisin. De hecho, UDP se caracteriza a
veces como una fina capa de proto-col que proporciona a las aplicaciones la capacidad de
enviar y recibir datagramas IP. Podemos resumir:
Sec. 25.3 El Protocolo de datagrama de usuario 421

UDP proporciona un servicio de extremo a extremo que permite una


aplicacin pro-grama para enviar y recibir mensajes individuales, cada
uno de los cuales viaja por separado en un datagrama. Una aplicacin
puede elegir restringir la comunicacin a otro programa de aplicacin
o comunicarse con mltiples aplicaciones.

25.4 The Connectionless Paradigm

UDP utiliza un paradigma de comunicacin sin conexi n, lo que significa que una
aplicacin utiliza UDP no necesita comunicacin preestablish antes de enviar los datos, ni
tampoco la necesidad de aplicacin para informar a la red cuando haya terminado. En su
lugar, una aplicacin puede generar y enviar los datos en cualquier momento. Adems,
permite una aplicacin UDP para retrasar arbitrariamente un largo tiempo entre el envo de
dos mensajes. UDP no mantener el estado, y no hace uso de los mensajes de control;
comunicacin consta slo de los mensajes de datos. En particular, si un par de aplicaciones,
detener el envo de datos, no hay otros paquetes son intercambiados. Como resultado, la
UDP tiene muy poca sobrecarga. A sum-marize:

UDP es un protocolo no orientado a conexi n, lo que significa que una


aplicacin puede enviar datos en cualquier momento y UDP no
transmitir todos los paquetes excepto los paquetes que transportan datos
de usuario.

25.5 Message-Oriented Interface

UDP ofrece programas de aplicacin de interfaz orientada a un mensaje. Cada vez


que un ap-licacin peticiones que UDP enviar un bloque de datos UDP, coloca los datos
en un solo mes-sage para la transmisin. UDP no dividir un mensaje en varios paquetes, y
no combinar mensajes de entrega - cada mensaje que enva una aplicacin es trans-portado
a travs de la Internet y la entrega al receptor.
La interfaz orientada a mensaje tiene varias consecuencias importantes para el
programa-Mers. En el lado positivo, las aplicaciones que utilizan UDP puede depender del
protocolo para conservar los datos de las fronteras - cada mensaje UDP proporciona a una
aplicacin de recepcin ser exactamente la misma que fue transmitida por el remitente.
En el lado negativo, cada mensaje UDP deben caber en un nico datagrama IP. Por lo tanto,
el tamao del datagrama IP abso-lad constituye un lmite en el tamao de un mensaje
UDP. Lo que es ms importante, el tamao de mensaje UDP pueden conducir a un uso
ineficiente de la red subyacente. Si enva una aplicacin extremadamente pequeos
mensajes, los datagramas resultante tendr una gran proporcin de octetos de datos de
cabecera de octetos. Si una aplicacin enva mensajes muy grandes, los datagramas
resultante puede ser ms grande que la MTU de la red, y ser fragmentado por IP.
422 Servicio de transporte de datagramas UDP:
Cap. 25

Permitir mensajes UDP para ser grande produce una interesante anomala.
Normalmente, un programador de aplicaciones que pueden lograr una mayor eficiencia
mediante grandes transferencias. Por ejemplo, los programadores son alentados a declarar
grandes buffers de E/S, y para especificar las transferencias que coincidan con el tamao
del bfer. Con UDP, sin embargo, enviar mensajes grandes conduce a menos eficiencia
porque los mensajes de gran tamao causa la fragmentacin. An ms sorprendente, la
fragmentacin puede ocurrir en el equipo de envo - una aplicacin enva un mensaje
grande, UDP coloca el mensaje entero en un datagrama de usuario y encapsula el
datagrama de usuario en un datagrama IP de Internet, y debe realizar la fragmentacin antes
del da-tagram puede ser enviado. El punto es:

Aunque un programador de intuicin sugiere que el uso de mayor mes-


sabios aumentar la eficiencia, si un mensaje UDP es ms grande que
la MTU de la red, IP fragmentar el datagrama resultante, lo cual reduce
la eficiencia.

Como consecuencia, muchos programadores que utilizan UDP elija un tamao de


mensaje que produce los datagramas que caben en un estndar MTU. En particular, porque
la mayora de las partes de Internet admiten ahora una MTU de 1500 octetos, los
programadores suelen elegir un tamao de mensaje de 1400 o 1450 para dejar espacio para
los encabezados IP y UDP.

25.6 UDP Communication Semantics

UDP utiliza el protocolo IP para toda la entrega. Adems, UDP proporciona a las
aplicaciones exact-ly la misma entrega de mejor esfuerzo semntica como IP, lo que
significa que los mensajes pueden ser:

Perdido
Duplicado
Retrasado
Entregan fuera de orden
Daado

Por supuesto, UDP no intencionalmente, introducir problemas de entrega. En su lugar,


simplemente UDP utiliza el protocolo IP para enviar mensajes, y no detectar o corregir
problemas de entrega. La UDP entrega de mejor esfuerzo semntica tienen importantes
consecuencias para las aplicaciones. Una aplicacin debe ser inmunes a los problemas o el
programador debe tomar medidas adicio-nales para detectar y corregir problemas. Como
un ejemplo de una aplicacin que puede tolerar errores de paquetes, considere la
posibilidad de una transmisin de audio. Si el remitente coloca una pequea cantidad de
audio en cada mensaje, la prdida de un solo paquete produce un pequeo hueco en la
reproduccin, que se escucha como un chasquido o clic. Aunque no es deseable, el ruido
es simplemente molesto. En el extremo opuesto, considere una compra on-line de apli-
cacin. Estas aplicaciones no estn escritos para usar UDP porque pueden tener errores de
paquetes
Sec. 25.6 La semntica de la comunicacin UDP 423

Consecuencias graves (por ejemplo, la duplicacin de un mensaje que lleva una orden de
catlogo puede resultar en dos rdenes, con el doble de los cargos que se hicieron a la
tarjeta de crdito del comprador).
Podemos resumir:

Ya que UDP ofrece la misma entrega de mejor esfuerzo semntica como


IP, un mensaje UDP se pueden perder, duplicar, retrasado, entregan
fuera de orden o bits pueden estar daados en trnsito. UDP slo basta
para aplicaciones como voz o vdeo que pueden tolerar los errores de
envo.

25.7 Modes Of Interaction And Broadcast Delivery

UDP permite cuatro estilos de interaccin:

1-A-1
1-a-muchos
Muchos-a-1
Muchos-muchos.

Es decir, una aplicacin que usa UDP tiene una eleccin. Una aplicacin puede elegir un
1-en-1-teraction en el cual la aplicacin intercambia mensajes exactamente con otra
aplicacin, un 1-a-muchos de interaccin en el cual la aplicacin enva un mensaje a varios
reci-pients, o varios a-1 de interaccin en el cual la aplicacin recibe mensajes de mul-tiple
remitentes. Por ltimo, un conjunto de aplicaciones que puede establecer un muchos-a-
muchos de interaccin en el cual intercambian mensajes el uno con el otro.
Aunque un 1 a muchos interaccin puede lograrse organizando a indivi-dual enviar
una copia del mensaje a cada destinatario, UDP permite el intercambio para ser Effi-ciente.
En lugar de requerir una aplicacin repetidamente para enviar un mensaje a varios reci-
pients, UDP permite una aplicacin para transmitir el mensaje a travs de IP multicast o
broadcast. Para ello, el emisor utiliza una direccin de difusin IP como la direccin IP de
destino. Para ex-amplia difusin local, pueden especificarse utilizando la IP de la direccin
de difusin limitada, 255.255.255.255. Asimismo, UDP permite una aplicacin para
mensajes de multidifusin. Entrega a travs de broadcast o multicast es especialmente til
para redes Ethernet porque el hardware subyacente admite ambos tipos de manera eficiente.
424 Servicio de transporte de datagramas UDP:
Cap. 25

25.8 Endpoint Identification With Protocol Port Numbers

Exactamente cmo UDP debe identificar un programa de aplicacin en un extremo?


Podra parecer que UDP podran usar el mismo mecanismo que utiliza el sistema operativo.
Unfor-lamentablemente, ya que UDP deben abarcar los equipos heterogneos, ningn
mecanismo comn ex-ists. Por ejemplo, algunos sistemas operativos utilizan
identificadores de proceso, otros utilizan nombres de trabajo, y otros utilizan
identificadores de tarea. Por lo tanto, un identificador que sea significativo en un sistema
puede no ser significativo en otro.
Para evitar la ambigedad, UDP define un resumen conjunto de identificadores
llamados nmeros de puerto de protocolo que son independientes del sistema operativo
subyacente. Cada ordenador que implementa UDP debe proporcionar una correlacin entre
el nmero de puerto de protocolo y el pro-gram identificadores que utiliza el sistema
operativo. Por ejemplo, el estndar define el protocolo UDP port nmero siete como el
puerto para un servicio echo y el nmero de puerto 37 como el puerto para
un timeserver servicio. Todos los equipos que ejecuten el protocolo UDP reconocer
nmeros de puerto estndar, independiente del sistema operativo subyacente. As, cuando
un mensaje llega a puerto UDP 7, protocolo UDP debe saber qu programa de software en
el equipo local implementa el servicio echo y debe pasar el mensaje entrante con el
programa.
El modo de comunicacin es determinado por la forma en que una aplicacin ocupe
en ad-vestidos y los nmeros de puerto de protocolo para un socket. Para participar en la
comunicacin 1-a-1, por ejemplo, una aplicacin especifica el nmero de puerto local, la
direccin IP remota, y re-mote; nmero de puerto de protocolo UDP slo pasa por la
aplicacin de mensajes que llegan desde el remitente especificado. A participar en muchos-
a-1, la comunicacin, la aplicacin especifica el nmero de puerto local, pero informa que
UDP del extremo remoto puede ser cualquier sistema. A continuacin, pasa el UDP
aplicacin todos los mensajes que llegan por el puerto especificado.

25.9 UDP Datagram Format

Cada mensaje UDP se denomina datagrama de usuario y consta de dos partes: un


encabezado corto que especifica el envo y la recepcin de los programas de aplicacin y
una carga que transporta los datos enviados. La figura 25.1 muestra el formato de
datagrama de usuario.

0 16 31
El puerto de origen UDP Puerto de destino UDP
Longitud de mensaje UDP Suma de comprobacin UDP
PAYLOAD (mensaje de datos)
...
Figura 25.1 El formato de un datagrama de usuario UDP con un cabezal de 8 octetos.

Slo una aplicacin puede solicitar todos los mensajes de un determinado puerto.
Sec. 25.9 Formato de datagramas UDP 425

Los dos primeros campos del encabezado UDP protocolo de 16 bits contienen
nmeros de puerto. El campo Puerto de origen UDP contiene el nmero de puerto de la
aplicacin de envo, y el campo de destino UDP port contiene el nmero de puerto de la
aplicacin a la que se enva el mensaje. El campo LONGITUD DE MENSAJE
UDP Especifica el tamao total del mensaje UDP, medidos en bytes de 8 bits.

25.10 The UDP Checksum And The Pseudo Header

Aunque el encabezado UDP contiene un campo de 16 bits denominado suma de


comprobacin UDP el checksum es opcional. Un emisor puede optar por calcular una suma
de comprobacin o ajustar todos los bits del campo de checksum en cero. Cuando un
mensaje llega a su destino, el software de suma de comprobacin UDP examina el campo,
y slo verifica la suma de comprobacin si el valor es distinto de cero.

Tenga en cuenta que el encabezado UDP no contienen ninguna identificacin del


remitente o re-ceiver aparte de los nmeros de puerto de protocolo. En particular, UDP
asume que las direcciones IP de origen y destino estn contenidas en el datagrama IP que
lleva la UDP. Por lo tanto, las direcciones IP no son transportadas en el encabezado UDP.
Omitiendo las direcciones IP origen y destino UDP hace ms pequeas y ef-ficient,
pero introduce la posibilidad de error. En particular, en caso de anomalas IP y ofrece un
mensaje UDP a un destino incorrecto, UDP no puede utilizar los campos de encabezado
para determinar que se ha producido un error.
Permitir UDP para verificar que los mensajes llegan al destino correcto, sin incurrir
en la sobrecarga de anillo de campos de cabecera adicionales, se extiende la suma de
comprobacin UDP. Cuando el com-poniendo la suma de comprobacin UDP pseudo
software incluye un encabezado que contiene el origen, el destino y el tipo (p. ej. PROTO)
campos del datagrama IP y longitud de un datagrama UDP. Es decir, el remitente calcula
un checksum como si el encabezado UDP contiene campos adicionales. Asimismo, para
verificar la suma de comprobacin, un receptor debe obtener la longitud UDP y el origen,
el destino y el tipo de campos del datagrama IP; el receptor anexa al mensaje UDP antes
de la verificacin de la suma de comprobacin. La figura 25.2 muestra los campos en el
pseudo-encabezado.

0 16 31
Direccin IP de origen
Direccin de destino IP
Cero PROTO Longitud UDP

Figura 25.2 La ilustracin de la pseudo cabecera usada para calcular la suma


de comprobacin UDP.
como IP, UDP utiliza un complemento ones-checksum; si la suma de comprobacin calculada tiene un
valor de cero, el emisor utiliza la forma de unos de cero.
426 Servicio de transporte de datagramas UDP:
Cap. 25

25.11 UDP Encapsulation

Como ICMP, cada datagrama UDP se encapsula en un datagrama IP para trans-sin


a travs de la Internet. La figura 25.3 muestra la encapsulacin.

Hdr UDP Carga UDP

Encabezado IP Carga IP

Encabezado de trama Carga del bastidor

Figura 25.3 La encapsulacin de un mensaje UDP en un datagrama IP.

25.12 Summary

El Protocolo de datagrama de usuario provides end-to-end del transporte de mensajes


desde una aplicacin ejecutndose en un ordenador a una aplicacin que se ejecuta en otro
equipo. UDP ofrece la misma entrega de mejor esfuerzo semntica como IP, lo que
significa que los mensajes se pueden perder, duplicar o entregan fuera de orden. Una de las
ventajas de un enfoque orientado a conexi n surge de la posibilidad de tener 1-a-1, 1-a-
muchos y muchos-a-1 interacciones entre ap-plications.
Para permanecer independientes de los sistemas operativos subyacentes, UDP utiliza
pequeas en-teger los nmeros de puerto de protocolo para distinguir entre programas de
aplicacin. El software de protocolo en un equipo determinado debe asignar cada nmero
de puerto de protocolo para el mecanismo apropiado (por ejemplo, ID de proceso) se
utilizan en el equipo.
La suma de comprobacin UDP es opcional - si un remitente rellena el campo
checksum con cero, el receptor no verifica la suma de comprobacin. Para comprobar que
el datagrama UDP lleg a la ubicacin correcta, una suma de comprobacin UDP se calcula
sobre el datagrama ms un pseudo header

UDP requiere dos niveles de encapsulamiento. Cada mensaje UDP se encapsula en


un datagrama IP para su transmisin a travs de la Internet. El datagrama se encapsula en
una trama para su transmisin a travs de una red individual.
Sec. 25.12 Resumen 427

Ejercicios

25.1 Cul es la diferencia conceptual entre IP de extremo a extremo y protocolos?


25.2 Enumerar las caractersticas de UDP.
25.3 Necesitan las aplicaciones para el intercambio de mensajes de control UDP antes de
intercambiar datos? Ex-Plain.
25.4 Calcular el tamao del mayor nmero posible mensaje UDP. (Sugerencia: todo el mensaje
UDP deben caber en un datagrama IP).
25.5 Qu ocurre si un mensaje UDP que contiene un paquete de 1500 bytes de datos se envan
a travs de una red Ethernet?
25.6 Si una aplicacin utiliza UDP para enviar un mensaje de 8K bytes a travs de una
conexin Ethernet, cuntas tramas recorren la red?
25.7 Cules son la semntica de UDP?
25.8 Qu valores extremos deber ser especificado por una aplicacin que se acopla en 1-a-1
comunicacin? En 1 a muchos? En muchos-a-1?
25.9 Qu es un pseudo encabezado y, cuando es utilizada?
25.10 Dada una trama Ethernet, qu campos debe ser examinado para determinar si la trama
lleva un mensaje UDP?
Contenido del captulo
26.1 Introduccin, 429
26.2 El Protocolo de control de transmisin, 429
26.3 El servicio TCP proporciona a las aplicaciones, 430
26.4 Servicio End-To-End y las conexiones virtuales, 431
26.5 Las tcnicas que utilizan los protocolos de transporte,
432
26.6 Tcnicas para evitar la congestin, 436
26.7 El arte de diseo de protocolo, 437
26.8 Tcnicas utilizadas en tcp para manejar la prdida de
paquetes, 438
26.9 Retransmisin adaptable, 439
26.10 Comparacin de la retransmisi n veces, 440
26.11 Buffers, Control de flujo y ventanas, 441
26.12 Intercambio de se ales de tres v as de TCP, 442
26.13 Control de congestin TCP, 443
26,14 El formato del segmento TCP, 444
26,15 Resumen, 446
26

TCP: Reliable
Transport Service
26.1 Introduction

Los captulos anteriores describen el servicio de entrega de paquetes sin conexin


proporcionada por IP y el Protocolo de datagrama de usuario que se ejecuta a travs de IP.
Este captulo se analizan los protocolos de transporte en general, y se examinan los
principales medios de transporte TCP, el protocolo utilizado en el Inter-net. El captulo
explica cmo el protocolo TCP proporciona una entrega confiable.
TCP logra una tarea aparentemente imposible: utiliza el datagrama no confiable
servicio ofrecido por IP cuando se enva a travs de Internet, sino que proporciona una
entrega fiable de datos Ser-vicio a los programas de aplicacin. TCP debe indemnizar por
la prdida, demora, duplicacin y entrega, y debe hacerlo sin sobrecargar las redes
subyacentes y routers. Despus de revisar el servicio que TCP proporciona a las
aplicaciones, el captulo examina las tcnicas TCP utiliza para lograr confiabilidad.

26.2 The Transmission Control Protocol

Los programadores no estn capacitados para pensar que la fiabilidad es fundamental


en un ordenador sys tem. Por ejemplo, cuando se escribe una aplicacin que enva los datos
a un dispositivo de E/S, tales como una impresora, un programador asume que los datos
lleguen correctamente o el sistema operativo informar de la aplicacin que se ha
producido un error. Es decir, un programador asume el sistema subyacente garantiza que
los datos sern entregados de forma fiable.

429
430 TCP: Servicio de transporte fiable Cap. 26

Para permitir a los programadores a seguir las tcnicas convencionales al crear


aplicaciones que tenga abiertas que se comunican a travs de Internet, el software de
protocolo debe proporcionar el mismo se-mantics como un sistema informtico
convencional: el software debe garantizar una pronta, reli-poder de comunicacin. Los
datos deben ser entregados en el mismo orden exacto en el que fue enviado, y no debe
haber ninguna prdida o duplicacin.
En el conjunto TCP/IP, el Protocolo de control de transmisin (TCP) proporciona
servicio de transporte fiable. TCP es notable porque resuelve un problema difcil - aunque
otros protocolos han sido creados, sin protocolo de transporte de propsito general ha
demostrado funcionar mejor. Por consiguiente, la mayora de las aplicaciones de Internet
estn diseados para utilizar TCP.

Para resumir:

En Internet, el Protocolo de control de transmisin (TCP) es un


protocolo de capa de transporte que proporciona fiabilidad.

26.3 The Service TCP Provides To Applications

El servicio ofrecido por TCP tiene siete funciones principales:

Orientacin de la conexin. TCP proporciona servicio orientado a la


conexin en la que una aplicacin debe primero solicitar una conexin
a un sexyskadi-cin y, a continuacin, utilice la conexin para la
transferencia de datos.
Comunicacin Point-To-Point. Cada conexin TCP tiene
exactamente dos puntos terminales.
Fiabilidad completa. TCP garantiza que los datos enviados a travs
de una conexin se entregarn exactamente como enviado, completa
y en orden.
Comunicacin full dplex. Una conexin TCP permite que los datos
fluyan en cualquier direccin, y permiten tanto el programa de
aplicacin para enviar datos en cualquier momento.
Interface de stream. TCP proporciona una interfaz de flujo en el cual
un ap-licacin enva una secuencia continua de octetos en una connec-
cin. TCP no agrupar los datos en registros o mensajes, y no es una
garanta para entregar los datos en el mismo tamao de piezas que
fueron trasladados por la aplicacin que realiza el envo.
Inicio de conexin fiable. TCP permite que dos aplicaciones a reli-
hbilmente iniciar la comunicacin.
Conexin ordenado el cierre. Antes de cerrar una conexin TCP
garantiza que todos los datos han sido entregados y que ambas partes
han acordado para cerrar la conexin.
Sec. 26.3 El servicio TCP proporciona a las aplicaciones 431

Para resumir:

TCP proporciona una fiable orientado a la conexin full-duplex,


servicio de transporte de flujo que permite que dos programas de
aplicacin para formar un con-nection, enviar datos en cualquier
direccin y, a continuacin, terminar la connec-cin. Cada conexin
TCP se inici de forma fiable y terminado completamente de gracia.

26.4 End-To-End Service And Virtual Connections

Como UDP, TCP es clasificado como un extremo a extremo porque proporciona el


protocolo de comunicacin entre una aplicacin en un ordenador a una aplicacin de otro
com-ordenador. Es orientado a la conexin, ya que las aplicaciones deben solicitar el
formulario TCP Un con-nection antes de poder transferir datos, y debe cerrar la conexin
cuando termine la transferencia.
Las conexiones proporcionadas por TCP se denominan conexiones virtuales porque
son realizados en el software. De hecho, la Internet subyacente no proporciona soporte de
hardware o software para conexiones. En su lugar, los mdulos de software de TCP en dos
mquinas intercambian mensajes para lograr la ilusin de una conexin.
Cada mensaje TCP se encapsula en un datagrama IP y enviados a travs de Internet.
Cuando el datagrama llega en el host de destino, IP pasa el contenido a TCP. Tenga en
cuenta que aunque TCP utiliza IP para transportar mensajes, IP no leer o interpretar los
mensajes. De hecho, IP trata cada mensaje TCP como los datos que se transfieren. Por el
contrario, trata de TCP IP como un sistema de comunicacin de paquetes que permite la
comunicacin entre los mdulos de TCP en cada extremo de una conexin. La figura 26.1
muestra cmo TCP ve los bajo-mentira de Internet.

Un host Sistema de comunicacin El host B


Visto por TCP
Appl. Appl.
TCP TCP
Direccin Direccin
IP Router IP
Net iface. Direccin IP Net iface.
Net iface.
Net 1 Net 2

Figura 26.1 Ejemplo de cmo el Internet TCP vistas subyacentes.


432 TCP: Servicio de transporte fiable Cap. 26

Como se muestra en la figura, es necesario un software TCP en cada extremo de una


conexin virtual, pero no en los enrutadores intermedios. Desde el punto de vista de TCP,
la totalidad de Internet es un sistema de comunicacin que pueden aceptar y entregar
mensajes sin modificar o interpretar-ing su contenido.

26.5 Techniques That Transport Protocols Use

De un extremo a otro protocolo de transporte deben ser diseados cuidadosamente


para lograr la transferencia eficiente y fiable. Los principales problemas son:

Comunicacin fiable. Los mensajes enviados a travs de Internet se


pueden perder, duplicar, daado, retrasado o entregada fuera de
orden.
Reiniciar el sistema final. En cualquier momento durante la
comunicacin, cualquiera de los dos sistemas finales podra
bloquearse y reiniciar. No debe haber confusin entre perodos de
sesiones; algunos sistemas embebidos puede reiniciar en menos del
tiempo que tarda un paquete cruzar la Internet.
Sistemas heterogneos. Un potente emisor puede generar datos tan
rpido que sobrepasa un receptor lento.
La congestin en Internet. Si los emisores agresivamente transmitir
datos, conmutadores y enrutadores intermedios pueden ser invadidos
con pack-ETS, anloga a una autopista congestionada.

Ya hemos visto ejemplos de tcnicas bsicas de sistemas de comunicaciones de datos


utilizar para superar algunos de los problemas. Por ejemplo, para compensar los bits que
se modifican durante la transmisin, el protocolo puede incluir los bits de paridad,
un checksum, o una comprobacin de redundancia cy-clic (CRC). Protocolos de transporte
hacen ms que detectar errores - que emplean tcnicas que pueda reparar o evitar
problemas. En particular, el transporte pro-tocols utilizan una variedad de herramientas
para tratar algunos de los ms complicados problemas de comunicacin. Las prximas
secciones describen mecanismos bsicos.

26.5.1 La secuenciacin para manejar duplicados y no cubierto por la


entrega de pedidos

Para manejar paquetes duplicados y fuera de la entrega de los pedidos, protocolos de


transporte que utilizan la secuencia. La parte emisora atribuye un nmero de secuencia
para cada paquete. La recep-ing lado almacena tanto el nmero de secuencia del ltimo
paquete recibido en orden, as como una lista adicional de paquetes que llegan fuera de
orden. Cuando llega un paquete, el receptor se examina el nmero de secuencia para
determinar cmo el paquete debe ser manejado. Si el paquete es el siguiente (es decir, la
espera ha llegado a pedido), el protocolo software entrega el paquete a la siguiente capa
superior, y comprueba su lista para ver si los paquetes adicionales tambin pueden ser
entregados. Si el paquete ha llegado fuera de orden, el protocolo software agrega el paquete
a la lista. La secuenciacin tambin soluciona el problema de la duplicacin: un receptor
comprueba la existencia de duplicados cuando se examina el nmero de secuencia de la
llegada de un paquete. Si
Sec. 26.5 Las tcnicas que utilizan los protocolos de transporte 433

El paquete ya ha sido entregado, o el nmero de secuencia coincide con uno de los pack-
ets esperando en la lista, el software descarta la nueva copia.

26.5.2 la retransmisin para manejar paquetes perdidos

Para manejar la prdida de paquetes, transporte protocolos utilizan el acuse de recibo


positivo con re-transmisin. Cuando una trama llega intacto, el software de protocolo de
recepcin enva una pequea confirmacin (ACK) mensaje que informa de buena
recepcin. El remitente asume la responsabilidad de garantizar que cada paquete se
transfiere correctamente. Siempre que se enva un paquete, el software de protocolo del
lado de envo inicia un temporizador. Si llega un acuse de recibo antes de que expire el
temporizador, el software anula el temporizador; si el temporizador expira antes de que
llegue el acuse de recibo, el software enva otra copia del paquete e inicia el temporizador
de nuevo. La accin de enviar una segunda copia se conoce como retransmitir, y la copia
se denomina comnmente una retransmisin.
Por supuesto, la retransmisin no puede tener xito si se produce un fallo de hardware
ha desconectado permanentemente la red o si el equipo receptor ha fallado. Por lo tanto,
los protocolos que retransmitir mensajes vinculados normalmente el nmero mximo de
retransmisiones. Cuando se ha alcanzado el lmite, el protocolo deja de retransmitir y
declara que la comunicacin es imposible.
Tenga en cuenta que si los paquetes se retrasa, la retransmisin puede introducir
paquetes duplicados. Por lo tanto, los protocolos de transporte que incorporan la
retransmisin generalmente estn diseados para manejar el problema de paquetes
duplicados.

26.5.3 Tcnicas para evitar la repeticin

Extraordinariamente largas demoras pueden provocar errores en la reproduccin que


retras el paquete af-fects comunicacin posterior. Por ejemplo, considere la siguiente
secuencia de eventos.

Dos equipos acuerdan comunicarse a las 1 PM.


Un equipo enva una secuencia de diez paquetes a los dems.
Las causas de un problema de hardware 3 paquetes a retrasarse.
Las rutas cambian para evitar el problema de hardware.
El software de protocolo en el ordenador emisor retransmite el
paquete 3, y enva los paquetes restantes sin error.
A las 1:05 PM los dos equipos acuerdan comunicarse de nuevo.
Tras el segundo paquete llega, el retraso de la copia del paquete 3 ar-
rives de la conversacin anterior.
Paquete 3 llega desde la segunda conversacin.
A menos que un protocolo de transporte est diseado cuidadosamente para evitar
tales problemas, un paquete desde una conversacin previa podra ser aceptado en una
conversacin posterior y descarta el paquete correcto como duplicado.
434 TCP: Servicio de transporte fiable Cap. 26

Tambin pueden ocurrir con Replay de paquetes de control (es decir, paquetes que
establecer o terminar la comunicacin). Para comprender el alcance del problema,
considere una situacin en la que dos programas de aplicacin forman una conexin TCP,
comunicarse, cerrar la conexin y, a continuacin, formar una nueva conexin. El mensaje
que especifica el cierre de la conexin puede estar duplicado y una copia se podra demorar
el tiempo suficiente para que el segundo connec-cin a establecerse. Un protocolo debe
disearse de manera que el mensaje duplicado no causar la segunda conexin se cierra.
Para evitar la reproduccin, protocolos marcar cada sesin con un identificador nico
(por ejemplo, el tiempo que se ha establecido la sesin), y requieren el ID exclusivo para
estar presentes en cada paquete. El protocolo software descarta cualquier paquete de
llegada que contiene un ID incorrecto. Para evitar la repeticin, una ID no deben
reutilizarse hasta que ha transcurrido un tiempo razonable (por ejemplo, horas).

26.5.4 Control de flujo para evitar el desbordamiento de datos

Existen diversas tcnicas para evitar que un equipo rpido de enviar tantos datos que
se sobrepasa un receptor lento. Utilizamos el trmino para referirse al control de flujo tech-
niques que manejar el problema. La forma ms simple de control de flujo es un stop-and-
go -sys tem en el que un emisor espera tras la transmisin de cada paquete. Cuando el
receptor est listo para otro paquete, el receptor enva un mensaje de control, generalmente
una forma de-edgement acknowl.
Aunque parar-y-ir protocolos evitar rebasamiento, son el resultado de muy bajo
rendimiento. Para entender el por qu, observe lo que sucede en una red que tiene un
tamao de paquete de 1000 octetos, una capacidad de 2 Mbps y un retardo de 50
milisegundos. El hardware de red puede transportar 2 Mbps desde un equipo a otro. Sin
embargo, despus de transmitir un paquete, el remitente debe esperar 100 mseg antes de
enviar otro pack-et (es decir, 50 mseg. para el paquete para llegar al receptor y 50 mseg.
para un acuse de recibo para viajar). As, la tasa mxima a la que los datos pueden enviarse
utilizando stop-and-go es un paquete cada 100 milisegundos. Cuando se expresa como una
tasa de bits, la velocidad max-mnimo que parar-y-ir puede alcanzar es de 80.000 bps, que
es slo el 4% de la capacidad de hardware.

Para obtener altas tasas de rendimiento, protocolos de transporte utilizan una tcnica
conocida como control de flujo de la ventana deslizante. El emisor y el receptor estn
programados para usar un win-dow tamao fijo, que es la cantidad mxima de datos que
puede ser enviada ante un acknowl-edgement llega. Por ejemplo, el remitente y el receptor
podra convenir en un tamao de ventana de cuatro paquetes. El emisor comienza con los
datos a ser enviados, extrae datos para llenar cuatro paquetes (es decir, la primera ventana),
y transmite una copia de cada paquete. En la mayora de protocolos de transporte, el
remitente conserva una copia en caso de retransmisin es necesaria. El receptor debe tener
espacio en bfer preasignados para toda la ventana. Si un paquete llega en secuencia, el
receptor pasa el paquete a la aplicacin receptora y transmite una acknowl-edgement al
remitente. Cuando llegue un acuse de recibo, el remitente descarta su copia del paquete
reconoce y transmite el siguiente paquete. La figura 26.2 muestra que el mecanismo se
conoce como una ventana deslizante.
Sec. 26.5 Las tcnicas que utilizan los protocolos de transporte 435

Ventana
12 11 10 9 8 7 6 5 4 3 2 1

(a)
An no
Ya se reconoce enviado.

Ventana
12 11 10 9 8 7 6 5 4 3 2 1

(b)
La ventana se mueve como
Agradecimientos llegar
Ventana
12 11 10 9 8 7 6 5 4 3 2
1

(c)

La figura 26.2 muestra una ilustracin de una ventana deslizante (A) inicial,
intermedio (B) y (c) la posicin final.

Ventana deslizante puede aumentar drsticamente el rendimiento. Para entender por


qu, com-pare la secuencia de transmisiones con un stop-and-go y un esquema esquema
de ventana deslizante. Figura 26.3 contiene una comparacin de un 4-La transmisin de
paquetes.

Host 1 Host 2 Host 1 Host 2


Enviar Enviar
Paquete Cuatro
Envi
Enviar Paquetes ar
Cua
Enviar Ack tro
Los
asen
timi
ento
Paquete s
Hecho
Enviar
Enviar Ack
Paquete
Enviar
Enviar Ack
Paquete
Enviar
Ack
Hecho

(a) (b)

Figura 26.3 Comparacin de transmisin usando (a) parar-y-ir, y (b)


deslizado-ing ventana.
436 TCP: Servicio de transporte fiable Cap. 26

En la figura de 26,3 a, un emisor transmite cuatro paquetes, pero espera un acuse de recibo
antes de enviar cada paquete. Si el retardo necesario para enviar un paquete nico en un
viaje a travs de la red es N, el tiempo total necesario para enviar cuatro paquetes es 8N.
En la Figura 26,3b, un emisor transmite todos los paquetes en la ventana antes de que lo
espera. La figura muestra un pequeo retraso entre las sucesivas transmisiones de paquetes
de transmisin porque nunca es instantneo - un corto perodo de tiempo (normalmente
unos pocos microsegundos) es necesario para el hardware para completar la transmisin
de un paquete y comenzar a transmitir el paquete siguiente. Por lo tanto, el tiempo total
necesario para enviar cuatro paquetes es 2N + , donde denota el pequeo retraso.

Para comprender el significado de la ventana deslizante, imagine un extendido de


comuni-cacin que involucra muchos paquetes. En tales casos, el tiempo total necesario
para la trans-sin es tan grande que puede ser ignorada. En tales redes, un protocolo
de ventana deslizante puede aumentar el rendimiento sustancialmente. El potencial de
mejora es:

Tw = Tg W (26,1)

Donde tw es el rendimiento que puede lograrse con un protocolo de ventana


deslizante, Tg es el rendimiento que puede lograrse con un stop-and-go, protocolo y W es
el tamao de la ventana. La ecuacin explica por qu el protocolo de ventana deslizante se
ilustra en la Figura 26,3b tiene aproximadamente cuatro veces el rendimiento de la parar-
y-ir protocolo en la figura de 26,3. Por supuesto, el rendimiento puede ser aumentado
arbitrariamente simplemente aumentando el tamao de la ventana. El ancho de banda de la
red subyacente impone un lmite superior: los bits no se pueden enviar ms rpido que el
hardware puede hacerlos. As, la ecuacin puede ser reescrita:

Tw = min (B, Tg W) (26,2)

Donde B es el ancho de banda del hardware subyacente.

26.6 Techniques To Avoid Congestion

Para comprender cmo la congestin puede ocurrir fcilmente, considere cuatro hosts
conectados mediante dos interruptores en la figura 26.4 se ilustra.

Interruptor 1 Conmutador 2
Figura 26.4 Cuatro hosts conectados mediante dos interruptores.
Sec. 26.6 Tcnicas para evitar la congestin 437

Asumir cada conexin en la figura funciona a 1 Gbps, y considerar qu hap-plumas si


ambos equipos conectados al conmutador 1 intentan enviar datos a un ordenador conectado
al switch 2. Interruptor 1 recibe datos a una velocidad agregada de 2 Gbps, pero slo puede
por Ward 1 Gbps al switch 2. La situacin es conocida como la congestin. Incluso si un
interruptor tem-porarily almacena paquetes almacenados en la memoria, se produce una
congestin en el aumento de la demora. Si persiste la congestin, el interruptor se quede
sin memoria y comenzar a descartar paquetes. Aunque la re-transmisin puede ser usada
para recuperar los paquetes perdidos, retransmisin enva ms paquetes en la red. Por lo
tanto, si la situacin persiste, toda una red puede quedar inutilizable; la condicin es
conocida como la congestin colapso. En la Internet, congestin ocurre generalmente en
los routers. Protocolos de transporte intenta evitar la congestin colapso por la supervisin
de la red y de reaccionar con rapidez y una vez que comienza la congestin. Hay dos
enfoques bsicos:

Organizar los sistemas intermedios (por ejemplo, routers) a informar


a un remitente cuando se produce una congestin
Aument el uso de retraso o prdida de paquetes como una estimacin de la
congestin

El antiguo rgimen es implementado por tener routers enviar un mensaje especial a la


fuente de paquetes cuando se produce una congestin o por tener routers Configurar un bit
en el encabezado de cada paquete que experimenta el retraso causado por la congestin.
Cuando, se utiliza el segundo mtodo, el equipo que recibe el paquete incluye informacin
en el ac-knowledgement para informar al remitente original.
Utilizando retardos y prdida para estimar la congestin es razonable en Internet
porque:

Hardware de red moderna funciona bien; la mayora de los retrasos y


la congestin de los resultados de prdida, no una falla del hardware.

La respuesta apropiada a la congestin consiste en la reduccin de la tasa a la cual el


pack-ETS se transmiten. Protocolos de ventanas deslizantes puede lograr el efecto de
reducir la tasa al reducir temporalmente el tamao de la ventana.

26.7 The Art Of Protocol Design

Aunque las tcnicas necesarias para resolver problemas concretos, son bien
conocidas, los proto-col diseo es importante por dos razones. Primero, hacer que la
comunicacin sea eficaz, los detalles se deben escoger cuidadosamente - pequeos errores
de diseo puede resultar en mal funcionamiento, ONU-paquetes necesarios, o retrasos. Por
ejemplo, si se utilizan nmeros de secuencia, cada paquete debe contener un nmero de
secuencia en el encabezado del paquete. El campo debe ser lo suficientemente grande para
los nmeros de secuencia no se reutilizan con frecuencia, pero lo suficientemente pequea
para evitar el desperdicio de ONU-ancho de banda necesario. Segundo, el protocolo
mecanismos pueden interactuar de maneras inesperadas. Por ejemplo, considerar la
interaccin entre el control de flujo y mecanismos de control de congestin. Esquema de
una ventana deslizante se utiliza ms agresivamente subyacente de la red de ancho de banda
para mejorar el rendimiento. Un mecanismo de control de congestin el op-

Un retraso prolongado puede ocurrir entre el momento en que se produce una congestin y el remitente
original es informado.
438 TCP: Servicio de transporte fiable Cap. 26

Integrado por la reduccin del nmero de paquetes que se introduce para evitar que la red
se colapse; el equilibrio entre el control de congestin y la ventana deslizante puede ser
complicado, y un diseo que hace bien es difcil. Es decir, el control de flujo agresiva puede
causar congestin y control de congestin conservador puede disminuir el rendimiento ms
de lo necesario. Diseos que intentan cambiar de agresivo a un comportamiento ms
conservador cuando se produce una congestin tienden a oscilar - aumentar lentamente su
uso del ancho de banda de la red hasta que empieza a experimentar congestin, disminuir
el uso de la red hasta que llega a ser estable, y luego comienzan a aumentar de nuevo.
Reinicio del sistema informtico plantea otro grave reto para el diseo de protocolo
de transporte. Imagine una situacin en la que dos programas de aplicacin establece una
conexin, ser-gin enviar datos y, a continuacin, el equipo se reinicia la recepcin de datos.
Aunque el software de protocolo en el reiniciado equipo no tiene conocimiento de una
conexin, el software de protocolo en el equipo remitente considera la conexin vlida. Si
el protocolo no est diseado cuidadosamente, un paquete duplicado puede causar un
equipo incorrectamente a crear una conexin y comenzar a recibir datos en mitad de
camino.

26.8 Techniques Used In TCP To Handle Packet Loss

Cul de las tcnicas mencionadas no TCP utilizan para lograr la transferencia


confiable? La respuesta es compleja porque TCP utiliza una variedad de planes que se
combinan de forma novedosa. Como era de esperarse TCP utiliza la retransmisin para
compensar la prdida de paquetes. Ser causa de TCP proporciona un flujo de datos en
ambas direcciones, a ambos lados de una comunicacin que participen en la retransmisin.
Cuando TCP recibe datos, enva un acuse de recibo al remitente. Cada vez que enva los
datos, TCP inicia un temporizador y retransmite los datos si el temporizador expire. As,
la retransmisin TCP bsica funciona como la figura 26.5 muestra.

Eventos en el host 1 Eventos en el host 2


Enviar mensaje 1
Recibir ACK 1 1
Enviar mensaje
Recibir ACK
1 enviar mensaje
2 Recibir ACK 2 2
Enviar mensaje

Recibir ACK 2
Enviar mensaje 3

Temporizador de Perdida de
retransmisin paquetes Recibir ACK 3 3
Retransmitir el mensaje 3 Enviar mensaje
Figura 26.5 Ejemplo de retransmisin TCP despus de una prdida de paquetes.
Sec. 26.8 Tcnicas utilizadas en tcp para manejar la prdida de paquetes 439

Esquema de retransmisin de TCP es la clave de su xito, ya que se encarga de


comuni-cacin a travs de una ruta de acceso arbitraria a travs de Internet. Por ejemplo,
una aplicacin podra enviar datos a travs de un canal de satlite a un equipo de otro pas,
mientras que otro ap-licacin enva los datos a travs de una red de rea local a un
ordenador en la habitacin de al lado. TCP deben estar preparados para retransmitir
cualquier mensaje que se pierde en la conexin. La pregunta es: cunto tiempo debe
esperar antes de retransmitir TCP? Agradecimientos desde un com-ordenador en una red
de rea local se espera que lleguen dentro de unos pocos milisegundos, pero un sat-ellite
conexin requiere cientos de milisegundos. Por un lado, esperar demasiado tiempo para tal
reconocimiento deja la red inactiva y no maximizar el rendimiento. As, en una red de rea
local, TCP no debera demorar mucho tiempo antes de retransmitir. Por otra parte, la
retransmisin rpida no funciona bien en una conexin va satlite porque el trfico
innecesario consume ancho de banda de la red y disminuye el rendimiento.
TCP se enfrenta a un desafo ms difcil de distinguir entre los destinos locales y
remotos: Rfagas de datagramas pueden causar congestin, lo que hace que la transmisin
de-establece a lo largo de un camino determinado a cambiar rpidamente. De hecho, el
tiempo total necesario para enviar un mes-sage y recibir un acuse de recibo puede aumentar
o disminuir en un orden de magni-tude en unos pocos milisegundos. Para resumir:

El retardo necesario para que los datos lleguen a destino y un acknowl-


edgement para devolver depende del trfico en la Internet, as como la
distancia al destino. Porque TCP permite que varios programas de
aplicacin para comunicarse con mltiples destinos simultneamente y
a las condiciones del trfico afectan a la demora, TCP debe manejar una
serie de demoras que pueden cambiar rpidamente.

26.9 Adaptive Retransmission

Antes de TCP fue inventado, protocolos de transporte utilizados un valor fijo para la
retransmisin retraso - el protocolo o network manager diseador eligi un valor que era
lo suficientemente grande para el retraso esperado. Los diseadores que trabajan en TCP
se dio cuenta de que un tiempo de espera fijo podra no funcionar bien para la Internet. Por
lo tanto, decidieron realizar la retransmisin de TCP adap-tiva. Es decir, TCP supervisa la
corriente retardo en cada conexin, y adapta (es decir, de cambios) el temporizador de
retransmisin para adaptarse a las condiciones cambiantes.
Cmo puede el monitor TCP retrasos de Internet? En realidad, TCP no se puede
conocer con exactitud la demoras por todas partes de la Internet en todo momento. En
cambio, TCP estimaciones retardo de ida y vuelta para cada conexin activa midiendo el
tiempo necesario para recibir una respuesta. Cada vez que enva un mensaje al que se espera
una respuesta, TCP registra la hora en que se envi el mensaje. Cuando llega una respuesta,
TCP se resta la hora en que el mensaje se envi desde el tiempo actual para producir una
nueva estimacin del retardo de ida y vuelta para esa conexin. Como se enva y recibe
paquetes de datos TCP agradecimientos, genera una secuencia de estimaciones de ida y
vuelta y utiliza una funcin estadstica para producir un promedio ponderado. Adems de
una media ponderada, TCP mantiene una estimacin de la varianza, y
440 TCP: Servicio de transporte fiable Cap. 26

Utiliza una combinacin lineal de la media y la varianza estimada a la hora de calcular el


momento en que es necesaria la retransmisin.
La experiencia ha demostrado que la retransmisin adaptable TCP funciona bien.
Mediante la variacin de TCP permite reaccionar rpidamente cuando la demora aumenta
tras una rfaga de paquetes. Usando una media ponderada ayuda a restablecer el
temporizador de retransmisin TCP si el retraso devuelve un valor menor despus de una
rfaga de temporal. Cuando el retraso se mantiene constante, TCP ajusta el tiempo de
espera de retransmisin a un valor que es ligeramente mayor que el promedio de ida y
vuelta de de-lay. Cuando los retrasos comienzan a variar, TCP ajusta el tiempo de espera
de retransmisin a un valor superior a la media para acomodar los picos.

26.10 Comparison Of Retransmission Times

Para comprender cmo la retransmisin adaptable TCP ayuda a maximizar el


rendimiento de cada conexin, considere un caso de prdida de paquetes en dos conexiones
que tienen diferentes retardos de ida y vuelta. Por ejemplo, en la figura 26.6 muestra el
trfico en dos de estas conexiones.

Est 1 .
.
.
Est 1
Est 2
Est 2
................ ................

Timeout Perdida de
................
paquetes
Timeout Perdida de paquetes

.. . . . . . . . . . . . . . .

Figura 26.6 y tiempo de espera de retransmisin en dos conexiones TCP que


tienen diferentes retardos de ida y vuelta.

Como muestra la figura, TCP establece el tiempo de espera de retransmisin para ser
un poco ms largo que el promedio de retardo de ida y vuelta. Si el retraso es grande, TCP
utiliza un gran tiempo de espera de retransmisin; si el retraso es pequea, TCP utiliza un
pequeo tiempo de espera. El objetivo es esperar el tiempo suficiente para determinar que
un paquete se pierde, sin esperar ms tiempo del necesario.
Sec. 26.11 Buffers, Control de flujo y Windows 441

26.11 Buffers, Flow Control, And Windows

Ventana TCP utiliza un mecanismo para controlar el flujo de datos. A diferencia de


las basadas en paquetes simplista esquema descrito arriba de la ventana, una ventana de
TCP se mide en bytes. Cuando se establece una conexin, cada extremo de la conexin
asigna un bfer para contener los datos entrantes y enva el tamao del bfer en el otro
extremo. Como dato llega, la re-recibiendo TCP enva acuses de recibo, que especifican el
tamao de bfer restantes. Ventana TCP utiliza el trmino para referirse a la cantidad de
espacio de bfer disponible en cualquier momento; no-tification que especifica el tamao
de la ventana se denomina ventana anuncio. Una ventana de receptor enva un anuncio con
cada confirmacin.
Si la aplicacin receptora puede leer datos tan pronto como llega, un receptor enviar
un positivo anuncio ventana junto con cada confirmacin. Sin embargo, si la parte emisora
funciona ms rpido que la parte receptora (p. ej., debido a que la CPU es ms rpido), los
datos entrantes eventualmente llenar el buffer del receptor, lo que provoca que el receptor
anuncie una ventana cero. Un remitente que recibe una ventana cero anuncio debe detener
el envo hasta que el receptor nuevamente anuncia una ventana positiva. La figura 26.7
muestra la ventana anuncios.

Eventos de El receptor de eventos


remitente
Anunciar window=2500

Enviar datos de octetos


1-1000 enviar octetos de Ack hasta 1000, WINDOW=1500
datos enviar datos octetos Ack hasta 2000, WINDOW=500
2001-2500 1001-2000
Ack hasta 2500, WINDOW=0

Recibir ACK para 1000


Recibir ACK para 2000
La aplicacin lee 2000 octetos
Recibir ACK para 2500
Ack hasta 2500, WINDOW=2000

Enviar octetos de datos Ack hasta 3500, WINDOW=1000


enviar datos octetos 3501- Ack hasta 4500, WINDOW=0
4500 2501-3500 La aplicacin lee 1000 octetos
Ack hasta 4500, WINDOW=1000
Recibir ACK para 3500.
Recibir ACK para 4500 .
.
.
Recibir ACK para 4500
Figura 26.7 una secuencia de mensajes que ilustra el flujo TCP para un tamao
de segmento mximo de 1000 bytes.
442 TCP: Servicio de transporte fiable Cap. 26

En la figura, el emisor utiliza un tamao de segmento mximo de 1000 bytes.


Transferencia-ginebras cuando el receptor anuncia un tamao inicial de la ventana
de 2500 bytes. El remitente im-mediately transmite tres segmentos, dos que
contienen 1000 bytes de datos y uno que contiene 500 bytes. Como los segmentos llegan,
el receptor genera un acuse de recibo con el tamao de la ventana reducida por la cantidad
de datos que ha llegado.
En el ejemplo, los tres primeros segmentos llenar el buffer del receptor ms rpido
que el re-recibiendo aplicacin puede consumir datos. Por lo tanto, el tamao de ventana
anunciado llega a cero, y el emisor no puede transmitir datos adicionales. Despus de la
aplicacin receptora con-sumes 2000 bytes de datos, el TCP receptor enva una
confirmacin adicional que anuncia un tamao de ventana de 2000 bytes. El tamao de la
ventana siempre se mide ms all de los datos de ser reconocida, as que el receptor es la
publicidad que pueda aceptar 2000 bytes ms all del 2500 ya ha recibido. El remitente
responde transmitiendo dos adicio-nales segmentos. Como cada segmento llega, el receptor
enva un acuse de recibo con el tamao de la ventana reducida por 1000 bytes (es decir, la
cantidad de datos que ha llegado).
Una vez ms, el tamao de la ventana llega a cero, causando el remitente para detener
la transmisin. Finalmente, la aplicacin receptora consume algunos de los datos y el TCP
receptor transmite un acuse de recibo positivo con un tamao de ventana. Si el remitente
tena ms datos a la espera de ser enviados, el remitente podr proceder a transmitir otro
segmento.

26.12 TCPs Three-Way Handshake

Para garantizar que las conexiones se establecen o suprimidos de manera fiable, TCP
utiliza un apretn de manos de 3 vas en el cual tres de los mensajes se intercambian.
Durante el apretn de manos de 3 vas para iniciar una conexin, cada lado enva un
mensaje de control que especifica un tamao de bfer inicial (para control de flujo) y un
nmero de secuencia. Los cientficos han demostrado que el TCP de 3 vas de intercambio
es necesario y suficiente para garantizar el acuerdo inequvoco a pesar de la prdida de
paquetes, duplicacin, retardo y reproducir eventos. Adems, el apretn de manos asegura
que TCP no se abre o cierra una conexin hasta que ambos extremos han acordado.
TCP utiliza el trmino segmento de sincronizacin (segmento SYN) para describir los
mensajes de control utilizado en un 3-way handshake para crear una conexin, y el
trmino segmento de aletas (corto para finalizar el segmento) para describir el control
mensajes utilizados en un 3-way handshake para cerrar una conexin. La figura 26.8 ilustra
el apretn de manos de 3 vas utilizadas para crear un con-nection.
Un aspecto clave del apretn de manos de 3 vas utilizadas para crear una conexin
implica la seleccin de nmeros de secuencia. TCP requiere cada extremo para generar un
32 bits aleatorios se-quence nmero que se convierte en la secuencia inicial de los datos
enviados. Si una aplicacin en tienta a establecer una nueva conexin TCP despus de TCP
se reinicia un equipo, elige un nmero aleatorio nuevo. Porque la probabilidad de
seleccionar un valor aleatorio que coincide con la secuencia utilizada en una conexin
anterior es baja, TCP evita problemas de repeticin. Es decir, si hay un par de programas
de aplicacin utiliza TCP para comunicarse, cierra la conexin y, a continuacin, establece
una conexin nueva, los nmeros de secuencia en la nueva conexin difieren de los
nmeros de secuencia utilizado en la antigua conexin TCP, permitiendo a rechazar
cualquier retrasado los paquetes que llegan.

como otros paquetes TCP, los mensajes utilizados para un 3-way handshake puede ser retransmitidos.
Sec. 26.12 Apretn de manos de tres vas de TCP 443

Eventos en el host 1 Eventos en el host 2


Enviar SYN
Recibir SYN
Enviar SYN+ACK
Recibir SYN+ACK
enviar ACK
Recibir ACK

Figura 26.8 El apretn de manos de 3 vas utilizadas para crear una conexin TCP.

El apretn de manos de 3 vas se utiliza para cerrar una conexin utiliza segmentos
de aletas. Un acknowl-edgement es enviado en cada direccin, junto con el fin de garantizar
que todos los datos se ar-rived antes se termina la conexin. La figura 26.9 ilustra el
intercambio.

Eventos en el Eventos en el
host 1 . host 2
.
Enviar fin + ACK .
Recibir ACK +
ALETAS
Recibir ACK + Enviar fin + ACK
ALETAS
Enviar ACK
Recibir ACK

Figura 26.9 El apretn de manos de 3 vas se utiliza para cerrar una conexin.

26.13 TCP Congestion Control

Uno de los aspectos ms interesantes de TCP es un mecanismo de control de


congestin. Recordar que en la Internet, el retraso o la prdida de paquetes es ms probable
que sea causado por el conges-cin de una falla de hardware, y que la retransmisin puede
exacerbar el problema de la congestin, inyectando copias adicionales de un paquete. Para
evitar el colapso, congestin TCP utiliza los cambios en la demora como una medida de la
congestin, y responde a la congestin mediante la reduccin de la tasa en la que se
retransmite los datos.
Aunque pensamos en reducir la tasa de transmisin, TCP no calcular una tasa de
transferencia de datos. En cambio, TCP bases de transmisin sobre el tamao del bfer. Es
decir, el receptor adver-tises un tamao de ventana, y el emisor puede transmitir datos para
llenar la ventana del receptor antes de que se reciba un ACK. Para controlar la velocidad
de los datos, TCP impone una restriccin en la
444 TCP: Servicio de transporte fiable Cap. 26

Tamao de ventana: al reducir temporalmente el tamao de la ventana, el TCP emisor


reduce efectivamente la tasa de transferencia de datos. El concepto importante es:

Conceptualmente, un protocolo de transporte debe reducir la tasa de la


trans-sion cuando se produce una congestin. Porque utiliza una
ventana de tamao variable, TCP puede lograr una reduccin en la tasa
de datos temporalmente reduciendo el tamao de la ventana. En el caso
extremo en que ocurre la prdida, TCP reduce temporalmente la ventana
a la mitad de su valor actual.

TCP utiliza un mecanismo de control de congestin especial al empezar una nueva


relacin o cuando un mensaje se pierde. En lugar de transmitir datos suficientes para llenar
el buffer del receptor (es decir, el tamao de la ventana del receptor), TCP comienza
enviando un nico mensaje de con-tencin de datos. Si un reconocimiento llega sin prdida
adicional, TCP, duplica la cantidad de datos enviados y enva dos mensajes adicionales. Si
ambos reconocen declaraciones llegan, TCP enva cuatro mensajes, y as sucesivamente.
El aumento exponencial contina hasta que TCP es el envo de la mitad de la ventana
anunciado del receptor. Cuando la mitad de la original se alcanza el tamao de ventana
TCP, disminuye su ritmo de crecimiento, y aumenta el tamao de win-dow linealmente
mientras no se produce congestin. El enfoque es conocido como slow start.

Los mecanismos de control de congestin TCP responden bien al aumento de trfico.


Por retroceder rpidamente, TCP es capaz de aliviar la congestin. En esencia, las
retransmisiones TCP se evita agregar cuando el Internet se congestiona. Lo que es ms
importante, si todos los TCPs fol-bajo el estndar, el sistema de control de congestin
significa que todos los emisores de vuelta cuando se produce una congestin y colapso de
congestin es evitada.

26.14 TCP Segment Format

TCP utiliza un formato nico para todos los mensajes, incluidos los mensajes que
contienen datos, aquellos que llevan los agradecimientos, y mensajes que forman parte de
la 3-way handshake utilizado para crear o terminar una conexin (SYN y FIN). Segmento
TCP utiliza el trmino para referirse a un mensaje. La Figura 26.10 muestra el formato del
segmento TCP.
Para entender el formato del segmento, es necesario recordar que un TCP-cin connec
contiene dos secuencias de datos, uno fluye en cada direccin. Si las aplicaciones en cada
extremo estn enviando datos simultneamente, TCP puede enviar un nico segmento que
transporta los datos salientes, el acuse de recibo de los datos entrantes, y una ventana de
publicidad que especifica la cantidad de espacio disponible en el bfer adicional para los
datos entrantes. As, algunos de los campos en el segmento se refieren a la corriente de
datos que viajan en el director de avance-cin, mientras que en otros campos se refiere a la
corriente de datos que viajan en la direccin inversa.
Sec. 26.14El formato del segmento
TCP 445

0 4 10 16 24 31
Puerto de origen Puerto de destino
Nmero de secuencia
Nmero de acuse de recibo
Los bits de
HLEN No se usa cdigo Ventana
CHECKSUM Puntero urgente
Opciones (de
haberlas)
A PARTIR DE LOS
DATOS
.
.

Figura 26.10 El segmento TCP formato utilizado para datos y control- mes
Los sabios.

Cuando un equipo enva un segmento, el nmero de acuse de recibo y los campos de


ventana consulte los datos entrantes: el nmero de acuse de recibo speci-fies el nmero de
secuencia de los datos que se espera para el prximo, y la ventana especifica cunto espacio
de bfer adicional est disponible ms all de los datos confirmados. El ac-knowledgement
siempre se refiere a la primera posicin para la cual faltan datos; si los segmentos llegan
fuera de orden, una recepcin TCP genera el mismo reconocimiento varias veces hasta que
llegue los datos faltantes. El campo Nmero de secuencia se refiere a costo-cin de datos.
Da el nmero de secuencia del primer byte de datos transportada en el seg-mento. Un
receptor utiliza el nmero de secuencia para reordenar segmentos que llegan fuera de orden
y calcular un nmero de confirmacin. El campo Puerto destino identifica qu programa
de aplicacin en el equipo receptor debe recibir los datos, mientras que el campo Puerto
de origen identifica la aplicacin que enva los datos. Por ltimo, el campo Checksum
contiene una suma de comprobacin que cubre el segmento TCP encabezado y los datos.

Las ideas clave con respecto a la numeracin de secuencia y acuse de recibo son:

El campo Nmero de secuencia en un segmento TCP da el nmero de


secuencia del primer byte de datos transportados en el segmento en la
direccin de avance; un nmero de confirmacin da la primera se-
quence nmero para el que faltan datos en la direccin inversa.
446 TCP: Servicio de transporte fiable Cap. 26

26.15 Summary

El Protocolo de control de transmisin (TCP) es el principal protocolo de transporte


del conjunto de protocolos TCP/IP. TCP proporciona programas de aplicacin con un
fiable control de flujo dplex completo, arroyo, servicio de transporte. Tras solicitar de
TCP para establecer una conexin, un programa de aplicacin puede utilizar la conexin
para enviar o recibir datos; TCP garantiza entregar los datos en orden, sin duplicacin. Por
ltimo, cuando los dos de apli-caciones acabado usando una conexin, solicitan que la
conexin se termina.
TCP en un ordenador se comunica con TCP de otro equipo ayud-ing mensajes. Todos
los mensajes de uno a otro TCP utiliza el formato del segmento TCP, incluidos los
mensajes que contienen datos, agradecimientos, anuncios y ventanas, as como de mensajes
utilizados para establecer y finalizar una conexin. Cada segmento TCP ACTRAV-els en
un datagrama IP.
En general, los protocolos de transporte que utilizan una variedad de mecanismos
fiables para asegurar Ser-vicio. TCP tiene una tarea particularmente compleja combinacin
de tcnicas que han demostrado ser sumamente exitoso. Adems de la suma de
comprobacin en cada segmento TCP retransmite cualquier mensaje que se pierde. Para
ser til en la Internet donde las demoras varan con el tiempo, el tiempo de espera de
retransmisin de TCP es adaptable - TCP mide el retardo de ida y vuelta por separado para
cada conexin, y utiliza un promedio ponderado del tiempo de viaje de ida y vuelta para
elegir un tiempo de espera de retransmisin.

Ejercicios

26.1 Asumir que los mensajes enviados entre los dos programas se pueden perder, duplicar,
demorado o entregada fuera de orden. Disear un protocolo que permita a los dos programas
de forma fiable a convenir para comunicarse. Dale a tu diseo a alguien, y ver si se puede
encontrar una secuencia de la prdida, la duplicacin y el retraso que hace el protocolo
fallan.
26.2 Enumerar las funciones de TCP.
26.3 Qu capas de la pila de protocolo se utiliza en un router? Un host?
26.4 Cules son los principales problemas de protocolo de transporte debe resolver para lograr
la transferencia confiable?
26.5 Cules son las tcnicas que utiliza el protocolo de transporte?
26.6 Cuando se utiliza una ventana deslizante de tamao N, cuntos paquetes se pueden enviar
sin requieran-ing un ACK para ser recibido?
26.7 Por qu parar-y-ir protocolo han especialmente bajo rendimiento a travs de un canal de
satlite GEO que opera a dos megabits por segundo?
26.8 Extender el esquema en la figura 26.3 para demostrar la transmisin de diecisis sucesivas
pack-ETS.
26.9 Cul es la principal causa de retardos y prdida de paquetes en el Internet?
26.10 Cmo manejar la prdida de paquetes TCP?