Herramientas de usuario

Herramientas del sitio


clase:daw:si:3eval:tema17

17. El protocolo TCP

Protocolo de Transporte

Vamos a hacer un resumen de lo visto hasta ahora y de esa forma ver donde encaja el protocolo TCP.

  • Para ordenadores que están conectado directamente , nos podemos conectar mediante Ethernet. Como dirección de los ordenadores usamos la MAC
  • Si los ordenadores no están conectado directamente , necesitamos de los routers y el protocolo IP. Como dirección de los ordenadores usamos la IP
  • El protocolo IP tiene una serie de problemas:
    • Los datos pueden llegar desordenados
    • Los datos pueden perderse
    • Los datos pueden llegar duplicados
    • No se especifica a que proceso del ordenador destino van los datos.
  • Junto con el protocolo IP están los protocolos ARP y ICMP que "ayudan" al protocolo IP

¿Para que sirve entonces el protocolo TCP? Obviamente para solucionar los problemas que tiene el protocolo IP. Por lo tanto las ventajas de TCP van a ser las siguientes:

  • Los datos llegan ordenados
  • Los datos nunca se pierden
  • Los datos nunca llegan duplicados
  • Se puede especificar a que proceso van destinados los datos.

Junto al protocolo TCP Existe otro llamado UDP que es similar a TCP. Aunque el importante de los dos es TCP. Y muchas cosas que son válidas para TCP también lo son para UDP

En el diagrama superior podemos ver todos los protocolos que conocemos y los programas que hacen uso de ellos. Como se puede ver, TCP y UDP trabajan sobre IP para realizar su trabajo.

Mas información:

Puerto

Hasta ahora para comunicarnos desde un ordenador a otro solo necesitábamos a parte de los propios datos, la IP del ordenador origen y la IP del ordenador destino. Sin embargo con eso no es suficiente. Pensemos en nuestro movil. Cuando nos llegan datos al movil ¿A que aplicación van? ¿Son para el Whatsapp?¿Para el correo?¿Para el navegador web? etc, etc ,etc. Por lo tanto es necesario especificar también cuando llegan los datos para que aplicación es. Eso se hace con un nuevo número llamado PUERTO. Ese número indica a que aplicación de nuestro ordenador se deben entregar los datos. Pero tambien es necesario indicar si van para el puerto por TCP o por UDP. Por lo tanto para establecer la conexión necesitamos lo siguiente:

  • Protocolo a usar: TCP o UDP
  • IP Origen y Puerto Origen
  • IP Destino y Puerto Destino

Sabiendo ésto, vamos a ver una tabla con los números de puertos que usan algunas aplicaciones:

Aplicación Puerto Protocolo
SSH 22 TCP
Servidor Web 80
443
TCP
TCP
MySQL 3306 TCP
eMule 4662
4665
4672
TCP
UDP
UDP
VoIP 1) 5060
5060
5004
TCP
UDP
UDP
IPTV 2) 12000 UDP
Minecraft 25565 TCP
BitTorrent 6881
6969
TCP
TCP

La tabla completa de puertos "oficiales", se llama "puertos bien conocidos" y la puedes ver en Wikipedia:Puerto bien conocidos

Podemos ver que es distinto un puerto en TCP o en UDP. Me refiero a que cuando uno se conecta por ejemplo al puerto 22 hay que decir si es por TCP o por UDP

El concepto de PUERTO es de las cosas mas importantes que debe aprender un desarrollador. Ya que al programar una aplicación de red, nosotros decidimos que puerto usa nuestra aplicación.

Además que como muchas ya habéis oído , muchas veces hace falta abrir los puertos.

Bien , pero lo que no hay que perder de vista es que realmente todo lo que llevamos contado de redes está orientado a que podamos enviar datos de un PROCESO3) a otro PROCESO4) que está en otro ordenador.

Por ejemplo:

  • Desde un Navegador Web (como Firefox) a un servidor Web (Como apache) y viceversa.
  • Desde un cliente SSH (como putty) a un servidor de SSH
  • Desde un cliente de correo a un servidor de correo.
  • Desde un cliente de Minecraft a un servidor de Minecraf.

