HTTP и DNS — как устроен интернет

1. Как работает интернет

Интернет — это не одна сеть, а миллионы компьютеров, соединённых друг с другом. Когда вы открываете сайт, браузер отправляет запрос, который прыгает по цепочке маршрутизаторов, пока не доберётся до сервера с нужным сайтом. Ответ возвращается по той же схеме.

# упрощённый путь запроса
Ваш браузер → ваш роутер → провайдер →
городской узел → сервер сайта
→ ответ возвращается обратно тем же маршрутом

2. IP-адреса и порты

Каждое устройство в сети получает IP-адрес — уникальный номер, по которому к нему можно обратиться. Сейчас сосуществуют два стандарта:

• IPv4 — четыре числа от 0 до 255: 192.168.0.1;
• IPv6 — длинный адрес из шестнадцатеричных групп: 2001:db8::ff00:42.

На одной машине может жить сотня сайтов, и различает их порт — служебное число. Стандартный порт для HTTP — 80, для HTTPS — 443.

# адрес глазами сети
http://    192.168.0.10   :8080   /index.html
   ↑          ↑           ↑         ↑
 протокол   IP-адрес     порт     путь

3. DNS — «телефонная книга» интернета

Запоминать IP-адреса неудобно, поэтому придумали доменные имена. За превращение имени site.ru в адрес 77.88.55.77 отвечает DNS (Domain Name System) — распределённая база данных записей.

# что происходит при вводе site.ru
1. Браузер спрашивает DNS: «какой IP у site.ru?»
2. DNS отвечает: 77.88.55.77
3. Браузер идёт по адресу и отправляет HTTP-запрос
4. Ответ кешируется на несколько секунд или минут

# проверить вручную (Linux/macOS)
dig site.ru
nslookup site.ru

4. URL — анатомия адреса

URL (Uniform Resource Locator) — полный адрес ресурса. Он состоит из нескольких частей, и каждая влияет на то, куда и с чем уйдёт запрос:

https://example.com:443/products?page=2&sort=price#top
   ↑        ↑          ↑     ↑        ↑            ↑
 протокол  домен     порт   путь  query-строка   якорь

• Протокол — как общаться: http://, https://;
• Хост — имя сервера: example.com;
• Путь — страница или ресурс: /products;
• Query-строка — параметры после ?, разделяются символом &;
• Якорь — место внутри страницы, на сервер не передаётся.

5. HTTP-запрос и ответ

Всё общение браузера с сервером — это обмен текстовыми сообщениями по протоколу HTTP. Запрос состоит из стартовой строки, заголовков и (иногда) тела. Ответ — из статус-кода, заголовков и тела.

// запрос
GET /products HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html

// ответ
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 523

<!DOCTYPE html>
<html>...</html>

6. Методы HTTP

Один и тот же ресурс может означать разные операции в зависимости от метода запроса. Самые частые методы:

# самодостаточные примеры через curl
curl -X GET  https://example.com/products
curl -X POST -d '{"title":"Телефон"}' https://example.com/products
curl -X PUT  -d '{}' https://example.com/products/7

7. Коды статусов

Первая строка ответа содержит трёхзначный код. По нему клиент понимает, что произошло, ещё до чтения тела:

2xx — успех
  200 OK                 # всё хорошо
  201 Created            # создано (после POST)
  204 No Content         # успех без тела

3xx — перенаправления
  301 Moved Permanently  # переехало навсегда
  302 Found              # временный редирект

4xx — ошибка клиента
  400 Bad Request        # запрос некорректен
  401 Unauthorized       # нужна авторизация
  403 Forbidden          # нет прав
  404 Not Found          # нет такого адреса

5xx — ошибка сервера
  500 Internal Server Error  # упал сервер
  503 Service Unavailable    # временно недоступен

8. Заголовки

Заголовки — это служебные пары «имя: значение», которые передают метаданные: тип данных, правила кеширования, сведения об авторизации.

// заголовки запроса
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/json
Authorization: Bearer eyJhbGciOi…

// заголовки ответа
Content-Type: text/html; charset=utf-8
Cache-Control: max-age=3600
Set-Cookie: session=abc123; Path=/; HttpOnly

9. Cookies и сессии

HTTP сам по себе не помнит пользователя. Чтобы «запомнить», что вы вошли, сервер отправляет cookie — маленькую запись, которую браузер сохраняет и возвращает при каждом следующем запросе.

// сервер выдаёт cookie при входе
HTTP/1.1 200 OK
Set-Cookie: session=eyJ1c2VyIjoxfQ; HttpOnly; SameSite=Lax

// браузер возвращает её в следующих запросах
GET /account HTTP/1.1
Cookie: session=eyJ1c2VyIjoxfQ

• Session cookie живёт до закрытия браузера;
• Persistent cookie имеет срок из параметра Expires;
• HttpOnly запрещает скриптам читать cookie — защита от кражи через XSS.

10. HTTPS и TLS — почему «замочек» важен

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

# как клиент и сервер договариваются
1. Клиент: «я хочу защищённое соединение»
2. Сервер: «вот мой сертификат (открытый ключ + подпись)»
3. Клиент проверяет сертификат у центра сертификации
4. Стороны обмениваются ключами и дальше всё шифруется

11. HTTP/2, HTTP/3 и DevTools Network

Протокол эволюционирует: HTTP/2 грузит много ресурсов параллельно по одному соединению, HTTP/3 работает поверх быстрого транспорта QUIC. Для разработчика это в основном прозрачно, но страницы становятся быстрее, а в DevTools хорошо видно, где тратилось время.

// открыть: F12 → вкладка Network → Ctrl+R
// что смотреть
Name       — какой файл загружался
Status     — код ответа (200/304/404…)
Size       — объём переданного
Time       — сколько ждали
Водопад    — фазы: ожидание, DNS, соединение, ответ

12. Кеширование и ETag

Кеширование избавляет сервер от повторной работы: браузер хранит копию ответа и не ходит за ней, пока кэш свеж. Управляется это заголовками Cache-Control, ETag и Last-Modified.

// сервер разрешает кэшировать ответ на час
Cache-Control: max-age=3600

// браузер спрашивает: ресурс изменился?
GET /app.js HTTP/1.1
If-None-Match: "abc123"

// сервер: не изменился — 304 без тела
HTTP/1.1 304 Not Modified

13. CORS: кросс-доменные запросы

Браузер запрещает странице напрямую обращаться к API другого домена. Этот механизм называется Same-Origin Policy, а исключения для конкретных доменов настраиваются заголовками CORS (Cross-Origin Resource Sharing).

// сервер API разрешает фронтенд-домену читать ответ
Access-Control-Allow-Origin: https://front.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS

• сложные запросы идут с предварительным OPTIONS — preflight;
• без корректного CORS фронтенд не сможет прочитать ответ скриптом;
• звездочка * разрешает всем — годится для публичных API без cookies.

14. Схемы авторизации в HTTP

Разные API по-разному узнают «кто вы». Простейшая схема — Basic (логин и пароль в заголовке), распространённая среди API — Bearer-токен (JWT), а классический веб чаще опирается на session-cookie из раздела 9.

// Basic: base64(логин:пароль)
Authorization: Basic dXNlcjpwYXNz

// Bearer: токен, полученный на POST /login
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

// cookie-сессия: браузер отправляет сам
Cookie: session=abc123

15. WebSockets: постоянные соединения

HTTP подходит для сценария «спросил — получил», но чатам и биржевым котировкам нужен постоянный канал. Протокол WebSocket открывает его: сервер сам отправляет данные, не дожидаясь запроса.

const ws = new WebSocket("wss://chat.example.com");
ws.onmessage = (e) => console.log("новое:", e.data);
ws.send("привет");

• рукопожатие начинается как HTTP с заголовком Upgrade;
• wss:// — шифрованный аналог https://;
• REST остаётся для запрос-ответа, WebSocket — для push-уведомлений.

16. Диагностика трафика: DevTools и curl

Когда запрос «не работает», первый инструмент — вкладка Network в DevTools: статус, тайминги, куки, заголовки запроса и ответа каждого ресурса.

# быстрый взгляд на статус из терминала
curl -I https://example.com
curl -v https://example.com   # весь диалог

Тайминги делятся на Waiting (TTFB) — время до первого байта, и Download — передача тела. Медленный TTFB — проблема сервера, медленный Download — сети/контента.

17. Изменяемые клиентом данные и методы в реальности

Методы редко используются «в чистом виде». Ключевые нюансы, которые ловят на практике:

• GET кешируется и не должен менять состояние — это принцип, а не правило;
• PUT — полная замена ресурса, повтор безопасен (идемпотентен);
• POST — создание, повтор может удвоить запись;
• PATCH — частичное обновление, не гарантирует идемпотентность.

# повторный PUT безопасен: файл тот же
PUT /users/42  {"name":"Иван"}

18. Заголовки безопасности: HSTS, CSP, X-Frame-Options

Сервер может принудительно укрепить браузер заголовками — это почти бесплатная защита. Ключевые:

Strict-Transport-Security: max-age=31536000
Content-Security-Policy: default-src 'self'
X-Frame-Options: DENY
X-Content-Type-Options: nosniff

19. HTTP/2 и HTTP/3: мультиплексирование и QUIC

Современные протоколы убирают главные задержки HTTP/1.1: параллельные запросы и повторные подключения.

# проверка версии протокола
curl -sI https://example.com | grep -i http2
# h2  → HTTP/2, h3 → HTTP/3

HTTP/2 мультиплексирует потоки по одному соединению и сжимает заголовки (HPACK). HTTP/3 работает поверх UDP (QUIC), что обходит блокировки TCP и ускоряет переключение сетей.

• spriting CSS спрайты и конкатенация файлов стали не нужны при HTTP/2;
• server push почти не используется — предпочтите preload;
• nginx/Apache легко включают HTTP/2 флагом listen ... http2.

20. Загрузка файлов: multipart/form-data

Передать файл по HTTP нельзя одним текстовым телом: нужен составной формат, в котором бинарные части идут отдельными блоками со своими заголовками — это multipart/form-data.

curl -F "photo=@cat.png" -F "caption=Мой кот" \
  https://api.example.com/upload

--boundary123
Content-Disposition: form-data; name="photo"; filename="cat.png"
Content-Type: image/png
...бинарные байты файла...
--boundary123--

• application/x-www-form-urlencoded — простые текстовые поля, но не файлы;
• multipart каждую часть оборачивает в Content-Disposition с именем поля;
• крупные файлы часто передаются фрагментами через Transfer-Encoding: chunked.

21. Server-Sent Events и long-polling: сервер вещает

Не всё общение требует полного дуплекса. Для лент новостей, курсов валют и статусов задач подходят односторонние потоки — сервер толкает данные, клиент просто слушает.

// сервер отправляет поток
Content-Type: text/event-stream
data: {"price": 92.4}
id: 3
retry: 5000

// клиент
const es = new EventSource('/prices');
es.onmessage = (e) => render(JSON.parse(e.data));

• long-polling — клиент держит запрос открытым, сервер отвечает по событию;
• SSE — одно постоянное HTTP-соединение с встроенными retry и id;
• WebSocket — когда нужна двусторонняя реальная связь (чат, игры).

22. Прокси и балансировка: X-Forwarded-заголовки

Между клиентом и приложением почти всегда стоят прокси: CDN, балансировщик, Nginx-фронт. Приложение видит их IP, а не клиента — если не передать нужные заголовки.

# Nginx: проброс реальных данных клиента
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

• X-Forwarded-For — цепочка IP; используйте её только от доверенного прокси;
• X-Forwarded-Proto — был ли запрос HTTPS по всему пути;
• без них приложение теряет реальный IP клиента — страдает гео и rate limiting.

23. Сжатие и range-запросы: доставка больших файлов

Тяжёлые видео и архивы требуют двух техник: сжатия текста на лету (gzip/brotli) и частичной отдачи через range-запросы, чтобы докачка не качала файл заново.

Accept-Encoding: gzip, br          # клиент
Content-Encoding: gzip             # ответ сервера

Range: bytes=0-1023                # часть файла
Content-Range: bytes 0-1023/1048576

• brotli сжимает HTML/CSS/JS эффективнее gzip (в Nginx — ngx_brotli);
• видео и PDF: браузер сам запрашивает диапазоны байтов при просмотре;
• докачка в curl -C - продолжает прерванное скачивание с того же места.

Что дальше

Теперь, когда ясна схема «запрос → ответ», открой DevTools и разбери загрузку любого сайта. Дальше изучи REST API — как современные бэкенды договариваются о данных, узнай, как вывести сайт в интернет, в уроке Хостинг и деплой, а почему сайт должен быть ещё и быстрым — в SEO и Chrome DevTools.

← Вернуться к курсам