Транспортный уровень: протоколы и трансляция сетевых адресов
Цели:
- Цельность передаваемых данных и надёжность передачи
- Различение потоков и управление ими
Задачи:
- Передано == принято
Порядок пакетов или один пакет
- Управление процессом передачи
Двустороннее соединение (с проверкой доступности) или один пакет
Подтверждение доставки / ошибки / и т. п. или один пакет
Обмен данными о состоянии канала или один пакет
⇒ Поток или датаграмма
- Идентификация потоков и датаграмм
- Адрес отправителя, адрес получателя
- Порт отправителя, порт получателя
UDP — «один пакет», TCP — поток
Порт + поток ⇒ клиент/сервер. /etc/services и временный порт отправителя.
TCP
3-way handshake — установление двунаправленного соединения (SYN+ACK):
Client → (SYN1) → Server
Client ← (ACK1+SYN2) ← Server
Client → (ACK2+DATA1) → Server
- …
Client → (DATA2(?)+FIN1) → Server
Client ← (ACK1+FIN2) ← Server
Client → (ACK2) → Server
- Sequence number: последовательность и цельность трафика
- Обработка ошибок TCP
- Окно: управление объёмом и качеством потока
Средство от всего — окно и «низкий старт»:
- алгоритм работы окна
пример (ссылка на исходник давно утеряна, есть на YouTube, swf-файл запасён тут)
- слишком частые ошибки
пример обработки ошибок (на Flash, swf-файл запасён тут)
- забивание канала
UDP
- Весь сеанс — одна датаграмма
- Нет шторма подтверждений
- Всё остальное делает прикладной уровень
Применение: DNS, traceroute, DHCP, SNMP, NTP
NAT
- Табличная подмена IP на основании «идентификатора сеанса»
- TCP: 4 порта
- DNS (UDP): DNS Query ID + 4 порта
- NTP (UDP): Originator Timestamp + 4 порта
- ping: ICMP-serial
- …
FTP
«Классический» FTP: C → S:21 ; C → S:21 "IP,PORT" ; IP:PORT ← S:20
- Проблемы "← S:20"
- Проблемы "IP ←" (NAT)
- Проблемы "←"
- Пассивный режим C → S:21 (получает IP+PORT); C → IP+PORT
- проблемы почти те же...
Другие варианты?
Поток нужен, порядок уже неважен (напр., видео): DCCP (или DCCP+UDP)
Несколько потоков в одном сеансе, двусторонняя готовность к сеансу (4-way handshake вместо 3-way): SCTP
Дешёвая / управляемая / прогнозируемая защита от забивания канала: ECN
Резервирование объёмов / пропускной способности / других свойств: RSVP (IPv6)
Д/З
TCP
- Посмотреть TCP-трафик
На сервере запустит tcpdump:
[root@uneex ~]# tcpdump -KlSnni enp0s3 tcp and port 80
- на клиенте — сходить куда-нибудь по 80-му порту, например:
[root@uneexclient ~]# date | netcat linux.org.ru 80
Наблюсти TCP-сеанс. Обратить внимание на флаги [S] (syn) [P] (payload) и [F] (fin), возникающие в сеансе, а также на использование двух нарастающих seq (туда и обратно)
Наблюсти тот же сеанс, убрав S и nn из ключей tcpdump
UDP и ICMP
- На сервере посмотреть трафик по 53-му и 123-му портам и протоколу ICMP
[root@uneex ~]# tcpdump -Klvnni enp0s3 port domain or port ntp or icmp
- На клиенте:
пингануть что-нибудь (например ping -c3 linux.org.ru)
обновить время (ntpdate ru.pool.ntp.org)
выполнить traceroute (traceroute -N1 -q1 -n linux.org.ru)
- Наблюсти на сервере
- DNS-трафик (от ping, ntpdate и т. п.). Где в нём DNS Query ID?
ICMP-трафик (для ping — id. для traceroute — увеличивающиеся ttl, UDP и ICMP)
- NTP-трафик (Transmit Timestamp и Originator Timestamp в ответе)
FTP и его непростой выбор портов
На сервере запустить tcpdump -i enp0s8
- На клиенте выполнить
[root@uneexclient ~]# ftp 10.30.50.1 … Name (10.30.50.1:root): ftp … ftp> ls … ftp> passive … ftp> ls … ftp> exit
- Найти:
- в passive режиме (по умолчанию):
в выводе FTP: предложение сервера подключиться для передачи данных к случайному порту (представлен в побайтно-десятичном виде сразу после адреса, например 234.12 — это 234*256+12 = 59916 - подключение к этому порту (в tcpdump) с клиента на сервер
в active режиме (после команды passive)
- в выводе FTP: предложение клиента подключиться для передачи данных к случайному порту
- подключение к этому порту (в tcpdump) с сервера на клиент
- в passive режиме (по умолчанию):