Как работает сайт – Как заработать на создании сайтов: с чего начать, сколько платят за сайты в Интернете?

Содержание

Что такое сайт и как он работает?

Привет, друзья! Сегодня мы продолжим говорить о технической стороне вашего Интернет бизнеса, а, точнее, обсудим что такое сайт и как он работает. В прошлой статье мы уже начали обсуждать инструменты Интернет бизнеса, мы говорили о том, как технические моменты выглядят с точки зрения пользователя, сейчас же рассмотрим этот вопрос со стороны вебмастера (или владельца).

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

Ничего сложного в этой теме нет, но я знаю, что многих она пугает. Поэтому, я постараюсь объяснить все тонкости максимально простым языком, чтобы про сайт поняли и пионеры и пенсионеры. Если останутся неясности – задавайте вопросы в комментариях.

Что такое сайт?

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

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

1. Файлы

Все картинки и многочисленные тексты, которые мы видим в Интернете – это дизайн, система управления сайтом (wordpress, joomla или что-то еще) и сама полезная информация (контент). Каждый из этих элементов представляет собой специальные файлы, точно также как любые другие файлы у вас дома на компьютере. Создаются они на специальных языках web программирования, таких как HTML, PHP и т.д. Когда мы видим текст, картинки и видео в нашем браузере, мы видим работу именно этих файлов.

2. Место для хранения файлов

Точно также как и у вас на компьютере, эти файлы не могут висеть в воздухе. Интернет не является чем-то абстрактным, это всего лишь много устройств, объединенных в сеть. Поэтому, для файлов любого сайта необходимо место. Обычно, файлы сайтов размещаются на серверах,(читайте – как разместить сайт в интернете), которые предоставляют специальные компании, называющиеся хостинг провайдерами, а место под файлы, вместе со всеми необходимыми программами, нужными для работы сайта, называется хостинг.

Какой хостинг лучше выбрать для своего сайта я рассказываю тут.

3. Адрес сайта или доменное имя

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

Например, BiznesSystem.ru – это адрес моего сайта. Занимаются назначением адресов для всех сайтов в сети специальные компании – регистраторы. А сами адреса называются доменами или доменными именами. Мы можем купить себе любое, свободное на данный момент, доменное имя.

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

Давайте закрепим этот материал простой аналогией с жильем. Вы и вся домашняя утварь, которой вы владеете – это внутреннее содержимое вашего сайта. Вам необходимо где-то жить, в квартире или доме – вашему сайту тоже нужно где-то жить, это хостинг. Чтобы вас найти, нужен адрес вашей квартиры – чтобы найти ваш сайт, нужно знать ее доменное имя.

Коротко ответ на вопрос “Что такое сайт?” будет звучать так – это комплекс файлов, размещенных на сервере (хостинге), к которому ведет специальный адрес (домен).

Как работает сайт?

Если вы внимательно прочитали все написанное выше, то понять как работает сайт вам будет несложно. Пользователь набирает в адресной строке своего браузера адрес (доменное имя) или просто кликает на ссылку, в результате чего на сервере, на котором размещены файлы, запускается программа.

Эта программа передает на компьютер пользователя данные сайта – текст, картинки, видео или что-то еще (зависит от конкретного случая).

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

Виды сайтов

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

  • Принадлежность – сайты бывают персональные, принадлежащие обычным людям, корпоративные – принадлежат фирмам, государственные – принадлежат органам власти или муниципальным образованиям.
  • Тематика – самая подробная классификаций по этому направлению описана в Яндекс Каталоге. Там перечислены все тематики в иерархическом формате (от общих к более конкретным). Эта классификация бывает полезна при выборе площадок для рекламы.
  • CMS – сайты могут создаваться как с чистого листа (html, css, php), так и с использованием уже готовых систем управления контентом. Движок сайта играет огромную роль при подборе плагинов или скриптов, так как то что подходит для одной CMS не подойдет для другой. Наиболее популярны WordPress, Joomla, Drupal, PHPbb.
  • Назначение – каждый сайт создается для определенных целей – блоги, форумы, социальные сети, городские порталы, каталоги и т.д.

Теперь вы в деталях знаете как работают сайты, и можете создать сайт сами бесплатно, не тратя деньги на дизайнерские конторы. Чтобы упростить задачу я подготовил большую подробную инструкцию по созданию сайта.

Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com

Эта статья является попыткой ответа на старый вопрос для собеседований: «Что же случается, когда вы печатаете в адресной строке google.com и нажимаете Enter?» Мы попробуем разобраться в этом максимально подробно, не пропуская ни одной детали.

Примечание: публикация основана на содержании репозитория What happens when...

Представленный контент изобилует большим количеством терминов, в переводе некоторых из них могут присутствовать различные неточности. Если вы обнаружите какую-то ошибку в нашем переводе — напишите личным сообщением, и мы всё исправим.

Мы перенесли перевод в репозиторий GitHub и отправили Pull Request автору материала — оставляйте свои правки к тексту, и вместе мы сможем значительно улучшить его.

1. Нажата клавиша «g»


Далее в статье содержится информация о работе физической клавиатуры и прерывания операционной системы. Но много чего происходит и помимо этого — когда вы нажимаете клавишу «g», браузер получает событие и запускается механизм автоподстановки. В зависимости от алгоритма браузера и его режима (включена ли функция «инкогнито») в выпадающем окне под строкой URL пользователю будет предложено определённое количество вариантов для автоподстановки.

Большинство алгоритмов автоподстановки ранжируют рекомендации в зависимости от истории поиска и оставленных закладках. Некоторые браузеры (например, Rockmelt) даже предлагают профили друзей на Facebook. Когда пользователь планирует напечатать в адресной строке «google.com», ничего из вышеперечисленного не играет роли, но тем не менее выполнится большое количество кода, а рекомендации будут обновляться с каждой новой напечатанной буквой. Возможно, браузер предложит перейти на google.com, до того, как пользователь вобьёт адрес целиком.

2. Клавиша «enter» нажата до конца


В качестве некой нулевой точки можно выбрать момент, когда клавиша Enter на клавиатуре нажата до конца и находится в нижнем положении. В этой точке замыкается электрическая цепь этой клавиши и небольшое количество тока отправляется по электросхеме клавиатуры, которая сканирует состояние каждого переключателя клавиши и конвертирует сигнал в целочисленный код клавиши (в данном случае — 13). Затем контроллер клавиатуры конвертирует код клавиши для передачи его компьютеру. Как правило, сейчас передача происходит через USB или Bluetooth, а раньше клавиатура подключалась к компьютеру с помощью коннекторов PS/2 или ADB.

В случае USB-клавиатуры:

  • Для работы USB-контуру клавиатуры требуется 5 вольт питания, которые поступают через USB-контроллер на компьютере.
  • Сгенерированный код клавиши хранится в регистре внутренней памяти клавиатуры, который называется «конечной точкой» (endpoint).
  • USB-контроллер компьютера опрашивает эту конечную точку каждые 10 микросекунд и получает хранящийся там код клавиши.
  • Затем это значение поступает в USB SIE (Serial Interface Engine) для конвертации в один или более USB-пакетов, которые формируются по низкоуровневому протоколу USB.
  • Эти пакеты затем пересылаются с помощью различных электрических сигналов через D+ и D- контакты с максимальной скоростью 1,5 Мб/сек — поскольку HID-устройства (Human Interface Device) всегда были «низкоскоростными».
  • Этот последовательный сигнал далее декодируется в USB-контроллере компьютера и интерпретируется универсальным драйвером HID-устройства (клавиатуры). Затем значение кода клавиши передаётся на «железный» уровень абстракции операционной системы.

В случае виртуальной клавиатуры (тачскрин):
  • Когда пользователь прикладывает палец к современному ёмкостному тач-экрану, небольшое количество тока передаётся к пальцу. Это замыкает цепь через электростатическое поле проводящего слоя и создаёт падение напряжения в этой точке экрана. Экранный контроллер затем инициирует прерывание, сообщающее координату «клика».
  • Затем мобильная ОС оповещает текущее открытое приложение о событии клика в одном из GUI-элементов (в этом случае — кнопках виртуальной клавиатуры).
  • Виртуальная клавиатура вызывает программное прерывание для отправки сообщения «клавиша нажата» обратно в ОС.
  • Это прерывание оповещает текущее открытое приложение о возникновении события «нажатия клавиши».

2.1 Возникло прерывание [не для USB-клавиатур]

Клавиатура отправляет сигналы в свою «линию запросов прерываний» (IRQ), которая затем сопоставляется с «вектором прерывания» (целое число) контроллером прерываний. Процессор использует «таблицу дескрипторов прерываний» (IDT) для сопоставления векторов прерываний с функциями («обработчики прерываний») ядра. Когда появляется прерывание, процессор (CPU) обновляет IDT вектором прерывания и запускает соответствующий обработчик. Таким образом, в дело вступает ядро.
2.2 (На Windows) Сообщение WM_KEYDOWN отправлено приложению

HID передаёт событие нажатой клавиши драйверу KBDHID.sys, который конвертирует его в скан-код (scancode). В данном конкретном случае скан-код — VK_RETURN (0x0D). Драйвер KDBHID.sys связывается с драйвером KBDCLASS.sys (драйвер классов клавиатуры). Он отвечает за безопасную обработку всего ввода с клавиатуры. В дальнейшем этот драйвер вызывает Win32K.sys (после возможной передачи сообщения через установленные сторонние клавиатурные фильтры). Все это происходит в режиме ядра.

Win32K.sys определяет, какое окно активно в данный момент, с помощью функции GetForegroundWindow(). Этот API обеспечивает обработку окна адресной строки в браузере. Затем главный «насос сообщений» Windows вызывает SendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam). lParam

— это битовая маска, которая указывает на дальнейшую информацию о нажатии клавиши: счётчик повторов (в этом случае 0), актуальный скан-код (может зависеть от OEM, но VK_RETURN обычно не зависит от этого), информацию о том, были ли нажаты дополнительные клавиши (например, Alt, Shift, Ctrl — в нашем случае не были) и некоторые другие данные.

В API Windows есть функция SendMessage, которая помещает сообщение в очередь для конкретного обработчика окон (hWnd). После этого для обработки всех сообщений очереди вызывается главная функция обработки сообщений (WindowProc), присвоенная обработчику hWnd.

Окно (hWnd), активное в данный момент, представляет из себя контрол обработки и в этом случае у WindowsProc есть обработчик для сообщений WM_KEYDOWN. Этот код изучает третий параметр, который поступил в SendMessage (wParam) и, поскольку это VK_RETURN, понимает, что пользователь нажал клавишу ENTER.

2.3 (В OS X) Событие NSEVent KeyDown отправлено приложению

Сигнал прерывания активирует событие прерывания в драйвере I/O Kit клавиатуры. Драйвер переводит сигнал в код клавиатуры, который затем передаётся процессу OS X под названием
WindowServer
. В результате, WindowsServer передаёт событие любому подходящему (активному или «слушающему») приложению через Mach-порт, в котором событие помещается в очередь. Затем события могут быть прочитаны из этой очереди потоками с достаточными привилегиями, чтобы вызывать функцию mach_ipc_dispatch. Чаще всего это происходит и обрабатывается с помощью основного цикла NSApplication через NSEvent в NSEventype KeyDown.
2.4 (В GNU/Linux) Сервер Xorg слушает клавиатурные коды

В случае графического X server, для получения нажатия клавиши будет использован общий драйвер событий evdev. Переназначение клавиатурных кодов скан-кодам осуществляется с помощью специальных правил и карт X Server. Когда маппинг скан-кода нажатой клавиши завершён, X server посылает символ в window manager (DWM, metacity, i3), который затем отправляет его в активное окно. Графический API окна, получившего символ, печатает соответствующий символ шрифта в нужном поле.

3. Парсинг URL


Теперь у браузера есть следующая информация об URL:
Protocol «HTTP»
Использовать «Hyper Text Transfer Protocol»

Resource «/»
Показать главную (индексную) страницу


3.1 Это URL или поисковый запрос?

Когда пользователь не вводит протокол или доменное имя, то браузер «скармливает» то, что человек напечатал, поисковой машине, установленной по умолчанию. Часто к URL добавляется специальный текст, который позволяет поисковой машине понять, что информация передана из URL-строки определённого браузера.
3.2 Список проверки HSTS

  • Браузер проверяет список «предзагруженных HSTS (HTTP Strict Transport Security)». Это список сайтов, которые требуют, чтобы к ним обращались только по HTTPS.
  • Если нужный сайт есть в этом списке, то браузер отправляет ему запрос через HTTPS вместо HTTP. В противном случае, начальный запрос посылается по HTTP. (При этом сайт может использовать политику HSTS, но не находиться в списке HSTS — в таком случае на первый запрос по HTTP будет отправлен ответ о том, что необходимо отправлять запросы по HTTPS. Однако это может сделать пользователя уязвимым к downgrade-атакам — чтобы этого избежать, в браузеры и включают список HSTS).

3.3 Конвертация не-ASCII Unicode символов в название хоста

  • Браузер проверяет имя хоста на наличие символов, отличных от a-z, A-Z, 0-9, -, или ..
  • В случае доменного имени google.com никаких проблем не будет, но если бы домен содержал не-ASCII символы, то браузер бы применил кодировку Punycode для этой части URL.

4. Определение DNS


  • Браузер проверяет наличие домена в своём кэше.
  • Если домена там нет, то браузер вызывает библиотечную функцию gethostbyname (отличается в разных ОС) для поиска нужного адреса.
  • Прежде, чем искать домен по DNS gethostbyname пытается найти нужный адрес в файле hosts (его расположение отличается в разных ОС).
  • Если домен нигде не закэширован и отсутствует в файле hosts, gethostbyname отправляет запрос к сетевому DNS-серверу. Как правило, это локальный роутер или DNS-сервер интернет-провайдера.
  • Если DNS-сервер находится в той же подсети, то ARP-запрос отправляется этому серверу.
  • Если DNS-сервер находится в другой подсети, то ARP-запрос отправляется на IP-адрес шлюза по умолчанию (default gateway).

4.1 Процесс отправки ARP-запроса

Для того, чтобы отправить широковещательный ARP-запрос необходимо отыскать целевой IP-адрес, а также знать MAC-адрес интерфейса, который будет использоваться для отправки ARP-запроса.

Кэш ARP проверяется для каждого целевого IP-адреса — если адрес есть в кэше, то библиотечная функция возвращает результат: Target IP = MAC.

Если же записи в кэше нет:

  • Проверяется таблица маршрутизации — это делается для того, чтобы узнать, есть ли искомый IP-адрес в какой-либо из подсетей локальной таблицы. Если он там, то запрос посылается с помощью интерфейса, связанного с этой подсетью. Если адрес в таблице не обнаружен, то используется интерфейс подсети шлюза по умолчанию.
  • Определяется MAC-адрес выбранного сетевого интерфейса.
  • Отправляется ARP-запрос (второй уровень стека):

ARP-запрос:

Sender MAC: interface:mac:address:here
Sender IP: interface.ip.goes.here
Target MAC: FF:FF:FF:FF:FF:FF (Broadcast)
Target IP: target.ip.goes.here

В зависимости от того, какое «железо» расположено между компьютером и роутером (маршрутизатором):

Прямое соединение:

  • Если компьютер напрямую подключён к роутеру, то это устройство отправляет ARP-ответ (ARP Reply).

Между ними концентратор (Хаб):
  • Если компьютер подключён к сетевому концентратору, то этот хаб отправляет широковещательный ARP-запрос со всех своих портов. Если роутер подключён по тому же «проводу», то отправит ARP-ответ.

Между ними коммутатор (свитч):
  • Если компьютер соединён с сетевым коммутатором, то этот свитч проверит локальную CAM/MAC-таблицу, чтобы узнать, какой порт в ней имеет нужный MAC-адрес. Если нужного адреса в таблице нет, то он заново отправит широковещательный ARP-запрос по всем портам.
  • Если в таблице есть нужная запись, то свитч отправит ARP-запрос на порт с искомым MAC-адресом.
  • Если роутер «на одной линии» со свитчем, то он ответит (ARP Reply).

ARP-ответ:

Sender MAC: target:mac:address:here
Sender IP: target.ip.goes.here
Target MAC: interface:mac:address:here
Target IP: interface.ip.goes.here

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

  • Порт 53 открывается для отправки UDP-запроса к DNS-серверу (если размер ответа слишком велик, будет использован TCP).
  • Если локальный или на стороне провайдера DNS-сервер «не знает» нужный адрес, то запрашивается рекурсивный поиск, который проходит по списку вышестоящих DNS-серверов, пока не будет найдена SOA-запись, а затем возвращается результат.

5. Открытие сокета


Когда браузер получает IP-адрес конечного сервера, то он берёт эту информацию и данные об используемом порте из URL (80 порт для HTTP, 443 для HTTPS) и осуществляет вызов функции socket системной библиотеки и запрашивает поток TCP сокета — AF_INET и SOCK_STREAM.
  • Этот запрос сначала проходит через транспортный уровень, где собирается TCP-сегмент. В заголовок добавляется порт назначения, исходный порт выбирается из динамического пула ядра (ip_local_port_range в Linux).
  • Получившийся сегмент отправляется на сетевой уровень, на котором добавляется дополнительный IP-заголовок. Также включаются IP-адрес сервера назначения и адрес текущей машины — после этого пакет сформирован.
  • Пакет передаётся на канальный уровень. Добавляется заголовок кадра, включающий MAC-адрес сетевой карты (NIC) компьютера, а также MAC-адрес шлюза (локального роутера). Как и на предыдущих этапах, если ядру ничего не известно о MAC-адресе шлюза, то для его нахождения отправляется широковещательный ARP-запрос.

На этой точке пакет готов к передаче через:
В случае интернет-соединения большинства частных пользователей или небольших компаний пакет будет отправлен с компьютера, через локальную сеть, а затем через модем (MOdulator/DEModulator), который транслирует цифровые единицы и нули в аналоговый сигнал, подходящий для передачи по телефонной линии, кабелю или беспроводным телефонным соединениям. На другой стороне соединения расположен другой модем, который конвертирует аналоговый сигнал в цифровые данные и передаёт их следующему сетевому узлу, где происходит дальнейший анализ данных об отправителе и получателе.

В конечном итоге пакет доберётся до маршрутизатора, управляющего локальной подсетью. Затем он продолжит путешествовать от одного роутера к другому, пока не доберётся до сервера назначения. Каждый маршрутизатор на пути будет извлекать адрес назначения из IP-заголовка и отправлять пакет на следующий хоп. Значение поля TTL (time to live) в IP-заголовке будет каждый раз уменьшаться после прохождения каждого роутера. Если значение поля TTL достигнет нуля, пакет будет отброшен (это произойдёт также если у маршрутизатора не будет места в текущей очереди — например, из-за перегрузки сети).

Во время TCP-соединения происходит множество подобных запросов и ответов.

5.1 Жизненный цикл TCP-соединения

a. Клиент выбирает номер начальной последовательности (ISN) и отправляет пакет серверу с установленным битом SYN для открытия соединения.

b. Сервер получает пакет с битом SYN и, если готов к установлению соединения, то:

  • Выбирает собственный номер начальной последовательности;
  • Устанавливает SYN-бит, чтобы сообщить о выборе начальной последовательности;
  • Копирует ISN клиента +1 в поле ACK и добавляет ACK-флаг для обозначения подтверждения получения первого пакета.

c. Клиент подтверждает соединение путём отправки пакета:
  • Увеличивает номер своей начальной последовательности;
  • Увеличивает номер подтверждения получения;
  • Устанавливает поле ACK.

d. Данные передаются следующим образом:
  • Когда одна сторона отправляет N байтов, то увеличивает значение поля SEQ на это число.
  • Когда вторая сторона подтверждает получение этого пакета (или цепочки пакетов), она отправляет пакет ACK, в котором значение поля ACK равняется последней полученной последовательности.

e. Закрытие соединения:
  • Сторона, которая хочет закрыть соединение, отправляет пакет FIN;
  • Другая сторона подтверждает FIN (с помощью ACK) и отправляет собственный FIN-пакет;
  • Инициатор прекращения соединения подтверждает получение FIN отправкой собственного ACK.

6. TLS handshake


  • Клиентский компьютер отправляет сообщение ClientHello серверу со своей версией протокола TLS, списком поддерживаемых алгоритмов шифрования и методов компрессии данных.
  • Сервер отвечает клиенту сообщением ServerHello, содержащим версию TLS, выбранный метод шифрования, выбранные методы компрессии и публичный сертификат сервиса, подписанный центром сертификации. Сертификат содержит публичный ключ, который будет использоваться клиентом для шифрования оставшейся части процедуры «рукопожатия» (handshake), пока не будет согласован симметричный ключ.
  • Клиент подтверждает сертификат сервера с помощью своего списка центров сертификации. Если сертификат подписан центром из списка, то серверу можно доверять, и клиент генерирует строку псевдослучайных байтов и шифрует её с помощью публичного ключа сервера. Эти случайные байты могут быть использованы для определения симметричного ключа.
  • Сервер расшифровывает случайные байты с помощью своего секретного ключа и использует эти байты для генерации своей копии симметричного мастер-ключа.
  • Клиент отправляет серверу сообщение Finished, шифруя хеш передачи с помощью симметричного ключа.
  • Сервер генерирует собственный хеш, а затем расшифровывает полученный от клиента хеш, чтобы проверить, совпадёт ли он с собственным. Если совпадение обнаружено, сервер отправляет клиенту собственный ответ Finished, также зашифрованный симметричным ключом.
  • После этого TLS-сессия передаёт данные приложения (HTTP), зашифрованные с помощью подтверждённого симметричного ключа.

7. Протокол HTTP


Если используемый браузер был создан Google, то вместо отправки HTTP-запроса для получения страницы, он отправит запрос, чтобы попытаться «договориться» с сервером об «апгрейде» протокола с HTTP до SPDY («спиди»).

Если клиент использует HTTP-протокол и не поддерживает SPDY, то отправляет серверу запрос следующей формы:

GET / HTTP/1.1
Host: google.com
Connection: close
[другие заголовки]

где [другие заголовки] — это серия пар «ключ: значение», разбитых переносом строки. (Здесь предполагается, что в использованном браузере нет никаких ошибок, нарушающих спецификацию HTTP. Также предполагается, что браузер использует HTTP/1.1, в противном случае он может не включать заголовок Host в запрос и версия, отданная в ответ на GET-запрос может быть HTTP/1.0 или HTTP/0.9).

HTTP/1.1 определяет опцию закрытия соединения («close») для отправителя — с её помощью происходит уведомление о закрытии соединения после завершения ответа. К примеру:

Connection: close

Приложения HTTP/1.1, которые не поддерживают постоянные соединения, обязаны включать опцию «close» в каждое сообщение.

После отправки запроса и заголовков, браузер отправляет серверу единичную пустую строку, сигнализируя о том, что содержимое сообщения закончилось.

Сервер отвечает специальным кодом, который обозначает статус запроса и включает ответ следующей формы:

200 OK
[заголовки ответа]

После этого посылается пустая строка, а затем оставшийся контент HTML-страницы www.google.com. Сервер может затем закрыть соединение, или, если того требуют отправленные клиентом заголовки, сохранять соединение открытым для его использования следующими запросами.

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

304 Not Modified
[заголовки ответа]

и, соответственно, клиенту не посылается никакого контента, вместо этого браузер «достаёт» HTML из кэша.

После разбора HTML, браузер (и сервер) повторяет процесс загрузки для каждого ресурса (изображения, стили, скрипты, favicon.ico и так далее), на который ссылается HTML-страница, но при этом изменяется адрес каждого запроса c GET / HTTP/1.1 на GET /$(относительный URL ресурса www.google.com) HTTP/1.1.

Если HTML ссылается на ресурс, размещённый на домене, отличном от google.com, то браузер возвращается к шагам, включающим разрешение доменного имени, а затем заново проходит процесс до текущего состояния, но уже для другого домена. Заголовок Host в запросе вместо google.com будет установлен на нужное доменное имя.

7.1 Обработка HTTP-запросов на сервере

HTTPD (HTTP Daemon) является одним из инструментов обработки запросов/ответов на стороне сервера. Наиболее популярные HTTPD-серверы это Apache или Nginx для Linux и IIS для Windows.

— HTTPD (HTTP Daemon) получает запрос.

— Сервер разбирает запрос по следующим параметрам:

  • Метод HTTP-запроса (GET, POST, HEAD, PUT или DELETE). В случае URL-адреса, который пользователь напечатал в строке браузера, мы имеем дело с GET-запросом.
  • Домен. В нашем случае — google.com.
  • Запрашиваемые пути/страницы, в нашем случае — / (нет запрошенных путей, / — это путь по умолчанию).

— Сервер проверяет существование виртуального хоста, который соответствует google.com.

— Сервер проверяет, что google.com может принимать GET-запросы.

— Сервер проверяет, имеет ли клиент право использовать этот метод (на основе IP-адреса, аутентификации и прочее).

— Если на сервере установлен модуль перезаписи (mod_rewrite для Apache или URL Rewrite для IIS), то он сопоставляет запрос с одним из сконфигурированных правил. Если находится совпадающее правило, то сервер использует его, чтобы переписать запрос.

— Сервер находит контент, который соответствует запросу, в нашем случае он изучит индексный файл.

— Далее сервер разбирает («парсит») файл с помощью обработчика. Если Google работает на PHP, то сервер использует PHP для интерпретации индексного файла и направляет результат клиенту.

8. За кулисами браузера


Задача браузера заключается в том, чтобы показывать пользователю выбранные им веб-ресурсы, запрашивая их с сервера и отображая в окне просмотра. Как правило такими ресурсами являются HTML-документы, но это может быть и PDF, изображения или контент другого типа. Расположение ресурсов определяется с помощью URL.

Способ, который браузер использует для интерпретации и отображения HTML-файлов описан в спецификациях HTML и CSS. Эти документы разработаны и поддерживаются консорциумом W3C (World Wide Wib Consortium), которая занимается стандартизацией веба.

Интерфейсы браузеров сильно похожи между собой. У них есть большое количество одинаковых элементов:

  • Адресная строка, куда вставляются URL-адреса;
  • Кнопки возврата на предыдущую и следующую страницу;
  • Возможность создания закладок;
  • Кнопки обновления страницы (рефреш) и остановки загрузки текущих документов;
  • Кнопка «домой», возвращающая пользователя на домашнюю страницу.

Высокоуровневая структура браузера

Браузер включает следующие компоненты:
  • Пользовательский интерфейс: В него входит адресная строка, кнопки продвижения вперёд/назад, меню закладок и так далее. Сюда относятся все элементы, кроме окна, в котором собственно отображается веб-страница.
  • «Движок» браузера: Распределяет действия между движком рендеринга и интерфейсом пользователя.
  • «Движок» рендеринга: Отвечает за отображение запрашиваемого контента. К примеру, если запрашивается HTML, то «движок» разбирает код HTML и CSS, а затем отображает полученный контент на экране.
  • Сетевая часть: с помощью сетевых функций браузер обрабатывает вызовы, вроде HTTP-запросов, с применением различных реализаций для разных платформ.
  • Бэкенд интерфейса (UI): Используется для отрисовки базовых виджетов, вроде комбо-боксов и окон.
  • Интерпретатор JavaScript: Используется для парсинга и выполнения JavaScript-кода.
  • Хранилище данных: Браузеру может понадобиться локально хранить некоторые данные (например, cookie). Кроме того, браузеры поддерживают различные механизмы хранения, такие как localStorage, IndexedDB, WebSQL и FileSystem.

9. Парсинг HTML


Движок рендеринга начинает получать содержимое запрашиваемого документа от сетевого механизма браузера. Как правило, контент поступает кусками по 8Кб. Главной задачей HTML-парсера является разбор разметки в специальное дерево.

Получающееся на выходе дерево («parse tree») — это дерево DOM-элементов и узлов атрибутов. DOM — сокращение от Document Object Model. Это модель объектного представления HTML-документа и интерфейс для взаимодействия HTML-элементов с «внешним миром» (например, JavaScript-кодом). Корнем дерева является объект «Документ».

Алгоритм разбора

HTML-нельзя «распарсить» с помощью обычных анализаторов (нисходящих или восходящих). Тому есть несколько причин:
  • Прощающая почти что угодно природа языка;
  • Тот факт, что браузеры обладают известной толерантностью к ошибкам и поддерживают популярные ошибки в HTML.
  • Процесс парсинга может заходить в тупик. В других языках код, который требуется разобрать, не меняется в процессе анализа, в то время как в HTML с помощью динамического кода (например, скриптовые элементы, содержащие вызовы document.write()) могут добавляться дополнительные токены, в результате чего сам процесс парсинга модифицирует вывод.

Невозможность использования привычных технологий парсинга приводит к тому, что разработчики браузеров реализуют собственные механизмы разбора HTML. Алгоритм парсинга подробно описан в спецификации HTML5.

Алгоритм состоит из двух этапов: токенизации и создания дерева.

Действия после завершения парсинга

После этого браузер начинает подгружать внешние ресурсы, связанные со страницей (стили, изображения, скрипты и так далее).

На этом этапе браузер помечает документ, как интерактивный и начинает разбирать скрипты, находящиеся в «отложенном» состоянии: то есть те из них, что должны быть исполнены после парсинга. После этого статус документа устанавливается в состояние «complete» и инициируется событие загрузки («load»).

Важный момент: ошибки «Invalid Syntax» при разборе не может быть, поскольку браузеры исправляют любой «невалидный» контент и продолжают работу.

10. Интерпретация CSS


  • Во время разбора браузер парсит CSS-файлы, содержимое тегов <style> и атрибутов «style» c помощью «лексической и синтаксической грамматики CSS».
  • Каждый CSS-файл разбирается в объект StyleSheet, каждый из таких объектов содержит правила CSS с селекторами и объектами в соответствии с грамматикой CSS.
  • Парсер CSS может быть как восходящим, так и нисходящим.

11. Рендеринг страниц


  • Путём перебора DOM-узлов и вычисления для каждого узла значений CSS-стилей создаётся «Дерево рендера» (Render Tree или Frame Tree).
  • Вычисляется предпочтительная ширина каждого узла в нижней части дерева — для этого суммируются значения предпочтительной ширины дочерних узлов, а также горизонтальные поля, границы и отступы узлов.
  • Вычисляется реальная ширина каждого узла сверху-вниз (доступная ширина каждого узла выделяется его потомкам).
  • Вычисляется высота каждого узла снизу-вверх — для этого применяется перенос текста и суммируются значения полей, высоты, отступов и границ потомков.
  • Вычисляются координаты каждого узла (с использованием ранее полученной информации).
  • Если элементы плавающие или спозиционированы абсолютно или относительно, предпринимаются более сложные действия. Более подробно они описаны здесь и здесь.
  • Создаются слои для описания того, какие части страницы можно анимировать без необходимости повторного растрирования. Каждый объект (фрейма или рендера) присваивается слою.
  • Для каждого слоя на странице выделяются текстуры.
  • Объекты (рендеры/фреймы) каждого слоя перебираются и для соответствующих слоёв выполняются команды отрисовки. Растрирование может осуществляться процессором или возможна отрисовка на графическом процессоре (GPU) через D2D/SkiaGL.
  • Все вышеперечисленные шаги могут требовать повторного использования значений, сохранённых с последнего рендеринга страницы, такая инкрементальная работа требует меньше затрат.
  • Слои страницы отправляются процессу-компоновщику, где они комбинируются со слоями для другого видимого контента (интерфейс браузера, iframe-элементы, addon-панели).
  • Вычисляются финальные позиции слоёв и через Direct3D/OpenGL отдаются композитные команды. Командные буферы GPU освобождаются для асинхронного рендеринга и фрейм отправляется для отображения на экран.

12. Рендеринг GPU


  • Во время процесса рендеринга уровни графических вычислений могут использовать процессор компьютера или графический процессор (GPU).
  • Во втором случае уровни графического программного обеспечения делят задачу на множество частей, что позволяет использовать параллелизм GPU для вычисления плавающей точки, которое требуется для процесса рендеринга.

13. Вызванное пользователем и пост-рендеринговое исполнение


После завершения рендеринга, браузер исполняет JavaScript-код в результате срабатывания некоего часового механизма (так работают дудлы на странице Google) или в результате действий пользователя (ввод поискового запроса в строку и получение рекомендаций в ответ). Также могут срабатывать плагины вроде Flash или Java (но не в рассматриваемом примере с домашней страницей Google). Скрипты могут потребовать обработки дополнительных сетевых запросов, изменять страницу или её шаблон, что приведёт к следующему этапу рендеринга и отрисовки.

Как работают сайты?

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

Ниже мы поговорим о структурах сайтов, об основных типах сайтов и о принципах работы сайта в сети интернет.

Структура сайта

Сайт – это информационный ресурс, имеющий конкретный адрес, по которому его можно найти в Сети. Он имеет четко организованную структуру, связанную с его целями и задачами.

Существует ряд страниц, составляющих основу большинства сайтов и необходимых для удобной навигации:

  • главная или домашняя страница – содержит основную информацию и дает четкое представление о тематике сайта, в блогах – отображает самые свежие записи;
  • «О сайте» или «Об авторе» - знакомит пользователей с целями создания данного сайта или с его автором;
  • карта сайта – структурированный перечень страниц и публикаций для облегчения поиска;
  • контактная информация;
  • форма обратной связи.

Каждая страница сайта разбита на отдельные элементы с различным содержимым:

  • шапка – компонент, который находится вверху страницы и отображает название сайта, сведения о торговой марке или бренде и т. д.;
  • блок навигации – позволяет быстро перемещаться между страницами и разделами сайта. Может отображаться в виде горизонтальной строки или вертикального блока;
  • информационное поле – содержит основное смысловое наполнение страницы;
  • сайт-бар – блоки, обычно расположенные с одной или двух сторон от основного поля, предназначены для размещения рекламы и различных виджетов;
  • подвал или нижний колонтитул – включает информацию о разработчиках, счетчик сайта и пр.

Виды сайтов

В зависимости от информационного наполнения различают следующие сайты:

  • сайт-визитка – сайт, состоящий из одной или нескольких страниц, на которых размещена информация о физическом либо юридическом лице с указанием контактных данных;
  • блог – своеобразный онлайн-дневник, на котором автор может делиться с читателями своими профессиональными навыками или увлечениями;
  • интернет-магазин – сайт с каталогом товаров и настроенной системой платежей;
  • корпоративный сайт – сайт, как правило, крупной компании с полным описанием производимых товаров или оказываемых услуг. На сайте размещаются новости компании, проводимые акции, свободные вакансии и т. д.;
  • портал – крупный интернет-ресурс, посвященный определенной тематике. Обычно предоставляет возможность пользователям общаться на форуме, в чате, заводить почтовый ящик и пр.

По способу отображения в браузере все сайты можно разделить на два вида.

  1. Статические – страницы сайта выглядят всегда одинаково независимо от действий пользователя. Для их написания используется язык разметки html.
  2. Динамические – внешний вид страниц меняется в зависимости от запроса посетителя. Достигается такая динамика с помощью скриптов, написанных на языке JavaScript.

Как работают сайты в Интернете

Чтобы сайт стал доступен для пользователей, ему нужно присвоить доменное имя и разместить на специальном сервере, имеющем достаточное пространство на диске и круглосуточное высокоскоростное подключение к Интернету. Такая площадка называется хостингом, а предоставляющие ее компании – провайдерами.

Все компьютеры в Сети можно условно разделить на серверы и клиенты. Как работают компьютеры-серверы? Они с одной стороны соединены с компьютерами клиентов по телефонным линиям, выделенным каналам или беспроводным сетям связи, с другой стороны – подключены к Интернету. С помощью специального программного обеспечения компьютер провайдера принимает запросы и выводит информацию на мониторы пользователей.

Компьютеры-клиенты отправляют запросы и обрабатывают полученную информацию с помощью программ-браузеров, например, Internet Explorer, Mozilla Firefox, Opera и других. Для взаимодействия различных операционных систем и программного обеспечения существуют протоколы обмена данными.

Все компьютеры в Сети имеют уникальный IP-адрес, представляющий собой последовательность чисел, по которой его можно найти в любой точке мира. Чтобы найти в Интернете конкретный сайт, нужно знать IP-адрес компьютера, на котором он расположен. Для облегчения поиска разработана система доменных имен (DNS – Domain Name System). То есть сайту присваивается символьное имя. Для преобразования доменного адреса в цифровой IP-адрес используется служба DNS-серверов.

Таким образом для работы сайта ему необходимо присвоить доменное имя и разместить на одной из хостинг-площадок.

Как работают веб-приложения / Habr

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

1. Чем веб-приложения отличаются от сайтов


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

Сайты содержат различную статику, которая как и HTML-файл не генерируется на лету. Чаще всего это картинки, CSS-файлы, JS-скрипты, но могут быть и любые другие файлы: mp3, mov, csv, pdf.

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

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

2. Какие бывают веб-приложения


Веб-приложения можно разделить на несколько типов, в зависимости от разных сочетаний его основных составляющих:
  1. Backend (бэкенд или серверная часть приложения) работает на удаленном компьютере, который может находиться где угодно. Она может быть написана на разных языках программирования: PHP, Python, Ruby, C# и других. Если создавать приложение используя только серверную часть, то в результате любых переходов между разделами, отправок форм, обновления данных, сервером будет генерироваться новый HTML-файл и страница в браузере будет перезагружаться.
  2. Frontend (фронтенд или клиентская часть приложения) выполняется в браузере пользователя. Эта часть написана на языке программирования Javascript. Приложение может состоять только из клиентской части, если не требуется хранить данные пользователя дольше одной сессии. Это могут быть, например, фоторедакторы или простые игрушки.
  3. Single page application (SPA или одностраничное приложение). Более интересный вариант, когда используются и бэкенд и фронтенд. С помощью их взаимодействия можно создать приложение, которое будет работать совсем без перезагрузок страницы в браузере. Или в упрощенном варианте, когда переходы между разделами вызывают перезагрузки, но любые действия в разделе обходятся без них.

3. Pyhon-фреймворк Django aka бэкенд


В разработке фреймворк — это набор готовых библиотек и инструментов, которые помогают создавать веб-приложения. Для примера опишу принцип работы фреймворка Django, написанного на языке программирования Python.

Первым этапом запрос от пользователя попадает в роутер (URL dispatcher), который решает какую функцию для обработки запроса надо вызвать. Решение принимается на основе списка правил, состоящих из регулярного выражения и названия функции: если такой-то урл, то вот такая функция.

Функция, которая вызывается роутером, называется вью (view). Внутри может содержаться любая бизнес-логика, но чаще всего это одно из двух: либо из базы берутся данные, подготавливаются и возвращаются на фронт; либо пришел запрос с данными из какой-то формы, эти данные проверяются и сохраняются в базу.

Данные приложения хранятся в базе данных (БД). Чаще всего используются реляционные БД. Это когда есть таблицы с заранее заданными колонками и эти таблицы связаны между собой через одну из колонок.

Данные в БД можно создавать, читать, изменять и удалять. Иногда для обозначения этих действий можно встретить аббревиатуру CRUD (Create Read Update Delete). Для запроса к данным в БД используется специальный язык SQL (structured query language).

В Джанго для работы с БД используются модели (model). Они позволяют описывать таблицы и делать запросы на привычном разработчику питоне, что гораздо удобнее. За это удобство приходится платить: такие запросы медленнее и ограничены в возможностях по сравнению с использованием чистого SQL.

Полученные из БД данные подготавливаются во вью к отправке на фронт. Они могут быть подставлены в шаблон (template) и отправлены в виде HTML-файла. Но в случае одностраничного приложения это происходит всего один раз, когда генерируется HTML-страница, на который подключаются все JS-скрипты. В остальных случаях данные сериализуются и отправляются в JSON-формате.

4. Javascript-фреймворки aka фронтенд


Клиентская часть приложения — это скрипты, написанные на языке программирования Javascript (JS) и исполняемые в браузере пользователя. Раньше вся клиентская логика основывалась на использовании библиотеки JQuery, которая позволяет работать с DOM, анимацией на странице и делать AJAX запросы.

DOM (document object model) — это структура HTML-страницы. Работа с DOM — это поиск, добавление, изменение, перемещеие и удаление HTML-тегов.

AJAX (asynchronous javascript and XML) — это общее название для технологий, которые позволяют делать асинхронные (без перезагрузки страницы) запросы к серверу и обмениваться данными. Так как клиентская и серверная части веб-приложения написаны на разных языках программирования, то для обмена информацией необходимо преобразовывать структуры данных (например, списки и словари), в которых она хранится, в JSON-формат.

JSON (JavaScript Object Notation) — это универсальный формат для обмена данными между клиентом и сервером. Он представляет собой простую строку, которая может быть использована в любом языке программирования.

Сериализация — это преобразование списка или словаря в JSON-строку. Для примера:

Словарь:

    {
        'id': 1, 
        'email': '[email protected]'
    }

Сериализованная строка:
    '{"id": 1, "email": "[email protected]"}'

Десериализация — это обратное преобразование строки в список или словарь.

С помощью манипуляций с DOM можно полностью управлять содержимым страниц. С помощью AJAX можно обмениваться данными между клиентом и сервером. С этими технологиями уже можно создать SPA. Но при создании сложного приложения код фронтенда, основанного на JQuery, быстро становится запутанным и трудно поддерживаемым.

К счастью, на смену JQuery пришли Javascript-фреймворки: Backbone Marionette, Angular, React, Vue и другие. У них разная философия и синтаксис, но все они позволяют с гораздо большим удобством управлять данными на фронтенде, имеют шаблонизаторы и инструменты для создания навигации между страницами.

HTML-шаблон — это «умная» HTML-страница, в которой вместо конкретных значений используются переменные и доступны различные операторы: if, цикл for и другие. Процесс получения HTML-страницы из шаблона, когда подставляются переменные и применяются операторы, называется рендерингом шаблона.

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

5. Как клиент и сервер общаются между собой


Общение клиента с сервером происходит по протоколу HTTP. Основа этого протокола — это запрос от клиента к серверу и ответ сервера клиенту.

Для запросов обычно используют методы GET, если мы хотим получить данные, и POST, если мы хотим изменить данные. Еще в запросе указывается Host (домен сайта), тело запроса (если это POST-запрос) и много дополнительной технической информации.

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

Есть еще один запрос, который делается перед HTTP. Это DNS (domain name system) запроc. Он нужен для получения ip-адреса, к которому привязан запрашиваемый домен. Эта информация сохраняется в браузере и мы больше не тратим на это время.

Когда запрос от браузера доходит до сервера, он не сразу попадает в Джанго. Сначала его обрабатывает веб-сервер Nginx. Если запрашивается статический файл (например, картинка), то сам Nginx его отправляет в ответ клиенту. Если запрос не к статике, то Nginx должен проксировать (передать) его в Джанго.

К сожалению, он этого не умеет. Поэтому используется еще одна программа-прослойка — сервер приложений. Например для приложений на питоне, это могут быть uWSGI или Gunicorn. И вот уже они передают запрос в Джанго.

После того как Джанго обработал запрос, он возвращает ответ c HTML-страницей или данными, и код ответа. Если все хорошо, то код ответа — 200; если страница не найдена, то — 404; если произошла ошибка и сервер не смог обработать запрос, то — 500. Это самые часто встречающиеся коды.

6. Кэширование в веб-приложениях


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

Cache — это концепция в разработке, когда часто используемые данные, вместо того чтобы их каждый раз доставать из БД, вычислять или подготавливать иным способом, сохраняются в быстро доступном месте. Несколько примеров использования кэша:

  • В Джанго пришел запрос на получение данных для графика в отчете. Мы достаем из БД данные, подготавливаем их и кладем в БД с быстрым доступом, например, memcached на 1 час. При следующем запросе мы сразу достанем их из memcached и отправим на фронтенд. Если мы узнаём, что данные перестали быть актуальными, мы их инвалидируем (удаляем из кэша).
  • Для кэширования статических файлов используются CDN (content delivery network) провайдеры. Это серверы, расположенные по всему миру и оптимизированные для раздачи статики. Иногда бывает эффективнее положить картинки, видео, JS-скрипты на CDN вместо своего сервера.
  • Во всех браузерах по умолчанию включено кэширование статических файлов. Благодаря этому, открывая сайт не в первый раз, все загружается заметно быстрее. Минус для разработчика в том, что со включенным кэшем не всегда сразу видны изменения сделанные в коде.

Как работают сайты

Как работают сайты

Оглавление:

Сидя в интернете, у начинающих вебмастеров или даже у простых пользователей, может возникнуть такой вопрос, а как работают сайты ?

Так вот в этой статье именно этот вопрос мы и разберём. То есть, узнаем основные принципы работы сайтов.

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

По словам википедии, веб сервер это сервер, который принимает запросы типа HTTP, от веб браузеров и выдаёт им HTTP ответы.

Вместе с HTTP ответами, веб сервер возвращает браузеру HTML страницу, изображения и другие необходимые файлы.

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

Сайты бывают двух типов, статические и динамические.

Когда мы заходим на главную страницу сайта, то в первую очередь, браузер ищет индексный файл, то есть файл с названием index. У статических сайтов, этот файл имеет расширение " .html " или " .htm ", а у динамичных сайтов " .php ".

Принцип работы статических сайтов

Со статическими сайтами всё просто. Для каждой странице, есть соответствующий html файл, который отвечает за эту страницу. Для страницы с контактами, может отвечать файл " contacts.html ", для страницы об авторе, может отвечать файл " about.html " и так далее.

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

как работает статический сайт

Принцип работы динамических сайтов

Здесь, сначала браузер также делает запрос к серверу, но сервер в этом случае уже не возвращает какой-то конкретный файл, а отправляет этот запрос на обработку интерпретатору PHP. Интерпретатор обрабатывает этот запрос и возвращает серверу обработанный код, а сервер уже возвращает браузеру этот код в формате html разметки.

как работает динамический сайт

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

Еще такой момент. Если в корне сайта находятся оба индексных файла, то есть файл " index.html " и файл " index.php ", то, когда мы заходим на главную страницу сайта, в первую очередь загружается файл " index.html ". Поэтому, если Вы хотите чтобы загружался файл " index.php ", то файл " index.html " нужно удалить.

На этом всё. Надеюсь, Вы поняли в общих чертах как работают сайты. Статья получилась не большая, но зато полезная.

Похожие статьи:

Видео по теме:

Понравилась статья?

Тогда поделитесь ею с друзьями и подпишитесь на новые интересные статьи.

Поделиться с друзьями:

Подписаться на новые статьи:

Поддержите пожалуйста мой проект!

<< Предыдущая статьяСледующая статья >>

Если у Вас есть какие-то вопросы или предложения, то можете писать их в комментариях или мне на почту [email protected]. И если Вы заметили какую-то ошибку в статье, то прошу Вас, сообщите мне об этом, и в ближайшее время я всё исправлю.

Добавляйтесь ко мне в друзья в:

Добавляйтесь в мои группы:

Подпишитесь на мои каналы:

Автор статьи: Мунтян Сергей

Копирование материалов с сайта sozdatisite.ru ЗАПРЕЩЕНО!!!

Дата добавления: 2017-08-22 05:28:18

Как работает сайт, сервер, HTTP. Настройка рабочего окружения

Длительность: 20 минут Сложность: Легко


Об уроке

В этом вступительном занятии мы изучим некоторое количество теоретической информации касательно работы веб-сайтов в целом. Узнаем что такое сайт и веб-сервер, как они взаимодействуют, и какое место в этом занимает PHP.

Кроме того, для дальнейшего изучения PHP и работы Вам потребуется определенный набор инструментов и программ. Я предлагаю использовать достаточно стандартный набор разработчика: NetBeans + Open Server или WAMP (для пользователей Windows), LAMP (для пользователей Linux), MAMP (для пользователей Mac OS). Так как большинство людей изучающих курс являются пользователями Windows, в уроке будет показан процесс настройки рабочего окружения для этой операционной системы.

P.S. Вы всегда свободны в выборе инструментов.


План

1. Как это работает:

  • Сайт
  • Клиент-серверная технология
  • Зачем нужен PHP

2. Настройка рабочего окружения:

  • Веб-сервер
  • Сервер БД
  • IDE NetBeans


Видео

Теория работы WEB:

         

Установка NetBeans:

       

Установка WAMP. Простейший сайт. Несколько слов о NetBeans:

P.S. Многие столкнулись с проблемами настройки WAMP, потому я подготовил материалы по отличной альтернативе - Open Server. Ниже ссылки на подробное руководство по установке веб-сервера и добавлению локальных доменов:

Установка web сервера OpenServer

Добавление доменов в OpenServer


Домашние задания

Очень важно закрепить пройденный материал, выполняя практические задания самостоятельно. Для этой цели я подготовил домашние задания с решениями. Всего Вас ждет более 30 интересных задач по курсу PHP Start | Теория, которые помогут лучше понять и запомнить пройденные уроки.


Полезные ссылки

Необходимые для работы программы:

Для получения информации о текущей конфигурации PHP: phpinfo()



Поделитесь в социальных сетях

Что такое CDN и как это работает? / Selectel corporate blog / Habr

Цифры и факты (вместо введения)


  • В 2010 году средний размер веб-страницы составлял 481 кБ. В 2019 — уже 1936.7 кБ (подробная статистика). За последние три года значение этого показателя выросло на 314.7%. Как показывают исследования, тенденция к увеличению размера веб-страниц сохраняется.
  • В настоящее время набирают популярность стриминговые аудио- и видеосервисы. По состоянию на апрель 2019 года число подписчиков популярного сервиса Spotify составило 217 миллионов.
  • По данным опросов 25% пользователей уходят с веб-страницы, если она загружается дольше 4 секунд. 74% пользователей, загружающих сайт с мобильного устройства, предпочитают не ждать, если загрузка длится более 5 секунд. 46% пользователей отказываются иметь дело с веб-сервисом, если он медленно работает.


О чём свидетельствуют вышеприведенные факты?

О том, что в Интернете с каждым годом становится все больше «тяжелого» контента.
А также о том, что в современном мире огромную роль играет скорость работы веб-сайтов и сервисов. Если скорость слишком мала ― это чревато потерей аудитории, а во многих случаях ― ещё и прибыли. Один из надёжных способов решения этой проблемы ― использование сетей доставки контента (Content Delivery Networks, CDN).

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

Основные термины


Прежде чем начать предметный разговор об особенностях CDN, определимся с основной терминологией.

CDN (Content Delivery Network) — это географически распределённая сетевая инфраструктура, обеспечивающая быструю доставку контента пользователям веб-сервисов и сайтов. Входящие в состав CDN cерверы географически располагаются таким образом, чтобы сделать время ответа для пользователей сайта/сервиса минимальным.

Ориджин (origin) — сервер, на котором хранятся исходные файлы или данные, раздаваемые через CDN.

PoP (point of presence, точка присутствия) — кэширующий сервер в составе CDN, расположенный в определенной географической локации. Для обозначения таких серверов также используется термин edge.

Динамический контент ― контент, генерируемый на сервере в момент получения запроса (либо изменяемый пользователем, либо загружаемый из базы данных).

Статический контент ― контент, хранимый на сервере в неизменяемом виде (например, бинарные файлы, аудио- и видеофайлы, JS и CSS).

Немного истории и теории


Резкий рост Интернета в середине 1990-х привел к ситуации, что серверы стали с трудом выдерживать нагрузку. С серверами того времени (которые по техническим характеристикам иногда были слабее не самого производительного современного ноутбука) приходилось идти на разные ухищрения: погуглите, например, «‎иерархическое кэширование» и information superhighway ― сейчас эти словосочетания используются разве что в статьях по истории интернет-технологий. Чтобы понять, как развивались технологии раздачи контента, сделаем небольшое теоретическое отступление.

Обратим внимание: раздача статического и динамического контента связаны с разными типами нагрузки на сервер. В случае с динамическим контентом, генерация которого связана с обращениями к базе данных, важны быстродействие процессора и объём оперативной памяти.

Для раздачи статического контента, который в большинстве случаев оказывается очень «‎тяжелым»‎ и который нужно загрузить очень быстро, важна в первую очередь скорость сети. Смысл технических решений для ускорения раздачи статики заключается в следующем: обеспечить горизонтальное масштабирование без сложных двусторонних синхронизаций с основным сервером.

Для снижения нагрузки владельцы веб-сервисов ещё в конце 1990-х годов начали раздавать статику и динамику с разных серверов. Крупные веб-проекты с огромной аудиторией, разбросанной по всему миру, начали размещать серверы со статикой в разных географических точках.

Тогда же, в конце 1990-х, стали появляться компании, у которых организация раздачи статики стала одним из основных направлений бизнеса. В 1998 году студент Массачусетского технологического института Дэниэл Левин и преподаватель математики Томсон Лейтон основали компанию Akamai. Ныне она является одним из крупнейших (если не самым крупным) CDN-провайдером в мире.

Уже в 2004 году CDN использовали более 3000 компаний; общий объем расходов на доставку контента составлял до 20 миллионов долларов в месяц.

Количество CDN во всём мире постоянно растет: соответствующие услуги предоставляют как крупные международные компании (например, Akamai, Amazon, Cloudflare), так и многочисленные региональные провайдеры (подробные обзоры).

CDN используется не только для раздачи статики в строгом смысле слова: распределение контента по многочисленным серверам в разных точках планеты помогает обеспечивать доступность в периоды пиковых нагрузок.

В течение последних 10-12 лет широкое распространение в Интернете получил еще один тип контента ― стриминговый (многочисленные сервисы потокового аудио и видео, которые в наши дни имеют огромную популярность и миллионную, если не миллиардную, аудиторию). Раздача сегодня является еще одним распространенным сценарием использования CDN.

