Основы компьютерных сетей

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

Приложение → TCP/UDP → IP → Ethernet/Wi-Fi → среда передачи

• Хост — подключённое к сети устройство.
• Интерфейс — точка подключения хоста к сети.
• Пакет — блок данных сетевого уровня.
• Кадр — блок данных канального уровня.
• Шлюз — узел, через который доступна другая сеть.
• Протокол — набор правил обмена данными.

Содержание

• Модели OSI и TCP/IP
• IP-адресация
• Маски подсети и CIDR
• TCP, UDP, порты и сокеты
• DNS
• HTTP
• Маршрутизация и NAT
• Firewall
• VPN и прокси
• Инструменты
• Алгоритм диагностики
• Путь HTTPS-запроса
• Краткая памятка

Модели OSI и TCP/IP

Модель OSI

Модель помогает локализовать проблему:

Нет сигнала             → уровень 1
Не виден сосед в LAN    → уровень 2
Нет маршрута            → уровень 3
Недоступен порт         → уровень 4
Ошибка HTTP             → уровень 7

Модель TCP/IP

При инкапсуляции каждый уровень добавляет служебный заголовок:

HTTP-сообщение
└── TCP-сегмент
    └── IP-пакет
        └── Ethernet-кадр

Основные протоколы:

IP-адресация

IP-адрес идентифицирует сетевой интерфейс на сетевом уровне.

IPv4 и IPv6

IPv4 содержит 32 бита и записывается четырьмя октетами:

192.168.1.10

IPv6 содержит 128 бит:

2001:0db8:0000:0000:0000:ff00:0042:8329
2001:db8::ff00:42:8329  # сокращённая запись

Последовательность нулевых групп можно заменить на :: только один раз. IPv6 loopback — ::1.

Специальные IPv4-диапазоны

Частные адреса напрямую не маршрутизируются в публичном Интернете. Для выхода наружу обычно используется NAT.

Сервис на 127.0.0.1:8080 доступен только локально. Сервис на 0.0.0.0:8080 слушает все IPv4-интерфейсы, но доступ всё равно зависит от firewall и маршрутизации.

Маски подсети и CIDR

Маска делит IP-адрес на часть сети и часть хоста:

IP:     192.168.1.42
Маска:  255.255.255.0
CIDR:   192.168.1.42/24

/24 означает 24 бита сети и 8 бит хоста:

Сеть:       192.168.1.0
Хосты:      192.168.1.1–192.168.1.254
Broadcast:  192.168.1.255

CIDR записывает сеть через длину префикса. Число IPv4-адресов:

2^(32 − длина префикса)

* Для обычных подсетей. /31 может использоваться на соединениях «точка — точка».

Пример расчёта

Для 192.168.10.77/26 маска равна 255.255.255.192. Размер блока:

256 − 192 = 64

Границы подсетей: 0, 64, 128, 192. Адрес 77 входит в блок 64–127:

Сеть:             192.168.10.64
Первый хост:      192.168.10.65
Последний хост:   192.168.10.126
Broadcast:        192.168.10.127

Если адрес назначения находится в той же подсети, хост обращается к нему напрямую. Иначе пакет отправляется шлюзу.

TCP, UDP, порты и сокеты

TCP

TCP предоставляет надёжный упорядоченный поток байтов:

• устанавливает соединение;
• подтверждает получение;
• повторяет потерянные сегменты;
• сохраняет порядок;
• управляет потоком и перегрузкой;
• не сохраняет границы сообщений.

Трёхэтапное рукопожатие:

Клиент → Сервер: SYN
Сервер → Клиент: SYN, ACK
Клиент → Сервер: ACK

TCP используют HTTP/1.1, HTTP/2, SSH, SMTP и многие СУБД.

UDP

UDP передаёт отдельные датаграммы без предварительного соединения:

• доставка и порядок не гарантируются;
• автоматических повторов нет;
• границы датаграмм сохраняются;
• надёжность при необходимости реализует приложение.

UDP используют DNS, голос, потоковое видео, телеметрия и игры. HTTP/3 работает через QUIC поверх UDP.

UDP не всегда быстрее: результат зависит от протокола приложения, потерь и задержки.

Порты

Порт — число от 0 до 65535, направляющее трафик нужному процессу.

Порт не гарантирует протокол: приложение можно запустить на нестандартном порту.

