Спецификация TCP-портов

Спецификация TCP-портов. Взаимодействие с системой защиты. Корневой каталог сервера. Увеличение производительности. Ограничение потери ресурсов. Количество серверов

Спецификация TCP-портов

TCP- протокол управления передачей - один из основных протоколов передачи данных интернета, предназначенный для управления передачей данных. Сети и подсети, в которых совместно используются протоколы TCP и IP называются сетями TCP/IP.

В стеке протоколов IP TCP выполняет функции протокола транспортного уровня модели OSI.

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

Реализации TCP обычно встроены в ядра ОС. Существуют реализации TCP, работающие в пространстве пользователя.

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

Порт источника, Порт назначения

Эти 16-битные поля содержат номера портов — числа, которые определяются по специальному списку.

Порт источника идентифицирует приложение клиента, с которого отправлены пакеты. Ответные данные передаются клиенту на основании этого номера.

Порт назначения идентифицирует порт, на который отправлен пакет.

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

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

Атаки на TCP/IP

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

Пассивные атаки на уровне TCP

При данном типе атак крэкеры никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводиться к наблюдению за доступными данными или сессиями связи.

Активные атаки на уровне TCP

При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соотвествующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN-затопление).

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

Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется.

Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.

Web сервер

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

Существуют несколько простых методик повышения эффективности работы Web сервера. Все основано на трех принципах:

• Сжатие запросов

• Уменьшение количества запросов

• Увеличение/ограничение ресурсов

• Все современные браузеры поддерживают работу со сжатием Gzip. Web сервер сжимает содержимое ответа перед отправкой его клиенту, а браузер распаковывает его в момент получения. Так можно сэкономить до 70% размера файла. Для клиентов это будет означать более высокую скорость работы Web сайта.

• Сжатие работает только для файлов текстового формата (HTML/XML, CSS, Javascript). Сжатие также приведет к дополнительной нагрузке на Web сервер, но незначительной.

Оптимизация Apache

Корневой компонент большинства современных веб-сайтов — это, конечно же, Apache. Он зарекомендовал себя как наиболее функциональный, стабильный и удобный в использовании HTTP-сервер, который можно использовать как для обслуживания домашней веб-страницы, так и для высоконагруженных корпоративных интернет-проектов. Одна проблема: Apache — очень тяжелое приложение, жадное до ресурсов сервера.

И это должно быть учтено при его настройке. Вот список рекомендаций, которые лучше выполнять при подготовке HTTP-сервера к работе:

• Львиная доля функционала Apache вынесена в загружаемые модули, которые можно активировать или отключить путем редактирования конфигурационного файла (директива LoadModule). Хорошей практикой является тотальное отключение всех неиспользуемых модулей, что позволит повысить производительность сервера и сохранить оперативную память.

• Apache обрабатывает каждый новый запрос в собственном потоке исполнения и позволяет использовать разные подходы для выполнения этой операции. Если ты собирал Apache2 из исходников, то мог заметить, что в опциях сборки присутствует возможность выбора так называемого MPM. Это и есть модуль мульти-процессинга (Multi-processing module), используемый для распараллеливания HTTP-сервера.

Всего их существует три:

1. prefork — классический MPM, реализующий модель мульти-процессинга, используемую в Apache 1.3. Каждый поток обрабатывается в отдельном процессе. Не самый производительный вариант, но наиболее стабильный. Используется по умолчанию.

2. worker — MPM, основанный на потоках. Сервер порождает несколько процессов, по несколько потоков в каждом. Один запрос — один поток. Производительнее prefork, но менее стабилен.

3. event — событийный MPM. Вместо потоков запросы обрабатываются, используя событийную модель, похожую на ту, что применяется в nginx. Наиболее производительный MPM, но и наименее стабильный (находится в экспериментальной стадии разработки).

Многие дистрибутивы позволяют устанавливать разные варианты Apache, различающиеся используемым MPM, их легко можно найти в репозитории по запросу «apache2-mpm».

• Apache позволяет контролировать максимальное количество порождаемых потоков с помощью опции MaxClients. Не стоит устанавливать ее значение слишком большим, иначе в определенный момент сервер исчерпает всю оперативную память, начнет свопить, и необслуженными останутся гораздо больше клиентов, чем было бы при задании жесткого ограничения. Оптимальным считается значение, равное количеству памяти, доступной Apache, поделенное на максимальный размер порожденного потока (проверяется с помощью ps или top).

• Как и многие другие HTTP-серверы, Apache позволяет контролировать длительность удержания соединений типа keep-alive, используемых для передачи нескольких запросов/ответов в рамках одного соединения. Keep-alive позволяет экономить ресурсы сервера, не вынуждая его создавать отдельный поток на каждую картинку, CSS и прочие элементы страницы. Однако слишком долго такое соединение держать открытым не стоит, потому как на это тоже уходят ресурсы. Хорошим значением опции KeepAliveTimeout будет 5-10 секунд, причем, если все зависимые компоненты страницы отдаются клиенту отдельными серверами, а текущий сервер используется только для отдачи HTML/PHP, необходимость поддержки keep-alive отпадает вовсе, и значение опции KeepAlive лучше установить в Off.

• Apache не любит сжатие. Если ты решил увеличить скорость отдачи страниц с помощью сжатия, то имей в виду, что, скорее всего, оно создаст еще большую нагрузку на сервер. Если же сжатие действительно необходимо (например, для мобильного портала, основной поток клиентов которого использует канал GPRS), то устанавливай коэффициент сжатия минимальным, это приведет лишь к незначительному росту объема результирующих данных, зато позволит существенно сэкономить ресурсы сервера.

Контрольные вопросы :

1.Что такое TCP?

2.Типы Атаки на TCP/IP ?

3. Что такое Web сервер ?

4. Методы оптивизации

5.Какой уровень надежности протоколов TCP ?