Comments 9
«Привет всем!
Меня зовут Андрей, я автор этого вебинара. Спасибо за ваши отзывы и комментарии!
Эта статья была написана для новичков, её основная цель — помочь тем, кто только начинает свой путь в веб‑разработке, понять общую картину. Мы специально упростили объяснения, чтобы начинающие могли легко разобраться, как работает клиентская часть веб‑приложений и какие задачи решает фронтенд.
Мы, конечно, понимаем, что в реальности процессы намного сложнее, и многие моменты можно было бы описать подробнее. Но для целей данной статьи мы постарались сделать акцент на базовых шагах, чтобы не перегружать новичков лишними техническими деталями.
Ещё раз спасибо за ваши замечания и предложения — постараемся их учесть при написании следующих статей!»
происходит следующее:
Браузер отправляет запрос на сервер через DNS для получения IP-адреса сайта.
После получения IP-адреса сервер отправляет браузеру HTTP-ответ с файлами сайта.
Браузер получает HTML, CSS и JavaScript файлы, и начинает процесс их обработки и отображения страницы.
Не пишите больше статьи...
Когда пользователь вводит URL-адрес в браузере, происходит следующее:
Браузер отправляет запрос на сервер через DNS для получения IP-адреса сайта.
После получения IP-адреса сервер отправляет браузеру HTTP-ответ с файлами сайта.
Браузер получает HTML, CSS и JavaScript файлы, и начинает процесс их обработки и отображения страницы.
У вас ошибка, вот так правильно:
Браузер отправляет запрос на сервер DNS для получения IP-адреса сайта.
После получения IP-адреса от DNS сервера, браузер отправляет серверу HTTP запрос. В случае с HTTPS перед самим запросом между сторонами происходит hand-shake с обменом ключей шифрования.
Браузер получает в ответе от сервера HTML
Браузер парсит HTML и может найти там ссылки на CSS, JS, картинки и т.п. И в зависимости от стратегии загрузки синхронно/асинхронно начинает их загружать
Ну это всё очень грубо говоря, прям совсем во все детали и нюансы вдаваться лень, ну основную суть ошибки я думаю вы поняли
Да это тоже не правильное, а крайне убогое описание.
Браузер отправляет запрос на сервер
На какой сервер? У ничего не знающего человек сложится мнение, что на тот сервер, на котором живёт сайт. В минимально правильной формулировке это должно звучать как «браузер отправляет запрос на DNS-сервер.
для получения IP-адреса сайта.
О господи. Сайто-центричное восприятие головного мозга. Действительно, нет порта кроме 80-го, и 443-й — пророк его.
В минимально правильной формулировке: не IP-адрес сайта, а IP-адрес хоста. Как а потому, что много сайтов может обслуживать один хост, равно как и один сайт может обслуживаться множеством хостов.
И тут мы подходим к более глобальному выводу.
Вместо этой строчки, что браузер делает запрос, надо было просто спрятать все эти детали за термином «резолвинг хоста». 20 лет назад @DmitryKoterov запостил на своем сайте (или на сайте проекта Денвер) статью похожего толка, и там итеративный процесс резолвинга хоста был великолепно и образцово описан — не сравнить с этим откровением девочки-эксперта.
Во-первых, а браузер ли отправляет DNS-запрос? Окей, в современных реалиях может быть и сам браузер. Но вообще это резолвинг хоста — это услуга, предоставляемая прикладному операционкой. Потому что, знаете ли, преобразовывать хостнейм в IP-адрес бывает нужно не только браузеру, но и SSH-клиенту, FTP-клиенту и вообще любому сетевому приложению.
Во-вторых, а отправляет ли вообще браузер или операционная система DNS-запрос? Результат преобразования хостнейма в IP-адрес может быть уже известен и закеширован, и тогда никакой запрос никто никуда не отправляет.
В-третьих, а точно ли именно запрос отправляет гипотетический браузер? А может не запрос, а запросы? А откуда браузер знает адрес DNS-сервера, которому нужно отправить запрос? За резолвингом скрывается уйма деталей об авторитетных и не-авторитетных NS-серверах, NS-записях, CNAME-записях, и всё это делает процесс сопоставления имени числовому адреса многоитеративным.
В-четвёртых, а что, если в URL вместо хостнейма уже зашит IP-адрес? Кому тогда браузер шлёт запрос с целью получения «IP-адреса сайта»?
И это только то, что касается первого пункта.
Второй пункт вообще-то должен быть не про отправку HTTP-запроса, а про установку TCP-соединения. Во-первых потому, что оно может и не установиться, и на этом процесс закончится. Во-вторых, потому что в рамках одного TCP-соединения можно быть отправлено несколько циклов HTTP-запрос/ответ, в-третьих, коль скоро вы упомянули HTTPS, то между вторым пунктом про установлении TCP-соединения с веб-сервером и третьим четвёртым пунктом про отправку HTTP-запроса должен быть пункт про TLS-handshake.
Браузер получает в ответе от сервера HTML, CSS и JavaScript файлы, и начинает процесс их обработки и отображения страницы.
Написано так, словно в ответ на единственный HTTP-запрос сервер вываливает клиенту сразу бандл из кучи «файлов», что не соответствует действительности.
Так это же описание грубое, на пальцах, не подробное, никто не претендовал на подробный разбор, в контексте статьи это просто браузер и сайт. Понятное дело что в обобщенном виде это клиент и хост/сервер. Понятное дело что DNS может резолвить как операционка, так и браузер, так и вообще в целом любое приложение если захочет разработчик. И т.д. и т.п. Если подробно описать весь путь, в том числе через посредников в виде nginx, haproxy, apache и т.п. с разбором заголовков, это тема для отельной подробной статьи, а не общего интродакшена в общую суть дела.
Начнём с того, что ваш коммент был сильно изменён по сравнению с его первоначальной редакцией (о чём свидетельствует иконка-карандашик напротив даты/времени публикации), на которую я отвечал. Сейчас получается, что я как будто бы критикую ваш коммент в его текущем виде, а ведь в своём текущем виде он не так плох, как был изначально.
Так это же описание грубое, на пальцах, не подробное, никто не претендовал на подробный разбор
Подождите-ка. «Грубое» и «подробное» это не две крайности и не две стороны одной медали. Это два ортогональных параметра, которые вообще друг от друга не зависят. Грубое описание — это не противоположность подробному описанию. Грубому описанию противостоит аккуратно описание, а подробному описанию противостоит краткое описание. Описание, соответственно, может быть грубым и кратким, подробным (но при этом грубым), кратким (но аккуратным и точным) и т.д.
Претензия к авторскому и вашему описанию не в том, что оно недостаточно подробное, а в том, что оно чересчур грубое. Например тем, что оно выдаёт общие случае за частные (и не в угоду краткости, а просто из-за неумения аккуратно сформулировать общий принцип), тем, что оно использует неточные и неудачные формулировки.
Второй пункт вообще-то должен быть не про отправку HTTP-запроса, а про установку TCP-соединения.
И это может быть не TCP-соединение. Протокол QUIC использует UDP.
Я искренне надеюсь, что автор не разочаруется в написании статей из-за бестактных комментаторов, вытащит всю необходимую информацию из фидбека, и продолжит развиваться и писать статьи. Желаю удачи!)
P.S. главная ошибка в том, что автор не указала, что это суперупрощённая схема, и что на самом деле механизм намного сложнее, особенно в плане взаимодействия с различными компонентами ОС. Так как для каждой ОС детали процесса могут отличаться, стоит абстрагироваться от этого взаимодействия и рассказать только о базовых процессах, происходящих в браузере. Ну и лучше сразу указать, что эта статья не для специалистов, которые и так всё знают)
Спасибо автору! Теперь знания на нужных полочках ☺️
«Привет всем!
Меня зовут Андрей, я автор этого вебинара. Спасибо за ваши отзывы и комментарии!
Эта статья была написана для новичков, её основная цель — помочь тем, кто только начинает свой путь в веб‑разработке, понять общую картину. Мы специально упростили объяснения, чтобы начинающие могли легко разобраться, как работает клиентская часть веб‑приложений и какие задачи решает фронтенд.
Мы, конечно, понимаем, что в реальности процессы намного сложнее, и многие моменты можно было бы описать подробнее. Но для целей данной статьи мы постарались сделать акцент на базовых шагах, чтобы не перегружать новичков лишними техническими деталями.
Ещё раз спасибо за ваши замечания и предложения — постараемся их учесть при написании следующих статей!»
Как работает фронтенд: от загрузки сайта до современных инструментов