3 Analisis Comparativo TCP

7/23/2019 3 Analisis Comparativo TCP

1/31

3 Analisis Comparativo TCP - UDP

Editar08

3. Anlisis comparativo: TCP - UDPLos dos protocolos ms comunes de la capa de Transporte del conjuntode protocolos TCP/IP son el Protocolo de control de transmisin (TCP) yel Protocolo de datagramas de usuario (UDP). m!os protocolosgestionan la comunicacin de m"ltiples aplicaciones. Las di#erenciasentre ellos son las #unciones espec$#icas %ue cada uno implementa.TCP vs UDP

TCP UDP

Orientado a la conexin

Confiabilidad en la entrega de

mensajes

Divide los mensajes en datagramas

Hace seguimiento del orden (o

secuencia)

Usa checksums para la deteccin

de errores

os procedimientos remotos no

son idempotentes

a confiabilidad es prioridad

os mensajes exceden el tama!o

de un pa"uete UD#

$in conexin

%o se fragmentan los mensajes

%o ha& reensamblaje ni sincroni'acin

n caso de error el mensaje se retransmite

$in acuse de env*o

os procedimientos remotos son idempotentes

os mensajes del servidor & el cliente entran

completamente dentro de un pa"uete

l servidor maneja multiples clientes (UD# no tiene

estados)

TCP y UDP utili&an el mismo es%uema de direccionamiento. Unadireccin IP y un n"mero de puerto.Ventajas de UDP

%o te restringe a un modelo de comunicacin

basado en la conexin la latencia para el inicio en

aplicaciones distribuidas es mucho menor al igual "ue la

Ventajas de TCP

l sistema operativo hace todo el trabajo

el manejo de pa"uetes de entrada tiene menos

cambios de contexto del kernel al espacio de
http://datagramas.wikispaces.com/3+Analisis+Comparativo+TCP+-+UDPhttp://datagramas.wikispaces.com/3+Analisis+Comparativo+TCP+-+UDP#discussionhttp://datagramas.wikispaces.com/3+Analisis+Comparativo+TCP+-+UDP#discussionhttp://datagramas.wikispaces.com/page/history/3+Analisis+Comparativo+TCP+-+UDPhttp://datagramas.wikispaces.com/page/menu/3+Analisis+Comparativo+TCP+-+UDPhttp://datagramas.wikispaces.com/3+Analisis+Comparativo+TCP+-+UDP#discussionhttp://datagramas.wikispaces.com/page/history/3+Analisis+Comparativo+TCP+-+UDPhttp://datagramas.wikispaces.com/page/menu/3+Analisis+Comparativo+TCP+-+UDPhttp://datagramas.wikispaces.com/3+Analisis+Comparativo+TCP+-+UDP


2/31

sobrecarga del sistema operativo+

,odo el control de flujo los acuses de recibo el

registro de transacciones etc+ depende de los programas de

usuario+ -dem.s slo es necesario implementar & utili'ar

las funciones "ue necesita+

l receptor de los pa"uetes UD# los recibe sin

fragmentar inclu&endo los l*mites de los blo"ues+

/roadcast & transmisin multicast est.n

disponibles con UD#+

usuario & de vuelta todo el reensamblaje acusede recibo control de flujo etc se lleva a cabo por

el kernel+

,C# garanti'a tres cosas0 "ue sus datos

lleguen "ue lleguen en orden & "ue lleguen sinduplicaciones+

os routers pueden notar los pa"uetes

,C# & los tratan de forma especial+ los pueden

almacenar en b1fer & los retransmiten+

,C# tiene un buen rendimiento relativo a

trav2s de un mdem o una -%+

Desventajas de UDP

%o ha& garant*as con UD#+ un pa"uete puede no

ser entregado o entregado dos veces o entregado fuera de

orden no se obtiene ning1n indicio de esto a menos "ue elprograma de escucha en el otro extremo decide decir algo+

UD# no tiene control de flujo+ la implementacin

es el deber de los programas de usuario+

os routers son mu& descuidados con UD#+ nunca

se retransmiten si colisionan & parecen ser la primera cosa

descartada cuando un router est. corto de memoria+ UD#sufre m.s p2rdida de pa"uetes "ue ,C#+

Desventajas de TCP

l sistema operativo puede ser

defectuoso+#uede ser inefica' & puede "ue no se

pueda afinar+

,C# es d*ficil de expandirse puede

establecer una pocas opciones de socketpero

tiene "ue tolerar el control de flujo incorporado+

,C# puede tener un montn de

caracter*sticas"ue no son necesarias puede

desperdiciar ancho de banda tiempo oesfuer'o enasegurar cosas "ue son irrelevantes para la tarea

en cuestin+

,C# no tiene l*mites de blo"ues debe

crear el su&o+

os routers de la 3nternet de ho& en d*a

est.n agotando su memoria no pueden prestar

mucha atencin a tcp las asumpsiones de dise!o

de ,C# se descomponen en este entorno+

,C# tiene rendimiento relativamente

pobre en conexiones de alta latencia gran ancho

de banda como una conexin por sat2lite o consobrecarga+

,C# no puede ser utili'ado para

broadcast o transmisin multicast+


3/31

,C# no puede concluir una transmisin

sin todos los datos en movimiento expl*citamente

confirmados+

Ventajas de la UDP para la

transferencia de archivos

l control de flujo depende del espacio de usuario4

las ventanas pueden ser infinitas no existen interrupciones

artificiales la latencia es bien tolerada & las velocidades

m.ximas solo se pueden for'ar por ancho de banda real a

pesar de "ue las velocidades reales son elegidas poracuerdo entre el emisor & el receptor+

$i recibe una imagen de forma simult.nea desde

varios hosts es mucho m.s f.cil con UD# como lo es elenv*o a varios hosts especialmente si llegan a ser parte del

mismo grupo broadcast o multicast+

Desventajas de TCP para la

transferencia de archivos

,C# permite una ventana de un m.ximo

de 56k & el mecanismo de -C73%8 significa "ue

la p2rdida de pa"uetes no se ha detectado+

os servidores de transferencia ,C# han

de mantener un socket separado (& a menudo un

hilo separado) para cada cliente+

l balanceo de carga es crudo &aproximado+ specialmente en las redes locales

"ue permiten colisiones dos transferencias

simult.neas de ,C# tienen una tendencia a pelearunas con otras incluso si el remitente es el

mismo+

2.8 Informacion adicional sobre UDP

Editar08

2.8 Informacin adicional sobr UDP'i !ien UDP es a eces la mejor alternatia para ciertos tipos deaplicaciones de!ido a sus propiedades "nicas presenta algunos retospara los desarrolladores. 'in em!argoestos retos pueden sersatis#ec*os mediante la estructuracin de la transmisin de datos parasuperar las limitaciones de UDP. continuacin se e+aminan estaslimitaciones y cmo pueden ser superadas.

2.8.! "alta d ntr#a #aranti$adaLos pa%uetes eniados a tra,s de UDP pueden perderse en trnsito-cada salto adicional entre un router y otro presenta ms retrasos yaumenta la pro!a!ilidad de %ue un pa%uete pueda ser descartadocuando el TTL llega a cero. dems los pa%uetes UDP pueden daarseoperderse si lacone+in de red #$sica en la %ue se enrutan se cae.a %ue
http://datagramas.wikispaces.com/2.8+Informacion+adicional+sobre+UDPhttp://datagramas.wikispaces.com/2.8+Informacion+adicional+sobre+UDP#discussionhttp://datagramas.wikispaces.com/2.8+Informacion+adicional+sobre+UDP#discussionhttp://datagramas.wikispaces.com/page/history/2.8+Informacion+adicional+sobre+UDPhttp://datagramas.wikispaces.com/page/menu/2.8+Informacion+adicional+sobre+UDPhttp://datagramas.wikispaces.com/2.8+Informacion+adicional+sobre+UDPhttp://datagramas.wikispaces.com/2.8+Informacion+adicional+sobre+UDP#discussionhttp://datagramas.wikispaces.com/page/history/2.8+Informacion+adicional+sobre+UDPhttp://datagramas.wikispaces.com/page/menu/2.8+Informacion+adicional+sobre+UDP


4/31

los pa%uetesde Internet son transmitidos a tra,s deuna red p"!licaintegrada por una amplia gama de in#raestructuras de red es pro!a!le%ue los pa%uetes se pierdan en alg"n punto de la cone+in.

Por supuesto en algunas aplicaciones de la p,rdida de pa%uetes

indiiduales puede no tener un e#ecto nota!le. Por ejemplo unasecuencia de $deo puede perder unos cuantos cuadros de imagen perosiempre %ue la mayor$a de las tramas lleguen la p,rdida es soporta!le.'in em!argo si un arc*io se est trans#iriendo entonces el contenidodel arc*io se conertir en ilegi!le y la p,rdida de pa%uetes llega a serinacepta!le. 'i la entrega garanti&ada es re%uerida la mejor alternatiaes eitar la comunicacin !asada en pa%uetes y utili&ar un mecanismode transporte ms adecuado como el Transmission Control Protocol(TCP). 0o o!stante si el uso de la UDP es pedido una solucin es %ue laparte %ue reci!e los pa%uetes en$e un pa%uete decon#irmacin(tam!i,n conocido como C1) de uelta al remitente. La

ausencia de un C1 indica %ue el pa%uete se *aperdido y de!e serretransmitido.

%&TAlgunos sistemas de transporte eniarn de uelta un C1 parapa%uetes indiiduales o para una amplia gama de pa%uetes. pesar de%ue se le aade complejidad el reconocimiento de una serie depa%uetes *ace un uso ms e#iciente del anc*o de !anda. lgunossistemas tam!i,n utili&an un pa%uete de reconocimiento negatie (01)para indicar %ue un pa%uete espec$#ico se perdi lo %ue desencadenainmediatamente la retransmisin de ese pa%uete.

2.8.2 "alta d sc'ncia d pa('ts #aranti$adaLas aplicaciones %ue re%uieren el acceso secuencial a los datos (yseamos sinceros %ue e%uiale a la mayor$a del so#t2are) de!en incluirun n"mero de secuencia en el contenido de un pa%uete datagrama. 'illega un pa%uete #uera de orden puede ser almacenado en !u##er *asta%ue los pa%uetes anteriores se *an alcan&ado. La secuencia aade unape%uea cantidad de complejidad pero *ace un sistema ms #ia!le(siempre sa!es con %u, pa%uete ests tratando). Los pa%uetes

duplicados de!en ser desec*ados y los pa%uetes perdidos (de!ido a la#alta de entrega garanti&ada) solicitados de nueo.

2.1 User Datagram Protocol UDP!

Editar016
http://datagramas.wikispaces.com/2.1+User+Datagram+Protocol+(UDP)http://datagramas.wikispaces.com/2.1+User+Datagram+Protocol+(UDP)#discussionhttp://datagramas.wikispaces.com/page/history/2.1+User+Datagram+Protocol+(UDP)http://datagramas.wikispaces.com/page/menu/2.1+User+Datagram+Protocol+(UDP)http://datagramas.wikispaces.com/2.1+User+Datagram+Protocol+(UDP)http://datagramas.wikispaces.com/2.1+User+Datagram+Protocol+(UDP)#discussionhttp://datagramas.wikispaces.com/page/history/2.1+User+Datagram+Protocol+(UDP)http://datagramas.wikispaces.com/page/menu/2.1+User+Datagram+Protocol+(UDP)


5/31

2. Usr Data#ram Protocol )UDP*

2.1 "isi#n general3l protocolo UDP (UserDatagram Protocol) es un protocolo no orientado a

cone+in de la capa de transporte del modelo TCP/IP lo %ue signi#ica %ue

nogaranti&ar ni la entrega de pa%uetes ni %ue los pa%uetes lleguen en ordensecuencial donde el control so!re el destino #inal de un pa%uete UDP recae en

el e%uipo %ue lo en$a.

Figura N 7: UDP en una red pueden ser poco fiables

Dado la pro!a!ilidad de p,rdida de pa%uetes de datos puede parecer e+trao

%ue a nadie se le ocurra utili&ar un sistema tan poco #ia!le aparentemente

anr%uica. De *ec*o *ay muc*as entajas al usar UDP %ue pueden no ser

eidentes a primera ista.

UDP puede ser ms e#iciente %ue la entrega garanti&ada de #lujos dedatos de. 'i la cantidad de datos es pe%uea y los datos se en$an con#recuencia tiene sentido usarla para eitar la so!recarga de entregagaranti&ada.


6/31

di#erencia de TCP %ue esta!lecen una cone+in UDP causa menosgastos generales. 'i la cantidad de datos %ue se en$an es pe%uea y los datosse en$an con #recuencia la so!recarga de esta!lecer una cone+in no puedealer la pena. UDP puede ser pre#eri!le en este caso so!re todo si se en$anlos datos de un gran n"mero de m%uinas a una central en cuyo caso la sumatotal de todas estas cone+iones pueden proocar una so!recarga considera!le.

Las aplicaciones en tiempo real pueden ser candidatos para usar UDP ya%ue *ay menos retrasos de!ido a la compro!acin de errores y control de #lujode TCP. Los Pa%uetes UDP pueden ser utili&ados para saturar el anc*o de!anda disponi!le para o#recer grandes cantidades de datos. dems si sepierden algunos datos pueden ser sustituidos por el siguiente grupo depa%uetes con in#ormacin actuali&ada eliminando la necesidad de oler aeniar los datos antiguos.

Los soc4ets UDP puede reci!ir datos de ms de un *ost. 'i *ay ariasm%uinasde!e *a!er comunicacin entonces UDP puede ser ms coneniente%ue otros mecanismos como TCP.

lgunos protocolos de red especi#icar UDP como mecanismo detransporte %ue re%uiriendo su uso.

Un soc4et es una re#erencia indirecta a un puerto particular usada por el

proceso receptor en la m%uina receptora.

3l en$o de datagramas es similar a eniar una carta a tra,s del sericio

postal5 3l orden de salida no es importante y no est garanti&ado y cada

mensaje es independiente de cual%uier otro.

3n las comunicaciones !asadas en datagramas como las UDP el pa%uete dedatagramas contiene el n"mero de puerto de su destino y el UDP encamina el

pa%uete a la aplicacin apropiada. Como en la #igura 06 7


7/31

Figura N 8: Comunicacin basada en datagramasUn datagrama eniado mediante

UDP es trasmitido desde un proceso emisor a un proceso receptor sin

reconocimiento o recompro!aciones. 'i tiene lugar un #allo el mensaje puede

no llegar. Un datagrama es transmitido entre procesos cuando un proceso lo

en$a y otro proceso lo reci!e. Cual%uier proceso %ue necesite eniar o reci!ir

mensajes de!e en primer lugar crear un soc4et a una direccin de Internet y

un puerto local. Un seridor enla&ar ese soc4et a un puerto seridor - uno %ue

se *ace conocido a los clientes de manera %ue puedan eniar mensajes al

mismo. Un cliente enla&a su soc4et a cual%uier puerto local li!re. 3l m,todo

receptor deuele la direccin de Internet y el puerto del emisor adems del

mensaje permitiendo a los receptores eniar una respuesta.

Figura N 9: un servidor utiliza dos sockets: uno para aceptar la conexin el otro para enviar !

receptor

Las clases 8aa para esta!lecer comunicaciones mediante datagramas son5


8/31

jaa.net.DatagramPac4et

jaa.net.Datagram'oc4et

2.2 Clase DatagramPac$et

Editar017

2 Usr Data#ram Protocol )UDP*

2.2 Clas Data#ramPac+t

La clase DatagramPac4et representa un pa%uete de datos destinados ala transmisin mediante el uso de UDP. Los pa%uetes son contenedoresde una pe%uea secuencia de !ytes e incluyen in#ormacin dedireccionamiento como una direccin IP y un puerto.

Figura N "#: Datagra$Packet

3l signi#icado de los datos almacenados en un DatagramPac4et estdeterminado por su conte+to. Cuando un DatagramPac4et se *a le$dodesde un soc4et UDP la direccin IP del pa%uete representa la direccindel remitente (lo mismo con el n"mero de puerto). 'in em!argo cuandoun DatagramPac4et es usado para eniar un pa%uete UDP la direccinIP almacenada en DatagramPac4et representa la direccin deldestinatario (lo mismo con el n"mero de puerto). 3sta inersin desentido es importante 9ecuerde uno no %uerr eniar un pa%uete deregreso a uno mismo.
http://datagramas.wikispaces.com/2.2+Clase+DatagramPackethttp://datagramas.wikispaces.com/2.2+Clase+DatagramPacket#discussionhttp://datagramas.wikispaces.com/2.2+Clase+DatagramPacket#discussionhttp://datagramas.wikispaces.com/page/history/2.2+Clase+DatagramPackethttp://datagramas.wikispaces.com/page/menu/2.2+Clase+DatagramPackethttp://datagramas.wikispaces.com/2.2+Clase+DatagramPackethttp://datagramas.wikispaces.com/2.2+Clase+DatagramPacket#discussionhttp://datagramas.wikispaces.com/page/history/2.2+Clase+DatagramPackethttp://datagramas.wikispaces.com/page/menu/2.2+Clase+DatagramPacket


9/31

2.2.!Crando 'n Data#ramPac+t:ay dos ra&ones para crear un nueo DatagramPac4et5I. Para eniar datos a una m%uina remota usando UDPII. Para reci!ir los datos eniados por una m%uina remota usando UDP

La clase DatagramPac4et proporciona un constructor %ue permite crearinstancias de un array de !ytes para el mensaje la longitud delmensaje la direccin Internet y el puerto local del soc4et de destino dela siguiente #orma5

Constr'ctorsLa eleccin del constructor DatagramPac4et es determinada por su#inalidad.Cada constructor re%uiere la especi#icacin de un conjunto de !ytes elcual se utili&ar para almacenar el contenido del pa%uete UDP y la

longitud del pa%uete de datos.

Para crear un DatagramPac4et para la recepcin de pa%uetes UDPentrantes el siguiente constructor de!e serusado5DatagramPac4et(!yte;< !u##er int lengt*).Porejemplo5DatagramPac4et pac4et = ne2 DatagramPac4et(ne2 !yte;>?@?@)APara eniar un DatagramPac4et a una m%uina remota es pre#eri!leutili&ar el siguientes constructor5DatagramPac4et(!yte;< !u##er intlengt* Inetddress destBaddr int destBport).Por ejemplo5Inetddressaddr = Inetddress.gety0ame(EF>[email protected])DatagramPac4et pac4et

= ne2 DatagramPac4et ( ne2 !yte;E>77 addr >GGG)A

2.2.2Usando 'n Data#ramPac+tLa clase DatagramPac4etproporciona algunos m,todos importantes %ue permiten a5 la direccinremota puerto remoto los datos (como un !ytes de array) y lalongitud del pa%uete puedan ser recuperado. partir de 8D1 E.E *aytam!i,n m,todos para modi#icar estos a tra,s de un m,todo setcorrespondiente. 3sto signi#ica %ue uno reci!epa%uetes %ue puedan serreutili&ados. Por ejemplo el contenido de un pa%uete puede serreempla&ado y eniado de uelta al remitente. 3sto a*orra el tener %uereiniciar la in#ormacin de direccionamiento la direccin y el puerto delpa%uete %ue ya est esta!lecido en el remitente.

,todos


10/31

Inetddress getddress()- deuele la direccin IP desde %ueunDatagramPac4et#ue eniado o (si el pa%uete a a ser eniado a unam%uina remota) la direccin IP de destino.

!yte ;< getData ()- deuele el contenido de la DatagramPac4et

representado como una matri& de !ytes.

int getLengt* int ()- deuele la longitud de los datosalmacenados en un DatagramPac4et. 3sto puede ser menor %ue eltamao real del !"#er de datos

int getPort ()- deuele el n"mero de puerto desde donde seeni un DatagramPac4et o (si el pa%uete a a ser eniado a unam%uina remota) el n"mero de puerto de destino.

oid setddress (Inetddress addr) - asigna una nuea direccinde destino a un DatagramPac4et.

oid setData (!yte ;< !u##er)- asigna un !u##er de datos nueos ala DatagramPac4et.

oid 'etLengt* (int lengt*)- asigna una nuea longitud dela DatagramPac4et.

Hoid setPort (int port)- asigna un puerto de destino a unnueo DatagramPac4et.

2.3 Clase Datagram%oc$et

Editar09

2.3 Clas Data#ramoc+tLa clase Datagram'oc4et proporciona acceso a un soc4et UDP lo %uepermite %ue los pa%uetes UDP puedan ser eniados y reci!idos. UnDatagramPac4et se utili&a para representar un pa%uete UDP y de!e sercreado antes de reci!ir los pa%uetes. 3l mismo Datagram'oc4et puede

ser usado para reci!ir los pa%uetes tanto como para eniarlos.'in em!argo las operaciones de lectura son de !lo%ueo lo %ue signi#ica%ue la aplicacincontinuara esperando *asta %ue llega un pa%uete. a%ue los pa%uetes UDP no garanti&an la entrega esto puede causar %ueuna aplicacin se detenga si el remitente no uela a eniar lospa%uetes. a %ue los pa%uetes UDP no garanti&an la entrega esto puedeoriginar %ue una aplicacin se detenga si el remitente no uela a eniar
http://datagramas.wikispaces.com/2.3+Clase+DatagramSockethttp://datagramas.wikispaces.com/2.3+Clase+DatagramSocket#discussionhttp://datagramas.wikispaces.com/2.3+Clase+DatagramSocket#discussionhttp://datagramas.wikispaces.com/page/history/2.3+Clase+DatagramSockethttp://datagramas.wikispaces.com/page/menu/2.3+Clase+DatagramSockethttp://datagramas.wikispaces.com/2.3+Clase+DatagramSockethttp://datagramas.wikispaces.com/2.3+Clase+DatagramSocket#discussionhttp://datagramas.wikispaces.com/page/history/2.3+Clase+DatagramSockethttp://datagramas.wikispaces.com/page/menu/2.3+Clase+DatagramSocket


11/31

los pa%uetes.

2.3.!Crando 'n Data#ramoc+t Datagram'oc4et puede serutili&ado para eniar y reci!ir pa%uetes. Cada Datagram'oc4et se une aun puerto en la m%uina local el cual es usado para dirigir a los

pa%uetes. 3l n"mero de puerto necesita no ser el mismo n"mero de lam%uina remota pero si la aplicacin es un seridor UDP se suelenelegir un n"mero de puerto espec$#ico. 'i el Datagram'oc4et estdestinado a ser un cliente yno necesita %ue se una a un n"mero depuerto espec$#ico un constructor en !lanco puede ser especi#icado.Constr'ctorPara crear un Datagram'oc4et cliente el siguiente constructor esusado5Datagram'oc4et () t*ro2s jaa.net.'oc4et3+ception.Para crear un serer Datagram 'oc4et el siguiente constructor esusado5 %ue toma como parmetro el puerto al %ue el sericio UDP ser

o!ligado5Datagram'oc4et (int puerto) t*ro2s jaa.net.'oc4et3+ception

2.3.2Usando 'n Data#ramoc+tDatagram'oc4et se utili&a parareci!ir los pa%uetes UDP entrantes y salientes para eniar pa%uetes UDP.Proporciona m,todos para eniar y reci!ir pa%uetes as$ tam!i,n comoespeci#icar un alor de tiempo de espera cuando non!loc4ing I/ estutili&ando para inspeccionar y modi#icar el m+imo tamao de lospa%uetes UDP y cerca del &calo.

,todos

oid close ()- cierra un soc4et y se desliga del puerto local.

oid connect (Inetddress remoteBaddr remoteBport int)Jrestringe el acceso a la direccin especi#icada a distancia y el puerto. Ladesignacin es un t,rmino e%uiocado ya %ue UDP en realidad no crearuna cone+in entre una m%uina y otra. 'in em!argo si este m,todose utili&a *ace %ue las e+cepciones %ue se produce si se intenta eniarpa%uetes ao leer los pa%uetes de cual%uier otro *ost y el puerto a los

especi#icados.

oid disconnect()- desconecta el Datagram'oc4et.

Inetddress getInetddress ()- Deuele la direccin remota a la%ue el soc4et est conectado o null si no e+iste ninguna tal cone+in.


12/31

int getPort ()- deuele el puerto remoto al %ue est conectado elsoc4et o -E si no e+iste dic*a cone+in.

Inetddress getLocalddress ()- deuele la direccin local a la%ue el soc4et esta enla&ado.

int getLocalPort ()- deuele el puerto local al %ue est enla&adoel conector.

int get9eceieu##er'i&e () t*ro2s jaa.net.'oc4et3+ceptionJdeuele el tamao m+imo del !"#er utili&ado para los pa%uetes UDPentrantes.

int get'endu##er'i&e () t*ro2s jaa.net.'oc4et3+ception-deuele el tamao m+imo de !"#er utili&ado para pa%uetes UDPsalientes.

get'oTimeout int () t*ro2s jaa.net.'oc4et3+ception- deuele elalor de la opcin de conector de tiempo de espera. 3ste alor se utili&apara determinar el n"mero de milisegundos %ue una operacin delectura !lo%ueara antes de lan&ar unjaa.io.InterruptedI3+ception. Demanera predeterminada este alor ser igual a cero lo %ue indica %ueel !lo%ueo de 3 / ' se utili&ar.

oid receie (DatagramPac4et pac4et)) t*ro2sjaa.io.I3+ception- lee un pa%uete UDP y almacena el contenido en el

pa%uete especi#icado. La direccin y el puerto.

2.& 'nviar pa()etes UDP

Editar08

2./ 0nviar pa('ts UDPLa misma inter#a& (Datagram'oc4et) empleada para reci!ir pa%uetes UDPtam!i,n se utili&a para eniarlos. Cuando se en$a un pa%uete la aplicacinde!e crear un DatagramPac4et esta!lecer la direccin y el puerto de la

in#ormacin y escri!ir los datos destinados a la transmisin a su array de!ytes. 'i est respondiendo a un pa%uete reci!ido la direccin y la in#ormacindel puerto ya estar almacenada y slo los datosnecesitan ser so!rescritos.Una e& %ue el pa%uete est listo para la transmisin el m,todo de en$odeDatagram'oc4et es inocado y un pa%uete UDP se en$a.
http://datagramas.wikispaces.com/2.5+Enviar+paquetes+UDPhttp://datagramas.wikispaces.com/2.5+Enviar+paquetes+UDP#discussionhttp://datagramas.wikispaces.com/page/history/2.5+Enviar+paquetes+UDPhttp://datagramas.wikispaces.com/page/menu/2.5+Enviar+paquetes+UDPhttp://datagramas.wikispaces.com/2.5+Enviar+paquetes+UDPhttp://datagramas.wikispaces.com/2.5+Enviar+paquetes+UDP#discussionhttp://datagramas.wikispaces.com/page/history/2.5+Enviar+paquetes+UDPhttp://datagramas.wikispaces.com/page/menu/2.5+Enviar+paquetes+UDP


13/31

3l siguiente #ragmento de cdigo ilustra este proceso5

Datagram%oc$et soc$et * ne+ Datagram%oc$et2,,,!DatagramPac$et pac$et * ne+ DatagramPac$et ne+ bte/2&0 2&0!pac$et.setAddress InetAddress.get4ame some5ost ! !pac$et.setPort 2,,, !boolean 6nis5ed * false+5ile 76nis5ed !99 'scribir datos en el b):er del pa()ete

.........soc$et.send pac$et!9 9 ;acer otra cosa como leer los pa()etes o revisar para9 9 ver si 5a m


14/31

co$putacionales con diferentes procesadores siste$as operativos1 seco$uni-uen unos con otros,

Protocolos de capa de transporte %&P!2P 0inicio de%&P!UDP1Publicado por'nri-ue Perez en$i/rcoles* enero 39* 3#"4

Esto es solo introduccin, ya estn en el horno los captulos subsiguientes, pero quera darles unadelanto. Adems me cay en las manos un artculo muy completo sobre traceroute, que esta porsalir en unos das (son varios artculos de hecho ... como "mashup" ). ues eso, provecho y hasta elsiguiente.

Protocolos de la capa de transporte TCP / IP.Las tres primeras capas del modelo de referencia OSI- la capa fsica, la de enlace de datos y la dered - son capas muy importantes para la comprensin de cmo funcionan las redes. La capa fsicamueve los bits a travs de cables; la capa de enlace de datos mueve tramas en una red, la capa de redmueve datagramas en una interconein de redes. !omadas en su con"unto, son las partes de la pilade protocolos responsables de las #tuercas y tornillos# reales del proceso de llevar datos de un lugara otro.

Inmediatamente por encima de stas tenemos la cuarta capa del modelo de referencia OSI$ la capa

de transporte, llamada la capa de transporte %ost-to-%ost en el modelo!&'(I'. )sta capa esinteresante, ya *ue reside en el mismo centro ar*uitectnico del modelo. 'or consiguiente,representa un importante punto de transicin entre las capas asociadas al %ard+are ubicadas pordeba"o de ella *ue %acen el #traba"o sucio#, y las capas *ue estn por encima, mas orientadas alsoft+are y por ende mas abstractas.

Los protocolos *ue operan en la capa de transporte estn a cargo de proporcionar varios serviciosimportantes para *ue las aplicaciones de soft+are en las capas superiores traba"en a travs de unainterconein de redes. 'or lo general son responsables de permitir los procesos de establecer ymantener coneiones entre servicios de soft+are en m*uinas posiblemente distantes. uis loms importante, sirven de puente entre las necesidades de muc%as aplicaciones de capas superioresde enviar datos de forma fiable sin tener *ue preocuparse por la correccin de errores, la prdida dedatos o la gestin de flu"o, y la capa de red protocolos, *ue a menudo son poco fiables y no se ocupan

de los acuses de recibo. Los protocolos de capa de transporte estn a menudo estrec%amentevinculados a los protocolos de capa de red directamente deba"o de ellos, y son dise/adosespecficamente para atender funciones de las *ue estos 0ltimos no se ocupan.

)n esta seccin describiremos protocolos de capa de transporte y las tecnologas coneas utiliadasen el protocolo !&' ( I' 1ay dos protocolos principales de esta capa, el 'rotocolo de &ontrol de!ransmisin 2!ransmission &ontrol 'rotocol !&'3 y el 'rotocolo de datagramas de usuario 24ser5atagram 'rotocol 45'3. !ambin se discute cmo en la capa de transporte se realia una clase dedireccionamiento en !&' ( I' en forma de puertos y soc6ets.
https://plus.google.com/103635952006321056936https://plus.google.com/103635952006321056936http://www.tecnodelinglesalcastellano.com/2014/01/protocolos-de-capa-de-transporte-tcpip.htmlhttp://www.tecnodelinglesalcastellano.com/2014/01/protocolos-de-capa-de-transporte-tcpip.htmlhttp://goo.gl/u5OEPRhttp://goo.gl/fJzMGahttp://goo.gl/fJzMGahttp://goo.gl/2vYLChttp://goo.gl/2vYLChttps://plus.google.com/103635952006321056936http://www.tecnodelinglesalcastellano.com/2014/01/protocolos-de-capa-de-transporte-tcpip.htmlhttp://goo.gl/u5OEPRhttp://goo.gl/fJzMGahttp://goo.gl/2vYLC


15/31

Nota:uede parecer e!trao que aqu solo haya una subseccin, la que cubre #$ y%&. Este es un resultado del hecho de que la gua de #$ ' es un e!tracto de unareerencia de redes ms grandes.

Protocolo de Control de Transmisin (TCP) y el Protocolo de datagramas de usuario

(UDP)!&' ( I' es el con"unto de protocolos de interconein ms importantes del mundo, es la base parael Internet, y el #lengua"e# %ablado por la gran mayora de los ordenadores conectados en red delmundo. !&' ( I' incluye un gran con"unto de protocolos *ue operan en la capa de red y por encima.La suite en su con"unto est anclada a la capa tres enel 'rotocolo de Internet 2I'3,el *ue muc%aspersonas consideran el protocolo ms importante en el mundo de las redes.

'or supuesto, %ay una cierta distancia ar*uitectnica entre la capa de red y las aplicaciones *ue see"ecutan en las capas por encima. 7 pesar de *ue I' es el protocolo *ue lleva a cabo la mayor partede las funciones necesarias para realiar una interconein de redes, este no incluye muc%ascapacidades *ue son re*ueridas por las aplicaciones. )n !&' ( I' estas tareas son realiadas por unpar de protocolos *ue operan en la capa de transporte$ el 'rotocolo de &ontrol de !ransmisin2!ransmission &ontrol 'rotocol !&'3 y el 'rotocolo de datagramas de usuario 24ser 5atagram

'rotocol 45'3.

5e estos dos, !&' recibe, con muc%o, la mayor atencin. )s el protocolo de capa de transporte *uese asocia ms con !&' ( I', y, bueno, su nombre est a%, #iluminado#. !ambin es el protocolo detransporte utiliado por muc%as de las aplicaciones ms populares de Internet, mientras *ue 45'

va segundo en la facturacin. Sin embargo, !&' y 45' son realmente pares *ue "uegan el mismopapel en !&' ( I'. 8uncionan de manera muy diferente y ofrecen diferentes venta"as y desventa"as alas aplicaciones *ue los utilian, lo *ue los %ace importantes a ambos para la suite de protocoloscomo un todo. Los dos protocolos tambin tienen ciertas reas de similitud, lo *ue %ace *ue sea mseficiente describirlos a ambos en la misma subseccin, destacando su caractersticas y mtodos deoperacin compartidos, as como en los *ue divergen.

)n esta seccin proporciono un eamen detallado de los dos protocolos de la capa de transporte!&'(I'$ )l 'rotocolo de &ontrol de !ransmisin 2!&'3 y el 'rotocolo de datagramas de usuario245'3. )mpieo con una breve descripcin de la funcin de estos dos protocolos en el con"unto deprotocolos !&' ( I', y una discusin sobre por *u son importantes. 5escribo el mtodo *ueemplean los protocolos para el direccionamiento, y el uso de puertos y soc6ets en la capa detransporte. Luego tenemos dos secciones detalladas para cada uno de ellos 45' y !&'. &oncluyocon un resumen rpido y una comparacin de ambos.

Incidentalmente, %e descrito 45' antes *ue !&' por una sencilla ran$ es ms simple. 45' operams como un protocolo clsico basado en mensa"es, y de %ec%o, es ms similar a I' en s de lo *uees !&'. )sta es la misma ran por la *ue la seccin en !&' es muc%o mayor *ue la *ue cubre 45'$!&' es muc%o ms comple"o y %ace muc%o ms *ue 45'.

Generalidades y rol general de TCP y UDP en la pila TCP / IP.La capa de transporte en una suite de protocolos es responsable de un con"unto especfico de

funciones. 'or esta ran, se podra esperar *ue la suite !&' ( I' tuviera un 0nico protocolo detransporte *ue llevara a cabo esas funciones,as como I'es el protocolo n0cleo en la capa de red. )suna curiosidad, entonces, *ue %aya dos protocolos de capa de transporte diferentes ampliamenteutiliados en !&' ( I'. )sta disposicin es probablemente uno de los me"ores e"emplos del poder dela disposicin de los protocolos en capas, y por tanto, un e"emplo de *ue vali la pena todo el tiempo*ue pas aprendiendo a entender ese molestomodelo de referencia OSI.

Diferentes Reuisitos de la capa de transporte de TCP / IP.9amos a empear con una mirada %acia atrs en la capa tres. )nmi visin general de lascaractersticas clave de funcionamiento del 'rotocolo de Internet, describ varias limitaciones
http://goo.gl/eqGlDHhttp://goo.gl/eqGlDHhttp://goo.gl/eqGlDHhttp://goo.gl/eqGlDHhttp://goo.gl/eqGlDHhttp://goo.gl/ATqjiohttp://goo.gl/ATqjiohttp://goo.gl/u5OEPRhttp://goo.gl/u5OEPRhttp://goo.gl/JYjRjAhttp://goo.gl/JYjRjAhttp://goo.gl/JYjRjAhttp://goo.gl/JYjRjAhttp://goo.gl/eqGlDHhttp://goo.gl/eqGlDHhttp://goo.gl/ATqjiohttp://goo.gl/ATqjiohttp://goo.gl/u5OEPRhttp://goo.gl/JYjRjAhttp://goo.gl/JYjRjA


16/31

importantes de cmo funciona el protocolo I'. La ms importante de estas limitaciones es el %ec%ode *ue el protocolo I' es un protocolo no orientado a conein. Los datos se envan a travs de unared I' sin antes establecer una conein, utiliando un es*uema del #me"or esfuero#. Losmensa"es suelen llegara donde tienen *ue ir, pero no %ay garantas, y el remitente por lo generalni si*uiera sabe si los datos llegaron a su destino.

)stas caractersticas presentan problemas graves desde el punto de vista del soft+are. :uc%os, si nola mayora, las aplicaciones tienen *ue ser capaces de contar con el %ec%o de *ue los datos *ueenvan llegarn a su destino sin prdidas o errores. !ambin re*uieren *ue la conein entre dosdispositivos sea gestionada de forma automtica, mane"ando apropiadamente cuando sea necesarioproblemas como la congestin y control de flu"o. 7 menos *ue se proporcione alg0n mecanismopara esto en las capas ms ba"as, cada aplicacin necesitara ocuparse de estos asuntos, lo *ue serauna duplicacin de esfuero ecesiva.

