一、TCP報文格式

16位源埠號：16位的源埠中包含初始化通訊的埠。源埠和源IP地址的作用是標識報文的返回地址。

16位目的埠號：16位的目的埠域定義傳輸的目的。這個埠指明報文接收計算機上的應用程式地址介面。

32位序號：32位的序列號由接收端計算機使用，重新分段的報文成最初形式。當SYN出現，序列碼實際上是初始序列碼（Initial Sequence Number，ISN），而第一個資料位元組是ISN+1。這個序列號（序列碼）可用來補償傳輸中的不一致。

32位確認序號：32位的序列號由接收端計算機使用，重組分段的報文成最初形式。如果設定了ACK控制位，這個值表示一個準備接收的包的序列碼。

4位首部長度：4位包括TCP頭大小，指示何處資料開始。

保留（6位）：6位值域，這些位必須是0。為了將來定義新的用途而保留。

標誌：6位標誌域。表示為：緊急標誌、有意義的應答標誌、推、重置連線標誌、同步序列號標誌、完成傳送資料標誌。按照順序排列是：URG、ACK、PSH、RST、SYN、FIN。

16位視窗大小：用來表示想收到的每個TCP資料段的大小。TCP的流量控制由連線的每一端通過宣告的視窗大小來提供。視窗大小為位元組數，起始於確認序號欄位指明的值，這個值是接收端正期望接收的位元組。視窗大小是一個16位元組欄位，因而視窗大小最大為65535位元組。

16位校驗和：16位TCP頭。源機器基於資料內容計算一個數值，收資訊機要與源機器數值 結果完全一樣，從而證明資料的有效性。檢驗和覆蓋了整個的TCP報文段：這是一個強制性的欄位，一定是由傳送端計算和儲存，並由接收端進行驗證的。

16位緊急指標：指向後面是優先資料的位元組，在URG標誌設定了時才有效。如果URG標誌沒有被設定，緊急域作為填充。加快處理標示為緊急的資料段。

選項：長度不定，但長度必須為1個位元組。如果沒有選項就表示這個1位元組的域等於0。

資料：該TCP協議包負載的資料。

在上述欄位中，6位標誌域的各個選項功能如下。

URG：緊急標誌。緊急標誌為"1"表明該位有效。

ACK：確認標誌。表明確認編號欄有效。大多數情況下該標誌位是置位的。TCP報頭內的確認編號欄內包含的確認編號（w+1）為下一個預期的序列編號，同時提示遠端系統已經成功接收所有資料。

PSH：推標誌。該標誌置位時，接收端不將該資料進行佇列處理，而是儘可能快地將資料轉由應用處理。在處理Telnet或rlogin等互動模式的連線時，該標誌總是置位的。

RST：復位標誌。用於復位相應的TCP連線。

SYN：同步標誌。表明同步序列編號欄有效。該標誌僅在三次握手建立TCP連線時有效。它提示TCP連線的服務端檢查序列編號，該序列編號為TCP連線初始端（一般是客戶端）的初始序列編號。在這裡，可以把TCP序列編號看作是一個範圍從0到4，294，967，295的32位計數器。通過TCP連線交換的資料中每一個位元組都經過序列編號。在TCP報頭中的序列編號欄包括了TCP分段中第一個位元組的序列編號。

FIN：結束標誌。

二、TCP三次握手

所謂三次握手（Three-Way Handshake）即建立TCP連線，就是指建立一個TCP連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立。在socket程式設計中，這一過程由客戶端執行connect來觸發，整個流程如下圖所示：

（1）第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。
（2）第二次握手：Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。
（3）第三次握手：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。

簡單來說，就是
1、建立連線時，客戶端傳送SYN包（SYN=i）到伺服器，並進入到SYN-SEND狀態，等待伺服器確認
2、伺服器收到SYN包，必須確認客戶的SYN（ack=i+1）,同時自己也傳送一個SYN包（SYN=k）,即SYN+ACK包，此時伺服器進入SYN-RECV狀態
3、客戶端收到伺服器的SYN+ACK包，向伺服器傳送確認報ACK（ack=k+1）,此包傳送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手，客戶端與伺服器開始傳送資料。

SYN攻擊：
在三次握手過程中，Server傳送SYN-ACK之後，收到Client的ACK之前的TCP連線稱為半連線（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地傳送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間佔用未連線佇列，導致正常的SYN請求因為佇列滿而被丟棄，從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連線狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：

#netstat -nap | grep SYN_RECV

三、TCP四次揮手

所謂四次揮手（Four-Way Wavehand）即終止TCP連線，就是指斷開一個TCP連線時，需要客戶端和服務端總共傳送4個包以確認連線的斷開。在socket程式設計中，這一過程由客戶端或服務端任一方執行close來觸發，整個流程如下圖所示：

由於TCP連線時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料傳送任務後，傳送一個FIN來終止這一方向的連線，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連線上仍然能夠傳送資料，直到這一方向也傳送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
（1）第一次揮手：Client傳送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。
（2）第二次揮手：Server收到FIN後，傳送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
（3）第三次揮手：Server傳送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。
（4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著傳送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

為什麼建立連線是三次握手，而關閉連線卻是四次揮手呢？
這是因為服務端在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給客戶端。而關閉連線時，當收到對方的FIN報文時，僅僅表示對方不再傳送資料了但是還能接收資料，己方也未必全部資料都傳送給對方了，所以己方可以立即close，也可以傳送一些資料給對方後，再傳送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開傳送。

為什麼TIME_WAIT狀態需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？
原因有二：
一、保證TCP協議的全雙工連線能夠可靠關閉
二、保證這次連線的重複資料段從網路中消失
先說第一點，如果Client直接CLOSED了，那麼由於IP協議的不可靠性或者是其它網路原因，導致Server沒有收到Client最後回覆的ACK。那麼Server就會在超時之後繼續傳送FIN，此時由於Client已經CLOSED了，就找不到與重發的FIN對應的連線，最後Server就會收到RST而不是ACK，Server就會以為是連線錯誤把問題報告給高層。這樣的情況雖然不會造成資料丟失，但是卻導致TCP協議不符合可靠連線的要求。所以，Client不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最後正確的關閉連線。

再說第二點，如果Client直接CLOSED，然後又再向Server發起一個新連線，我們不能保證這個新連線與剛關閉的連線的埠號是不同的。也就是說有可能新連線和老連線的埠號是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連線和已經關閉的老連線埠號是一樣的，如果前一次連線的某些資料仍然滯留在網路中，這些延遲資料在建立新連線之後才到達Server，由於新連線和老連線的埠號是一樣的，又因為TCP協議判斷不同連線的依據是socket pair，於是，TCP協議就認為那個延遲的資料是屬於新連線的，這樣就和真正的新連線的資料包發生混淆了。所以TCP連線還要在TIME_WAIT狀態等待2倍MSL，這樣可以保證本次連線的所有資料都從網路中消失。

四、TCP的滑動視窗機制

TCP這個協議是網路中使用的比較廣泛，他是一個面向連線的可靠的傳輸協議。既然是一個可靠的傳輸協議就需要對資料進行確認。TCP協議裡視窗機制有2種：一種是固定的視窗大小；一種是滑動的視窗。這個視窗大小就是我們一次傳輸幾個資料。對所有資料幀按順序賦予編號，傳送方在傳送過程中始終保持著一個傳送視窗，只有落在傳送視窗內的幀才允許被髮送；同時接收方也維持著一個接收視窗，只有落在接收視窗內的幀才允許接收。這樣通過調整傳送方視窗和接收方視窗的大小可以實現流量控制。
TCP滑動視窗技術通過動態改變視窗大小來調節兩臺主機間資料傳輸。每個TCP/IP主機支援全雙工資料傳輸，因此TCP有兩個滑動視窗：一個用於接收資料，另一個用於傳送資料。TCP使用肯定確認技術，其確認號指的是下一個所期待資料包的序列號。 假定傳送方裝置以每一次三個資料包的方式傳送資料，也就是說，視窗大小為3。傳送方傳送序列號為1、2、3的三個資料包，接收方裝置成功接收資料包，用序列號4確認。傳送方裝置收到確認，繼續以視窗大小3傳送資料。當接收方裝置要求降低或者增大網路流量時，可以對視窗大小進行減小或者增加，本例降低視窗大小為2，每一次傳送兩個資料包。當接收方裝置要求視窗大小為0，表明接收方已經接收了全部資料，或者接收方應用程式沒有時間讀取資料，要求暫停傳送。傳送方接收到攜帶視窗號為0的確認，停止這一方向的資料傳輸。

我們可以看下面一張圖來分析一下固定視窗大小有什麼問題。

這裡我們可以看到假設視窗的大小是1，也是就每次只能傳送一個資料只有接受方對這個資料進行確認了以後才能傳送第2個資料。我們可以看到傳送方每傳送一個資料接受方就要給傳送方一個ACK對這個資料進行確認。只有接受到了這個確認資料以後傳送方才能傳輸下個資料。 這樣我們考慮一下如果說視窗過小，那麼當傳輸比較大的資料的時候需要不停的對資料進行確認，這個時候就會造成很大的延遲。如果說視窗的大小定義的過大。我們假設傳送方一次傳送100個資料。但是接收方只能處理50個資料。這樣每次都會只對這50個資料進行確認。傳送方下一次還是傳送100個資料，但是接受方還是隻能處理50個資料。這樣就避免了不必要的資料來擁塞我們的鏈路。所以我們就引入了滑動視窗機制，視窗的大小並不是固定的而是根據我們之間的鏈路的頻寬的大小，這個時候鏈路是否擁護塞。接受方是否能處理這麼多資料了。
我們看看滑動視窗是如何工作的。我們看下面幾張圖。

首先是第一次傳送資料這個時候的視窗大小是根據鏈路頻寬的大小來決定的。我們假設這個時候視窗的大小是3。這個時候接受方收到資料以後會對資料進行確認告訴傳送方我下次希望手到的是資料是多少。這裡我們看到接收方傳送的ACK=3(這是傳送方傳送序列2的回答確認，下一次接收方期望接收到的是3序列訊號)。這個時候傳送方收到這個資料以後就知道我第一次傳送的3個資料對方只收到了2個。就知道第3個資料對方沒有收到。下次在傳送的時候就從第3個資料開始發。這個時候視窗大小就變成了2。

這個時候傳送方傳送2個資料。

看到接收方傳送的ACK是5就表示他下一次希望收到的資料是5，傳送方就知道我剛才傳送的2個資料對方收了這個時候開始傳送第5個資料。
這就是滑動視窗的工作機制，當鏈路變好了或者變差了這個視窗還會發生變話，並不是第一次協商好了以後就永遠不變了。

滑動視窗協議優勢：
1、允許傳送方在停止並等待確認前可以連續傳送多個分組。由於傳送方不必每傳送每確認，因此該協議可以加速資料的傳輸。
2、在接收視窗向前滑動時（與此同時也傳送了確認），傳送視窗也會同步向前滑動，收發兩端的視窗按照以上規律不斷地向前滑動 ，可以動態調整視窗大小