這裡主要為了將問題弄清楚，後續遇到問題會不斷的增加，儘量希望能夠把問題逐步搞清楚！

第一：tcp連線為什麼需要三次握手？

      在謝希仁著《計算機網路》第四版中講“三次握手”的目的是“為了防止已失效的連線請求報文段突然又傳送到了服務端，因而產生錯誤”。在另一部經典的《計算機網路》一書中講“三次握手”的目的是為了解決“網路中存在延遲的重複分組”的問題。這兩種不用的表述其實闡明的是同一個問題。
      謝希仁版《計算機網路》中的例子是這樣的，“已失效的連線請求報文段”的產生在這樣一種情況下：client發出的第一個連線請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連線釋放以後的某個時間才到達server。

本來這是一個早已失效的報文段。但server收到此失效的連線請求報文段後，就誤認為是client再次發出的一個新的連線請求。於是就向client發出確認報文段，同意建立連線。假設不採用“三次握手”，那麼只要server發出確認，新的連線就建立了。由於現在client並沒有發出建立連線的請求，因此不會理睬server的確認，也不會向server傳送資料。但server卻以為新的運輸連線已經建立，並一直等待client發來資料。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連線。”。主要目的防止server端一直等待，浪費資源。

第二：tcp斷開為什麼需要四次分手？

           原因是因為tcp是全雙工模式，當接收到FIN時意味將對端沒有資料再發來，但是本端可以繼續傳送資料。

（校注：這裡是資料包，至於ack控制包不在此列）！

第二：四次分手過程詳解如下?

FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態實際上是當SOCKET在ESTABLISHED狀態時，它想主動關閉連線，向對方傳送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態

，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態一般是比較難見到的，而FIN_WAIT_2狀態還有時常常可以用netstat看到。（主動方）
FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半連線，也即有一方要求close連線，但另外還告訴對方，我暫時還有點包需要傳送給你(ACK資訊)，稍後再關閉連線。（主動方）
TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後即可回到CLOSED可用狀態了。如果FIN_WAIT_1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，可以直接進入到TIME_WAIT狀態，而無須經過FIN_WAIT_2狀態。（主動方）
CLOSING（比較少見）: 這種狀態比較特殊，實際情況中應該是很少見，屬於一種比較罕見的例外狀態。正常情況下，當你傳送FIN報文後，按理來說是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。但是CLOSING狀態表示你傳送FIN報文後，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文。什麼情況下會出現此種情況呢？其實細想一下，也不難得出結論：那就是如果雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時傳送FIN報文的情況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET連線。（同時關閉的情況）
CLOSE_WAIT: 這種狀態的含義其實是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後傳送FIN報文給自己，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正需要考慮的事情是察看你是否還有資料傳送給對方，如果沒有的話，那麼你也就可以 close這個SOCKET，傳送FIN報文給對方，也即關閉連線。所以你在CLOSE_WAIT狀態下，需要完成的事情是等待你去關閉連線。（被動方）
LAST_ACK: 這個狀態還是比較容易好理解的，它是被動關閉一方在傳送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也即可以進入到CLOSED可用狀態了。（被動方）

CLOSED: 表示連線中斷，實際中不存在。

第三：關於建連線時SYN超時問題

第四：關於SYN Flood攻擊

第五：關於 MSL和TIME_WAIT

第六：關於關於TIME_WAIT數量太多
上面的問題都可以在這裡網址找到比較靠譜的答案！

http://coolshell.cn/articles/11564.html/comment-page-1#comments

第七：tcp四次揮手的time_wait狀態存在的理由：

第一：確保client的ack到達了server端，並且被接手！

第二：防止上一次連線中的包，迷路後重新出現，影響新連線（經過2MSL，上一次連線中所有的重複包都會消失），這裡2MSL指的是報文在網路上存活的時間！

第八： 關於rst flag情況說明

第九： 關於close_wait的說明

       通過命令查詢netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'  如果出現大量的close_wait,說明伺服器的tcp 狀態機有問題，解決的唯一方法就是查程式碼！

被動端收到FIN之後，會進入CLOSE_WAIT狀態， 這個狀態是幹啥的呢其實就是wait to close,  也就是wait應用程式(被動關閉端)close socket,  至於應用程式什麼時候close, 那完全取決於程式。所以， CLOSE_WAIT狀態什麼時候終結， 取決於應用程式什麼時候來close socket,  所以， 從理論上來講， 只要被動關閉端不斷電， 程序不退出， 那麼CLOSE_WAIT狀態就會一直持續下去。

第十：關於TCP flag的說明

在TCP層，有個FLAGS欄位，這個欄位有以下幾個標識：SYN, FIN, ACK, PSH, RST, URG.
其中，對於我們日常的分析有用的就是前面的五個欄位。

它們的含義是：

URG:Urget pointer is valid (緊急指標欄位值有效)

SYN: 表示建立連線，在wireshark的過濾欄位傳入：tcp.connection.syn就可以

FIN: 表示關閉連線，tcp.connection.fin

ACK: 表示響應，tcp.connection.ack

PSH: 表示有 DATA資料傳輸 tcp.flags.push

RST: 表示連線重置 tcp.connection.rst

第十一：tcp三次握手和accpet()的順序

  原因是:狀態機的變化是由核心控制，APP的只是觸發條件，三次握手都是connect的觸發條件

    設想一個情景，若有10000個客戶端都和該服務端進行連線，傳送SYN，服務端收到之後，這些客戶端卻不再理會服務端的回覆，然而此時服務端的資源卻都用accept()分配了。這就是所謂的“DDOS攻擊”。

    為了解決這個問題，accept()於是被放在三次握手之後。

    當然更加可信的demo，請參考這個連結！ http://blog.csdn.net/stpeace/article/details/76140474

具體的詳見這篇csdn，http://blog.csdn.net/tennysonsky/article/details/45621341 我主要做一下總結： 1）connect函式為客戶端主動連線伺服器，建立連線是通過三次握手，而這個連線的過程是由核心完成，不是這個函式完成的，這個函式的作用僅僅是通知Linux核心，讓linux核心自動完成TCP三次握手連線,最後把連線的結果返回給這個函式的返回值（成功連線為0,失敗為-1）。 2)listen函式為將該套接字和套接字對應的連線佇列長度告訴 Linux 核心，核心維護中兩套連結串列，分別是sys_rcv和establish。 3)accept函式從處於 established 狀態的連線佇列頭部取出一個已經完成的連線，如果這個佇列沒有已經完成的連線，accept()函式就會阻塞，直到取出佇列中已完成的使用者連線為止。

第十三. TCP通訊中伺服器處理客戶端意外斷開

      這一部分也是常需要考慮的細節，就是保活的功能！在之前rtsp server也是考慮到，

      由於那個client端是未定的，或者是client和server端是不同廠商負責，導致各自負責，

      沒有辦法統一從app角度使用，像這種心跳包在pppoe也有頻繁的使用。下面轉載一個，後續有深入的可以討論！

      引用地址：http://blog.csdn.net/kkkkkxiaofei/article/details/12966407

      如果TCP連線被對方正常關閉，也就是說，對方是正確地呼叫了closesocket(s)或者shutdown(s)的話，那麼上面的Recv或Send呼叫就能馬上返回，並且報錯。這是由於close socket(s)或者shutdown(s)有個正常的關閉過程，會告訴對方“TCP連線已經關閉，你不需要再發送或者接受訊息了”。

但是，如果意外斷開，客戶端（3g的移動裝置）並沒有正常關閉socket。雙方並未按照協議上的四次揮手去斷開連線。

那麼這時候正在執行Recv或Send操作的一方就會因為沒有任何連線中斷的通知而一直等待下去，也就是會被長時間卡住。

       像這種如果一方已經關閉或異常終止連線，而另一方卻不知道，我們將這樣的TCP連線稱為半開啟的。

       解決意外中斷辦法都是利用保活機制。而保活機制分又可以讓底層實現也可自己實現。

     1、自己編寫心跳包程式

     簡單的說也就是在自己的程式中加入一條執行緒，定時向對端傳送資料包，檢視是否有ACK，如果有則連線正常，沒有的話則連線斷開

     2、啟動TCP程式設計裡的keepAlive機制

一、雙方擬定心跳（自實現）

     一般由客戶端傳送心跳包，服務端並不迴應心跳，只是定時輪詢判斷一下與上次的時間間隔是否超時（超時時間自己設定）。伺服器並不主動傳送是不想增添伺服器的通訊量，減少壓力。

但這會出現三種情況：

情況1.

       客戶端由於某種網路延遲等原因很久後才傳送心跳（它並沒有斷），這時伺服器若利用自身設定的超時判斷其已經斷開，而後去關閉socket。若客戶端有重連機制，則客戶端會重新連線。若不確定這種方式是否關閉了原本正常的客戶端，則在ShutDown的時候一定要選擇send,表示關閉傳送通道，伺服器還可以接收一下，萬一客戶端正在傳送比較重要的資料呢，是不？

情況2.

       客戶端很久沒傳心跳，確實是自身斷掉了。在其重啟之前，服務端已經判斷出其超時，並主動close，則四次揮手成功互動。

情況3.

      客戶端很久沒傳心跳，確實是自身斷掉了。在其重啟之前，服務端的輪詢還未判斷出其超時，在未主動close的時候該客戶端已經重新連線。

       這時候若客戶端斷開的時候傳送了FIN包，則服務端將會處於CLOSE_WAIT狀態；

       這時候若客戶端斷開的時候未傳送FIN包，則服務端處還是顯示ESTABLISHED狀態；

       而新連線上來的客戶端（也就是剛才斷掉的重新連上來了）在服務端肯定是ESTABLISHED;這時候就有個問題，若利用輪詢還未檢測出上條舊連線已經超時（這很正常，timer總有個間隔吧），而在這時，客戶端又重複的上演情況3，那麼服務端將會出現大量的假的ESTABLISHED連線和CLOSE_WAIT連線。

        最終結果就是新的其他客戶端無法連線上來，但是利用netstat還是能看到一條連線已經建立，並顯示ESTABLISHED，但始終無法進入程式程式碼。個人最初感覺導致這種情況是因為假的ESTABLISHED連線和CLOSE_WAIT連線會佔用較大的系統資源，程式無法再次建立連線（因為每次我發現這個問題的時候我只連了10個左右客戶端卻已經有40多條無效連線）。而最近幾天測試卻發現有一次程式內只連線了2，3個裝置，但是有8條左右的虛連線，此時已經連線不了新客戶端了。這時候我就覺得我想錯了，不可能這幾條連線就佔用了大量連線把，如果說幾十條還有可能。但是能肯定的是，這個問題的產生絕對是裝置在不停的重啟，而伺服器這邊又是簡單的輪詢，並不能及時處理，暫時還未能解決。

二、利用KeepAlive

其實keepalive的原理就是TCP內嵌的一個心跳包,

         以伺服器端為例，如果當前server端檢測到超過一定時間（預設是 7,200,000 milliseconds，也就是2個小時）沒有資料傳輸，那麼會向client端傳送一個keep-alive packet（該keep-alive packet就是ACK和當前TCP序列號減一的組合），此時client端應該為以下三種情況之一：

        1. client端仍然存在，網路連線狀況良好。此時client端會返回一個ACK。server端接收到ACK後重置計時器（復位存活定時器），在2小時後再發送探測。如果2小時內連線上有資料傳輸，那麼在該時間基礎上向後推延2個小時。

        2. 客戶端異常關閉，或是網路斷開。在這兩種情況下，client端都不會響應。伺服器沒有收到對其發出探測的響應，並且在一定時間（系統預設為1000 ms）後重復發送keep-alive packet，並且重複傳送一定次數（2000 XP 2003 系統預設為5次, Vista後的系統預設為10次）。

         3. 客戶端曾經崩潰，但已經重啟。這種情況下，伺服器將會收到對其存活探測的響應，但該響應是一個復位，從而引起伺服器對連線的終止。

       對於應用程式來說，2小時的空閒時間太長。因此，我們需要手工開啟Keepalive功能並設定合理的Keepalive引數。

