TCP頭部結構
- 16位源端口：標識發送方端口
- 16位目的端口：標識接受方端口
- 32位序列號：數據按照序列號傳輸，如果接收方接受后的數據序列號出現錯誤，可以根據此序號重新排列
- 32位確認號：接受方接受到信號后，對發送方進行確認，此確認好為接受到的序列號+1
- 4位頭部長度：標識TCP頭部有多少個4字節，最大為1111(15)，也就是說TCP頭部最大有15*4=60個字節
- 6位保留長度：暫時沒有標明用途
- 6位標志：
-- URG：緊急指針是否有效。為1，標識某一位需要被優先處理。
-- ACK：確認號是否有效
-- PSH：提示接收端應用程序立即從TCP緩沖區把數據讀走
-- RST：復位信號，對方要求重新建立連接
-- SYN：請求建立連接，在三次握手中用到
-- FIN：請求斷開連接，在四次揮手中用到 - 16位窗口大小：是接受方勇與告訴發送方TCP緩沖區還能容納多少字節
- 16位檢驗和：檢驗數據在發送過程中是否損壞
- 16位緊急指針：當URG為1時生效，緊急數據字節號(urgSeq)=TCP報文序號(seq)+緊急指針(urgpoint)-1
ACK、SYN和FIN這些大寫的單詞表示標志位，其值要么是1，要么是0；ack、seq小寫的單詞表示序號。
3次握手
第一次握手：建立連接時，客戶端發送syn包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。
4次揮手
1）客戶端進程發出連接釋放報文，並且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等於前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。
2）服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3）客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最后的數據）。
4）服務器將最后的數據發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態，等待客戶端的確認。
5）客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2∗∗MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。
6）服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB后，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。
TCB：
在同一時刻，設備可能會產生多種數據需要分發給不同的設備，為了確保數據能夠正確分發，TCP用一種叫做TCB，也叫傳輸控制塊的數據結構把發給不同設備的數據封裝起來，我們可以把該結構看做是信封。一個TCB數據塊包含了數據發送雙方對應的socket信息以及擁有裝載數據的緩沖區。
常見問題
- 為什么連接的時候是三次握手，關閉的時候卻是四次握手？
答：因為當Server端收到Client端的SYN連接請求報文后，可以直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能並不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端所有的報文都發送完了，我才能發送FIN報文，因此不能一起發送。故需要四步握手。
- 為什么TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
答：雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。在Client發送出最后的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發送出ACK之后進入到TIME_WAIT狀態。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那么Client會重發ACK並再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經被成功接收，則結束TCP連接。
- 為什么不能用兩次握手進行連接？
答：3次握手完成兩個重要的功能，既要雙方做好發送數據的准備工作(雙方都知道彼此已准備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。
現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。作為例子，考慮計算機S和C之間的通信，假定C給S發送一個連接請求分組，S收到了這個分組，並發 送了確認應答分組。按照兩次握手的協定，S認為連接已經成功地建立了，可以開始發送數據分組。可是，C在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已准備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發來的任何數據分 組，只等待連接確認應答分組。而S在發出的分組超時后，重復發送同樣的分組。這樣就形成了死鎖。
- 如果已經建立了連接，但是客戶端突然出現故障了怎么辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75秒鍾發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接着就關閉連接。
出現大量TIME_WAIT或CLOSE_WAIT的原因及解決辦法
統計tcp狀態數量
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
出現大量TIME_WAIT的原因以及解決辦法
存在大量短連接，並且由該方主動關閉。一般出現在web服務器中，因為HTTP關閉TCP連接的是Server端。
HTTP1.0默認使用非持久連接，一個request和response后立馬關閉TCP連接（為了實現client到web-server能支持長連接，必須在HTTP請求頭里顯示指定 Connection:keep-alive）；
HTTP1.1默認使用持久連接，也就是會重用TCP連接傳輸多個 request/response（要關閉keep-alive需要在HTTP請求頭里顯示指定 Connection:close)
解決方法
#編輯/etc/sysctl.conf優化內核
#開啟SYN Cookies。當出現SYN等待隊列溢出時，啟用cookies來處理，可防范少量SYN攻擊，默認為0，表示關閉；
net.ipv4.tcp_syncookies = 1
#開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接，默認為0，表示關閉；
net.ipv4.tcp_tw_reuse = 1
#對於本端斷開的socket連接，TCP保持在FIN-WAIT-2狀態的時間。
net.ipv4.tcp_fin_timeout = 30
#對於一個新建連接，內核要發送多少個 SYN 連接請求才決定放棄。不應該大於255，默認值是5，對應於180秒左右時間。(對於大負載而物理通信良好的網絡而言,這個值偏高,可修改為2.這個值僅僅是針對對外的連接,對進來的連接,是由tcp_retries1 決定的)
net.ipv4.tcp_syn_retries = 2
#對於遠端的連接請求SYN，內核會發送SYN ＋ ACK數據報，以確認收到上一個 SYN連接請求包。這是所謂的三次握手( threeway handshake)機制的第二個步驟。這里決定內核在放棄連接之前所送出的 SYN+ACK 數目。不應該大於255，默認值是5，對應於180秒左右時間。(可以根據上面的 tcp_syn_retries 來決定這個值)
net.ipv4.tcp_synack_retries = 2
#在近端丟棄TCP連接之前﹐要進行多少次重試。默認值是7個﹐相當於 50秒 – 16分鍾﹐視 RTO 而定。如果您的系統是負載很大的web服務器﹐那么也許需要降低該值﹐這類 sockets 可能會耗費大量的資源。
net.ipv4.tcp_orphan_retries = 3
#當keepalive起用的時候，TCP發送keepalive消息的頻度。缺省是2小時，改為20分鍾(20*60s)
net.ipv4.tcp_keepalive_time = 1200
#TCP發送keepalive探測以確定該連接已經斷開的次數。(注意:保持連接僅在SO_KEEPALIVE套接字選項被打開是才發送.次數默認不需要修改,當然根據情形也可以適當地縮短此值.設置為5比較合適)
net.ipv4.tcp_keepalive_probes = 5
#探測消息發送的頻率，乘以tcp_keepalive_probes就得到對於從開始探測以來沒有響應的連接殺除的時間。默認值為75秒，也就是沒有活動的連接將在大約11分鍾以后將被丟棄。(對於普通應用來說,這個值有一些偏大,可以根據需要改小.特別是web類服務器需要改小該值,15是個比較合適的值)
net.ipv4.tcp_keepalive_intvl = 15
#表示用於向外連接的端口范圍。缺省情況下很小：32768到61000，改為10000到65000
net.ipv4.ip_local_port_range = 10000 65000
#SYN隊列的長度，默認為1024，加大隊列長度為8192，可以容納更多等待連接的網絡連接數
net.ipv4.tcp_max_syn_backlog = 8192
#修改完之后執行/sbin/sysctl -p讓參數生效。
出現大量CLOSE_WAIT的原因以及解決辦法
如果一直保持在CLOSE_WAIT狀態，那么只有一種情況，就是在對方關閉連接之后服務器程序自己沒有進一步發出ack信號。換句話說，就是在對方連接關閉之后，程序里沒有檢測到，或者程序壓根就忘記了這個時候需要關閉連接，於是這個資源就一直被程序占着。這種情況通過服務器內核參數也沒辦法解決，服務器對於程序搶占的資源沒有主動回收的權利，除非終止程序運行。
所以如果將大量CLOSE_WAIT的解決辦法總結為一句話那就是：查代碼。因為問題出在程序里頭啊。