Pues bien, un proceso tiene que decirle al sistema operativo que se "conecta" a un protocolo, un puerto y una IP (Obviamente restringido a las IPs del propio equipo). Y así cuando envíe o reciba datos será con ese puerto y protocolo. Y luego el proceso enviará datos a un destino con un puerto e IP destinos (El protocolo destino obviamente será el mismo que el del origen. )

  • Se elije protocolo (TCP o UDP)
  • Se elige Puerto Origen y Dirección IP Origen
  • Se conecta a Puerto Destino y Dirección IP Destino.

Resumiendo: Ahora la comunicación es:

                              TCP
(IP Origen,Puerto Origen) ----------> (IP Destino,Puerto Destino)

o

                              UDP
(IP Origen,Puerto Origen) ----------> (IP Destino,Puerto Destino)
  • Es importante destacar que únicamente un proceso (un programa en ejecución) se puede conectar a un puerto y protocolo. Por ejemplo:
    • Si hacemos un programa en Java y lo conectamos al puerto 3306 por TCP, luego no podremos instalar MYSQL, ya que MYSQL usa el puerto 3306 por TCP
    • Pero Si hacemos un programa en Java y lo conectamos al puerto 3306 por UDP, luego si podremos instalar MYSQL, ya que MYSQL usa el puerto 3306 por TCP.
  • Pero lo que si que se permite es que un proceso se conecte a dos puertos. Por ejemplo:
    • El servidor Web de Java llamado Tomcat está conectado al puerto 8080 para recibir peticiones de navegadores
    • Pero también está conectado al puerto 8005 para recibir peticiones que reinician el servidor
Entonces, ¿Acabo de decir que cualquier proceso se puede "conectar" al puerto 3306 y todo el mundo creerá que es MySQL? Realmente si, pero no es ningún problema. Al igual que debemos de saber la IP del ordenador destino , también debemos de saber el puerto al que está conectado. Así que si en nuestro ordenador decidimos que al puerto 3306 se conecta un programa en Java que hemos hecho, tendremos que instalar MySQL en cualquier otro puerto libre, por ejemplo el 15000. Y decirle a todos nuestros clientes que se vayan a conectar que el puerto que hemos usado en MySQL es el 15000.

Obviamente, lo normal es que si el puerto 3306 lo use MySQL y no usemos nosotros ese puerto, pero se han desarrollado tantos programas , que podría ser que dos programadores elijan el mismo número de puerto en sus programas. En ese caso uno de los dos programas debería configurarse en un puerto distinto. Por ello todos los programas, permiten siempre configurar el puerto que usan.

Cliente-Servidor

Fijémonos ahora en un detalle. Damos por hecho que cualquier ordenador se puede conectar con cualquier otro ordenador. Pues realmente no es así.

  • A nivel de Ethernet y de IP, te puedes conectar con cualquier ordenador ya que es el propio sistema operativo el que recibe los datos.
  • A nivel de TCP solo te puedes conectar si en el ordenador destino hay un proceso conectado al puerto al que te quieres conectar.

Volvamos a ver el primer ejemplo:

Supongamos que el Host 192.168.3.14 se quiere conectar con el Host 192.168.4.123. Ahora sabemos que lo primero es elegir el protocolo de Transporte:

  • TCP
  • UDP

Supongamos que queremos conectarnos con el protocolo TCP.

Ahora debemos elegir a que puerto del ordenador destino (192.168.4.123):

  • 1
  • 2
  • 3
  • …..
  • 655355)

Supongamos que queremos conectarnos al puerto 3306

La elección de conectarnos al puerto 3306 no es arbitraria. Suponemos que al programa al que queremos conectarnos está escuchando en ese puerto. Es decir que realmente lo que decidimos es a que programa nos queremos conectar y una vez elegido tenemos que saber en que puerto está escuchando. En ese ejemplo realmente lo que queremos es conectarnos a MySQL y debemos que saber de antenamo que MySQL está conectado en el puerto 3306.

