Erklär mir Schritt für Schritt alles, was passiert, wenn ein Client einen HTTPS-Request an deinen Service schickt.

Der Client löst den Hostnamen per DNS auf, öffnet eine TCP-Verbindung zur aufgelösten Adresse oder nutzt eine bestehende weiter, und macht dann einen TLS-Handshake, der das Serverzertifikat validiert und Session Keys aushandelt. Der verschlüsselte Request läuft über Load Balancer und Proxies zu deiner Anwendung, die ihn verarbeitet und eine Antwort über dieselbe Verbindung zurückschreibt. Keep-Alive und HTTP/2-Multiplexing lassen spätere Requests den größten Teil des Setups überspringen.

Zuerst braucht der Client eine Adresse, er schaut also in seinen eigenen Cache, dann in den Resolver des Betriebssystems, dann zu einem rekursiven Resolver, und bekommt eine IP mit einer Time to Live zurück. Dann ein TCP-Handshake zu dieser Adresse, außer es liegt schon eine offene Verbindung im Pool, was meistens der Fall ist. Dann TLS: Der Server präsentiert eine Zertifikatskette, der Client validiert sie gegen seinen Trust Store und prüft, ob der Hostname passt, und beide handeln Session Keys aus. Mit TLS 1.3 ist das ein Round Trip, oder null bei einer wiederaufgenommenen Session. Der Request geht verschlüsselt raus und trifft in der Praxis zuerst auf ein CDN oder einen Load Balancer, der meist TLS terminiert und eine eigene Verbindung zu meinem Service öffnet. Meine App verarbeitet ihn und die Antwort kommt denselben Weg zurück. Der Grund, warum mich die Reihenfolge interessiert, ist Latenz: Auf Mobilgeräten bezahlt der erste Request DNS plus TCP plus TLS, bevor ein einziges Byte meines Codes läuft, Verbindungswiederverwendung ist also oft der größte verfügbare Gewinn.