屎记.txt

cmd 1b
sn 3b
una 3b

标识
流
不可靠包 //无序 收到就处理  可以设置重试次数 超过丢弃
可靠包

先只实现流,  包模式 有序是多余的。与流功能本质上重叠的

tick  需要定时器 有没有数据都会调用  收发数据必定调用

#如果flag不够用的解决方法
分段。比如 第一个cmd 表示 有没有流和其他 和有没有下一个cmd
如果有  则继续读取  且 flag 意义换成另外的


#流
count 数据块数量
offset  第一个是 基准
len  2B(0表示1 最大65536)
data
offset  之后的是 相较于前一个的偏移(只能大于第一个)
len
data

#不可靠包
可跟 流数据 在一个包里。
不可靠包  丢了也不影响窗口滑动。窗口滑动是以  数据范围 计算的。

#基于数据范围了  una 不可靠了
因为sn不会复用。就不会重发。需要通知对方 接收偏移。
包头的una sn就没用了？？。设计的乱七八糟的。丢包全靠 超时重发？
una sn还是有用的。可以确认 哪个数据包收到了。但是丢包的情况 怎么处理。una的更新问题。
当取出数据的时候，更新该包为una?  貌似可行。因为无论是重发的还是第一次发的 都是自增的sn虽然没法证明 payload集合 的顺序

#una 只能知道 连续的最早已接受的  需要额外的ack 才能实现fastack比如 ackmask

#ackmask
使用bitset实现
记录una 直到最大的sn  的接收情况。

#丢包问题
仅仅使用una 和检查包是否所有数据都被接收 去判断前面的seg 丢失的部分是否已接收是做不到的 做不到的 做不到的
必须使用ack
因为seg不会重发 所以单靠una 和 数据范围检查 做不到。必须有ack

#ackmask
不需要特别多，因为丢包率不是特别大  100bit应该就够
包头加 一个count(1b) 记录位数 最大255
之后跟着的是 byte[] 存下最低count位数(取8的倍数)
如果count0 说明 最大已知的包 已经处理完了 等待接收下一个包

  

#不使用ackmask的情况更新una
因为无法直到包前面的包传输的数据范围  是不是必然小于当前包
如果小于 可以直接滑动  但是无法判断，因为存在重传的，重传的也可能丢。不能直接假定接收了
但是，可以加入一个字段，指向前一个  有数据的sn
在数据传输完毕的时候，如果发现 没改变。则直接更新una即可





#目前想到的
cmd
sn 唯一标记包
una rcv_next_sn
rcv_offset  发送方的rcv_offset  用来滑动rcv用
preHavaDataSn  上一个有数据的sn(没数据传输的时候 可以直接更新una  不过不更新una也不影响传输  大杂烩 acksn也没实现)

貌似目前  preHavaDataSn  是多余的 但是确实有效。就像假定都接收了一样
preHavaDataSn 是否根据对方的反馈进行调整？互相滑动。而不是只根据上一个有数据的sn。可以避免回环。比如长时间不发数据最终就会回环。



# 分析una的作用 和不使用ACK时的替代
una 是发送方rcv_next_sn 表示下一个要接受的sn
可以知道 对方 第一个 为接收到的 sn。  比如 丢了的第一个包。可以实现重传功能。
但是 需要的场景是包不能直接重发。
但是 seg附带rcv_offset  也可以实现  等同于una的功能。  可知道  第一个未接收的数据范围（小于的 则表示已接收 可以进行滑动 ）
una可以根据sn滑动  也可以根据 seg.rcv_offset

una和rcv_offset 功能重叠了  seg.una非必须
但是后续设计  快速重传  和ackmsk  有用  作为ackmask的起始

使用una和ackmask的话  基于rcv_offset 的滑动就多余了。
不使用的话，使用rcv_offset代替  una(分片传输协议中的una作用)



# 梳理 rcv_next_sn的滑动
目前是 rcv_next_sn=_maxint_(rcv_next_sn,segment.sn);
是偷懒的方式 只是直接接收了 sn  不考虑丢包。segment sn没有意义了 una 也没意义 只有rcv_offset有意义

1.无ack 基于超时重传 sn una都是多余的  只根据rcv_offset判断是否接受到
2.ackmas  基于fastack快速重传  rcv_offset是多余的
# 梳理 逻辑
## input
判断segment是否合法
-.接收数据(不可能出现超出缓冲区范围的情况，如果有 一定是意外)
1.将una之前的segment标记为已接收
2.对snd_ackmask进行标记 根据发来的ackmask
3.根据seg.rcv_offset 进行滑动
4.进行滑动处理。
根据ackmask 进行ack确认  跳过指定次数的，立即标记为需要重传, 并滑动
(因为每个包 不能原样重发 标记需要重发的范围 等待确认的这个包 就没用了 不需要存了，连续数据范围合并时 最大重传次数 取最大值  或者不合并，合并徒增复杂度，极小包情况下会零碎多而已)

可能的漏洞（如果中间人串改了数据段的数量缩小了，导致数据认为已经接收了，对方滑动了就不会重发了）

如果seg是next_sn  直接处理 不放入rcv_segments(并更新rcv_offset)
否则  放入







snd_next_sn(自己要发送的下一个sn序号)
maxSn(收到的最大的远方sn)
rcv_next_sn(要接收的下一个远方sn)
byte[] ackmask  (从rcv_next_snk开始 每个bit 表示 之后第几个sn 是否接收到)

请根据这些,

//请使用java实现以下功能。 ,和。我需要你实现  基于byte[] 从对方 rcv_next_sn(第一个未接收到的sn)  到 对方接收到的最大的sn 这个范围。每个bit 表示 是否接收

ackmask 第一个bit必定位0 因为 开始是 rcv_next_sn 是没收到的sn
# 根据ackmask滑动
//snd_ackmask 只需要rcv_ackmask 发送到远方只需要远方处理完就丢了
rcv_ackmask

# 没数据的包  是否直接假定对方收到了？
如果附带snd_offset  没有数据发生 只要本地rcv_offset和远程snd_offset相同 可以直接更新una。但是意义不大好像。因为有数据传输的时候没用。使用fastack和ackmask即可

#rcv_next_sn（una）的更新？
接收 ackmask 也只能确认snd_里的哪些 没被接收  跟rcv_next_sn无关
rcv_next_sn是 下一个要接收的sn。***除非允许sn重发 或 发送方 使用一个bitarr 标记重发了的数据包。接收方 直接假定收到了.....不对啊。。。。交叉矛盾
啊。可以使用 seg.rcv_offset解决。如果发送方检查丢了的 seg 发现小于 远程rcv_offset 就认为已经接收了
小于远程 rcv_offset有几种情况  1.没丢收到了 2.丢了 但是收到了重发的数据填补了
不对。。。应该是seg.snd_offset 在接收时处理。。输错了。但是 只有在数据传输完毕的时候 才会同步rcv_next_sn

还有一种方法标记是否包含重发的。如果不包含重发的。如果rcv_offset 等于 当前包的最大值。则表示这个包前面的包 需要的数据都接收了。直接更新rcv_next_sn
不对。。重发的必然小于 新发的。不需要标记。  *******直接 判断rcv_offset>=当前包 最大的数据位置。 更新una为seg.sn+1


rcv_next_sn貌似 仅仅只在 ackmask 中使用？

#rcv_next_sn（una）的更新规则
1.如果seg.sn=rcv_next_sn  更新     有无数据都不影响
2.如果rcv_offset>=当前包 最大的数据位置   更新  主要应对 丢包重发的  没有数据的无法处理，必须配合上一条 共同完成 rcv_next_sn的更新
而rcv_next_sn 与维护ackmask 相关  与fastack相关
3.无数据时附带snd_offset 。 接收时如果 snd_offset=rcv_offset  rcv_next_sn=seg.sn

在数据传输完毕后  不会更新了... 因为丢包 导致规则1 无效  而规则2 是有需要有数据 才生效。如何解决？在无数据的时候  附带 snd_offset？
规则3.无数据时附带snd_offset
？？？无数据时是不是ackmask也能省去了？


# snd_offset的更新
从头连续的 被确认的segment 取最大的 数据位置(payload.offset+payload.len)
# rcv_offset的更新
1.如果seg.sn=rcv_next_sn  更新 seg 最大数据位置
2.从 rcv_segments 取出连续的  取最大的 数据位置(payload.offset+payload.len)

#snd rcv  segments 是多余的
数据可以从缓冲区取，数据范围 DataRange 管理着(只是标记了范围)
不对。。。。snd的不多余 因为  

#梳理结构
cmd 1
sn 4
una 4
rcv_offset 4
ackmask count 0-1
ackmask 0-8

# 为什 l2.rcv_next_sn  42  但是lcp input的时候 认为35未收到  且命名只测试了丢包 没测试ackmask 不应该出现的快速重传字样 为什么出现了？
因为 rcv_offset在recv的时候才会更新。导致明明收到了的数据  以为没收到。
使用1.补正的时候  正常了。但是 存在新的问题(对方可以没有限制的不断发数据，无论recv 是否取出，如果没有取出会导致 溢出)

解决方法
1.补正  打包seg时 seg.rcv_offset+=rcvBuf.readableBytes();
缺点：无法实现流控  除非主动丢包，但是发送端无法知道 缓冲区满了。会不断重发
2.加入额外的包字段  像wnd字段一样告知 窗口大小。
3.修改ack机制。ack的时候 根据连续的最大值 判断真实的rcv_offset

方案3 改了半天不知道怎么弄  暂时方案1  如果rcvBuf  writerIndex 超过缓冲区2倍就丢弃


错了1.补正 不能使用rcvBuf.readableBytes 因为  存在空缺。 要使用rcv_dr.canLeftShift(ACK) 得到最左边还没取出的数据长度
找到bug了。是una的问题
rcv_next_sn  在对方没有payload的包 比较对方的sn_offset  然后直接更新了una
应该不传输sn_offset而是 传输 最大位置

未开启ackmask不会触发快速重传。应该
但是为什么会触发？好像是在数据传输完毕的时候。传输的end_sn_offset  发现了跳过的sn。触发了快速重传，不是bug

应该是完成了。就差实现ackmask了

# 新问题
丢包后  莫名其妙触发快速重传。但是目前没开启ackmask
重传是根据rmt_rcv_offset  标记的（之前有丢过包应该  重发的已经被接收了  但是una无法更新(snd_offset只在传输停止的时候附带)）
由于una未更新，  进入了一个地方（seg存在未接收的部分，但是实际上远程好像已经接收了，lcp标记重发的时候  lcp认为没被确认 而l2 已经接收）
测试发现与seg.snd_offset无关  因为 snd_offset只在数据传输完毕的时候  用来对比无条件同步una用。数据传输过程中没用

不清楚算不算bug和如何解决。目前是正常运行，只是没详细考虑到这个情况、逻辑貌似是正常的。数据也无误的重发了 lcp认为 未接收的部分

数据能正常传输，收到了重发的包，但是l2的una未更新。

解决方法，暂时忽略，加入ackmask 自然解决了。
但是不搞清楚原因，任意埋坑。

大致原因是l2的rcv_next_sn 138 与153 差距太多  为什么这样？是这些包 都在rcv_offset之后吗
另一个原因可能是


为什么rcv_next_sn 不能用real_offset 进行比较 而是rcv_offset比较？
为什么换成real_rcv_offset就进了offset 范围错误的异常了？
不清楚，乍一想以为是 超过了接收的缓冲区大小。后一想不对， 在lcp里异常  标记了 实际未接收的数据为已接收状态。不知道为什么会变成这样
伴随很多 忽略error  但是不应该连续忽略那么多。难道是una的问题 还有bug1也跟着刷
rcv_next_sn就是una  但是没想明白使用real_offset  应该不会导致sn 确认了未接收的数据吧
毕竟real_rcv_offset是实际接收了的
啊！难道是循环里写错了。real_rcv_offset和rcv_offset必然跟其他情况有关。差了一个包的偏移之类？相关的模糊的感觉
发现出现这个情况的时候  lcp没数据发送，缓冲区内数据都为确认，无法发送数据。此时携带的 snd_offset也无法帮上忙。因为是数据阻塞而不是数据传输完成。


最可能的原因，不能根据2进行判断。虽然 使用rcv_offset而不是real_rcv_offset看样子没问题（偶尔也出现了 不知道怎么回事）
很有可能，比如 缓冲区满了。现在已经发了1，2，3，4 。缓冲区即将满了，重发了1，2
包里只有1，2。以为sn之前的都收到了。实际上3，4没收到。
lcp以为收到了，进行markRange 但是调试判断发现  l2实际没收到 所以进入了  offset范围错误的问题

解决方法：彻底抛弃方案2，引入ackmask
或者lcp计算una发给l2  虽然滞后 但是还是准确的
引入ackmask 只能告诉 对方哪个收到了，加速 更新 rmt_rcv_offset。
并不会更新 l2的una。还是要lcp  发送
不对啊，如果不使用ackmask  una不就不需要了。  snd自己判断，l2也不需要维护，只基与rcv_offset就行了。
因为现在，就算不更新rcv_next_sn  也不影响最终传输。
要想更新，只能 lcp进行反向更新

总结
rcv_next_sn 在只基于超时重传的时候 没用，需要ackmask 配合 作为 基础偏移序号用，需要远端进行反馈。
反馈方式
1.发送计算得到的rmt_una（受延迟影响较大，导致ackmask  滞后）
2.每个包进行标记， 表示这个包被完整确认的时候，更新到的una  但是需要考虑丢包  根据ackmask 计算una  也就是滑动

先使用方案1吧  方案2需要ackmask实现后 先暂时搁置
#梳理结构
cmd 1
sn 4
una 4
rcv_offset 4 
end_offset  4(好像不需要了 这个是更新una的方案1 现在由updateUna 实现)
updateUna 4
ackmask count 0-1
ackmask 0-8

16+8+1+1=26
头有点臃肿了，再加上其他数据。感觉比kcp大。但是 支持 范围传输
范围传输单个片段 大致1 4 2 ，有数据的包最低 除了数据至少要33字节....
rcv_offset貌似是非必须的，如果使用了sn 和ackmask...确实....

简化版的协议  只有cmd rcv_offset

大致30多字节 是信息

如果没ackmask 就不打包 una 了，出现una基本也代表 可能丢包了

# 新问题
input不需要保留 seg
takeSend需要。 之前是 非连续的 确认收到就可以删了。
现在  una错误，  不能删，为了连续的滑动 增长una发给l2
导致发送端开销比较大。是个缺陷。

# 重发问题。。重发只能发1次。因为数据  转移到了新的数据包里。
原先的可以删除了，但是不是作为 确认sn 删除 而是直接删除。

#snd_buf_size 是没用的
因为目前是 不限制 send大小。
所以，只受远方 缓冲区大小 影响。



#缺陷
对fec支持不是很好
包大小固定，所以难以以包为分片。
如果以数据范围进行分片。比如 实际传输的是 fec编码后的数据。
每1000B 为单位，比如fec分片3+1模式。
可能片1，2的部分塞到一个包里。一旦丢失，2个分片都是不完整的。无法参与fec运算。

就是  分太小，多个片塞到一个包，都丢失或丢失部分。
分太大，一个包收不完，比如超大1M，mtu1400，窟窿一样，每个片随机缺失部分。也无法参与fec。
就算是均衡的情况，也总会有些许缺失。

除非，设计排序方法。尽量每个包，只放一个包或按丢包率重发次数 先后，进行排列，最大化减小 丢失时的影响。


# 可能的大小优化
没数据的时候 不需要携带 end_offset
undateuna 也可以考虑暂停。不增长发送
只需要1个cmd


新问题
l2发给lcp 极为缓慢 300多次循环  才接受了3000
原因不清楚，估计是太零碎了？和丢包率80的缘故？lcp的缓冲区没取出过。最多接收4096

# 积压ackmask
由于远方未recv 持续的交互 导致ack积压？

# 不对。。。发送逻辑存在问题。几百轮循环  远远超过rto 也经常发不到4096
检查发现。lcp的rnd_dr都是 连续的是末尾没有收到数据
。。。。找到原因了。 l2.takeSend(30)... 测试的时候 只注意了 lcp发给l2  所以每次只发了十几B最多。同步慢是正常的

# unpdateuna 可以改回  接收方自动更新，但是需要发送方 配合
之前不能根据 rcv_offset 滑动una是因为。可能包含重发的数据
比如 a1,b2,c3,d4
a1丢了，重发了a5  不能根据单个包的数据都被接收 来滑动una
因为 b2,c3可能还没接到。除非能确保 能确保 能确保  这个数据包里的数据，前面的数据都被接收了。
但是又复杂化了。。。算了  暂时使用 发送方更新接收方的una的方案吧


#seg.rcv_offset是非必须的。因为远方获取 真实rcv_offset  是根据  队列 最左边确认收到的包的数量 加上之前的snd_offset得到的
不需要 接收方 反馈rcv_offset。 可以删除rcv_offset 字段。

## 模式
1.超时重传 + 范围传输
传输时，头部只需要rcv_offset。丢包重传全靠发送方 超时重传

2.sn+发送方更新接收方una+超时重传+范围传输
会被前面的数据包丢失阻塞。影响性能

3.sn+ackmask(fastack)  +发送方更新接收方una+超时重传+范围传输


只有模式1和3常用
1.只适合 在可能丢包的  安全信道传输。延迟无感，接收缓冲区大的情况。
2.范围传输的问题，包不允许直接原样重发(sn无法复用)。 方案2是方案3关掉ackmask的场景。适合几乎不丢包的情况，不然会阻塞，尤其是没有ack机制的情况。导致收到了的对方无法感知，会连着重发浪费。
3.ackmask 告知发送方 哪些包被接收了，重发已收到的问题。

总结，包头难以减少。。。。1，2没啥用  只有3能用。包结构头部大小难以减少。



#使用注意问题
初始化时
rmt_una 要等于 rcv_next_sn

测试sn从-10开始，增加到0 结果 int回绕的时候出问题了。重新测试 初始化把rmt_una改成rcv_next_sn 一样的初始值-10
正确执行了，sn增长到0到正数 正常运行。
高丢包率的情况，ackmask会无限增长。。。。包没有数据的也许不需要增长sn。这样就能将范围控制在 含有重发的数据包上。

## 梳理
#end_offset作用
在没有数据传输的更新una，引入updateUna后 多余了。
segment.end_offset = snd_offset + snd_buf.writerIndex();
#rcv_offset
告诉发送方自己当前接收了多少，有点多余。发送方可以计算出真实的rcv_offset。
但是要判断接收方能接收多少，就需要 rcv_offset而不是real_rcv_offset
real_rcv_offset是确认收到的数据末尾位置，包含接收方在缓冲区内未 调用recv()取出的。
如果根据real_rcv_offset发送，起不到计算 可接收 缓冲区大小的作用。
可发送的数据数量为int bufLimit = _itimediff(rmt_rcv_offset + rcv_buf_size, snd_offset);
#rmt_una
发送方计算得到的 接收方需要接收到的下一个sn

#updateUna
发送方 更新接收方的una

#rcv_next_sn(una)
接收方从发送方获取到的una。作为ackmask的起始。
与ackmask一同发给 发送方进行 确认哪些包收到了


#TODO
rto的计算更新
高丢包率的情况，只重发前面的。 百分之80丢包，ackmask居然90字节。跨越700个包。

## 不对 有bug
高丢包率的情况。发现 sn一直没变。
结果发现 接收方是 rcv_next_sn 152
发送方的对列 第一个是153。。。。没有152。152莫名其妙被删除了
不清楚是计算una的问题 还是  删除逻辑的问题
====测试发现 152没被加入snd_segments
152没有数据。所以每加入。
更新una的规则 应该加一条
滑动距离加上  snd_segments第一个sn 减去 rmt_una
rmt_una+= _itimediff(first.sn,rmt_una)

#加上了之后 还是卡在153  卡住的问题 不在una？而是需要的数据没收到所以滑动失败？
为什么没收到？是被提前删除了？永远不会发送了？
。。。。测试发现。153全部被接收了。但是并没有滑动。原因不明
。。。为什么l2的rcv_dr size是0  如果rcv_dr相关的是 正确的
发送方 为什么没有发？发送方计算的real_rcv_offset与 接收方的rcv_offset一致
发送方snd_segments 明明有很多携带了数据的  seg
为什么 接收方没有接收？

发现发送方的 snd_offset 小于接收方。落后了一个rcv_buf_size左右的大小。所以 接收方收不到 。
收到的都是过时的数据。
貌似需要根据 接收方的rcv_offset  不仅更新 real_rcv_offset(取最大值，在丢包时滑动snd_segments和snd_offset)
的功能并没有起作用
先检查这个功能为什么没效果，不行可能就需要增加一条  snd_offset的规则
滑动至 real_rcv_offset
segments 不用管，下次会删除

发现了一个其他bug
l2给lcp发数据。没数据发了之后，每次l2发送的updateUna 都没改变。差距超过int 一半的时候  会导致判断大小的结果 相反

发现lcp 以为的rmt_real_rcv_offset 并不是 l2真正的收到的位置。。。。
        rmt_real_rcv_offset = _maxint_(rmt_real_rcv_offset, canDistance + snd_offset);
//        rmt_real_rcv_offset = _maxint_(rmt_real_rcv_offset, segment.rcv_offset);
。。。。这一句我觉得 没用就注释了。  以为只靠数据范围的确认 滑动  就行了。
但是还没清楚为什么 发送方的 snd_dr前面的没有确认。
我应该是写了 如果包被确认，所有的数据都会标记为 ack
应该是能滑动的。难道ackSn 方法有问题。并没有对该确认的数据进行确认。
难道是确认的时候  范围计算错了？不清楚有什么影响。就算不修复  
使用  rmt_real_rcv_offset = _maxint_(rmt_real_rcv_offset, segment.rcv_offset);
也能消除这个问题吧。尽管并没有解决原本的问题？



发现末尾压根没进过markRange。也是。。。还是input的 问题吧

。。。好像就是不能注释、、当时以为 不需要rcv_offset参数删了。后来发现需要就没加上。其他地方用了，这个地方以为不需要就没加
rmt_real_rcv_offset = _maxint_(rmt_real_rcv_offset, segment.rcv_offset);

real_rcv_offset的更新方式
1.加 滑动已确认的距离
2.根据 远程发来的rcv_offset 取最大值

修复后 再看看 会不会积压，刚才持续增长ackmask的尺寸。是因为rmt_real_rcv_offset计算错误。没有max(seg.rcv_offset,)
好像正常了，una会正常增长了。

ackmask没有很大。不会无限增长了。但是依旧有几十。大概十几 ，20多字节 左右。可以接受。
加入高丢包 高频发送 最左边的 应该会好些。


。。。。ackmask 最大达到30多。。。。达到66。看样子不会无限增长
80丢包情况基本也无法正常使用，不用担心ackmask的问题。
除非伪造了一个sn。非常大，加上机制确保不接受过大的sn。

有个问题。
应该不会遇见，每个包平均1000的话，每秒1w包。大概能达到100Mbps速度。(10MB/s)
发送丢包（正常情况不会跨度那么大吧，还跟缓冲区大小和延迟有关）。

先写成  不接收 超过rcv_next_una 1w的包吧。抛异常

如果延迟很高，缓冲区很小，速率就很低。不丢包的情况。比如 往返延迟1秒
缓冲区4096。代表最多1秒只能传4KB数据。
如果要高延迟，还能高的传输速率，需要增加 rcv_buf_size。


# ackmask的问题
只能确认少数。比如 8字节的话 只能确认 una 后面的 63个是否被接受
如果传输中未接收的包数量超过63 后面的 就无法被确认。导致后续的 认为超时了。但是实际并没有。
如果要计算rto，应只检测  una和后面共64个。

或者  额外设计动态ackmask。批量对后面的数据进行确认。

解决方法
1.增加ackmask 的发送限制，不限制为8字节。
缺点：10M传输 mtu1000左右的情况。延迟1秒  大约空中有 1w的数据包。极端情况，假设 头部丢包。会维持1w/8 字节 大概1K的ackmask
可能就没数据能填充了。
可以间隔一些包，发送完整的ackmask。和 如果takeSend 剩余比较大，能填多少ackmask 填多少。



# 之前的ackmask 前面一个字节是长度。 最多表示256 字节长度。
改成 varint。避免限制只能256字节。
。。。算了 直接2字节表示长度吧。多1字节的问题。





#梳理结构
cmd 1
sn 4
una 4
rcv_offset 4
updateUna 4
ackmasklen 0|2
ackmask >0


最短头17 才能封包。但是一直17附带不了其他数据。无法正常传输。

传输最低需要 2+maxAckMaskLen +   [1+4+2](数据范围)和数据体

大致是2+1~max  加 7  加1  最低28 才能发送1字节。
实际最低 30~40多才能传输数据，考虑如果是在高丢包且  限制极小包大小。 ackmask因为丢包会扩充。挤占了几到十几左右的容量。




#如果canUse 还有余
可以 继续填充 还未超时的数据。




#思考延迟与丢包 重发
发送方 发送和重发的数据范围 只有rmt_rcv_offset 开始 rcv_buf_size 范围
如果丢包，比如头部丢包了，必须 被跳过才会重发。或等待超时。
fastack重发是最快的也需要  一个往返。
也就是丢包发生，如果计算rto  使用原先的sn 表示收到了。
其实是不合理的。比如sn1 重发为3
1是时间100发出去
网络往返延迟200
假设 接收方收到2的时候 立刻 发送给发送方
发送方发现1丢了 此时已经经过200毫秒。
发送方 重发了数据  序号为3
3正常接收，反馈给 发送方

这样  1虽然丢了，但是处理的时候  视为接收到了的话。也参与超时计算是不合理的。
因为1事实上没收到，收到的是3。正好是1重发的数据收完了。
滑动的时候 判断1的数据范围收到了。就进行 确认（不是ack确认 而是snd发现数据范围收到了的确认）
会错误的计算1的rtt是  200+200  也就是翻倍了。而3是正常的一个200。
也许 rtt的计算  只需要考虑 直接收到的数据包。

可以统计丢包率，和排除丢的包 后 得到的网络延迟。
避免丢包导致的rtt计算剧增。加速超时重传。

和还需要考虑，计算丢包率，进行多倍发包的逻辑。
比如 靠前的数据  多倍发送(下一个包里 重复发送数据范围)，

但是没有数据传输的时候 不准确。基本 单个包的rtt是最短时间。
没有数据传输，ack是没作用的吧。

#突然发现数据传输完毕 之后的una没有更新。
加一条规则
如果end_offset=real_rmt_rcv_offset
takeSend时
rmt_una=segment.sn+1;

        if(end_offset==rmt_real_rcv_offset){
            rmt_una=segment.sn+1;
        }


# 虽然修复了 但是还有一个小问题
如果 数据一直在缓冲区不取出。 una也不会更新。暂且不管
只要接收方正常取出数据，就能正常发送。如果接收方不取出数据。
可能是失联了。暂时没设计 握手和断开 超时 等 连接状态的管理。
只设计了数据的传输


测试了下乱序接受，没什么错误。


啊啊啊啊啊出bug了，之前遇见过以为是其他问题导致的已经修复了
结果还是出了。
rcvBufWrite方法
readerIndex: -234, writerIndex: 258 (expected: 0 <= readerIndex <= writerIndex <= capacity(512))

int diff = _itimediff(payload.offset + payload.length, rcv_offset);
结果为0 数据的末端 是 rcv_offset  说明接收过了(虽然连续但是没有重叠的部分 所以不需要写入)
下面一个判断记得之前是<=0 就忽略。当时以为这里有问题好像改过。但是跟这里没关系。这次概率一样刚好又碰到。发现这里应该改回去。。。吧

        if (diff < 0) {//检查 是否在范围
            System.out.println("忽略过时的" + payload.offset);
            return;//
        }

。。。又出现了。错误的在下面的代码。忘了什么意思了
还有一个相减。好像是负数了，疑似是测试乱序接受出现的。是之前就有bug。
当时写错了，应该是相减 计算 写到缓冲区的位置，但是 写反了，变成负数了。
 int paylaodOffset = payload.offset - offset; 结果为负数
offset是上面计算得到的  payload.offset和rcv_offset 最大值。
应该最大值offset -最小值payload.offset 计算得到缓冲区偏移
写反了，在乱序测试的时候才发现问题。
needLen也错了，真马虎。计算了payload实际需要读取的开始位置Offset
needLen计算并没有 减去这个偏移
int paylaodOffset = _itimediff(offset,payload.offset);
int needLen = _itimediff(payload.offset + payload.length, offset);
int needLen = _itimediff(payload.offset + payload.length  加上(-paylaodOffset), offset);
应该没问题了。再测试n遍试试。

#TODO改进  之前想 数据传输完毕之后 不需要更新una。结果改来改去又加上了。sn一直增长，尽管很难。但是una不动 非常漫长的时间之后 会造成回绕，可能影响运行的bug。
而且 好像有一个主要问题
比如数据即将发送完成，比如高频率的takeSend的话。
延迟非常高的情况，后续本来就不会携带数据的包。可以被丢弃的包，仅仅是同步una作用。（其实是多余的吧。哪怕不发，不增长snd_next_sn）
会导致，头部数据阻塞，导致后面 高频率的空包  变成了必须确认的加入到了ackmask。

也许需要设计针对 数据传输完毕(表示前面没有数据) 的包。
没有自己的sn，或者sn是不变的，可以重发的。既不增长una，也不在前面有数据阻塞的时候，空包导致的ackmask增长。
同时允许携带ackmask。比如

cmd
updateUna
rcv_offset
ackmasklen
ackmask
......越加越接近原样。。一开始想了只加updateUna，觉得需要携带信息，不传数据最起码携带信息，然后又觉得rcv_offset也需要加，ackmask也需要加。una也需要加，结果真就只少了sn。。。。
干脆改。。。改进也可能是多余的。。。。徒增复杂度。
亦或者不使用同一套sn 数据传输的sn只在有数据的时候增长 无数据的 在前一个有数据的sn为基准开始增长或独立

#延迟波动率计算？
延迟（不包含丢包）


#ackmask也许可以  间隔时间，或包数量  满足一个条件 就发送。而不需要每次都携带，

#测试发现。input很耗时。。。几百毫秒
定位到slideSnd方法耗时
定位到
snd_buf.readerIndex(slideDistance);
snd_buf.discardReadBytes();
疑似是 700M的文件放到了snd_buf。调用discardReadBytes 废弃已被确认的数据时。的开销？
并且随着时间耗时降低了，应该是容量减小相关。
所以snd_buf不建议放入过大的数据。
或者 将数据绑定到 DataRange上。 范围split的时候  拆分为多个Buf

700M 废弃4K及一下 耗时 130~200毫秒
200M 约30多毫秒
100M 约15毫秒
#发现新问题，lcp发l2收
但是出现连续的标记4，调试看了一下发现只有一个payload 说明是连续的segment被确认。
一发一收 无丢包模式，应该一次确认一个。为什么导致了lcp snd的积压和确认
。。。发现 测试里 有个if忘了删  isNeedSend 忘了删。里面逻辑没写好 屏蔽了。只剩下一个  间隔时间判断。所以导致了积压
核心逻辑没出问题

性能测试大概ByteBuf discard 1M的情况大概1w5每秒
4096的情况 700w
4M 3k
byteBuf discardReadBytes 太耗时，使用接收时废弃已接受的 来滑动sndBuf 不合适
如果是切成一块块数据分别存储  就可以避免这个问题。
而且不是必须使用ByteBuf。（至少觉得可以自动扩容和废弃读过的比较方便）
一股脑把数据都写入ByteBuf 接收时废弃非常耗时行不通。耗时估计是内存拷贝时间。
就算接收时不立即滑动snd。snd的内容过大 下次滑动依旧会非常耗时。

DataRange 太耗时了。needRanges每次都构造List返回

之前怕写错 recv 用的DataRange 逻辑上应该是获取 rcv_buf可读字节
跑了一段时间发现没有出现不匹配的情况。
删掉了recv里的needRange 性能上去了一点
和屏蔽了一个takeSend中  检查是否真的被接收了用的 代码
40秒，循环里完成759M文件的 模拟发送接收 每秒。。只有18M
删掉了多个 测试范围检查的代码
32秒。

单纯读文件。不写出22秒
实际传输大概性能接近或2倍(udp开销。。。没测试)


马虎。忘了rcvBuf 存在空袭。
之前为了优化不使用DataRange。
然后忘了这一点，后续测试文件模拟传输  也是循环中没模拟丢包乱序。
今天又跑了一遍乱序和丢包 发现出现了问题。
找了半天才想起来。rcvBuf 的可读字节不等于  连续的数据。
导致错误的滑动距离。触发了其他地方的断点（还好断点多  一运行就发现了错误）

另外发现简单优化 ackmask 连续滑动的 方法逻辑（虽然没什么用）
滑动最小距离，后面是1就连续。计算需要的距离然后滑动。
计算错了。。。马虎 也修复了。
修复了recv方法的bug。性能下降了。因为DataRange
RingArr 也发现了bug。。。不能代替list
split(limit)非常耗时，需要优化
needOne 第一行 split是不需要的，删了。性能好了一些。

经过简单的测试，发现不能满足使用。
发送缓冲区 达到1M 性能开销大概6倍？相较于4K
但是 4K根本的传输速度太低。主要在 snd_buf 的discardReadBytes 和 rcv_buf
需要额外编写方法，减少 数据的拷贝。
比如  尽量不频繁discard 但是。。容量大了之后 调用一次依旧会卡顿。比如错误使用snd_buf直接填入了几百M的文件，滑动一次 需要1到200多毫秒。影响很大。

