Imagina un escenario simple donde una aplicación web de comercio electrónico llama a un punto final de API que devuelve información sobre un pedido de cliente. A nivel de aplicación, esto parece una operación bastante simple. Pero hay mucho happening debajo del capó.

Primero, el cliente consulta el DNS para obtener la dirección IP vinculada al punto final de la API. El DNS puede devolver la dirección de un balanceador de carga en lugar de la dirección de un servidor de aplicaciones específico. Luego, el sistema operativo determina cómo deben enviarse los paquetes a esa dirección IP.

Puede elegir enviarlos a través de la red local, un proveedor de servicios de Internet (ISP) o varios otros routers. El objetivo ultimate es que los paquetes de datos lleguen a la red de destino. El protocolo más común utilizado para esto es HTTP.

Sin embargo, antes de que HTTP pueda enviar la solicitud, el cliente generalmente necesita establecer alguna forma de conexión con el servidor de destino. Con HTTPS tradicional, esto significa establecer una conexión TCP. En este tipo de conexión, el cliente y el servidor realizan un handshake intercambiando algunos paquetes iniciales para que ambos lados sepan que se ha establecido una conexión.

Luego, el cliente y el servidor realizan un handshake de TLS. Solo después de esto se puede enviar la solicitud HTTP de manera segura. Un balanceador de carga lo recibe, selecciona una instancia de aplicación saludable y reenvía la solicitud.

La aplicación realiza su trabajo y envía la respuesta de vuelta por el mismo camino. Todo esto cae bajo el ámbito de las redes. Debido a su naturaleza ubicua, las redes se convierten en una disciplina extremadamente importante para que los desarrolladores la dominen.