tcp segment of a reassembled pdu wireshark что это
Tcp segment of a reassembled pdu wireshark что это
Network protocols often need to transport large chunks of data which are complete in themselves, e.g. when transferring a file. The underlying protocol might not be able to handle that chunk size (e.g. limitation of the network packet size), or is stream-based like TCP, which doesn’t know data chunks at all.
In that case the network protocol has to handle the chunk boundaries itself and (if required) spread the data over multiple packets. It obviously also needs a mechanism to determine the chunk boundaries on the receiving side.
Wireshark calls this mechanism reassembly, although a specific protocol specification might use a different term for this (e.g. desegmentation, defragmentation, etc).
7.8.2. How Wireshark Handles It
For some of the network protocols Wireshark knows of, a mechanism is implemented to find, decode and display these chunks of data. Wireshark will try to find the corresponding packets of this chunk, and will show the combined data as additional pages in the “Packet Bytes” pane (for information about this pane. See Section 3.20, “The “Packet Bytes” Pane”).
Figure 7.8. The “Packet Bytes” pane with a reassembled tab
 |
Reassembly might take place at several protocol layers, so it’s possible that multiple tabs in the “Packet Bytes” pane appear.
You will find the reassembled data in the last packet of the chunk.
For example, in a HTTP GET response, the requested data (e.g. an HTML page) is returned. Wireshark will show the hex dump of the data in a new tab “Uncompressed entity body” in the “Packet Bytes” pane.
Reassembly is enabled in the preferences by default but can be disabled in the preferences for the protocol in question. Enabling or disabling reassembly settings for a protocol typically requires two things:
The tooltip of the higher level protocol setting will notify you if and which lower level protocol setting also has to be considered.
7.8.3. TCP Reassembly
Protocols such as HTTP or TLS are likely to span multiple TCP segments. The TCP protocol preference “Allow subdissector to reassemble TCP streams” (enabled by default) makes it possible for Wireshark to collect a contiguous sequence of TCP segments and hand them over to the higher level protocol (for example, to reconstruct a full HTTP message). All but the final segment will be marked with “[TCP segment of a reassembled PDU]” in the packet list.
Disable this preference to reduce memory and processing overhead if you are only interested in TCP sequence number analysis (Section 7.5, “TCP Analysis”). Keep in mind, though, that higher level protocols might be wrongly dissected. For example, HTTP messages could be shown as “Continuation” and TLS records could be shown as “Ignored Unknown Record”. Such results can also be observed if you start capturing while a TCP connection was already started or when TCP segments are lost or delivered out-of-order.
To reassemble of out-of-order TCP segments, the TCP protocol preference “Reassemble out-of-order segments” (currently disabled by default) must be enabled in addition to the previous preference. If all packets are received in-order, this preference will not have any effect. Otherwise (if missing segments are encountered while sequentially processing a packet capture), it is assumes that the new and missing segments belong to the same PDU. Caveats:
Regardless of the setting of these two reassembly-related preferences, you can always use the “Follow TCP Stream” option (Section 7.2, “Following Protocol Streams”) which displays segments in the expected order.
Русские Блоги
TCP segment of a reassembled PDU
Приглашение «Сегмент TCP повторно собранного PDU» часто появляется при захвате пакета wireshark под Windows:
Вы можете использовать Edit-> Preferences-> Protocols / TCP-> Разрешить подразделу Wireshark для повторной сборки потоков TCP, чтобы снять этот флажок, чтобы исключить запрос:
В большинстве перепечатанных статей в Интернете утверждается, что порядковый номер ACK сегмента TCP повторно собранного PDU одинаков, поэтому запрос на отображение фактически не связан с ACK.
Ключом к проблеме является то, что длина пакета составляет 2194 байта, что превышает размер MTU 1500, поэтому сегмент TCP запрашивается.
MTU Max Transmit Unit, 1500, можно посмотреть через ifconfig
MSS Max Segment Size，1460=1500-20-20
PDU Protocol Data Unit
Максимальная длина пакета, передаваемого NIC, составляет 1514 байт = MTU + Ether = 1500 + 14.
Возникает вопрос: почему сообщение размером 2194 байта нормально и почему оно не фрагментировано по IP?
Поскольку современная ОС поддерживает функцию разгрузки сети (TSO), сетевой адаптер заменяет ЦП для реализации сегментации и объединения пакетов, экономя системные ресурсы и позволяя системе обрабатывать больше соединений.
TSO TCP Segment Offload
LSO Large Segment Offload
GSO Generic Segment Offload
LRO Large Receive Offload
RSC Receive Segment Coalescing
Когда стек протокола TCP отправляет большие блоки данных, NIC выполняет сегментацию. Поскольку оборудование адаптера может выполнять сегментацию данных намного быстрее, чем программное обеспечение операционной системы, эта функция может улучшить производительность передачи. Кроме того, адаптер использует меньше ресурсов процессора.
Процесс противоположен отправке. Сетевая карта объединит полученные данные в большой пакет данных и затем отправит их в стек протоколов TCP / IP. Как показано на рисунке, Wireshark работает между NIC и стеком протоколов, собирая данные на сетевой карте, в это время длина пакета данных может быть больше, чем MTU.
Почему один (?) Пакет TCP разделен на несколько блоков PDU здесь?
Фото связано:
Почему эти сегменты помечены как отдельные пакеты (все Ack, Seq = 509)? Почему пакет разбился?
3 ответа 3
Я не вижу изображения, но протокол более низкого уровня (скажем, Ethernet) может разбить протокол более высокого уровня (скажем, пакет TCP) на фрагменты в зависимости от размера его MTU (Maximum Transmission Unit).
Википедия определяет протокольную единицу данных следующим образом:
В телекоммуникациях термин протокольный блок данных (PDU) имеет следующие значения:
PDU имеют отношение к каждому из первых 4 уровней модели OSI (уровень 5 и выше называются данными).
Иногда пакет не будет доставлен одним куском. Вместо этого пакет поступает в виде нескольких протокольных блоков данных (PDU). WireShark попытается собрать эти блоки обратно в один пакет. Такой пакет называется повторно собранным PDU.
При работе с повторно собранным PDU дисплей будет не так хорош, как обычный пакет. Заголовки ответа находятся в нижней части рисунка 2.11.
Это означает, что это сегменты сообщения TCP/IP и что обычно только последний сегмент имеет значимую и полную информацию о сообщении TCP/IP.
Вы можете отключить повторную сборку сегментов TCP, сняв флажок «Разрешить подразделу разбивать потоки TCP» в настройках протокола TCP. Таким образом, все части PDU приложения будут отображаться самостоятельно.
Это способ гарантировать, что все сегменты будут содержать всю информацию, необходимую для осмысленного отображения сегмента TCP/IP, а не только последний пакет.
Я предполагаю, что вы имеете в виду видимые кадры в диапазоне 56-78.
Давайте решать вещи в таком порядке,
Если вы перепроверите свой исходный файл захвата, вы должны найти кадры с 54 по 67, у которых TCP-порт источника 80 (для HTTP) добавит к 9646 байтовым ответным данным с HTTP-сервера.
Здесь вы видите ответ размером 9 КБ от HTTP-сервера, попадающего в ваш браузер в виде нескольких ограниченных MTU сегментов TCP, каждый из которых был подтвержден стеком TCP вашей ОС.
Это высокоуровневая последовательность общения.
Вы можете прочитать больше об обработке сборки Wireshark TCP в Wireshark Wiki.
TCP_Reassembly
TCP Reassembly
Wireshark supports reassembly of PDUs spanning multiple TCP segments for a large number of protocols implemented on top of TCP. These protocols include, but are not limited to, iSCSI, HTTP, DNS, Kerberos, CIFS, ONC-RPC etc. All in all probably something like 20 different protocols. The support to do this is very easy to add to Wireshark if required for new protocols, so if your favorite protocol is missing, please give the Wireshark developers a shout.
Note that TCP Reassembly ONLY works if you capture the entire packet and if all the checksums for that packet are valid. If you use packet slicing and only capture parts of the packets OR if the packets have incorrect checksums, i.e. TCP_Checksum_Verification fails, then the packets will be ignored and reassembly will fail. (You can disable the TCP_Checksum_Verification test in preferences.)
Preferences
To enable this feature you must enable the preference :
This option will enable the TCP layer to perform reassembly of PDUs spanning multiple segments for all protocols that request it.
Note that this is not sufficient in itself, this preference above is the master switch to enable it on the TCP layer, you will also have to make sure that the protocol specific reassembly option is enabled as well.
The protocol specific reassembly option for HTTP are these:
If for example you want to reassemble HTTP PDUs spanning multiple segments you must thus enable all three options above.
Warning : memory is consumed like there is no tomorrow
This feature requires a lot of memory so it is always disabled by default. I advise that if you use it, only enable it temporarily when you absolutely need to and leave it off for the rest of the time. (You can not imagine how much memory is required if you accidentally leave it on and then load a 1GByte trace into wireshark)
Example
This is an example of how to reassemble a HTTP stream and to extract and save to a file a JPEG image from inside a HTTP PDU.
First download the example capture SampleCaptures/http_with_jpegs.cap.gz from the SampleCaptures page.
Then enable all three preferences above.
Then select packet #479 and click on the JPEG protocol to select it:
Then just right click on the JPG protocol and select «Export Selected Bytes» and save it to a file. If everything worked, you will now have a nice JPEG of the Dolphin Show at SeaWorld in SurfersParadise to view for your enjoyment.
(It seems reassembly of HTTP packets consume an enormous amount of CPU. There must be something suboptimal in the implementation and someone should have a look at it. It also likes to rescan the capture list several times when selecting one such packet.)
Preference String
Allow subdissector to desegment TCP streams
TCP_Reassembly (последним исправлял пользователь GeraldCombs 2009-04-23 18:12:58)
Русские Блоги
Анализ пакетов Wireshark
Замечания по исследованию Wireshark и анализ результатов захвата пакетов
1．[Packet size limited during capture]
Когда вы видите это приглашение, это означает, что помеченный пакет не захвачен. В качестве примера возьмем пакет № 4 на рисунке 1. Он имеет общую длину 171 байт, но были захвачены только первые 96 байт, поэтому Wireshark дал это приглашение.
Эта ситуация обычно вызвана перехватом пакетов. В некоторых операционных системах по умолчанию tcpdump захватывает только первые 96 байтов каждого кадра. Мы можем использовать параметр «-s», чтобы указать количество байтов, которые мы хотим захватить.
2.［TCP Previous segment not captured］
Кстати, проанализируйте сетевой пакет на рисунке 2, который был перехвачен клиентом при ненормальной передаче HTTPS. Поскольку небольшой пакет «Len: 667» (то есть пакет 6) может быть доставлен, но большой пакет «Len: 1448» потерян, что указывает на то, что на пути может быть сетевое устройство с меньшим MTU, и он отбросит большой пакет. Более поздние решения подтвердили это предположение, пока MTU всего сетевого пути оставался неизменным, проблема исчезла.
3．[TCP ACKed unseen segment]
Указывает, что пакет TCP ACK был перехвачен, но фактические данные, полученные и подтвержденные, не были перехвачены. Это, вероятно, самый распространенный совет Wireshark, но, к счастью, он почти всегда незначителен. Взяв рисунок 3 в качестве примера, Seq Len = 6889 1448 = 8337 для пакета 32, указывая, что следующий пакет, отправленный сервером, должен быть Seq = 8337. То, что мы видим, является Seq = 11233 пакета 35, что означает, что данные с 8337 по 11232 не были захвачены. Этот фрагмент данных должен был появиться до 34-го числа, поэтому Wireshark запросил [TCP ACKed unseen segment].
Нетрудно представить, что вы часто будете видеть это приглашение в начале сетевого пакета, потому что перехватывается только обратный Ack, а передний пакет не перехватывается.
Во время передачи TCP (исключая трехстороннее рукопожатие и четырехстороннюю волну) пакеты данных, отправленные одним и тем же хостом, должны быть непрерывными, то есть номер Seq последнего пакета равен Seq Len предыдущего пакета. Можно также сказать, что Seq последнего пакета будет больше или равно Seq предыдущего пакета. Когда Wireshark обнаружит, что номер Seq следующего пакета меньше, чем Seq Len предыдущего пакета, он будет считаться неупорядоченным, поэтому будет выдан запрос [TCP Out-of-Order]. Как показано на рисунке 4, Seq = 2685642 для пакета 3362 меньше, чем Seq = 2712622 для пакета 3360, поэтому он вышел из строя.
Беспорядок малого промежутка имеет небольшой эффект: например, если исходный порядок равен 1, 2, 3, 4 и 5, а пакеты разбиты на 2, 1, 3, 4, 5, все будет хорошо. Однако непоследовательность с большим промежутком может инициировать быструю повторную передачу, например, когда она перетасовывается в 2, 3, 4, 5, 1, будет запущено достаточное количество Dup ACK, что приведет к повторной передаче пакета 1.
В случае нарушения порядка или потери пакетов получатель получит некоторые пакеты с номерами Seq, превышающими ожидаемые. Он будет подтверждать ожидаемое значение Seq каждый раз, когда получает такой пакет, таким образом, чтобы напомнить отправителю, поэтому он генерирует некоторый дубликат Ack. Wireshark пометит [TCP Dup ACK] на этом повторном подтверждении.
Взяв рисунок 5 в качестве примера, 7-й пакет, полученный сервером, представляет собой «Seq = 29303, Len = 1460», поэтому он ожидает, что следующий пакет должен быть Seq Len = 29303, 1460 = 30763, но не ожидал, что он фактически получил 8-й Пакет Seq = 32223 указывает, что пакет с Seq = 30763 может быть потерян. Поэтому сервер немедленно отправил Ack = 30763 на 9-й пакет, указав «Я хочу Seq = 30763». Поскольку 10-е, 12-е и 14-е, полученные сервером, больше, чем Seq = 30763, он будет отвечать Ack = 30763 каждый раз, когда его получает 1. Из рисунка видно, что Wireshark пометил эти ответы [ TCP Dup ACK.
6．[TCP Fast Retransmission]
Когда отправитель получает 3 или более [TCP Dup ACK], он понимает, что ранее отправленный пакет может быть потерян, поэтому он быстро ретранслирует его (это правило RFC). Взяв рисунок 6 в качестве примера, клиент получает 4 Ack = 991851, поэтому он повторно передает Seq = 991851 в пакете 1177.
Если пакет действительно потерян, и нет последующего пакета, который может вызвать [Dup Ack] в приемнике, он не будет повторно передан быстро. В этом случае отправитель должен ждать тайм-аута для повторной передачи, и такие пакеты повторной передачи будут помечены [TCP Retransmission] Wireshark. Взяв рисунок 7 в качестве примера, после того, как клиент отправил исходный пакет (номер пакета 1053), он не может ждать соответствующего Ack, поэтому он может быть повторно передан только после более чем 100 миллисекунд (пакет номер 1225).
Сверхурочная ретрансляция является очень технической точкой знаний. Например, продолжительность времени ожидания очень усвоена. Эта статья не будет детализирована. В конце концов, очень мало людей, которые должны это понимать.
«Win =» в пакете TCP представляет размер окна приема, которое указывает, сколько буферной области отправитель этого пакета может в настоящее время принимать данные. Когда Wireshark находит в пакете «win = 0», он помечает его как «нулевое окно TCP», указывая, что область буфера заполнена и больше не может принимать данные. Например, на рисунке 8 показано, что буфер сервера заполнен, поэтому уведомите клиента, чтобы он больше не отправлял данные. Мы даже можем видеть, как процесс его окна постепенно уменьшается с 3258 до 3263 пакетов, то есть с win = 15872 до win = 1472.
Когда Wireshark помещает флаг [TCP window Full] в пакет, это означает, что отправитель этого пакета исчерпал окно приема, объявленное другой стороной. Взяв в качестве примера рисунок 9, Британия всегда заявляла, что ее окно приема составляет всего 65535, а это означает, что Ближний Восток может отправлять ему максимум 65535 байтов данных без подтверждения, то есть «транзитные байты» не более 65535 байтов. Когда Wireshark находится в упаковкерасчетЭто сообщение будет отправлено, когда на Ближнем Востоке будет неподтверждено 65535 байт. Что касается того, как Wireshark вычисляет, пожалуйста, обратитесь к статье «Расчет» Количество байтов в пути «».
[TCP window Full] легко спутать с [TCP zerowindow], на самом деле они имеют сходство. Первый указывает, что отправитель этого пакета временно не может отправить данные, а последний указывает, что отправитель этого пакета временно не может получить данные, что означает, что оба означают, что передача приостановлена, и на оба следует обратить внимание.
10．[TCP segment of a reassembled PDU]
Если вы внимательно сравните рисунок 10 и рисунок 11, вы обнаружите, что ответ Read считан в заголовке пакета № 48 на рисунке 10 и рассчитан в заголовке пакета № 39 на рисунке 11. Это приведет к странному результату: время отклика на чтение, показанное на рисунке 10, составляет 2,528 миллисекунды (разница во времени между пакетами 38 и 48), а время отклика на чтение, показанное на рисунке 11, составляет 2,476 миллисекунды (разница во времени между пакетами 38 и 39). ). Который правильный? На этот вопрос сложно ответить. Если вас интересует фактическая общая производительность, посмотрите на первое, если вы хотите проигнорировать потерю протокола TCP / IP и посмотреть на скорость ответа сервера, то посмотрите на второе. В некоторых особых случаях разница между ними очень велика, поэтому ее необходимо уточнить.
12．［Time-to-live exceeded (Fragment reassembly time exceeded)］
ICMP сообщает о многих видах ошибок, которые нетрудно понять, поэтому мы возьмем только одну из них в качестве примера. [Превышено время повторной сборки фрагмента] указывает, что отправитель этого пакета уже получил некоторые фрагменты, но по какой-то причине он не смог собрать. Например, на рисунке 12 некоторые пакеты, отправленные из Шанхая в Пекин, передаются фрагментами, а некоторые из них теряются в пути, поэтому пекинская сторона не может собрать его, поэтому она должна использовать эту ошибку ICMP для информирования шанхайской стороны.
2. Анализ результатов захвата пакетов
(tcp.flags.syn == 1) && (tcp.analysis.retransmission) Отфильтровать запросы на повторную передачу рукопожатия
Отслеживание потока tcp
10.21.4.33:58964 просит 10.11.2.17:8080 отключиться.
10.11.2.17: 8080 возвращает ACK для подтверждения 10.21.4.33: 58964.
10.11.2.17: 8080 запросил отключение от 10.21.4.33: 58964, tcp повторно передан.
10.21.4.33: 58964 и 10.21.4.33: 8080 происходит переподключение.
(tcp.flags.reset == 1) && (tcp.seq == 1) фильтрует запросы на повторное соединение
Отслеживание потока tcp
10.11.2.17: 8080 запрос на отключение от 10.21.4.33: 57614 не получил подтверждение ACK 10.21.4.33: 57614, что привело к непрерывной повторной передаче tcp.