Trabajo Práctico N° 3

Establecimiento: Instituto de Educación Superior “Juan José

Jeuzel”.

Carrera: Técnico Superior en Soporte de Infraestructura de Tecnología

de la Información.

Materia: Redes Informáticas

Tema: Protocolos

Integrantes:
 TOLEDO, Camila Aldana.
 TOLEDO, Carla Alejandra.
 TOLEDO, Carolina Andrea.

Profesor: SUAREZ, David Hernán.

Año: 2018.
 Trabajo Práctico Nº 3 de Redes Informáticas: Protocolos

Consignas:
1) Del libro “Redes de computadoras Tanenbaum 4ta edición” investigue los
siguientes protocolos:
HTTP (Protocolo de Transferencia de Hipertexto ): Es un protocolo de
aplicación de amplio uso que es la base de World Wide Web. Cuando un
navegador desea una página Web, utiliza este protocolo para enviar al servidor el
nombre de dicha página, y el servidor devuelve la página. Otros protocolos de
aplicación se utilizan para la transferencia de archivos, correo electrónico y noticias
en la red.

El protocolo http es el lenguaje nativo de Web, el que hablan los servidores Web,
especifica cuáles mensajes pueden enviar los clientes a los servidores y qué respuestas
obtienen. Cada interacción consiste en una solicitud ASCII, seguida por una respuesta.
Todos los clientes y servidores deben obedecer este protocolo.

HTTP es un protocolo ASCII, es muy fácil que una persona en una terminal (a diferencia de
un navegador) hable de manera directa con los servidores Web. Todo lo que se necesita es
una conexión TCP con el puerto 80 del servidor.

Conexiones: La forma común en que un navegador contacta a un servidor es

estableciendo una conexión TCP con el puerto 80 de la máquina del servidor. El valor de
utilizar TCP es que ni los navegadores ni los servidores tienen que preocuparse por los
mensajes largos, perdidos o duplicados, ni por las confirmaciones de recepción. En la
implementación de TCP se manejan todos estos aspectos.

En HTTP 1.0, una vez que se establecía la conexión, se enviaba una solicitud y se obtenía
una respuesta.

Luego se diseñó HTTP 1.1, que soporta conexiones persistentes. Con ellas, es posible
establecer una conexión TCP, enviar una solicitud y obtener una respuesta, y después
enviar solicitudes adicionales y obtener respuestas adicionales.

Versiones:

 HTTP/1.0 
 HTTP/1.1
 HTTP/1.2
 HTTP/2 
Métodos:

 GET: Solicita la lectura de una página Web

 HEAD: Solicita la lectura del encabezado de una página Web
 PUT: Solicita el almacenamiento de una página Web
 POST: Inserta algo a un recurso con nombre (por ejemplo, una página Web)
 DELETE: Elimina la página Web
 TRACE: Repite la solicitud entrante
 CONNECT: Reservado para uso futuro
 OPTIONS: Consulta ciertas opciones

Encabezados de mensaje: A la línea de solicitud le pueden seguir líneas adicionales

que contienen más información. Éstas se llaman encabezados de solicitud. Esta
información puede compararse con los parámetros de una llamada a procedimiento. Las
respuestas también pueden tener encabezados de respuesta.

Algunos encabezados de mensaje son:

 User-Agent: Solicitud: Información acerca del navegador y su plataforma

 Accept: Solicitud: El tipo de páginas que el cliente puede manejar
 Accept-Charset: Solicitud: Los conjuntos de caracteres que son aceptables para el
cliente
 Accept-Encoding: Solicitud: Las codificaciones de página que el cliente puede
manejar
 Accept-Language: Solicitud: Los idiomas naturales que el cliente puede manejar
 Host: Solicitud: El nombre DNS del servidor
 Authorization: Solicitud: Una lista de las credenciales del cliente
 Cookie: Solicitud: Regresa al servidor una cookie establecida previamente
 Date: Ambas: Fecha y hora en que se envió el mensaje
 Upgrade: Ambas: El protocolo al que el emisor desea cambiar
 Server: Respuesta: Información acerca del servidor
 Content-Encoding: Respuesta: Cómo se codifica el contenido
 Content-Language: Respuesta: El idioma natural utilizado en la página
 Content-Length: Respuesta: La longitud de la página en bytes
 Content-Type: Respuesta: El tipo MIME de la página
 Last-Modified: Respuesta: La fecha y hora de la última vez que cambió la página
 Location: Respuesta: Un comando para que el cliente envíe su solicitud a cualquier
otro lugar
 Accept-Ranges: Respuesta: El servidor aceptará solicitudes de rango de bytes
  Set-Cookie Respuesta El servidor desea que el cliente guarde una cookie

IP (ipv4): IPv4 es la cuarta versión de  Internet Protocol (IP), pero la primera que

ha sido implementada de forma extensiva. Fue descrito en el RFC 791 elaborado
por la Internet Engineering Task Force (IETF) en 1981. Es el protocolo que
mayormente se usa en la Capa de Red del Modelo TCP/IP para conexiones a
Internet.
Funcionamiento básico de IPv4: IPv4 es un protocolo para ser usado en las redes de
conmutación de paquetes. Funciona empleando un modelo de entrega de mejor esfuerzo,
ya que no garantiza la entrega, ni garantiza la secuenciación ni evita entrega por
duplicado. Estos aspectos, incluyendo la integridad de datos, son abordados por un
protocolo de transporte en la capa superior, tales como el Protocolo de Control de
Transmisión(TCP).
Fragmentación y re ensamblado de paquetes: El protocolo IP permite a las redes
comunicarse entre sí. El diseño permite redes de diversa naturaleza física: es
independiente de la tecnología de transmisión física empleada en la capa de enlace. Las
redes con diferentes hardware usualmente varían en la velocidad de transmisión y en el
tamaño MTU (unidad máxima de transmisión).

Cuando una red quiere transmitir datagramas hacia una red con un MTU menor, esta
fragmentará sus datagramas. En IPv4, esta función se lleva a cabo en la capa de Internet y
es realizada en los routers IPv4, por esto sólo requiere que esta capa sea la más alta en ser
implementada en su diseño.

Por otro lado, en las IPv6, no se les permite a los routers realizar fragmentación. Los hosts
deben determinar el camino MTU antes del envío de datagramas.

Fragmentación: Cuando un router recibe un paquete, este examina la dirección de

destino y determina la interfaz de salida a usar y la interfaz del MTU. Si el tamaño del
paquete es mayor que el MTU y el bit Do not Fragment (DF o No fragmentar) en la
cabecera del paquete está en 0, entonces el router puede fragmentar el paquete.

El router divide el paquete en fragmentos. El máximo tamaño de cada paquete es MTU

menos el tamaño de cabecera IP (20 bytes mínimo; 60 bytes máximo).

Re ensamblado: Un receptor sabe que un paquete es un fragmento si se cumple al

menos de una de estas condiciones:

- La bandera "más fragmentos" está activada (esto es verdadero para todos los
fragmentos con excepción del último).
- El campo "fragment offset" (desplazamiento de fragmento) es distinto de cero (esto es
verdadero para todos los fragmentos excepto el primero).

El receptor identifica los fragmentos que se emparejan usando dirección de internet local
y foránea, y el campo de identificación. El receptor re ensamblará los datos desde
fragmentos con el mismo ID usando el desplazamiento de fragmento y las banderas de
más fragmentos. Cuando el receptor recibe el último fragmento (que tiene la bandera
"más fragmentos" en cero), puede calcular la longitud de los datos originales,
multiplicando el último desplazamiento de fragmento por 8 y agregando el tamaño de
datos del último fragmento.

Cuando el receptor tiene todos los fragmentos, podrá ubicarlos en el orden correcto
empleando sus offsets (desplazamientos). Podrá pasar los datos a la pila que luego para
futuro procesamiento.
Características:

 Es un protocolo de un servicio de datagramas no fiable.

 La garantía en la entrega de datos es nula.
 La garantía sobre la corrección de los datos es nula.
 Puede resultar en paquetes duplicado o en desorden.

Todo esto se resuelve en un nivel superior del modelo TCP/IP.

Propósito general: Proveer una dirección única a cada sistema para que cuando una
computadora o equipo con la posibilidad de manejar IP’S pueda identificar a otro.

Otro equipo porque no solo las computadoras tienen la capacidad para ser configuradas
con una dirección IP, también pueden ser configuradas una impresora de red, un servidor,
un teléfono IP, etc.

Direcciones: IPv4 usa direcciones de 32 bits (4 bytes) lo que equivale a 4,294,967,295

direcciones. Pero no todas son para uso doméstico, muchas están reservadas para redes
privadas, multicast, etc. Como bien sabemos, el uso de Internet se ha masificado tanto
que se ha tenido que desarrollar una nueva versión del protocolo, IPv6.

IP (ipv6): En 1990 la IETF comenzó a trabajar, en una versión nueva del IP, una
que nunca se quedaría sin direcciones, resolvería varios otros problemas y sería
más flexible y eficiente también. Sus metas principales eran:

1. Manejar miles de millones de hosts, aún con asignación de espacio de direcciones

ineficiente.
 2. Reducir el tamaño de las tablas de enrutamiento.

3. Simplificar el protocolo, para permitir a los enrutadores el procesamiento más

rápido de los paquetes.

4. Proporcionar mayor seguridad (verificación de autenticidad y confidencialidad) que

el IP actual.

5. Prestar mayor atención al tipo de servicio, especialmente con datos en tiempo real.

6. Ayudar a la multidifusión permitiendo la especificación de alcances.

7. Posibilitar que un host sea móvil sin cambiar su dirección.

8. Permitir que el protocolo evolucione.

9. Permitir que el protocolo viejo y el nuevo coexistan por años.

Es una versión del protocolo IP destinada a sustituir al protocolo IPv4. El porqué de este
cambio viene dado la limitación de direcciones de IPv4 frente al elevado número de
equipos conectados a la red.

Es compatible con todos los demás protocolos Internet, incluidos TCP, UDP, ICMP, IGMP,
OSPF, BGP y DNS, a veces con algunas pequeñas modificaciones (maneja direcciones más
grandes). El IPv6 tiene direcciones más grandes que el IPv4; son de 16 bytes de longitud, lo
que proporciona una cantidad prácticamente ilimitada de direcciones Internet.

del IPv6 es la simplificación del encabezado, que contiene sólo 7 campos (contra 13 en el
IPv4). Este cambio permite a los enrutadores procesar con mayor rapidez los paquetes y
mejorar, por tanto, la velocidad real de transporte. La tercera mejora importante fue el
mejor apoyo de las opciones. Este cambio fue esencial con el nuevo encabezado, pues
campos que antes eran obligatorios ahora son opcionales. Además, es diferente la manera
de representar las opciones, haciendo más sencillo que los enrutadores hagan caso omiso
de opciones no dirigidas a ellos. Esta característica mejora el tiempo de procesamiento de
los paquetes. Una cuarta área en la que el IPv6 representa un avance importante es la
seguridad. La IETF tenía infinidad de historias sobre preadolescentes precoces que usaban
sus computadoras personales para meterse en bancos e instalaciones militares por todas
partes de Internet. Se tenía la fuerte sensación de que había que hacerse algo para
mejorar la seguridad. La autenticación y la privacidad son características clave del IP
nuevo. Estas características fueron incluidas posteriormente en el IPv4, así que las
diferencias no son tan marcadas en el área de la seguridad. Por último, se ha puesto
mayor atención en la calidad del servicio. En el pasado se realizaron varios esfuerzos
débiles, pero con el crecimiento actual de la multimedia en Internet, se requiere un mayor
esfuerzo.

El encabezado principal del IPv6: Dentro del encabezado principal podemos

encontrar a:

 El campo de Versión
 El campo Clase de tráfico
 El campo de Etiqueta de flujo
 El campo de Longitud de carga útil
 El campo Encabezado siguiente
 El campo de Límite de saltos.
 los campos de Dirección de origen y Dirección de destino.

Encabezados de extensión: el IPv6 introdujo el concepto de encabezado de extensión

(opcional). Estos encabezados pueden usarse para proporcionar información extra, pero
codificada de una manera eficiente. Hay seis tipos de encabezados de extensión definidos
actualmente, los mismos son:

 Opciones salto por salto: Información diversa para los enrutadores

 Opciones de destino: Información adicional para el destino
 Enrutamiento: Ruta total o parcial a seguir
 Fragmentación: Manejo de fragmentos de datagramas
 Autenticación: Verificación de la identidad del emisor
 Carga útil de seguridad encriptada: Información sobre el contenido encriptado

Todos los encabezados son opcionales, pero si hay más de uno, deben aparecer justo
después del encabezado fijo, y de preferencia en el orden listado. Algunos de los
encabezados tienen un formato fijo; otros contienen un número variable de campos de
longitud variable.

TCP (Protocolo de Control de Transmisión): Es uno de los protocolos

