diff --git a/dev/architecture/Database per service.md b/dev/architecture/Database per service.md index 37e965f9..c523fa0e 100644 --- a/dev/architecture/Database per service.md +++ b/dev/architecture/Database per service.md @@ -1,6 +1,7 @@ --- aliases: - separate data store + - своя база данных tags: - maturity/🌱 date: 2024-11-24 diff --git a/dev/architecture/Shared Database.md b/dev/architecture/Shared Database.md index 0ca1c198..6da16cca 100644 --- a/dev/architecture/Shared Database.md +++ b/dev/architecture/Shared Database.md @@ -1,5 +1,6 @@ --- -aliases: +aliases: + - общей базы данных tags: - maturity/🌱 date: 2024-11-24 diff --git a/dev/architecture/Архитектурная концепция.md b/dev/architecture/Архитектурная концепция.md index 9f27747e..8f3caec6 100644 --- a/dev/architecture/Архитектурная концепция.md +++ b/dev/architecture/Архитектурная концепция.md @@ -12,12 +12,14 @@ date: 2024-10-01 ## Классификация На уровне системы: -- [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]] +- [[../../../../wiki/zero/00 Микросервисная архитектура|Микросервисная архитектура]] +- [[Монолитная архитектура]] - [[../../../../_inbox/Событийно-ориентированное программирование|Событийно-ориентированное программирование]] - [[Асинхронное программирование]] - [[Реактивное программирование|Реактивное программирование]] На уровне компонентов системы: +- [[Паттерн проектирования]] - [[Inversion of Control]] - [[Один клиент — один поток]] - [[Много клиентов — один поток]] diff --git a/dev/architecture/Большой комок грязи.md b/dev/architecture/Большой комок грязи.md new file mode 100644 index 00000000..4995594a --- /dev/null +++ b/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]] +### Дополнительные материалы +- +### Дочерние заметки + diff --git a/dev/architecture/Гранулярность микросервисов.md b/dev/architecture/Гранулярность микросервисов.md index 8b89433d..768a137d 100644 --- a/dev/architecture/Гранулярность микросервисов.md +++ b/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]] **Автор**:: diff --git a/dev/architecture/Декомпозиция на микросервисы.md b/dev/architecture/Декомпозиция на микросервисы.md new file mode 100644 index 00000000..8dbb0a90 --- /dev/null +++ b/dev/architecture/Декомпозиция на микросервисы.md @@ -0,0 +1,21 @@ +--- +aliases: + - декомпозиции сервисов +tags: + - maturity/🌱 +date: 2024-11-27 +--- + +*** +## Мета информация +**Область**:: [[../../../../wiki/zero/00 Микросервисная архитектура|00 Микросервисная архитектура]] +**Родитель**:: [[Микросервис]] +**Источник**:: +**Создана**:: [[2024-11-27]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Межсервисное взаимодействие.md b/dev/architecture/Межсервисное взаимодействие.md new file mode 100644 index 00000000..a2741dd0 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Монолитная архитектура.md b/dev/architecture/Монолитная архитектура.md new file mode 100644 index 00000000..1fcc15a4 --- /dev/null +++ b/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]] +### Дополнительные материалы +- +### Дочерние заметки + + +- [[Монолитный ад]] + diff --git a/dev/architecture/Монолитный ад.md b/dev/architecture/Монолитный ад.md new file mode 100644 index 00000000..046152fb --- /dev/null +++ b/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]] +### Дополнительные материалы +- +### Дочерние заметки + diff --git a/dev/architecture/Распределенный монолит.md b/dev/architecture/Распределенный монолит.md index d3734409..47883776 100644 --- a/dev/architecture/Распределенный монолит.md +++ b/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/Событийно-ориентированное программирование|Событийно-ориентированное программирование]]. Использование событийной модели взаимодействия позволяет уменьшить тесную связанность сервисов и избавиться от необходимости прямого взаимодействия между ними. Сервисы реагируют на события, а не вызывают друг друга напрямую, что повышает автономность. - **Асинхронные коммуникации**. Использование асинхронных методов взаимодействия, таких как [[Брокер сообщений|очереди сообщений]], снижает связанность между сервисами и позволяет им работать независимо друг от друга. diff --git a/dev/efficiency/You Aren’t Gonna Need It.md b/dev/efficiency/You Aren’t Gonna Need It.md new file mode 100644 index 00000000..f60555f5 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/java/JDK для Apple Silicon.md b/dev/java/JDK для Apple Silicon.md index 67d9df85..3df234a9 100644 --- a/dev/java/JDK для Apple Silicon.md +++ b/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) diff --git a/dev/linux/Контейнерная виртуализация.md b/dev/linux/Контейнерная виртуализация.md index 84ccf343..a3babac6 100644 --- a/dev/linux/Контейнерная виртуализация.md +++ b/dev/linux/Контейнерная виртуализация.md @@ -1,6 +1,7 @@ --- aliases: - контейнерах + - Контейнеризация tags: - maturity/🌱 date: 2024-03-20 diff --git a/dev/network/HTTP 1.md b/dev/network/HTTP 1.md new file mode 100644 index 00000000..a5f0f165 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/network/HTTP 2.md b/dev/network/HTTP 2.md new file mode 100644 index 00000000..47acfb71 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/network/HTTP 3.md b/dev/network/HTTP 3.md new file mode 100644 index 00000000..470e1f51 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/network/HTTP over SSL or TLS.md b/dev/network/HTTP over SSL or TLS.md new file mode 100644 index 00000000..3379a502 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/network/HyperText Transfer Protocol.md b/dev/network/HyperText Transfer Protocol.md index aeac3a23..8e2ecea0 100644 --- a/dev/network/HyperText Transfer Protocol.md +++ b/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 - [[Cookie]] +- [[Chunked transfer encoding]] +- [[Условный GET запрос]] +- [[HTTP 2]] +- [[HTTP 1]] +- [[HTTP 3]] +- [[HTTP over SSL or TLS]] diff --git a/dev/network/Quick UDP Internet Connections.md b/dev/network/Quick UDP Internet Connections.md new file mode 100644 index 00000000..cef3bb49 --- /dev/null +++ b/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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/meta/files/images/Pasted image 20241127183453.png b/meta/files/images/Pasted image 20241127183453.png new file mode 100644 index 00000000..5949b4c9 Binary files /dev/null and b/meta/files/images/Pasted image 20241127183453.png differ diff --git a/meta/files/images/Pasted image 20241127183553.png b/meta/files/images/Pasted image 20241127183553.png new file mode 100644 index 00000000..2e2db662 Binary files /dev/null and b/meta/files/images/Pasted image 20241127183553.png differ diff --git a/meta/files/images/Pasted image 20241127184802.png b/meta/files/images/Pasted image 20241127184802.png new file mode 100644 index 00000000..3783b210 Binary files /dev/null and b/meta/files/images/Pasted image 20241127184802.png differ diff --git a/meta/files/images/Pasted image 20241127200905.png b/meta/files/images/Pasted image 20241127200905.png new file mode 100644 index 00000000..44620cb1 Binary files /dev/null and b/meta/files/images/Pasted image 20241127200905.png differ diff --git a/meta/files/images/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png b/meta/files/images/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png new file mode 100644 index 00000000..84ad2a4d Binary files /dev/null and b/meta/files/images/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png differ diff --git a/meta/files/images/comp/Pasted image 20241127183453.png b/meta/files/images/comp/Pasted image 20241127183453.png new file mode 100644 index 00000000..ea05ac66 Binary files /dev/null and b/meta/files/images/comp/Pasted image 20241127183453.png differ diff --git a/meta/files/images/comp/Pasted image 20241127183453.png.md5 b/meta/files/images/comp/Pasted image 20241127183453.png.md5 new file mode 100644 index 00000000..61141aad --- /dev/null +++ b/meta/files/images/comp/Pasted image 20241127183453.png.md5 @@ -0,0 +1 @@ +0fa259b2c5e5423ca919b55f4b2db19a diff --git a/meta/files/images/comp/Pasted image 20241127183553.png b/meta/files/images/comp/Pasted image 20241127183553.png new file mode 100644 index 00000000..ae1239ef Binary files /dev/null and b/meta/files/images/comp/Pasted image 20241127183553.png differ diff --git a/meta/files/images/comp/Pasted image 20241127183553.png.md5 b/meta/files/images/comp/Pasted image 20241127183553.png.md5 new file mode 100644 index 00000000..5c7a2f7b --- /dev/null +++ b/meta/files/images/comp/Pasted image 20241127183553.png.md5 @@ -0,0 +1 @@ +856b67234f0c093c95fdff30e7df17f2 diff --git a/meta/files/images/comp/Pasted image 20241127184802.png b/meta/files/images/comp/Pasted image 20241127184802.png new file mode 100644 index 00000000..372fcbf6 Binary files /dev/null and b/meta/files/images/comp/Pasted image 20241127184802.png differ diff --git a/meta/files/images/comp/Pasted image 20241127184802.png.md5 b/meta/files/images/comp/Pasted image 20241127184802.png.md5 new file mode 100644 index 00000000..7a59f62e --- /dev/null +++ b/meta/files/images/comp/Pasted image 20241127184802.png.md5 @@ -0,0 +1 @@ +b42c40507c4e1dc957bf2da94e08080f diff --git a/meta/files/images/comp/Pasted image 20241127200905.png b/meta/files/images/comp/Pasted image 20241127200905.png new file mode 100644 index 00000000..258d6318 Binary files /dev/null and b/meta/files/images/comp/Pasted image 20241127200905.png differ diff --git a/meta/files/images/comp/Pasted image 20241127200905.png.md5 b/meta/files/images/comp/Pasted image 20241127200905.png.md5 new file mode 100644 index 00000000..9ab56a7d --- /dev/null +++ b/meta/files/images/comp/Pasted image 20241127200905.png.md5 @@ -0,0 +1 @@ +a73518e97304f3df38cebc45419f52a0 diff --git a/meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png b/meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png new file mode 100644 index 00000000..a4cba845 Binary files /dev/null and b/meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png differ diff --git a/meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png.md5 b/meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png.md5 new file mode 100644 index 00000000..a5ba285b --- /dev/null +++ b/meta/files/images/comp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.png.md5 @@ -0,0 +1 @@ +8dd5cf65a8163d7d6d22c487b6aaa466 diff --git a/meta/files/images/webp/Pasted image 20241127183453.webp b/meta/files/images/webp/Pasted image 20241127183453.webp new file mode 100644 index 00000000..41c6898a Binary files /dev/null and b/meta/files/images/webp/Pasted image 20241127183453.webp differ diff --git a/meta/files/images/webp/Pasted image 20241127183453.webp.md5 b/meta/files/images/webp/Pasted image 20241127183453.webp.md5 new file mode 100644 index 00000000..61141aad --- /dev/null +++ b/meta/files/images/webp/Pasted image 20241127183453.webp.md5 @@ -0,0 +1 @@ +0fa259b2c5e5423ca919b55f4b2db19a diff --git a/meta/files/images/webp/Pasted image 20241127183553.webp b/meta/files/images/webp/Pasted image 20241127183553.webp new file mode 100644 index 00000000..bed75cf1 Binary files /dev/null and b/meta/files/images/webp/Pasted image 20241127183553.webp differ diff --git a/meta/files/images/webp/Pasted image 20241127183553.webp.md5 b/meta/files/images/webp/Pasted image 20241127183553.webp.md5 new file mode 100644 index 00000000..5c7a2f7b --- /dev/null +++ b/meta/files/images/webp/Pasted image 20241127183553.webp.md5 @@ -0,0 +1 @@ +856b67234f0c093c95fdff30e7df17f2 diff --git a/meta/files/images/webp/Pasted image 20241127184802.webp b/meta/files/images/webp/Pasted image 20241127184802.webp new file mode 100644 index 00000000..3a8fa6f7 Binary files /dev/null and b/meta/files/images/webp/Pasted image 20241127184802.webp differ diff --git a/meta/files/images/webp/Pasted image 20241127184802.webp.md5 b/meta/files/images/webp/Pasted image 20241127184802.webp.md5 new file mode 100644 index 00000000..7a59f62e --- /dev/null +++ b/meta/files/images/webp/Pasted image 20241127184802.webp.md5 @@ -0,0 +1 @@ +b42c40507c4e1dc957bf2da94e08080f diff --git a/meta/files/images/webp/Pasted image 20241127200905.webp b/meta/files/images/webp/Pasted image 20241127200905.webp new file mode 100644 index 00000000..a9201d27 Binary files /dev/null and b/meta/files/images/webp/Pasted image 20241127200905.webp differ diff --git a/meta/files/images/webp/Pasted image 20241127200905.webp.md5 b/meta/files/images/webp/Pasted image 20241127200905.webp.md5 new file mode 100644 index 00000000..9ab56a7d --- /dev/null +++ b/meta/files/images/webp/Pasted image 20241127200905.webp.md5 @@ -0,0 +1 @@ +a73518e97304f3df38cebc45419f52a0 diff --git a/meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp b/meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp new file mode 100644 index 00000000..6e38453a Binary files /dev/null and b/meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp differ diff --git a/meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp.md5 b/meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp.md5 new file mode 100644 index 00000000..a5ba285b --- /dev/null +++ b/meta/files/images/webp/a46f1a15-51d7-4007-8116-0d6b936c5cd1.webp.md5 @@ -0,0 +1 @@ +8dd5cf65a8163d7d6d22c487b6aaa466 diff --git a/meta/zero/00 Архитектура ИС.md b/meta/zero/00 Архитектура ИС.md index 4b9bf2f6..be0f44c2 100644 --- a/meta/zero/00 Архитектура ИС.md +++ b/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]]