使用 Unpooled.wrappedBuffer  得到的CompositeByteBuf 可以动态的添加
在send方法里 每个4K进行扩容，然后写入。discardReadBytes  在snd_buf（多个buf组合的） 达到很大时 也不会非常耗时

性能好像更糟了，而且非常耗时在32M的时候每4K创建一个对象。
几十秒创建完毕。屏蔽掉之后 反而快。比如Unpooled.buffer()得到的Buf 快些
之前测试 缓冲区大小1M 1G大概5秒  32M 三十多秒
现在 依旧是5秒多

单独测试。。。CompositeByteBuf  的discard确实快。不知道是不是循环使用的，还是自动分段扩容的？
好像不是循环的，写超过初始化容量，依旧可以写，说明扩容了，而且初始化数组第一个也没见  写然后discard 再写 没见循环写。

不需要麻烦的又造屎山轮子了。 从Unpooled.buffer()  换成 CompositeByteBuf  解决了discardReadBytes 性能问题
就算直接往snd_buf 写入700M的文件。 也不影响性能。（性能主要是 discardReadBytes 耗时 居然换成CompositeByteBuf  好了）

突然发现测试方法写错了， 性能很好。。。
（一次性调用send 传入700M  不到一秒 接近6000次包，发送完成）
。。看错了 之前测试减少数据量/100了。。实际只有7M.。。。。。。
完美的内存溢出了。。。java.lang.OutOfMemoryError: Java heap space
性能约1000M 5秒 与缓冲区大小无关了 
好像没法提升了，DataRange也不是主要瓶颈。。大概吧
感觉性能已经凑合了。能用的程度。可能跟java也有关，和水平问题，做不到更高性能。
发现时间统计错了，前面的读取文件忘了删。现在是内存测试。
大概3秒 1000M 每秒300M。

测试有误
加了 发送间隔(如果没有数据需要发送就不发送)
导致，没有及时的发送确认。传输阻塞了
解决：每收到多少包，就忽略。
ignoreCount 每次收到 +1
发送归零。在小于间隔的时候，如果ignoreCount<阈值 忽略。否则 无视间隔，发送

1000M 依旧是5秒
因为测试是收发一起。 可能传输性能1v1 超过100M每秒 (收发性能可能不均衡  至少是超过100M最高接近200M)
仅内存测试结果
改了下又出bug了
l2:空包 在间隔内忽略
lcp:空包 在间隔内忽略
l2:空包 在间隔内忽略
lcp:空包 在间隔内忽略
l2:空包 在间隔内忽略
lcp:空包 在间隔内忽略
想让在需要的时候才发送，比如 lcp单方面向l2发送。
如果收到16次 才反馈一次，或达到限制间隔。 窗口32M 16次 每次最多1376字节 达不到瓶颈。
但是测试发现数据发不动。。。在某个时间之后 lcp没数据发了，跟l2一起都在间隔等待。。。不对啊。
32M的缓冲区，16次1376也不至于没数据发了。哪里想错了
也许应该 收到数据时，需要立即确认？没有数据时  可以周期性发送。
或者交给 应用管理。不多设计这个功能了。

至于32M缓冲区应该没满，测试数据未发送完成 发现是 测试写错了。
如果snd_buf.writerIndex 小于4096 则置入1M数据
但是  加了忽略功能，所有 跨度超过4096导致的没数据可发

一顿瞎改 性能降低了。。
。。。。好像是播放器没关，导致的测试性能影响。关掉 还是5秒。多了一点点
时间间隔好多余感觉。感觉不适合这个协议内部实现。
而是上层管理，需要什么时候发，什么时候发。内部不用实现。算了暂时不删了。

udp测试，发现了更多问题。。一头雾水
DataRange 疑似有问题，但是是其他错误断点先触发，可能是传入了错误的参数。是其他问题也许不是dr的问题

难道是线程安全问题
加了锁好像好了。测试udp是额外写了个线程，并且 主线程循环间隔时间 也会写数据。可能冲突了。
udp测试写错了。 不知道为什么OutOfMemoryError
lcp逻辑又出问题了。。不知道动了哪
之前的测试跑不了了 好像是una计算问题

离奇，重新写了一下 接收和标记数据。
之前一直进标记4。乱序收发也正常，刚才发现代码有问题，之前怎么跑通的。
现在重新梳理 重写了 input和 ackSn，现在不报错了。奇怪，之前怎么跑通的。

为什么好了，为什么坏了，为什么好了，为什么坏了，

报错了 rcv_buf 一看容量0 设置writerIndex 超出0就报错了。
突然发现rcv_buf 取出数据并不需要discard 直接修改writerIndex 为0即可。性能好些应该
需要先修改readerIndex 不然 readerIndex>writerIndex 异常
报错好像是逻辑错了。。。不是rcv_buf问题。
应该是刚改的ackSn
..错误的地方是 接收。而不是snd_dr  
继续分析

una的更新规则
接收时
1.如果是下一个，则+1
2.如果远方下发，则取最大值
3.根据rmt_real_rcv_offset 进行确认
可计算得到要更新对方的 una
4.发送时 数据末尾=rmt_real_rcv_offset 更新远方una (表示对方已经接收完毕)

规则4 不知道为什么加上  问题就出现了。 删掉就正常。
        int end_offset = snd_offset + snd_buf.writerIndex();

        if (end_offset == rmt_real_rcv_offset) {
            rmt_una = segment.sn + 1;
        }
好像没问题看着
加上去也正常。啊？我刚才改了什么把bug修了？

udp测试貌似也正常跑通了。但是ackmask  居然达到了600多字节
也许应该加入sack

有个地方总是进，可能是丢包重发了的，重复接收时触发的。
可能是没加最小rto限制，被跳过就标记为unsend 等待下次取出范围发送了。而且乱序情况下总是进。应该就这个原因。

似乎有bug？高速发送的时候 每秒大概几千包。逻辑有问题？ 本地单机测试  好像丢了很多
导致收不到数据，缓冲区1M。

检查发现 并没有丢包。每秒发送100包。接收方发送1包。
出现了  忽略过时的125216
忽略过时的126592
忽略过时的127968
忽略过时的129344
好像不是这个问题。

好像会丢包，不知道跟断点暂停有没有关系。 发送数量 和 另一个udp的 接收数量对不上。统计好像没问题

测试发现会。
不会。。。。使用AtomicInteger 统计发现没丢
emmm会丢、。会丢。。会丢
netty 本机udp 收发 好像极限是6w/s..... 总觉得好低性能
基本在3w~6w 接收

找其他软件测试。发现单机127.0.0.1 收发 好像最大也就 几十M每秒 应该是正常情况
70M左右
。。。不对是复制的iperf测试参数问题。
好像单机大概 最大150MB/s  (每秒1w9包（每个8K）)
如果1400 只有27.....
iperf3 -c 127.0.0.1 -i 1 -t 300 -u -b 3000M -l 1400

貌似 udp每秒最大不超过2w包比较合适 超过容易丢包。不过下载的kcp-netty 里的测速。能达到6w每秒 (mtu1400)
iperf3 换成64位。每秒2w2

纠正单机的速度 跟 包大小有关。不过超过1400 的udp没有参考价值。虽然单机能传输几百MB每秒。但是网络上 mtu一般使用1400

性能又下降了，发现是rcv_buf 新写的如果容量小于 rcv_buf_size
就设定容量。但是比较耗时。不知道 clear或重置writerIndex 能不能代替discard
并且 不会修改容量
可以。recv 基本是全部取出。所以clear（修改writerIndex和readerIndex=0）
可以

奇怪还是慢。而且内存溢出了
好像是使用clear后 越来越大了。容量，莫名其妙一直在扩容

不对 discard 也这样。应该是其他地方导致的。
recBuf.writeBytes(rcv_buf, readLen)；后扩容了。
莫名其妙，明明最大writerIndex 很小。每次write莫名其妙容量翻倍？
不是每次，是达到一半就扩容好像。不是无限扩容

看错了。不是rcv_buf 是recBuf.....是参数，正常。
好像只是内存爆了。测试1G 一个发送在snd_buf 一个在外面 取出存着。
内存爆了
性能差不多  clear 和discard  不需要特意替代(clear快一点点  因为只是改指针)

内存爆了好像跟  payloads 每个都创建了一个buf 并写入数据的问题。
相当于snd_buf一份  rcvBuf一份  snd_segments.paylaods里面一份 怪不得溢出了。
payload.data.release(); 太耗时  没法直接调用。置null 好像没什么效果，不会立即回收
难道之前recBuf 调用了discard？（注释掉了 ）
难道之前没测试过  接收所有。
溢出是recBuf内存不够了。

payload.data.release()并不耗时，是刚才测试recBuf没clear。（随手注释掉了）
以为是release 加了又耗时了。实际上没什么影响

并且内存不会暴涨了。snd_segments 里的buf清理ok
编写检查方法。遍历rcv_dr。判断远方是否已发送。
遍历snd_segment。判断被确认的  范围 是否远方已接受 
。。。。定位半天bug又回到了之前发现的问题
使用clear代替后。乱序情况下，只有头部一些字节可以取。所以clear不合适
使用discard。容量减小了。。。扩容性能又下降了
((CompositeByteBuf)buf).addComponent(Unpooled.wrappedBuffer(new byte[1024*1024]));
比buf.capacity( 容量)快

扩容时，尽量添加比 需要的多的。减少扩容次数
或者考虑其他办法。
discardReadComponents() 然后再加进去？
不行。。io.netty.util.IllegalReferenceCountException: refCnt: 0 异常。buf已被释放
addComponent性能也不好。。
性能好差啊。。之前测试错了。 一种是刚好取完。直接clear性能最好。测试一直是这个。
以为是discard

想办法避免使用discard
设计多个缓冲区？循环使用？

Unpooled.buffer()和  CompositeByteBuf  好像discard性能差不多
CompositeByteBuf  在大数据量时 性能好

使用循环数组   封装了一个 循环Buf。discard不会导致 资源释放。
性能很好，每秒2000w次大概。测试大概 每秒 8000MB（4096+2 每次读写都调用discard 只是移动偏移 没有资源释放）
循环使用多个buf，并支持扩容（释放方法没做）
单次使用4096读写。2千2百完次每秒。

替换rcv_buf后。 4.8秒左右，性能没有影响。
替换snd_buf后 4.2秒左右。 
但是snd_buf 需要考虑释放，比如放入了几百M的文件。
之后不发送这么大的数据了，会一直占几百M用不到。

再写个方法，释放未使用的 ByteBuf

总结，改善了 rcv_buf 缓冲区较大的时候。discard的性能问题（snd_buf也是，比如700M 耗时200多毫秒，无法正常使用的程度）
修改后，不会进行拷贝仅仅进行偏移。使用额外封装的方式，替换ByteBuf。
主要解决的是，取出缓冲区的部分，并废弃。比如 snd_buf 头部的被确认了，被确认的部分 就可以删了。调用discard比较方便。
rcv_buf 如果取出的程度等于 writerIndex 直接clear性能最好。但是  乱序的情况，只能取出头部的部分，也需要调用discard。
如果使用偏移  来解决  写的乱七八糟的容易搞错。而且  buffer 还是要discard不然无限的增长下去了。或者也使用多个循环使用。但是写到核心代码里 太乱了。
还是额外造了个轮子。封装 循环使用的ByteBuf。使用环形数组，主要在头部和尾部进行增加删除，不会触发拷贝。也没有链表的节点包装对象。随机访问也快。
(但是容量扩容 可能导致的问题。。。没考虑是否有bug。。一般不需要很大容量，暂时搁置考虑，目前是能用，也用不到 int 一半的元素数量那么多，目前每次扩容*2 拷贝数组)





测试100M 1.1秒左右 200M 1.6秒左右  300M 2秒左右 500M 2.6秒左右
1000M  4.2秒 。。。。。。。测试方法有问题吗，不是均匀的
应该能满足使用。


之前模拟丢包和随机接收。效率很慢。
快速重传触发了的被再次跳过的时候就忽略的。加上了如果超过100毫秒就 不忽略，标记为可以立刻取出发送的状态
发现接收数据的效率上去了。之前是龟速  半小时300KB。（只是测试能不能接收）
发现原来问题是，包重发了也丢了，只能等rto了。但是当前默认3000。丢了只能等，所以很慢。


发现之前设计的ack问题。跳过数量的问题，找到最后一个标记为接收的snd seg
然后将之前的 非done的 跳过次数+1 和标记为 需要发送
但是，有时候丢包，比如只有一个包的情况。没收到，虽然后续的包收到了（空包无数据 不会加入snd_segments）
导致检测不到，无法快速重传。
换了个逻辑。记录最大的被确认的sn。所有小于sn的未done的  均 跳过次数+1  触发快速重传 

