Блог

Я пытаюсь понять, что происходит в фоновом режиме при использовании веб-сайта ИЛИ, в основном, что происходит, когда пользователь взаимодействует с браузером. Я понимаю, что это огромный список, который сильно зависит от архитектуры, действий пользователя и т.д., Я просто пытаюсь разобраться в основных вещах и устранить свои недоразумения, а также использовать это, чтобы больше узнать о том, чего я не понимаю.

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

Пользователь вводит URL => браузер проверяет, доступен ли он в кэше браузера => Поиск DNS [поиск корневого dns => рекурсивный dns => получить ip] => устанавливает tcp-соединение => отправляет http-запрос => получает статическую страницу с веб-сервера => если требуется аутентификация, которая происходит [либо считывает файлы cookie из браузера, ЛИБО просит пользователя ввести учетные данные] => каким-то образом также получает динамические элементы [как? , здесь какая-то ленивая инициализация?] => Затем пользователь выполняет какое-либо действие [нажимает на ссылку или что-то еще] => проверяет кэш браузера => если не удается [принимает входные параметры и каким-либо образом вставляет в URL [может быть зашифровано что-то, если требуется] => обращается к балансировщику нагрузки => направляется на сервер приложений [в зависимости от того, как LB выбирает хост] => проверяется кэш сервера приложений [memcached или какой-то вид кэширования, не уверен, происходит ли это «обычно» здесь или на каком-то другом уровне] => сервер приложений пытается поймите запрос [если его служба прослушивает какой-либо порт, http порт 80, она получит URL-адрес и проанализирует для выполнения некоторых операций] => при необходимости запрашивается база данных => здесь снова может быть соединение mgmt / кэширование / параллельные запросы и т.д. => база данных возвращает результат на сервер приложений => сервер приложений создает полезную нагрузку результата и заголовки [http] => отправляет его в браузер для рендеринга => кэш браузера обновляется => пользователь реагирует на ответ.

Я не рассматривал повторные попытки / сбои и то, как они обрабатываются, но я хотел бы получить некоторую информацию и там в общем смысле

Примечание:
Я смотрю на вещи в целом, я уверен, что немногие компании могли бы сделать это по-другому и т.д. И т.п. Я также хотел бы услышать альтернативы!.

• Это попытка получить больше перспективы и прочитать о нескольких вещах, которые помогут мне в целом.
• Очевидно, что я предпринял честную попытку
• Я также надеюсь, что это помогло бы другим, рассматривающим вопрос в целом, узнать что-то новое.
• Я не спрашиваю мнения и т.д., Так что это не совсем открытый вопрос [не все верно, хотя есть много вариантов]

Спасибо!

Для браузера нет разницы между статическим или динамическим. Браузер делает HTTP-запрос и получает HTTP-ответ. Если ответом является HTML-страница, то браузер отображает HTML, применяет стили и выполняет код JavaScript, который поставляется вместе со страницей. Эта страница может быть динамической или статической — браузеру все равно! Сторона заботы — это серверная сторона. Если страница статична, HTTP-сервер просто возьмет страницу с диска и отправит ее клиенту в качестве HTTP-ответа. Если страница динамическая, HTTP-сервер вызовет какое-либо приложение и попросит это приложение предоставить запрошенный ресурс. Это приложение может быть PHP-модулем для Apache (http-сервер) или ASP.net для IIS или даже вашего кода на C , который будет генерировать любой контент, который вы хотите. Как именно будет сконструирована страница или ресурс (HTTP-ответ может быть также xml или изображением и т.д.), Зависит от используемого приложения (серверной технологии).

Например, если вы используете PHP — HTTP сервер обнаружит, что запрошенный ресурс имеет расширение .php, сервер передаст этот PHP-файл в PHP-модуль для обработки, и результат будет отправлен HTTP-клиенту (браузеру) в качестве ответа.

Когда пользователь выполняет какое-либо действие, это снова обычный HTTP-запрос. HTTP-методы GET и POST (ищите статью о HTTP в Википедии) используются для передачи некоторых входных данных с сервера клиенту. Страница может содержать несколько сложных JS, которые сделают страницу больше похожей на настольное приложение (богатые элементы управления, динамически реагирующие на действия пользователя без запроса к серверу или взаимодействующие с сервером в фоновом режиме), но это не обязательно для того, чтобы веб-приложение было веб-приложением (для веб-сайта динамическим). Это может быть старый добрый статический HTML с HTML-формами и некоторым кодом на стороне сервера.

Веб-приложение — это абстрактная сущность, которая может состоять из множества HTTP-ресурсов (разные URL-адреса для ответа сервера). Веб-приложение также представляет собой код на стороне клиента, который взаимодействует с кодом на стороне сервера через HTTP с помощью HTTP-клиента (браузера) и HTTP-сервера. Веб-приложение — это не какая-то отдельная часть, которая начинает работать только тогда, когда пользователь выполняет какое-то действие.

Веб-сервис может соответствовать этому описанию — как вещь, которая обычно не заботится о страницах и появляется только тогда, когда требуется какое-то действие. Это особый тип веб-приложения, которое предоставляет некоторый API через HTTP (обычно). Вы можете запросить некоторый ресурс и передать некоторый параметр, и вы получите ответ с некоторым результатом. Это то же веб-приложение, но без страниц. Но веб-сервис обычно является частью большого веб-приложения со страницами или даже другой частью того же веб-приложения (в зависимости от того, как вы смотрите на это). Это может быть та же серверная технология и тот же HTTP-сервер. И нет необходимости создавать веб-сервис, если вы хотите создать какое-либо веб-приложение (динамический веб-сайт).

Серверная часть веб-приложения также может взаимодействовать с некоторой базой данных, но в этом тоже нет необходимости. Может быть реальная база данных или просто несколько текстовых файлов на диске. И браузеру, коду на стороне клиента и HTTP-серверу также наплевать на базу данных или источник, откуда серверный код берет данные.

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

Файлы cookie передаются с каждым HTTP-запросом на HTTP-сервер, и если запрашиваемый ресурс не является статической страницей, этот HTTP-сервер передаст их далее в серверный код / приложение (часть). И обычно так работает аутентификация и авторизация — файлы cookie содержат информацию о сеансе, и на стороне сервера есть некоторые данные, связанные с сеансом, которые содержатся — это может быть идентификатор пользователя, поэтому серверный код будет распознавать пользователя при каждом запросе.