Что происходит при вводе google.com в браузере?
Что проверяют
Кругозор за пределами своего кода: понимаете ли вы, как запрос доходит до приложения и как ответ превращается в страницу. Питонисту вопрос задают ещё и ради границы ответственности, то есть где кончается сеть, где начинается веб-сервер и где ваш код.
Как отвечать
Ведите рассказ слоями, от адресной строки к своему коду и обратно:
- браузер разбирает ввод, дописывает схему, сверяется со списком HSTS и для известных доменов сразу идёт по HTTPS;
- разрешение имени: кэш браузера, кэш операционной системы, затем рекурсивный резолвер провайдера, который спрашивает корневые серверы, серверы зоны и авторитативный сервер; ответ кэшируется на время TTL, поэтому у популярных доменов запрос обычно не выходит за пределы провайдера;
- соединение: рукопожатие TCP или QUIC поверх UDP, затем TLS, где через SNI выбирается сертификат, а через ALPN версия протокола;
- запрос попадает на ближайшую точку присутствия, балансировщик снимает шифрование и передаёт его внутрь;
- ваш слой: фронтовый веб-сервер отдаёт статику сам, а динамику проксирует в WSGI- или ASGI-сервер, тот вызывает приложение, приложение ходит в базу и кэш и возвращает ответ;
- браузер разбирает HTML, строит DOM и CSSOM, блокируется на синхронных скриптах, считает раскладку и красит.
Где спотыкаются
Заучивают список шагов и сыплются на первом уточнении. Лучше назвать пять слоёв и уметь развернуть любой, чем перечислить пятнадцать пунктов и не суметь объяснить, чем рекурсивный резолвер отличается от авторитативного.
Называют конкретный адрес и незащищённый порт. У крупных сайтов за одним именем стоят разные адреса в разных сетях, а на незащищённом порту в лучшем случае редирект, которого браузер с предзагруженным списком HSTS даже не увидит.
Молчат про собственный уровень. Вопрос задан питонисту не ради DNS: ждут слов про воркеры, про то, что синхронное приложение занимает воркер целиком на всё время запроса, и про таймауты между прокси и приложением.