目錄

1.應用層

2.傳輸層（核心問題）

2.1 UDP協(xié)議

2.1.2 UDP的特點

2.1.3?基于UDP的應用層協(xié)議

2.2 TCP協(xié)議（重點內(nèi)容）

2.2.1 TCP/IP 協(xié)議含義

2.2.2?TCP協(xié)議端格式：

2.2.3 TCP的特點

2.3?TCP原理

2.4?確認應答機制（安全機制）

2.5?超時重傳機制（安全機制）

2.5.1?數(shù)據(jù)直接丟了，接收方?jīng)]收到，自然不會發(fā) ack

2.5.2 接收方收到數(shù)據(jù)，返回的 ack 丟了

2.6 TCP 是如何實現(xiàn)可靠性的？

??2.7?連接管理機制（安全機制）（三次握手與四次揮手）（整個網(wǎng)絡原理最核心的考點）

1??TCP 建立連接：三次握手

?2.7.1?為什么需要三次握手，兩次不行嗎？

??2.7.2?四次握手呢？

2??TCP 斷開連接：四次揮手

???2.7.3 為啥三次握手能100%合并，四次揮手就不能合并？

????2.7.4 揮手為什么需要四次？

2.8?滑動窗口（效率機制）

2.8.1 批量發(fā)送的過程中，如果出現(xiàn)丟包咋辦？？?

2.8.2 滑動窗口、快速重傳是在批量傳輸大量數(shù)據(jù)的時候，會采取的措施

2.9?流量控制（安全機制）

2.9.1 如何實現(xiàn)流量控制

2.10?擁塞控制（安全機制）

2.10.1 擁塞窗口（擁塞控制實驗出來的窗口）

2.11?延遲應答（效率機制）

2.11.1 如何進行延時應答

2.12?捎帶應答（效率機制）

2.13?面向字節(jié)流

2.13.1 解決粘包問題

2.14?TCP異常情況

2.15 TCP小結

2.16 TCP 和 UDP 的差別

?文章來源地址http://www.zghlxwxcb.cn/news/detail-412251.html

??按照網(wǎng)絡協(xié)議這幾個層次展開：

1.應用層

應用層和代碼直接相關的一層，決定了數(shù)據(jù)要傳輸什么，拿到數(shù)據(jù)之后如何使用；應用層雖然存在一些現(xiàn)有的協(xié)議（HTTP），但是也有很多情況，需要程序員自定制協(xié)議

約定應用層數(shù)據(jù)報，數(shù)據(jù)結構就是在自定義協(xié)議

??如何約定？

1??確定要傳輸哪些信息（根據(jù)所需求來）

2??確定數(shù)據(jù)按照什么樣的格式來組織(隨意約定的)

網(wǎng)絡上傳輸?shù)模举|(zhì)上都是 0101，視為二進制的字符串，需要把上述這些信息整合成一個字符串

實際開發(fā)中，有一種現(xiàn)成的格式，可以直接使用的：典型的格式1??xml?——通過標簽的形式來組織2??json

2.傳輸層（核心問題）

2.1 UDP協(xié)議

2.1.1 UDP協(xié)議端格式：

2.1.2 UDP的特點

1??無連接 ：知道對端的IP和端口號就直接進行傳輸，不需要建立連接；

2??不可靠 ：沒有任何安全機制，發(fā)送端發(fā)送數(shù)據(jù)報以后，如果因為網(wǎng)絡故障該段無法發(fā)到對方，UDP協(xié)議層也不會給應用層返回任何錯誤信息；

3??面向數(shù)據(jù)報 ：應用層交給UDP多長的報文，UDP原樣發(fā)送，既不會拆分，也不會合并；

如果發(fā)送端一次發(fā)送100個字節(jié)，那么接收端也必須一次接收100個字節(jié)；而不能循環(huán)接收10次， 每次接收10個字節(jié)。

4??緩沖區(qū) ：UDP只有接收緩沖區(qū)，沒有發(fā)送緩沖區(qū)

UDP沒有真正意義上的 發(fā)送緩沖區(qū)。發(fā)送的數(shù)據(jù)會直接交給內(nèi)核，由內(nèi)核將數(shù)據(jù)傳給網(wǎng)絡層協(xié)議進行后續(xù)的傳輸動作；

