Главная страница


ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Valentin Nechayev                    2:5020/400     05 Mar 2006  12:19:26
 To : Alex Semenyaka
 Subject : Re: Форкающийся tcp-демон
 -------------------------------------------------------------------------------- 
 
 
 >>> Alex Semenyaka wrote: 
 
  AS>>> Hе так. По приходу ACK вываливаемся из listen. Более того, так как
  AS>>> сторона, где выполнялся listen, уже послала ACK, завершающий
  AS>>> handshake, то клиент мог (получив этот ACK) начать передачу данных.
  AS>>> Которые могут поступить ещё даже до начала accept, если сетка
  AS>>> быстрая, и/или сервер прогружен. Так что правильный ответ - как
  AS>>> минимум 3 пакета установления соединения, но, возможно, и
  AS>>> ещё сколько-то данных.
  VN>> Вообще-то ситуация ещё веселее: никто не запрещает в первом же
  VN>> SYN-пакете послать порцию данных.
 AS> Запрещать - не запрещает. Hо я тут на raw sockets и divertе программку летом
 AS> писал, TCP моделировал. Так вот, в этом случае всё плохо - отправитель
 AS> думает, что данные послал, а получатель их вовсе даже не подтверждает, а
 AS> возвращает ACK[dst] = ISN[src] + 1. Времени и возможности покопаться в коде 
 AS> TCP тогда не было, увы, чтобы понять, где это оно так - на первый беглый
 AS> взляд на код должно подтверждать бы. Yar@ и glebius@ дружно сказали, что так
 AS> и должно быть, и что это часть защиты от SYN-флуда.
 
 Да, в случае обнаружения SYN flood так безусловно надо делать. Hо в
 спокойной обстановке это, IMO, перебор. Впрочем, я не слышал ни
 одной жалобы (что логично - стилю реализации BSD sockets следуют
 
 этак >98% всех IP стеков, а в нём ты в принципе не отправишь данные
 
 пока не пройдёт 3-way handshake).
 
  VN>> но например в TLI интерфейсе (доступном на SysV системах) - штатное
  VN>> свойство интерфейса.
 AS> Только с SYN всё равно не пройдёт, как выяснилось :)
 
 Hадо на тех же SysV с серверной стороны проверить:)
 -netch-
 --- ifmail v.2.15dev5.3
  * Origin: Dark side of coredump (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 Re: Форкающийся tcp-демон   Valentin Davydov   04 Mar 2006 14:21:32 
 Re: Форкающийся tcp-демон   Konstantin Sorokin   04 Mar 2006 16:48:05 
 Re: Форкающийся tcp-демон   Vadim Goncharov   04 Mar 2006 16:54:38 
 Re: Форкающийся tcp-демон   Konstantin Sorokin   04 Mar 2006 17:41:26 
 Re: Форкающийся tcp-демон   Vadim Goncharov   04 Mar 2006 17:59:38 
 Форкающийся tcp-демон   Alex Semenyaka   04 Mar 2006 17:30:52 
 Re: Форкающийся tcp-демон   Vadim Goncharov   04 Mar 2006 18:06:41 
 Форкающийся tcp-демон   Alex Semenyaka   04 Mar 2006 19:42:36 
 Re: Форкающийся tcp-демон   Vadim Goncharov   05 Mar 2006 16:23:45 
 Форкающийся tcp-демон   Alex Mogilnikov   04 Mar 2006 21:42:17 
 Форкающийся tcp-демон   Alex Semenyaka   05 Mar 2006 05:01:50 
 Re: Форкающийся tcp-демон   Valentin Nechayev   05 Mar 2006 12:15:23 
 Форкающийся tcp-демон   Alex Semenyaka   05 Mar 2006 14:25:42 
 Re: Форкающийся tcp-демон   Valentin Nechayev   04 Mar 2006 20:47:57 
 Форкающийся tcp-демон   Alex Semenyaka   05 Mar 2006 05:34:34 
 Re: Форкающийся tcp-демон   Valentin Nechayev   05 Mar 2006 12:19:26 
 Re: Форкающийся tcp-демон   Vadim Goncharov   05 Mar 2006 16:39:51 
 Форкающийся tcp-демон   Alex Semenyaka   05 Mar 2006 19:07:50 
 Re: Форкающийся tcp-демон   Vadim Goncharov   08 Mar 2006 16:20:59 
 Форкающийся tcp-демон   Alex Semenyaka   08 Mar 2006 22:32:30 
Архивное /ru.unix.bsd/223830bcc4ab6.html, оценка 2 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional