*Самую короткую формулировку видел в Гугле, но, думаю, она не всех устроит:*

> The browser parses the html (DOM) and gets the external resources in an array or stack-like structure. After the html is loaded, the browser starts to load the external resources in the structure in parallel and execute, until all resources are loaded. (Google)

1. Браузер определяет, введённая строка - это URL или поисковый запрос. Если это URL, то делает разбор адреса:
```
http: //   domain.ru / index.html ? param1=1
[protocol] [host]      [resource]   [params]
```

2. Резолв доменного имени в IP (для попадания данных в сетевой уровень передачи данных)
- Из локального кэша
- Из `/etc/hosts`
- Из кэша ОС
- Из обращения к DNS

3. Handshake: Установка TCP соединения. // See also: [Уровни сетевых протоколов](https://pravosleva.pro/blog/article/protocols)

4. Handshake: Проверка подлинности SSL сертификата. // See also: [Как работает SSL/TLS-рукопожатие](https://pravosleva.pro/blog/article/protocols-ssl-tls)

5. Формирование HTTP заголовков

6. Отправка HTTP запроса

7. Получение документа в виде HTML строки

8. Парсинг HTML строки по алгоритмам из спецификации (операция в несколько потоков)

9. Формирование DOM (что нужно отрисовать)

10. Формирование CSSOM (как нужно отрисовать) // See also: [Блокировка рендеринга CSS - Как это исправить?](https://bcorrections.com/blog/speed/render-blocking-css)

11. Формирование Render Tree (на основе DOM & CSSOM) - Набор объектов рендеринга (Webkit использует термин «renderer», или «render object», а Gecko — «frame»)

12. Layout - Для каждого элемента render tree рассчитывается положение на странице. Браузеры используют поточный метод (flow), при котором в большинстве случаев достаточно одного прохода для размещения всех элементов.

13. Paint - происходит отрисовка всего этого в браузере

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

15. Reflow **(более затратный процесс, который включается при изменении размеров, положения элементов или при добавлении/удалении элементов)** - Если же изменения затрагивают содержимое, структуру документа, положение элементов — происходит reflow (или relayout). Причинами таких изменений обычно являются:
- Манипуляции с DOM (добавление, удаление, изменение, перестановка элементов);
- Изменение содержимого, в т.ч. текста в полях форм;
- Расчёт или изменение CSS-свойств;
- Добавление, удаление таблиц стилей;
- Манипуляции с атрибутом «class»;
- Манипуляции с окном браузера — изменения размеров, прокрутка;
- Активация псевдо-классов (например, :hover).

[See also](https://habr.com/ru/articles/224187/)

<ControlsBox
  controlsJson='[
    {
      "title": "NEXT",
      "label": "See also: How does a Browser render a Webpage?",
      "type": "link",
      "link": "https://dev.to/anuradha9712/how-does-a-browser-render-a-webpage-2en8"
    }
  ]'
/>

Как браузер загружает веб страницу // без особого погружения в #сетевые_протоколы

# About [HTTP/3](https://ru.wikipedia.org/wiki/QUIC)

Третья версия протокола передачи гипертекста HTTP. С июня 2022 года находится в стадии предлагаемого стандарта. HTTP/3 основан на [QUIC](https://ru.wikipedia.org/wiki/QUIC) — экспериментальном сетевом протоколе транспортного уровня (поверх UDP), разработанном в 2012 году компанией Google.

Первоначальное название — **HTTP-over-QUIC**. Главное отличие от предыдущих в — он использует новый транспортный протокол и передаёт контент быстрее.

<ControlsBox
  controlsJson='[
    {
      "title": "PREV",
      "label": "Протоколы обеспечения безопасности SSL; TLS",
      "type": "link",
      "link": "https://pravosleva.pro/blog/article/protocols-ssl-tls"
    },
    {
      "title": "Читать на edgecenter.ru",
      "label": "HTTP/3 и QIUC: будущее интернета (2022)",
      "type": "link",
      "link": "https://edgecenter.ru/blog/http3-and-quic-the-future-of-the-internet"
    },
    {
      "title": "END_TELEGRAM",
      "label": "See also comment by Zh",
      "type": "link",
      "link": "https://t.me/bash_exp_ru/466/467"
    }
  ]'
