diff --git a/dev/system-design/GraphQL.md b/dev/GraphQL.md
similarity index 80%
rename from dev/system-design/GraphQL.md
rename to dev/GraphQL.md
index db0375d5..f209c9ff 100644
--- a/dev/system-design/GraphQL.md
+++ b/dev/GraphQL.md
@@ -4,20 +4,20 @@ tags:
   - maturity/🌱
 date: 2024-11-03
 ---
-![[../../meta/files/images/Pasted image 20241103004648.png]]
+![[../meta/files/images/Pasted image 20241103004648.png]]
 
 - Предоставляет клиентам единую конечную точку для запроса именно тех данных, которые им нужны.
 - Клиенты указывают точные поля, требуемые во вложенных запросах, и сервер возвращает оптимизированный ответ, содержащую только эти поля.
 - Поддерживает модификации для изменения данных и подписки на уведомления в режиме реального времени.
 - Отлично подходит для объединения данных из нескольких источников и хорошо работает с быстро меняющимися требованиями к интерфейсу.
 - Однако это переносит сложность на сторону клиента и может допускать некорректные запросы, если они не защищены должным образом.
-- Стратегии кэширования могут быть более сложными, чем [[RESTful|REST]].
+- Стратегии кэширования могут быть более сложными, чем [[architecture/Representation State Transfer|REST]].
 
 
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Протоколы коммуникаций|Протоколы коммуникаций]]
+**Область**:: [[../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[architecture/Протоколы коммуникаций|Протоколы коммуникаций]]
 **Источник**:: 
 **Создана**:: [[2024-11-03]]
 **Автор**:: 
diff --git a/dev/architecture/API Gateway.md b/dev/architecture/API Gateway.md
index 736b017b..91ba0a98 100644
--- a/dev/architecture/API Gateway.md	
+++ b/dev/architecture/API Gateway.md	
@@ -6,7 +6,7 @@ date: 2024-11-03
 ---
 ![[../../meta/files/images/Pasted image 20241103020227.png|600]]
 
-**Шаг 1**: Клиент отправляет [[../network/HTTP|HTTP]]-запрос на API-шлюз.
+**Шаг 1**: Клиент отправляет [[../network/HyperText Transfer Protocol|HTTP]]-запрос на API-шлюз.
 **Шаг 2**: API-шлюз анализирует и проверяет атрибуты запроса.
 **Шаг 3**: API-шлюз выполняет проверки по спискам разрешений и запретов (allow-list/deny-list).
 **Шаг 4**: API-шлюз взаимодействует с поставщиком идентификаций для аутентификации и авторизации.
diff --git a/dev/system-design/Long polling.md b/dev/architecture/Long polling.md
similarity index 100%
rename from dev/system-design/Long polling.md
rename to dev/architecture/Long polling.md
diff --git a/dev/system-design/Remote Procedure Call.md b/dev/architecture/Remote Procedure Call.md
similarity index 100%
rename from dev/system-design/Remote Procedure Call.md
rename to dev/architecture/Remote Procedure Call.md
diff --git a/dev/system-design/RESTful.md b/dev/architecture/Representation State Transfer.md
similarity index 79%
rename from dev/system-design/RESTful.md
rename to dev/architecture/Representation State Transfer.md
index cb21d3c9..e0c72e11 100644
--- a/dev/system-design/RESTful.md
+++ b/dev/architecture/Representation State Transfer.md	
@@ -1,12 +1,15 @@
 ---
 aliases:
   - REST
+  - REST API
+  - RESTful
 tags:
   - maturity/🌱
 date: 2024-11-03
 ---
-![[../../meta/files/images/Pasted image 20241103004607.png]]
+Representation State Transfer (REST) - способ взаимодействия компонентов распределенного приложения в сети.
 
+![[../../meta/files/images/Pasted image 20241103004607.png]]
 
 - Использует стандартные HTTP-методы, такие как GET, POST, PUT, DELETE, для операций CRUD.
 - Хорошо работает, когда вам нужны простые, единообразные интерфейсы между отдельными сервисами / приложениями.
@@ -17,7 +20,7 @@ date: 2024-11-03
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Протоколы коммуникаций|Протоколы коммуникаций]]
+**Родитель**:: [[../architecture/Протоколы коммуникаций|Протоколы коммуникаций]]
 **Источник**:: 
 **Создана**:: [[2024-11-03]]
 **Автор**:: 
diff --git a/dev/system-design/Short polling.md b/dev/architecture/Short polling.md
similarity index 97%
rename from dev/system-design/Short polling.md
rename to dev/architecture/Short polling.md
index ded3d03d..864bef86 100644
--- a/dev/system-design/Short polling.md	
+++ b/dev/architecture/Short polling.md	
@@ -25,7 +25,7 @@ date: 2024-11-03
 **Создана**:: [[2024-11-03]]
 **Автор**:: 
 ### Дополнительные материалы