UDP具有接收緩沖區(qū)，但是這個接收緩沖區(qū)不能保證收到的UDP報的順序和發(fā)送UDP報的順序一 致；如果緩沖區(qū)滿了，再到達的UDP數(shù)據(jù)就會被丟棄；

UDP的socket既能讀，也能寫，這個概念叫做 全雙工

5??大小受限 ：UDP協(xié)議首部中有一個16位的最大長度。也就是說一個UDP能傳輸?shù)臄?shù)據(jù)最大長度是64K（包含UDP首部）。

2.1.3?基于UDP的應用層協(xié)議

NFS：網(wǎng)絡文件系統(tǒng)

TFTP：簡單文件傳輸協(xié)議

DHCP：動態(tài)主機配置協(xié)議

BOOTP：啟動協(xié)議（用于無盤設備啟動）

DNS：域名解析協(xié)議

當然，也包括你自己寫UDP程序時自定義的應用層協(xié)議

2.2 TCP協(xié)議（重點內(nèi)容）

2.2.1 TCP/IP 協(xié)議含義

?從字面意義上講，有人可能會認為 TCP/IP 是指 TCP 和 IP 兩種協(xié)議。實際生活當中有時也確實就是指這兩種協(xié)議。然而在很多情況下，它只是利用 IP 進行通信時所必須用到的協(xié)議群的統(tǒng)稱。具體來說，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬于 TCP/IP 協(xié)議。他們與 TCP 或 IP 的關系緊密，是互聯(lián)網(wǎng)必不可少的組成部分。TCP/IP 一詞泛指這些協(xié)議，因此，有時也稱 TCP/IP 為網(wǎng)際協(xié)議群。

互聯(lián)網(wǎng)進行通信時，需要相應的網(wǎng)絡協(xié)議，TCP/IP 原本就是為使用互聯(lián)網(wǎng)而開發(fā)制定的協(xié)議族。因此，互聯(lián)網(wǎng)的協(xié)議就是 TCP/IP，TCP/IP 就是互聯(lián)網(wǎng)的協(xié)議

2.2.2?TCP協(xié)議端格式：

源/目的端口號：表示數(shù)據(jù)是從哪個進程來，到哪個進程去；

32位序號/32位確認號：后面詳細講；

4位TCP報頭長度：表示該TCP頭部有多少個32位bit（有多少個4字節(jié)）；所以TCP頭部最大長度是 15 * 4 = 60

6位標志位:

? ? URG：緊急指針是否有效

? ? ACK：確認號是否有效

? ? PSH：提示接收端應用程序立刻從TCP緩沖區(qū)把數(shù)據(jù)讀走

? ? RST：對方要求重新建立連接；我們把攜帶RST標識的稱為 復位報文段

? ? SYN：請求建立連接；我們把攜帶SYN標識的稱為 同步報文段

? ? FIN：通知對方，本端要關閉了，我們稱攜帶FIN標識的為 結束報文段

16位窗口大?。汉竺嬖僬f

16位校驗和：發(fā)送端填充，CRC校驗。接收端校驗不通過，則認為數(shù)據(jù)有問題。此處的檢驗和不光 包含TCP首部，也包含TCP數(shù)據(jù)部分。

16位緊急指針：標識哪部分數(shù)據(jù)是緊急數(shù)據(jù)；

40字節(jié)頭部選項：暫時忽略；

2.2.3 TCP的特點

1??有連接

2??可靠傳輸

3??面向字節(jié)流

4??全雙工

2.3?TCP原理

TCP對數(shù)據(jù)傳輸提供的管控機制，主要體現(xiàn)在兩個方面：安全和效率。 這些機制和多線程的設計原則類似：保證數(shù)據(jù)傳輸安全的前提下，盡可能的提高傳輸效率。

2.4?確認應答機制（安全機制）

每一個ACK都帶有對應的確認序列號，意思是告訴發(fā)送者，我已經(jīng)收到了哪些數(shù)據(jù)；下一次你從哪里開始發(fā)。

2.5?超時重傳機制（安全機制）

丟包是一種典型的情況

?如果中間任何一個節(jié)點出現(xiàn)問題，都有可能導致丟包

每個設備都是在承擔很多的轉(zhuǎn)發(fā)任務；每個設備轉(zhuǎn)發(fā)能力都是有上限的；某一時刻某個設備，上邊的流量達到峰值，就可能會引起部分數(shù)據(jù)被丟失

