本篇文章較長，大家先看下目錄

1、簡介

2、TCP協議頭

3、TCP數據包的編號（SEQ）

4、三次握手建立連接

5、四次揮手斷開連接

6、TCP可靠性的保證

7、滑動窗口技術

9、窗口滑動的數據重發

9、TCP流控制

10、網線“斷”了怎么辦

01 簡介 ?

TCP(Transmission Control Protocol 傳輸控制協議)是一種基于IP的傳輸層協議，TCP協議面向連接、正面確認與重傳、緩沖機制、流量控制、差錯控制、擁塞控制，可保證高可靠性(數據無丟失、數據無失序、數據無錯誤、數據無重復到達)傳輸層協議。

上圖形象展示了TCP協議是基于IP協議的傳輸層協議，對于IP協議的詳解，請看《IP協議詳解》。

02 TCP協議頭 ?

TCP協議頭數據個數如下：

端口號[16bit]

我們知道，網絡實現的是不同主機的進程間通信。在一個操作系統中，有很多進程，當數據到來時要提交給哪個進程進行處理呢?這就需要用到端口號。在TCP頭中，有源端口號(SourcePort)和目標端口號(DestinationPort)。源端口號標識了發送主機的進程,目標端口號標識接受方主機的進程。端口是由互聯網分配號碼管理局（IANA）分配的，具體請看《UDP協議詳解》。

序號[32bit]

序號分為發送序號(SequenceNumber)和確認序號(AcknowledgmentNumber)。

發送序號：用來標識從TCP源端向TCP目的端發送的數據字節流，它表示在這個報文段中的第一個數據字節的順序號。如果將字節流看作在兩個應用程序間的單向流動，則?TCP用順序號對每個字節進行計數。序號是32bit的無符號數，序號到達2∧32－?1后又從?0開始。當建立一個新的連接時，SYN標志變1，順序號字段包含由這個主機選擇的該連接的初始順序號ISN(Initial Sequence Number)。

確認序號：包含發送確認的一端所期望收到的下一個順序號。因此，確認序號應當是上次已成功收到數據字節順序號加?1。只有ACK標志為1時確認序號字段才有效。TCP為應用層提供全雙工服務，這意味數據能在兩個方向上獨立地進行傳輸。因此，連接的每一端必須保持每個方向上的傳輸數據順序號。

在wireshark的抓包文件中，Seq表示發送序列號，Ack表示確認序列號。

偏移[4bit]

這里的偏移實際指的是TCP首部的長度，它用來表明TCP首部中32bit字的數目，通過它可以知道一個TCP包它的用戶數據是從哪里開始的。這個字段占4bit,如4bit的值是0101,則說明TCP首部長度是5* 4 = 20字節。所以TCP的首部長度最大為15* 4 = 60字節。然而沒有可選字段，正常長度為20字節。

Reserved [3bit]

目前沒有使用，它的值都為0。注意：在比較舊的資料中顯示6bit的保留字節，因為新的TCP協議使用了3個位作為標志，所以只剩下3個保留位。

標志[9bit]

上面說到增加了3位作標志位，增加的是：

NS: "nonce sum"簡寫。隨機和，該標簽用來保護不受發送者發送的突發的惡意隱藏報文的侵害。

CWR: "Congestion WindowReduced"簡寫。擁塞窗口減，發送方降低它的發送速率，發送者在接收到一個帶有ECEflag包時，將會使用CWRflag。

ECE: "ECN-Echo"簡寫。ECN表示ExplicitCongestion Notification(顯式擁塞通知)，發送方接收到了一個更早的擁塞通告。表示TCPpeer有ECN能力。

其他6個標志位

URG: "urgent"簡寫。通知接收端處理在處理其他包前優先處理接收到的緊急報文（urgentpackets），緊急指針(urgentpointer)有效。

ACK: "Acknowledgment"簡寫。表示包已經被成功接收，確認序號有效。

PSH: "push"簡寫。通知接收端處理接收的報文，而不是將報文緩存到buffer中。

