comparison src/core/ngx_connection.c @ 5569:462ae7eedc68 stable-1.4

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 f941cf265cc5
children
comparison
equal deleted inserted replaced
5568:560de9681661 5569:462ae7eedc68
645 #ifdef TCP_DEFER_ACCEPT 645 #ifdef TCP_DEFER_ACCEPT
646 646
647 if (ls[i].add_deferred || ls[i].delete_deferred) { 647 if (ls[i].add_deferred || ls[i].delete_deferred) {
648 648
649 if (ls[i].add_deferred) { 649 if (ls[i].add_deferred) {
650 timeout = (int) (ls[i].post_accept_timeout / 1000); 650 /*
651 * There is no way to find out how long a connection was
652 * in queue (and a connection may bypass deferred queue at all
653 * if syncookies were used), hence we use 1 second timeout
654 * here.
655 */
656 timeout = 1;
651 657
652 } else { 658 } else {
653 timeout = 0; 659 timeout = 0;
654 } 660 }
655 661