Лекция 5. Транспортный и прикладной уровень

1. Транспортный уровень: задачи и функции

Транспортный уровень (Layer 4 модели OSI, Transport layer в TCP/IP) обеспечивает передачу данных между приложениями на разных узлах сети. Если сетевой уровень (IP) отвечает за доставку пакетов между хостами, то транспортный уровень решает задачу доставки данных конкретному процессу на хосте.

1.1. Ключевые задачи транспортного уровня

Задача	Описание
Мультиплексирование	Несколько приложений на одном хосте одновременно используют сеть. Транспортный уровень добавляет номер порта отправителя, чтобы различать потоки данных
Демультиплексирование	На принимающей стороне транспортный уровень по номеру порта назначения определяет, какому приложению передать полученные данные
Надёжная доставка	Обнаружение потерь, повторная передача, контроль целостности (реализовано в TCP; отсутствует в UDP)
Контроль потока	Предотвращение переполнения буфера получателя — отправитель не должен передавать данные быстрее, чем получатель способен их обработать
Контроль перегрузки	Регулировка скорости передачи для предотвращения перегрузки в промежуточных узлах сети

1.2. Мультиплексирование и демультиплексирование

Каждое сетевое приложение привязывается к определённому порту — числовому идентификатору (0–65535). При отправке данных транспортный уровень инкапсулирует данные приложения в сегмент (TCP) или дейтаграмму (UDP), добавляя порт источника и порт назначения.

Приложение A (порт 12345)  ──┐
                               ├──▶  Транспортный уровень  ──▶  Сеть
Приложение B (порт 54321)  ──┘       (мультиплексирование)

Сеть  ──▶  Транспортный уровень  ──┬──▶  Приложение A (порт 12345)
           (демультиплексирование) └──▶  Приложение B (порт 54321)

Таким образом, сокет — это комбинация IP-адреса и номера порта, однозначно идентифицирующая конечную точку соединения.

2. TCP (Transmission Control Protocol)

TCP — это протокол транспортного уровня, обеспечивающий надёжную, упорядоченную, ориентированную на соединение передачу потока байтов между двумя приложениями.

2.1. Основные характеристики TCP

Ориентирован на соединение — перед передачей данных устанавливается логическое соединение (трёхстороннее рукопожатие).
Надёжность — гарантия доставки данных: подтверждения (ACK), повторные передачи, контрольные суммы.
Упорядоченность — данные доставляются в том порядке, в котором были отправлены.
Полнодуплексная связь — одновременная передача данных в обоих направлениях.
Потоковая передача — TCP рассматривает данные как непрерывный поток байтов, а не набор отдельных сообщений.

2.2. Формат сегмента TCP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data  |       |U|A|P|R|S|F|                                   |
| Offset| Rsrvd |R|C|S|S|Y|I|            Window Size            |
|       |       |G|K|H|T|N|N|                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (variable)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Data ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле	Размер	Описание
Source Port	16 бит	Порт отправителя
Destination Port	16 бит	Порт получателя
Sequence Number	32 бита	Порядковый номер первого байта данных в сегменте
Acknowledgment Number	32 бита	Номер следующего ожидаемого байта от другой стороны
Data Offset	4 бита	Длина заголовка (в 32-битных словах)
Flags	6 бит	Управляющие флаги: URG, ACK, PSH, RST, SYN, FIN
Window Size	16 бит	Размер окна приёма (для контроля потока)
Checksum	16 бит	Контрольная сумма для проверки целостности

2.3. Трёхстороннее рукопожатие (Three-Way Handshake)

Перед обменом данными TCP устанавливает соединение с помощью трёх сообщений:

    Клиент                                  Сервер
       |                                       |
       |  ──── SYN (seq=x) ──────────────▶     |  1. Клиент отправляет SYN
       |                                       |
       |  ◀──── SYN-ACK (seq=y, ack=x+1) ──   |  2. Сервер отвечает SYN-ACK
       |                                       |
       |  ──── ACK (ack=y+1) ─────────────▶    |  3. Клиент подтверждает ACK
       |                                       |
       |  ◀════════ Данные ════════════════▶    |  Соединение установлено

