psh ack wireshark что это

Psh ack wireshark что это

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 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, фильтры и т. Д.

Существует большая разница между отправкой и получением захвата пакетов

Используйте «три оси» рабочего процесса и шагов для анализа проблемы.

Источник

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

Транспортные протоколы TCP и UDP

Оглавление: Компьютерные сети

6. Канальный уровень передачи данных

7. Маршрутизация данных

8. Служебный протокол ICMP

10. Настройка сетевых подключений в командной строке Linux

11. Определение проблем работы сети

12. Туннелизация

Сходства и различия TCP и UDP

В первой части «Как работают компьютерные сети» мы узнали, что для передачи информации используются транспортные протоколы TCP и UDP. В физическом смысле эти протоколы представляют собой сетевые пакеты. Каждый сетевой пакет передаёт небольшой фрагмент информации, поэтому данные разбиваются на много пакетов.

Каждый сетевой пакет обоих протоколов TCP и UDP состоит из двух частей:

В заголовке содержится «служебная информация» (можно сказать, что это метаданные) — порты пункта назначения и исходного узла, номер пакета в потоке, тип пакета и так далее.

Различие между протоколами TCP и UDP в том, что протокол TCP имеет механизм контроля полноты переданных данных — если какой-либо пакет был потерян или повреждён, то предусмотрен механизм для проверки этого факта и повторной отправки пакета. В протоколе UDP такого механизма нет — то есть если потерян пакет протокола UDP, то узел, который его отправил, никогда об этом не узнает, а принимающая сторона никогда не узнает, что ей был отправлен потерянный пакет UDP.

Может возникнуть вопрос, зачем вообще нужен такой ненадёжный протокол UDP, если есть надёжный протокол TCP? Платой за надёжность протокола TCP является то, что в бухгалтерии называется «накладные расходы» (overheads) — суть в том, что для обеспечения механизма контроля доставки пакетов в протоколе TCP отправляется много данных, которые не содержат полезной информации, а служат только для установки и контроля соединения. К примеру, чтобы отправить хотя бы одни пакет с полезными данными в TCP нужно завершить трёхступенчатое рукопожатие, которое заключается в отправке 1 особого пакета от источника к пункту назначения, получения 1 пакета о возможности установить соединения и отправки ещё 1 специального пакета от источника с подтверждением, что всё готово к отправке — за это время с помощью протокола UDP можно было бы отправить уже несколько пакетов с полезными данными.

Детальное понимание TCP и UDP имеет значение при:

К примеру, понимая механизм TCP подключения, можно настроить файлервол (iptables) так, что будут запрещены все новые подключения с сохранением существующих, либо запретить любые входящие подключения с полным разрешением исходящих, понимать и предотвращать ряд DoS атак, понимать SYN и другие виды сканирований — почему они возможны и каков их механизм и т.д..

Протокол TCP

Transmission Control Protocol (TCP, протокол управления передачей) — один из основных протоколов передачи данных интернета, предназначен для управления передачей данных.

Из-за перегрузки сети, балансировки нагрузки трафика или непредсказуемого поведения сети, IP-пакеты могут быть потеряны, дублированы или доставлены не в неправильном порядке. TCP обнаруживает эти проблемы, запрашивает повторную передачу потерянных данных, переупорядочивает неупорядоченные данные и даже помогает минимизировать перегрузку сети, чтобы уменьшить возникновение других проблем. Если данные все ещё остаются недоставленными, источник уведомляется об этом сбое. После того, как получатель TCP собрал последовательность первоначально переданных октетов, он передаёт их принимающему приложению. Таким образом, TCP абстрагирует связь приложения от базовых сетевых деталей.

TCP широко используется во многих интернет-приложениях, включая World Wide Web (WWW), электронную почту, протокол передачи файлов, Secure Shell, одноранговый обмен файлами и потоковое мультимедиа.

Протокол TCP оптимизирован для точной доставки, а не для своевременной доставки, и может вызывать относительно длительные задержки (порядка секунд) при ожидании сообщений, вышедших из строя или повторных передач потерянных сообщений. Поэтому он не особенно подходит для приложений реального времени, таких как передача голоса по IP.

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

Алгоритм работы TCP следующий:

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

Всё это возможно с помощью заголовков TCP пакета.

Что такое 1 соединение TCP

