?個人主頁：bit me??
?當前專欄：Java EE初階??

??一. 確認應答

TCP 誕生的初衷就是可靠傳輸

可靠傳輸是 TCP 最核心的部分，TCP 內(nèi)部的很多機制，都是在保證可靠傳輸。（可靠傳輸是發(fā)了之后我知道對方收沒收到，而不是 100% 能收到(可能沒收到 --> 網(wǎng)線斷了)）

可靠性如何保證的呢？確認應答 ?。?br> ?
此處說的 “可靠性” 和 “安全性” 沒有任何關(guān)系，千萬不能說 TCP 這個可靠的通信協(xié)議，說成 “安全的” 通信協(xié)議。安全性：指的是，數(shù)據(jù)被截獲之后，不容易被理解內(nèi)部的意思或者被篡改，通過加密來做到的。

確認應答，要針對數(shù)據(jù)進行編號，然后才能明確，應答報文是在應答哪個數(shù)據(jù)，應對了網(wǎng)絡(luò)傳輸?shù)?“后發(fā)先至”。

TCP 就引入了 “序號”

32 位序號給發(fā)送的每個數(shù)據(jù)，都進行編號了，32 位確認序號表示：如果當前報文是一個普通的報文，確認序號不生效；如果當前報文是應答報文，確認序號就表示應答的是哪個普通報文。

報文的字節(jié)：

由于 TCP 是面向字節(jié)流的，編號的時候，也不是說按照 “條” 的方式編的，而是按照字節(jié)來編。

這一口氣發(fā)了 1000 個字節(jié)的數(shù)據(jù)（一個 TCP 的數(shù)據(jù)報，長度是 1000，序號是 1），TCP 報頭中的序號是 1 ，整個報文長度是 1000，就相當于把序號 1 - 1000 的這些字節(jié)都發(fā)過來了。

應答報文中的確認序號，就是 1001。應答報文，可以視為只有 TCP 報頭，沒有載荷，在這個報頭里，確認序號字段，填寫了 1001 ，意思就是 < 1001 的數(shù)據(jù)，B 已經(jīng)收到了，接下來 A 就要從 1001 開始往后發(fā)送?。?！

此處有人會問，TCP 不是傳輸?shù)淖止?jié)流嗎？怎么傳輸?shù)臄?shù)據(jù)報？
?
例如在我們的 UDP 中：

B 這邊調(diào)用一個 recv 方法：

• 第一次調(diào)用讀取的肯定是 1111
• 第二次調(diào)用讀取的肯定是 2222
• 第三次調(diào)用讀取的肯定是 3333

?
每次調(diào)用 recv 方法就是從接收緩沖區(qū)里取走一個數(shù)據(jù)，UDP 的接收緩沖區(qū)，相當于一個鏈表，里面有三個節(jié)點，每次讀，都以一個節(jié)點為單位
?
這就是面向數(shù)據(jù)報

---

在 TCP 中：

用 InputStream.read(buffer)

• byte[1] buffer 讀出來的就是 1
• byte[3] buffer 讀出來的就是 111
• byte[5] buffer 讀出來的就是 11112
• byte[7] buffer 讀出來的就是 1111222

?
TCP 的接收緩沖區(qū)，更像是一個數(shù)組，若干個 TCP 數(shù)據(jù)報的載荷會一直追加到這個數(shù)組里，融為一體。
?
這就是面向字節(jié)流

---

面向字節(jié)流和面向數(shù)據(jù)報，主要是影響代碼咋寫(影響著應用層！！！)，而在傳輸層這里，仍然是一個一個報文來傳輸數(shù)據(jù)的。（傳輸了報文，不意味著 “面向數(shù)據(jù)報”，兩個不同的概念）

如何區(qū)分，一個報文是普通報文還是應答報文呢？

在 TCP 報頭里有六個非常重要的 bit 位，其中第二位 ACK 就表示是否是應答報文