Шаги:

SYN — клиент отправляет сегмент с флагом SYN и начальным порядковым номером x.
SYN-ACK — сервер отвечает сегментом с флагами SYN и ACK, своим начальным номером y и подтверждением ack = x + 1.
ACK — клиент отправляет подтверждение ack = y + 1. Соединение установлено, можно передавать данные.

Начальные порядковые номера (ISN) выбираются случайным образом для защиты от атак подмены.

2.4. Контроль потока (Flow Control) — Sliding Window

TCP использует механизм скользящего окна (sliding window) для управления скоростью передачи. Получатель сообщает отправителю размер своего свободного буфера через поле Window Size.

Данные:  [1][2][3][4][5][6][7][8][9][10]...
          ▲           ▲
     отправлено     граница окна
     и подтверждено  (window = 4)

  [отправлено и ACK] [можно отправлять] [нельзя отправлять]
  ◄────────────────► ◄───────────────► ◄──────────────────►

Отправитель может передавать данные только в пределах текущего окна.
По мере получения ACK окно «сдвигается» вперёд.
Если получатель перегружен, он уменьшает Window Size (вплоть до 0 — «нулевое окно»).

2.5. Контроль перегрузки (Congestion Control)

Контроль перегрузки предотвращает коллапс сети, когда множество отправителей одновременно заполняют промежуточные маршрутизаторы. TCP использует переменную congestion window (cwnd), ограничивающую объём неподтверждённых данных.

Основные фазы:

Фаза	Механизм	Описание
Slow Start	Экспоненциальный рост cwnd	Начинается с cwnd = 1 MSS. При каждом ACK cwnd удваивается. Быстрый набор скорости до первой потери
Congestion Avoidance	Линейный рост cwnd	После достижения порога (ssthresh) cwnd увеличивается на 1 MSS за каждый RTT. Плавный рост
Fast Retransmit	3 дублирующих ACK	При получении трёх одинаковых ACK — немедленная повторная передача без ожидания таймаута
Fast Recovery	Частичное снижение cwnd	После fast retransmit: ssthresh = cwnd / 2, cwnd = ssthresh + 3, продолжение в режиме congestion avoidance

2.6. Завершение соединения (Four-Way Handshake)

    Клиент                                  Сервер
       |                                       |
       |  ──── FIN ───────────────────────▶     |  1. Клиент инициирует закрытие
       |                                       |
       |  ◀──── ACK ──────────────────────     |  2. Сервер подтверждает
       |                                       |
       |  ◀──── FIN ──────────────────────     |  3. Сервер закрывает свою сторону
       |                                       |
       |  ──── ACK ───────────────────────▶     |  4. Клиент подтверждает
       |                                       |

После отправки финального ACK клиент переходит в состояние TIME_WAIT (обычно 2 × MSL ≈ 60 секунд), чтобы гарантировать, что последний ACK дошёл до сервера.

3. UDP (User Datagram Protocol)

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

3.1. Основные характеристики UDP

Без соединения — нет рукопожатия, данные отправляются немедленно.
Без гарантий доставки — дейтаграммы могут теряться, дублироваться, приходить не по порядку.
Без контроля потока и перегрузки — отправитель передаёт данные с любой скоростью.
Минимальные накладные расходы — заголовок всего 8 байт (против минимум 20 байт у TCP).
Сохранение границ сообщений — каждая дейтаграмма — отдельное сообщение.

3.2. Формат дейтаграммы UDP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Data ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле	Размер	Описание
Source Port	16 бит	Порт отправителя (необязателен, может быть 0)
Destination Port	16 бит	Порт получателя
Length	16 бит	Длина дейтаграммы (заголовок + данные), минимум 8 байт
Checksum	16 бит	Контрольная сумма (необязательна в IPv4, обязательна в IPv6)

