Vamos a hacer un resumen de lo visto hasta ahora y de esa forma ver donde encaja el protocolo TCP.
¿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:
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:
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:
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
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:
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. )
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)
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.
Fijémonos ahora en un detalle. Damos por hecho que cualquier ordenador se puede conectar con cualquier otro ordenador. Pues realmente no es así.
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:
Supongamos que queremos conectarnos con el protocolo TCP.
Ahora debemos elegir a que puerto del ordenador destino (192.168.4.123):
Supongamos que queremos conectarnos al 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:
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.
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.
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:
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:
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:
Pasemos ahora a ver el formato de la cabecera del segmento
Los campos que nos interesan son los siguientes:
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.
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:
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.
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.
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.
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
Si enviamos 1024 Bytes de datos por TCP
Si enviamos 1024 Bytes de datos por UDP
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.
NOTA: Este ejercicio es opcional
Según lo que has hecho en los ejercicios 2 y 3: