Блин, синфлуды, пардон

аа, точно. понял. это да.

поймите, речь идет как раз о том, что 1) абонентам пофиг 2) монтажники не есть сервисная комповая служба

Хм... а вы куда перенаправляете запросы на переустановку ОС? Ведь такие обращения наверняка есть. Или просто сливаете в унитаз?

Хм... а вы куда перенаправляете запросы на переустановку ОС? Ведь такие обращения наверняка есть. Или просто сливаете в унитаз?

Прайс шлем. И высылаем парня который это любит за доп. прайс.

Хм... а вы куда перенаправляете запросы на переустановку ОС? Ведь такие обращения наверняка есть. Или просто сливаете в унитаз?

есть компьютерный сервис, но он не может делать все

плюс часто абонент не хочет платить за то, что ему будут вирусы лечить.

ему проще жить с трипером, как Мао

зато дешевле

Ну я бы вот здесь наладил... Парень, который делает за доп., на самом деле, еще должен говорить спасибо, ну хотя бы 10%. Их он может отрабатывать вот по таким заявкам..

Кстати. А вот если без SYNcookie теряется третий пакет в рукопожатии, с ACK - чем сценарий отличается от сценария с SYNcookie? Ничем. Клиент ждет приветствие от сервера, его не происходит. Что делает клиент? Через время посылает ACK опять. Что происходит без SYNcookie? Устанавливается сессия, и сервер чего-то плюет. Что происходит с SYNcookie? То же самое. В чем разница? :)

плюс часто абонент не хочет платить за то, что ему будут вирусы лечить.

Просто приведу пример. Если у клиента резолвер висит, он получает нотисы ежедневные. Если с него потек трафик ДНСовский, он отключается. По звонку включается. По детекту снова отключается. Чтобы не было вони, с ними ведется работа. Вообще, в конце концов, у него появляется микротик ?

Кстати. А вот если без SYNcookie теряется третий пакет в рукопожатии, с ACK - чем сценарий отличается от сценария с SYNcookie? Ничем. Клиент ждет приветствие от сервера, его не происходит. Что делает клиент? Через время посылает ACK опять. Что происходит без SYNcookie? Устанавливается сессия, и сервер чего-то плюет. Что происходит с SYNcookie? То же самое. В чем разница? :)

да как бы ретрансмит будет

Просто приведу пример. Если у клиента резолвер висит, он получает нотисы ежедневные. Если с него потек трафик ДНСовский, он отключается. По звонку включается. По детекту снова отключается. Чтобы не было вони, с ними ведется работа. Вообще, в конце концов, у него появляется микротик ?

эгм, Вы совершенно правы. вот только некому постоянно мониторить, что у него там

Да он как бы будет в обоих случаях. Потому что клиент вообще не в курсе, работают на сервере синкуки или нет. Это механизм реализации, а не протокола, на проводе его нет.

эгм, Вы совершенно правы. вот только некому постоянно мониторить, что у него там

Счетчики. Да хоть в зеркало воткнуть какой-нибудь анализатор, пусть хоть 1 гиг анализирует, уже хватит для принятия решения.

Поэтому я продолжаю не видеть, чем синкуки мешают SMTP

Ну и отмечу, что синкуки нынче по умолчанию включены во всех дистрибутивах линукса и фри AFAIK. Так что вопрос только тюнинга.

эгм, они включаются только при определенном трешхолде

по дефолту — нет

Ну и да, еще синкуки неприятны ppsами, которые сервервер может не держать. Опять же, вопрос подбора железа и тюнинга.

https://github.com/torvalds/linux/blob/v2.6.38/Documentation/networking/ip-sysctl.txt#L422

эгм, они включаются только при определенном трешхолде

Слово "тюнинг" пишу в 4-й раз ;)

Кстати. А вот если без SYNcookie теряется третий пакет в рукопожатии, с ACK - чем сценарий отличается от сценария с SYNcookie? Ничем. Клиент ждет приветствие от сервера, его не происходит. Что делает клиент? Через время посылает ACK опять. Что происходит без SYNcookie? Устанавливается сессия, и сервер чего-то плюет. Что происходит с SYNcookie? То же самое. В чем разница? :)

с чего бы клиенту через какое-то время опять ACK посылать?

сервер без syn cookie пошлёт заново syn-ack, а с syn cookie - ничего не пошлёт...

Потому что ретрансмит. И он это будет делать, если его ACK потерян, независимо от того, есть на сервере SYNcookie или нет.

здрасте приехали

сервер без syn cookie пошлёт заново syn-ack, а с syn cookie - ничего не пошлёт...

Чо??

а откуда клиент знает что ACK потерян?

потому что sequence number'ы есть

А ниоткуда. ACK - это подтверждение последнего SN, и больше ничего. Послыается, по большому счету, просто так

хорошо. Я клиент, я отправил ack с номером 1773. Дальше что? :)

А ниоткуда. ACK - это подтверждение последнего SN, и больше ничего. Послыается, по большому счету, просто так

ну так один раз посылается, нет? :)

ну если ты получил следующий пакет и не было ack'а на предыдущий sn, то что-то не так

Дальше через время этот ACK перепосылается. Ну или - зависит от стека и настроек - сессия рубится по отсутствию активности.

Если я послал SYN и не получил SYN-ACK (который потерялся) - я через время перепосылаю SYN. Если я после отсылки SYN-ACK ничего не виду, я время от времени перепосылаю свой ACK, подтверждающий нулевой относительный SN

кто "я" при посылке SYN-ACK?

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

Клиент

ясно

следующий

И это никак не зависит от SYNcookie. Есть они, нет их - этот сценарий один и тот же.

Клиент

У вас и syn, и syn-ack, и ack - клиент отправляет?

Зачем ему вообще сервер, он самодостаточен! :))

Я не по-русски написал "если я послал SYN и не получил SYN-ACK..."?

У вас то ACK потерян, то SYN-ACK....

Если syn-ack потерян, то ничего не будет.

Спишь?

Сорри

Если сервер не получит от клиента ACK то клиент будет считать что соединение открыто, а сервер вообще ничего об этом знать не будет.

Может быть потерян любой из трех пакетов. Я по очереди про эти ситуации написал. Ну, потерянный SYN - очевидно. Потерянный SYN-ACK - это перепосылка SYN клиентом. Потерянный ACK (клиента) - это перепосылка ACK клиентом же.

Да с чего клиенту отправлять опять ack? Да еще и с тем же номером?

На колу мочало, начинай сначала. Клиент. Время от времени. перепосылает последний ACK. В том числе, и на случай, если он потерян. Потому что ACK - это acknoledgement, подтверждение SN. И все. В данном примере он подтверждает SN=ISN со своей стороны.

Протокол так устроен.

ткните меня носом в какую-нибудь ссылку что ли, про периодическую отправку ACK после получения единстенного SYN-ACK

И если б он был устроен иначе, то сессии на заре интернета открывались бы намного хуже :) Потому что тогда этот сценарий был вполне вероятен

Стивенс, второй том.

Стивенс, второй том.

страница?

Нет уж, я и так вас бесплатно слишком долго консультировал.

?

А я все ждал, когда эта мегадискуссия завершится :))

то есть никого больше не смущает, что клиент, не получая от сервера никаких пакетов - просто так отправляет ACK периодически?

Не ссорьтесь, направьте лучше меня на путь верный. Есть сервер с аццелем, вхреначиваю туда сетевуху на i350, в результате при нагрузке на отдачу получаю кучу protocol reject 0xffff в логах роутеров(и на аццеле) и последущий отвал сессии. Даже напрямую, соответсвенно потерь на сетевухе нет. При нагрузке на входящий все ок, только lcp echo бегает. При этом на встройке все отлично, куда копнуть?

то есть никого больше не смущает, что клиент, не получая от сервера никаких пакетов - просто так отправляет ACK периодически?

лимит должен быть да

Нет уж, я и так вас бесплатно слишком долго консультировал.

Да такие консультации и даром - слишком дорого

Вам пора учиться по книгам, а не по чатам, вот что.

а вам пора понять что ACK отправляется при получении каких-то данных, а не просто так "периодически"

Еще раз. Учитесь. Подучитесь - возвращайтесь.

Мда, запахло. Кто б там не был прав, посмотрите со стороны.

Еще раз. Учитесь. Подучитесь - возвращайтесь.

Во всем мире почему-то есть проблема с syn-cookies в некоторых случаях, и все это признают, а по вашему - её не существует. Ок, видимо ваш tcp/ip более правильный.

