編者前言： 本文近9千文字，預計閱讀時間15分鐘，文章內容整理於網絡，僅供分享，更多好文請關註公眾號：一航代碼
公眾號閱讀鏈接：TCP是什麼？為什麼要三次握手四次揮手？ （本文近9千字，建議收藏）
一. 基本描述
1.TCP是什麼？
定義：傳輸控制協議（TCP，Transmission Control Protocol） 是一種面向連接的、可靠的、基於字節流的傳輸層通信協議，由IETF的RFC 793定義。
2.為什麼要定義TCP協議？
互聯網絡與單個網絡有很大的不同，因為互聯網絡的不同部分可能有截然不同的拓撲結構、帶寬、延遲、數據包大小和其他參數。TCP的設計目標是能夠動態地適應互聯網絡的這些特性，而且具備面對各種故障時的健壯性。
不同主機的應用層之間經常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機制，而是提供不可靠的包交換。
TCP協議是為瞭在不可靠的互聯網絡上提供可靠的端到端字節流而專門設計的一個傳輸協議。
3.數據流和數據包有什麼區別？
數據流（data stream），最初是通信領域使用的概念，代表傳輸中所使用的信息的數字編碼信號序列。然而，我們所提到的數據流概念與此不同。這個概念最初在1998年由Henzinger在文獻87中提出，他將數據流定義為 “隻能以事先規定好的順序被讀取一次的數據的一個序列”
數據包（data package），在包交換網絡裡，單個消息被劃分為多個數據塊，這些數據塊稱為數據包，它包含發送者和接收者的地址信息。這些包然後沿著不同的路徑在一個或多個網絡中傳輸，並且在目的地重新組合。理論上是一次收完所有數據並還回給應用層。
數據流可以分成多個有序的數據包。 流的特點並不是一次收完所有數據，比如，30個字節，第一次可能是收到6個，第二次3個，第三次11個。
二. 主要功能
應用層向TCP層發送用於網間傳輸的、用8位字節表示的數據流，TCP則把數據流分割成適當長度的報文段（最大傳輸段大小（MSS）通常受該計算機連接的網絡的數據鏈路層的最大傳送單元（MTU）限制）。之後TCP把數據包傳給IP層，由它來通過網絡將包傳送給接收端實體的TCP層。
TCP為瞭保證不發生丟包，就給每個包一個序號，同時序號也保證瞭傳送到接收端實體的包的按序接收。然後接收端實體對已成功收到的包發回一個相應的確認（ACK）；如果發送端實體在合理的往返時延（RTT）內未收到確認，那麼對應的數據包就被假設為已丟失將會被進行重傳。 TCP用一個校驗和函數來檢驗數據是否有錯誤；在發送和接收時都要計算校驗和。
- 在數據正確性與合法性上，TCP用一個校驗和函數來檢驗數據是否有錯誤，在發送和接收時都要計算校驗和；同時可以使用md5認證對數據進行加密。
- 在保證可靠性上，采用超時重傳和捎帶確認機制。
- 在流量控制上，采用滑動窗口協議，協議中規定，對於窗口內未經確認的分組需要重傳。
- 在擁塞控制上，采用廣受好評的TCP擁塞控制算法（也稱AIMD算法）。
三. 主要特點
TCP是一種面向廣域網的通信協議，目的是在跨越多個網絡通信時，為兩個通信端點之間提供一條具有下列特點的通信方式：
（1）基於流的方式；
（2）面向連接；
（3）可靠通信方式；
（4）在網絡狀況不佳的時候盡量降低系統由於重傳帶來的帶寬開銷；
（5）通信連接維護是面向通信的兩個端點的，而不考慮中間網段和節點。
為滿足TCP協議的這些特點，TCP協議做瞭如下的規定：
①數據分片：在發送端對用戶數據進行分片，在接收端進行重組，由TCP確定分片的大小並控制分片和重組；
②到達確認：接收端接收到分片數據時，根據分片數據序號向發送端發送一個確認；
③超時重發：發送方在發送分片時啟動超時定時器，如果在定時器超時之後沒有收到相應的確認，重發分片；
④滑動窗口：TCP連接每一方的接收緩沖空間大小都固定，接收端隻允許另一端發送接收端緩沖區所能接納的數據，TCP在滑動窗口的基礎上提供流量控制，防止較快主機致使較慢主機的緩沖區溢出；
⑤失序處理：作為IP數據報來傳輸的TCP分片到達時可能會失序，TCP將對收到的數據進行重新排序，將收到的數據以正確的順序交給應用層；
⑥重復處理：作為IP數據報來傳輸的TCP分片會發生重復，TCP的接收端必須丟棄重復的數據；
⑦數據校驗：TCP將保持它首部和數據的檢驗和，這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到分片的檢驗和有差錯，TCP將丟棄這個分片，並不確認收到此報文段導致對端超時並重發。
四. TCP報文段的首部格式
源端口（Source Port）：占2個字節。
目的端口（Destination Port）：占2個字節。
序號（Sequence Number）seq：占4個字節，用來標記數據段的順序，TCP把連接中發送的所有數據字節都編上一個序號，第一個字節的編號由本地隨機產生；給字節編上序號後，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節的數據編號。
確認號（Acknowledgment Number）ack：占4個字節，期待收到對方下一個報文段的第一個數據字節的序號；序列號表示報文段攜帶數據的第一個字節的編號；而確認號指的是期望接收到下一個字節的編號；因此當前報文段最後一個字節的編號+1即為確認號。
數據偏移（Data Offset）：占4位，該字段的值是TCP首部（包括選項）長度除以4。
保留(Reserved)：占4位，這些位必須是0。為瞭將來定義新的用途所保留，其中RFC3540將Reserved字段中的最後一位定義為Nonce標志。
6個標志位： 緊急指針（URG）：占1位，僅當URG=1時，緊急指針字段才有效。
確認（ACK）：占1位，僅當ACK=1時，確認號字段才有效。ACK=0時，確認號無效。 Push功能（PSH）：占1位，僅當PSH=1時，表示這個包是帶數據的，發送端告訴接收端，這個數據包以及以前接收到的數據包需要交給應用層立即進行處理。
復位（RST）：占1位，僅當RST=1時，用於復位因某種原因引起出現的錯誤連接，也用來拒絕非法數據和請求。如果接收到RST位時候，通常發生瞭某些錯誤。
同步（SYN）：占1位，連接建立時用於同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標志位隻有在TCP建產連接時才會被置1，握手完成後SYN標志位被置0。
終止（FIN）：占1位，用來釋放一個連接。FIN=1表示：此報文段的發送方的數據已經發送完畢，並要求釋放運輸連接。
窗口（Windows）：占2個字節，表示接收緩沖區的空閑空間，用來告訴TCP連接對端自己能夠接收的最大數據長度。
校驗和（Checksum）：占2個字節，目的是為瞭發現TCP首部和數據在發送端到接收端之間發生的任何改動。如果接收方檢測到檢驗和有差錯，則TCP段會被直接丟棄。
緊急指針（Urgent Pointer）：占2個字節，在URG標志設置瞭時才有效。與序號字段的值相加後表示最後一個緊急數據的下一字節的序號，可以說這個字段是緊急指針相對當前序號的偏移。
選項部分（Options）：長度不定，最長報文大小，接收方或發送方所能接受的最大報文段的長度。通常連接方都在通信的第一個報文段中指明這個選項，但長度必須以是32bits的整數倍。常見的選項包括MSS、SACK、Timestamp等等。
填充（Padding）：顧名思義，選項部分如果不是32位的整數倍，要添加填充位，加入額外的零，保證TCP頭是32的整數倍。
數據部分（Data）： TCP 報文段中的數據部分是可選的。在一個連接建立和一個連接終止時，雙方交換的報文段僅有 TCP 首部。如果一方沒有數據要發送，也使用沒有任何數據的首部來確認收到的數據。在處理超時的許多情況中，也會發送不帶任何數據的報文段。、
一個完整的TCP首部展示：
五. 工作方式 – 建立連接-三次握手：
TCP是因特網中的傳輸層協議，使用三次握手協議建立連接。當主動方發出SYN連接請求後，等待對方回答SYN+ACK，並最終對對方的 SYN 執行 ACK 確認。這種建立連接的方法可以防止產生錯誤的連接，TCP使用的流量控制協議是可變大小的滑動窗口協議。
TCP三次握手的過程如下：
1. 客戶端發送SYN（seq=x）報文，給服務器端，進入SYN_SEND狀態。（該數據包中，初始序列號（ISN） 是客戶端隨機產生的一個值，即x，確認號ACK=0；）
2. 服務器端收到SYN報文，回應一個SYN （seq=y）ACK（ACK=x+1）報文，進入SYN_RECV狀態。（該數據包中，初始序列號（ISN） 是服務器隨機產生的一個值，即y，確認號ACK是客戶端的初始序列號加上1，即x+1）
3. 客戶端收到服務器端的SYN報文，回應一個ACK（ACK=y+1）報文，進入Established狀態。（該數據包中，序列號是上一個同步請求數據包中的確認號值加上1，即x+1，確認號是服務器的初始序列號加上1，即y+1。）
三次握手完成，TCP客戶端和服務器端成功地建立連接，可以開始傳輸數據瞭。
連接終止-四次揮手：
建立一個連接需要三次握手，而終止一個連接要經過四次握手，這是由TCP的半關閉（half-close）造成的。具體過程如下圖所示。
（1） 某個應用進程首先調用close，稱該端執行“主動關閉”（active close）。該端的TCP於是發送一個FIN分節，表示數據發送完畢。
（2） 接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP確認。
註意：FIN的接收也作為一個文件結束符（end-of-file）傳遞給接收端應用進程，放在已排隊等候該應用進程接收的任何其他數據之後，因為，FIN的接收意味著接收端應用進程在相應連接上再無額外數據可接收。
（3） 一段時間後，接收到這個文件結束符的應用進程將調用close關閉它的套接字。這導致它的TCP也發送一個FIN。
（4） 接收這個最終FIN的原發送端TCP（即執行主動關閉的那一端）確認這個FIN。既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節。
註意：
（1）“通常”是指，某些情況下，步驟1的FIN隨數據一起發送，另外，步驟2和步驟3發送的分節都出自執行被動關閉那一端，有可能被合並成一個分節。
（2）在步驟2與步驟3之間，從執行被動關閉一端到執行主動關閉一端流動數據是可能的，這稱為“半關閉”（half-close）。
（3）當一個Unix進程無論自願地（調用exit或從main函數返回）還是非自願地（收到一個終止本進程的信號）終止時，所有打開的描述符都被關閉，這也導致仍然打開的任何TCP連接上也發出一個FIN。
無論是客戶還是服務器，任何一端都可以執行主動關閉。通常情況是，客戶執行主動關閉，但是某些協議，例如，HTTP/1.0卻由服務器執行主動關閉。
六. 為什麼要三次握手和四次揮手？
1.為什麼要三次握手？兩次可以嗎？
目的：為瞭防止已失效的連接請求報文段突然又傳送到瞭服務端，因而產生錯誤。主要防止資源的浪費。
具體過程： 當客戶端發出第一個連接請求報文段時並沒有丟失，而是在某個網絡節點出現瞭長時間的滯留，以至於延誤瞭連接請求在某個時間之後才到達服務器。這應該是一個早已失效的報文段。但是服務器在收到此失效的連接請求報文段後，以為是客戶端的一個新請求，於是就向客戶端發出瞭確認報文段，同意建立連接。假設不采用三次握手，而是兩次，那麼隻要服務器發出確認後，新的連接就可以建立瞭。但是由於客戶端沒有發出建立連接的請求，因此不會管服務器的確認，也不會向服務器發送數據，但服務器卻以為新的運輸連接已經建立，一直在等待，所以，服務器的資源就白白浪費掉瞭。
2.如果在TCP第三次握手中的報文段丟失瞭會出現什麼情況？
客戶端會認為此連接已建立，如果客戶端向服務器發送數據，服務器將以RST包響應，這樣就能感知到服務器的錯誤瞭。
3.為什麼要四次揮手？ 目的：為瞭保證在最後斷開的時候，主動方能夠發送最後一個ACK報文段能夠被被動方接收到。
反過來說：防止已經失效的連接請求報文突然又傳送到瞭服務器，從而產生錯誤。
如果被動方在收到主動方給它的斷開連接的請求之後，回應完主動方就直接斷開連接的話，若主動方沒有收到回應就無法進入CLOSE狀態，所以被動方要等待兩個最長報文段壽命的時間（2MSL），以便於主動方沒有收到請求之後重新發送請求。
防止“已失效的連接請求報文”出現在連接中，在釋放連接的過程中會有一些無效的滯留報文，這些報文在經過2MSL的時間內就可以發送到目的地，不會滯留在網絡中。這樣就可以避免在下一個連接中出現上一個連接的滯留報文瞭。
當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有數據再發送給被動方瞭。但未必被動方所有的數據都完整的發送給瞭主動方，所以被動方不會馬上斷開連接，它可能還需要發送一些數據給主動方後，再發送FIN報文給主動方，告訴主動方同意關閉連接，所以這裡的ACK報文和FIN報文多數情況下都是分開發送的。
七. 常見問題
1.描述一下或者畫一下三次握手過程。
2.描述一下或者畫一下四次握手過程。
3.為什麼建立連接是三次握手？兩次可以嗎？四次可以嗎？（口述版打比方，A，B連接，如果是兩次會怎麼樣，如果是三次會怎麼樣，如果是四次會怎麼樣）
答： 兩次不可以，四次可以，但是沒有必要。
這主要是為瞭防止已失效的請求連接報文忽然又傳送到瞭，從而產生錯誤。
思路一： 假定A向B發送一個連接請求，由於一些原因，導致A發出的連接請求在一個網絡節點逗留瞭比較多的時間。此時A會將此連接請求作為無效處理又重新向B發起瞭一次新的連接請求，B正常收到此連接請求後建立瞭連接，數據傳輸完成後釋放瞭連接。如果此時A發出的第一次請求又到達瞭B，B會以為A又發起瞭一次連接請求，如果是兩次握手：此時連接就建立瞭，B會一直等待A發送數據，從而白白浪費B的資源。如果是三次握手：由於A沒有發起連接請求，也就不會理會B的連接響應，B沒有收到A的確認連接，就會關閉掉本次連接。
思路二：
第一次握手： Client什麼都確認不瞭，Server確認瞭對方發送正常。
第二次握手：
Client確認：自己發送/接收正常，對方發送/接收正常；
Server確認：自己接收正常 ，對方發送正常。
第三次握手：
Client確認：自己發送/接收正常，對方發送/接收正常；
Server確認：自己發送/接收正常 ，對方發送/接收正常。
所以通過三次握手確認雙方收發功能都正常，四次也可以但是顯得比較多餘。
4.為什麼建立連接是三次握手，斷開連接卻是四次揮手呢？（分成兩個方面回答）
答：建立連接的時候， 服務器在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裡發送給客戶端。
而斷開連接的時候，服務器收到對方的FIN報文時，僅僅表示對方不再發送數據瞭但是還能接收數據，而自己也未必全部數據都發送給對方瞭，所以己方可以立即關閉，也可以發送一些數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多瞭一次。
5.如果已經建立瞭連接，但是客戶端突然出現故障瞭怎麼辦？
答： TCP還設有一個保活計時器，顯然，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出瞭故障，接著就關閉連接。
6.為什麼客戶端最後還要等待2MSL？（為什麼需要TIME_WAIT狀態？）
答：最長報文段壽命的時間（Maximum Segment Lifetime，MSL），TCP允許不同的實現可以設置不同的MSL值。
第一，保證客戶端發送的最後一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失，站在服務器的角度看來，我已經發送瞭FIN+ACK報文請求斷開瞭，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，於是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，並且會重啟2MSL計時器。
第二，防止類似與“三次握手”中提到瞭的“已經失效的連接請求報文段”出現在本連接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可以使本連接持續的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現舊連接的請求報文。
7.描述一下超時重傳和快速重傳技術。
答：
超時重傳：當超時時間到達時，發送方還未收到對端的ACK確認，就重傳該數據包。
快速重傳：當後面的序號先到達，如接收方接收到瞭1、 3、 4，而2沒有收到，就會立即向發送方重復發送三次ACK=2的確認請求重傳。如果發送方連續收到3個相同序號的ACK，就重傳該數據包。而不用等待超時。
8.第三次握手可以攜帶數據嗎？為什麼？
答：可以，能夠發出第三次握手報文的客戶端，一定接收到瞭第二次握手的報文，因為偽造IP的主機是不會收到第二次報文的。所以能夠發出第三次握手報文的客戶端是合法的客戶端。盡管服務器端的狀態還沒有切換為“established”，接收到第三次握手報文的瞬間，狀態就會切換為“established”，報文中攜帶的數據按照正常的流程繼續進行就可以瞭。
9.TCP和UDP的區別：
答：
TCP是有連接的，兩臺主機在進行數據交互之前必須先通過三次握手建立連接；而UDP是無連接的，沒有建立連接這個過程。
TCP是可靠的傳輸，TCP協議通過確認和重傳機制來保證數據傳輸的可靠性；而UDP是不可靠的傳輸。
TCP還提供瞭擁塞控制、滑動窗口等機制來保證傳輸的質量，而UDP都沒有。
TCP是基於字節流的，將數據看做無結構的字節流進行傳輸，當應用程序交給TCP的數據長度太長，超過MSS時，TCP就會對數據進行分段，因此TCP的數據是無邊界的；而UDP是面向報文的，無論應用程序交給UDP層多長的報文，UDP都不會對數據報進行任何拆分等處理，因此UDP保留瞭應用層數據的邊界 。
10.SYN Flood攻擊（DOS攻擊的一種）原理：
答：TCP連接的三次握手中，假設一個用戶向服務器發送瞭SYN報文後突然死機或掉線，那麼服務器在發出SYN+ACK應答報文後是無法收到客戶端的ACK報文的(第三次握手無法完成)，這種情況下服務器端一般會重試(再次發送SYN+ACK給客戶端)並等待一段時間後丟棄這個未完成的連接。這段時間的長度我們稱為SYN Timeout，一般來說這個時間是分鐘的數量級(大約為30秒~2分鐘)；一個用戶出現異常導致服務器的一個線程等待1分鐘並不是什麼很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況(偽造IP地址)，服務器端將為瞭維護一個非常大的半連接列表而消耗非常多的資源。即使是簡單的保存並遍歷也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果服務器的TCP/IP棧不夠強大，最後的結果往往是堆棧溢出崩潰—— 即使服務器端的系統足夠強大，服務器端也將忙於處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求(畢竟客戶端的正常請求比率非常之小)，此時從正常客戶的角度看來，服務器失去響應，這種情況就稱作：服務器端受到瞭SYN Flood攻擊(SYN洪水攻擊)。
防范措施：①降低SYN timeout時間，使得主機盡快釋放半連接的占用。②采用SYN cookie設置，如果短時間內連續收到某個IP的重復SYN請求，則認為受到瞭該IP的攻擊，丟棄來自該IP的後續請求報文。③在網關處設置過濾，拒絕將一個源IP地址不屬於其來源子網的包進行更遠的路由。
11.有哪些應用層協議是基於TCP的，哪些是基於UDP的：
答：
- TCP：FTP、HTTP、Telnet、SMTP、POP3、HTTPS
- UDP：DNS、SNMP、NFS
12.簡述一下滑動窗口協議，它有什麼意義？
答：首先明確：TCP滑動窗口分為接收窗口，發送窗口。
滑動窗口協議是傳輸層進行流控的一種措施，接收方通過通告發送方自己的窗口大小，從而控制發送方的發送速度，從而達到防止發送方發送速度過快而導致自己被淹沒的目的。 對ACK的再認識，ack通常被理解為收到數據後給出的一個確認ACK，ACK包含兩個非常重要的信息： 一是期望接收到的下一字節的序號n，該n代表接收方已經接收到瞭前n-1字節數據，此時如果接收方收到第n+1字節數據而不是第n字節數據，接收方是不會發送序號為n+2的ACK的。舉個例子，假如接收端收到1-1024字節，它會發送一個確認號為1025的ACK,但是接下來收到的是2049-3072，它是不會發送確認號為3072的ACK,而依舊發送1025的ACK。 二是當前的窗口大小m，如此發送方在接收到ACK包含的這兩個數據後就可以計算出還可以發送多少字節的數據給對方，假定當前發送方已發送到第x字節，則可以發送的字節數就是y=m-(x-n).這就是滑動窗口控制流量的基本原理。
重點：發送方根據收到ACK當中的期望收到的下一個字節的序號n以及窗口m，還有當前已經發送的字節序號x，算出還可以發送的字節數。
發送端窗口的第一個字節序號一定是ACK中期望收到的下一個字節序號，比如下圖：
上圖52 53 54 55 字節都是可以新發送的字節序 接受端窗口的第一個字節序之前一定是已經完全接收的，後面窗口裡面的數據都是希望接受的，窗口後面的數據都是不希望接受的。
TCP的滑動窗口分為接收窗口和發送窗口，不分析這兩種窗口就討論是不妥當的。 TCP的滑動窗口主要有兩個作用：一是提供TCP的可靠性；二是提供TCP的流控特性。 同時滑動窗口機制還體現瞭TCP面向字節流的設計思路。TCP 段中窗口的相關字段。
TCP的Window是一個16bit位字段，它代表的是窗口的字節容量，也就是TCP的標準窗口最大為2^16-1=65535個字節。
另外在TCP的選項字段中還包含瞭一個TCP窗口擴大因子，option-kind為3，option-length為3個字節，option-data取值范圍0-14。窗口擴大因子用來擴大TCP窗口，可把原來16bit的窗口，擴大為31bit。
滑動窗口基本原理：
1）對於TCP會話的發送方，任何時候在其發送緩存內的數據都可以分為4類，“已經發送並得到對端ACK的”，“已經發送但還未收到對端ACK的”，“未發送但對端允許發送的”，“未發送且對端不允許發送”。“已經發送但還未收到對端ACK的”和“未發送但對端允許發送的”這兩部分數據稱之為發送窗口。
當收到接收方新的ACK對於發送窗口中後續字節的確認時，窗口滑動，滑動原理如下圖。
當收到ACK=36時窗口滑動。
2）對於TCP的接收方，在某一時刻在它的接收緩存內存在3種。“已接收”，“未接收準備接收”，“未接收並未準備接收”（由於ACK直接由TCP協議棧回復，默認無應用延遲，不存在“已接收未回復ACK”）。其中“未接收準備接收”稱之為接收窗口。
發送窗口與接收窗口關系：
TCP是全雙工的協議，會話的雙方都可以同時接收、發送數據。TCP會話的雙方都各自維護一個“發送窗口”和一個“接收窗口”。其中各自的“接收窗口”大小取決於應用、系統、硬件的限制（TCP傳輸速率不能大於應用的數據處理速率）。各自的“發送窗口”則要求取決於對端通告的“接收窗口”，要求相同。
滑動窗口實現面向流的可靠性：
1）最基本的傳輸可靠性來源於“確認重傳”機制。
2）TCP的滑動窗口的可靠性也是建立在“確認重傳”基礎上的。
3）發送窗口隻有收到對端對於本段發送窗口內字節的ACK確認，才會移動發送窗口的左邊界。
4）接收窗口隻有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有字節未接收但收到後面字節的情況下，窗口不會移動，並不對後續字節確認。以此確保對端會對這些數據重傳。
滑動窗口的流控特性：
TCP的滑動窗口是動態的，我們可以想象成小學常見的一個數學題，一個水池，體積V，每小時進水量V1，出水量V2。當水池滿瞭就不允許再註入瞭，如果有個液壓系統控制水池大小，那麼就可以控制水的註入速率和量。這樣的水池就類似TCP的窗口。應用根據自身的處理能力變化，通過本端TCP接收窗口大小控制來對對對端的發送窗口流量限制。
應用程序在需要（如內存不足）時，通過API通知TCP協議棧縮小TCP的接收窗口。然後TCP協議棧在下個段發送時包含新的窗口大小通知給對端，對端按通知的窗口來改變發送窗口，以此達到減緩發送速率的目的。
