madoff

Рейтинг
235
Регистрация
01.12.2009
Должность
administrator
Интересы
Linux Unix
I am terminator ;)
_Dizerd_:
Вы имели ввиду типа я это madoff? я даже незнаю madoff

Конечно не знаешь, я чёрный плащ 😂

myhand:
А не madoff-ли это шалит?

Вам меня одного мало ? :) предпочитаете ещё одного ? :)

Интересно Андрей, всё это из за perl модуля ? если да, не пиши тут лучше этого ))

Andreyka:
То, что ты не видишь проблем - это твоя проблема
А зачем нужен дистр, в котором для нормального софта нужно его собирать самому? Не задумывался над этим?

Разработчики nginx, не кому, не чего не должны, а тебе не раз говорили сделай что-то сам.

Andreyka:
Интересно, что сломается от замены 0.7 на 1.0? Ничего. Просто тормозной механизм дает два варианта - устаревший и нестабильный.


1. На сайте разработчика указаны поддерживающиеся релизы. URL сам нагуглишь?

2. Например для robo.

Каждому по возможности, и каждому по потребности, 0-7 является стабильной версией, но без поддержки, 1.0.5 является стабильной на данный момент c поддержкой, у меня стоит 1.1.8 я пока не вижу проблем, хотя пишут есть они, но видь они не критичные ? и меня пока это не затронуло, а значит всё работает как положено если тебе надо какае-то хрень типа robo скомпилируй nginx да пользуйся. показать мануал как это делать ? или сам найдёшь.

zexis:
В основе механизма синкуков лежит, то что когда очередь полуоткрытых соединений заполнена, новые соединения не ставятся в очередь, а сервер в своем ответе SYN+ACK в 32-битном поле TCP заголовка Sequence number указывает число вычисленное по определенному алгоритму и только клиент с настоящим IP получает пакет SYN+ACK и отвечает правильным пакетом ACK.

На википедии довольно ясно описан алгоритм работы синкуков
http://en.wikipedia.org/wiki/SYN_cookies

там пишется о трех возможных проблемах, которые он вызывает.
1. First, the server is limited to only 8 unique MSS values, as that's all that can be encoded in 3 bits.
2. Second, the server must reject all TCP options (such as large windows), because the server discards the SYN queue entry where that information would otherwise be stored.
3. Third, a connection may freeze when the final ACK of the three-way handshake is lost and the client first awaits data from the server

Также там пишется, что эти ограничения возникают лишь во время атаки, а пока атаки нет (Очередь соединений не заполнена) механизм синкуки не используется.

Furthermore, these restrictions need only apply when the server is under attack, and the connection would have otherwise been denied. In such a situation, the loss of a few of the more esoteric options in order to save the connection is usually a reasonable compromise.

Я не вижу аргументов, почему синкуки нужно выключать, когда нет атаки.
Кто то может такие аргументы привести?

А глаза ниже в вики не опустились ? дотянул до середины только, чё за люди :)

Использование Cookies SYN не нарушает любого протокола, спецификации, и поэтому должны быть совместимы со всеми реализациями TCP. Есть, однако, три предостережения, которые вступают в силу, когда SYN-Cookies используются. Во-первых, сервер ограничивается только 8 уникальные значения MSS, а это все, что может быть закодирована в 3 бита. Во-вторых, сервер должен отклонять все TCP варианты (например, большие окна), так как сервер отбрасывает вступление SYN очередь, где эту информацию в противном случае будут сохранены. В-третьих, соединение может замерзнуть при окончательном ACK из трех путей теряется, и клиент сначала ждет данные с сервера (то есть клиент завершил трехэтапного, сервер не может получить клиента ACK и, следовательно, на самом деле не открыли соединение). [1]

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

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

А для доров это проблема 100% там сервер сходит сума , атаки...атаки... :)

p.s Ситуации разные и всякое бывает.

Boris A Dolgov:

В одном релизе в 1.1 сломали работу error_page, который в куче старых конфигов использовался для рерайта. В stable такого не бывает.

Баг репорт есть?

iopiop я завтра вам отвечу, в развёрнутом виде о синкукисах, сейчас не могу.

p.s сори за офф топ

iopiop:
хорошо поставленный вопрос содержит 50% ответа.

ну да ладно, я вижу что тут все настолько круто сваренные, что и спросить ничего нельзя, одни только крики в ответ. а как спросишь что-то конкретное - сразу либо в кусты, либо в гугл.
бог с ним, не на одних Одминчигах с серча свет клином сошелся.

вы спрашивали, вам отвечал я, много раз отвечал, но зачем спрашивать когда нету общего понимание ? давайте вы спросите у myhand, может он вам объяснит, проведите эксперимент, я вам долго и упорно пытался разжевать, простые вещи.

по поводу, серча, это единственный форум ru-net где я вижу специалистов ( в количестве ) - всё остальное серое и скудное.

iopiop:
ну как бэ понятно что куда отослали в логе не видно.
вы спрашиваете что будет если "кукисы не проверят те, куда отослали"? ответ простой - кукисы проверяет сервер, а не клиент.
вы спрашивайте, спрашивайте. глядишь, и докопаемся до истины.

Сначала я скажу что вы не читали, и даже не имеете желание читать, вы не шарите в алгоритме и понятие не имеете как работает эта функция, я обучать вас не буду.


ответ простой - кукисы проверяет сервер, а не клиент.

ответ не является полным, но 10% вы угадали, прям как рулетка.

Всего: 3250