Обновление

dev/architecture/Database per service.md

@@ -1,6 +1,7 @@
 ---
 aliases:
   - separate data store
+  - своя база данных
 tags:
   - maturity/🌱
 date: 2024-11-24

dev/architecture/Shared Database.md

@@ -1,5 +1,6 @@
 ---
-aliases: 
+aliases:
+  - общей базы данных
 tags:
   - maturity/🌱
 date: 2024-11-24

dev/architecture/Архитектурная концепция.md

@@ -12,12 +12,14 @@ date: 2024-10-01
 
 ## Классификация
 На уровне системы:
-- [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+- [[../../../../wiki/zero/00 Микросервисная архитектура|Микросервисная архитектура]]
+- [[Монолитная архитектура]]
 - [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированное программирование]]
 - [[Асинхронное программирование]]
 - [[Реактивное программирование|Реактивное программирование]]
 
 На уровне компонентов системы:
+- [[Паттерн проектирования]]
 - [[Inversion of Control]]
 - [[Один клиент — один поток]]
 - [[Много клиентов — один поток]]

dev/architecture/Большой комок грязи.md

@@ -0,0 +1,40 @@
+---
+aliases:
+  - Big ball of mud
+tags:
+  - maturity/🌱
+date: 2024-04-04
+---
+**Большой комок грязи** (Big Ball of Mud) — это термин, описывающий программную систему с нераспознаваемой архитектурой. Такие системы не имеют чёткой структуры, их сложно поддерживать и развивать.
+
+Ключевым последствием появления большой системы с неясной архитектурой является значительное замедление разработки. Это связано с тем, что:
+- **Сложность понимания кода**: Новые разработчики вынуждены тратить много времени на разбор устаревших и запутанных участков.
+- **Повышенная вероятность ошибок**: Внесение изменений в одну часть системы часто непредсказуемо влияет на другие.
+- **Снижение гибкости**: Система становится менее адаптируемой к новым требованиям бизнеса.
+
+В результате работа над новыми функциями или изменениями превращается в долгий и трудозатратный процесс.
+
+Одним из ярких примеров большого комка грязи является [[Распределенный монолит|распределённый монолит]]. Это система, которая внешне представлена как набор микросервисов, но на практике они сильно связаны между собой. Такая архитектура унаследовала все проблемы монолитных систем, добавив к ним сложности, связанные с распределёнными взаимодействиями.
+
+**Почему возникают большие комки грязи?**
+- **Давление сроков**: Когда бизнес требует быстрых результатов, разработчики часто жертвуют качеством архитектуры ради скорости.
+- **Отсутствие единого видения**: Если в команде нет согласованного подхода к архитектурным решениям, код становится хаотичным.
+- **Текучка кадров**: Новые разработчики могут не понимать оригинального замысла системы и добавлять решения, противоречащие существующей структуре.
+- **Рост системы**: По мере увеличения объёма кода его поддержка становится всё сложнее, особенно если архитектура изначально была слабой.
+
+**Как избежать появления большого комка грязи?**
+- **Создавать архитектурные стандарты**: Документировать основные принципы построения системы и регулярно их пересматривать.
+- [[../efficiency/Рефакторинг кода|Рефакторинг]] на ранних этапах: Регулярно пересматривать код и устранять хаотичные или устаревшие участки.
+- **Обучение команды**: Убедиться, что все разработчики понимают выбранный подход к проектированию.
+- **Разумное планирование сроков**: Учитывать время, необходимое для создания качественной архитектуры, вместо того чтобы ориентироваться только на скорость.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
+**Родитель**:: [[Архитектурная концепция]]
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2024-04-04]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

dev/architecture/Гранулярность микросервисов.md

@@ -8,7 +8,7 @@ date: 2024-11-24
 ---
 Гранулярность микросервисов — это один из ключевых вопросов при проектировании распределённых систем. От неё зависит многое: гибкость архитектуры, масштабируемость, время разработки и стоимость поддержки. Однако определение оптимального размера каждого сервиса — задача не из лёгких.
 
-Гранулярность в контексте микросервисной архитектуры — это уровень разделения логики системы на отдельные сервисы. Слишком крупные сервисы рискуют превратиться в монолиты, теряя преимущества микросервисного подхода. Слишком мелкие, наоборот, создают сложности в управлении и коммуникации, что приводит к росту накладных расходов.
+Гранулярность в контексте микросервисной архитектуры — это уровень разделения логики системы на отдельные сервисы. Слишком крупные сервисы рискуют превратиться в [[Монолитная архитектура|монолиты]], теряя преимущества микросервисного подхода. Слишком мелкие, наоборот, создают сложности в управлении и коммуникации, что приводит к росту накладных расходов.
 
 Основной вызов заключается в нахождении оптимального баланса. Микросервисы должны быть достаточно маленькими, чтобы можно было легко управлять их жизненным циклом и развивать независимо от других компонентов. В то же время они должны оставаться самодостаточными и функциональными.
 
@@ -31,12 +31,11 @@ date: 2024-11-24
 
 **Практические рекомендации**
 - **Начинайте с более крупных сервисов** и постепенно выделяйте их части, когда возникает потребность в независимом развитии и деплое. Это поможет избежать излишней сложности на начальных этапах.