Надо смотреть реализации, да. ACK может посылаться после SYN/SYN-ACK в любой момент, это его право. Но может и не посылаться. Если в линуксовом стеке, например, клиент предполагает перепосылку SYN-ACK на случай потери ACK, и сам ACK не перепосылает - проблема иногда может случаться

Хотя и непонятно, зачем бы так реализовывать эту часть.

*перепосылаться

Вот это уже более конструктивный диалог. А можно попросить пример реализаций где ACK перепосылается? Я нигде ни разу о такой реализации упоминаний не встречал - может и правда упустил что-то...

Если это действительно так реализовано. Других подводных камней я не вижу

У меня твердое впечатление, что в BSD-стеке так изначально делалось, но в код в полвторого ночи не полезу смотреть

Вообще, надо поизучать вопрос. Может, надо это место стандартизировать. Хотя бы draft в IETF написать. Ибо пока что это на совести реализатора, возможно. Надо завтра RFC поглядеть.

А кто нибудь хочет прямо ип6, так что б по настоящему, без баловства?

Я обеими руками за IPv6

просто меня пугает количество людей, которые как попугаи повторяют “если Вы используете NAT в IPv6, то Вы не поняли, зачем IPv6”

Это я говорил

Вот это уже более конструктивный диалог. А можно попросить пример реализаций где ACK перепосылается? Я нигде ни разу о такой реализации упоминаний не встречал - может и правда упустил что-то...

Нашел. Кажется, в Linux TCP keepalive (та самая простая перепосылка ACK время от времени) по умолчанию может быть выключен. Да, согласен, в этом случае возникает проблема, а настройка ОС клиентов в общем случае (типа SMTP) невозможна.

Ну что, надо подумать, как бы просигналить о том, что на этом соединении ее надо включать, таки действительно сделать draft.

Нашел. Кажется, в Linux TCP keepalive (та самая простая перепосылка ACK время от времени) по умолчанию может быть выключен. Да, согласен, в этом случае возникает проблема, а настройка ОС клиентов в общем случае (типа SMTP) невозможна.

Ну это всё же отдельная тема, и по-моему по дефолту интервал отправки keepalive - 2 часа.

Вот зоопарк не изучал, надо смотреть, что там в разных дистрибутивах. Навскидку сложилось впечатление, что он действительно может быть отключен по умолчанию. Впрочем, интервал 2 часа - это почти что отключен. Зачем так делать - непонятно :)

Но если так, то да, засады возможны. Не очень вероятны, но все же

в линуксе 2 часа, в freebsd - The default is 7200000 msec (2 hours)...в винде вроде так же.

в линуксе 2 часа, в freebsd - The default is 7200000 msec (2 hours)...в винде вроде так же.

"According to RFC 1122, keep-alive may be included in an implementation. If it is included, the interval between keep-alive packets MUST be configurable, and MUST default to no less than two hours."

аргументы смешные для 2017-го года: If keepalive is provided the RFC states that the required inter- keepalive distance MUST default to no less than two hours. If it does not, the probability of connections breaking increases, the bandwidth used due to keepalives increases, and cost increases over paths which charge per packet.

Дивный новый мир. Называется интернет вещей.

вот да. Mirai хорошо выступил :)

Ну что, пошел писать draft, чтобы сервер сигналил клиенту о необходимости агресивного keepalive.

Дело нехитрое, добровольное, полная обратная совместимость

можно даже не о кипаливах сигналить, а о том что "если после отсылки первого ACK нет данных от сервера в течение ХХ секунд" - считать соединение разорваным.

Ну и да, еще синкуки неприятны ppsами, которые сервервер может не держать. Опять же, вопрос подбора железа и тюнинга.

имхо, сейчас почти не осталось операционных систем, которые не живут под несколькими mpps.

ХХ задать в rfc. Но я что-то слабо себе представляю каким образом можно в одном единственном пакете передать что-то клиенту, учитывая что набор флагов мы менять не можем, а если вместо SYN-ACK отправлять какой-нибудь SYN-ACK-URG - наверняка что-нибудь сломается на "старом" клиенте...

Зачем? TCP options двух видов: "у меня тут SYNcookie, если после ACK молчание - рвите соединение" и "у меня тут SYNcookie, если после ACK молчание - перепосылайте почаще". Можно даже рекомендуемую частоту передать.

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

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

Ладно, это все завтра. Сейчас спать надо

Ну, про опции не знаю...Может и можно

Спокойной ночи!

Ну, MSS же уже так аджастят, и норм