测试方法每次循环sleep 200
快速重传，刚才写的100毫秒就。导致 一个周期内重复发送。改成200，发现不会周期内重复发送了。效率也上升了。
几乎每秒都在输出到文件。几百字节。（单次takeSend 1400）
。。。马虎
                if(System.currentTimeMillis()-cur.ts>200){
                                System.out.println("重发超过100毫秒的");
                                cur.ts=System.currentTimeMillis();//刚才没有置新的ts 标记重发后又会一直标记重发

经常停滞，不知道什么时候突然又继续了。停止的时候一直再重发
而且偶尔能看见 ackmask 是一堆  86，太规律了。跟忽略数量有关吗
01 01 间隔

        //如果 远程的real_rcv_offset=end_offset// 没有数据要发送的时候  也持续更新una
        int end_offset = snd_offset + snd_buf.writerIndex();

        if (end_offset == rmt_real_rcv_offset) {
            rmt_una = segment.sn + 1;
        }
难道是这句导致的 注释掉后 依旧 ackmask依旧是一串的 86

基于udp的测试 应该不至于丢包那么严重吧单机。逻辑有问题，不知道为什么放到udp测试显现了。
收到的数据包  存在跨度 有的缺失了 比如sn1不存在
发现确实打包了。但是莫名其妙没接收到 奇数的
奇怪 发送好像是没问题。序号是自增的
但是接收为什么序号重复接收了。反序列化出问题了？
udp发送的时候  有什么地方错了？
但是为什么只有一端有问题，另一端的接收没有出现跨度？
takeSend检查 确实有打包啊，打包也立刻调用trySend 传递发送了。
为什么错误了。
发现位置原因，udp收到的buf 是空的，内容是空的。
发现 收到数据后 直接使用的同一个buf 并且没有clear导致的 发送出去时  头部附带了其他干扰数据

正常了

udp跑通了。但是发现一个问题，增大每秒发送的数据量时（200ms间隔，每次100）
17秒收到10MB。
但是发现一个问题
刚开始 会 一直刷
error ackSn 970忽略949
false
error ackSn 971忽略949
false
error ackSn 972忽略949
false
error ackSn 973忽略949
false
疑似很多包会被跳过。
估计是una有问题。
难道是刚开始。尝试先 空数据启动，然后 再发数据试试。
问题消失了。疑似 第一发数据的时候错误的更新了una？

每秒大概450包发送，（200ms间隔 每次100可能是线程sleep 的问题误差 和莫名其妙的丢包（单机丢包，不知道为什么））
正常传输成功。
不对 又出现了 erro ackSn
ackSn 小于 rmt_una

重新梳理una的更新规则

发送时。如果对方real_rcv_offset= 发送方end_offset
更新对方una。//接收好像有问题  如果乱序接收 好像会提前更新？
不过逻辑是取最大值，应该没问题吧

 rcv_next_sn。


貌似不发送数据 一切正常
发现是先刷了 处理ack
然后快速重传跳过次数
之后才会出现
收到ackmask14  seg.una1597 [-14, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 1]
=================处理ackmask
如果没开ackmask 进入这里可能有问题？？ 跨sn也可能是丢包
false
error ackSn 1598忽略1609
为什么头部丢包了？
rmt_una=1599
也就是发送方认为 对方下一需要接收的是1599
1111 0010废弃2 还是有2个没收到

发现有包被多次重发

而且频繁刷 如果没开ackmask 进入这里可能有问题？？ 跨sn也可能是丢包
难道只是丢包造成？写的udp测试单机。 丢包率很大



为什么KCP-netty 的测速 统计 每秒能6w包？
升级了netty 测试  也达不到。
之前的测试逻辑是
循环几w 然后sleep500毫秒  计算 收到的数量。
现在改成5秒。基本能收到大部分了。
难道是积压了，虽然是本地发送，但是积压了。
修改测试方法试试，连续测试，每次结束后 输出统计数量。然后减去 数量。

先测试了sleep 2000 大部分能收到
sleep 1000 大量的没收到。 积压居然会滞后1秒以上？
在网络上传输必然会增大延迟。
重新测试，最多每秒4w。可能测试方法有问题

            ByteBuf byteBuf = byteBufAllocator.ioBuffer(buf.readableBytes());
//            ByteBuf byteBuf = Unpooled.buffer(buf.readableBytes());
            byteBuf.writeBytes(buf);
ioBuffer是做什么用的？换成这个貌似丢包率少了一些。好奇kcp用的什么buf找到 是使用的ioBuffer这个方法创建的
totalSend = 466762
totalRecv = 464799
totalSend = 467148
totalRecv = 460610
为什么换个buf 丢包率降低了，是cpu消耗问题吗。kcp测试的时候 cpu比我 循环发送（有最大发送次数限制 不是死循环） cpu低。
totalSend = 470095
totalRecv = 469368
换回Unpooled.buffer试试
totalSend = 469677
totalRecv = 395759  丢包好多
观察到内存增长，难道是gc导致的？iobuffer为什么没这个问题。。是池化的吗
。。。发现kcp测试比我循环cpu使用率高 刚才看错了。内存涨到一定程度不涨了
ioBuffer 好像是池化的，刚开始，1秒内 发送次数没达到上限。慢慢的达到发送上限。
且内存没有增长了，ioBuffer疑似是池化的。
但是不知道为什么，跑不到6w每秒
ioBuffer确实是池化的。不需要释放吗？发送upd 的时候writerAndFlush 里面自动管理了 程序上层不需要再做任何操作了？
循环结束后，等待3秒。发现居然收到了19w包。积压这么多吗。
等待5秒，貌似大部分都能收到。为什么积压这么多。
基于UDP的协议，似乎具有天然的劣势。单机性能都这么差。
tcp 单机测试 单线程可以上350MB每秒的性能，cpu也很低。 多线程能达到1GB/s以上
基于用户层的协议具有天然的劣势？
突然发现没加锁，加了锁又测试。
发现一个bug，不知道为什么 rcv_next_sn跨度那么大
        if (_itimediff(segment.sn, rcv_next_sn) > 10000) {
            throw new RuntimeException("收到了过大的sn" + segment.sn + "," + rcv_next_sn);
        }
感觉是其他逻辑有问题，因为发现被重发十几次的。肯定收到了，但是 为什么没被确认

太乱了，完全捋不顺。缓存所有的 发送seg。当远程ackSn的时候 检查是否数据已被接收
突然发现一个 snd_segments 第一个 sn=updateUna 这不正常。
第一次发送数据。
        if (end_offset == rmt_real_rcv_offset) {
            rmt_una = segment.sn + 1;
        }
        segment.updateUna = rmt_una;
        if(segment.sn== segment.updateUna){
            System.out.println("sn 等于 updateUna 有bug");

        }
//加个逻辑。如果等于 说明应该是第一次发送，end_offset 自然不等于 rmt_real_rcv_offset
所以没+1
导致 sn=updateUna。导致的队列积压？
（启动时无数据发送 后来才发的数据）
加逻辑  如果sn=updateUna  updateUna加1

然后bug了。。bug snd未被接收的数据 被标记为已接收
难道是滑动snd有问题
好像知道怎么回事了。
sn1 end_offset=rmt_real_rcv_offset  updateUna=2
sn2 有数据  如果接到了sn1 una自增满足  如果没有接到una 按updateUna更新。
有数据传输时，updateUna  应为第一个snd_segmetns 第一个有数据的 sn。
sn2 的updateUna = sn2 是多余的。但是是没影响的。
sn3 有数据 updateUna=sn2 如果2丢了，不会导致una 增长，因为sn2确实丢了。
发送方根据 rmt_real_rcv_offset  判断哪些被接收
最终 滑动snd。（不需要复杂的逻辑）
发送时，如果 end_offset=rmt_real_rcv_offset una=cur.sn+1
如果不等于说明有数据未确认，获取 snd_segments第一个的sn 作为una即可


远程input，根据 sn=rcv_next 时自增 和 rcv_next_sn 和updateUna 取最大值进行更新。
和滑动时进行更新。

调试时，发现snd_dr 第一个rto是3000 其他的都是0  发现 拆分range时忘了赋值rto。
导致后面的 永远立即取出。
修复后出现了新bug。。
                if (range.start + range.length > rcv_buf.writerIndex()) {
                    System.out.println("rcv_dr 存在 确认了  位置大于rcv_bUf的");//触发了
                }
奇怪但是 查看值 加起来不大于writerIndex啊

偶尔触发另一个。
 System.out.println("错误!确认了并未接受的sn");

也不对啊。。。看了偏移，是接收过的。
之前也没触发过。什么情况
        for (Payload payload : segment.payloads_stream) {
            rcvBufWrite(payload);
            if (isRecived(payload.offset, payload.length)) {

            } else {
                System.out.println("测试失败");
                isRecived(payload.offset, payload.length);
            }
        }
这里偶尔也会触发了。为什么啊。。。。难道 拆分range的逻辑有问题。
而且其中一个触发了，再次调用。结果 结果是通过的。说明被其他线程改了？
                       if (rmt.isRecived(payload.offset, payload.length) == false) {//因为 false 进来了
                           boolean r= rmt.isRecived(payload.offset, payload.length);//但是再次判断 居然是true
                            throw new RuntimeException("bug snd未被接收的数据 被标记为已接收");
                        }
但是 加了锁啊
在调用之前 记录offset length 发现 并没有被修改。
难道是rmt.rcv_offset 发生了改变？发现确实是。
因为加锁是当前对象。检查代码 调用另一个对象  使用的不是同一个锁
我只在  封装的 trySend tryRecevice 加了锁调用scp
但是检查代码是跨线程的。修复了 range的rto没有赋值的问题。
才出现这个状况，说明改对了？
将2个scp 使用一个锁测试看看。如果还有问题，说明逻辑有bug

又回到之前的状态。 数据停滞，积压。

看上去数据好像确实发出去了，为什么没被确认？
                if(payload.offset==rmt.snd_offset){
                    boolean b=true;//断点     触发了 说明确实收到了数据 
                }
确实收到了，而且 rcv_offset大于 rmt的snd_offset  说明都收到了。
为什么发送方认为没收到。难道 根据offset 进行标记的逻辑有问题

发现 rcv_offset大于rmt snd_offset
但是远程收到的seg 为什么 rcv_offset 等于 当前实例的snd_offset.....
takeSend 应该是附带的rcv_offset啊  明明大于远方。为什么远方就变成了接收方的snd_offset了
啊？？？？
也不像自己发给自己了啊
似乎是积压的问题。当前没设计拥塞控制。虽然测试 每秒只有几百个包。不应该积压啊
发出去的sn是6000  然后断点收到的是500。滞后很多

跑了下 循环里模拟的测试，貌似一切正常。
感觉是udp积压和加锁的问题。没有拥塞控制导致

加了个简单的判断，如果snd_segmetns size 超过10 就不发送了。
基本正常运行了
没有刷跳过 sn。说明之前的error acksn 忽略 是积压导致的。
已接收0.082672119140625
end1收到出站数据了你好
已接收0.192901611328125
end1收到出站数据了你好
已接收0.578704833984375

但是每秒只发送几百个包，为什么会导致积压，难道是 接收方法或takesend 发生了耗时的操作，比如为了调试加的 检查代码
加了简易的wnd。10秒收完了10M
但是不稳定。好复杂啊，也许应该统计1秒内 对方收到了多少包。但是需要额外的支持。无数据的一般丢了就丢了，但是要统计就麻烦了。
除非不允许丢了。但是好像没必要，，，不值得改
概率一样 又出现了停滞问题。(一直触发快速重传)
收到ackmask264  seg.una462(怎么固定这个长度 内容好像没变动过)
下面刷 不存在  
啊。好像是超时 或快速重传的依旧占了未确认数量。导致发不出去数据
而触发超时重传 判断为丢包缩小了窗口，永远发不出去。。。。



感觉快速重传设计有问题。
触发重传之后  下次就不会再触发了。
但是我写错了，依旧会触发

之前加了 时间内不会触发是多此一举的。有个地方的 检测代码也写错了。删了。也是多余的。
目前 刷error ackSn（sn被跳过）
是数据的滞后和导致的。（una正常增长）

似乎是设计的问题。因为测试代码是  收发穿插着执行，两个端 2个线程 使用一个锁。测试的。
传输是正常的现在。

现在相当于 无间隔，能发就发。
比如乱序收到了 sn2 ，标记为需要重发 sn1马上进来之前。takeSend了 重发了。浪费了

混合ack。解决有时候 很多连续的-1（均已接收 只有头部未接收或尾部之外  大部分是连续的1的情况）
格式
类型(最高位0 ackmask)(最高位1表示数量)
也就是 最多能表示127位连续的已被接收。 或字节数量的 ackmask
比如0|8 byte[8]   1|10  0|2 byte[2]
表示 8个字节的ackmask  10个连续的被确认  接下来又是 2个字节的ackmask


奇怪 莫名其妙有发送瓶颈？
调用763次左右 就不能发了。哪怕数据是100M 每个1376分片
也要76204多包。为什么763次停了

难道是rcv_buf_size的限制？
啊！确实是，刚好是1M。忘了。。udp测试里使用的1M 缓冲区
我说怎么调整窗口依旧是限制在700多。每秒稳定2M。

缓冲区大小增大到100M 反而不行了。半天才接收1M。
可能必须考虑延迟和 拥塞控制问题。不然目前的快速重发逻辑 一旦发生滞后，丢包。单机测试  会大量不必要的重发

收到数据时，放入队列。
在线程里  调用scp 的input  recv 和takeSend
发现性能上去了。一点点。100M传了30秒



算了，测试一下 目前的重传标记逻辑
测试方法。4K接收区。8K数据发送。
应该是，第一次发送4K。下次发送 丢失的数据 和填满剩余 最大不超过4K

逻辑好像有问题
发3个 第一个丢了
l2 takeSend 反馈。 lcp发现丢了
lcp takeSend 重发。但是在窗口内完全发送成功之前，不会发 超过 缓冲区大小的位置。
所以 只重发了1。
l2每次input都取出。更新rcv_offset

lcp 发3 第一个丢了
l2 takeSend反馈
lcp 重发
l2 takeSend 反馈确实接到了。
lcp 

一旦发生丢包，就会导致传输停止
比如传100M数据第一个包1K丢了，可用的发送容量也只有未确认的部分。
需要改进

ackmask  最小化
1. 压缩，如果压缩后并没有减小，则废弃。
2.翻转。  比如 只有第一个没收到，后续的都收到了。翻转后  1表示未接收。
3.ackmask 加sack 加ackmask  遇到连续的就sack 遇到非连续的 就ackmask
4.


una 滞后问题。
接收方 目前 无法区分 数据包是连续的新发送 还是重发 的 和混合在一起哪些是新的哪些是旧的。
接收方只能 更新real_rcv_offset,但是 已经过去的sn不知道。rcv_next_sn 没有更新。
导致 在接收到 发送方更新前，依旧会使用过时的rcv_next_sn。导致ackmask过大。
明明某个sn之前的包的数据都已经携带了。
目前的逻辑是，发送方更新una 为  第一个snd_segmetns的成员的 sn。
表示接收方这个还没收到，而且连续的有数据的segment。都使用 当前第一的sn 作为updateUna
连续接收的时候 可以接收方正常自增。并反馈给  发送方（rcv_offset也可以，rcv_next_sn 附带仅仅是作为ackmask的起始标记用，不主要参与确认之前的sn(虽然也能 但是跟rcv_offset作用一样)）

也许，发送方可以标记数据包。当接收到某个offset时，更新una 为指定。
发送方，在发送有数据的时候  携带第一个snd_segments的成员sn是有点多余的。
如果没丢包，接收方自增了。如果丢包了，携带的updateUna 也不会更新。所以有点多余。
可以加一个字段。如果接收方达到这个偏移，则更新 rcv_next_sn。可以稍微提前一点 接收方更新una。避免了发送方来更新。
好像计算这个增加了性能开销。还增大了包结构。

ackmask压缩逻辑
取反 看看长度是否减小了。如果能填入就填入。不能就尝试压缩。


标识增加2个  除了 有ackmask 还增加了  ,取反,压缩 两个标识

snappy 压缩性能不错。大概每秒一千万次。
无法压缩的情况下，压缩后比原数据大。
似乎有问题，如果传入 并不是压缩的数据。会导致性能骤降？
可能会导致解压缩时 以为数据很大，造成性能问题

好像解密失败返回null
100M 空byte[] 压缩后4M...........


收到数据后将buf加入队列。然后 在 专处理scp逻辑的线程里。调用 input send recv方法
发现，之前的丢包改善了？可能之前的丢包和乱序，并不是 udp单机真的乱序了。丢包虽然会 但是极低概率（大概，iperf3 测试udp有丢包率 可能会丢吧 也可能是 滞后了统计错了）
使用队列后，从队列取出  专门的单线程里进行input。没有刷乱序导致的信息了。传输速度稳定几乎没有停滞。

当我没说
收到ackmask63  seg.una31512 [0, -16, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 15]


奇怪,bug? 为什么ack是连续的0
收到ackmask264  seg.una105049 [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
=================处理ackmask
最终
发生异常
Exception in thread "Thread-0" java.lang.RuntimeException: java.lang.RuntimeException: 收到了过大的sn164189,64188

发送次数7001scp1  耗时:2981
不知道为什么发送很耗时，1毫秒只有2个包。
去掉了锁，使用了Blocking队列 放入要发送和接收的Buf
在线程里取出，发现还是慢。然后记录了开始循环发送的时间，发现速度低于之前的测试。
之前测试  循环里 无丢包。1000M 5秒。 总762069次
大约1毫秒 可以打包150多次。 而在udp 本机测试时，不知道为什么。封包效率极低。
难道是过长的ackmask？限制长度最大8 依旧。
snd_segmetns从ArrayList换成RingArr 依旧
由于单次调用在1ms以下。难以测量
难道是dr的问题。在大量拆分后零碎的情况。搜索很慢。

测试 100M 每次取出1376范围。然后标记为ACK。继续取出非ACK的
发现每秒只有几千次。性能极低。
由于needOne 需要根据type进行检测。需要搜索。所以拆分的越多，开销越大。。。主要是在for遍历。。。


优化方案。不从头搜索。
下次搜索，从指定位置搜索，减少遍历次数。

如果下次搜索时，ts相同。则，从上次搜索到的下标继续。
没有考虑参数，如果参数变更可能会导致 结果错误。

有点复杂，为了性能必须在滑动 和 markRange 和 split 考虑对应的处理。
而且 下次调用，可能前面的已经过期了。只能从头找。缓存无效。
除非单独放入一个队列。但是复杂度又上升了。
或者搜索的时候  时间在100毫秒内重复使用。触发缓存。1秒最多慢操作10次重置缓存。
。发现效果不好，微乎其微
使用了 二分查找  来寻找和split。加上needOne 缓存下标
7000次依旧消耗了1秒

好像有点用。第一次慢，滞后7000次
发送次数7001scp1  wnd20000  耗时:1184	size:9801400
发送次数7000scp1  wnd20000  耗时:792	size:9800000
发送次数7000scp1  wnd20000  耗时:562	size:9800000
但是。。每秒几乎最大9M~15M。。。速度太低了
发送次数2752scp1  wnd20000  耗时:7	size:3852800
容量小时比较快。
发送次数7000scp1  wnd20000  耗时:57	size:9800000

貌似刚开始慢，之后快。不知道是不是jvm优化了。
也可能是缓存下标的问题。

依旧阻塞了。一看等待input的数据包 积压了几万。。。
takeSend 依旧优化了，input 也需要优化。。
优化了markRangen
测试100M 23秒。使用了kcp的rtt计算
不知道为什么 哪怕加大初始rto。 一开始总有部分包被重发。
主要问题是，测试偶尔成功偶尔失败。
失败原因：收到了过大的sn
疑似丢包导致，和重发失败。持续的发送，没有窗口限制。导致  最早的una和最新发送的sn跨度过大。
奇怪？增加rto结果 更频繁了 触发  ：忽略过时的 
说明被重发了。
。。。又出现了停滞情况。复现失败。
发现rto没起作用，一开始莫名其妙100毫秒。复制的kcp的逻辑没看懂也没看。改了一个限位最小rto 改大。没有触发重传了，之前应该是计算100毫秒。但是并没有100毫秒内处理数据包所以超时重发了。
增大了最小rto 进行测试。14秒传输完毕。性能依旧很差，达不到每秒几十M的性能。
可能加入拥塞控制和 再设计设计rto  就能实现。
能力问题，dr的性能没法改善。除非使用其他结构，但是太复杂不会写。

啊啊啊搞不明白，理论上增加了缓冲区，发送的时候可以多发。调高rto  哪怕积压一股脑 本地 发过去，没有达到几万/s的极限
应该可以啊。但是为什么  反而接收速度下降了。 输出发现对列是空的，都处理完了emmmm
啊？
增大缓冲区就出现了停滞的情况。
收到ackmask264  seg.una18269 [-64, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1]

又测了一下10MB/s  没到瓶颈，感觉就是停滞的和缓冲区大小限位的问题

并且 发现rto全是1000（设置的最小rto）
rtt的计算有问题，因为只考虑了数据传输的包。空的没考虑（空的压根不会进入snd_segments存储）


绝对有什么地方逻辑写错了！难道是una错误更新过头了？居然重发了几百次 一直停滞下去
Range{sendcount=667, start=100448, length=1376, type=1, ts=1706605682709, sn=0, rto=1000}
之前被发送数量667 当前包sn6337358
Range{sendcount=667, start=101824, length=1376, type=1, ts=1706605682709, sn=0, rto=1000}
之前被发送数量667 当前包sn6337359
Range{sendcount=667, start=103200, length=1376, type=1, ts=1706605682709, sn=0, rto=1000}
发现积压了45w包在scp2接收队列..........input takeSend 性能不对等导致的积压吗


ackSndWithRmtRcvOffset emmmm忘了判断是否完成直接跳过
每次会遍历所有元素 的所有payload。。。。。。

而且好像没必要遍历所有，不过设计问题，新发的虽然有序，但是重发的放到末尾。导致只能遍历所有未标记done的所有payload
也许应该在发送时标记  数据末尾位置。（就这样吧


不知道有没有地方偏移写错。offset+len 得到的应该是 后一个数据的开始位置，而不是末尾。emmm虽然目前好像没看见有什么影响？
懒得找了先。

rto有问题？跑了下之前的丢包测试。变成了40多秒.......
好像是因为takeSend 放入了 list   间隔200毫秒的循环  下次随机取出 input 进行的乱序和丢包测试
导致的计算延迟很高。

又出现了停滞，发现scp1貌似没有刷信息？卡在哪里了？死循环？
并没有卡死，只是慢

性能的开销貌似集中在ackmask 的确认
收到ackmask264  seg.una13879 [0, 0, 0, 0, 0, 0, 0, -4, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1]
=================处理ackmask
将接收的scp线程 抛了异常停止掉了。
新刷的内容都是scp1的
发现规律的刷收到ackmask。但是速度很慢，scp2也停止了不会发数据。所以是积压的数据。
说明ackmask的处理是耗时的。

之前对segment进行确认处理是 ackSn方法  遍历所有。找到然后处理
（目前只有2000个 感觉不会慢吧，只是比较sn 然后才进行处理）
难道是 ackmask的获取性能问题。
。。。测试的时候经常一个丢包导致一大串  -1
每次接收都会重复检查。ackmask 太长 性能也会降低。每秒只能十几万次。
但是 每秒需要检查几万包和额外开销，性能就慢了下来。
ackmask也许不适合单独作为ack。
也许应该加入sack，最起码不能一直响应一长串 ackmask。

。。。。接收端也积压了
啊啊啊，设计问题性能上不去，只能低速率传输了吗

needOne似乎有bug
rto值3000 ts与搜索参数 只相差2 不应该被取出来

发现一个问题，概率出现。
在循环中 takeSend 然后input
发现takeSend的时候  就出现了问题
耗时是一方面，另一方面是概率出现  
之前被发送数量1 当前包sn55538
Range{sendcount=1, start=0, length=1376, type=1, ts=1706680235240, sn=0, rto=10000}
之前被发送数量1 当前包sn55543
Range{sendcount=1, start=1376, length=1376, type=1, ts=1706680235277, sn=0, rto=10000}
之前被发送数量1 当前包sn55544
Range{sendcount=1, start=2752, length=1376, type=1, ts=1706680235277, sn=0, rto=10000}
说明数据被重发了，但是。很奇怪，只是在循环里 第一次发送 怎么就判断他的发送数量为1. 已经发送过了？
最奇怪的是为什么概率出现。明明是在循环中测试的。
难道是 获取时间戳的变动问题。System.currentTimeMillis();

啊！好像知道为什么了。测试6w次 耗时超过3秒，导致后续的循环以为前面的超时了才取出来。

单独测试needOne  无缓存5秒 缓存 103秒
但是缓存只是根据时间戳，容易失效。
takeSend是是获取当前时间  根据当前时间取出 判断rto是否超时。
为了减少for循环的此时 记录上次的位置。
在进行标记或滑动时重置下标。
为了发现超时的，在时间参数 相同的时候 使用上次的位置继续搜索。
时间是  System.currentTimeMillis()
虽然这个方法不准确，可能偶尔是基于时间片 15毫秒或者多少毫秒  变动一次。
但是 失效的次数太多了。导致6w需要10秒。
抹去末尾部分，比如 curTs-=curTs%1000
发现6w 可以在几百毫秒内执行完毕。基本满足需求，但是  会导致rto的之后
超时重传的滞后。
%100  大约300毫秒执行完毕
%10 大约450毫秒

%10基本可以接受。
同时可以进行优化，needOne的时候  记录前面最小的过期时间和下标
当curTs 小于的时候，从目标开始搜索。

。。。。又变成input积压了

当snd_segments.size >5000的时候 百分之50概率 takeSend直接返回0
发现改善了。 瓶颈主要就是takeSend和input的开销上。
目前基本只能5M 上限传输.极限10M.cpu消耗略高
已接收5.2490234375
end1收到出站数据了你好
已接收51.966644287109375
end1收到出站数据了你好
传输完毕耗时9074

测试发现input处理好慢，之前测试错了。确认input也很慢了。。。但是好像没什么地方可以优化
耗时：545  takeSend  6w
耗时：48732 input  6w(存在丢包)  每秒只能input1000？
似乎是头部的 rcv_dr  已经接受了的  因为没被取出，所以每次循环都从头遍历的问题。

优化方案。
1.也使用缓存，但是dr类已经很乱了，现在简单特定情况加了  下标缓存 之后不知道什么时候再用做其他东西的时候可能埋坑。
2.直接取出ack，但是不更新rcv_offset。（避免远端滥发数据），需要维护一个偏移量。
每次使用rcv_offset的时候  都需要减去偏移量 容易出错。（real_rcv_offset）
real_rcv_offset 作为rcv_dr的起始。rcv_offset 作为 rcv_buf的起始。
X_X，不想改了。优化方案1吧，改偏移  乱七八糟的  都不知道哪里改了哪里没改  定位也麻烦。

缓存连续的ack类型的最后一个的下标。和距离。
再滑动后和标记  这个距离之前的 时 重置缓存。
或者
方案3.及时的recv。


目前100M 8秒。感觉提升不上去

但是测试里，之前6w 处理了一分钟。现在几百毫秒。
说明性能问题是在 rcv_dr for循环 统计 连续的ack的数量上。
目前 100M 7秒~十几秒  应该是极限了

超时重传是多余的，如果是在需要的时候取出指定大小的数据包。不适合开启 超时重传，只适合快速重传来触发标记丢失。

最快6秒

========
发现偶尔停滞。没有开启超时重传，snd_segments就算满了，也有概率发出去（写了个0.5概率就返回）
发出去被确认，应该就触发了快速重传，但是查看发现没有积压的数据等待input。
应该是哪个步骤出问题了。

一开始以为是之前因为ackmask性能问题限制了 最大发送8
导致的末尾的确认没被收到。但是解除限制后依旧没有快速重传，并且ackmask一直增长，发现 发生了积压现象。
说明ackmask的性能问题。。。。确实有问题

如果放弃ackmask。包里就不需要 una了

但目前是  基本只有一种包。设置不同的标识位增加数据和ackmask。
如果引入额外的ack包。有时候 只takeSend一次的话。可能取不出来。

啊？翻了一下kcp，segment发现里面有个叫ackmask的 long类型
啊？做什么用的
好像是只有64位  一样功能的...位图一样按位标记第几个是否接收了的
啊？名字也一样emmm 一开始命名的时候bitset mask什么的想了半天用了ackmask
结果撞了，难道是之前什么时候看见了  下意识选了这个名字。太巧了

private long[] acklist = new long[8]; 好像这个字段是记录哪些已经标记的
也有自动扩容功能
不对。。好像是list一样  记录哪些sn收到了。（为什么不直接用ArrayList
    private void ackPush(long sn, long ts) {
        int newSize = 2 * (ackcount + 1);
        if (newSize > acklist.length) {
            int newCapacity = acklist.length << 1; // double capacity
            if (newCapacity < 0) {
                throw new OutOfMemoryError();
            }
            long[] newArray = new long[newCapacity];
            System.arraycopy(acklist, 0, newArray, 0, acklist.length);
            this.acklist = newArray;
        }
        acklist[2 * ackcount] =  sn;
        acklist[2 * ackcount + 1] =  ts;
        ackcount++;
    }

好像是  偶数 序号 奇数 时间戳


重新分析了下我的停滞原因。似乎是之前测试总是重发然后  把快速重传改的特别大来屏蔽了。和最小rto也改了。
再加上ackmask的问题，由于sn不会重发。ackmask也截断。导致发现被跳过的机制无效。
加上去之后  总觉得有不必要的被重传了。重传的较多
传输性能稳定在8秒左右

性能测试 大概6w takeSend input 都在500毫秒左右
虽然在1s内，但是 实际性能为什么最多为什么只有十M
很多都进行了优化，突然发现ackSn方法有问题
有的方法循环seg进行判断是否确认 然后再调用ackSn方法进行处理
但是，循环了2次。先是找到seg 然后ackSn(seg.sn) 里面又循环了一次
目前感觉性能微乎其微，暂且优化试试，只优化input没办法，takeSend 已经没办法优化了
果然没啥用，设计的太糟糕了，写的也菜 只能做到这种程度了
完蛋啦 不知道改到了什么  停滞了  也没任何输出信息
end1收到出站数据了你好
已接收28.283050537109375
end1收到出站数据了你好
已接收28.283050537109375
end1收到出站数据了你好

发现snd_dr出问题了。。。啊？
第一个的length  异常 超出了mtu
Range{sendcount=0, start=0, length=49771008, type=0, ts=0, sn=0, rto=0}

ctrl+z 一路撤回 正常了
。。。没有正常


发现是ackmask的滑动改错了。
acksn又优化回去了。性能上升了......
现在是极限偶尔5秒多 100M ....
        //所有小于una的都进行确认
        for (int i = 0; i < snd_segments.size(); i++) {
            Segment cur = snd_segments.get(i);
            if (_itimediff(rmt_una, cur.sn) > 0) {
//                ackSn(cur.sn);
                ackSeg(cur);
            }
        }
end1收到出站数据了你好
已接收82.52777099609375
end1收到出站数据了你好
已接收89.99188232421875
end1收到出站数据了你好
传输完毕耗时5327

已接收99.846923828125
end1收到出站数据了你好
传输完毕耗时4638

极限4秒多

已经放弃思考了，又出现了停滞

解决了，就是之前思考的问题
ackmask。
丢包的时候  才会出现ackmask
上面 对小于una的进行确认。
后面又遍历位，ackSn
现在放到了一个循环里
几乎不会阻塞了
稳定5秒左右

感觉性能消耗全都是在循环上


不对 停滞还有其他原因
收到ackmask390  seg.una58952 [-128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 127]
有ackmask
收到ackmask390  seg.una58952 [-128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 127]
end1收到出站数据了你好
有ackmask
收到ackmask390  seg.una58952 [-128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1]
已接收77.12454223632812  队列：0	0
有ackmask
收到ackmask390  seg.una58952 [-128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1]
end1收到出站数据了你好
有ackmask
收到ackmask391  seg.una58952 [-128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 1]
有ackmask
收到ackmask391  seg.una58952 [-128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 3]


没有积压了  但是偶尔停滞了，说明丢失的没被重发？
太多seg了 看不出来。
只看到第一个 resend 为true  且dr里 对应的type为1
难道是 重发的  倒霉也丢包了  导致只能超时取出了
但是理论上后续发的包也会被ack。如果丢了，被跳过确认  就会再次标记未发送
下次能立即取出
但是看ack输出的长度 正常增长了，重发的包丢失了  应该也能被发现

算了，知道大致原因  明天再写个测试  丢包后重发且又丢包的测试


。。。貌似正常

不对
前面的 range  sendCount是1  如果是重发的应该是2
.。。。好难复现  试了几十次  不想碰见的时候 总出现，想的时候几十次都没出现

突然发现checkRange 也可以优化。作用是检查是否已接受的，避免将已接受标记为丢失。
性能又好了一点点

啊啊啊啊啊啊啊啊啊啊啊@#*%&*@$^*@^%*
是不是有bug啊是不是有bug啊

是不是有bug啊

是不是有bug啊

是不是有bug啊

是不是有bug啊

偶尔一大串重发，太反常了。
之前那个停滞的没有遇见，难道是dr checkRange有问题，没看出来啊。
重发是先isAcked 检查范围是否被确认 里面用的checkRange啊
优化后重写 测试n次，性能很好，但是之前的停滞bug没遇见了。测试很久了，啊？？？
不怕bug就怕bug突然不出现了。感觉也没修啊

还有之前debug模式  必然耗时增加  到十几秒或者20秒才结束。
现在也是5，6秒左右了。为什么啊。
性能好了是挺好的，但是为什么会之前debug运行会 减慢运行
现在不减慢了。

看了下批量重发的，收到了  头部连续的未接收的ackmask  看样子没问题

又出现停滞bug了。
sendCount1   rto不为0  resend=true
被跳过了 应该标记为 unsend
但是没有，说明没有执行markRangen(,,unsend)
不对。。看逻辑应该是调用了
加个再次检查 断点看看
一百年过去了，还没触发
好难复现好难复现好难复现

复现了，但是并没有进断点
                                //标记为UNSENED 是为了takesend能立即取出  而不是等待超时取出
                                snd_dr.markRangen(start, len, DataRange.UNSEND);

                                        if(snd_dr.rangeCheck(start,len,DataRange.UNSEND)==false){
                                            System.out.println("发现停滞原因");//没进
                                        }

                  if (isAcked(payload.offset, payload.length)) {
                                System.out.println("快速重传只传未接收部分");//这一句也没输出
                                continue;
                            } else {
看样子不是dr问题？

收到ackmask119  seg.una41451 [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -128, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 63]
---标记2——9632_1376  snd_offset56843584
---标记2——11008_1376  snd_offset56843584
---标记2——12384_1376  snd_offset56843584

发现缺失一部分没有标记
同时发现 在之前也触发了重发，snd_offset 跨度44MB(应该是正常的  测试时缓冲区100M)

快速重传标记方法是  
skipCountIncrement
增加被跳过的次数，达到重传要求 则重传

在之前应该进行了滑动。slideSnd
标记2 暑促和信息  应该是0开始，滑动后  最左边的数据应该是未确认的。

。。。。。。。。。。。。。。。
Segment是参考的kcp的 复用，虽然我这个没必要。但是写了。
来回增删字段 有的不使用。和优化，一开始测试  来回维护太麻烦 就没用recycle回收
相当于直接new的
后来优化加上了。遇到过几次，没重置值。
后来重置了，然后才想起  前天又把 recycle 用了。但是性能并没有什么提升。就没管了
发现。。。。resend没重置为false
。。。。

应该解决了

。。。。测试量换成了200M
7秒完毕。（啊？100M 5秒 200M7 秒）
就是说 持续使用的时候，应该能正常用吧。虽然达不到网上下载的KCP的  单机50M 每秒6w包的性能
10,11秒300M
性能大概是KCP一半。（应该不是，下载的kcp-netty 瓶颈应该是 本地UDP包6w  而我是 每秒处理性能太低）

摆烂了  已经。。很厉害了。。
低的超乎预期，为什么本地会那么慢啊，为什么tcp可以达到700MB每秒啊
为什么本机UDP还会丢包的啊
为什么for循环那么吃性能的啊
为什么啊




凑合能用的程度吧。。就差  拥塞窗口和 rto了
这个协议不适合 计算rto大概
毕竟主要只有  send(拷贝要发送的数据到缓冲区) recv(拷贝出已接受数据)  takeSend(取出不超过指定大小的包)  input(数据包传入)
无法主动发送数据，只能被动的 被调用 取出数据 来发送
在需要的时间节点  和包大小  进行发送用。
不是以低延迟为目的。

针对包数量的窗口也不需要，动态的调整rcv_buf_size 应该就能实现同样的目的


解压成功448/33    压缩前/压缩后
解压成功385/28
解压成功112/17
加了Snappy压缩 ackmask 懒得设计其他ack机制了。对ackmask直接进行了压缩。偷懒

突然想到一个问题。。。目前没怎么测试丢包场景。
最初只是测试丢包能完成传输（耗了很久  传输完毕）
现在是测试实际在udp上传输 虽然是本地 的性能
ackmask是偶尔丢包才会触发。
目前的设计不知道在频繁丢包的场景  会不会瞬间骤降  积压

百分之20丢包率  16秒完毕。（大量输出ackmask等调试信息）

收到ackmask486  seg.una91504 [-12, -49, -4, -3, -70, -9, -3, -89, -9, -19, -17, 126, -19, -65, -25, -101, -13, -5, -14, 63, -43, -5, -21, -1, -18, -9, -13, -1, 31, -1, 95, -15, -1, 29, -15, -9, -33, -67, -34, -36, -1, 122, -29, 108, 91, -2, -42, -81, 53, -85, -98, 127, 119, -9, -33, 119, -1, -1, -65, -1, 122, -13, -13, 110, -70, -2, 119, -3, 121, -33, -1, -30, -33, 109, -10, -1, 95, 127, -9, 55, -17, -65, -14, -1, -42, -4, -65, -29, -60, -1, -33, -126, -5, -4, -1, -82, -35, -65, -97, -1, -65, -54, -1, -4, -26, 127, -49, -9, -3, -5, -51, -69, -18, -5, -69, -1, -3, -1, -97, -66, -41, -70, -9, -22, -1, -43, 95, -17, -34, -37, -6, -83, -38, 62, -65, 62, -1, -1, -81, -50, -15, -9, -3, -10, 45, -101, -25, 88, -1, 94, -94, -5, 86, -1, -10, -3, -17, -1, -105, -100, 87, -1, -20, -1, -9, -25, -33, -5, 59, -43, 119, -25, -33, -65, -115, -33, 111, -50, -9, 127, 95, -1, -1, -34, -33, -5, -1, -5, -69, -1, -1, 99, -81, -2, -65, -65, -1, -65, 61, 127, -1, -1, -1, -97, -65, -26, -5, 125, -1, -1, -41, -49, 92, 95, -20, -3, -1, -3, 63, -65, -17, 127, -5, -5, -5, -3, -3, -3, -14, -67, -1, -69, -1, -65, 126, -25, 127, 50, -11, -33, -11, -66, -9, -34, -2, 59, -50, -66, -81, -21, -1, -37, 111, -1, 124, 127, -49, -9, -81, -77, -33, 127, -14, -49, -2, 53, -57, -17, -9, 124, -1, 123, -4, 33, -65, -14, -103, -5, 123, -33, 121, -67, 119, -1, -1, -107, -1, -1, -5, -33, -67, 119, -17, -9, -41, -19, -5, -97, -33, -10, -46, -1, -37, -2, 87, 91, -9, -1, 125, -6, -33, -65, -57, -65, -1, -37, -3, 103, -27, -3, -5, -110, -17, 93, 103, -3, -5, -66, -100, 127, 111, -13, -17, 91, -1, -3, 126, -81, -65, -39, -3, -47, -65, 93, 127, -3, -68, 63, -17, -41, -41, -18, -13, -11, -68, -17, 61, -53, -10, -3, -77, -25, -1, -1, -2, -30, -4, 119, -33, -9, -81, 63, -38, 55, 78, -10, 56, -27, -85, -35, -65, -1, 119, -3, 110, -1, -67, -13, -1, -1, -99, -2, -9, 127, 119, -21, -1, -17, -12, -36, 127, -3, -5, -5, -25, -53, -1, -9, 95, -1, 125, -34, 127, 58, -9, -1, 23, 77, -1, -77, 95, -44, 61, -17, -2, -1, -67, -3, -65, -2, -1, -3, -4, -37, 111, -1, -9, -1, -33, 53, -7, -33, -1, -73, 55, -18, -35, 95, -1, -33, -12, 123, -33, -110, -1, -3, -12, -19, -2, -2, -1, -33, -17, 127, -6, -1, -4, -66, -33, -3, 107, 77, -33, -1, -65, 127, -12, -1, -11, -9, -43, -35, 126, 117, -1, 31]
有ackmask
收到ackmask491  seg.una91629 [-100, -33, -105, -1, -87, -34, 95, -1, 119, -65, -97, -1, -1, -8, -1, -118, -1, -17, -120, -65, -1, -18, -11, -26, -2, -41, 27, 103, -37, -14, -73, 126, -83, 89, -11, -4, -69, -69, -1, -66, -5, -1, -1, -3, -41, -101, -97, 119, -45, -11, -65, -21, -49, -5, -2, 23, -1, 110, -77, -1, -1, -6, -69, -65, 121, -1, -107, -1, -73, -26, -1, 29, 39, -2, -1, 22, -36, -25, -1, 119, -19, -2, -3, -4, -1, 85, -2, -25, 55, -1, 123, -66, -17, -33, 111, -34, 117, -33, -33, -3, -17, -1, -1, -12, -67, -42, -67, 87, -1, -81, -2, 122, -9, -34, -42, 111, -43, -10, -7, -11, -7, -1, 127, 117, -114, -65, -17, -73, 111, -39, 60, -57, -6, -9, 18, -35, -73, -6, -73, -17, 127, -1, -65, -28, -68, -6, 103, -1, -65, 63, -1, -34, -33, -87, -66, 59, -1, -2, 109, -4, 126, 115, -66, -1, -5, -6, -1, -9, -2, -34, -1, -33, -33, -3, -1, 31, 123, -11, -1, -3, -3, -1, -19, -7, -5, -1, -1, -1, -4, 53, -33, -17, -5, -1, -65, 126, -26, -6, 98, -17, -1, -17, -1, -7, 125, -1, -37, -33, -33, -17, -17, -17, -105, -17, -3, -33, -3, -1, -11, 59, -1, -109, -87, -1, -82, -9, -67, -9, -10, -33, 113, -10, 125, 93, -1, -33, 126, -5, -25, -5, 123, -66, 127, -99, -3, -2, -109, 127, -10, -81, 57, 126, -65, -25, -5, -33, -29, 15, -7, -107, -49, -36, -33, -5, -50, -21, -67, -5, -1, -81, -4, -1, -33, -1, -18, -67, 123, -65, -65, 110, -33, -1, -4, -74, -105, -2, -33, -10, -65, -38, -70, -1, -17, -45, -1, -2, 61, -2, -3, -33, -18, 63, 43, -17, -33, -105, 124, -17, 58, -21, -33, -9, -27, -4, 123, -101, 127, -33, -6, -17, -9, 123, -3, -51, -18, -113, -2, -19, -6, -21, -25, -3, 121, -65, -66, 118, -97, -81, -25, 125, -17, 89, -74, -17, -97, 61, -1, -1, -9, 23, -25, -65, -5, -66, 127, -3, -47, -66, 113, -78, -57, 41, 95, -19, -2, -3, -65, -21, 119, -5, -17, -99, -1, -1, -17, -12, -65, -1, -69, 91, -1, 127, -89, -25, -2, -21, -33, -33, 63, 95, -2, -65, -1, -6, -17, -13, -2, -45, -71, -1, -65, 104, -6, -97, -3, -94, -18, 121, -9, -1, -17, -19, -1, -11, -1, -17, -25, -33, 126, -5, -65, -1, -1, -82, -55, -1, -2, -65, -67, 113, -17, -2, -6, -1, -90, -33, -5, -106, -4, -17, -89, 111, -9, -9, -1, -1, 126, -1, -45, -1, -25, -9, -3, -18, 95, 107, -6, -2, -1, -3, -93, -1, -81, -65, -81, -18, -10, -85, -5, -1, -66, -1, -4, 127, -3, -34, -5, -33, -37, 63, -3, -1, -10, -4, -39, -19, 111, -3, -1, -2, 1]
有ackmask
收到ackmask306  seg.una93331 [-66, -9, 127, -9, -1, -41, -17, -4, 79, -90, -2, -69, -34, -9, -34, -37, 127, -57, -39, -9, 117, -3, 127, -5, -19, -97, -17, -17, -7, -2, 117, -10, -5, 79, -2, -39, -65, -26, -8, -3, -98, -17, 127, -113, 63, -28, 87, 62, 115, 127, -17, 59, -81, -9, -18, -1, -65, -14, -1, 127, -1, -69, -9, -18, -3, -2, -70, 125, -1, -13, -37, 94, -6, 127, -37, -1, 106, -21, -2, -65, 79, -1, -5, -9, -8, -9, 127, -69, -1, -84, -68, 127, 95, -14, -67, -21, -84, 127, -33, -105, -13, -17, 109, -2, 125, -21, -65, -33, -17, -11, 55, -69, 63, -6, -73, -21, -81, -97, -9, -25, -3, -6, -38, 125, -66, -98, -9, -67, 103, -39, -66, 127, -10, -4, -1, -33, 95, -100, -1, -18, -5, -2, -11, 71, -5, -58, -55, 30, -89, 124, -75, -5, -9, -1, -82, -33, -19, -65, 119, -2, -1, -65, -45, -1, -2, -17, 110, -3, -1, -99, -98, -5, -81, 127, 127, -1, 124, -7, -1, -2, -21, -65, -49, -5, 79, -25, -2, -1, -94, -23, 127, -10, -117, -70, -25, -35, -1, -65, -73, -1, -41, -1, -65, -97, 127, -5, -19, -1, -2, -1, -69, 38, -1, -5, -1, -10, -58, -67, -5, -21, -1, -101, 126, -17, 91, -14, -65, -97, -66, -35, -33, -1, -1, -5, -3, 79, -1, -97, -33, -9, -69, 127, -83, -23, -5, -1, -9, -113, -2, -65, -2, -66, -70, -37, -81, -18, -1, -5, -2, -13, -1, -11, 123, -17, 127, 111, -1, -12, -1, -37, -13, 103, -73, -65, -11, -1, -5, -33, -38, -1, -4, -41, -13, -1, 43, -11, -9, 106, -66, 125, -66, -102, -5, -2, -18, -97, -4, -117, -34, -13, -81, -65, -1, -2, -7, 29]
有ackmask

随机丢包的情况，压缩无效。只能发送特别长的ackmask
如果是突发丢包  压缩才有效。均匀的丢包  无法压缩

偶尔刷了这个
bug..超出 payload 跨度过大
bug..超出 payload 跨度过大
bug..超出 payload 跨度过大

不是bug
payload是 第一个 偏移是4字节 之后的是 相较于上一个的末尾 的偏移 只用了2字节。
且排列是有序的，如果跨度超过 2字节能表示的，就无法放入了。
最初什么字段都是varint设计的，但是太复杂了，总是计算错需要多少  能写入多少  之类
就放弃了。这个跨度只是这个包不打包了，可以放到下次打包。
如果重新设计，确实可以尽可能的打包，但是懒得改了。
比如  不使用相对偏移前一个，而是每个都使用4字节。
但是感觉有点浪费。虽然数据包的头部比最初预想的本身就大了很多。只是懒得改了

好奇怪，给KCP-netty  这个项目测试  加上了百分之20丢包。
每秒能穿14MB左右  我的100M 传15秒左右，怎么算 都是性能接近一半。。。
越看越觉得我的ackmask有点多余。kcp的怎么弄的，网上搜索没搜到，懒得查了。。。源码不想翻了


之前测试  限制ackmask 最大8字节或者16字节等
但是  设计问题，导致无法触发被跳过。除非携带  最大收到的sn号。
不然  ackmask不完整的发送，导致未收到的部分无法发现被跳过来触发快速重传
只能等待超时触发重传，

比如 第一个丢失的 重发了。倒霉也丢包了。
但是刚好在ackmask外。就无法发现 他丢了，只能等rto。
目前等于是没开启rto。因为计算好像有问题（直接复制的kcp   我的ts计算也有问题）
开启再试试

。。开启后总刷  忽略过时的
说明数据已经接受了，依旧被重发了。可能是ackmask之外的  没被确认，误以为超时了。
左脚绊右脚  右脚绊左脚 我这设计的什么玩意

而且积压了，说明input处理不过来了
已接收17.46048927307129  队列：0	40362
已接收17.46048927307129  队列：0	40650
已接收17.46048927307129  队列：0	40762
已接收17.46048927307129  队列：0	40899
已接收17.46048927307129  队列：0	41084

目前基本在大流量是无法传输，在小流量  几KB 应该是可以使用（ackmask问题）


测试改成持续测试，又遇到了积压
发现 输出 “发生异常”  下一句是抛出异常  。。。居然没打印任何红字


。。。又发现刷了这个....
                                if (range.sendcount > 100) {
                                    System.out.println("bug!!!!!!!!!!!!!!!!!?");
                                }
        if (_itimediff(segment.sn, rcv_next_sn) > 200000) {
            throw new RuntimeException("收到了过大的sn" + segment.sn + "," + rcv_next_sn);
        }
........放弃思考


emmmm好像是发生了停滞
有ackmask
收到ackmask1  seg.una3533 [2]
忽略过时的-2145607620 diff-4191558
有ackmask
收到ackmask1  seg.una3533 [2]
忽略过时的-2145606247 diff-4190185
有ackmask
收到ackmask1  seg.una3533 [2]
忽略过时的-2145604874 diff-4188812
有ackmask
收到ackmask1  seg.una3533 [2]
忽略过时的-2145549954 diff-4133892

似乎是持续的传输 超过了2G
snd_offset 变为了负数  哪里的逻辑出了问题

不对。。。没负数的时候就停滞了
有ackmask
收到ackmask1  seg.una2046 [2]
忽略过时的1294664133 diff-771069
有ackmask
收到ackmask1  seg.una2046 [2]
忽略过时的1294666879 diff-768323
有ackmask
收到ackmask1  seg.una2046 [2]
忽略过时的1294668252 diff-766950

之前测试解除了  snd_segments.size 大于指定数量时  概率直接返回，防止发送太多积压
加回去正常了
发现  snd_offset 负数不影响传输。问题就是发送的数据太多了，积压了


奇怪 持续测试  一直刷 已接受99
停滞这里了。没见ackmask剧增和阻塞。
难道是统计出问题了？但是应该是同步的啊。不应该出错。



停滞似乎是ackmask  无法完全传输。（还是要改成其他ack）
但是
sn不允许重发导致的  拖长una和最新的una 的区间  问题是主要的



有ackmask
收到ackmask1374  seg.una21590649 [126, -1, -2, -33, -3, -5, -9, 119, -65, -1, -3, -41, 123, -7, -28, -67, 125, -26, -9, -43, -1, -69, 127, 119, -19, -13, -67, -67, -5, -55, -97, -2, -49, -17, -3, -21, -67, -1, 61, -1, 63, 127, -69, 126, -33, -5, -14, 110, -1, -2, 61, -79, -1, -17, -25, -13, -17, 95, -11, -5, 127, -4, -2, 127, -1, -1, -2, -5, -34, 123, 127, -9, -1, -81, 127, -1, -2, -46, -6, -1, -19, -65, -1, 127, 119, 127, 31, -5, 119, -4, -37, 95, -10, -5, -17, 95, -1, -5, -1, -10, -1, -82, -1, -31, -1, -1, -8, -69, 105, -59, -34, -35, -7, -65, -14, -1, -34, -1, -17, -81, -65, -33, -105, -1, 123, -13, 95, -33, -1, -43, -17, 127, -2, -5, -65, 86, -32, -18, 107, -1, -1, -101, -33, -17, -65, 62, 79, -33, -19, -1, -27, -5, -4, -9, -2, 121, -5, 116, 79, 127, -11, -3, -108, -9, -82, -65, 127, -67, 108, -97, 91, 90, 63, -85, -1, 127, -65, -18, 119, -2, -41, -22, -3, -34, -25, -35, -9, 125, -17, -37, -65, -42, 63, 127, -67, -33, -5, -2, 127, 125, -10, 127, -1, -81, -9, -19, -66, -33, -3, 123, -3, 127, -7, -3, -33, 108, -1, -1, 51, -3, -13, -3, -1, -34, -65, -19, -1, -19, -3, -1, -2, -33, -17, -21, -1, -5, -6, -1, -10, -33, -9, -1, -41, -49, 123, -21, -1, -2, -1, 95, -9, -17, -3, -1, -22, -9, -5, -5, -10, -76, -39, -1, -11, -1, -18, -10, -7, 127, -83, -33, -2, -65, 54, -66, -1, -1, -37, -17, 47, -5, -1, 122, -2, -33, -106, -65, -3, -81, -49, -1, -9, -25, -3, 95, -9, 123, -9, -65, -11, -21, -1, -33, -21, -18, -3, 123, -75, -71, -33, 123, -33, 123, -21, -5, -25, -66, -53, -17, -9, 127, -3, -26, -33, 125, -1, 79, -27, -49, -1, -1, -69, -5, -1, -45, -1, 127, -3, -1, -11, -46, -3, -29, -1, -33, -2, -2, -10, -5, -34, -6, 125, -8, -29, -19, -65, -1, -26, -1, -34, -9, 117, -42, -69, -1, -87, -23, -25, -1, -5, -65, -10, -33, -18, -12, -57, -1, -1, -35, -35, -35, -98, -65, -3, -1, -81, -9, -1, -7, -3, -67, -17, -33, -17, 105, 122, -65, 124, 127, -7, -3, -9, -97, -25, -9, -19, -9, -12, -49, -65, -1, -33, -25, -66, -2, 63, -46, 111, -34, -2, 74, -4, 125, -17, 121, -13, 62, -45, -1, -1, -65, 117, -1, 127, -2, -4, -2, -1, -86, -11, -4, -9, 94, -99, 126, -2, -1, -6, 95, -1, -43, -11, -21, -68, -6, -28, -69, -99, 63, -50, -4, -5, -2, -81, -69, -3, 123, -2, -65, -101, -49, -49, -2, 125, -17, -1, -1, -17, 125, -2, -9, -22, -17, -65, -1, 125, -3, -1, -5, -13, -9, -4, -1, -1, -41, -25, -65, 95, -66, 114, -98, -66, 119, -2, -1, -2, -5, -1, 127, -1, -19, -1, -6, -1, -65, -34, -11, -33, -17, -73, 110, -17, -65, -3, -71, -1, -79, 79, 47, 26, -37, -9, 103, -1, -1, -1, -9, -85, -1, -2, -104, -41, 48, -9, -65, -5, -13, -65, -3, -2, 127, -82, -3, -23, -37, -23, -3, -9, -41, 127, -27, -1, -21, -5, 83, -121, -67, -38, 97, -65, -9, -1, 105, -33, -89, -2, -9, -17, -1, -41, -1, -5, -25, -1, -73, 111, -69, -9, -73, -33, -43, -1, -17, -81, -1, -3, -3, -33, -21, -41, -68, -97, -10, -2, -3, -49, -1, -5, 127, -9, -34, -36, 63, -65, 127, -99, 111, 110, -3, 103, -17, -89, -36, -3, 127, 115, 122, 124, -101, -5, -2, -1, -3, -3, -1, -11, -1, -9, -105, -53, -27, 91, -43, -105, 126, -33, -17, -18, -35, 93, -3, -24, -113, -103, -8, -17, 126, -1, -1, -67, -33, -7, 89, -17, -9, 111, 126, -43, -33, -74, -1, 126, 58, -1, -1, -1, -82, -1, 79, -3, 111, -36, -49, -5, -67, -1, -33, -71, -17, -36, -1, -7, 13, -9, 127, 109, -1, -4, 111, -10, -67, -33, 62, -1, 125, -5, -49, 25, -1, -35, -17, -41, -1, 106, -1, -81, -53, -41, -17, 95, -73, -1, 79, -1, -9, 63, -113, -3, -27, -33, -1, -37, -19, -99, -5, -9, 127, -17, -9, -65, -114, -57, -3, -1, -17, -3, -69, -9, -73, -27, -14, -1, -9, 120, -33, -100, -15, -9, -14, -33, -25, -34, 127, -1, -2, -17, -65, -49, -26, -37, -5, -70, 94, -66, -105, -81, -2, -49, -34, -65, -37, 23, 111, 55, -3, -33, -75, -81, -1, -68, 127, 127, 127, -1, -5, -26, -1, 61, -55, -9, 43, -1, -33, -113, -3, 127, -59, -1, -17, 62, -26, -33, -2, -65, -9, -33, -7, -1, -81, -19, -72, -17, -65, -5, -33, -5, 106, -69, -2, -36, -3, 111, -1, 79, -17, -9, -7, -3, -2, -1, -33, -15, -65, 127, 115, -20, 29, -33, -1, -33, -15, -2, 119, -66, 87, -21, -1, 51, -99, -2, 123, -105, -5, -17, 62, -17, -1, -10, -57, -85, -67, -83, -1, -65, -1, -13, -3, -1, -18, -1, -19, -1, -1, -19, -14, -1, 87, -1, -37, -17, -1, -5, -13, 117, -18, -123, -65, -17, -1, -10, 97, 123, -82, -41, -6, -5, -68, -1, 91, -1, 119, -97, -1, -67, -65, -1, -17, -17, -21, -1, 63, -79, -1, -9, -17, -4, -5, -1, 51, -65, -53, -121, -1, -49, -9, -78, -73, -3, -49, -10, -33, -17, -1, 107, 94, -9, -5, -4, -9, -113, 127, -8, -1, 127, -81, -89, -37, -18, -9, -119, -34, -1, -35, -5, -73, -113, -1, -67, -97, -99, 78, -33, -66, -82, -9, -33, -7, -9, -29, -5, -1, -19, -10, -21, 127, -66, -13, -1, -1, -1, -41, -18, -78, -99, -7, -61, -65, -69, -1, 127, -17, -67, -91, -5, -4, -1, -1, -1, -121, -43, -34, 95, -75, -21, -17, -4, -6, 126, -10, -33, -2, -1, -1, -1, -29, -1, -11, -11, -65, -10, 111, 127, 127, 127, -66, -1, -1, -121, -3, 119, -33, -22, -69, -9, -3, -1, -20, -35, -41, -5, -1, -33, -10, -1, -97, -10, -65, -17, -1, -65, -10, -57, -2, -65, -1, -1, -3, 127, -23, -70, -5, -1, -105, 88, 14, -1, -5, -109, -65, -1, -7, -97, -37, -3, -9, -67, 127, -9, -97, -5, -3, -87, -3, -17, -41, -2, -19, -97, -19, -25, -29, -5, 85, -3, -9, -18, 127, -35, 55, 127, -3, -1, 111, 111, -37, -1, -8, 95, 127, 127, -1, -2, -1, -45, -6, -17, 127, -105, -2, 103, -33, 111, -2, -33, 123, -3, -3, -19, 127, -2, 119, 126, -107, -17, -17, -1, -4, -66, 126, -71, -33, -45, -86, -1, -73, -94, 59, -69, -1, -15, -1, -41, -2, -65, -105, -65, 111, -3, -77, -1, 95, -109, -2, -9, 63, -1, -48, 127, -1, -42, -33, 122, -1, -1, -1, -10, -11, 127, -3, -3, -2, 124, 111, -3, -65, -4, -1, -104, -13, 123, 95, -17, -9, -1, -39, -17, -65, -65, -1, -1, -35, 93, -67, -57, 102, 62, -18, -17, -69, -1, -25, -2, -1, -1, -3, -27, -3, -37, -35, -65, -72, -5, 127, 95, 31, 63, -33, -19, 62, -1, -2, -3, -2, -17, -36, 127, -65, -10, 127, -33, -65, -9, -4, 123, -5, -22, -74, -68, -1, 61, -2, 115, -18, 111, -9, -2, 127, -6, 127, -49, -19, -1, -2, -29, -1, -2, -1, 123, -1, -9, -25, -2, -10, -21, -47, -1, 123, -1, -1, -3, 95, 43, -37, -2, -41, 127, 109, -1, -9, 91, 107, 106, -1, -50, -4, -67, 126, -2, -1, -2, 122, -15, -3, -35, -31, -25, -45, -3, -5, -5, -6, -39, 95, -10, -3, -1, -33, -1, -33, -11, -5, -1, -17, -33, -9, -35, -38, -1, -33, -1, -17, -65, -1, 123, -3, -3, -37, -9, -1, -21, -29, 117, -73, -1, -5, -66, 120, -65, -7, -69, -1, -1, 127, -1, -4, -15, 119, -65, -43, -5, -76, 127, -3, -65, 127]
已接收27.683996200561523  队列：0	0
有ackmask
收到ackmask1368  seg.una21590649 [126, -1, -2, -33, -3, -5, -9, 119, -65, -1, -3, -41, 123, -7, -28, -67, 125, -26, -9, -43, -1, -69, 127, 119, -19, -13, -67, -67, -5, -55, -97, -2, -49, -17, -3, -21, -67, -1, 61, -1, 63, 127, -69, 126, -33, -5, -14, 110, -1, -2, 61, -79, -1, -17, -25, -13, -17, 95, -11, -5, 127, -4, -2, 127, -1, -1, -2, -5, -34, 123, 127, -9, -1, -81, 127, -1, -2, -46, -6, -1, -19, -65, -1, 127, 119, 127, 31, -5, 119, -4, -37, 95, -10, -5, -17, 95, -1, -5, -1, -10, -1, -82, -1, -31, -1, -1, -8, -69, 105, -59, -34, -35, -7, -65, -14, -1, -34, -1, -17, -81, -65, -33, -105, -1, 123, -13, 95, -33, -1, -43, -17, 127, -2, -5, -65, 86, -32, -18, 107, -1, -1, -101, -33, -17, -65, 62, 79, -33, -19, -1, -27, -5, -4, -9, -2, 121, -5, 116, 79, 127, -11, -3, -108, -9, -82, -65, 127, -67, 108, -97, 91, 90, 63, -85, -1, 127, -65, -18, 119, -2, -41, -22, -3, -34, -25, -35, -9, 125, -17, -37, -65, -42, 63, 127, -67, -33, -5, -2, 127, 125, -10, 127, -1, -81, -9, -19, -66, -33, -3, 123, -3, 127, -7, -3, -33, 108, -1, -1, 51, -3, -13, -3, -1, -34, -65, -19, -1, -19, -3, -1, -2, -33, -17, -21, -1, -5, -6, -1, -10, -33, -9, -1, -41, -49, 123, -21, -1, -2, -1, 95, -9, -17, -3, -1, -22, -9, -5, -5, -10, -76, -39, -1, -11, -1, -18, -10, -7, 127, -83, -33, -2, -65, 54, -66, -1, -1, -37, -17, 47, -5, -1, 122, -2, -33, -106, -65, -3, -81, -49, -1, -9, -25, -3, 95, -9, 123, -9, -65, -11, -21, -1, -33, -21, -18, -3, 123, -75, -71, -33, 123, -33, 123, -21, -5, -25, -66, -53, -17, -9, 127, -3, -26, -33, 125, -1, 79, -27, -49, -1, -1, -69, -5, -1, -45, -1, 127, -3, -1, -11, -46, -3, -29, -1, -33, -2, -2, -10, -5, -34, -6, 125, -8, -29, -19, -65, -1, -26, -1, -34, -9, 117, -42, -69, -1, -87, -23, -25, -1, -5, -65, -10, -33, -18, -12, -57, -1, -1, -35, -35, -35, -98, -65, -3, -1, -81, -9, -1, -7, -3, -67, -17, -33, -17, 105, 122, -65, 124, 127, -7, -3, -9, -97, -25, -9, -19, -9, -12, -49, -65, -1, -33, -25, -66, -2, 63, -46, 111, -34, -2, 74, -4, 125, -17, 121, -13, 62, -45, -1, -1, -65, 117, -1, 127, -2, -4, -2, -1, -86, -11, -4, -9, 94, -99, 126, -2, -1, -6, 95, -1, -43, -11, -21, -68, -6, -28, -69, -99, 63, -50, -4, -5, -2, -81, -69, -3, 123, -2, -65, -101, -49, -49, -2, 125, -17, -1, -1, -17, 125, -2, -9, -22, -17, -65, -1, 125, -3, -1, -5, -13, -9, -4, -1, -1, -41, -25, -65, 95, -66, 114, -98, -66, 119, -2, -1, -2, -5, -1, 127, -1, -19, -1, -6, -1, -65, -34, -11, -33, -17, -73, 110, -17, -65, -3, -71, -1, -79, 79, 47, 26, -37, -9, 103, -1, -1, -1, -9, -85, -1, -2, -104, -41, 48, -9, -65, -5, -13, -65, -3, -2, 127, -82, -3, -23, -37, -23, -3, -9, -41, 127, -27, -1, -21, -5, 83, -121, -67, -38, 97, -65, -9, -1, 105, -33, -89, -2, -9, -17, -1, -41, -1, -5, -25, -1, -73, 111, -69, -9, -73, -33, -43, -1, -17, -81, -1, -3, -3, -33, -21, -41, -68, -97, -10, -2, -3, -49, -1, -5, 127, -9, -34, -36, 63, -65, 127, -99, 111, 110, -3, 103, -17, -89, -36, -3, 127, 115, 122, 124, -101, -5, -2, -1, -3, -3, -1, -11, -1, -9, -105, -53, -27, 91, -43, -105, 126, -33, -17, -18, -35, 93, -3, -24, -113, -103, -8, -17, 126, -1, -1, -67, -33, -7, 89, -17, -9, 111, 126, -43, -33, -74, -1, 126, 58, -1, -1, -1, -82, -1, 79, -3, 111, -36, -49, -5, -67, -1, -33, -71, -17, -36, -1, -7, 13, -9, 127, 109, -1, -4, 111, -10, -67, -33, 62, -1, 125, -5, -49, 25, -1, -35, -17, -41, -1, 106, -1, -81, -53, -41, -17, 95, -73, -1, 79, -1, -9, 63, -113, -3, -27, -33, -1, -37, -19, -99, -5, -9, 127, -17, -9, -65, -114, -57, -3, -1, -17, -3, -69, -9, -73, -27, -14, -1, -9, 120, -33, -100, -15, -9, -14, -33, -25, -34, 127, -1, -2, -17, -65, -49, -26, -37, -5, -70, 94, -66, -105, -81, -2, -49, -34, -65, -37, 23, 111, 55, -3, -33, -75, -81, -1, -68, 127, 127, 127, -1, -5, -26, -1, 61, -55, -9, 43, -1, -33, -113, -3, 127, -59, -1, -17, 62, -26, -33, -2, -65, -9, -33, -7, -1, -81, -19, -72, -17, -65, -5, -33, -5, 106, -69, -2, -36, -3, 111, -1, 79, -17, -9, -7, -3, -2, -1, -33, -15, -65, 127, 115, -20, 29, -33, -1, -33, -15, -2, 119, -66, 87, -21, -1, 51, -99, -2, 123, -105, -5, -17, 62, -17, -1, -10, -57, -85, -67, -83, -1, -65, -1, -13, -3, -1, -18, -1, -19, -1, -1, -19, -14, -1, 87, -1, -37, -17, -1, -5, -13, 117, -18, -123, -65, -17, -1, -10, 97, 123, -82, -41, -6, -5, -68, -1, 91, -1, 119, -97, -1, -67, -65, -1, -17, -17, -21, -1, 63, -79, -1, -9, -17, -4, -5, -1, 51, -65, -53, -121, -1, -49, -9, -78, -73, -3, -49, -10, -33, -17, -1, 107, 94, -9, -5, -4, -9, -113, 127, -8, -1, 127, -81, -89, -37, -18, -9, -119, -34, -1, -35, -5, -73, -113, -1, -67, -97, -99, 78, -33, -66, -82, -9, -33, -7, -9, -29, -5, -1, -19, -10, -21, 127, -66, -13, -1, -1, -1, -41, -18, -78, -99, -7, -61, -65, -69, -1, 127, -17, -67, -91, -5, -4, -1, -1, -1, -121, -43, -34, 95, -75, -21, -17, -4, -6, 126, -10, -33, -2, -1, -1, -1, -29, -1, -11, -11, -65, -10, 111, 127, 127, 127, -66, -1, -1, -121, -3, 119, -33, -22, -69, -9, -3, -1, -20, -35, -41, -5, -1, -33, -10, -1, -97, -10, -65, -17, -1, -65, -10, -57, -2, -65, -1, -1, -3, 127, -23, -70, -5, -1, -105, 88, 14, -1, -5, -109, -65, -1, -7, -97, -37, -3, -9, -67, 127, -9, -97, -5, -3, -87, -3, -17, -41, -2, -19, -97, -19, -25, -29, -5, 85, -3, -9, -18, 127, -35, 55, 127, -3, -1, 111, 111, -37, -1, -8, 95, 127, 127, -1, -2, -1, -45, -6, -17, 127, -105, -2, 103, -33, 111, -2, -33, 123, -3, -3, -19, 127, -2, 119, 126, -107, -17, -17, -1, -4, -66, 126, -71, -33, -45, -86, -1, -73, -94, 59, -69, -1, -15, -1, -41, -2, -65, -105, -65, 111, -3, -77, -1, 95, -109, -2, -9, 63, -1, -48, 127, -1, -42, -33, 122, -1, -1, -1, -10, -11, 127, -3, -3, -2, 124, 111, -3, -65, -4, -1, -104, -13, 123, 95, -17, -9, -1, -39, -17, -65, -65, -1, -1, -35, 93, -67, -57, 102, 62, -18, -17, -69, -1, -25, -2, -1, -1, -3, -27, -3, -37, -35, -65, -72, -5, 127, 95, 31, 63, -33, -19, 62, -1, -2, -3, -2, -17, -36, 127, -65, -10, 127, -33, -65, -9, -4, 123, -5, -22, -74, -68, -1, 61, -2, 115, -18, 111, -9, -2, 127, -6, 127, -49, -19, -1, -2, -29, -1, -2, -1, 123, -1, -9, -25, -2, -10, -21, -47, -1, 123, -1, -1, -3, 95, 43, -37, -2, -41, 127, 109, -1, -9, 91, 107, 106, -1, -50, -4, -67, 126, -2, -1, -2, 122, -15, -3, -35, -31, -25, -45, -3, -5, -5, -6, -39, 95, -10, -3, -1, -33, -1, -33, -11, -5, -1, -17, -33, -9, -35, -38, -1, -33, -1, -17, -65, -1, 123, -3, -3, -37, -9, -1, -21, -29, 117, -73, -1, -5, -66, 120, -65, -7, -69, -1, -1, 127, -1, -4, -15, 119, -65, -43]
end1收到出站数据了你好
有ackmask
收到ackmask1374  seg.una21590649 [126, -1, -2, -33, -3, -5, -9, 119, -65, -1, -3, -41, 123, -7, -28, -67, 125, -26, -9, -43, -1, -69, 127, 119, -19, -13, -67, -67, -5, -55, -97, -2, -49, -17, -3, -21, -67, -1, 61, -1, 63, 127, -69, 126, -33, -5, -14, 110, -1, -2, 61, -79, -1, -17, -25, -13, -17, 95, -11, -5, 127, -4, -2, 127, -1, -1, -2, -5, -34, 123, 127, -9, -1, -81, 127, -1, -2, -46, -6, -1, -19, -65, -1, 127, 119, 127, 31, -5, 119, -4, -37, 95, -10, -5, -17, 95, -1, -5, -1, -10, -1, -82, -1, -31, -1, -1, -8, -69, 105, -59, -34, -35, -7, -65, -14, -1, -34, -1, -17, -81, -65, -33, -105, -1, 123, -13, 95, -33, -1, -43, -17, 127, -2, -5, -65, 86, -32, -18, 107, -1, -1, -101, -33, -17, -65, 62, 79, -33, -19, -1, -27, -5, -4, -9, -2, 121, -5, 116, 79, 127, -11, -3, -108, -9, -82, -65, 127, -67, 108, -97, 91, 90, 63, -85, -1, 127, -65, -18, 119, -2, -41, -22, -3, -34, -25, -35, -9, 125, -17, -37, -65, -42, 63, 127, -67, -33, -5, -2, 127, 125, -10, 127, -1, -81, -9, -19, -66, -33, -3, 123, -3, 127, -7, -3, -33, 108, -1, -1, 51, -3, -13, -3, -1, -34, -65, -19, -1, -19, -3, -1, -2, -33, -17, -21, -1, -5, -6, -1, -10, -33, -9, -1, -41, -49, 123, -21, -1, -2, -1, 95, -9, -17, -3, -1, -22, -9, -5, -5, -10, -76, -39, -1, -11, -1, -18, -10, -7, 127, -83, -33, -2, -65, 54, -66, -1, -1, -37, -17, 47, -5, -1, 122, -2, -33, -106, -65, -3, -81, -49, -1, -9, -25, -3, 95, -9, 123, -9, -65, -11, -21, -1, -33, -21, -18, -3, 123, -75, -71, -33, 123, -33, 123, -21, -5, -25, -66, -53, -17, -9, 127, -3, -26, -33, 125, -1, 79, -27, -49, -1, -1, -69, -5, -1, -45, -1, 127, -3, -1, -11, -46, -3, -29, -1, -33, -2, -2, -10, -5, -34, -6, 125, -8, -29, -19, -65, -1, -26, -1, -34, -9, 117, -42, -69, -1, -87, -23, -25, -1, -5, -65, -10, -33, -18, -12, -57, -1, -1, -35, -35, -35, -98, -65, -3, -1, -81, -9, -1, -7, -3, -67, -17, -33, -17, 105, 122, -65, 124, 127, -7, -3, -9, -97, -25, -9, -19, -9, -12, -49, -65, -1, -33, -25, -66, -2, 63, -46, 111, -34, -2, 74, -4, 125, -17, 121, -13, 62, -45, -1, -1, -65, 117, -1, 127, -2, -4, -2, -1, -86, -11, -4, -9, 94, -99, 126, -2, -1, -6, 95, -1, -43, -11, -21, -68, -6, -28, -69, -99, 63, -50, -4, -5, -2, -81, -69, -3, 123, -2, -65, -101, -49, -49, -2, 125, -17, -1, -1, -17, 125, -2, -9, -22, -17, -65, -1, 125, -3, -1, -5, -13, -9, -4, -1, -1, -41, -25, -65, 95, -66, 114, -98, -66, 119, -2, -1, -2, -5, -1, 127, -1, -19, -1, -6, -1, -65, -34, -11, -33, -17, -73, 110, -17, -65, -3, -71, -1, -79, 79, 47, 26, -37, -9, 103, -1, -1, -1, -9, -85, -1, -2, -104, -41, 48, -9, -65, -5, -13, -65, -3, -2, 127, -82, -3, -23, -37, -23, -3, -9, -41, 127, -27, -1, -21, -5, 83, -121, -67, -38, 97, -65, -9, -1, 105, -33, -89, -2, -9, -17, -1, -41, -1, -5, -25, -1, -73, 111, -69, -9, -73, -33, -43, -1, -17, -81, -1, -3, -3, -33, -21, -41, -68, -97, -10, -2, -3, -49, -1, -5, 127, -9, -34, -36, 63, -65, 127, -99, 111, 110, -3, 103, -17, -89, -36, -3, 127, 115, 122, 124, -101, -5, -2, -1, -3, -3, -1, -11, -1, -9, -105, -53, -27, 91, -43, -105, 126, -33, -17, -18, -35, 93, -3, -24, -113, -103, -8, -17, 126, -1, -1, -67, -33, -7, 89, -17, -9, 111, 126, -43, -33, -74, -1, 126, 58, -1, -1, -1, -82, -1, 79, -3, 111, -36, -49, -5, -67, -1, -33, -71, -17, -36, -1, -7, 13, -9, 127, 109, -1, -4, 111, -10, -67, -33, 62, -1, 125, -5, -49, 25, -1, -35, -17, -41, -1, 106, -1, -81, -53, -41, -17, 95, -73, -1, 79, -1, -9, 63, -113, -3, -27, -33, -1, -37, -19, -99, -5, -9, 127, -17, -9, -65, -114, -57, -3, -1, -17, -3, -69, -9, -73, -27, -14, -1, -9, 120, -33, -100, -15, -9, -14, -33, -25, -34, 127, -1, -2, -17, -65, -49, -26, -37, -5, -70, 94, -66, -105, -81, -2, -49, -34, -65, -37, 23, 111, 55, -3, -33, -75, -81, -1, -68, 127, 127, 127, -1, -5, -26, -1, 61, -55, -9, 43, -1, -33, -113, -3, 127, -59, -1, -17, 62, -26, -33, -2, -65, -9, -33, -7, -1, -81, -19, -72, -17, -65, -5, -33, -5, 106, -69, -2, -36, -3, 111, -1, 79, -17, -9, -7, -3, -2, -1, -33, -15, -65, 127, 115, -20, 29, -33, -1, -33, -15, -2, 119, -66, 87, -21, -1, 51, -99, -2, 123, -105, -5, -17, 62, -17, -1, -10, -57, -85, -67, -83, -1, -65, -1, -13, -3, -1, -18, -1, -19, -1, -1, -19, -14, -1, 87, -1, -37, -17, -1, -5, -13, 117, -18, -123, -65, -17, -1, -10, 97, 123, -82, -41, -6, -5, -68, -1, 91, -1, 119, -97, -1, -67, -65, -1, -17, -17, -21, -1, 63, -79, -1, -9, -17, -4, -5, -1, 51, -65, -53, -121, -1, -49, -9, -78, -73, -3, -49, -10, -33, -17, -1, 107, 94, -9, -5, -4, -9, -113, 127, -8, -1, 127, -81, -89, -37, -18, -9, -119, -34, -1, -35, -5, -73, -113, -1, -67, -97, -99, 78, -33, -66, -82, -9, -33, -7, -9, -29, -5, -1, -19, -10, -21, 127, -66, -13, -1, -1, -1, -41, -18, -78, -99, -7, -61, -65, -69, -1, 127, -17, -67, -91, -5, -4, -1, -1, -1, -121, -43, -34, 95, -75, -21, -17, -4, -6, 126, -10, -33, -2, -1, -1, -1, -29, -1, -11, -11, -65, -10, 111, 127, 127, 127, -66, -1, -1, -121, -3, 119, -33, -22, -69, -9, -3, -1, -20, -35, -41, -5, -1, -33, -10, -1, -97, -10, -65, -17, -1, -65, -10, -57, -2, -65, -1, -1, -3, 127, -23, -70, -5, -1, -105, 88, 14, -1, -5, -109, -65, -1, -7, -97, -37, -3, -9, -67, 127, -9, -97, -5, -3, -87, -3, -17, -41, -2, -19, -97, -19, -25, -29, -5, 85, -3, -9, -18, 127, -35, 55, 127, -3, -1, 111, 111, -37, -1, -8, 95, 127, 127, -1, -2, -1, -45, -6, -17, 127, -105, -2, 103, -33, 111, -2, -33, 123, -3, -3, -19, 127, -2, 119, 126, -107, -17, -17, -1, -4, -66, 126, -71, -33, -45, -86, -1, -73, -94, 59, -69, -1, -15, -1, -41, -2, -65, -105, -65, 111, -3, -77, -1, 95, -109, -2, -9, 63, -1, -48, 127, -1, -42, -33, 122, -1, -1, -1, -10, -11, 127, -3, -3, -2, 124, 111, -3, -65, -4, -1, -104, -13, 123, 95, -17, -9, -1, -39, -17, -65, -65, -1, -1, -35, 93, -67, -57, 102, 62, -18, -17, -69, -1, -25, -2, -1, -1, -3, -27, -3, -37, -35, -65, -72, -5, 127, 95, 31, 63, -33, -19, 62, -1, -2, -3, -2, -17, -36, 127, -65, -10, 127, -33, -65, -9, -4, 123, -5, -22, -74, -68, -1, 61, -2, 115, -18, 111, -9, -2, 127, -6, 127, -49, -19, -1, -2, -29, -1, -2, -1, 123, -1, -9, -25, -2, -10, -21, -47, -1, 123, -1, -1, -3, 95, 43, -37, -2, -41, 127, 109, -1, -9, 91, 107, 106, -1, -50, -4, -67, 126, -2, -1, -2, 122, -15, -3, -35, -31, -25, -45, -3, -5, -5, -6, -39, 95, -10, -3, -1, -33, -1, -33, -11, -5, -1, -17, -33, -9, -35, -38, -1, -33, -1, -17, -65, -1, 123, -3, -3, -37, -9, -1, -21, -29, 117, -73, -1, -5, -66, 120, -65, -7, -69, -1, -1, 127, -1, -4, -15, 119, -65, -43, -5, -76, 127, -3, -65, 127]
不对，又出现问题
暂停发现 没积压
snd_offset 是负数 -2143299692


不对。。。
scp1 snd_offset-2143294279
但是
scp2 snd_offset 2147478713
....
疑似是发生在溢出
而不是snd_offset负数的原因（无丢包下测试正常）
snd_buf 有数据。
snd_segments 空的
snd_dr 前面全是长度6的 sendCount0 rto0 说明没被取出来发送过
疑似takeSend 判断是否需要发送有问题

int bufLimit = _itimediff(rmt_rcv_offset + rcv_buf_size, snd_offset);
等于0！！！?

snd_offset -2143294279
rcv_buf_size 4194304
rmt_rcv_offset 2147478713

    static int _itimediff(long later, long earlier) {
        return ((int) (later - earlier));
    }
没想到一开始 复制过来的  这个方法以为是接近回绕。计算都使用的这个。
参数long类型没在意。以为需要long来计算。没注意

不对  原因不是这个，计算结果是正确的
计算能发送的数量为0
说明snd_segments应该有未被接受的数据  缓冲区大小4M的数据
但是 snd_segments 空的,这才是问题。
为什么被取出了？还是说压根没放进去？
为什么远程 rcv_real_offset 不等于scp1 snd_offset
 
scp2的 rcv_offset ==real_rcv_offset
说明scp2压根没收到 这个消失的4M


                    int offset = payload.offset - pre.offset - pre.length;
                    if (offset < 0) {//也许在缓冲区大的时候  前后跨度大超过32KB左右或64KB 就会错误 因为写出成Short 读取是读成无符号int 应该跨度达到64K就会出问题
                        System.out.println("定位2");
                    }
发现刷了 定位2 信息
在writeiToBuf方法

好难定位
已知条件是  发生回绕后  丢包情况下  ackmask增长后  接收方的rcv_dr 是空的，但是应该有内容 

修了一个小bug
丢包的时候  检查是否已接受的方法
rangeCheck 搜索range的时候 没找到下标就-1了  获取元素下标错误
发生异常可能导致后续不执行了。
不知道跟这个有没有关系

似乎好了,多跑一会多跑几次看看
可能是重传未接收部分时检查的，但是发生了异常导致后续没执行。

跑了很久停在了定位2
突然发现是保险起见写了排序最初。 对payload排序  seg序列化到buf时
根据比较大小进行的。

导致回绕的时候  负数其实应该在后 排序后 在前 导致错乱了。
计算的offset就错误的了（相较于前者的  偏移 2字节存储  负数的相对偏移存不了读出来就错误了）

目前对needOne 获取的时候ts是在调用之前 赋值的。而不是调用时赋值的。确保 一个takeSend里获取时 使用的是同一个ts
并且 加了缓存下标。ts相同时不重置。
ts相同  取出来的数据 必然是 从小往大 小下标往大下标取  数据范围必然是有序的。
所以不需要排序了。删了

挂一晚上明天看是否依旧在运行
完美
摆烂了。发出来看看有没有人需要

una跑了两天，还没回绕。之前测试过初始una是负数和即将负数的情况。没问题
应该没问题，唯一的问题只有  长时间的丢包 导致ackmask 无限增长无法携带完整。也没携带收到最大的sn的序号。导致超出ackmask长度的sn无法被反馈，前面的可能无法快速重传(重发的丢了，且sn在ackmask之外，不能被确认，只能等待超时)

una回绕没问题。

ackSndWithRmtRcvOffset的ackSn方法忘了换成ackSeg
换了之后性能上去了。100M 2.6秒

又把slideSn 和确认ackmask和跳过的计数
全部写到一个方法里了。减少了循环次数。
现在测试1000M在循环里测试  3秒3最快

在UDP测试100M 好像没什么提升。100M 还是2.6秒
不过已经提升很明显了。之前接近20M。现在接近40M。
相较于kcp-netty的本地测试 达到了三分之二性能。

处理snd_segments写到一个方法里一个循环里。持续测试莫名其妙有问题。
而且性能提升不大，改回之前的。

不对！性能实际差了一半。
对比kcp-netty项目
耗时 :1000 接收数据: 59.70318603515625MB 有效数据: 57.87890625 MB
57.87890625
Snmp{BytesSent=0, BytesReceived=60690432, MaxConn=0, ActiveOpens=0, PassiveOpens=0, CurrEstab=0, InErrs=0, InCsumErrors=0, KCPInErrors=0, 收到包=59736, 发送包=31, InSegs=59736, OutSegs=31, 收到字节=62603328, 发送字节=744, 总共重发数=0, 快速重发数=0, 空闲快速重发数=0, 超时重发数=0, 收到重复包数量=461, fec恢复数=0, fec恢复错误数=0, 收到fecData数=0, 收到fecParity数=0, fec缓存冗余淘汰data包数=0, fec收到重复的数据包=0}

6w包哪怕一个包只传1300也有七十多M。实际只有60。
考虑到KCP应该是存在单独的ack包。
而我的模拟一直传数据的场景，大概只有3w包一秒处理速度不积压的情况。
性能实际只有一半，如果看 数据包的数量处理能力。而不是三分之二。
大概接收能力3w极限了。也就38，39M 每秒左右的传输速度。


好像目前还没碰到瓶颈，加了一下测试的缓冲区到40M(之前4M)。居然每秒能传60M了。大概4.5w包每秒。
然后改成10M发现速度一样60M。估计是之前优化后缓冲区太小了所以没提升。但是设计上绝对有问题，就超时重传。
现在是改成最小1000毫秒了。避免测试的时候积压滞后导致能收到以为没收到，不规则的延迟波动？导致的rto计算错误？被迫重传？
rto好像有问题，所以测试的时候设置的较大，来避免其实能收到但是被迫重发了。
rto只是暂时复制的KCP的，感觉不适合。可能我封装的UDP收发有问题，使用队列的问题或者其他，的处理耗时影响了延迟计算？

发出去，需要的人自己改吧。应该没人需要T_T







数据结构

cmd 1B  标记有无ackmask 有无数据  ackmask是不是压缩的
sn 4B  发送方   包的sn
una 4B  接收方  作为ackmask的起始位置  和确认之前所有的sn
rcv_offset 4B  接收方  已经接收到的位置
updateUna 4B  发送方  更新接收方的 更新远程 rcv_next_sn  表示之前的都被确认接收了。
ackmaskLen 2B 需要时        接收方ackmask的长度
ackmask  需要时        接收方告知发送方  哪些包收到了，如果存在持续丢包，区间丢包 没被反馈到，只能等待超时重传
payloads  需要时    发送方 携带的数据段落 可以携带多个部分。

第一个payload  
基础offset4B len2B +数据    发送方 数据的开始位置和长度

其余的
相较于前一个末端位置 偏移量
offset2B len2b +数据





















































































































































































 





























































好比shit山开凿出来雕像
好比粪池3d打印浮现出来
历尽千辛万苦，绞尽脑汁
.......................终于！设计写出来了！........Shit C P。。。。
经过我的努力。。。屎山貌似无误的跑起来了
能用吧，应该。虽然不完美还有缺陷。