Прежде чем изучить структуру заголовка TCP пакета, разберёмся, что такое 1 TCP соединение — это поможет яснее понимать, что именно мы анализируем в Wireshark и сколько TCP соединений нам нужно искать. К примеру, сколько TCP соединений задействуется при открытии 1 страницы веб-сайта? Типичный веб-сайт состоит из 1 страницы HTML кода, нескольких страниц каскадных таблиц стилей CSS и JavaScript файлов, а также пары десятков файлов изображений. Так вот, для получения каждого из этих файлов создаётся новое TCP соединеие. Для каждого из этих соединений выполняется трёхэтапное рукопожатие — это к вопросу о том, какие издержки, «накладные расходы» несёт в себе TCP.

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

Поэтому при анализе трафика в Wireshark при открытии даже одной веб страницы вы увидите множество начатых и завершённых TCP соединений.

Заголовок TCP

Порт источника и порт назначения не обязаны быть одинаковыми: к примеру, если делается запрос к 80-му порту сервера, то этот запрос может прийти, например, с порта 34054.

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

Указывает на количество переданных байт, и каждый переданный байт полезных данных (payload) увеличивает это значение на 1.

В противном случае, если SYN не установлен, первый байт данных, передаваемый в данном пакете, имеет этот порядковый номер.

Если установлен флаг ACK, то это поле содержит порядковый номер октета, который отправитель данного сегмента желает получить. Это означает, что все предыдущие октеты (с номерами от ISN+1 до ACK-1 включительно) были успешно получены.

Каждая сторона подсчитывает свой Sequence number для переданных данных и отдельно Acknowledgement number для полученных данных. Соответственно Sequence number каждой из сторон соответствует Acknowledgement number другой стороны.

Минимальный размер заголовка составляет 5 слов, а максимальный — 15 слов, что даёт минимальный размер 20 байтов и максимум 60 байтов, что позволяет использовать до 40 байтов опций в заголовке. Это поле получило такое имя (смещение данных) из-за того, что оно также показывает расположение фактических данных от начала сегмента TCP.

Итак, длина заголовка определяет смещение полезных данных относительно начала сегмента. Например, Data offset равное 1111 говорит о том, что заголовок занимает пятнадцать 32-битных слова (15 строк*32 бита в каждой строке/8 бит = 60 байт).

По умолчанию размер окна измеряется в байтах, поэтому ограничен 2 16 (65535) байтами. Однако благодаря TCP опции Window scale option этот размер может быть увеличен до 1 Гбайта. Чтобы задействовать эту опцию, обе стороны должны согласовать это в своих SYN сегментах.

Поле Options является полем переменной длины и содержит необязательные заголовки, которые мы можем захотеть использовать. По сути, это поле всегда содержит 3 подполя. В начальном поле указывается длина поля «Параметры», во втором поле указывается, какие параметры используются, а затем у нас есть фактические параметры. Полный список всех опций TCP можно найти в опциях TCP.

Сессия TCP

Рукопожатие TCP (установление подключения TCP)

Для установления соединения TCP использует трёхэтапное рукопожатие.

Подключение можно выполнить только если вторая сторона прослушивает порт, к которому будет выполняться подключение: к примеру, веб-сервер прослушивает порты 80 и 443. То есть это не охватывается рукопожатием, но прежде чем клиент попытается соединиться с сервером, сервер должен сначала подключиться к порту и начать прослушивать его, чтобы открыть его для соединений: это называется пассивным открытием. Как только пассивное открытие установлено, клиент может инициировать активное открытие. Для установления соединения происходит трёхэтапное (или трёхступенчатое) рукопожатие:

Первый этап, отправка пакета с включённым флагом SYN: активное открытие выполняется клиентом, отправляющим SYN на сервер. Клиент устанавливает порядковый номер сегмента на случайное значение A.

Обратите внимание, что по умолчанию Wireshark показывает относительное значение порядкового номера (Sequence number), чуть ниже вы также можете видеть реальное значение (показано как raw).

Второй этап, отправка пакета с включённым флагом SYN-ACK: В ответ сервер отвечает SYN-ACK. Номер подтверждения установлен на единицу больше принятого Порядкового номера (Sequence number), то есть A+1. Поскольку сервер также будет отправлять данные, то для себя он тоже выбирает Порядковый номер (Sequence number) первого пакета с данными, который будет другим случайным числом B.

Третий этап, отправка пакета с включённым флагом ACK: наконец, клиент отправляет ACK обратно на сервер. Порядковый номер устанавливается равным полученному значению подтверждения, то есть A+1, а номер подтверждения устанавливается на единицу больше, чем принятый порядковый номер, то есть B+1.

