Порядок пакетов (TCP)

Question

[zTrue]

Скрипт слушает pcap. Некоторые сообщения, если не помещаются в один пакет, разбиваются на несколько пакетов. Но иногда случается так, что вторая часть сообщения (второй пакет) приходит раньше, чем первая. Мне нужно передавать пакеты приложению в правильном порядке (не обязательно целыми сообщениями, важен только порядок), без существенного таймаута. По идентификаторам пакетов я могу расставить их в нужном порядке, но как я могу быть уверен, что в конкретный момент времени у меня нет «пропущенных» пакетов, которые придут следом? Возможно, какие-то заголовки (о том, что это только часть сообщения)? Если да, то какие?
На данный момент единственное решение, которое вижу — делать таймаут, но оно мне не нравится из-за magic-number таймаута и все-равно отсутствия гарантий.
PS
Модифицировать пакеты или способ их передачи возможности нет.

Comments

[zTrue]

Вторая часть (которая пришла раньше)

{
  "link_type":"LINKTYPE_ETHERNET",
  "link":{
    "dhost":"...",
    "shost":"...",
    "ethertype":2048,
    "ip":{
      "version":4,
      "header_length":5,
      "header_bytes":20,
      "diffserv":0,
      "total_length":58,
      "identification":13447,
      "flags":{"reserved":0,"df":1,"mf":0},
      "fragment_offset":0,
      "ttl":113,
      "protocol":6,
      "header_checksum":22392,
      "saddr":"...",
      "daddr":"...",
      "protocol_name":"TCP",
      "tcp":{
        "sport":8088,
        "dport":59906,
        "seqno":1455344501,
        "ackno":1469993398,
        "data_offset":66,
        "header_bytes":32,
        "reserved":0,
        "flags":{"cwr":0,"ece":0,"urg":0,"ack":1,"psh":1,"rst":0,"syn":0,"fin":0},
        "window_size":258,
        "checksum":36646,
        "urgent_pointer":0,
        "options":{"timestamp":340036816,"echo":667434095},
        "data_end":72,
        "data_bytes":6,
        "data":[...]
      }
    }
  },
  "pcap_header":{"tv_sec":1381693846,"tv_usec":835169,"caplen":72,"len":72,"link_type":"LINKTYPE_ETHERNET","time_ms":1381693846835.169}
}

Первая часть (которая пришла позже)

{
  "link_type":"LINKTYPE_ETHERNET",
  "link":{
    "dhost":"...",
    "shost":"...",
    "ethertype":2048,
    "ip":{
      "version":4,
      "header_length":5,
      "header_bytes":20,
      "diffserv":0,
      "total_length":1492,
      "identification":13446,
      "flags":{"reserved":0,"df":1,"mf":0},
      "fragment_offset":0,
      "ttl":113,
      "protocol":6,
      "header_checksum":20959,
      "saddr":"...",
      "daddr":"...",
      "protocol_name":"TCP",
      "tcp":{
        "sport":8088,
        "dport":59906,
        "seqno":1455343061,
        "ackno":1469993398,
        "data_offset":66,
        "header_bytes":32,
        "reserved":0,
        "flags":{"cwr":0,"ece":0,"urg":0,"ack":1,"psh":0,"rst":0,"syn":0,"fin":0},
        "window_size":258,
        "checksum":59362,
        "urgent_pointer":0,
        "options":{"timestamp":340036816,"echo":667434095},
        "data_end":1506,
        "data_bytes":1440,
        "data":[...]
      }
    }
  },
  "pcap_header":{"tv_sec":1381693846,"tv_usec":835771,"caplen":1506,"len":1506,"link_type":"LINKTYPE_ETHERNET","time_ms":1381693846835.771}
}

[pavelsh]

Поправьте про сокет — напишите что скрипт слушает pcap. А то и дальше народ будет очевидности про tcp рассказывать.

Answer 1

[pavelsh]

Пока FIN не пришел, вы можете получить еще пакет от той стороны.

А можете пояснить зачем вам node-pcap? Какую задачу хотите сделать?

Comments

[zTrue]

У всех пакетов (не зависимо от того, разбитое это сообщение или нет) fin = 0
node-pcap использую для получения данных, отправляемых сервером flash-приложению в браузере (сторонняя программа), и использования потом этих данных для статистики.

[zTrue]

Пакеты отличаются только тем, что у первого psh=0, а у второго psh=1, но поскольку второй приходит раньше, эта информация становится бесполезной

[pavelsh]

Делайте буфер. Принимайте пакет 2, ждите, когда придет недостающий пакет, добивайте им буфер и отправляйте на уровень выше. Вообще, я бы не советовал делать в своем приложении реализацию tcp стека. Может быть эту задачу можно реализовать как-то по-другому?

[zTrue]

В этом и проблема, как узнать, что пришедшая часть имеет другую часть?

[pavelsh]

1. Смотрите на флаг fin. Если он = 0, то ждите еще данных
2. При получении пакета смотрите на его sequence number. Если это число больше, чем sequence number предыдущего пакета + длина предыдущего tcp пакета (обязательно посмотрите в RFC как происходит приращение sequence number — потому как я могу быть не прав) — то пропущен пакет — пакеты — нужно ждать их и не использовать текущий пакет. А если полученный sequence number такой, какой вы ожидали — пакеты не пропущены.

Читайте RFC.

[zTrue]

Да, все верно. Если еще вычесть data_offset, то все сходится.

Answer 2

[major]

Скрипт слушает tcp сокет == пакеты приходят в правильном порядке (tcp стек все уже сделал самостоятельно)

Comments

[zTrue]

Я так и полагал, но проверял WireShark, пакеты тоже не в том порядке и выделены другим цветом. Идентификатор пакета, который приходит раньше на 1 больше, чем у того, который приходит позже.
Использую node-pcap.
Может быть, это прослушивание не tcp сокета?

[merlin-vrn]

Нет у пакета никакого идентификатора. PSH — это не номер пакета, это флаг (0 или 1, других не будет). То, что вы в Wireshark увидели данные в произвольном порядке — следствие того, что вы получили их через pcap в обход tcp-стека, т.е. в обход всей логики ОС по упорядочению и гарантиям доставки.

[zTrue]

я говорил не про psh, а про ip.identification

[merlin-vrn]

Разделяйте транспортный уровень и сетевой. На уровень tcp (транспортный) передаются уже собранные пакеты, если они были фрагментированы — слой tcp опять не получит пакет, пока все его фрагменты не собраны (на сетевом уровне). То же самое касается других протоколов этого уровня: udp-пакет можно фрагментировать и он или «дойдёт целиком и в правильном порядке» или «не дойдёт совсем».

А в вашем случае вроде пакеты целые, не фрагментированные.

Answer 3

[lex_t]

TCP гарантирует, что все придет в правильном порядке. Все отправленные пакеты нумеруются

Comments

[zTrue]

Посмотрите, пожалуйста, уточнение выше.

[merlin-vrn]

lex_t, нумеруются не пакеты, нумеруются байты. Теоретически в процессе передачи можно разделить пакет на части или наоборот склеить пакеты или перераспределить байты по ним, но порядок сохранить — прикладной уровень ничего не заметит. Поле SEQ — это порядковый номер первого байта в пакете.

Answer 4

[jcmvbkbc]

Если скрипт слушает TCP-сокет стандартными средствами (read/recv), то TCP-стек должен гарантировать доставку данных в правильном порядке. Я думаю, именно это имел в виду major.

По идентификаторам пакетов я могу расставить их в нужном порядке, но как я могу быть уверен, что в конкретный момент времени у меня нет «пропущенных» пакетов, которые придут следом? Возможно, какие-то заголовки (о том, что это только часть сообщения)? Если да, то какие?

