This commit is contained in:
parent
d8d8e74b4a
commit
7d78047f43
@ -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]]
|
||||
**Автор**::
|
||||
@ -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-шлюз взаимодействует с поставщиком идентификаций для аутентификации и авторизации.
|
||||
|
||||
@ -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]]
|
||||
**Автор**::
|
||||
@ -25,7 +25,7 @@ date: 2024-11-03
|
||||
**Создана**:: [[2024-11-03]]
|
||||
**Автор**::
|
||||
### Дополнительные материалы
|
||||
- [[Long polling]]
|
||||
- [[../architecture/Long polling]]
|
||||
- [[Webhook]]
|
||||
|
||||
### Дочерние заметки
|
||||
@ -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) -->
|
||||
@ -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. Этот подход позволяет контролировать, было ли сообщение уже обработано и в каком оно состоянии.
|
||||
|
||||
|
||||
@ -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 -->
|
||||
|
||||
@ -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) и объект пользователя
|
||||
|
||||
@ -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, распределяет соединения между тремя репликами, и каждое соединение (каждая вкладка) попадает на свою реплику.
|
||||
|
||||
|
||||
@ -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 -->
|
||||
|
||||
@ -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]]
|
||||
@ -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) -->
|
||||
@ -26,7 +26,7 @@ Keys - команда, которая ищет ключи по маске. Ис
|
||||
|
||||
***
|
||||
## Мета информация
|
||||
**Область**:: [[../../meta/zero/00 Redis|00 Redis]]
|
||||
**Область**:: [[../../../meta/zero/00 Redis|00 Redis]]
|
||||
**Родитель**::
|
||||
**Источник**::
|
||||
**Создана**:: [[2024-11-03]]
|
||||
@ -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]]
|
||||
@ -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]]
|
||||
25
dev/network/Chunked transfer encoding.md
Normal file
25
dev/network/Chunked transfer encoding.md
Normal file
@ -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) -->
|
||||
|
||||
30
dev/network/Cookie.md
Normal file
30
dev/network/Cookie.md
Normal file
@ -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) -->
|
||||
|
||||
@ -1,9 +1,52 @@
|
||||
---
|
||||
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 -->
|
||||
|
||||
@ -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-адресами отправителя и получателя.
|
||||
|
||||
@ -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 -->
|
||||
|
||||
|
||||
@ -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]]
|
||||
|
||||
|
||||
21
dev/network/Условный GET запрос.md
Normal file
21
dev/network/Условный GET запрос.md
Normal file
@ -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) -->
|
||||
|
||||
@ -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) -->
|
||||
|
||||
BIN
meta/files/images/Pasted image 20241127084201.png
Normal file
BIN
meta/files/images/Pasted image 20241127084201.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 1.5 MiB |
BIN
meta/files/images/comp/Pasted image 20241127084201.png
Normal file
BIN
meta/files/images/comp/Pasted image 20241127084201.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 425 KiB |
@ -0,0 +1 @@
|
||||
5802b66f54692a064156b91a45c1998c
|
||||
BIN
meta/files/images/webp/Pasted image 20241127084201.webp
Normal file
BIN
meta/files/images/webp/Pasted image 20241127084201.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 114 KiB |
@ -0,0 +1 @@
|
||||
5802b66f54692a064156b91a45c1998c
|
||||
@ -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, чтобы восстановить данные до актуального состояния.
|
||||
## Кластеризация
|
||||
Реплики работают только в режиме чтения. Нужно на стороне клиента понять в какую реплику нужно писать ключ. При отправке запроса не в ту реплику, редис ответит ошибкой, указав хост, куда нужно отправить запрос.
|
||||
|
||||
@ -19,7 +19,7 @@ aliases:
|
||||
- [Service Oreinted Architecture](Service%20Oreinted%20Architecture.md)
|
||||
- [[00 HighLoad|HighLoad]]
|
||||
|
||||
- [[../../dev/system-design/Протоколы коммуникаций|Протоколы коммуникаций]]
|
||||
- [[../../dev/architecture/Протоколы коммуникаций|Протоколы коммуникаций]]
|
||||
## Заметки
|
||||
- На проекте вести архитектурные карты, где указаны связи между сервисами
|
||||
## Полезное
|
||||
|
||||
@ -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]]
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user