尧图网站建设 
滑动窗口的本质两个 int 和一个环形数组我的github(https://github.com/xcx55/ubuntu-linux-project)感谢各位大佬参观我的github源笔记TCP 滑动窗口326-9-28、TCP4 滑动窗口本质拆解26-9-29、滑动窗口以及流量控制本质26-9-29可靠性靠序号和重传解决了但效率怎么办等一个应答再发下一批慢得没法看。滑动窗口就是 TCP 的效率答案一批一批地发不等应答。这一篇拆到最后会发现——这么大名鼎鼎的机制本质就是两个 int。一、先说它解决什么滑动窗口策略就是序号策略一批一批发不等应答、连续发送滑动窗口的数据 可以暂时不收应答、直接发送数据的区域滑动窗口是发送缓冲区的一部分。它和流量的关系流量控制为了降低无意义的网络资源消耗——对面内存快满了还猛发只会导致重传纯属浪费。二、窗口有多大16 位不够加因子复习报头窗口大小字段是 16 位 → 最大 65535也就是 64KB。显然不够高带宽长距离的链路64KB 根本喂不饱。怎么破——选项字段里有一个参数可以让 16 位的数字左移M 扩大因子把 16 位窗口值放大 M 位窗口就能撑到远超 64KB。所以三次握手时除了交换序号也交换窗口——这是连接建立时就要谈好的参数。三、物理载体是 sk_buff 队列本质却是两个 int这里有个漂亮的认知跳跃物理上一个 sk_buff 队列就是发送缓冲结构——结构体数组管理报文数据报文的顺序无所谓只要有索引即可但笔记里一句反思把真相挖了出来滑动窗口不适宜用 sk_buff 来管理——它是以缓冲区的字节流管理的那么滑动窗口的本质是什么结构就是表示 sk_buff 下标的int start和int end——两个字段为什么因为sk_buff 那一套适合 IP 层面向报文而 TCP 传输层是面向字节流的。字节流的本质是每个字节都有编号那么窗口就是一段编号区间滑动窗口 [start, end) // end start win滑动窗口就这样被具体化成了两个整型变量。四、动态更新接收端在远程操控你的窗口窗口不是定死的每个 ACK 回来都会更新start 确认序号 // ACK 给出的下一个期望编号 end start win // win 来自 ACK 报头对面报出的接收能力所以笔记的结论是相当于接收端在远程控制滑动窗口Start 确认序号end win start。它的可靠性来自接收端一定可以收下这个保证返回的确认序号 发送端 start_win返回的可用窗口大小 win——第二段数据是可以直接发送的因为这是接收端在上一个 ACK 里商量的窗口空间一定够对方接收窗口不变我们的滑动窗口大小也不会变。五、两条铁律不能左滑、不能缩小1、start 只会变大或者不变不会变小——滑动窗口不可能左滑一个 ACK 的确认序号小于 start就是过期报文忽略。左移意味着什么左移就是左边变成发送成功的——回退已确认的数据逻辑上就是错的。2、窗口大小只会变大或不变。对于一个相等确认序号的 ACK接收方的缓冲区只会变大或不变、不可能变小——所以此时要比窗口大小上一个 这一个 → 可以覆盖并继续发送上一个 这一个 →说明是之前时间、上层接收方还没读的旧信息——不能替换六、确认序号的维护机制接收方守着下一个接收缓冲区一直维护着一个值希望下一个接收到的序号。每个报文到了中断会开一个内核线程先比对到达序号 vs 维护值判定动作发来 维护中间有空洞返回 ACK 维护值提醒对方补洞发来 维护过期报文不管发来 维护正好接上返回维护值 ACK更新维护确认序号的确定机制就是接收方判断收到的最大的序号 本身长度 - 1再返回对应上一篇的每个字节都是躺着的人。空洞和过期都靠快重传 超时重传两个机制兜底——也就是确认报文的两大策略快重传连续收到重复 ACK空洞一直没补上就立刻重传不等超时超时重传等不到确认就重发500ms×2^n。七、窗口探测两边都可以主动窗口可能被协商到很小甚至 0这时需要窗口探测有两个策略发送方自己发探测报文试探对方窗口开没开接收方自己主动发送报文窗口一变大就通知。两条路都通谁方便谁走。八、建模一条环形数组最后一句总结把模型收干净了把缓冲区视为环形数组——就是滑动窗口的建模。字节流编号在环形数组上滚动start 往前走end 跟着挪走过的区域就是已确认中间的区间就是已发未确认后面的就是还能发。两个下标 一块环形的字节流空间就是滑动窗口的全部家当。总结滑动窗口 序号策略一批一批发、暂不收应答的区域是发送缓冲区的一部分16 位窗口只有 64KB 不够用 → 选项里的扩大因子 M 左移放大三次握手交换序号也交换窗口物理上是 sk_buff 队列本质是两个 intstart/end——TCP 是字节流所以按字节编号管理而不是按报文每个 ACK 更新start 确认序号end start win——接收端远程控制滑动窗口第二段数据可直接发因为窗口是接收端商量过的start 只增不减不能左滑窗口大小只增不减相等确认序号时比值旧的不能覆盖新的接收方维护下一个期望序号大于则空洞、小于则过期、等于则更新空洞/过期交给快重传 超时重传窗口探测双策略发送方试探 / 接收方主动通知滑动窗口建模 环形数组上的两个下标。TCP 章到这里主体收尾报头、序号、握手挥手、队列、RST、TIME_WAIT、滑动窗口——从怎么保证送达到怎么发得够快一条完整的因果链。 滑动窗口的本质-两个int和一个环形数组
滑动窗口的本质两个 int 和一个环形数组我的github(https://github.com/xcx55/ubuntu-linux-project)感谢各位大佬参观我的github源笔记TCP 滑动窗口326-9-28、TCP4 滑动窗口本质拆解26-9-29、滑动窗口以及流量控制本质26-9-29可靠性靠序号和重传解决了但效率怎么办等一个应答再发下一批慢得没法看。滑动窗口就是 TCP 的效率答案一批一批地发不等应答。这一篇拆到最后会发现——这么大名鼎鼎的机制本质就是两个 int。一、先说它解决什么滑动窗口策略就是序号策略一批一批发不等应答、连续发送滑动窗口的数据 可以暂时不收应答、直接发送数据的区域滑动窗口是发送缓冲区的一部分。它和流量的关系流量控制为了降低无意义的网络资源消耗——对面内存快满了还猛发只会导致重传纯属浪费。二、窗口有多大16 位不够加因子复习报头窗口大小字段是 16 位 → 最大 65535也就是 64KB。显然不够高带宽长距离的链路64KB 根本喂不饱。怎么破——选项字段里有一个参数可以让 16 位的数字左移M 扩大因子把 16 位窗口值放大 M 位窗口就能撑到远超 64KB。所以三次握手时除了交换序号也交换窗口——这是连接建立时就要谈好的参数。三、物理载体是 sk_buff 队列本质却是两个 int这里有个漂亮的认知跳跃物理上一个 sk_buff 队列就是发送缓冲结构——结构体数组管理报文数据报文的顺序无所谓只要有索引即可但笔记里一句反思把真相挖了出来滑动窗口不适宜用 sk_buff 来管理——它是以缓冲区的字节流管理的那么滑动窗口的本质是什么结构就是表示 sk_buff 下标的int start和int end——两个字段为什么因为sk_buff 那一套适合 IP 层面向报文而 TCP 传输层是面向字节流的。字节流的本质是每个字节都有编号那么窗口就是一段编号区间滑动窗口 [start, end) // end start win滑动窗口就这样被具体化成了两个整型变量。四、动态更新接收端在远程操控你的窗口窗口不是定死的每个 ACK 回来都会更新start 确认序号 // ACK 给出的下一个期望编号 end start win // win 来自 ACK 报头对面报出的接收能力所以笔记的结论是相当于接收端在远程控制滑动窗口Start 确认序号end win start。它的可靠性来自接收端一定可以收下这个保证返回的确认序号 发送端 start_win返回的可用窗口大小 win——第二段数据是可以直接发送的因为这是接收端在上一个 ACK 里商量的窗口空间一定够对方接收窗口不变我们的滑动窗口大小也不会变。五、两条铁律不能左滑、不能缩小1、start 只会变大或者不变不会变小——滑动窗口不可能左滑一个 ACK 的确认序号小于 start就是过期报文忽略。左移意味着什么左移就是左边变成发送成功的——回退已确认的数据逻辑上就是错的。2、窗口大小只会变大或不变。对于一个相等确认序号的 ACK接收方的缓冲区只会变大或不变、不可能变小——所以此时要比窗口大小上一个 这一个 → 可以覆盖并继续发送上一个 这一个 →说明是之前时间、上层接收方还没读的旧信息——不能替换六、确认序号的维护机制接收方守着下一个接收缓冲区一直维护着一个值希望下一个接收到的序号。每个报文到了中断会开一个内核线程先比对到达序号 vs 维护值判定动作发来 维护中间有空洞返回 ACK 维护值提醒对方补洞发来 维护过期报文不管发来 维护正好接上返回维护值 ACK更新维护确认序号的确定机制就是接收方判断收到的最大的序号 本身长度 - 1再返回对应上一篇的每个字节都是躺着的人。空洞和过期都靠快重传 超时重传两个机制兜底——也就是确认报文的两大策略快重传连续收到重复 ACK空洞一直没补上就立刻重传不等超时超时重传等不到确认就重发500ms×2^n。七、窗口探测两边都可以主动窗口可能被协商到很小甚至 0这时需要窗口探测有两个策略发送方自己发探测报文试探对方窗口开没开接收方自己主动发送报文窗口一变大就通知。两条路都通谁方便谁走。八、建模一条环形数组最后一句总结把模型收干净了把缓冲区视为环形数组——就是滑动窗口的建模。字节流编号在环形数组上滚动start 往前走end 跟着挪走过的区域就是已确认中间的区间就是已发未确认后面的就是还能发。两个下标 一块环形的字节流空间就是滑动窗口的全部家当。总结滑动窗口 序号策略一批一批发、暂不收应答的区域是发送缓冲区的一部分16 位窗口只有 64KB 不够用 → 选项里的扩大因子 M 左移放大三次握手交换序号也交换窗口物理上是 sk_buff 队列本质是两个 intstart/end——TCP 是字节流所以按字节编号管理而不是按报文每个 ACK 更新start 确认序号end start win——接收端远程控制滑动窗口第二段数据可直接发因为窗口是接收端商量过的start 只增不减不能左滑窗口大小只增不减相等确认序号时比值旧的不能覆盖新的接收方维护下一个期望序号大于则空洞、小于则过期、等于则更新空洞/过期交给快重传 超时重传窗口探测双策略发送方试探 / 接收方主动通知滑动窗口建模 环形数组上的两个下标。TCP 章到这里主体收尾报头、序号、握手挥手、队列、RST、TIME_WAIT、滑动窗口——从怎么保证送达到怎么发得够快一条完整的因果链。