protocolos

ndice general
1

Protocolo orientado a la conexin

1.1

Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3

Lista de protocolos orientados a la conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

Vase tambin

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

1.5

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.6

Enlaces externos

Transmission Control Protocol

2.1

Objetivos de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Informacin tcnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1

Funciones de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.2

Caractersticas del TCP

2.2.3

Formato de los segmentos TCP

2.3

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

Funcionamiento del protocolo en detalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.1

Establecimiento de la conexin (negociacin en tres pasos) . . . . . . . . . . . . . . . . .

2.3.2

Transferencia de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.3

Tamao de ventana TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.4

Escalado de ventana

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

2.3.5

Fin de la conexin

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

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

2.4

Puertos TCP

2.5

Desarrollo de TCP

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

2.6

Comparativa entre UDP y TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.7

Bibliotecas de sockets TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8

Vase tambin

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

2.9

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10 Enlaces externos

3

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

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

Frame Relay
3.1

Frame Relay
3.1.1

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

Aplicaciones y Benecios

3.2

Vase tambin

3.3

Enlaces externos

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

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

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

ii
4

NDICE GENERAL
Modo de Transferencia Asncrona

4.1

Resea histrica de ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2

Descripcin del proceso ATM

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

4.3

Formato de las celdas ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

4.3.1

10

Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4

Encaminamiento

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

4.5

Modelo arquitectnico

4.6

Perspectiva de la tecnologa ATM

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

11

4.7

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

4.8

Vase tambin

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

11

4.9

Enlaces externos

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

11

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

10
11

Protocolo no orientado a la conexin

12

5.1

Lista de protocolos no orientados a la conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

5.2

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

5.3

Vase tambin

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

12

5.4

Enlaces externos

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

12

5.5

Texto e imgenes de origen, colaboradores y licencias . . . . . . . . . . . . . . . . . . . . . . . .

13

5.5.1

Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

5.5.2

Imgenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

5.5.3

Licencia de contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

Captulo 1

Protocolo orientado a la conexin

1.2 Alternativas

Un protocolo orientado a la conexin es un modo de

comunicacin de redes donde se debe establecer una conexin antes de transferir datos. Se identica el ujo
de trco con un identicador de conexin en lugar de
utilizar explcitamente las direcciones de la fuente y el
destino. Tpicamente, el identicador de conexin es un
escalar (por ejemplo en Frame Relay son 10 bits y en
Asynchronous Transfer Mode 24 bits). Esto hace a los
conmutadores de red substancialmente ms rpidos (las
tablas de encaminamiento son ms sencillas, y es ms fcil construir el hardware de los conmutadores). El impacto es tan grande, que protocolos tpicamente no orientados a la conexin, tal como el trco de IP, utilizan prejos orientados a la conexin (por ejemplo IPv6 incorpora
el campo etiqueta de ujo).

Una terminologa alternativa al servicio que ofrece un

protocolo orientado a la conexin y un protocolo no
orientado a la conexin son los servicios de circuitos virtuales y de datagramas respectivamente.
El servicio de circuito virtual es un tipo de servicio orientado a la conexin, dado que implica iniciar y descartar
una entidad de tipo conexin, y mantener informacin del
estado de la conexin en los conmutadores de paquetes.
El servicio de datagrama es un tipo de servicio sin conexin en el que no se emplean entidades de tipo conexin.

1.3 Lista de protocolos orientados

a la conexin

Se dice que un servicio de comunicacin entre dos entidades es orientado a conexin cuando antes de iniciar la
comunicacin se verican determinados datos (disponibilidad, alcance, etc.) entre estas entidades y se negocian
unas credenciales para hacer esta conexin ms segura y
eciente. Este tipo de conexiones suponen mayor carga
de trabajo a una red (y tal vez retardo) pero aportan la
eciencia y abilidad necesaria a las comunicaciones que
la requieran.

protocolo TCP
protocolo FRAME RELAY
protocolo ATM

Algunos protocolos orientados a la conexin son

Transmission Control Protocol, Frame Relay y
Asynchronous Transfer Mode.

1.4 Vase tambin

Protocolo no orientado a la conexin
Circuito virtual

1.1 Seguridad
1.5 Referencias
Hay cierta confusin sobre la seguridad y los servicios
orientados a la conexin y no orientados a la conexin.
En el pasado, cuando haba menos servicios y protocolos, y haba menos aplicaciones, se crea que los servicios
orientados a la conexin eran seguros y los no orientados
a la conexin no eran seguros.

Kurose J. F.; Ross K. W., REDES DE COMPUTADORES.Un enfoque descendente basado en Internet (2.ed 2004), Pearson Educacin ed.

1.6 Enlaces externos

Estas equivalencias no son ciertas.[cita requerida] Es posible

disear una capa de transporte que proporciona un servicio orientado a la conexin no seguro. De forma similar,
una capa de transporte puede proporcionar un servicio no
orientado a la conexin seguro, si utiliza una capa de red
segura.

Kurose J. F.; Ross K. W., redes de computadores

The Transport Layer: Tutorial and Survey

Captulo 2

Transmission Control Protocol

Transmission Control Protocol (TCP) o Protocolo de
Control de Transmisin, es uno de los protocolos fundamentales en Internet. Fue creado entre los aos 1973 y
1974 por Vint Cerf y Robert Kahn.[1]

cliente sean recibidos por el servidor sin errores y en el

mismo orden que fueron emitidos, a pesar de trabajar con
los servicios de la capa IP, la cual no es conable. Es un
protocolo orientado a la conexin, ya que el cliente y el
Muchos programas dentro de una red de datos compuesta servidor deben de anunciarse y aceptar la conexin antes
por redes de computadoras, pueden usar TCP para crear de comenzar a transmitir los datos a ese usuario que debe
recibirlos.
conexiones entre s a travs de las cuales puede enviarse un ujo de datos. El protocolo garantiza que los datos
sern entregados en su destino sin errores y en el mismo 2.2.2 Caractersticas del TCP
orden en que se transmitieron. Tambin proporciona un
mecanismo para distinguir distintas aplicaciones dentro
Permite colocar los datagramas nuevamente en orde una misma mquina, a travs del concepto de puerto.
den cuando vienen del protocolo IP.
TCP da soporte a muchas de las aplicaciones ms populares de Internet (navegadores, intercambio de cheros, clientes FTP, etc.) y protocolos de aplicacin HTTP,
SMTP, SSH y FTP.

Permite el monitoreo del ujo de los datos y as evita

la saturacin de la red.

2.1 Objetivos de TCP

Permite multiplexar los datos, es decir, que la informacin que viene de diferentes fuentes (por ejemplo, aplicaciones) en la misma lnea pueda circular
simultneamente.

Permite que los datos se formen en segmentos de

longitud variada para entregarlos al protocolo IP.