La pregunta es, ¿Hay un proceso en el Host 192.168.4.123 conectado al puerto 3306? Es decir que para conectarnos a otro ordenador debe obligatoriamente estar un proceso conectado a ese puerto, ya que sino el sistema operativo no sabría a que proceso enviar los datos. Ya que realmente no enviamos los datos de ordenador a ordenador sino de programa a programa. Piensa en el Whatsapp….

Pero aun hay otra cosa. Ese proceso que está conectado al puerto 3306, se dice que está ESCUCHANDO o que dicho proceso es un SERVIDOR . ¿Porque decimos que está escuchando o que es un servidor? , porque se proceso va a aceptar que cualquier ordenador le envíe datos. Piensa en MySQL. Ese proceso está escuchando en el puerto 3306 a que cualquier otro ordenador (al que a partir de ahora llamaremos ordenador cliente) le envíe una SELECT para que MySQL retorne los datos.

Así que:

  • Proceso Servidor: Es un proceso que está escuchando en un puerto a que le envíen datos.
  • Proceso Cliente: Es un proceso que comienza enviado datos a un proceso servidor

Se dice que la conexión por TCP o UDP es de tipo Cliente-Servidor ya que uno de los procesos hace de cliente y otro hace de servidor.

Es importante destacar que no estamos hablando de ordenadores cliente y ordenadores servidor. Ya que el mismo ordenador puede tener procesos que hacen de clientes y procesos de hacen de servidor. Así que lo correcto es hablar de procesos clientes y procesos servidor. Aunque abusamos del lenguaje y solemos decir que un ordenador es servidor si lo mas importante que hace es tener procesos servidores aunque alguna vez tenga un proceso cliente.Incluso hasta puede que lo haga como cliente y servidor a la vez aunque obviamente en puertos distintos 6)

Volvamos a éste pequeño esquema:

                              TCP
(IP Origen,Puerto Origen) ----------> (IP Destino,Puerto Destino)

Tenemos ya lo siguiente datos

                                 TCP
(192.168.3.14,Puerto Origen) ----------> (192.168.4.123,3306)

Pero aun nos falta saber el puerto origen. Pues bien, el puerto origen, no lo decidimos nosotros. El sistema operativo nos asigna el puerto que él quiere cuando queremos hacer de cliente. Podríamos pensar que debemos tener el 3306 o que siempre sea el mismo pero si pensamos un poco, da igual el puerto que tenga el cliente. El servidor siempre nos va a responder al puerto origen que tengamos, así que da igual cual sea 7)

Así que como puerto origen vamos a suponer que el sistema operativo nos asigna el nº de puerto 45345. Ahora por fin ya tenemos toda la información para la conexión TCP.

                         TCP
(192.168.3.14,45345) ----------> (192.168.4.123,3306)

Por último decir que aunque el cliente es que inicia la conexión al servidor, estando el servidor siempre esperando que algún cliente le conecte. Una vez establecida la conexión, ya pueden enviar libremente datos tanto el cliente como el servidor.

Una forma mas sencilla de ver lo de cliente y servidor es pensar en la Web. Nuestros navegadores son procesos que son clientes de TCP. Por otro lado los servidores web son procesos que son servidores TCP que escuchan en el puerto 80. El servidor no inicia ninguna conexión con el cliente sino que el servidor está a la espera a que un cliente (nuestro navegador) se conecte. Por lo tanto es nuestor proceso navegador que actua como cliente TCP el que siempre inicia la conexión hacia el proceso que actua como servidor TCP. Y una vez establecida la conexión ya pueden cualquiera de los dos enviar datos al otro cuando quiera.

Protocolo TCP

Por fin vamos a explicar el protocolo TCP. Lo vamos a ver de una forma muy muy sencilla ya que es un protocolo muy complejo.

Lo primero es indicar que si lo que envía Ethernet se llama Trama, lo que envía IP se llama Datagrama, lo que envía TCP se llama Segmento.

Pasemos ahora a recordemos lo que debe hacer el protocolo TCP:

  • Se puede especificar a que proceso van destinados los datos
  • Los datos llegan ordenados: Se soluciona numerando los datos
  • Los datos nunca se pierden: Se soluciona numerando los datos
  • Los datos nunca llegan duplicados: Se soluciona numerando los datos

Para especificar a que proceso van destinados los datos, ya hemos visto que se soluciona introduciendo el concepto de puerto, ya que un proceso se conecta a un puerto8).

Ahora veamos como soluciona el resto de problemas: Resulta que en cada conexión que se establece en TCP (Recordemos que una conexión es la unión de IP Origen, Puerto Origen, IP Destino, Puerto Destino) se van a numerar los segmentos que envía. De esa forma si alguno no llega, llega repetido o llega en orden distinto, TCP va a saberlo.

Veamos un ejemplo: Imagina que queremos enviar 5 KB de datos y cada KB lo ponemos en un segmento distinto. Los segmentos a enviar son los siguientes: 1, 2, 3, 4 y 5. Y obviamente el Host origen los envía en ese orden, es decir , primero el segmento 1, después el segmento 2, etc.

Vamos ahora a ver distintos casos de llegada de los segmentos al Host destino y como se detecta cada error.

Llegada de los segmentos Problema detectado
1 ,2 ,3 ,4 ,5 Ninguno. Todo ha llegado bien
1 ,2 ,4 ,5 Se ha perdido el segmento 3
1 ,2 ,3, 4 ,4 , 5 El segmento 4 ha llegado duplicado
1 ,2 ,4 , 3 , 5 Los segmentos 3 y 4 han llegado desordenados
3, 1, ,4 , 4 , 5 El segmento 4 ha llegado duplicado,el segmento 2 se ha perdido, el segmento 3 y 1 han llegado fuera de orden

En caso de problemas, TCP los soluciona de la siguiente forma:

  • Segmento duplicado: TCP descarga el segmento que ha llegado duplicado
  • Segmentos desordenados: TCP recompone el orden ya que tiene el nº de secuencia.
  • Segmento perdido: TCP le indica al Host origen que vuelva a enviar el segmento que no ha llegado.

Mas información en,

Podemos ver en la siguiente imagen como TCP añade su propia cabecera sobre los datos de IP. Es decir que existe una cabecera para los segmentos.

Es decir:

  • Tenemos unos datos.
  • Añadimos una cabecera TCP y enviamos el segmento con su cabecera (Con el puerto origen y destino) y los datos al protocolo IP
  • El protocolo IP añade su propia cabecera , con la IP de origen y de destino, creando un datagrama y lo envía a Ethernet
  • Finalmente Ethernet añade su propia cabecera con las MAC origen y destino y finalmente envía la trama por el cable físico.

Pasemos ahora a ver el formato de la cabecera del segmento

Los campos que nos interesan son los siguientes:

  • Puerto de origen: El puerto desde el que se envían los datos.
  • Puerto de destino: El puerto al que se envían los datos
  • Número de secuencia: El Nª de secuencia del segmento que permite detectar errores.
  • Número de acuse de recibo: También se llama Nº ACK. Es el que dice al otro Host el Nº de segmento que estamos esperando recibir y así saber cual se ha perdido.
  • Longitud de la cabecera: Se especifica en palabras de 32 bits. Es decir que un 1 significa que la cabecera ocupa 32 bits, un 2 significa que la cabecera ocupa 64 bits, etc.
  • Suma de verificación: Es el CRC de todo el segmento (Cabecera y datos)
  • SYNC y ACK: Estos son dos bits que se usan para establecer y cerrar la conexión en TCP. Ya hemos comentado que para enviar datos es necesario previamente establecer una conexión. Y cuando se acaban de enviar datos, cerrar la conexión. En la siguiente imagen se muestran los segmentos TCP que se envían para establecer la conexión (De forma similar se hace para cerrar la conexión)

Antes de poder enviar los datos hay que enviar unos segmentos para establecer la conexión. Sin estos segmentos iniciales con el bits de SYNC y/o ACK activado, el servidor no aceptará los segmentos con datos.

Para terminar con TCP, podemos decir que después de muchos protocolos con TCP hemos conseguido que los datos se envíen desde un proceso a otro de una forma fiable sin perdidas o alteraciones de información.

Protocolo UDP

El protocolo UDP es muy similar al protocolo TCP , así que la mayoría de las cosas que hemos explicado de TCP sirven para UDP. Entonces ¿en que se diferencian?

En que UDP no resuelve los siguientes problemas:

  • No resuelve si los datos llegan desordenados
  • No resuelve si los datos se pierden
  • No resuelve si los datos llegan duplicados.

Y en que en UDP no es necesario establecer/cerrar la conexión es decir que se envían los datos directamente.

Aunque si que resuelve el que se puede especificar a que proceso van destinados los datos. Es decir que el concepto de puerto se usa en UDP.

Mas información en:

Entonces para que sirve UDP si no se solucionan los problemas del protocolo IP. Bueno , como ya hemos dicho hay uno que si que se soluciona y es poder especificar a que proceso van los datos gracias al puerto.

Veamos ahora la cabecera UDP

Como podemos ver es muy muy simple y no necesita de mas explicación.

Pero lo que debes estar pensando desde hace un rato es ¿entonces para que sirve UDP? ¡¡Si funciona mal!!!!. Pues la respuesta es muy simple, resulta que TCP es un protocolo muy bueno pero es muy complejo de implementar además que es muy lento al enviar cosas. Mientras que UDP es muy sencillo de programar y el envío es muy rápido. Así que aunque pierdes fiabilidad, mejoras en rapidez.

Uno de los motivos por los que UDP es mas rápido es que no necesita establecer y cerrar la conexión ,así que se ahorra mucho tiempo en transmisiones cortas

Lo siguiente es un chiste sobre UDP, indicando justamente que mejora la velocidad pero tiene poca fiabilidad.

Vale , pero aunque sea mas rápido , uno no quiere nunca perder datos. Así que ¿para que puede ser útil UDP?

Aplicación Ventajas Supuestas Desventajas
Envío de la temperatura desde un sensor que está arriba de una montaña Gasta menos datos y necesita un procesador mas simple No pasa nada si alguna vez se pierde alguna temperatura o llega desordenada o llega dos veces
Telefonía por internet Gasta menos ancho de banda No pasa nada si a veces se oye mal o se oye algo anterior o se pierde la voz
Video-llamada por internet Gasta menos ancho de banda No pasa nada si a veces se ve mal o se ve algo anterior o se pierde alguna imagen

Como vemos son aplicaciones en las que si hay algún fallo ocasional no hay ningún problema. Además que en general hay que decir que las redes no fallan tanto así que esos problemas ocurrirás pocas veces. Pero repito que si necesitamos fiabilidad, siempre habrá que usar TCP.

Ultimas consideraciones

Vamos ahora hacer uno pequeños comentarios o aclaraciones sobre TCP y UDP.

Son protocolos que solo existen en el Host origen y destino. Es decir los router no saber nada de TCP o UDP. Los router solo se dedican a enviar cosas a nivel de IP. Y es el Host origen y destino es que gestiona que se reenvien de nuevo los datagramas IP o tener en cuenta si falta alguno, etc.

Bueno, hay que decir que todos los routers tienen también el protocolo TCP pero debido a que queremos a ellos enviarles datos directamente por ejemplo para configurarlos. Es decir , aunque un router solo debería tener software para controlar el protocolo IP, en la práctica eso nunca se da ya que siempre el propio router tiene un servidor TCP montado para aceptar que se le configure.

Hay un riesgo en tener un proceso escuchado en un puerto. Si puede aceptar conexiones de cualquier ordenador del mundo, estamos expuestos a que un Hacker desde su ordenador se conecte por TCP a nuestro servidor y consiga hackearnos debido a cualquier error en nuestro software. Así que nunca es recomendable tener procesos escuchando en nuestro ordenador. Al hablar de los cortafuegos , volveremos a tratar este tema.

Nuevos protocolos de transporte

Hemos dicho que TCP es un protocolo muy lento mientras que UDP es rápido. El motivo de que TCP sea tan lento es que la comunicación es totalmente fiable aunque las comunicaciones físicas fallen mucho. TCP se creo en una época en que las redes fallaban mucho , así que había que hacer un protocolo muy robusto aunque fuera mas lento. Pero ya han pasado muchísimos años desde que se creo en 1973 y ahora las redes no fallan casi , así que toda esa seguridad que nos ofrece TCP no es necesaria.

¿Porque cuento ésto ? Porque se quiere crear un protocolo para la Web que no esté basado en TCP. Pero los sistemas operativos está todos ya programados únicamente con TCP y UDP así que cambiar a uno nuevo no sería fácil. Sería algo tan complejo como pasar de IPv4 a IPv6, así que este nuevo protocolo para la Web lo van a hacer sobre UDP. ¿?????

Me explico, UDP entrega ya "datos", ¿Porque no nos encargamos nosotros de hacer lo que hace TCP pero con UDP y así que no hay que tocar nada de Internet? Pues esa es la idea en la que están trabajando y se llama HTTP/3 o QUIC. Ya veremos como acaba pero al menos que entendamos que están haciendo cuando nos digan que nuestro nuevo servidor Web escucha en un puerto UDP.

Os recomiendo leer los dos artículos solo para ver si ,después de toda la teoría de redes que lleváis , sois capaces de entender la mayoría de cosa que ponen ahí. Ya que algún día igual debéis decidir si queréis en vuestros servidores Web usar HTTP/3

Ejercicios

Ejercicio 1

  1. Busca 4 programas informáticos que se comuniquen por IP e indica, el protocolo de transporte que usa y el puerto del servidor. Al menos uno de ellos deberá usar UDP y no puedes repetir los ejemplos que he usado en los apuntes
  2. Si desde nuestro Linux nos conectamos por SSH a la IP 8.8.8.8. ¿cual serán los "datos" de la conexión? Es decir los puertos e IPs
  3. Si tenemos una aplicación de mensajería instantánea de ordenador a ordenador (tipo Whatsapp o Telegram) pero sin pasar por un ordenador central. El programa que nos instalamos, ¿hace de cliente o de servidor?
  4. Si tenemos una aplicación de mensajería instantánea cuyas comunicaciones pasan por un servidor central. El programa que nos instalamos, ¿hace de cliente o de servidor?

Ejercicio 2

Si enviamos 1024 Bytes de datos por TCP

  1. ¿cuantos bytes se envían como mínimo realmente en el segmento TCP?
  2. ¿cuantos bytes se envían como mínimo realmente en el datagrama IP?
  3. ¿cuantos bytes se envían como mínimo realmente en la trama Ethernet ?

Ejercicio 3

Si enviamos 1024 Bytes de datos por UDP

  1. ¿cuantos bytes se envían como mínimo realmente en el segmento UDP?
  2. ¿cuantos bytes se envían como mínimo realmente en el datagrama IP?
  3. ¿cuantos bytes se envían como mínimo realmente en la trama Ethernet ?

Ejercicio 4

Para responder a las siguientes preguntas , siempre hablamos de límites teóricos, que no están limitados por cuestiones de memoria RAM, CPU, etc.

  1. Cuantos puertos tiene como máximo por TCP un Host
  2. Cuantos puertos tiene como máximo por UDP un Host
  3. Si un servidor ya tiene todos sus puertos TCP en uso, ¿puede enviar algo por UDP?
  4. ¿Podemos estableces desde 2 procesos de SSH conexión al mismo Host destino? Si la respuesta es afirmativa, indica como no se equivoca el Host destino a que proceso al devolver información cada información.

