Русские Блоги
Когда вы видите это приглашение, это означает, что помеченный пакет не захвачен. В качестве примера возьмем пакет № 4 на рисунке 1. Он имеет общую длину 171 байт, но были захвачены только первые 96 байт, поэтому Wireshark дал это приглашение.
Эта ситуация обычно вызвана перехватом пакетов. В некоторых операционных системах по умолчанию tcpdump захватывает только первые 96 байтов каждого кадра. Мы можем использовать параметр "-s", чтобы указать количество байтов, которые мы хотим захватить.
2.［TCP Previous segment not captured］
В процессе передачи по TCP сегмент данных, отправляемый одним и тем же хостом, должен быть непрерывным, то есть номер Seq последнего пакета равен Seq Len предыдущего пакета (три рукопожатия и четыре колебания являются исключениями). Если Wireshark обнаружит, что номер Seq следующего пакета больше, чем Seq Len предыдущего пакета, он знает, что часть данных отсутствует в середине. Если пропущенные данные не найдены во всем сетевом пакете (то есть неупорядоченные исключены), он выдаст запрос [Предыдущий сегмент TCP не захвачен]. Например, в примере на фиг.2 номер 1449 Seq пакета 6 больше, чем Seq Len = 1 0 = 1 пакета 5, что указывает на то, что пакет, несущий 1448 байтов в середине, не был перехвачен, это "Seq = 1, Len = 1448" .
Есть два случая, когда сетевой пакет не перехвачен: один действительно потерян, другой — то, что он фактически не потерян, но инструмент захвата пакетов пропустил его. Как отличить эти две ситуации в Wireshark? Просто посмотрите на подтверждение (Ack) от другой стороны. Если подтверждение содержит пакет, который не был перехвачен, то просто отсутствует инструмент захвата пакета, в противном случае он действительно потерян.
Кстати, проанализируйте сетевой пакет на рисунке 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.
9．[TCP window Full]
Когда Wireshark помещает флаг [TCP window Full] в пакет, это означает, что отправитель этого пакета исчерпал окно приема, объявленное другой стороной. Взяв в качестве примера рисунок 9, Британия всегда заявляла, что ее окно приема составляет всего 65535, а это означает, что Ближний Восток может отправлять ему максимум 65535 байтов данных без подтверждения, то есть «транзитные байты» не более 65535 байтов. Когда Wireshark находится в упаковкерасчетЭто сообщение будет отправлено, когда на Ближнем Востоке будет неподтверждено 65535 байт. Что касается того, как Wireshark вычисляет, пожалуйста, обратитесь к статье "Расчет" Количество байтов в пути "".
[TCP window Full] легко спутать с [TCP zerowindow], на самом деле они имеют сходство. Первый указывает, что отправитель этого пакета временно не может отправить данные, а последний указывает, что отправитель этого пакета временно не может получить данные, что означает, что оба означают, что передача приостановлена, и на оба следует обратить внимание.
10．[TCP segment of a reassembled PDU]
Когда вы получаете это приглашение, вы должны включить функцию Разрешить субсектору повторную сборку потоков TCP в меню Правка -> Параметры -> Протоколы -> TCP. Это означает, что Wireshark может виртуализировать TCP-пакеты, принадлежащие одному и тому же PDU прикладного уровня (например, SMB’s Read Response и Write Request). Как показано на рисунке 10, этот ответ чтения SMB завершается пакетами с 39 по 48, поэтому Wireshark фактически собирает все пакеты в последнем пакете. Преимущество этого заключается в том, что вы можете щелкнуть правой кнопкой мыши поле внизу рисунка 10 и выбрать «Копировать -> Байты -> Только для печати», чтобы скопировать весь PDU прикладного уровня. Студенты, занимающиеся исследованиями и разработками, могут нуждаться в этой функции больше.
Вы видите это приглашение, указывающее, что Разрешить субсектору повторную сборку потоков TCP была закрыта в меню Edit -> Preferences -> Protocols -> TCP. Например, пакеты на рисунке 10 становятся похожими на рисунок 11, когда они закрыты.
Если вы внимательно сравните рисунок 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.
Wireshark [TCP Window Full] & [Zero Window]
TCP sliding window is very crucial concept in understanding how TCP behaves. In order to see how this mechanism works, I have rate limited an HTTP download and observed what happens during this scenario in which we will see reports from Wireshark that [TCP Window Full] and [TCP ZeroWindow]. The aim of this post is to try to show how wireshark understands that Window is full.
We have a web server and a client machine on this setup. We intentionally rate limit the traffic by using wget to allow us investigate this scenario.
Yes we have downloaded the the file. During the download I also took packet capture on the client side. In order to understand the behaviour, first this rate limiting needs a bit of explanation. When you set the option “–limit-rate” on wget, software in order to sustain the throughput you set, sends a TCP segment with Window Size set to 0 which literally instructs the sender to pause. As my aim is to try to understand how Wireshark notices window full situation, we are starting to investigate the packet capture right after client sends a TCP ACK with Window Size zero.
We should better zoom into particular time frame in order to understand this event easier as the whole story is developed between Pkt 181 and Pkt 200 in this capture. You need to take a look at this screenshot before going further in the article since it shows how we go from “Window Zero” to Window full state.
Packet no: 181 is sent from client with Win=0 as you can see. At that particular moment, sender knows that it isn’t allowed to send any more packets.
Packet no: 182 client this time decides to accept packets because of which sets the WindowSize to 22656 (Win=22656). What does this mean practically? As window size is a number which tells the sender that “You can send this number of bytes without expecting any acknowledgement from me“, sender resumes sending segments as fast as it can from this point on.
Packet no: 183 – 197 In a normal TCP communication you don’t see this number of segments which aren’t acknowledged. This is because of our rate limiting actually.
Now we stop the clock right after packet 197 is received i.e T=0.653210000 and take a closer look at the status of the window or we somehow take a snapshot of the receive window at this point.
Have you stopped the clock at Time = 0.653210000. Remember! client had told sender that your window is 22656Bytes. You can only send this amount with no ACK from me. What we see here is that packets from 183 to 197 didn’t receive any ACK from client (receiver). Hence number of bytes sent but not ACKed are 20272Bytes. This means sender can send 22656 – 20272 = 2280Bytes more and if doesn’t receive any feedback(ACK), then it will stop.
Packet 198: but something happens here. Receiver(client) decides to acknowledge some of the bytes by setting ACK=4109684389. What does really this mean? With this single number, Receiver is telling the Sender that “I have received all the bytes up to this byte”. By this announcement, Receiver has actually acknowledged Pkt 183 sent from the sender. Not clear? Maybe I can show it like this. Let’s open the bytes on Pkt 183 and see how the bytes are counted.
SEQ number (4109683925) is the first byte in the TCP segment which is an inclusive number and our packet’s TCP payload has 464 bytes which means the last byte number is (4109684388). Hence on the ACK Pkt 198, receiver says that it is acknowledging the last byte 4109684388 by setting the ACK to 4109684389. It is important to understand that ACK number is the next expected sequence number of the TCP segment from the other side.
Now what happens. This is really important to understand the whole topic. At the beginning of the transaction on Pkt 183, receiver had set the Window to 22656 but now on this latest ACK (Pkt 198), it is reducing the window size further to 22272 (Win=22272) hence sender should send less bytes and the below image shows both how window is sliding and reduced at the same time.
What does this snapshot of the Receive window mean?
It means sender can send 2000 Bytes more without any acknowledgement from the receiver.
Pkt 199 (1448 Bytes) and Pkt 200 (552 Bytes) are sent from the sender which fills this usable window 2000Bytes. Therefore there isn’t any available space left in the receive window and Wireshark immediately detects and displays you the message [TCP Window Full]
I must say that it is really cool! Wireshark is doing a wonderful job to help people troubleshooting network issues.
I am hoping I haven’t done any conceptual mistake here. This is how I understand this behaviour. If you have anything to add or correct, please do let me know.
7.5. TCP Analysis
By default, Wireshark’s TCP dissector tracks the state of each TCP session and provides additional information when problems or potential problems are detected. Analysis is done once for each TCP packet when a capture file is first opened. Packets are processed in the order in which they appear in the packet list. You can enable or disable this feature via the “Analyze TCP sequence numbers” TCP dissector preference.
Figure 7.5. “TCP Analysis” packet detail items
 |
