скорее всего переполнена очередь коннектов---------- Добавлено 04.01.2012 в 00:01 ---------- Предыдущее сообщение было 03.01.2012 в 23:55 ----------
и это все что вы можете сказать? а как же хваленое
ведь все что я просил - покажите же! ну вот не смог я найти, не смог. помогите.
ну вот я помню. да и не только я, бо мужик был толковый и исключительно плодовитый.
а это при чем вообще, помнит его кто-то или нет? как это связано с темой разговора? факт остается фактом - линус не самый легкий человек в общении. который, кстати, очень не любит признавать свои ошибки. посему я вполне допускаю и третий вариант причины этого предупреждения.
вы, пожалуйста, выражайтесь определеннее. что значит "неживой"? который подсунул левый IP, что ли? ну если хост по этому IP не отвечает, то сервер шлет один раз пакетик SYN-ACK, ждет, шлет еще раз пакетик SYN-ACK, ждет, потом идет чистить очередь.
а в чем вопрос-то был?---------- Добавлено в 23:29 ---------- Предыдущее сообщение было в 23:22 ----------
я прошу прощения, но почему бы вам самим не посмотреть кто и куда влазил?
меня заинтересовало сообщение от вас
в какой момент случается RST и кто его генерирует?
вот! покажите пожалуйста, это все что я прошу (вики читал, да).
хе-хе, упертость товарища линуса хорошо известна, достаточно вспомнить скандальный уход одного из коре-девелоперов, который считал (о ужас!) что линух на десктопе должен быть более отзывчивым и предлагал новый планировщик.
в том-то и дело, что на одном заборе одно написано, а на другом - другое.
вот вы высказали мнение что син-куки ресеты шлет почем зря. вы можете подтвердить свое утверждение фактами какими-то? потому что я смотрю в алгоритм и не вижу где там RST может вылезти - просветите пожалуйста.
собственно, я не вижу подтверждения вообще по всем трем "пунктам обвинения"
1) грубо нарушает работу тсп - в чем? любая не син-куки имплементация тсп может выдать абсолютно такие же пакеты
2) деградирует производительность - прошу прощения, производительность уже деградировала, сайт под атакой
3) проблемы с смтп-релеем - тут загадка. это когда у меня на сервере релей стоит? или когда ко мне стучится релей? или когда сервер стучится к релею? 20 страниц гугла молчат... хотя вполне возможно что я плохо вопросы задаю гуглу.
может конечно.
а может что просто был какой-то смтп-сервер в 1996 году, в котором была бага не позволяющая работать с куками. теперь эту багу пофиксили (или сервер в лету канул), а предупреждение осталось. может такое быть? я допускаю что может.
а может быть просто изначально не разобрались в чем проблема была, а теперь стыдно признаться? может такое быть? я вот вполне допускаю, исходя из того что пишет автор син-куков.
хочется таки понять где собака порылась.
угу, как в 1996 году это написали, так оно там и висит. вот только почему-то никто не может объяснить, а в чем, собственно, заключается этот "violate". в аппроксимации MSS? в невозможности использовать большие окна? если сайт под атакой, если он просто дропает попытки соединения, буду ли я задумываться об оптимизации соединения? забавно, не так ли?
а между тем син-куки добавляют в IPv6 ...
syncookies по умолчанию выставлены в ноль не потому что это хорошо или плохо, а потому что неизвестно как будет использоваться сервер. если сервер будет использоваться как стандартный веб-сервер, то включение кукисов не окажет никакого влияния на тсп, зато поможет при syn-флуде. а вот если сервер будет фтп или стримить - тогда надо выбирать, либо неоптимальная работа тсп (причем только во время атаки), либо syn-флуд (т.е. отказ в обслуживании). как по мне - пусть сервер хоть как-то, но работает, чем в даун уходит.---------- Добавлено в 03:07 ---------- Предыдущее сообщение было в 03:04 ----------
в алгоритм syn-cookies вообще не заложена отсылка RST
Добавьте не только в форму, но и в саму базу NOT NULL поле в таблицу юзверей чтобы в обход формы нельзя было регистрироваться
Кстати напрасно, т.к. сайт будем палить как гуглу, так и яндексу, пока Илья не вернет долги.
Вор должен сидеть.
не получится если больше 2 неуникальных значений, edogs правильно написал последний вариант
вернее получится, но через вложенный селект
SELECT id, hach FROM tbl WHERE hash IN (SELECT hash FROM tbl GROUP BY hash HAVING COUNT(*) > 1);