RST:"reset"簡寫。重置連接標志，用于重置由于主機崩潰或其他原因而出現錯誤的連接。復位通訊請求，一般表示斷開一個連接。我們把含有RST標識的報文稱為復位報文段。

SYN:"Synchronisation"簡寫。表示三次握手建立連接的第一步，在建立連接時發送者發送的第一個包中設置flag值為SYN。我們把含有SYN標識的報文稱為同步報文段。

FIN: "finished"簡寫。表示發送者以及發送完數據，通常用在發送者通知對端,本端即將關閉。我們把含有FIN標識的報文稱為結束報文段

注意：他們中的多個可同時被置為1。

窗口大小(window)[16bit]

指的是接收窗口，窗口的大小，表示源方法最多能接受的字節數。

校驗和[16bit]

校驗和覆蓋了整個的TCP報文段：TCP首部和TCP數據。這是一個強制性的字段，一定是由發端計算和存儲，并由收端進行驗證。

緊急指針[16bit]

只有當URG標志置為1時緊急指針才有效。緊急指針是一個正的偏移量，和序號字段中的值相加表示緊急數據最后一個字節的序號。TCP的緊急方式是發送端向另一端發送緊急數據的一種方式。

TCP選項

長度不定，但長度必須是32bits的整數倍。TCP頭部的最后一個選項字段（options）是可變長的可選信息。這部分最多包含40字節，因為TCP頭部最長是60字節（其中還包含前面討論的20字節的固定部分）。典型的TCP選項頭部結構如圖所示。

選項的第一個字段kind說明選項的類型，有的TCP選項沒有后面兩個字段，僅包含1字節的kind字段。

第二個字段length（如果有的話）指定該選項的總長度，該長度包括kind字段和length字段占據的2字節。

第三個字段info（如果有的話）是選項的具體信息。

常見的TCP選項有7種，如圖所示

1、kind=0，選項表結束（EOP）選項

一個報文段僅用一次。放在末尾用于填充，用途是說明：首部已經沒有更多的消息，應用數據在下一個32位字開始處。

2、kind=1，空操作（NOP）選項

沒有特殊含義，一般用于將TCP選項的總長度填充為4字節的整數倍。

3、kind=2，最大報文段長度（MSS）選項

TCP連接初始化時，通信雙方使用該選項來協商最大報文段長度。TCP模塊通常將MSS設置為（MTU-40）字節（減掉的這40字節包括20字節的TCP頭部和20字節的IP頭部）。這樣攜帶TCP報文段的IP數據報的長度就不會超過MTU（假設TCP頭部和IP頭部都不包含選項字段，并且這也是一般情況），從而避免本機發生IP分片。對以太網而言，MSS值是1460（1500-40）字節。

4、kind=3，窗口擴大因子選項

TCP連接初始化時，通信雙方使用該選項來協商接收窗口的擴大因子。在TCP的頭部中，接收窗口大小是用16位表示的，故最大為65535字節，但實際上TCP模塊允許的接收窗口大小遠不止這個數（為了提高TCP通信的吞吐量）。窗口擴大因子解決了這個問題。

假設TCP頭部中的接收通告窗口大小是N，窗口擴大因子（移位數）是M，那么TCP報文段的實際接收通告窗口大小是N*(2^M)，或者說N左移M位。注意，M的取值范圍是0～14。我們可以通過修改/proc/sys/net/ipv4/tcp_window_scaling內核變量來啟用或關閉窗口擴大因子選項。

和MSS選項一樣，窗口擴大因子選項只能出現在同步報文段中，否則將被忽略。但同步報文段本身不執行窗口擴大操作，即同步報文段頭部的接收窗口大小就是該TCP報文段的實際接收窗口大小。當連接建立好之后，每個數據傳輸方向的窗口擴大因子就固定不變了。

5、kind=4，選擇性確認（SelectiveAcknowledgment，SACK）選項

TCP通信時，如果某個TCP報文段丟失，則TCP會重傳最后被確認的TCP報文段后續的所有報文段，這樣原先已經正確傳輸的TCP報文段也可能重復發送，從而降低了TCP性能。SACK技術正是為改善這種情況而產生的，它使TCP只重新發送丟失的TCP報文段，而不用發送所有未被確認的TCP報文段。選擇性確認選項用在連接初始化時，表示是否支持SACK技術。我們可以通過修改/proc/sys/net/ipv4/tcp_sack 內核變量來啟用或關閉選擇性確認選項。

6、kind=5，SACK實際工作的選項

該選項的參數告訴發送方本端已經收到并緩存的不連續的數據塊，從而讓發送端可以據此檢查并重發丟失的數據塊。每個塊邊沿（edgeofblock）參數包含一個4字節的序號。其中塊左邊沿表示不連續塊的第一個數據的序號，而塊右邊沿則表示不連續塊的最后一個數據的序號的下一個序號。這樣一對參數（塊左邊沿和塊右邊沿）之間的數據是沒有收到的。因為一個塊信息占用8字節，所以TCP頭部選項中實際上最多可以包含4個這樣的不連續數據塊（考慮選項類型和長度占用的2字節）。

7、kind=8，時間戳選項。

該選項提供了較為準確的計算通信雙方之間的回路時間（RoundTrip Time，RTT）的方法，從而為TCP流量控制提供重要信息。我們可以通過修改/proc/sys/net/ipv4/tcp_timestamps內核變量來啟用或關閉時間戳選項。

以SYN的TCP選項的MSS為例的wireshark分析，其他的大家可以自行分析。

整個TCP協議頭部的wireshark解析。

03 TCP數據包的編號（SEQ） ?

一個包1400字節，那么一次性發送大量數據，就必須分成多個包。比如，一個10MB 的文件，需要發送7100多個包。

發送的時候，TCP協議為每個包編號（sequencenumber，簡稱SEQ），以便接收的一方按照順序還原。萬一發生丟包，也可以知道丟失的是哪一個包。

第一個包的編號是一個隨機數。為了便于理解，這里就把它稱為1號包。假定這個包的負載長度是100字節，那么可以推算出下一個包的編號應該是101。這就是說，每個數據包都可以得到兩個編號：自身的編號，以及下一個包的編號。接收方由此知道，應該按照什么順序將它們還原成原始文件。

這里的編號就是TCP頭中的確認號。wireshark顯示的Seq和Ack是wireshark重新編號的。

數據包1：發送序號：532420307（1），確認序號：2978637660（1）。數據包長6

數據包2：發送序號：2978637660（1），確認序號：532420313（7）。

備注：括號里是wireshark的編號。

可以發現：

數據包2的發送序號是數據包1的確認序號。

數據包2的確認序號是數據包1的發送序號+6，也就是加上數據包長。

符合上面的文字描述。

04 三次握手建立連接 ?

三次握手建立連接過程：

a.請求端(通常稱為客戶)發送一個SYN段指明客戶打算連接的服務器的端口，以及初始序號(ISN,在這個例子中為1415531521)。這個SYN段為報文段1。

b.服務器發回包含服務器的初始序號的SYN報文段(報文段2)作為應答。同時，將確認序號設置為客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將占用一個序號。

c.客戶必須將確認序號設置為服務器的ISN加1以對服務器的SYN報文段進行確認(報文段3)。

這三個報文段完成連接的建立。這個過程也稱為三次握手(three-wayhandshake)。

用wirshark抓包如下:

可以看到三次握手確定了雙方間包的序號、最大接受數據的大小(window)以及MSS(MaximumSegment Size)。

MSS = MTU - IP頭-TCP頭,MTU表示最大傳輸單元，我們在IP頭分析的時候會講到,它一般為1500個字節。IP頭和TCP頭部帶可選選項的時候都是20個字節。這樣的話MSS=1500- 20 -20 = 1460。

MSS限制了TCP包攜帶數據的大小,它的意思就是當應用層向傳輸層提交數據通過TCP協議進行傳輸時，如果應用層的數據大于MSS就必須分段，分成多個段，逐個的發過去。這部分內容是不是IP分片，不要和IP分片混淆了，IP分片是IP協議層的數據報分片，這是TCP的分片，IP協議分片詳細請看《IP協議詳解》。

我們wireshar抓包顯示MSS都是1460，這樣顯示不出來握手的協商機制。假設客戶端的MSS是4312，服務器的MSS是1460，那么握手過程中的協商可以下圖形象表示。

其中，第1 次和第2 次握手包的TCP 首部包含MSS 選項，互相通知對方網絡接口能夠適應的MSS 的大小，然后雙方會使用較小的MSS 值進行傳輸。

前面講解TCP頭中flg中就有SYN標志，在wireshark抓包中也有顯示。

讀到這里，好像一切順理成章，決定既然互聯網“先驅”定義了三次握手建立，那么就是三次握手建立連接。可有些人會有疑問，為什么兩次握手不能。

比如A給B東西，

A說：我要和你建立，你準備好了嗎？

B說：好的，我準備好了。

A直接把東西給B。

這樣的邏輯在生活中好像一點毛病也沒有，但其實這樣是不行，3次握手完成兩個重要的功能，既要雙方做好發送數據的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協商，這個序列號在握手過程中被發送和確認。

現在把三次握手改成僅需要兩次握手，死鎖是可能發生的。其實上面有個“坑”，那就是一開始我們限制了A給B東西，但實際的TCP通信中，連接建立了，可以客戶端主動和服務器通信，也可以服務器主動和客戶端通信，如果兩次握手，B收到A的握手申請，發送好的，我準備好了。這時候B在想，A如果收不到怎么辦，A到底有沒有收到啊，我（B）能不能向A發數據？？？

所以需要三次握手。

A說：我和你建立，你準備好了嗎？

B說：好的，我準備好了。

A說：我知道你準備好了（我也準備好了）。

開始愉快的相互傳輸數據。

05 四次揮手斷開連接 ?

四次揮手斷開連接過程：

a.現在的網絡通信都是基于socket實現的，當客戶端將自己的socket進行關閉時，內核協議棧會向服務器自動發送一個FIN置位的包，請求斷開連接。我們稱首先發起斷開請求的一方稱為主動斷開方。

b.服務器端收到請客端的FIN斷開請求后，內核協議棧會立即發送一個ACK包作為應答，表示已經收到客戶端的請求。

c.服務器運行一段時間后，關閉了自己的socket。這個時候內核協議棧會向客戶端發送一個FIN置位的包，請求斷開連接。

d.客戶端收到服務端發來的FIN斷開請求后，會發送一個ACK做出應答，表示已經收到服務端的請求。

用wirshar抓包分析如下:

前面講解TCP頭中flg中就有FIN標志，在wireshark抓包中也有顯示。

下圖類比四次揮手過程：

這里有個問題，如果有同學自己wireshark抓包分析的話（我提供的wireshark文件第一次通信也是這種情況），會發現下面情況：

怎么只有3次揮手，應用程序出問題了？wirshark自行”合并“了？為什么別人抓包就有四次揮手斷開？

這跟Wireshark沒有關系，跟實現有關。四次揮手，都知道是客戶端和服務器之間交互的四個報文，FIN、ACK、FIN、ACK。但抓包來看，卻不是每次如教科書說的那樣。首先要搞明白這個FIN報文的真正用途，FIN報文用在本端沒有數據發送給對方時，關閉從本端到對端的連接。但是并不影響從對方到本端的連接，也就是說本端仍然可以接收對方的數據。即發送通道關閉，接收通道正常。如果對方收到本端FIN報文時，對方的接收通道就會關閉。此時，如果對方也沒有數據發給本端，那么對方也會發送FIN給本端，用于關閉從對方到本端的連接，這時候就可能出現ACK和FIN合在一起的情況。當然，如果對方仍然有數據發送，那么就等數據發完，再發FIN來關閉連接，這時候就是四次揮手了。因此，四次揮手變成三次，跟wireshark沒關系，跟數據的收發雙方才有關系，從這也能看出tcp是雙工通信了。現在的很多的實現都是合并在一起，三個過程，主要是為了效率和安全。