fundamentales en Internet. Fue creado entre los años 1973 y 1974 por Vint Cerf y
Robert Kahn. Es un protocolo confiable, orientado a la conexión, que permite que
un flujo de bytes que se origina en una máquina se entregue sin errores en
cualquier otra máquina en la interred. Divide el flujo de bytes entrantes en
mensajes discretos y pasa cada uno de ellos a la capa de interred. En el destino, el
proceso TCP receptor reensambla en el flujo de salida los mensajes recibidos. TCP
también maneja el control de flujo para asegurarse de que un emisor rápido no
sature a un receptor lento con más mensajes de los que puede manejar.
TCP se definió formalmente en el RFC 793. Conforme el tiempo, se detectaron varios
errores e inconsistencias. En el RFC 1122 se detallan estas especificaciones y algunos
arreglos de errores. En el RFC 1323 se dan algunas extensiones.

Cada máquina que soporta TCP tiene una entidad de transporte TCP, ya sea un
procedimiento de biblioteca, un proceso de usuario o parte del kernel. En todos los casos,
maneja flujos TCP e interactúa con la capa IP. Una entidad TCP acepta flujos de datos de
usuario de procesos locales, los divide en fragmentos que no excedan los 64 KB y envía
cada fragmento como un datagrama IP independiente.

La capa IP no proporciona ninguna garantía de que los datagramas se entregarán de

manera apropiada, por lo que corresponde a TCP terminar los temporizadores y
retransmitir los datagramas conforme sea necesario.

El modelo del servicio TCP:

El servicio TCP se obtiene al hacer que tanto el servidor como el cliente creen puntos
terminales, llamados sockets, como se mencionó en la sección 6.1.3. Cada socket tiene un
número (dirección), que consiste en la dirección IP del host, y un número de 16 bits, que
es local a ese host, llamado puerto. Un puerto es el nombre TCP para un TSAP. Para
obtener el servicio TCP, se debe establecer de manera explícita una conexión entre un
socket en la máquina emisora y uno en la máquina receptora.

Un socket puede utilizarse para múltiples conexiones al mismo tiempo. En otras palabras,
dos o más conexiones pueden terminar en el mismo socket.

Los números de puerto menores que 1024 se llaman puertos bien conocidos y se reservan
para servicios estándar. Por ejemplo, cualquier proceso que desee establecer una
conexión a un host para transferir un archivo utilizando FTP puede conectarse con el
puerto 21 del host de destino para conectar su demonio (daemon) FTP. La lista de puertos
bien conocidos se proporciona en www.iana.org.

Ciertamente podría ser posible que el demonio FTP se conecte a sí mismo al puerto 21 en
tiempo de arranque, que el demonio telnet se conecte a sí mismo al puerto 23 en tiempo
de arranque, y así sucesivamente. Hacer lo anterior podría llenar la memoria con
demonios que están inactivos la mayor parte del tiempo. En su lugar, lo que se hace es
que un solo demonio, llamado inetd (demonio de Internet) en UNIX, se conecte a sí mismo
a múltiples puertos y esperar la primera conexión entrante. Cuando eso ocurre, inetd
bifurca un nuevo proceso y ejecuta el demonio apropiado en él, dejando que ese demonio
maneje la solicitud. De esta forma, los demonios distintos a inetd sólo están activos
cuando hay trabajo para ellos. Inetd consulta un archivo de configuración para saber cuál
puerto utilizar.

Todas las conexiones TCP son de dúplex total y de punto a punto. Dúplex total significa
que el tráfico puede ir en ambas direcciones al mismo tiempo. Punto a punto significa que
cada conexión tiene exactamente dos puntos finales.

Una última característica del servicio TCP que vale la pena mencionar son los datos
urgentes. Cuando un usuario interactivo oprime las teclas Supr o Ctrl+C para interrumpir
una operación remota que ha iniciado, la aplicación emisora coloca información de control
en el flujo de datos y se la da a TCP junto con el indicador URGENT. Este evento ocasiona
que TCP interrumpa el encolamiento de datos y transmita inmediatamente todo lo que
tenga para esa conexión

El protocolo TCP: Una característica clave de TCP, y una que domina el diseño del
protocolo, es que cada byte de una conexión TCP tiene su propio número de secuencia de
32 bits. Cuando Internet comenzó, las líneas entre los enrutadores eran principalmente
líneas alquiladas de 56 kbps, por lo que un host que mandaba datos a toda velocidad
tardaba una semana en recorrer los números de secuencia.

La entidad TCP emisora y la receptora intercambian datos en forma de segmentos. Un

segmento consiste en un encabezado TCP fijo de 20 bytes seguido de cero o más bytes de
datos. El software de TCP decide el tamaño de los segmentos; puede acumular datos de
varias escrituras para formar un segmento, o dividir los datos de una escritura en varios
segmentos. Hay dos límites que restringen el tamaño de segmento. Primero, cada
segmento, incluido el encabezado TCP, debe caber en la carga útil de 65,515 bytes del IP.
Segundo, cada red tiene una unidad máxima de transferencia (MTU) y cada segmento
debe caber en la MTU. En la práctica, la MTU es, generalmente, de 1500 bytes (el tamaño
de la carga útil en Ethernet) y, por tanto, define el límite superior del tamaño de
segmento.

El protocolo básico usado por las entidades TCP es el protocolo de ventana corrediza.
Cuando un transmisor envía un segmento, también inicia un temporizador. Cuando llega
el segmento al destino, la entidad TCP receptora devuelve un segmento que contiene un
número de confirmación de recepción igual al siguiente número de secuencia que espera
recibir. Si el temporizador del emisor expira antes de la recepción de la confirmación, el
emisor envía de nuevo el segmento.

El encabezado del segmento TCP: Cada segmento comienza con un encabezado de

formato fijo de 20 bytes. El encabezado fijo puede ir seguido de opciones de encabezado.
Tras las opciones, si las hay, pueden continuar hasta 65,535 − 20 − 20 = 65,495 bytes de
datos, donde los primeros 20 se refieren al encabezado IP y los segundos al encabezado
TCP. Los segmentos sin datos son legales y se usan por lo común para confirmaciones de
recepción y mensajes de control.

Establecimiento de una conexión TCP: TCP utiliza segmentos para determinar si el

