protocolos

ndice general

1 Protocolo orientado a la conexin 11.1 Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Lista de protocolos orientados a la conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.6 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Transmission Control Protocol 22.1 Objetivos de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Informacin tcnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2.1 Funciones de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2.2 Caractersticas del TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2.3 Formato de los segmentos TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Funcionamiento del protocolo en detalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3.1 Establecimiento de la conexin (negociacin en tres pasos) . . . . . . . . . . . . . . . . . 32.3.2 Transferencia de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3.3 Tamao de ventana TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.4 Escalado de ventana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.5 Fin de la conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Puertos TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5 Desarrollo de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.6 Comparativa entre UDP y TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.7 Bibliotecas de sockets TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.8 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.9 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.10 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Frame Relay 73.1 Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Aplicaciones y Benecios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

i

ii NDICE GENERAL

4 Modo de Transferencia Asncrona 94.1 Resea histrica de ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Descripcin del proceso ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.3 Formato de las celdas ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3.1 Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4 Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.5 Modelo arquitectnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.6 Perspectiva de la tecnologa ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.7 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.8 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.9 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5 Protocolo no orientado a la conexin 125.1 Lista de protocolos no orientados a la conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.2 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.3 Vase tambin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.4 Enlaces externos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.5 Texto e imgenes de origen, colaboradores y licencias . . . . . . . . . . . . . . . . . . . . . . . . 13

5.5.1 Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.5.2 Imgenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.5.3 Licencia de contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Captulo 1

Protocolo orientado a la conexin

Un protocolo orientado a la conexin es un modo decomunicacin de redes donde se debe establecer una co-nexin antes de transferir datos. Se identica el ujode trco con un identicador de conexin en lugar deutilizar explcitamente las direcciones de la fuente y eldestino. Tpicamente, el identicador de conexin es unescalar (por ejemplo en Frame Relay son 10 bits y enAsynchronous Transfer Mode 24 bits). Esto hace a losconmutadores de red substancialmente ms rpidos (lastablas de encaminamiento son ms sencillas, y es ms f-cil construir el hardware de los conmutadores). El impac-to es tan grande, que protocolos tpicamente no orienta-dos a la conexin, tal como el trco de IP, utilizan pre-jos orientados a la conexin (por ejemplo IPv6 incorporael campo etiqueta de ujo).Se dice que un servicio de comunicacin entre dos enti-dades es orientado a conexin cuando antes de iniciar lacomunicacin se verican determinados datos (disponi-bilidad, alcance, etc.) entre estas entidades y se negocianunas credenciales para hacer esta conexin ms segura yeciente. Este tipo de conexiones suponen mayor cargade trabajo a una red (y tal vez retardo) pero aportan laeciencia y abilidad necesaria a las comunicaciones quela requieran.Algunos protocolos orientados a la conexin sonTransmission Control Protocol, Frame Relay yAsynchronous Transfer Mode.

1.1 Seguridad

Hay cierta confusin sobre la seguridad y los serviciosorientados a la conexin y no orientados a la conexin.En el pasado, cuando haba menos servicios y protoco-los, y haba menos aplicaciones, se crea que los serviciosorientados a la conexin eran seguros y los no orientadosa la conexin no eran seguros.Estas equivalencias no son ciertas.[cita requerida] Es posibledisear una capa de transporte que proporciona un servi-cio orientado a la conexin no seguro. De forma similar,una capa de transporte puede proporcionar un servicio noorientado a la conexin seguro, si utiliza una capa de redsegura.

1.2 AlternativasUna terminologa alternativa al servicio que ofrece unprotocolo orientado a la conexin y un protocolo noorientado a la conexin son los servicios de circuitos vir-tuales y de datagramas respectivamente.El servicio de circuito virtual es un tipo de servicio orien-tado a la conexin, dado que implica iniciar y descartaruna entidad de tipo conexin, y mantener informacin delestado de la conexin en los conmutadores de paquetes.El servicio de datagrama es un tipo de servicio sin cone-xin en el que no se emplean entidades de tipo conexin.

1.3 Lista de protocolos orientadosa la conexin

protocolo TCP protocolo FRAME RELAY protocolo ATM

1.4 Vase tambin Protocolo no orientado a la conexin Circuito virtual

1.5 Referencias Kurose J. F.; Ross K. W., REDES DE COMPU-

TADORES.Un enfoque descendente basado en In-ternet (2.ed 2004), Pearson Educacin ed.

1.6 Enlaces externos Kurose J. F.; Ross K. W., redes de computadores The Transport Layer: Tutorial and Survey

1

Captulo 2

Transmission Control Protocol

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

Muchos programas dentro de una red de datos compuestapor redes de computadoras, pueden usar TCP para crearconexiones entre s a travs de las cuales puede enviar-se un ujo de datos. El protocolo garantiza que los datossern entregados en su destino sin errores y en el mismoorden en que se transmitieron. Tambin proporciona unmecanismo para distinguir distintas aplicaciones dentrode una misma mquina, a travs del concepto de puerto.TCP da soporte a muchas de las aplicaciones ms po-pulares de Internet (navegadores, intercambio de che-ros, clientes FTP, etc.) y protocolos de aplicacin HTTP,SMTP, SSH y FTP.

2.1 Objetivos de TCPCon el uso de protocolo TCP, las aplicaciones pueden co-municarse en forma segura (gracias al de acuse de reci-bo -ACK- del protocolo TCP) independientemente de lascapas inferiores. Esto signica que los routers (que fun-cionan en la capa de Internet) slo tiene que enviar losdatos en forma de datagrama, sin preocuparse con el mo-nitoreo de datos porque esta funcin la cumple la capa detransporte (o ms especcamente el protocolo TCP).

2.2 Informacin tcnicaTCP es usado en gran parte de las comunicaciones de da-tos. Por ejemplo, gran parte de las comunicaciones quetienen lugar en Internet emplean TCP.

2.2.1 Funciones de TCPEn la pila de protocolos TCP/IP, TCP es la capa interme-dia entre el protocolo de internet (IP) y la aplicacin. Mu-chas veces las aplicaciones necesitan que la comunicacina travs de la red sea conable. Para ello se implementael protocolo TCP que asegura que los datos que emite el

cliente sean recibidos por el servidor sin errores y en elmismo orden que fueron emitidos, a pesar de trabajar conlos servicios de la capa IP, la cual no es conable. Es unprotocolo orientado a la conexin, ya que el cliente y elservidor deben de anunciarse y aceptar la conexin antesde comenzar a transmitir los datos a ese usuario que deberecibirlos.

2.2.2 Caractersticas del TCP Permite colocar los datagramas nuevamente en or-

den cuando vienen del protocolo IP. Permite el monitoreo del ujo de los datos y as evita

la saturacin de la red. Permite que los datos se formen en segmentos de

longitud variada para entregarlos al protocolo IP. Permite multiplexar los datos, es decir, que la infor-

macin que viene de diferentes fuentes (por ejem-plo, aplicaciones) en la misma lnea pueda circularsimultneamente.

Por ltimo, permite comenzar y nalizar la comuni-cacin amablemente.

2.2.3 Formato de los segmentos TCPEn el nivel de transporte, los paquetes de bits que consti-tuyen las unidades de datos de protocolo TCP se llamansegmentos. El formato de los segmentos TCP se mues-tra en el esquema segmento TCP.

2.3 Funcionamiento del protocoloen detalle

Las conexiones TCP se componen de tres etapas:

1. establecimiento de conexin,2. transferencia de datos, y3. n de la conexin.

2

2.3. FUNCIONAMIENTO DEL PROTOCOLO EN DETALLE 3

Para establecer la conexin se usa el procedimiento lla-mado negociacin en tres pasos (3-way handshake).Para la desconexin se usa una negociacin en cuatropasos (4-way handshake). Durante el establecimiento dela conexin, se conguran algunos parmetros tales comoel nmero de secuencia con el n de asegurar la entregaordenada de los datos y la robustez de la comunicacin.

2.3.1 Establecimiento de la conexin (ne-gociacin en tres pasos)

Client ServerSYN seq=x

SYN-ACK ack

=x+1 seq=y

ACK ack=y+1 seq=x+1[data]

Negociacin en tres pasos o Three-way handshake

Aunque es posible que un par de entidades nales co-miencen una conexin entre ellas simultneamente, nor-malmente una de ellas abre un socket en un determinadopuerto TCP y se queda a la escucha de nuevas conexiones.Es comn referirse a esto como apertura pasiva, y deter-mina el lado servidor de una conexin. El lado cliente deuna conexin realiza una apertura activa de un puerto en-viando un paquete SYN inicial al servidor como parte dela negociacin en tres pasos. En el lado del servidor (es-te receptor tambin puede ser una PC o alguna estacinterminal) se comprueba si el puerto est abierto, es decir,si existe algn proceso escuchando en ese puerto, pues sedebe vericar que el dispositivo de destino tenga este ser-vicio activo y est aceptando peticiones en el nmero depuerto que el cliente intenta usar para la sesin. En casode no estarlo, se enva al cliente un paquete de respuestacon el bit RST activado, lo que signica el rechazo del in-tento de conexin. En caso de que s se encuentre abiertoel puerto, el lado servidor respondera a la peticin SYNvlida con un paquete SYN/ACK. Finalmente, el clientedebera responderle al servidor con un ACK, completan-do as la negociacin en tres pasos (SYN, SYN/ACK yACK) y la fase de establecimiento de conexin. Es in-teresante notar que existe un nmero de secuencia gene-rado por cada lado, ayudando de este modo a que no sepuedan establecer conexiones falseadas (spoong).

2.3.2 Transferencia de datos

Durante la etapa de transferencia de datos, una serie demecanismos claves determinan la abilidad y robustez delprotocolo. Entre ellos estn incluidos el uso del nmerode secuencia para ordenar los segmentos TCP recibidosy detectar paquetes duplicados, checksums para detectarerrores, y asentimientos y temporizadores para detectarprdidas y retrasos.Durante el establecimiento de conexin TCP, los nme-ros iniciales de secuencia son intercambiados entre lasdos entidades TCP. Estos nmeros de secuencia son usa-dos para identicar los datos dentro del ujo de bytes,y poder identicar (y contar) los bytes de los datos dela aplicacin. Siempre hay un par de nmeros de secuen-cia incluidos en todo segmento TCP, referidos al nmerode secuencia y al nmero de asentimiento. Un emisorTCP se reere a su propio nmero de secuencia cuandohabla de nmero de secuencia, mientras que con el nme-ro de asentimiento se reere al nmero de secuencia delreceptor. Para mantener la abilidad, un receptor asientelos segmentos TCP indicando que ha recibido una par-te del ujo continuo de bytes. Una mejora de TCP, lla-mada asentimiento selectivo (Selective Acknowledgement,SACK) permite a un receptor TCP asentir los datos quese han recibido de tal forma que el remitente solo retrans-mita los segmentos de datos que faltan.A travs del uso de nmeros de secuencia y asentimiento,TCP puede pasar los segmentos recibidos en el orden co-rrecto dentro del ujo de bytes a la aplicacin receptora.Los nmeros de secuencia son de 32 bits (sin signo), quevuelve a cero tras el siguiente byte despus del 2321.Una de las claves para mantener la robustez y la segu-ridad de las conexiones TCP es la seleccin del nmeroinicial de secuencia (Initial Sequence Number, ISN).Un checksum de 16 bits, consistente en el complementoa uno de la suma en complemento a uno del contenidode la cabecera y datos del segmento TCP, es calculadopor el emisor, e incluido en la transmisin del segmento.Se usa la suma en complemento a uno porque el acarreonal de ese mtodo puede ser calculado en cualquier ml-tiplo de su tamao (16-bit, 32-bit, 64-bit...) y el resultado,una vez plegado, ser el mismo. El receptor TCP recal-cula el checksum sobre las cabeceras y datos recibidos.El complemento es usado para que el receptor no tengaque poner a cero el campo del checksum de la cabece-ra antes de hacer los clculos, salvando en algn lugar elvalor del checksum recibido; en vez de eso, el receptorsimplemente calcula la suma en complemento a uno conel checksum incluido, y el resultado debe ser igual a 0. Sies as, se asume que el segmento ha llegado intacto y sinerrores.Hay que jarse en que el checksum de TCP tambin cubrelos 96 bit de la cabecera que contiene la direccin origen,la direccin destino, el protocolo y el tamao TCP. Estoproporciona proteccin contra paquetes mal dirigidos por

