TCP vs UDP: Главная битва транспортного уровня #сетевые_протоколы

# OSI против TCP/IP: Теория против Практики

В компьютерных сетях существуют две главные архитектуры, описывающие правила путешествия данных между устройствами: модель **OSI** и стек **TCP/IP**. 

Если говорить кратко: **OSI — это идеальный чертеж здания, а TCP/IP — это само здание, построенное на практике.**

---

### Наглядная аналогия: Отправка посылки

Представьте работу курьерской службы:
* **В модели OSI** детально регламентирован каждый микро-шаг: написание текста, перевод на понятный язык, упаковка в коробку, проверка адреса, выбор класса доставки, планирование маршрута между городами, движение грузовика по трассе и вращение его колес.
* **В модели TCP/IP** этапы объединены ради скорости: вы просто приносите вещь в пункт выдачи (**Прикладной** уровень), служба выбирает тип доставки (**Транспортный**), логисты распределяют маршрут по индексам (**Сетевой**), а транспорт везет посылку по дорогам (**Сетевой доступ**).

---

### Сравнительная таблица уровней

Модель TCP/IP проще, так как она объединяет несколько абстрактных уровней OSI в один практический блок.

| Модель OSI (7 уровней) | Модель TCP/IP (4 уровня) | Что происходит на этом этапе? | Примеры |
| :--- | :--- | :--- | :--- |
| **7. Прикладной (Application)**<br>**6. Представления (Presentation)**<br>**5. Сеансовый (Session)** | **1. Прикладной (Application)** | Пользовательские программы создают данные. Здесь же происходит их кодирование, сжатие и шифрование (например, TLS/SSL для HTTPS). | HTTP, HTTPS, FTP, DNS |
| **4. Transport (Транспортный)** | **2. Transport (Транспортный)** | Передача данных между конкретными программами. Отвечает за надежность (TCP) или скорость (UDP). | TCP, UDP, Порты (80, 443) |
| **3. Network (Сетевой)** | **3. Internet (Сетевой / Межсетевой)** | Адресация устройств в глобальной сети. Поиск оптимального пути для пакетов (маршрутизация). | IP (IPv4/IPv6), Роутеры |
| **2. Data Link (Канальный)**<br>**1. Physical (Физический)** | **4. Network Access (Сетевой доступ)** | Передача чистых битов (0 и 1) по конкретной физической среде: проводу, оптоволокну или радиоволне. | Ethernet, Wi-Fi, MAC-адреса |

---

### Ключевые различия моделей

1. **Происхождение**. OSI (Open Systems Interconnection) создавалась международными институтами стандартизации (ISO) как строгий академический эталон. TCP/IP создавался Министерством обороны США (DARPA) как практический стек для строящегося Интернета.
2. **Жизнеспособность**. Модель OSI слишком долго застряла на этапе проектирования. К моменту ее финального релиза мир уже вовсю работал на базе TCP/IP. Поэтому сегодня OSI используется преимущественно для обучения и классификации.
3. **Философия надежности**. В модели TCP/IP за доставку и исправление ошибок отвечает только конечный узел (Транспортный уровень — TCP), а сама сеть (уровень IP) работает максимально просто и быстро. В OSI функции контроля были размыты по нескольким уровням.

---

### Итог

Сегодня весь мировой интернет работает на стеке **TCP/IP**. Однако сетевые инженеры до сих пор используют терминологию **OSI** для удобства общения. Например, когда говорят *«проблема на 3-м уровне»*, все сразу понимают, что речь идет о сетевых настройках, неполадках с IP-адресами или роутерами.

Наглядное сравнение TCP/IP и OSI #сетевые_протоколы

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

