Syn пакет что это
Что такое атака SYN flood и как она работает?
SYN flood (полуоткрытая атака) — это тип атаки «отказ в обслуживании» (DDoS), целью которой является сделать сервер недоступным для законного трафика, потребляя все доступные ресурсы сервера. Повторно отправляя пакеты SYN, злоумышленник может перегрузить все доступные порты на целевом сервере, в результате чего целевое устройство будет вяло реагировать на допустимый трафик или не реагировать вовсе.
Как работает атака SYN флуд
Атаки SYN flood работают, используя процесс квитирования TCP-подключения. В нормальных условиях TCP-подключение показывает три различных процесса для установления соединения.
Чтобы создать отказ в обслуживании, злоумышленник использует тот факт, что после получения исходного пакета SYN сервер ответит одним или несколькими пакетами SYN/ACK и дождется последнего шага в квитировании. Вот как это работает:
В сети, когда сервер оставляет соединение открытым, но машина на другой стороне — связи нет, соединение является полуоткрытым. В этом типе DDoS-атаки целевой сервер постоянно оставляет открытыми соединения и ждет каждого соединения для тайм-аута, прежде чем порты становятся доступными снова. В результате такой тип атаки можно считать «полуоткрытой атакой».
Потоп SYN может проходить тремя различными способами:
На видео: Понятное объяснение syn flood атаки в шуточной форме.
Как смягчается атака SYN flood
Уязвимость SYN флуд была известна в течение длительного времени, и был использован ряд путей смягчения. Несколько подходов включают:
Как Cloudflare смягчает атаки SYN Flood
Cloudflare частично смягчает этот тип атаки, стоя между целевым сервером и потоком SYN. При выполнении первоначального запроса SYN Cloudflare обрабатывает процесс квитирования в облаке, удерживая соединение с целевым сервером до завершения квитирования TCP. Эта стратегия берет стоимость ресурса поддержания соединений с фиктивными пакетами SYN от целевого сервера и помещает его в Сеть Anycast Cloudflare.
Обзор CentOS 7. Часть 4: Смягчение DDoS атак TCP SYN Flood. Тест в облаке бесплатно
В первой части обзора CentOS 7 было рассказано о поддержке контейнеров Linux в Cent OS 7. Во второй части мы поговорили об управлении идентификацией. В третья части обзора мы коснулись сетевой файловой системы NFS и ее окружению. В этой статье поговорим о смягчении DDoS атак TCP SYN Flood. В конце поста ссылка на бесплатное тестирование CentOS 7 в облачной VPS от Infobox.
DDoS (Distributed Denial of Service) атаки становятся все более частым явлением, из-за того, что бизнес становится все более зависимым от сети Интернет. Одна из самых распространенных видов DDoS – SYN Flood. Эта основная атака конечных хостов, ставящая ваш сервер на колени. В результате ваш сервер не может правильно обрабатывать входящие запросы.
Важно заметить, что описанные механизмы защиты доступны в CentOS 7, но не включены по умолчанию.
Почему SYN-flood — боль для ядра
Основная проблема масштабируемости TCP для ядра Linux связана с тем, как много новых соединений могут быть созданы за секунду. Это относится к блокировке на сокет в состоянии «listen» (прослушивания). «Estabilished» (Установленные) соединения масштабируются очень хорошо. Блокировка состояния «listen» встречается не только с SYN–пакетами, но и другими пакетами для первоначального подключения «SYN-ACK» и «ACK» (пакеты тройного рукопожатия в TCP). В сценарии атаки флудом нам необходим механизм фильтрации фейковых попыток подключения до того, как сокет войдет в состояние «listen» и блокирует новые входящие соединения.
Основы фильтрации conntrack
Используя систему отслеживания соединений в Netfilter (conntrack), мы можем начать фильтрацию ложных SYN-ACK и ACK пакетов до того, как они вызовут блокирующее состояние «listen». Это было возможно уже долгое время, но не было включено по умолчанию.
Вам помогут следующие две команды:
Правило для iptables будет отлавливать пакеты, которые система отслеживания соединений классифицировала как «INVALID» и не являющихся частью известных состояний соединения.
Настройка sysctl сделает систему отслеживания соединений более строгой в категоризации и поможет уклониться в том числе от атак ACK–flood.
Что с производительностью?
В результате мы в 20 раз уменьшим влияние атак, основанных на SYN–ACK и ACK.
Conntrack в Netfilter имеет плохую репутацию за низкую скорость работы, но так было в первое время после появления технологии. Сейчас она предлагает превосходную масштабируемость и работает очень быстро. Conntrack работает без локов, используя RCU (обновление через копирование) для существующих соединений.
По сути это предотвратит проблемы от всех флудящих пакетов TCP, кроме SYN.
Почему это не работает с SYN-flood?
В conntrack есть проблема масштабируемости (похожая на блокировку «listen»), возникающую, когда речь идет о создании (или удалении) соединений, которую вызывает SYN флуд.
Даже после настройки contrack SYN пакеты будут отправлены сокету вызывая блокировку «listen». Методика смягчения этой атаки — отправить SYN–куки и предотвратить создание любого статуса, пока SYN–ACK не будет виден.
К сожалению SYN–куки, отправляются под той же блокировкой «listen», поэтому такое смягчение не решит проблему масштабируемости. Чуть позже мы обсудим, как обойти это ограничение.
Что нового в CentOS 7
На Netfilter Workshop 2013 была предложена идея «сетевых контрмер». Это дало рождение модулю iptables «SYNPROXY» и соответствующим изменениям в ядре Netfilter. Теперь эта функциональность доступна в CentOS 7.
Модуль SYNPROXY предназначен для решения двух проблем с масштабируемостью. Во-первых работает с SYN–куками параллельно. Во-вторых, он не создает conntrack до получения пакета SYN–ACK, что позволяет conntrack не блокировать новые соединения.
SYNPROXY может быть использован на локальном хосте или может защищать другие хосты за файрволом. Как только первоначальное соединение установлено, conntrack возьмет на себя все необходимые трансляции (повторно использовав части кода NAT).
Тестирование на соединениях к localhost показали 10-и кратный рост производительности по смягчению SYN–атак.
Настройка SYNPROXY
Настройка SYNPROXY может быть достаточно сложной без руководства. В этой статье рассмотрены необходимые шаги, однако вы можете использоват0 и скрипт для упрощения настройки.
Этот пример может быть использован для защиты веб-сервера на 80 порту.
Шаг 1
Убедитесь, что соединения, которые мы защищаем, не создают conntrack для SYN пакетов.
Шаг 2
Включим более строгий conntrack. Это необходимо чтобы иметь INVALID статус для плохих ACK пакетов.
Шаг 3
Теперь нам необходимо обрабатывать эти пакеты и передавать их напрямую в модуль SYNPROXY. Чтобы это сделать, используйте правило обработки UNTRACKED SYN и INVALID пакетов, которые содержат ACK от тройного рукопожатия (и других, но они просто будут проходить через это правило):
Шаг 4
Поймайте пакеты с состоянием INVALID, которые попали в SYNPROXY и уничтожьте их. Это предотвратит флуд SYN–ACK.
Шаг 5
Не забудьте включить временные метки TCP. SYN–куки используют это поле TCP.
Шаг 6
Если у вас нагруженный сайт, рекомендуется настроить conntrack для увеличения лимита в 64 тысячи подключений. Так же увелитьте размер хеша conntrack. Это очень важно для производительности.
Необходимо устанавливать значение лимитов, актуальное для вашего сайта и посчитать использование памяти для него. Например, 2 000 000 записей за раз по 288 байт = максимум 576 Мб потенциального использования памяти. Для хеша, каждая голова хеш-таблицы занимает только 8 байт на миллион записей = 8 Мб фиксированной выделенной памяти (помните размер вашего кеша L3 у CPU, когда выбираете значение кеша). Узнать, какой процессор используется на хосте можно командой:
Соображения по использованию SYNPROXY
Включение SYNPROXY может не пройти незаметно. Установка соединений будет проходить медленнее в связи с дополнительной настройкой соединения, необходимого конечному хосту. Когда конечный хост локальный, все происходит очень быстро и практически не добавляет задержек.
Параметры модуля SYNPROXY должны соответствовать опциям TCP и должны поддерживаться конечным хостом, для которого TCP соединение проксируется. Обнаружение и настройка производится вручную на основе правил (полезный инструмент «nfsynproxy» – часть релиза iptables 1.4.21). К сожалению это означает, что модуль не может быть просто развернуть на DHCP файрволы.
В будущем есть планы по авто-обнаружению опций TCP конечных хостов. Голосуйте за фичу в баг-трекере Red Hat.
Разбор атак на части: SYN-flood
Spoofed SYN — атака, при которой заголовки пакетов подделывается таким образом, что место реального отправителя занимает произвольный либо несуществующий IP-адрес.
Дисклеймеры
Дисклеймер №1
Все, описанное в этом и последующих топиках – по сути не является know-how. Все методики – открытые, и в то или иное время (некоторые – от 2003 года) были опубликованы в открытых источниках. Я взял на себя труд только свести их в одно и описать «глобальную стратегию» защиты, ориентированную на системных администраторов, обслуживающих небольшие проекты, расположенные на выделенных серверах (описанную стратегию можно применить и в shared-проектах, но реализация будет настолько запредельно ужасной, что писать об этом нет никакого желания)
Дисклеймер №2
В топике не рассматриваются аппаратные решения защиты – во-первых, они отлично рассмотрены в многочисленных статьях производителей этих самых решений, во вторых, проекты, располагающие одним сервером не часто могут себе их позволить (грубо говоря, цена на работающие решения стартует от 20 тысяч евро), в третьих – автор не располагает достаточными данными и опытом по работе с таким специализированным железом, что бы делать глобальные выводы о методах и эффективности такой защиты – навряд ли кому-то интересен обзор решений от двух вендоров из дюжины, не подкрепленный серьезной рабочей статистикой их использования. Но стоит заметить, что оба аппаратных решения, которые мне приходилось использовать, как правило очень эффективны на SYN-атаках при выполнении ряда условий.
Дисклеймер №3
В топике не рассматриваются провайдеры защиты от DDoS-атак – сервис-инженеры этих организаций смогут описать их методы работы лучше и подробнее. Стоило бы, наверное, сделать обзор самих провайдеров как таковых — с точки зрения клиента (в разное время проекты, в которых я принимал участие, были клиентами Dragonara, Blacklotus, Gigenet, Vistnet (в настоящий момент), Prolexic (в настоящий момент) и ряда продавцов услуг вышеперечисленных компаний), но это выбивается из рамок топика, попробуем поговорить об этом позже. Опять же, стоит заметить что все провайдеры защиты, с которыми работают или работали проекты автора, справляются с проблемой SYN-атак, показывая хорошую эффективность.
Немного механики и википедии
Не хотелось бы превращать топик в подобие RFC и цитировать и так всем известные истины, поэтому ограничимся тем, чем интересен TCP с точки зрения SYN-атаки и пробежимся по верхам.
Во-первых, TCP — это один из наиболее используемых транспортных протоколов, поверх которого располагаются большинство протоколов прикладных. Во-вторых, он обладает рядом особых признаков (явно подтверждаемые начало и завершение соединения, управление потоком, etc. ) – которые делают его реализацию относительно сложной и ресурсоемкой.
В контексте статьи интересно рассмотреть механизм установки TCP-соединения – трехстороннее рукопожатие. В первом приближении на уровне «клиент-сервер» выглядит это вот так: клиент отправляет серверу SYN-пакет, на который отвечает SYN+ACK.Клиент отправляет в ответ ACK на SYN сервера и соединение переходит в состояние установленного.
SYN-атака – отправка в открытый порт сервера массы SYN-пакетов, не приводящих к установке реального соединения по тем или иным причинам, что влечет за собой создание «полуоткрытых соединений», которые переполняют очередь подключений, вынуждая сервер отказывать в обслуживании очередным клиентам. Плюс к этому, TCP RFC обязывает сервер отвечать на каждый входящий SYN, что дополнительно бьет как по ресурсам сервера, так и по каналу передачи данных. В прочем, если вы уже сталкивались с – по сути – любыми DDoS атаками – описанное выше вы знаете и без меня. Переходим к конкретным рекомендациям.
Один в поле
Используй то, что под рукою, и не ищи себе другое – что можно сделать, находясь один на один с атакой? Честно говоря, не многое, но бывает, что хватает и этого. Далее описано, что делать с FreeBSD, так как в наших проектах в 90% случаев используется именно эта система. Впрочем, от ОС к ОС разница будет невелика – принципы одинаковы.
Первое – необходимо получить доступ к серверу (да, в этом тоже может быть сложность, особенно если атака масштабная и/или продолжительная – сервер просто выбрал все буферы или имеет 100% загрузку CPU). Обычно для этого достаточно закрыть атакуемый сервис фаерволом или просто его – сервис – погасить (впрочем, при обнаружении атаки это нужно сделать в любом случае, хотя бы для того, что бы иметь возможность делать на сервере что-то еще).
Второе – получить первые сведения о атаке. Если у вас уже сделан мониторинг входящего трафика – отлично, если нет – открываем фаервол/поднимаем сервис и используем старые-добрые tcpdump и netstat, что бы узнать, что именно атакуют и какой размер атаки в пакетах в секунду. Попутно можно быстро просмотреть сети, из которых идут массовые запросы – входят ли они в типичную для вашего сервиса аудиторию. Все это пригодится в будущем.
Третье – на интерфейсе, где расположен атакуемый IP-адрес должен остаться только он один. Каждый алиас будет снижать производительность системы. Выражается это в разных числах для разных систем, но числа эти – серьезные, каждый алиас может стоить дополнительных 2-3 тысяч пакетов в секунду.
Четвертое – если вы используете какой-либо фаерволл для входящего трафика по атакуемому адресу – все правила, кроме блокирования, должны быть отключены – к примеру, при spoofed SYN-атаке вероятность того, что вам поможет SYN-proxy от PF стремится к нулю, а CPU это займет очень серьезно.
Пятое – настраиваем систему. Чудес тут не будет, для них нужен рояль в кустах в виде подготовленных драйверов и специально купленных сетевых карт, а единственные две общие рекомендации, которые серьезно отражаются на возможности приема SYN-атаки давно всем известны:
— Размазать обработку прерываний по процессорам сервера;
— Включить syn-cookies и отключить syn-cache.
Остальной тюнинг системы поможет выжать дополнительные 5-10 тысяч пакетов, что в условиях атаки вряд ли окажется определяющим. На случай, если он кому-нибудь пригодится – вот максимально общий конфиг (без включения опций, требующих пересборки ядра или специализированных драйверов):
Система уровня десктопного компьютера, сконфигурированная в соответсвии с данными рекомендациями:
Система уровня IBM System x3630 M3, сконфигурированная в соответсвии с данными рекомендациями:
Детальные конфигурации ОС и машин, и, собственно, как мы пришли именно к ним — я попробую рассказать в следующем топике.
Одно дело делаем
Что делать помимо тюнинга системы В принципе, есть чем заняться.
Тут стоит сделать небольшое отступление – большинство хостинг-компаний помогут в борьбе с атакой крайне неохотно, если помогут вообще, и в этом их трудно винить. Но как минимум данные о атаке они предоставят – если придется работать с провайдерами защиты, это, вкупе с информацией, собранной вами в ходе атаки, здорово облегчит жизнь.
Просим заблокировать все неиспользуемые порты и протоколы – SYN-атака может с легкостью сменится UDP-атакой.
На эти действия способен фактически любая хостниг-компания. Но если вам посчастливилось работать с серьезной компанией — попросите заблокировать трафик из региона, где не проживает большая часть аудитории вашего проекта (например, Китай) – обычно это означает анонс блекхола для вашей сети для магистральных провайдеров определенного региона. Как правило, SYN-атака совершается из Азии, ввиду дешевизны и массовости, и, следовательно, такой анонс может серьезно помочь в борьбе с атакой либо вообще исключить ее возможность.
Помимо вышеописанных мер можно посоветовать использовать GeoDNS-like сервис – при некоторых условиях (атака ведется по домену, к примеру) это сработает аналогично анонсированию блекхола для определенных сетей.
Напоследок
Надеюсь, статья поможет вам справиться с проблемой SYN-флуда, не превысив годовой бюджет какой-нибудь африканской страны. Конечно, здесь даны только самые общие рекомендации, но поверьте – в 90% случаев их вполне достаточно. И главное — don’t panic!
UPD. Продолжение находится в стадии написания, и скоро будет выложено тут. Оставайтесь с нами!
Внутренние механизмы ТСР, влияющие на скорость загрузки: часть 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 стека воедино.