• ACK 為 0 表示不是應答報文??！
• ACK 為 1 表示是應答報文?。?！

這六個 bit 位的各個含義：

• URG：緊急指針是否有效
• ACK：確認號是否有效
• PSH：提示接收端應用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走
• RST：對方要求重新建立連接；我們把攜帶RST標識的稱為復位報文段
• SYN：請求建立連接；我們把攜帶SYN標識的稱為同步報文段
• FIN：通知對方，本端要關(guān)閉了，我們稱攜帶FIN標識的為結(jié)束報文段

在確認應答的情況下，如果收到了 ACK 就好辦，如果沒收到呢？還需要通過其他途徑來處理！

??二. 超時重傳

ACK 沒有收到的時候，不應立即放棄，需要重新再發(fā)一遍。

網(wǎng)絡(luò)的環(huán)境是非常復雜的，尤其是有時候網(wǎng)絡(luò)會擁堵，擁堵就可能導致丟包

丟包是 “無差別” 的，任何一個數(shù)據(jù)報，都有可能會丟包。發(fā)送的普通的報文是可能丟的；發(fā)送的 ACK 也是可能丟的。

業(yè)務(wù)數(shù)據(jù)丟了：

ACK 丟了：

業(yè)務(wù)數(shù)據(jù)已經(jīng)到了主機 B 了，反饋的 ACK 沒有回過去，發(fā)送方等待了一會兒之后，就觸發(fā)了重傳。對于發(fā)送方來說，無法區(qū)分是業(yè)務(wù)數(shù)據(jù)丟了還是 ACK 丟了，因此發(fā)送方能做的就是達到一定時間之后，就重傳。

這個情況下，主機 B 收到了兩份 1 - 1000 這個數(shù)據(jù)！此時，如果在應用層調(diào)用 read ，讀出來的是 1 份數(shù)據(jù)好，還是讀出兩份一樣的數(shù)據(jù)好？
?
當然是一份數(shù)據(jù)好，畢竟兩份數(shù)據(jù)不是咱想要的。

那么 TCP 協(xié)議需要能夠識別出那些包是重復的包，并且把重復的丟棄掉。這時候我們可以利用前面提到的序列號，就可以很容易做到去重的效果。B 知道自己都收到了哪些數(shù)據(jù)，當發(fā)現(xiàn)又收到了一份之前的數(shù)據(jù)，就會自動丟棄，保證應用層讀到的數(shù)據(jù)是不重復的。

但是在數(shù)據(jù)轉(zhuǎn)發(fā)過程中，可能會發(fā)生很多種可能：

• 本來是 1 - 1000 -> 1 - 500
• 本來是 1 - 1000 -> 1 - 2000
• 本來是 1 - 1000 -> 1 - 1000（內(nèi)容變了）

數(shù)據(jù)發(fā)送出去之后，就會同時發(fā)送數(shù)據(jù)內(nèi)容 + 校驗和，數(shù)據(jù)接收方會按照同樣的規(guī)則，再算一次校驗和，并且和收到的校驗和作比較。在任意傳輸過程中，某個中間節(jié)點，發(fā)現(xiàn)校驗和不對，都會主動觸發(fā)丟包。

內(nèi)容變了 / 長度變了 校驗和也就變了，就可以通過校驗和知道這里的變化，發(fā)現(xiàn)數(shù)據(jù)有問題就丟棄！

超時重傳機制下，發(fā)一個數(shù)據(jù)，丟包了，重傳數(shù)據(jù)，是否還會丟包呢？當然會！比如我們概率來算，丟包幾率為 10% ，連續(xù)兩次丟包概率就是 10% * 10% = 1%。

丟包操作，還有一個超時時間，超時時間具體是多少，在操作系統(tǒng)內(nèi)核是可以配置的。

• 第一次丟包，超時時間是 T1
• 第二次丟包，超時時間是 T2

