Wireshark TS | 發送數據超出接收窗口

前言

來自于測試中無意發現到的一個接收窗口滿的案例，特殊，或者可以說我以前都沒在實際場景中見過。一開始都沒整太明白，花了些精力才算是弄清楚了些，記錄分享下。

問題說明

在研究擁塞控制的慢啟動階段時，通過 packetdrill 寫了一個腳本，如下。

# cat tcp_troubleshooting_1_001.pkt
`ethtool -K tun0 tso offethtool -K tun0 gso off`0  socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0+0 < S 0:0(0) win 10000 <mss 1000,nop,nop,sackOK>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 10000
+0 accept(3, ..., ...) = 4+0.01 < P. 1:101(100) ack 1 win 2000
+0 > . 1:1(0) ack 101+0.01 write(4,...,4000) = 4000+0 `sleep 10`
#

TCP 三次握手中通告的 MSS 為 1000，也沒有啟用 WScale 因子，之后客戶端發送了一個數據段，其中通告了自身的 Win 為 2000，服務器也正常響應了 ACK，之后服務器端寫入了 4000 字節大小的數據包。

想象中的實驗結果應該是，由于接收端 Win 2000 限制的緣故，服務器端只能發出 2 個 1000 字節的數據包，可惜想象很美好，結果卻不一致，服務器發出了 4 個 1000 字節的數據包，無視接收窗口的限制，問題在哪？

# tcpdump -i any -nn port 8080
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:00:20.517879 tun0  In  IP 192.0.2.1.45917 > 192.168.235.30.8080: Flags [S], seq 0, win 10000, options [mss 1000,nop,nop,sackOK], length 0
22:00:20.517912 tun0  Out IP 192.168.235.30.8080 > 192.0.2.1.45917: Flags [S.], seq 2020381752, ack 1, win 64240, options [mss 1460,nop,nop,sackOK], length 0
22:00:20.528033 tun0  In  IP 192.0.2.1.45917 > 192.168.235.30.8080: Flags [.], ack 1, win 10000, length 0
22:00:20.538114 tun0  In  IP 192.0.2.1.45917 > 192.168.235.30.8080: Flags [P.], seq 1:101, ack 1, win 2000, length 100: HTTP
22:00:20.538139 tun0  Out IP 192.168.235.30.8080 > 192.0.2.1.45917: Flags [.], ack 101, win 64140, length 0
22:00:20.548217 tun0  Out IP 192.168.235.30.8080 > 192.0.2.1.45917: Flags [.], seq 1:1001, ack 101, win 64140, length 1000: HTTP
22:00:20.548221 tun0  Out IP 192.168.235.30.8080 > 192.0.2.1.45917: Flags [P.], seq 1001:2001, ack 101, win 64140, length 1000: HTTP
22:00:20.548226 tun0  Out IP 192.168.235.30.8080 > 192.0.2.1.45917: Flags [.], seq 2001:3001, ack 101, win 64140, length 1000: HTTP
22:00:20.548227 tun0  Out IP 192.168.235.30.8080 > 192.0.2.1.45917: Flags [P.], seq 3001:4001, ack 101, win 64140, length 1000: HTTP
#

問題分析

通常所說的發送窗口就是min(cwnd,rwnd)，由于初始 CWND 為 10，所以初步的判斷仍是 rwnd 的限制，但是為什么 Win 2000 沒生效，確實讓人費解。

第一步驗證 rwnd ，考慮到 No.3 和 No4 均有 Win 值，如果 Win 2000 未生效的情況，是否是受限制于上一個 Win 10000。修改腳本如下，考慮測試簡便，調整成了 3000 和 2000，仍然嘗試寫入 4000 字節大小的數據包。

# cat tcp_troubleshooting_1_002.pkt 
`ethtool -K tun0 tso offethtool -K tun0 gso off`0  socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0+0 < S 0:0(0) win 10000 <mss 1000,nop,nop,sackOK>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 3000
+0 accept(3, ..., ...) = 4+0.01 < P. 1:101(100) ack 1 win 2000
+0 > . 1:1(0) ack 101+0.01 write(4,...,4000) = 4000+0 `sleep 10`
#

可以看到服務器端發送的數據包只有 3 個，也就是受限于上一個 Win 3000，而不是最近的一個 Win 2000。

