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
};

View Code

 

鏈接池

 　　在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;
};

View Code

 

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，則客戶端接收數據，直到服務端主動斷開鏈接。

Http1.0與Http1.1 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