Con el uso de protocolo TCP, las aplicaciones pueden comunicarse en forma segura (gracias al de acuse de reci Por ltimo, permite comenzar y nalizar la comunibo -ACK- del protocolo TCP) independientemente de las
cacin amablemente.
capas inferiores. Esto signica que los routers (que funcionan en la capa de Internet) slo tiene que enviar los
datos en forma de datagrama, sin preocuparse con el monitoreo de datos porque esta funcin la cumple la capa de 2.2.3 Formato de los segmentos TCP
transporte (o ms especcamente el protocolo TCP).
En el nivel de transporte, los paquetes de bits que constituyen las unidades de datos de protocolo TCP se llaman
segmentos. El formato de los segmentos TCP se mues2.2 Informacin tcnica
tra en el esquema segmento TCP.
TCP es usado en gran parte de las comunicaciones de datos. Por ejemplo, gran parte de las comunicaciones que
tienen lugar en Internet emplean TCP.

2.2.1

2.3 Funcionamiento del protocolo

en detalle

Funciones de TCP

Las conexiones TCP se componen de tres etapas:

En la pila de protocolos TCP/IP, TCP es la capa intermedia entre el protocolo de internet (IP) y la aplicacin. Muchas veces las aplicaciones necesitan que la comunicacin
a travs de la red sea conable. Para ello se implementa
el protocolo TCP que asegura que los datos que emite el

1. establecimiento de conexin,
2. transferencia de datos, y
3. n de la conexin.
2

2.3. FUNCIONAMIENTO DEL PROTOCOLO EN DETALLE

Para establecer la conexin se usa el procedimiento llamado negociacin en tres pasos (3-way handshake).
Para la desconexin se usa una negociacin en cuatro
pasos (4-way handshake). Durante el establecimiento de
la conexin, se conguran algunos parmetros tales como
el nmero de secuencia con el n de asegurar la entrega
ordenada de los datos y la robustez de la comunicacin.

2.3.2 Transferencia de datos

Durante la etapa de transferencia de datos, una serie de

mecanismos claves determinan la abilidad y robustez del
protocolo. Entre ellos estn incluidos el uso del nmero
de secuencia para ordenar los segmentos TCP recibidos
y detectar paquetes duplicados, checksums para detectar
errores, y asentimientos y temporizadores para detectar
2.3.1 Establecimiento de la conexin (ne- prdidas y retrasos.
gociacin en tres pasos)
Durante el establecimiento de conexin TCP, los nmeros iniciales de secuencia son intercambiados entre las
dos entidades TCP. Estos nmeros de secuencia son usaServer dos para identicar los datos dentro del ujo de bytes,
Client
y poder identicar (y contar) los bytes de los datos de
SYN
la aplicacin. Siempre hay un par de nmeros de secuenseq=
cia incluidos en todo segmento TCP, referidos al nmero
x
de secuencia y al nmero de asentimiento. Un emisor
y
=
TCP
se reere a su propio nmero de secuencia cuando
q
e
s
x+1
=
habla
de nmero de secuencia, mientras que con el nmek
c
a
-ACK
ro
de
asentimiento se reere al nmero de secuencia del
N
Y
S
receptor. Para mantener la abilidad, un receptor asiente
los segmentos TCP indicando que ha recibido una parACK
ack=
te del ujo continuo de bytes. Una mejora de TCP, llay+1
seq=
mada asentimiento selectivo (Selective Acknowledgement,
x+1
[dat
a]
SACK) permite a un receptor TCP asentir los datos que
se han recibido de tal forma que el remitente solo retransmita los segmentos de datos que faltan.
Negociacin en tres pasos o Three-way handshake

Aunque es posible que un par de entidades nales comiencen una conexin entre ellas simultneamente, normalmente una de ellas abre un socket en un determinado
puerto TCP y se queda a la escucha de nuevas conexiones.
Es comn referirse a esto como apertura pasiva, y determina el lado servidor de una conexin. El lado cliente de
una conexin realiza una apertura activa de un puerto enviando un paquete SYN inicial al servidor como parte de
la negociacin en tres pasos. En el lado del servidor (este receptor tambin puede ser una PC o alguna estacin
terminal) se comprueba si el puerto est abierto, es decir,
si existe algn proceso escuchando en ese puerto, pues se
debe vericar que el dispositivo de destino tenga este servicio activo y est aceptando peticiones en el nmero de
puerto que el cliente intenta usar para la sesin. En caso
de no estarlo, se enva al cliente un paquete de respuesta
con el bit RST activado, lo que signica el rechazo del intento de conexin. En caso de que s se encuentre abierto
el puerto, el lado servidor respondera a la peticin SYN
vlida con un paquete SYN/ACK. Finalmente, el cliente
debera responderle al servidor con un ACK, completando as la negociacin en tres pasos (SYN, SYN/ACK y
ACK) y la fase de establecimiento de conexin. Es interesante notar que existe un nmero de secuencia generado por cada lado, ayudando de este modo a que no se
puedan establecer conexiones falseadas (spoong).

A travs del uso de nmeros de secuencia y asentimiento,

TCP puede pasar los segmentos recibidos en el orden correcto dentro del ujo de bytes a la aplicacin receptora.
Los nmeros de secuencia son de 32 bits (sin signo), que
vuelve a cero tras el siguiente byte despus del 232 1.
Una de las claves para mantener la robustez y la seguridad de las conexiones TCP es la seleccin del nmero
inicial de secuencia (Initial Sequence Number, ISN).
Un checksum de 16 bits, consistente en el complemento
a uno de la suma en complemento a uno del contenido
de la cabecera y datos del segmento TCP, es calculado
por el emisor, e incluido en la transmisin del segmento.
Se usa la suma en complemento a uno porque el acarreo
nal de ese mtodo puede ser calculado en cualquier mltiplo de su tamao (16-bit, 32-bit, 64-bit...) y el resultado,
una vez plegado, ser el mismo. El receptor TCP recalcula el checksum sobre las cabeceras y datos recibidos.
El complemento es usado para que el receptor no tenga
que poner a cero el campo del checksum de la cabecera antes de hacer los clculos, salvando en algn lugar el
valor del checksum recibido; en vez de eso, el receptor
simplemente calcula la suma en complemento a uno con
el checksum incluido, y el resultado debe ser igual a 0. Si
es as, se asume que el segmento ha llegado intacto y sin
errores.
Hay que jarse en que el checksum de TCP tambin cubre
los 96 bit de la cabecera que contiene la direccin origen,
la direccin destino, el protocolo y el tamao TCP. Esto
proporciona proteccin contra paquetes mal dirigidos por

CAPTULO 2. TRANSMISSION CONTROL PROTOCOL

errores en las direcciones.

en el bfer de recepcin durante la conexin. La entidad

El checksum de TCP es una comprobacin bastante d- emisora puede enviar una cantidad determinada de datos
bil. En niveles de enlace con una alta probabilidad de pero antes debe esperar un asentimiento con la actualizaerror de bit quiz requiera una capacidad adicional de cin del tamao de ventana por parte del receptor.
correccin/deteccin de errores de enlace. Si TCP fue- Un ejemplo sera el siguiente: un receptor comienza con
se rediseado hoy, muy probablemente tendra un cdigo un tamao de ventana X y recibe Y bytes, entonces su tade redundancia cclica (CRC) para control de errores en mao de ventana ser (X - Y) y el transmisor slo podr
vez del actual checksum. La debilidad del checksum es- mandar paquetes con un tamao mximo de datos de (X t parcialmente compensada por el extendido uso de un Y) bytes. Los siguientes paquetes recibidos seguirn resCRC en el nivel de enlace, bajo TCP e IP, como el usa- tando tamao a la ventana de recepcin. Esta situacin
do en el PPP o en Ethernet. Sin embargo, esto no sig- seguir as hasta que la aplicacin receptora recoja los
nica que el checksum de 16 bits es redundante: sor- datos del bfer de recepcin.
prendentemente, inspecciones sobre el trco de Internet
han mostrado que son comunes los errores de software y
hardware[cita requerida] que introducen errores en los paque- 2.3.4 Escalado de ventana
tes protegidos con un CRC, y que el checksum de 16 bits
Para una mayor eciencia en redes de gran ancho de bande TCP detecta la mayora de estos errores simples.
da, debe ser usado un tamao de ventana mayor. El camLos asentimientos (ACK o Acknowledgments) de los dapo TCP de tamao de ventana controla el movimiento de
tos enviados o la falta de ellos, son usados por los emidatos y est limitado a 16 bits, es decir, a un tamao de
sores para interpretar las condiciones de la red entre el
ventana de 65.535 bytes.
emisor y receptor TCP. Unido a los temporizadores, los
emisores y receptores TCP pueden alterar el comporta- Como el campo de ventana no puede expandirse se usa
miento del movimiento de datos. TCP usa una serie de un factor de escalado. La escala de ventana TCP (TCP
mecanismos para conseguir un alto rendimiento y evi- window scale) es una opcin usada para incrementar el
tar la congestin de la red (la idea es enviar tan rpido mximo tamao de ventana desde 65.535 bytes, a 1 Gicomo el receptor pueda recibir). Estos mecanismos in- gabyte.
cluyen el uso de ventana deslizante, que controla que el La opcin de escala de ventana TCP es usada solo durantransmisor mande informacin dentro de los lmites del te la negociacin en tres pasos que constituye el comienzo
bfer del receptor, y algoritmos de control de ujo, tales de la conexin. El valor de la escala representa el nmero
como el algoritmo de evitacin de la congestin (conges- de bits desplazados a la izquierda de los 16 bits que fortion avoidance), el de comienzo lento (slow-start), el de man el campo del tamao de ventana. El valor de la escala
retransmisin rpida, el de recuperacin rpida (fast re- puede ir desde 0 (sin desplazamiento) hasta 14. Hay que
covery), y otros.
recordar que un nmero binario desplazado un bit a la
izquierda es como multiplicarlo en base decimal por 2.
Control de ujo
TCP usa control de ujo para evitar que un emisor enve
datos de forma ms rpida de la que el receptor puede recibirlos y procesarlos. El control de ujo es un mecanismo esencial en redes en las que se comunican computadoras con distintas velocidades de transferencia. Por ejemplo, si una PC enva datos a un dispositivo mvil que procesa los datos de forma lenta, el dispositivo mvil debe
regular el ujo de datos.
TCP usa una ventana deslizante para el control de ujo. En cada segmento TCP, el receptor especica en el
campo receive window la cantidad de bytes que puede almacenar en el bfer para esa conexin. El emisor puede
enviar datos hasta esa cantidad. Para poder enviar ms
datos debe esperar que el receptor le enve un ACK con
un nuevo valor de ventana.

2.3.3

Tamao de ventana TCP

2.3.5 Fin de la conexin

Servidor

Cliente
Transferencia
de datos
Terminar
conexin

Transferencia
de datos

FIN
ACK
FIN

Conexin
terminada

ACK
Conexin
terminada

Cierre de una conexin segn el estndar.

El tamao de la ventana de recepcin TCP es la canti- La fase de nalizacin de la conexin utiliza una negodad de datos recibidos (en bytes) que pueden ser metidos ciacin en cuatro pasos (four-way handshake), terminan-

2.6. COMPARATIVA ENTRE UDP Y TCP

do la conexin desde cada lado independientemente. Sin

embargo, es posible realizar la nalizacin de la conexin
en 3 fases; enviando el segmento FIN y el ACK en uno
solo.[2] Cuando uno de los dos extremos de la conexin
desea parar su mitad de conexin transmite un segmento con el ag FIN en 1, que el otro interlocutor asentir
con un ACK. Por tanto, una desconexin tpica requiere
un par de segmentos FIN y ACK desde cada lado de la
conexin.

RFC 793, publicado en 1981. El documento RFC 1122

(Host Requirements for Internet Hosts), especica el nmero de requisitos de una implementacin del protocolo TCP.[4] El RFC 2581 (Control de Congestin TCP)
es uno de los ms importantes documentos relativos a
TCP de los ltimos aos, describe nuevos algoritmos para evitar la congestin excesiva.[5] En 2001, el RFC 3168
fue escrito para describir la Noticacin de Congestin
Explcita (ECN), una forma de eludir la congestin con
Una conexin puede estar medio abierta en el caso de mecanismos de sealizacin. En los comienzos del siglo
XXI, TCP es usado en el 95% de todos los paquetes que
que uno de los lados la nalice pero el otro no. El lado
[cita requerida]
Entre las aplicaciones
que ha dado por nalizada la conexin no puede enviar circulan por Internet.
ms comunes que usan TCP estn HTTP/HTTPS (World
ms datos pero la otra parte si podr.
Wide Web), SMTP/POP3/IMAP (correo electrnico) y
FTP (transferencia de cheros). Su amplia extensin ha
sido la prueba para los desarrolladores originales de que
2.4 Puertos TCP
su creacin estaba excepcionalmente bien hecha.
TCP usa el concepto de nmero de puerto para identicar a las aplicaciones emisoras y receptoras. Cada lado
de la conexin TCP tiene asociado un nmero de puerto
(de 16 bits sin signo, con lo que existen 65536 puertos
posibles) asignado por la aplicacin emisora o receptora.
Los puertos son clasicados en tres categoras:
1. bien conocidos,
2. registrados, y

Recientemente, un nuevo algoritmo de control de congestin fue desarrollado y nombrado como FAST TCP
(Fast Active queue management Scalable Transmission
Control Protocol) por los cientcos de California Institute of Technology (Caltech). Es similar a TCP Vegas en
cuanto a que ambos detectan la congestin a partir de los
retrasos en las colas que sufren los paquetes al ser enviados a su destino. Todava hay un debate abierto sobre si este es un sntoma apropiado para el control de la
congestin.[cita requerida]