-- [[Long polling]]
+- [[../architecture/Long polling]]
 - [[Webhook]]
 
 ### Дочерние заметки
diff --git a/dev/system-design/Webhook.md b/dev/architecture/Webhook.md
similarity index 75%
rename from dev/system-design/Webhook.md
rename to dev/architecture/Webhook.md
index 3a845cca..bdd2a04a 100644
--- a/dev/system-design/Webhook.md
+++ b/dev/architecture/Webhook.md
@@ -4,7 +4,7 @@ tags:
   - maturity/🌱
 date: 2024-11-03
 ---
-**Webhook** — это метод взаимодействия между системами, при котором один сервер автоматически отправляет HTTP-запрос на другой сервер, когда происходит определенное событие. В отличие от [[Long polling|Long polling]] или [[Short polling|Short polling]], клиенту не нужно регулярно проверять наличие обновлений; вместо этого он получает уведомление от сервера в режиме реального времени.
+**Webhook** — это метод взаимодействия между системами, при котором один сервер автоматически отправляет HTTP-запрос на другой сервер, когда происходит определенное событие. В отличие от [[../architecture/Long polling|Long polling]] или [[../architecture/Short polling|Short polling]], клиенту не нужно регулярно проверять наличие обновлений; вместо этого он получает уведомление от сервера в режиме реального времени.
 
 ![[../../meta/files/images/Pasted image 20241103010806.png|600]]
 
@@ -18,13 +18,13 @@ date: 2024-11-03
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Протоколы коммуникаций]]
+**Родитель**:: [[../architecture/Протоколы коммуникаций]]
 **Источник**:: 
 **Создана**:: [[2024-11-03]]
 **Автор**:: 
 ### Дополнительные материалы
-- [[Short polling]]
-- [[Long polling]]
+- [[../architecture/Short polling]]
+- [[../architecture/Long polling]]
 
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
diff --git a/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md b/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md
index 4af7702a..2c6031a9 100644
--- a/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md	
+++ b/dev/architecture/highload/Идемпотентность на базе уникального идентификатора.md	
@@ -4,7 +4,7 @@ tags:
   - maturity/🌱
 date: 2024-11-12
 ---
-При реализации [[../Идемпотентность|идемпотентности]] в системах, где требуется многократная обработка событий или вызовов, [[../../../meta/zero/00 Redis|Redis]] может быть использован как ключевой инструмент для предотвращения повторной обработки сообщений. Данное решение подходит для различных систем обмена сообщениями, таких как [[../../../../../_inbox/00 Kafka|Kafka]], [[../../system-design/gRPC|gRPC]], [[../../network/HTTP|HTTP]], и других видов асинхронных или синхронных вызовов.
+При реализации [[../Идемпотентность|идемпотентности]] в системах, где требуется многократная обработка событий или вызовов, [[../../../meta/zero/00 Redis|Redis]] может быть использован как ключевой инструмент для предотвращения повторной обработки сообщений. Данное решение подходит для различных систем обмена сообщениями, таких как [[../../../../../_inbox/00 Kafka|Kafka]], [[../../gRPC|gRPC]], [[../../network/HyperText Transfer Protocol|HTTP]], и других видов асинхронных или синхронных вызовов.
 ### Основной подход
 Каждое сообщение или запрос должен иметь уникальный идентификатор, обычно называемый **requestId**. Этот идентификатор присваивается при создании сообщения или вызова и передаётся вместе с ним в процессе обработки. Потребитель, получая сообщение, сначала проверяет наличие **requestId** в Redis. Этот подход позволяет контролировать, было ли сообщение уже обработано и в каком оно состоянии.
 
diff --git a/dev/architecture/highload/Кэширование на стороне браузера.md b/dev/architecture/highload/Кэширование на стороне браузера.md
index 5b85b589..a51fcf83 100644
--- a/dev/architecture/highload/Кэширование на стороне браузера.md	
+++ b/dev/architecture/highload/Кэширование на стороне браузера.md	
@@ -1,5 +1,5 @@
 ---
-aliases: 
+aliases: []
 tags:
   - maturity/🌱
 date:
@@ -14,10 +14,10 @@ linked:
 
 Обычно кэшируются только GET запросы, так как они должны быть [[../Идемпотентность|идемпотентны]].
 
-Заголовки для кэширования:
+Управление кэшированием часто осуществляется с помощью http-заголовков. Заголовки для кэширования:
 - ETAG. Тег, который позволяет указать версию файла. Можно использовать [[../../cryptography/MD5|MD5]].
