Как работает интернет “под капотом”: от клика до ответа сервера

Каждый раз, когда ты открываешь сайт, нажимаешь кнопку или вызываешь fetch(), где-то в глубинах интернета начинается маленький техно-экшен.

Для тебя это выглядит просто:

fetch("https://example.com/api/users")

А под капотом в этот момент происходит целый квест: DNS ищет адрес, TCP устанавливает связь, HTTPS шифрует данные, HTTP отправляет запрос, сервер думает, база данных напрягается, а браузер ждёт ответ и делает вид, что всё под контролем.

🚀 Шаг 1. Ты нажимаешь кнопку или вызываешь fetch()

Начинается всё максимально невинно. Пользователь кликает по кнопке, фронтенд вызывает API, и приложение отправляет запрос:

const response = await fetch("https://site.ru/api/products");

Разработчик в этот момент думает: «Ну сейчас просто получим данные».

Интернет: «Просто? Сейчас будет DNS, TCP, TLS, HTTP, балансировщик, backend, база и немного боли».

🌍 Шаг 2. DNS: “А где вообще живёт этот сайт?”

Компьютеры не понимают красивые домены вроде:

google.com
kodik.app
example.com

Им нужен IP-адрес. Например:

142.250.185.14

Поэтому браузер спрашивает DNS-сервер: “Эй, куда мне идти за этим сайтом?”

DNS отвечает: “Вот IP-адрес, держи”.

DNS можно представить как телефонную книгу интернета. Только вместо имени человека — домен, а вместо номера телефона — IP-адрес.

💡 Если DNS работает медленно, сайт может начать тормозить ещё до того, как запрос вообще дошёл до сервера.

🤝 Шаг 3. TCP: “Давай сначала договоримся”

Когда IP найден, браузер не сразу кидает данные серверу в лицо. Сначала нужно установить соединение.

Для этого используется TCP — протокол, который отвечает за надёжную доставку данных.

TCP делает так называемое трёхстороннее рукопожатие:

1. Клиент: “Привет, хочу подключиться”.

2. Сервер: “Привет, можно”.

3. Клиент: “Отлично, начинаем”.

Это похоже на ситуацию, когда ты не просто врываешься в чат, а сначала проверяешь, что собеседник онлайн.

🔒 Шаг 4. TLS: “Шифруемся, пацаны”

Если сайт работает по HTTPS, а сейчас почти всё работает по HTTPS, поверх TCP добавляется TLS.

TLS нужен, чтобы данные нельзя было просто взять и прочитать по пути.

Без TLS кто-то между тобой и сервером мог бы увидеть:

• логины;

• пароли;

• токены;

• личные данные;

• запросы к API.

TLS делает так, чтобы данные летели в зашифрованном виде. Даже если кто-то их перехватит, он увидит не смысл, а кашу из байтов.

🔐 HTTPS — это не “красивая зелёная иконка”, а реальная защита данных.

📦 Шаг 5. HTTP: наконец-то сам запрос

Вот теперь начинается то, что ближе всего к разработке. Браузер отправляет HTTP-запрос.

GET /api/products HTTP/1.1
Host: site.ru
Authorization: Bearer token
Content-Type: application/json

В запросе есть:

• метод — GET, POST, PUT, DELETE;

• путь — например /api/products;

• заголовки — служебная информация;

• тело запроса — если нужно отправить данные.

Например, когда ты отправляешь форму регистрации, браузер может отправить POST-запрос:

POST /api/register HTTP/1.1
Content-Type: application/json

{
  "email": "user@mail.com",
  "password": "secret"
}

🚦 Шаг 6. Балансировщик: “К какому серверу тебя отправить?”

В маленьком проекте запрос может сразу попасть на один сервер. Но в крупных сервисах серверов много.

Поэтому перед ними часто стоит балансировщик нагрузки.

Его задача — решить, какой сервер сейчас примет запрос.

Он смотрит:

• какой сервер менее загружен;

• какой сервер доступен;

• куда лучше направить пользователя;

• не умер ли один из серверов после очередного деплоя в пятницу.

Балансировщик — это как администратор в ресторане: “Так, этот столик занят, этот перегружен, а вот туда можно посадить”.

⚙️ Шаг 7. Backend: “Так, что от меня хотят?”

Запрос доходит до backend-приложения. Тут начинается бизнес-логика.

Сервер проверяет:

• кто отправил запрос;

• есть ли права доступа;

• валидные ли данные;

• что нужно достать из базы;

• какой ответ собрать.

Например:

app.get("/api/products", async (req, res) => {
  const products = await db.products.findMany();
  res.json(products);
});

Вроде просто. Но в реальности за одной строкой может скрываться: база данных, кэш, очереди, микросервисы, внешние API и боль в логах.

🗄️ Шаг 8. База данных: “Сейчас поищу, но это не точно”

Очень часто backend идёт в базу данных. Например, чтобы получить товары, пользователя, заказы или настройки.

Если запрос простой и индексы настроены нормально — всё быстро.

Если запрос тяжёлый, индексов нет, а таблица разрослась до миллионов строк — сервер начинает грустить.

🐢 Частая причина медленных API — не сам интернет, а медленные запросы к базе.

⚡ Шаг 9. Кэш: “А может, не будем каждый раз страдать?”

Чтобы не ходить в базу за одними и теми же данными постоянно, используют кэш.

Кэш — это быстрый слой хранения популярных данных.

Например:

• профиль пользователя;

• список популярных товаров;

• настройки приложения;

• результаты тяжёлых вычислений.

Если данные есть в кэше, backend может вернуть ответ быстрее. Если нет — идёт в базу.

Это как держать часто используемые вещи на рабочем столе, а не каждый раз лезть за ними в кладовку.

📨 Шаг 10. Сервер отправляет ответ

Когда backend всё обработал, он формирует HTTP-ответ:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "products": [
    {
      "id": 1,
      "title": "Курс по JavaScript"
    }
  ]
}

В ответе есть:

• статус-код — например 200, 404, 500;

• заголовки — служебная информация;

• тело ответа — данные.

📟 Статусы HTTP: короткий словарь боли

🧩 Шаг 11. Ответ возвращается в браузер

Ответ проходит обратно через сеть, TCP следит за доставкой пакетов, браузер получает данные и отдаёт их JavaScript-коду.

const data = await response.json();
console.log(data);

После этого приложение обновляет интерфейс:

• показывает список товаров;

• рисует профиль пользователя;

• открывает страницу;

• или показывает ошибку, если что-то пошло не так.

🐌 Где обычно всё тормозит?

Когда пользователь говорит “сайт тормозит”, это не всегда значит, что виноват интернет.

Тормозить может почти любой этап:

📱 Где это можно нормально закрепить?

Если хочется не просто читать статьи, а реально прокачивать навыки, загляни в приложение Кодик.

Там можно изучать программирование через практику: решать задачи, повторять темы, постепенно разбираться в JavaScript, Python, backend, API и других важных штуках.

А ещё у Кодика есть телеграм-сообщество, где выходят полезные посты для разработчиков. Это удобный способ регулярно повторять программирование и не выпадать из темы.

💬 Итог

Интернет — это не магия и не “просто запросик”. Каждый клик запускает цепочку из десятков действий: от поиска IP-адреса до обработки данных на сервере.

И чем лучше ты понимаешь эту цепочку, тем проще тебе:

• искать баги;

• ускорять приложения;

• читать логи;

• понимать backend;

• не паниковать при ошибке 500.

Так что в следующий раз, когда напишешь fetch(), помни: ты не просто отправил запрос. Ты запустил маленькое путешествие данных через интернет.