Не очень понятно, о каких пакетах и идентификаторах идёт речь. Целостность потока данных TCP обеспечивается полем sequence number заголовка TCP (см. www.ietf.org/rfc/rfc793.txt п 3.1) и длиной принятых данных (вычисляется на основании поля total length из заголовка IP, см. tools.ietf.org/html/rfc791#section-3.1). А именно, каждый переданный байт данных — это +1 к sequence number. Начальный sequence number выбирается случайным образом при установке соединения, т.е. при приёме пакета с флагом SYN. В простейшем случае (без selective ack), каждое установленное соединение должно хранить sequence number ожидаемых данных и сравнивать его с полученным по сети sequence number; в случае их совпадения пропущенных данных нет.

Comments

[zTrue]

Я имел ввиду ip.identification (в схеме выше), вероятно, что-то напутал с терминологией

[jcmvbkbc]

ip.identification следует использовать только для сборки фрагментированных ip-пакетов, к TCP-сегментации и данным передаваемым внутри TCP соединения ip.identification имеет очень опосредованное отношение.

Answer 5

[merlin-vrn]

Пакеты, конечно, могут придти в разном порядке. Но вот ядро отдаст данные вашему приложению всегда в правильном порядке.

Т.е. даже если пришли пакеты с SEQ=1, и длиной 1000, а также SEQ = 2501 и длиной 500, то ядро понимая, что чего-то не хватает (пропущено 1500 байтов в середине — второй SEQ, т.е. номер байта, 2501, а мы пока что имели байты вплоть до 1000 включительно), не отдаст на прикладной уровень второй пакет. А по сети ядро будет отправлять ACK 1000, что он получил первый пакет, намекая, что там больше нету.

Как только придёт пакет с SEQ 1001 и какой-нибудь длиной, он будет отдан ядру. Пакет с SEQ=2501, хотя он у ядра давно уже есть, вашему приложению не будет отдан до тех пор, пока все 1500 байтов с номерами 1001 до 2500 включительно не дойдут, по скольким пакетом бы они ни были раскиданы (хоть 1500 пакетов по одному байту). Если в процессе передачи этих промежуточных пакетов произойдёт таймаут, то пакет с SEQ=2501 ваше приложение и не увидит никогда, хотя ядро системы-получателя его имело.

(Хочу обратить внимание на то, что пакеты не пронумерованы. Пронумерованы байты. Поле SEQ в пакете — последовательный номер первого байта данного пакета. Одна тонкость: нумерация начинается не с 0 и не с 1, а со случайного числа, которое определяется отправителем при установке соединения — в пакете с флагом SYN. Пример выше нужно понимать так, что SYN был с SEQ=1).

То есть, о том, что до вас не дойдут промежуточные пакеты, вы можете в случае с TCP не беспокоиться. Если вы на одном конце записали байты в сокет в определённом порядке, вы на другом конце или получите их в точно таком же порядке, или не получите вообще.

Comments

[merlin-vrn]

В вашем случае, поведение системы предсказать нельзя, т.е. вы предоставили недостаточно данных. Нужно было бы знать seqno пакета с флагом «syn»: 1, а вы такой пакет то ли не захватили, то ли забыли здесь указать.

Если предположить, что первый пакет в данном соединении реально «первый», то у syn-пакета в вашем случае seqno был равен 1455343061, и ваше приложение, слушающее сокет, не получит вообще никаких данных и событий от этого сокета (например, select(...) не вернётся, а если вернётся, то этот сокет не будет в нём readable), пока система не получит пакет с seq=1455343061, после получения которого она данные из него отдаст приложению, а сама добавит к этому числу размер пакета (в данном случае — 1440), и следующим приложению будут выданы данные из пакета с seqno = 1455343061+1440 = 1455344501, каким бы он по порядку ни пришёл из сети.

[themiron]

select еще как вернется. после fin, теоретизируя в цифрах — не забываем о rfc и их реализациях.
более того, у tcp syn (вы же о tcp, да?) не может быть произвольного seqno, это начало «потока».

[merlin-vrn]

Да, действителньно, я должен был написать так: select(...) не вернётся, а если вернётся, то этот сокет не будет в списке read_set, а если будет, то с ним будет связано событие, что соединение закрыто. Справедливости ради, как выяснилось, в node.js хорошо абстрагировано сетевое api и нет вообще никакого select, нас могут не понять :)

Так или иначе, данных в сокете не будет ни в каком другом случае, кроме «пришёл пакет с нужным seq».

По поводу seqno в syn-пакете: вы заблуждаетесь, он СЛУЧАЙНЫЙ. Он именно произвольный, какое-то число, которое произвольным образом выбрала передающая сторона. SYN-пакет и определяет в начале соединения: «вот этот номер считать началом отсчёта». Wireshark по умолчанию показывает относительные SEQ, вычисляется номер байта относительно SEQ в SYN-пакете, то есть SEQ-SEQ[SYN], и таким образом для SYN-пакета Wireshark покажет 0. Но там явно написано — «relative». Если вы посмотрите на дамп пакета, увидите там некое (в идеале) непредсказуемое число.

(Кстати, если система генерирует предсказуемые SEQ в SYN-пакетах, она окажется уязвимой для некоторых атак на стек TCP.)

Answer 6

[Sayonji]

По-видимому, вы получаете всё-таки сегменты, а не пакеты. В таком случае, если идет сегмент А, а за ним сегмент Б, то разность их идентификаторов (Sequence number) должна быть равна размеру окна (Window size) сегмента А. Если после упорядочивания это не так, значит что-то не пришло.

Comments

[jcmvbkbc]

разность их идентификаторов (Sequence number) должна быть равна размеру окна (Window size) сегмента А

Не размеру окна, а размеру данных в сегменте A. Размер окна — это максимальное количество данных, которые могут быть отправлены без подтверждения. И к тому же он работает в другую сторону: размер окна в пакетах которые мы получаем, означает сколько данных мы можем отправить принимающей стороне.

[Sayonji]

Да, ошибся с полем. Ниже уже поточнее рассказали.