网络协议 8 - TCP协议（上）：性恶就要套路深
系列文章：
????上次說了“性本善”的 UDP 協議，這哥們秉承“網之初，性本善，不丟包，不亂序”的原則，徜徉在網絡世界中。
????與之相對應的，TCP 就像是老大哥一樣，了解了社會的殘酷，變得復雜而成熟，秉承“性惡論”。它認為網絡環境是惡劣的，丟包、亂序、重傳、擁塞都是常有的事兒，一言不合可能就會丟包，送達不了，所以從算法層面來保證可靠性。
TCP 包頭格式
????老規矩，咱們先來看看 TCP 頭的格式。
????從上面這個圖可以看出，它比 UDP 要復雜的多。而復雜的地方，也正是它為了解決 UDP 存在的問題所必需的字段。
????首先，源端口號和目標端口號是兩者都有，不可缺少的字段。
????接下來是包的序號。給包編號就是為了解決亂序的問題。老大哥做事，穩重為主，一件件來，面臨再復雜的情況，也臨危不亂。
????除了發送端需要給包編號外，接收方也會回復確認序號。做事靠譜，答應了就要做到，暫時做不到也要給個回復。
????這里要注意的是，TCP 是個老大哥沒錯，但不能說他一定會保證傳輸準確無誤的完成。從 IP 層面來講，如果網絡的確那么差，是沒有任何可靠性保證的，即使 TCP 老大哥再穩，他也管不了 IP 層丟包，他只能盡可能的保證在他的層面上的可靠性。
然后是一些狀態位。有以下常見狀態位：
- SYN（Synchronize Sequence Numbers，同步序列編號）：發起一個連接
- ACK（Acknowledgement，確認字符）：回復
- RST（Connection reset）：重新連接
- FIN：結束連接
????從這些狀態位就可以看出，TCP 基于“性惡論”，警覺性就很高，不像 UDP 和小朋友似的，隨便一個不認識的小朋友都能玩到一起，他與別人的信任要經過多次交互才能建立。
????還有一個窗口大小。這個是 TCP 用來進行流量控制的。通信雙方各聲明一個窗口，標識自己當前的處理能力，讓發送端別發送的太快，要不然撐死接收端。也不能發送的太慢，要不然就餓死接收端了。
根據上述對 TCP 頭的分析，我們知道對于 TCP 協議要重點關注以下幾個問題：
- 順序問題，穩重不亂；
- 丟包問題，承諾靠譜；
- 連接偉豪，有始有終；
- 流量控制，把握分寸；
- 擁塞控制，知進知退。
TCP 的三次握手
????了解完 TCP 頭，我們就來看下 TCP 建立連接的過程，這就是著名的“三次握手”。
三次握手，過程是這樣子的：
- A：你好，我是 A（SYN）。
- B：你好 A，我是 B（SYN，ACK）。
- A：你好 B（ACK 的 ACK）。
????著重記憶上述過程，后續很多分析都是基于這個過程來的。
????記得剛接觸三次握手的時候，就一直很納悶，為啥一定要三次？兩次不行嗎？四次不行嗎？然后很多人就解釋，如果是兩次，就怎樣怎樣，四次，又怎樣怎樣？但這其實都是從結果推原因，沒有說明本質。
????我們應該知道，握手是為了建立穩定的連接，這個是最終目的。而要達到這個目的，就要通信雙方的交互形成一個確認的閉環。
????拿上述 A、B 通信的例子來看，A 給 B 發信息，B 要告訴 A 他收到信息了。這時候，算是一個確認閉環嗎？明顯不是，因為 B 沒有收到來自 A 的確認信息。
????所以，要達到我們上述的目標，還要 A 給 B 一個確認信息，這樣就形成了一個確認閉環。
????A 給 B 的確認信息發出后，遇到網絡不好的情況，也會出現丟包的情況。按理來說，還應該有個回應，但是，我們發現，好像這樣下去就沒玩沒了啦。
????所以，我們說，只要通信雙方形成一個確認閉環后，就認為連接已建立。一旦連接建立，A 會馬上發送數據，而 A 發送數據，后續的很多問題都得到了解決。
????例如 A 發給 B 的確認消息丟了，當 A 后續發送的數據到達的時候，B 可以認為這個連接已經建立。如果 B 直接掛了，A 發送的數據就會報錯，說 B 不可達，這樣，A 也知道 B 出事情了。
????三次握手除了通信雙方建立連接外，主要還是為了溝通 TCP 包的序號問題。
????A 要告訴 B，我發起的包的序號起始是從哪個號開始的，B 也要告訴 A，B 發起的包的序號的起始號。
????TCP 包的序號是會隨時間變化的，可以看成一個 32 位的計數器，每 4ms 加一。計算一下，這樣到出現重復號，需要 4 個多小時。但是，4 個小時后，還沒到達目的地的包早就死翹翹了。這是因為 IP 包頭里的 TTL（生存時間）。
????為什么序號不能從 1 開始呢？因為這樣會很容易出現沖突。
????例如，A 連上 B 之后，發送了 1、2、3 三個包，但是發送 3 的時候，中間丟了，或者繞路了，于是重新發送，后來 A 掉線了，重新連上 B 后，序號又從 1 開始，然后發送 2，但是壓根沒想發送 3，而如果上次繞路的那個 3 剛好又回來了，發給了 B ，B 自然就認為，這就是下一包，于是發生了錯誤。
????就這樣，雙方歷經千辛萬苦，終于建立了連接。前面也說過，為了維護這個連接，雙方都要維護一個狀態機，在連接建立的過程中，雙方的狀態變化時序圖就像下面這樣：
整體過程是：
TCP 的四次揮手
????說完了連接，接下來就來了解下 TCP 的“再見模式”。這也常被稱為四次揮手。
還拿 A 和 B 舉例，揮手過程：
????這樣這個連接就關閉了。看起來過程很順利，是的，這是通信雙方“和平分手”的場面。
????A 開始說“不玩了”，B 說“知道了”，這個回合，是沒什么問題的，因為在此之前，雙方還處于合作的狀態。
????如果 A 說“不玩了”，沒有收到回復，那么 A 會重新發送“不玩了”。但是這個回合結束之后，就很可能出現異常情況了，因為有一方率先撕破臉。這種撕破臉有兩種情況。
????一種情況是，A 說完“不玩了”之后，A 直接跑路，這是會有問題的，因為 B 還沒有發起結束，而如果 A 直接跑路，B 就算發起結束，也得不到回答，B 就就不知道該怎么辦了。
????另一種情況是，A 說完“不玩了”，B 直接跑路。這樣也是有問題的，因為 A 不知道 B 是還有事情要處理，還是過一會發送結束。
????為了解決這些問題，TCP 專門設計了幾個狀態來處理這些問題。接下來，我們就來看看斷開連接時的狀態時序圖。
整體過程是：
????最后一個步驟里，如果 A 直接跑路了，也會出現問題。因為 A 的最后一個回復，B 如果沒有收到的話就會重復第 4 步，但是因為 A 已經跑路了，所以 B 會一直重復第 4 步。
????因此，TCP 協議要求 A 最后要等待一段時間，這個等待時間是 TIME_WAIT，這個時間要足夠長，長到如果 B 沒收到 A 的回復，B 重發給 A，A 的回復要有足夠時間到達 B。
????A 直接跑路還有一個問題是，A 的端口就空出來了，但是 B 不知道，B 原來發過的很多包可能還在路上，如果 A 的端口被新的應用占用了，這個新的應用會受到上個連接中 B 發過來的包，雖然序列號是重新生成的，但是這里會有一個雙保險，防止產生混亂。因此也需要 A 等待足夠長的時間，等到 B 發送的所有未到的包都“死翹翹”，再空出端口。
????這個等待的時間設為 2MSL，MSL 是 Maximum Segment Lifetime，即報文最大生存時間。它是任何報文再網絡上存在的最長時間，超過這個時間的報文就會被丟棄。
????因為 TCP 報文基于 IP 協議，而 IP 頭中有一個 TTL 域，是 IP 數據報可以經過的最大路有數，每經過一個處理他的路由器，此值就減 1，當此值為 0 時，數據報就被丟棄，同時發送 ICMP 報文通知源主機。協議規定 MSL 為 2 分鐘，實際應用中常用的是 30 秒、1分鐘和 2 分鐘等。
????還有一種異常情況，B 超過了 2MS 的時間，依然沒有收到它發的 FIN 的 ACK。按照 TCP 的原理，B 當然還會重發 FIN，這個時候 A 再收到這個包之后，就表示，我已經等你這么久，算是仁至義盡了，再來的數據包我就不認了，于是直接發送 RST，這樣 B 就知道 A 跑路了。
TCP 狀態機
????將連接建立和連接斷開的兩個時序狀態圖綜合起來，就是著名的 TCP 狀態機。我們可以將這個狀態機和時序狀態機對照看，就會更加明了。
圖中加黑加粗部分，是上面說到的主要流程，相關說明：
- 阿拉伯數字序號：建立連接順序；
- 大寫中文數字序號：斷開連接順序；
- 加粗實線：客戶端 A 的狀態變遷；
- 加粗虛線：服務端 B 的狀態變遷；
總結
- TCP 包頭很復雜，主要關注 5 個問題。順序問題、丟包問題、連接維護、流量控制、擁塞控制；
- 建立連接三次握手，斷開連接四次揮手，狀態圖要牢記。
參考：
轉載于:https://www.cnblogs.com/lonelyxmas/p/10788723.html
總結
以上是生活随笔為你收集整理的网络协议 8 - TCP协议（上）：性恶就要套路深的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Oracle-洛总脚本--查询相关慢SQ
- 下一篇： HTTP协议1之协议详解--转