?
T2 > T1 這里等待的時間間隔隨著時間的推移越來越大，連續(xù)兩次沒發(fā)過去，意味著當前單次丟包的概率已經(jīng)相當大了，很可能是網(wǎng)絡(luò)上遇到了非常嚴重的事故，短期內(nèi)恢復不了，發(fā)送的再頻繁也沒用。超時重傳也不會無限制的重傳下去，嘗試幾次之后，仍然無法傳送過去，此時就會放棄重傳，然后嘗試斷開重連，如果重連還沒連上去，就徹底放棄了。

超時的時間如何確定？

• 最理想的情況下，找到一個最小的時間，保證 “確認應答一定能在這個時間內(nèi)返回”。
• 但是這個時間的長短，隨著網(wǎng)絡(luò)環(huán)境的不同，是有差異的。
• 如果超時時間設(shè)的太長，會影響整體的重傳效率；
• 如果超時時間設(shè)的太短，有可能會頻繁發(fā)送重復的包；

TCP為了保證無論在任何環(huán)境下都能比較高性能的通信，因此會動態(tài)計算這個最大超時時間。

• Linux中（BSD Unix和Windows也是如此），超時以500ms為一個單位進行控制，每次判定超時重發(fā)的超時時間都是500ms的整數(shù)倍。
• 如果重發(fā)一次之后，仍然得不到應答，等待 2*500ms 后再進行重傳。
• 如果仍然得不到應答，等待 4*500ms 進行重傳。依次類推，以指數(shù)形式遞增。
• 累計到一定的重傳次數(shù)，TCP認為網(wǎng)絡(luò)或者對端主機出現(xiàn)異常，強制關(guān)閉連接。

以上兩種機制可以認為是保證 TCP 可靠性的，最核心的機制

??三. 連接管理

• 網(wǎng)絡(luò)知識中，最高頻的考點，沒有之一?。?！
  ?
• 談到操作系統(tǒng)，最高頻的考題是進程和線程的區(qū)別
• 談到網(wǎng)絡(luò)，最高頻的考點是 TCP 的三次握手四次揮手
• 談到數(shù)據(jù)結(jié)構(gòu)，最高頻的考點是哈希表

在正常情況下，TCP要經(jīng)過三次握手建立連接，四次揮手斷開連接

主動的那一方是客戶端，三次握手，一定是客戶端先發(fā)起的

中間有兩步，不過都是從服務(wù)器到客戶端，所以合并為一次。經(jīng)歷了這四次交互，就完成了建立連接的過程。兩對操作，客戶端和服務(wù)器，相互給對方發(fā)送了一個 SYN ，再互相給對方發(fā)送了一個 ACK ，中間的兩次合并為一次，所以稱為 “三次握手”。

為啥要和并為一次傳輸？每次報文傳輸，都要經(jīng)過一系列的封裝分用！分成兩個包來發(fā)就比一個包代價大很多。

由我們的標志位可知，第五個標志位 SYN 是同步報文，第二個標志位 ACK 是確認報文，所以合并的那個報文第二個和第五個報文都是 1 。

1. 為啥要三次握手？（意義 / 初心）
   ?

• 三次握手，認為是一種保證可靠性的機制！這個東西相當于 “投石問路” ，在正式通信之前，先確認好通信鏈路是否通暢！如果通信鏈路不通暢，后續(xù)大概率要丟包！
• 讓通信雙方協(xié)商一些重要的參數(shù)（比如一次連接中不一定是從序號 1 開始的。也例如結(jié)婚）
  

?
2. 為啥三次握手要握三次呢？四次行不行？兩次行不行？
?
四次可以，但是沒必要，因為效率低；兩次鐵定不行，三次握手也是在驗證通信雙方的發(fā)送能力和接收能力是否正常！

四次揮手：斷開連接的過程。（客戶端和服務(wù)器都可以主動?。?/font>