前言

来自于测试中无意发现到的一个接收窗口满的案例，特殊，或者可以说我以前都没在实际场景中见过。一开始都没整太明白，花了些精力才算是弄清楚了些，记录分享下。

问题说明

在研究拥塞控制的慢启动阶段时，通过 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