# tcpdump -i any -nn port 8080
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:30:05.357883 tun0  In  IP 192.0.2.1.40269 > 192.168.166.85.8080: Flags [S], seq 0, win 10000, options [mss 1000,nop,nop,sackOK], length 0
22:30:05.357911 tun0  Out IP 192.168.166.85.8080 > 192.0.2.1.40269: Flags [S.], seq 2967841851, ack 1, win 64240, options [mss 1460,nop,nop,sackOK], length 0
22:30:05.367982 tun0  In  IP 192.0.2.1.40269 > 192.168.166.85.8080: Flags [.], ack 1, win 3000, length 0
22:30:05.378045 tun0  In  IP 192.0.2.1.40269 > 192.168.166.85.8080: Flags [P.], seq 1:101, ack 1, win 2000, length 100: HTTP
22:30:05.378065 tun0  Out IP 192.168.166.85.8080 > 192.0.2.1.40269: Flags [.], ack 101, win 64140, length 0
22:30:05.388145 tun0  Out IP 192.168.166.85.8080 > 192.0.2.1.40269: Flags [.], seq 1:1001, ack 101, win 64140, length 1000: HTTP
22:30:05.388155 tun0  Out IP 192.168.166.85.8080 > 192.0.2.1.40269: Flags [P.], seq 1001:2001, ack 101, win 64140, length 1000: HTTP
22:30:05.388158 tun0  Out IP 192.168.166.85.8080 > 192.0.2.1.40269: Flags [.], seq 2001:3001, ack 101, win 64140, length 1000: HTTP
#

那么為什么服務器端在收到 No.4 也就是 Win 2000 的數據包后，沒有更新 rwnd ？帶著疑惑，翻了源碼和很多資料，最后才找到答案，相關發送窗口更新的處理函數為 tcp_ack_update_window -> tcp_may_update_window ，如下。

/* Check that window update is acceptable.* The function assumes that snd_una<=ack<=snd_next.*/
static inline bool tcp_may_update_window(const struct tcp_sock *tp,const u32 ack, const u32 ack_seq,const u32 nwin)
{return	after(ack, tp->snd_una) ||after(ack_seq, tp->snd_wl1) ||(ack_seq == tp->snd_wl1 && nwin > tp->snd_wnd);
}

主要有三個判斷條件，after(ack, tp->snd_una) || after(ack_seq, tp->snd_wl1) || (ack_seq == tp->snd_wl1 && nwin > tp->snd_wnd) 。

  1. after(ack, tp->snd_una)，由于 No.4 的 ACK 并沒有確認新數據，所以判斷不成立；
  2. after(ack_seq, tp->snd_wl1)，由于 No.4 的 Seq Num 和之前 snd_wl1 一樣，所以判斷也不成立；
  3. (ack_seq == tp->snd_wl1 && nwin > tp->snd_wnd) ，由于 No.4 的 Seq Num 和之前 snd_wl1 一樣，前一個成立，但是 nwin 為 2000 并不大于 snd_wnd 10000，后一個不成立，所以判斷也不成立。

綜合 return 為 0 ，也就是說并不會更新發送窗口為 2000，仍保持發送窗口為 10000，因此服務器最終是可以發出 4 個 1000 字節的數據包。

答案是找到了，但既然到這一步了，就繼續通過實驗驗證，鞏固下這個知識點。

實驗擴展

通過三個實驗驗證以上三個判斷條件，在各自條件成立的情況下，從而更新發送窗口。

  1. after(ack, tp->snd_una)

修改腳本，使得 ACK 確認新數據，如下，ACK win 2000 的 ack num 1001 確認了新數據。

# cat tcp_troubleshooting_1_003.pkt 
`ethtool -K tun0 tso offethtool -K tun0 gso off`0  socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0+0 < S 0:0(0) win 10000 <mss 1000,nop,nop,sackOK>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 10000
+0 accept(3, ..., ...) = 4+0.01 < P. 1:101(100) ack 1 win 3000
+0 > . 1:1(0) ack 101+0.01 write(4,...,1000) = 1000
+0.01 < . 101:101(0) ack 1001 win 2000+0.01 write(4,...,4000) = 4000
#

Win 2000 限制生效，服務器端僅能發出 2 個 MSS 1000 大小的數據包。

