> > > > Ну и как итог - все это является следствием "нормального"
> поведения
> > > > клиентских браузеров посетителей сайта, и с серверной стороны
> это
> > > > никак не побороть?
> > >
> > > Стоит посмотреть в сторону accept-фильтров/TCP_DEFER_ACCEPT.
> > > http://nginx.org/r/listen/ru
> >
> > счастливым обладателям freebsd может быть и стоит, но у меня debian
> где это
> > не поддерживается...
> >
>
> % uname
> Linux
> % man tcp
>
> TCP_DEFER_ACCEPT (since Linux 2.4)
> Allow a listener to be awakened only when data arrives
> on the
> socket. Takes an integer value (seconds), this can
> bound the
> maximum number of attempts TCP will make to complete the
> connec‐
> tion. This option should not be used in code
> intended to be
> portable.
>
если бы все было так просто....
подозреваю, что разработчики хрома считают себя весьма хитрыми людьми и делают против этого какой-то трюк с фиктивной отсылкой данных:
+listen 80 default_server backlog=1024 sndbuf=512k deferred;
после этого в логах все еще интереснее:
2012/09/19 11:53:22 [debug] 27380#0: *421 accept: 79.164.125.238 fd:85
2012/09/19 11:53:22 [debug] 27380#0: *421 post event 00007FD536406738
2012/09/19 11:53:22 [debug] 27380#0: *421 delete posted event 00007FD536406738
2012/09/19 11:53:22 [debug] 27380#0: *421 malloc: 0000000000830860:1296
2012/09/19 11:53:22 [debug] 27380#0: *421 posix_memalign: 0000000000830D80:256 @16
2012/09/19 11:53:22 [debug] 27380#0: *421 malloc: 0000000000884870:16384
2012/09/19 11:53:22 [debug] 27380#0: *421 posix_memalign: 0000000000830E90:4096 @16
2012/09/19 11:53:22 [debug] 27380#0: *421 http process request line
2012/09/19 11:53:22 [debug] 27380#0: *421 recv: fd:85 -1 of 16384
2012/09/19 11:53:22 [debug] 27380#0: *421 recv() not ready (11: Resource temporarily unavailable)
2012/09/19 11:53:22 [debug] 27380#0: *421 event timer add: 85: 3000:1348041205251
2012/09/19 11:53:22 [debug] 27380#0: *421 epoll add event: fd:85 op:1 ev:80000001
и затем через 3 секунды
2012/09/19 11:53:25 [debug] 27380#0: *421 event timer del: 85: 1348041205251
2012/09/19 11:53:25 [debug] 27380#0: *421 http process request line
2012/09/19 11:53:25 [info] 27380#0: *421 client timed out (110: Connection timed out) while reading client request line, client: 79.164.125.238, server: coolsite.ru
2012/09/19 11:53:25 [debug] 27380#0: *421 http request count:1 blk:0
2012/09/19 11:53:25 [debug] 27380#0: *421 http close request
2012/09/19 11:53:25 [debug] 27380#0: *421 http log handler
2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830E90, unused: 2208
2012/09/19 11:53:25 [debug] 27380#0: *421 close http connection: 85
2012/09/19 11:53:25 [debug] 27380#0: *421 reusable connection: 0
2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000884870
2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830860
2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830750, unused: 0
2012/09/19 11:53:25 [debug] 27380#0: *421 free: 0000000000830D80, unused: 112
то есть как я понимаю запрос шлется не целиком (может вообще 1 байт), затем соединение уходит в состояние ожидания и потом все равно также отваливается только по таймауту. в freebsd accf_http наверное помог бы (и то может они и для него чего-то делают), а в linux получается что все, финита
