comparison src/core/ngx_connection.c @ 5541:fdb67cfc957d

Fixed TCP_DEFER_ACCEPT handling (ticket #353). Backed out 05a56ebb084a, as it turns out that kernel can return connections without any delay if syncookies are used. This basically means we can't assume anything about connections returned with deferred accept set. To solve original problem the 05a56ebb084a tried to solve, i.e. to don't wait longer than needed if a connection was accepted after deferred accept timeout, this patch changes a timeout set with setsockopt(TCP_DEFER_ACCEPT) to 1 second, unconditionally. This is believed to be enough for speed improvements, and doesn't imply major changes to timeouts used. Note that before 2.6.32 connections were dropped after a timeout. Though it is believed that 1s is still appropriate for kernels before 2.6.32, as previously tcp_synack_retries controlled the actual timeout and 1s results in more than 1 minute actual timeout by default.
author Maxim Dounin <mdounin@mdounin.ru>
date Tue, 28 Jan 2014 15:40:46 +0400
parents c51b9491b0bd
children 3c5ddf0575d8
comparison
equal deleted inserted replaced
5540:3a8e19528b30 5541:fdb67cfc957d
699 #ifdef TCP_DEFER_ACCEPT 699 #ifdef TCP_DEFER_ACCEPT
700 700
701 if (ls[i].add_deferred || ls[i].delete_deferred) { 701 if (ls[i].add_deferred || ls[i].delete_deferred) {
702 702
703 if (ls[i].add_deferred) { 703 if (ls[i].add_deferred) {
704 value = (int) (ls[i].post_accept_timeout / 1000); 704 /*
705 * There is no way to find out how long a connection was
706 * in queue (and a connection may bypass deferred queue at all
707 * if syncookies were used), hence we use 1 second timeout
708 * here.
709 */
710 value = 1;
705 711
706 } else { 712 } else {
707 value = 0; 713 value = 0;
708 } 714 }
709 715