Транспортный уровень: TCP и UDP

Цели:

  1. Цельность передаваемых данных и надёжность передачи
  2. Различение потоков и управление ими

Задачи:

UDP — «один пакет», TCP — поток

Порт + поток ⇒ клиент/сервер. Асимметричная (клиент-серверная) природа транспортных протоколов.

TCP

vs

UDP

есть

подключение

нет

есть

подтверждения

нет

есть

отслеживание цельности потока

нет

есть

отслеживание качества потока

нет

несколько

количество пакетов

один

TCP

Статья в Википедии

  1. Установление (и завершение) соединения
  2. Подтверждение доставки каждого пакета
  3. Уведомление об ошибках
  4. Повторная передача при отсутствии уведомлений
  5. Окно «одновременно» пересылаемых пакетов
  6. Поддержка цельности потока / порядка пакетов с помощью Sequential Number
  7. Двунаправленное (т. е. состоит из двух встречных потоков)

Понятие «порт»

Привязка портов: /etc/services и временный порт отправителя.

Sequential Number

Задачи:

Решение:

Подключение

Пакеты могут носить с собой т. н. флаги — это способ управления соединением

3-way handshake — установление двунаправленного соединения (флаг SYN — запрос на подключение, флаг FIN — запрос на отключение, флаг ACK — подтверждение получения пакета):

Завершение соединение может инициировать любая сторона.

(Пример: tcpdump tcp-соединения)

Демо на YouTube

Обработка ошибок и обеспечение надёжности

Получение каждого пакета в каждую сторону нужно подтвердить (ACK)

Sliding Window

Средство от всего — Sliding window protocol и «низкий старт».

Окно — это последовательная группа пакетов из потока, которую можно передавать/получать «одновременно», не дожидаясь подтверждения каждого.

При получении очередного пакета окно «сдвигается» на следующий ещё не полученный. Если пакеты идут с разной скоростью или пропадают, в окне получателя образуется «недопринятая» область:

  1. Непрерывное начало потока уже получено целиком
  2. Окно приёма из N пакетов
    • Первый пакет в окне ещё не получен (сразу после получения начало окна сдвигается)
    • Далее — какие-то пакеты в окне получены (вне очереди), какие-то — нет
  3. Остальные пакеты потока пока только предполагаются ☺

При отправлении TCP дожидается, пока каджому отправленному пакету придёт подтверждение (годится и подтверждение о приёме одного из следующих пакетов, см. далее). Если некоторые подтверждения по тем или иным причинам не пришли, образуется «недопереданная» область.

  1. Непрерывное начало потока уже передано.
  2. Окно передачи из N пакетов
    • Первый пакет в окне отправлен, но ещё не подтверждён (как только подтверждение пришло, начало окна сдвигается)
    • Далее — какие-то пакеты в окне уже отправлены, какие-то — ещё нет, но подтверждённых среди них не (подтверждение пакета M автоматически означает, что пакеты M-k тоже уже получены)
  3. Остальные пакеты потока пока только предполагаются ☺

TODO перейти с Flash на что-нибудь из этого:

Фиксированное окно

Будем называть «очередными» пакеты, принадлежащие уже полученному потоку, а «внеочередными» — пакеты, принадлежащие недопринятой области окна, т. е. полученные раньше, чем какой-то предыдущий пакет потока.

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

Демо:

Масштабируемое окно

Чем больше окно, тем больше потенциальная пропускная способность:

Чем меньше окно, тем меньше пропускная способность (спасибо, Кэп).

Поэтому размер окна может изменяться в зависимости от «качества» канала передачи данных.

Напомним, что TCP — двунаправленное соединение, и во встречном потоке данных действуют те же правила, а абоненты меняются ролями.

Linux: sysctl net.ipv4.tcp_adv_win_scale

Дурацкое маленькое окошко на медленных / ненадёжных каналах.

Пример масштабирования окна (без обработки ошибок)

У скользящего окна ∃ ещё «быстрый старт» и много-много модификаций…

UDP

Применение: DNS, traceroute, DHCP, SNMP, NTP

Использование netcat и socat

TCP-соединение предоставляет поток данных, так что все сетевые приложения написаны примерно одинаково:

С точки зрения ОС двунаправленный поток данных (как сложный, типа TCP-соединения, так и более простой, например, между двум процессами или вырожденный, типа датаграмм UDP) — это сокет.

Универсальные инструменты умеют в оба сценария — и клиентский и серверный, они просто перенаправляют поток данных откуда-то куда-то, наподобие утилиты cat. Содержимое потока (прикладной уровень) их не волнует, зато, как видно из описания выше, даже в самых простых случаях есть множество вариантов (например, по UDP доставлять только одну датаграмму или все, и что такое «все»).

Другие варианты транспорта?

Д/З

Обновлён образ:

Задание 6

  1. Суть: Почитать документацию по socat (руководство, есть статьи попроще ☺) и организовать проброс TCP-соединения и UDP-датаграммы без использования маршрутизации.

  2. Площадка: Клиент-1 ←сеть1→ Клиент-2 ←Сеть-2→ Клиент-3
    • Настроить сеть на всех хостах заранее, в отчёт не входит

  3. Отчёт:
    1. (на Клиенте-1) report 6 client1

      • Запустить socat в режиме listen на каком-нибудь TCP-порту с перенаправлением вывода на стандартный вывод

    2. (на Клиенте-2) report 6 client2

      • Запустить socat в режиме listen на каком-нибудь TCP-порту и выводом на TCP-порт Клиента-1

    3. (на Клиенте-3) report 6 client3

      • Запустить cal и перенаправить с помощью socat вывод на TCP-порт Клиента-2

      • В результате этой команды на Клиенте-1 появится вывод cal и все socat-ы остановятся

    4. (снова на Клиенте-1, report не останавливаем)
      • Запустить socat в режиме UDP-RECVFROM: (см. документацию) на каком-нибудь UDP-порту с перенаправлением вывода на стандартный вывод

    5. (снова на Клиенте-2, report не останавливаем)
      • Запустить socat в режиме UDP-RECVFROM: на каком-нибудь UDP-порту с выводом на UDP-порт Клиента-1 (режим UDP-SENDTO:)

    6. (снова на Клиенте-3)
      • Запустить cal и перенаправить с помощью socat (режим UDP-SENDTO:) вывод на UDP-порт Клиента-2

      • В результате этой команды на Клиенте-1 появится вывод cal и все socat-ы остановятся

    7. Остановить все report-ы
  4. Три отчёта (названия сохранить, должно быть: report.06.client1, report.06.client2 и report.06.client3) переслать одним письмом в качестве приложений на uneexlectures@cs.msu.ru

    • В теме письма должно встречаться слово LinuxNetwork2024

LecturesCMC/LinuxNetwork2024/06_TransportProtocols (last edited 2024-03-27 18:06:17 by FrBrGeorge)