TCP 連接必須經過時間2MSL 后才真正釋放掉(2MSL的時間的用意?---?為了保證A 發送的最后一個ACK 報文段能夠到達B.防止“已失效的連接請求報文段”出現在本連接中.A在發送完最后一個ACK 報文段后,再經過時間2MSL,就可以使本連接持續的時間內所產生的所有報文段,都從網絡中消失.這樣就可以使下一個新的連接中不會出現這種舊的連接請求報文段)。

? 06 TCP可靠性的保證 ? TCP采用一種名為“帶重傳功能的肯定確認（positiveacknowledge withretransmission）”的技術作為提供可靠數據傳輸服務的基礎。這項技術要求接收方收到數據之后向源站回送確認信息ACK。發送方對發出的每個分組都保存一份記錄，在發送下一個分組之前等待確認信息。發送方還在送出分組的同時啟動一個定時器，并在定時器的定時期滿而確認信息還沒有到達的情況下，重發剛才發出的分組。

下圖a表示帶重傳功能的肯定確認協議傳輸數據的情況，下圖a表示分組丟失引起超時和重傳。為了避免由于網絡延遲引起遲到的確認和重復的確認，協議規定在確認信息中稍帶一個分組的序號，使接收方能正確將分組與確認關聯起來。

下圖a可以看出，雖然網絡具有同時進行雙向通信的能力，但由于在接到前一個分組的確認信息之前必須推遲下一個分組的發送，簡單的肯定確認協議浪費了大量寶貴的網絡帶寬。為此，?TCP使用滑動窗口的機制來提高網絡吞吐量，同時解決端到端的流量控制。

07 滑動窗口技術 ?

TCP的滑動窗口主要有兩個作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同時滑動窗口機制還體現了TCP面向字節流的設計思路。

TCP的Window是一個16bit位字段，它代表的是窗口的字節容量，也就是TCP的標準窗口最大為2^16-1=65535個字節。另外在TCP的選項字段中還包含了一個TCP窗口擴大因子，option-kind為3，詳細請看上文。

滑動窗口技術是簡單的帶重傳的肯定確認機制的一個更復雜的變形，它允許發送方在等待一個確認信息之前可以發送多個分組。

所以，TCP的滑動窗口的可靠性也是建立在“確認重傳”基礎上的。

TCP 滑動窗口分為：發送窗口和接收窗口。

發送方的發送緩存內的數據都可以被分為4類:

已發送，已收到ACK

已發送，未收到ACK

未發送，但允許發送

未發送，但不允許發送

其中類型2和3都屬于發送窗口。

接收方的緩存數據分為3類：

已接收

未接收但準備接收

未接收而且不準備接收

如下圖所示，發送方要發送一個分組序列，滑動窗口協議在分組序列中放置一個固定長度的窗口，然后將窗口內的所有分組都發送出去；當發送方收到對窗口內第一個分組的確認信息時，它可以向后滑動并發送下一個分組；隨著確認的不斷到達，窗口也在不斷的向后滑動。

上面的解釋，對于不熟悉滑動窗口的同學，可能看不太明白。下面將詳細講述一下。

上面講解三次握手建立連接時說到，握手過程中商議了MSS，也就是每一包的數據長度。抓包中也顯示的確是1460字節傳輸的。

但是1460字節不是整數，不方便我們快速計算，下面講解將MSS假設為1000，這樣方面快速理解。

在進行數據傳輸時，如果傳輸的數據比較大(大于1000)，就需要拆分為多個數據包進行發送。TCP協議需要對數據進行確認后，才可以發送下一個數據包，

從上圖中可以看到，發送端每發送一個數據包，都需要得到接收端的確認應答以后，才可以發送下一個數據包。這樣一來，就會在等待確認應答包環節浪費時間。為了避免這種情況，TCP引入了窗口概念。窗口大小指的是不需要等待確認應答包而可以繼續發送數據包的最大值。

例如，窗口大小為3，數據包的傳輸如圖所示。

從上圖中可以看到，發送端發送第一個數據包（1-1000），沒有等待對應的確認應答包，就繼續發送第二個數據包（1001-2000）和第三個包（2001-3000）。當收到第3個數據包的確認應答包時，會連續發送3個數據包（3001-4000，4001-5000，5001-6000）。當收到第6個數據包的確認應答包時，又會發送3個數據包（6001-7000，7001-8000，8001-9000）。

