Что происходит при открытии сайта на сетевом уровне

Что проверяют

Видите ли вы путь запроса целиком, а не только свой обработчик. Для бэкендера важна вторая половина пути: что происходит с соединением после балансировщика и почему приложение на Python вообще получает запрос.

Как отвечать

Идти по шагам, не проваливаясь в детали, пока не спросят:

• разбор URL и проверка кэшей: браузер смотрит свой кэш, список HSTS, потом кэш операционной системы и файл hosts;
• DNS: резолвер обходит корневые серверы, серверы зоны и авторитативный сервер домена, отдаёт запись A или AAAA, ответ живёт по TTL;
• TCP: трёхстороннее рукопожатие SYN, SYN-ACK, ACK с нужным адресом и портом;
• TLS: для https поверх TCP идёт рукопожатие с проверкой сертификата и согласованием ключей, дальше трафик шифруется;
• HTTP: браузер шлёт строку запроса и заголовки Host, Cookie, Accept-Encoding;
• сервер: запрос принимает обратный прокси, статику отдаёт сам, а динамику передаёт приложению через WSGI или ASGI. Воркер выполняет код, ходит в базу и кэш, возвращает ответ;
• ответ: статус, заголовки, тело. Браузер разбирает HTML и дозапрашивает стили, скрипты и картинки, обычно по тому же соединению.

Хорошо добавить, что делали руками: смотрели dig, curl -v, искали, на каком участке теряется время.

Где спотыкаются

Останавливаются на DNS и HTTP, пропуская TLS. Вопрос почти всегда задают ради шифрования: кто кому предъявляет сертификат, зачем нужен SNI и что даёт возобновление сессии.

Второе: считают, что на каждый ресурс открывается новое соединение. Так было в ранних версиях протокола, сейчас работает keep-alive, а HTTP/2 мультиплексирует запросы в одном соединении.

Третье: на бэкенд-собеседовании не доводят рассказ до своего кода. Про количество воркеров, таймауты прокси и пул соединений к базе спрашивают ровно потому, что там и живут настоящие аварии.