網絡編程--上篇
網絡編程--上篇
本文只做歸納總結。
1.基礎知識
①網絡模型
這里引用一下菜鳥教程網站的介紹和圖片,為了使不同計算機廠家生產的計算機能夠相互通信,以便在更大的范圍內建立計算機網絡,國際標準化組織(ISO)在1978年提出了"開放系統互聯參考模型",即著名的OSI/RM模型(Open System Interconnection/Reference Model)。它將計算機網絡體系結構的通信協議劃分為七層。除了標準的OSI七層模型以外,常見的網絡層次劃分還有TCP/IP四層協議以及TCP/IP五層協議:(如下圖所示-來自菜鳥教程)
拋出一個問題:為什么要分層?
②協議
在上述的各層級中,有各種各樣的協議,在計算機網絡中,我們常見的協議有:IP協議,TCP協議,UDP協議,HTTP協議,WebSocket協議,HTTPS協議,FTP協議,DNS協議,SSH協議等等。
+++
IP協議:網絡層
互聯網的基礎協議,負責將數據從源主機通過路由傳輸到目標主機,通過IP 地址(如192.168.1.1)唯一標識網絡中的設備。我們常說的IP地址在僅僅是網絡層中用于標識一個節點(或者網絡設備的接口)。網絡標識唯一節點,便于數據包轉發。
- IPv4:32 位地址(如
192.168.1.100),地址空間約 43 億,面臨枯竭(通過 NAT 技術擴展)。 - IPv6:128 位地址(如
2001:0db8:85a3:0000:0000:8a2e:0370:7334),地址空間幾乎無限。
所有互聯網通信的基礎(如網頁訪問、文件傳輸都依賴 IP 尋址);路由器通過 IP 協議實現跨網絡的數據轉發
+++
TCP協議 和 UDP協議 【傳輸層】
tcp:面向連接的可靠傳輸協議,確保數據從源應用到目標應用的有序、無丟失傳輸。當一臺計算機想要與另一臺計算機通訊時,兩臺計算機之間的通信需要暢通且可靠,這樣才能保證正確收發數據。例如,當你想查看網頁或查看電子郵件時,希望完整且按順序查看網頁,而不丟失任何內容?!疽环N面向連接的、可靠的、基于字節流的傳輸層通信協議】
UDP:無連接的不可靠傳輸協議,以高效率、低延遲為核心,不保證數據到達或順序。 UDP協議全稱是用戶數據報協議。
他們二者的各自的特點:
| TCP | UDP |
|---|---|
| 面向連接:發送數據之前必須在兩端建立連接。建立連接的方法是“三次握手”,這樣能建立可靠的連接。建立連接,是為數據的可靠傳輸打下了基礎。 | 面向無連接,首先 UDP 是不需要和 TCP一樣在發送數據前進行三次握手建立連接的,想發數據就可以開始發送了 |
| 僅支持單播傳輸,只能進行點對點的數據傳輸,不支持多播和廣播傳輸方式 | 有單播,多播,廣播的功能,UDP 不止支持一對一的傳輸方式,同樣支持一對多,多對多,多對一的方式 |
| 面向字節流,不保留報文邊界的情況下以字節流方式進行傳輸 | UDP是面向報文的 |
| 可靠傳輸 | 不可靠性 |
| 提供擁塞控制 | 頭部開銷小,傳輸數據報文時是很高效的。 |
+++
Http和WebSocket協議 【應用層】
HTTP(超文本傳輸協議)和WebSocket都是應用層協議,但它們在設計目標、通信方式和適用場景上有顯著差異,同時也存在一定聯系。
| 特性 | HTTP | WebSocket |
|---|---|---|
| 通信模式 | 單向請求-響應,客戶端發起請求,服務器響應后連接關閉(HTTP/1.1支持持久連接,但仍是客戶端主動) | 全雙工雙向通信,連接建立后,服務器和客戶端可隨時主動發送數據 |
| 連接生命周期 | 短連接(每次請求需新建連接)或長連接(如HTTP/1.1的Keep-Alive,但需定期維護) | 持久連接,一次握手后長期保持,適合高頻實時交互 |
| 頭部開銷 | 頭部較大(如包含Cookie、緩存頭等),每次請求需攜帶完整頭部 | 頭部極簡(僅2-10字節),數據傳輸效率高 |
| 數據格式 | 純文本(如HTML、JSON),需遵循特定MIME類型 | 支持二進制和文本數據,可傳輸任意格式(如Blob、ArrayBuffer) |
| 適用場景 | 靜態資源加載、API調用、表單提交等 | 實時聊天、在線游戲、股票行情、協作編輯等需要低延遲雙向通信的場景【實時】 |
上述兩個協議的聯系:
1.握手協議兼容
WebSocket通過HTTP協議完成握手升級:
- 客戶端發送
HTTP Upgrade請求(包含Sec-WebSocket-Key等頭部) - 服務器響應
101 Switching Protocols狀態碼 - 此后通信切換為WebSocket協議(基于TCP,使用
ws://或wss://地址)
2.應用層協議層級
兩者均位于TCP/IP協議棧的應用層,但WebSocket提供了更高效的雙向通信機制,可視為HTTP的補充而非替代。
3.共用基礎設施
- 均可通過防火墻、代理服務器
- 都支持TLS加密(HTTPS與WSS)
+++
**Https協議 **【應用層】
安全套接字層超文本傳輸協議(Hyper Text Transfer Protocol over Secure Socket Layer)。以安全為目標的HTTP通道,簡單講是HTTP的安全版本,即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容就需要SSL。
http和https的區別
| 對比維度 | http | https |
|---|---|---|
| 協議性質 | 明文傳輸,不加密 | 基于 SSL/TLS 加密協議,數據加密傳輸 |
| 默認端口 | 80 | 443 |
| 安全性 | 低,數據易被竊取、篡改或監聽 | 高,通過加密、身份驗證和完整性校驗保證安全 |
| 證書要求 | 無需 CA 證書 | 需要申請 CA(證書頒發機構)簽名的數字證書(或自簽名證書,僅限測試) |
| 加密方式 | 無加密 | 使用 對稱加密(如 AES)和 非對稱加密(如 RSA)結合,通過證書驗證身份 |
| URL 前綴 | http:// |
https:// |
| 性能影響 | 無加密開銷,速度略快 | 存在加密 / 解密開銷,首次連接時延遲略高(可通過 TLS 1.3 等優化) |
- HTTP 適合對安全性要求低的場景,但存在數據泄露風險。
- HTTPS 通過加密和證書機制保障安全,是現代網站的標準配置,尤其適用于涉及用戶隱私或交易的場景。
- HTTPS 的核心優勢:防止數據篡改、身份偽造和信息泄露,建立用戶信任。
+++
**FTP 協議 **【應用層】
用于在網絡中上傳或下載文件的協議,支持交互式文件管理(如創建目錄、重命名文件)
+++
**DNS 協議(域名系統) **【應用層】
將人類可讀的域名(如baidu.com)解析為機器可讀的 IP 地址(如14.215.177.38)的分布式數據庫系統
+++
**SSH 協議(安全外殼協議) **應用層(基于 TCP)
用于加密遠程登錄和命令執行的協議,替代不安全的 Telnet,確保通信過程中數據不被竊取或篡改。
比如說我們平時管理員通過 SSH 登錄 Linux 服務器,執行系統維護命令;
②網絡連接
大家耳熟能詳的“TCP三次握手、四次揮手”:計算機網絡中的三次握手和四次揮手是TCP協議建立和終止連接的核心機制,確保數據傳輸的可靠性。
+++
一些標志:
【ACK】:用以指示確認字段中的值是有效的,即該報文段包括一個對已被成功接收的報文段的確認;
【RST】:用以指示連接的強制拆除,當接收到錯誤連接時會發送RST位置為1的報文;
【SYN】:用以指示連接的建立,該位為1的報文表示希望建立連接;
【FIN】:用以指示連接的終止,該位為1的報文表示希望斷開連接;
【seq】:序列號
首先建立連接:三次握手,目的是為了確??蛻舳撕头掌麟p方具備雙向通信能力,同步初始序列號(ISN);
- SYN(客戶端 → 服務器)
- 客戶端發送SYN報文(SYN=1,seq=x),進入
SYN-SENT狀態。 - 作用:請求建立連接,攜帶初始序列號
x。
- 客戶端發送SYN報文(SYN=1,seq=x),進入
- SYN-ACK(服務器 → 客戶端)
- 服務器收到SYN后,回復SYN-ACK報文(SYN=1,ACK=1,seq=y,ack=x+1),進入
SYN-RCVD狀態。 - 作用:確認客戶端的SYN,并發送自己的初始序列號
y。
- 服務器收到SYN后,回復SYN-ACK報文(SYN=1,ACK=1,seq=y,ack=x+1),進入
- ACK(客戶端 → 服務器)
- 客戶端回復ACK報文(ACK=1,seq=x+1,ack=y+1),進入
ESTABLISHED狀態。 - 服務器收到后也進入
ESTABLISHED狀態,連接建立。 - 作用:確認服務器的SYN,雙方確認通信正常。
- 客戶端回復ACK報文(ACK=1,seq=x+1,ack=y+1),進入
可以看出,ack標志是接收到的序列號+1
問題1:為什么需要三次?
原因有幾個,但是主要原因是防止舊的重復連接初始化造成混亂,假設只有兩次握手,客戶端發送一個舊的SYN包(比如因網絡延遲滯留的包)到服務器,服務器收到后,直接回復SYN-ACK并分配資源,進入連接狀態。如果客戶端發現這是一個舊的連接請求(比如網絡等原因導致已超時),直接忽略服務器的SYN-ACK,導致服務器一直進入連接狀態等待,浪費資源【TCP連接需要雙方分配資源,在只有兩次握手的情況下,服務器在收到SYN后立即分配資源,但客戶端可能因超時或放棄連接,導致服務器資源浪費】。所以,第三次握手時,客戶端必須回復ACK確認服務器的SYN,確保雙方資源分配是同步的,如果客戶端收到的是服務器的舊的SYN-ACK,會發送RST(重置)包終止連接,避免服務器誤開連接。
第二個原因是確保雙方通信能力對稱,第一次握手(客戶端→服務器),可以讓服務器確認客戶端的發送能力正常,自己的接收能力正常;第二次握手(服務器→客戶端),可以讓客戶端確認服務器的發送和接收能力正常,自己的接收能力正常;第三次握手(客戶端→服務器),可以讓服務器確認客戶端的接收能力正常,自己的發送能力正常。
舉個例子,比如兩個人打電話:經過三次確認后,雙方確認通信正常,開始對話
A打給B:“喂,聽得到嗎?”(SYN)
B回答:“聽到了,你能聽到我嗎?”(SYN-ACK)
A說:“能聽到!”(ACK)
+++
然后是斷開連接:四次揮手,目的是為了雙方安全關閉連接,確保所有數據傳輸完成。
- FIN(主動關閉方 → 被動關閉方)
- 主動方(如客戶端)發送FIN報文(FIN=1,seq=u),進入
FIN-WAIT-1狀態。 - 作用:聲明不再發送數據,但可接收數據。
- 主動方(如客戶端)發送FIN報文(FIN=1,seq=u),進入
- ACK(被動方 → 主動方)
- 被動方(如服務器)回復ACK(ACK=1,seq=v,ack=u+1),進入
CLOSE-WAIT狀態。 - 主動方收到后進入
FIN-WAIT-2狀態。 - 作用:確認FIN,允許被動方繼續發送剩余數據。
- 被動方(如服務器)回復ACK(ACK=1,seq=v,ack=u+1),進入
- FIN(被動方 → 主動方)
- 被動方處理完數據后,發送FIN報文(FIN=1,ACK=1,seq=w,ack=u+1),進入
LAST-ACK狀態。 - 作用:聲明被動方不再發送數據。
- 被動方處理完數據后,發送FIN報文(FIN=1,ACK=1,seq=w,ack=u+1),進入
- ACK(主動方 → 被動方)
- 主動方回復ACK(ACK=1,seq=u+1,ack=w+1),進入
TIME-WAIT狀態,等待2MSL(最大報文生存時間)。 - 被動方收到后關閉連接,主動方等待2MSL后關閉。
- 作用:確保被動方收到ACK,防止報文丟失導致重傳FIN。
- 主動方回復ACK(ACK=1,seq=u+1,ack=w+1),進入
問題1:為什么需要四次?
TCP連接是雙向的(客戶端和服務器可以同時發送和接收數據),因此關閉連接時,雙方需要獨立關閉各自的發送通道,主動關閉方(如客戶端)關閉自己的發送通道,同時,被動關閉方(如服務器)也要關閉自己的發送通道。
因為被動關閉方的剩余數據需要處理,所以其第二次揮手(ACK)和第三次揮手(FIN)必須分開發送,服務器收到客戶端的FIN時,可能仍有數據未發送完畢,需要先回復ACK確認關閉請求,然后繼續發送剩余數據,最后再發送自己的FIN。若合并為ACK+FIN,會導致服務器無法發送剩余數據,破壞數據完整性。
我們與三次握手做一下對比:在三次握手中,服務器的SYN和ACK可以合并發送(SYN-ACK),因為此時沒有數據需要處理。但是在四次揮手中,ACK和FIN的發送存在時間差(等待數據處理),因此無法合并。
但是嚯,凡是都有但是,如果被動關閉方沒有剩余數據需要發送,理論上可以將第二次揮手(ACK)和第三次揮手(FIN)合并,變為三次交互。比如說服務器收到FIN后,立即回復ACK+FIN,客戶端回復ACK。由于TCP協議標準要求嚴格處理數據完整性,因此我們還是要默認仍按四次揮手設計,確保兼容所有場景。
問題2:主動關閉方,為什么要有TIME_WAIT這個狀態?為啥是等待2MSL?
TIME_WAIT狀態是主動關閉連接的一方(發送最后一個ACK后)必須經歷的狀態,其核心目的是確保連接的可靠終止和避免新舊連接的數據混淆。如果在第四次握手中,主動關閉方最后一次ACK丟失,被動關閉方會在超時后重傳FIN,有TIME_WAIT這個狀態的話,主動關閉方在TIME_WAIT期間仍能接收該FIN,并重新發送ACK,確保被動關閉方正常關閉。如果沒有TIME_WAIT這個狀態,主動關閉方最后一次ACK丟失的話,服務端就會一直在 LAST_ACK 狀態下等待。
舊連接數據混淆是什么意思呢?假設在沒有TIME_WAIT這個狀態的情況下A --- B連接了,端口是8080,然后現在A發起關閉,經過了三次揮手了,A發起第四次揮手之后直接關閉了,由于網絡延遲原因,這個第四次揮手的ACK包要過一段時間才會到B。現在C想要來連接B,同樣端口8080,連接的時候,上次關閉連接第四次揮手的ACK包恰好在這個時候到B了,這不就是與舊連接數據混淆了嘛。
MSL 的單位是時間,TIME_WAIT 等待 2 倍的 MSL,比較合理的解釋是: 網絡中可能存在來自發送方的數據包,當這些發送方的數據包被接收方處理后又會向對方發送響應,所以一來一回需要等待 2 倍的時間。
2. Java中的網絡
Java 網絡編程是指使用 Java 語言開發基于網絡通信的應用程序,主要基于 TCP/IP 協議棧,支持從底層套接字編程到高層 Web 服務的多種網絡通信方式。此外,Java 主要關注 傳輸層(TCP/UDP)和 應用層(HTTP、FTP 等)。
2.1 BIO模型
BIO(Blocking IO) 又稱同步阻塞IO,一個客戶端由一個線程來進行處理
在net包下面,一些與網絡有關的類:
InetAddress 表示 IP 地址(IPv4 或 IPv6);
InetAddress.getByName(String host):根據主機名或文本形式的 IP 創建地址對象。
InetAddress.getLocalHost():獲取本機地址。
getHostAddress()/getHostName():分別返回字符串形式的 IP 和主機名。
ServerSocket 面向連接的服務器套接字,用于監聽并接受客戶端的 TCP 連接。
關鍵方法:
new ServerSocket(int port):在指定端口監聽。
accept():阻塞等待并返回客戶端 Socket。
setSoTimeout(int timeout):設置 accept() 的超時時間。
工作模式:主線程循環 accept(),新連接交給工作線程或線程池處理。
Socket 面向連接的客戶端套接字,用于 TCP(流式)通信
常見構造:
new Socket(String host, int port):直接建立到目標服務器的連接。
new Socket(InetAddress addr, int port)。
主要方法:
getInputStream()/getOutputStream():拿到網絡讀寫的字節流。
close():關閉連接。
與 ServerSocket 配合,實現點對點的請求-響應模型。
UDP 相關:DatagramSocket / DatagramPacket 提供無連接、不可靠的報文(數據報)通信:
DatagramPacket封裝要發送或接收的報文數據及其目的地址、端口。構造時指定字節數組、長度,接收時自動填充。
DatagramSocket,用于發送(send(packet))和接收(receive(packet)) DatagramPacket。也可通過 new DatagramSocket(port) 綁定本地端口。
MulticastSocket繼承自 DatagramSocket,用于 IP 組播(將報文發給一組訂閱者)。
joinGroup(InetAddress mcastaddr):加入組播組。
leaveGroup(InetAddress mcastaddr):離開組播組。
NetworkInterface表示本地網絡接口,如以太網卡、Wi-Fi 適配器等。
NetworkInterface.getByName(String name)、getNetworkInterfaces():列出本機所有網絡接口??刹樵兘涌跔顟B、IP 地址列表、MAC 地址等信息。
URL / URLConnection 用于簡單的基于 URL 的網絡資源訪問。
URL url = new URL("http://example.com/index.html");
URLConnection conn = url.openConnection();通過 conn.getInputStream() 讀取遠程資源;可設置請求頭、超時、緩存等。
具體子類:HttpURLConnection(HTTP 協議);JarURLConnection(訪問 JAR 內部資源)
URI 表示統一資源標識符,比 URL 更通用/輕量。支持對各部分(scheme、host、path、query、fragment)進行解析與重組。此外還可以從 URI 生成 URL,也可做路徑規范化/相對路徑解析。
簡單客戶端服務端示例:
// server.java
public class NetServer {
public static void main(String[] args) {
// ExecutorService pool = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
ExecutorService pool = Executors.newFixedThreadPool(2);
try ( ServerSocket socket = new ServerSocket(9999) ) {
while ( true ) {
Socket client = socket.accept();
pool.execute(new Handler(client));
}
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
pool.shutdown();
}
}
private static class Handler implements Runnable {
private Socket client;
public Handler(Socket client) {
this.client = client;
}
@Override
public void run() {
if ( client == null ) return;
try {
while ( true ) {
byte[] bytes = new byte[256];
int read = client.getInputStream().read(bytes);
if ( read != -1 ) {
String message = new String(bytes, 0, read);
if ( "bye".equals(message) ) break; // 斷開連接
System.out.println("客戶端發來消息:" + message);
client.getOutputStream().write("hello, 我是服務器".getBytes());
} else {
break;
}
}
} catch (IOException e) {
throw new RuntimeException(e);
} finally {
try {
if ( client != null ) client.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
}
}
// client.java
public class NetClient {
public static void main(String[] args) {
Scanner in = new Scanner(System.in);
try ( Socket client = new Socket("localhost", 9999) ) {
// 第一個線程寫東西給服務器
Thread w = new Thread(() -> {
try {
while (true) {
String msg = in.nextLine();
client.getOutputStream().write(msg.getBytes());
client.getOutputStream().flush();
if ( "bye".equals(msg) ) break;
}
} catch (IOException e) {
throw new RuntimeException(e);
}
});
w.start();
// 第二個線程讀取服務器發來的消息
Thread r = new Thread(() -> {
while (true) {
try {
byte[] bytes = new byte[256];
int read = client.getInputStream().read(bytes);
if ( read == -1 ) break;
System.out.println("【服務器】:" + new String(bytes, 0, read));
} catch (IOException e) {
throw new RuntimeException(e);
}
}
});
r.start();
w.join(); r.join();
} catch (IOException | InterruptedException e) {
throw new RuntimeException(e);
} finally {
in.close();
}
}
}
2.2 NIO模型
.........。。。我再寫的話,也只能是對他拙劣的模仿了,看他的文章,猶如久旱逢甘霖,他鄉遇故知。
建議直接看這篇文章吧,我認為無人出其右了。深入理解BIO、NIO、AIO線程模型
地址(電腦打開更佳):https://blog.csdn.net/qq_45076180/article/details/112698579
同時這篇文章也值得一看:「操作系統」什么是用戶態和內核態?為什么要區分
地址(電腦打開更佳):https://blog.csdn.net/u014571143/article/details/129660010
2.3.1 零拷貝技術
零拷貝(Zero-copy)技術指在計算機執行操作時,CPU 不需要先將數據從一個內存區域復制到另一個內存區域,從而可以減少上下文切換以及 CPU 的拷貝時間。它的作用是在數據報從網絡設備到用戶程序空間傳遞的過程中,減少數據拷貝次數,減少系統調用,實現 CPU 的零參與,徹底消除 CPU 在這方面的負載。
為什么這里要介紹一下該技術呢?那是因為在傳統的數據傳輸過程通常需要經歷多次內存拷貝。在傳輸數據的過程中,會從從磁盤讀取數據,將數據從內核空間拷貝到用戶空間,再從用戶空間拷貝到應用程序的內存中。這些額外的拷貝會消耗大量的CPU資源和內存帶寬,降低數據傳輸的效率。零拷貝就是為了避免這些不必要的數據拷貝,能夠將數據直接傳輸到目標內存區域,以提高數據傳輸的效率。如下圖(文件傳輸)所示

上圖中的DMA是什么呢?從上圖可以看到如果這四次拷貝,都要需要 CPU 親自參與搬運數據的過程,并且這個過程,CPU 是不能做其他事情的,當數據量很大的時候,CPU忙得過來嗎。所以就有了DMA,英文全稱是Direct Memory Access,即直接內存訪問。DMA本質上是一塊主板上獨立的芯片,允許外設設備和內存存儲器之間直接進行IO數據傳輸。簡單理解就是,在進行 I/O 設備和內存的數據傳輸的時候,數據搬運的工作全部交給 DMA 控制器,而 CPU 不再參與任何與數據搬運相關的事情,這樣 CPU 就可以去處理別的事務。
但是 DMA 有其局限性,DMA 僅僅能用于設備之間交換數據時進行數據拷貝,但是設備內部的數據拷貝還需要 CPU 進行,例如 CPU 需要負責內核空間數據與用戶空間數據之間的拷貝(內存內部的拷貝),如上圖中的磁盤設備與內存、網卡設備與內存,他們在電腦中是不同的設備。
如上圖【文件傳輸】,我僅僅是想要發送一份數據,卻經歷了四次上下文切換、四次數據拷貝,這樣的效率肯定是不行的,所以就要在上下文切換和拷貝次數上面做文章了。
那么,零拷貝并不是沒有拷貝數據,而是 CPU 不再全程負責數據拷貝時的搬運工作、盡可能減少用戶態/內核態的切換次數以及CPU拷貝的次數。
零拷貝技術的具體實現方式有很多,例如:
- sendfile
- mmap
- splice
- 直接 Direct I/O
+++
sendfile:它主要是用到了DMA、傳遞文件描述符代替數據拷貝: 如下圖所示
工作流程大致如下【從上圖可以看出,只有兩次上下文切換,然后CPU是0次拷貝】
- DMA從磁盤拷貝數據到內核緩沖區。
- 將內核緩沖區的數據描述符(地址、長度)直接傳遞給Socket緩沖區【可能會有CPU拷貝】。
- DMA將數據從內核緩沖區拷貝到網卡。
注意的是:只有網卡支持 SG-DMA(The Scatter-Gather Direct Memory Access)技術才可以通過傳遞文件描述符的方式避免內核空間內的一次 CPU 拷貝
+++
mmap:mmap是Linux提供的一種內存映射文件的機制,它實現了將內核中讀緩沖區地址與用戶空間緩沖區地址進行映射,從而實現內核緩沖區與用戶緩沖區的共享。這樣就減少了一次用戶態和內核態的CPU拷貝,但是在內核空間內仍然有一次CPU拷貝。
+++
splice: splice() 的主要優勢在于減少了數據拷貝的次數和數據在用戶空間和內核空間之間的來回傳輸,從而顯著提高了數據傳輸的效率。但它也有一些局限,它的兩個文件描述符參數中有一個必須是管道設備。
+++
Direct I/O: 顧名思義,數據直接存儲在用戶空間中,繞過了內核
end.參考
- 菜鳥教程 -- 【https://www.runoob.com/w3cnote/summary-of-network.html#_label0】
- https://blog.csdn.net/ymb615ymb/article/details/123449588 【tcp、udp】
- https://blog.csdn.net/weixin_45321483/article/details/117968774 【https協議】
- https://blog.csdn.net/spade_Kwo/article/details/119464901 【詳解 TCP 連接的“三次握手”與“四次揮手” ---- (好文)建議讀者閱讀】
- https://blog.csdn.net/Allen_Adolph/article/details/107117156 【TCP協議的流程圖解 ---- (好文)建議讀者閱讀】
- https://blog.csdn.net/qq_45076180/article/details/112698579 【深入理解BIO、NIO、AIO線程模型---- (好文)建議讀者閱讀】
- http://www.rzrgm.cn/xiaolincoding/p/13719610.html 【零拷貝】
- https://segmentfault.com/a/1190000044068914#item-4-4 【零拷貝--思否】

浙公網安備 33010602011771號