class command_t
{
public:
virtual void apply(std::vector< std::string > const &args) = 0;
virtual std::string get_help() = 0;
};
class add_command_t : command_t
{
public:
void apply(std::vector< std::string > const &args)
{
int ans = atoi(args[1].c_str()) + atoi(args[2].c_str());
std::cout << ans;
}
std::string get_help()
{
return "add arg1 arg2\n";
}
};
//аналогично mul_command и.т.дtypedef std::map< std::wstring, command_t * > command_map_t;
typedef command_map_t::iterator command_iter;
//////////////////////////////////////////
command_map_t commands;
commands['add'] = new add_command_t();
//...
while (true)
{
std::string x;
std::getline(cin, x);
std::vector< std::string > words = split(x); //напиши split сам
command_iter iter = commands.find(words[0]);
if (iter != commands.end()) //если такая команда есть
{
iter->apply(words);
}
else
{
std::cout << "Wrong command!\n";
}
}
Сессия это хеш который хранится в куках у пользователя, при обращение пользователя к скрипту, пхп сверяет хеш и берет из файла данные этой сессии.
session_regenerate_id(); совсем не нужно.session_start();
$ip = $_SESSION['userIP'];
if (!$ip) {
$_SESSION['userIP'] = $_SERVER['REMOTE_ADDR'];
} elseif ($ip != $_SERVER['REMOTE_ADDR']) {
session_destroy();
session_start();
}
Если коротко, то ошибка закралась вот тут:
В асинхронном сервере в единый момент времени обрабатывается столько запросов, сколько есть воркеров
Представьте себе, что у вас на сервер приходит запрос, связанный с выборкой данных из БД.
Он отрабатывает, предположим, за 150 мс, из которых 130 это работа с базой данных.
В случае с PHP у вас воркер будет заблокирован эти 150 мс для обработки других запросов.
В случае с асинхронным сервером, он, пока запрос 1 ждет данные от БД в течение 130 мс, сможет принять и начать обрабатывать другие запросы. Предположим, что у нас один PHP-воркер. В этом случае таких запросов, как из примера, он сможет обработать семь штук за секунду.
Асинхронному же, допустим, прилетят 20 запросов. Он обработает каждый до взаимодействия с БД, допустим за 10 мс, полетят 20 запросов к БД, пройдут, допустим, за 500 мс, и сервер сформирует ответ. И это все практически параллельно. Итого меньше чем за секунду мы таким образом обработаем 20 запросов.
Можно, конечно, увеличить пул FastCGI, но оверхед при обработке запроса каждым воркером будет несоизмеримо выше, чем при обработке асинхронным сервером.
SYN_RECV - это состояние tcp-соединения во время three-handshake, означающее что сервер принял пакет с установленным флагом SYN (запрос на соединение), отправил SYN/SYN-ACK клиенту и ожидает от клиента пакет с флагом ACK.
Поскольку ACK от клиента (в нашем случае, от атакующего хоста) не приходит, то соединение висит до момента, пока оно не будет убито по таймауту. Пока такое соединение существует в системе - оно потребляет ресурсы, что может создать прецедент для замедления работы системы.
Таким образом, чтобы таких соединений не создавалось нужно отсеивать из них неугодные до того, как система выделит для них ресурсы. В Вашем случае, нужно фильтровать все входящие пакеты с установленным флагом SYN и дропать те из них, которые нас не устраивают. Легитимный пользователь не будет создавать по десятку соединений каждую секунду, а атакующий - будет.
Соответственно, Вам нужно выяснить закономерность (периодичность, количество запросов и т. п.), позволяющую отличить легитимный хост от атакующего конкретно в Вашем случае, и в соответствии с ней создать правила.
Если говорить обобщенно, то в Вашем случае, я думаю, проблему можно решить с помощью модуля recent в iptables. Уверен, его функционала Вам будет достаточно. Сможете обойтись несколькими правилами. Алгоритм следует применить примерно такой:
1. Сначала разрешаете входящий tcp-трафик по соединениям в состояниях ESTABLISHED и RELATED (модуль conntrack).
iptables -I INPUT 1 -p tcp -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTiptables -A INPUT -p tcp -m multiport --dports 80,443 --syn -m conntrack --ctstate NEW -m recent --name webtraffic --update --seconds 5 --hitcount 16 -j DROP
iptables -A INPUT -p tcp -m multiport --dports 80,443 --syn -m conntrack --ctstate NEW -j ACCEPTnet.ipv4.tcp_max_syn_backlog = 262144
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20