Funcionamiento Protocolo TCP-IP

Para entender a profundidad el funcionamiento y la forma de cómo interactúan estos

protocolos entre si, vamos primero que todo a explicar cada uno de ellos de manera
individual ilustrando algunos ejemplos y luego vamos a relacionarlos en conjunto.
La capa IP: para comprender la necesidad del protocolo IP vamos a situarnos en un
escenario que nos permita explicarlo de una manera comprensiva, como lo es el correo
postal.
En nuestro ejemplo ilustrativo tendremos como protagonista al señor Andrés el cual
reside en Madrid, el cual quiere enviar una carta a la siguiente dirección:
Francisco Peláez
Av. Litoral, 30 - 08005 Barcelona
La pregunta del millón ¿cómo puede llegar esta carta a su destino, Después que Andrés
la inserte en el buzón de mensajes de su barrio? Todos conocemos bien el proceso.
Primero el cartero del barrio la recoge y las lleva a la oficina de correos más cercana.
Una vez ahí, observan que el destino es Barcelona y por lo tanto el sobre es
transportado hasta dicho destino en un furgón de correos. Una vez que el camión ha
llegado a Barcelona la lleva a la oficina de correos más cercana de la dirección de
destino, en esa oficina comprueban la dirección y llevan la carta al buzón personal de
Francisco Peláez.
Gracias a las direcciones postales todo el sistema de correos puede funcionar. Tanto la
dirección de origen como la dirección de destino hacen posible que haya interacción de
extremo a extremo, ya que gracias a la dirección de origen se sabrá a quien informar si
la carta no llega a su destino, y el destinatario podrá responder a la carta si lo desea
estas direcciones deben contener como información extra (nombre, calle, código postal,
población y provincia).
En internet sucede exactamente lo mismo con la direcciones IP aunque es importante
aclarar que las direcciones IP no van a llevar como información extra el nombre, la
calle, población, etc. En realidad esos campos si existen pero se expresan de una manera
diferente y están codificados dentro del propio número que forma la dirección IP.
Como pudimos observar dentro del sistema de correo postal existen oficinas que se
encargan de transportar y verificar información en internet también existen maquinas
dedicadas a realizar este tipo de analogías, estas máquinas mediadoras habitualmente
denominadas Router se dedican a analizar direcciones IP para saber dónde tendrá que
enviar el sobre para que paso a paso termine llegando a su destino.
La capa TCP: Para entender este complejo protocolo vamos a emplear un escenario que
nos permita explicar de una manera comprensible el funcionamiento y la importancia
que implica en una comunicación.
Ejemplo 1
Vamos a situarnos en un hospital, como podemos observar en la imagen el doctor PyC
recibe un mensaje de urgencia atravez del servicio de megafonía del hospital. Pero ¿Qué
ocurriría si el doctor PyC no estuviese en el hospital o si estuviese en ese momento
escuchando música y escuchara el mensaje? Cuando la persona que está transmitiendo el
mensaje por megafonía él tiene cierta confianza en que el mensaje llegara a su
destinatario, pero en realidad no se tiene una certeza sobre el desenlace del mensaje que
se está transmitiendo. Es decir sueltas el mensaje al vacío y no tienes la forma de saber
si al otro lado hay alguien escuchando. Esto es lo que se llama una comunicación no
orientada a conexión.
Pueden existir muchas soluciones para este caso, por ejemplo, en el caso de la megafonía
del hospital si el doctor PyC no responde al aviso en cierto tiempo, probablemente le
volverá a llamar pero como sabemos no es una solución fiable o acertada. En algunos
casos la comunicación no orientada a conexión es suficiente cuando no necesitamos que
del otro lado nos escuche, entonces por ende no necesitaremos un protocolo de
transporte fiable como lo es el protocolo TCP, sí no que solo bastaría utilizar un
protocolo no orientado a conexión como lo es el UDP.
El protocolo TCP podemos clasificarlo como pesado por que al estar orientado a
conexión consume muchos más recursos de red, es decir el proceso para establecer una
comunicación de este tipo estar formada por muchos procedimientos.
Vamos hablar un poco del protocolo UDP, a diferencia del protocolo TCP, este lo
podemos considerar como un protocolo ligero por que al no estar orientado a conexión
consume pocos recursos de la red y el procedimiento para entablar una comunicación no
va llevar mucho proceso o complicaciones. El uso de este este protocolo se puede ver
reflejado en la emisión de video por internet o los programas de intercambio de archivos.
Para que se entienda el uso de este protocolo, en la transmisión de video en tiempo real
por internet lo que interesa el que el receptor capte la mayor cantidad de información
posible en el menor espacio de tiempo posible, no importa si se pierden unos cuantos
frames de la película por el camino (es imperceptible) lo importante es que la película no
se pare y se pueda ver fluida en tiempo real.
Sería absurdo emplear en este caso como protocolo el TCP, ya que si por ejemplo el
frame 7 falta o no llega, se parase la película, pidiendo nuevamente al emisor el frame
que hace falta y tendríamos que esperar nuevamente su llegada, su comprobación y de
esta manera la película continuaría su trayecto. Ahora pensemos algo caótico
imaginemos que llega entre 15 a 30 frames por segundo buff estaríamos parando la
película cada dos por tres, es mejor despreciar ese frame que hace falta y seguir con la
peli. En caso de los programas de intercambio de información (P2P), si varios usuarios
están descargado un programa llamado office.zip que pesa aproximadamente 800 MB
este nos llegaría en fragmentos pequeños, lo importante es que no lleguen cuanto más
fragmentos mejor y en el menor espacio de tiempo posible, pero claro está que no
debemos perder ningún fragmento o sino el Zip a la hora de descomprimir el archivo nos
dará errores.
En este caso pensaríamos que es mejor utilizar el protocolo TCP puesto a que nos
asegura la llegada de cada fragmento, pero entonces viene una problemática con este
paso, estaríamos sobrecargando la red P2Pcon centenares de peticiones de
comprobación y la descarga sería muy lenta ¿Cómo resolvemos esto? Pues trabajamos
con el protocolo UDP y hacemos que sea el programa P2P quien compruebe si faltan
fragmentos. En caso de faltar un trozo se reclama y en caso de no faltar no se reclama.
Para que quede claro en qué ambiente o en qué tipo de comunicación se debe utilizar
cada protocolo vamos a elaborar un escenario que nos permita explicarlo un poco más
claro.