3. dinmicos/privados.
Los puertos bien conocidos son asignados por la Internet
Assigned Numbers Authority (IANA), van del 0 al 1023 y
son usados normalmente por el sistema o por procesos
con privilegios.[3] Las aplicaciones que usan este tipo de
puertos son ejecutadas como servidores y se quedan a la
escucha de conexiones. Algunos ejemplos son: FTP (21),
SSH (22), Telnet (23), SMTP (25) y HTTP (80).
Los puertos registrados son normalmente empleados
por las aplicaciones de usuario de forma temporal cuando
conectan con los servidores, pero tambin pueden representar servicios que hayan sido registrados por un tercero
(rango de puertos registrados: 1024 al 49151).
Los puertos dinmicos/privados tambin pueden ser
usados por las aplicaciones de usuario, pero este caso es
menos comn. Los puertos dinmicos/privados no tienen
signicado fuera de la conexin TCP en la que fueron
usados (rango de puertos dinmicos/privados: 49152 al
65535, recordemos que el rango total de 2 elevado a la
potencia 16, cubre 65536 nmeros, del 0 al 65535).

2.5 Desarrollo de TCP

TCP es un protocolo muy desarrollado y complejo. Sin
embargo, mientras mejoras signicativas han sido propuestas y llevadas a cabo a lo largo de los aos, ha conservado las operaciones ms bsicas sin cambios desde el

2.6 Comparativa entre UDP y TCP

UDP: proporciona un nivel de transporte no able
de datagramas, ya que apenas aade la informacin necesaria para la comunicacin extremo a extremo al paquete que enva al nivel inferior. Lo utilizan aplicaciones como NFS (Network File System)
y RCP (comando para copiar cheros entre computadores remotos), pero sobre todo se emplea en tareas de control y en la transmisin de audio y vdeo
a travs de una red. No introduce retardos para establecer una conexin, no mantiene estado de conexin alguno y no realiza seguimiento de estos parmetros. As, un servidor dedicado a una aplicacin
particular puede soportar ms clientes activos cuando la aplicacin corre sobre UDP en lugar de sobre
TCP.[cita requerida]
TCP: es el protocolo que proporciona un transporte able de ujo de bits entre aplicaciones. Est pensado para poder enviar grandes cantidades de
informacin de forma able, liberando al programador de la dicultad de gestionar la abilidad de la conexin (retransmisiones, prdida de paquetes, orden
en el que llegan los paquetes, duplicados de paquetes...) que gestiona el propio protocolo. Pero la complejidad de la gestin de la abilidad tiene un coste
en eciencia, ya que para llevar a cabo las gestiones
anteriores se tiene que aadir bastante informacin

CAPTULO 2. TRANSMISSION CONTROL PROTOCOL

a los paquetes que enviar. Debido a que los paquetes
para enviar tienen un tamao mximo, cuanta ms
informacin aada el protocolo para su gestin, menos informacin que proviene de la aplicacin podr
contener ese paquete (el segmento TCP tiene una
sobrecarga de 20 bytes en cada segmento, mientras
que UDP solo aade 8 bytes). Por eso, cuando es
ms importante la velocidad que la abilidad, se utiliza UDP. En cambio, TCP asegura la recepcin en
destino de la informacin para transmitir.

2.7 Bibliotecas de sockets TCP

[2] Andrew S. Tanenbaum y David J. Wetherall, Redes

de computadoras, Quinta edicin, Pearson Educacin,
2012,Pg. 482
[3] Asignacin de puertos del IANA
[4] Ver RFC 1122
[5] Ver RFC 2581
[6] http://www.solarsockets.solar-opensource.com
[7] http://www.solarsockets.solar-opensource.com/index.
php/Ejemplos
[8] http://www.libsdl.org/projects/SDL_net/
[9] http://www.alhem.net/Sockets/index_spanish.html

Se listan algunas de las bibliotecas de comunicaciones

existentes, que utilizan los protocolos TCP y UDP para [10] http://www.gnu.org/software/commoncpp/docs/refman/
html/_sample_socket_port_8cpp-example.html
distintos sistemas operativos.
SolarSockets es una biblioteca para C++ Multiplataforma y Multithread, gratuita para proyectos
libres.[6] Fcil de usar y con varios ejemplos.[7]
SDL NET proporciona funciones y tipos de dato
multiplataforma para programar aplicaciones que
trabajen con redes.[8]
C++ Sockets Library es una biblioteca de clases en
C++ bajo licencia GPL que 'mapea' el berkeley sockets C API, y funciona tanto en algunos sistemas
Unix como en Win32.[9]
GNU Common C++ es una biblioteca de propsito
general que incluye funciones de red.[10]
HackNet es una biblioteca de comunicaciones para
crear juegos multijugador.[11]
DirectPlay simplica el acceso de las aplicaciones a
los servicios de comunicacin. Es una componente
de DirectX.

2.8 Vase tambin

Implementaciones de TCP
Lista de nmeros de puerto
SCTP
UDP
Ruido de fondo de internet

2.9 Referencias
[1] Cerf, V.; Kahn, R. (1974). A Protocol for Packet Network Intercommunication. IEEE Transactions on Communications. COM-22 (5): 637648.

[11] http://hacknet.sourceforge.net/

2.10 Enlaces externos

RFC793 en texto en claro
RFC1180 Un Tutorial de TCP/IP
Administracin avanzada de redes TCP/IP. Javier Carmona Murillo, David Corts Polo, M.
Domnguez-Dorado, Alfonso Gazo-Cervero, JosLuis Gonzlez-Snchez, Francisco Javier Rodrguez
Prez. ISBN 978-84-695-2037-6. January, 2012.
Protocolo TCP
Comunicaciones y redes de computadoras

Captulo 3

Frame Relay
Frame Relay o (Frame-mode Bearer Service) es una tcnica de comunicacin mediante retransmisin de tramas
para redes de circuito virtual, introducida por la ITUT a partir de la recomendacin I.122 de 1988. Consiste
en una forma simplicada de tecnologa de conmutacin
de paquetes que transmite una variedad de tamaos de
tramas o marcos (frames) para datos, perfecto para la
transmisin de grandes cantidades de datos.

No obstante, cabe la posibilidad de transmitir por encima del CIR contratado, mediante los Be (Excess Burst).
Estos datos que superan lo contratado, sern enviados en
modo best-eort, activndose el bit DE de estas tramas,
con lo que sern las primeras en ser descartadas en caso
de congestin en algn nodo.

La tcnica Frame Relay se utiliza para un servicio de

transmisin de voz y datos a alta velocidad que permite
la interconexin de redes de rea local separadas geogrcamente a un coste menor.

3.1 Frame Relay