-- **Автоматизируйте тестирование и деплой**. Большое количество микросервисов требует высокой степени автоматизации, чтобы поддерживать скорость разработки и гарантировать стабильность.
 - **Анализируйте связи между сервисами**. Регулярный анализ зависимостей и коммуникационных потоков поможет понять, не стали ли отдельные сервисы слишком тесно связаны и не следует ли их объединить.
 ***
 ## Мета информация
 **Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
-**Родитель**:: 
+**Родитель**:: [[Микросервис]]
 **Источник**:: 
 **Создана**:: [[2024-11-24]]
 **Автор**:: 

dev/architecture/Декомпозиция на микросервисы.md

@@ -0,0 +1,21 @@
+---
+aliases:
+  - декомпозиции сервисов
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+
+***
+## Мета информация
+**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+**Родитель**:: [[Микросервис]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Межсервисное взаимодействие.md

@@ -0,0 +1,24 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+Примитивные каналы, такие как [[брокер сообщений]], или прямое взаимодействие с помощью легковесных протоколов наподобие [[Representation State Transfer|REST]] или [[../gRPC|gRPC]].
+
+Чем больше вызовов нужно сделать, тем меньшую [[Reliability|отказоустойчивость]] получаем.
+
+![[../../../../meta/files/Pasted image 20241127200019.png]]
+***
+## Мета информация
+**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]]
+**Родитель**:: [[Микросервис]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Монолитная архитектура.md

@@ -0,0 +1,39 @@
+---
+aliases:
+  - монолит
+  - монолиты
+  - монолитного приложения
+tags:
+  - maturity/🌱
+date: 2024-04-04
+---
+Монолитная архитектура — это способ проектирования, разработки и деплоя [[../../../../_inbox/Информационная система|информационной системы]] как единого целого. Все компоненты приложения — от пользовательского интерфейса до базы данных — объединены в одном приложении. Такой подход остаётся популярным для многих проектов из-за его простоты на начальных этапах.
+
+Монолитный подход имеет ряд **преимуществ**, которые делают его привлекательным для небольших или средних проектов:
+- **Простота разработки**. Все инструменты разработки (например, IDE) сосредоточены на создании единого приложения. Это упрощает работу команды, особенно если проект небольшой и команда ограничена в ресурсах.
+- **Лёгкость внесения радикальных изменений**. В монолитной архитектуре вы можете одновременно менять код и структуру базы данных. После этого достаточно пересобрать и развернуть новое приложение.
+- **Простота тестирования**. Сквозное тестирование охватывает всю систему сразу. Инструменты, такие как Selenium, позволяют тестировать пользовательский интерфейс, API и внутреннюю логику в одном процессе.
+- **Упрощённое развертывание**. Разработчику достаточно скопировать один WAR-файл (или аналог) на сервер с установленным приложением, например Tomcat.
+- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за балансировщиком нагрузки, распределяя трафик между ними.
+
+Несмотря на простоту, монолитный подход имеет **ряд ограничений**, которые могут стать критическими при увеличении размера приложения или масштабировании бизнеса:
+
+- **Трудности с масштабированием**. Программные модули конкурируют за ресурсы. Например, модуль обработки изображений, нагружающий CPU, может негативно влиять на стабильность других модулей.
+- **Единые технологии для всех задач**. Монолит ограничивает возможность использовать разные технологии для разных частей системы. Например, вы не сможете использовать Java для одних модулей, а C++ — для других.
+- **Проблемы с надёжностью и стабильностью**. Утечка памяти в одном модуле может вызвать сбой всей системы, поскольку в монолите все компоненты тесно связаны.
+- **Проблемы масштабируемости и сложности управления**. Популярные приложения часто перерастают монолитную архитектуру. Это приводит к увеличению времени сборки, сложности управления и проблемам с разделением ответственности в команде. В конечном итоге проект может оказаться в состоянии так называемого “[[Монолитный ад|монолитного ада]]”.
+
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Архитектурная концепция]]
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2024-04-04]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+- [[Монолитный ад]]
+<!-- SerializedQuery END -->

dev/architecture/Монолитный ад.md

@@ -0,0 +1,45 @@
+---
+aliases:
+  - монолитном аду
+  - монолитного ада
+tags:
+  - maturity/🌱
+date:
+  - - 2024-04-04
+---
+**Монолитный ад** — это состояние [[Монолитная архитектура|монолитного приложения]], в котором его сложность и размеры становятся настолько большими, что разработка, поддержка и развитие системы превращаются в серьёзную проблему. Приложение становится практически непонятным для одного разработчика, а любая попытка изменить код или добавить новую функциональность усиливает хаос.
+
+**Основные симптомы монолитного ада**
+- **Медленная разработка**. Сборка кода занимает слишком много времени. Большое приложение долго запускается, что затягивает цикл разработки: написание, сборка, запуск, тестирование.
+- **Медленные и сложные релизы**. Разные команды работают над одной кодовой базой. Даже если монолит разбит на модули, выпуск релиза невозможен, пока все команды не завершат свои изменения. Это приводит к задержкам и конфликтам.
+- **Постепенное устаревание технологий**. Переход на новые фреймворки или инструменты в монолите становится практически невозможным. Нельзя точечно обновить технологии для одного модуля, например, использовать Spring для модуля оплаты и Quarkus для управления пользователями.
+
+![](../../meta/files/images/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png)
+
+**Причины возникновения монолитного ада**
+- **Рост команды и кодовой базы**. Чем больше разработчиков работает над проектом и чем больше кода добавляется, тем сложнее становится система. При этом сложность системы обычно растёт экспоненциально, что усугубляет ситуацию.
+- **Плохая архитектура и низкая читаемость кода**. Когда кодовая база плохо структурирована, разработчики не могут вносить изменения корректно. Это приводит к новым ошибкам и ещё большей путанице.
+- **Увеличение технического долга**. Непродуманные изменения ради краткосрочных целей делают код менее поддерживаемым, что в долгосрочной перспективе замедляет разработку.
+
+**Последствия монолитного ада**
+- [[Большой комок грязи]]. Проблемы монолита приводят к тому, что система превращается в плохо структурированный, запутанный код, который трудно понять и поддерживать.
+- **Снижение производительности команды**. Разработчики вынуждены тратить больше времени на понимание существующего кода, чем на реализацию новых функций.
+- **Повышенные риски отказов**. Ошибка или сбой в одной части системы может полностью нарушить её работу, так как все модули тесно связаны.
+- **Замедление внедрения инноваций**. Устаревший стек технологий и сложность внедрения изменений препятствуют использованию современных подходов, что снижает конкурентоспособность продукта.
+
+**Как избежать монолитного ада?**
+- Планомерный [[../efficiency/Рефакторинг кода|рефакторинг]]. Регулярное улучшение кода и упрощение архитектуры позволяют снизить сложность системы и избежать накопления технического долга.
+- Переход на [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисную архитектуру]]. Если приложение становится слишком сложным, можно начать выделять отдельные модули в микросервисы. Это разделяет ответственность и снижает связность системы.
+- [[../efficiency/Стандартизация подходов в разработке|Стандартизация подходов в разработке]]. Использование единых стандартов и инструментов помогает команде работать более эффективно и избежать хаоса.
+- **Контроль за качеством кода**. Внедрение строгих код-ревью, тестирования и анализа статического кода позволяет предотвращать появление проблем ещё на этапе разработки.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Монолитная архитектура]]
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2024-04-04]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->

dev/architecture/Распределенный монолит.md

@@ -1,27 +1,30 @@
 ---
-aliases: 
+aliases:
+  - распределённый монолит
 tags:
   - maturity/🌱
 date: 2024-11-24
 ---
 Распределенный монолит — это архитектурный [[Паттерн проектирования|паттерн]], в котором компоненты системы, хотя и развернуты в виде отдельных [[Микросервис|сервисов]], фактически зависят друг от друга настолько, что не могут развиваться и масштабироваться независимо.
 
-Внешне такая архитектура выглядит как микросервисная, но из-за сильной [[Связанность|связанности]] и отсутствия независимости деплоя она теряет все преимущества микросервисного подхода и в итоге становится даже более сложной и неудобной в поддержке, чем традиционный [[../../../../_inbox/Монолитная архитектура|монолит]].
+![[../../meta/files/images/Pasted image 20241127200905.png]]
 
-Признаки распределенного монолита:
+Внешне такая архитектура выглядит как микросервисная, но из-за сильной [[Связанность|связанности]] и отсутствия независимости деплоя она теряет все преимущества микросервисного подхода и в итоге становится даже более сложной и неудобной в поддержке, чем традиционный [[Монолитная архитектура|монолит]].
+
+**Признаки распределенного монолита:**
 - Высокая [[Связанность|связанность]] между сервисами, требующие координации при деплое. Из-за этого невозможно обновить или развернуть один сервис без изменения других
 - **Глобальные транзакции**, которые охватывают несколько сервисов, что приводит к сильной связанности и усложняет управление согласованностью данных
 - **Отсутствие автономности** сервисов. Если один сервис не может работать без другого, и их логика тесно переплетается, то, вероятно, вы имеете дело с распределенным монолитом.
-- **Общие схемы данных**. Использование общей базы данных или общей схемы между сервисами приводит к тесной связанности и усложняет внесение изменений без координации между командами.
+- **Общие схемы данных**. Использование [[Shared Database|общей базы данных]] или общей схемы между сервисами приводит к тесной связанности и усложняет внесение изменений без координации между командами.
 
-Причины появления распределенного монолита
+**Причины появления распределенного монолита**
 - **Недостаточное понимание микросервисных принципов**. При переходе от монолита к микросервисам важно пересмотреть подходы к разработке и взаимодействию между компонентами. Не все команды понимают, что микросервисы требуют не только разбиения на отдельные сервисы, но и пересмотра способов их взаимодействия и управления данными.
 - Излишняя [[Гранулярность микросервисов|гранулярность микросервисов]]. Желание сделать сервисы как можно более маленькими и специализированными иногда приводит к обратному результату — коммуникационные накладные расходы становятся слишком большими, и система превращается в распределенный монолит с большим количеством зависимостей.
 - **Общие ресурсы**. Использование общих баз данных ([[Shared Database|Shared Database]]) или сервисов, которые нельзя изменить независимо, приводит к тому, что сервисы не могут быть развернуты или изменены самостоятельно. 
 - **Плохой дизайн API**. Сервисные интерфейсы, которые создают жесткие зависимости и требуют координации между разными сервисами, также способствуют появлению распределенного монолита.
 
 Как избежать создания распределенного монолита
