diff --git a/content-ru/.translation-manifest.json b/content-ru/.translation-manifest.json
index 531e2093a967..5f437b0190c1 100644
--- a/content-ru/.translation-manifest.json
+++ b/content-ru/.translation-manifest.json
@@ -1,4 +1,13 @@
 {
+  "browser/Event Loop/Event Loop.md": "ef7e18bdfa11924dff151a6a5557be2893e4004c9c10068ffb553f0008c36225",
+  "browser/Event Loop/Rendering Pipeline.md": "b698d9525fdb3aea1de4b3243b52c8bc411ad011ace105e9388a18ea704192d6",
+  "browser/Event Loop/index.md": "00cc102dabdebcb267cbfa6c0f10ca45571ecb015de4a2ac221857421f2e9db4",
+  "browser/Network/CORS.md": "90a34e5d48b1faad3fdb74ecb7b41fa0b78bb87af7e157c439f2c537d60632a8",
+  "browser/Network/Cookies & Storage.md": "9a49a4e936342471acae3b88e5f5f81f9c2c7c83e14be4a19dbe3acb88330d87",
+  "browser/Network/HTTP Headers & Caching.md": "84d40df2788021f2466cb63770346463df8cab99283ec7f78ed57026ee035c09",
+  "browser/Network/TCP & TLS Handshake.md": "40b29f2a89a82ff105ec0b9e581a3b0bf7b6d0b27937deebb636225c2fd8db16",
+  "browser/Network/index.md": "8562b0aabb62de7630dcf0b354e7c903792255721a1c57f519b4f1245651e483",
+  "browser/index.md": "36cb2ffc1ebf165c0ceabc5aab8c514d292f06d148fdb359ac03da0a14964313",
   "headhunter/JavaScript-easy-level.md": "07d772fee0195708ac9b6bdf41e1f0fcd2efcf15861cc34947dbce0975d26277",
   "headhunter/JavaScript-middle-level.md": "46ae57febadc70bebdc4f8116a7cf2db901c525e2b573bcfa34377be7af45ac0",
   "headhunter/index.md": "d9888f62e5b1a3e71f67b05616d51e15e1eccb67be651c33da850f48f438afd2",
@@ -90,6 +99,6 @@
   "leetcode/index.md": "88c151c7c5564227dea91e47d96076632d854dd7fc1eddfa45440093be401dc3",
   "vue/Internals/Compiler.md": "c46b3dd12912b11bc4f0a34b2abba574baff9626f42df410eab279ae77b99e90",
   "vue/Internals/Reactivity.md": "9b502f513195b4512f4d8188f1ac30746030e1c5a52a6a626d51c80c15752d24",
-  "vue/Internals/index.md": "0637645f58c346554c1687702236afa74ed3b25e795a4c0ad5038369ed0479fb",
-  "vue/index.md": "aa6244e7ef392b574ddd86f1cafeeac49e03dda7df6eb83b1767e493d1059669"
+  "vue/index.md": "aa6244e7ef392b574ddd86f1cafeeac49e03dda7df6eb83b1767e493d1059669",
+  "vue/Internals/index.md": "0637645f58c346554c1687702236afa74ed3b25e795a4c0ad5038369ed0479fb"
 }
diff --git a/content-ru/browser/Event Loop/Event Loop.md b/content-ru/browser/Event Loop/Event Loop.md
new file mode 100644
index 000000000000..91139d336c39
--- /dev/null
+++ b/content-ru/browser/Event Loop/Event Loop.md	
@@ -0,0 +1,93 @@
+# ⏱ Event Loop, микротаски, макротаски, requestAnimationFrame
+
+## 💡 Основная идея
+
+> Event Loop не выполняет код. Это диспетчер: он проверяет, пуст ли call stack, и затем перекладывает в него следующую задачу из очереди.
+
+На два вопроса отвечает эта заметка: почему `setTimeout(fn, 0)` всегда выполняется после всего синхронного кода _и_ всех промисов? И почему бесконечная цепочка `Promise.then()` намертво замораживает вкладку, а бесконечный цикл `requestAnimationFrame` — нет?
+
+---
+
+# 🧭 Участники
+
+1. **Call Stack** — выполняет синхронный JS строку за строкой. Пока он не пуст, ничего другого не выполняется.
+2. **JS-движок (V8 и т.д.)** — выполняет только call stack. У него нет встроенного понятия `setTimeout`, DOM или `fetch` — ничего из этого не входит в спецификацию ECMAScript.
+3. **Web API** (браузер) / **libuv** (Node.js) — отдельная часть рантайма, которая непосредственно считает таймеры, слушает сетевые/DOM-события и готовит кадры.
+4. **Очередь макротасков** — `setTimeout`, `setInterval`, DOM-события, I/O. FIFO; Event Loop забирает из неё **по одной задаче за раз**.
+5. **Очередь микротасков** — `Promise.then`, `queueMicrotask`, `MutationObserver`. FIFO, но Event Loop **опустошает её полностью**, прежде чем заняться чем-либо ещё.
+6. **Event Loop** — сам диспетчер: в цикле проверяет «пуст ли call stack?», забирает следующую задачу, помещает её в стек.
+
+---
+
+# 🔑 Золотое правило
+
+> После каждой синхронной задачи Event Loop **полностью опустошает** очередь микротасков — включая те, что добавляются во время самого опустошения. И только когда очередь пуста, он переходит дальше (к рендерингу или к одному-единственному макротаску).
+
+Разница не в «приоритете» — это разная стратегия опустошения: микротаски означают _«доделать всё, что накопилось, сколько бы его ни оказалось»_; макротаск означает _«взять ровно одну вещь и вернуть управление диспетчеру»_.
+
+**Одна полная итерация цикла:**
+
+```
+Call Stack (весь синхронный код)
+  → опустошить очередь микротасков ПОЛНОСТЬЮ (даже если она пополняется в процессе)
+      → колбэки requestAnimationFrame (снимок ровно этого кадра)
+          → Рендер: Layout → Paint → Composite
+              → взять ОДИН макротаск → выполнить его
+                  → снова опустошить очередь микротасков
+                      → ... повторить
+```
+
+---
+
+# 🎞 requestAnimationFrame
+
+`requestAnimationFrame(cb)` просит браузер _«выполнить это прямо перед отрисовкой следующего кадра»_. Это не таймер, и он не даёт гарантий по точным миллисекундам — он привязан к реальному циклу обновления экрана (~60/сек).
+
+Порядок выполнения с учётом rAF:
+
+```js
+Promise.resolve().then(() => console.log("promise"))
+requestAnimationFrame(() => console.log("raf"))
+setTimeout(() => console.log("timeout"), 0)
+
+// promise → raf → timeout
+```
+
+---
+
+# ❄️ Почему бесконечный Promise.then() замораживает вкладку, а бесконечный rAF — нет
+
+Это не совпадение — обе очереди работают по принципиально разной механике.
+
+**Очередь микротасков проверяется динамически.** Перед каждым шагом Event Loop спрашивает «пуста ли очередь?». Если выполняющийся сейчас микротаск ставит в очередь новый, тот присоединяется к очереди и выполняется **в этом же проходе**. Для бесконечной цепочки условие выхода («пусто») никогда не наступает:
+
+```js
+function loop() {
+  Promise.resolve().then(loop) // каждый .then() порождает следующий
+}
+loop()
+// Event Loop никогда не доходит до рендеринга, макротасков или кликов — вкладка мертва
+```
+
+**Очередь rAF для кадра — это снимок (batch), зафиксированный в начале обработки этого кадра.** Всё, что регистрируется через `requestAnimationFrame(...)` _во время_ выполнения текущего batch, физически не может попасть в этот же batch — только в следующий кадр:
+
+```js
+function animate() {
+  x++
+  requestAnimationFrame(animate) // попадёт в СЛЕДУЮЩИЙ кадр, не в этот
+}
+requestAnimationFrame(animate)
+// Рендер (Layout → Paint → Composite) гарантированно происходит между кадрами
+```
+
+Поэтому бесконечная рекурсия через rAF не блокирует браузер: рендер гарантированно вклинивается между итерациями. Ключевое отличие не в том, насколько быстро выполняется каждый из колбэков — а в том, что у очереди микротасков нет границы-снимка, а у batch'а rAF она есть.
+
+---
+
+# 🧠 Одним предложением
+
+> Условие выхода Event Loop для очереди микротасков — «пусто», а самопополняющаяся очередь никогда его не достигает. Очередь rAF, напротив, выходит по _снимку_: всё, что добавляется во время batch'а, откладывается на следующий, независимо от того, насколько быстро он выполняется.
+
+[[browser/Event Loop/index|Event Loop & Rendering]]
+[[browser/Event Loop/Rendering Pipeline|Rendering Pipeline — что происходит после опустошения очереди микротасков]]
+#browser
diff --git a/content-ru/browser/Event Loop/Rendering Pipeline.md b/content-ru/browser/Event Loop/Rendering Pipeline.md
new file mode 100644
index 000000000000..c14c89913134
--- /dev/null
+++ b/content-ru/browser/Event Loop/Rendering Pipeline.md	
@@ -0,0 +1,116 @@
+# 🖼 Rendering Pipeline: Parse → Style → Layout → Paint → Composite
+
+## 💡 Основная идея
+
+> Не каждое изменение стиля одинаково дорого. То, что триггерит CSS-свойство — Layout, Paint или просто Composite — определяет, будет ли анимация плавной или начнёт дропать кадры.
+
+---
+
+# 🧭 Полный пайплайн
+
+```
+Parse HTML → DOM
+Parse CSS  → CSSOM
+DOM + CSSOM → Render Tree (excludes display:none)
+Render Tree → Layout      (geometry: x, y, width, height)
+Layout      → Paint       (pixels: color, text, shadows)
+Paint       → Composite   (GPU assembles layers)
+```
+
+`element.style.width = '100px'` **не** триггерит layout немедленно. Браузер просто помечает элемент (и часто его поддерево) как «грязный» и откладывает пересчёт до следующей естественной точки рендера — шага, который идёт сразу после того, как опустошается очередь микротасков и отрабатывают колбэки rAF в [[browser/Event Loop/Event Loop|Event Loop]].
+
+Важное различие: **CSSOM** (распарсенные правила из `<style>`/стилшитов) и инлайновый `element.style` (объект `CSSStyleDeclaration`, привязанный к атрибуту `style` одного элемента) — это разные объекты. Запись `el.style.width = ...` никогда не трогает CSSOM — она только помечает грязным этот один элемент.
+
+---
+
+# ⚡ Что триггерит каждый этап
+
+```
+Layout:          width/height, top/left/right/bottom, margin/padding,
+                  border-width, font-size, display, adding/removing DOM nodes
+Paint:            color, background, box-shadow, border-radius, visibility, outline
+Composite-only:   transform, opacity
+```
+
+## Почему transform/opacity дешёвые
+
+Не потому что _значат_ эти свойства — а из-за того, _где_ они обрабатываются. Если у элемента уже есть свой compositor layer (GPU-текстура — от `will-change`, идущей анимации, `position: fixed`, `<video>`, `<canvas>` и т.д.), изменение `transform`/`opacity` — это просто применение матрицы трансформации или значения альфа-канала к _уже растеризованной_ текстуре, целиком на **compositor thread**. Layout и Paint вообще не запускаются.
+
+- `transform` — это не категория «свойств для анимации», это геометрические трансформации (translate/scale/rotate/skew/matrix), которые оказались дешёвыми в анимации.
+- `opacity` — это не яркость, это альфа-канал (0 = невидимо, 1 = непрозрачно).
+
+Все функции `transform` компилируются в одну каноническую форму:
+
+- `translate(x, y)` — сдвиг по осям (`translateX/Y/Z`, `translate3d`)
+- `scale(x, y)` — изменение размера (`scale(1.5)` = в 1.5 раза больше); `scaleX`/`scaleY` независимо по каждой оси
+- `rotate(angle)` — вращение вокруг точки (по умолчанию: центр элемента); `rotateX/Y/Z` для 3D
+- `skew(x-angle, y-angle)` — сдвиг/скос: превращает прямоугольник в параллелограмм
+- `matrix(a, b, c, d, e, f)` — низкоуровневая матрица 2×3 affine, в которую компилируется всё вышеперечисленное (`matrix3d` — 4×4, для 3D)
+
+---
+
+# 🧵 Main thread vs Compositor thread
+
+```
+Main thread:        JS execution → Style calc → Layout → Paint
+Compositor thread:  Composite (transform/opacity)
+```
+
+Main thread — это место, где живут [[browser/Event Loop/Event Loop|Event Loop]], call stack и весь JS — Style, Layout и Paint тоже находятся там. Если main thread заблокирован (долгий синхронный JS, forced reflow), всё замирает: скролл, клики и любая анимация на `width`/`top`.
+
+Compositor thread отдельный и не блокируется main thread'ом. К моменту выполнения Composite DOM/CSSOM уже не важны: Paint (на main thread) уже превратил элемент в растеризованную GPU-текстуру. Compositor thread видит только готовые текстуры и матрицы трансформаций — он никогда не трогает дерево DOM. Composite — это не «рисование поверх HTML/CSS-скелета», это «размещение уже готовых картинок на экране».
+
+## Как формируются compositor layers
+
+Слой — это не DOM-элемент, а область пикселей плюс правило её позиционирования. Он состоит из:
+
+- **display list** — записанных Paint команд рисования («залить этот прямоугольник», «нарисовать этот текст») для части DOM в этом слое
+- **растеризованной текстуры (bitmap)** — результата выполнения display list, обычно нарезанной на **тайлы** (например, 256×256px) для эффективной перезагрузки
+- **свойств трансформации** — матрицы (transform), opacity и позиции в системе координат compositor'а
+
+Этапы формирования:
+
+1. **Style** — вычисляются значения CSS
+2. **Layout** — вычисляется геометрия (размеры, позиции)
+3. **Построение дерева слоёв (layerization)** — main thread решает, какие элементы получают собственный compositor layer. Триггеры: анимированные `transform`/`opacity`, `will-change`, `position: fixed`, `<video>`, `<canvas>`. Всё остальное рисуется в слой родителя.
+4. **Paint** — main thread не рисует пиксели, он записывает display list для каждого слоя
+5. **Растеризация** — display list превращается в реальные пиксели, обычно через GPU (например, GPU-бэкенд Skia), часто на отдельных raster-потоках
+6. **Compositing** — compositor thread собирает готовые текстуры слоёв в финальный кадр, применяя transform/opacity каждого слоя целиком
+
+Шаги 1–4 выполняются на main thread; шаги 5–6 — на отдельных потоках. Если у элемента, который уже имеет слой, меняется только `transform`/`opacity`, шаги 1–4 полностью пропускаются — сразу к шагу 6 с существующей текстурой.
+
+Почему каждый слой рендерится в свою текстуру: её можно переиспользовать без перерисовки. Если слой уже содержит что-то дорогое (текст, тени, градиенты) и его просто перемещают (`translateX`), нет нужды заново выполнять команды рисования — GPU просто перепозиционирует готовую текстуру. Это также распараллеливает работу: разные слои растеризуются одновременно на разных потоках, и перерисовывается только тот слой, который реально изменился.
+
+---
+
+# 🐢 Forced synchronous layout
+
+Если вы записываете стиль и сразу читаете свойство, зависящее от layout (`offsetWidth`, `getBoundingClientRect()`, `clientHeight`, `scrollTop`, …), браузер обязан пересчитать геометрию **синхронно, прямо на месте**, чтобы дать точный ответ — он не может отложить это до следующей точки рендера.
+
+```js
+// bad: 1000 forced layouts, one per iteration
+items.forEach((item) => {
+  item.style.width = "100px" // write — flags the element dirty
+  console.log(item.offsetWidth) // read — forces a full recalculation NOW
+})
+
+// good: one layout for the whole batch
+items.forEach((item) => {
+  item.style.width = "100px"
+}) // all writes first
+items.forEach((item) => {
+  console.log(item.offsetWidth)
+}) // all reads — first read recomputes, the rest hit the cache
+```
+
+Почему это дорого: layout вычисляет геометрию не только для затронутого элемента — обычно для значительной затронутой части дерева (элементы влияют друг на друга через flexbox, проценты, реflow текста). Это как заново измерять 1000 стен и звать инспектора после каждой, вместо того чтобы позвать его один раз в конце.
+
+---
+
+# 🧠 Одним предложением
+
+> Изменения `width`/`top` стоят Layout + Paint на main thread; изменения `color`/`shadow` стоят только Paint; `transform`/`opacity` пропускают и то, и другое и остаются на compositor thread — это и есть вся причина предпочитать анимировать именно их.
+
+[[browser/Event Loop/index|Event Loop & Rendering]]
+[[browser/Event Loop/Event Loop|Event Loop — where render fits into the loop]]
+#browser
diff --git a/content-ru/browser/Event Loop/index.md b/content-ru/browser/Event Loop/index.md
new file mode 100644
index 000000000000..1ddcab49d6e3
--- /dev/null
+++ b/content-ru/browser/Event Loop/index.md	
@@ -0,0 +1,12 @@
+---
+title: event loop
+---
+
+# Event Loop и рендеринг
+
+[[browser/index|← Browser]]
+
+- [[browser/Event Loop/Event Loop|Event Loop, микрозадачи, макрозадачи]]
+- [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline: Layout, Paint, Composite]]
+
+#browser
diff --git a/content-ru/browser/Network/CORS.md b/content-ru/browser/Network/CORS.md
new file mode 100644
index 000000000000..55da5abe5181
--- /dev/null
+++ b/content-ru/browser/Network/CORS.md
@@ -0,0 +1,49 @@
+# 🚧 CORS
+
+## 💡 Основная идея
+
+> CORS — это механизм безопасности на стороне браузера, а не сервера — он решает, разрешено ли _фронтенд JS_ читать кросс-доменный ответ, а не может ли сам запрос быть отправлен. Это невозможно исправить со стороны клиента, если сервер не отправляет нужные заголовки.
+
+---
+
+# 🌐 Origin
+
+Origin — это тройка `scheme + host + port`. Два URL считаются одного происхождения только если совпадают все три компонента — `http://` и `https://`, или `:3000` и `:8080` на одном и том же хосте, считаются _разными_ origin.
+
+---
+
+# 🔀 Простые и preflight-запросы
+
+- **Простые запросы** (GET/HEAD/POST только с небольшим набором стандартных заголовков и типов контента) идут прямо на сервер. Ответ приходит обратно, и браузер решает _постфактум_, разрешено ли JS его читать, основываясь на `Access-Control-Allow-Origin`.
+- **Preflight-запросы** — всё, что использует не-простой метод (PUT, DELETE, PATCH) или кастомные заголовки (`Authorization`, `Content-Type: application/json` и т.д.) — сначала запускают `OPTIONS`-запрос, спрашивающий у сервера, что разрешено, _до_ отправки реального запроса. Только если preflight-ответ сервера разрешает метод/заголовки, браузер отправляет фактический запрос.
+
+---
+
+# ⚙️ Настройка на стороне сервера
+
+- Явно разрешайте нужный `Origin`, методы и заголовки — не полагайтесь на значения по умолчанию.
+- Никогда не сочетайте `Access-Control-Allow-Origin: *` с `Access-Control-Allow-Credentials: true` — спецификация это запрещает, и браузеры отклоняют такое сочетание.
+- Для API-прокси (например, Nuxt/Node backend-for-frontend), маршрутизация запросов через собственный сервер полностью убирает кросс-доменный переход между браузером и бэкендом — заголовки CORS не нужны.
+
+```ts
+app.use(
+  cors({
+    origin: ["https://app.example.com"],
+    credentials: true,
+    allowedHeaders: ["content-type", "authorization"],
+    methods: ["GET", "POST", "PATCH", "DELETE"],
+  }),
+)
+```
+
+---
+
+# 🐞 Отладка
+
+- Ошибки CORS невозможно исправить на клиенте, если сервер не отправляет нужные заголовки — обходного пути на стороне клиента не существует (кроме использования прокси).
+- Проверьте вкладку Network на предмет ответа preflight-запроса `OPTIONS` и «blocked reason» браузера.
+- Если куки не отправляются кросс-доменно, проверьте `Access-Control-Allow-Credentials` на сервере _и_ `credentials: 'include'` на клиенте — а также что `Access-Control-Allow-Origin` указывает точный origin, а не `*`.
+
+[[browser/Network/index|HTTP & Network]]
+[[browser/Network/Cookies & Storage|Cookies & Storage — SameSite и кросс-доменные куки]]
+#browser
diff --git a/content-ru/browser/Network/Cookies & Storage.md b/content-ru/browser/Network/Cookies & Storage.md
new file mode 100644
index 000000000000..7b593a147acd
--- /dev/null
+++ b/content-ru/browser/Network/Cookies & Storage.md	
@@ -0,0 +1,59 @@
+# 🍪 Cookies и клиентское хранилище
+
+## 💡 Основная идея
+
+> Все три флага безопасности cookie звучат так, будто "защищают от XSS", если читать по диагонали — но каждый из них защищает от _разных_ атак. Путать их — самая распространённая ошибка здесь.
+
+---
+
+# Cookies
+
+Небольшие пары ключ/значение, которые браузер автоматически прикрепляет к подходящим запросам через заголовок `Cookie`. Флаги — `HttpOnly`, `Secure`, `SameSite`, `Path`, `Domain`, `Max-Age` — управляют безопасностью и областью действия.
+
+## Три флага, три разные угрозы
+
+- **`HttpOnly` → XSS.** Не мешает вредоносному скрипту выполниться — мешает этому скрипту прочитать _конкретно эту cookie_ через `document.cookie`. XSS всё равно выполняется; он просто не может украсть защищённую cookie.
+- **`Secure` → перехват в сети / MITM.** Cookie никогда не отправляется по обычному HTTP, даже если пользователь случайно попал на HTTP-версию HTTPS-сайта.
+- **`SameSite` → CSRF (Cross-Site Request Forgery).** Мешает другому сайту заставить браузер прикрепить вашу cookie к запросу против вашего домена.
+  - `Strict` — cookie никогда не отправляется с межсайтовым запросом.
+  - `Lax` — отправляется только при top-level навигации (клик по ссылке), но не с форм/fetch/XHR с другого сайта.
+  - `None` — отправляется всегда, но обязательно в паре с `Secure`.
+
+Для токена сессии `HttpOnly` cookie обычно безопаснее, чем `localStorage`: `localStorage` полностью читаем любым JS на странице, включая вредоносный код, внедрённый через XSS — `HttpOnly` cookie же вообще невидима для JS.
+
+```ts
+setCookie(event, "session", sessionId, {
+  httpOnly: true,
+  secure: true,
+  sameSite: "lax",
+  path: "/",
+  maxAge: 60 * 60 * 24 * 7,
+})
+```
+
+---
+
+# cookies vs localStorage vs sessionStorage
+
+| Критерий             | `cookies`                                                                       | `localStorage`                                                                            | `sessionStorage`                                                         |
+| -------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| Время жизни          | по умолчанию до закрытия браузера; `Max-Age`/`Expires` для фиксированного срока | навсегда, пока явно не удалено                                                            | пока не закрыта вкладка (переживает перезагрузку страницы)               |
+| Видимость на сервере | отправляется автоматически с каждым HTTP-запросом (заголовок `Cookie`)          | только клиент, JS должен отправлять явно                                                  | только клиент, JS должен отправлять явно                                 |
+| Размер               | ~4 КБ                                                                           | ~5-10 МБ                                                                                  | ~5-10 МБ                                                                 |
+| API                  | `document.cookie` (сырая строка, которую нужно самому парсить)                  | `.setItem()/.getItem()/.removeItem()`                                                     | `.setItem()/.getItem()/.removeItem()`                                    |
+| Флаги безопасности   | `HttpOnly`, `Secure`, `SameSite`                                                | нет — полностью доступно из JS                                                            | нет — полностью доступно из JS                                           |
+| Использовать для     | токена сессии, который должен уходить на сервер с каждым запросом               | данных, которые должны сохраняться между визитами (настройка темы, долгоживущий черновик) | данных, привязанных к одной вкладке/сессии (черновик формы, шаг мастера) |
+
+---
+
+# За пределами cookies: другое клиентское хранилище
+
+- **`localStorage` / `sessionStorage`** — синхронные, небольшие, только строки (сериализуйте объекты через `JSON.stringify`/`parse`). Не источник истины — полностью видимы и редактируемы пользователем.
+- **IndexedDB** — асинхронное, работает с большими структурированными данными, правильный выбор, когда ограничения `localStorage` по размеру/синхронности становятся проблемой.
+- **Cache API** — работает в паре с service worker для оффлайн-кеширования и кеширования ассетов.
+
+Практические заметки: версионируйте форму хранимых данных (`settings:v2`) и обрабатывайте миграции; слушайте событие `storage` для синхронизации состояния между вкладками; учитывайте, что `window` может быть недоступен во время SSR.
+
+[[browser/Network/index|HTTP & Network]]
+[[browser/Network/CORS|CORS — credentials и кросс-доменные cookies]]
+#browser
diff --git a/content-ru/browser/Network/HTTP Headers & Caching.md b/content-ru/browser/Network/HTTP Headers & Caching.md
new file mode 100644
index 000000000000..5b22fc1465fc
--- /dev/null
+++ b/content-ru/browser/Network/HTTP Headers & Caching.md	
@@ -0,0 +1,64 @@
+```markdown
+# 📦 HTTP-заголовки и кэширование
+
+## 💡 Основная идея
+
+> Вся ценность кэширования — в том, чтобы полностью пропустить сетевую цепочку из [[browser/Network/TCP & TLS Handshake|TCP & TLS Handshake]], или хотя бы пропустить самую дорогую её часть — тело ответа.
+
+---
+
+# 🏷 Категории заголовков
+
+- **General** — не привязаны конкретно к запросу или ответу: `Date`, `Connection` (`keep-alive`), `Cache-Control` (используется в обоих).
+- **Request** — контекст запроса: `Host`, `User-Agent`, `Accept`, `Authorization`, `If-None-Match`.
+- **Response** — контекст ответа: `Server`, `Set-Cookie`, `Location`.
+- **Entity/Representation** — описывают тело независимо от направления: `Content-Type`, `Content-Length`, `Content-Encoding`, `ETag`, `Last-Modified`.
+
+Разделение не формальное — это скорее подсказка, где заголовок вообще имеет смысл (`Content-Length` бессмыслен без тела).
+
+---
+
+# 🗄 Cache-Control
+
+- `max-age=N` — сколько секунд ответ считается свежим; в течение этого окна браузер мгновенно отдаёт кэшированную копию, вообще не обращаясь к серверу.
+- `no-cache` — обманчивое название: кэшировать можно, но при каждой отдаче требуется ревалидация с сервером через условный запрос (см. ETag ниже).
+- `no-store` — кэширование запрещено полностью, в любой форме.
+- `private` / `public` — можно кэшировать только в браузере пользователя / можно кэшировать в любом месте цепочки (включая CDN/прокси).
+
+Ключевое отличие: `no-cache` = «кэшируй, но всегда ревалидируй»; `no-store` = «вообще не кэшируй».
+
+## ETag и условные запросы
+
+1. Первый ответ: `200 OK` + тело + `ETag: "abc123"` (отпечаток конкретной версии ресурса).
+2. Кэшированная копия устарела / `no-cache` — браузер отправляет `If-None-Match: "abc123"` вместо слепой повторной загрузки.
+3. Сервер сравнивает: совпадение → **`304 Not Modified`, без тела** (экономит весь трафик, который занимало бы тело ответа); нет совпадения → `200 OK` + новое тело + новый `ETag`.
+
+`If-Modified-Since`/`Last-Modified` работают по тому же принципу, но по времени, а не по хешу — грубее (точность до секунды), но не требует вычисления хеша на сервере.
+
+В ответах `304` нет ничего, кроме заголовков — ни тела, ни дополнительной структуры.
+
+## Где кэширование находится в цепочке
+
+Кэширование срабатывает **до** сети: если `max-age` ещё не истёк, соединение вообще не открывается (ни DNS, ни TCP, ни TLS). `no-cache`/`304` — частичный выигрыш: сам round trip всё равно происходит, но экономится самая дорогая часть (тело ответа).
+
+---
+
+# 🌍 Места хранения кэша и стратегии
+
+Три точки на пути запроса, каждая — потенциальный «склад» с готовой копией, от ближайшей/быстрейшей до самой дальней/медленной:
+
+1. **Кэш браузера** — копия на диске/в памяти пользователя. Сеть вообще не задействована.
+2. **CDN** — копия на сервере, географически близком к пользователю (не origin-сервер сайта). Требует сети, но путь короче. Используется только если ответ помечен `Cache-Control: public`; `private` разрешает копию только в кэше браузера, но не на CDN/общем прокси.
+3. **Origin-сервер** — место, где реально живут код и данные. Самый дальний вариант, к которому обращаются, только если копии взять больше негде.
+
+## Стратегии
+
+- **cache-first** — если что-то есть в кэше, отдать это и вообще не трогать сеть (без проверок, а не «постоянная ревалидация»). Безопасно для ресурсов, которые никогда не меняются под одним и тем же URL (хешированное имя файла — изменение порождает новое имя/URL, поэтому старая закэшированная копия никогда не может стать «неправильной»).
+- **network-first** — сначала пытаться получить свежую копию по сети; кэш — лишь запасной вариант на случай недоступности сети. Для часто меняющихся данных (лента, курс валют), где важна свежесть.
+- **stale-while-revalidate** — гибрид: сразу отдать то, что есть в кэше (даже если оно устарело), и **параллельно, в фоне** выполнить обычный сетевой запрос, чтобы обновить кэш для следующего раза. Пользователь никогда не ждёт сеть, но не всегда видит самую новую версию.
+
+[[browser/Network/index|HTTP & Network]]
+[[browser/Network/TCP & TLS Handshake|TCP & TLS Handshake — что позволяет пропустить кэширование]]
+[[browser/Network/CORS|CORS — ещё один сетевой шлюз на стороне браузера]]
+#browser
+```
diff --git a/content-ru/browser/Network/TCP & TLS Handshake.md b/content-ru/browser/Network/TCP & TLS Handshake.md
new file mode 100644
index 000000000000..27b7d2b06235
--- /dev/null
+++ b/content-ru/browser/Network/TCP & TLS Handshake.md	
@@ -0,0 +1,28 @@
+**PowerShell Tool**
+
+Result:
+
+```
+content/browser/Network/HTTP Headers & Caching.md
+content/browser/Network/TCP & TLS Handshake.md
+content/browser/Network/index.md
+```
+
+I'll translate the note and write it to the matching path in `content-ru/browser/Network/`.
+
+**Write**
+
+````
+{
+  "file_path": "/home/faust/notes/content-ru/browser/Network/TCP & TLS Handshake.md",
+  "content": "# \ud83d\udd10 TCP & TLS Handshake\n\n## \ud83d\udca1 Основная идея\n\n> Всё, что происходит до первого байта HTTP-ответа, — это цепочка рукопожатий, каждое из которых оплачивает гарантию, необходимую следующему уровню: сначала надёжный байтовый поток (TCP), затем доверенный зашифрованный канал (TLS). Понимание того, *почему* существует каждый круговой обмен пакетами, объясняет, почему HTTPS почти никогда не является узким местом на практике.\n\n---\n# \ud83e\udded Полная цепочка\n\n```\nDNS resolution (hostname → IP)\n  → TCP three-way handshake (SYN / SYN-ACK / ACK)     — 1 RTT, transport layer\n      → TLS handshake, HTTPS only                      — ~1 RTT more (TLS 1.3)\n          → HTTP request  (method + path + headers + body)\n              → HTTP response (status + headers + body)\n                  → keep-alive: connection stays open, next request reuses it\n```\n\n## Разрешение DNS\n\nМаршрутизаторы пересылают пакеты только по IP (сетевой уровень) — доменное имя это чисто человекочитаемый уровень поверх. Браузер физически не может собрать TCP SYN-пакет без числового IP в заголовке, поэтому DNS должен разрешиться раньше TCP.\n\nПорядок поиска: кэш браузера → кэш ОС/файл hosts → рекурсивный резолвер (провайдера или публичный, например 8.8.8.8) → если в кэше нет, резолвер проходит по иерархии: корневые серверы → серверы TLD (`.com`) → авторитетный nameserver домена → IP возвращается и кэшируется на срок TTL. Транспорт обычно UDP/53 (или DoH/DoT поверх HTTPS/TLS для приватности).\n\n---\n# \ud83e\udd1d TCP-рукопожатие\n\n```\nClient --- SYN (seq=x) --------------> Server\nClient <-- SYN-ACK (seq=y, ack=x+1) -- Server\nClient --- ACK (ack=y+1) -------------> Server\n```\n\n- **SYN** — клиент отправляет случайный начальный порядковый номер `seq=x`, отправную точку для нумерации каждого байта, который он будет отправлять (нужно для обнаружения потери/дублирования/переупорядочивания).\n- **SYN-ACK** — сервер подтверждает SYN клиента (`ack=x+1`) **и одновременно** отправляет свой собственный SYN (`seq=y`). Оба флага в одном пакете — это piggyback: TCP полнодуплексен (два независимых байтовых потока, каждый со своим счётчиком), и если бы сервер отправлял ACK и свой SYN отдельно, это добавило бы целый лишний круговой обмен (4 сообщения / 2 RTT вместо 3 / 1 RTT).\n- **ACK** — клиент подтверждает `seq=y` сервера (`ack=y+1`). Данные могут идти сразу после этого; клиент отправляет этот финальный ACK, не дожидаясь ответа на него, поэтому всё тройное рукопожатие укладывается в **1 RTT**, а не 3.\n\nЭто устанавливает надёжный, упорядоченный байтовый поток **до того**, как хотя бы один байт HTTP сможет пройти — цена гарантии надёжности TCP (доставка + порядок).\n\n---\n# \ud83d\udd12 TLS-рукопожатие (TLS 1.3)\n\nНадстраивается поверх уже установленного TCP-соединения, для `https://`.\n\n1. **Client Hello** — поддерживаемые наборы шифров, версия TLS, случайное число. На этом этапе ничего ещё не зашифровано.\n2. **Server Hello + сертификат** — публичный ключ сервера (внутри сертификата), цепочка подписей вплоть до CA и выбранный набор шифров.\n3. **Проверка сертификата.** Сертификат — это набор полей (публичный ключ сервера, домен, срок действия), подписанный **приватным ключом CA** — не сервера. Механика подписи: CA хэширует эти поля → шифрует хэш своим приватным ключом → прикрепляет результат как подпись. Браузер берёт *публичный* ключ CA из **хранилища доверия** (списка доверенных корневых CA, предустановленного в ОС/браузере — никогда не загружается по сети), расшифровывает подпись, чтобы получить хэш, вычисленный CA, и независимо пересчитывает хэш из тех же полей сам. Если они совпадают, значит CA подтвердил, что этот публичный ключ принадлежит этому домену. Несовпадение или сломанная цепочка → `NET::ERR_CERT_*`.\n4. **Доказательство владения приватным ключом (подпись транскрипта).** Сертификат публичен и может быть скопирован — MITM мог бы предъявить чужой валидный сертификат. Поэтому сервер отдельно подписывает **своим собственным** приватным ключом хэш *транскрипта*: полной последовательности сообщений, которыми обменялись в рамках именно этого рукопожатия. Клиент проверяет эту подпись публичным ключом сервера (из сертификата). Это замыкает цепочку доверия: CA подтвердил, что ключ принадлежит домену, а подпись транскрипта доказывает, что сторона на другом конце прямо сейчас реально владеет этим ключом — а не просто переслала копию сертификата.\n5. **Обмен ключами (ephemeral Diffie-Hellman / ECDHE).** Сам секрет сессии никогда не передаётся по сети — обе стороны обмениваются только публичными DH-значениями, и каждая независимо вычисляет один и тот же секрет. Показатели степени **эфемерны**: генерируются заново для каждого рукопожатия и немедленно уничтожаются после. Приватный ключ сертификата вообще не участвует в этом вычислении — он только подписывает (шаг 4). Отсюда и берётся **forward secrecy**: даже если приватный ключ сертификата утечёт позже, это не поможет расшифровать прошлый трафик, потому что секрет этого трафика был получен из уже уничтоженных эфемерных значений, а не из ключа сертификата. (Наблюдатель видит в трафике только публичные значения — восстановление секрета из них означает решение задачи дискретного логарифма, вычислительно неосуществимо.)\n6. **Переход на симметричное шифрование** — весь последующий трафик использует быстрый симметричный шифр (AES и т.п.) с ключом из секрета шага 5.\n\nTLS 1.3 укладывает всё рукопожатие в **1 RTT** (TLS 1.2 требовал 2).\n\n## Асимметричная криптография ≠ асимметричное шифрование\n\nАсимметричная криптография — это общий термин как минимум для трёх разных операций над парой ключей: (a) шифрование публичным ключом / расшифровка приватным — например, почта PGP; (b) подпись приватным ключом / проверка публичным — шаги 3–4 выше; (c) согласование общего секрета без шифрования чего-либо — ECDHE, шаг 5. Только (a) буквально является «асимметричным шифрованием данных», и именно это TLS 1.3 вообще не использует. Конкретное сравнение: версии до TLS 1.3 шифровали pre-master secret публичным ключом сервера — классическое асимметричное шифрование (операция a), но без forward secrecy, поскольку тот же долгоживущий приватный ключ мог расшифровать его при утечке позже. TLS 1.3 заменил это на ECDHE (операция c) специально ради forward secrecy.\n\n---\n# \u267b\ufe0f Keep-alive против возобновления сессии\n\nДва разных механизма избежать нового рукопожатия, на двух разных уровнях:\n\n- **Keep-alive** (уровень HTTP, `Connection: keep-alive`, поведение по умолчанию в HTTP/1.1) — держит **уже открытое** TCP+TLS соединение живым между запросами; следующий запрос переиспользует его вообще без нового рукопожатия. Умирает при закрытии вкладки/браузера или таймауте простоя.\n- **Возобновление сессии (session resumption)** (уровень TLS) — для **нового** соединения (старое уже закрыто: новая вкладка, визит на следующий день). При первом рукопожатии сервер выдаёт зашифрованный **билет сессии (session ticket)**. При новом соединении клиент предъявляет билет, и обе стороны выполняют сокращённое рукопожатие вместо полного. Переживает перезапуски браузера (билеты живут часы/дни).\n\n**Тест, чтобы отличить их друг от друга:** то же соединение, никогда не закрывалось → keep-alive. Новое соединение, но рукопожатие заметно быстрее полного → возобновление сессии.\n\n## TLS 1.3 0-RTT\n\nСтроится на том же билете сессии, что и возобновление, но идёт на шаг дальше: клиент отправляет зашифрованные данные приложения (например, сам HTTP-запрос) **в самом первом пакете**, вместе с Client Hello — не дожидаясь никакого ответа. Это работает, потому что билет несёт pre-shared key (PSK) из предыдущего соединения. «0» относится к количеству **дополнительных круговых обменов до того, как реальные данные смогут пойти**, а не к тому, что само рукопожатие завершается мгновенно.\n\nНа самом деле здесь три уровня, а не два:\n\n1. **Полное рукопожатие** — 1 RTT, сертификат проверяется с нуля.\n2. **Возобновление сессии без 0-RTT** — всё ещё 1 RTT, но рукопожатие сокращено через PSK; повторная проверка сертификата не нужна.\n3. **0-RTT** — данные уходят до завершения хотя бы одного кругового обмена.\n\n**Почему данные 0-RTT рискованны: повтор (replay), а не кража ключа.** MITM не может расшифровать или подделать данные 0-RTT — шифрование по-прежнему защищает конфиденциальность и целостность. Но он *может* захватить зашифрованный пакет и отправить его серверу повторно несколько раз. Обычно свежесть гарантируется свежими случайными значениями, обмен которыми происходит интерактивно за один круговой обмен; данные 0-RTT отправляются до того, как это интерактивное подтверждение существует, поэтому у сервера нет встроенного способа отличить повтор от по-настоящему нового запроса.\n\nИменно поэтому 0-RTT ограничен **идемпотентными** операциями. Идемпотентность = повтор одного и того же запроса любое число раз даёт то же самое конечное состояние (GET, PUT, DELETE — повторить один раз или десять, результат тот же). Неидемпотентные (POST, например `перевести $100`) создают новый эффект при каждом вызове — повторить 5 раз, произойдёт 5 переводов.\n\nНа практике (RFC 8470) сочетаются два уровня защиты:\n\n1. **Уровень HTTP** — запросы, пришедшие как 0-RTT, помечаются `Early-Data: 1`. Приложение проверяет метод: безопасный (GET) → обрабатывается как обычно; небезопасный (POST/PUT/DELETE) → отвечает `425 Too Early`, не выполняя его, и клиент повторяет тот же запрос после завершения полного рукопожатия.\n2. **Уровень TLS** — серверы могут поддерживать ограниченное окно анти-повтора уже виденных билетов/nonce, но это плохо масштабируется на несколько серверов за балансировщиком нагрузки — вторичная защита, а не основная.\n\n---\n# \ud83e\udde0 Почему HTTPS на практике едва ли медленнее HTTP\n\nРукопожатие оплачивается **один раз на соединение**, а не один раз на запрос. `keep-alive` держит TCP+TLS открытыми, HTTP/2 мультиплексирует множество запросов через одно соединение. Накладные расходы заметны только там, где браузер открывает **много новых соединений** к разным origin (первый визит на страницу, загруженную со сторонними доменами — каждый новый origin означает своё собственное TCP+TLS рукопожатие).\n\n[[browser/Network/index|HTTP & Network]]\n[[browser/Network/HTTP Headers & Caching|HTTP Headers & Caching]]\n#browser\n"
+}
+````
+
+Result:
+
+```
+File created successfully at: /home/faust/notes/content-ru/browser/Network/TCP & TLS Handshake.md
+```
+
+Translated and saved to `content-ru/browser/Network/TCP & TLS Handshake.md`, mirroring the English source path.
diff --git a/content-ru/browser/Network/index.md b/content-ru/browser/Network/index.md
new file mode 100644
index 000000000000..1d868ab77103
--- /dev/null
+++ b/content-ru/browser/Network/index.md
@@ -0,0 +1,14 @@
+---
+title: сеть
+---
+
+# HTTP и сеть
+
+[[browser/index|← Браузер]]
+
+- [[browser/Network/TCP & TLS Handshake|TCP & TLS Handshake]]
+- [[browser/Network/HTTP Headers & Caching|HTTP Headers & Caching]]
+- [[browser/Network/CORS|CORS]]
+- [[browser/Network/Cookies & Storage|Cookies & Storage]]
+
+#browser
diff --git a/content-ru/browser/index.md b/content-ru/browser/index.md
new file mode 100644
index 000000000000..1d88249eb869
--- /dev/null
+++ b/content-ru/browser/index.md
@@ -0,0 +1,12 @@
+# Браузер
+
+- [[browser/Event Loop/index|Event Loop и рендеринг]]
+  - [[browser/Event Loop/Event Loop|Event Loop, микрозадачи, макрозадачи]]
+  - [[browser/Event Loop/Rendering Pipeline|Конвейер рендеринга: Layout, Paint, Composite]]
+- [[browser/Network/index|HTTP и сеть]]
+  - [[browser/Network/TCP & TLS Handshake|TCP и TLS Handshake]]
+  - [[browser/Network/HTTP Headers & Caching|HTTP-заголовки и кеширование]]
+  - [[browser/Network/CORS|CORS]]
+  - [[browser/Network/Cookies & Storage|Cookies и хранилище]]
+
+#browser