Cuéntame todo lo que pasa cuando un cliente envía una petición HTTPS a tu servicio.

El cliente resuelve el nombre por DNS, abre una conexión TCP a la dirección resuelta o reutiliza una existente, y luego completa un handshake TLS que valida el certificado del servidor y acuerda las claves de sesión. La petición cifrada viaja por balanceadores y proxies hasta tu aplicación, que la atiende y escribe una respuesta de vuelta por la misma conexión. El keep alive y la multiplexación de HTTP/2 permiten que las peticiones siguientes se salten casi toda la preparación.

Primero el cliente necesita una dirección, así que mira su propia caché, luego el resolver del sistema operativo, luego un resolver recursivo, y recibe una IP con un tiempo de vida. Después un handshake TCP a esa dirección, salvo que ya haya una conexión abierta en el pool, que normalmente la hay. Después TLS: el servidor presenta una cadena de certificados, el cliente la valida contra su almacén de confianza y comprueba que el nombre coincide, y acuerdan claves de sesión. Con TLS 1.3 eso es un viaje de ida y vuelta, o cero en una sesión reanudada. La petición sale cifrada, y en la práctica llega primero a una CDN o a un balanceador, que normalmente termina TLS y abre su propia conexión a mi servicio. Mi aplicación la atiende y la respuesta vuelve por el mismo camino. La razón por la que me importa la secuencia es la latencia: en móvil la primera petición paga DNS más TCP más TLS antes de que se ejecute un solo byte de mi código, así que reutilizar conexiones suele ser la mayor ganancia disponible.