-- **Слабая связанность и независимость деплоя**. Стремитесь к тому, чтобы сервисы были как можно более независимыми друг от друга. Это касается не только разработки, но и данных. Каждому микросервису должна принадлежать своя база данных ([[Database per service|Database per service]]), чтобы минимизировать зависимость от других сервисов.
+- Слабая [[связанность]] и независимость деплоя. Стремитесь к тому, чтобы сервисы были как можно более независимыми друг от друга. Это касается не только разработки, но и данных. Каждому микросервису должна принадлежать [[Database per service|своя база данных]], чтобы минимизировать зависимость от других сервисов.
 - **Декомпозиция по бизнес-доменам**. Разделение системы на сервисы должно основываться на бизнес-логике и [[Доменная область|доменных областях]]. Сервисы должны быть построены вокруг конкретных бизнес-процессов, а не технических компонентов, что поможет избежать тесной связанности.
 - [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированное программирование]]. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность.
 - **Асинхронные коммуникации**. Использование асинхронных методов взаимодействия, таких как [[Брокер сообщений|очереди сообщений]], снижает связанность между сервисами и позволяет им работать независимо друг от друга.

dev/efficiency/You Aren’t Gonna Need It.md

@@ -0,0 +1,26 @@
+---
+aliases:
+  - YAGNI
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+YAGNI (You Aren’t Gonna Need It) — это принцип разработки, который гласит: “Не реализовывайте функционал или код в надежде, что он может понадобиться в будущем.”
+
+**Почему это важно?**
+- **Код становится проще**. Самый простой код — это отсутствие кода. Любая строчка, которая добавляется, должна быть действительно необходимой.
+- **Избегание чрезмерной инженерии**. Overengineering (чрезмерное проектирование) — это создание сложных решений, которые оказываются избыточными для текущих задач. Пример: разработка универсального механизма вместо простого рабочего решения.
+- **Фокус на MVP**. Работайте над минимально жизнеспособным продуктом (MVP), реализуя только критически важный функционал. Лишние детали можно добавить позже, если они действительно потребуются.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Эффективная разработка|00 Эффективная разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/java/JDK для Apple Silicon.md

@@ -11,7 +11,7 @@ linked:
 ---
 Когда-то давным давно скачал [JDK](JDK.md), работает и ладно. Посмотрел доклад про [нативные сборки](Нативные%20сборки%20в%20Java.md), и там упоминалось про [JDK](JDK.md) для Apple Silicon. Решил проверить, а такой ли у меня. Оказалось не такой.
 
-В итоге вот сколько собирался большой [монолит](../../../../_inbox/Монолитная%20архитектура.md) (с генерацией javadoc), состоящий из 22 модуля на обычной [JDK](JDK.md). Все зависимости были закачены заранее и сборка была запущена в [многопоточном режиме](Параллельная%20сборка%20модулей%20в%20Maven.md).
+В итоге вот сколько собирался большой [монолит](../architecture/Монолитная%20архитектура.md) (с генерацией javadoc), состоящий из 22 модуля на обычной [JDK](JDK.md). Все зависимости были закачены заранее и сборка была запущена в [многопоточном режиме](Параллельная%20сборка%20модулей%20в%20Maven.md).
 
 ![](../../meta/files/images/Pasted%20image%2020240908115826.png)
 

dev/linux/Контейнерная виртуализация.md

@@ -1,6 +1,7 @@
 ---
 aliases:
   - контейнерах
+  - Контейнеризация
 tags:
   - maturity/🌱
 date: 2024-03-20

dev/network/HTTP 1.md

