targetcli块设备
服务端配置
1 | yum install -y targetcli |
scst
1 | rpm -i scst-4.19.90-52.23.v2207.gfb08.ky10.aarch64-3.7.0-1.ky10.src.rpm |
1 | iscsiadm -m node -T iqn.2025-09.local:ramdisk.target -p 10.152.1.205 --logout |
服务端配置
1 | [root@node205]# yum install -y targetcli |
1 | rpm -i scst-4.19.90-52.23.v2207.gfb08.ky10.aarch64-3.7.0-1.ky10.src.rpm |
1 | iscsiadm -m node -T iqn.2025-09.local:ramdisk.target -p 10.152.1.205 --logout |
关闭防火墙
关闭SELinux
关闭NetworkManager
1 | systemctl stop NetworkManager |
ssh配置
1 | ``` |
1 | yum install -y nfs-utils rpcbind |
1 | mount -t nfs 192.168.100.191:/home/nfs /mnt -o proto=tcp -o nolock |
https://luyuhuang.tech/2020/12/09/kcp.html
https://zhuanlan.zhihu.com/p/10153049382
调用 ikcp_send 发送数据,创建报文段实例,加入 snd_queue 中
ikcp_update 会在合适的时刻调用 ikcp_flush。
在 ikcp_flush 中:
snd_queue 移入 发送缓冲snd_buf 中snd_buf 中满足条件的报文段发送出去:snd_buf 中,从未被发送过的报文对端收到报文后,icp_input 会被调用,解析收到的数据
所有的报文都有 una 字段,根据una将相应的报文标为送达
如果是 ACK 报文, 就将相应的报文标记为已送达
如果是数据报文, 就将它放入 rcv_buf, 然后将 rcv_buf 中顺序正确的报文移入 rcv_queue
接着将相关信息插入 ACK 列表, 在稍后的 ikcp_flush 调用中会发送相应的 ACK;
如果是窗口探测报文, 就标记 “需要发送窗口通知”. 在稍后的 ikcp_flush 调用中会发送窗口通知报文;
包括窗口通知报文在内的所有报文都有 wnd 字段, 据此更新 rmt_wnd;(对端窗口大小)
根据 ACK 失序情况决定快速重传
计算cwnd
调用 ikcp_recv 接收数据,从 rcv_queue 中读取数据
对端发送ACK报文给发送方
发送方在 ikcp_input 中解析到ACK,将相应报文标为已送达
队列中的报文都是有序的(发送队列与接收队列都是)
缓冲区与滑动窗口相关
snd_buf 是一个链表,链表中的报文段编号始终递增
两个指针
snd_una 指针指向第一个已经发出但未收到ACK的报文段
小于该una的报文,均已收到ACK,
在发送缓冲区 snd_buf 中,已经收到ACK的报文段会被删除
snd_nxt 指向缓冲区的下一个插入位置
发送窗口 cwnd 的起始位置是 snd_una 指针指向的位置,大小为 cwnd
flush时,会从 snd_queue 中取出报文,并从 snd_nxt 指向的位置开始插入 snd_buf ,然后 snd_nxt 向右移动
当 snd_nxt - snd_una >= cwnd 时,不允许新的报文加入 snd_buf ,
发送窗口中未确认到达的报文何时重传,取决于这个报文的RTO,报文在一个RTO时间内仍未被确认,则重传
rx_rto在 KCP 的实现中, rcv_buf 是一个报文段链表,链表中报文段编号始终递增。当收到新的报文时,会根据编号插入到链表中相应的位置中。顺序正确的报文会从链表头部弹出, 移动到 rcv_queue 中。
nrcv_que 为接收队列的长度,rcv_buf 中在 rcv_nxt 之前的报文段都将移入 rcv_queue 中nrcv_que 个报文,读取后删除该报文,接收窗口向右滑动指针 rcv_nxt :指向编号最小的未收到报文应插入的位置,即已收到最小编号的报文之前
rcv_buf 对应的位置。然后,检查 rcv_nxt 是否可向右移动,仅当报文顺序正确且连续才能移动KCP会通知发送方,剩余的接收窗口大小 rcv_wnd-nrcv_queue
如果收到的数据报文编号大于 rcv_nxt+rcv_wnd ,远超接收窗口,这个报文会被丢弃
报文中,会携带报文发送者的接收缓冲区 rcv_buf 中还未收到的最小报文编号——rcv_nxt
rcv_nxt具有ACK+UNA的双重确认机制
t1:发送una=1的报文,该报文被加入发送缓冲区
snd_una 指向1,snd_nxt 指向2t2-t3:依次发送2至3号报文,snd_nxt 依次后移
t4:对端收到3号报文,放入 rcv_buf 中,发送3号报文的ACK报文
t5:对端收到2号报文,放入rcv_buf 中,发送2号报文的ACK报文
t7:收到2号报文的ACK报文,将2号报文标为已送达,送 snd_buf 中移除
ACK报文的una为1,标识rcv_nxt指向1,对端还未收到una=1的报文,因此发送方知道需要重发
snd_una 仍为1
t8:重发1号报文,
t9:1号报文到达对端,对端发送1号报文的ACK
t10:发送方收到1号报文的ACK报文,将1号报文标为发送成功,同时una=4,所以也将3号报文标为已收到,snd_una 移动到4
每个报文的RTO会随着重传次数的增加而增加
初始值保存在 rx_rto 中,
KCP计算RTO初始值的方法是TCP的标准方法,在RFC 6298中
计算所依赖的两个中间量,$srtt$ (对一段时间内RTT均值的估计)与 $rttvar$ (对 RTT 平均偏差的估计)
每收到一个ACK都能得到一个RTT,然后更新中间变量,得出RTO
其中,$g=\frac{1}{8}$ 与 $h=\frac{1}{4}$ 为常数,$interval$ 为计时器粒度(调用 ikcp_flush 的时间间隔)
RTO至少为一个时钟间隔
初始值,测得第一个RTT时对srtt和rttvar初始化
发送方不能无限制地发送数据,否则必然会导致网络与缓冲区无法容纳发送的数据,导致大量丢包
拥塞控制,实际上是动态计算发送窗口大小的过程
慢启动:理想情况下, 发送数据的速率正好等于网路的容量, 然而我们并不知道网路的实际容量. 我们的做法是先将 cwnd 设为 1, 随后平均每经过一个 RTT 时间 cwnd 都翻一倍, 以探测到何时会出现丢包. 这种方法便是慢启动.
在慢启动中 cwnd 会指数增长, 这个过程显然不能一直持续下去. 当 cwnd 超过一个阈值之后, 便会进入拥塞避免阶段. 这个阈值我们称为慢启动阈值(Slow Start Threshold), 通常记作 ssthresh
在拥塞避免阶段, cwnd 会近似于线性增长.
随着 cwnd 的增长, 网路容量会被逐步填满
网络容量填满之后, 就会不可避免地出现丢包. 这就意味着我们的发送速率过大, cwnd 应该减小了. KCP 称之为丢包退让。此时有两种策略:
一种是将 ssthresh 置为当前 cwnd 的一半, 然后 cwnd 置为 1, 重新执行慢启动
将 ssthresh 置为当前 cwnd 的一半, 但 cwnd 置为比 ssthresh 稍高的值, 然后进入快速恢复阶段
快速恢复阶段中, cwnd 会以与拥塞避免相同的方式线性增长
KCP 采用的策略是, 如果发生超时重传, 就进入慢启动; 如果发生快速重传, 就进入快速恢复.
rmt_wnd.慢启动时, 平均每经过一个 RTT 时间 cwnd 都翻一倍
在拥塞避免阶段, 差不多要等当前发送窗口发的报文都确认到达之后, cwnd 才增加 1.
在 KCP 的实现中, 拥塞避免阶段的 cwnd 仍然会在每收到一个 ACK 的时候增长, 只不过不是增加 1, 而是增加零点几.
KCP 的做法是维护一个中间变量 incr,计算方式为诶
当 incr 累计增加的值超过一个 mss 时, cwnd 增加 1

实际上相当于每收到一个 ACK, cwnd 都自增 $\frac{1}{cwnd}$ ,即要等当前发送窗口发的报文都确认到达之后, cwnd 才增加 1.
去掉 $\frac{mss}{16}$ 即为TCP拥塞避免阶段cwnd的增长方式
| 特性类别 | 协议 | 描述 |
|---|---|---|
| 拥塞控制机制 | TCP | 固定算法(慢启动、拥塞避免等),保守的调整策略(指数和线性增长) |
| KCP | 灵活算法,动态调整策略,快速调整窗口大小 | |
| 重传机制的延迟 | TCP | 固定重传间隔(RTO),多次确认触发重传,需要主动开启选择性重传(SACK) |
| KCP | 快速重传,选择性重传,减少重传延迟 | |
| 流量控制 | TCP | 固定流量控制(依赖接收窗口和发送窗口),通用性设计 |
| KCP | 自适应流量控制,应用层反馈调整发送窗口和重传策略 | |
| 应用场景 | TCP | 广泛应用于各种网络环境,标准化要求高 |
| KCP | 优化特定场景(如高丢包率和高延迟网络),灵活实现 |
TCP 作为一种成熟且广泛使用的传输协议,在设计上注重可靠性和通用性,因此在拥塞控制和流量控制方面相对保守,以确保在各种网络条件下都能稳定运行。
拥塞控制机制
重传机制的延迟
应用场景的差异
TCP
广泛应用:TCP 设计用于广泛的网络环境,包括稳定的有线网络和不稳定的无线网络,因此其机制必须足够通用和保守,保证在各种情况下的可靠性。
标准化要求:作为互联网的基础协议,TCP 的各项机制经过严格标准化,任何修改都需要广泛测试和验证,以确保不会影响现有网络的稳定性。
KCP
特定优化:KCP 设计初衷是优化特定场景下的传输性能,特别是高丢包率和高延迟网络,因此在设计上更加灵活,能够根据实时网络状况进行调整。
灵活实现:KCP 可以根据具体应用需求进行优化,例如在实时通信和在线游戏等场景中,灵活的流量控制和快速重传机制显著提升了传输效率。
可以利用这个函数构建高效的事件驱动网络程序
1 | // 示例:管理多个RUDP连接的调度器 |
[TOC]
[TOC]
- 基本的文件权限与目录配置(Linux是多用户多任务的环境,文件权限的管理很重要)
- Linux文件与目录管理
- 用户身份
- 磁盘与文件系统管理
- 挂载、虚拟内存容量扩充
- 文件的压缩与打包
计算机概论与Linux简介
- 计算机概论
Linux介绍与版本
Linux的规划与安装
- Linux与硬件平台密切相关
规划硬件与Linux安装
- 主机规划与磁盘分区
- 安装CentOS、多重引导
简单使用
帮助手册
- 文本编辑器
- 关机
Linux用户管理
- 账号规则与ACL权限控制
- 主机的系统与程序的管理
- 磁盘配额(Quota)与文件系统管理
- 工作调度
- 程序管理与SELinux
Linux系统管理员
- 系统服务daemon
- 开关机流程、模块管理、loader,登录文件
- 网络设置与备份策略
- 软件安装
- 源码、Tarball
- RPM、SRPM与YUM
- 图形窗口 X Window
- 内核编译
[TOC]
[TOC]