> 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` 👉 Файл `/etc/hosts` в Linux работает как локальный DNS-сервер, сопоставляя имена хостов с IP-адресами с наивысшим приоритетом: система сначала ищет запись в этом файле; если находит, использует указанный IP, минуя DNS-серверы, что полезно для временных настроек (например, тестирования сайта) или блокировки доступа к ресурсам путем указания неверного IP. **По шагам:** Запрос имени: Вы вводите имя хоста (например, **example.com**) в браузере или приложении. ➡️ Проверка `/etc/hosts` (Приоритет 1): Система смотрит в файл `/etc/hosts` ➡️ Сопоставление: ➡️ Если найдена запись вида `192.168.1.100 example.com`, система сразу использует **192.168.1.100** ➡️ Если записи нет, система переходит к следующему шагу. ➡️ Запрос к DNS (Приоритет 2): Запрос отправляется к настроенным DNS-серверам (указанным в `/etc/resolv.conf`)
- Из кэша ОС
- *(как описано выше)* Из обращения к DNS-резолверу интернет провайдера. Если он не имеет информации о домене, он отправит запрос на один из корневых серверов, которые оперируют информацией о доменах первого уровня (**.ru, .com** и т.д.) и знают, к каким DNS-серверам обратиться, чтоб найти информацию в рамках определенной доменной зоны. Полученный результат будет сохранен в кэш.

![DNS resolver](https://pravosleva.pro/express-helper/chat/storage/uploads/sp.pravosleva/1748330246231.png)

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

Протокол TCP описывает, как данные делятся на пакеты: их нумерация, обработка и проверка принимающей стороной.

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

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

5. **На уровне HTTP** браузер формирует объект запроса, который состоит из 1) Заголовков (мета информация), 2) Тела (целевая информация)

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

7. Получение документа в виде HTML строки (по тому же TCP-соединению через который был получен запрос)

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"
    }
  ]'
/>

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

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

Третья версия протокола передачи гипертекста HTTP.
- С июня 2022 года находился в стадии предлагаемого стандарта. HTTP/3 основан на [QUIC](https://ru.wikipedia.org/wiki/QUIC) — экспериментальном сетевом протоколе транспортного уровня (поверх UDP), разработанном в 2012 году компанией Google.
- Был принят [IETF](https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80%D0%BD%D1%8B%D0%B9_%D1%81%D0%BE%D0%B2%D0%B5%D1%82_%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82%D0%B0) как рекомендованный стандарт в июне 2022 года. 

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

Поддержка HTTP/3 была добавлена в Chrome (сборка Canary) в сентябре 2019 года, и была включена по умолчанию в апреле 2020 года. Firefox поддерживает HTTP/3 с апреля 2021. Экспериментальная поддержка HTTP/3 была добавлена в Safari Technology Preview 8 апреля 2020 года а потом в Safari 14, но всё ещё выключена по умолчанию.

## 🚀 Что нового:
- **Транспортный протокол:** Использует QUIC, который работает поверх UDP, в отличие от HTTP/2, который использует TCP.
- **Решена проблема блокировки пакетов (Head-of-Line-Blockierung):** QUIC устраняет проблему блокировки пакетов, которая возникает, когда потеря одного пакета может заблокировать весь поток данных. Вместо этого в HTTP/3 могут быть заблокированы только отдельные потоки, не затрагивая остальные.
- **Быстрый хендшейк:** QUIC интегрирует TLS-шифрование в процесс установления соединения, что позволяет сократить время на установку соединения (1-RTT) или даже достичь нулевого времени (0-RTT).
- **Безопасность:** Имеет встроенную поддержку TLS, что обеспечивает более полную и надежную защиту данных.
- **Миграция соединения:** Позволяет сохранять активное соединение при смене IP-адреса или сетевого интерфейса, например при переключении между Wi-Fi и мобильным интернетом.

<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"
    }
  ]'
/>

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

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

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

## 🚀 Что нового:
- **Мультиплексированные потоки.** Пересылаемая через 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/1.1 (01.1997)

HTTP/1.1 — это протокол передачи данных, который использует текстовый формат для обмена информацией между клиентом и сервером. Он ввел ключевые возможности, такие как keep-alive для поддержания постоянного TCP-соединения для нескольких запросов, что сокращает задержки, и поддержку прокси-серверов.

![keep-alive](https://gosuslugi.pravosleva.pro/express-helper/chat/storage/uploads/ux-test/1762398864541.png)

> HTTP 1.1 ввел такое понятие как виртуальные хосты. С точки зрения реализации в протоколе HTTP появилась одна небольшая деталь. Кроме request line стал обязательным еще и заголовок, который называется host. Он определяет, какой именно домен должен быть возвращен с этого IP адреса. [Источник](https://ru.hexlet.io/courses/http_protocol/lessons/http_1_1/theory_unit)

## 🚀 Что нового:
- Текстовый формат: Запросы и ответы передаются в виде простого текста, что делает протокол легко читаемым и отлаживаемым.
- «Keep-alive»: По умолчанию соединение не закрывается после каждого запроса. Это позволяет повторно использовать одно и то же TCP-соединение для нескольких запросов, что снижает нагрузку на сервер и сокращает время ожидания.
- Управление потоком: Управление потоком осуществляется на основе базового TCP-соединения, что требует отдельного механизма управления для каждого соединения.
- Совместимость: Широко поддерживается старой инфраструктурой и сторонними API, что делает его популярным выбором для проектов, где высокая производительность не является критическим фактором.
- Применимость: Прост в изучении и отладке, подходит для простых REST API и других приложений, где не требуется высокой параллельной обработки данных.

# HTTP/1.0 (05.1996)
HTTP/1.0 — одна из версий протокола передачи гипертекста (HTTP), используемая для передачи контента, такого как HTML, между клиентами (например, веб-браузерами) и веб-серверами.

## 🚀 Что нового:
- HTTP/1.0 ввел заголовки, статусные коды и методы (POST, HEAD), в то время как HTTP/0.9 был гораздо более простым: поддерживал только метод GET, не имел заголовков и позволял передавать только текстовое содержимое

# HTTP/0.9 (1991)
HTTP/0.9 (однострочный протокол) был чрезвычайно прост
## 🚀 Особенности:
- Запросы состояли из одной строки и начинались с единственно возможного метода GET, за которым следовал путь к ресурсу
- Полный URL не включался, поскольку после подключения к серверу протокол, сервер и порт не требовались.

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

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"
    }
  ]'
/>

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

> А можешь TCP поменять и перезапросить? *(ДевОпс фронтендеру)*

*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) я нашёл список запрещённых для изменения заголовков в браузере.

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