connection
在 nginx 中 connection 就是對 tcp 連接的封裝，其中包括連接的 socket，讀事件，寫事件。利用 Nginx 封裝的 connection，我們可以很方便的使用 Nginx 來處理與連接相關的事情，比如，建立連接，發送與接受數據等。? ? ? ? ? ? ? ? ( 推薦學習：nginx使用?)
而 Nginx 中的 http 請求的處理就是建立在 connection之上的，所以 Nginx 不僅可以作為一個web服務器，也可以作為郵件服務器。當然，利用 Nginx 提供的 connection，我們可以與任何后端服務打交道。
結合一個 tcp 連接的生命周期，我們看看 Nginx 是如何處理一個連接的。
首先，Nginx 在啟動時，會解析配置文件，得到需要監聽的端口與 ip 地址，然后在 Nginx 的 master 進程里面，先初始化好這個監控的 socket(創建 socket，設置 addrreuse 等選項，綁定到指定的 ip 地址端口，再 listen)，然后再 fork 出多個子進程出來，然后子進程會競爭 accept 新的連接。
此時，客戶端就可以向 Nginx 發起連接了。
當客戶端與服務端通過三次握手建立好一個連接后，Nginx 的某一個子進程會 accept 成功，得到這個建立好的連接的 socket，然后創建 Nginx 對連接的封裝，即 ngx_connection_t 結構體。
接著，設置讀寫事件處理函數并添加讀寫事件來與客戶端進行數據的交換。最后，Nginx 或客戶端來主動關掉連接，到此，一個連接就壽終正寢了。
當然，Nginx 也是可以作為客戶端來請求其它 server 的數據的（如 upstream 模塊），此時，與其它 server 創建的連接，也封裝在 ngx_connection_t 中。
作為客戶端，Nginx 先獲取一個 ngx_connection_t 結構體，然后創建 socket，并設置 socket 的屬性（ 比如非阻塞）。然后再通過添加讀寫事件，調用 connect/read/write 來調用連接，最后關掉連接，并釋放 ngx_connection_t。
在 Nginx 中，每個進程會有一個連接數的最大上限，這個上限與系統對 fd 的限制不一樣。在操作系統中，通過?ulimit -n，我們可以得到一個進程所能夠打開的 fd 的最大數，即 nofile，因為每個 socket 連接會占用掉一個 fd，所以這也會限制我們進程的最大連接數，當然也會直接影響到我們程序所能支持的最大并發數，當 fd 用完后，再創建 socket 時，就會失敗。
Nginx 通過設置 worker_connectons 來設置每個進程支持的最大連接數。如果該值大于 nofile，那么實際的最大連接數是 nofile，Nginx 會有警告。
Nginx 在實現時，是通過一個連接池來管理的，每個 worker 進程都有一個獨立的連接池，連接池的大小是 worker_connections。這里的連接池里面保存的其實不是真實的連接，它只是一個 worker_connections 大小的一個 ngx_connection_t 結構的數組。
并且，Nginx 會通過一個鏈表 free_connections 來保存所有的空閑 ngx_connection_t，每次獲取一個連接時，就從空閑連接鏈表中獲取一個，用完后，再放回空閑連接鏈表里面。
在這里，很多人會誤解 worker_connections 這個參數的意思，認為這個值就是 Nginx 所能建立連接的最大值。其實不然，這個值是表示每個 worker 進程所能建立連接的最大值，所以，一個 Nginx 能建立的最大連接數，應該是worker_connections * worker_processes。
當然，這里說的是最大連接數，對于 HTTP 請求本地資源來說，能夠支持的最大并發數量是worker_connections * worker_processes，而如果是 HTTP 作為反向代理來說，最大并發數量應該是worker_connections * worker_processes/2。
因為作為反向代理服務器，每個并發會建立與客戶端的連接和與后端服務的連接，會占用兩個連接。
那么，我們前面有說過一個客戶端連接過來后，多個空閑的進程，會競爭這個連接，很容易看到，這種競爭會導致不公平，如果某個進程得到 accept 的機會比較多，它的空閑連接很快就用完了，如果不提前做一些控制，當 accept 到一個新的 tcp 連接后，因為無法得到空閑連接，而且無法將此連接轉交給其它進程，最終會導致此 tcp 連接得不到處理，就中止掉了。
很顯然，這是不公平的，有的進程有空余連接，卻沒有處理機會，有的進程因為沒有空余連接，卻人為地丟棄連接。那么，如何解決這個問題呢？
首先，Nginx 的處理得先打開 accept_mutex 選項，此時，只有獲得了 accept_mutex 的進程才會去添加accept事件，也就是說，Nginx會控制進程是否添加 accept 事件。
Nginx 使用一個叫 ngx_accept_disabled 的變量來控制是否去競爭 accept_mutex 鎖。
在第一段代碼中，計算 ngx_accept_disabled 的值，這個值是 Nginx 單進程的所有連接總數的八分之一，減去剩下的空閑連接數量，得到的這個 ngx_accept_disabled 有一個規律，當剩余連接數小于總連接數的八分之一時，其值才大于 0，而且剩余的連接數越小，這個值越大。
再看第二段代碼，當 ngx_accept_disabled 大于 0 時，不會去嘗試獲取 accept_mutex 鎖，并且將 ngx_accept_disabled 減 1，于是，每次執行到此處時，都會去減 1，直到小于 0。
不去獲取 accept_mutex 鎖，就是等于讓出獲取連接的機會，很顯然可以看出，當空余連接越少時，ngx_accept_disable 越大，于是讓出的機會就越多，這樣其它進程獲取鎖的機會也就越大。
不去 accept，自己的連接就控制下來了，其它進程的連接池就會得到利用，這樣，Nginx 就控制了多進程間連接的平衡了。
ngx_accept_disabled?=?ngx_cycle->connection_n?/?8 ????????-?ngx_cycle->free_connection_n;????if?(ngx_accept_disabled?>?0)?{ ????????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; ????????????} ????????} ????}
連接就先介紹到這，知道在 Nginx 中連接是個什么東西就行了，而且連接是屬于比較高級的用法。