全域性設定可更改/etc/sysctl.conf,加上:
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 60

在程式中設定如下:

1. #include <sys/socket.h>
2.  #include <netinet/in.h>
3.  #include <arpa/inet.h>
4.  #include <sys/types.h>
5.  #include <netinet/tcp.h>
6.  int keepAlive = 1; // 開啟keepalive屬性
7.  int keepIdle = 60; // 如該連線在60秒內沒有任何資料往來,則進行探測 
8.  int keepInterval = 5; // 探測時發包的時間間隔為5 秒
9.  int keepCount = 3; // 探測嘗試的次數.如果第1次探測包就收到響應了,則後2次的不再發.
10.  setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));  
11.  setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));  
12.  setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));  
13.  setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));   

在程式中表現為,當tcp檢測到對端socket不再可用時(不能發出探測包,或探測包沒有收到ACK的響應包),select會返回socket可讀,並且在recv時返回-1,同時置上errno為ETIMEDOUT.
       send函式並沒有傳送資料的能力， send函式的作用僅僅是把應用程式的資料拷貝到傳送端的核心緩衝區中， 只要有足夠的空間， send函式就不會阻塞， 就會返回成功。 至於核心緩衝區中的資料是否傳送， 什麼時候傳送， 那是協議棧的事情,  跟send函式沒有半毛錢的關係。下面用的圖形就比較清晰了！

第十五：如何設定連線建立和斷開的引數值設定

連線建立的相關引數設定： 這裡面的backlog，其實其實每次listen函式傳入的最後一個變數，它的值可以粗略定義為： 1.x = sys_rvcd佇列的數目 2.y = established佇列的數目 那麼值就是x+y的總和。

echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog
echo 2 > /proc/sys/net/ipv4/tcp_syn_retries
echo 2 > /proc/sys/net/ipv4/tcp_synack_retries
tcp_max_syn_backlog  SYN佇列的長度，時常稱之為未建立連線佇列。系統核心維護著這樣的一個佇列，用於容納狀態為SYN_RECV的TCP連線(half-open connection),即那些依然尚未得到客戶端確認(ack)的TCP連線請求。加大該值，可以容納更多的等待連線的網路連線數。
tcp_syn_retries  新建TCP連線請求，需要傳送一個SYN包，該值決定核心需要嘗試傳送多少次syn連線請求才決定放棄建立連線。預設值是5. 對於高負責且通訊良好的物理網路而言，調整為2
tcp_synack_retries  對於遠端SYN連線請求，核心會發送SYN+ACK資料包來確認收到了上一個SYN連線請求包，然後等待遠端的確認(ack資料包）。該值則指定了核心會向遠端傳送tcp_synack_retires次SYN+ACK資料包。預設設定值是5，可以調整為2

echo 0 > /proc/sys/net/ipv4/tcp_syncookies
在CentOS5.3中，該選項預設值是1，即開啟SYN Cookies功能。當出現SYN等待佇列溢位時，啟用cookies來處理，可防範少量SYN攻擊。我們建議先關閉，直到確定受到syn flood攻擊的時候再開啟syn cookies功能，有效地防止syn flood攻擊。也可以通過iptables規則拒絕syn flood攻擊。

斷開連線時候引數設定：

echo 30 >  /proc/sys/net/ipv4/tcp_fin_timeout
echo 15000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
echo 1 >  /proc/sys/net/ipv4/tcp_tw_recycle
tcp_fin_timeout 對於由本端主動斷開連線的TCP連線，本端會主動傳送一個FIN資料報，在收到遠端ACK後,且並沒有收到遠端FIN包之前，該TCP連線的狀態是FIN_WAIT_2狀態，此時當遠端關閉了應用，網路不可達（拔網張），程式不可斷僵死等等，本端會一直保留狀態為FIN_WAIT_2狀態的TCP連線，該值tcp_fin_timeout則指定了狀態為FIN_WAIT_2的TCP連線儲存多長時間，一個FIN_WAIT_2的TCP連線最多佔1.5k記憶體。系統預設值是60秒，可以將此值調整為30秒，甚至10秒。
tcp_max_tw_buckets 系統同時處理TIME_WAIT sockets數目。如果一旦TIME_WAIT tcp連線數超過了這個數目，系統會強制清除並且顯示警告訊息。設立該限制，主要是防止那些簡單的DoS攻擊，加大該值有可能消耗更多的記憶體資源。如果TIME_WAIT socket過多，則有可能耗盡記憶體資源。預設值是18w,可以將此值設定為5000~30000 
tcp_tw_resue 是否可以使用TIME_WAIT tcp連線用於建立新的tcp連線。
tcp_tw_recycle 是否開啟TCP連線中TIME-WAIT sockets的快速回收功能。為了對NAT裝置更友好，建議設定為0

總結：如何檢視狀態遷移，進行分析？

常用的工具，netstat，大多數使用命令如下：

netstat -anpts
netstat -n | grep “TIME”

下面是執行上一條語句列印的統計資訊，可以看到！

IcmpMsg:
    InType0: 3
    InType3: 763
    InType8: 1324
    OutType0: 1324
    OutType3: 79
    OutType8: 3
Tcp:
    38848 active connections openings
    3829 passive connection openings
    256 failed connection attempts
    3246 connection resets received
    98 connections established
    2697775547 segments received
    3749622382 segments send out
    713569 segments retransmited
    797 bad segments received.
    1054 resets sent
UdpLite:
TcpExt:
    137 invalid SYN cookies received //無效的syn包
    4 resets received for embryonic SYN_RECV sockets
    1384 packets pruned from receive queue because of socket buffer overrun
    35920 TCP sockets finished time wait in fast timer
    4604194 delayed acks sent
    2912 delayed acks further delayed because of locked socket
    Quick ack mode was activated 66379 times
    46082980 packets directly queued to recvmsg prequeue.
    157616979 bytes directly in process context from backlog
    489222304 bytes directly received in process context from prequeue
    148 packets dropped from prequeue
    1722022072 packet headers predicted
    45233809 packets header predicted and directly queued to user
    137598131 acknowledgments not containing data payload received
    1456859456 predicted acknowledgments
    63008 times recovered from packet loss by selective acknowledgements
    16 bad SACK blocks received
    Detected reordering 6 times using FACK
    Detected reordering 7 times using SACK
    Detected reordering 32 times using time stamp
    38 congestion windows fully recovered without slow start
    26 congestion windows partially recovered using Hoe heuristic
    1637 congestion windows recovered without slow start by DSACK
    12046 congestion windows recovered without slow start after partial ack
    TCPLostRetransmit: 36117
    1701 timeouts after SACK recovery
    86 timeouts in loss state
    654771 fast retransmits
    6216 forward retransmits
    25907 retransmits in slow start
    13344 other TCP timeouts
    TCPLossProbes: 600665
    TCPLossProbeRecovery: 460323
    2056 SACK retransmits failed
    8515 packets collapsed in receive queue due to low socket buffer
    68131 DSACKs sent for old packets
    223 DSACKs sent for out of order packets
    521780 DSACKs received
    210 DSACKs for out of order packets received
    45 connections reset due to unexpected data
    20 connections reset due to early user close
    714 connections aborted due to timeout
    TCPDSACKIgnoredOld: 2424
    TCPDSACKIgnoredNoUndo: 310510
    TCPSpuriousRTOs: 929
    TCPSackShifted: 636029
    TCPSackMerged: 613319
    TCPSackShiftFallback: 343428
    TCPBacklogDrop: 696
    TCPRetransFail: 244
    TCPRcvCoalesce: 54141309
    TCPOFOQueue: 18593353
    TCPOFOMerge: 211
    TCPChallengeACK: 815
    TCPSYNChallenge: 803
    TCPSpuriousRtxHostQueues: 28
IpExt:
    InBcastPkts: 4134951
    OutBcastPkts: 33492
    InOctets: -550766607
    OutOctets: 2039824407
    InBcastOctets: 817912422
    OutBcastOctets: 3173434
    InNoECTPkts: -895991522