/>

# About [HTTP/2](https://ru.wikipedia.org/wiki/HTTP/2)

## Чем был плох HTTP 1.1?

HTTP 1.1 позволяет обрабатывать лишь один поступивший запрос на одно TCP-соединение, поэтому браузеру приходится устанавливать несколько соединений, чтобы обрабатывать одновременно несколько запросов.

## Особенности HTTP/2

- **Мультиплексированные потоки.** Пересылаемая через HTTP/2 в обе стороны последовательность текстовых фреймов, которыми обмениваются между собой клиент и сервер, называется “потоком”. В ранних версиях HTTP можно было транслировать только по одному потоку за раз, с небольшой задержкой между разными потоками. Передавать таким способом большие объёмы медиа-контента было слишком неэффективно и ресурсозатратно. Для решение этой проблемы в HTTP/2 применяется новый бинарный слой фреймов.
- **Отправка данных по инициативе сервера (Server Push).** Эта возможность позволяет серверу отправлять клиенту дополнительную кэшируемую информацию, которую тот не запрашивал, но которая может понадобиться при будущих запросах. Например, если клиент запрашивает ресурс Х, который ссылается на ресурс Y, то сервер может передать Y вместе с Х, не дожидаясь от клиента дополнительного запроса.
- **Приоритезация потоков.** HTTP/2 позволяет клиенту отдавать предпочтения конкретным потокам данных. Хотя сервер и не обязан следовать подобным клиентским инструкциям, тем не менее этот механизм помогает серверу оптимизировать распределение сетевых ресурсов согласно требованиям конечных пользователей.
- **Сжатие заголовков с сохранением состояния.** Чтобы произвести на пользователей наилучшее впечатление, современные веб-сайты должны быть богаты контентом и графикой. HTTP — это протокол без сохранения состояния, то есть каждый клиентский запрос должен содержать как можно больше информации, необходимой серверу для выполнения соответствующей операции. В результате потоки данных содержат многочисленные повторяющиеся фреймы, потому что сервер не должен хранить информацию из предыдущих клиентских запросов.

HTTP/2 создавался с учётом повышения эффективности клиент-серверного обмена данными, что позволяет бизнесменам увеличить охват своих сегментов рынка, а пользователям — быстрее получить доступ к качественному контенту. Помимо прочего, сегодня веб ситуативен как никогда ранее.

<ControlsBox
  controlsJson='[
    {
      "title": "Читать на Хабре",
      "label": "Как HTTP/2 сделает веб быстрее (2016)",
      "type": "link",
      "link": "https://habr.com/ru/companies/nix/articles/304518/"
    }
  ]'
/>

HTTP #сетевые_протоколы 

HTTP и WS работают поверх TCP

TCP несимметричный, есть сервер (тот, кто принимает запрос на соединение) и клиент (тот, кто инициирует запрос). Соединение состоит из двух пар значений IP_адрес:ПОРТ, для сервера и клиента. После того как соединение установлено, поменять там ничего нельзя - только разорвать соединение и установить новое

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

//

Эту проблему надо решать не на прикладном уровне. DNS можно использовать, чтобы балансировать нагрузку. Или, можно создать хренову тучу поддоменов, вида ip1.smartprice.ru ip2.smartprice.ru и т.д. и всё таки переложить балансировку на прикладной уровень. Но подделывать HTTP заголовки браузер не даст

Правда, если проблема проявляется только на планшетах Сбера, а на остальных всё нормально, то видимо дело не в нагрузке. Надо раздобыть планшет на тест и выяснить в чём дело.  Может у них там антивирус что-нибудь особенное делает, они это любят

Вот я нашёл список запрещённых для изменения заголовков в браузере:
https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_header_name

About #TCP | fetchRetry, корпоративные планшеты Сбера #smartprice #сетевые_протоколы

TLS-рукопожатие происходит после того, как с помощью TCP-рукопожатия было установлено TCP-соединение.