-- If-Modified-Since. Дата изменения файла.
-- Cache-Control
+- [[../../network/Условный GET запрос|If-Modified-Since]]. Дата изменения файла.
+- Cache-Control. Передает инструкции по выполнению кэширования.
 	- public - Сохранять может не только браузер, но и промежуточные узлы
 	- private - Сохранять может только браузер клиента
 	- no-store - не кэшируем. ==не уверен что правильно записал==
@@ -43,3 +43,6 @@ linked:
 - [[../../devops/nginx/Кэширование статики в Nginx]]
 ### Дочерние заметки
 <!-- 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) -->
+- [[Кэширование статики в Nginx]]
+<!-- SerializedQuery END -->
diff --git a/dev/architecture/Контракт взаимодействия.md b/dev/architecture/Контракт взаимодействия.md
index 4d54b798..839e40d3 100644
--- a/dev/architecture/Контракт взаимодействия.md	
+++ b/dev/architecture/Контракт взаимодействия.md	
@@ -27,7 +27,7 @@ zero-link:
 
 **Контракт API**: В контексте API контрактом является описание того, как клиент может взаимодействовать с API. Это включает в себя форматы запросов и ответов, методы HTTP, параметры, типы данных, кодировки и обработку ошибок.
    
-Пример контракта [[../system-design/RESTful|REST]] API:
+Пример контракта [[Representation State Transfer|REST]] API:
 - Метод: `POST /users` 
 - Входные данные: JSON-объект с полями `name` и `email`
 - Ответ: код 201 (Created) и объект пользователя
diff --git a/dev/architecture/Проблема горизонтального масштабирования Websocket.md b/dev/architecture/Проблема горизонтального масштабирования Websocket.md
index 3fe04cd1..5961f3e5 100644
--- a/dev/architecture/Проблема горизонтального масштабирования Websocket.md	
+++ b/dev/architecture/Проблема горизонтального масштабирования Websocket.md	
@@ -4,7 +4,7 @@ tags:
   - maturity/🌱
 date: 2024-11-13
 ---
-WebSocket-соединение, в отличие от [[../system-design/RESTful|REST]], имеет состояние, которое представлено объектом класса `Session`. Это создает трудности при горизонтальном масштабировании.
+WebSocket-соединение, в отличие от [[Representation State Transfer|REST]], имеет состояние, которое представлено объектом класса `Session`. Это создает трудности при горизонтальном масштабировании.
 
 Представим, что наш сервис чатов развернут в Kubernetes с 3 репликами. Пользователь чата открывает три вкладки браузера с нашим онлайн-чатом. [[highload/Балансировка нагрузки|Балансировщик нагрузки]], использующий алгоритм round robin, распределяет соединения между тремя репликами, и каждое соединение (каждая вкладка) попадает на свою реплику.
 
diff --git a/dev/system-design/Протоколы коммуникаций.md b/dev/architecture/Протоколы коммуникаций.md
similarity index 93%
rename from dev/system-design/Протоколы коммуникаций.md
rename to dev/architecture/Протоколы коммуникаций.md
index 2edd217b..afd484b4 100644
--- a/dev/system-design/Протоколы коммуникаций.md	
+++ b/dev/architecture/Протоколы коммуникаций.md	
@@ -8,12 +8,12 @@ date: 2024-11-03
 
 - [[../../../../_inbox/SOAP|SOAP]]
 	- Основан на XML
-- [[RESTful]]
+- [[Representation State Transfer]]
 	- Популярный, легко реализуемый, методы HTTP
 	- Идеален для веб-сервисов
-- [[GraphQL]]
+- [[../GraphQL]]
 	- Язык запросов, позволяет запрашивать конкретные данные
-- [[gRPC|gRPC]]
+- [[../gRPC|gRPC]]
 	- Современный, высокопроизводительный, использует Protocol Buffers
 	- Подходит для микросервисных архитектур для межсервисного общения.
 - WebSocket
@@ -34,9 +34,9 @@ date: 2024-11-03
 ### Дочерние заметки
 <!-- 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) -->
-- [[GraphQL]]
-- [[RESTful]]
 - [[Webhook]]
+- [[Representation State Transfer]]
 - [[gRPC]]
+- [[GraphQL]]
 <!-- SerializedQuery END -->
 
diff --git a/dev/system-design/Append-Only File.md b/dev/database/redis/Append-Only File.md
similarity index 97%
rename from dev/system-design/Append-Only File.md
rename to dev/database/redis/Append-Only File.md
index 916d067d..ff9ccc5b 100644
--- a/dev/system-design/Append-Only File.md	
+++ b/dev/database/redis/Append-Only File.md	
@@ -11,7 +11,7 @@ linked:
 ---
 Включение режима appendonly позволяет Redis обеспечивать долговременное хранение данных, записывая каждую операцию изменения в файл в хронологическом порядке. Вот основные моменты, которые стоит знать.
 
-![[../../meta/files/images/Pasted image 20241103222301.png]]
+![[../../../meta/files/images/Pasted image 20241103222301.png]]
 
 **Как работает AOF:**
 - **Лог изменений**: Когда appendonly включен, Redis записывает каждую команду, изменяющую состояние базы данных (например, SET, DEL, LPUSH), в файл AOF, а не только хранит данные в памяти.
@@ -31,7 +31,7 @@ linked:
 - **Производительность**: В зависимости от настроек, частота записи в AOF может влиять на производительность системы (особенно при использовании режима appendfsync always).
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Redis|00 Redis]]
+**Область**:: [[../../../meta/zero/00 Redis|00 Redis]]
 **Родитель**:: 
 **Источник**:: 
 **Создана**:: [[2024-10-07]]
diff --git a/dev/system-design/Redis Database Backup.md b/dev/database/redis/Redis Database Backup.md
similarity index 84%
rename from dev/system-design/Redis Database Backup.md
rename to dev/database/redis/Redis Database Backup.md
index 1b2e8652..48b8359d 100644
--- a/dev/system-design/Redis Database Backup.md	
+++ b/dev/database/redis/Redis Database Backup.md	
@@ -5,9 +5,9 @@ tags:
   - maturity/🌱
 date: 2024-10-07
 ---
-Механизм RDB (Redis Database Backup) — это способ создания **снапшотов** состояния базы данных Redis и их сохранения на диск. В отличие от [[Append-Only File|AOF]], который записывает каждую операцию в реальном времени, RDB создаёт полные резервные копии состояния базы на определенные промежутки времени. Вот как это работает и основные моменты, которые стоит учитывать:
+Механизм RDB (Redis Database Backup) — это способ создания **снапшотов** состояния базы данных Redis и их сохранения на диск. В отличие от [[database/redis/Append-Only File|AOF]], который записывает каждую операцию в реальном времени, RDB создаёт полные резервные копии состояния базы на определенные промежутки времени. Вот как это работает и основные моменты, которые стоит учитывать:
 
-![[../../meta/files/images/Pasted image 20241103222301.png]]
+![[../../../meta/files/images/Pasted image 20241103222301.png]]
 
 **Как работает RDB:**
 - **Снапшоты базы данных**: Redis периодически сохраняет полную копию всех данных в файл на диске. Это называется “снапшот”. RDB-файл содержит сжатую и двоичную версию всех ключей и их значений на момент создания.
@@ -23,13 +23,13 @@ date: 2024-10-07
 - **Тяжелые операции на большом объеме данных**: Процесс создания снапшота может потреблять значительные ресурсы, особенно в крупных базах данных, что может влиять на производительность Redis на время создания снимка.
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Redis|00 Redis]]
+**Область**:: [[../../../meta/zero/00 Redis|00 Redis]]
 **Родитель**:: 
 **Источник**:: 
 **Создана**:: [[2024-10-07]]
 **Автор**:: 
 ### Дополнительные материалы
-- [[Append-Only File]]
+- [[database/redis/Append-Only File]]
 
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
diff --git a/dev/system-design/Команды Redis-cli.md b/dev/database/redis/Команды Redis-cli.md
similarity index 93%
rename from dev/system-design/Команды Redis-cli.md
rename to dev/database/redis/Команды Redis-cli.md
index 0ddb57dd..e229381f 100644
--- a/dev/system-design/Команды Redis-cli.md	
+++ b/dev/database/redis/Команды Redis-cli.md	
@@ -26,7 +26,7 @@ Keys - команда, которая ищет ключи по маске. Ис
 
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Redis|00 Redis]]
+**Область**:: [[../../../meta/zero/00 Redis|00 Redis]]
 **Родитель**:: 
 **Источник**:: 
 **Создана**:: [[2024-11-03]]
diff --git a/dev/system-design/Конфигурация Redis.md b/dev/database/redis/Конфигурация Redis.md
similarity index 91%
rename from dev/system-design/Конфигурация Redis.md
rename to dev/database/redis/Конфигурация Redis.md
index 6ed4f62b..01c2a655 100644
--- a/dev/system-design/Конфигурация Redis.md	
+++ b/dev/database/redis/Конфигурация Redis.md	
@@ -8,18 +8,18 @@ date: 2024-11-03
 
 - `stop-writes-on-bg-save-error`. Если на snapshot возникает какая-то проблема, то Redis перестает работать. По умолчанию yes. Обычно рекомендуется отключать. Тогда могут возникнуть проблемы с персистентностью, но хотя бы память озу будет работать.
 - `rdbcompression`. Немного влияет негативно на производительность, но уменьшает размер хранимых данных.
