Pull to refresh

Comments 20

Мы тут посовещались, и решили что мы его не берем, ответ на вопрос был крайне поверхностный, т.к. кандидат не рассказал откуда в розетке берется электричество для работы пк)

Не очень понял два момента:

1) сначала вы пишите что DNS идет от кешей->роутер-провайдер и дальше и дальше к более глобальным серверам, пока не найдет нужную запись. А далее вы пишите про рекурсивные запросы где вы как пишите сначала корневой сервер дает более нисходящие сервера потом запрос к ним и они уже дают на ещё более точечные сервера.

Так какое направление то? определитесь.

2) вы пишите про проверку сертификата браузером, но если очистить все кэши и удалить системные сертификаты, то через wireshark я не вижу что существуют запросы к "центру сертификации" для проверки что отданный сертификат сервером является верным. Как это работает на самом деле?

В сертификатах используется очень умная криптография, а именно алгоритмы асинхронного шифрования (например, RSA), которыми можно "подписать" сертификат.

Такую подпись подделать практически невозможно.

В сертификате указывается центр сертификации, который выдал сайту сертификат. Эту информацию тоже не получится подделать из-за подписи. В Винде есть каталог предустановленных доверенных корневых сертификатов, от которых и идут сертификаты для всех сайтов. Поэтому компьютер сам способен определить подлинность отправленного сайтом сертификата, даже если нет интернета. Запросов в центр сертификации не требуется.

по первому пункту: от юзера запрос идёт снизу вверх (браузер -> роутер -> провайдер -> dns), попав на DNS сервер, запрос начинает спускаться вниз, от общего к частному, например для taxi.yandex.ru = .ru -> yandex-> taxi)

Если вы удалите все CA с устройства и хранилища браузера, то тот будет ругаться на любое https соединение.

Ну что ж, рассказывают про базовые вещи. mailto://my@name.to

chrome://flags

Спорим, ваш El Tomate, который придумал задавать такой вопрос, не подумал про подвох?

Я думаю, что вместо очередного краткого пересказа и без того простой статьи с MDN лучше было чутка подробнее рассказать про какой-нибудь сложный и интересный кейс в этом всем процессе.

Такое поверхностное описание - это даже не уровень джуна, если честно. Если говорить про собеседования, с которых вы начали.

Рассмотрим именно загрузку статических страниц, хотя для фреймворков процесс будет немного сложнее.

И чем же?

Я отталкивался именно от собеседований и от краткости отвта, потому что прям в подробностях знать это кандидату не нужно, нужно что бы он просто понимал суть.

Так нет абсолютно никакой разницы. Фрейморк - это просто объединение готовых механизмов по своей сути. Дальше все стандартно со стороны работы браузера.

Дело в том, что сути в таком "ответе" очень мало, фактически глубины знаний здесь для тех. собеса маловато, особенно для мидла. Более того, не так важно, в каком кеше хранится таблица для DNS. Для фронтенд разработчика куда важнее этап общения между сервером, когда HTML начинает парситься браузером и как часто и по каким причинам браузер производит отрисовку.

Какой механизм задействован при парсинге. Как браузер понимает, что это конкретный элемент. Почему бразуер не продолжает парсить html, пока не обработает JS. Что происходит при обработке JS. И куча куча нюансов, по которым можно понимать глубину знаний и понимания, что на самом деле происходит.

Все таки, техническое интервью оно на то и техническое. А вот такая статья - это популистский материал.

Для middle и react разработчика ответ вполне допустим, но не более того.

Начиная с формулировки "что происходит после нажатия на enter" (после нажатия на enter в первую очередь ОС регистрирует нажатие клавиши и передаёт нажатие активному окну, потом происходит много магии перед тем, как браузер решает "пользователь хочет открыть такой-то сайт), заканчивая сумбурным ответом по поводу DNS (порядок далеко не всегда такой, к рутам ходят в реальности очень редко, всё обмазано кешами) и отсутствия информации про различные DoH (или я пропустил?), которые могут быть как на стороне браузера, так и на роутере.

Не увидел нюансов про HTTP/1.1, HTTP/2, лимит на количество параллельных скачиваний с одного домена и для одной страницы и многое другое.

С сертами тоже есть масса нюансов ну и так далее.

В качестве рерайта или обзора нормальной доки - сойдёт, в остальных случаях - откровенно слабо.

p.s. Я не смогу пол дня вещать как на картинке в комментах, но на собесе однажды у меня было подобное - меня спросили, как происходит загрузка Linux, попросив рассказать максимальной подробно.. на 20й минуте я дошёл до загрузки systemd и мне сказали "дальше можно не продолжать, верю что вы знаете" - но ведь они сами попросили ;))

Ой, ну задушнил, задушнил, я бы тебя не взял, потом работать замучаешься с тобой, ахаха)

Про ДНС фигню написали, начиная с ближайшего- какой еще ближайший? Почему провайдера?

Ну и вообще нахрена фронтенд разработчику в деталях разбираться в модели OSI?

По моему это звоночек, услышать такие вопросы на собеседовании

Идеальный вопрос. Про ответ на него всегда можно сказать, что ответ был не полный.

С другой стороны понятно можно ли дальше работать с этой не полнотой.

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

Sign up to leave a comment.