На этом этапе и клиент, и сервер получили подтверждение соединения. Шаги 1, 2 устанавливают параметр соединения (порядковый номер) для одного направления, и оно подтверждается. Шаги 2, 3 устанавливают параметр соединения (порядковый номер) для другого направления, и он подтверждается. Таким образом устанавливается полнодуплексная (двухсторонняя) связь.

Передача данных в TCP

PSH-ACK: Клиент отправляет запрос к серверу по HTTP протоколу, поскольку данные поместились в один сетевой пакет TCP, то он имеет флаг PSH, чтобы сервер не ждал продолжение получения данных, а отправил их веб-серверу для выполнения.

ACK: В ответ на принятую информацию сервер отправляет пакет ACK с номером успешно полученных данных.

PSH-ACK: Сервер обработал запрос и отправляет данные — веб страницу

ACK: клиент подтверждает, что данные получены

На последнем скриншоте:

Завершение соединения

Фаза завершения соединения использует четырёхэтапное рукопожатие, причём каждая сторона соединения завершается независимо. Когда конечная точка хочет остановить свою половину соединения, она передаёт пакет FIN, который другой конец подтверждает пакетом с флагом ACK. Поэтому для типичного разрыва требуется пара сегментов FIN и ACK от каждой конечной точки TCP. После того, как сторона, отправившая первый FIN, ответила с последним ACK, она ожидает тайм-аута, прежде чем окончательно закрывает соединение, в течение которого локальный порт недоступен для новых соединений; это предотвращает путаницу из-за задержанных пакетов, доставляемых во время последующих соединений.

Соединение может быть «полуоткрытым», и в этом случае одна сторона завершила свою часть, а другая — нет. Завершившая сторона больше не может отправлять какие-либо данные в соединение, но другая сторона может. Завершающая сторона должна продолжить чтение данных, пока другая сторона также не завершит свою работу.

Также возможно разорвать соединение трёхэтапным рукопожатием, когда хост A отправляет FIN, а хост B отвечает FIN&ACK (просто объединяет 2 шага в один), а хост A отвечает ACK.

Некоторые операционные системы, такие как Linux и H-UX, реализуют полудуплексную последовательность закрытия в стеке TCP. Если хост активно закрывает соединение, но при этом остаются непрочитанными входящие данные, хост отправляет сигнал RST (потеря всех полученных данных) вместо FIN. Это гарантирует приложению TCP, что удалённый процесс прочитал все переданные данные, ожидая сигнала FIN, прежде чем он активно закроет соединение. Удалённый процесс не может различить сигнал RST для прерывания соединения и потери данных. Оба вызывают удалённый стек, чтобы потерять все полученные данные.

Как можно увидеть на скриншоте, завершение TCP соединения также происходит как (Linux с последним ядром):

Клиент: FIN-ACK

Сервер: FIN-ACK

Клиент: ACK

Состояния клиента и сервера

Описание данных состояний позволяет лучше понимать информацию, которую показывают программы о состоянии сети, такие как netstat и ss (смотрите также «Как проверить открытые порты на своём компьютере. Что означают 0.0.0.0, :*, [::], 127.0.0.1. Как понять вывод NETSTAT»).

Фильтры Wireshark для TCP

Чтобы увидеть только трафик TCP:

Показать трафик, источником или портом назначения которого является определённый порт, например 8080:

Показать трафик, источником которого является порт 80:

Показать трафик, который отправляется службе, прослушивающей порт 80:

Показать TCP пакеты с включённым флагом SYN:

Показать TCP пакеты с включённым флагом SYN и отключённым флагом ACK:

Аналогично и для других флагов:

Также можно использовать синтаксис вида tcp.flags == 0x0XX, например:

Длина заголовка (смещение данных):

Пакеты с установленными зарезервированными битами:

Вычесленный размер окна:

Фактор масштабирования размера окна:

tcp.window_size_value — это необработанное значение размера окна, считываемое непосредственно из заголовка TCP, тогда как tcp.window_size — это вычисленный размер окна, который основан на том, применимо ли масштабирование окна или нет. Если масштабирование окна не используется или коэффициент масштабирования равен 1 или неизвестно, применимо ли масштабирование окна или нет, потому что трёхэтапное рукопожатие TCP не было захвачено, тогда эти два значения будут одинаковыми. С помощью tcp.window_size_scalefactor вы можете определить, какое из этих условий применимо — если его значение равно -1, то оно неизвестно, если его значение равно -2, тогда масштабирование окна не используется, а все остальные значения представляют фактический размер фактора масштабирования окна.

