描述
   TCP連接跟蹤是網絡流控和防火墻中的一項重要的基礎技術，當運用于主機時，連接必與進程相關聯，要么是主動發出的，要么是被動接受的，當后代進程被動態創建時，由于文件描述符的繼承，一個連接就會被這個進程樹中的所有進程共享；當一個進程發出或接受多個連接時，就擁有了多個連接。本方法可用于網絡安全產品中，監控TCP連接及所屬進程，能準確并動態地知道一個連接被哪些進程共享，一個進程擁有哪些連接。

特點
   操作系統自帶的netstat工具只是關聯到了一個根進程，無法看到擁有該連接的所有進程，查看進程擁有的全部連接也不方便。該方法的特點是實時跟蹤、查看連接與進程相關信息方便、支持連接的管控。

---

實現
   本方法通過內核安全的十字鏈表實現了連接與進程的相關性，連接信息結構體含有一個所屬進程鏈表頭，進程信息結構體含有一個擁有連接鏈表頭，通過十字鏈表結點鏈接，x方向鏈接到進程的連接鏈表，y方向鏈接到連接的進程鏈表，如下圖所示    進程1為根進程，進程2，...，進程n為進程1的后代進程；連接1，連接2，...，連接n為進程1產生的連接。node(x,y)為十字鏈表結點，用于關聯連接與進程，x對應進程編號，y對應連接編號，每個node包含了所屬的連接和進程指針，每行和每列都是一個雙向循環鏈表（循環未畫出），每個鏈表用一個自旋鎖同步操作。
   動態跟蹤的過程包括4個方面：進程創建、進程退出、連接產生、連接銷毀。在Linux下，可通過攔截內核函數do_fork掛鉤進程創建，攔截do_exit掛鉤進程退出；可通過攔截inet_stream_ops的成員函數connect和accept掛鉤連接產生，攔截成員函數release掛鉤連接銷毀。下面為4個方面對應的流程圖，由于所有外層加鎖前已禁止本地中斷和內核搶占，因此內層加鎖前就不必再禁止本地中斷和內核搶占了。

   進程創建
   將copy_node插入到c的進程鏈表末尾，即為y方向增加（下同）；插入到p的連接鏈表末尾，為x方向增加（下同）。

   進程退出
   從c的進程鏈表中移除node，即為y方向移除（下同）；再從p的連接鏈表中移除node，即為x方向移除（下同）。

---

   連接產生
      當進程發出連接或接受連接時，調用此流程。
   連接銷毀
      當某個進程銷毀連接時，調用此流程。 描述
   在P2P應用系統中，當需要與處于不同私網的對方可靠通信時，先嘗試TCP打洞穿透，若穿透失敗，再通過處于公網上的代理服務器（下文簡稱proxy）轉發與對方通信，如下圖所示      終端A先連接并發消息msg1到proxy（連接為c1）；proxy再發消息msg2給P2P服務器，P2P服務器收到消息后通過已有的連接發消息msg3給終端B，B收到msg3后，連接并發消息msg4到proxy（連接為c2）。這4個消息格式由應用層協議決定，但必須遵守的規范如下：
   ◆ msg1至少包含B的設備ID。
   ◆ msg2至少包含B的設備ID和c1的連接ID。
   ◆ msg3至少包含c1的連接ID和連接代理指示。
   ◆ msg4至少包含B的設備ID和c1的連接ID。
   proxy為多線程架構，當接受到若干連接時，如果數據相互轉發的兩個連接（比如上圖中的c1和c2）不在同一線程，由于一個連接寫數據到另一連接的發送隊列，而另一連接從發送隊列讀數據以發送，那么就要對另一連接的發送隊列（或緩沖區）加鎖，這樣一來由于頻繁的網絡IO而頻繁地加解鎖，降低了轉發效率，因此為了解決這一問題，就需要調度TCP連接到同一線程。

---

