sack-shift-sacked-rack test
还是同样的脚本:
// Test shifting of newly-SACKed ranges onto the previous already-SACKed skb. // This variant tests non-FACK SACK with SACKs coming in the order // 2 6 8 3 9, to test what happens when we get a new SACKed range // (for packet 3) that is on the right of an existing SACKed range // (for packet 2). `../common/defaults.sh` // Establish a connection and send 10 MSS. 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 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7> +0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8> +.1 < . 1:1(0) ack 1 win 1024 +0 accept(3, ..., ...) = 4 +0 write(4, ..., 10000) = 10000 +0 > P. 1:10001(10000) ack 1 +.1 < . 1:1(0) ack 1 win 257 <sack 2001:3001,nop,nop> +.001 < . 1:1(0) ack 1 win 257 <sack 2001:3001 6001:7001,nop,nop> +0 %{ print("1---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% +.001 < . 1:1(0) ack 1 win 257 <sack 2001:3001 6001:7001 8001:9001,nop,nop> +0 %{ print("2---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // 3 SACKed packets, so we enter Fast Recovery. +0 > . 1:1001(1000) ack 1 +0 %{ assert tcpi_ca_state == TCP_CA_Recovery, tcpi_ca_state }% // +0 %{ assert tcpi_lost == 6, tcpi_lost }% +0 %{ print("3---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // SACK for 3001:4001. // This SACK for an adjacent range causes the sender to // shift the newly-SACKed range onto the previous skb. +.007 < . 1:1(0) ack 1 win 257 <sack 2001:4001 6001:7001 8001:9001,nop,nop> +0 > . 1001:2001(1000) ack 1 // +0 %{ assert tcpi_lost == 5, tcpi_lost }% +0 %{ assert tcpi_reordering == 6, tcpi_reordering }% // 8001:9001 -> 3001:4001 is 6 +0 %{ print("4---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // SACK for 9001:10001. +.01 < . 1:1(0) ack 1 win 257 <sack 2001:4001 6001:7001 8001:10001,nop,nop> // +0 %{ assert tcpi_lost == 5, tcpi_lost }% //3526 +0 %{ print("5---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // ACK for 1:1001 as packets from t=0.303 arrive. +.083 < . 1:1(0) ack 1001 win 257 <sack 2001:4001 6001:7001 8001:10001,nop,nop> // +0 %{ assert tcpi_lost == 4,tcpi_lost }% +0 %{ print("6---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // ACK for 1:4001 as packets from t=0.310 arrive. +.017 < . 1:1(0) ack 4001 win 257 <sack 6001:7001 8001:10001,nop,nop> // +0 %{ assert tcpi_lost == 3,tcpi_lost }% +0 %{ print("7---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // ACK for 1:7001 as packets from t=0.320 arrive. +.01 < . 1:1(0) ack 7001 win 257 <sack 8001:10001,nop,nop> +0 %{ print("8---tcpi_ca_state:", tcpi_ca_state, "tcpi_sacked:", tcpi_sacked, "tcpi_lost:", tcpi_lost, "tcpi_reordering:", tcpi_reordering) }% // ACK for all data as packets from t=0.403 arrive. +.1 < . 1:1(0) ack 10001 win 257 +0 %{ assert tcpi_ca_state == TCP_CA_Open, tcpi_ca_state assert tcpi_unacked == 0, tcpi_unacked assert tcpi_sacked == 0, tcpi_sacked assert tcpi_lost == 0, tcpi_lost assert tcpi_retrans == 0, tcpi_retrans }% //+0 `sleep 1000000`
来分析内核协议栈:
主要区别就是lost计算了,由于开启了fack;所以进入disorderde 的时候;
//如果不进入 Recovery 状态,判断可否进入 OPen 状态。 if (!tcp_time_to_recover(sk, flag)) { tcp_try_to_open(sk, flag);//如果不进入 Recovery 状态,判断可否进入 OPen 状态。 //此时判断存在left_out =tp->sacked_out + tp->lost_out;数据或者被sack或者存在 retrans_out 数据;则设置为disorder状态 //否者进入open状态 return; } 就会调用tcp_try_to_open 进入disorder //由于此时开启了rack 且lost_oput=0 static bool tcp_time_to_recover(struct sock *sk, int flag) { struct tcp_sock *tp = tcp_sk(sk); /* Trick#1: The loss is proven. */ if (tp->lost_out) // return true; /* Not-A-Trick#2 : Classic rule... 由于此时开启了rack 不会进入*/ if (!tcp_is_rack(sk) && tcp_dupack_heuristics(tp) > tp->reordering) return true; return false; }
所以:tcpi_ca_state: 1 tcpi_sacked: 2 tcpi_lost: 0 tcpi_reordering: 3
当收到<sack 2001:3001 6001:7001 8001:9001,nop,nop>的时候;调用逻辑为:
也就是会调用tcp_rack_mark_lost 标记lost数据;rack原理标记最新 sak前面的报文也就是< 8001:9001 ;那么1-1000 1001-2001 3001-4001 4001-5001 5001-6001 7001-8001一共6个报文
所以此时为2---tcpi_ca_state: 3 tcpi_sacked: 3 tcpi_lost: 6 tcpi_reordering: 3
tcp_identify_packet_loss(sk, ack_flag); tcp_enter_recovery(sk, ece_ack); fast_rexmit = 1; tcp_update_scoreboard(sk, fast_rexmit);
static void tcp_identify_packet_loss(struct sock *sk, int *ack_flag) { struct tcp_sock *tp = tcp_sk(sk); if (tcp_rtx_queue_empty(sk)) return; if (unlikely(tcp_is_reno(tp))) {//对于Reno/NewReno-TCP tcp_newreno_mark_lost(sk, *ack_flag & FLAG_SND_UNA_ADVANCED); } else if (tcp_is_rack(sk)) {//启用RACK算法的TCP u32 prior_retrans = tp->retrans_out; tcp_rack_mark_lost(sk); //如果之前的重传报文数量大于当前的重传数量,表明丢失了部分重传报文,设置FLAG_LOST_RETRANS标志。 if (prior_retrans > tp->retrans_out) *ack_flag |= FLAG_LOST_RETRANS;// 表示有部分重传报文丢失,现在重传报文也 } }
后面的逻辑和前面一样。
http代理服务器(3-4-7层代理)-网络事件库公共组件、内核kernel驱动 摄像头驱动 tcpip网络协议栈、netfilter、bridge 好像看过!!!!
但行好事 莫问前程
--身高体重180的胖子
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
2020-12-18 http 校验参考文档