Nginx學習筆記（二） Nginx--connection&request

Nginx--connection&request

　　在Nginx中，主要包括了連接與處理兩部分。

connection

　　在src/core文件夾下包含有connection的源文件，Ngx_connection.h/Ngx_connection.c中可以找到SOCK_STREAM，也就是說Nginx是基於TCP連接的。

連接過程

　　對於應用程序,首先第一步肯定是加載並解析配置文件，Nginx同樣如此，這樣可以獲得需要監聽的端口和IP地址。之后，Nginx就要創建master進程，並建立socket，這樣就可以創建多個worker進程來，每個worker進程都可以accept連接請求。當通過三次握手成功建立一個連接后，nginx的某一個worker進程會accept成功，得到這個建立好的連接的socket，然后創建ngx_connection_t結構體，存儲客戶端相關內容。

　　這樣建立好連接后，服務器和客戶端就可以正常進行讀寫事件了。連接完成后就可以釋放掉ngx_connection_t結構體了。

　　同樣，Nginx也可以作為客戶端，這樣就需要先創建一個ngx_connection_t結構體，然后創建socket，並設置socket的屬性（ 比如非阻塞）。然后再通過添加讀寫事件，調用connect/read/write來調用連接，最后關掉連接，並釋放ngx_connection_t。

struct ngx_connection_s {
    void               *data;
    ngx_event_t        *read;
    ngx_event_t        *write;

    ngx_socket_t        fd;

    ngx_recv_pt         recv;
    ngx_send_pt         send;
    ngx_recv_chain_pt   recv_chain;
    ngx_send_chain_pt   send_chain;

    ngx_listening_t    *listening;

    off_t               sent;

    ngx_log_t          *log;

    ngx_pool_t         *pool;

    struct sockaddr    *sockaddr;
    socklen_t           socklen;
    ngx_str_t           addr_text;

#if (NGX_SSL)
    ngx_ssl_connection_t  *ssl;
#endif

    struct sockaddr    *local_sockaddr;

    ngx_buf_t          *buffer;

    ngx_queue_t         queue;

    ngx_atomic_uint_t   number;

    ngx_uint_t          requests;

    unsigned            buffered:8;

    unsigned            log_error:3;     /* ngx_connection_log_error_e */

    unsigned            unexpected_eof:1;
    unsigned            timedout:1;
    unsigned            error:1;
    unsigned            destroyed:1;

    unsigned            idle:1;
    unsigned            reusable:1;
    unsigned            close:1;

    unsigned            sendfile:1;
    unsigned            sndlowat:1;
    unsigned            tcp_nodelay:2;   /* ngx_connection_tcp_nodelay_e */
    unsigned            tcp_nopush:2;    /* ngx_connection_tcp_nopush_e */

#if (NGX_HAVE_IOCP)
    unsigned            accept_context_updated:1;
#endif

#if (NGX_HAVE_AIO_SENDFILE)
    unsigned            aio_sendfile:1;
    ngx_buf_t          *busy_sendfile;
#endif

#if (NGX_THREADS)
    ngx_atomic_t        lock;
#endif
};

 

連接池

 　　在linux系統中，每一個進程能夠打開的文件描述符fd是有限的，而每創建一個socket就會占用一個fd，這樣創建的socket就會有限的。在Nginx中，采用連接池的方法，可以避免這個問題。

 　　Nginx在實現時，是通過一個連接池來管理的，每個worker進程都有一個獨立的連接池，連接池的大小是worker_connections。這里的連接池里面保存的其實不是真實的連接，它只是一個worker_connections大小的一個ngx_connection_t結構的數組。並且，nginx會通過一個鏈表free_connections來保存所有的空閑ngx_connection_t，每次獲取一個連接時，就從空閑連接鏈表中獲取一個，用完后，再放回空閑連接鏈表里面（這樣就節省了創建與銷毀connection結構的開銷）。

　　所以對於一個Nginx服務器來說,它所能創建的連接數也就是socket連接數目可以達到worker_processes（worker數）*worker_connections。

競爭問題

　　對於多個worker進程同時accpet時產生的競爭，有可能導致某一worker進程accept了大量的連接，而其他worker進程卻沒有幾個連接，這樣就導致了負載不均衡，對於負載重的worker進程中的連接響應時間必然會增大。很顯然，這是不公平的，有的進程有空余連接，卻沒有處理機會，有的進程因為沒有空余連接，卻人為地丟棄連接。

　　nginx中存在accept_mutex選項，只有獲得了accept_mutex的進程才會去添加accept事件，也就是說，nginx會控制進程是否添加accept事件。nginx使用一個叫ngx_accept_disabled的變量來控制進程是否去競爭accept_mutex鎖。

ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;  //可以看出來隨着空余連接的增加，disabled的值降低

 if (ngx_use_accept_mutex) {
        if (ngx_accept_disabled > 0) {　　　　　　　　　　　//當disabled的值大於0時，禁止競爭，但每次-1
            ngx_accept_disabled--;
        } else {
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }
　　　　　　　if (ngx_accept_mutex_held) {
                flags |= NGX_POST_EVENTS;
            } else {
                if (timer == NGX_TIMER_INFINITE
                    || timer > ngx_accept_mutex_delay) {
                    timer = ngx_accept_mutex_delay;
                }
            }
        }
}

request

　　在nginx中，request是http請求，具體到nginx中的數據結構是ngx_http_request_t。ngx_http_request_t是對一個http請求的封裝。 

struct ngx_http_request_s {
    uint32_t                          signature;         /* "HTTP" */

    ngx_connection_t                 *connection;

    void                            **ctx;
    void                            **main_conf;
    void                            **srv_conf;
    void                            **loc_conf;

    ngx_http_event_handler_pt         read_event_handler;
    ngx_http_event_handler_pt         write_event_handler;

#if (NGX_HTTP_CACHE)
    ngx_http_cache_t                 *cache;
#endif

    ngx_http_upstream_t              *upstream;
    ngx_array_t                      *upstream_states;
                                         /* of ngx_http_upstream_state_t */

    ngx_pool_t                       *pool;
    ngx_buf_t                        *header_in;

    ngx_http_headers_in_t             headers_in;
    ngx_http_headers_out_t            headers_out;

    ngx_http_request_body_t          *request_body;

    time_t                            lingering_time;
    time_t                            start_sec;
    ngx_msec_t                        start_msec;

    ngx_uint_t                        method;
    ngx_uint_t                        http_version;

    ngx_str_t                         request_line;
    ngx_str_t                         uri;
    ngx_str_t                         args;
    ngx_str_t                         exten;
    ngx_str_t                         unparsed_uri;

    ngx_str_t                         method_name;
    ngx_str_t                         http_protocol;

    ngx_chain_t                      *out;
    ngx_http_request_t               *main;
    ngx_http_request_t               *parent;
    ngx_http_postponed_request_t     *postponed;
    ngx_http_post_subrequest_t       *post_subrequest;
    ngx_http_posted_request_t        *posted_requests;

    ngx_int_t                         phase_handler;
    ngx_http_handler_pt               content_handler;
    ngx_uint_t                        access_code;

    ngx_http_variable_value_t        *variables;

#if (NGX_PCRE)
    ngx_uint_t                        ncaptures;
    int                              *captures;
    u_char                           *captures_data;
#endif

    size_t                            limit_rate;

    /* used to learn the Apache compatible response length without a header */
    size_t                            header_size;

    off_t                             request_length;

    ngx_uint_t                        err_status;

    ngx_http_connection_t            *http_connection;
#if (NGX_HTTP_SPDY)
    ngx_http_spdy_stream_t           *spdy_stream;
#endif

    ngx_http_log_handler_pt           log_handler;

    ngx_http_cleanup_t               *cleanup;

    unsigned                          subrequests:8;
    unsigned                          count:8;
    unsigned                          blocked:8;

    unsigned                          aio:1;

    unsigned                          http_state:4;

    /* URI with "/." and on Win32 with "//" */
    unsigned                          complex_uri:1;

    /* URI with "%" */
    unsigned                          quoted_uri:1;

    /* URI with "+" */
    unsigned                          plus_in_uri:1;

    /* URI with " " */
    unsigned                          space_in_uri:1;

    unsigned                          invalid_header:1;

    unsigned                          add_uri_to_alias:1;
    unsigned                          valid_location:1;
    unsigned                          valid_unparsed_uri:1;
    unsigned                          uri_changed:1;
    unsigned                          uri_changes:4;

    unsigned                          request_body_in_single_buf:1;
    unsigned                          request_body_in_file_only:1;
    unsigned                          request_body_in_persistent_file:1;
    unsigned                          request_body_in_clean_file:1;
    unsigned                          request_body_file_group_access:1;
    unsigned                          request_body_file_log_level:3;

    unsigned                          subrequest_in_memory:1;
    unsigned                          waited:1;

#if (NGX_HTTP_CACHE)
    unsigned                          cached:1;
#endif

#if (NGX_HTTP_GZIP)
    unsigned                          gzip_tested:1;
    unsigned                          gzip_ok:1;
    unsigned                          gzip_vary:1;
#endif

    unsigned                          proxy:1;
    unsigned                          bypass_cache:1;
    unsigned                          no_cache:1;

    /*
     * instead of using the request context data in
     * ngx_http_limit_conn_module and ngx_http_limit_req_module
     * we use the single bits in the request structure
     */
    unsigned                          limit_conn_set:1;
    unsigned                          limit_req_set:1;

#if 0
    unsigned                          cacheable:1;
#endif

    unsigned                          pipeline:1;
    unsigned                          chunked:1;
    unsigned                          header_only:1;
    unsigned                          keepalive:1;
    unsigned                          lingering_close:1;
    unsigned                          discard_body:1;
    unsigned                          internal:1;
    unsigned                          error_page:1;
    unsigned                          ignore_content_encoding:1;
    unsigned                          filter_finalize:1;
    unsigned                          post_action:1;
    unsigned                          request_complete:1;
    unsigned                          request_output:1;
    unsigned                          header_sent:1;
    unsigned                          expect_tested:1;
    unsigned                          root_tested:1;
    unsigned                          done:1;
    unsigned                          logged:1;

    unsigned                          buffered:4;

    unsigned                          main_filter_need_in_memory:1;
    unsigned                          filter_need_in_memory:1;
    unsigned                          filter_need_temporary:1;
    unsigned                          allow_ranges:1;

#if (NGX_STAT_STUB)
    unsigned                          stat_reading:1;
    unsigned                          stat_writing:1;
#endif

    /* used to parse HTTP headers */

    ngx_uint_t                        state;

    ngx_uint_t                        header_hash;
    ngx_uint_t                        lowcase_index;
    u_char                            lowcase_header[NGX_HTTP_LC_HEADER_LEN];

    u_char                           *header_name_start;
    u_char                           *header_name_end;
    u_char                           *header_start;
    u_char                           *header_end;

    /*
     * a memory that can be reused after parsing a request line
     * via ngx_http_ephemeral_t
     */

    u_char                           *uri_start;
    u_char                           *uri_end;
    u_char                           *uri_ext;
    u_char                           *args_start;
    u_char                           *request_start;
    u_char                           *request_end;
    u_char                           *method_end;
    u_char                           *schema_start;
    u_char                           *schema_end;
    u_char                           *host_start;
    u_char                           *host_end;
    u_char                           *port_start;
    u_char                           *port_end;

    unsigned                          http_minor:16;
    unsigned                          http_major:16;
};

 

HTTP

 　　這里需要復習下Http協議了。

　　http請求是典型的請求-響應類型的的網絡協議，需要一行一行的分析請求行與請求頭，以及輸出響應行與響應頭。

　　Request 消息分為3部分，第一部分叫請求行requset line， 第二部分叫http header, 第三部分是body. header和body之間有個空行。

　　Response消息的結構， 和Request消息的結構基本一樣。 同樣也分為三部分，第一部分叫response line, 第二部分叫response header，第三部分是body. header和body之間也有個空行。

　　分別為Request和Response消息結構圖：

處理流程

　　worker進程負責業務處理。在worker進程中有一個函數ngx_worker_process_cycle()，執行無限循環，不斷處理收到的來自客戶端的請求，並進行處理，直到整個nginx服務被停止。

　　一個HTTP Request的處理過程:　

1. 初始化HTTP Request（讀取來自客戶端的數據，生成HTTP Requst對象，該對象含有該請求所有的信息）。
2. 處理請求頭。
3. 處理請求體。
4. 如果有的話，調用與此請求（URL或者Location）關聯的handler
5. 依次調用各phase handler進行處理。

　　一個phase handler的執行過程：

1. 獲取location配置。
2. 產生適當的響應。
3. 發送response header.
4. 發送response body.

　　這里直接上taobao團隊的給出的Nginx流程圖了。

　　從這個圖中可以清晰的看到解析http消息每個部分的不同模塊。

keepalive長連接

　　長連接的定義：所謂長連接，指在一個連接上可以連續發送多個數據包，在連接保持期間，如果沒有數據包發送，需要雙方發鏈路檢測包。

　　在這里，http請求是基於TCP協議之上的，所以建立需要三次握手，關閉需要四次握手。而http請求是請求應答式的，如果我們能知道每個請求頭與響應體的長度，那么我們是可以在一個連接上面執行多個請求的，這就需要在請求頭中指定content-length來表明body的大小。在http1.0與http1.1中稍有不同，具體情況如下：

    對於http1.0協議來說，如果響應頭中有content-length頭，則以content-length的長度就可以知道body的長度了，客戶端在接收body時，就可以依照這個長度來接收數據，接收完后，就表示這個請求完成了。而如果沒有content-length頭，則客戶端會一直接收數據，直到服務端主動斷開連接，才表示body接收完了。

    而對於http1.1協議來說，如果響應頭中的Transfer-encoding為chunked傳輸，則表示body是流式輸出，body會被分成多個塊，每塊的開始會標識出當前塊的長度，此時，body不需要通過長度來指定。如果是非chunked傳輸，而且有content-length，則按照content-length來接收數據。否則，如果是非chunked，並且沒有content-length，則客戶端接收數據，直到服務端主動斷開連接。

 

　　當客戶端的一次訪問，需要多次訪問同一個server時，打開keepalive的優勢非常大，比如圖片服務器，通常一個網頁會包含很多個圖片。打開keepalive也會大量減少time-wait的數量。

pipeline管道線

 　　管道技術是基於長連接的，目的是利用一個連接做多次請求。

　　keepalive采用的是串行方式，而pipeline也不是並行的，但是它可以減少兩個請求間的等待的事件。nginx在讀取數據時，會將讀取的數據放到一個buffer里面，所以，如果nginx在處理完前一個請求后，如果發現buffer里面還有數據，就認為剩下的數據是下一個請求的開始，然后就接下來處理下一個請求，否則就設置keepalive。

lingering_close延遲關閉

　　 當Nginx要關閉連接時，並非立即關閉連接，而是再等待一段時間后才真正關掉連接。目的在於讀取客戶端發來的剩下的數據。

　　如果服務器直接關閉，恰巧客戶端剛發送消息，那么就不會有ACK，導致出現沒有任何錯誤信息的提示。

　　Nginx通過設置一個讀取客戶數據的超時事件lingering_timeout來防止以上問題的發生。

 

　　參考：http://tengine.taobao.org/book/#id2