特點
   本方法能將數據轉發的兩邊連接放在同一線程，從而避免了數據轉發時的加鎖，由于是一對一的連接匹配，因此也做到了每個線程中連接數的均衡。

---

實現
   工作原理
      proxy的主線程負責綁定知名端口并監聽連接，工作線程負責數據轉發。當接受到一個連接時，按輪轉法調度它到某個工作線程，在那個線程內接收分析應用層協議數據，以識別連接類型，即判斷連接是來自數據請求方還是數據響應方，為統一描述，這里把前者特稱為客戶連接，后者為服務連接，連接所在的線程為宿主線程。如果是客戶連接，那么先通知P2P服務器請求對應的客戶端來連接代理，并等待匹配；如果是服務連接，那么就去匹配客戶連接，在匹配過程中，如果服務連接和客戶連接不在同一線程內，那么就會調度到客戶連接的宿主線程，匹配成功后，就開始轉發數據。
      為了加快查找，分2個hash表存放連接，客戶連接放在客戶連接hash表中，以連接ID為鍵值；服務連接放在服務連接hash表中，以設備ID為鍵值。

   TCP連接調度
      包括新連接的輪轉、識別連接類型、匹配客戶連接1、匹配客戶連接2和關閉連接共5個流程，如下一一所述。
      新連接的輪轉
         該流程工作在主線程，如下圖所示
      索引i初始為0，對于新來的連接，由于還不明確連接類型，所以先放入客戶連接表中。

      識別連接類型
         該流程工作在工作線程，當接受到一個連接時開始執行，如下圖所示       當連接類型為服務連接時，從客戶連接表轉移到服務連接表。

      匹配客戶連接1
         該流程工作在工作線程，當接受到一個服務連接時開始執行，如下圖所示

      匹配客戶連接2
         該流程工作在工作線程，當服務連接移到客戶連接的宿主線程時開始執行，如下圖所示
      這里的流程和匹配客戶連接流程1有些類似，看起來好像做了重復的判斷操作，但這是必要的，因為在服務連接轉移到另一線程這個瞬間內，客戶連接有可能斷開了，也有可能斷開后又來了一個相同連接ID的其它客戶連接，所以要重新去客戶連接表查找一次，然后進行4個分支判斷。 
   
      關閉連接
         該流程工作在工作線程內，當連接斷開或空閑時執行。當一邊讀數據出錯時，不能馬上關閉另一邊連接，得在另一邊緩沖區數據發送完后才能關閉；當一邊連接寫數據出錯時，可以馬上關閉另一邊連接，如下圖所示
     摘要:    為了使nginx支持windows服務，本文闡述以下主要的改進實現。ngx_main函數   為了在SCM服務中復用main函數的邏輯，將其重命名為ngx_main，并添加第3個參數is_scm以兼容控制臺運行方式，聲明在core/nginx.h中。    Code highligh...  閱讀全文 結構定義
   假設s1為初始狀態，狀態變遷為s1->s2->...->sn。

常規實現 
   狀態機處理函數state_machine_handle通常在一個循環內或被事件驅動框架調用，輸入data會隨時序變化，從而引起狀態的變遷，偽代碼框架如下。
   sm->state初始化為s1。

腳本概述
   由于使用objdump反匯編linux內核的輸出太多（2.6.32-220.el6.x86_64統計結果為1457706行），而很多時候只是想查看特定部分的機器碼與匯編指令，例如函數的入口、堆棧、調用了哪個函數等，為了高效和通用，因此編寫了一個簡單的awk腳本，其命令行參數說明如下：
   ● SLINE表示匹配的起始行號（不小于1），SPAT表示匹配的起始行模式，這兩個只能有一個生效，當都有效時，以SLINE為準。
   ● NUM表示從起始行開始的連續輸出行數（不小于1，含起始行），EPAT表示匹配的結束行模式，這兩個只能有一個生效，當都有效時，以NUM為準。