## Как работает SSL-рукопожатие
1. Браузер создаёт запрос серверу, есть ли у него сертификат SSL
2. Сервер отдает информацию и публичный ключ
3. Браузер получает информацию и сверяет ее с центром сертификации
4. Если информация подтверждается, браузер генерирует сеансовый ключ, зашифровывает его с помощью публичного ключа сервера, и отправляет на сервер
5. Сервер, получив зашифрованный сеансовый ключ, расшифровывает его с помощью приватного ключа и сохраняет сеансовый ключ, который будет использоваться для шифрования в данной сессии.

<ControlsBox
  controlsJson='[
    {
      "title": "START_NEW_TAB",
      "label": "Что происходит при TLS-рукопожатии? | SSL-рукопожатие",
      "type": "link",
      "link": "https://www.cloudflare.com/ru-ru/learning/ssl/what-happens-in-a-tls-handshake/"
    }
  ]'
/>

## Что происходит при TLS-рукопожатии?
В ходе TLS-рукопожатия клиент и сервер вместе выполняют следующие действия:
- Указывают, какую версию TLS (TLS 1.0, 1.2, 1.3 и т. д.) они будут использовать
- Решают, какие наборы шифров (ряд алгоритмов, используемый при установлении защищенного соединения) они будут использовать
- Проверяют подлинность сервера с помощью открытого ключа сервера и цифровой подписи центра сертификации SSL.
- Генерируют сеансовые ключи, чтобы использовать симметричное шифрование после завершения рукопожатия

<ControlsBox
  controlsJson='[
    {
      "title": "PREV",
      "label": "TCP-рукопожатие",
      "type": "link",
      "link": "https://pravosleva.pro/blog/article/protocols-tcp"
    },
    {
      "title": "NEXT",
      "label": "HTTP",
      "type": "link",
      "link": "https://pravosleva.pro/blog/article/protocols-http"
    }
  ]'
/>

Протоколы обеспечения безопасности SSL; TLS hadnshake #сетевые_протоколы

## Как устанавливается соединение: TCP handshake
Процесс TCP handshake — это сердце коммуникации в интернете. Он состоит из трех этапов, которые гарантируют, что соединение между двумя устройствами установлено надежно и данные могут передаваться без ошибок.

Первый этап: одно устройство (клиент) отправляет другому устройству (серверу) специальный запрос (SYN пакет), который можно сравнить с просьбой "Давай поговорим!".
Второй этап: сервер отвечает клиенту, отправляя комбинированный пакет (SYN+ACK), который в переводе на человеческий язык звучит как "Да, давай поговорим. Я готов слушать!".
Третий этап: клиент подтверждает получение ответа от сервера, отправляя пакет ACK, что в нашей аналогии означает "Отлично, я начинаю говорить".
Эти три шага гарантируют, что обе стороны готовы к обмену данными, знают о существовании друг друга и могут надежно передавать информацию.

## Зачем нужен этот сложный процесс?
Надежность и эффективность — вот что делает TCP handshake таким важным. Без этого процесса интернет был бы как большая вечеринка, где все говорят одновременно и никто не слышит друг друга. TCP handshake обеспечивает, что каждое сообщение доставлено и принято в правильном порядке, и что нет потерянных или перепутанных данных. Это как если бы на вечеринке был специальный координатор, который бы убедился, что ваше сообщение доставлено именно тому человеку, которому вы его адресовали.

<ControlsBox
  controlsJson='[
    {
      "title": "START_NEW_TAB",
      "label": "TCP handshake: как работает трехстороннее рукопожатие",
      "type": "link",
      "link": "https://sky.pro/wiki/javascript/tcp-handshake-kak-rabotaet-trehstoronnee-rukopozhatie/"
    }
  ]'
/>

## Инструменты для изучения TCP handshake
Для тех, кто хочет углубиться в изучение процесса TCP handshake и других аспектов сетевых протоколов, существуют мощные инструменты, такие как Scapy и Wireshark. Эти инструменты позволяют "заглянуть под капот" интернета, анализировать трафик и экспериментировать с сетевыми протоколами. Используя их, можно не только лучше понять, как работает интернет, но и научиться обнаруживать и устранять сетевые проблемы.

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

<ControlsBox
  controlsJson='[
    {
      "title": "PREV",
      "label": "OSI; TCP/IP",
      "type": "link",
      "link": "https://pravosleva.pro/blog/article/protocols"
    },
    {
      "title": "NEXT",
      "label": "Протоколы обеспечения безопасности SSL; TLS-рукопожание",
      "type": "link",
      "link": "https://pravosleva.pro/blog/article/protocols-ssl-tls"
    }
  ]'
/>

TCP handshake #сетевые_протоколы

У моделей OSI и TCP имеется много общих черт. Обе модели основаны на концепции стека независимых протоколов.

<CollapsibleBox
header="Модель OSI"
text="**Open Systems Interconnection protocols** (Протоколы взаимодействия открытых систем) — это концептуальная модель, разработанная еще в 1970-х годах, чтобы описать архитектуру и принципы работы сетей передачи данных. А также модель OSI характеризует и стандартизирует то, как различные компоненты программных обеспечений и аппаратных средств, участвующие в сетевой коммуникации, должны разделять труд и взаимодействовать друг с другом. Это имеет семь уровней"
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#1-osi"
  },
  {
    "label": "community.fs.com",
    "link": "https://community.fs.com/ru/article/tcpip-vs-osi-whats-the-difference-between-the-two-models.html",
    "target": "_blank"
  }
]'
/>

<CollapsibleBox
header="Стек протоколов TCP/IP"
text="Модель TCP/IP описывает процесс передачи цифровых данных. Модель ISO OSI и протоколы к ней были готовы когда TCP/IP уже фактически использовались на практике. Они оказались сложнее TCP/IP, но не лучше, поэтому на практике не использовались. Модель протоколов (семиуровневая) ISO OSI часто используется для классификации протоколов, однако при описании TCP/IP, как у тебя правильно  отмечено, используется только 5."
actionsJson='[
  {
    "label": "LOCAL_LINK",
    "link": "#1-tcpip"
  }
]'
/>

# OSI