以這種方式發送，就可以省去多個數據包（第1、2、4、5、7、8個）的確認應答包時間，從而避免了網絡的吞吐量的降低。

這樣就引出了窗口的概念，窗口大小指的是可以發送數據包的最大數量。建議讀到這里，剛才對窗口不太理解的同學，向上翻翻，再理解一下滑動窗口的圖示。

那么，此時窗口就通過滑動的方式，向后移動，確保下一次發送仍然可以發送窗口大小的數據包。這樣的發送方式被稱為滑動窗口機制。設置窗口大小為3，滑動窗口機制原理如圖所示。

上圖中，每1000 個字節表示一個數據包。發送端同時發送了3個數據包（2001-5000），接收端響應的確認應答包為“下一個發送4001”，表示接收端成功響應了前兩個數據包，沒有響應最后一個數據包。此時，最后一個數據包要保留在窗口中。

由于窗口大小為3，發送端除了最后一個包以外，還可以繼續發送下兩個數據包（5001-6000和6001-7000）。窗口滑動到7001 處。

08 窗口滑動的數據重發 ?

在進行數據包傳輸時，難免會出現數據丟失情況。這種情況一般分為兩種。

第一種，如果未使用滑動窗口機制，發送的數據包沒有收到確認應答包，那么數據都會被重發；如果使用了滑動窗口機制，即使確認應答包丟失，也不會導致數據包重發。

第二種，發送的數據包丟失，將導致數據包重發。

下面詳細介紹使用滑動窗口機制的兩種情況。

確認應答包丟失

這種情況指的是前面發送的數據包沒有收到對應的確認應答。當收到后面數據包的確認應答包，表示前面的數據包已經成功被接收端接收了，發送端不需要重新發送前面的數據包了。如圖所示。

下面分為5 部分對上圖進行講解。

1) 發送端第1 次發送數據包：這里設置的窗口大小為3，可以最大發送3 個數據包。發送端同時發送3 個數據包1-1000、1001-2000和2001-3000。

2) 接收端返回確認應答包：接收端接收到這些數據，并給出確認應答包。數據包1-1000 和數據包2001-3000 的確認應答包沒有丟失，但是數據包1001-2000 的確認應答包丟失了。

3) 發送端第2 次發送數據包：發送端收到接收端發來的確認應答包，雖然沒有收到數據包1001-2000 的確認應答包，但是收到了數據包2001-3000 的確認應答包。判斷第一次發送的3 個數據包都成功到達了接收端。再次發送3 個數據包3001-4000、4001-5000和5001-6000。

4) 接收端返回確認應答包：接收端接收到這些數據，并給出確認應答包。數據包3001-4000 和數據包4001-5000 的確認應答包丟失了，但是數據包5001-6000 沒有丟失。

5) 發送端第3 次發送數據包：發送端收到接收端發來的確認應答包，查看到數據包5001-6000 收到了確認應答包。判斷第2 次發送的3 個數據包都成功到達了接收端。再次發送3 個數據包6001-7000、7001-8000和8001-9000。

發送數據包丟失

這種情況指的是發送端發送的部分數據包沒有達到接收端。那么，如果在接收端收到的數據包，不是本應該要接收的數據包，那么就會給發送端返回消息，告訴發送端自己應該接收的數據包。

如果發送端連續收到3 次這樣的數據包，就認為該數據包成功發送到接收端，這時就開始重發該數據包。如圖所示。

下面分為7 部分對上圖進行講解。

1) 發送端發送數據包：這里窗口大小為4，發送端發送4 個數據包，分別為1-1000、1001-2000、2001-3000和3001-4000。

2) 接收端返回確認應答包：接收端接收到這些數據，并給出確認應答包。接收端收到了數據包1-1000，返回了確認應答包；收到了數據包1001-2000，返回了確認應答包；但是數據包2001-3000，在發送過程中丟失了，沒有成功到達接收端。數據包3001-4000 沒有丟失，成功到達了接收端，但是該數據包不是接收端應該接收的數據包，數據包2001-3000 才是真正應該接收的數據包。因此收到數據包3001-4000 以后，接收端第一次返回下一個應該發送2001 的數據包的確認應答包。

