Rst пакет что это
Русские Блоги
Посмотреть исходный текст (# ^. ^ #)
Что такое RST
Состав TCP-заголовка выглядит следующим образом:
При отправке пакета RST для закрытия соединения напрямую отбросьте буферный пакет и отправьте пакет RST. После получения пакета RST принимающей стороне не нужно отправлять пакет ACK для подтверждения.
При каких обстоятельствах появится пакет RST
GFW (Великий китайский файрвол)
Как только GFW обнаруживает, что в пакете данных есть конфиденциальная информация, он подделывает пакет данных RST и отправляет его подключенным сторонам.
Доступ к портам без ПРОСЛУШИВАНИЯ
A инициирует соединение с B, но соответствующий порт не отслеживается на B. В это время обработчик TCP в операционной системе B отправит пакет RST.
Примечание: если BACKLOG сервера заполнен, SYN-пакет клиента просто отбрасывается.Клиент показывает, что время ожидания соединения истекло, и сервер не будет отправлять пакет RST.
По истечении времени ожидания запроса был получен пакет другой стороны.
A создает сокет, устанавливает для параметра SO_RCVTIMEO значение 100 мс и отправляет пакет SYN на B, чтобы запросить соединение. B отвечает на пакет SYN-ACK нормально, но когда A получает этот пакет, период ожидания в 100 мс истек. В это время A отправит пакет RST B.
Приложение закрывает соединение, когда в буфере recv есть данные
После того, как A и B устанавливают соединение, A отправляет 5000 байт данных в B, но B читает только 4096 байт, а затем вызывает closesocket() В это время B отправит пакет RST к A.
Пакет данных получен на закрытом сокете
A и B успешно устанавливают соединение. Во время связи A внезапно теряет питание, а B в это время не знает. После перезапуска A предыдущая информация о соединении была потеряна. Когда он получил пакет данных от B, он выглядел сбитым с толку и мог только ответить B пакетом RST.
Тайм-аут NAT
Большинство наших устройств подвешены под устройством NAT, и устройство NAT отключит соединение после периода отсутствия обмена данными между взаимодействующими сторонами. Когда вы снова отправите пакет данных другой стороне, вы получите пакет RST.
Примечание. China Mobile 2G, время ожидания NAT 3G составляет 5 минут, China Telecom 3G больше 28 минут.
SO_LINGER вариант
После установки этой опции для сокета вызовите closesocket() В это время он напрямую отбрасывает незавершенные данные в буфере отправки и отправляет пакет RST другой стороне, чтобы закрыть соединение.
Включить быстрое восстановление TIME_WAIT под Linux
Измените параметры ядра в /etc/sysctl.conf:
Когда отметка времени полученного пакета SYN меньше, чем в последний раз, он будет RST.
Каждый TCP пакет несёт заголовок и в нем есть биты завершения соединения:
Хорошо это или плохо, так как красный сигнал не предвещает ничего хорошего? Все, конечно же, зависит от ситуации, когда они происходят.
TCP RST ACK – это нормальный и предусмотренный RFC 793 процесс разрыва соединения, но если их много и это оказывает влияние на производительность приложения и пользователей, то это бесспорно повод задуматься. Как всегда дьявол кроется в деталях и необходимо задать себе несколько вопросов.
В каком месте общения между устройствами происходит TCP Reset?
Если TCP Reset происходит в начале соединения, то это тоже не проблема для пользователя. На примере ниже мы запрашиваем файл с облака, но его уже там нет. Поэтому клиент дважды попытался его получить и оба раза сервер ответил TCP IP Reset.
Если TCP Reset происходит в середине процесса передачи данных, то потребуется дополнительный анализ, так как это может быть проблема на сервере, в приложении или даже клиенте. Пользователь запросил данные через браузер и затем закрыл его, не дожидаясь ответа. В данном случае будет однозначно отправлен TCP Reset.
Почему TCP RST отправлен сразу после SYN?
Причин может быть также несколько. Обычно это означает, что порт, по которому пытаются открыть соединение, недоступен. Сервер отключен, сервер занят или такой порт закрыт. Поэтому происходит сброс SYN и все.
Кто отправил TCP RST ACK?
Важно также понимать кто инициатор разрыва соединения. Клиент, сервер, сетевое оборудование внутри собственной инфраструктуры или на пути от провайдера (см. TTL, а также IP адрес отправителя). На все эти вопросы мы можем получить ответ, анализируя трафик с помощью анализатора протоколов.
Русские Блоги
Несколько случаев RST в TCP соединении (подробнее)
Несколько случаев RST в TCP соединении (подробнее)
Никто не должен сомневаться в том, что сейчас эпоха Интернета. Многие программисты должны учитывать при программировании различные проблемы, связанные с несколькими компьютерами, локальными и глобальными сетями. Следовательно, знание сети неизбежно для изучения. Автор всегда считал, что знания о сетях TCP / IP должны быть включены в систему знаний программистов.
В протоколе TCP RST означает сброс и используется для аварийного закрытия соединения. Он незаменим при разработке TCP. При отправке пакета RST для закрытия соединения вам не нужно ждать, пока все пакеты в буфере будут отправлены, просто отбросьте пакеты в буфере и отправьте пакет RST. После получения пакета RST принимающей стороне не нужно отправлять пакет ACK для подтверждения.
Фактически, в процессе сетевого программирования различные ошибки RST сложнее устранить и найти причину. Ниже я перечисляю несколько ситуаций, в которых может возникнуть RST.
1 порт не открыт
Порт серверной программы не открыт, и клиент подключается. Это самая распространенная и понятная ситуация. Эта ошибка может возникнуть при подключении через telnet к неоткрытому TCP-порту. Это связано с реализацией операционной системы. В некоторых случаях операционная система также полностью игнорирует эти запросы, отправленные на неоткрытые порты.
Например, в следующем случае хост 241 отправляет SYN-запрос хосту 114, указывая, что он хочет подключиться к порту 40000 хоста 114, но хост 114 вообще не открывает порт 40000, поэтому он отправляет RST на хост 241. Такая ситуация очень распространена. В частности, часто возникает постоянное появление RST после перезапуска дампа памяти серверной программы.
Конечно, это может быть не так на некоторых хостах операционной системы. Например, если хост WINDOWS7 отправляет запрос на подключение к несуществующему порту, хост не отвечает.
2 Истекло время ожидания запроса
Например, как следующее:
Есть 89 и 27 двух хостов. Хост 89 отправляет SYN хосту 27, указывая, что он хочет подключиться к порту 8888, и хост 27 отвечает хосту 89 SYN, указывающим, что он может быть подключен. Но хост 27 очень недружелюбен и каким-то образом отправил RST, чтобы указать, что я не хочу больше с вами связываться.
3 закрываются раньше
Посмотрите на две программы:
Этот раздел представляет собой простейший код сервера. Логика очень проста: прослушайте TCP-порт и создайте дочерний процесс для его обработки при подключении клиента. Обратите внимание на обработку в этом разделе вилки:
| 1 | char pcContent[4096]; |
| 2 | read(real_fd,pcContent,4096); |
| 3 | close(real_fd); |
Каждый раз просто прочтите первые 4096 байт сокета, а затем закройте соединение.
Затем посмотрите на клиентский код:
Этот код проще: он открывает сокет, затем подключается к серверу и отправляет 5000 байт. Только что мы посмотрели на код сервера, каждый раз он получает только 4096 байт, затем оставшиеся 4 байта, отправленные клиентом, не принимаются серверным приложением, и сокет сервера закрывается. В этом случае Что будет, или возьмите пакет и посмотрите.
Первые три строки представляют собой трехстороннее рукопожатие TCP. Начиная с четвертой строки, порт 49660 клиента отправляет 5000 байтов данных на порт 9877 сервера, а затем сервер отправляет ACK для подтверждения, а затем сервер отправляет Клиент отправил RST для отключения. Соответствует нашим ожиданиям.
4 Получать данные о закрытом сокете
Если сокет был закрыт, но все еще получает данные, также будет сгенерирован RST.
Клиент все еще отправляет данные после того, как сервер закрыл сокет. В это время сервер сгенерирует RST.
подводить итоги
Таким образом, в этой статье рассказывается о нескольких ситуациях, когда RST появляется в TCP-соединениях. На самом деле видов RST должно быть бесчисленное множество. Я буду постепенно собирать больше примеров и добавлять их в эту статью.
Интеллектуальная рекомендация
Генерация аудио PCM-данных в файлы WAV и MP3 с использованием FFMpeg
Справочник статей 1. Получить кодировщик и создать контекст декодера 2. Создайте аудио поток и выведите контекст обертки 3. Записать необработанные данные в файл Формат упаковки аудио WAV может хранит.
3. Wu Weida Machine Учебное примечание Полные сухие товары (глава 3: Линейный регрессионный обзор)
1053 Путь равного веса (30 очков)
1053 Путь равного веса (30 очков) Given a non-empty tree with root R, and with weight Wi assigned to each tree node Ti. The weight of a path from R to L&n.
1020 Tree Traversals
Главная мысль: Укажите количество узлов двоичного дерева, а также пост-порядок, результат прохождения среднего порядка и результат прохождения уровня. Идеи решения проблем: Подзадача о бинарном древе.
[OpenStack] Neenron Добавить ICMP и SSH правила (веб-интерфейс)
Вам нужно подготовить правила группы безопасности перед конфигурацией. Поскольку группа безопасности по умолчанию не позволяет Ping ICMP-пакеты и SSH удаленного входа в систему. Вам необходимо вручную.
Подробности пакета TCP RST
Почему первый пакет TCP не нуждается в подтверждении? Это потому, что отправитель RST будет продолжать отправлять RSTs каждый раз, когда он получает другой пакет с другой стороны?
на связанной заметке, Как может номер подтверждения в действительном первом пакете Быть 0?
3 ответов
на связанной заметке, Как может номер подтверждения в первом пакете быть 0?
поскольку сегмент с первым битом должен завершить соединение, не более того. Квитирования имеет смысл только тогда, когда соединение установлено и бит ACK установлен в индустрии. Получатель первого сегмента также должен рассмотреть возможность того, что клиент протокола приложения на другом конце был внезапно прерван и не имел возможность обработать неподтвержденные данные, которые были отправлены ему.
посмотреть RFC 793, стр. 15:
TCP RST packet-это удаленная сторона, сообщающая вам, что соединение, на которое отправляется предыдущий TCP-пакет, не распознается, возможно, соединение закрыто, возможно, порт не открыт, и что-то вроде этого.
вот мое мнение, так как соединение больше не является действительным, нет необходимости отвечать ACK. И поскольку удаленный узел не знает соединения, имеет смысл, что ACK в первом пакете равен 0.
TCP RST означает, что соединение недопустимо. Т. е. на удаленной стороне нет связанного сеанса. Этот пакет обычно отправляется, когда порт, который вы пытаетесь достичь, закрыт, как я знаю.
TCP FIN-это то, что отправляется, когда соединение собирается закрыть, и там вам нужно подтвердить.
Русские Блоги
Wireshark analysis art [описание чтения]
Wireshark analysis art [описание чтения]
1. Фактическая работа Wireshark
Анализ работы интерфейса
Один из трех приемов: просмотр статистики и атрибутивной информации
Одна из трех осей анализа производительности:
Определите, высокий или низкий расход, и не перегружен ли он
Второй из трех способов: просмотр и анализ экспертной информации.
Анализ производительности по трем осям:
Проверьте, есть ли такая информация, как примечания, предупреждения, ошибки, проверьте наличие связанных предупреждений и ошибок, оцените качество сети, нарушение повторной передачи и т. Д.
Три хитрости: просмотрите время ответа службы
Третий из трех приемов анализа производительности:
Проверьте время отклика службы для каждой операции, чтобы определить, не перегружена ли она.
Используйте относительные значения для seq вместо истинных значений
Правка-> Настройки-> Протоколы-> TCP, отметьте относительные порядковые номера.
Это относительное значение до включения.
Просмотр TCP StreamGraph
Проверьте ситуацию передачи данных, например, является ли передача ровной, есть ли TCP Zero Windows и т. Д.
Значение поля и подсказка
1，[Packer size limited during caputre]
2，[TCP ACKed unseen segment]
3，[TCP Previous segment not captured]
При передаче данных TCP, в дополнение к трехэтапному и четырехстороннему рукопожатию, сегмент данных, отправленный одним и тем же компьютером, должен быть непрерывным, то есть Seq следующего пакета равен Seq + Len предыдущего пакета. Это правильная ситуация; если Если будет обнаружено, что Seq последнего пакета больше, чем Seq + Len предыдущего пакета, это означает, что часть данных потеряна в середине. Если потерянные данные не найдены во всем сетевом пакете, Wireshark предложит [TCP Previous segment not captured] ，
В этой ситуации есть две возможности:
4，[TCP Out-of-Order]
При передаче данных TCP, в дополнение к трехэтапному и четырехэтапному рукопожатию, сегмент данных, отправленный одной и той же машиной, должен быть непрерывным, то есть Seq следующего пакета равняется Seq + Len предыдущего пакета, что должно быть правильным случаем; или Говорят, что Seq последнего пакета должен быть больше или равен Seq + Len предыдущего пакета. Если Wireshark обнаруживает, что Seq последнего пакета меньше, чем Seq + Len предыдущего пакета, то он считается неисправным, и он запрашивает [TCP Out-of-Order] 。
5，[TCP Dup ACK]
6，[TCP Fast Retransmission]
Когда отправитель получает 3 или более подряд [TCP Dup ACK] В то время я понял, что ранее отправленный пакет может быть потерян, поэтому он начнет быстро повторно передавать в соответствии с RFC. [TCP Dup ACK] Это получатель отвечает отправителю, поэтому отправитель может его воспринять и начать быструю повторную передачу, когда он получает более трех сообщений подряд.
Алгоритм быстрой повторной передачи предусматривает, что, пока отправитель получает 3 повторяющихся подтверждения подряд, он должен немедленно повторно передать сегмент сообщения, который другой стороной не получил, не дожидаясь истечения установленного времени счетчика повторной передачи.
7，[TCP Retransmission]
Если пакет действительно потерян, и никакие последующие пакеты не могут вызвать [Dup Ack] на получателе, тогда быстрая повторная передача не будет включена.В этом случае отправитель может только дождаться тайм-аута перед отправкой повторной передачи. Пакет будет отмечен wirehark и подсказкой [TCP Retransmission]
Тайм-аут TCP и повторная передача должны быть одними из самых сложных частей TCP. Тайм-аут повторной передачи является основой TCP для обеспечения надежной передачи. Когда TCP отправляет данные, данные и подтверждение могут быть потеряны, поэтому TCP решает эту проблему, устанавливая таймер при отправке. Если таймер переполняется и не получил подтверждения, он повторно передает данные. Ключевым моментом является стратегия тайм-аута и повторной передачи. Необходимо учитывать два аспекта:
В более поздних версиях ядра Linux, таких как 3.15, есть как минимум 9 таймеров: таймер повторной передачи тайм-аута, непрерывный таймер, таймер задержки ER, таймер PTO, таймер задержки ACK, таймер SYNACK, Таймер поддержания активности, таймер FIN_WAIT2, таймер TIME_WAIT.
8，[TCP zerowindow]
Как правило, размер окна следует постепенно уменьшать до заполнения буфера.
9，[TCP window Full]
[TCP window Full] и указанное выше [TCP zerowindow] легко перепутать. Первое означает, что отправитель этого пакета не имеет возможности отправлять какие-либо данные в данный момент; второй означает, что отправитель этого пакета больше не может получать данные; оба будут Приостановить передачу данных
10，[TCP segment of reassembled PDU]
Доступно только в меню Edit-> Preferences-> Protocols-> TCP Allow sub dissector to reassemble TCP streams После этого можно получить это приглашение. Это представление может виртуально собирать TCP-пакеты, принадлежащие одному PDU прикладного уровня.
11，[Continuation to #]
Закрывается только в меню Edit-> Preferences-> Protocols-> TCP Allow sub dissector to reassemble TCP streams После этого можно получить это приглашение.
12，[Time-to-live-exceeded(Fragment reasembly time execeeded)]
(Превышено время повторной сборки фрагмента) указывает на то, что отправитель этого пакета уже получил некоторые фрагменты раньше, но по некоторым причинам сборка задерживалась.
Например, если некоторые фрагменты потеряны во время передачи, получатель не может их собрать, а затем отправитель уведомляется этим методом ICMP.
Во-вторых, Wireshark анализирует протокол TCP.
Основы протокола захвата пакетов TCP
Поле управления TCP
На уровне TCP есть поле FLAGS со следующими идентификаторами: SYN, FIN, ACK, PSH, RST, URG.
Форма поля управления, отображаемого при захвате пакета, следующая:
[SYN]: установить соединение, запустить пакет [FIN]: закрыть соединение, завершить пакет [PSH]: передача данных DATA [ACK]: ответ ACK [RST]: RESET, сброс соединения
Два других часто используемых поля:
[Len]: длина пакета [Seq]: порядковый номер пакета.
ACK может использоваться одновременно с SYN, FIN и т. Д. Например, SYN и ACK могут быть 1 одновременно, это означает, что ответ после установления соединения, если это только один SYN, это означает, что установлено только соединение
Когда появляется пакет FIN или RST, мы думаем, что клиент отключен от сервера. Когда появляются пакеты SYN и SYN + ACK, мы думаем, что клиент установил соединение с сервером.
Направление захвата пакета (клиент или сервер)
TCP Ack
Например, ACK пакета 97 = 65701 и Seq + Len = 64273 + 1428 = 65701 пакета 96, тогда это означает, что ACK 97 является ответом на 96, то есть другие ACK до 96 не отображаются. Фактически, пакеты прошли ACK пакета 97, поэтому отправитель также знает, что все пакеты, отправленные до 96, были получены и подтверждены другой стороной.
MSL、TTL、RTT
RTT (время приема-передачи), что означает время, необходимое для передачи данных от клиента к серверу и обратно. TCP содержит алгоритм для динамической оценки RTT.
Разрешение MAC-адреса
Протокол = ARP Источник и место назначения имеют формат MAC-адреса, например 00: 60: 48: ff: 12: 31.
При анализе захвата пакетов, если сеть заблокирована, ACK не может быть получен и т. Д., Необходимо дополнительно проверить правильность MAC-адреса каждого пакета.Напротив, есть некоторые проблемы, вызванные несколькими MAC-адресами.
Протокол установления связи TCP и волновой протокол
Пакет трехстороннего подтверждения TCP и ответного суждения
Соглашение о трехстороннем рукопожатии
Захват пакетных данных, как определить, является ли пакет пакетом возврата предыдущего пакета? Согласно протоколу TCP, если значение Ack следующего пакета равно Seq + Len предыдущего пакета, это означает, что пакет возвращается.
Во время трехстороннего рукопожатия все MSS будут объявлены друг другу.
ПТС четыре раза махнул и трижды
Четырехволновой протокол TCP
Обычно таких волн будет четыре, но если есть задержка с подтверждением, тогда четыре волны станут тремя волнами, сохраняя вторую сумку из четырех волн.
Алгоритм контроля перегрузки TCP
Количество байтов в пути
Перегрузка сети
Окно отправки
Алгоритм TCP Nagle и отложенный ACK
Это необходимо для уменьшения количества небольших пакетов в глобальной сети, тем самым уменьшая вероятность перегрузки сети;
Преимущество этого алгоритма в том, что он адаптивен. Чем быстрее приходит подтверждение, тем быстрее будут отправлены данные. В низкоскоростной глобальной сети, которая хочет уменьшить количество небольших пакетов, будет отправлено меньше пакетов;
Если tcp отправляет подтверждение подтверждения для каждого пакета данных, то отправка подтверждения для одного пакета данных обходится дороже, поэтому TCP будет задерживаться на определенный период времени. Если в течение этого периода на противоположный конец будут отправлены данные, они будут отправлены с совмещением. ack, если будет обнаружено, что подтверждение не было отправлено при срабатывании таймера отложенного подтверждения, оно будет отправлено отдельно немедленно;
Преимущества отложенного ACK:
(1) Избегайте синдрома запутанного окна; (2) При отправке данных отправляйте подтверждение с совмещением вместо отправки подтверждения отдельно; (3) Если Если в течение времени задержки поступает несколько сегментов данных, стеку протоколов разрешается отправить подтверждение для подтверждения нескольких сегментов сообщения;
Используйте параметр сокета TCP TCP_NODELAY, чтобы отключить параметр сокета;
Рассмотрите возможность отключения алгоритма Нэгла в следующих случаях:
(1) Противоположный конец не отправляет данные на локальный конец, и операция более чувствительна к задержке; этот вид операции не может переносить подтверждение; (2) Операция записи-записи-чтения, как указано выше; В этом случае вместо отключения алгоритма Нэгла предпочтительнее использовать другие методы:
Разница и сравнение TCP и UDP
Главное отличие
Разница между TCP и UDP в том, что TCP надежен, а UDP ненадежен, но какова реальная производительность? Что ненадежно? В чем разница между ACK конкретного протокола?
Независимо от того, TCP это или UDP, он может быть фрагментированным, что определяется MSS Ethernet; разница заключается в обработке фрагментированной передачи:
UDP больше подходит для голоса, чем TCP
Сценарий голосового вызова заключается в том, что задержка не может быть принята, но качество звука немного хуже. В этом случае во время передачи UDP, если некоторые пакеты потеряны, прикладной уровень может игнорировать и продолжать передавать другие пакеты. Потеря некоторых пакетов повлияет только на качество звука, но обеспечит плавность. Что касается TCP, каждый пакет будет передан повторно, и пока пакет будет потерян, он будет повторно передаваться. Это вызовет определенную задержку. Если есть задержка в голосе, это нежелательно.
Следовательно, TCP и UDP имеют свои подходящие сценарии. Для голоса и видео больше подходит UDP.Как голосовая сеть и linphone, UDP используется для обработки аудио и видео. TCP должен использоваться при взаимодействии базового и основного протоколов.
Эффективность TCP и UDP
Пример: по дороге взад и вперед едет только одна машина. Процесс возврата эквивалентен пустому пробегу (обратный путь эквивалентен ACK TCP), поэтому эффективность TCP, конечно, низкая. Однако, если вы попытаетесь увеличить количество транспортных средств при отсутствии заторов, транспортные средства на дороге будут просто заполнены, поэтому общая эффективность передачи улучшится, а ACK обратного рейса не будет затронут.
Фрагментация пакетов, MTU, MSS
Фрагментация и повторная сборка пакетов
Но следует отметить, что в некоторых сетях в настоящее время есть такие устройства, как Jumbo Frame (jumbo frame) или PPPOE, поэтому их MTU не составляет 1500 байтов. В настоящее время у отправителя нет хорошего механизма для определения оптимального размера фрагмента, и он должен стараться поддерживать согласованность MTU устройств в сети. Если MTU устройств в сети несовместимо, как протокол TCP адаптируется к MTU? Мы знаем, что когда TCP устанавливает соединение, сначала должно быть выполнено трехстороннее рукопожатие. TCP взаимно объявит свой собственный MSS в первых двух пакетах подтверждения. Если клиентская сторона объявляет свой собственный MSS = 8960 (jumbo-фрейм), а серверная сторона объявляет свой собственный MSS = 1460, то клиент знает MSS сервера после трехстороннего рукопожатия, поэтому, когда клиент хочет отправить пакет, превышающий MSS сервера Будет предпринята инициатива по уменьшению собственного MSS до размера MSS на стороне сервера, чтобы адаптироваться к MTU получателя. Видно, что уровень протокола TCP проделал большую оптимизацию и обработку.
Настоящая битва MTU
Если MTU клиента = 9000, а MTU сервера = 1500, тогда, когда клиент запрашивает сервер, пакет клиента будет либо потерян, либо фрагментирован при прохождении через маршрутизатор. Если этот пакет jumbo-кадра несет на сетевом уровне флаг DF (Don’t Fragment), он будет отброшен (его установка означает, что фрагментация не разрешена), если он не установлен, будет выполнена передача фрагмента. Следует отметить, что в этом случае, если пакет потерян, а повторная передача все еще отбрасывается, он становится черной дырой.
В тесте вы можете смоделировать эту ситуацию с помощью команды ping:
Особый контроль потока и пропускная способность
Существует своего рода «кадр паузы», который может удовлетворить это требование: когда буфер коммутатора собирается заполниться, на сервер отправляется кадр паузы, и сервер некоторое время ждет, чтобы отправить его снова, чтобы избежать переполнения и потери пакетов. Повторная передача после потери пакета. Время ожидания на стороне сервера определяется параметром pause_time в кадре паузы, так что серверная сторона начнет отправку после ожидания pause_time. Конечно, коммутатор также может отправить на сервер кадр паузы с pause_time = 0, чтобы сообщить серверу, что я его обработал и могу отправить немедленно.
Обратите внимание, что управление потоком здесь отличается от управления потоком TCP.
В-третьих, используйте методологию анализа Wireshark.
Чтобы устранить проблему с помощью wirehark, вам необходимо проанализировать сетевой пакет, найти некоторые подсказки в сетевом пакете, а затем сделать вывод на основе сетевого протокола, затем отменить один за другим и, наконец, найти проблему.
Необходимо уметь понимать основной протокол TCP и смысл каждого поля.
Используйте некоторые инструменты статистики и анализа Wireshark, фильтры и т. Д.
Существует большая разница между отправкой и получением захвата пакетов
Используйте «три оси» рабочего процесса и шагов для анализа проблемы.