sistema de recepción está listo para recibir los datos. Cuando el protocolo TCP de envío
desea establecer conexiones, envía un segmento denominado SYN al protocolo TCP del
host de recepción. El protocolo TCP de recepción devuelve un segmento
denominado ACK para confirmar que el segmento se ha recibido correctamente. El
protocolo TCP de envío emite otro segmento ACK y luego procede al envío de los datos.
Este intercambio de información de control se denomina protocolo de tres vías.
Liberación de una conexión TCP: Aunque las conexiones TCP son dúplex total, para
entender la manera en que se liberan las conexiones es mejor visualizarlas como un par de
conexiones símplex. Cada conexión símplex se libera independientemente de su igual.
Para liberar una conexión, cualquiera de las partes puede enviar un segmento TCP con el
bit FIN establecido, lo que significa que no tiene más datos por transmitir. Al confirmarse
la recepción del FIN, ese sentido se apaga. Sin embargo, puede continuar un flujo de datos
indefinido en el otro sentido. Cuando ambos sentidos se han apagado, se libera la
conexión. Al igual que con las llamadas telefónicas en las que ambas partes dicen adiós y
cuelgan el telé- fono simultáneamente, ambos extremos de una conexión TCP pueden
enviar segmentos FIN al mismo tiempo.
Modelado de administración de conexiones TCP : Los pasos requeridos para
establecer y liberar conexiones pueden representarse en una máquina de estados finitos.
Los mismos son:

 CLOSED: No hay conexión activa ni pendiente

 LISTEN: El servidor espera una llamada
 SYN RCVD: Llegó solicitud de conexión; espera ACK
 SYN SENT: La aplicación comenzó a abrir una conexión
 ESTABLISHED: Estado normal de transferencia de datos
 FIN WAIT 1: La aplicación dijo que ya terminó
 FIN WAIT 2: El otro lado acordó liberar
 TIMED WAIT Espera que todos los paquetes mueran
 CLOSING Ambos lados intentaron cerrar simultáneamente
 CLOSE WAIT El otro lado inició una liberación
 LAST ACK Espera que todos los paquetes mueran

Política de transmisión del TCP:

  receptor búfer = 4096 bytes
emisor envía un segmento de 2048 bytes que se recibe correctamente
el receptor enviará la confirmación de recepción del segmento. 
Sin embargo, dado que ahora sólo tiene 2048 bytes de espacio de búfer anunciará
una ventana
de 2048 comenzando con el siguiente byte esperado
el emisor envía otros 2048 bytes, para los cuales el receptor envía la confirmación
de recepción, pero la ventana anunciada es de 0.
El emisor debe detenerse hasta que el proceso de aplicación del host receptor
retire algunos datos del búfer, en cuyo momento el TCP puede anunciar una
ventana más grande.
 Cuando la ventana tiene un tamaño de cero, el emisor no puede mandar
segmentos, con dos excepciones. Se pueden mandar los datos urgentes y se
pueden mandar un segmento de 1 byte para causar que el recibidor genere un
acuse nuevo con la ventana. Este último es para evitar el bloqueo indefinido.
 Los emisores no tienen que mandar datos inmediatamente y los recibidores no
tienen que mandar acuses inmediatamente. Se puede usar esta flexibilidad para
mejorar el rendimiento.
 Por ejemplo, considera una conexión de TELNET. Cada carácter tipiado genera un
paquete de IP de 41 bytes, seguido por un acuse de 40 bytes, seguido por una
actualización de la ventana de 40 bytes cuando la aplicación lee el carácter,
seguido por 41 bytes cuando la aplicación hace un eco del carácter, y finalmente
40 y 40 más.
 Una optimización es demorar los acuses y las actualizaciones de ventana por 500
msegs para usar piggybacking.
 Una segunda optimización para minimizar los segmentos con solamente un byte
de información es el algoritmo de Nagle. En esto se almacena los datos hasta que
llegue el último acuse o haya suficientes datos para llenar la mitad de la ventana o
un segmento máximo.
 Otro problema es el síndrome tonto de ventana. En esto la ventana del recibidor
está llena. La aplicación en el recibidor lee un byte, que causa que el recibidor
manda una actualización del tamaño de ventana al emisor. El emisor manda un
byte y la ventana está llena otra vez. La solución de Clarke es no mandar una
actualización de ventana hasta que el recibidor pueda manejar el segmento
máximo de la conexión o el
buffer esté medio vació, cualquier es menor. También el emisor no manda
segmentos pequeños (si posible). Debiera esperar hasta que haya suficiente
espacio en la ventana para un segmento completo o el buffer del recibidor esté
medio vacío (según su estimación de su tamaño).

Control de congestión en TCP: Cuando la carga ofrecida a cualquier red es mayor que
lo que puede manejar se genera una congestión. La solución real a este problema es la
disminución a la tasa de datos
Ventana de congestión
Al establecer una conexión, el emisor asigna a la ventana de congestión el tamaño de
segmento
máximo usado por la conexión; entonces envía un segmento máximo. Si se recibe la
confirmación
de recepción de este segmento antes de que expire el temporizador, el emisor agrega el
equivalente en bytes de un segmento a la ventana de congestión para hacerla de dos
segmentos de
tamaño máximo, y envía dos segmentos. A medida que se confirma cada uno de estos
segmentos,
se aumenta el tamaño de la ventana de congestión en un segmento máximo. Cuando la
ventana de
congestión es de n segmentos, si de todos los n se reciben confirmaciones de recepción a
tiempo,
se aumenta el tamaño de la ventana de congestión en la cuenta de bytes correspondiente
a n segmentos. De hecho, cada ráfaga confirmada duplica la ventana de
congestionamiento.
Algoritmo de control de congestión de Internet
Este algoritmo requiere de un parámetro llamado umbral, inicialmente de 64 KB, además
de las ventanas de recepción y congestión. Al ocurrir una expiración del temporizador, se
establece el umbral en la mitad de la ventana de congestión actual, y la ventana de
congestión se restablece a un segmento máximo. Luego se usa el arranque lento para
determinar lo que puede manejar la red, excepto que el crecimiento exponencial termina
al alcanzar el umbral. A partir de este punto, las transmisiones exitosas aumentan
linealmente.
Este algoritmo está suponiendo que probablemente es aceptable recortar la ventana de
congestión a la mitad, y luego aumentarla gradualmente a partir de ahí.
La congestión puede manejarse aprovechando un principio de física, La ley de la
conservación de paquetes. La idea es no inyectar un paquete nuevo en la red hasta que
salga uno viejo, y esto se logra manipulando dinámicamente el tamaño de la ventana
La solución es aceptar que existen dos problemas potenciales (capacidad de la red
y capacidad del receptor) y manejarlos por separado. Para ello, cada emisor mantiene dos
ventanas: la ventana que ha otorgado el receptor y una segunda ventana, la ventana de
congestión.
Este algoritmo se llama arranque lento, pero no es lento en lo absoluto; es exponencial, y
se requiere que todas las implementaciones de TCP lo manejen.