Frame Relay proporciona conexiones y vitlatla entre
usuarios a travs de una red pblica, del mismo modo
que lo hara una red privada punto a punto, esto quiere
decir que es orientado a la conexin.
Las conexiones pueden ser del tipo permanente, (PVC,
Permanent Virtual Circuit) o conmutadas (SVC, Switched
Virtual Circuit). Por ahora slo se utiliza la permanente.
De hecho, su gran ventaja es la de reemplazar las lneas
privadas por un slo enlace a la red.
El uso de conexiones implica que los nodos de la red son
conmutadores, y las tramas deben llegar ordenadas al destinatario, ya que todas siguen el mismo camino a travs
de la red, puede manejar tanto trco de datos como de
voz.
Al contratar un servicio Frame Relay, contratamos un ancho de banda determinado en un tiempo determinado. A
este ancho de banda se le conoce como CIR (Commited
Information Rate). Esta velocidad, surge de la divisin de
Bc (Committed Burst), entre Tc (el intervalo de tiempo).
No obstante, una de las caractersticas de Frame Relay es
su capacidad para adaptarse a las necesidades de las aplicaciones, pudiendo usar una mayor velocidad de la contratada en momentos puntuales, adaptndose muy bien al
trco en rfagas. Aunque la media de trco en el intervalo Tc no deber superar la cantidad estipulada Bc.

Como se observa en la imagen, las tramas que superen

la cantidad de Bc+Be en el intervalo, sern descartadas
directamente sin llegar a entrar en la red, sin embargo
las que superan la cantidad Bc pero no Bc+Be se marcan
como descartables (DE=1) para ser estas las primeras en
ser eliminadas en caso de congestin.
Para realizar control de congestin de la red, Frame Relay activa unos bits, que se llaman FECN (forward explicit congestion notication), BECN (backward explicit

Estos bits de Bc sern enviados de forma transparente.

7

CAPTULO 3. FRAME RELAY

congestion notication) y DE (Discard Eligibility). Para

ello utiliza el protocolo LAPF, un protocolo de nivel de
enlace que mejora al protocolo LAPD.

Tarifa ja. Los precios no son sensitivos a la distancia, lo que signica que los clientes no son penalizados por conexiones a largas distancias.

FECN se activa, o lo que es lo mismo, se pone en 1, cuando hay congestin en el mismo sentido que va la trama.

Mayor exibilidad. Las conexiones son denidas por

los programas. Los cambios hechos a la red son ms
rpidos y a menor costo si se comparan con otros
servicios.

BECN se activa cuando hay congestin en el sentido

opuesto a la transmisin. DE igual a 1 indica que la trama ser descartable en cuanto haya congestin. Se utiliza
el llamado Algoritmo del Cubo Agujereado, de forma
que se simulan 2 cubos con un agujero en el fondo: Por el
primero de ellos pasan las tramas con un trco inferior a
CIR, el que supera este lmite pasa al segundo cubo, por
el que pasar el trco inferior a CIR+EIR (y que tendrn
DE=1). El que supera este segundo cubo es descartado.
En cada nodo hay un gestor de tramas, que decide, en caso de congestin, a quien noticar, si es leve avisa a las
estaciones que generan ms trco, si es severa le avisa
a todos. Siguiendo el algoritmo anterior, podramos descartar en el peor de los casos el trco que pasa a travs
del segundo cubo. Este funcionamiento garantiza que se
cumplen las caractersticas de la gestin de trco.
Por otro lado, no lleva a cabo ningn tipo de control de
errores o ujo, ya que delega ese tipo de responsabilidades en capas superiores, obteniendo como resultado una
notable reduccin del trco en la red, aumentando signicativamente su rendimiento. Esta delegacin de responsabilidades tambin conlleva otra consecuencia, y es
la reduccin del tamao de su cabecera, necesitando de
menor tiempo de proceso en los nodos de la red y consiguiendo de nuevo una mayor eciencia. Esta delegacin
de control de errores en capas superiores es debido a que
Frame Relay trabaja bajo redes digitales en las cuales la
probabilidad de error es muy baja.

3.1.1

Aplicaciones y Benecios

Reduccin de complejidad en la red. elecciones virtuales mltiples son capaces de compartir la misma
lnea de acceso.
Equipo a costo reducido. Se reduce las necesidades del hardware y el procesamiento simplicado
ofrece un mayor rendimiento por su dinero.
Mejora del desempeo y del tiempo de respuesta. penetracin directa entre localidades con pocos
atrasos en la red.
Mayor disponibilidad en la red. Las conexiones a la
red pueden redirigirse automticamente a diversos
cursos cuando ocurre un error.
Se pueden utilizar procedimientos de Calidad de
Servicio (QoS) basados en el funcionamiento Frame Relay.

Ofrece mayores velocidades y rendimiento, a la vez

que provee la eciencia de ancho de banda que viene
como resultado de los mltiples circuitos virtuales
que comparten un puerto de una sola lnea.
Los servicios de Frame Relay son conables y de alto rendimiento. Son un mtodo econmico de enviar
datos, convirtindolo en una alternativa a las lneas
dedicadas.
El Frame Relay es ideal para usuarios que necesitan
una conexin de mediana o alta velocidad para mantener un trco de datos entre localidades mltiples
y distantes .
Opcionales WEB, Libros virtuales: redes...
Frame Relay constituye un mtodo de comunicacin
orientado a paquetes para la conexin de sistemas informticos. Se utiliza principalmente para la interconexin
de redes de rea local (LANs, local area networks) y redes de rea extensa (WANs, wide area networks) sobre
redes pblicas o privadas. La mayora de compaas pblicas de telecomunicaciones ofrecen los servicios Frame
Relay como una forma de establecer conexiones virtuales de rea extensa que ofrezcan unas prestaciones relativamente altas. Frame Relay es una interfaz de usuario
dentro de una red de conmutacin de paquetes de rea
extensa, que tpicamente ofrece un ancho de banda comprendida en el rango de 56 kbit/s y 1.544 Mbit/s. Frame
Relay se origin a partir de las interfaces ISND y se propuso como estndar al Comit consultivo internacional
para telegrafa y telefona (CCITT) en 1984. El comit
de normalizacin T1S1 de los Estados Unidos, acreditado por el Instituto americano de normalizacin (ANSI),
realiz parte del trabajo preliminar sobre Frame Relay.

3.2 Vase tambin

Norma X.25
Asynchronous Transfer Mode
Data Link Connection Identier

3.3 Enlaces externos

Recomendacin I.122 de la ITU.

Captulo 4

Modo de Transferencia Asncrona

retardos inaceptables de hasta 85 ms. Este retardo no permitira la transmisin de voz con cierto nivel de calidad a
la vez que obligaba a instalar canceladores de eco.
Despus de muchas discusiones y ante la falta de acuerdo,
en la reunin del CCITT celebrada en Ginebra en junio
de 1989 se tom una decisin salomnica: Ni para unos
ni para otros. 48 bytes ser el tamao de la celda. Para
la cabecera se tom un tamao de 5 bytes. Un extrao
nmero primo 53 (48+5) sera el tamao denitivo, en
octetos, de las clulas ATM. Un nmero que tuvo la virtud
de no satisfacer a nadie, pero que supona una conciliacin
de todos los grupos de inters y evitaba una ruptura de
consecuencias imprevisibles.

