目錄

1. TCP-IP五層模型

2. UDP協(xié)議

2.1 特點

2.2 UDP協(xié)議端格式

2.3 校驗和

3. TCP協(xié)議

3.1 特點

3.2 TCP協(xié)議段格式

3.2.1 首部長度

3.2.2 選項

3.2.3 保留6位

3.3 TCP內(nèi)部的工作機制

3.3.1 確認應(yīng)答

（1）應(yīng)答報文ack

（2）小結(jié)

3.3.2 超時重傳

3.3.3 連接管理

3.3.4 滑動窗口

窗口大小

3.3.5流量控制

3.3.6擁塞控制

3.3.7延遲應(yīng)答

3.3.8稍帶應(yīng)答

3.3.9面向字節(jié)流

3.3.10異常情況

1. TCP-IP五層模型

應(yīng)用層-數(shù)據(jù)具體要怎么使用。

傳輸層-只考慮起點和終點。

網(wǎng)絡(luò)層-負責(zé)任意兩個結(jié)點之間的傳輸、路徑規(guī)劃。

數(shù)據(jù)鏈路層-負責(zé)相鄰節(jié)點間的數(shù)據(jù)傳輸。

物理層-信息傳輸?shù)墓贰?/p>

下面的四層都是在系統(tǒng)內(nèi)核/驅(qū)動程序/硬件中已經(jīng)實現(xiàn)好的，只能了解不能修改。

應(yīng)用層協(xié)議是可以自定義的。自定義協(xié)議主要是做兩件事：

1.明確協(xié)議數(shù)據(jù)要傳遞哪些信息（根據(jù)需求來的）

2.明確數(shù)據(jù)組織格式，比如按照純文本的方式，也可以使用xml、json、protobuffer

應(yīng)用層除了上述自定義的協(xié)議之外，也有一些大佬們設(shè)計好的現(xiàn)成的協(xié)議，最典型的就是http協(xié)議。

傳輸層雖然是操作系統(tǒng)內(nèi)核已經(jīng)實現(xiàn)好了，但是程序員寫代碼，要調(diào)用系統(tǒng)提供的socket api完成網(wǎng)絡(luò)編程的，socket就是屬于傳輸層的部分。

端口號是傳輸層協(xié)議的概念，TCP和UDP協(xié)議報頭中都會包含源端口和目的端口，這倆都是使用2個字節(jié)，16個比特位表示的。

需要熟背的內(nèi)容

1個字節(jié) 8 bit? 范圍 -128到+127? ? ? ? ? ?0-255

2個字節(jié)16bit 范圍-32768到+32767? ? ?0-65535

4個字節(jié) 32bit 范圍 -21億到+21億? ? ? ? 0-42億9千萬

一個端口號的取值范圍是0-65535，但是自己寫的程序綁定的端口號得是從1024起的。

0-1023這個范圍的端口，稱為“知名端口號/具名端口號”，這些端口號是屬于已經(jīng)分配給了一些知名的廣泛使用的應(yīng)用程序了。

端口號：數(shù)據(jù)庫mysql默認端口3306，起到的效果就是區(qū)分一個主機上具體的應(yīng)用程序，要求在同一個主機上，一個端口號不能被多個進程綁定。

2. UDP協(xié)議

2.1 特點

無連接、不可靠、面向數(shù)據(jù)報、全雙工。

2.2 UDP協(xié)議端格式

一次網(wǎng)路通信涉及到五元組：源IP、源端口、目的IP、目的端口、協(xié)議類型

UDP報頭里包含了一些特定的屬性，就攜帶了一些重要的信息。不同的協(xié)議，功能不同，報頭中帶有的屬性信息也不同，對于UDP來說，報頭一共就是8個字節(jié)。分成4個部分（每個部分兩個字節(jié)）。

16位UDP長度，表示整個數(shù)據(jù)報（UDP首部+UDP數(shù)據(jù)）的最大長度；2個字節(jié)，范圍0-65535；換算單位為64KB，一個UDP數(shù)據(jù)報最大只能傳輸64KB的數(shù)據(jù)。如果應(yīng)用層數(shù)據(jù)報超過64KB，咋辦？

（1）就需要在應(yīng)用層，通過代碼的方式針對應(yīng)用層數(shù)據(jù)報進行手動的分包，拆分成多個包通過多個UDP數(shù)據(jù)報進行傳輸(本來需要send一次，現(xiàn)在需要send多次)

（2）不用UDP，換成TCP（TCP沒有這樣的限制）

2.3 校驗和

