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 адрес отправителя). На все эти вопросы мы можем получить ответ, анализируя трафик с помощью анализатора протоколов.
Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 1
Ускорение каких-либо процессов невозможно без детального представления их внутреннего устройства. Ускорение интернета невозможно без понимания (и соответствующей настройки) основополагающих протоколов — IP и TCP. Давайте разбираться с особенностями протоколов, влияющих на скорость интернета.
IP (Internet Protocol) обеспечивает маршрутизацию между хостами и адресацию. TCP (Transmission Control Protocol) обеспечивает абстракцию, в которой сеть надежно работает по ненадежному по своей сути каналу.
Протоколы TCP/IP были предложены Винтом Серфом и Бобом Каном в статье «Протокол связи для сети на основе пакетов», опубликованной в 1974 году. Исходное предложение, зарегистрированное как RFC 675, было несколько раз отредактировано и в 1981 году 4-я версия спецификации TCP/IP была опубликована как два разных RFC:
TCP обеспечивает нужную абстракцию сетевых соединений, чтобы приложениям не пришлось решать различные связанные с этим задачи, такие как: повторная передача потерянных данных, доставка данных в определенном порядке, целостность данных и тому подобное. Когда вы работаете с потоком TCP, вы знаете, что отправленные байты будут идентичны полученным, и что они придут в одинаковом порядке. Можно сказать, что TCP больше «заточен» на корректность доставки данных, а не на скорость. Этот факт создает ряд проблем, когда дело доходит до оптимизации производительности сайтов.
Стандарт НТТР не требует использования именно TCP как транспортного протокола. Если мы захотим, мы можем передавать НТТР через датаграммный сокет (UDP – User Datagram Protocol) или через любой другой. Но на практике весь НТТР трафик передается через TCP, благодаря удобству последнего.
Поэтому необходимо понимать некоторые внутренние механизмы TCP, чтобы оптимизировать сайты. Скорее всего, вы не будете работать с сокетами TCP напрямую в своем приложении, но некоторые ваши решения в части проектирования приложения будут диктовать производительность TCP, через который будет работать ваше приложение.
Тройное рукопожатие
Все TCP-соединения начинаются с тройного рукопожатия (рис. 1). До того как клиент и сервер могут обменяться любыми данными приложения, они должны «договориться» о начальном числе последовательности пакетов, а также о ряде других переменных, связанных с этим соединением. Числа последовательностей выбираются случайно на обоих сторонах ради безопасности.
Клиент выбирает случайное число Х и отправляет SYN-пакет, который может также содержать дополнительные флаги TCP и значения опций.
SYN ACK
Сервер выбирает свое собственное случайное число Y, прибавляет 1 к значению Х, добавляет свои флаги и опции и отправляет ответ.
Клиент прибавляет 1 к значениям Х и Y и завершает хэндшейк, отправляя АСК-пакет.
Рис. 1. Тройное рукопожатие.
После того как хэндшейк совершен, может быть начат обмен данными. Клиент может отправить пакет данных сразу после АСК-пакета, сервер должен дождаться АСК-пакета, чтобы начать отправлять данные. Этот процесс происходит при каждом TCP-соединении и представляет серьезную сложность плане производительности сайтов. Ведь каждое новое соединение означает некоторую сетевую задержку.
Например, если клиент в Нью-Йорке, сервер – в Лондоне, и мы создаем новое TCP-соединение, это займет 56 миллисекунд. 28 миллисекунд, чтобы пакет прошел в одном направлении и столько же, чтобы вернуться в Нью-Йорк. Ширина канала не играет здесь никакой роли. Создание TCP-соединений оказывается «дорогим удовольствием», поэтому повторное использование соединений является важной возможностью оптимизации любых приложений, работающих по TCP.
TCP Fast Open (TFO)
Загрузка страницы может означать скачивание сотен ее составляющих с разных хостов. Это может потребовать создания браузером десятков новых TCP-соединений, каждое из которых будет давать задержку из-за хэндшейка. Стоит ли говорить, что это может ухудшить скорость загрузки такой страницы, особенно для мобильных пользователей.
TCP Fast Open (TFO) – это механизм, который позволяет снизить задержку за счет того, что позволяет отправку данных внутри SYN-пакета. Однако и у него есть свои ограничения: в частности, на максимальный размер данных внутри SYN-пакета. Кроме того, только некоторые типы HTTP-запросов могут использовать TFO, и это работает только для повторных соединений, поскольку использует cookie-файл.
Использование TFO требует явной поддержки этого механизма на клиенте, сервере и в приложении. Это работает на сервере с ядром Linux версии 3.7 и выше и с совместимым клиентом (Linux, iOS9 и выше, OSX 10.11 и выше), а также потребуется включить соответствующие флаги сокетов внутри приложения.
Специалисты компании Google определили, что TFO может снизить сетевую задержку при HTTP-запросах на 15%, ускорить загрузку страниц на 10% в среднем и в отдельных случаях – до 40%.
Контроль за перегрузкой
В начале 1984 года Джон Нейгл описал состояние сети, названное им как «коллапс перегрузки», которое может сформироваться в любой сети, где ширина каналов между узлами неодинакова.
Когда круговая задержка (время прохождения пакетов «туда-обратно») превосходит максимальный интервал повторной передачи, хосты начинают отправлять копии одних и тех же датаграмм в сеть. Это приведет к тому, что буферы будут забиты и пакеты будут теряться. В итоге хосты будут слать пакеты по нескольку раз, и спустя несколько попыток пакеты будут достигать цели. Это называется «коллапсом перегрузки».
Нейгл показал, что коллапс перегрузки не представлял в то время проблемы для ARPANETN, поскольку у узлов была одинаковая ширина каналов, а у бэкбона (высокоскоростной магистрали) была избыточная пропускная способность. Однако это уже давно не так в современном интернете. Еще в 1986 году, когда число узлов в сети превысило 5000, произошла серия коллапсов перегрузки. В некоторых случаях это привело к тому, что скорость работы сети падала в 1000 раз, что означало фактическую неработоспособность.
Чтобы справиться с этой проблемой, в TCP были применены несколько механизмов: контроль потока, контроль перегрузки, предотвращение перегрузки. Они определяли скорость, с которой данные могут передаваться в обоих направлениях.
Контроль потока
Контроль потока предотвращает отправку слишком большого количества данных получателю, которые он не сможет обработать. Чтобы этого не происходило, каждая сторона TCP-соединения сообщает размер доступного места в буфере для поступающих данных. Этот параметр — «окно приема» (receive window – rwnd).
Когда устанавливается соединение, обе стороны задают свои значения rwn на основании своих системных значений по умолчанию. Открытие типичной страницы в интернете будет означать отправку большого количества данных от сервера клиенту, таким образом, окно приема клиента будет главным ограничителем. Однако, если клиент отправляет много данных на сервер, например, загружая туда видео, тогда ограничивающим фактором будет окно приема сервера.
Если по каким-то причинам одна сторона не может справиться с поступающим потоком данных, она должна сообщить уменьшенное значение своего окна приема. Если окно приема достигает значения 0, это служит сигналом отправителю, что не нужно более отправлять данные, пока буфер получателя не будет очищен на уровне приложения. Эта последовательность повторяется постоянно в каждом TCP-соединении: каждый АСК-пакет несет в себе свежее значение rwnd для обеих сторон, позволяя им динамически корректировать скорость потока данных в соответствии с возможностями получателя и отправителя.
Рис. 2. Передача значения окна приема.
Масштабирование окна (RFC 1323)
Исходная спецификация TCP ограничивала 16-ю битами размер передаваемого значения окна приема. Это серьезно ограничило его сверху, поскольку окно приема не могло быть более 2^16 или 65 535 байт. Оказалось, что это зачастую недостаточно для оптимальной производительности, особенно в сетях с большим «произведением ширины канала на задержку» (BDP – bandwidth-delay product).
Чтобы справиться с этой проблемой в RFC 1323 была введена опция масштабирования TCP-окна, которая позволяла увеличить размер окна приема с 65 535 байт до 1 гигабайта. Параметр масштабирования окна передается при тройном рукопожатии и представляет количество бит для сдвига влево 16-битного размера окна приема в следующих АСК-пакетах.
Сегодня масштабирование окна приема включено по умолчанию на всех основных платформах. Однако промежуточные узлы, роутеры и сетевые экраны могут переписать или даже удалить этот параметр. Если ваше соединение не может полностью использовать весь канал, нужно начать с проверки значений окон приема. На платформе Linux опцию масштабирования окна можно проверить и установить так:
В следующей части мы разберемся, что такое TCP Slow Start, как оптимизировать скорость передачи данных и увеличить начальное окно, а также соберем все рекомендации по оптимизации TCP/IP стека воедино.
Немного о типах DDoS-атак и методах защиты
Согласно проведенным исследованиям, масштабы DDoS-атак выросли примерно в 50 раз за последние несколько лет. При этом злоумышленники «метят» как в локальные инфраструктуры, так и публичные облачные площадки, на которых сосредотачиваются решения клиентов.
«Успешно реализованные атаки имеют непосредственное влияние на бизнес клиентов и носят деструктивные последствия», – комментирует Даррен Ансти (Darren Anstee), представитель компании Arbor Networks, поставляющей решения для обеспечения безопасности в сетях.
При этом частота атак также увеличивается. В конце 2014 года их число составляло 83 тыс., а в первом квартале 2015 года цифра увеличилась до 126 тыс. Поэтому в нашем сегодняшнем материале мы бы хотели рассмотреть различные виды DDoS-атак, а также способы защиты от них.
/ Flickr / Kenny Louie / CC
DoS атака (Denial of Service – отказ в обслуживании) представляет собой бомбардировку серверов жертвы отдельными пакетами с подложным обратным адресом. Сбой в этом случае является результатом переполнения (забивания трафиком) арендуемой клиентом полосы либо повышенного расхода ресурсов на атакуемой системе.
Злоумышленники при этом маскируют обратный адрес, чтобы исключить возможность блокировки по IP. Если атака является распределённой и выполняется одновременно с большого количества компьютеров, говорят о DDoS-атаке. Давайте взглянем на несколько распространённых типов.
TCP SYN Flood
Цель атаки SYN Flood – вызвать перерасход ресурсов системы. На каждый входящий SYN-пакет система резервирует определенные ресурсы в памяти, генерирует ответ SYN+ACK, содержащий криптографическую информацию, осуществляет поиск в таблицах сессий и т. д. – то есть затрачивает процессорное время. Отказ в обслуживании наступает при потоке SYN Flood от 100 до 500 тыс. пакетов за секунду. А злоумышленник, имея хотя бы гигабитный канал, получает возможность направить поток до 1,5 млн пакетов в секунду.
Защита от типа атак SYN Flood осуществляется средствами DPI-систем, которые способны анализировать и контролировать проходящий через них трафик. Например, такой функционал предоставляет решение СКАТ от VAS Experts. Система сперва обнаруживает атаку по превышению заданного порога неподтвержденных клиентом SYN-запросов, а затем самостоятельно, вместо защищаемого сайта, на них отвечает. TCP-сессия организуется с защищаемых сайтов после подтверждения запроса клиентом.
Fragmented UDP Flood
Эта атака осуществляется фрагментированными UDP-пакетами небольшого размера, на анализ и сборку которых платформе приходится выделять ресурсы. Защиту от такого типа флуда тоже предоставляют системы глубокого анализа трафика, отбрасывая неактуальные для подзащитного сайта протоколы или ограничивая их по полосе. Например, для веб-сайтов рабочими протоколами являются HTTP, HTTPS – в этом случае неактуальные протоколы можно попросту исключить или ограничить по полосе.
Атака с использованием ботнета
Злоумышленники обычно стараются заполонить полосу жертвы большим количеством пакетов или соединений, перегружая сетевое оборудование. Такие объемные атаки проводятся с использованием множества скомпрометированных систем, являющихся частью боднет.
В этом примере (изображение выше), злоумышленник контролирует несколько «машин-зомби» для проведения атак. «Зомби» общаются с главной машиной по защищенному скрытому каналу, причем управление часто осуществляется по IRC, P2P-сетям и даже с помощью Twitter.
При проведении атаки такого типа пользователю нет нужды скрывать IP-адрес каждой машины, и благодаря большому числу участвующих в атаке компьютеров, такие действия ведут к значительной нагрузке на сайт. Причем обычно злоумышленники выбирают наиболее ресурсоемкие запросы.
Для защиты от ботнет-атак применяются различные поведенческие стратегии, задача которых – выявлять неожиданные отклонения и всплески трафика. Еще один вариант, который предлагает компания VAS Experts, – использование теста Тьюринга (странички с CAPTCHA).
В этом случае к работе с сайтом допускаются только те пользователи, которые удачно прошли проверку на «человечность». При этом страничка с капчей располагается на отдельном сервере, способном справиться с потоком запросов ботнета любого размера.
Также хотелось бы упомянуть об атаках, которые появились относительно недавно. Речь идет об атаках на IoT-устройства с целью их «захвата» и включения в ботнет для осуществления DDoS-атак.
Согласно отчету компании Symantec, 2015 год побил рекорды по числу атак на IoT, а в интернете появилось восемь новых семейств вредоносных программ. Атаки участились по ряду причин. Во-первых, многие умные устройства постоянно доступны из Сети, но при этом не обладают надежными средствами защиты – не позволяет вычислительная мощность. Более того, пользователи зачастую не обновляют программное обеспечение, только повышая риск взлома.
Злоумышленники используют простую тактику: сканируют все доступные IP-адреса и ищут открытые порты Telnet или SSH. Когда такие адреса найдены, они пытаются выполнить вход с помощью стандартного набора логинов и паролей. Если доступ к оборудованию получен, на него загружается файл скрипта (.sh), который подкачивает тело бота, запускает его и закрывает доступ к устройству, блокируя порты Telnet и внося изменения в iptables, чтобы исключить возможность перехвата системы другим червем.
Чтобы минимизировать риск или избежать взлома IoT-устройств, необходимо выполнить простых действий: отключить неиспользуемые сетевые функции устройства, отключить Telnet-доступ и обратиться к SSH, по возможности перейти на проводное соединение вместо Wi-Fi, а также регулярно проводить обновление программного обеспечения.
Smurf-атаки
Атакующий посылает поддельный пакет IСМР Echo по адресу широковещательной рассылки. При этом адрес источника пакета заменяется адресом жертвы, чтобы «подставить» целевую систему. Поскольку пакет Еcho послан по широковещательному адресу, все машины усиливающей сети возвращают жертве свои ответы. Послав один пакет IСМР в сеть из 100 систем, атакующий инициирует усиление DDoS-атаки в сто раз.
Чтобы предотвратить эффект усиления, специалисты по сетевой безопасности советуют запретить операции прямой широковещательной рассылки на всех граничных маршрутизаторах. Также дополнительно стоит установить в ОС режим «тихого» отбрасывания широковещательных эхо-пакетов IСМР.
DNS-атака с усилением
Атака с усилением – это наиболее распространенная DDoS-атака, использующая рекурсивные сервера имен. Она похожа на Smurf-атаку, только в этом случае злоумышленник посылает небольшие запросы на DNS resolver, как бы заставляя его отправлять ответы на подмененный адрес.
Что касается конкретного примера, то в феврале 2007 года был проведен ряд атак на корневые DNS-серверы, от работы которых напрямую зависит нормальное функционирование всей Сети. Популярные практики защиты от этого типа атак можно найти на сайте Cisco.
TCP Reset
TCP Reset выполняется путем манипуляций с RST-пакетами при TCP-соединении. RST-пакет – это заголовок, который сигнализирует о том, что необходимо переподключение. Обычно это используется в том случае, если была обнаружена какая-либо ошибка или требуется остановить загрузку данных. Злоумышленник может прерывать TCP-соединение, постоянно пересылая RST-пакет с валидными значениями, что делает невозможным установление соединение между источником и приемником.
Предотвратить этот тип атаки можно – необходимо мониторить каждый передаваемый пакет и следить, что последовательность цифр поступает в нужном порядке. С этим справляются системы глубокого анализа трафика.
Сейчас основной целью взлома устройств является организация DDoS-атак или причинение ущерба путем ограничения доступа пользователей к сайту в интернете. Поэтому сами операторы связи, интернет-провайдеры и другие компании, в том числе VAS Experts, также предлагают и организуют решения по защите от DDoS – мониторинг трафика в реальном времени для отслеживания аномалий и всплесков загруженности полосы, функцию Carrier Grade NAT, которая позволяет «спрятать» устройство абонента от злоумышленников, закрыв к нему доступ из интернета, а также другие интеллектуальные и даже самообучающиеся системы.
Дополнительное чтение по теме DPI (Deep packet inspection):
Русские Блоги
Формат сообщения TCP и флаги TCP
(2) Формат сообщения TCP (rfc793)
Описание каждого поля:
TCP использует полнодуплексный режим, и передача данных выполняется после того, как соединение установлено и до того, как соединение будет разорвано.Передача данных является односторонней, от отправителя к получателю. TCP может гарантировать, что данные будут приняты принимающей стороной через порядковый номер. TCP устанавливает соединение посредством трехстороннего рукопожатия.
Во время TCP-соединения бит флагов используется для индикации состояния соединения во время передачи. Таким образом, этот флаг можно использовать для обнаружения проблемы или управления отправкой указанного соединения. Процесс трехстороннего подтверждения TCP выглядит следующим образом:
Для старой версии определения заголовка TCP, флаги имеют 6 бит, а новая версия заголовка TCP расширяет флаги на 3 бита. Каждый флаг TCP соответствует 1 биту. Таким образом, старая версия флагов заголовка TCP имеет 6 значений, а новая версия расширила 3 значения. От низкого к высокому: FIN, SYN, RST, PSH, ACK, URG, ECE, CWR, NS.
Старое поле TCP Flags:
Новая версия поля TCP Flags:
Описание значения флагов:
FIN: сокращение от «готово». Указывает отправителя и отправленные данные. Обычно используется в последнем пакете после того, как отправитель отправил данные.
SYN: сокращение от «Синхронизация». Представляет первый шаг трехстороннего рукопожатия для установления соединения.Значение флага устанавливается на SYN в первом пакете, отправленном отправителем, когда соединение установлено.
RST: сокращение от «сброс». Флаг сброса подключения используется для сброса неправильного подключения из-за сбоя хоста или по другим причинам. Или, когда отправляющий пакет отправляется неожиданному узлу назначения, принимающая сторона отправляет пакет сброса для сброса флага соединения.
PSH: сокращение от «push». Уведомить принимающую сторону о необходимости обработки полученного сообщения вместо буферизации сообщения в буфере.
ACK: сокращение от «Подтверждение». Указывает, что пакет был успешно получен.
URG: сокращение от «срочно». Уведомить принимающую сторону о необходимости обработки полученных срочных пакетов перед обработкой других пакетов. Подробнее см. RFC6093.
ECE: сокращение от «ECN-Echo». ECN означает явное уведомление о перегрузке. Указывает, что одноранговый узел TCP имеет возможность ECN. Подробнее см. RFC3168.
CWR: сокращение от «Уменьшенное окно перегрузки». Отправитель будет использовать флаг CWR при получении пакета с флагом ECE. Подробнее см. RFC3168.
NS: сокращение от «nonce sum». Этот тег используется для защиты от вредоносных скрытых сообщений, отправляемых отправителем. Подробнее см. RFC 3540.
(4) Используйте tcpdump для захвата сообщения значения флага ответа
Потому что флаги TCP расположены в 14-м байте заголовка TCP. Все это можно просканировать с помощью следующей команды:
Подробности пакета TCP RST
Почему первый пакет TCP не нуждается в подтверждении? Это потому, что отправитель RST будет продолжать отправлять RSTs каждый раз, когда он получает другой пакет с другой стороны?
на связанной заметке, Как может номер подтверждения в действительном первом пакете Быть 0?
3 ответов
на связанной заметке, Как может номер подтверждения в первом пакете быть 0?
поскольку сегмент с первым битом должен завершить соединение, не более того. Квитирования имеет смысл только тогда, когда соединение установлено и бит ACK установлен в индустрии. Получатель первого сегмента также должен рассмотреть возможность того, что клиент протокола приложения на другом конце был внезапно прерван и не имел возможность обработать неподтвержденные данные, которые были отправлены ему.
посмотреть RFC 793, стр. 15:
TCP RST packet-это удаленная сторона, сообщающая вам, что соединение, на которое отправляется предыдущий TCP-пакет, не распознается, возможно, соединение закрыто, возможно, порт не открыт, и что-то вроде этого.
вот мое мнение, так как соединение больше не является действительным, нет необходимости отвечать ACK. И поскольку удаленный узел не знает соединения, имеет смысл, что ACK в первом пакете равен 0.
TCP RST означает, что соединение недопустимо. Т. е. на удаленной стороне нет связанного сеанса. Этот пакет обычно отправляется, когда порт, который вы пытаетесь достичь, закрыт, как я знаю.
TCP FIN-это то, что отправляется, когда соединение собирается закрыть, и там вам нужно подтвердить.