Tarjeta de red ATM de 25 Mbps con interfaz PCI y conexin de

par trenzado.

El Modo de Transferencia Asncrona (Asynchro- 4.2 Descripcin del proceso ATM

nous Transfer Mode, ATM) es una tecnologa de
telecomunicacin desarrollada para hacer frente a la gran
Con esta tecnologa, a n de aprovechar al mximo la cademanda de capacidad de transmisin para servicios y
pacidad de los sistemas de transmisin, sean estos de caaplicaciones.
ble o radioelctricos, la informacin no es transmitida y
conmutada a travs de canales asignados en permanencia,
sino en forma de cortos paquetes (celdas ATM) de longi4.1 Resea histrica de ATM
tud constante y que pueden ser enrutadas individualmente
mediante el uso de los denominados canales virtuales y
La primera referencia del ATM (Asynchronous Transfer trayectos virtuales.
Mode) tiene lugar en los aos 60 cuando un norteamericano de origen oriental perteneciente a los laboratorios
Bell describi y patent un modo de transferencia no sncrono. Sin embargo el ATM no se hizo popular hasta
1988 cuando el CCITT decidi que sera la tecnologa de
conmutacin de las futuras redes ISDN en banda ancha
(rec I.121).
Para ello, el equipo detrs del ATM tuvo primero que
persuadir a algunos representantes de las redes de comunicaciones que hubieran preferido una simple ampliacin
de las capacidades de la ISDN en banda estrecha. Conseguido este primer objetivo y desechando los esquemas
de transmisin sncronos, se empezaron a discutir aspectos tales como el tamao de las celdas. Por un lado los
representantes de EEUU y otros pases proponan un tamao de celdas grande de unos 64 bytes. Sin embargo
para los representantes de los pases europeos el tamao
ideal de las celdas era de 32 bytes (segn Tanenbaum), y
sealaban que un tamao de celda de 64 bytes provocara

Figura 1: Diagrama simplicado del proceso ATM.

En la gura 1 se ilustra la forma en que diferentes ujos de informacin, de caractersticas distintas en cuanto
a velocidad y formato, son agrupados en el denominado
Mdulo ATM para ser transportados mediante grandes
enlaces de transmisin a velocidades (bit rate) de 155 o
622 Mbit/s facilitados generalmente por sistemas SDH.
9

10

CAPTULO 4. MODO DE TRANSFERENCIA ASNCRONA

En el terminal transmisor, la informacin es escrita byte

a byte en el campo de informacin de usuario de la celda
y a continuacin se le aade la cabecera.

el campo GFC para labores de gestin de trco,

pero en la prctica no es utilizado. Las celdas NNI
lo emplean para extender el campo VPI a 12 bits.

En el extremo distante, el receptor extrae la informacin,

tambin byte a byte, de las celdas entrantes y de acuerdo con la informacin de cabecera, la enva donde sta le
indique, pudiendo ser un equipo terminal u otro mdulo ATM para ser encaminada a otro destino. En caso de
haber ms de un camino entre los puntos de origen y destino, no todas las celdas enviadas durante el tiempo de conexin de un usuario sern necesariamente encaminadas
por la misma ruta, ya que en ATM todas las conexiones
funcionan sobre una base virtual.

VPI (Virtual Path Identier, Identicador de Ruta

Virtual, 8 bits) y VCI (Virtual Channel Identier,
Identicador de Circuito Virtual, 16 bits): se utilizan
para indicar la ruta de destino o nal de la clula.

4.3 Formato de las celdas ATM

Son estructuras de datos de 53 bytes compuestas por dos
campos principales:
1. Header o Cabecera, sus 5 bytes tienen tres funciones principales:
(a) identicacin del canal,

PT (Payload Type, Tipo de Informacin de Usuario, 3 bits): identica el tipo de datos de la celda (de
datos del usuario o de control). Uno identica el tipo
de carga en el campo de usuario, otro indica si hay
congestin en la red y el ltimo es el SDU.
CLP (Cell Loss Priority, Prioridad, 1 bit): indica el
nivel de prioridad de la celda, si este bit est activo cuando la red ATM est congestionada la celda
puede ser descartada.
HEC (Header Error Correction, Correccin de
Error de Cabecera, 8 bits): contiene un cdigo de
deteccin de error que slo cubre la cabecera (no la
informacin de usuario), y que permite detectar un
buen nmero de errores mltiples y corregir errores
simples.

(b) informacin para la deteccin de errores

(c) y si la clula es o no utilizada.
(d) Eventualmente puede contener tambin correccin de errores y un nmero de secuencia.

4.4 Encaminamiento

ATM ofrece un servicio orientado a conexin, en el cual

2. Payload, tiene 48 bytes fundamentalmente con da- no hay un desorden en la llegada de las celdas al destino.
tos del usuario y protocolos AAL que tambin son Esto lo hace gracias a los caminos o rutas virtuales (VP,
considerados como datos del usuario.
Virtual Path) y los canales o circuitos virtuales (VC, Virtual Channel). Los caminos y canales virtuales tienen el
Dos de los conceptos ms signicativos del ATM, Ca- mismo signicado que las conexiones de canales virtuanales Virtuales y Rutas Virtuales, estn materializados les (VCC, Virtual Channel Connection) en X.25, que inen dos identicadores en el header de cada clula (VCI y dica el camino jo que debe seguir la celda. En el caso
VPI), ambos determinan el encaminamiento entre nodos. de ATM, los caminos virtuales (VP), son los caminos que
siguen las celdas entre dos router ATM pero este camino
El estndar dene el protocolo orientado a conexin que puede tener varios circuitos virtuales (VC).
las transmite y dos tipos de formato de celda:
En el momento de establecer la comunicacin con una ca NNI (Network to Network Interface, Interfaz Red a lidad de servicio deseada y un destino, se busca el camino
Red): el cual se reere a la conexin de switches ATM virtual que van a seguir todas las celdas. Este camino no
cambia durante toda la comunicacin, as que si se cae un
en redes privadas.
nodo la comunicacin se pierde. Durante la conexin se
UNI (User to Network Interface, Interfaz Usuario reservan los recursos necesarios para garantizarle durante
a Red): se reere a la conexin de un switch ATM toda la sesin la calidad del servicio al usuario.
de una empresa pblica o privada con un terminal
Cuando una celda llega a un encaminador, este le camATM de un usuario normal, siendo este ltimo el
bia el encabezado segn la tabla que posee y lo enva al
ms utilizado.
siguiente con un VPI y/o un VCI nuevo.
La ruta inicial de encaminamiento se obtiene, en la mayora de los casos, a partir de tablas estticas que residen
en los conmutadores. Tambin podemos encontrar tablas
dinmicas que se conguran dependiendo del estado de
4.3.1 Campos
la red al comienzo de la conexin; este es uno de los pun GFC (Generic Flow Control, Control de Flujo Ge- tos donde se ha dejado libertad para los fabricantes. Gran
nrico, 4 bits): el estndar originariamente reserv parte del esfuerzo que estn haciendo las compaas est

4.9. ENLACES EXTERNOS

dedicado a esta rea, puesto que puede ser el punto fundamental que les permita permanecer en el mercado en
un futuro.

4.5 Modelo arquitectnico

11

4.9 Enlaces externos

www.atmforum.com ATM forum.
www.telecomspace.com/vop-atm.html ATM Info
and resources.
ATM Cell formats- Cisco Systems.

La conmutacin de clulas est intercalada entre las funciones de transmisin y las que adaptan los diferentes tipos de trco a los ujos conmutados, lo que plantea un
modelo arquitectnico de tres capas:
1. Capa fsica: relacionada con el medio fsico de
transmisin, adapta ujos, protege cabeceras, delimita clulas y adapta al medio.
2. Capa ATM: realiza la multiplexacin y conmutacin de clulas.
3. Capa AAL (ATM Adaptation Layer): relacionada
con los ujos de informacin, facilita la gestin de
caudales, modos de conexin y en caso necesario,
referencia de sincronismo.

4.6 Perspectiva de la tecnologa

ATM
El Modo de Transferencia Asncrona fue la apuesta de
la industria tradicional de las telecomunicaciones por las
comunicaciones de banda ancha. Se plante como herramienta para la construccin de redes de banda ancha (BRDSI o B-ISDN) basadas en conmutacin de paquetes
en vez de la tradicional conmutacin de circuitos. El despliegue de la tecnologa ATM no ha sido el esperado por
sus promotores. Las velocidades para las que estaba pensada (hasta 622 Mbps) han sido rpidamente superadas;
no est claro que ATM sea la opcin ms adecuada para
las redes actuales y futuras, de velocidades del orden del
gigabit. ATM se ha encontrado con la competencia de las
tecnologas provenientes de la industria de la Informtica,
que con proyectos tales como la VoIP parece que ofrecen
las mejores perspectivas de futuro.
En la actualidad, ATM es ampliamente utilizado all donde se necesita dar soporte a velocidades moderadas, como
es el caso de la ADSL, aunque la tendencia es sustituir esta tecnologa por otras como Ethernet que est basada en
tramas de datos.

4.7 Referencias
4.8 Vase tambin
Familia de protocolos de Internet

Asynchronous Transfer Mode (ATM) - Cisco Systems.

www.chipweb.de/atm/ ATM ChipWeb - Chip and
NIC database.
Reference for Q.2931 etc Link failes.
Netheads vs Bellheads by Steve Steinberg.
A tutorial from Juniper web site.
Asynchronous Transfer Mode Networks.
ATM Tutorial.

Captulo 5

Protocolo no orientado a la conexin

En telecomunicaciones, no orientado a la conexin sig- 5.3 Vase tambin
nica una comunicacin entre dos puntos nales de una
red en los que un mensaje puede ser enviado desde un
Protocolo orientado a la conexin
punto nal a otro sin acuerdo previo. El dispositivo en un
extremo de la comunicacin transmite los datos al otro,
sin tener que asegurarse de que el receptor est disponible
5.4 Enlaces externos
y listo para recibir los datos. El emisor simplemente enva un mensaje dirigido al receptor. Cuando se utiliza esta
forma de comunicacin son ms frecuentes los problemas Kurose J. F.; Ross K. W., Redes de computadores
de transmisin que con los protocolos orientado a la conexin y puede ser necesario reenviar varias veces los datos.
Los protocolos no orientados a la conexin son a menudo rechazados por los administradores de redes que utilizan cortafuegos porque los paquetes maliciosos son ms
difciles de ltrar. El protocolo IP y el protocolo UDP
son protocolos no orientados a la conexin, pero TCP es
un protocolo orientado a la conexin. Los protocolos no
orientados a la conexin son descritos generalmente como sin estado porque los puntos nales no guardan informacin para recordar una conversacin de cambios
de mensajes. La alternativa al enfoque no orientado a la
conexin es utilizar protocolos orientados a la conexin,
que son descritos a veces como con estado porque pueden
seguir una conversacin.

5.1 Lista de protocolos no orientados a la conexin

protocolo IP
protocolo UDP
ICMP
IPX
TIPC

5.2 Referencias
Kurose J. F.; Ross K. W., Redes de computadores.Un enfoque descendente basado en Internet (2.ed
2004), Pearson Educacin ed.
12

5.5. TEXTO E IMGENES DE ORIGEN, COLABORADORES Y LICENCIAS

13

5.5 Texto e imgenes de origen, colaboradores y licencias

5.5.1

Texto

Protocolo orientado a la conexin Fuente: https://es.wikipedia.org/wiki/Protocolo_orientado_a_la_conexi%C3%B3n?oldid=84824754

Colaboradores: Siabef, Biasoli, Lucien leGrey, Muro Bot, PaintBot, Macarse, Mutari, Gabaro, Farisori, Botito777, Almabot, Victoria84,
Addbot y Annimos: 6
Transmission Control Protocol Fuente: https://es.wikipedia.org/wiki/Transmission_Control_Protocol?oldid=84886385 Colaboradores:
Hashar, Aloriel, Rsg, Aequanimous, Tano4595, Barcex, Porao, 142857, Caos, Digigalos, Petronas, Rembiapo pohyiete (bot), Caiser, NekroByte, Orgullobot~eswiki, RobotQuistnix, Dibujon, Yrbot, FlaBot, Vitamine, YurikBot, GermanX, Equi, KnightRider, JRGL, Play284,
Scardoso, Pieraco, Maldoror, Er Komandante, Ciencia Al Poder, Cheveri, Chlewbot, Siabef, Paintman, BOTpolicia, CEM-bot, Damifb,
DEEJAY, Paco c, Roberpl, Thijs!bot, PabloCastellano, Xoacas, IrwinSantos, Isha, Martin Rizzo, Mpeinadopa, JAnDbot, Jugones55, BetBot~eswiki, Muro de Aguas, Gaius iulius caesar, TXiKiBoT, Rei-bot, NaSz, Plux, Snakefang, Cinevoro, VolkovBot, Technopat, Raystorm, Matdrodes, Trustee~eswiki, Shooke, Barri, Muro Bot, SieBot, DaBot~eswiki, Loveless, Cobalttempest, Er conde, Paconi, Idleloop,
ElYeante, Egjose, Marcecoro, HUB, Mrzeon, David.rgh, Ignacio Jorge Castaos Gonzalez, PixelBot, Botelln, Marcelo8776, Alejandrocaro35, Alecs.bot, Alexbot, Darkicebot, BodhisattvaBot, AVBOT, Edenial, LucienBOT, MastiBot, Pipandro, Diegusjaimes, DumZiBoT,
MelancholieBot, Dcostanzo, Luckas-bot, Nallimbot, Jrodri18, Princess 14, KrlosT, Billinghurst, Gacpro, Hampcky, Vivaelcelta, DirlBot,
ArthurBot, Xqbot, Jkbw, Ismael ule, Rubinbot, Ricardogpn, Botarel, BenzolBot, RedBot, LoliBot, PatruBOT, Ripchip Bot, JdmGarcia,
Foundling, EmausBot, AVIADOR, Guarddon, Usuariotuputhamadre, KLBot, Rubpe19, ChuispastonBot, Snubcube, Miguel.baillon, MerlIwBot, MetroBot, Invadibot, IRedRat, Elvisor, Agckem, Otosan-kf, Legobot, AleAnonMallo, Addbot, Tcproyect, Kevinsimon300, Philip
7, Facumontero, MrCharro, Magdiel2014 y Annimos: 187
Frame Relay Fuente: https://es.wikipedia.org/wiki/Frame_Relay?oldid=83415425 Colaboradores: Dodo, Barcex, Morgul~eswiki, Airunp,
Roadmr~eswiki, Johnbojaen, RobotQuistnix, Superzerocool, Amads, FlaBot, YurikBot, Damisoft, JRGL, Kekkyojin, Tulises16, Suomi
1973, CEM-bot, Damifb, Hendryx, Alexav8, Luks~eswiki, Antur, Julian Mendez, Montgomery, Thijs!bot, Bot que revierte, MSBOT, Gusgus, JAnDbot, Mandrake33, TXiKiBoT, Amanuense, Cinevoro, VolkovBot, Superhori, Snakeyes, Matdrodes, AlleborgoBot, SieBot, Valders, Paconi, HUB, Sindala, Nicop, Aikurn, Asierba, PixelBot, Botelln, Walter closser, Alexbot, BodhisattvaBot, Aipni-Lovrij, AVBOT,
Amirobot, DSisyphBot, ArthurBot, Obersachsebot, Xqbot, Evelazquez77, Botarel, Andreskru, PatruBOT, EmausBot, ZroBot, Dondervogel 2, Legobot, Fx.vera, Ignacibaquedano, Jarould y Annimos: 75
Modo de Transferencia Asncrona Fuente: https://es.wikipedia.org/wiki/Modo_de_Transferencia_As%C3%ADncrona?oldid=
83221630 Colaboradores: Youssefsan, PACO, Moriel, JorgeGG, Lourdes Cardenal, ManuelGR, Zwobot, Sms, Rsg, Tano4595, Barcex,
Enric Naval, Periku, Villamota, Renabot, Ilario, Caos, Digigalos, Jesjimenez, ICrash, Taichi, Rembiapo pohyiete (bot), RobotQuistnix,
Francosrodriguez, Yrbot, Amads, FlaBot, Vitamine, BOTijo, GermanX, Beto29, KnightRider, Carlos Humberto, JRGL, Maldoror, Ricard
Delgado Gonzalo, CEM-bot, GilliamJF, Antur, Thijs!bot, Artziel, JAnDbot, Zufs, CommonsDelinker, Rei-bot, AlnoktaBOT, Cinevoro,
VolkovBot, Technopat, LpaULE, Manuel Castillo Cagigal, BlackBeast, BotMultichill, SieBot, Loveless, Bigsus-bot, Pabloshi, Raul.lara,
Tirithel, Javierito92, Marcecoro, Botelln, Alexbot, Methossant, Darkicebot, UA31, AVBOT, Diegusjaimes, Alhassam, Luckas-bot,
Nallimbot, Gacpro, ArthurBot, Jkbw, Marsal20, Siberia.spica, PatruBOT, KamikazeBot, Dinamik-bot, Gustavo Girardelli, Foundling,
EmausBot, ZroBot, MerlIwBot, KLBot2, Legobot, Addbot, Fernandosanma, BOTito, AVIADOR-bot, Sinkmanu, Ignacibaquedano y
Annimos: 97
Protocolo no orientado a la conexin Fuente: https://es.wikipedia.org/wiki/Protocolo_no_orientado_a_la_conexi%C3%B3n?oldid=
78026967 Colaboradores: Siabef, CEM-bot, Thijs!bot, Muro Bot, PaintBot, Nubecosmica, Mutari, Gabaro, Botito777, Jkbw, Abinadab1,
Addbot y Annimos: 2

5.5.2

Imgenes

Archivo:ATM3_opti.png Fuente: https://upload.wikimedia.org/wikipedia/commons/a/a7/ATM3_opti.png Licencia: CC BY 2.5 Colaboradores:

ATM3.png Artista original: ATM3.png: jesjimher
Archivo:Commons-emblem-question_book_orange.svg
Fuente:
https://upload.wikimedia.org/wikipedia/commons/1/1f/
Commons-emblem-question_book_orange.svg Licencia: CC BY-SA 3.0 Colaboradores: <a href='//commons.wikimedia.org/wiki/File:
Commons-emblem-issue.svg' class='image'><img alt='Commons-emblem-issue.svg' src='https://upload.wikimedia.org/wikipedia/
commons/thumb/b/bc/Commons-emblem-issue.svg/25px-Commons-emblem-issue.svg.png' width='25' height='25' srcset='https:
//upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/38px-Commons-emblem-issue.svg.png
1.5x,
https://upload.wikimedia.org/wikipedia/commons/thumb/b/bc/Commons-emblem-issue.svg/50px-Commons-emblem-issue.svg.png 2x'
data-le-width='48' data-le-height='48' /></a> + <a href='//commons.wikimedia.org/wiki/File:Question_book.svg' class='image'><img
alt='Question
book.svg'
src='https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/25px-Question_
book.svg.png' width='25' height='20' srcset='https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/
38px-Question_book.svg.png 1.5x, https://upload.wikimedia.org/wikipedia/commons/thumb/9/97/Question_book.svg/50px-Question_
book.svg.png 2x' data-le-width='252' data-le-height='199' /></a> Artista original: GNOME icon artists, Jorge 2701
Archivo:Fin_de_conexin_TCP.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/3/35/Fin_de_conexi%C3%B3n_TCP.
svg Licencia: CC-BY-SA-3.0 Colaboradores: ? Artista original: ?
Archivo:ForeRunnerLE_25_ATM_Network_Interface_(1).jpg Fuente: https://upload.wikimedia.org/wikipedia/commons/6/6c/
ForeRunnerLE_25_ATM_Network_Interface_%281%29.jpg Licencia: CC BY-SA 3.0 Colaboradores: Trabajo propio Artista original:
Barcex
Archivo:Fr_cir.PNG Fuente: https://upload.wikimedia.org/wikipedia/commons/e/e3/Fr_cir.PNG Licencia: Public domain Colaboradores: ? Artista original: ?
Archivo:Tcp-handshake.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/9/98/Tcp-handshake.svg Licencia: CC-BY-SA3.0 Colaboradores:
300px-Tcp-handshake.png Artista original: 300px-Tcp-handshake.png: ???

14

CAPTULO 5. PROTOCOLO NO ORIENTADO A LA CONEXIN

5.5.3

Licencia de contenido

Creative Commons Attribution-Share Alike 3.0