腳本實現
   檢查傳值
   由于向腳本傳入的值在BEGIN塊內沒生效，在動作塊{}和END塊內有效，但若在{}內進行檢查則太低效，因為處理每條記錄都要判斷，所以為了避免在{}內進行多余的判斷，就在BEGIN塊內解析命令行參數來間接獲得傳值，當傳值無效時，給出提示并退出。
   結束處理
   當處理了NUM條記錄或匹配了結束行模式時，應退出動作塊{}。   
   完整腳本下載：rangeshow。

腳本示例
   查看linux內核第10000行開始的10條指令，如下圖
   
   
   查看linux內核函數do_fork入口開始的10條指令，如下圖    
   

   查看linux內核第10000行開始到callq的一段指令，如下圖
   

   查看linux內核函數do_exit入口到調用profile_task_exit的一段指令，如下圖   
       本文根據RFC793協議規范和BSD 4.4的實現，總結了TCP分組丟失時的狀態變遷，如下圖所示：實線箭頭表示客戶端的狀態變遷，線段虛線箭頭表示服務端的狀態變遷，圓點虛線箭頭表示客戶端或服務端的狀態變遷；黑色文字表示正常時的行為，紅色文字表示分組丟失時的行為。
   這里假設重傳時分組依然會丟失，當在不同狀態（CLOSED除外）分組丟失后，最終會關閉套接字而回到CLOSED狀態。下面逐個分析各狀態時的情景。

SYN_SENT
   連接階段第1次握手，客戶端發送的SYN分組丟失，因此超時收不到服務端的SYN+ACK而重傳SYN，嘗試幾次后放棄，關閉套接字。

SYN_RCVD
   1）連接階段第2次握手，服務端響應的SYN+ACK分組丟失，因此超時收不到客戶端的ACK而重傳SYN+ACK，嘗試幾次后放棄，發送RST并關閉套接字。
   2）連接階段第3次握手，客戶端發送的ACK分組丟失，因此服務端超時收不到ACK而重傳SYN+ACK，嘗試幾次后放棄，發送RST并關閉套接字。
   3）同時打開第2次握手，本端響應的SYN+ACK分組丟失，因此對端超時收不到SYN+ACK而重傳SYN、嘗試幾次后放棄、發送RST并關閉套接字，而此時本端收到RST。

ESTABLISHED
   1）連接階段第3次握手，客戶端發送ACK分組后，雖然丟失但會進入該狀態（因為ACK不需要確認），但此時服務端還處于SYN_RCVD狀態，因為超時收不到客戶端的ACK而重傳SYN+ACK、嘗試幾次后放棄、發送RST并關閉套接字，而此時客戶端收到RST。
   2）數據傳輸階段，本端發送的Data分組丟失，因此超時收不到對數據的確認而重傳、嘗試幾次后放棄、發送RST并關閉套接字，而此時對端收到RST。

FIN_WAIT_1
   1）關閉階段第1次握手，客戶端發送的FIN分組丟失，因此超時收不到服務端的ACK而重傳FIN，嘗試幾次后放棄，發送RST并關閉套接字。
   2）關閉階段第2次握手，服務端響應的ACK分組丟失，因此客戶端超時收不到ACK而重傳FIN，嘗試幾次后放棄，發送RST并關閉套接字。
 
FIN_WAIT_2
   關閉階段第3次握手，服務端發送的FIN分組丟失，因此超時收不到客戶端的ACK而重傳FIN、嘗試幾次后放棄、發送RST并關閉套接字，而此時客戶端收到RST。
 
CLOSING
   同時關閉第2次握手，本端發送的ACK分組丟失，導致對端超時收不到ACK而重傳FIN、嘗試幾次后放棄、發送RST并關閉套接字，而此時本端收到RST。

TIME_WAIT
   關閉階段第4次握手，客戶端響應的ACK分組丟失，導致服務端超時收不到ACK而重傳FIN、嘗試幾次后放棄、發送RST并關閉套接字，而此時客戶端收到RST。

CLOSE_WAIT
   關閉階段第2次握手，服務端響應的ACK分組丟失，導致客戶端超時收不到ACK而重傳FIN、嘗試幾次后放棄、發送RST并關閉套接字，而此時服務端收到RST。

LAST_ACK
   關閉階段第3次握手，服務端發送的FIN分組丟失，導致超時收不到客戶端的ACK而重傳FIN、嘗試幾次后放棄、發送RST并關閉套接字。      摘要:    由于linux內核中的struct list_head已經定義了指向前驅的prev指針和指向后繼的next指針，并且提供了相關的鏈表操作方法，因此為方便復用，本文在它的基礎上封裝實現了一種使用開鏈法解決沖突的通用內核Hash表glib_htable，提供了初始化、增加、查找、刪除、清空和銷毀6種操作，除初始化和銷毀外，其它操作都做了同步，適用于中斷和進程上下文。...  閱讀全文    nginx的域名解析器使用已連接udp（收發前先調用ngx_udp_connect）發送dns查詢、接收dns響應，如上篇tcp異步連接所講，iocp需要先投遞udp的接收操作，才能引發接收完成的事件，因此要對域名解析器和udp異步接收作些改進。

發送后投遞
    dns查詢由ngx_resolver_send_query函數實現，定義在core/ngx_resolver.c中。     當nginx用于代理連接上游服務器前，要先解析域名，首次調用鏈為：ngx_http_upstream_init_request->ngx_resolver_name->ngx_resolver_name_locked->ngx_resolver_send_query；若5s（單次超時）后還沒收到dns響應，則再發送1次查詢，調用鏈為：ngx_resolver_resend_handler->ngx_resolver_resend->ngx_resolver_send_query，如此反復，直到收到響應或30s（默認總超時）后不再發送查詢。它調用ngx_send發送dns查詢，16行~21行代碼為筆者添加，ngx_resolver_read_response函數用于接收并分析dns響應報文，它會調用到下面的ngx_udp_overlapped_wsarecv函數。

異步接收
   由ngx_udp_overlapped_wsarecv函數實現，定義在os/win32/ngx_udp_wsarecv.c中。    先以非阻塞方式接收，若發生WSAWOULDBLOCK錯誤，則使用MSG_PEEK標志投遞一個0字節的重疊接收操作，當dns響應返回時發生完成事件，會再次進入ngx_resolver_read_response而調用到該函數，此時rev->complete為1，rev->ovlp.error為ERROR_MORE_DATA（GetQueuedCompletionStatus返回的錯誤），由于使用了MSG_PEEK，因此數據還在接收緩沖區中，要忽略ERROR_MORE_DATA而繼續接收，這時就能成功了。不管WSARecv返回WSA_IO_PENDING錯誤還是成功，iocp都會得到完成通知，所以這里當重疊操作投遞成功時，返回NGX_AGAIN，便于在回調內統一處理。    iocp是Windows NT操作系統的一種高效IO模型，對應于Linux中的epoll和FreeBSD中的kqueue，nginx對ske(select、kqueue和epoll的首寫字母組合)的支持很好，但截止到1.6.2版本，還不支持iocp。由于ske都是反應器模式，即先注冊IO事件，當IO事件發生（讀寫通知）時，在其回調內主動調用API來讀或寫數據；而iocp是前攝器模式，要先投遞IO操作，才能引發IO事件（完成通知）的發生，在其回調內數據已被動由操作系統讀或寫完成。因此，iocp的特點決定了nginx對它的支持與ske有所不同。通過hg clone http://hg.nginx.org/nginx下載的nginx源代碼，雖然實現了iocp事件模塊、異步接受連接、部分異步讀寫，但根本不能正常工作，而且不支持異步連接和SCM服務控制，筆者在參考ske模塊的實現基礎上，改進支持了如下特性：
      1. 異步接受連接時的負載均衡
      2. 正反向代理的異步連接
      3. 異步聚合讀寫
      4. 域名解析時的UDP異步接收
      5. 異步文件傳輸
      6. SCM服務控制
   由于2、4、6均為原創，其它幾點的思路皆源于ske模塊的實現（只是平臺API不同），因此本文先闡述異步連接的實現。為了兼容select事件模塊，所有iocp相關的代碼使用NGX_HAVE_IOCP宏和（或）NGX_USE_IOCP_EVENT標志包圍，其中NGX_HAVE_IOCP宏用于條件編譯，在WIN32平臺下，定義為1；當選擇的事件模塊為iocp時，全局變量ngx_event_flags才包含NGX_USE_IOCP_EVENT標志。

異步連接對端
   由ngx_event_connect_peer函數（這里省去了與異步連接無關的代碼）實現，定義在event/ngx_event_connect.c中，因為connect不支持異步連接事件的完成通知，所以要使用擴展API ConnectEx。     調用ConnectEx前要先bind本地地址，不然發生WSAEINVAL錯誤；由于域名解析可能返回IPv6記錄，導致創建本地套接字的地址族為AF_INET6，因此bind時需要匹配IPv6地址，不然發生WSAEFAULT錯誤，導致nginx返回Internal Server Error錯誤給前端，因此綁定前要調用ngx_iocp_set_localaddr設定正確的本地地址，當且僅當pc->local為空或地址族不匹配時。

本地初始化與設定
   支持IPv6，實現在event/modules/ngx_iocp_module.c。
   地址變量定義如下。
   sin對應IPv4，sin6對應IPv6，作為bind的套接字本地地址。

   sin和sin6在啟動iocp事件模塊時調用ngx_iocp_init初始化。       不論IP地址或端口，都指定為0，表示由系統自動分配出口IP地址和未占用的端口。

   本地設定由ngx_iocp_set_localaddr實現。

 1ngx_int_t ngx_iocp_set_localaddr(ngx_log_t *log, in_port_t family, ngx_addr_t **local)
 2{
 3    struct sockaddr *sa;
 4    socklen_t len;
 5    
 6    if(AF_INET == family){            
 7        sa = &sin;
 8        len = sizeof(struct sockaddr_in);        
 9    }
10#if (NGX_HAVE_INET6)
11    else if(AF_INET6 == family){
12        sa = &sin6;
13        len = sizeof(struct sockaddr_in6);
14    }
15#endif
16    else{
17        ngx_log_error(NGX_LOG_ALERT, log, 0, "not supported address family");
18        return NGX_ERROR;        
19    }
20
21    local_addr.sockaddr = sa;
22    local_addr.socklen = len;
23    *local = &local_addr;
24
25    return NGX_OK;
26}

   對于除IPv4和IPv6外的協議族，則記錄一個錯誤日志。必要時也可擴展支持其它的協議族，例如NetBIOS（對應地址族為AF_NETBIOS），但要看ConnectEx是否支持。    ICMP在IP系統間傳遞差錯和管理報文，是任何IP系統必須實現的組成部分。Linux 2.6.34中ICMP模塊的實現在linux/icmp.h，net/icmp.h和ipv4/icmp.c中，導出了icmp_err_convert數組和icmp_send函數，供其它網絡子系統使用。在其它網絡子系統中，當檢測到錯誤時，調用icmp_send產生并發送相應的ICMP差錯消息到源主機；當源主機收到ICMP不可達差錯消息，傳遞到原始套接字和傳輸層，而它們使用icmp_err_convert把對應的消息代碼轉換成套接字層比較容易理解的錯誤代碼。在內核空間中可發送的ICMP消息包括查詢應答和差錯報文，下面總結了產生這兩類消息的網絡子系統（及函數）與錯誤轉換。

---

應答消息
   應答消息由ICMP模塊的內部函數icmp_reply而非icmp_send發送。根據RFC1122 3.2.2.9規范， 除非一個主機作為地址掩碼代理，否則不能發送回復，這對應ICMP的icmp_address實現為空，因此上表沒有列出地址掩碼應答項（內核符號為ICMP_ADDRESSREPLY）。

差錯消息
   差錯消息由中間路由器或目的主機產生，當數據報不能成功提交給目的主機時。從上表可見，在IP層的接收、本地處理、轉發和輸出各過程中，都可能產生差錯消息；在傳輸層如果對應的端口沒有打開，那么UDP會產生ICMP端口不可達差錯，而TCP則會使用自己的差錯處理機制發送一個RST復位包，這也是上表沒有列出TCP子系統的原因。對于重定向差錯，由ICMP模塊的icmp_redirect調用ip_rt_redirect更新路由；其它差錯則由icmp_unreach處理。

---

錯誤轉換
   第2列為icmp_err_convert數組索引，第4列也就是調用socket API出錯時返回的errno，最后1列為icmp_err_convert中的fatal成員取值，0表示非致命錯誤，1表示致命錯誤，需要報告給用戶進程。錯誤轉換會被RAW的raw_err、TCP的tcp_v4_err和UDP的udp_err用到，對于ICMP_DEST_UNREACH類型的差錯，使用上表轉換；ICMP_SOURCE_QUENCH類型的忽略不處理；ICMP_PARAMETERPROB類型的轉換成EPROTO（協議錯誤）；ICMP_TIME_EXCEEDED類型的轉換成EHOSTUNREACH。
   在這要注意，從ICMP_PORT_UNREACH到ECONNREFUSED的轉換，不適用于TCP，原因已在上節說明；而對于UDP的未連接套接字，如果主機在線而端口沒打開，調用sendto得不到ECONNREFUSED錯誤，但recvfrom會阻塞，這是因為雖然內核收到了ICMP差錯，但沒上報給應用進程。盡管如此，如果想得到ECONNREFUSED錯誤，那么可以寫個ICMP守護進程，應用進程先把它的套接字描述符通過unix域套接口傳遞到ICMP守護進程，而守護進程使用raw socket來接收ICMP差錯，再發給應用進程。

---

發送限速
   不論一般差錯消息還是重定向差錯消息，發送限速針對的都是特定目標主機。
   一般限速
   在使用icmp_send發送差錯消息（PMTU消息除外）時，為減少網絡擁塞而限制了發送的速率，限速由xrlim_allow函數實現，定義在ipv4/icmp.c中。
   dst為目標路由緩存，timeout為允許發送的超時（單位為jiffies），dst->rate_tokens記錄令牌的個數，當令牌個數不小于timeout時，則減少timeout并允許發送一個消息；反之則不能發送，需等到令牌個數累積到大于timeout時才能發送，但是不能無限大，否則就會導致在一個可能很短的timeout內，發送遠多于6個的消息，引起ICMP風暴，所以這里限制了令牌的最大值為XRLIM_BURST_FACTOR*timeout即6倍的超時，也就是說在一個timeout內，最多能發送6個差錯消息。 
  
   重定向限速
   路由子系統使用ip_rt_send_redirect來發送重定向消息，定義在ipv4/route.c中，該函數內部調用icmp_send實現，在它的限速基礎上，使用指數回退算法控制發送速率。
   重定向差錯使用ip_rt_redirect_silence（默認為(HZ/50)<<10）、ip_rt_redirect_number（默認為9）和ip_rt_redirect_load（默認為HZ/50）3個量來控制發送的速率；rt->u.dst.rate_last記錄上次發送的時間，rt->u.dst.rate_tokens累計發送總數，最大值為ip_rt_redirect_number；當兩次發送的時間間隔超過ip_rt_redirect_silence或ip_rt_redirect_load<<rt->u.dst.rate_tokens，并且發送總數不超過ip_rt_redirect_number時，才允許發送一個，這樣一來，在ip_rt_redirect_silence間隔內，每次發送的超時呈2的指數增長，達到了變減速發送的效果，直到總數達到ip_rt_redirect_number時停止發送，這是因為源主機可能忽略了重定向消息所以停止發送；當ip_rt_redirect_silence時間過后，又允許發送了，這是因為認為源主機沒有更新路由所以又需要發送。