• upstream請求結束：資料互動出錯、後端關閉socket時nginx接收到FIN、content-length資料已接收到
• upstream結束的主函式：ngx_http_upstream_finalize_request()
• keepalive機制：nginx長連線

一、upstream finalize

upstream請求結束分三種情況：

1. read()、write()過程中出現NGX_ERROR/NGX_ABORT，表示請求過程中發生異常，設定p->upstream_error = 1；
2. read()函式時後端關閉socket，後端系統傳送FIN分節到nginx，接收到該訊號則設定rev->ready = 0
   和p->upstream_eof = 1；
3. 正常情況下，upstream接收Header時會記錄content-length，然後接收body時減小p->length的值，當所有body接收完時p->length=0，並設定p->upstream_done = 1；

分析ngx_http_upstream_finalize_request()：

• 清除cleanup指標，因為在upstream的前面階段：create、init、傳送請求、接收Headers時出現異常則會呼叫ngx_http_finalize_request()，並執行cleanup()的呼叫。所以這裡首先要清除cleanup指標；
• u->finalize_request()，實際呼叫ngx_http_proxy_finalize_request，沒有任何操作；
• u->peer.free()，實際呼叫’ngx_http_upstream_keepalive_close_handler()’進行peer的“關閉”操作；
• 如果peer->connection不為空，則關閉connection，原因是上一步有可能是keepalive裡把connection放到cache裡後置為空，所以不用關閉connection；
• ngx_http_send_special()，設定一個帶有last標誌的特殊buffer，告知資料傳送環節需要將之前快取而沒有傳送的buffer chain，傳送出去；
• ngx_http_finalize_request()，結束請求
  
  • 如果還沒資料沒傳送完c->buffered不為0，則設定write控制代碼為ngx_http_write，表示要繼續傳送資料，在函式ngx_http_write中ngx_htt_finalize_request()是最後執行，形成遞迴；
  • 若資料傳送完了，則直接幹到這一行r->done = 1，標記結束，並把client的write控制代碼關閉
  • ngx_http_post_action()，若無後續操作，則無實際執行
  • 如果socket關閉了，會發送FIN分節，標記c->read->eof，執行ngx_http_close_request()關閉socket，？？？？
  • ngx_http_finalize_connection()，關閉連結
    
    • 檢查請求的引用計數器，不等於1說明還有多個動作在操作著請求？？？（請求建立時ngx_http_create_request()該值賦為1）；
    • 引用計數器為1時，檢查keepalive是否超時，接著結束keepalive請求返回；
    • 呼叫ngx_http_set_lingering_close()，預設lingering超時是5s
      
      • 設定ngx_http_lingering_close_handler()讀事件，意思客戶端在lingering_timeout時間內沒有進行任何操作，那麼就會關閉與客戶端的連線，如果有操作，也有總時間lingering_time超時，然後呼叫ngx_http_close_request()
      • ngx_shutdown_socket(fd, NGX_WRITE_SHUTDOWN)關閉socket寫端；
      • 呼叫ngx_http_lingering_close_handler()，進一步會ngx_http_free_request()列印請求日誌、釋放request，ngx_http_close_connection()中釋放connection，並ngx_close_socket(fd)回收描述符。lingering機制詳見nginx lingering_close，進一步也可以瞭解與之相關的case：nginx的延遲關閉。

二、upstream keepalive

啟用nginx到upstream的keepalive，需要設定proxy http\1.1和覆蓋connection為空（nginx預設會置為close）。

2.1 資料傳送

• ngx_http_proxy_create_request()，nginx首先準備好發向upstream的資料；
• 呼叫uscf->peer.init()，實際呼叫ngx_http_upstream_init_keepalive_peer() ==> ngx_http_upstream_init_round_robin_peer()，通過負載均衡引擎獲取一個後端服務節點；
• 是否連線該服務節點取決於keepalive queue中是否能從cache佇列線性查詢到該節點，若查詢到則從佇列中移出該節點，並將節點放到空閒佇列free；
• ngx_http_upstream_send_request()，向該節點發送資料。

2.2 資料接收

• 先接收upstream發來的Header，一邊接收一邊解析，直到完整接收到Header
• nginx立即將Headers傳送給client，再接收Body，一邊從upstream接收一邊發往client，但這裡底層實際上是先buffer住，等所有資料接收完才發往client傳送資料；
• 其中p->length記錄了待接收資料的長度（解析header時用content-length賦值給u->length然後呼叫ngx_http_proxy_input_filter_init()賦值給p->length），每次收到資料會減小，直到p->length為0時，會判斷connection_close（在http\1.0下預設為1否則為0），當upstream返回connection:close時設定為1，以決定是否keepalive；
• 若遇到readv()返回0表示upstream傳送了FIN訊號而關閉的遠端socket，則nginx也後續相應關閉連結；
• 最後若對方socket未關閉、socket未出錯、keepalive，則會把後端節點的連線物件存放到cache佇列頭部，如果佇列滿了，則釋放列隊尾部的一個元素，LRU淘汰策略。