4 CAPTULO 2. TRANSMISSION CONTROL PROTOCOL

errores en las direcciones.El checksum de TCP es una comprobacin bastante d-bil. En niveles de enlace con una alta probabilidad deerror de bit quiz requiera una capacidad adicional decorreccin/deteccin de errores de enlace. Si TCP fue-se rediseado hoy, muy probablemente tendra un cdigode redundancia cclica (CRC) para control de errores envez del actual checksum. La debilidad del checksum es-t parcialmente compensada por el extendido uso de unCRC en el nivel de enlace, bajo TCP e IP, como el usa-do en el PPP o en Ethernet. Sin embargo, esto no sig-nica que el checksum de 16 bits es redundante: sor-prendentemente, inspecciones sobre el trco de Internethan mostrado que son comunes los errores de software yhardware[cita requerida] que introducen errores en los paque-tes protegidos con un CRC, y que el checksum de 16 bitsde TCP detecta la mayora de estos errores simples.Los asentimientos (ACK o Acknowledgments) de los da-tos enviados o la falta de ellos, son usados por los emi-sores para interpretar las condiciones de la red entre elemisor y receptor TCP. Unido a los temporizadores, losemisores y receptores TCP pueden alterar el comporta-miento del movimiento de datos. TCP usa una serie demecanismos para conseguir un alto rendimiento y evi-tar la congestin de la red (la idea es enviar tan rpidocomo el receptor pueda recibir). Estos mecanismos in-cluyen el uso de ventana deslizante, que controla que eltransmisor mande informacin dentro de los lmites delbfer del receptor, y algoritmos de control de ujo, talescomo el algoritmo de evitacin de la congestin (conges-tion avoidance), el de comienzo lento (slow-start), el deretransmisin rpida, el de recuperacin rpida (fast re-covery), y otros.

Control de ujo

TCP usa control de ujo para evitar que un emisor envedatos de forma ms rpida de la que el receptor puede re-cibirlos y procesarlos. El control de ujo es un mecanis-mo esencial en redes en las que se comunican computado-ras con distintas velocidades de transferencia. Por ejem-plo, si una PC enva datos a un dispositivo mvil que pro-cesa los datos de forma lenta, el dispositivo mvil deberegular el ujo de datos.TCP usa una ventana deslizante para el control de u-jo. En cada segmento TCP, el receptor especica en elcampo receive window la cantidad de bytes que puede al-macenar en el bfer para esa conexin. El emisor puedeenviar datos hasta esa cantidad. Para poder enviar msdatos debe esperar que el receptor le enve un ACK conun nuevo valor de ventana.

2.3.3 Tamao de ventana TCPEl tamao de la ventana de recepcin TCP es la canti-dad de datos recibidos (en bytes) que pueden ser metidos

en el bfer de recepcin durante la conexin. La entidademisora puede enviar una cantidad determinada de datospero antes debe esperar un asentimiento con la actualiza-cin del tamao de ventana por parte del receptor.Un ejemplo sera el siguiente: un receptor comienza conun tamao de ventana X y recibe Y bytes, entonces su ta-mao de ventana ser (X - Y) y el transmisor slo podrmandar paquetes con un tamao mximo de datos de (X -Y) bytes. Los siguientes paquetes recibidos seguirn res-tando tamao a la ventana de recepcin. Esta situacinseguir as hasta que la aplicacin receptora recoja losdatos del bfer de recepcin.

2.3.4 Escalado de ventanaPara una mayor eciencia en redes de gran ancho de ban-da, debe ser usado un tamao de ventana mayor. El cam-po TCP de tamao de ventana controla el movimiento dedatos y est limitado a 16 bits, es decir, a un tamao deventana de 65.535 bytes.Como el campo de ventana no puede expandirse se usaun factor de escalado. La escala de ventana TCP (TCPwindow scale) es una opcin usada para incrementar elmximo tamao de ventana desde 65.535 bytes, a 1 Gi-gabyte.La opcin de escala de ventana TCP es usada solo duran-te la negociacin en tres pasos que constituye el comienzode la conexin. El valor de la escala representa el nmerode bits desplazados a la izquierda de los 16 bits que for-man el campo del tamao de ventana. El valor de la escalapuede ir desde 0 (sin desplazamiento) hasta 14. Hay querecordar que un nmero binario desplazado un bit a laizquierda es como multiplicarlo en base decimal por 2.

2.3.5 Fin de la conexin

Cliente Servidor

FIN

FINACK

ACK

Transferenciade datos

Transferenciade datos

Terminarconexin

Conexinterminada

Conexinterminada