3.3. Области применения UDP

DNS — запросы и ответы обычно укладываются в одну дейтаграмму; скорость важнее надёжности (при потере — повторный запрос).
VoIP и видеозвонки — задержка критичнее потери отдельных пакетов; повторная передача бессмысленна.
Стриминг видео/аудио — потеря одного кадра менее заметна, чем задержка из-за повторной передачи.
Онлайн-игры — минимальная задержка критически важна для игрового процесса.
DHCP, SNMP, NTP — простые протоколы запрос-ответ, где достаточно UDP.

3.4. Почему иногда UDP лучше TCP

Низкая задержка — нет рукопожатия, нет ожидания ACK.
Приложение само управляет надёжностью — протокол прикладного уровня может реализовать только нужные механизмы (например, QUIC поверх UDP).
Multicast и broadcast — TCP не поддерживает многоадресную рассылку, UDP — поддерживает.
Простота реализации — для IoT-устройств с ограниченными ресурсами UDP — оптимальный выбор.

4. Сравнение TCP и UDP

Характеристика	TCP	UDP
Соединение	Да (трёхстороннее рукопожатие)	Нет
Надёжность	Гарантированная доставка (ACK, повторная передача)	Нет гарантий
Порядок доставки	Гарантирован	Не гарантирован
Контроль потока	Да (sliding window)	Нет
Контроль перегрузки	Да (slow start, congestion avoidance)	Нет
Размер заголовка	20–60 байт	8 байт
Скорость	Ниже (из-за overhead)	Выше
Тип передачи	Потоковая (stream)	Дейтаграммная (message)
Применение	HTTP, HTTPS, FTP, SSH, SMTP, базы данных	DNS, VoIP, стриминг, игры, DHCP, NTP

Практическое правило: если важны целостность и порядок данных — TCP; если важна скорость и допустима частичная потеря — UDP.

5. Порты

5.1. Понятие порта

Порт — 16-битное число (0–65535), идентифицирующее конкретное приложение или службу на хосте. Порт совместно с IP-адресом образует сокет — уникальный адрес конечной точки соединения.

Сокет = IP-адрес : Номер порта
Пример: 192.168.1.10:443

5.2. Диапазоны портов

Диапазон	Название	Описание
0–1023	Well-known (системные)	Зарезервированы за стандартными службами. Требуют привилегий root/администратора для привязки
1024–49151	Registered (зарегистрированные)	Регистрируются в IANA для конкретных приложений и служб
49152–65535	Dynamic / Ephemeral (динамические)	Назначаются ОС автоматически клиентским приложениям для исходящих соединений

5.3. Примеры well-known портов

Порт	Протокол	Служба
20, 21	TCP	FTP (данные / управление)
22	TCP	SSH
23	TCP	Telnet
25	TCP	SMTP (отправка почты)
53	TCP/UDP	DNS
80	TCP	HTTP
110	TCP	POP3
143	TCP	IMAP
443	TCP	HTTPS
3306	TCP	MySQL
5432	TCP	PostgreSQL
6379	TCP	Redis

Проверить, какие порты слушаются на Linux-системе:

# Показать все прослушиваемые порты
ss -tlnp

# Или с помощью netstat
netstat -tlnp

6. DNS (Domain Name System)

6.1. Назначение DNS

Людям удобно запоминать доменные имена (google.com), а компьютерам нужны IP-адреса (142.250.74.206). DNS — это распределённая иерархическая система, преобразующая доменные имена в IP-адреса и обратно.

DNS можно представить как глобальную «телефонную книгу» интернета.

6.2. Иерархия DNS

                        . (root)
                       / | \
                    com  org  ru   ← TLD (Top-Level Domain)
                   / |        |
              google  github  yandex  ← SLD (Second-Level Domain)
              /    \
           www    mail               ← поддомены