Чтобы показать пакеты, содержащие какую либо строку, например, строку hackware:

Следовать потоку TCP с номером X:

Фильтровать по номеру потока:

Показать повторные отправки пакетов. Помогает прослеживать замедление производительности приложений и потери пакетов:

Этот фильтр выведен проблемные пакеты (потерянные сегменты, повторную отправку и другие. Этот фильтр проходят пакеты TCP Keep-Alive, но они не являются показателем проблем.

Фильтры для оценки качества сетевого подключения.

Следующие характеристики относятся к TCP фреймам. Причём они не основываются на заголовках фрейма — рассматриваемые характеристики (пропуск данных, дубли) присвоены программой Wireshark исходя из анализа.

Фильтр выводит информацию о фреймах с флагом ACK, которые являются дублями. Большое количество таких фреймов может говорить о проблемах связи:

Фильтр показа фреймов для которых не захвачен предыдущий сегмент:

Это нормально в начале захвата данных — поскольку информация перехватывается не с самого начала сессии.

Для показа фреймов, которые являются ретрансмиссией (отправляются повторно):

Вывод фреймов, которые получены не в правильном порядке:

Виды сканирований Nmap

Мы рассмотрели механизм рукопожатия TCP, напомним его структуру:

Знаменитый сканер портов Nmap по умолчанию выполняет сканирования с использованием полуотрытых соединений, или его ещё называют SYN сканированием. На самом деле, это не что иное, как отправленный пакет с включённым флагом SYN — то есть Nmap инициирует рукопожатие TCP. Если в ответ приходит пакет с флагами SYN-ACK (то есть удалённый хост отправляет свою часть рукопожатия), то это означает, что порт открыт. Если удалённый хост отвечает пакетом с флагом RST-ACK, то это означает, что порт закрыт.

Такой метод, с одной стороны, является универсальным — любой открытый порт обязательно должен ответить пакетом с флагами SYN-ACK, поскольку это стандарт транспортного протокола TCP. Но при этом Nmap не завершает рукопожатие, то есть не создаётся полноценное соединение и приложение, которое прослушивает просканированный порт, никогда не узнает об этом неудачном TCP рукопожатии, и этот факт не отобразиться в журналах этого приложения.

Пример сканирования портов:

На следующем скриншоте мы можем видеть отправленные и полученные пакеты:

Первая группа пакетов (выделена прямоугольником) — пинг хоста, чтобы определить, доступен ли он. Также на этапе доступности хоста делается запрос к портам 80 и 443 (хотя порт 443 не указан для сканирования), видимо, также для подтверждения того, что хост онлайн.

Если от порта получен пакет SYN-ACK (сервер готов к установке соединения), то Nmap отвечает пакетом с флагом RST для обрыва начатого рукопожатия.

Вторая группа — они отмечены серым и зелёным — это непосредственно сканирование портов — это пакеты с флагом SYN. Серым отмечены те, которые прислали ответ RST-ACK (порт закрыт), а зелёным т е, которые прислали ответ SYN-ACK (порт открыт).

Пакеты RST-ACK, а также пакеты RST (от Nmap) помечены красным.

Как можно увидеть, техника очень простая и использует самые базовые возможности трансопртного протокола TCP.

Кроме этого метода, Nmap поддерживает ещё несколько типов сканирования:

Если вы хотите узнать об этих опциях и типах сканирвоания подробнее, то рекомендуется изучить их на справочной странице Nmap: https://kali.tools/?p=1317

Теперь, когда понятна суть сканирований портов, можно предложить меры по защите сервера от сканирований. Если ваш сервер предназначен принимать входящие соединения (например, это веб сервер с SSH), то на 100% защититься от сканирований портов нельзя, поскольку для полуоткрытых соединений используются «легальные» TCP пакеты с флагом SYN, которые являются первой частью рукопожатий. Тем не менее в iptables или fail2ban можно настроить примерно такое правило: «если от одного удалённого хоста поступило более 10 SYN пакетов за указанный промежуток времени, то отклонять его последующие попытки подключения». Это затруднит или даже сделает невозможным массовое сканирование портов на вашем сервере.

Если у вас настроен контроль доступа по IP, то можно запретить SYN пакеты от любого хоста, кроме разрешённых IP, — в этом случае посторонние не только не смогут подключаться, но и не смогут узнать, что порт на самом деле открыт.

Примеры iptables

[БУДЕТ ДОБАВЛЕНО ПОЗЖЕ]

Протокол UDP

Если вы смогли разобраться с TCP и его заголовками, то с UDP вам будет совсем просто.

Протокол пользовательских дейтаграмм (UDP) — это очень простой протокол. Он был разработан для обеспечения очень простой передачи данных без какого-либо обнаружения ошибок. Это так называемый stateless (то есть «без состояния») протокол, это отличает его от протокола TCP, в котором есть понятие соединения (stateful), включающее в себя создания подключения (трёхэтапное рукопожатие) и в котором передача данных выполняется только в рамках данного подключения. Соответственно, для протокола UDP не предусмотрены различные состояния клиента и сервера.

Однако он очень хорошо подходит для приложений типа запрос/ответ, таких как, например, DNS и т. д., поскольку мы знаем, что если мы не получим ответ от DNS-сервера, запрос где-то был потерян. Иногда также стоить использовать протокол UDP вместо TCP, например, когда мы хотим только обнаружение ошибок/потерь, но не заботимся о последовательности пакетов. Это устраняет некоторые издержки, связанные с протоколом TCP.

Природа UDP как протокола без сохранения состояния также полезна для серверов, отвечающих на небольшие запросы от огромного числа клиентов, например DNS и потоковые мультимедийные приложения вроде IPTV, Voice over IP, протоколы туннелирования IP и многие онлайн-игры.

Что такое 1 соединение UDP

Для UDP пакетов понятие «соединение» неправильное, поскольку отправляется один пакет без установки соединения. Если требуется передать поток данных, то отправляется множество UDP пакетов, которые хотя и могут иметь одну общую задачу, с точки зрения транспортного протокола каждый из них является независимым.

В ответ также может прийти один или несколько пакетов UDP. Они приходят на тот же порт, с которого был отправлен исходный UDP пакет — это позволяет определить, что данная датаграмма является ответной на отправленную ранее.

Тем не менее при открытом UDP порте состояние сервера становится LISTEN (сервер ожидает запросов установления соединения от клиента). Также UDP соединение может иметь статус UCONN или ESTAB.

Как можно увидеть, UDP пакет отправлен с порта 42044:

Ответный UDP пакет также пришёл на порт 42044:

Если сравнить с TCP, то минимальное количество пакетов для отправки запроса и получения информации — 10, а для UDP минимальное количество пакетов для отправки запроса и получения информации — 2.

Заголовок UDP

Можно сказать, что заголовок UDP представляет собой очень упрощённый заголовок TCP. Он содержит порты назначения, порты источника, длину заголовка и контрольную сумму, как показано на рисунке ниже.

Как и с протоколом TCP — для сервера обычно используется один из стандартных портов (например, порт 53 для DNS серверов), а порт источника выбирается произвольно для каждого соединения, обычно это номера портов с большим номером (десятки тысяч).

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

Поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями. Поле не является обязательным для IPv4.

Фильтры Wireshark для UDP

Чтобы увидеть только трафик UDP:

Для UDP не используются флаги. Для этого протокола можно только указать порт.

Показать трафик, источником которого является порт 53:

Показать трафик, который отправляется службе, прослушивающей порт 53:

UDP пакет, в котором встречается определённая строка, например, строка hackware:

Порт назначения ИЛИ исходный порт:

Время между пакетами (для выявления проблем сети):

Номер потока (запрос-ответ):

Сравнение UDP и TCP

TCP — ориентированный на соединение протокол, что означает необходимость «рукопожатия» для установки соединения между двумя хостами. Как только соединение установлено, пользователи могут отправлять данные в обоих направлениях.

UDP — более простой, основанный на сообщениях протокол без установления соединения. Протоколы такого типа не устанавливают выделенного соединения между двумя хостами. Связь достигается путём передачи информации в одном направлении от источника к получателю без проверки готовности или состояния получателя. В приложениях для голосовой связи через интернет-протокол (Voice over IP, TCP/IP) UDP имеет преимущество над TCP, в котором любое «рукопожатие» помешало бы хорошей голосовой связи. В VoIP считается, что конечные пользователи в реальном времени предоставят любое необходимое подтверждение о получении сообщения.

Источник