原文鏈接：https://javaguide.cn/cs-basics/network

OSI七層模型

1. 應(yīng)用層
2. 表示層
3. 會話層
4. 傳輸層
5. 網(wǎng)絡(luò)層
6. 數(shù)據(jù)鏈路層
7. 物理層

TCP/IP 四層模型

1. 應(yīng)用層（HTTP，DNS，SSH）
2. 傳輸層（TCP，UDP）
3. 網(wǎng)絡(luò)層（IP，NAT，ARP）
4. 網(wǎng)絡(luò)接口層（MAC，以太網(wǎng)）

OSI七層模型和TCP/IP四層模型對比

HTTP協(xié)議（應(yīng)用層）

• 位于應(yīng)用層，基于傳輸層的TCP協(xié)議，主要是為 Web 瀏覽器與 Web 服務(wù)器之間的通信而設(shè)計(jì)的。
• 無狀態(tài)的協(xié)議，使用Cookie，Session等記住用戶的狀態(tài)。

HTTP1.0

• 最早出現(xiàn)于1996年

HTTP1.1

• 緩存處理， 提供了更多的緩存頭用來控制緩存策略；
• 引入range頭域，允許只請求資源的一部分，支持了斷點(diǎn)續(xù)傳；
• 引入更多錯(cuò)誤狀態(tài)碼
• 引入Host頭域，可以訪問同一IP地址的不同域名
• 支持長連接，不用每次都要三次握手

HTTP2.0

• 二進(jìn)制分幀，所有的幀都采用二進(jìn)制編碼
• 多路復(fù)用，每個(gè)數(shù)據(jù)流都可以拆分成很多互不依賴的幀，這些幀可以獨(dú)立發(fā)送，接收端再組合起來。HTTP2.0的連接都是持久化的，每個(gè)域名一個(gè)連接。
• 請求優(yōu)先級，幀可以設(shè)置優(yōu)先級
• header壓縮，HTTP1.1的header帶有大量信息，且每次都要重復(fù)發(fā)送，HTTP2.0對此進(jìn)行了壓縮
• 服務(wù)端推送，服務(wù)端可以對一個(gè)請求發(fā)送多個(gè)響應(yīng)

TCP協(xié)議（傳輸層）

面向連接，可靠，基于字節(jié)流
基于字節(jié)流是指，TCP只處理二進(jìn)制數(shù)據(jù)，是無法區(qū)分?jǐn)?shù)據(jù)之間的關(guān)系的，為此，HTTP協(xié)議在每個(gè)數(shù)據(jù)頭標(biāo)記了數(shù)據(jù)的長度，以此區(qū)分不同的數(shù)據(jù)。

三次握手

為了確認(rèn)兩件事情，一是客戶端的發(fā)送與接受功能是否正常；二是服務(wù)端的發(fā)送與接受能力是否正常。

• 第一次握手，客戶端發(fā)出消息，服務(wù)端接受到消息后，服務(wù)端確認(rèn)了客戶端的發(fā)送功能和服務(wù)端的接受功能正常；
• 第二次握手，服務(wù)端發(fā)送消息，客戶端接受到消息后，客戶端確認(rèn)了客戶端的發(fā)送接受功能和服務(wù)端的發(fā)送接受功能正常；
• 第三次握手，客戶端發(fā)送消息，服務(wù)端接受消息后，服務(wù)端確認(rèn)了客戶端的接受功能和服務(wù)端的發(fā)送功能正常。

四次揮手

TCP是全雙工通信，可以雙向傳輸數(shù)據(jù)。

• 第一次揮手，客戶端發(fā)出FIN消息，服務(wù)端接受到消息后，確認(rèn)客戶端沒有消息發(fā)出了；
• 第二次揮手，服務(wù)端發(fā)出ACK消息，客戶端接收到消息后，確認(rèn)服務(wù)端知道了客戶端不再發(fā)送消息的事實(shí)；
• 第三次揮手，服務(wù)端發(fā)出FIN消息，客戶端接收到消息后，確認(rèn)服務(wù)端沒有消息發(fā)出了；
• 第四次揮手，客戶端發(fā)出ACK消息，服務(wù)端接受到消息后，確認(rèn)客戶端知道了服務(wù)端不再發(fā)送消息的事實(shí)。

如何保證數(shù)據(jù)傳輸?shù)目煽啃?/h5>