??發(fā)送方對于丟包的判定是：一定時間內(nèi)沒有收到 ack

2.5.1?數(shù)據(jù)直接丟了，接收方?jīng)]收到，自然不會發(fā) ack

主機A發(fā)送數(shù)據(jù)給B之后，可能因為網(wǎng)絡擁堵等原因，數(shù)據(jù)無法到達主機B； 如果主機A在一個特定時間間隔內(nèi)沒有收到B發(fā)來的確認應答，就會進行重發(fā)

2.5.2 接收方收到數(shù)據(jù)，返回的 ack 丟了

?主機A未收到B發(fā)來的確認應答，也可能是因為ACK丟失了；因此主機B會收到很多重復數(shù)據(jù)；這個時候TCP 會在接收緩沖區(qū)中根據(jù)收到的數(shù)據(jù)的序號，自動去重——保證了應用程序讀到的數(shù)據(jù)仍然只有一份

??那么，如果超時的時間如何確定？

最理想的情況下，找到一個最小的時間，保證 "確認應答一定能在這個時間內(nèi)返回"。

但是這個時間的長短，隨著網(wǎng)絡環(huán)境的不同，是有差異的。

如果超時時間設的太長，會影響整體的重傳效率；

如果超時時間設的太短，有可能會頻繁發(fā)送重復的包；

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

2.6 TCP 是如何實現(xiàn)可靠性的？

??大家覺得答案是什么呢

---

??答案是?確認應答+超時重傳?

?總結：

1??一切順利，使用確定應答保證可靠性

2??出現(xiàn)丟包，使用超時重傳作為補充

這兩個機制是 TCP 可靠性的基石

??2.7?連接管理機制（安全機制）（三次握手與四次揮手）（整個網(wǎng)絡原理最核心的考點）

連接管理機制 包括?TCP 建立連接 與 TCP 斷開連接

1??TCP 建立連接：三次握手

建立連接一定是由客戶端主動發(fā)起的

??握手（handshake）:指的是通信雙方進行一次網(wǎng)絡交互；相當于客戶端和服務器之間，通過三次交互建立了連接關系(雙方各自記錄對方的信息)

簡單圖解：

第一次握手：客戶端將標志位SYN置為1，隨機產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給服務器端，客戶端進入SYN_SENT狀態(tài)，等待服務器端確認。

第二次握手：務器端收到數(shù)據(jù)包后由標志位SYN=1知道客戶端請求建立連接，服務器端將標志位SYN和ACK都置為1，ack=J+1，隨機產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給客戶端以確認連接請求，服務器端進入SYN_RCVD狀態(tài)。

第三次握手：客戶端收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給服務器端，服務器端檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，客戶端和服務器端進入ESTABLISHED狀態(tài)，完成三次握手，隨后客戶端與服務器端之間可以開始傳輸數(shù)據(jù)了。?

三次握手這個過程本質(zhì)上是投石問路，驗證了客戶端和服務器，各自的發(fā)送能力和接收能力是否正常

?2.7.1?為什么需要三次握手，兩次不行嗎？

弄清這個問題，我們需要先弄明白三次握手的目的是什么，能不能只用兩次握手來達到同樣的目的。

• 第一次握手：客戶端發(fā)送網(wǎng)絡包，服務端收到了。
  這樣服務端就能得出結論：客戶端的發(fā)送能力、服務端的接收能力是正常的。
• 第二次握手：服務端發(fā)包，客戶端收到了。
  這樣客戶端就能得出結論：服務端的接收、發(fā)送能力，客戶端的接收、發(fā)送能力是正常的。不過此時服務器并不能確認客戶端的接收能力是否正常。
• 第三次握手：客戶端發(fā)包，服務端收到了。
  這樣服務端就能得出結論：客戶端的接收、發(fā)送能力正常，服務器自己的發(fā)送、接收能力也正常。

因此，需要三次握手才能確認雙方的接收與發(fā)送能力是否正常。

試想如果是用兩次握手，則會出現(xiàn)下面這種情況：