Ejemplo 2
Retomemos de nuevo el escenario del hospital con el doctor PyC y nos vamos a centrar
en un ambiente P2P.
El doctor en este caso hará el papel de receptor y recibe por megafonía un mensaje
(archivo) pero la persona que está emitiendo el mensaje por el megáfono es muy
exigente y obliga al doctor que confirme la correcta recepción de cada palabra que se
emitió en el mensaje.
El mensaje que se está emitiendo emplea el siguiente contenido: Preséntese
inmediatamente al quirófano.
-La persona del megáfono emite la primera palabra (primera parte del archivo)
PRESENTESE
-El pobre doctor va corriendo a un teléfono, llama al tipo del megáfono y le dice que ha
recibido correctamente la palabra (fragmento del archivo) PRESENTESE
- La persona del megáfono emite la primera palabra (primera parte del archivo)
INMEDIATAMENTE
- El pobre doctor va corriendo a un teléfono, llama al tipo del megáfono y le dice que ha
recibido correctamente la palabra (fragmento del archivo) INMEDIATAMENTE
-Y así seguiremos hasta que el doctor confirme la llegada de la última palabra
QUIROFANO en ese momento el doctor (receptor) une todas las palabras (o todos los
fragmentos del archivo) y obtiene el mensaje (archivo) PRESENTESE
INMEDIATAMENTE EN EL QUIROFANO.
Como podemos ver la comunicación es 100% segura, el doctor confirma la llegada de
cada palabra, pero se ha invertido mucho tiempo y muchas llamaditas de confirmación.
Ejemplo 3
Doctor en un sistema UDP en un mundo P2P
En este caso el doctor PyC recibe el mensaje por megafonía pero la persona del
megáfono (emisor) es muy despreocupada y no le importa si el doctor PyC reciba o no el
mensaje.
-La persona del megáfono emite la primera palabra (primera parte del archivo)
PRESENTESE
-El doctor en teoría recibe la primera palabra (primera parte del fragmento del archivo)
PRESENTESE
- La persona del megáfono emite la segunda palabra (Segunda parte del fragmento del
archivo) INMEDIATAMENTE
El doctor en teoría recibe la primera palabra (primera parte del fragmento del archivo)
INMEDIATAMENTE
-Seguiríamos así hasta que el doctor en teoría recibe la última palabra (ultimo
fragmento del archivo) y en ese momento el doctor uniría todas las palabras (fragmentos
del archivo) obteniendo el mensaje completo (archivo).como podemos ver la
comunicación es mucho más rápida (nos ahorramos las confirmaciones) pero, si el doctor
estaba tomándose un café quizá prefiere acabárselo antes de acudir al quirófano (y
seguro que su paciente muere desangrado).
En el caso de la emisión de video por internet en tiempo real ya hemos dicho que no nos
importaba perder unos cuantos frames, pero en el caso de P2P queremos todos los
trocitos del archivo, y queremos que el doctor PyC no deje morir a su paciente ¿cómo lo
solucionamos si no queremos utilizar el sistema TCP?
Como podemos observar tenemos un problema: no queremos sobrecargar la red
telefónica del hospital confirmando cada palabra que recibimos, pero queremos
asegurarnos de reci9bir los mensajes completitos. Muy bien pues en este caso tendremos
que dotar a los intervinientes (la persona del megáfono y el doctor un poquito de
inteligencia)
A cada uno se le asociara un software se reúnen y después de un buen rato discutiendo
el problema llegan a una solución y deciden utilizar el protocolo UDP, pero cada
palabra emitida estará procedida de un número que la identifique (número de control).