Cierre de una conexin segn el estndar.

La fase de nalizacin de la conexin utiliza una nego-ciacin en cuatro pasos (four-way handshake), terminan-

2.6. COMPARATIVA ENTRE UDP Y TCP 5

do la conexin desde cada lado independientemente. Sinembargo, es posible realizar la nalizacin de la conexinen 3 fases; enviando el segmento FIN y el ACK en unosolo.[2] Cuando uno de los dos extremos de la conexindesea parar su mitad de conexin transmite un segmen-to con el ag FIN en 1, que el otro interlocutor asentircon un ACK. Por tanto, una desconexin tpica requiereun par de segmentos FIN y ACK desde cada lado de laconexin.Una conexin puede estar medio abierta en el caso deque uno de los lados la nalice pero el otro no. El ladoque ha dado por nalizada la conexin no puede enviarms datos pero la otra parte si podr.

2.4 Puertos TCPTCP usa el concepto de nmero de puerto para identi-car a las aplicaciones emisoras y receptoras. Cada ladode la conexin TCP tiene asociado un nmero de puerto(de 16 bits sin signo, con lo que existen 65536 puertosposibles) asignado por la aplicacin emisora o receptora.Los puertos son clasicados en tres categoras:

1. bien conocidos,2. registrados, y3. dinmicos/privados.

Los puertos bien conocidos son asignados por la InternetAssigned Numbers Authority (IANA), van del 0 al 1023 yson usados normalmente por el sistema o por procesoscon privilegios.[3] Las aplicaciones que usan este tipo depuertos son ejecutadas como servidores y se quedan a laescucha de conexiones. Algunos ejemplos son: FTP (21),SSH (22), Telnet (23), SMTP (25) y HTTP (80).Los puertos registrados son normalmente empleadospor las aplicaciones de usuario de forma temporal cuandoconectan con los servidores, pero tambin pueden repre-sentar servicios que hayan sido registrados por un tercero(rango de puertos registrados: 1024 al 49151).Los puertos dinmicos/privados tambin pueden serusados por las aplicaciones de usuario, pero este caso esmenos comn. Los puertos dinmicos/privados no tienensignicado fuera de la conexin TCP en la que fueronusados (rango de puertos dinmicos/privados: 49152 al65535, recordemos que el rango total de 2 elevado a lapotencia 16, cubre 65536 nmeros, del 0 al 65535).

2.5 Desarrollo de TCPTCP es un protocolo muy desarrollado y complejo. Sinembargo, mientras mejoras signicativas han sido pro-puestas y llevadas a cabo a lo largo de los aos, ha con-servado las operaciones ms bsicas sin cambios desde el

RFC 793, publicado en 1981. El documento RFC 1122(Host Requirements for Internet Hosts), especica el n-mero de requisitos de una implementacin del protoco-lo TCP.[4] El RFC 2581 (Control de Congestin TCP)es uno de los ms importantes documentos relativos aTCP de los ltimos aos, describe nuevos algoritmos pa-ra evitar la congestin excesiva.[5] En 2001, el RFC 3168fue escrito para describir la Noticacin de CongestinExplcita (ECN), una forma de eludir la congestin conmecanismos de sealizacin. En los comienzos del sigloXXI, TCP es usado en el 95% de todos los paquetes quecirculan por Internet.[cita requerida] Entre las aplicacionesms comunes que usan TCP estn HTTP/HTTPS (WorldWide Web), SMTP/POP3/IMAP (correo electrnico) yFTP (transferencia de cheros). Su amplia extensin hasido la prueba para los desarrolladores originales de quesu creacin estaba excepcionalmente bien hecha.Recientemente, un nuevo algoritmo de control de con-gestin fue desarrollado y nombrado como FAST TCP(Fast Active queue management Scalable TransmissionControl Protocol) por los cientcos de California Insti-tute of Technology (Caltech). Es similar a TCP Vegas encuanto a que ambos detectan la congestin a partir de losretrasos en las colas que sufren los paquetes al ser en-viados a su destino. Todava hay un debate abierto so-bre si este es un sntoma apropiado para el control de lacongestin.[cita requerida]

2.6 Comparativa entre UDP y TCP UDP: proporciona un nivel de transporte no ablede datagramas, ya que apenas aade la informa-cin necesaria para la comunicacin extremo a ex-tremo al paquete que enva al nivel inferior. Lo uti-lizan aplicaciones como NFS (Network File System)y RCP (comando para copiar cheros entre compu-tadores remotos), pero sobre todo se emplea en ta-reas de control y en la transmisin de audio y vdeoa travs de una red. No introduce retardos para es-tablecer una conexin, no mantiene estado de cone-xin alguno y no realiza seguimiento de estos par-metros. As, un servidor dedicado a una aplicacinparticular puede soportar ms clientes activos cuan-do la aplicacin corre sobre UDP en lugar de sobreTCP.[cita requerida]

TCP: es el protocolo que proporciona un transpor-te able de ujo de bits entre aplicaciones. Es-t pensado para poder enviar grandes cantidades deinformacin de forma able, liberando al programa-dor de la dicultad de gestionar la abilidad de la co-nexin (retransmisiones, prdida de paquetes, ordenen el que llegan los paquetes, duplicados de paque-tes...) que gestiona el propio protocolo. Pero la com-plejidad de la gestin de la abilidad tiene un costeen eciencia, ya que para llevar a cabo las gestionesanteriores se tiene que aadir bastante informacin

6 CAPTULO 2. TRANSMISSION CONTROL PROTOCOL

a los paquetes que enviar. Debido a que los paquetespara enviar tienen un tamao mximo, cuanta msinformacin aada el protocolo para su gestin, me-nos informacin que proviene de la aplicacin podrcontener ese paquete (el segmento TCP tiene unasobrecarga de 20 bytes en cada segmento, mientrasque UDP solo aade 8 bytes). Por eso, cuando esms importante la velocidad que la abilidad, se uti-liza UDP. En cambio, TCP asegura la recepcin endestino de la informacin para transmitir.

2.7 Bibliotecas de sockets TCPSe listan algunas de las bibliotecas de comunicacionesexistentes, que utilizan los protocolos TCP y UDP paradistintos sistemas operativos.

SolarSockets es una biblioteca para C++ Multi-plataforma y Multithread, gratuita para proyectoslibres.[6] Fcil de usar y con varios ejemplos.[7]

SDL NET proporciona funciones y tipos de datomultiplataforma para programar aplicaciones quetrabajen con redes.[8]

C++ Sockets Library es una biblioteca de clases enC++ bajo licencia GPL que 'mapea' el berkeley soc-kets C API, y funciona tanto en algunos sistemasUnix como en Win32.[9]

GNU Common C++ es una biblioteca de propsitogeneral que incluye funciones de red.[10]

HackNet es una biblioteca de comunicaciones paracrear juegos multijugador.[11]

DirectPlay simplica el acceso de las aplicaciones alos servicios de comunicacin. Es una componentede 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 Net-

work Intercommunication. IEEE Transactions on Com-munications. COM-22 (5): 637648.

[2] Andrew S. Tanenbaum y David J. Wetherall, Redesde 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

[10] http://www.gnu.org/software/commoncpp/docs/refman/html/_sample_socket_port_8cpp-example.html

[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. Ja-

vier Carmona Murillo, David Corts Polo, M.Domnguez-Dorado, Alfonso Gazo-Cervero, Jos-Luis Gonzlez-Snchez, Francisco Javier RodrguezPrez. 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 tc-nica de comunicacin mediante retransmisin de tramaspara redes de circuito virtual, introducida por la ITU-T a partir de la recomendacin I.122 de 1988. Consisteen una forma simplicada de tecnologa de conmutacinde paquetes que transmite una variedad de tamaos detramas o marcos (frames) para datos, perfecto para latransmisin de grandes cantidades de datos.La tcnica Frame Relay se utiliza para un servicio detransmisin de voz y datos a alta velocidad que permitela interconexin de redes de rea local separadas geogr-camente a un coste menor.

3.1 Frame RelayFrame Relay proporciona conexiones y vitlatla entreusuarios a travs de una red pblica, del mismo modoque lo hara una red privada punto a punto, esto quieredecir que es orientado a la conexin.Las conexiones pueden ser del tipo permanente, (PVC,Permanent Virtual Circuit) o conmutadas (SVC, SwitchedVirtual Circuit). Por ahora slo se utiliza la permanente.De hecho, su gran ventaja es la de reemplazar las lneasprivadas por un slo enlace a la red.El uso de conexiones implica que los nodos de la red sonconmutadores, y las tramas deben llegar ordenadas al des-tinatario, ya que todas siguen el mismo camino a travsde la red, puede manejar tanto trco de datos como devoz.Al contratar un servicio Frame Relay, contratamos un an-cho de banda determinado en un tiempo determinado. Aeste ancho de banda se le conoce como CIR (CommitedInformation Rate). Esta velocidad, surge de la divisin deBc (Committed Burst), entre Tc (el intervalo de tiempo).No obstante, una de las caractersticas de Frame Relay essu capacidad para adaptarse a las necesidades de las apli-caciones, pudiendo usar una mayor velocidad de la con-tratada en momentos puntuales, adaptndose muy bien altrco en rfagas. Aunque la media de trco en el inter-valo Tc no deber superar la cantidad estipulada Bc.Estos bits de Bc sern enviados de forma transparente.

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

Como se observa en la imagen, las tramas que superenla cantidad de Bc+Be en el intervalo, sern descartadasdirectamente sin llegar a entrar en la red, sin embargolas que superan la cantidad Bc pero no Bc+Be se marcancomo descartables (DE=1) para ser estas las primeras enser eliminadas en caso de congestin.Para realizar control de congestin de la red, Frame Re-lay activa unos bits, que se llaman FECN (forward ex-plicit congestion notication), BECN (backward explicit

7

8 CAPTULO 3. FRAME RELAY

congestion notication) y DE (Discard Eligibility). Paraello utiliza el protocolo LAPF, un protocolo de nivel deenlace que mejora al protocolo LAPD.FECN se activa, o lo que es lo mismo, se pone en 1, cuan-do hay congestin en el mismo sentido que va la trama.BECN se activa cuando hay congestin en el sentidoopuesto a la transmisin. DE igual a 1 indica que la tra-ma ser descartable en cuanto haya congestin. Se utilizael llamado Algoritmo del Cubo Agujereado, de formaque se simulan 2 cubos con un agujero en el fondo: Por elprimero de ellos pasan las tramas con un trco inferior aCIR, el que supera este lmite pasa al segundo cubo, porel que pasar el trco inferior a CIR+EIR (y que tendrnDE=1). El que supera este segundo cubo es descartado.En cada nodo hay un gestor de tramas, que decide, en ca-so de congestin, a quien noticar, si es leve avisa a lasestaciones que generan ms trco, si es severa le avisaa todos. Siguiendo el algoritmo anterior, podramos des-cartar en el peor de los casos el trco que pasa a travsdel segundo cubo. Este funcionamiento garantiza que secumplen las caractersticas de la gestin de trco.Por otro lado, no lleva a cabo ningn tipo de control deerrores o ujo, ya que delega ese tipo de responsabilida-des en capas superiores, obteniendo como resultado unanotable reduccin del trco en la red, aumentando sig-nicativamente su rendimiento. Esta delegacin de res-ponsabilidades tambin conlleva otra consecuencia, y esla reduccin del tamao de su cabecera, necesitando demenor tiempo de proceso en los nodos de la red y consi-guiendo de nuevo una mayor eciencia. Esta delegacinde control de errores en capas superiores es debido a queFrame Relay trabaja bajo redes digitales en las cuales laprobabilidad de error es muy baja.

3.1.1 Aplicaciones y Benecios Reduccin de complejidad en la red. elecciones vir-

tuales mltiples son capaces de compartir la mismalnea de acceso.

Equipo a costo reducido. Se reduce las necesida-des del hardware y el procesamiento simplicadoofrece un mayor rendimiento por su dinero.

Mejora del desempeo y del tiempo de respues-ta. penetracin directa entre localidades con pocosatrasos en la red.

Mayor disponibilidad en la red. Las conexiones a lared pueden redirigirse automticamente a diversoscursos cuando ocurre un error.

Se pueden utilizar procedimientos de Calidad deServicio (QoS) basados en el funcionamiento Fra-me Relay.

Tarifa ja. Los precios no son sensitivos a la distan-cia, lo que signica que los clientes no son penaliza-dos por conexiones a largas distancias.

Mayor exibilidad. Las conexiones son denidas porlos programas. Los cambios hechos a la red son msrpidos y a menor costo si se comparan con otrosservicios.

Ofrece mayores velocidades y rendimiento, a la vezque provee la eciencia de ancho de banda que vienecomo resultado de los mltiples circuitos virtualesque comparten un puerto de una sola lnea.

Los servicios de Frame Relay son conables y de al-to rendimiento. Son un mtodo econmico de enviardatos, convirtindolo en una alternativa a las lneasdedicadas.

El Frame Relay es ideal para usuarios que necesitanuna conexin de mediana o alta velocidad para man-tener un trco de datos entre localidades mltiplesy distantes .

Opcionales WEB, Libros virtuales: redes...

Frame Relay constituye un mtodo de comunicacinorientado a paquetes para la conexin de sistemas infor-mticos. Se utiliza principalmente para la interconexinde redes de rea local (LANs, local area networks) y re-des de rea extensa (WANs, wide area networks) sobreredes pblicas o privadas. La mayora de compaas p-blicas de telecomunicaciones ofrecen los servicios FrameRelay como una forma de establecer conexiones virtua-les de rea extensa que ofrezcan unas prestaciones rela-tivamente altas. Frame Relay es una interfaz de usuariodentro de una red de conmutacin de paquetes de reaextensa, que tpicamente ofrece un ancho de banda com-prendida en el rango de 56 kbit/s y 1.544 Mbit/s. FrameRelay se origin a partir de las interfaces ISND y se pro-puso como estndar al Comit consultivo internacionalpara telegrafa y telefona (CCITT) en 1984. El comitde normalizacin T1S1 de los Estados Unidos, acredita-do 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

Tarjeta de red ATM de 25 Mbps con interfaz PCI y conexin depar trenzado.

El Modo de Transferencia Asncrona (Asynchro-nous Transfer Mode, ATM) es una tecnologa detelecomunicacin desarrollada para hacer frente a la grandemanda de capacidad de transmisin para servicios yaplicaciones.

4.1 Resea histrica de ATMLa primera referencia del ATM (Asynchronous TransferMode) tiene lugar en los aos 60 cuando un norteameri-cano de origen oriental perteneciente a los laboratoriosBell describi y patent un modo de transferencia no sn-crono. Sin embargo el ATM no se hizo popular hasta1988 cuando el CCITT decidi que sera la tecnologa deconmutacin de las futuras redes ISDN en banda ancha(rec I.121).Para ello, el equipo detrs del ATM tuvo primero quepersuadir a algunos representantes de las redes de comu-nicaciones que hubieran preferido una simple ampliacinde las capacidades de la ISDN en banda estrecha. Con-seguido este primer objetivo y desechando los esquemasde transmisin sncronos, se empezaron a discutir aspec-tos tales como el tamao de las celdas. Por un lado losrepresentantes de EEUU y otros pases proponan un ta-mao de celdas grande de unos 64 bytes. Sin embargopara los representantes de los pases europeos el tamaoideal de las celdas era de 32 bytes (segn Tanenbaum), ysealaban que un tamao de celda de 64 bytes provocara

retardos inaceptables de hasta 85 ms. Este retardo no per-mitira la transmisin de voz con cierto nivel de calidad ala 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 juniode 1989 se tom una decisin salomnica: Ni para unosni para otros. 48 bytes ser el tamao de la celda. Parala cabecera se tom un tamao de 5 bytes. Un extraonmero primo 53 (48+5) sera el tamao denitivo, enoctetos, de las clulas ATM.Un nmero que tuvo la virtudde no satisfacer a nadie, pero que supona una conciliacinde todos los grupos de inters y evitaba una ruptura deconsecuencias imprevisibles.

4.2 Descripcin del proceso ATMCon esta tecnologa, a n de aprovechar al mximo la ca-pacidad de los sistemas de transmisin, sean estos de ca-ble o radioelctricos, la informacin no es transmitida yconmutada a travs de canales asignados en permanencia,sino en forma de cortos paquetes (celdas ATM) de longi-tud constante y que pueden ser enrutadas individualmentemediante el uso de los denominados canales virtuales ytrayectos virtuales.

Figura 1: Diagrama simplicado del proceso ATM.

En la gura 1 se ilustra la forma en que diferentes u-jos de informacin, de caractersticas distintas en cuantoa velocidad y formato, son agrupados en el denominadoMdulo ATM para ser transportados mediante grandesenlaces de transmisin a velocidades (bit rate) de 155 o622 Mbit/s facilitados generalmente por sistemas SDH.

9

10 CAPTULO 4. MODO DE TRANSFERENCIA ASNCRONA

En el terminal transmisor, la informacin es escrita bytea byte en el campo de informacin de usuario de la celday a continuacin se le aade la cabecera.En el extremo distante, el receptor extrae la informacin,tambin byte a byte, de las celdas entrantes y de acuer-do con la informacin de cabecera, la enva donde sta leindique, pudiendo ser un equipo terminal u otro mdu-lo ATM para ser encaminada a otro destino. En caso dehaber ms de un camino entre los puntos de origen y des-tino, no todas las celdas enviadas durante el tiempo de co-nexin de un usuario sern necesariamente encaminadaspor la misma ruta, ya que en ATM todas las conexionesfuncionan sobre una base virtual.

4.3 Formato de las celdas ATMSon estructuras de datos de 53 bytes compuestas por doscampos principales:

1. Header o Cabecera, sus 5 bytes tienen tres funcio-nes principales:(a) identicacin del canal,(b) informacin para la deteccin de errores(c) y si la clula es o no utilizada.(d) Eventualmente puede contener tambin co-

rreccin de errores y un nmero de secuencia.2. Payload, tiene 48 bytes fundamentalmente con da-

tos del usuario y protocolos AAL que tambin sonconsiderados como datos del usuario.

Dos de los conceptos ms signicativos del ATM, Ca-nales Virtuales y Rutas Virtuales, estn materializadosen dos identicadores en el header de cada clula (VCI yVPI), ambos determinan el encaminamiento entre nodos.El estndar dene el protocolo orientado a conexin quelas transmite y dos tipos de formato de celda:

NNI (Network to Network Interface, Interfaz Red aRed): el cual se reere a la conexin de switches ATMen redes privadas.

UNI (User to Network Interface, Interfaz Usuarioa Red): se reere a la conexin de un switch ATMde una empresa pblica o privada con un terminalATM de un usuario normal, siendo este ltimo elms utilizado.

4.3.1 Campos GFC (Generic Flow Control, Control de Flujo Ge-

nrico, 4 bits): el estndar originariamente reserv

el campo GFC para labores de gestin de trco,pero en la prctica no es utilizado. Las celdas NNIlo emplean para extender el campo VPI a 12 bits.

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

PT (Payload Type, Tipo de Informacin de Usua-rio, 3 bits): identica el tipo de datos de la celda (dedatos del usuario o de control). Uno identica el tipode carga en el campo de usuario, otro indica si haycongestin en la red y el ltimo es el SDU.

CLP (Cell Loss Priority, Prioridad, 1 bit): indica elnivel de prioridad de la celda, si este bit est acti-vo cuando la red ATM est congestionada la celdapuede ser descartada.

HEC (Header Error Correction, Correccin deError de Cabecera, 8 bits): contiene un cdigo dedeteccin de error que slo cubre la cabecera (no lainformacin de usuario), y que permite detectar unbuen nmero de errores mltiples y corregir erroressimples.

4.4 EncaminamientoATM ofrece un servicio orientado a conexin, en el cualno hay un desorden en la llegada de las celdas al destino.Esto lo hace gracias a los caminos o rutas virtuales (VP,Virtual Path) y los canales o circuitos virtuales (VC, Vir-tual Channel). Los caminos y canales virtuales tienen elmismo signicado que las conexiones de canales virtua-les (VCC, Virtual Channel Connection) en X.25, que in-dica el camino jo que debe seguir la celda. En el casode ATM, los caminos virtuales (VP), son los caminos quesiguen las celdas entre dos router ATM pero este caminopuede tener varios circuitos virtuales (VC).En el momento de establecer la comunicacin con una ca-lidad de servicio deseada y un destino, se busca el caminovirtual que van a seguir todas las celdas. Este camino nocambia durante toda la comunicacin, as que si se cae unnodo la comunicacin se pierde. Durante la conexin sereservan los recursos necesarios para garantizarle durantetoda la sesin la calidad del servicio al usuario.Cuando una celda llega a un encaminador, este le cam-bia el encabezado segn la tabla que posee y lo enva alsiguiente con un VPI y/o un VCI nuevo.La ruta inicial de encaminamiento se obtiene, en la ma-yora de los casos, a partir de tablas estticas que residenen los conmutadores. Tambin podemos encontrar tablasdinmicas que se conguran dependiendo del estado dela red al comienzo de la conexin; este es uno de los pun-tos donde se ha dejado libertad para los fabricantes. Granparte del esfuerzo que estn haciendo las compaas est

4.9. ENLACES EXTERNOS 11

dedicado a esta rea, puesto que puede ser el punto fun-damental que les permita permanecer en el mercado enun futuro.

4.5 Modelo arquitectnicoLa conmutacin de clulas est intercalada entre las fun-ciones de transmisin y las que adaptan los diferentes ti-pos de trco a los ujos conmutados, lo que plantea unmodelo arquitectnico de tres capas:

1. Capa fsica: relacionada con el medio fsico detransmisin, adapta ujos, protege cabeceras, deli-mita clulas y adapta al medio.

2. Capa ATM: realiza la multiplexacin y conmuta-cin de clulas.

3. Capa AAL (ATM Adaptation Layer): relacionadacon los ujos de informacin, facilita la gestin decaudales, modos de conexin y en caso necesario,referencia de sincronismo.

4.6 Perspectiva de la tecnologaATM

ElModo de Transferencia Asncrona fue la apuesta dela industria tradicional de las telecomunicaciones por lascomunicaciones de banda ancha. Se plante como herra-mienta para la construccin de redes de banda ancha (B-RDSI o B-ISDN) basadas en conmutacin de paquetesen vez de la tradicional conmutacin de circuitos. El des-pliegue de la tecnologa ATM no ha sido el esperado porsus promotores. Las velocidades para las que estaba pen-sada (hasta 622 Mbps) han sido rpidamente superadas;no est claro que ATM sea la opcin ms adecuada paralas redes actuales y futuras, de velocidades del orden delgigabit. ATM se ha encontrado con la competencia de lastecnologas provenientes de la industria de la Informtica,que con proyectos tales como la VoIP parece que ofrecenlas mejores perspectivas de futuro.En la actualidad, ATM es ampliamente utilizado all don-de se necesita dar soporte a velocidades moderadas, comoes el caso de la ADSL, aunque la tendencia es sustituir es-ta tecnologa por otras como Ethernet que est basada entramas de datos.

4.7 Referencias

4.8 Vase tambin Familia de protocolos de Internet

4.9 Enlaces externos www.atmforum.com ATM forum. www.telecomspace.com/vop-atm.html ATM Infoand resources.

ATM Cell formats- Cisco Systems. Asynchronous Transfer Mode (ATM) - Cisco Sys-tems.

www.chipweb.de/atm/ ATM ChipWeb - Chip andNIC 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-nica una comunicacin entre dos puntos nales de unared en los que un mensaje puede ser enviado desde unpunto nal a otro sin acuerdo previo. El dispositivo en unextremo de la comunicacin transmite los datos al otro,sin tener que asegurarse de que el receptor est disponibley listo para recibir los datos. El emisor simplemente en-va un mensaje dirigido al receptor. Cuando se utiliza estaforma de comunicacin son ms frecuentes los problemasde transmisin que con los protocolos orientado a la cone-xin y puede ser necesario reenviar varias veces los datos.Los protocolos no orientados a la conexin son a menu-do rechazados por los administradores de redes que utili-zan cortafuegos porque los paquetes maliciosos son msdifciles de ltrar. El protocolo IP y el protocolo UDPson protocolos no orientados a la conexin, pero TCP esun protocolo orientado a la conexin. Los protocolos noorientados a la conexin son descritos generalmente co-mo sin estado porque los puntos nales no guardan in-formacin para recordar una conversacin de cambiosde mensajes. La alternativa al enfoque no orientado a laconexin es utilizar protocolos orientados a la conexin,que son descritos a veces como con estado porque puedenseguir una conversacin.

5.1 Lista de protocolos no orienta-dos a la conexin

protocolo IP protocolo UDP ICMP IPX TIPC

5.2 Referencias Kurose J. F.; Ross K. W., Redes de computado-

res.Un enfoque descendente basado en Internet (2.ed2004), Pearson Educacin ed.

5.3 Vase tambin Protocolo orientado a la conexin

5.4 Enlaces externosKurose J. F.; Ross K. W., Redes de computadores

12

5.5. TEXTO E IMGENES DE ORIGEN, COLABORADORES Y LICENCIAS 13

5.5 Texto e imgenes de origen, colaboradores y licencias5.5.1 Texto

Protocolo orientado a la conexin Fuente: https://es.wikipedia.org/wiki/Protocolo_orientado_a_la_conexi%C3%B3n?oldid=84824754Colaboradores: 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, Ne-kroByte, 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, Bet-Bot~eswiki, Muro de Aguas, Gaius iulius caesar, TXiKiBoT, Rei-bot, NaSz, Plux, Snakefang, Cinevoro, VolkovBot, Technopat, Rays-torm, 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, Alejandro-caro35, 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, Mer-lIwBot, MetroBot, Invadibot, IRedRat, Elvisor, Agckem, Otosan-kf, Legobot, AleAnonMallo, Addbot, Tcproyect, Kevinsimon300, Philip7, Facumontero, MrCharro, Magdiel2014 y Annimos: 187

FrameRelay 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, Suomi1973, CEM-bot, Damifb, Hendryx, Alexav8, Luks~eswiki, Antur, Julian Mendez, Montgomery, Thijs!bot, Bot que revierte, MSBOT, Gus-gus, JAnDbot, Mandrake33, TXiKiBoT, Amanuense, Cinevoro, VolkovBot, Superhori, Snakeyes, Matdrodes, AlleborgoBot, SieBot, Val-ders, 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, Donder-vogel 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, RicardDelgado 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 yAnnimos: 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 Colabo-

radores: 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: + 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 Colaborado-res: ? Artista original: ?

Archivo:Tcp-handshake.svg Fuente: https://upload.wikimedia.org/wikipedia/commons/9/98/Tcp-handshake.svg Licencia: CC-BY-SA-3.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

Protocolo orientado a la conexinSeguridad Alternativas Lista de protocolos orientados a la conexin Vase tambin Referencias Enlaces externos

Transmission Control ProtocolObjetivos de TCP Informacin tcnica Funciones de TCP Caractersticas del TCP Formato de los segmentos TCP

Funcionamiento del protocolo en detalle Establecimiento de la conexin (negociacin en tres pasos) Transferencia de datos Tamao de ventana TCP Escalado de ventana Fin de la conexin

Puertos TCP Desarrollo de TCP Comparativa entre UDP y TCP Bibliotecas de sockets TCP Vase tambin Referencias Enlaces externos

Frame RelayFrame Relay Aplicaciones y Beneficios

Vase tambin Enlaces externos

Modo de Transferencia AsncronaResea histrica de ATM Descripcin del proceso ATM Formato de las celdas ATM Campos

Encaminamiento Modelo arquitectnico Perspectiva de la tecnologa ATM Referencias Vase tambin Enlaces externos

Protocolo no orientado a la conexinLista de protocolos no orientados a la conexin Referencias Vase tambin Enlaces externos Texto e imgenes de origen, colaboradores y licenciasTextoImgenesLicencia de contenido