1. 基于數(shù)據(jù)塊傳輸 ：應(yīng)用數(shù)據(jù)被分割成 TCP 認(rèn)為最適合發(fā)送的數(shù)據(jù)塊，再傳輸給網(wǎng)絡(luò)層，數(shù)據(jù)塊被稱為報(bào)文段或段。
2. 對失序數(shù)據(jù)包重新排序以及去重：TCP 為了保證不發(fā)生丟包，就給每個(gè)包一個(gè)序列號，有了序列號能夠?qū)⒔邮盏降臄?shù)據(jù)根據(jù)序列號排序，并且去掉重復(fù)序列號的數(shù)據(jù)就可以實(shí)現(xiàn)數(shù)據(jù)包去重。
3. 校驗(yàn)和 : TCP 將保持它首部和數(shù)據(jù)的檢驗(yàn)和。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗(yàn)和有差錯(cuò)，TCP 將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段。
4. 超時(shí)重傳 : 當(dāng)發(fā)送方發(fā)送數(shù)據(jù)之后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。接收端實(shí)體對已成功收到的包發(fā)回一個(gè)相應(yīng)的確認(rèn)信息（ACK）。如果發(fā)送端實(shí)體在合理的往返時(shí)延（RTT）內(nèi)未收到確認(rèn)消息，那么對應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失并進(jìn)行重傳。
5. 流量控制 : TCP 連接的每一方都有固定大小的緩沖空間，TCP 的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)。當(dāng)接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失。TCP 使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議（TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制）。
6. 擁塞控制 : 當(dāng)網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送。

流量控制

TCP 利用滑動(dòng)窗口實(shí)現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。
TCP協(xié)議會將待發(fā)送的數(shù)據(jù)拆分成數(shù)據(jù)包一個(gè)一個(gè)發(fā)送，并通過一個(gè)滑動(dòng)窗口來控制發(fā)送的速率。這個(gè)窗口保證同一時(shí)刻內(nèi)只有特定數(shù)量的數(shù)據(jù)包處于待發(fā)送狀態(tài)，包含已經(jīng)發(fā)送但未收到確認(rèn)消息的數(shù)據(jù)包和即將發(fā)送的數(shù)據(jù)包。

發(fā)送窗口

接受窗口

擁塞控制

• 流量控制是端到端的，而擁塞控制是全局性的，涉及到所有的路由器和網(wǎng)絡(luò)。
• TCP發(fā)送方會讓自己的發(fā)送窗口取擁塞窗口和接收方接受窗口中較小的一個(gè)。
• TCP的擁塞控制采取了四種算法，慢開始、擁塞避免、快重傳和快恢復(fù)。

RPC（應(yīng)用層）

RPC(Remote Procedure Call）又叫做 遠(yuǎn)程過程調(diào)用，它本身并不是一個(gè)具體的協(xié)議，而是一種調(diào)用方式 。
不同的RPC實(shí)現(xiàn)要么直接基于TCP，要么基于HTTP協(xié)議，總之，都是應(yīng)用層的協(xié)議。核心功能有：

1. 客戶端：調(diào)用遠(yuǎn)程方法的一端
2. 客戶端Stub（樁）：代理類，將你調(diào)用方法，類，參數(shù)等信息傳遞到服務(wù)端
3. 網(wǎng)絡(luò)傳輸：將信息傳輸?shù)椒?wù)端
4. 服務(wù)端Stub（樁）：接受到請求后，指定對應(yīng)的方法然后返回結(jié)果的類
5. 服務(wù)端：提供遠(yuǎn)程方法的一端

Dubbo框架

Dubbo3提供了從服務(wù)定義、服務(wù)發(fā)現(xiàn)、服務(wù)通信到流量管控等幾乎所有的服務(wù)治理能力，支持Triple協(xié)議（基于HTTP/2之上定義的下一代RPC通信協(xié)議）。

gRPC框架

Google開源的一個(gè)高性能、通用的開源RPC框架，基于HTTP/2協(xié)議設(shè)計(jì)，基于ProtoBuf序列化協(xié)議開發(fā)。

HTTP協(xié)議和RPC的區(qū)別

• RPC是C/S架構(gòu)，HTTP是B/S架構(gòu)。RPC協(xié)議可能每家都不一樣，而HTTP協(xié)議是一個(gè)通用的協(xié)議，是個(gè)瀏覽器就支持。
• 服務(wù)發(fā)現(xiàn)，HTTP通過DNS服務(wù)查找服務(wù)器的IP地址和端口，RPC協(xié)議使用專門的中間服務(wù)來獲取IP地址和端口。
• 底層連接方式，HTTP協(xié)議再建立了底層TCP連接后一般會復(fù)用該連接，RPC協(xié)議會維護(hù)一個(gè)TCP連接池，用完再放回去，無太大區(qū)別。
• 傳輸內(nèi)容，一般包含消息頭和消息體。HTTP協(xié)議傳輸?shù)膬?nèi)容以字符串或json格式為主，RPC可以使用Protobuf序列化格式保存二進(jìn)制數(shù)據(jù)，信息密度更高。

Protobuf序列化協(xié)議

采用Tag-Length-Value將每個(gè)字段編碼成二進(jìn)制數(shù)據(jù)，然后拼接成一個(gè)二進(jìn)制字節(jié)流，信息密度十分緊湊。