如客戶端發(fā)出連接請求，但因連接請求報文丟失而未收到確認，于是客戶端再重傳一次連接請求。后來收到了確認，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接，客戶端共發(fā)出了兩個連接請求報文段，其中第一個丟失，第二個到達了服務端，但是第一個丟失的報文段只是在某些網(wǎng)絡結點長時間滯留了，延誤到連接釋放以后的某個時間才到達服務端，此時服務端誤認為客戶端又發(fā)出一次新的連接請求，于是就向客戶端發(fā)出確認報文段，同意建立連接，不采用三次握手，只要服務端發(fā)出確認，就建立新的連接了，此時客戶端忽略服務端發(fā)來的確認，也不發(fā)送數(shù)據(jù)，則服務端一致等待客戶端發(fā)送數(shù)據(jù)，浪費資源。

??2.7.2?四次握手呢？

?四次握手相當于把中間的 syn 和 ack 開分開分別發(fā)送，可以但沒必要；分成兩次發(fā)，效率不如合成一次

2??TCP 斷開連接：四次揮手

1??2??上述兩個過程和 可靠性 有一點關系僅此而已；但是TCP是通過 確認應答 + 超時重傳 實現(xiàn)可靠性的

斷開連接是客戶端和服務器都有可能先發(fā)起的

通信雙方，各自給對方發(fā)送一個 FIN（結束報文），在各自給對方返回 ACK

四次揮手：即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發(fā)送4個包以確認連接的斷開。在socket編程中，這一過程由客戶端或服務端任一方執(zhí)行close來觸發(fā)。

由于TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數(shù)據(jù)發(fā)送任務后，發(fā)送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數(shù)據(jù)流動了，即不會再收到數(shù)據(jù)了，但是在這個TCP連接上仍然能夠發(fā)送數(shù)據(jù)，直到這一方向也發(fā)送了FIN。首先進行關閉的一方將執(zhí)行主動關閉，而另一方則執(zhí)行被動關閉。

?簡單圖解：

ack 和 fin 有一定概率合并成一個的?。〉峭ǔＧ闆r下，不能合并的

第一次揮手：客戶端發(fā)送一個FIN=M，用來關閉客戶端到服務器端的數(shù)據(jù)傳送，客戶端進入FIN_WAIT_1狀態(tài)。意思是說"我客戶端沒有數(shù)據(jù)要發(fā)給你了"，但是如果你服務器端還有數(shù)據(jù)沒有發(fā)送完成，則不必急著關閉連接，可以繼續(xù)發(fā)送數(shù)據(jù)

第二次揮手：服務器端收到FIN后，先發(fā)送ack=M+1，告訴客戶端，你的請求我收到了，但是我還沒準備好，請繼續(xù)你等我的消息。這個時候客戶端就進入FIN_WAIT_2 狀態(tài)，繼續(xù)等待服務器端的FIN報文。

第三次揮手：當服務器端確定數(shù)據(jù)已發(fā)送完成，則向客戶端發(fā)送FIN=N報文，告訴客戶端，好了，我這邊數(shù)據(jù)發(fā)完了，準備好關閉連接了。服務器端進入LAST_ACK狀態(tài)。

第四次揮手：客戶端收到FIN=N報文后，就知道可以關閉連接了，但是他還是不相信網(wǎng)絡，怕服務器端不知道要關閉，所以發(fā)送ack=N+1后進入TIME_WAIT狀態(tài)，如果Server端沒有收到ACK則可以重傳。服務器端收到ACK后，就知道可以斷開連接了?？蛻舳说却?MSL后依然沒有收到回復，則證明服務器端已正常關閉，那好，我客戶端也可以關閉連接了。

???2.7.3 為啥三次握手能100%合并，四次揮手就不能合并？

三次握手：ack 和 syn 是同一個時機觸發(fā)的（都是內(nèi)核來完成的）

四次揮手：ack 和 fin 則是不同時機觸發(fā)的（ack 是內(nèi)核完成的，會在收到 fin 的時候第一時間返回；fin 則是應用程序代碼控制的，在調(diào)用 socket 的close 方法的時候才會觸發(fā) fin）

????2.7.4 揮手為什么需要四次？

因為當服務端收到客戶端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當服務端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴客戶端，“你發(fā)的FIN報文我收到了”。只有等到我服務端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四次揮手

TCP 要保證的不僅僅是可靠性（提升可靠性往往意味著損失效率），還有效率

2.8?滑動窗口（效率機制）

對每一個發(fā)送的數(shù)據(jù)段，都要給一個ACK確認應答。收到ACK后再發(fā)送下一個數(shù)據(jù)段。這樣做有一個比較大的缺點，就是性能較差。尤其是數(shù)據(jù)往返的時間較長的時候。

?此時 A 這邊就花了大量時間在等待 ACK；想逃提高效率，就需要縮短等待時間——這時候就需要 批量發(fā)送數(shù)據(jù)

一次發(fā)多條數(shù)據(jù)，一次等多個 ack

??這里就是批量發(fā)送4條數(shù)據(jù)，發(fā)完之后，統(tǒng)一等待 ack；每次收到一個 ack 就立即發(fā)下一條（不是收到4個 ack 再發(fā)下一組）

使用一份時間，等待多個 ack；總的等待時間縮短了，整體效率就提升了（是和沒有批量發(fā)送進行對比的，而不是和 沒有可靠性 對比的）

上述批量傳輸數(shù)據(jù)的過程，稱為 滑動窗口

?批量不是無限發(fā)送，是發(fā)送到一定程度就等待 ack ，不等待直接發(fā)送的數(shù)據(jù)量是有上線的，而且是回來一個 ack 就立即發(fā)下一條，相當于總的要批量等待的數(shù)據(jù)是一致的，把批量等待數(shù)據(jù)的數(shù)量，就稱為“窗口大小”

滑動：收到一個 ack 就立即發(fā)下一條

2.8.1 批量發(fā)送的過程中，如果出現(xiàn)丟包咋辦？？?

可靠性第一，效率靠后

1??ack 丟了——沒有任何影響，因為后一個 ack 會對前一個 ack 進行包含，不影響數(shù)據(jù)的可靠傳輸

2??數(shù)據(jù)丟了——重新傳輸數(shù)據(jù)

?當 1001 這個數(shù)據(jù)重傳過來之后，此時缺失的拼圖就補全了；接下來就要從 7001 開始索要的

?如果是 4001也缺失，那么收到的 1001-2000 之后，接下來返回的 ack 就是索要 4001；同理反復索要；發(fā)送方就會重傳 4001

上述重傳過程，沒有任何冗余的操作；丟了的數(shù)據(jù) 才會重傳，不丟的數(shù)據(jù)不必重傳，整體速度是比較快的，這個重傳過程也稱為 快速重傳

2.8.2 滑動窗口、快速重傳是在批量傳輸大量數(shù)據(jù)的時候，會采取的措施

如果只傳一條兩條、少量的、低頻的操作，就不會按照滑動窗口這么搞了，仍然是前面樸素的確認應答和超時重傳了

2.9?流量控制（安全機制）

滑動窗口，批量發(fā)送；窗口越大，相當于批量的數(shù)據(jù)越多，整體的速度就越快

?接收端處理數(shù)據(jù)的速度是有限的。如果發(fā)送端發(fā)的太快，導致接收端的緩沖區(qū)被打滿，這個時候如果發(fā)送端繼續(xù)發(fā)送，就會造成丟包，繼而引起丟包重傳等等一系列連鎖反應。這樣就會得不償失，需要通過流量控制來實現(xiàn)

流量控制（也是保證可靠性的機制）：本質(zhì)上就是讓接收方來限制一下發(fā)送方的速度

2.9.1 如何實現(xiàn)流量控制

接收端將自己可以接收的緩沖區(qū)大小放入 TCP 首部中的 "窗口大小" 字段，通過ACK端通知發(fā) 送端；

窗口大小字段越大，說明網(wǎng)絡的吞吐量越高；

接收端一旦發(fā)現(xiàn)自己的緩沖區(qū)快滿了，就會將窗口大小設置成一個更小的值通知給發(fā)送端；

發(fā)送端接受到這個窗口之后，就會減慢自己的發(fā)送速度；

如果接收端緩沖區(qū)滿了，就會將窗口置為0；這時發(fā)送方不再發(fā)送數(shù)據(jù)，但是需要定期發(fā)送一 個窗口探測數(shù)據(jù)段，使接收端把窗口大小告訴發(fā)送端。

?發(fā)送方的窗口大小 = 流量控制 + 擁塞控制

2.10?擁塞控制（安全機制）

?滑動窗口的大小取決于流量控制（衡量了接收方的處理能力）和擁塞控制（衡量了傳輸路徑的處理能力）

?傳輸路徑上任何一個設備，處理能力如果遇到瓶頸，都會對整體的傳輸速率產(chǎn)生明顯的影響

??擁塞控制：衡量中間節(jié)點傳輸?shù)哪芰?/strong>