OSI Protocols ([**Open Systems Interconnection protocols**](https://en.wikipedia.org/wiki/OSI_protocols) Протоколы взаимодействия открытых систем) — это семейство стандартов обмена информацией, разработанных совместно [ISO](https://en.wikipedia.org/wiki/International_Organization_for_Standardization) и [ITU-T](https://en.wikipedia.org/wiki/ITU-T). Процесс стандартизации начался в 1977 году, но в итоге получил много критики в осн. из-за избыточной сложности реализации.

![iso](https://pravosleva.pro/express-helper/chat/storage/uploads/sp.pravosleva/1730722879991.png)

![img](https://pravosleva.pro/express-helper/chat/storage/uploads/sp.pravosleva/1730724440813.png)

Cемиуровневая модель OSI часто используется в качестве справочного материала для обучения и документирования.
- **Прикладной уровень** ([HTTP](https://ru.wikipedia.org/wiki/HTTP) / [HTTPS](https://ru.wikipedia.org/wiki/HTTPS) / FTP / POP3 / SMTP / WS / WSS) - реализован на уровне приложений;
- **Уровень представления** (SSL / TLS) - реализован на уровне приложений. Решает проблемы кодирования/декодирования, шифрования/дешифрования информации. Если сервер, к которому вы посылаете запрос, работает на протоколе HTTPS, то в него включён протокол защиты данных — SSL. SSL развивался до версии 3.0. Потом на основе него был создан TLS, который сейчас используется везде и гарантирует безопасность соединения. Принцип работы протокола базируется на ассиметричном шифровании и для создания безопасного канала связи оперирует такими понятиями как публичный ключ, приватный ключ, сеансовый ключ. TLS-рукопожатие происходит после того, как с помощью TCP-рукопожатия было установлено TCP-соединение. Ещё пример: корректная интерпретация при передачи изображений GIF, JPEG.
- **Сеансовый** - реализован на уровне приложений. Решает задачу установки и завершения соединения между взаимодействующими приложениями (VPN conn protocols: L2TP, PPTP)
- **Транспортный** (TCP / UDP)
- **Сетевой** - Решает проблемы маршрутизации траффика; Маршрутизаторы (router) передают пакеты информации, в которых содержится соответствие MAC-адресов и IP сетевого уровня. Информация об известных IP и MAC адресах хранится в таблице в ОС роутера, который распределяет трафик, полученный из глобальной сети между устройствами локальной сети
- **Канальный** - Решает проблемы адресации (биты собираются в кадры/фреймы, внутри которых служебная информация об отправителе и получателе); Коммутаторы (switch) передают сформированные кадры между сетевыми устройствами, используя физические MAC-адреса сетевых адаптеров (уникальный 48-битный id устройства)
- **Физический** - Решает проблему передачи сигнала по проводникам либо с помощью электромагнитных волн. Все проводные соединения описаны стандартом ETHERNET (бит как единица информации)

![img](http://pravosleva.pro/express-helper/chat/storage/uploads/sp.pravosleva/1725963909964.jpg)

# 🎓 BTW
<YoutubeGrid json='["x2j_fbTsQo8", "4a2CeSD1yIk"]' />

# TCP/IP

Стек протоколов созданный на основе NCP ([Network Control Protocol](https://ru.wikipedia.org/wiki/Network_Control_Protocol)). Первая демонстрация в 1976 передачи данных по трем различным сетям: Сан-Франциско / Лондон / Университет в Южной Калифорнии (итог - 150К км без потерь байтов).

> Я бы советовал мыслить в категориях TCP/IP, а OSI упоминать только на собесах)

![tcp-ip](https://pravosleva.pro/express-helper/chat/storage/uploads/sp.pravosleva/1730723028871.png)

1. **Физический** (нет в стандарте, но есть в вики)

2. **Канальный** + подуровень "управления доступа к среде" (Media Access Control, MAC, он нужен в сетях наподобие Ethernet или WiFi, где устройства должны иметь возможность внутри сети передавать информацию и иметь адресацию до того как им будут назначены IP адреса, в противоположность соединениям точка-точка (point to point protocol, PPP), где у тебя один провод или волокно и ты точно знаешь что на другом конце провода одно устройство)

3. **Сетевой**, это IP4 и IP6, это и есть Интернет, IP это Internet Protocol. Здесь происходит маршрутизация пакетов. С точки зрения маршрутизатора сетевого уровня у него есть несколько интерфейсов с уникальными IP адресами и таблица маршрутизации. На любой интерфейс может придти IP пакет адресованный кому угодно, следуя таблице маршрутизации маршрутизатор (роутер) либо отправит его на один из своих IP интерфейсов либо удалит его.

4. **Транспортный** уровень. Это уровень который обеспечивает надёжное соединение (гарантию доставки информации при этом в правильном порядке, до этого уровня никаких гарантий не было). Фактически этим занимается только протокол TCP. Логически он представляет двусторонний канал связи куда можно писать и читать. Протокол TCP реализован в виде программы (в ядре), которая отправляет и получает IP пакеты, следит за из порядком и успешностью доставки, отправляет повторно если пакет не дошёл. Есть ещё псевдо протокол UDP, который ничего не гарантирует и просто кладёт информацию в IP пакет и отправляет. Он нужен чтобы из юзерспейса приложения могли сами реализовывать свой транспорт, если TCP им не подходит (например для трансляции видео надёжность не важна, а задержки очень важны, TCP не очень подходит)

5. **Прикладной** уровень, всё что делает приложение и сервер поверх транспортного. Сюда попадает и HTTP, и шифрование и всё подряд

<ControlsBox
  controlsJson='[
    {
      "title": "START_NEW_TAB",
      "label": "Что происходит когда вводишь url или как работает интернет",
      "type": "link",
      "link": "https://habr.com/ru/companies/karuna/articles/568702/"
    },
    {
      "title": "NEXT",
      "label": "TCP-handshake",
      "type": "link",
      "link": "https://pravosleva.pro/blog/article/protocols-tcp"
    }
  ]'
/>

сетевые_протоколы

Как браузер загружает веб страницу // без особого погружения в #сетевые_протоколы

HTTP #сетевые_протоколы

About #TCP | fetchRetry, корпоративные планшеты Сбера #smartprice #сетевые_протоколы

Протоколы обеспечения безопасности SSL; TLS hadnshake #сетевые_протоколы

TCP handshake #сетевые_протоколы

OSI; TCP/IP #сетевые_протоколы