Ejercicio 5

  1. Si un proceso está usando el puerto 34567 por TCP, ¿puede otro proceso conectarse al mismo puerto TCP?
  2. Si un proceso está usando el puerto 34567 por TCP, ¿puede otro proceso conectarse al mismo puerto UDP?
  3. Si un proceso está usando el puerto 34567 por UDP, ¿puede otro proceso conectarse al mismo puerto TCP?
  4. Si un proceso está usando el puerto 34567 por UDP, ¿puede otro proceso conectarse al mismo puerto UDP?

Ejercicio 6

  1. Si un proceso está usando el puerto 34567 por TCP, ¿puede el mismo proceso conectarse el puerto 12345 TCP?
  2. Si un proceso está usando el puerto 34567 por TCP, ¿puede el mismo proceso conectarse el puerto 12345 UDP?
  3. Si un proceso está usando el puerto 34567 por UDP, ¿puede el mismo proceso conectarse el puerto 12345 TCP?
  4. Si un proceso está usando el puerto 34567 por UDP, ¿puede el mismo proceso conectarse el puerto 12345 UDP?

Ejercicio 7

  1. Si un proceso está usando el puerto 34567 por TCP como cliente, ¿puede el mismo proceso conectarse al mismo puerto TCP como servidor?
  2. Si un proceso está usando el puerto 34567 por TCP como cliente, ¿puede el mismo proceso conectarse al mismo puerto UDP como servidor?
  3. Si un proceso está usando el puerto 34567 por UDP como cliente, ¿puede el mismo proceso conectarse el puerto 12345 TCP como servidor?
  4. Si un proceso está usando el puerto 34567 por UDP como cliente, ¿puede el mismo proceso conectarse el puerto 12345 UDP como servidor?

Ejercicio 8

  1. Si te conectas a MySQL indica como se llama el programa de hace de cliente y como se llama el programa que hace de servidor
  2. Si te conectas a un servidor Web indica como se llama el programa de hace de cliente y como se llama el programa que hace de servidor
  3. Si te conectas por SSH a Linux indica como se llama el programa de hace de cliente y como se llama el programa que hace de servidor

Ejercicio 9

  1. Usando un cliente de MySQL , indica como puedes especificar la IP y el puerto en el que está escuchando el servidor de MySQL.
  2. Usando un navegador Web, indica como puedes especificar la IP y el puerto en el que está escuchando el servidor Web.
  3. Usando putty, indica como puedes especificar la IP y el puerto en el que está escuchando el servidor de SSH.

Ejercicio 10

NOTA: Este ejercicio es opcional

Según lo que has hecho en los ejercicios 2 y 3:

  • Haz una formula que dado el Nº de bytes a enviar por TCP calcule el % de sobrecarga mínimo de datos que se envían por Ethernet debido a todos los protocolos que encapsulan la conexión. Por ejemplo si queremos enviar 10 bytes de datos y por Ethernet se envía finalmente 13 datos , El % de sobre carga sería del 30%
  • Haz una formula que dado el Nº de bytes a enviar por UDP calcule el % de sobrecarga mínimo de datos que se envían por Ethernet debido a todos los protocolos que encapsulan la conexión. Por ejemplo si queremos enviar 10 bytes de datos y por Ethernet se envía finalmente 13 datos , El % de sobre carga sería del 30%
  • Haz una gráfica en la que se vean las 2 fórmulas que has creado (Para TCP y UDP).
    • En el eje X contendrá el tamaño de los datos a enviar
    • En el eje Y contendrá el % de sobre carga.
  • Teniendo únicamente en cuenta el % de sobrecarga, ¿en que casos sería mejor usar TCP y en que casos sería mejor usar UDP?
1)
Telefonía por internet
2)
Televisión por Internet
3) , 4)
programa en ejecución
5)
Al ver la cabecera IP comprobaremos que el puerto es un número de 16 bits
6)
podría ser en el mismo puerto si uno es por TCP y el otro por UDP
7)
Realmente si que podemos indicar que puerto queremos usar como cliente pero no suele ser muy habitual
8)
o a varios, como él quiera
clase/daw/si/3eval/tema17.txt · Última modificación: 2021/05/10 13:05 por admin