Piénsalo de esta manera. Los presidentes de dos países quieren comunicarse entre sí. El problema es que ambos países hablan idiomas completamente diferentes e imagínense que solo hay un traductor disponible en todo el mundo que puede hablar ambos idiomas con fluidez. Entonces el presidente P1 se comunica con su secretaria S1 en el lenguaje L1. S1 transfiere el mensaje del presidente al traductor T en el lenguaje L1. T luego convierte el mensaje a L2 y lo transfiere al secretario S2, quien a su vez lo comunica al presidente P2.
Esta es una analogía muy simplificada de cómo funciona la conexión TCP de extremo a extremo. Básicamente, a partir del ejemplo, puede inferir que es el trabajo de la secretaria respectiva llevar el mensaje. Cualquiera de los presidentes es ajeno al hecho de que su mensaje se ha convertido a otro idioma.
En la pila TCP / IP real, su aplicación (es decir, el presidente) no necesita preocuparse por cosas como
- hardware subyacente (por ejemplo, su NIC) presente en el sistema,
- si el mensaje se transmite a través de WiFi, ethernet o bluetooth o ZigBee o cualquier otro estándar
- Qué esquema de red (IPv6 o IPv4) se está siguiendo.
Simplemente puede crear sockets (análogos a la secretaria) y simplemente entregar el mensaje a la secretaria.
Ahora imagine que el traductor no es realmente fluido en el lenguaje L2. Entonces, el mensaje de que está transfiriendo a S2 tiene algunos errores. S2 es fluido en el lenguaje L2 nota inmediatamente este error pero no conoce la fuente de este error. Podría haber ocurrido en cualquier etapa del sistema y este mensaje no se puede dar al presidente debido a su naturaleza errónea. Entonces, envía un mensaje de regreso diciendo que ese mensaje no se recibió. S1 lo recibe pero lo mantiene alejado de P1. Ahora todo el proceso se repite con S1 enviando de nuevo el mensaje P1s. Ahora supongamos que milagrosamente T es capaz de representar la traducción correcta esta vez y P2 recibe el mensaje. Esta es nuevamente una versión muy simplificada de confiabilidad en la comunicación de extremo a extremo a través de TCP.
Ahora imagine que P1 tiene que comunicarse con otro presidente P3 de otro país lingüísticamente diferente. P1 no puede enviar el mensaje a S1 ya que él ya está ocupado comunicándose con su contraparte S2. Entonces, contrata a otra secretaria S3 para transmitir sus mensajes a P3 a través de un traductor T igual o diferente (¡por supuesto, dependiendo de la capacidad de T para traducir L3 si no se contrata a otro traductor T3!). Se lleva a cabo exactamente el mismo proceso descrito anteriormente. La ventaja de usar un sistema de este tipo es ahora evidente. P1 ahora puede simplemente seguir transmitiendo su mensaje a quien quiera sin tener que preocuparse demasiado de cómo se transmite el mensaje.
Esto es exactamente lo que sucede cuando abres múltiples pestañas / ventanas del navegador. ¿Alguna vez se preguntó por qué digamos que si consulta Google en una pestaña y Yahoo en la otra, ambas aparecen en las pestañas respectivas desde las que se realizaron las consultas? Después de todo, ambas consultas eran de la misma aplicación (es decir, navegador o en nuestro caso P1). Esto sucede porque se abre un socket diferente para cada pestaña que segrega los datos en las pestañas respectivas. Este caso es análogo a que las pestañas son las diferentes secretarias (S1 y S2) y que el navegador es el presidente P1.
Este concepto de abstracción es lo que mantiene internet o, para el caso, cualquier tipo de red informática. Proporciona una gran flexibilidad entre dispositivos con la red y también con respecto a la escritura de aplicaciones. ¡Imagina tener que escribir una aplicación desde cero!