Сокет — программная конечная точка обмена. TCP-соединение идентифицируется комбинацией:

протокол + локальный IP:порт + удалённый IP:порт
TCP 192.168.1.10:53144 → 203.0.113.20:443

DNS

DNS (Domain Name System) — распределённая система сопоставления доменных имён с данными.

Как разрешается имя

1. Приложение и ОС проверяют кэш и файл hosts.
2. Запрос отправляется рекурсивному DNS-резолверу.
3. При отсутствии ответа в кэше резолвер обращается к корневому серверу.
4. Корневой сервер указывает серверы зоны верхнего уровня, например .com.
5. Сервер .com указывает авторитетный сервер домена.
6. Авторитетный сервер возвращает запись.
7. Резолвер кэширует результат и отвечает клиенту.

Клиент → рекурсивный резолвер
             ├→ корневой сервер
             ├→ сервер зоны .com
             └→ авторитетный сервер домена

TTL задаёт срок хранения ответа в кэше. После изменения записи старое значение моет сохраняться до истечения TTL.

Обычные DNS-запросы часто используют UDP/53. TCP/53 применяется, например, для некоторых крупных ответов, повторов после усечения и передачи зон.

Linux/macOS: /etc/hosts
Windows:     C:\Windows\System32\drivers\etc\hosts

HTTP

HTTP — прикладной протокол запросов и ответов.

GET /users/42?details=true HTTP/1.1
Host: api.example.com
Accept: application/json

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

{"id":42,"name":"Анна"}

Сообщение содержит стартовую строку, заголовки, пустую строку и необязательное тело.

URL

https://api.example.com:443/users/42?details=true#profile

Фрагмент после # обычно серверу не отправляется.

Методы

GET, HEAD, OPTIONS считаются безопасными. GET, HEAD, PUT, DELETE, OPTIONS обычно идемпотентны. POST обычно не идемпотентен.

Статус-коды

HTTPS — HTTP поверх TLS. TLS обеспечивает шифрование, целостность и проверку сертификата сервера. HTTP/1.1 и HTTP/2 обычно используют TCP, HTTP/3 — QUIC поверх UDP.

Маршрутизация и NAT

Маршрутизация — выбор пути для IP-пакета. Таблица маршрутов содержит сеть назначения, шлюз, интерфейс и метрику.

192.168.1.0/24  → напрямую через eth0
10.10.0.0/16    → через 192.168.1.1
0.0.0.0/0       → через 192.168.1.254

0.0.0.0/0 — маршрут IPv4 по умолчанию, ::/0 — IPv6. Если подходят несколько маршрутов, выбирается самый конкретный — с наиболее длинным префиксом.

ip route                 # Linux
ip route get 8.8.8.8
route print              # Windows
netstat -rn              # macOS

NAT изменяет адреса и иногда порты:

До NAT:     192.168.1.10:53144 → 203.0.113.20:443
После NAT:  198.51.100.25:62001 → 203.0.113.20:443

• SNAT меняет адрес источника.
• DNAT меняет адрес назначения.
• PAT/NAPT дополнительно преобразует порты.
• Port forwarding направляет внешний порт внутреннему сервису.

198.51.100.25:8443 → 192.168.1.50:443

NAT не заменяет firewall.

Firewall

Firewall разрешает, отклоняет или отбрасывает трафик по правилам. Учитываться могут протокол, адреса, порты, интерфейс, направление и состояние соединения.

• Stateless проверяет каждый пакет отдельно.
• Stateful отслеживает соединения и распознаёт NEW, ESTABLISHED, RELATED, INVALID.
• accept — разрешить;
• drop — молча отбросить;
• reject — отклонить с ответом;
• log — записать событие.

Типовая политика сервера:

Разрешить loopback
Разрешить ESTABLISHED/RELATED
Разрешить SSH только из административной сети
Разрешить HTTP/HTTPS извне
Остальной входящий трафик запретить

При удалённой настройке важно сохранить административный доступ и способ восстановления.

VPN и прокси

VPN создаёт защищённый туннель поверх другой сети. Remote access VPN подключает отдельный хост, site-to-site соединяет сети.

• Full tunnel — весь трафик идёт через VPN.
• Split tunnel — через VPN идут только заданные сети.