5e %ec%o, se podra argumentar *ue el establecimiento de coneiones, el aseguramiento de lafiabilidad y el mane"o retransmisiones, buffering y flu"o de datos son tan importantes *ue %ubierasido me"or simplemente incluir estas %abilidades directamente en el 'rotocolo de Internet I'.&uriosamente, ese fue eactamente el caso en los primeros das de !&' ( I'.#)n el principio# no erams *ue un solo protocolollamado #!&'#, *ue combinaba las funciones del 'rotocolo de Internetcon la fiabilidad y las caractersticas de gestin de sesiones *ue acabamos de mencionar.

Sin embargo, %ay un gran problema con esto. )l establecimiento de coneiones, el aseguramiento dela confiabilidad, la gestin y el de control de flu"o y los acuses de recibo y retransmisiones$ todosstos tienen un costo$ el tiempo y anc%o de banda. La construccin de todas estas capacidades en un0nico protocolo *ue abar*ue las capas tres y cuatro significara *ue todas las aplicacionespercibiran no solo las venta"as de fiabilidad, sino tambin los costos. :ientras *ue esto estara bienpara muc%as aplicaciones, %ay otras *ue no necesitan tanto la fiabilidad, y #no pueden permitirse# lasobrecarga necesaria para proporcionarla.

!a solucin" dos protocolos de transporte muy diferentes.La solucin a este problema era simple$ de"ar *ue la capa de red 2I'3 se encargara del movimiento

bsico de datos sobre una interconein de redes, y definir dos protocolos en la capa de transporte.4no podra proporcionar un amplio con"unto de servicios para a*uellas aplicaciones *ue necesiten

esa funcionalidad, en el entendimiento de *ue se re*uieren algunos gastos para lograrlo. )l otrosera simple, proporcionando pocas funcionalidades desde la perspectiva clsica de las funciones decapa cuatro, pero sera rpido y fcil de usar. 5e a% el resultado de dos protocolos de capa detransporte en !&'(I'$

Protocolo de Control de Transmisin (TCP)"4n protocolo de transporte fiableorientado a conein y con todas las funciones para las aplicaciones !&' ( I'.!&' proveedireccionamiento de capa de transporte al permitir *ue m0ltiples aplicaciones de soft+are utilicensimultneamente una 0nica direccin I'. 'ermite *ue un par de dispositivos establecan unaconein virtual y, a continuacin intercambien datos bidireccionalmente. Las transmisiones segestionan mediante un sistema especial de ventana desliante, con deteccin y el reenvoautomtico de las transmisiones no reconocidas. La funcionalidad adicional permite mane"ar elflu"o de datos entre dispositivos y resolver las circunstancias especiales.

Protocolo de datagramas de usuario (UDP)" 4n protocolo de transporte muy simple

*ue proporciona direccionamiento a nivel de capa de transporte como !&', pero no muc%o mas *ueeso. 45' es poco ms *ue un protocolo #contenedor# 2+rapper3 *ue provee un medio para *ue lasaplicaciones accedan al protocolo I'. o est orientado a conein, las transmisiones no son fiables,

y los datos se pueden perder.

'ara emplear una analoga, !&' es un sedn de alto rendimiento totalmente de lu"o con c%ferseguimiento por satlite y sistemas sistema de navegacin. Ofrece un montn de lu"os, un buenrendimiento y confort. )sto prcticamente garantia *ue usted va a llegar a donde tiene *ue ir sinning0n problema, y cual*uier in*uietud *ue sur"a se podr corregir. 'or el contrario, 45' es uncoc%e de carreras bsico. Su ob"etivo es la simplicidad y la velocidad, la velocidad, la velocidad, todo
http://goo.gl/KXUlihttp://goo.gl/KXUlihttp://goo.gl/KXUlihttp://goo.gl/O30YWJhttp://goo.gl/O30YWJhttp://goo.gl/O30YWJhttp://goo.gl/aubcQQhttp://goo.gl/aubcQQhttp://goo.gl/aubcQQhttp://goo.gl/KXUlihttp://goo.gl/KXUlihttp://goo.gl/O30YWJhttp://goo.gl/O30YWJhttp://goo.gl/aubcQQhttp://goo.gl/aubcQQhttp://goo.gl/aubcQQ


17/31

lo dems es secundario. 'robablemente llegues a donde necesitas ir, pero bueno, los coc%es decarreras puede ser fastidiosos de operar.

Concepto clave:ara adaptarse a las dierentes necesidades de transporte de lasmuchas aplicaciones #$ ' , e!isten dos protocolos en la capa de transporte #$ ' .El rotocolo de $ontrol de #ransmisin (#$) es un protocolo con todas las unciones,orientado a cone!in que proporciona la entrega segura de los datos, mientras gestionadel lu*o de trico y mane*a problemas como la congestin y la p+rdida de transmisin.El protocolo de datagramas de usuario (%&), en contraste, es un protocolo mucho mssencillo que se concentra solamente en la entrega de datos, para ma!imiar la velocidadde la comunicacin cuando no se requieren las caractersticas de #$.

Generalidades y rol general de TCP y UDP en la pila TCP / IP.#plicaciones de TCP y UDP.

!ener dos protocolos de capa de transporte con fortaleas y debilidades complementariasproporciona una gran fleibilidad a los creadores de soft+are de red$

#plicaciones TCP"La mayora de las aplicaciones #tpicas# necesitan la fiabilidad y otros

servicios prestados por !&', y no se preocupan por la prdida de una pe*ue/a cantidad deprestaciones a la sobrecarga. 'or e"emplo, la mayora de las aplicaciones *ue transfieren arc%ivosimportantes o datos entre m*uinas utilian !&', ya *ue la prdida de cual*uier parte del arc%ivoinutilia totalmente la aplicacin. Los e"emplos incluyen aplicaciones conocidas como el 'rotocolode transferencia de %iperteto 21ypertet !ransfer 'rotocol 1!!'3 utiliado por la


18/31

7ntes de de"ar el tema de la comparacin de 45' y !&', *uiero se/alar eplcitamente *ue a pesarde *ue !&' se describe a menudo como ms lento *ue 45', esta es una medida relativa. !&' es unprotocolo muy bien escrito *ue es capa de e"ecutar transferencias de datos de alta eficiencia. Sloes lento en comparacin con 45' debido a la sobrecarga de crear y administrar las coneiones. Ladiferencia puede ser importante, pero no es enorme, as *ue tenlo en cuenta.

Caractersticas del protocolo UDP

'l protocolo UDP 0Protocolo de datagrama de usuario1 es un protocolo no orientado a

conexin de lacapa de transportedel $odelo %&P!2P, 'ste protocolo es $u si$ple a -ue no

proporciona deteccin de errores 0no es un protocolo orientado a conexin1,

Por lo tanto* el encabezado del seg$ento UDP es $u si$ple:

datos

0longitud variable1,

Significado de los diferentes campos

Puerto de origen: es el n5$ero depuertorelacionado con la aplicacin del re$itente

del seg$ento UDP, 'ste ca$po representa una direccin de respuesta para el destinatario,

Por lo tanto* este ca$po es opcional, 'sto significa -ue si el puerto de origen no est(

especificado* los "6 bits de este ca$po se pondr(n en cero, 'n este caso* el destinatario

no podr( responder 0lo cual no es estricta$ente necesario* en particular para $ensaes

unidireccionales1,

Puerto de destino: este ca$po contiene el puerto correspondiente a la aplicacin del

e-uipo receptor al -ue se env+a,

Longitud: este ca$po especifica la longitud total del seg$ento* con el encabezado

incluido, 8in e$bargo* el encabezado tiene una longitud de 4 x "6 bits 0-ue es x bits1*

por lo tanto la longitud del ca$po es necesaria$ente superior o igual a btes,

Suma de comprobacin: es unasu$a de co$probacinrealizada de $anera tal -ue

per$ita controlar la integridad del seg$ento,
http://es.ccm.net/contents/tcpip.php3http://es.ccm.net/contents/tcpip.php3http://es.ccm.net/contents/tcpip.php3http://es.ccm.net/contents/port.php3http://es.ccm.net/contents/port.php3http://es.ccm.net/contents/port.php3http://es.ccm.net/contents/base/control.php3http://es.ccm.net/contents/base/control.php3http://es.ccm.net/contents/tcpip.php3http://es.ccm.net/contents/tcpip.php3http://es.ccm.net/contents/port.php3http://es.ccm.net/contents/base/control.php3


19/31


20/31


21/31

@!td

@!td

, 1 2 3 > & 0 ? 8 @ 1,

11

12

13

1>

1&

10

1?

18

1@

2,

21

22

23

2>

2&

20

2?

28

2@

3,

31

P)erto de origen P)erto de destino

4mero de sec)encia

4mero de ac)se de recibo

Bargende

datos

eservado "entana

%)ma de control P)ntero )rgente

pciones elleno

Datos

8ignificado de los diferentes ca$pos:

Puerto de origen0"6 bits1: Puerto relacionado con la aplicacin en curso en la