# tcpdump -i any -nn port 8080
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:55:16.017895 ?     In  IP 192.0.2.1.36917 > 192.168.24.159.8080: Flags [S], seq 0, win 10000, options [mss 1000,nop,nop,sackOK], length 0
22:55:16.017930 ?     Out IP 192.168.24.159.8080 > 192.0.2.1.36917: Flags [S.], seq 4123551004, ack 1, win 64240, options [mss 1460,nop,nop,sackOK], length 0
22:55:16.028014 ?     In  IP 192.0.2.1.36917 > 192.168.24.159.8080: Flags [.], ack 1, win 10000, length 0
22:55:16.038118 ?     In  IP 192.0.2.1.36917 > 192.168.24.159.8080: Flags [P.], seq 1:101, ack 1, win 3000, length 100: HTTP
22:55:16.038154 ?     Out IP 192.168.24.159.8080 > 192.0.2.1.36917: Flags [.], ack 101, win 64140, length 0
22:55:16.048290 ?     Out IP 192.168.24.159.8080 > 192.0.2.1.36917: Flags [P.], seq 1:1001, ack 101, win 64140, length 1000: HTTP
22:55:16.058342 ?     In  IP 192.0.2.1.36917 > 192.168.24.159.8080: Flags [.], ack 1001, win 2000, length 0
22:55:16.068472 ?     Out IP 192.168.24.159.8080 > 192.0.2.1.36917: Flags [.], seq 1001:2001, ack 101, win 64140, length 1000: HTTP
22:55:16.068479 ?     Out IP 192.168.24.159.8080 > 192.0.2.1.36917: Flags [P.], seq 2001:3001, ack 101, win 64140, length 1000: HTTP
#
  1. after(ack_seq, tp->snd_wl1)

修改腳本，使得 ACK Seq num 101 更新，大于之前的 snd_wl1 1 。

# cat tcp_troubleshooting_1_004.pkt 
`ethtool -K tun0 tso offethtool -K tun0 gso off`0  socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0+0 < S 0:0(0) win 10000 <mss 1000,nop,nop,sackOK>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 10000
+0 accept(3, ..., ...) = 4+0.01 < P. 1:101(100) ack 1 win 3000
+0 > . 1:1(0) ack 101+0.01 < P. 101:201(100) ack 1 win 2000
+0 > . 1:1(0) ack 201+0.01 write(4,...,4000) = 4000
#

Win 2000 限制生效，服務器端僅能發出 2 個 MSS 1000 大小的數據包。

# tcpdump -i any -nn port 8080
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
23:00:54.817885 tun0  In  IP 192.0.2.1.49051 > 192.168.214.190.8080: Flags [S], seq 0, win 10000, options [mss 1000,nop,nop,sackOK], length 0
23:00:54.817913 tun0  Out IP 192.168.214.190.8080 > 192.0.2.1.49051: Flags [S.], seq 2399892350, ack 1, win 64240, options [mss 1460,nop,nop,sackOK], length 0
23:00:54.827992 ?     In  IP 192.0.2.1.49051 > 192.168.214.190.8080: Flags [.], ack 1, win 10000, length 0
23:00:54.838065 ?     In  IP 192.0.2.1.49051 > 192.168.214.190.8080: Flags [P.], seq 1:101, ack 1, win 3000, length 100: HTTP
23:00:54.838084 ?     Out IP 192.168.214.190.8080 > 192.0.2.1.49051: Flags [.], ack 101, win 64140, length 0
23:00:54.848151 ?     In  IP 192.0.2.1.49051 > 192.168.214.190.8080: Flags [P.], seq 101:201, ack 1, win 2000, length 100: HTTP
23:00:54.848170 ?     Out IP 192.168.214.190.8080 > 192.0.2.1.49051: Flags [.], ack 201, win 64040, length 0
23:00:54.858248 ?     Out IP 192.168.214.190.8080 > 192.0.2.1.49051: Flags [.], seq 1:1001, ack 201, win 64040, length 1000: HTTP
23:00:54.858252 ?     Out IP 192.168.214.190.8080 > 192.0.2.1.49051: Flags [P.], seq 1001:2001, ack 201, win 64040, length 1000: HTTP
#
  1. (ack_seq == tp->snd_wl1 && nwin > tp->snd_wnd)

修改腳本，使得 nwin 3000 大于 snd_wnd 2000。

# cat tcp_troubleshooting_1_005.pkt 
`ethtool -K tun0 tso offethtool -K tun0 gso off`0  socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0+0 < S 0:0(0) win 10000 <mss 1000,nop,nop,sackOK>
+0 > S. 0:0(0) ack 1 <...>
+0.01 < . 1:1(0) ack 1 win 2000
+0 accept(3, ..., ...) = 4+0.01 < P. 1:101(100) ack 1 win 3000
+0 > . 1:1(0) ack 101+0.01 write(4,...,4000) = 4000
#

Win 3000 限制生效，服務器端能發出 3 個 MSS 1000 大小的數據包。

# tcpdump -i any -nn port 8080
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
23:03:00.017903 ?     In  IP 192.0.2.1.34617 > 192.168.35.60.8080: Flags [S], seq 0, win 10000, options [mss 1000,nop,nop,sackOK], length 0
23:03:00.017940 ?     Out IP 192.168.35.60.8080 > 192.0.2.1.34617: Flags [S.], seq 3161188315, ack 1, win 64240, options [mss 1460,nop,nop,sackOK], length 0
23:03:00.028034 ?     In  IP 192.0.2.1.34617 > 192.168.35.60.8080: Flags [.], ack 1, win 2000, length 0
23:03:00.038103 ?     In  IP 192.0.2.1.34617 > 192.168.35.60.8080: Flags [P.], seq 1:101, ack 1, win 3000, length 100: HTTP
23:03:00.038126 ?     Out IP 192.168.35.60.8080 > 192.0.2.1.34617: Flags [.], ack 101, win 64140, length 0
23:03:00.048222 ?     Out IP 192.168.35.60.8080 > 192.0.2.1.34617: Flags [.], seq 1:1001, ack 101, win 64140, length 1000: HTTP
23:03:00.048232 ?     Out IP 192.168.35.60.8080 > 192.0.2.1.34617: Flags [P.], seq 1001:2001, ack 101, win 64140, length 1000: HTTP
23:03:00.048235 ?     Out IP 192.168.35.60.8080 > 192.0.2.1.34617: Flags [.], seq 2001:3001, ack 101, win 64140, length 1000: HTTP
#

問題總結

實際中的場景，你們是否有見過，感覺奇奇怪怪的知識又增加了。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/web/90812.shtml
繁體地址，請注明出處：http://hk.pswp.cn/web/90812.shtml
英文地址，請注明出處：http://en.pswp.cn/web/90812.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

C語言自定義數據類型詳解（四）——聯合體

C語言自定義數據類型詳解（四）——聯合體

好的&#xff0c;接下來我們來學習最后一個自定義數據類型——聯合體。 一、什么是聯合體&#xff1a; 聯合體又叫共用體&#xff0c;用關鍵字union來進行定義。又因為所有的成員變量共用同一段內存空間&#xff08;關于這一點&#xff0c;我們不久就會加以驗證&#xff09;&…
閱讀更多...
[python][flask]Flask-Login 使用詳解

[python][flask]Flask-Login 使用詳解

1. 簡介Flask-Login 是 Flask 的一個擴展&#xff0c;專門用于處理用戶認證相關的功能。它提供了用戶會話管理、登錄/注銷視圖、記住我功能等常見認證需求&#xff0c;讓開發者能夠快速實現安全的用戶認證系統。2. 安裝與基礎配置首先&#xff0c;需要安裝 Flask-Login&#xf…
閱讀更多...
【WebGPU學習雜記】WebAssembly中的relaxed_madd指令到底做了什么？

【WebGPU學習雜記】WebAssembly中的relaxed_madd指令到底做了什么？

relaxed_madd 這條指令到底做了什么核心&#xff1a;relaxed_madd 是一個分量級別 (Component-wise) 的操作 首先&#xff0c;最重要的一點是&#xff1a;v128.relaxed_madd<f32>(a, b, c) 不是矩陣乘法。它是一個在三個向量 a, b, c 之間進行的、逐個分量的、并行的融合…
閱讀更多...
【全新上線】境內 Docker 鏡像狀態監控

【全新上線】境內 Docker 鏡像狀態監控