Рассмотрим принципы работы и особенности использования CDN более подробно.

Как работает CDN


Представим себе веб-сервис, которым пользуются люди на всей территории России. Основные серверы расположены в Санкт-Петербурге, а пользователи находятся в самых разных географических точках: скажем, в Краснодаре (2 604,2 км от Петербурга), Новосибирске (3 826,1 км), Иркутске (5 661, 7 км) или Владивостоке (9 602, 4 км). Чем дальше пользователь находится от оригинального сервера, тем больше время «‎оригинального»‎ ответа. На заре Рунета, в самом начале 2000-х, жители Южно-Сахалинска или Петропавловска-Камчатского могли дожидаться полной загрузки простой веб-страницы полновесные 5, а то и все 10, минут.

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

Для ускорения раздачи динамики при использовании CDN используются другие механизмы: CDN-провайдер за счет своей сети сокращает сетевой маршрут.

Ещё один интересный сценарий использования CDN ― так называемый live-streaming: пользователи Интернета со всего мира могут в браузере (а иногда и в специальном приложении) смотреть или слушать трансляцию с мест событий. Устроено это так: один или несколько ориджин-серверов принимают c видеокамеры транслируемый поток, который сразу же ретранслируется на точки присутствия. Ориджин-серверы при этом контент клиентам не раздают. В состав стриминговых CDN входят также балансировщики нагрузки, перенаправляющие запросы к наименее загруженным на текущий момент edge-серверам.

Как организована раздача контента?


Как правило, для настройки раздачи статического контента через CDN необходимо выполнить следующие шаги:

Шаг 1: Вынести статику сайта на отдельный домен, например, static.example.com — это будет origin.

Шаг 2: Для работы через CDN создать домен вида cdn.example.com.

Шаг 3: Подключить CDN у провайдера. Для подключения владельцу веб-сервиса необходимо сообщить провайдеру следующее:
домен, с которого он будет забирать статику — static.example.com;
домен, с которого будет идти раздача — cdn.example.com.

Шаг 4: У своего DNS-регистратора настроить CNAME запись с cdn.example.com на домен CDN-провайдера, который CDN провайдер выделяет при подключении.
Например, в CDN Selectel такой домен имеет вид 85e77c09-bc03-43bf-b8f3-9492ae33390f.selcdn.net, где 85e72c09-bc03-43bf-b8f3-9492ae33390f генерируется автоматически.

Шаг 5: На своем сайте изменить домен для статики, которую планируется раздавать через CDN, на cdn.example.com.

Пользователь набирает в строке браузера адрес www.example.com, с которого он получает HTML-страницу. При этом весь статический контент, например, графические изображения, подгружается из CDN (с адреса cdn.example.com).

Статический контент, предназначенный для раздачи, часто помещается в объектные хранилища (об этом мы писали еще шесть лет назад). Существует множество плагинов и расширений для популярных CMS (WordPress, Joomla, Drupal, 1C Битрикс и других), с помощью которых можно настроить интеграцию с облачными сервисами хранения и раздачу статики через CDN.

Веб-сервис после подключения CDN будет работать на том же оригинальном сервере. Кэшированные части сайта будут загружены на серверы CDN-сети. Система находит для пользователя ближайший сервер и максимально быстро загружает статику сайта с него.

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

Как CDN понимает, где находится ближайший кэширующий сервер?


Как правило, для подгрузки контента из CDN используются две популярные технологии: GeoDNS и AnyCast.

С помощью GeoDNS можно привязать к одному доменному имени несколько IP-адресов. В зависимости от географического положения (определяется по IP-адресу, с которого пришел запрос) пользователь перенаправляется на ближайший сервер. Об особенностях работы GeoDNS можно почитать в этой статье (на английском языке).

При использовании технологии Anycast адреса общие, но маршрутизация происходит на «‎свои» серверы в пределах региона. При обращении к адресу www.example.com пользователь переадресуется на ближайшую точку присутствия. Провайдер пользователя получает несколько анонсов от разных сетей, в которых есть точка присутствия, и маршрутизатор провайдера выбирает из них самый близкий. Ответ аналогичным образом возвращается по наиболее короткому маршруту.

Как кэшируется контент?


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

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

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

В большинстве CDN пользователь, отправивший запрос на получение статического контента, переадресуется к ближайшей точке присутствия и получает кэшированную версию этого контента с неё. Если ближайшая точка присутствия не сможет найти файлы, начнётся поиск по соседним точкам присутствия, откуда и будет перенаправлен ответ пользователю. В CDN Akamai эта процедура называется tiered distribution (на русский можно перевести как «многоуровневая раздача»).

Для чего используются CDN?


Чаще всего CDN используется для уменьшения времени отклика кэшированного контента, что, как мы уже упоминали выше, уменьшает отток посетителей из-за медленной загрузки ресурса и тем самым сокращает возможные финансовые потери. Также CDN помогает снизить риск потери доступа к контенту из-за падения основного сервера. Контент будет доступен всё время, пока вы восстанавливаете работоспособность основного сервера.

Использование CDN существенно снижает нагрузку на основной сервер, что помогает решить проблему пиковых нагрузок. Современная CDN способна переживать очень большие нагрузки. В конце 2018 года компания Akamai заявила о рекордном объеме передаваемого через CDN трафика: 72 Тб/c.

В наше время CDN активно используются также для раздачи стримингового контента.

О чем важно помнить при работе с CDN?


Как и любая технология, CDN обладает рядом особенностей.

Самая первая проблема, с которой могут столкнуться использующие CDN веб-сервисы ― это задержки кэширования. Вполне вероятна следующая ситуация: на основном сервере файл был изменён, а вот на кэширующих серверах он всё ещё будет лежать в неизмененном виде. Это особенно важно, когда через CDN распространяется часто обновляемый контент (фотографии с места событий, новые версии ПО и так далее)

Чтобы обеспечить доставку «свежего» контента в современных CDN имеется функция очистки кэша, то есть удаление контента из пула кэширования. Кроме того, владельцы сайтов и сервисов могут сами управлять настройками, используя заголовки-валидаторы (см. наши рекомендации на эту тему в опубликованной ранее статье).

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

Кому нужны CDN?


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

CDN может пригодиться также разработчикам мобильных приложений: по статистике, пользователи часто отказываются продолжать работу с приложением из-за проблем со скоростью. В последнее время появились специальные технические решения, ориентированные на раздачу контента на мобильные устройства. Они так и называются ― Mobile CDNs. Соответствующие услуги предлагают многие крупные CDN-провайдеры ― например, Akamai или Amazon.

Нужны CDN и проектам, ориентированным на распространение игрового, мультимедийного контента и стриминг (об этом уже было сказано выше).

На что обратить внимание при выборе CDN-провайдера (вместо заключения)


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

На что нужно обратить внимание при выборе CDN-провайдера?

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

Во-вторых, это наличие стыков с операторами связи. Это тоже немаловажный фактор, от которого зависит скорость и эффективность работы CDN. Например, у CDN-провайдера с точками присутствия в 100 городах, но небольшим количеством стыков задержка может быть больше, чем у провайдера, у которого точки присутствия расположены в 5 городах, но стыков с операторами связи гораздо больше.

К сожалению, такую информацию в большинстве случаев CDN-провайдеры не публикуют, поэтому проверить всё можно только тестированием.

В-третьих, на наличие дополнительных услуг и функций. Многие CDN-провайдеры предоставляют такие услуги, как анализ статистики потребления, управление политиками кэширования, управление HTTP-заголовками, предзагрузка очень «тяжёлого» (от 200 МБ и более контента), полная и выборочная очистка кэша.

Кроме того, при выборе CDN-провайдера нужно проверить, поддерживает ли он необходимые вам технологии и протоколы (HTTP/2, IPv6, сертификаты SSL и другие).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *