这个问题令我困惑已久,来自 tun/tap 网卡中读取的 tcpip psh 包(客户端主动发送的数据包)始终与“预期的客户端流水号”的值始终无法对上,促使收取的流“二进制”始终不对(缺一截),嘲讽的是“应用层”tcpip 发送频率变的很低以后就不会出现(调到 sent 一次 >= 50 ms 时)。
-------------------------------------------------------------
sseq:服务器的流水号(v-server)
push-cseq:客户端提供的流水号
expected-cseq:期望的流水号(绝对正确的流水号)
len:客户端 push-payload 的长度
---------------------------------------------------------------------------------------------------------------
real-ack_no:expected-cseq + len
我并未没有想明白,它错在什么地方,即使错也不应该刚刚 SYN + ACK 后,应用层与虚拟服务器建立连接后,应用层 PSH 第一帧的流水号就不对?
从收取的“应用层”提供的“ack、seq”的值中,获悉丢包,但大多数情况下提供的“第一帧”与“第二帧”会告知丢失了 1960 个字节,然而我根本就从未收到足够的分片,理论上我不进行 ACK 那么它需要重传丢失的片段上来,但它没有对这些丢失片段进行重传。
但虚拟服务器向“应用层”PSH、FIN、RST、SYN 是不存在问题的,它意味着“虚拟服务器”本身管理的“sseq、cseq”是不具备序列混乱的问题。
即便本机环境下存在丢包的问题,但这似乎不影响重传,但似乎它根本不按既定的预期进行重传。
-----------------------------
注:SYN 三次握手过程中,服务器只需要应答一次 SYN + ACK 即,应用层在收到 SYN + ACK 后,主动投递重新确认的 ACK,但对 TCP 连接建立而言,意义不大。
---------------------------------------------
本机环境下,个体认为并不需要利用“滑动窗口”控制“tcpip”的发包速度,所以采取了一个恒定的值,本机内存中内存的拷贝效率应该不会太低,远远高出通过物理网卡从(A to B)的数据吞吐量,几乎是可以肯定的。
