if (ls[i].listen) {
/* change backlog via listen() */
//改变每个监听的数目
if (listen(ls[i].fd, ls[i].backlog) == -1) { //ls[i].fd 10, ls[i].backlog 511
ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_socket_errno,
"listen() to %V, backlog %d failed, ignored",
&ls[i].addr_text, ls[i].backlog);
}
}
/*
* setting deferred mode should be last operation on socket,
* because code may prematurely continue cycle on failure
*/
#if (NGX_HAVE_DEFERRED_ACCEPT)
#ifdef SO_ACCEPTFILTER //freebsd所用
// 我们首先考虑的第1个选项是TCP_DEFER_ACCEPT（这是Linux系统上的叫法，其他一些操作系统上也有同样的选项但使用不同的名字）。为了
// 理解TCP_DEFER_ACCEPT选项的具体思想，我们有必要大致阐述一下典型的HTTP客户/服务器交互过程。请回想下TCP是如何与传输数据的目
// 标建立连接的。在网络上，在分离的单元之间传输的信息称为IP包（或IP
// 数据报）。一个包总有一个携带服务信息的包头，包头用于内部协议的处理，并且它也可以携带数据负载。服务信息的典型例子就是一套所谓的标志，它把包标记代
// 表TCP/IP协议栈内的特殊含义，例如收到包的成功确认等等。通常，在经过“标记”的包里携带负载是完全可能的，但有时，内部逻辑迫使TCP/IP协议
// 栈发出只有包头的IP包。这些包经常会引发讨厌的网络延迟而且还增加了系统的负载，结果导致网络性能在整体上降低。
// 现在服务器创建了一个套接字同时等待连接。TCP/IP式的连接过程就是所谓“3次握手”。首先，客户程序发送一个设置SYN标志而且不带数据负载的
// TCP包（一个SYN包）。服务器则以发出带SYN/ACK标志的数据包（一个SYN/ACK包）作为刚才收到包的确认响应。客户随后发送一个ACK包确
// 认收到了第2个包从而结束连接过程。在收到客户发来的这个SYN/ACK包之后，服务器会唤醒一个接收进程等待数据到达。当3次握手完成后，客户程序即开
// 始把“有用的”的数据发送给服务器。通常，一个HTTP请求的量是很小的而且完全可以装到一个包里。但是，在以上的情况下，至少有4个包将用来进行双向传
// 输，这样就增加了可观的延迟时间。此外，你还得注意到，在“有用的”数据被发送之前，接收方已经开始在等待信息了。
// 为了减轻这些问题所带来的影响，Linux（以及其他的一些操作系统）在其TCP实现中包括了TCP_DEFER_ACCEPT选项。它们设置在侦听套接
// 字的服务器方，该选项命令内核不等待最后的ACK包而且在第1个真正有数据的包到达才初始化侦听进程。在发送SYN/ACK包之后，服务器就会等待客户程
// 序发送含数据的IP包。现在，只需要在网络上传送3个包了，而且还显著降低了连接建立的延迟，对HTTP通信而言尤其如此。
// 这一选项在好些操作系统上都有相应的对等物。例如，在FreeBSD上，同样的行为可以用以下代码实现：
// /* 为明晰起见，此处略去无关代码 */
// struct accept_filter_arg af = { "dataready", "" };
// setsockopt(s, SOL_SOCKET, SO_ACCEPTFILTER, &af, sizeof(af));
// 这个特征在FreeBSD上叫做“接受过滤器”，而且具有多种用法。不过，在几乎所有的情况下其效果与TCP_DEFER_ACCEPT是一样的：服务器
// 不等待最后的ACK包而仅仅等待携带数据负载的包。要了解该选项及其对高性能Web服务器的重要意义的更多信息请参考Apache文档上的有关内容。
// 就HTTP客户/服务器交互而言，有可能需要改变客户程序的行为。客户程序为什么要发送这种“无用的”ACK包呢？这是因为，TCP协议栈无法知道ACK
// 包的状态。如果采用FTP而非HTTP，那么客户程序直到接收了FTP服务器提示的数据包之后才发送数据。在这种情况下，延迟的ACK将导致客户/服务器
// 交互出现延迟。为了确定ACK是否必要，客户程序必须知道应用程序协议及其当前状态。这样，修改客户行为就成为必要了。
// 对Linux客户程序来说，我们还可以采用另一个选项，它也被叫做TCP_DEFER_ACCEPT。我们知道，套接字分成两种类型，侦听套接字和连接套
// 接字，所以它们也各自具有相应的TCP选项集合。因此，经常同时采用的这两类选项却具有同样的名字也是完全可能的。在连接套接字上设置该选项以后，客户在
// 收到一个SYN/ACK包之后就不再发送ACK包，而是等待用户程序的下一个发送数据请求；因此，服务器发送的包也就相应减少了。
if (ls[i].delete_deferred) {
if (setsockopt(ls[i].fd, SOL_SOCKET, SO_ACCEPTFILTER, NULL, 0) //SOL_SOCKET: 基本套接口，减少收到和发送包等待的延迟效率
== -1)
{
ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
"setsockopt(SO_ACCEPTFILTER, NULL) "
"for %V failed, ignored",
&ls[i].addr_text);
if (ls[i].accept_filter) {
ngx_log_error(NGX_LOG_ALERT, cycle->log, 0,
"could not change the accept filter "
"to \"%s\" for %V, ignored",
ls[i].accept_filter, &ls[i].addr_text);
}
continue;
}
ls[i].deferred_accept = 0;
}
if (ls[i].add_deferred) {
ngx_memzero(&af, sizeof(struct accept_filter_arg));
(void) ngx_cpystrn((u_char *) af.af_name,
(u_char *) ls[i].accept_filter, 16);
if (setsockopt(ls[i].fd, SOL_SOCKET, SO_ACCEPTFILTER,
&af, sizeof(struct accept_filter_arg))
== -1)
{
ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
"setsockopt(SO_ACCEPTFILTER, \"%s\") "
"for %V failed, ignored",
ls[i].accept_filter, &ls[i].addr_text);
continue;
}
ls[i].deferred_accept = 1;
}
#endif
#ifdef TCP_DEFER_ACCEPT //linux所用
if (ls[i].add_deferred || ls[i].delete_deferred) { //走到这里
if (ls[i].add_deferred) {
timeout = (int) (ls[i].post_accept_timeout / 1000);
} else {
timeout = 0;
}
// 使用TCP_DEFER_ACCEPT可以减少用户程序hold的连接数，也可以减少用户调用epoll_ctl和epoll_wait的次数，从而提高了程序的性能。
// 设置listen套接字的TCP_DEFER_ACCEPT选项后， 只当一个链接有数据时是才会从accpet中返回（而不是三次握手完成)。
// timeout参数：
// 当服务端一直没接受到数据后,会重发SYN/ACK给客户端，当超过(net.ipv4.tcp_synack_retries = 5)次后， 就开始timeout的计时.
// timeout = 0表示取消 TCP_DEFER_ACCEPT选项
// 性能四杀手：内存拷贝，内存分配，进程切换，系统调用。
// TCP_DEFER_ACCEPT 对性能的贡献，就在于 减少系统调用了。
// 里面 timeout 的单位是秒，注意如果打开这个功能，kernel 在 val 秒之内还没有收到数据，不会继续唤醒进程，而是直接丢弃连接。
// 经过测试发现，设置TCP_DEFER_ACCEPT选项后，服务器受到一个CONNECT请求后，操作系统不会Accept，也不会创建IO句柄。操作系统应该在若干秒，(但肯定远远大于上面设置的1s) 后，会释放相关的链接。但没有同时关闭相应的端口，所以客户端会一直以为处于链接状态。如果Connect后面马上有后续的发送数据，那么服务器会调用Accept接收这个链接端口。
// 感觉了一下，这个端口设置对于CONNECT链接上来而又什么都不干的攻击方式处理很有效。我们原来的代码都是先允许链接，然后再进行超时处理，比他这个有点Out了。不过这个选项可能会导致定位某些问题麻烦。
// 它们设置在侦听套接字的服务器方，该选项命令内核不等待最后的ACK包而且在第1个真正有数据的包到达才初始化侦听进程。在发送SYN/ACK包之后，服务器就会等待客户程序发送含数据的IP包。现在，只需要在网络上传送3个包了，而且还显着降低了连接建立的延迟，对HTTP通信而言尤其如此。这一选项在好些操作系统上都有相应的对等物。
// 这是因为，TCP协议栈无法知道ACK包的状态。如果采用FTP而非HTTP，那么客户程序直到接收了FTP服务器提示的数据包之后才发送数据。在这种情况下，延迟的ACK将导致客户/服务器交互出现延迟。为了确定ACK是否必要，客户程序必须知道应用程序协议及其当前状态。这样，修改客户行为就成为必要了。
// 在连接套接字上设置该选项以后，客户在收到一个SYN/ACK包之后就不再发送ACK包，而是等待用户程序的下一个发送数据请求；因此，服务器发送的包也就相应减少了。
// TCP_QUICKACK
// 阻止因发送无用包而引发延迟的另一个方法是使用TCP_QUICKACK选项。这一选项与 CP_DEFER_ACCEPT不同，它不但能用作管理连接建立过程而且在正常数据传输过程期间也可以使用。另外，它能在客户/服务器连接的任何一方设置。如果知道数据不久即将发送，那么推迟ACK包的发送就会派上用场，而且最好在那个携带数据的数据包上设置ACK 标志以便把网络负载减到最小。当发送方肯定数据将被立即发送（多个包）时，TCP_QUICKACK选项可以设置为0。对处于“连接”状态下的套接字该选项的缺省值是1，首次使用以后内核将把该选项立即复位为1（这是个一次性的选项）。
// 在某些情形下，发出ACK包则非常有用。ACK包将确认数据块的接收，而且，当下一块被处理时不至于引入延迟。这种数据传输模式对交互过程是相当典型的，因为此类情况下用户的输入时刻无法预测。在Linux系统上这就是缺省的套接字行为。在上述情况下，客户程序在向服务器发送HTTP请求，而预先就知
// 道请求包很短所以在连接建立之后就应该立即发送，这可谓HTTP的典型工作方式。既然没有必要发送一个纯粹的ACK包，所以设置 TCP_QUICKACK为0以提高性能是完全可能的。在服务器方，这两种选项都只能在侦听套接字上设置一次。所有的套接字，也就是被接受呼叫间接创建的套接字则会继承原有套接字的所有选项。
if (setsockopt(ls[i].fd, IPPROTO_TCP, TCP_DEFER_ACCEPT,
&timeout, sizeof(int)) //在web服务器采用这个，但在ftp服务器不需要设置
== -1)
{
ngx_log_error(NGX_LOG_ALERT, cycle->log, ngx_errno,
"setsockopt(TCP_DEFER_ACCEPT, %d) for %V failed, "
"ignored",
timeout, &ls[i].addr_text);
continue;
}
}
if (ls[i].add_deferred) {
ls[i].deferred_accept = 1;
}
#endif
#endif /* NGX_HAVE_DEFERRED_ACCEPT */
}
return;
}
阅读(2719) | 评论(0) | 转发(1) |