3)?發送端發送數據包：發送端仍然繼續向接收端發送4 個數據包，分別為4001-5000、5001-6000、6001-7000和7001-8000。

4) 接收端返回確認應答包：接收端接收到這些數據，并給出確認應答包。當接收端收到數據包4001-5000 時，發現不是自己應該接收的數據包2001-3000，第二次返回下一個應該發送2001 的數據包的確認應答包。當接收端收到數據包5001-6000 時，仍然發現不是自己應該接收的數據包2001-3000，第三次返回下一個應該發送2001 的數據包的確認應答包。以此類推直到接收完所有數據包，接收端都返回下一個應該發送2001 的數據包的確認應答包。

5)?發送端重發數據包：發送端連續3 次收到接收端發來的下一個應該發送2001 的數據包的確認應答包，認為數據包2001-3000 丟失了，就進行重發該數據包。

6)?接收端收到重發數據包：接收端收到重發數據包以后，查看這次是自己應該接收的數據包2001-3000，并返回確認應答包，告訴發送端，下一個該接收8001 的數據包了。

7)?發送端發送數據包：發送端收到確認應答包后，繼續發送窗口大小為4 的數據包，分別為8001-9000、9001-10000、10001-11000和11001-12000。 09 TCP流控制 ? 在使用滑動窗口機制進行數據傳輸時，發送方根據實際情況發送數據包，接收端接收數據包。但是，接收端處理數據包的能力是不同的。

1)如果窗口過小，發送端發送少量的數據包，接收端很快就處理了，并且還能處理更多的數據包。這樣，當傳輸比較大的數據時需要不停地等待發送方，造成很大的延遲。

2)如果窗口過大，發送端發送大量的數據包，而接收端處理不了這么多的數據包，這樣，就會堵塞鏈路。如果丟棄這些本應該接收的數據包，又會觸發重發機制。

3) 為了避免這種現象的發生，TCP提供了流控制。所謂的流控制就是使用不同的窗口大小發送數據包。發送端第一次以窗口大小（該窗口大小是根據鏈路帶寬的大小來決定的）發送數據包，接收端接收這些數據包，并返回確認應答包，告訴發送端自己下次希望收到的數據包是多少（新的窗口大小），發送端收到確認應答包以后，將以該窗口大小進行發送數據包。

TCP 流控制過程如圖所示。

為了方便講解，將上圖以發送端發送數據包進行分隔，將其分為3 部分進行講解。

第一部分

發送端根據當前鏈路帶寬大小決定發送數據包的窗口大小。這里，窗口大小為3，表示可以發送3 個數據包。因此發送端發送了3 個數據包，分別為1-1000、1001-2000和2001-3000。

接收端接收這些數據包，但是只能處理2 個數據包，第3 個數據包2001-3000 沒有被處理。因此返回確認應答包，設置窗口大小為2，告訴發送端自己現在只能處理2 個數據包，下一次請發送2 個數據包。

第二部分

發送端接收到確認應答包，查看到接收端返回窗口大小為2，知道接收端只處理了2 個數據包。發過去的第3 個數據包2001-3000 沒有被處理。這說明此時接收端只能處理2 個數據包，第3 個數據包還需要重新發送。

因此發送端發送2 個數據包2001-3000 和3001-4000。接收端收到這兩個數據包并進行了處理。此時，還是只能處理2 個窗口，繼續向發送端發送確認應答包，設置窗口為2，告訴發送端，下一個應該接收4001 的數據包。

第三部分

發送端接收到確認應答包，查看到接收端返回窗口大小為2。說明接收端接收了上次發送的2 個數據包。此時仍然可以處理2 個數據包，繼續發送數據包4001-5000 和5001-6000。

如果在接收端返回的確認應答包中，窗口設置為0，則表示現在不能接收任何數據。這時，發送端將不會再發送數據包，只有等待接收端發送窗口更新通知才可以繼續發送數據包。