$(-uina origen

Puerto de destino0"6 bits1: Puerto relacionado con la aplicacin en curso en la

$(-uina destino

N(mero de secuencia0G3 bits1: &uando el indicador 8N est( fiado en #* el n5$ero

de secuencia es el de la pri$era palabra del seg$ento actual,&uando 8N est( fiado en "* el n5$ero de secuencia es igual al n5$ero de secuencia

inicial utilizado para sincronizar los n5$eros de secuencia 028N1,

N(mero de acuse de recibo0G3 bits1: 'l n5$ero de acuse de recibo* ta$bi/n

lla$ado n5$ero de descargo se relaciona con el n5$ero 0secuencia1 del 5lti$o seg$entoesperado no el n5$ero del 5lti$o seg$ento recibido,

)argen de datos04 bits1: 'sto per$ite ubicar el inicio de los datos en el pa-uete,

C-u+* el $argen es funda$ental por-ue el ca$po opcin es de ta$a)o variable,

!eser&ado06 bits1: Un ca$po -ue actual$ente no est( en uso pero se proporciona

para el uso futuro,

"ndicadores06x" bit1: ;os indicadores representan infor$acin adicional:

U!*: 8i este indicador est( fiado en "* el pa-uete se debe procesar en

for$a urgente,

+C,: 8i este indicador est( fiado en "* el pa-uete es un acuse de recibo,


22/31

PS-0PU8E1: 8i este indicador est( fiado en "* el pa-uete opera de

acuerdo con el $/todo PU8E,

!S#: 8i este indicador est( fiado en "* se restablece la conexin,

S.N: 'l indicador 8N de %&P indica un pedido para establecer una

conexin,

F"N: 8i este indicador est( fiado en "* se interru$pe la conexin,

/entana0"6 bits1: &a$po -ue per$ite saber la cantidad de btes -ue el receptor

desea recibir sin acuse de recibo,

Suma de control0&A&1: ;a su$a de control se realiza to$ando la su$a del ca$po

de datos del encabezado para poder verificar la integridad del encabezado,

Puntero urgente0"6 bits1: 2ndica el n5$ero de secuencia despu/s del cual la

infor$acin se torna urgente,

0pciones0ta$a)o variable1: Diversas opciones

!elleno: 'spacio restante despu/s de -ue las opciones se rellenan con ceros para

tener una longitud -ue sea $5ltiplo de G3 bits,

Confiabilidad de las transferencias

'l protocolo %&P per$ite garantizar la transferencia de datos confiable* a pesar de -ue usa el

protocolo 2P* -ue no inclue ning5n $onitoreo de la entrega de datagra$as,

De .ec.o* el protocolo %&P tiene un siste$a de acuse de recibo -ue per$ite al cliente al

servidor garantizar la recepcin $utua de datos,

&uando se e$ite un seg$ento* se lo vincula a un n(mero de secuencia, &on la recepcin de

un seg$ento de datos* la $(-uina receptora devolver( un seg$ento de datos donde el

indicador C& est/ fiado en " 0para poder indicar -ue es un acuse de recibo1 aco$pa)adopor un n5$ero de acuse de recibo -ue e-uivale al n5$ero de secuencia anterior,

Cde$(s* usando un te$porizador -ue co$ienza con la recepcin del seg$ento en el nivel de

la $(-uina originadora* el seg$ento se reenv+a cuando .a transcurrido el tie$po per$itido* a

-ue en este caso la $(-uina originadora considera -ue el seg$ento est( perdido,


23/31

8in e$bargo* si el seg$ento no est( perdido llega a destino* la $(-uina receptora lo sabr(*

gracias al n5$ero de secuencia* -ue es un duplicado* slo retendr( el 5lti$o seg$ento -ue

lleg a destino,

Cmo establecer una cone'in

&onsiderando -ue este proceso de co$unicacin* -ue se produce con la trans$isin el

acuse de recibo de datos* se basa en un n5$ero de secuencia* las $(-uinas originadora

receptora 0cliente servidor1 deben conocer el n5$ero de secuencia inicial de la otra

$(-uina,

;a conexin establecida entre las dos aplicaciones a $enudo se realiza siguiendo el siguiente

es-ue$a:

;os puertos %&P deben estar abiertos,

;a aplicacin en el servidor es pasiva* es decir* -ue la aplicacin escuc.a espera

una conexin,

;a aplicacin del cliente realiza un pedido de conexin al servidor en el lugar donde la

aplicacin es abierta pasiva, ;a aplicacin del cliente se considera


24/31

en este seg$ento es el de acuse de recibo -ue contiene el n5$ero de secuencia inicial delcliente incre$entado en ",

Por 5lti$o* el cliente trans$ite un acuse de recibo* -ue es un seg$ento en el -ue el

indicador C& est( fiado en " el indicador 8N est( fiado en # 0a no es un seg$entode sincronizacin1, 8u n5$ero de secuencia est( incre$entado el acuse de recibo

representa el n5$ero de secuencia inicial del servidor incre$entado en ",

Despu/s de esta secuencia con tres interca$bios* las dos $(-uinas est(n sincronizadas la

co$unicacin puede co$enzar,

'xiste una t/cnica de pirater+a lla$ada falsificacin de 2P* -ue per$ite corro$per este enlace

de aprobacin con fines $aliciosos,

)1todo de &entana corredi2a

'n $uc.os casos* es posible li$itar la cantidad de acuses de recibo con el fin de aliviar el

tr(fico en la red, 'sto se logra fiando un n5$ero de secuencia despu/s del cual se re-uiera

un acuse de recibo, 'ste n5$ero en realidad se guarda en el ca$po ventanadel encabezado

%&P!2P,

'ste $/todo se lla$a efectiva$ente el


25/31

Cde$(s* el ta$a)o de esta ventana no es fio, De .ec.o* el servidor puede incluir el ta$a)o

de la ventana -ue considera $(s apropiado en sus acuses de recibo guard(ndolo en el

ca$po ventana, De este $odo* cuando el acuse de recibo indica un pedido para au$entar la

ventana* el cliente se desplazar( al borde derec.o de la ventana,

Por el contrario* en el caso de una reduccin* el cliente no desplazar( el borde derec.o de la

ventana .acia la iz-uierda sino -ue esperar( -ue avance el borde iz-uierdo 0al llegar los

acuses de recibo1,

Cmo terminar una cone'in

'l cliente puede pedir -ue se ter$ine una conexin del $is$o $odo -ue el servidor,

Para ter$inar una conexin se procede de la siguiente $anera:

Una de las $(-uinas env+a un seg$ento con el indicador FINfiado en "* la

aplicacin se autocoloca en estado de espera* es decir -ue dea de recibir el seg$entoactual e ignora los siguientes,

Despu/s de recibir este seg$ento* la otra $(-uina env+a un acuse de recibo con el

indicadorFINfiado en " sigue enviando los seg$entos en curso, Despu/s de esto* la$(-uina infor$a a la aplicacin -ue se .a recibido un seg$ento FIN luego env+a un

seg$ento FINa la otra $(-uina* -ue cierra la conexin,

Protocolo UDP 'l protocolo User Datagram Protocol UDP! proporciona )nservicio de entrega de datagramas sin coneEiFon no con6able )tiliGando elprotocolo IP como el protocolo s)bacente. Proporciona p)ertos para disting)irentre las aplicaciones de )n mismo an6triFonH cada mensae contiene el n)meF ro de p)erto destino asFJ como el de origen. Un programa de aplicaciFon ()e)tiliGa UDP debe responsabiliGarse por los problemas en la com)nicaciFonH pFerdida retraso d)plicaciFon desorden en la entrega de datagramas. 'l

formato de la cabecera UDP se m)estra en la 6g)ra 1.8. Ka cabecera es m)simple solo consta de la direcciFon de los p)ertos UDP de origen destino lalongit)d del mensae UDP )na s)ma de veri6caciFon ()e es opcional. %i laaplicaciFon decide )tiliGar la s)ma de veri6caciFon se debe )tiliGar )na pse)docabecera 6g)ra 1.@ para realiGar el cFalc)lo de la misma. Ka pse)do cabecerase )sa solo para calc)lar la s)ma de veri6caciFon no se incl)e al enviar elmensae. 'sta F incl)e las 1.@ Protocolo TCP 1? direcci#n IP destino , ceroprotocolo 1& 10 31 longit)d UDP direcci#n IP origen Lig)ra 1.@H Pse)do


26/31

cabecera UDP direcciones IP del origen del destino el n)Fmero de protocolo la longit)d del datagrama UDP sin incl)ir la longit)d de la misma pse)docabecera. 'l n)me F ro asignado al protocolo UDP es ,E11 es )sado tanto enla pse)do cabecera UDP como en la cabecera IP. 'n este trabao el protocoloUDP se )sa )nto con las eEtensiones m)ltidif)siFon para transmitir los datosde las lect)ras de los sensores inalFambricos a travFes de internet. "Fease elcapFJt)lo &. 1.@. Protocolo TCP 'l Transmission Control Protocol TCP! es )nprotocolo orientado a coneEiFon con- 6able de eEtremo a eEtremo disenMadopara encaar en )na erar()FJa de protocolos ()e soporten m)lt F iplesaplicaciones de red. Provee )na com)nicaciFon con6able entre procesos dean6triones en redes distintas pero interconectadas entre sFJ. TCP as)me m)poco sobre la con6abilidad de los protocolos de niveles inferiores. De 5ec5ocon obtener )n datagrama de las capas inferiores es s)6ciente. TCP es capaGde transferir )n N)o contin)o de btes en cada direcciFon entre s)s )s)ariosempa()etando el N)o en segmentos de )n tamanoM apropiado para s)transmisiFon. 'l tamanoM de los segmentos estFa limitado por la )nidad mFaEima de transmisiFon de la capa de acceso a la red ()e en el caso de

et5ernet es de 1&,, btes. Kos pa()etes res)ltantes se pasan al protocolo IPpara s) entrega a travFes de internet. Para aseg)rar ()e los pa()etes no sepierdan en el camino evitar ()e lleg)en en desorden TCP le asigna a cadapa()ete )n n)Fmero de sec)encia. 'l receptor p)ede con este n)mero Freacomodar los segmentos reconstr)ir el N)o. 'n )n momento dado elreceptor tendrFa cero o mFas btes reconstr)idos desde el inicio del N)o. Porlos btes bien recibidos el receptor envFJa )n ac)se de recibo especi6cando eln)me F ro de sec)encia del sig)iente bte ()e espera recibir. Cada veG ()e seenvFJa )n segmento el TCP inicia )n temporiGador espera )n ac)se de recibo.%i se termina el tiempo antes de ()e se ac)sen de recibidos los datos delsegmento el TCP as)me ()e el segmento se perdiFo o se corrompiFo lo