@@ -0,0 +1,48 @@
+---
+aliases:
+  - HTTP 1.1
+  - HTTP 1.0
+  - HTTP/1.1
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+С развитием интернета протокол [[HyperText Transfer Protocol|HTTP]] прошёл значительные изменения. Первой полноценной версией стал **HTTP/1.0**, завершённый в 1996 году. 
+
+Однако его ключевая особенность — необходимость устанавливать отдельное [[../../../../knowledge/dev/network/TCP|TCP]]-соединение для каждого запроса — привела к существенным проблемам. ==Каждый новый запрос требовал затратного трёхфазного рукопожатия, что значительно увеличивало задержки и создавало дополнительную нагрузку на серверы==. Это особенно сказывалось на страницах, содержащих множество ресурсов, таких как изображения и скрипты.
+
+Ответом на эти ограничения стал **HTTP/1.1**, опубликованный уже в 1997 году. Он внедрил концепцию постоянных соединений: ==теперь одно [[../../../../knowledge/dev/network/TCP|TCP]]-соединение можно было оставить открытым и использовать повторно для нескольких запросов==. Это улучшение позволило сократить задержки и снизить нагрузку на серверы, так как устранить необходимость постоянного открытия новых соединений.
+
+![[../../meta/files/images/Pasted image 20241127084201.png]]
+
+Важной чертой HTTP/1.1 стал обязательный заголовок Host. Он позволяет одному серверу обслуживать сразу несколько доменов, что сделало возможным использование виртуального хостинга.
+
+Кроме того, HTTP/1.1 добавил поддержку частичных запросов, что стало полезным для докачки файлов или загрузки больших ресурсов по частям с помощью заголовка Range.
+
+Несмотря на эти улучшения, HTTP/1.1 не смог решить проблему блокировки первой строки (Head-of-Line, HOL). Эта ситуация возникает, когда ограничение на количество одновременных запросов исчерпывается, и последующие запросы вынуждены ждать завершения предыдущих. В результате сайты с большим количеством ресурсов всё ещё загружаются медленно, даже при использовании постоянных соединений.
+
+Структурно HTTP/1.1 сохранил идентификацию ресурсов через [[Uniform Resource Identifier|URI]], а также обязательные стартовую строку и заголовки. В запросе стартовая строка определяет метод (например, GET или POST) и [[Uniform Resource Identifier|URI]] ресурса, а заголовки предоставляют дополнительную информацию о запросе, такой как тип передаваемого контента или параметры кеширования.
+
+Пример стандартного запроса HTTP/1.1 выглядит следующим образом:
+
+```http
+GET /about.html HTTP/1.1
+Host: example.com
+Connection: keep-alive
+User-Agent: Mozilla/5.0
+Accept: text/html
+```
+
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: [[HyperText Transfer Protocol|HyperText Transfer Protocol]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/network/HTTP 2.md

@@ -0,0 +1,47 @@
+---
+aliases:
+  - HTTP/2
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+В 2015 году был представлен **HTTP/2**, который стал значительным шагом в развитии протокола. Его главной целью было устранение недостатков HTTP/1.1, в том числе проблемы блокировки первой строки (Head-of-Line, HOL) на уровне приложения. Это удалось достичь благодаря внедрению мультиплексирования, что позволило передавать несколько запросов одновременно через одно [[../../../../knowledge/dev/network/TCP|TCP]]-соединение, минимизируя задержки и увеличивая производительность. Однако HOL-блокировка на транспортном уровне (TCP) всё ещё осталась нерешённой.
+
+![[../../meta/files/images/Pasted image 20241127183453.png]]
+
+Одним из важнейших изменений стало то, что HTTP/2 перешёл с текстового на бинарный формат. Это нововведение улучшило обработку запросов и ответов, упростив разбиение данных на более мелкие фрагменты, которые называются кадрами (frames). Кроме того, появилась возможность сжимать заголовки с помощью алгоритма HPACK, что снизило объём данных, передаваемых по сети, и ускорило загрузку страниц.
+
+Одной из ключевых концепций HTTP/2 стал механизм потоков (streams). Это абстракция, позволяющая мультиплексировать несколько HTTP-запросов и ответов в рамках одного TCP-соединения. Потоки работают независимо друг от друга, что предотвращает блокировку одних запросов другими, даже если они выполняются одновременно.
+
+Каждое соединение в HTTP/2 содержит несколько потоков. Потоки, в свою очередь, состоят из сообщений формата “запрос-ответ”, которые делятся на кадры. Эти кадры передаются между сервером и клиентом, а специальные теги помогают идентифицировать их и собирать в правильной последовательности.
+
+![[../../meta/files/images/Pasted image 20241127183553.png]]
+
+HTTP/2 предоставляет возможность приоритизировать потоки. Приоритизация позволяет разработчикам назначать запросам относительный вес, чтобы более важные запросы обрабатывались первыми. Например, это может быть полезно при загрузке веб-страницы, где основные элементы, такие как HTML и CSS, должны обрабатываться быстрее, чем изображения или дополнительные скрипты.
+
+**Преимущества HTTP/2**
+- **Мультиплексирование**: Одновременная передача нескольких запросов через одно соединение без блокировок.
+- **Сжатие заголовков**: Уменьшение объёма передаваемых данных благодаря алгоритму HPACK.
+- **Бинарный формат**: Более эффективная передача и обработка данных.
+- **Приоритизация**: Возможность распределять ресурсы в зависимости от важности запросов.
+
+![[../../meta/files/images/Pasted image 20241127184802.png]]
+
+**Как работает HTTP/2:**
+- Устанавливается одно TCP-соединение между сервером и клиентом.
+- В рамках соединения создаются потоки, каждый из которых обрабатывает отдельный запрос.
+- Сообщения в потоке разбиваются на кадры, чтобы их можно было передавать параллельно.
+- На принимающей стороне кадры собираются обратно в исходное сообщение благодаря меткам, уникальным для каждого кадра.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: [[HyperText Transfer Protocol|HyperText Transfer Protocol]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/network/HTTP 3.md

@@ -0,0 +1,27 @@
+---
+aliases:
+  - HTTP/3
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+**HTTP/3** был впервые представлен в 2020 году в виде черновика как преемник [[HTTP 2|HTTP/2]]. Его основная цель — устранить оставшиеся ограничения, связанные с использованием [[../../../../knowledge/dev/network/TCP|TCP]], и повысить производительность и надёжность передачи данных в современных сетях. Главным отличием HTTP/3 является переход на транспортный протокол [[Quick UDP Internet Connections|QUIC]], который решает проблему блокировки первой строки (Head-of-Line, HOL) на уровне транспорта.
+
+Использование QUIC в HTTP/3 даёт ряд ощутимых преимуществ по сравнению с предыдущими версиями протокола:
+- **Устранение HOL-блокировки**: Благодаря независимости потоков, HTTP/3 решает проблему, сохранявшуюся в HTTP/2 на уровне TCP.
+- **Ускорение передачи данных**: За счёт минимизации времени на установку соединений и устранения необходимости в повторном рукопожатии.
+- **Повышение устойчивости к сетевым потерям**: Пакетная потеря в одном потоке не останавливает другие потоки, что особенно важно в нестабильных сетях.
+- **Шифрование по умолчанию**: QUIC включает встроенную поддержку TLS 1.3, что делает соединения более безопасными без дополнительных затрат на настройку.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: [[HyperText Transfer Protocol]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/network/HTTP over SSL or TLS.md

@@ -0,0 +1,37 @@
+---
+aliases:
+  - HTTP over SSL/TLS
+  - HTTPS
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+Для обеспечения безопасности данных используется HTTPS (HTTP over SSL/TLS). Это расширение HTTP, которое добавляет шифрование данных, чтобы защитить их от перехвата.
+
+![[photo_2024-10-29 18.27.09.jpeg]]
+
+![[Pasted image 20241103035804.png]]
+**Как происходит шифрование и дешифрование данных**
+- **Шаг 1** — Клиент (браузер) и сервер устанавливают [[../../../../../knowledge/dev/network/TCP|TCP]]-соединение.
+- **Шаг 2** — Клиент отправляет серверу сообщение «client hello». Это сообщение содержит набор поддерживаемых алгоритмов шифрования (наборов шифров) и последнюю версию TLS, которую клиент может поддерживать. Сервер отвечает сообщением «server hello», чтобы сообщить клиенту, какие алгоритмы и версия TLS поддерживаются.
+- Затем сервер отправляет клиенту SSL-сертификат, который содержит публичный ключ, имя хоста, срок действия сертификата и другую информацию. Клиент проверяет подлинность сертификата.
+- **Шаг 3** — После успешной проверки SSL-сертификата клиент генерирует сеансовый ключ и шифрует его с помощью публичного ключа. Сервер получает зашифрованный сеансовый ключ и дешифрует его с использованием своего приватного ключа.
+- **Шаг 4** — Теперь, когда и клиент, и сервер обладают одним и тем же сеансовым ключом (симметричное шифрование), данные передаются в зашифрованном виде по защищённому двустороннему каналу.
+
+**Почему HTTPS переключается на симметричное шифрование для передачи данных?**
+1. **Безопасность**: Асимметричное шифрование работает только в одну сторону. Это означает, что если сервер попытается отправить зашифрованные данные обратно клиенту, любой сможет расшифровать их, используя публичный ключ.
+2. **Ресурсы сервера**: Асимметричное шифрование требует значительных вычислительных ресурсов из-за сложных математических операций. Это делает его непригодным для передачи данных в долгих сессиях.
+
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: [[HyperText Transfer Protocol|HyperText Transfer Protocol]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/network/HyperText Transfer Protocol.md

@@ -5,84 +5,85 @@ tags:
   - maturity/🌱
 date: 2024-10-29
 ---
-НТТР (англ. Hyper Text Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных. Изначально - в виде гипертекстовых документов в формате «HTML», в настоящий момент используется для передачи произвольных данных.
+HTTP (англ. HyperText Transfer Protocol) — протокол передачи гипертекста, функционирующий на прикладном уровне. Первоначально создан для передачи HTML-документов, теперь используется для работы с произвольными типами данных, такими как изображения, JSON, видео и другие.
 
-HTTP сообщения состоят из трех частей, которые передаются в указанном порядке:
-- Стартовая строка - определяет тип сообщения
-- HTTP-заголовки - характеризуют тело сообщения, параметры передачи и прочие сведения
-- Пустая строка для отделения данных от заголовков.
-- Тело сообщения - данные.
+HTTP-сообщения состоят из следующих элементов:
+- **Стартовая строка** — определяет тип сообщения:
+	- Для запросов включает метод (например, GET) и URL.
+	- Для ответов включает код состояния (например, 200 OK).
+- **HTTP-заголовки** — строки вида параметр: значение, которые описывают сообщение:
+	- Например, Content-Type: application/json определяет формат тела сообщения.
+- **Пустая строка** — разделяет заголовки и тело сообщения.
+- **Тело сообщения** — содержит данные, передаваемые между клиентом и сервером. Например, в запросе POST тело может содержать JSON с информацией для сервера.
+
+**Простая структура HTTP-запроса:**
+```HTTP
+GET /api/resource HTTP/1.1
+Host: example.com
+Authorization: Bearer my-token
+```
+
+**Ответ сервера:**
+```HTTP
+HTTP/1.1 200 OK
+Content-Type: application/json
+Content-Length: 123
+
+{
+  "message": "Success",
+  "data": []
+}
+```
 
 - [[Cookie|Cookie]]
-## Http методы
-- GET - получить содержимое указанного ресурса
-- HEAD - получить только заголовки
-- POST - отправить данные на создание
-- PUT - отправить данные на обновление
-- DELETE - удалить указанный ресурс
-- OPTIONS - определить параметры сервера
-## HTTP заголовки
-Заголовки - строки в HTTP сообщении, содержащие разделенную двоеточием пару параметр-значение.
+- [[HTTP over SSL or TLS|HTTP over SSL/TLS]]
+
+![[../../meta/files/images/Pasted image 20241103014445.png]]
+
+**Версии HTTP**
+- [[HTTP 1|HTTP/1.1]]:
+	- Широко распространен.
+	- Поддержка постоянных соединений (keep-alive)
+- [[HTTP 2|HTTP/2]]:
+	- Использует бинарный формат (вместо текстового).
+	- Поддержка мультиплексирования (одновременная отправка нескольких запросов в одном соединении).
+- [[HTTP 3|HTTP/3]]:
+	- Основан на протоколе QUIC (работает поверх [[../../../../knowledge/dev/network/UDP|UDP]]).
+	- Улучшенная скорость соединений.
+## Http методы
+Методы HTTP определяют действия, которые клиент хочет выполнить на сервере:
+- **GET**: Получение данных с сервера.
+- **HEAD**: Запрос только заголовков ресурса, без тела.
+- **POST**: Отправка данных на сервер для создания ресурса.
+- **PUT**: Обновление или замена существующего ресурса.
+- **DELETE**: Удаление ресурса.
+- **OPTIONS**: Запрос информации о поддерживаемых сервером методах.
+
+Дополнительно есть методы, такие как PATCH (частичное обновление) и TRACE (трассировка маршрута сообщения).
+## HTTP заголовки
+Заголовки в HTTP структурируют метаинформацию сообщения. Пример заголовков:
 
-Пример заголовков:
 ```http
-Server: nginx/1.16.1
-Date: Tue, 10 Dec 2019 16:32:07 GMT
-Content-Type: image/jpeg
-Content-Length: 33519
-Last-Modified: Mon, 19 Feb 2018 04:59:24 GMT
-Connection: keep-alive ETag: "1a7a93ac-34ef"
-Access-Control-Allow-Origin: *
-Access-Control-Allow-Methods: * 
-Access-Control-Allow-Headers: *
-Access-Control-Max-Age: 86400
-Accept-Ranges: bytes
+Content-Type: application/json
+Authorization: Bearer token
+Cache-Control: no-cache
 ```
 
 Заголовки подразделяются на четыре основные группы:
-- General Headers - могут включаться в любое сообщение клиента и сервера
-- Request Headers - используются только в запросах клиента
-- Response Headers - используются только для ответов от сервера
-- Entity Headers - сопровождают каждую сущность сообщения
+- **General Headers** — общие для запросов и ответов:
+	- Cache-Control: управление кешированием.
+	- Date: время отправки сообщения.
+- **Request Headers** — используются только в запросах:
+	- Accept: указывает желаемый формат ответа.
+	- Authorization: передача токена аутентификации.
+- **Response Headers** — характерны для ответов сервера:
+	- Server: информация о сервере.
+	- Set-Cookie: установка cookies.
+- **Entity Headers** — сопровождают тело сообщения:
+	- Content-Type: тип содержимого.
+	- Content-Length: размер тела в байтах.
 
-Можно добавлять свои кастомные заголовки. Традиционно кастомные заголовки начинаются с префикса `X-`, чтобы избежать конфликта имен с существующими.
-## История развития HTTP
-![[../../meta/files/images/Pasted image 20241103014445.png]]
-
-**HTTP 1.0** был завершён и полностью задокументирован в 1996 году. Для каждого запроса к одному и тому же серверу требуется отдельное [[../../../../knowledge/dev/network/TCP|TCP]]-соединение.
-
-**HTTP 1.1** был опубликован в 1997 году. [[../../../../knowledge/dev/network/TCP|TCP]]-соединение теперь можно оставить открытым для повторного использования (постоянное соединение), но проблема блокировки первой строки (Head-of-Line, HOL) не решена.
-
-> [!NOTE] Head-of-Line, HOL
->  Ситуация, когда лимит параллельных запросов в браузере исчерпан, и последующие запросы вынуждены ждать завершения предыдущих.
-
-![[../../meta/files/images/Pasted image 20241127084201.png]]
-
-- Для идентификации ресурсов использует [[Uniform Resource Identifier|URI]].
-- Стартовая строка и заголовок являются обязательными
-- Обязательно содержится заголовок Host
-
-**HTTP 2.0** был опубликован в 2015 году. Он решает проблему HOL на уровне приложения благодаря мультиплексированию запросов, устраняя блокировку HOL на этом уровне. Однако проблема остаётся на транспортном уровне ([[../../../../knowledge/dev/network/TCP|TCP]]).
-
-Как показано на диаграмме, HTTP 2.0 ввёл концепцию HTTP “streams”: это абстракция, которая позволяет мультиплексировать различные HTTP-запросы в рамках одного [[../../../../knowledge/dev/network/TCP|TCP]]-соединения. Каждый поток может передаваться независимо от остальных.
-
-**HTTP 3.0** впервые был опубликован в виде черновика в 2020 году. Он предложен как преемник HTTP 2.0. Вместо [[../../../../knowledge/dev/network/TCP|TCP]] для транспортного уровня используется протокол QUIC, что устраняет блокировку HOL на уровне транспорта.
-
-**QUIC** основан на протоколе **UDP**. Он вводит потоки как полноценные сущности на уровне транспорта. Потоки QUIC используют одно и то же соединение QUIC, поэтому для создания новых потоков не требуется дополнительных рукопожатий и медленного старта. При этом потоки QUIC доставляются независимо друг от друга, что означает, что в большинстве случаев потеря пакетов, влияющая на один поток, не затрагивает остальные.
-## HTTPS
-![[../../meta/files/images/photo_2024-10-29 18.27.09.jpeg]]
-
-![[../../meta/files/images/Pasted image 20241103035804.png]]
-**Как происходит шифрование и дешифрование данных**
-- **Шаг 1** — Клиент (браузер) и сервер устанавливают [[../../../../knowledge/dev/network/TCP|TCP]]-соединение.
-- **Шаг 2** — Клиент отправляет серверу сообщение «client hello». Это сообщение содержит набор поддерживаемых алгоритмов шифрования (наборов шифров) и последнюю версию TLS, которую клиент может поддерживать. Сервер отвечает сообщением «server hello», чтобы сообщить клиенту, какие алгоритмы и версия TLS поддерживаются.
-- Затем сервер отправляет клиенту SSL-сертификат, который содержит публичный ключ, имя хоста, срок действия сертификата и другую информацию. Клиент проверяет подлинность сертификата.
-- **Шаг 3** — После успешной проверки SSL-сертификата клиент генерирует сеансовый ключ и шифрует его с помощью публичного ключа. Сервер получает зашифрованный сеансовый ключ и дешифрует его с использованием своего приватного ключа.
-- **Шаг 4** — Теперь, когда и клиент, и сервер обладают одним и тем же сеансовым ключом (симметричное шифрование), данные передаются в зашифрованном виде по защищённому двустороннему каналу.
-
-**Почему HTTPS переключается на симметричное шифрование для передачи данных?**
-1. **Безопасность**: Асимметричное шифрование работает только в одну сторону. Это означает, что если сервер попытается отправить зашифрованные данные обратно клиенту, любой сможет расшифровать их, используя публичный ключ.
-2. **Ресурсы сервера**: Асимметричное шифрование требует значительных вычислительных ресурсов из-за сложных математических операций. Это делает его непригодным для передачи данных в долгих сессиях.
+Разработчики могут создавать собственные заголовки. Префикс `X-` традиционно указывает, что заголовок нестандартный.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Сети|00 Сети]]
@@ -97,5 +98,11 @@ Accept-Ranges: bytes
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 - [[Cookie]]
+- [[Chunked transfer encoding]]
+- [[Условный GET запрос]]
+- [[HTTP 2]]
+- [[HTTP 1]]
+- [[HTTP 3]]
+- [[HTTP over SSL or TLS]]
 <!-- SerializedQuery END -->
 

dev/network/Quick UDP Internet Connections.md

@@ -0,0 +1,26 @@
+---
+aliases:
+  - QUIC
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+**QUIC** (Quick UDP Internet Connections) — это транспортный протокол, построенный поверх [[../../../../knowledge/dev/network/UDP|UDP]]. В отличие от [[../../../../knowledge/dev/network/TCP|TCP]], он изначально разрабатывался с учётом современных потребностей интернета, таких как минимизация задержек, повышение надёжности и поддержка безопасного соединения по умолчанию (встроенное шифрование).
+
+Ключевым нововведением QUIC стало введение потоков как самостоятельных сущностей на уровне транспорта. Эти потоки обеспечивают:
+1. **Быстрое открытие соединений**: Для новых потоков не требуется дополнительных рукопожатий, что устраняет задержки при их создании.
+2. **Независимость потоков**: Потери пакетов в одном потоке не влияют на другие, что делает передачу данных более стабильной.
+3. **Единое соединение**: Все потоки используют одно соединение QUIC, снижая накладные расходы на создание и поддержание нескольких соединений.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

meta/files/images/comp/Pasted image 20241127183453.png.md5

@@ -0,0 +1 @@
+0fa259b2c5e5423ca919b55f4b2db19a

meta/files/images/comp/Pasted image 20241127183553.png.md5

@@ -0,0 +1 @@
+856b67234f0c093c95fdff30e7df17f2

meta/files/images/comp/Pasted image 20241127184802.png.md5

@@ -0,0 +1 @@
+b42c40507c4e1dc957bf2da94e08080f

meta/files/images/comp/Pasted image 20241127200905.png.md5

@@ -0,0 +1 @@
+a73518e97304f3df38cebc45419f52a0

meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png.md5

@@ -0,0 +1 @@
+8dd5cf65a8163d7d6d22c487b6aaa466

meta/files/images/webp/Pasted image 20241127183453.webp.md5

@@ -0,0 +1 @@
+0fa259b2c5e5423ca919b55f4b2db19a

meta/files/images/webp/Pasted image 20241127183553.webp.md5

@@ -0,0 +1 @@
+856b67234f0c093c95fdff30e7df17f2

meta/files/images/webp/Pasted image 20241127184802.webp.md5

@@ -0,0 +1 @@
+b42c40507c4e1dc957bf2da94e08080f

meta/files/images/webp/Pasted image 20241127200905.webp.md5

@@ -0,0 +1 @@
+a73518e97304f3df38cebc45419f52a0

meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp.md5

@@ -0,0 +1 @@
+8dd5cf65a8163d7d6d22c487b6aaa466

meta/zero/00 Архитектура ИС.md

@@ -14,7 +14,7 @@ aliases:
 
 - [[../../dev/architecture/CAP теорема|CAP теорема]]
 - [Трёхзвенная структура](../../dev/architecture/Трёхзвенная%20структура.md)
-- [Монолитная архитектура](Монолитная%20архитектура.md)
+- [Монолитная архитектура](../../dev/architecture/Монолитная%20архитектура.md)
 - [00 Микросервисная архитектура](../../../../wiki/zero/00%20Микросервисная%20архитектура.md)
 - [Service Oreinted Architecture](Service%20Oreinted%20Architecture.md)
 - [[00 HighLoad|HighLoad]]