如果校驗和出錯，就會直接丟棄。

校驗和的作用是驗證傳輸?shù)臄?shù)據(jù)是否是正確的；網(wǎng)絡(luò)傳輸過程中，可能會受到一些干擾，在這些干擾下就可能出現(xiàn)“比特翻轉(zhuǎn)”的情況。網(wǎng)絡(luò)傳輸?shù)谋举|(zhì)是光信號/電信號，就會受到一些物理環(huán)境的影響，所以就引入了校驗和來進行鑒別，針對數(shù)據(jù)內(nèi)容進行一系列的數(shù)學(xué)運算，得到一個比較短的結(jié)果，如果數(shù)據(jù)內(nèi)容一定，得到的校驗和結(jié)果就一定，如果數(shù)據(jù)變了，得到的校驗和也就變了。

針對網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)來說，生成校驗和的算法有很多種，其中比較知名的幾個：

1.CRC?

循環(huán)冗余檢驗

簡單粗暴，把數(shù)據(jù)的每個字節(jié)，循環(huán)往上累加，如果累加溢出了，高位就不要了。【優(yōu)點：好算，但是校驗效果不是特別理想，萬一數(shù)據(jù)同時變了兩個比特位，就容易出現(xiàn)內(nèi)容變了，CRC沒變這樣的情況】

2.MD5

不是簡單相加，有一系列公式，來進行更復(fù)雜的數(shù)學(xué)運算（數(shù)學(xué)問題）

特點：

（1）定長，無論原始數(shù)據(jù)多長，得到的MD5值都是固定長度（4字節(jié)版本，也有8字節(jié)版本）

（2）沖突概率很小，原始數(shù)據(jù)哪怕只變動一個地方，算出的MD5值都會差別很大（讓MD5結(jié)果更分散了）

（3）不可逆。通過原始數(shù)據(jù)計算MD5很容易，通過MD5還原成原始數(shù)據(jù)很難，理論上是不可實現(xiàn)的。

MD5的特點讓它的作用更多了：校驗和、作為計算哈希值的方式、加密。

3.SHA1

3. TCP協(xié)議

TCP Transmission Control Protocol 傳輸控制協(xié)議

3.1 特點

有連接、可靠、面向字節(jié)流、全雙工

3.2 TCP協(xié)議段格式

3.2.1 首部長度

一個TCP報頭，長度是可變的，不是像UDP一樣固定是8個字節(jié)。因此，首部長度就描述了TCP報頭具體多長。另外選項之前的部分是固定長度（20字節(jié)：一行是4個字節(jié)）

【此處的首部長度是4比特位】

3.2.2 選項

首部長度 - 20 字節(jié)得到的就是選項部分的長度。

如果首部長度值是5，表示整個TCP報頭的長度是20字節(jié)【相當(dāng)于沒有選項】

如果首部長度值是15，表示整個TCP報頭是60字節(jié)【選項長度相當(dāng)于是40字節(jié)】

3.2.3 保留6位

保留6位是為了以后的擴展來考慮的，對于網(wǎng)絡(luò)協(xié)議來說，擴展升級，是一件成本極高的事情，比如UDP，報文長度是2字節(jié)，因此一個包最大就是64KB，現(xiàn)在是否可以能把UDP協(xié)議升級，讓他支持更大的長度，比如把報頭長度使用4字節(jié)表示？？

理論上可行但實際的操作成本極高。這不是技術(shù)問題，而是營銷問題。需要升級設(shè)備中的操作系統(tǒng)。但是如果引入“保留位”，此時升級操作的成本就會降低不少，如果后續(xù)TCP引入了一些新的功能，就可以使用保留位的字段，此時對于TCP本來的報頭結(jié)構(gòu)的影響比較小，老的設(shè)備即使不升級，也可以兼容。

3.3 TCP內(nèi)部的工作機制

3.3.1 確認應(yīng)答

實現(xiàn)可靠傳輸最核心的機制。可靠不是說發(fā)送方百分百可以將消息發(fā)給接收方，而是盡可能的把數(shù)據(jù)進行傳輸，同時如果還是傳輸不過去，至少能知道。

（1）應(yīng)答報文ack

ack = 1 -- 應(yīng)答報文

任何一條數(shù)據(jù)（包括應(yīng)答報文）都是有序號的，確認序號，則是只有應(yīng)答報文有（普通報文確認序號字段里的值無意義）

應(yīng)答報文中確認序號填寫的是1001，就是在數(shù)據(jù)1000上+1，表示的含義