retransmite. 'l TCP provee al receptor de )na forma de gobernar la cantidad dedatos ()e envFJa el emisor. 'sto lo 5ace mediante el )so de la ventanadesliGable. %)pFongase ()e )n an6triFon tiene lista )na sec)encia de pa()etespara transmitir ()e el receptor de los mismo le 5a an)nciado )na ventana de8 pa()etes. 'sto signi6ca ()e el an6triFon enviarFa 5asta 8 pa()etes esperara )n ac)se de recibo por todos. Ka ventana indica la cantidad aceptablede btes ()e el emisor p)ede transmitir sin esperar )n ac)se de recibo. 'steconcepto 5ace ()e la transmisiFon de N)o sea e6ciente. %i TCP )tiliGase )nes()ema simple de ac)se de recibo positivo )na ventana de 1 pa()ete!oc)parFJa )n gran anc5o de banda de red debido a ()e retrasarFJa el envFJo de)n n)evo pa()ete 5asta ()e reciba )n ac)se del pa()ete anterior. 18 CapFJt)lo

1H Introd)ccionF a TCP9IP protocolo , cero 1& 10 31 longit)d TCP direcci#n IPdestino direcci#n IP origen Lig)ra 1.1,H Pse)do cabecera TCP Kos ac)ses derecibo ACOs no se generan inmediatamente desp)Fes de recibir )n segmentodebido al algoritmo de los ACOs retrasados. 'ste algoritmo retarda el envFJodel ACO d)rante )n tiempo alrededor de 3,, ms1. 'ste retraso a)n()e aprimera vista pareGca )n tope mFaEimo de la velocidad de transferencia es enrealidad )na optimiGaciFon ()e permite red)cir el trFa6co meorar eldesempenMo. Por eemplo si d)rante la espera se reciben n)evos datos con )n


27/31


28/31

'l n)Fmero de palabras de 32 bits de la cabecera. Indica en donde comienGanlos datos. Ka longit)d de la cabecera TCP a)nF con opciones incl)idas siemprees )n m)Fltiplo de 32 bits. eservado 0 bits!. eservado para )so f)t)ro. Debevaler cero. anderas 0 bits!. C)ando estas banderas estFan veri6cadas s)signi6cado es el sig)ienteH USH el campo del p)ntero )rgente tienesigni6cado. ACOH el campo del ac)se de recibo tiene signi6cado. P%;H 'fect)arla f)nciFon p)s5. %TH ea)star la coneEiFon. %Q4H %incroniGar los n)me F rosde sec)encia. LI4H 'l emisor no enviarFa mFas datos. "entana 10 bits!. 'ln)me F ro de btes de datos comenGado con el segmento indicado en elcampo de ac)se ()e el emisor de este segmento p)ede aceptar. C5ec$s)m10 bits!. Ka s)ma de veri6caciFon del segmento TCP. P)ntero )rgente 10 bits!.'ste campo indica el valor act)al del p)ntero )rgente como )n o:set positivodesde el n)mero F de sec)encia en este segmento. 'l p)ntero senala M al n)Fmero de sec)encia del sig)iente bte de los datos )rgentes. pcioneslongit)d variable!. Kas opciones p)eden oc)par espacio al 6nal de la cabecera

TCP s) longit)d es )n m)lti F plo de 8 bits. Todas las opciones se incl)en alcalc)lar la s)ma de veri6caciFon. Lig)ra 1.11H Lormato de la cabecera TCP 2,

CapFJt)lo 1H Introd)ccionF a TCP9IP 'l algoritmo de la s)ma de veri6caciFon esel mismo ()e para la cabecera IP. %e calc)la )tiliGando el valor ,E,,,, en elcampo de c5ec$s)m comenGando en la pse)do cabecera 5asta el )Fltimobte de datos. 'n la cabecera se aprecia )n campo de opciones. 'l TCP de6nevarios parFametros opcionales ()e se p)eden incl)ir en la cabecera si laaplicaciFon re()iere 5acer )so de ellas. Una de las opciones mFas importantees el tamanoM mFaEimo de segmento B%% la c)Fal oc)pa 10 bits. %i esta opciFon estFa presente indica el tamanoM mFaEimo de segmento ()e p)ede recibirel emisor del mismo. 'ste campo solo se envFJa al establecer la coneEiFon. %ino estFa presente entonces se as)me ()e el B%% es &30 btes. Linalmentecabe mencionar ()e el n)me F ro de protocolo ()e se )sa en la cabecera IP

para encaps)lar al protocolo TCP es ,E,0. [email protected]. 'tapas de )na coneEionF TCP'n tFerminos generales )na coneEiFon TCP atraviesa por tres etapasHestablecimiento de la coneEiFon transferencia de datos cierre de la coneEiFon. 'stablecimiento de la coneEionF Para establecer )na coneEiFon el TCP)tiliGa )n sal)do de 3 etapas 3-+a 5ands5a$e!. 'l procedimiento es iniciadonormalmente por )n p)nto eEtremo contestado por otro. 'l caso mFassencillo se m)estra en la 6g)ra 1.12. 'stablecido ecepci#n de %Q4 'stablecido'nvo de %Q4 'stablecido 'stablecido A Lig)ra 1.12H %al)do bFasico de 3etapas de TCP 'l primer segmento del sal)do se identi6ca por()e estFaveri6cada la bandera %Q4. 'l seg)ndo mensae tiene veri6cados las banderas%Q4 ACO indicando el ac)se del primer segmento como el 5ec5o de ()e se

contin)aF con el sal)do. 'l )Fltimo segmento del sal)do es solo )n ac)se derecibo se )sa para indicar ()e ambos eEtremos estFan de ac)erdo enestablecer la coneEiFon. 'l sal)do realiGa dos f)nciones importantesH garantiGa()e ambos lados estFen listos para transferir datos permite a las partesacordar el I%4. Cada eEtremo selecciona )n I%4 aleatorio. 'n la 6g)ra 1.12 eleEtremo A escogiFo el I%4*1,, mientras ()e escogiFo I%4*3,,. 'l I%4 nop)ede comenGar siempre con el mismo valor en el doc)mento LC1122 /8 ses)giere escoger el I%4 basado en la lect)ra del relo de la mFa()ina. AdemFas


29/31

de ponerse de ac)erdo en el I%4 ambos eEtremos an)ncian s) B%%. 1.@Protocolo TCP 21 Transferencia de datos Una veG ()e la coneEiFon estFaestablecida la com)nicaciFon se da por el intercambio de segmentos. Dado()e los segmentos se p)eden perder por errores en la transmisiFon o congestiFon de la red el TCP 5ace retransmisiones desp)Fes de )n tiempo f)era! paraaseg)rar la entrega de cada segmento. Cada entidad mantiene )n registro conlos n)Fmeros de sec)encia ()e debe )sar otro con los n)Fmeros desec)encia ()e espera recibir. 'l cierre de la coneEiFon implica )na f)nciFonp)s5 la llegada de )n segmento con la bandera LI4 veri6cada. Cierre de laconeEionF 'n esta fase se )sa )n sal)do de > etapas >-+a 5ands5a$e! concada lado terminando independientemente. C)ando )n eEtremo deseaterminar la coneEiFon envFJa )n pa()ete con la bandera LI4 veri6cada ()e elotro eEtremo ac)sa de recibido enviando )n segmento ACO. closed A 6n+ait2 6n+ait1 time+ait lastac$ close+ait closed 2B%K Lig)ra1.13H Cierre de coneEiFon bFasico de > etapas de TCP Por lo tanto )n cierre tFJpico re()iere )n par de segmentos LI4 ACO desde cada eEtremo como enla 6g)ra 1.13. Una coneEiFon p)ede estar Vmedio abiertaV este es el caso en

()e )n eEtremo 5a cerrado pero el otro no. 'l lado ()e 5a terminado no p)edeenviar mFas datos por la coneEiFon mientras ()e el otro si p)ede. Cabemencionar ()e las banderas %Q4 LI4 oc)pan )n l)gar en el espacio de n)Fmero de sec)encia. C)ando estas banderas se transmiten el n)me F ro desec)encia del emisor se incrementa en 1. [email protected]. Ba()ina F de estados TCP KaoperaciFon de TCP se p)ede eEplicar meor mediante el )so de )na mFa()inade estados. Ka 6g)ra 1.1> m)estra la mFa()ina de estados TCP donde losestados se m)estran como )n c)adrado redondeado las transiciones comoNec5as entre los estados. 22 CapFJt)lo 1H Introd)ccionF a TCP9IP TCP9IP %tate

Transition Diagram LC?@3! Sordon BcOinne 1, Leb 2,,>! A connectionprogresses t5ro)g5 a series of states d)ring its lifetime listed belo+!. CK%'D

is 6ctional beca)se it represents t5e state +5en t5ere is no TC and t5ereforeno connection. rieN t5e meanings of t5e states areH KI%T'4 represents+aiting for a connection re()est from an remote TCP and port. %Q4-%'4Trepresents +aiting for a matc5ing connection re()est after 5aving sent aconnection re()est. %Q4-'C'I"'D represents +aiting for a con6rmingconnection re()est ac$no+ledgment after 5aving bot5 received and sent aconnection re()est. '%TAKI%;'D represents an open connection datareceived can be delivered to t5e )ser. T5e normal state for t5e data transferp5ase of t5e connection. LI4-WAIT-1 represents +aiting for a connectiontermination re()est from t5e remote TCP or an ac$no+ledgment of t5econnection termination re()est previo)sl sent. LI4-WAIT-2 represents +aiting

for a connection termination re()est from t5e remote TCP. CK%'-WAITrepresents +aiting for a connection termination re()est from t5e local )ser.CK%I4S represents +aiting for a connection termination re()estac$no+ledgment from t5e remote TCP. KA%T-ACO represents +aiting for anac$no+ledgment of t5e connection termination re()est previo)sl sent to t5eremote TCP +5ic5 incl)des an ac$no+ledgment of its connection terminationre()est!. TIB'-WAIT represents +aiting for eno)g5 time to pass to be s)re t5eremote TCP received t5e ac$no+ledgment of its connection termination


30/31

re()est. CK%'D represents no connection state at all. A TCP connectionprogresses from one state to anot5er in response to events. T5e events are t5e)ser calls P'4 %'4D 'C'I"' CK%' AT and %TATU% t5e incomingsegments partic)larl t5ose containing t5e %Q4 ACO %T and LI4 Nags andtimeo)ts. CK%'D KI%T'4 %Q4XC"D %Q4X%'4T '%TAKI%;'D LI4XWAITX1CK%'XWAIT LI4XWAITX2 CK%I4S TIB'XWAIT KA%TXACO data transfer statestarting point 2B%K timeo)t passive open active open sim)ltaneo)s close applHpassive open sendH applH sendH %Q4 active open applH sendH %Q4 send datarecvH %Q4 sendH %Q4 ACO recvH %T timeo)t sendH %T recvH %Q4 sendH %Q4ACO sim)ltaneo)s open recvH %Q4 ACO sendH ACO applH close sendH LI4 recvHACO sendH recvH LI4 sendH ACO recvH ACO sendH recvH LI4 ACO sendH ACO recvHACO sendH applH close sendH LI4 recvH LI4 sendH ACO recvH LI4 sendH ACO applHclose sendH LI4 applH close or timeo)t recvH ACO sendH active close passiveclose normal transitions for client normal transitions for server applH statetransitions ta$en +5en application iss)es operation recvH state transitions ta$en+5en segment received sendH +5at is sent for t5is transition TCP statetransition diagram. eprinted from TCP9IP Ill)strated "ol)me 2H T5e

Implementation b Sar . Wrig5t and W. ic5ard %tevens Coprig5t Y 1@@&b Addison-Wesle P)blis5ing Compan Inc. Lig)ra 1.1>H Diagrama de estadosde TCP Una coneEiFon atraviesa por varios de los estados mostrados en la6g)ra 1.1> Festos se describen a contin)aciFonH KI%T'4 epresenta la esperade )na solicit)d coneEiFon desde otro p)nto eEtremo. %Q4-%'4T epresentaesperar por )na coneEiFon desp)Fes de 5aber enviado la solicit)d de coneEiFon. %Q4-'C'I"'D epresenta esperar el ac)se de la con6rmaciFon de coneEiFon desp)Fes de 5aber recibido enviado la peticiFon de coneEiFon. 1.1,'t5ernet 23 '%TAKI%;'D epresenta )na coneEiFon abierta los datos sep)eden entregar al )s)ario. 'l estado normal para realiGar coneEiones. LI4-WAIT-1 epresenta la espera de la solicit)d de cierre de coneEiFon del otro

p)nto eEtremo o el ac)se de la peticiFon de cierre enviada con anterioridad.LI4-WAIT-2 epresenta la espera por )na solicit)d de cierre del otro p)ntoeEtremo. CK%'-WAIT epresenta la espera por )na solicit)d de cierre de)s)ario local. CK%I4S epresenta la espera el ac)se de la solicit)d de cierredel otro p)nto eEtremo. KA%T-ACO epresenta la espera el ac)se de la solicit)dde cierre enviada al otro p)nto eEtremo. TIB'-WAIT epresenta la espera de )ntiempo s)6ciente para aseg)rar ()e el otro p)nto eEtremo 5aa recibido elac)se de la solicit)d de cierre. CK%'D epresenta )n estado en el ()e no 5aconeEiFon. 1.1,. 't5ernet 'n la capa de acceso a la red se enc)entra 't5ernet.'t5ernet I''' 8,2.3! es )na especi6caciFon de cableado senMaliGaciFon pararedes de Farea local. Kos nodos de la red se conectan entre sFJ )tiliGando )na

topologFJa en estrella o en b)s. Kas velocidades de transmisiFon estFandarespara et5ernet son 1, Bbps 1,, Bbps 1 Sbps. 'n )na red et5ernet )n nodose com)nica con otros enviando pa()etes estos pa()etes llegan a todos losnodos de la red. 'n cada pa()ete se especi6ca el nodo destino )tiliGando )nadirecciFon solo el nodo ()e tiene la direcciFon indicada procesarFa elpa()ete. Cada dispositivo conectado a )na red et5ernet se identi6ca con )nadirecciFon de 0 btes llamada direcciFon et5ernet. Ka direcciFon et5ernet tambiFen se conoce como direcciFon BAC Bedia Access Control!. Ka direcciFon estFa


31/31

asignada por el fabricante del dispositivo a s) veG el rango de direccionesasignado a los fabricantes es controlado por la I'''. C)ando )na direcciFonet5ernet contiene todos s)s bits en 1 se conoce como direcciFon broadcast. Unpa()ete ()e tenga como destino la direcciFon broadcast serFa procesado portodos los nodos de la red. 'n )na red et5ernet solo )n nodo transmite a la veG.%i dos nodos transmiten al mismo tiempo se provoca )na colisiFon en donde lospa()etes se pierden. 't5ernet )tiliGa el mecanismo de control Carrier %enseB)ltiple Access +it5 Collision Detection C%BA9CD! para detectar colisiones rec)perarse de las mismas. C)ando se detecta )na colisiFon se llevan a cabolos sig)ientes pasosH 1. 'l nodo esc)c5a el canal antes de transmitir paradeterminar si otro nodo estFa transmitiendo. 2. C)ando el nodo determina ()eel canal estFa libre comienGa a transmitir el pa()ete. %i dos nodos detectan elcanal libre al mismo tiempo se provocarFa )na colisiFon. 3. Bientras el nodo estFa transmitiendo el pa()ete tambiFen estFa esc)c5ando si se prod)ce )nacolisiFon. 2> CapFJt)lo 1H Introd)ccionF a TCP9IP >. %i se deteca )na colisiFon losnodos invol)crados dean de transmitir. &. Kos nodos reintetarFan la transmisiFon desp)Fes de )n tiempo de espera logarFJtmico. 'ste proceso se repite

5asta ()e se logra transmitir el pa()ete en )n mFaEimo de 10 intentos aldiecisieteavo intento se descarta el pa()ete. 'Eisten dos tipos de formatos depa()etes et5ernetH 't5ernet II I''' 8,2.3. 'stos se m)estran en las 6g)ras1.1& 1.10 respectivamente. Para identi6car el tipo de pa()ete )tiliGado en)na red se lee la palabra formada por los btes 13 1>. %i Festa es menor ()e1&,, el formato es 8,2.3 si es maor es 't5ernet II. btesH 0 0 2 >01&,, >BAC destino BAC origen tipo datos CC Lig)ra 1.1&H Lormato de pa()ete't5ernet II btesH BAC destino BAC origen datos CC control origen %APdestino %AP longit)d 0 0 2 1 1 1 >31>@? > Lig)ra 1.10H Lormato de pa()eteI''' 8,2.3 'n este trabao se )tiliGFo el formato 't5ernet II por ser el mFas)tiliGado. Partiendo de este formato el tamanoM mFJnimo de )n pa()ete es 0>

btes en Feste se p)eden transferir >8 btes de datos. %i se re()iere transferirmenos de >8 btes se agregan btes de relleno 5asta lograr >8. Por otra parteel tamanoM mFaEimo de )n pa()ete 't5ernet II es de 1&18 btes lo ()epermite 5asta 1&,, btes de datos. Linalmente la )nidad mFaEima detransmisiFon BTU! es el n)Fmero mFaEimo de datos ()e se p)eden transmitiren )n solo pa()ete es de 1&,, btes para )na red et5ernet. Cabe mencionar()e al generar )n pa()ete et5ernet la cola del mismo el CC! es generadapor el 5ard+are controlador de et5ernet no por el soft+are del sistema de cFomp)to ()e genera el pa()ete

3 Analisis Comparativo TCP

Documents

Transcript of 3 Analisis Comparativo TCP