Русские Блоги
Wireshark Work Notes — Разрешение состояния TCP и установить соединение соединения и закрытия
В слое TCP есть поле флагов, это поле имеет следующую идентичность: SYN, FIN, ACK, PSH, RST, URG.
Среди них полезно для нашего ежедневного анализа — пять полей впереди.
SYN означает установление соединения,
Фин указывает, что соединение закрыто.
ACK выражает ответ,
PSH указывает на то, что есть передача данных данных.
RST представляет сброс соединения.
Среди них ACK может использоваться одновременно с синжером, плавником и т. Д., Такими как SYN и ACKS, могут быть 1, что представляет собой ответ после установления соединения,
Если это всего лишь один син, он представляет только установить соединение.
Рукопожатие TCP выражается таким ACK.
Тем не менее, Syn And Fin не будет одновременно, потому что первое выражено как создание связи, в то время как последнее выражено.
RST, как правило, в том случае, если плавник — 1, что указывает на сброс соединения.
Как правило, когда происходит плавный пакет или пакет RST, мы думаем, что клиент подключен к серверу на сервер; и появляется пакет SYN и SYN + ACK, мы считаем, что клиент установил связь с сервером.
Корпус PSH 1, как правило, появляется только в пакете, в котором содержимое данных не составляет 0, то есть PSH 1 представлено с помощью истинного содержимого пакета TCP.
Соединение TCP и подключение и соединение завершено, все из которых завершены запрос-ответ.
Дополнение концепции — TCP три рукопожатия:
TCP (протокол управления передачей) протокол управления передачей
TCP — это протокол управления передачей хоста к слое хоста, обеспечивающий надежную службу подключения, используя три рукопожатия для подтверждения установления соединения:
Битовый код — это флаг TCP, есть шесть указывают: SYN (синхронный рабочие задания Интернета) ACK (подтверждение подтверждения) PSH (Push Transfer) FIN (конец окончания) RST (RESET RESET) URG (срочный аварийный аварийный). Обратитесь номер (проверять номер)
Первое рукопожатие: хост-код передачи битовой код син = 1, случайно генерирует пакеты данных SEQ Number = 1234567 к серверу, хост B известен из Syn = 1, а A требует онлайн-соединения;
Вторая рука Рука: Host B принимает запрос на подтверждение онлайн-информации, отправить номер ACK = (SEQ + 1 Host A), SYN = 1, ACK = 1, случайным образом генерирует пакет SEQ = 7654321;
Третье рукопожатие: Host Checks Checks, если номер ACK правильный, то есть первое отправлено SEQ Number + 1, и будь то битовый код ACK 1, если он правильно, хост A отправит номер ACK = ( Хост B SEQ + 1), ACK = 1, хост B принимает после подтверждения того, что значение SEQ успешно подключено к ACK = 1.
Завершите три рукопожатия, Host A Запускает данные с хостом B.
В протоколе TCP / IP протокол TCP предоставляет надежную службу подключения и устанавливает соединение с тремя рукопожатиями. Первое рукопожатие: при установлении соединения клиент отправляет пакет SYN (Syn = j) на сервер и введите состояние Syn_Send, ожидание для подтверждения сервера; второе рукопожатие: сервер получает пакет SYN, вы должны подтвердить SYN (ACK = J + 1), пока вы также отправляете пакет SYN (SYN = K), пакет SYN + ACK, в течение которого сервер входит в состояние Syn_recv;
Третье рукопожатие: клиент получает пакет Syn + ACK сервера, отправляет пакет подтверждения на сервер (ACK = K + 1), этот пакет отправляется, клиент и сервер вводят в установленное состояние, выполните три рукопожатия. Завершите три рукопожатия, клиент начинает передавать данные с сервером. Выдержка из сети Китая Yun’an (www.yunsec.netОригинал:http://www.yunsec.net/a/school/wlcs/agreement/2012/0317/10262.html
Во-первых, структура текста введение
Когда вы начинаете говорить о процессе подключения TCP, вы все еще смотрите в формате пакетов TCP, как показано на рисунке 1. IP DataGram на этот раз состоит из заголовка IP + заголовок TCP + TCP. Заголовок TCP без опции длиной 20 байтов, а заголовок TCP составляет до 60 байтов. Общие варианты включают максимальный размер (MSS), Timestamp (используйте при передаче элемента управления), масштабирование окна (используйте при управлении трафиком), селективный ACK (используется при передаче). Давайте возьмем конкретный взгляд на поле заголовка TCP, как показано на рисунке 2.
Рисунок 1 DataSeet IP TCP Пакет
Подробная структура головы TCP показана на фиг. Источник порта однозначно идентифицирует каждое TCP соединение с портом назначения и портом назначения и IP-адреса назначения и IP-адреса назначения. Первый запускной байт одного конца поля порядковых номеров идентифицирует поток данных TCP к другому концу (например, общая длина данных, передаваемая передающим концом, составляет 1000 байт, при условии, что серийный номер запускается из 1, общая последовательность № 1-1000, TCP дает каждый байт на серийный номер). После того, как серийный номер представляет данные, передаваемые в приемную, после того, как принимающий конец получает данные, передающий конец может быть отправлен отправителю по номеру подтверждения (ACK), позволяющий отправителю узнать, что данные были приняты. Этот номер ACK представляет собой последовательный номер следующих данных, полученных полученными данными, представляя порядковый номер следующих данных, которые требуется прием. (Примечание. ACK не занимает серийный номер, поскольку приемный конец отправляет ACK на передающий конец, ISN передавающего конца равен полученному номеру ACK в это время).
Рисунок 2 Устройство головки TCP
Длина блока длины головы составляет 32бит, поэтому это также определяет длину TCP до 4 * 15 = 60 байтов. Восемь знаков (CWR, ECE . и т. Д.), Здесь впервые представлены, а затем дополнительное введение. Давайте возьмем главное понимание ACK, SYN, FIN. ACK подтверждается, что он обычно включен после установления соединения. SYN используется для инициализации синхронного серийного номера соединения. Когда отправитель закончил передачу данных, сегмент отчета FIN отправляется на приемный конец. Размер окна будет сосредоточен на управлении трафиком TCP.
Во-вторых, учреждение и прекращение связи TCP
Установлена диаграмма процессы TCP-соединения, и терминация устанавливается, как показано на фиг.
Рисунок 3 Установление и прекращение связи TCP
TCP создал три рукопожатия:
1. Отправитель отправляет раздел SYN Message (SYN BIT BIT), а синхронизм включает в себя порт назначения TCP и номер начального последовательности (ISN (C) на рисунке), не имея данные о параметрах TCP.
2. После приема запроса соединения отправителя приемный конец отправляет свой собственный сегмент SYN-сообщения (включая ISN (S)), и подтвердил синхронизацию отправителя, как описано ранее, ACK, отправленный принимающим концом, является ISN (C +1. На данный момент бит ACK устанавливается. Принимающий конец отправляет SYN + ACK к отправителю.
3. После приема данных SYN + ACK о приемной цели ISN (S) подтвержден, и ACK передается в сегмент отчета +1 +1 до получения приема.
Четыре рукопожатия отключены TCP:
1. Спецификация протокола TCP инициируется путем передачи сегмента плавника (установлена плавник), а заканчивается отправка на фиг. 3, передает сегмент FIN к принимающему концу, сообщите ему, что данные были отправлены, запрос отключите соединение TCP Отказ В то же время, отчет FIN также содержит ACK для недавно принятых данных.
2. После того, как приемный конец получает конец, плавник подтвержден, а ACK = K + 1 отправляется отправителю.
3. Принимающий конец отправляет соединение с верхним приложением, а приложение инициирует соединение для отключения работы. В это время принимающий конец распадается пассивными закрывающими соединениями и передает сегмент плавного сообщения для отправителя. Серийный номер пакета L (здесь также можно увидеть, что серийный номер отправки ACK является L, потому что ACK не занимает серийный номер, поэтому серийный номер плавника здесь также L).
4. После того, как отправляющий конец получает плавник, соединение TCP прекращается после отправки ACK обратно к приемному концу. Если FIN потерян, конец отправки плавника необходимо повторно отправить FIN, знаю, что ACK получен.
Как упоминалось ранее, TCP-соединение требует трех абзацев, в то время как соединение TCP должно быть 4 отчетах.
[PSH,ACK] wireshark capture
I am capturing a https traffic from a PC to the web application and I am seeing an ACK follow by a PSH,ACK from the source to destination and vice versa:
PC [ACK] -> WebApp PC [PSH,ACK] -> WebApp WebApp [ACK] -> PC WebApp [PSH,ACK] -> PC
What does it mean? Thanks
asked 15 Apr ’13, 09:04
character9
16 ● 10 ● 10 ● 12
accept rate: 0%
ACK means that the machine sending the packet with ACK is acknowledging data that it had received from the other machine. In TCP, once the connection is established, all packets sent by either side will contain an ACK, even if it’s just re-acknowledging data that it’s already acknowledged.
PSH is an indication by the sender that, if the receiving machine’s TCP implementation has not yet provided the data it’s received to the code that’s reading the data (program, or library used by a program), it should do so at that point. To quote RFC 793, the official specification for TCP:
The data that flows on a connection may be thought of as a stream of octets. The sending user indicates in each SEND call whether the data in that call (and any preceeding calls) should be immediately pushed through to the receiving user by the setting of the PUSH flag.
A sending TCP is allowed to collect data from the sending user and to send that data in segments at its own convenience, until the push function is signaled, then it must send all unsent data. When a receiving TCP sees the PUSH flag, it must not wait for more data from the sending TCP before passing the data to the receiving process.
There is no necessary relationship between push functions and segment boundaries. The data in any particular segment may be the result of a single SEND call, in whole or part, or of multiple SEND calls.
The purpose of push function and the PUSH flag is to push data through from the sending user to the receiving user. It does not provide a record service.
There is a coupling between the push function and the use of buffers of data that cross the TCP/user interface. Each time a PUSH flag is associated with data placed into the receiving user’s buffer, the buffer is returned to the user for processing even if the buffer is not filled. If data arrives that fills the user’s buffer before a PUSH is seen, the data is passed to the user in buffer size units.
There is no special significance to PSH and ACK both being set in the conversation; PSH being set has some significance, and, once the connection is established, ACK being set has very little significance.
RST, by itself, means that the sender of the RST believes an error occurred and that the connection should be «reset». It should be sent if, for example, a packet arrives on a connection that is «apparently not intended for the current connection», to quote RFC 793. So if the connection was closed, but a packet arrives for it anyway, that should provoke an RST.
Протокол TCP: что нужно знать специалисту по анализу сетевого трафика!
По нашему опыту, когда дело доходит до низкоуровневого анализа TCP девять из десяти ИТ специалистов в компаниях среднего и крупного бизнеса чувствуют себя неуверенно. Не могут точно сказать, что такое ретрансмиссии, размер окна и т.д. Большинство материалов в интернете по этой теме больше походят на научные работы. В этой статье мы попытаемся донести с практической точки зрения, что же полезного прячет в себе протокол TCP для того, кто занимается анализом сетевого трафика.
В каких случаях нам нужен анализ TCP пакетов?
Как показывает практика, современные системы анализа сетевого трафика имеют большую базу протоколов и готовых шаблонов для программного обеспечения. Это позволяет без труда разбивать транзакции на логические части. К сожалению, далеко не для всех задач бизнеса удаётся найти готовые продукты и в каждой компании обязательно найдётся парочка «самописных» или кастомизированных приложений. Как же анализировать трафик от таких приложений?
База анализатора трафика не имеет информации, в каком бите содержится код реквеста, какой код соответствует респонсу и т.д. В таких ситуациях приходится прибегать к самым азам сетевой науки – TCP анализу. Давайте рассмотрим, что прячет внутри себя этот протокол.
По своей сути TCP является протоколом транспортного уровня. Он позволяет осуществить соединение одного сокета (IP-адрес + порт) хоста источника с сокетом хоста назначения. Заголовок IP будет содержать информацию, связанную с IP-адресами, а заголовок TCP — информацию о порте.
Заголовок TCP
Заголовки TCP перемещаются по сети для установления, поддержки и завершения TCP-соединений, а также передачи данных.
Рисунок 1. Заголовок TCP
В заголовке TCP содержаться следующие поля:
- Source port (16 бит): порт источника. Порт хоста, от которого исходит запрос.
- Destination port (16 бит): порт назначения. Порт хоста, куда направляется запрос.
- Sequence number, SYN (32 бита): порядковый номер. Позволяет контролировать порядок сообщений. Каждая конечная точка (как порт источника, так и порт назначения) будут поддерживать свой уникальный порядковый номер для отправляемых сообщений. При установлении соединения TCP (используется сообщение с установленным флагом SYN) в качестве изначального порядкового номера будет сгенерировано случайное число. Вернее, не совсем случайно сгенерировано, а будет содержать конкретное 32-битное число, то есть в пределах от 0 до 4294967295 (или 2 в 32-ой степени возможных вариантов), которое будет соответствовать времени, прошедшему после перегрузки системы отправителя (из расчета +1 за каждые прошедшие 4 микросекунды), а также увеличенное на 64000 каждый раз при установлении нового соединения. Так как сгенерированное число будет уникальным для периода времени почти в пять часов (если при этом никакие соединения не устанавливались), то такой подход к выбору порядкового номера позволяет избежать случайных коллизий при передаче данных, когда для нескольких пакетов из разных соединений будет совпадать порядковый номер. В дальнейшем, при отправке следующих пакетов, значение порядкового номера будет увеличиваться на +1 для всех пакетов с флагом SYN, пакетов с флагом FIN и для каждого байта отправленных данных. Это позволяет принимающей системе обрабатывать пакеты в правильной последовательности, как они были сформированы при отправлении, а не в том порядке, как они были получены.
- Acknowledgement number, ACK (32 бита): номер подтверждения. Когда сообщение содержит флаг ACK, то значение в номере подтверждения должно соответствовать следующему порядковому номеру (SYN), которое отправитель сообщения с флагом ACK ожидает получить от передающей системы. Таким образом, отправка одного номера подтверждения способна подтвердить получение всех байтов с информацией, полученных до этого. Более наглядно об использовании порядкового номера и номера подтверждения вы можете посмотреть на этом видео:
- Data offset (4 бита): длина заголовка, известная также как смещение данных. Содержит размер заголовка TCP, измеряемый в 32-битных сегментах. Минимальный размер заголовка TCP составляет пять 32-битных сегментов (всего 20 байт), а максимальный — пятнадцать 32-битных сегмента (или 60 байт).
- Reserved (3 бита): зарезервировано. Зарезервировано для будущего использования, пока просто забивается нулями. На данный момент осталось три незадействованных бита, в то время как еще три ранее зарезервированных бита уже используются как флаги.
- Flags, 9 бит (флаги или управляющие биты):
- NS (1 бит): одноразовая сумма (Nonce Sum). Используется для улучшения работы механизма явного уведомления о перегрузке (Explicit Congestion Notification, ECN).
- CWR (1 бит): окно перегрузки уменьшено (Congestion Window Reduced). Данный флаг устанавливается отправителем, чтобы показать, что TCP-фрагмент был получен с установленным полем ECE. Таким образом, это является подтверждением получения пакета данных с флажком ECE от хоста получателя и включением отправителем механизма уменьшения перегрузки (Congestion Control), позволяющим оптимизировать отправку пакетов с данными в перегруженных сетях, избежав серьезных задержек из-за отбрасывания пакетов.
- ECE (1 бит): ECN-Эхо (ECN-Echo). Выполняет двойственную роль, в зависимости от значения флага SYN. При установленном флаге SYN это указывает на то, что отправитель пакета поддерживает ECN. Если флаг SYN сброшен (SYN=0), а ECE установлен, то это означает, что пакет с установленным флагом CE (Congestion Experienced, Подтвержденная перегрузка) был получен в заголовке IP во время обычной передачи. Таким образом, это служит индикатором перегрузки сети (или предстоящей перегрузки) для TCP-отправителя.
- URG (1 бит). Устанавливается, если необходимо передать ссылку на поле указателя срочности (Urgent pointer).
- ACK (1 бит). Устанавливается, когда пакет содержит значение номера подтверждения в поле подтверждения. Все пакеты после стартового пакета SYN будут иметь установленный флаг ACK.
- PSH (1 бит). Делает этот пакет пакетом PUSH (проталкивания). При нормальном потоке передачи данных система получателя не будет подтверждать получение каждого пакета сразу же после его получения. Вместо этого система получателя в течении некоторого времени будет собирать и хранить полученные данные в буфере, пока не передаст их приложению пользователя. Пакет PUSH инструктирует систему получателя немедленно передать все полученные ранее данные из буфера в приложение пользователя и сразу же отправить сообщение с подтверждением.
- RST (1 бит): сброс данного соединения. Отправкой пакета RST одна из сторон сообщает о немедленном разрыве соединения. При этом соединение обрывается, а буфер очищается. Самые распространенные причины отправки пакета с установленным флагом RST — ответ на пакет, полученный для закрытого сокета; пользователь сам прервал соединение (например, закрыв браузер, не дожидаясь ответа); соединение не было нормально закрыто, но находится в неактивном состоянии некоторое время.
- SYN (1 бит). Начинает соединение и синхронизирует порядковые номера. Первый пакет, отправленный с каждой стороны, должен в обязательном порядке иметь установленным этот флаг.
- FIN (1 бит). Одна из конечных точек отправляет пакет с установленным флагом FIN для другой конечной точки, чтобы сообщить, что все пакеты были отправлены, и соединение пора завершить.
Механизм передачи сообщений TCP
Перед тем, как данные могут быть переданы между двумя узлами, в TCP, в отличие от UDP, предусмотрена стадия установки соединения. Также, после того, как все данные были переданы, наступает стадия завершения соединения. Таким образом, осуществление каждого TCP-соединения можно условно разделить на три фазы:
- Инициализация соединения.
Установка соединения осуществляется с помощью, так называемого трехстороннего рукопожатия TCP. Инициатором соединения может выступать любая сторона. Однако чтобы упростить рассмотрения данного вопроса в рамках данной статьи, мы рассмотрим пример, когда клиент инициализирует соединение с сервером.
Рисунок 2. Трехстороннее рукопожатие TCP
(Пакет №1). Клиент отправляет пакет с установленным флагом SYN и случайным числом («R1»), включенным в поле порядкового номера (sequence number).
(Пакет №2). При получении пакета №1 сервер в ответ отправляет пакет с установленным флагом SYN, а также с установленным флагом ACK. Поле порядкового номера будет содержать новое случайное число («R2»), а поле номера подтверждения будет содержать значение порядкового номера клиента, увеличенного на единицу (то есть «R1 + 1»). Таким образом, он будет соответствовать следующему порядковому номеру, который сервер ожидает получить от клиента.
(Пакет №3). В ответ на пакет SYN от сервера (пакет №2) клиент отправляет пакет с установленным флагом ACK и полем номера подтверждения с числом «R2 + 1». По аналогии, это число будет соответствовать следующему порядковому номеру, который клиент ожидает получить от сервера.
- Загрузка данных.
После инициализации соединения полезная нагрузка будет перемещаться в обоих направлениях TCP-соединения. Все пакеты в обязательном порядке будут содержать установленный флаг ACK. Другие флаги, такие как, например, PSH или URG, могут быть, а могут и не быть установленными.
- Завершение соединения.
При нормальном завершении TCP-соединения в большинстве случаев инициализируется процедура, называемая двухсторонним рукопожатием, в ходе которой каждая сторона закрывает свой конец виртуального канала и освобождает все задействованные ресурсы. Обычно эта фаза начинается с того, что один из задействованных процессов приложения сигнализирует своему уровню TCP, что сеанс связи больше не нужен. Со стороны этого устройства отправляется сообщение с установленным флагом FIN (отметим, что этот пакет не обязательно должен быть пустым, он также может содержать полезную нагрузку), чтобы сообщить другому устройству о своем желании завершить открытое соединение. Затем получение этого сообщения подтверждается (сообщение от отвечающего устройства с установленным флагом ACK, говорящем о получении сообщения FIN). Когда отвечающее устройство готово, оно также отправляет сообщение с установленным флагом FIN, и, после получения в ответ подтверждающего получение сообщения с установленным флагом ACK или ожидания определенного периода времени, предусмотренного для получения ACK, сеанс полностью закрывается. Состояния, через которые проходят два соединенных устройства во время обычного завершения соединения, отличаются, потому что устройство, инициирующее завершение сеанса, ведет себя несколько иначе, чем устройство, которое получает запрос на завершение. В частности, TCP на устройстве, получающем начальный запрос на завершение, должен сразу информировать об этом процесс своего приложения и дождаться от него сигнала о том, что приложение готово к этой процедуре. Инициирующему устройству не нужно это делать, поскольку именно приложение и выступило инициатором. Более подробно завершении TCP-соединения смотрите здесь (http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm).
Рисунок 3. Завершение TCP-соединения
- Keep-alive или повторное использование соединений
На уровне TCP нет сообщений типа «keep-alive», и поэтому, даже если сеанс соединения в какой-то момент времени становится неактивным, он все равно будет продолжаться до тех пор, пока не будет отправлен следующий пакет.
Когда мы отправляем HTTP-запрос по сети, нам сразу нужно создать TCP-соединение. Однако в HTTP 1.0 возможность повторного использования соединения по умолчанию закрыта (если заголовок «keep-alive = close» дополнительно не включен в заголовок HTTP), то есть TCP-соединение автоматически закрывается после получения запроса и отправки ответа. Так как процесс создания TCP-соединения относительно затратный (он требует дополнительных затрат процессорных ресурсов и памяти, а также увеличивает сетевой обмен между сервером и клиентом, что особенно становится актуальным при создании защищенных соединений), то все это увеличивает количество лагов и повышает вероятность перегрузки сети. Поэтому для HTTP 1.1 было решено оставлять TCP-соединение открытым до тех пор, пока одна из сторон не решит прекратить его.
С другой стороны, если соединения не будут закрываться после того, как клиенты получат все необходимые им данные, задействованные ресурсы сервера для поддержания этих соединений не будут доступны другим клиентам. Поэтому HTTP-серверы, чтобы обеспечить больший контроль над потоком данных, используют временные интервалы (таймауты) для поддержки функциональности «keep-alive» для неактивных соединений (длящихся по умолчанию, в зависимости от архитектуры и конфигурации сервера, не более нескольких десятков секунд, а то и просто нескольких секунд), а также максимальное число отправляемых запросов «keep-alive», прежде чем сеанс без активного соединения будет остановлен. Более подробно о функциональности «keep-alive» вы можете узнать здесь (https://blog.stackpath.com/glossary/keep-alive/).
Вступайте в Telegram канал проекта NetworkGuru, чтобы не пропустить интересные статьи и вебинары.
Подписывайтесь на рассылку, делитесь статьями в соцсетях и задавайте вопросы в комментариях!
What is [PSH, ACK] doing during my connection to a global catalog server?
A linux server of mine is trying to establish a LDAPS connection to a global catalog server and the connection is getting dropped (presumably by the GC side).
For the purpose of discussion, let’s say that 1.1.1.1 is the Linux server and 1.2.3.4 is the global catalog server.
If I try to use telnet from the Linux box, I see:
There’s no delay between the 4th and 5th lines. It just immediately drops the connection.
I thought that telnet results might be a little misleading (since it’s not actually appropriate for any type of secure communication) so I collected a packet capture of the actual connection attempt from the appliance (using the actual program requiring LDAPS).
Here’s what I see (again, IPs and source ports have been renamed to protect the innocent):
I’m a bit rusty with TCP/IP so please forgive my ignorance. I see the three-way handshake taking place in packets 1-3. That makes sense. What’s going on in packet #4 though? What does [PSH, ACK] mean? This seems like a redundant acknowledgement that’s unnecessary. Is actual data being sent in this 4th packet? Or is this some weird continuation of the handshake?