境內 Docker 鏡像狀態監控&#xff1a;您的 Docker 加速伴侶 在當今云計算和容器化技術飛速發展的時代&#xff0c;Docker 已成為開發者不可或缺的工具。然而&#xff0c;對于身處國內的用戶而言&#xff0c;訪問境外 Docker Hub 等鏡像倉庫時常會遭遇網絡延遲和連接不穩定的困…
閱讀更多...
Visual Studio中部署PaddleOCRv5 (借助ncnn框架）

Visual Studio中部署PaddleOCRv5 (借助ncnn框架）

PaddleOCRv5_ncnn PaddleOCRv5 在Visual Studio中進行圖片OCR檢測&#xff08;ncnn框架open-mobile實現)&#xff0c;嘗試對nihui的ncnn-android-ppocrv5檢測算法的剝離與移植。 本項目Github鏈接如下&#xff1a;PaddleOCRv5_ncnn 寫在前面 本倉庫代碼是基于nihui的ncnn-a…
閱讀更多...
中級全棧工程師筆試題

中級全棧工程師筆試題

解釋ACID特性&#xff0c;如何在node.js中實現事務操作針對React單頁應用&#xff0c;請提供至少5種性能優化方案&#xff0c;并解釋其原理&#xff1a; 減少首屏加載時間優化渲染性能資源加載策略狀態管理優化代碼分割方案 如何防止以下攻擊&#xff1a; JWT令牌挾持Graph QL查…
閱讀更多...
Windows---動態鏈接庫Dynamic Link Library（.dll）

Windows---動態鏈接庫Dynamic Link Library（.dll）

DLL的“幕后英雄”角色 在Windows操作系統的生態中&#xff0c;有一類文件始終扮演著“幕后英雄”的角色——它們不像.exe文件那樣直接呈現為用戶可見的程序窗口&#xff0c;卻支撐著幾乎所有應用程序的運行&#xff1b;它們不單獨執行&#xff0c;卻承載著系統與軟件的核心功…
閱讀更多...
深入分析計算機網絡傳輸層和應用層面試題

深入分析計算機網絡傳輸層和應用層面試題

三、傳輸層面試題&#xff08;Transmission Layer&#xff09;傳輸層位于 OSI 七層模型的第四層&#xff0c;它的核心任務是為兩個主機之間的應用層提供可靠的數據傳輸服務。它不僅承擔了數據的端到端傳輸&#xff0c;而且還實現了諸如差錯檢測、數據流控制、擁塞控制等機制&am…
閱讀更多...
【RH134 問答題】第 2 章 調度未來任務

【RH134 問答題】第 2 章 調度未來任務

目錄crontab 文件中的用戶作業時間格式怎么解釋&#xff1f;如果需要以當前用戶身份計劃周期性作業&#xff0c;在上午 8 點到晚上 9 點之間每兩分鐘一次輸出當前日期和時間&#xff0c;該作業只能在周一到周五運行&#xff0c;周六或周日不能運行。要怎么做&#xff1f;要計劃…
閱讀更多...
【ee類保研面試】通信類---信息論

【ee類保研面試】通信類---信息論

25保研er&#xff0c;希望將自己的面試復習分享出來&#xff0c;供大家參考 part0—英語類 part1—通信類 part2—信號類 part3—高數類 part100—self項目準備 文章目錄**面試復習總綱****Chap2: 熵、相對熵和互信息 (Entropy, Relative Entropy, and Mutual Information)****…
閱讀更多...
vue2+node+express+MongoDB項目安裝啟動啟動

vue2+node+express+MongoDB項目安裝啟動啟動

文章目錄 準備環境 安裝MongoDB 安裝 MongoDB Compass（圖形化數據庫管理工具） 安裝 Postman（接口測試工具） 項目結構 配置項目代理 項目啟動 提交項目 生成Access Token 準備環境 默認含有node.js、npm 安裝MongoDB 下載地址：https://www.mongodb.com/try/download/com…
閱讀更多...
JavaEE初階第十二期：解鎖多線程，從 “單車道” 到 “高速公路” 的編程升級（十）

JavaEE初階第十二期：解鎖多線程，從 “單車道” 到 “高速公路” 的編程升級（十）

專欄&#xff1a;JavaEE初階起飛計劃 個人主頁&#xff1a;手握風云 目錄 一、多線程案例 1.1. 定時器 一、多線程案例 1.1. 定時器 定時器是軟件開發的一個重要組件&#xff0c;是一種能夠按照預設的時間間隔或在特定時間點執行某個任務或代碼片段的機制。你可以把它想象成…
閱讀更多...
EDoF-ToF: extended depth of field time-of-flight imaging解讀, OE 2021

EDoF-ToF: extended depth of field time-of-flight imaging解讀, OE 2021

1. 核心問題&#xff1a;iToF相機的“景深”死穴我們之前已經詳細討論過&#xff0c;iToF相機的“景深”&#xff08;有效測量范圍&#xff09;受到光學散焦的嚴重制約。問題根源&#xff1a; 當iToF相機的鏡頭散焦時&#xff0c;來自場景不同深度的光信號會在傳感器像素上發生…
閱讀更多...
符號引用與直接引用：概念對比與實例解析

符號引用與直接引用：概念對比與實例解析

符號引用與直接引用&#xff1a;概念對比與實例解析 符號引用和直接引用是Java虛擬機(JVM)中類加載與執行機制的核心概念&#xff0c;理解它們的區別與聯系對于深入掌握Java運行原理至關重要。下面我將從定義、特性、轉換過程到實際應用&#xff0c;通過具體示例全面比較這兩類…
閱讀更多...
每日一講——Podman

每日一講——Podman

一、概念1、定義與定位Podman&#xff08;Pod Manager&#xff09;是符合OCI標準的容器引擎&#xff0c;用于管理容器、鏡像及Pod&#xff08;多容器組&#xff09;。它無需守護進程&#xff08;Daemonless&#xff09;&#xff0c;直接通過Linux內核功能&#xff08;如命名空間…
閱讀更多...
Spring Boot DFS、HDFS、AI、PyOD、ECOD、Junit、嵌入式實戰指南

Spring Boot DFS、HDFS、AI、PyOD、ECOD、Junit、嵌入式實戰指南

Spring Boot分布式文件系統 以下是一些關于Spring Boot分布式文件系統（DFS）的實現示例和關鍵方法，涵蓋了不同場景和技術的應用。這些示例可以幫助理解如何在Spring Boot中集成DFS（如HDFS、MinIO、FastDFS等）或模擬分布式存儲。 使用Spring Boot集成HDFS 基礎配置 // 配…
閱讀更多...
解決GoLand運行go程序報錯：Error: Cannot find package xxx 問題

解決GoLand運行go程序報錯：Error: Cannot find package xxx 問題

問題描述 一個簡單的go程序&#xff0c;代碼如下 package mainimport "fmt" func main() {// 占位符&#xff0c;和java的String.format用法一樣fmt.Printf("我%d歲&#xff0c;我叫%s", 18, "yexindong") }結構如下當我想要運行時卻報錯 Error:…
閱讀更多...
Spring MVC設計精粹：源碼級架構解析與實踐指南

Spring MVC設計精粹：源碼級架構解析與實踐指南

文章目錄一、設計哲學&#xff1a;分層與解耦1. 前端控制器模式2. 分層架構設計二、核心組件源碼解析1. DispatcherServlet - 九大組件初始化2. DispatcherServlet - 前端控制器&#xff08;請求處理中樞&#xff09;請求源碼入口&#xff1a;FrameworkServlet#doGet()請求委托…
閱讀更多...
k8s之控制器詳解

k8s之控制器詳解

1.deployment&#xff1a;適用于無狀態服務1.功能(1)創建高可用pod&#xff08;2&#xff09;滾動升級/回滾&#xff08;3&#xff09;平滑擴容和縮容2.操作命令&#xff08;1&#xff09;回滾# 回滾到上一個版本 kubectl rollout undo deployment/my-app# 回滾到特定版本&…
閱讀更多...
.NET Core中的配置系統

.NET Core中的配置系統

傳統配置方式文件Web.config 進行配置。ConfigurationManager類配置。.NET配置系統中支持配置方式文件配置&#xff08;json、xml、ini等&#xff09;注冊表環境變量命令行自定義配置源Json文件配置方式實現步驟&#xff1a;創建一個json文件&#xff0c;把文件設置 為“如果較…
閱讀更多...
最新文章

Copyright @ 2022~2023