Уровни серверов:

Root-серверы (13 кластеров, обозначаются A–M) — знают, где находятся TLD-серверы.
TLD-серверы (для .com, .org, .ru и т.д.) — знают авторитативные серверы для доменов второго уровня.
Авторитативные серверы — содержат фактические DNS-записи для конкретного домена.

6.3. Типы DNS-записей

Тип	Назначение	Пример
A	Сопоставление имени с IPv4-адресом	`example.com → 93.184.216.34`
AAAA	Сопоставление имени с IPv6-адресом	`example.com → 2606:2800:220:1:...`
CNAME	Псевдоним (alias) — указывает на другое доменное имя	`www.example.com → example.com`
MX	Почтовый сервер для домена (с приоритетом)	`example.com → mail.example.com (prio 10)`
NS	Авторитативные DNS-серверы для домена	`example.com → ns1.example.com`
TXT	Произвольная текстовая информация (SPF, DKIM, верификация)	`example.com → "v=spf1 include:_spf.google.com ~all"`
SOA	Start of Authority — основная информация о зоне (серийный номер, TTL, контакт)	Содержит параметры зоны

6.4. Процесс резолвинга

Рекурсивный запрос — клиент просит DNS-резолвер (обычно DNS-сервер провайдера или публичный, например, 8.8.8.8) полностью разрешить имя. Резолвер самостоятельно обходит иерархию DNS.

Итеративный запрос — сервер отвечает ссылкой на следующий сервер в иерархии, а клиент (или рекурсивный резолвер) обращается к нему сам.

Браузер ──▶ Резолвер ──▶ Root-сервер ──▶ "Обратись к .com"
                    ──▶ TLD-сервер (.com) ──▶ "Обратись к ns1.example.com"
                    ──▶ Авторитативный (ns1.example.com) ──▶ "93.184.216.34"
            ◀────── Ответ: 93.184.216.34
◀────── Ответ: 93.184.216.34

6.5. Кэширование и TTL

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

Локальный кэш ОС (/etc/hosts, systemd-resolved, dnsmasq).
Кэш рекурсивного резолвера.
Кэш браузера.

# Просмотр DNS-записей
dig example.com A
nslookup example.com

# Просмотр TTL
dig +nocmd +noall +answer example.com

7. HTTP/HTTPS

7.1. Протокол HTTP

HTTP (HyperText Transfer Protocol) — протокол прикладного уровня для передачи гипертекстовых документов (и не только). Работает по модели запрос-ответ (клиент-сервер) поверх TCP (порт 80).

7.2. Структура HTTP-запроса

GET /api/users?page=1 HTTP/1.1       ← стартовая строка (метод, URI, версия)
Host: example.com                     ← заголовки
Accept: application/json
Authorization: Bearer <token>
User-Agent: Mozilla/5.0
                                      ← пустая строка
                                      ← тело (для POST/PUT)

7.3. Структура HTTP-ответа

HTTP/1.1 200 OK                       ← строка статуса (версия, код, описание)
Content-Type: application/json        ← заголовки
Content-Length: 256
Cache-Control: max-age=3600
                                      ← пустая строка
{"users": [...]}                      ← тело ответа

7.4. Основные HTTP-методы

Метод	Назначение	Идемпотентность	Тело запроса
GET	Получение ресурса	Да	Нет
POST	Создание ресурса	Нет	Да
PUT	Полная замена ресурса	Да	Да
PATCH	Частичное обновление ресурса	Нет	Да
DELETE	Удаление ресурса	Да	Нет (обычно)
HEAD	Получение только заголовков (без тела)	Да	Нет
OPTIONS	Запрос поддерживаемых методов (CORS preflight)	Да	Нет

7.5. Коды ответов HTTP