VPN добавляет виртуальный интерфейс и маршруты. Он не заменяет TLS, firewall и авторизацию приложений.

Forward proxy находится со стороны клиента:

Клиент → Forward proxy → Интернет

Он может фильтровать, журналировать и кэшировать запросы.

Reverse proxy находится перед серверами:

Клиент → Reverse proxy → Backend

Он может завершать TLS, балансировать нагрузку, маршрутизировать запросы, кэшировать ответы и ограничивать частоту запросов.

Инструменты

ping

Проверяет ICMP-достижимость и RTT:

ping -c 4 example.com       # Linux/macOS
ping -n 4 example.com       # Windows

ping не проверяет конкретный порт. Отсутствие ответа не доказывает, что хост выключен: ICMP может блокироваться.

traceroute / tracert

Показывает промежуточные маршрутизаторы с помощью возрастающего TTL:

traceroute example.com      # Linux/macOS
tracert example.com         # Windows
traceroute -n example.com   # без DNS-разрешения адресов

Звёздочка не обязательно означает обрыв: узел может не отвечать на диагностику, но передавать трафик.

curl

curl https://example.com        # GET
curl -i https://example.com     # заголовки и тело
curl -I https://example.com     # только заголовки
curl -v https://example.com     # DNS, TCP, TLS, HTTP
curl -L http://example.com      # следовать redirect

curl https://api.example.com/users \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{"name":"Анна"}'

-k отключает проверку TLS-сертификата; использовать только для ограниченной диагностики.

ss / netstat

sudo ss -ltnp       # слушающие TCP-порты и процессы
sudo ss -lntup      # TCP и UDP
ss -tan             # TCP-соединения

netstat -ano        # Windows: соединения и PID

Состояния TCP: LISTEN, SYN-SENT, ESTABLISHED, CLOSE-WAIT, TIME-WAIT. Рост CLOSE-WAIT может означать, что приложение не закрывает сокеты.

dig / nslookup

dig example.com
dig +short example.com
dig example.com MX
dig @1.1.1.1 example.com
dig -x 8.8.8.8
nslookup example.com

В dig важны status, ANSWER SECTION, SERVER, TTL и Query time.

Алгоритм диагностики

ip address                    # интерфейс и IP
ip route                      # маршруты и шлюз
ping <шлюз>                   # локальная сеть
ping 8.8.8.8                  # внешняя IP-доступность
dig example.com               # DNS
traceroute example.com        # путь
nc -vz example.com 443        # TCP-порт
curl -v https://example.com   # TLS и HTTP
ss -ltnp                      # локальный сервис

Типичные направления поиска:

Имя не разрешается       → DNS
Connection timed out     → маршрут, firewall, потери, недоступный узел
Connection refused       → порт не слушается или отклонён
TLS certificate error    → имя, срок, цепочка сертификата, доверие
HTTP 401/403             → аутентификация или права
HTTP 404                 → путь или ресурс
HTTP 500                 → приложение/сервер
HTTP 502/504             → reverse proxy или upstream

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

Путь HTTPS-запроса

1. Клиент разбирает URL.
2. DNS возвращает IP-адрес.
3. ОС выбирает маршрут.
4. Для удалённой сети пакет отправляется шлюзу.
5. В IPv4 LAN ARP определяет MAC-адрес шлюза.
6. Устанавливается TCP-соединение с портом 443.
7. Выполняется TLS-рукопожатие.
8. Отправляется HTTP-запрос.
9. Сервер или reverse proxy возвращает ответ.

Для HTTP/3 используется QUIC поверх UDP.

Краткая памятка

IP          → адресация между сетями
CIDR        → длина сетевого префикса
ICMP        → диагностика и сетевые сообщения
TCP         → надёжный поток байтов
UDP         → датаграммы без гарантии доставки
Порт        → идентификатор процесса
Сокет       → программная конечная точка
DNS         → доменное имя в записи, включая IP
HTTP        → запрос и ответ приложения
TLS/HTTPS   → защищённый HTTP-канал
Маршрут     → правило выбора следующего узла
NAT         → преобразование адресов и портов
Firewall    → фильтрация трафика
VPN         → защищённый туннель
Proxy       → посредник между клиентом и сервером

Главный принцип диагностики:

Адрес → маршрут → DNS → порт → TLS → HTTP → приложение