TCP协议(确认帧)问题，高手救命。

Question

图片1 :上图（图片1）中是普通vpn连上后，4个ping包的抓包情况。接下来：
我把发出去的GRE包全部截获下来：192.168.3.33（设为A机）发往92.48.96.28（设为B机）的GRE截获下来，通过TCP来传到B机，B机再取出GRE包发给自己；B机发给A机的GRE包也做相同操作。上面只是说一下我的软件思路。问题在下面一张图：
图片2 :
http://p.blog.csdn.net/images/p_blog_csdn_net/okmnji79513/EntryImages/20090713/2.JPG
上图（图片2）中是我实现了我的思路，但是速度上有点问题。
从抓到的第1条数据开始是ping开始，
1-->2（这里的1、2指的是图中No那一列的序号）可以看出，从 截获到GRE数据包 到 被打包进TCP几乎没用时间。
3 是 B机返回的包含GRE数据包的TCP包。
4 是3中GRE包发向网关。
5 是 GRE包由网管发向A机。（此时 cmd中第一个ping的时间出来了）  
6 参考 图1中的 3、6、9、12 。   
7 是将6打包。
这时，关键的部分来了，8 出现（即第2个ping包发出）照理来讲，应该是8立即被打包并发送出去（即10，此过程类似1-->2），但是10并没有立即被发送出去， 而是TCP程序在等待9的到来（即7的确认帧），9到来后，10才被发出去，这样就导致了第二个ping的时间多了8、9之间的156ms。
第三个、第四个ping包有相同情况（即为等待9、17、...的到来多了时间）。请问该问题有无解决方案?(即图2中8之后一定要等9的到来才能发10吗？  7能不能和10 用同一个确认帧？)
我用A机向B机发一个文件（发文件 是A机向B机 单向发，照理应该是每个发向B机的包，都应该得到一个确认帧），但是，抓包时看到好像TCP并不是每一个包都有确认帧的，由此想到  7能不能和10 用同一个确认帧？ps: 图1、2中都是 192.168.3.33 ping向 92.48.96.28 ；A、B机都是win2003虚拟机 网卡桥接模式。

Answer 1

在tcp的协议里，不是每个包都需要回应包的，按照滑动模型的要求，一个回应包可以理解为在之前的所有包已确认到达。

Answer 2

是 滑动窗口 不？刚开始看 TCP-IP详解 有点晕。

Answer 3

看你的意思，你是不是要从TCP这一层对2个连接进行中间控制？你想让A以为你是B，让B以为你是A？

Answer 4

不是啊，我只是把 GRE 拦下来 不让它在网域网传，A运到B后（用TCP运），再将GRE发给B；B运到A后，同样再将GRE发给A。

Answer 5

昨天没空来，呵呵，今天还看见这帖子，我再进一步说说我的看法吧。首先，楼主要把重点放到你图中后面的SEQ 和ACK项。我们都知道TCP的SEQ和ACK是一一响应的，WINDOWS实现的时候，并不是把这2者分开的。ACK包往往就是直接跟在SEQ包里，标志了我的序列号，同时制定了对方下次发送的序列号。在你的图中，按照你的设定，A机发送的包选择的起始序号以288开头，B机选择的起始序号是以166开头，10一定是在9之后才发送的，因为9的ACK数值就对应10的SEQ数值。你说来不及劫持，我觉得不是。是不是你根本就没劫持到。劫持不是复制，这个有区别。从接受缓冲区里拷贝数据是个拷贝操作，你是拷贝到了，但是原软件是不是也拷贝到了。是不是你的劫持不是真正的劫持呢？

Answer 6

我之所以这么判断就是因为，这里不存在速度的问题。因为B在没有确切获取A的数据包前，是不会做出任何反应的。超时设置也绝对比156MS要长很多很多倍。

Answer 7

to   boygo1982 帅哥图2 中 2是对1的截获并用TCP发送，可看出我的 截获 规则，是正确的，并且从 截获 到 TCP发送 用时很少。但是从 8到10 看到，他中间多了 等待9 的156ms，导致在CMD中看到的第2个ping包 去和回来 用时比实际情况多了156ms，我的问题就是 怎么把这156ms弄掉？PS：我用UDP来运GRE包，这时ping所用时间 和 不用TCP或UDP运直接VPN里ping所用时间 相差无几（多20ms左右吧，不会像TCP那样：第一个ping包正常，第二个多一百多，第二个多二百多...）。但是UDP容易丢包，有兴趣回答下我这个帖子吧，UDP丢包的：http://topic.csdn.net/u/20090705/10/770049ab-4f66-457a-8772-4159efef97fe.html