Класс	Диапазон	Описание	Примеры
1xx	100–199	Информационные	100 Continue, 101 Switching Protocols
2xx	200–299	Успех	200 OK, 201 Created, 204 No Content
3xx	300–399	Перенаправление	301 Moved Permanently, 302 Found, 304 Not Modified
4xx	400–499	Ошибка клиента	400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
5xx	500–599	Ошибка сервера	500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

7.6. HTTPS = HTTP + TLS

HTTPS — это HTTP, защищённый протоколом TLS (Transport Layer Security). Работает на порту 443.

Что обеспечивает TLS:

Конфиденциальность — данные шифруются (симметричное шифрование после установления соединения).
Целостность — данные не могут быть незаметно изменены (MAC — Message Authentication Code).
Аутентификация — сервер подтверждает свою личность с помощью сертификата.

Упрощённый процесс TLS-рукопожатия:

Клиент отправляет ClientHello (поддерживаемые версии TLS, шифры).
Сервер отвечает ServerHello (выбранный шифр) и отправляет свой сертификат.
Клиент проверяет сертификат (подписан доверенным CA — Certificate Authority?).
Стороны обмениваются ключами (Diffie-Hellman или RSA) и вырабатывают сессионный ключ.
Все последующие данные шифруются сессионным ключом (симметричное шифрование — AES и т.д.).

8. SSH (Secure Shell)

8.1. Назначение SSH

SSH — протокол для безопасного удалённого доступа к серверам и передачи данных по зашифрованному каналу. Работает на порту 22 (TCP).

SSH заменил небезопасные протоколы Telnet и rlogin, в которых данные (включая пароли) передавались в открытом виде.

8.2. Принцип работы

Клиент подключается к SSH-серверу (sshd).
Устанавливается зашифрованное соединение (обмен ключами, выбор алгоритмов).
Происходит аутентификация пользователя.
После аутентификации открывается безопасный канал для передачи команд и данных.

8.3. Аутентификация по паролю vs по ключу

По паролю:

Пользователь вводит логин и пароль.
Пароль передаётся по зашифрованному каналу (не в открытом виде).
Уязвимо к brute-force атакам.

По ключу (рекомендуемый способ):

Используется асимметричная криптография — пара ключей:
- Приватный ключ — хранится у клиента, никогда не передаётся.
- Публичный ключ — размещается на сервере (в ~/.ssh/authorized_keys).
Сервер отправляет challenge, клиент подписывает его приватным ключом, сервер проверяет подпись публичным ключом.

# Генерация пары ключей
ssh-keygen -t ed25519 -C "user@example.com"

# Копирование публичного ключа на сервер
ssh-copy-id user@server.example.com

# Подключение
ssh user@server.example.com

8.4. Применение SSH

Удалённый доступ — интерактивная оболочка на удалённом сервере.
SSH-туннелирование — проброс портов через зашифрованный канал (forward/reverse tunneling).
SCP — копирование файлов по SSH (scp file.txt user@server:/path/).
SFTP — интерактивная передача файлов поверх SSH.
Git по SSH — аутентификация при работе с удалёнными репозиториями.

9. Другие прикладные протоколы

9.1. FTP / SFTP

FTP (File Transfer Protocol) — протокол передачи файлов. Использует два TCP-соединения: управляющее (порт 21) и для данных (порт 20). Данные передаются в открытом виде — небезопасен.

SFTP (SSH File Transfer Protocol) — передача файлов поверх SSH. Полностью зашифрован, использует порт 22. Не путать с FTPS (FTP + TLS).

9.2. SMTP / IMAP / POP3

Протокол	Порт	Назначение
SMTP	25 (587 с STARTTLS)	Отправка электронной почты
IMAP	143 (993 с TLS)	Чтение почты с сервера (письма хранятся на сервере, синхронизация)
POP3	110 (995 с TLS)	Загрузка почты на клиент (обычно удаляется с сервера)

SMTP отвечает за маршрутизацию и доставку писем между серверами. IMAP и POP3 — протоколы для получения писем клиентом.

9.3. NTP (Network Time Protocol)

NTP — протокол синхронизации системных часов по сети (UDP, порт 123). Обеспечивает точность до миллисекунд. Критически важен для:

логирования событий;
работы сертификатов TLS (проверка срока действия);
распределённых систем (согласованность данных);
аутентификации (Kerberos, TOTP).

10. Межсетевые экраны (Firewalls)

10.1. Понятие межсетевого экрана

Межсетевой экран (firewall) — программный или аппаратный компонент, фильтрующий сетевой трафик на основе набора правил. Основная задача — контроль доступа между сетевыми зонами (например, интернет и внутренняя сеть).

10.2. Типы межсетевых экранов

Тип	Описание	Уровень OSI
Пакетный фильтр (Packet Filter)	Анализирует заголовки пакетов (IP, порт, протокол). Не отслеживает состояние соединений	L3–L4
Stateful firewall (с отслеживанием состояний)	Отслеживает состояние TCP-соединений. Пропускает пакеты, принадлежащие установленным соединениям	L3–L4
Прикладной (Application-level gateway / WAF)	Анализирует содержимое данных на уровне приложений (HTTP, SQL и т.д.)	L7

10.3. Зоны и цепочки правил

В Linux (iptables/nftables) трафик проходит через цепочки (chains):

Цепочка	Описание
INPUT	Входящий трафик, адресованный самому хосту
OUTPUT	Исходящий трафик от самого хоста
FORWARD	Транзитный трафик (хост выступает как маршрутизатор)

10.4. Правила фильтрации

Каждое правило содержит условие (matching criteria) и действие (target):

ACCEPT — пропустить пакет.
DROP — отбросить пакет (без уведомления отправителя).
REJECT — отбросить пакет и отправить ICMP-ошибку.
LOG — записать информацию о пакете в журнал.

Правила обрабатываются последовательно — первое совпавшее правило применяется.

10.5. Примеры настройки

iptables (классический инструмент Linux):

# Разрешить SSH (порт 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Разрешить HTTP и HTTPS
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Разрешить установленные соединения
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Запретить всё остальное (default policy)
iptables -P INPUT DROP

ufw (упрощённый интерфейс для iptables в Ubuntu):

# Включить firewall
sudo ufw enable

# Разрешить SSH, HTTP, HTTPS
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Запретить всё входящее по умолчанию
sudo ufw default deny incoming

# Посмотреть правила
sudo ufw status verbose

Windows Firewall (PowerShell):

# Разрешить входящие TCP-соединения на порт 8080
New-NetFirewallRule -DisplayName "Allow Port 8080" `
  -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow

11. Вопросы для самопроверки

В чём заключаются задачи мультиплексирования и демультиплексирования на транспортном уровне?
Опишите процесс установления TCP-соединения (трёхстороннее рукопожатие). Какова роль каждого из трёх сообщений?
Как работает механизм скользящего окна в TCP и зачем он нужен?
Чем отличаются фазы Slow Start и Congestion Avoidance в механизме контроля перегрузки TCP?
Почему UDP предпочтительнее TCP для VoIP и онлайн-игр?
Что такое сокет? Чем отличаются well-known, registered и ephemeral порты?
Опишите иерархию DNS. Как происходит резолвинг доменного имени? В чём разница между рекурсивным и итеративным запросом?
Перечислите основные типы DNS-записей (A, AAAA, CNAME, MX, NS, TXT) и их назначение.
Какова структура HTTP-запроса и HTTP-ответа? Приведите примеры кодов ответов из классов 2xx, 4xx, 5xx.
Как работает HTTPS? Что обеспечивает TLS и из каких основных шагов состоит TLS-рукопожатие?
Чем аутентификация по SSH-ключу отличается от аутентификации по паролю? Почему ключи безопаснее?
Какие типы межсетевых экранов существуют и чем отличается stateful firewall от простого пакетного фильтра?