a.小于1001的數(shù)據(jù)都已經(jīng)確認收到了

b.A接下來該從1001這個序號開始繼續(xù)發(fā)送

（2）小結(jié)

TCP可靠傳輸能力，最主要的就是通過確認應(yīng)答機制保證的。通過應(yīng)答報文，就可以讓發(fā)送方清楚的知道是否傳輸成功，進一步引入序號和確認序號，針對多組數(shù)據(jù)進行詳細區(qū)分【網(wǎng)絡(luò)上可能存在“后發(fā)先至”這個情況下，收到的消息的順序可能是存在變數(shù)的】。

3.3.2 超時重傳

超過一定的時間沒響應(yīng)，就重新傳輸。

TCP對于重復(fù)數(shù)據(jù)的傳輸有特殊的處理【去重】

TCP存在一個“接收緩沖區(qū)”，這樣的存儲空間【接收方的操作系統(tǒng)內(nèi)核里的一段內(nèi)存】

對確認應(yīng)答一個重要補充：一旦出現(xiàn)丟包的情況，就要重新進行傳輸。發(fā)送方卡一個超時時間，指定時間范圍內(nèi)都沒有收到ack，此時就認為丟了，需要重傳?！緮?shù)據(jù)報丟了：直接重傳。ack丟了：就說明接收方會收到兩份一樣的數(shù)據(jù)，tcp會根據(jù)序號針對收到的消息進行去重】

3.3.3 連接管理

連接【Connection】：抽象的概念。

意義：

通信雙方各自建立對對方的“認同”

驗證通信雙方各自的發(fā)送能力與接收能力是否ok

在握手的過程中，雙方協(xié)商一些重要參數(shù)。

三次握手：syn【嘗試建立連接】 ack【應(yīng)答】? ?四次交互，中間兩次交互可以合二為一。

四次揮手：斷開連接。通信雙方各自給對方發(fā)送一個FIN【結(jié)束報文段】，再各自給對方返回一個ack【由于中間的兩次時間并不盡相同，ack是立即返回的，下一條FIN是代碼里執(zhí)行到close方法，才觸發(fā)的，因此是四次，如果中間間隔真的很短或者加上了延遲應(yīng)答這樣的機制，四次揮手也是可能會合并成三次的】

理解：TIME_WAIT

出現(xiàn)在主動發(fā)起斷開連接的一方客戶端需要等待一個2MSL【互聯(lián)網(wǎng)上兩個結(jié)點之間的數(shù)據(jù)傳輸消耗的最大時間】（Max Segment Life,報文最大生存時間）的時間，才會進入CLOSDE狀態(tài)。?

3.3.4 滑動窗口

一發(fā)一收的方式性能較低，一次發(fā)送多條數(shù)據(jù)就可以大大提高性能。（將多個時段的等待時間重疊在一起了）提升效率不等于高效。確認應(yīng)答、超時重傳、連接管理保證了TCP的可靠性?！究煽啃院蛡鬏斝时旧硎敲艿摹?/p>

窗口大小

無需等待確認應(yīng)答而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值。

操作系統(tǒng)內(nèi)核為了維護這個滑動窗口，需要開辟發(fā)送緩沖區(qū)來記錄當(dāng)前還有哪些數(shù)據(jù)沒有應(yīng)答；只有確認應(yīng)答過的數(shù)據(jù)，才能從緩沖區(qū)刪掉。

窗口越大，網(wǎng)絡(luò)的吞吐率就越高。

能夠根據(jù)接收方的處理能力制衡發(fā)送方的發(fā)送速率

滑動窗口的本質(zhì)是降低了確認應(yīng)答、等待ACK的時間?！具M行IO操作的時候，時間成本主要是兩個部分等待和數(shù)據(jù)傳輸。大多數(shù)情況下都是在等】

出現(xiàn)了丟包，如何進行重傳？【分兩種情況討論】

a.數(shù)據(jù)包已抵達，ACK被丟了

ack丟了不要緊，因為可以通過后續(xù)的ACK進行確認。

b.數(shù)據(jù)包直接丟了

當(dāng)一段報文段丟失之后，發(fā)送端會一直收到1001這樣的ACK，就像是在提醒發(fā)送端“我想要的是1001”一樣。

如果發(fā)送端主機連續(xù)三次收到了同樣的一個“1001”這樣的應(yīng)答，就會將對應(yīng)的數(shù)據(jù)1001-2000重新發(fā)送。

這時接收端收到1001之后，再次返回的ACK就是7001（2001-7000接收端其實之前就已經(jīng)收到了，被放到了接收端操作系統(tǒng)內(nèi)核的接收緩沖區(qū)中）

這種機制也叫做“高速重發(fā)控制”【快重傳】--超時重傳機制在滑動窗口下的變形。

3.3.5流量控制

一種干預(yù)發(fā)送窗口大小的機制。

滑動窗口，窗口越大，傳輸效率越高，但是窗口不能無限大。

（1）完全不等ACK可靠性就不能保障

（2）窗口太大，消耗系統(tǒng)資源

（3）發(fā)送速度太快，接收方處理不過來，發(fā)了也白發(fā)。

約束依據(jù)：接收方的處理能力。

接收方處理數(shù)據(jù)的速度是有限的，如果發(fā)送端發(fā)的太快，導(dǎo)致接收端的緩沖區(qū)被打滿，這個時候發(fā)送端繼續(xù)發(fā)送，就會造成丟包，繼而引起丟包重傳等一系列連鎖反應(yīng)。

因此TCP支持根據(jù)接收端的處理能力，來決定發(fā)送端的發(fā)送速度，這個機制就叫做流量控制。

直接看接收方接收緩沖區(qū)的剩余大小。

如何把窗口大小告訴發(fā)送端？

在TCP的首部，有一個16位窗口字段，就是為了存放窗口大小信息。16位數(shù)字最大表示65535，那么TCP窗口的最大就是65535個字節(jié)么？

TCP首部40字節(jié)選項中還包含一個窗口擴大因子M，實際窗口大小是窗口字段的值左移M位。

3.3.6擁塞控制

流量控制【接收方的處理能力】+擁塞控制【傳輸過程中中間結(jié)點的處理能力 不好衡量，通過“實驗”測試，逐漸找到一個合適的窗口大小】共同決定了發(fā)送方的窗口大小是多少【取較小值】。

擁塞窗口的值不是固定不變的，而是一直動態(tài)變化的。

先指數(shù)增長，之后線性增長之后回跳【熱戀】

3.3.7延遲應(yīng)答

如果接收數(shù)據(jù)的主機立刻返回ACK應(yīng)答，這時候返回的窗口可能比較小。在接收方能夠處理的了的前提下，盡可能的把窗口放大。

延遲：收到數(shù)據(jù)之后，不是立即返回ACK，而是稍微等會再返回。等待的時間里，接收方的應(yīng)用程序，就能把接收緩沖區(qū)的數(shù)據(jù)消費一波，這樣剩余空間就更大了

3.3.8稍帶應(yīng)答

也是提升效率的方式，在延遲應(yīng)答的基礎(chǔ)上，引入了捎帶應(yīng)答。

能夠合并。

3.3.9面向字節(jié)流

粘包問題，明確兩個包的邊界：分隔符、長度。

3.3.10異常情況

出現(xiàn)了不可抗力的因素。

進程崩潰了

主機關(guān)機

進程沒了，對應(yīng)的PCB就沒了，對應(yīng)的問價描述符表就釋放了，相當(dāng)于socket.close();

此時內(nèi)核會繼續(xù)完成四次揮手，此時其實仍然是一個正常斷開的流程。

主機關(guān)機要先殺進程，然后再正式關(guān)機（殺死進程的過程中，也是和上面一樣觸發(fā)四次揮手）

主機掉電

網(wǎng)線斷開

假設(shè)是接收方掉電，發(fā)送方仍然再繼續(xù)發(fā)送數(shù)據(jù)，發(fā)完數(shù)據(jù)要繼續(xù)等待ACK，ACK等不到，超時重傳，再怎么重傳也收不到ACK，重傳幾次，還是沒有應(yīng)答，嘗試重置tcp連接，（復(fù)位報文段? RST）,顯然這個重置也會時報，放棄連接。

如果是發(fā)送端掉電，接收方發(fā)現(xiàn)沒有數(shù)據(jù)了，沒數(shù)據(jù)是發(fā)送方掛了還是發(fā)送方要組織下語言重新發(fā)送接收方是不知道的，接收方選擇先等，周期性的給發(fā)送方發(fā)送一個消息，確認下對方是否還正常工作?！拘奶?-心跳是周期性的，如果心跳無了，就說明掛了，使用心跳包來確認通信雙方是處在正常的工狀態(tài)中】文章來源地址http://www.zghlxwxcb.cn/news/detail-799694.html

到了這里，關(guān)于JAVAEE初階相關(guān)內(nèi)容第十七彈--網(wǎng)絡(luò)原理之TCP_IP的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！