Set the nginx listening set interface

If (ls [I]. listen) {/* changebacklogvialisten () * // change the number of listeners if (listen (ls [I]. fd, ls [I]. backlog)-1 ){/...
If (ls [I]. listen) {/* change backlog via listen () * // change the number of listeners 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);} www.2cto.com}/** setting deferred mode shocould be last operation on socket, * because code may prema Turely continue cycle on failure */# if (NGX_HAVE_DEFERRED_ACCEPT) # ifdef SO_ACCEPTFILTER // used by freebsd // The First 1st options we consider is TCP_DEFER_ACCEPT (this is the name of the Linux system, other operating systems also have the same option but use different names ). To // understand the specific ideas of the TCP_DEFER_ACCEPT option, it is necessary to briefly describe the typical HTTP client/server interaction process. Recall how TCP establishes a connection with the object/Mark of the transmitted data. On the network, the information transmitted between separated units is called an IP packet (or an IP // datagram ). A packet always has a header containing service information, which is used for internal protocol processing and can also carry data load. A typical example of service information is a set of so-called labels, which mark packets with special meanings in the TCP/IP protocol stack, such as the success confirmation of packets received. Generally, it is entirely possible to carry the load in a tagged packet, but sometimes the internal logic forces the TCP/IP protocol // stack to issue an IP packet with only a packet header. These packages often cause annoying network latency and increase the system load. as a result, the overall network performance is reduced. // Now the server creates a socket and waits for the connection. The TCP/IP connection process is called "three handshakes ". First, the client program sends a // TCP packet (a SYN packet) that sets the SYN flag without data load ). The server sends a packet with the SYN/ACK mark (a SYN/ACK packet) as the confirmation response of the packet received just now. The customer then sends an ACK package and confirms that 2nd packets are received to end the connection process. After receiving the SYN/ACK packet from the customer, the server will wake up a receiving process waiting for data to arrive. After three handshakes are completed, the client program starts to send "useful" data to the server. Generally, an HTTP request is very small and can be fully loaded into a package. However, in the above cases, at least four packages will be used for bidirectional transmission/transmission, which increases the latency. In addition, you must note that the recipient has begun waiting for information before "useful" data is sent. // To mitigate the impact of these problems, Linux (and other operating systems) includes the TCP_DEFER_ACCEPT option in its TCP implementation. They are set on the server that listens for packets/characters. the kernel of this option does not initialize the listening process until the last ACK package arrives and 1st packets with real data arrive. After a SYN/ACK packet is sent, the server waits for the client to send an IP packet containing data in a specific order. Now, you only need to transfer three packets on the network, and it also significantly reduces the delay of connection establishment, especially for HTTP communication. // This option has a peer object on many operating systems. For example, on FreeBSD, the same behavior can be implemented using the following code: // * for clarity, the irrelevant code is omitted here * // struct accept_filter_arg af = {"dataready ", ""}; // setsockopt (s, SOL_SOCKET, SO_ACCEPTFILTER, & af, sizeof (af); // This feature is called "accept filter" on FreeBSD ", it also has multiple usage methods. However, in almost all cases, the effect is the same as that of TCP_DEFER_ACCEPT: The server // does not wait for the last ACK packet, but only for the packet carrying the data load. For more information about this option and its significance to high-performance Web servers, see The Apache documentation. // For HTTP client/server interaction, the behavior of the client program may need to be changed. Why does the customer program send this "useless" ACK package? This is because the TCP protocol stack cannot know the ACK // package status. If FTP is used instead of HTTP, the client program will not send data until it receives the data packet prompted by the FTP server. In this case, a delayed ACK will lead to a delay in the customer/server/interaction. To determine whether ACK is necessary, the customer program must know the application protocol and its current status. In this way, it is necessary to modify the customer behavior. // For Linux client programs, we can also use another option, which is also called TCP_DEFER_ACCEPT. As we know, sockets are divided into two types: listening sockets and connection sockets, which have their respective sets of TCP options. Therefore, the two options that are often used at the same time have the same name. After this option is set on the connection socket, the customer no longer sends the ACK packet after // receives a SYN/ACK packet, but waits for the user program to send data requests. therefore, the number of packets sent by the server is reduced accordingly. If (ls [I]. delete_deferred) {if (setsockopt (ls [I]. fd, SOL_SOCKET, SO_ACCEPTFILTER, NULL, 0) // SOL_SOCKET: basic set of interfaces to reduce the delay efficiency of packet receipt and delivery waiting =-1) www.2cto.com {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, "cocould not change the accept filter" "to \" % S \ "for % V, ignored", ls [I]. accept_filter, & ls [I]. addr_text);} www.2cto.com 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_A LERT, 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 www.2cto.com # ifdef TCP_DEFER_ACCEPT // if (ls [I] for linux. add_deferred | ls [I]. delete_deferred) {// go here if (ls [I]. add_deferred) {timeout = (int) (ls [I]. post_accept_timeout/1000);} else {timeout = 0;} // use TCP_DE FER_ACCEPT can reduce the number of connections held by the user program, or reduce the number of times that the user calls epoll_ctl and epoll_wait, thus improving the program performance. // After the TCP_DEFER_ACCEPT option of the listen socket is set, only data in a link is returned from accpet (instead of three handshakes ). // Timeout parameter: www.2cto.com // when the server has not received data, it resends SYN/ACK to the client. ipv4.tcp _ synack_retries = 5. // timeout = 0 indicates canceling the TCP_DEFER_ACCEPT option // performance 4 killer: Memory Copy, memory allocation, process switching, and system call. // The contribution of TCP_DEFER_ACCEPT to performance lies in reducing system calls. // The unit of timeout is seconds. Note that if this function is enabled, the kernel does not receive data within val seconds and will not wake up the process, but directly discard the connection. // After testing, it is found that after the TCP_DEFER_ACCEPT option is set, the operating system does not Accept or create an IO handle after the server receives a CONNECT request. The related link will be released after the operating system is several seconds (but it must be much larger than the 1 s set above. But the corresponding port is not closed at the same time, so the client will always think that it is in the link state. If data is sent immediately after Connect, the server will call Accept to receive the connection port. // It seems that this port setting is very effective for the attack method that connects to the CONNECT link and does nothing. The original code allows connections first and then times Out. this is a bit Out of the code. However, this option may cause some problems to be located. // They are set on the server that listens to the socket. the kernel of this option does not wait for the last ACK packet, and the listening process is initialized only when 1st packets with real data arrive. After a SYN/ACK packet is sent, the server waits for the client program to send an IP packet containing data. Now, only three packets need to be transmitted on the network, and the delay of connection establishment is also significantly reduced, especially for HTTP communication. This option has an equivalent in many operating systems. // This is because the TCP protocol stack cannot know the ACK packet status. If FTP is used instead of HTTP, the client program will not send data until it receives the data packet prompted by the FTP server. In this case, a delayed ACK will lead to a delay in customer/server interaction. To determine whether ACK is necessary, the customer program must know the application protocol and its current status. In this way, it is necessary to modify the customer behavior. // After this option is set on the connection socket, the customer will not send the ACK packet after receiving a SYN/ACK packet, but will wait for the user program to send the data request. therefore, the number of packets sent by the server is reduced accordingly. Www.2cto.com // TCP_QUICKACK // Another way to prevent delay caused by sending useless packets is to use the TCP_QUICKACK option. Unlike CP_DEFER_ACCEPT, this option can be used not only to manage the connection establishment process, but also during normal data transmission. In addition, it can be set on either side of the client/server connection. If you know that the data is about to be sent soon, the delay in sending the ACK package will come in handy, and it is best to set the ACK flag on the data packet to minimize the network load. When the sender confirms that the data will be sent immediately (multiple packets), the TCP_QUICKACK option can be set to 0. For sockets in the "connection" status, the default value of this option is 1. after the first use, the kernel will immediately reset this option to 1 (this is a one-time option ). // In some cases, it is very useful to issue an ACK package. The ACK package will confirm the receipt of the data block, and the delay will not be introduced when the current one is processed. This data transmission mode is quite typical for the interaction process, because in such cases, users' input time cannot be predicted. In Linux, this is the default socket behavior. In the above circumstances, the client program is sending an HTTP request to the server, but the pre-known // request packet is very short, so it should be sent immediately after the connection is established, this is a typical way of working with HTTP. Since there is no need to send a pure ACK package, it is entirely possible to set TCP_QUICKACK to 0 to improve performance. On the server side, both options can be set only once on the listening socket. All sockets, that is, sockets indirectly created by the accepted call, inherit all the options of the original socket. Www.2cto.com if (setsockopt (ls [I]. fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, & timeout, sizeof (int) // This is used on the web server, but you do not need to set =-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;} www.2cto.com # endif/* NGX_HAVE_DEFERRED_ACCEPT */} return ;}