Возможности, предоставляемые при перехвате пакетов
На сегодняшний день TCP/IP является стандартным сетевым протоколом. IP (Internet Protocol) обеспечивает функциональность сетевого уровня (адресация и маршрутизация), тогда как TCP (Transmission Control Protocol) контролирует соединение на уровне точка-точка. Стек TCP/IP включает в себя множество других полезных протоколов. В наши дни практически все приложения включают в себя некую сетевую функциональность. Следовательно, для каждого программиста становится необходимым наличие хотя бы базовых знаний о TCP/IP.
TCPDump — утилита, которая позволяет перехватывать и записывать пакеты, проходящие через сетевой интерфейс. Это очень удобная утилита, которая может помочь программисту при поиске ошибок в сетевых приложениях, например, используя петлевой интерфейс (loopback, осуществляется полная обработка данных на транспортном и сетевом уровнях, после чего IP датаграмма направляется по петле назад, когда выходит вниз из сетевого уровня). Однако, в связи с тем, что утилита может перехватывать все пакеты, полученные интерфейсом, она также может быть использована в неблаговидных целях.
Обычно, верхним уровням стека TCP/IP передаются только те пакеты, которые адресованы конкретному сетевому интерфейсу. Все прочие пакеты попросту игнорируются. Если же интерфейс находится в режиме Promiscuous, то верхним уровням передаются абсолютно все пакеты. TCPDump для своей работы переводит интерфейс именно в такой режим.
Итак: TcpDump позволяет делать дамп трафика в сети. TcpDump может использоваться для отображения заголовка пакетов на сетевом интерфейсе, которые соответствуют данному критерию. Также вы можете использовать TcpDump для обнаружения сетевых проблем, некоторых типов нападений и контроля сетевых действий.
Градация методов перехвата
2.1. BPF.
В современных реализациях ядра BSD существует пакетный фильтр BSD (BPF - BSD Packet Filter), именно его использует TCPDump, чтобы отлавливать и фильтровать пакеты из сетевой платы (которая помещена в смешанный режим). BPF также работает с каналами точка-точка, такими как SLIP и с интерфейсом loopback.
Фильтр, указанный пользователем, сообщает BPF, какие фреймы необходимо обрабатывать. Эти инструкции интерпретируются фильтром BPF в ядре. Фильтрация в ядре, а не в пользовательском процессе, уменьшает количество данных, которые должны быть переданы от ядра пользовательскому процессу.
2.2. Библиотека Рсар.
Библиотека рсар предоставляет удобный для программиста интерфейс с BPF и позволяет, не опускаясь на уровень сетевых устройств, установить фильтрацию пакетов, при помощи набора системных и специализированных функций.
С помощью вызова pcap_compile() библиотеки libpcap можно откомпилировать особый BPF-псевдокод из текстовой строчки, которая может быть, к примеру, сохранена в текстовом файле. В tcpdump это выражение вводится в командной строке ("host 192.168.0.1 proto 6 port 23/xOO").
Структура программ, написанных с помощью этой библиотеки, следующая:
Определившись с тем, какое из сетевых устройств собираемся
прослушивать (char *dev = pcap_lookupdev()), мы обращаемся к функции
библиотеки рсар (pcap_t *pcap_open_live(...)), возвращающей указатель на
устройство, который можно будет использовать для переключения между
сессиями в случае, когда одновременно идет работа с несколькими точками
коммуникации.
В случае если нас интересует определенный трафик (только TCP пакеты или
только пакеты, приходящие на порт 23) мы должны создать набор правил
(rule set), откомпилировать (compile) их и принять (apply).
В завершении мы даем команду рсар войти в основной цикл выполнения,
т. е. дождаться получения указанного количества пакетов, при получении
очередного вызывать заранее определенную функцию обработки (возможно,
разбивающую пакет на части и выводящую его на экран пользователю, или
сохраняющую его в файл...).
После получения достаточной для итогов информации мы закрываем
сессию и на этом работа заканчивается.
2.3. TCPDump.
TCPDump — это программа, позволяющая выводить в файл или на экран информацию о пакетах, приходящих на сетевой интерфейс и удовлетворяющих заданному условию. Она может обрабатывать как сохраненные в файл пакеты, так и непосредственно поступающие от устройства, а так же отброшенные ядром из за недостатка места в буфере. Обычно сетевые платы для сред передачи захватывают только фреймы канального уровня, адресованные конкретному интерфейсу или отправленные на широковещательный адрес. Программа tcpdump разработана таким образом, чтобы переводить сетевую плату в смешанный режим (promiscuous mode), при этом, каждый пакет, проходящий по кабелю, фиксируется
TCPdump использует библиотеку libpcap (библиотека захвата пакетов — packet capture library), которая свободно доступна. Библиотека libpcap универсальна и работает с пакетным фильтром BSD, SVR4 Data-link Provider Interface (DLPI) и интерфейсом Linux SOCK_PACKET.
Помимо многочисленных опций, позволяющих определять многие параметры обработки пакетов, синтаксис вызова этой функции включает выражение для выбора пакетов.
tcpdump [-options] [expression]
Выражение может содержать следующие ограничения:
Tun(type) ограничение, определяющее тип следующего за ним имени или числа.
Может принимать значение host, net и port. Например, 'host foo', 'net 128.3',
'port 20'. По умолчанию host.
Направление(dir) ограничение, определяющее направление. Может принимать
значение src, dst, src or dst и src and dst соответственно от англ, source и
destination. Например, 'src foo', 'dst net 128.3', 'src or dst port ftp-data'.
Протокол(proto) ограничение, определяющее конкретный протокол.
Может принимать значение ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp, udp.
Нарпимер, 'ether src foo', 'arp net 128.3', 'tcp port 21’.
Существуют ограничения, не соответствующие шаблону. Это ключевые слова
gateway, broadcast, less, greater и набор арифметических операций.
Выражение может принимать следующие формы:
· dst host host - истина, если поле назначения пакета в формате IPv4/v6 имеет
значение host которое может быть именем или адресом.
· src host host - то же, но поле источника.
· host host - истина, если и адрес источника и адрес назначения host.
· ether dst ehost - истина, если Ethernet-адрес получателя ehost.
· ether dst ehost — истина, если Ethernet-адрес отправителя ehost.
· ether host host - истина, если и Ethernet-адрес получателя, и Ethernet-адрес
отправителя ehost.
· gateway host - истина, если пакет использовал host в качестве шлюза, т. е.
если Ethernet-адрес отправителя или получателя был host, но ни IP-адрес
отправителя, ни IP-адрес получателя не был host.
· dst net net - истина, если IPv4/v6 адрес получателя с номером сети net.
· src net net - истина, если IPv4/v6 адрес отправителя с номером сети net.
· net net - истина, если IPv4/v6 адрес получателя или адрес отправителя с
номером сети net.
· net net mask netmask - истина, если маска сети IP-адреса netmask.
· net net/len — истина, если IPv4/v6 адрес указывает на сеть с длиной сетевой
маски в len бит.
· dst port port - истина, если пакет ip/tcp, ip/udp, ip6/tcp or ip6/udp и порт
получателя port.
· src port port - истина, если пакет ip/tcp, ip/udp, ip6/tcp or ip6/udp и порт
отправителя port
· less length - истина, если длина пакета меньше length.
· greater length — истина, если длина пакета больше length.
· ip proto protocol - истина, если ip пакет содержит в себе пакет протокола
protocol, protocol м. б. icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp or tcp.
· ip6 proto protocol — то же, но для ip6.
· ip broadcast - истина, если пакет имеет широковещательный IP-адрес
(последовательность нулей или единиц).
· ip multicast — истина, если ip пакет отправлен на несколько машин в разных
сетях одновременно.
· ether proto protocol выражения, принимающие значение истина,
fddi protocol protocol если пакет стандартов Ethernet, FDDI иB
tr protocol protocol TokenRing или OSI соответственно.
iso proto protocol
· tcp, udp, icmp — сокращения от ip proto p or ip6 proto p, где р – это протокол вышележащего уровня.
В выражениях можно также использовать следующие арифметические операции: >, <, >= , <=, =, !=; а так же бинарные: +,-,*, /, &, |.
Примеры захваченных пакетов и элементы анализа
Вот как проиллюстрирует TCPDump процедуру установления соединения между двумя машинами: rtsg и csam.
rtsg.1023 > csam. login: s 768512:768512(0) win 4096 <mss 1024> handshake
csam. login > rtsg. 1024: s 947648:947648(0) ask 768513 win 4096 <mss 1024>
rtsg.1023 > csam. login: . ack 1 win 4096
rtsg.1023 > csam. login: p 2:21(19) ack 1 win 4096
csam. login > rtsg.1024: p 1:2(1) ack 21 win 4077
csam. login > rtsg.1024: p 2:3(1) ack 21 win 4077 urg 1
csam. login > rtsg.1024: p 3:4(1) ack 21 win 4077 urg 1
Первая строка говорит о том, что tcp-порт 1023 на rtsg отправляет пакет порту login на csam. Индикатор s говорит о том, что был послан syn флаг, т. е. бит, означающий, что TCP - пакет представляет собой запрос на установления соединения. Номер в последовательности (32-битное поле, содержание которого определяет положение данных TCP - пакета внутри исходящего потока данных, существующего в рамках текущего логического соединения) был установлен в 768512 и пакет не содержал данных. Флаг ack не был установлен, так как не было информации, требующей подтверждения. Возможный для rtsg размер скользящего окна - 4096 байт. Так же был указан максимальный размер сегмента данных, а именно 1024 байта.
Получение пакета с установленным флагом syn должно быть подтверждено получающей стороной. Csam отвечает сходным пакетом, но с установленным флагом ack. Gtsg затем отвечает пакетом с флагом ack, тем самым подтверждая получение ответа от csam. Y говорит о том, что другие флаги установлены не были. Пакет не сдержит данных, а, следовательно, и номер в последовательности. Замечательно то, что Номер подтверждения у этого пакета имеет тип small integer (1). Когда tcpdump впервые видит tcp-соединение, она выводит номер в последовательности непосредственно из пакета. Для последующих пакетов соединения высчитывается разность текущего номера и инициализированного при установлении соединения.
В четвертой строке rtsg посылает csam 19 байт данных. Установлен флаг Push, сообщающий, что данные, переданные в пакете, должны быть немедленно переданы прикладной программе.
В пятой строке csam сообщает, что переданные ему данные были получены. Большая часть этих данных видимо находится в буфере устройства, т. к. csam просит уменьшить размер скользящего окна на 19 байт. Этот пакет так же содержит один байт данных.
Далее scam посылает еще два пакета со срочными данными, требующими немедленной передачи прикладной программе.
Обработка TCPTrace
В результате запуска TCPDump мы получили файл, содержащий некоторые характеристики потока данных соединений, удовлетворяющих заданным условиям. Но на базе этой информации можно делать более глубокие выводы, чем кажется на первый взгляд, запустив для этого файла обработку TCPTrace.
3.1. Детальный анализ.
Tcptrace может вычислять подробную статистику TCP подключений, когда установлена опция - l или опция подробного вывода.
1 arg remaining, starting with 'outfortcptrace'
Ostermann's tcptrace -- version 5.Wed Sep 15, 1999
200 packets seen, 200 TCP packets traced
elapsed wallclock time: 0:00:17. 11 pkts/sec analyzed
trace file elapsed time: 0:00:31.465429
TCP connection info:
20 TCP connections traced:
================================
. . .
================================
TCP connection 17:
host bg: 192.168.7.98:4393
host bh: 192.168.7.200:80
complete conn: yes
first packet: Wed Apr 28 09:42:16.169
last packet: Wed Apr 28 09:42:16.388
elapsed time: 0:00:00.219201
total packets: 11
filename: outfortcptrace
bg->bh: bh->bg:
total packets: 6 total packets: 5
ack pkts sent: 5 ack pkts sent: 5
pure acks sent: 3 pure acks sent: 1
unique bytes sent: 258 unique bytes sent: 208
actual data pkts: 1 actual data pkts: 2
actual data bytes: 258 actual data bytes: 208
rexmt data pkts: 0 rexmt data pkts: 0
rexmt data bytes: 0 rexmt data bytes: 0
outoforder pkts: 0 outoforder pkts: 0
pushed data pkts: 1 pushed data pkts: 2
SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1
req sack: Y req sack: N
sacks sent: 0 sacks sent: 0
mss requested: 1460 bytes mss requested: 1024 bytes
max segm size: 258 bytes max segm size: 183 bytes
min segm size: 258 bytes min segm size: 25 bytes
avg segm size: 257 bytes avg segm size: 103 bytes
max win adv: 65535 bytes max win adv: 16384 bytes
min win adv: 65327 bytes min win adv: 16384 bytes
zero win adv: 0 times zero win adv: 0 times
avg win adv: 78553 bytes avg win adv: 16384 bytes
initial window: 258 bytes initial window: 25 bytes
initial window: 1 pkts initial window: 1 pkts
ttl stream length: 258 bytes ttl stream length: 208 bytes
missed data: 0 bytes missed data: 0 bytes
truncated data: 216 bytes truncated data: 141 bytes
truncated packets: 1 pkts truncated packets: 1 pkts
data xmit time: 0.000 secs data xmit time: 0.203 secs
idletime max: 202.9 ms idletime max: 202.7 ms
throughput: 1177 Bps throughput: 949 Bps
Tcptrace обрабатывает dumpfile (результат запуска tcpdump c опцией - w). Первые строки сообщают, какой файл будет на выходе после выполнения работы tcptrace, версия tcptrace и дата компиляции. Следующая строка сообщает, что 200 пакетов было замечено в dumpfile, и все 200 TCP пакетов этой группы были прослежены. Следующая строка сообщает время обработки dumpfile и среднюю скорость обработки (пакетов в секунду).
Последующие строки указывают на TCP соединения. Семнадцатым было замечено соединение между машинами 192.168.7.98 TCP порт 4393, и 192.168.7.200 TCP порт http. Tcptrace использует схему маркирования для обращения к отдельным прослеженным подключениям. В вышеупомянутом примере это подключение помечено bh-bg соответственно. 6 пакетов были замечены в bh->bg направлении и 5 пакетов - в bh<-bg направлении.
Указываются хосты, участвующие в соединениях и номера TCP портов:
host bg: 192.168.7.98:4393
host bh: 192.168.7.200:80
Далее сообщается о том, что подключение было полным то есть, подключение было прослежено полностью с SYN и FIN флагами. TCP подключение могло также быть сообщенено как сброшенное, если оно было закрыто с флагом RST, или unidirectional, если движение пакетов было замечено только в одном направлении.
Время, в которое первый и последний пакеты соединения были захвачены, а также "продолжительность жизни" подключения и число замеченных пакетов. Далее указано имя файла, в настоящее время обрабатываемого, с подробной TCP статистикой для прямого (bg->bh) и обратного (bh<-bg) направлений.
· total packets - общее количество замеченных пакетов.
· ack pkts sent - общее количество пакетов с установленным ack флагом.
· pure acks sent - общее количество пакетов с установленным ack флагом, которые не несли пользовательских данных (только TCP заголовок и никаких данных) и не имели флагов SYN/FIN/RST.
· sack pkts sent - общее количество ack TCP пакетов seen carrying TCP SACK.
Прим.
При поступлении сегмента протокол TCP на приемной стороне имеет два варианта выбора времени отправки подтверждения:
А. «Немедленно».
Б. «С накоплением». Когда данные успешно приняты, отмечается необходимость в подтверждении, но последнее отправляется с очередным исходящим сегментом данных, в котором устанавливается флаг АСК. Во избежание длительных задержек устанавливается таймер окна. Если время таймера истекает до момента отсылки очередного сегмента данных, то отправителю посылается пустой сегмент, содержащий соответствующий номер подтверждения.
(http://*****/polez/home_lan/optimize/optimize02.html)
· dsack pkts sent - общее количество пакетов sack, содержащихся в двойном SACK (D-SACK).
· max sack blks/ack - максимальное число блоков, замеченных в любой группе sack.
· unique bytes sent - число посланных unique байтов, то есть байтов данных, исключая ретранслированные байты и любые байты анализа окна.
· actual data pkts - число пакетов с, по крайней мере, 1 байтом данных.
· actual data bytes - общее количество обработанных байтов данных, включая байты ретрансляций и байты анализа окна.
· rexmt data pkts - общее число пакетов ретрансляции.
· rexmt data bytes - общее число байтов в пакетах ретрансляции.
· zwnd probe pkts - общее число пакетов анализа окна. (Пакеты анализа размера окна обычно посылаются источником, когда приемник сообщает о сокращении размера окна до нуля, и позволяют определить, готово ли окно теперь).
· zwnd probe bytes - общее число байтов в пакетах анализа окна.
· outoforder pkts - общее число пакетов, которые прибывали поврежденными.
· pushed data pkts - общее число пакетов с установленным битом PUSH в TCP заголовке.
· SYN/FIN pkts sent - общее число пакетов с SYN/FIN набором битов в TCP заголовке.
· req 1323 ws/ts - если точка соединения установила опцию Window Scaling/Time Stamp как определено в RFC 1323, "Y" напечатан в соответствующем поле. Если опция не требовалась, "N" напечатан. Например, "N/Y " в поле означает, что опция анализа размера окна не была определена, в то время как опция Time-stamp была определена в сегменте SYN. Обратите внимание, что, так как опция Window Scaling посылается только в SYN пакетах, это поле имеет значение, только если соединение было захвачено полностью в dumpfile, вместе с SYN пакетами.
· adv wind scale – использовался анализ размера окна. Снова, это поле имеет значение только если соединение было захвачено полностью, чтобы включить SYN пакеты. Так как соединение использовало бы вычисление размера окна, если и только, если обе стороны затребовали использование этой опции, это поле сброшено в 0 (даже если масштаб окна требовался в SYN группе для этого направления), если SYN группа в обратном направлении не содержал указаний к анализу размера окна.
· req sack - если получатель послал разрешение на использование SACK в SYN пакете, открывшем соединение, "Y" напечатана, иначе "N".
· sacks sent - общее количество ACK пакетов, имевших SACK информацию.
· urgent data pkts - общее количество пакетов с URG битом в TCP заголовке (срочных данных).
· urgent data bytes - общее количество байтов в пакетах с URG битом в TCP заголовке. Это поле рассчитано суммированием количества срочных данных.
· mss requested - Maximum Segment Size (MSS), опция TCP в SYN пакете, открывающем соединение.
· max segm size - максимальный размер сегмента, наблюдаемый в течение времени существования соединения.
· min segm size - минимальный размер сегмента, наблюдаемый в течение времени существования соединения.
· avg segm size - средний размер сегмента, наблюдаемый в течение времени существования соединения.
· max win adv - максимальный размер окна, объявленный во время соединения, если соединение использовало анализ размера окна (обе стороны установили эту опцию) и оба сегмента SYN, открывших соединение были захвачены в dumpfile.
· min win adv - минимальный размер окна.
· zero win adv - число объявлений нулевого окна.
· avg win adv - средний зафиксированный размер окна, рассчитанный как сумма всех размеров окна, разделенная на количество пакетов, если точки соединения установили опцию анализа размера окна.
· initial window - размер в байтах начального окна, то есть число байтов при первой передаче данных (перед получением первого ack пакета от другого участника соединения). Обратите внимание, что ack пакет от другого участника соединения - первый ack, подтверждающий некоторые данные (часть ACK "тройного рукопожатия" не считается), и любые пакеты ретрансляции в этой стадии исключены.
· initial window - общее количество сегментов (пакетов) отправленных в начальном окне.
· ttl stream length - The Theoretical Stream Length (Теоретическая Длина Потока). Рассчитанная как различие между порядковыми номерами SYN и FIN пакетов, отражает длину потока данных.
· missed data - пропущенные данные, рассчитанные как различие между длиной потока ТТЛ-схемы и уникальными переданными байтами. Если соединение не было полно, это вычисление недействительно, и " NA " (Not Available) напечатано.
· truncated data - обрезанные данные. Рассчитывается как количество байтов данных, обрезанных в процессе захвата пакета. Например, с tcpdump (snaplen) опция длины пакета может быть установлена в 64 (с - s) так, чтобы только заголовки пакета соединения были захвачены, усекая большинство данных пакета. В Ethernet с максимальным размером сегмента 1500 байтов, усечение данных составило бы 1= 1436 байтов пакета.
· truncated packets - общее количество пакетов, усеченных как объяснено выше.
· data xmit time - полное время передачи, рассчитанное как различие между временами захвата первых и последних пакетов, несущих пользовательские данные TCP соединения.
· idletime max - максимальное время простоя, расчетное как максимальное время между последовательными пакетами, замеченными в направлении.
· throughput - средняя производительность, рассчитанная как количество уникальных байтов, разделенное на разницу во времени между захватом первых и последних пакетов соединения.
3.2 RTT Информация.
RTT (Round-Trip Time) - время обращения сегмента рассчитывается, когда - r опция определена наряду с - l.
Когда сегмент принимается с ошибками либо не поступает вовсе, подтверждение ACK просто не формируется, что однозначно указывает на необходимость повторной передачи. Для принятия решения о повторной передаче используется таймер, работающий с каждым посланным сегментом. Если время таймера истекает до получения ACK для данного сегмента, отправитель должен выполнить повторную передачу.
Регулируемое время этого таймера является важным параметром протокола TCP. Если его значение будет слишком малым, то заметно участятся ненужные повторные передачи, уменьшающие полезную полосу пропускания сети, что вызовет дополнительные повторные передачи и т. д. При очень большом значении реакция протокола на потерю сегмента станет слишком медленной. Таймер должен быть установлен так, чтобы его значение немного превышало время обращения сегмента (Round Trip Time, RTT). Естественно, эта задержка зависит от множества факторов, влияние которых ощутимо даже при постоянной загрузке сети.
Рассмотрим на примере:
1 arg remaining, starting with 'outfortcptrace'
Ostermann's tcptrace -- version 5.Wed Sep 15, 1999
200 packets seen, 200 TCP packets traced
elapsed wallclock time: 0:00:17. 11 pkts/sec analyzed
trace file elapsed time: 0:00:31.465429
TCP connection info:
20 TCP connections traced:
================================
. . .
================================
TCP connection 17:
host bg: 192.168.7.98:4393
host bh: 192.168.7.200:80
complete conn: yes
first packet: Wed Apr 28 09:42:16.169
last packet: Wed Apr 28 09:42:16.388
elapsed time: 0:00:00.219201
total packets: 11
filename: outfortcptrace
bg->bh: bh->bg:
. . .
RTT samples: 3 RTT samples: 4
RTT min: 0.2 ms RTT min: 0.1 ms
RTT max: 0.6 ms RTT max: 202.3 ms
RTT avg: 0.4 ms RTT avg: 50.7 ms
RTT stdev: 0.2 ms RTT stdev: 101.0 ms
post-loss acks: 0 post-loss acks: 0
segs cum acked: 0 segs cum acked: 0
duplicate acks: 2 duplicate acks: 1
triple dupacks: 0 triple dupacks: 0
max # retrans: 0 max # retrans: 0
min retr time: 0.0 ms min retr time: 0.0 ms
max retr time: 0.0 ms max retr time: 0.0 ms
avg retr time: 0.0 ms avg retr time: 0.0 ms
sdv retr time: 0.0 ms sdv retr time: 0.0 ms
================================
· RTT samples - общее количество зафиксированных обращений сегментов (Round-Trip Time RTT). Tcptrace выбирает только значимые RTT потоки. RTT поток анализируется только, если ack пакет получен от другой точки соединения с подтверждением порядкового номера предыдущего пакета (ожидается пакет с порядковым номером на 1 больше). Также требуется, чтобы подтверждаемый пакет не был ретранслирован, и чтобы никакие пакеты, переданные прежде в той же последовательности, не были ретранслированы после рассматриваемого.
· RTT min – минимум времени обращения RTT потоков, замеченных в соединении.
· RTT max - максимум времени обращения RTT потоков, замеченных в соединении.
· RTT avg - среднее значение времени обращения RTT потоков, замеченных в соединении. Рассчитывается прямо, как сумма всех значений RTT разделенная на общее количество RTT потоков.
· RTT stdev - среднеквадратичное отклонение времени обращения RTT потоков.
· post-loss acks - общее количество ack пакетов, полученных после того, как потеря была обнаружена, и ретрансляция произошла. Более точно, post-loss ack обнаружена, когда значение подтверждения в ack pkt на 1 больше (с учетом кумулятивной схемы, используемой asc может быть более), чем последний порядковый номер пакета, и по крайней мере один пакет перед подтвержденным был ретранслирован позже. Другими словами, ack пакет получен после того, как мы наблюдали случай потери и восстанавливаемся после этого.
· segs cum acked - число сегментов, которые были кумулятивно подтверждены и не непосредственно подтвержденный.
· duplicate acks - общее количество повторно полученных подтверждений. Ack-пакет является дубликатом ack пакета-основанния, если выполнено:
· ack пакет имеет самый большой ACK номер подтверждения из когда-либо замеченных.
· ack не должен содержать пользовательских данных. Объявленный размер окна, его значение в ack-пакете, не должно измениться по сравнению с предыдущим.
· triple dupacks - общее количество тройных повторно полученных подтверждений (три повторных подтверждения одного и того же сегмента).
· max # retrans - максимальное число ретрансляций, во время существования соединения для одного сегмента.
· min retr time - минимальное время ретрансляций, во время существования соединения для одного сегмента.
· max retr time - максимальное время, замеченное между любыми двумя ретрансляциями сегмента.
· avg retr time - среднее время, замеченное между любыми двумя ретрансляциями сегмента.
· sdv retr time - среднеквадратичное отклонение оценок времени.
Рассмотрим один из подходов, который учитывает среднее наблюдаемое время для некоторого количества посланных сегментов. Если это время достаточно точно предсказывает будущие задержки, то полученное значение таймера повторной передачи обеспечит очень хорошую производительность сети. Усредненное время можно определить, используя следующее выражение:
,
где RTT(i) — наблюдаемое время обращения i-го переданного сегмента, а ARTT(K) — среднее время обращения для первых K сегментов. Для удобства последующего изложения представим приведенное выражение в виде
,
Следует учесть, что каждый параметр в последней формуле имеет равный вес. Однако, как правило, больший вес, или большая степень доверия, присваивается самым последним замерам, поскольку они точнее всего отражают будущее поведение сети. Общий метод предсказания очередного усредненного значения времени обращения на основе предыдущей серии измерений приведен в документе RFC 793. В его основе лежит выражение:
,
где SRTT(K) — так называемое сглаженное оцененное время обращения (Smoothed Round Trip Time). Нетрудно сравнить это выражение с предыдущим. Используя константу a (0 < a < 1), не зависящую от числа последних наблюдений, можно сформулировать условия, при которых учитываются все последние значения наблюдений, но более ранние наблюдения имеют меньший вес. Эту константу называют фактором сглаживания.
Наименьшее значение константы a придает больший вес самым последним наблюдениям. При a = 0,5 самыми весомыми становятся четыре или пять последних наблюдений, в то время как при a = 0,875 средний вес распределяется между десятью последними наблюдениями (и даже большим их числом). Достоинством использования малого значения константы a является то, что оно позволяет учесть быстрые изменения в наблюдаемых величинах. Недостаток же такого выбора состоит в следующем: при возникновении короткого волнообразного изменения наблюдаемых времен обращения с последующим возвратом к среднему значению происходят резкие изменения вычисляемого усредненного времени обращения.
Как уже упоминалось, таймер повторной передачи должен быть установлен так, чтобы его значение слегка превосходило оцененное время обращения. Для вычисления этого превышения можно использовать формулу:
,
где RTO (Retransmission Time Оut) — контрольное время повторной передачи (его иногда называют тайм-аутом повторной передачи), а D — некоторая константа. Недостаток этого способа состоит в том, что значение D не пропорционально значению SRTT. Для больших значений SRTT величина константы D относительно невелика. В этом случае флуктуации фактического значения RTT будут приводить к ненужным повторным передачам. При малых значениях SRTT величина D, напротив, начинает доминировать и может вызвать ненужные задержки при повторных передачах потерянных сегментов.
В этой связи документ RFC 793 определяет значение таймера, пропорциональное SRTT, со следующими ограничениями:
,
где UBOUND и LBOUND — фиксированные верхняя и нижняя границы значения таймера, а b — константа, называемая фактором изменения задержки. Документ RFC 793 не рекомендует применять фиксированные значения, в нем приводятся диапазоны изменений параметров a и b.
Таким образом, RTO вычисляется на основе предсказания RTT, которое было спрогнозировано, исходя из значения предыдущего RTT. Но если задержки на стороне получателя изменяются, то в этом случае точность оценки RTT невысока.
На основании данных, полученных обработкой вывода TCPDump, мы можем наглядно представить распределение RTT avg (среднее значение RTT потоков, замеченных в соединении) в виде полигона и гистограммы частот. Из графикор становится исно, что этих величины колеблются значительно, причем в очень короткое время.
Обозначив i -> j исходящий и j -> i входящий трафик, вычислим некоторые вероятностные характеристики потоков.
RTT avg i -> j | RTT avg i <- j | Статистика | |
0,1 | 0 | математическое ожидание RTT avg -> | 0,88 |
0,6 | 0 | математическое ожидание RTT avg <- | 33,345 |
11,9 | 192,7 | дисперсия RTT avg -> | 6,4346 |
0,4 | 0 | дисперсия RTT avg <- | 2918,749475 |
0,8 | 52,4 | среднеквадратическое отклонение RTT avg -> | 2, |
0,3 | 0 | среднеквадратическое отклонение RTT avg <- | 54,0254521 |
0,1 | 0 | начальный момент 2 порядка -> | 7,209 |
0,4 | 0,1 | начальный момент 3 порядка -> | 84,3268 |
0 | 0 | начальный момент 4 порядка -> | 1002,71109 |
0,3 | 0 | центральный момент 2 порядка -> | 6,4346 |
0,4 | 0 | центральный момент 3 порядка -> | 66,657984 |
0,6 | 0 | центральный момент 4 порядка -> | 737,5775655 |
0,3 | 0 | мода -> | 0,1 |
0,1 | 1 | ассиметрия -> | 4, |
0,3 | 62,9 | ||
0,4 | 61,6 | коэффициент эксцесса -> | 693,1734884 |
0,4 | 50,7 | ||
0,1 | 134,5 | ||
0,1 | 111 | начальный момент 2 порядка <- | 4030,6385 |
0 | 0 | начальный момент 3 порядка <- | 0181 |
начальный момент 4 порядка <- | ,79 | ||
центральный момент 2 порядка <- | 2918,749475 | ||
центральный момент 3 порядка <- | 9748 | ||
центральный момент 4 порядка <- | |||
мода <- | 0 | ||
ассиметрия <- | 1, | ||
коэффициент эксцесса <- | ,5 | ||
коэффициент ковариации > 0, значит величины коррелированные | 93,3 | ||
коэффициент корреляции отличен от нуля но и далек от единицы, следовательно величины зависимы | 0,6808 |
Таким образом, как было сказано выше, точность оценок снижается и становится сложно прогнозировать качество передачи даже на короткий период.
Выводы
Анализируя трафик сети, мы можем не только корректно определить модель поведения протокола TCP, но и подобрать оптимальные значения числа повторных передач, контрольное время (тайм-аут) ретрансляции, заметить сбои, приводящие к потере данных или отладить сетевой программный продукт, подвергнув его самому тщательному тестированию. Исходные коды программы TCPDump не раз изменялись программистами, подстраивались под актуальные задачи и помогали находить новые решения в алгоритмах протокола TCP.
Ресурсы:
http://*****/polez/home_lan/optimize/optimize02.html
(Оптимизация работы протокола ТСР в распределенных сетях)
http://jarok. cs. ohiou. edu/software/tcptrace/manual/index. html
(TCPTRACE Manual_4)
http://book. *****/4/45/network_r. htm
(Сетевая надежность)
, «Таблицы математической статистики»
