Обновление

dev/Universal Unique IDentifier.md

@@ -41,7 +41,7 @@ UUID версии 1 использует текущее время по григ
 
 UUID версии 3 (V3) — это идентификатор, основанный на алгоритме хеширования [[cryptography/MD5|MD5]]. В отличие от UUID версии 1, который использует текущее время, UUID V3 генерируется на основе имени (строки) и пространства имен (namespace). Основная идея заключается в том, что при использовании одинаковых имени и пространства имен результатом всегда будет один и тот же UUID.
 
-**Пример использования:** Когда нужно сгенерировать уникальный идентификатор для имени домена в сети, применяется UUID V3 с пространством имен **DNS** и строкой, содержащей доменное имя. Например:
+**Пример использования:** Когда нужно сгенерировать уникальный идентификатор для имени домена в сети, применяется UUID V3 с пространством имен [[network/Domain Name System|DNS]] и строкой, содержащей доменное имя. Например:
 
 ```
 UUID(DNS, "example.com") → 5df41881-3aed-3515-88a7-2f4a814cf09e

dev/architecture/CAP теорема.md

@@ -1,5 +1,6 @@
 ---
-aliases: 
+aliases:
+  - CAP-теорема
 tags:
   - maturity/🌱
 date:

dev/architecture/Session Affinity.md

@@ -0,0 +1,44 @@
+---
+aliases:
+  - Sticky Sessions
+tags:
+  - maturity/🌱
+date: 2025-01-17
+---
+**Session Affinity** (или **Sticky Sessions**) — это подход в [[highload/Балансировка нагрузки|балансировке нагрузки]], при котором запросы от одного клиента всегда направляются на один и тот же сервер в течение всей сессии. Это обеспечивает сохранение состояния клиента на конкретном сервере и делает взаимодействие более последовательным.
+
+**Преимущества**
+- **Сохранение состояния**: Не требует сложной реализации хранения состояния между серверами.
+- **Простота для разработчиков**: Упрощает работу с приложениями, которые не являются [[Stateless Service|stateless]].
+
+**Недостатки**
+- **Риски перегрузки**: Сервер, привязанный к большому количеству клиентов, может стать перегруженным.
+- **Уязвимость к сбоям**: Если сервер выходит из строя, сессии клиентов теряются.
+- Меньшая гибкость [[Масштабирование информационной системы|масштабирования]]: Динамическое добавление или удаление серверов затруднено.
+
+**Методы реализации**
+- **По IP-адресу клиента**:
+    - Сервер выбирается на основе IP-адреса клиента.
+    - Простая реализация, но уязвима к использованию прокси-серверов и NAT.
+- **По cookie**:
+    - Балансировщик устанавливает [[../network/Cookie|cookie]] на клиенте, где хранится информация о назначенном сервере.
+    - Наиболее популярный метод благодаря своей гибкости.
+- **На основе токена**:
+	- Клиент предоставляет токен (например, JWT), который указывает на сервер, обрабатывающий сессию.
+	- Токен может быть частью механизма аутентификации.
+- **Hash-Based (Хеширование)**:
+	- Сервер определяется через хеширование идентификатора клиента (например, IP, ID пользователя или URL).
+	- Эффективен для систем с большим количеством пользователей.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[highload/Балансировка нагрузки|Балансировка нагрузки]]
+**Источник**:: 
+**Создана**:: [[2025-01-17]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Stateless Service.md

@@ -0,0 +1,32 @@
+---
+aliases:
+  - Stateless
+  - Stateless-сервисы
+tags:
+  - maturity/🌱
+date: 2025-01-17
+---
+**Stateless-приложения** — это приложения или сервисы, которые обрабатывают каждый запрос как независимое событие, не полагаясь на сохранение данных между запросами. Вся необходимая информация для выполнения запроса должна передаваться в рамках самого запроса.
+
+**Преимущества:**
+- [[Масштабирование информационной системы|Масштабируемость]]: Простота [[highload/Горизонтальное масштабирование|горизонтального масштабирования]] за счет отсутствия необходимости синхронизации состояния между серверами.
+- **Отказоустойчивость**: Выход из строя одного сервера не влияет на другие. Пользователь может обратиться к любому серверу в кластере, и запрос будет обработан корректно.
+- **Упрощенное управление**: Легче деплоить и управлять, так как не требуется репликация состояния.
+- Совместимость с [[highload/Балансировка нагрузки|балансировкой нагрузки]]: Подход хорошо интегрируется с алгоритмами балансировки, такими как Round Robin или Least Connections.
+
+**Недостатки**
+- **Необходимость внешнего хранилища**: Для хранения состояния используются базы данных, кэши (Redis, Memcached) или другие системы. Это может увеличить задержки при доступе к данным.
+- **Более сложные запросы**: Поскольку сервер не помнит пользователя, клиент должен передавать всю необходимую информацию в каждом запросе (например, токены аутентификации, данные контекста).
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2025-01-17]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/highload/Балансировка нагрузки.md

@@ -5,6 +5,9 @@ aliases:
   - балансировщики нагрузки
   - балансировщиком нагрузки
   - балансировщиком
+  - балансировке нагрузки
+  - алгоритмами балансировки
+  - балансировкой нагрузки
 tags:
   - maturity/🌱
 date: 2024-06-13
@@ -12,14 +15,16 @@ date: 2024-06-13
 ![[../../../meta/files/images/Pasted image 20241103021050.png]]
 
 **Статические алгоритмы**
-- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть stateless (не сохранять состояние между запросами).
+- **Round robin**. Запросы от клиентов отправляются поочередно разным экземплярам сервиса. Как правило, сервисы должны быть [[../Stateless Service|stateless]] (не сохранять состояние между запросами).
 - **Sticky round-robin** Улучшенная версия алгоритма round robin. Если первый запрос от Алисы попал на сервис A, то и все последующие её запросы будут отправляться на этот же сервис A.
 - **Weighted round-robin** Администратор может задать вес для каждого сервиса. Сервисы с большим весом будут обрабатывать больше запросов, чем другие.
 - **Hash (Хеширование)** Этот алгоритм применяет хеш-функцию к IP-адресу или URL запроса. Запросы направляются на соответствующие экземпляры сервиса в зависимости от результата [[../../cryptography/Хеш-функция|хеш-функции]].
+- [[../Session Affinity|Session Affinity]]
   
 **Динамические алгоритмы**
 - **Least connections**. Новый запрос отправляется экземпляру сервиса с наименьшим числом текущих соединений.
 - **Least response time.** Новый запрос отправляется на экземпляр сервиса с самым быстрым временем отклика.
+- **Adaptive Load Balancing**. Использует мониторинг серверов и их текущей нагрузки (CPU, RAM, сетевые ресурсы). Запрос направляется на наиболее “свободный” сервер.
 
 ***
 ## Мета информация
@@ -32,3 +37,6 @@ date: 2024-06-13
 - 
 ### Дочерние заметки
 <!-- 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) -->
+- [[Session Affinity]]
+<!-- SerializedQuery END -->

dev/architecture/Кэширование.md

@@ -33,7 +33,7 @@ linked:
 - [Кэширование на стороне браузера](highload/Кэширование%20на%20стороне%20браузера.md). Ответы HTTP могут кэшироваться браузером. При первом запросе данных по HTTP они возвращаются с политикой истечения срока действия в заголовке HTTP. При повторном запросе данных клиентское приложение сначала пытается получить их из кэша браузера.
 - [Кэширование на стороне Nginx](../devops/nginx/Кэширование%20на%20стороне%20Nginx.md)
 - [Content Delivery Network](highload/Content%20Delivery%20Network.md). CDN кэширует статические веб-ресурсы. Клиенты могут получать данные с ближайшего узла CDN.
-- **Балансировщик нагрузки**: Балансировщик также может кэшировать ресурсы.
+- [[highload/Балансировка нагрузки|Балансировщик нагрузки]]: Балансировщик также может кэшировать ресурсы.
 - [Кэширование в приложении](Кэширование%20в%20приложении.md). В сервисах есть несколько уровней кэша. Если данные не находятся в кэше процессора, сервис пытается получить их из памяти. Иногда в сервисе есть вторичный уровень кэша для хранения данных на диске.
 - **Распределённый кэш**: Распределённые кэши, такие как Redis, хранят пары ключ-значение в памяти для множества сервисов. Это обеспечивает значительно лучшую производительность чтения и записи по сравнению с базой данных.
 - **База данных**: Даже в базе данных есть различные уровни кэша

dev/architecture/Масштабирование информационной системы.md

@@ -4,6 +4,7 @@ aliases:
   - масштабировании
   - масштабируемости
   - масштабируемость
+  - масштабирования
 tags:
   - maturity/🌱
 date: 2024-12-03

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

@@ -15,7 +15,7 @@ date: 2024-04-04
 - **Лёгкость внесения радикальных изменений**. В монолитной архитектуре вы можете одновременно менять код и структуру базы данных. После этого достаточно пересобрать и развернуть новое приложение.
 - **Простота тестирования**. Сквозное тестирование охватывает всю систему сразу. Инструменты, такие как Selenium, позволяют тестировать пользовательский интерфейс, API и внутреннюю логику в одном процессе.
 - **Упрощённое развертывание**. Разработчику достаточно скопировать один WAR-файл (или аналог) на сервер с установленным приложением, например Tomcat.
-- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за балансировщиком нагрузки, распределяя трафик между ними.
+- **Масштабирование путём клонирования**. Для увеличения производительности можно развернуть несколько экземпляров приложения за [[highload/Балансировка нагрузки|балансировщиком нагрузки]], распределяя трафик между ними.
 
 Несмотря на простоту, монолитный подход имеет **ряд ограничений**, которые могут стать критическими при увеличении размера приложения или масштабировании бизнеса:
 - **Трудности с масштабированием**. Программные модули конкурируют за ресурсы. Например, модуль обработки изображений, нагружающий CPU, может негативно влиять на стабильность других модулей.

dev/architecture/Распределённая система.md

@@ -0,0 +1,48 @@
+---
+aliases:
+  - распределенная система
+tags:
+  - maturity/🌱
+date: 2025-01-17
+---
+Распределённая система — это группа независимых компьютеров, которые взаимодействуют через сеть для выполнения общей задачи. Для пользователя такая [[Информационная система|система]] выглядит как единое целое.
+
+Примеры: кластеры серверов, системы хранения данных (например, Hadoop, [[Cassandra]]), платформы потоковой обработки ([[00 Kafka|Kafka]], Flink) и блокчейн-сети.
+
+**Основные характеристики:**
+- **Отсутствие общего состояния:** Каждый узел работает независимо, состояние хранится локально или реплицируется между узлами.
+- **Прозрачность распределения:** Система должна скрывать сложность распределения от пользователя, обеспечивая:
+	- **Доступ**: пользователю не нужно знать, на каком узле хранятся данные.
+	- **Расположение**: данные могут быть перемещены между узлами.
+	- **Сопряжённость**: система должна справляться с частичными сбоями.
+- [[Масштабирование информационной системы|Масштабируемость]]: Возможность увеличивать производительность системы за счёт добавления новых узлов.
+- [[Reliability|Отказоустойчивость]]: Система продолжает работать даже при сбое отдельных компонентов.
+- [[Согласованность данных|Согласованность данных]]: Обеспечение актуальности данных на всех узлах в условиях асинхронных операций.
+
+**Проблемы распределённых систем**
+- Согласованность данных ([[CAP теорема|CAP-теорема]]):
+	- Система не может одновременно обеспечивать все три свойства:
+		- **Согласованность (Consistency):** Все узлы возвращают одинаковые данные.
+		- **Доступность (Availability):** Каждый запрос получает ответ, даже при сбоях.
+		- **Устойчивость к разделению (Partition Tolerance):** Система работает при разделении сети.
+- **Управление отказами:** Определение, какие узлы вышли из строя, и их восстановление.
+- **Сложность разработки:** Необходимость учитывать сетевые [[Latency|задержки]], частичные сбои и распределённое состояние.
+- **Производительность:** Распределённые операции могут быть медленнее из-за необходимости синхронизации данных.
+
+**Модели взаимодействия**
+- **Клиент-сервер:** Клиенты отправляют запросы, серверы обрабатывают их.
+- **Peer-to-Peer (P2P):** Все узлы равны и взаимодействуют напрямую. Пример: BitTorrent, блокчейн.
+- **Публикация-подписка (Pub/Sub):** Узлы подписываются на определённые темы и получают уведомления о новых событиях. Пример: [[../../../../_inbox/00 Kafka|Kafka]], [[../../../../_inbox/00 RabbitMQ|RabbitMQ]].
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Информационная система]]
+**Источник**:: 
+**Создана**:: [[2025-01-17]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+

dev/architecture/Согласованность данных.md

@@ -23,7 +23,7 @@ date: 2025-01-15
 - [[highload/Монотонное чтение|Монотонное чтение]] (Monotonic Read Consistency):
 	- Если пользователь прочитал определённое значение данных, последующие чтения не вернут более старое состояние.
 - [[Еventual consistency|Конечная согласованность]] (Eventual Consistency): Узлы системы со временем синхронизируются, но в краткосрочной перспективе данные могут быть несогласованными.
-	- Пример: Системы репликации данных, такие как [[../../../../knowledge/dev/network/DNS|DNS]].
+	- Пример: Системы репликации данных, такие как [[../network/Domain Name System|Domain Name System]].
 
 **Методы обеспечения согласованности**
 - **Консенсусные алгоритмы**:
@@ -49,7 +49,7 @@ date: 2025-01-15
 ### Дочерние заметки
 <!-- 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) -->
-- [[Еventual consistency]]
 - [[Согласованность транзакции БД (Сonsistency)]]
+- [[Еventual consistency]]
 <!-- SerializedQuery END -->
 

dev/network/Domain Name System.md

@@ -0,0 +1,74 @@
+---
+aliases:
+  - DNS
+tags:
+  - maturity/🌱
+date:
+  - - 2024-01-13
+---
+## Тезисы
+- **DNS (Domain Name System)** — это система, которая преобразует доменные имена в IP-адреса и наоборот.
+- DNS — это распределенная база данных, состоящая из множества серверов, которые хранят и предоставляют информацию о доменах.
+- Основные компоненты DNS: клиент (resolving), серверы (root, TLD, authoritative), зоны и записи (A, AAAA, CNAME и другие).
+- Процесс DNS-запроса включает несколько этапов, начиная от локального кэша до root-серверов и серверов имен.
+***
+**DNS (Domain Name System)** — это [[../architecture/Распределённая система|распределенная система]], которая позволяет пользователям использовать удобные доменные имена (например, `example.com`) вместо сложных для запоминания [[../../../../knowledge/dev/network/Internet Protocol v4|IP]]-адресов (например, `192.0.2.1`).
+
+По умолчанию DNS сервер работает на 53 порту.
+
+**Компоненты DNS**
+- **DNS-клиенты (Resolvers)**
+    - Это программы или устройства, которые инициализируют DNS-запрос для преобразования доменного имени в IP-адрес.
+    - Пример: ваш браузер или операционная система.
+- **DNS-серверы**:
+	- **Root-серверы**:
+		- Основной уровень в иерархии DNS.
+		- Направляют запросы к серверам TLD (Top-Level Domain).
+		- Существует 13 логических групп root-серверов (например, `a.root-servers.net`).
+	- **TLD-серверы**: Обрабатывают запросы для доменов верхнего уровня (например, `.com`, `.org`, `.ru`).
+	- **Authoritative Name Servers**: Хранят окончательную информацию о домене, включая IP-адреса, записи MX и другие.
+- **DNS-зоны**:
+	- Фрагменты пространства имен, управляемые конкретным сервером.
+	- Пример: зона для `example.com` может включать записи для `www.example.com` и `mail.example.com`.
+- **DNS-записи**:
+	- **A**: IPv4-адрес.
+	- **AAAA**: IPv6-адрес.
+	- **CNAME**: каноническое имя (псевдоним для другого домена).
+	- **MX**: почтовые серверы для домена.
+	- **TXT**: текстовые данные, используемые для SPF, DKIM, подтверждения владения.
+	- **NS**: серверы, обслуживающие зону.
+	- **PTR**: обратное преобразование IP в доменное имя.
+
+**Как работает DNS?**
+1. **Пользователь вводит доменное имя в браузере.**
+2. **Клиент (resolver)** проверяет локальный кэш. Если запись найдена, используется она.
+3. Если записи нет, запрос отправляется на root-сервер.
+4. Root-сервер перенаправляет запрос на сервер TLD (например, `.com`).
+5. TLD-сервер перенаправляет запрос на authoritative сервер для конкретного домена.
+6. Authoritative сервер возвращает нужную запись (например, IP-адрес).
+7. Клиент получает IP-адрес и устанавливает соединение с сервером по этому адресу.
+
+**Проблемы и угрозы DNS**
+- **DNS Spoofing (подмена)**: Атака, при которой злоумышленники подменяют ответ DNS-сервера, перенаправляя пользователей на вредоносные сайты.
+- **DDoS-атаки на DNS**: Направлены на перегрузку серверов, чтобы сделать их недоступными.
+- **Кэш-поизонинг**: Внедрение ложной информации в кэш DNS.
+- **Проблемы с конфиденциальностью**: DNS-запросы могут быть видны третьим сторонам, что создает риски слежки.
+
+**Современные улучшения DNS**
+- **DNSSEC (DNS Security Extensions)**: Добавляет цифровую подпись для проверки подлинности записей.
+- **DoH (DNS over HTTPS)** и **DoT (DNS over TLS)**: Шифруют DNS-запросы, повышая конфиденциальность и защищенность.
+- **Anycast**: Используется для распределения запросов на ближайший DNS-сервер, улучшая производительность и устойчивость.
+
+## Заметки
+- По умолчанию работает по протоколу [UDP](UDP.md), переходит на [TCP](TCP.md) если размер ответа больше 500 байт.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: 
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2024-01-13]]
+### Дополнительные материалы
+- 
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->