TCP Analysis flags are added to the TCP protocol tree under “SEQ/ACK analysis”. Each flag is described below. Terms such as “next expected sequence number” and “next expected acknowledgement number” refer to the following»:
TCP ACKed unseen segment
Set when the expected next acknowledgement number is set for the reverse direction and it’s less than the current acknowledgement number.
TCP Dup ACK <frame> # <acknowledgement number>
Set when all of the following are true:
- The segment size is zero.
- The window size is non-zero and hasn’t changed.
- The next expected sequence number and last-seen acknowledgment number are non-zero (i.e. the connection has been established).
- SYN, FIN, and RST are not set.
TCP Fast Retransmission
Set when all of the following are true:
- This is not a keepalive packet.
- In the forward direction, the segment size is greater than zero or the SYN or FIN is set.
- The next expected sequence number is greater than the current sequence number.
- We have more than two duplicate ACKs in the reverse direction.
- The current sequence number equals the next expected acknowledgement number.
- We saw the last acknowledgement less than 20ms ago.
Supersedes “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”.
TCP Keep-Alive
Set when the segment size is zero or one, the current sequence number is one byte less than the next expected sequence number, and any of SYN, FIN, or RST are set.
Supersedes “Fast Retransmission”, “Out-Of-Order”, “Spurious Retransmission”, and “Retransmission”.
TCP Keep-Alive ACK
Set when all of the following are true:
- The segment size is zero.
- The window size is non-zero and hasn’t changed.
- The current sequence number is the same as the next expected sequence number.
- The current acknowledgement number is the same as the last-seen acknowledgement number.
- The most recently seen packet in the reverse direction was a keepalive.
- The packet is not a SYN, FIN, or RST.
Supersedes “Dup ACK” and “ZeroWindowProbeAck”.
TCP Out-Of-Order
Set when all of the following are true:
- This is not a keepalive packet.
- In the forward direction, the segment length is greater than zero or the SYN or FIN is set.
- The next expected sequence number is greater than the current sequence number.
- The next expected sequence number and the next sequence number differ.
- The last segment arrived within the calculated RTT (3ms by default).
Supersedes “Spurious Retransmission” and “Retransmission”.
TCP Port numbers reused
Set when the SYN flag is set (not SYN+ACK), we have an existing conversation using the same addresses and ports, and the sequencue number is different than the existing conversation’s initial sequence number.
TCP Previous segment not captured
Set when the current sequence number is greater than the next expected sequence number.
TCP Spurious Retransmission
Set when all of the following are true:
- In the forward direction, the segment length is greater than zero or the SYN or FIN is set.
- This is not a keepalive packet.
- The segment length is greater than zero.
- Data for this flow has been acknowledged. That is, the last-seen acknowledgement number has been set.
- The next sequence number is less than or equal to the last-seen acknowledgement number.
TCP Retransmission
Set when all of the following are true:
- This is not a keepalive packet.
- In the forward direction, the segment length is greater than zero or the SYN or FIN is set.
- The next expected sequence number is greater than the current sequence number.
TCP Window Full
Set when the segment size is non-zero, we know the window size in the reverse direction, and our segment size exceeds the window size in the reverse direction.
TCP Window Update
Set when the all of the following are true:
- The segment size is zero.
- The window size is non-zero and not equal to the last-seen window size.
- The sequence number is equal to the next expected sequence number.
- The acknowledgement number is equal to the last-seen acknowledgement number.
- None of SYN, FIN, or RST are set.
TCP ZeroWindow
Set when the window size is zero and non of SYN, FIN, or RST are set.
TCP ZeroWindowProbe
Set when the sequence number is equal to the next expected sequence number, the segment size is one, and last-seen window size in the reverse direction was zero.
[TCP ZeroWindow], [TCP Window Update], [TCP Window Full] displayed on Wireshark – cause & countermeasure
I summarized the display related to «TCP Window» which is frequently observed with Wireshark.
What is TCP Window
The TCP Window associated with these displays is an implementation of TCP flow control .
To put it briefly, from the standpoint of receiving data , it is reasonable to control the problem of «It is inefficient even if a small amount of information is sent even though a large amount of data can be handled even though it can be handed off» It’s a way to send it to your opponent with speed.Please refer to this page for details.
The situation indicated by [TCP ZeroWindow]
[TCP ZeroWindow] will be transmitted because the data receiver side informs the sender that «Since it can not be processed anymore, wait for it to be sent once «.Specifically, it is displayed when a packet with TCP «Window field» set to 0 is observed along with Ack with the other party.
The situation indicated by [TCP Window Update]
On the other hand, the transmission of [TCP Window Update] tells the sender that «You can process the buffer, so please resume transmission! «Specifically, it is displayed when packets with the same ACK number as ZeroWindow and the numerical value of its own receive buffer is set in TCP «Window field».
Even within normal TCP exchanges, Window’s update is done, but this is displayed when updating when there is no business to send to the other party (Ack for the last received data has also been sent) I will.
The situation indicated by [TCP Window Full]
Finally, [TCP Window Full] , this is the situation that the sending side «has sent off to the limit of the receiving buffer on the receiving side «.This is because Wireshark calculates Window and transmission volume, it grasps the situation and displays it bothers me.Expert Info will show » tcp window specified by the receiver is now completely full «.
What are the situations where these three indications occur frequently
There are two possibilities.
Processing on the receiving side is merely slow
One is simply that «the buffer on the data receiving side overflows, tells the sender to stop sending data (ZeroWindow), when the buffer is created it tells its capacity (Window Update) and before the client side handles it The sending side sends it to the limit of buffer capacity.»
In other words, it is the case that the processing capacity of the data receiving side is very slow compared to the network speed .
In this case, there is no other way to raise specs on the data receiving side.
The data receiving side is controlling the bandwidth
The other is the possibility that the client intentionally created such a condition for bandwidth control.
Specifically, this depends on how to create the application’s TCP / IP socket API. For example, if you add the «—limit — rate» option with curl or wget command, or «—bwlimit» with the rsync command, When downloading a certain amount , etc., the client repeats these series of operations to control the speed.
The following is an example of limiting the speed to 100 kbps with curl command.