Administración de temporizadores del TCP: El TCP usa varios temporizadores para

hacer su trabajo. El más importante de éstos es el temporizador de retransmisión. Al
enviarse un segmento, se inicia un temporizador de retransmisiones. Si la confirmación de
recepción del segmento llega antes de expirar el temporizador, éste se detiene. Si, por
otra parte, el temporizador termina antes de llegar la confirmación de recepción, se
retransmite el segmento.
TCP y UDP inalámbricos: En teoría, los protocolos de transporte deben ser
independientes de la tecnología de la capa de red subyacente. En particular, el TCP no
debería preocuparse si el IP está operando por fibra o por radio. Ignorar las propiedades
de la transmisión inalámbrica puede conducir a implementaciones del TCP correctas
desde el punto de vista lógico, pero con un desempeño horrendo.

El problema principal es el algoritmo de control de congestionamientos.

Los enlaces de transmisión inalámbrica son muy poco confiables. Pierden paquetes todo el
tiempo. El enfoque adecuado para el manejo de paquetes perdidos es enviarlos
nuevamente, tan pronto como sea posible.

Al perderse un paquete en una red alámbrica, el emisor debe reducir la velocidad. Cuando
se pierde uno en una red inalámbrica, el emisor debe acelerar. Cuando el emisor no sabe
de qué clase de red se trata, es difícil tomar la decisión correcta.

Una solución propuesta por Bakne y Badrinath (1995), el TCP indirecto, es la división de la
conexión TCP en dos conexiones distintas. La primera va del emisor a la estación base. La
segunda va de la estación base al receptor.

Una solución diferente, debido a Balakrishnan y cols. (1995), no quebranta la semántica

del TCP. Funciona haciendo varias modificaciones pequeñas al código de la capa de red de
la estación base. Uno de los cambios es la adición de un agente espía que observa y
almacena en caché los segmentos TCP que van al host móvil y las confirmaciones de
recepción que regresan de él.

La comunicación inalámbrica también afecta otras áreas, no sólo el desempeño.

Conforme las redes inalámbricas se vuelvan más comunes, los problemas de ejecutar TCP
sobre ellas se volverán más serios.

TCP para Transacciones: los siguientes paquetes, se pueden utilizar para realizar una
RPC en TCP.

1. El cliente envía un paquete SYN para establecer una conexión.

2. El servidor envía un paquete ACK para confirmar la recepción del paquete SYN.

3. El cliente completa el acuerdo de tres vías.

4. El cliente envía la solicitud real.

5. El cliente envía un paquete FIN para indicar que ha terminado el envío.

6. El servidor confirma la recepción de la solicitud y el paquete FIN.

7. El servidor envía la respuesta al cliente.

8. El servidor envía un paquete FIN para indicar que también ha terminado.

9. El cliente confirma la recepción del paquete FIN del servidor.

Con esto surge rápidamente la pregunta de si hay alguna forma para combinar la
eficiencia de RPC utilizando UDP con la confiabilidad de TCP. La respuesta es: Puede
hacerse con una variante TCP llamada T/TCP (TCP para Transacciones), que se describe en
los RFCs 1379 y 1644.

La idea central es modificar ligeramente la secuencia estándar de configuración de

conexión para permitir la transferencia de datos durante la configuración. El primer
paquete del cliente contiene el bit SYN, la solicitud misma y el paquete FIN

Cuando el servidor obtiene la solicitud, busca o calcula la respuesta y elige cómo

responder. la respuesta se puede ajustar en un o más de un paquete.

T/TCP no es la única mejora propuesta a TCP. Otra propuesta es SCTP (Protocolo de

Transmisión de Control de Flujo). Sus características incluyen preservación de los límites
de mensajes, modos de entrega múltiples, multihoming y confirmaciones de recepción
selectivas.

Para concluir: Muchos programas dentro de una red de datos compuesta por
computadoras, pueden usar TCP para crear conexiones entre ellos a través de las cuales
puede enviarse un flujo de datos. El protocolo garantiza que los datos serán entregados en
su destino sin errores y en el mismo orden en que se transmitieron. También proporciona
un mecanismo para distinguir distintas aplicaciones dentro de una misma máquina, a
través del concepto de puerto.

TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores,

intercambio de ficheros, programas de mensajería, etc.) y protocolos de aplicación como
HTTP, SMTP, SSH y FTP.

El protocolo TCP está documentado en el RFC 793 de la IETF, y sus principales

características técnicas son:

ORIENTADO A LA CONEXIÓN: dos computadoras establecen una conexión para

intercambiar datos. Los sistemas de los extremos se sincronizan con el otro para manejar
el flujo de paquetes y adaptarse a la congestión de la red.
OPERACIÓN FULL-DÚPLEX: una conexión TCP es un par de circuitos virtuales, cada uno en
una dirección. Sólo los dos sistemas finales sincronizados pueden usar la conexión.

REVISIÓN DE ERRORES: una técnica de checksum es usada para verificar que los paquetes
no estén corruptos.

ACUSES DE RECIBO: sobre recibo de uno o más paquetes, el receptor regresa un acuse de
recibido, al transmisor indicando que recibió los paquetes. Si los paquetes no son
notificados, el transmisor puede reenviar los paquetes o terminar la conexión si el
transmisor cree que el receptor no está más en la conexión.

CONTROL DE FLUJO: si el transmisor está desbordando el buffer del receptor por

transmitir demasiado rápido, el receptor descarta paquetes. Los acuses fallidos que llegan
al transmisor le alertan para bajar la tasa de transferencia o dejar de transmitir.

SERVICIO DE RECUPERACIÓN DE PAQUETES: el receptor puede pedir la retransmisión de

un paquete. Si el paquete no es notificado como recibido (ACK), el transmisor envía de
nuevo el paquete.

UDP (Protocolo de Datagrama de Usuario): es un protocolo del nivel de

transporte basado en el intercambio de datagramas. Es no confiable y no
orientado a la conexión para aplicaciones que no desean la secuenciación o el
control de flujo de TCP y que desean proporcionar el suyo. También tiene un
amplio uso en consultas únicas de solicitud-respuesta de tipo cliente-servidor en
un solo envío, así como aplicaciones en las que la entrega puntual es más
importante que la precisa, como en la transmisión de voz o vídeo.

El conjunto de protocolos de Internet soporta un protocolo de transporte no orientado a

la conexión, UDP. Este protocolo proporciona una forma para que las aplicaciones envíen
datagramas IP encapsulados sin tener que establecer una conexión. UDP se describe en el
RFC 768. UDP transmite segmentos que consisten en un encabezado de 8 bytes seguido
por la carga útil. Los dos puertos sirven para identificar los puntos terminales dentro de las
máquinas de origen y destino. Cuando llega un paquete UDP, su carga útil se entrega al
proceso que está enlazado al puerto de destino. Este enlace ocurre cuando se utiliza la
primitiva BIND o algo similar, (el proceso de enlace es el mismo para UDP). De hecho, el
valor principal de contar con UDP en lugar de simplemente utilizar el IP puro es la adición
de los puertos de origen y destino. Sin los campos de puerto, la capa de transporte no
sabría qué hacer con el paquete. Con ellos, entrega los segmentos de manera correcta.

Una aplicación que utiliza de esta manera a UDP es DNS (el Sistema de Nombres de
Dominio). Un programa que necesita buscar la dirección IP de algún host, por ejemplo,
www.cs.berkeley.edu, puede enviar al servidor DNS un paquete UDP que contenga el
nombre de dicho host. El servidor responde con un paquete UDP que contiene la dirección
IP del host. No se necesita configuración por adelantado ni tampoco liberación posterior.
Sólo dos mensajes viajan a través de la red. El paso de mensajes es transparente para el
programador. Esta técnica se conoce como RPC (Llamada a Procedimiento Remoto) y se
ha vuelto la base de muchas aplicaciones de redes. Tradicionalmente, el procedimiento
invocador se conoce como cliente y el proceso invocado, como servidor, por lo que aquí
utilizaremos esos nombres. A pesar de la elegancia conceptual de RPC, hay algunas
desventajas ocultas. La más grande es el uso de parámetros de apuntador.

El protocolo de transporte en tiempo real : Está colocado en el espacio de usuario

y se ejecuta sobre UDP. La aplicación multimedia consiste en múltiples flujos de audio,
vídeo, texto, entre otros. Éstos se colocan en la biblioteca RTP, la cual está en el espacio
de usuario junto con la aplicación. Esta biblioteca multiplexa los flujos y los codifica en
paquetes RTP, que después coloca en un socket. En el otro extremo del socket (en el
kernel del sistema operativo), los paquetes UDP se generan e incrustan en paquetes IP. Si
la computadora está en una Ethernet, los paquetes IP se colocan a continuación en tramas
Ethernet para su transmisión. Es un protocolo genérico, independiente de la aplicación
que simplemente proporciona características de transporte, por lo que se parece a un
protocolo de transporte.

La función básica de RTP es multiplexar varios flujos de datos en tiempo real en un solo
flujo de paquetes UDP. El flujo UDP se puede enviar a un solo destino (unidifusión) o a
múltiples destinos (multidifusión).

A cada paquete enviado en un flujo RTP se le da un número más grande que a su

predecesor. Esta numeración permite al destino determinar si falta algún paquete.

Cada carga útil RTP podría contener múltiples muestras, y éstas podrían codificarse de la
forma en la que la aplicación desee. Para permitir la interconectividad, RTP define diversos
perfiles, y para cada perfil se podrían permitir múltiples formatos de codificación.

Otra característica que muchas de las aplicaciones en tiempo real necesitan es la

marcación del tiempo (timestamping). La idea aquí es permitir que el origen asocie una
marca de tiempo con la primera muestra de cada paquete. Las marcas de tiempo son
relativas al inicio del flujo, por lo que sólo son importantes las diferencias entre dichas
marcas de tiempo.

RTP tiene un hermano pequeño llamado RTCP (Protocolo de Control de Transporte en

Tiempo Real). Maneja la retroalimentación, sincronización y la interfaz de usuario, pero no
transporta ningún tipo de datos. También maneja sincronización entre flujos. El problema
es que flujos diferentes pueden utilizar relojes diferentes, con distintas granularidades y
distintas tasas de derivación. RTCP puede utilizarse para mantenerlos sincronizados. Por
último, proporciona una forma para nombrar los diversos orígenes. Esta información
puede desplegarse en la pantalla del receptor para indicar quién está hablando en ese
momento.

Características: Las principales características técnicas del protocolo UDP son:

- Es un protocolo mínimo de nivel de transporte orientado a mensajes
(datagramas) documentado en el RFC 768 de la IETF.
- Proporciona una sencilla interfaz entre la capa de red y la capa de aplicación.
- No otorga garantías para la entrega de sus mensajes.
- Se utiliza, por ejemplo, cuando se necesita transmitir voz o vídeo y resulta más
importante transmitir con velocidad que garantizar el hecho de que lleguen
absolutamente todos los bytes.

 Ethernet: es un estándar de redes de área local para computadores con acceso al

medio por detección de la onda portadora y con detección de colisiones
(CSMA/CD). Su nombre viene del concepto físico de ether. Ethernet define las
características de cableado y señalización de nivel físico y los formatos de tramas
de datos del nivel de enlace de datos del modelo OSI.
Ethernet se tomó como base para la redacción del estándar internacional IEEE 802.3,
siendo usualmente tomados como sinónimos. Se diferencian en uno de los campos de la
trama de datos. Sin embargo, las tramas Ethernet e IEEE 802.3 pueden coexistir en la
misma red.
Es una red de difusión basada en bus con control descentralizado, que por lo general
funciona de 10 Mbps a 10 Gbps. Las computadoras que están en una Ethernet pueden
transmitir siempre que lo deseen; si dos o más paquetes entran en colisión, cada
computadora espera un tiempo aleatorio y lo intenta de nuevo más tarde.

Ethernet es una tecnología para redes de área local que se empezó a comercializar en
1980 y que está estandarizada en el IEEE 802.3. Los sistemas que se comunican mediante
Ethernet utilizan flujo de datos mediante paquetes individuales llamados trama de red o
frame. Ethernet señala tanto las características de cables a nivel físico como los formatos
de las tramas a nivel de la capa de enlace.

Funcionamiento: La idea básica detrás de Ethernet es que todas las PCs dentro de una
red envíen y reciban datos de una forma en que se evite cualquier tipo de
superposición, lo que sería desastroso. Es por ello que los datos que se envían o reciben
mediante este estándar deben ser fragmentados en fracciones más pequeñas y enviados a
través de un método conocido como “Conmutación de paquetes”.

Básicamente esto consiste en que, si una de las PC de la red quiere enviar un paquete de
datos a otra, debe ser empaquetado, lo que finalmente arroja como resultado un
“paquete”, el cual consiste de varios datos tales como cabecera, dirección del dispositivo
en la red a quién va destinado y qué dispositivo de la red lo está enviando. Además,
contiene datos de control y otras informaciones relativas al mismo como la cantidad de
datos que transporta y otros.

Historia: La historia empieza en la prístina Hawaii a principios de la década de 1970. En

este caso, “prístina” se puede interpretar como “que no tiene un sistema telefónico
funcional”. En tanto, el investigador Norman Abramson y sus colegas de la Universidad de
Hawaii, quienes estuvieron tratando de conectar usuarios de las islas remotas a la
computadora principal de HonoSEC. Conectar sus propios cables bajo el Océano Pacífico
parecía imposible, de modo que buscaron una solución diferente. La primera que
encontraron fueron los radios de onda corta. Cada terminal estaba equipada con un radio
pequeño de dos frecuencias: un canal ascendente (a la computadora central) y otro
descendente (desde la computadora central). Cuando el usuario deseaba conectarse con
la computadora, sólo transmitía por el canal ascendente un paquete que contenía los
datos. Si en ese instante nadie más estaba transmitiendo, probablemente el paquete
saldría y su recepción sería confirmada en el canal descendente. Si había contención por el
canal ascendente, la terminal detectaría la falta de confirmación de recepción y haría otro
intento. Puesto que sólo habría un emisor en el canal descendente (la computadora
central), nunca habría colisiones ahí. Este sistema, llamado ALOHANET, trabajaba muy
bien en condiciones de bajo tráfico, pero se caía cuando el flujo de tráfico ascendente era
pesado. En esa misma época, Bob Metcalfe aplicando su conocimiento del trabajo de
Abramson, junto con su colega David Boggs, diseñó e implementó la primera red de área
local (Metcalfe y Boggs, 1976). Llamaron Ethernet al sistema a través del cual se pensó
alguna vez que se propagaba la radiación electromagnética. Aquí el medio de transmisión
era un cable coaxial grueso (el éter) de más de 2.5 km de largo (con repetidoras cada 500
metros). El sistema podía contener hasta 256 máquinas por medio de transceptores
acoplados al cable. Un cable con múltiples máquinas en paralelo se llama cable de
derivación múltiple (multidrop). El sistema se ejecutaba a 2.94 Mbps. Ethernet tenía una
mejora importante respecto de ALOHANET; antes de transmitir, una computadora tenía
que escuchar el cable para ver si había alguien más transmitiendo. En caso de que ya lo
hubiera, la computadora se mantenía en espera de que la transmisión actual terminara. Al
hacerlo así se evitaba interferir con las transmisiones existentes, dando una mayor
eficiencia. ALOHANET no trabajaba de este modo porque para una terminal en una isla era
imposible detectar la transmisión de otra terminal en una isla distante. El problema se
resolvía con un cable único. A pesar de que la computadora escucha antes de transmitir,
surge un problema: ¿qué sucede si dos o más computadoras esperan hasta que se
complete la transmisión actual y luego empiezan a transmitir al mismo tiempo? La
solución es que cada computadora escuche durante su propia transmisión y, si detecta
interferencia, mande una señal para poner en alerta a todos los transmisores. Después
espera un tiempo aleatorio antes de reintentarlo. Si sucede una colisión, el tiempo
aleatorio de espera se duplica y así sucesivamente, para separar las transmisiones que
están en competencia y dar a alguna la oportunidad de transmitir primero. La Ethernet de
Xerox fue tan exitosa que DEC, Intel y Xerox diseñaron un estándar en 1978 para una
Ethernet de 10 Mbps, llamado estándar DIX. Con dos cambios menores, en 1983 el
estándar DIX se convirtió en el estándar IEEE 802.3. Por desgracia para Xerox, ya tenía
fama de hacer inventos originales (como el de las computadoras personales) y luego fallar
en la comercialización de los mismos, como se menciona en un relato titulado Fumbling
the Future (Smith y Alexander, 1988). Cuando Xerox mostró poco interés en hacer algo
con Ethernet aparte de ayudar a estandarizarlo, Metcalfe formó su propia empresa,
3Com, con el propósito de vender adaptadores Ethernet para PCs. Ha vendido más de 100
millones. Ethernet continuó su desarrollo y aún está en desarrollo. Han salido nuevas
versiones a 100 y 1000 Mbps, e incluso más altas. También se ha mejorado el cableado y
se han agregado conmutación y otras características. De paso, vale la pena mencionar que
Ethernet (IEEE 802.3) no es el único estándar de LAN. El comité también estandarizó
Token Bus (802.4) y Token Ring (802.5). La necesidad de tres estándares más o menos
incompatibles tiene poco que ver con la tecnología y mucho con la polí- tica. En el
momento de la estandarización, General Motors estaba impulsando una LAN en la que la
topología era la misma que la usada en Ethernet (un cable linear), pero las computadoras
transmitían por turnos pasando un pequeño paquete de computadora a computadora,
llamado token. Una computadora podía transmitir sólo si poseía el token, lo que evitaba
colisiones. General Motors anunció que este esquema era esencial para la manufactura de
automóviles y que no estaba preparado para cambiar su postura. No obstante este
anuncio, el 802.4 prácticamente desapareció. Del mismo modo, IBM tenía su favorito: su
Token Ring patentado. En este esquema el token se pasaba a través del anillo y la
computadora que poseyera el token podía transmitir antes de poner el token de nuevo en
el anillo. A diferencia del 802.4, este esquema, estandarizado como 802.5. Transceptor
Cable de la interfaz Éter aún se usa en algunos sitios de IBM, pero prácticamente en
ninguna parte más. Sin embargo, se está desarrollando una versión de 1 gigabit (802.5v),
pero parece poco probable que alcance a Ethernet. Había una guerra entre Ethernet,
Token Bus y Token Ring, pero Ethernet ganó, porque fue la primera y los retadores no
pudieron superarlo.
Cableado Ethernet: Comúnmente se usan cuatro tipos de cableado, y estos son:
- El cable 10Base5, llamado Ethernet grueso. las conexiones a él se hacen usando
derivaciones vampiro. La notación 10Base5 significa que opera a 10 Mbps, utiliza
señalización de banda base y puede manejar segmentos de hasta 500 metros.
- El cable 10Base2 o Ethernet delgado. Las conexiones se hacen usando conectores
BNC estándar de la industria para formar uniones T. El Ethernet delgado es mucho
más económico y fácil de instalar, pero sólo puede extenderse 185 metros.
- El cable 10Base-T. Por lo general, estos cables son pares trenzados telefónicos; la
longitud máxima del cable es de sólo 100 metros, tal vez de 200 metros si se usa
cable de par trenzado de alta calidad.
- El cable 10Base-F, que usa fibra óptica. Esta alternativa es cara debido al costo de
los conectores y los terminadores. Se permiten separaciones de kilómetros entre
conexiones. También ofrece buena seguridad debido a que es más difícil intervenir
una conexión de fibra que una de cobre. La longitud máxima del cable es de 2000
metros.

Cada versión de Ethernet tiene una longitud máxima de cable por segmento. Para permitir
redes mayores, se pueden conectar múltiples cables mediante repetidores. Un repetidor
es un dispositivo de capa física que recibe, amplifica (regenera) y retransmite señales en
ambas direcciones. En lo que concierne al software, una serie de segmentos de cable
conectados mediante repetidores no es diferente de un solo cable (excepto por el retardo
introducido por los repetidores). Un sistema puede contener múltiples segmentos de
cable y múltiples repetidores, pero ningún par de transceptores puede estar separado por
más de 2.5 km y ninguna ruta entre dos transceptores puede atravesar más de cuatro
repetidores.

Ethernet conmutada: Ethernet conmutado, también conocido como Ethernet

Switcheado o Switched Ethernet, utiliza equipos similares a los concentradores de
red, que tienen canales de comunicación de alta velocidad en su interior, con una
arquitectura similar a las centrales de teléfonos que conmutan (switchean) el tráfico entre
las estaciones conectadas a ellos. Esto permite que cada estación disponga de un canal de
10 ó 100 Mbits/s, en lugar de un único canal para todas ellas. La ventaja de esta
especificación es que utiliza los mismos cables y tarjetas de red que el 10baseT o
el 100baseX, sustituyéndose sólo los concentradores por conmutadores.

Fast Ethernet: o Ethernet de alta velocidad es el nombre de una serie de estándares

de IEEE de redes Ethernet de 100 Mbps. En su momento el prefijo fast se le agregó para
diferenciarla de la versión original Ethernet de 10 Mbps.
Debido al incremento de la capacidad de almacenamiento y en el poder de
procesamiento, los Pc’s actuales tienen la posibilidad de manejar gráficos de gran calidad
y aplicaciones multimedia complejas. Cuando estos ficheros son almacenados y
compartidos en una red, las transferencias de un cliente a otro producen un gran uso de
los recursos de la red.
Las redes tradicionales operaban entre 4 y 16 Mbps. Más del 40 % de todos los Pc’s están
conectados a Ethernet. Tradicionalmente Ethernet trabajaba a 10 Mbps. A estas
velocidades, dado que las compañías producen grandes ficheros, pueden tener grandes
demoras cuando envían los ficheros a través de la red. Estos retrasos producen la
necesidad de mayor velocidad en las redes.
Fast Ethernet no es hoy por hoy la más rápida de las versiones de Ethernet.
Gigabit Ethernet: Gigabit Ethernet, también conocida como GigaE, es una ampliación
del estándar Ethernet (concretamente la versión 802.3ab y 802.3z del IEEE) que consigue
una capacidad de transmisión de 1 gigabit por segundo, correspondientes a unos
1000 megabits por segundo de rendimiento contra unos 100 de Fast Ethernet.

Gigabit Ethernet soporta dos modos diferentes de funcionamiento: modo de dúplex total
y modo de semidúplex.

Estándar IEEE 802.2: control lógico del enlace: que es la parte superior de la capa
enlace en las redes de área local. La subcapa LLC presenta una interfaz uniforme al
usuario del servicio enlace de datos, normalmente la capa de red. Bajo la subcapa LLC está
la subcapa MAC, que depende de la configuración de red usada (Ethernet, token
ring, FDDI, 802.11, etc.). El uso de control de enlace lógico (LLC) es obligatorio en todas las
redes del IEEE 802 a excepción de Ethernet.

2) Cree un cuadro comparativo con ventajas y desventajas entre IPv6 e IPv4.

VENTAJAS DESVENTAJAS
IPv6 IPv4 IPv6 IPv4
 Direcciones de  Direcciones de  La necesidad de  Elevada
128 bits. 32 bits. extender un demanda
 Formato de  Formato de soporte de
cabecera más cabecera más permanente para direccione
sencillo. grande. IPv6 a través de s IP.
 Configuración  Configuración todo internet y
automática. manual. de los
 Proporciona  Proporciona dispositivos
una cantidad una cantidad conectados.
ilimitada de limitada de  Para estar  No posee
direcciones. direcciones. enlazada al seguridad
  Seguridad  Contiene enlace universo IPv6
incorporada. con fibra óptica durante la fase de
 Encabezado de  El espacio de las transición,
7 datagramas. direcciones es todavía se
menor necesita una
 Simplificación  Puede generar dirección IPv4 o
de tareas del 4.294 millones algún tipo de
 Limita el
router de NAT.
crecimient
combinaciones.  Direcciones
o del
extensas y mucho
internet.
más difíciles de
 Es lenta
memorizar.
para
 La
transmitir
implementación
videos.
es más costosa y
tarda bastante
tiempo en
aplicar.

3) Cree un cuadro comparativo con ventajas y desventajas entre TCP y UDP.

VENTAJAS DESVENTAJAS
TCP UDP TCP UDP
 Este  Este protocolo  Si pasado  No otorga
protocolo es aporta un determinado garantías para
el encargado procedimiento tiempo no se la entrega de
de establecer para que los recibe el ACK sus mensajes y
la conexión y programas de correspondiente el origen UDP
dividir la aplicación , la información no retiene
información puedan enviar será estados de los
en paquetes, mensajes a retransmitida, mensajes UDP
garantizando otros desde el punto que han sido
que no abra programas de de vista que enviados a la
perdida y mecanismo de envié 2 archivos red.
estarán en el protocolo. después de un  UPD solo añade
orden determinado multiplexado
apropiado. tiempo. de aplicación y
 TCP también  Proporciona suma de
asegura que una sencilla verificación de
toda la interfaz entre la cabecera y la
información la capa de red carga útil.
emitida es y la capa de Cualquier tipo
recibida. Para aplicación. de garantías
ello, por cada para la
paquete transmisión de
emitido, debe la información
recibirse un deben ser
asentimiento. implementadas
en capas
superiores.