Ejemplo 4 Doctor en un sistema UDP en un mundo P2P con control añadido

El doctor PyC recibe por megafonía un mensaje (archivo) con un sistema previamente
pactado.
El mensaje que se está emitiendo es el siguiente: PRESENTESEINMEDIATAMENTEEN
EL QUIROFANO

Aquí viene lo interesante según lo pactado en cada palabra que se transmita debe lleva
un número, entonces seria de esta manera (uno-preséntese, dos-inmediatamente, tres-en
cuatro- el cinco-quirófano)
-La persona del megáfono emite la primera palabra (primera parte del archivo) UNO-
PRESENTESE
-El doctor en teoría recibe la primera palabra (primera parte del fragmento del archivo)
UNO-PRESENTESE
- La persona del megáfono emite la segunda palabra (Segunda parte del fragmento del
archivo) DOS-INMEDIATAMENTE
El doctor en teoría recibe la primera palabra (primera parte del fragmento del archivo)
DOS-INMEDIATAMENTE
-Seguiríamos así hasta que el doctor en teoría reciba la última palabra del mensaje. En
ese momento el software que tiene asociado el doctor comprobaría que tiene en su poder
las palabras y que no falta ninguna de ellas (gracias a este sistema se puede comprobar
ya que cada palabra tiene un numero identificativo) ¿pero cuál sería la ventaja de este
sistema? En caso que de que faltara alguna palabra el doctor PyC llamaría por teléfono
al emisor pidiéndole únicamente la palabra que falta. Como podemos ver, la conexión
sigue siendo UDP y estamos cargando un poco la red, pero gracias a que hemos dotado a
la persona del megáfono y al doctor con un software cada uno de ellos hemos conseguido
seguridad en la comunicación.

Nota: Una cosa es el tipo de protocolo que estamos utilizando para nuestras conexiones
(TCP o UDP e incluso ambas a la vez)y sus consecuencias sobre la red, pero una cosa
muy distinta es como programamos el software para mejorar el rendimiento de dichas
conexiones
Hemos visto que las carencias de seguridad del protocolo UDP (capa de transporte) han
sido salvadas gracias a como hemos programado el software (nivel de aplicación)