如果這個更新通知在傳輸中丟失了，那么就可能導致無法繼續通信。為了避免這樣的情況發生，發送端會時不時地發送窗口探測包，該包僅有1個字節，用來獲取最新的窗口大小的信息。

原理如圖所示。

下面介紹上圖所示的獲取窗口更新數據包的原理。

1) 發送端發送數據。發送端以窗口大小為2，發送了2 個數據包，分別為4001-5000 和5001-6000。接收端接收到這些數據以后，緩沖區滿了，無法再處理數據，于是向發送端返回確認應答包，告訴它下一個接收6001 的數據，但是現在處理不了數據，先暫停發送數據，設置窗口大小為0。

2)?發送端暫停發送數據。發送端收到確認應答包，查看到下一次發送的是6001 的數據，但窗口大小為0，得知接收端此時無法處理數據。此時，不進行發送數據，進入等待狀態。

3)接收端發送窗口大小更新包。當接收端處理完發送端之前發來的數據包以后，將會給發送端發送一個窗口大小更新包，告訴它，此時可以發送的數據包的數量。這里設置窗口大小為3，表示此時可以處理3 個數據包，但是該數據包丟失了，沒有發送到發送端。

4)?發送端發送窗口探測包。由于窗口大小更新包丟失，發送端的等待時間超過了重發超時時間。此時，發送端向接收端發送一個窗口探測包，大小為1 字節，這里是6001。

5)?接收端再次發送窗口大小更新包。接收端收到發送端發來的探測包，再次發送窗口大小更新包，窗口大小為3。

6)?發送端發送數據。發送端接收到窗口大小更新包，查看到應該發的是6001 的數據包，窗口大小為3，可以發送3 個數據包。因此發送了數據包，分別為6001-7000、7001-8000和8001-9000。 10 網線“斷”了怎么辦 ? 對于TCP鏈接來說，他們之間一旦建立了連接，那么可以一直沒有消息通訊。TCP連接的雙方都沒有向對方發送數據，則在兩個TCP模塊之間不交換任何信息。

只要兩端的主機沒有被重啟，則連接依然保持建立，不管中間路由器可以崩潰和重啟，還是電話線被掛斷再連通。這意味著我們可以啟動一個客戶與服務器建立一個連接，然后離去數小時、數天、數個星期或者數月，而連接依然保持。

這對于客戶端來說，倒還好一點，畢竟不會有那么多的連接被占用，對于服務器來說，就是一個很糟糕的事情，這種連接無疑是一種僵尸連接，平白無辜的占用著服務器的資源，一旦這種連接非常多，服務器往往會因為連接數量的限制，導致沒有辦法接入新的客戶端。

這個時候，其實就需要一種定時探測對端連接是否還存活的機制存在，如此以來彼此都能知道對方的狀態，是否還能繼續使用。

這種機制，對于TCP來說，就是TCP的保活機制。TCP還設有一個保活計時器，服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75秒鐘發送一次，俗稱“心跳”。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

TCP具有保活器，但我建議在應用層最好還要設計一個“心跳”用來維持TCP連接，時間間隔可自行確定。再插一嘴，具有保活器的TCP就是長連接。

?

長連接：建立一個連接，多個請求復用這個連接，一直用同一個鏈接傳輸數據，最后再關閉連接。

短連接：建立一個連接，傳輸一個請求，發送完數據后就關閉連接。

?

TCP具有保活器優點：

1.在連接兩個端系統的網絡出現臨時故障的時候，保活選項會引起一個?實際上很好的連接終止。例如，如果在一個中間路由器崩潰并重新啟動時發送保活探查，那么TCP會認為客戶的主機已經崩潰，而實際上所發生的并非如此。

2.保活功能主要是為服務器應用程序提供的。服務器應用程序希望知道客戶主機是否崩潰，從而可以代表客戶使用資源，及時回收這些資源。

TCP具有保活器缺點：

保活并不是TCP規范中的一部分。HostRequirements RFC提供了3個不使用保活定時器的理由：

1)在出現短暫差錯的情況下，這可能會使一個非常好的連接釋放掉；

2）它們耗費不必要的帶寬；

3）在按分組計費的情況下會在互聯網上花掉更多的錢。