这个问题令我困惑已久，来自 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）的数据吞吐量，几乎是可以肯定的。