Tcp previous segment not captured что это
TCP: Previous segment not captured, Is that a connectivity issue?
Hi guys, I’ve been analyzing the packets sent between one server (172.20.3.188) and some clients, after I put the capture on Wireshark and I saw that there is some messages that say «Protocol TCP. Previous segment not captured» and «TCP: ACKed segment that wasn’t captured (common at capture start)». Looking on the internet I found that is a connectivity issue, but I’m not so able to understand it at all. I was wondering if you can give me some ideas/advices about what could be happening. I uploaded the capture, here is the link, http://www.cloudshark.org/captures/416284356bd1.
asked 03 Oct ’13, 08:21
EduardoHzz
11 ● 1 ● 1 ● 4
accept rate: 0%
edited 04 Oct ’13, 23:36
grahamb ♦
19.8k ● 3 ● 30 ● 206
Clicking on the link gives a «404 Not Found»
Do I have to download any software to share this?, Let see if this does work http://www.cloudshark.org/captures/3ce0dafb3430
The messages just mean exactly what they say: one or more tcp segments were not captured.
This will happen if (a) a capture is started in the middle of a TCP «conversation» (obviously) or (b) one or more frames are dropped (not captured) during a capture.
(a) is normal (b) might happen for a number of reasons (e.g., machine which is running Wireshark is slow).
Looking at the capture:
It seems to me that you are having a problem with the actual capture: That is; there are significant gaps of 1 or more seconds in the capture (e.g. between frames 6967 and 6968).
This has to be a problem with the capture itself because the traffic on the various connections continues on; IOW the sending/receiving nodes think everything is OK; They are seeing the frames even if they are missing from the capture file.
Looking at the I/O graph (Statistics IO Graph) shows a number of obvious gaps.
So: answering your original question: This is a «capture» issue (which causes the «previous segment lost» & etc expert messages.
answered 03 Oct ’13, 09:00
Bill Meier ♦♦
3.2k ● 1 ● 8 ● 50
accept rate: 17%
PacketTrain.NET
Анализ сетевого трафика
Руководство по захвату сетевого трафика. Часть 2 – Скорость, дуплекс и дропы (Перевод)
В первой части серии мы прошлись взглядом по типичным схемам сетей Ethernet и различным ситуациям при захвате трафика. Поэтому в текущей статье (и во всех последующих!) я буду считать, что вы ознакомились с предыдущими частями. Сегодня давайте обсудим, в каком случае скорость интерфейса и режим дуплекса становятся очень важны, и что такое эти «дропы».
Скорость и дуплекс
Есть 2 режима дуплекса, которые можно встретить при работе с сетью Ethernet:
Ну так и что же случится, если одна сторона работает в режиме FDX, а вторая всего лишь в HDX? Ничего хорошего. Узел, который использует FDX, будет думать, что он спокойно может передавать данные когда только пожелает, не понимая, что это вызовет коллизию, если вдруг случится так, что HDX-сосед как раз в этот момент отправляет что-то свое. Называется такая ситуация «duplex mismatch». Что в результате? Скорость передачи упадет до совсем печального уровня (уточним: это считанные килобайты в секунду вместо мегабайтов в секунду на линке в 100 Мбит/с).
Интересный факт 1: Автосогласование
Иногда люди думают, что “10/100 автосогласование” на одной стороне окажется достаточно разумным алгоритмом, чтобы распознать параметры второй стороны, настроенной вручную. Типа: «так, я поставлю на одной стороне 100 Мбит/с + полный дуплекс самостоятельно, а вторая сторона должна это увидеть и подстроиться». Давайте рассмотрим это на примере. Сторона номер 1 (обычно коммутатор) настроена принудительно на “100/полный дуплекс”, сторона номер 2 (обычно ПК) – выставлена на “автосогласование”. Что получится? Правильно, несоответствие, именно этот duplex mismatch:
Почему так происходит? Сторона 2 (ПК, настроенный в “авто”), сообщает: «я могу 10Мбит/с полудуплекс; 10Мбит/с полный дуплекс; 100Мбит/с полудуплекс; 100Мбит/с полный дуплекс». Ну, то есть, перечисляет все свои возможные режимы. А что говорит сторона 1 – коммутатор? А вообще ничего, он же настроен жестко. Из-за этого ПК, который ничего не слышит, на всякий случай переходит в режим полудуплекса (предполагает худшее). И это ещё хорошо, что скорость он все же может обнаружить и все-таки выставит себе 100Мбит/с, а иначе мы бы получили полный сбой соединения – стороны с несогласованной скоростью порта не могут общаться вообще никак!
Поэтому существует такое правило: ставим или обе стороны на авто, или обе вручную! По крайней мере, так было, пока не вышла спецификация 1Гбит/с (IEEE 802.3z), которая содержит небольшое, но важное предписание сообщать о параметрах, даже если узел настроен статически вручную.
По этой причине в последнее время, когда все стали переходить на гигабит и больше, количество проблем с duplex mismatch пошло на убыль.
Интересный факт 2: Полудуплекс на гигабите!
Да, есть такой стандарт: 1Гбит/с, полудуплекс. Ходят слухи, что инженеры (естественно, зная, что полудуплекс – дело прошлого) все равно должны были описать этот режим, чтобы стандарт формально остался в группе 802.3. Которая называется «CSMA-CD», и где CD означает «Collision Detection», а для этого Collision Detection нужен полудуплекс, иначе откуда там взяться коллизиям? 🙂
Что? Опять про дуплекс?
Могу себе представить, что некоторые читатели, снова смотря на главу про полный/полудуплекс, скажут: «чувак, об этом надо было помнить лет 10-15 назад, но сейчас? Сейчас все на полном дуплексе!» Ну, во-первых, этот цикл создавался для начинающих. А, во-вторых, давайте зададим простой, но важный вопрос более знающим читателям:
Сможете ли вы захватить полностью загруженный гигабитный полнодуплексный канал, используя один такой же полнодуплексный порт гигабитной сетевой карты?
И ответ… нет, не сможете.
И так как я уверен, что многие сейчас чешут затылок в размышлениях, давайте углубимся в этот вопрос ещё немного, потому что это по-настоящему важно. Ключевое слово в моем вопросе – «полнодуплексный» гигабитный канал. Как мы помним, это значит, что узел может отправлять и получать данные одновременно.
Ну так что это означает, если мы говорим про гигабитный полнодуплексный канал? 1 гигабит в секунду на прием и 1 гигабит в секудну на отправку (а совсем не 500Мбит/с на прием и 500Мбит/с на отправку, как часто неправильно думают мои ученики на курсах по Wireshark). Итого, когда мы говорим про полнодуплексный гигабитный канал, по факту мы имеем дело с общей скоростью передачи 2 гигабита в секунду (да-да, конечно, если он полностью загружен). То же относится и к 10Гбит FDX – это по сути 20Гбит. 25Гбит означает 50Гбит, 40 означает 80, 100 означает 200, если мы имеем дело с полным дуплексом.
Но все же, и почему мы не сможем захватить такой канал одним портом гигабитной карты? Она же тоже полнодуплексная, правда?
Оно-то так, но карта захвата может только получать трафик, но не отправлять (точнее, не должна бы отправлять, или, по моему мнению, не должна отправлять ни в коем случае). Итак, скорость карты захвата на передачу нам становится полностью неважна и бесполезна. И все, что нас интересует – это скорость карты захвата на прием, а она равна 1 Гбит/с. Выходит, что такой карты мало, для того, чтобы захватить полнодуплексный гигабитный загруженный канал. Потому что он будет иметь в сумме скорость 2 Гбит/с. А мы сможем принять из них только 1 Гбит/с. Нам придется с этим столкнуться ещё позже, но если уже сейчас вы подумали «вот же…», то вы на правильном пути.
Захватываем преамбулу и протокол автосогласования
Захватить преамбулу и делимитер Ethernet-кадра, которые передаются перед самим кадром, практически невозможно. Может, удастся их увидеть на экране осциллографа в медленной сети (10Мбит/с), или получится захватить коллизию (смотрите в предыдущей статье).
А причина в том факте, что сетевая карта передает компьютеру только сами кадры. Ей незачем передавать также всякие служебные вещи, которые происходят где-то в проводах, потому что попросту эти вещи никому кроме самой сетевой карты не нужны и никакого смысла загружать ими ПК нет. Если все-таки очень хочется увидеть эти данные, понадобится как минимум специализированная (читайте: профессиональная и очень дорогая) карта захвата. Никакая обычная потребительская сетевая карта не позволит этого сделать.
Если вы обладатель профессиональной карты захвата совместно с TAP, то вы как минимум сможете захватить импульсы протокола автосогласования, как на рисунке ниже (это только часть, ещё многое происходит позже, но, как видите, эта часть происходит как раз перед переходом в состояние “link up”). Захватывался этот дамп на специализированном устройстве Network General S6040 в комбинации с полнодуплексным оптическим ТАР:
«Дропы»
«Дроп», он же «отброшенный пакет» – это пакет, который по факту был в сети и должен был быть захвачен, но не захватился. Разница «потерянного» (lost) и «отброшенного» (drop) пакетов в том, что потерянный пакет пропал где-то в сети (то есть, на входе нашего порта его уже не было), и в случае, если у нас ТСР, то такой пакет будет переотправлен заново отправителем. Если же пакет не захватился, в дампе отсутствует, но в сети он был, дошел до получателя и никуда по пути не пропал – то это «дроп» То есть отбросили его мы. Примерно ситуация с дропами выглядит так:
 |
| Пример дропов в дампе |
Если вы видите в Wireshark сообщение “TCP ACKed unseen segment” (это сообщение генерируется модулем-анализатором ТСР) – это верный признак дропов при захвате: Wireshark видит, что в дампе присутствует ACK (подтверждение) для какого-то пакета данных, а вот самого пакета не видит. Так как узел, участвующий в обмене данными, подтвердил прием, следовательно, пакет с данными дошел до получателя нормально. Просто этот пакет с данными не добрался до нас, до самого Wireshark’а. Всего две основных причины могут быть связаны с этим:
Но все же больше, чем в 95% случаев причиной “недолета” пакетов является первая – было недостаточно производительности устройства захвата. Кстати, ещё один признак дропов – это сообщения “TCP Previous segment not captured”, после которых нет переотправленных пакетов с данными. Подумайте об этом.
Причины дропов
Возможны несколько причин, но все они попадают в категорию «ваше устройство захвата было недостаточно быстро, чтобы захватить весь трафик без потерь». Дропы могут возникнуть по вине коммутатора, ответвителя ТАР, сетевой карты, жесткого диска и даже ЦП или памяти вашего ПК (к примеру, если ваш софт недостаточно оптимизирован). Подведем итог: всё, что угодно, – любое устройство или схема – которые находятся между пакетом в проводе и диском, куда пишется дамп, может стать причиной дропов. Что-то из этого виновато чаще, что-то реже. (Дорогие производители ТАР, следите за своим давлением, мы будем рассматривать ТАР позже, и тогда же уточним, почему дропы могут возникнуть и здесь).
В зависимости от ситуации, дропы могут иметь разную степень критичности.
Критичные дропы
Считаются таковыми, если вам нужна полная информация, и вы не можете себе позволить ни одного потерянного пакета. Зачастую это касается задач сетевой безопасности, когда необходима реконструкция контента, переданного по сети. Если у вас пропал один или несколько пакетов, которые были частью переданного вредоносного файла – вы уже не сможете этот файл полностью восстановить, и его реверс-инжиниринг будет невозможен (или как минимум затруднен).
В другой ситуации у вас может быть задача исследовать причину потерь пакетов – и дропы приведут вас к ложным выводам, просто потому, что вы думали, что пакет был потерян в сети (packet loss), а на самом деле он дропнулся на вашем устройстве захвата. (В случае с ТСР об этом хотя бы косвенно можно догадаться, как написано выше. А вот UDP и другие уже не дадут таких подсказок. – прим. перев.)
Некритичные дропы
Дропы могут раздражать, но быть не настолько критичными, если их влияние в конкретной задаче траблшутинга предсказуемо. Как правило, это требует навыка анализа выше среднего уровня, так как аналитик должен иметь достаточно опыта, чтобы найти причину сбоев даже в присутствии отвлекающих внимание паразитных дропов. Но эти товарищи могут увести неопытного аналитика по ложному пути.
Как пример можно взять анализ ТСР-соединения, которое страдает от симптома «низкая производительность (bad performance)». Здесь аналитик сможет пережить редкие дропы, потому что он видит, что TCP ACK на эти «как бы потерянные» пакеты есть, а значит, эти пакеты потеряли мы сами.
В обратном случае (исследование места реальных потерь пакетов в сети, packet loss), где задача – найти сбойное сетевое устройство, вызывающее потери, вы не можете себе позволить дропы, потому что они исказят всю картину. Вы можете быть не в состоянии разграничить, был ли этот пакет реально потерян кем-то другим, или виновник – вы же сами.
Несущественные дропы
Дропы становятся несущественными, если аналитику и так не нужен был каждый пакет. Например, если он делает снимок характеристик трафика в сети (baselining). Если просто нужно собрать некоторую статистику сети (например, распределение протоколов, «какой процент от всех пакетов у нас НТТР?»), вы можете запросто пережить дропы. Они особо не повлияют на конечный результат (ну, конечно, если у вас их не огромное количество) 🙂
Заключение
Да, я помню, что в первой части говорил, что сегодня мы рассмотрим и сетевые карты, но не хотелось бы делать очень длинную статью, и потому я отложил их на потом. Иначе пришлось бы сокращать другой материал, а это нежелательно. Зато теперь сетевые карты займут свою собственную целую статью.
Что стоит вынести из данной статьи:
– дропы могут быть как большой проблемой, так и не очень;
– полный дуплекс – это скорость больше, чем она кажется на первый взгляд, и если канал загружен, а у вас карта захвата только с одним портом…
Статья переведена и опубликована с разрешения автора (Jasper Bongertz) только для сайта packettrain.net
Использование материала статьи без согласования запрещено!
Tcp previous segment not captured что это
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.
For analysis of data or protocols layered on top of TCP (such as HTTP), see Section 7.8.3, “TCP Reassembly”.
Figure 7.7. “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 #
Set when all of the following are true:
TCP Fast Retransmission
Set when all of the following are true:
Supersedes “Out-Of-Order” 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:
Supersedes “Dup ACK” and “ZeroWindowProbeAck”.
TCP Out-Of-Order
Set when all of the following are true:
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 sequence 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
Checks for a retransmission based on analysis data in the reverse direction. Set when all of the following are true:
Supersedes “Fast Retransmission”, “Out-Of-Order”, and “Retransmission”.
TCP Retransmission
Set when all of the following are true:
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:
TCP ZeroWindow
Set when the receive window size is zero and none of SYN, FIN, or RST are set.
The window field in each TCP header advertises the amount of data a receiver can accept. If the receiver can’t accept any more data it will set the window value to zero, which tells the sender to pause its transmission. In some specific cases this is normal — for example, a printer might use a zero window to pause the transmission of a print job while it loads or reverses a sheet of paper. However, in most cases this indicates a performance or capacity problem on the receiving end. It might take a long time (sometimes several minutes) to resume a paused connection, even if the underlying condition that caused the zero window clears up quickly.
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.
If the single data byte from a Zero Window Probe is dropped by the receiver (not ACKed), then a subsequent segment should not be flagged as retransmission if all of the following conditions are true for that segment: * The segment size is larger than one. * The next expected sequence number is one less than the current sequence number.
This affects “Fast Retransmission”, “Out-Of-Order”, or “Retransmission”.
TCP ZeroWindowProbeAck
Set when the all of the following are true:
Supersedes “TCP Dup ACK”.
TCP Ambiguous Interpretations
Some captures are quite difficult to analyze automatically, particularly when the time frame may cover both Fast Retransmission and Out-Of-Order packets. A TCP preference allows to switch the precedence of these two interpretations at the protocol level.
Русские Блоги
Анализ пакетов 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.
Интеллектуальная рекомендация
[Leetcode Tour] Array-697. Степень массива
Добавить расширение Redis для PHP7 под Windows
1 Просмотр информации о версии PHP Непосредственно используйте функцию phpinfo (), вывод в браузер в порядке Результаты вывода, в основном, отображают следующую информацию: версия PHP, архитектура, сб.
неправильная причина: Первичный ключ сущности установлен в режим саморазвития, но первичный ключ идентификатора устанавливается для него при сохранении.
работа на прошлой неделе не особенно подходит для различных причин, рисунок слайдера имеет узкое и не будет завершена на этой неделе, но это хорошо, чтобы быть в разработке и продвижении персонажа и д.
Том Зибель технические книги рекомендуется
iOS разработка программного обеспечения 1. Опытный в Objective-C [США] Кит Ли, Су Баолонг Народная почта и телекоммуникационная пресса Эта книга подходит для некоторых разработчиков, которые уже начал.