-- `save <seconds> <changes>`. **Триггеры создания снапшотов** [[system-design/Redis Database Backup|RDB]]:
+- `save <seconds> <changes>`. **Триггеры создания снапшотов** [[Redis Database Backup|RDB]]:
 	- save 900 1 — сохранить снапшот, если в течение последних 900 секунд (15 минут) было выполнено хотя бы 1 изменение.
 	- save 300 10 — сохранить снапшот, если за последние 300 секунд (5 минут) было выполнено 10 изменений.
 	- save 60 10000 — сохранить снапшот, если за последние 60 секунд (1 минута) было выполнено 10 000 изменений.
-- [[system-design/Append-Only File|appendonly]]
+- [[database/redis/Append-Only File|appendonly]]
 - Можно указать [[algorithm/Алгоритм вытеснения кэша|Алгоритмы вытеснения]] ключей
 - `oom-score-adj-values`
 - `disable-thp`. Лучше выключить. По умолчанию выключено.
 
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Redis|00 Redis]]
+**Область**:: [[../../../meta/zero/00 Redis|00 Redis]]
 **Родитель**:: 
 **Источник**:: 
 **Создана**:: [[2024-11-03]]
diff --git a/dev/system-design/gRPC.md b/dev/gRPC.md
similarity index 90%
rename from dev/system-design/gRPC.md
rename to dev/gRPC.md
index 982a33f8..53624edf 100644
--- a/dev/system-design/gRPC.md
+++ b/dev/gRPC.md
@@ -7,7 +7,7 @@ date: 2024-04-12
 - Подходит для [[../../../../wiki/zero/00 Микросервисная архитектура|микросервисных архитектур]] для межсервисного общения.
 
 ## Как работает?
-![[../../meta/files/images/Pasted image 20241103005832.png]]
+![[../meta/files/images/Pasted image 20241103005832.png]]
 
 - **Шаг 1**: Клиент отправляет REST-запрос. Тело запроса обычно в формате JSON.
 - **Шаги 2 - 4**: Сервис заказов (gRPC-клиент) получает REST-запрос, преобразует запрос в компактный бинарный формат и передает его в транспортный слой
@@ -19,8 +19,8 @@ date: 2024-04-12
 **Балансировка нагрузки L7 vs L4**: Kubernetes обычно использует балансировку нагрузки на уровне 4 (L4), которая перенаправляет трафик на основе информации IP и порта. Однако gRPC полагается на HTTP/2, что требует балансировки на уровне 7 (L7) для эффективного распределения запросов. Это может потребовать дополнительных настроек или использования специализированных ингресс-контроллеров, поддерживающих HTTP/2.
 ***
 ## Мета информация
-**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
-**Родитель**:: [[Remote Procedure Call|RPC]], [[Протоколы коммуникаций]]
+**Область**:: [[../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[architecture/Remote Procedure Call|RPC]], [[architecture/Протоколы коммуникаций]]
 **Источник**:: 
 **Автор**:: 
 **Создана**:: [[2024-04-12]]
diff --git a/dev/network/Chunked transfer encoding.md b/dev/network/Chunked transfer encoding.md
new file mode 100644
index 00000000..2ca07420
--- /dev/null
+++ b/dev/network/Chunked transfer encoding.md	
@@ -0,0 +1,25 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+Chunked transfer encoding - механизм передачи данных в НТТР, позволяющий надежно доставлять данные от сервера клиенту, без необходимости знать точный размер сообщения
+
+- сервер добавляет заголовок `Transfer-Encoding: chunked`
+- данные разбиваются на небольшие части
+- каждая часть передается с указанием точного ее размера
+- окончанием передачи определяется наличием пустого пакета с заголовком `Content-Lenght: 0`
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: [[HyperText Transfer Protocol]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+
diff --git a/dev/network/Cookie.md b/dev/network/Cookie.md
new file mode 100644
index 00000000..b6fb6f6c
--- /dev/null
+++ b/dev/network/Cookie.md
@@ -0,0 +1,30 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+Cookies - это набор данных, в формате ключ-значение, привязанный к домену.
+
+Используется для: 
+- аутентификации пользователя
+- хранение персональных предпочтений и настроек пользователя
+- отслеживание состояния пользовательской сессии
+- сведения статистики о пользователях
+
+Особености:
+- Отправляется клиенту в заголовке Set-Cookie
+- Браузер обязан отправить cookie обратно серверу при следующем запросе
+***
+## Мета информация
+**Область**:: [[../../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) -->
+
diff --git a/dev/network/HTTP.md b/dev/network/HyperText Transfer Protocol.md
similarity index 66%
rename from dev/network/HTTP.md
rename to dev/network/HyperText Transfer Protocol.md
index 5b80bc58..aeac3a23 100644
--- a/dev/network/HTTP.md
+++ b/dev/network/HyperText Transfer Protocol.md	
@@ -1,9 +1,52 @@
 ---
-aliases: 
+aliases:
+  - HTTP
 tags:
   - maturity/🌱
 date: 2024-10-29
 ---
+НТТР (англ. Hyper Text Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных. Изначально - в виде гипертекстовых документов в формате «HTML», в настоящий момент используется для передачи произвольных данных.
+
+HTTP сообщения состоят из трех частей, которые передаются в указанном порядке:
+- Стартовая строка - определяет тип сообщения
+- HTTP-заголовки - характеризуют тело сообщения, параметры передачи и прочие сведения
+- Пустая строка для отделения данных от заголовков.
+- Тело сообщения - данные.
+
+- [[Cookie|Cookie]]
+## Http методы
+- GET - получить содержимое указанного ресурса
+- HEAD - получить только заголовки
+- POST - отправить данные на создание
+- PUT - отправить данные на обновление
+- DELETE - удалить указанный ресурс
+- OPTIONS - определить параметры сервера
+## 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
+```
+
+Заголовки подразделяются на четыре основные группы:
+- General Headers - могут включаться в любое сообщение клиента и сервера
+- Request Headers - используются только в запросах клиента
+- Response Headers - используются только для ответов от сервера
+- Entity Headers - сопровождают каждую сущность сообщения
+
+Можно добавлять свои кастомные заголовки. Традиционно кастомные заголовки начинаются с префикса `X-`, чтобы избежать конфликта имен с существующими.
+## История развития HTTP
 ![[../../meta/files/images/Pasted image 20241103014445.png]]
 
 **HTTP 1.0** был завершён и полностью задокументирован в 1996 году. Для каждого запроса к одному и тому же серверу требуется отдельное [[../../../../knowledge/dev/network/TCP|TCP]]-соединение.
@@ -13,6 +56,12 @@ date: 2024-10-29
 > [!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]]-соединения. Каждый поток может передаваться независимо от остальных.
@@ -20,8 +69,7 @@ date: 2024-10-29
 **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]]
@@ -47,4 +95,7 @@ date: 2024-10-29
 
 ### Дочерние заметки
 <!-- 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]]
+<!-- SerializedQuery END -->
 
diff --git a/dev/network/Open System Interconnection Reference Model.md b/dev/network/Open System Interconnection Reference Model.md
index f89c806e..72e6114f 100644
--- a/dev/network/Open System Interconnection Reference Model.md	
+++ b/dev/network/Open System Interconnection Reference Model.md	
@@ -12,7 +12,7 @@ date:
 > Теоретическая модель, которая на практике не используется
 
 ![[../../meta/files/images/Pasted image 20241103020737.png]]
-- **Шаг 1**: Когда Устройство A отправляет данные на Устройство B по сети через протокол [[HTTP]], к данным сначала добавляется HTTP-заголовок на уровне приложения.
+- **Шаг 1**: Когда Устройство A отправляет данные на Устройство B по сети через протокол [[HyperText Transfer Protocol]], к данным сначала добавляется HTTP-заголовок на уровне приложения.
 - **Шаг 2**: Затем к данным добавляется заголовок [[../../../../knowledge/dev/network/TCP|TCP]] или [[../../../../knowledge/dev/network/UDP|UDP]]. На транспортном уровне данные инкапсулируются в TCP-сегменты, содержащие информацию о портах отправителя и получателя, а также номер последовательности.
 - **Шаг 3**: Сегменты инкапсулируются с IP-заголовком на сетевом уровне. IP-заголовок содержит IP-адреса отправителя и получателя.
 - **Шаг 4**: На канальном уровне к IP-датаграмме добавляется MAC-заголовок с MAC-адресами отправителя и получателя.
diff --git a/dev/network/Uniform Resource Identifier.md b/dev/network/Uniform Resource Identifier.md
index ed87c6ed..6d04a0bd 100644
--- a/dev/network/Uniform Resource Identifier.md	
+++ b/dev/network/Uniform Resource Identifier.md	
@@ -5,10 +5,14 @@ tags:
   - maturity/🌱
 date: 2024-11-03
 ---
-URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса. Он определяет логический или физический ресурс в интернете. URL и URN являются подтипами URI: URL указывает расположение ресурса, а URN — его имя.
+URI (Uniform Resource Identifier) — унифицированный идентификатор ресурса. Он определяет логический или физический ресурс в интернете. [[Uniform Resource Locator|URL]] и URN являются подтипами URI: URL указывает расположение ресурса, а URN — его имя.
 
 ![[../../meta/files/images/Pasted image 20241103021719.png]]
 
+Примеры:
+URI, URL = https://example.com/nest/post/632/
+URL, URI = https://example.com
+URN, URI = /nest/post/632/
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Сети|00 Сети]]
@@ -21,4 +25,7 @@ URI (Uniform Resource Identifier) — унифицированный идент
 
 ### Дочерние заметки
 <!-- 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) -->
+- [[Uniform Resource Locator]]
+<!-- SerializedQuery END -->
 
diff --git a/dev/network/Uniform Resource Locator.md b/dev/network/Uniform Resource Locator.md
index f1d7517f..9c56d386 100644
--- a/dev/network/Uniform Resource Locator.md	
+++ b/dev/network/Uniform Resource Locator.md	
@@ -5,7 +5,9 @@ tags:
   - maturity/🌱
 date: 2024-11-03
 ---
-URL (Uniform Resource Locator) — унифицированный указатель ресурса, ключевое понятие в [[HTTP|HTTP]]. URL представляет собой адрес уникального ресурса в интернете. URL также можно использовать с другими протоколами, такими как FTP и JDBC.
+URL (Uniform Resource Locator) — унифицированный указатель ресурса, ключевое понятие в [[HyperText Transfer Protocol|HTTP]]. URL представляет собой адрес уникального ресурса в интернете. URL также можно использовать с другими протоколами, такими как FTP и JDBC.
+
+Стандарт закреплен в RFC 3986
 
 ![[../../meta/files/images/Pasted image 20241103021925.png]]
 
diff --git a/dev/network/Условный GET запрос.md b/dev/network/Условный GET запрос.md
new file mode 100644
index 00000000..18bc963d
--- /dev/null
+++ b/dev/network/Условный GET запрос.md	
@@ -0,0 +1,21 @@
+---
+aliases:
+  - If-Modified-Since
+tags:
+  - maturity/🌱
+date: 2024-11-27
+---
+GET запрос является условным, если содержит заголовок `If-Modified-Since`. Тело ресурса передается только если он изменялся после даты, указанной в заголовке. Это позволяет разгрузить сеть, так как сокращается объем избыточной информации.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Сети|00 Сети]]
+**Родитель**:: [[HyperText Transfer Protocol]]
+**Источник**:: 
+**Создана**:: [[2024-11-27]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+
diff --git a/dev/snippet/Конфигурация gRPC соединения в Quarkus.md b/dev/snippet/Конфигурация gRPC соединения в Quarkus.md
index b914ebdc..ae4cccf8 100644
--- a/dev/snippet/Конфигурация gRPC соединения в Quarkus.md	
+++ b/dev/snippet/Конфигурация gRPC соединения в Quarkus.md	
@@ -38,6 +38,6 @@ public class AppealSdkManager {
 **Автор**:: 
 **Создана**:: [[2024-04-03]]
 ### Дополнительные материалы
-- [[../system-design/gRPC|gRPC]]
+- [[../gRPC|gRPC]]
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
diff --git a/meta/files/images/Pasted image 20241127084201.png b/meta/files/images/Pasted image 20241127084201.png
new file mode 100644
index 00000000..1ba5be66
Binary files /dev/null and b/meta/files/images/Pasted image 20241127084201.png differ
diff --git a/meta/files/images/comp/Pasted image 20241127084201.png b/meta/files/images/comp/Pasted image 20241127084201.png
new file mode 100644
index 00000000..0a502637
Binary files /dev/null and b/meta/files/images/comp/Pasted image 20241127084201.png differ
diff --git a/meta/files/images/comp/Pasted image 20241127084201.png.md5 b/meta/files/images/comp/Pasted image 20241127084201.png.md5
new file mode 100644
index 00000000..330154fe
--- /dev/null
+++ b/meta/files/images/comp/Pasted image 20241127084201.png.md5	
@@ -0,0 +1 @@
+5802b66f54692a064156b91a45c1998c
diff --git a/meta/files/images/webp/Pasted image 20241127084201.webp b/meta/files/images/webp/Pasted image 20241127084201.webp
new file mode 100644
index 00000000..d5fe2c8d
Binary files /dev/null and b/meta/files/images/webp/Pasted image 20241127084201.webp differ
diff --git a/meta/files/images/webp/Pasted image 20241127084201.webp.md5 b/meta/files/images/webp/Pasted image 20241127084201.webp.md5
new file mode 100644
index 00000000..330154fe
--- /dev/null
+++ b/meta/files/images/webp/Pasted image 20241127084201.webp.md5	
@@ -0,0 +1 @@
+5802b66f54692a064156b91a45c1998c
diff --git a/meta/zero/00 Redis.md b/meta/zero/00 Redis.md
index bb24220a..6be17f24 100644
--- a/meta/zero/00 Redis.md	
+++ b/meta/zero/00 Redis.md	
@@ -14,8 +14,8 @@ Redis (Remote Dictionary Service) — это хранилище данных н
 
 Redis использует однопоточную модель выполнения с использованием multiplexing для работы с запросами, что обеспечивает простоту реализации и высокую производительность.
 
-- [[../../dev/system-design/Конфигурация Redis|Конфигурация Redis]]
-- [[../../dev/system-design/Команды Redis-cli|Команды Redis-cli]]
+- [[../../dev/database/redis/Конфигурация Redis|Конфигурация Redis]]
+- [[../../dev/database/redis/Команды Redis-cli|Команды Redis-cli]]
 
 Особенности:
 - Большое количество команд
@@ -56,8 +56,8 @@ Redis может использоваться в различных сценар
 - Кроме того, Redis задействует несколько эффективных низкоуровневых структур данных.
 
 Redis поддерживает два типа сохранения данных.
-- [[../../dev/system-design/Redis Database Backup|RDB]] создание снимков базы данных через заданные промежутки времени
-- [[../../dev/system-design/Append-Only File|AOF]] логирование каждой операции для минимизации потерь данных
+- [[../../dev/database/redis/Redis Database Backup|RDB]] создание снимков базы данных через заданные промежутки времени
+- [[../../dev/database/redis/Append-Only File|AOF]] логирование каждой операции для минимизации потерь данных
 Комбинированный подход RDB + AOF позволяет добиться как высокой производительности, так и надёжности. В случае катастрофы Redis сначала восстанавливает данные из последнего RDB-снапшота, а затем воспроизводит команды из AOF, чтобы восстановить данные до актуального состояния.
 ## Кластеризация
 Реплики работают только в режиме чтения. Нужно на стороне клиента понять в какую реплику нужно писать ключ. При отправке запроса не в ту реплику, редис ответит ошибкой, указав хост, куда нужно отправить запрос.
diff --git a/meta/zero/00 Архитектура ИС.md b/meta/zero/00 Архитектура ИС.md
index 9b7a23e7..4b9bf2f6 100644
--- a/meta/zero/00 Архитектура ИС.md	
+++ b/meta/zero/00 Архитектура ИС.md	
@@ -19,7 +19,7 @@ aliases:
 - [Service Oreinted Architecture](Service%20Oreinted%20Architecture.md)
 - [[00 HighLoad|HighLoad]]
 
-- [[../../dev/system-design/Протоколы коммуникаций|Протоколы коммуникаций]]
+- [[../../dev/architecture/Протоколы коммуникаций|Протоколы коммуникаций]]
 ## Заметки
 - На проекте вести архитектурные карты, где указаны связи между сервисами
 ## Полезное
diff --git a/source/lecture/Доклад. Могут ли Virtual threads заменить Webflux.md b/source/lecture/Доклад. Могут ли Virtual threads заменить Webflux.md
index dc26ee4c..9589d551 100644
--- a/source/lecture/Доклад. Могут ли Virtual threads заменить Webflux.md	
+++ b/source/lecture/Доклад. Могут ли Virtual threads заменить Webflux.md	
@@ -62,7 +62,7 @@ NIO посылает события Netty их преобразовывает в
 Итого, Sping WebFlux позволял нам обрабатывать множество запросов на одном потоке. И виртуальные потоки нам позволяют делать по сути то же самое. При этом не нужно разбираться в реактивной парадигме разработки. Тогда зачем нам WebFlux?
 
 ## Сравнение производительности
-Для этого сравним два подхода на примере [небольшого приложения](https://github.com/petrelevich/jvm-digging/tree/master/virtual-thread), которое будет принимать [[../../dev/system-design/RESTful|REST]] запросы и отправлять их в кафку, после чего отвечать клиенту что сообщение доставлено.
+Для этого сравним два подхода на примере [небольшого приложения](https://github.com/petrelevich/jvm-digging/tree/master/virtual-thread), которое будет принимать [[../../dev/architecture/Representation State Transfer|REST]] запросы и отправлять их в кафку, после чего отвечать клиенту что сообщение доставлено.
 
 ![[../../meta/files/images/Pasted image 20241003083724.png]]