如何解析TCP包内压缩的html页面数据？

qw10371006

回复 8# Tinnal
是的，因为方法2的太容易出问题而且麻烦，所以我用版主大神的方法1，这样确实能够获取得未压缩的数据了。在修改完tcp数据后，除了包的长度和校验和需要修改以外，还有什么需要改的呢？？因为我发现改完的包接收端丢弃了，但是还能返回ack。而且这个ack还由于之前包长度发生变化导致序列号变了，web端好像就不认这个ack了，然后web端就重发这个包。。。。。。。。
   

qw10371006

回复 9# 瀚海书香
您说的代理模式是什么呢？

   

qw10371006

回复 11# qw10371006
wireshark提示new fragment overlaps old data  新老数据片段重叠  难道还是序列号的问题？？

   

Tinnal

回复 11# qw10371006

你从返回的ACK里看看，客户端的TCP有没有确认你追加的数据。下面我们假定确认了。

这要清楚，你改的是HTTP报文的一个分片，HTTP报文本身也有它的控制字段。因此，如果你只是改了局部的TCP报文。做为TCP层来说，你是对的，因此给你ACK，但作为HTTP来说，你的报文是错的。

因此，你考虑事情，要重HTTP整个包围角度出发呀。

多看看wireshark的分析，从HTTP角度再分析一下。


如果你改的内容对HTTP有影响，则要把HTTP的相关字段也同步修改。特别的，如果你当前改的内容影响到之前的已经发送的HTTP内容，那么你就必须在之前的内容转发前作为预判及预修改。


因此，如果没有其它什么好的方案，参照HTTP代码的方式，把重处HTTP都先收下来，再去处，然后再进行发送可能还更好，甚至可以把这事情通过合理的路由和NAT，直接放到用户态去做，那样就更加灵活了。



   

qw10371006

回复 14# Tinnal
我之前觉得改中间的包数据会更乱，所以我改的是最后传输的一个包，正好长度也不满可以在最后加上我所需要的东西，这样长度也就变了。今天通过试着不改变包的长度，用memset改变包内一些数据，这样的话可以成功传输一点问题都没有。也就证明了是由于长度变化。我想尝试着，将最后返回的ack的序列号强制改为长度不变之前与之对应的序列号，但是tcphdr里面序列号字段__be32 seq总是不会改，因为这个值不像一般的十六进制数据  我实在不会转为正常整数值。哎  新手刚接触，让您见笑了

qw10371006

回复 14# Tinnal
版主大神，方案1我已经能够成功完成了，但是果然如我之前所猜测的。这样降低效率的方法不被采纳，同时还提到了前面那位大神所说的代理模式，不知道这怎么弄的呢？？求指点

   

wait_rabbit

Tinnal 发表于 2015-01-19 20:32
方案1：HOOK客户端发起的HTTP请求，把request 中的Accept-Encoding: gzip, deflate参数去掉。让服务器别给你 ...

最近也在研究和http有关的协议栈方面的内容。发觉在传送一个超级大的html文件时，协议栈的数据很奇怪。趁机请教一下各位。

MTU: 1500，MSS : 1460.

server：nginx（已经禁止了 gzip ）；html文件大小：20M。

当 wget 该 html 时，理论上 ip 应该分片成十几个，但是抓包的结果很奇怪，具体如下：

1， 确实分片了。但是每个分片的标识（identification）不同，连续递增（理论上应该是相同的）。并且每个分片的 DF 置1，MF 为 0.
      
      这种情况下，client 要如何才能将各个分片重新组装起来？

2，根据 RFC 1122，如果 client 收到一连串具有最大长度的报文，那么必须每隔一个报文就要发送一个确认。但是实际上，我发觉接收方确认得挺随机的，经常接收到4、5个甚至10个最大长度报文才想起来确认一次。而 FreeBSD 就非常标准地每两个报文返回一个确认。

      不知道 linux 协议栈到底是怎么一个策略？

先行谢过。

qw10371006

回复 17# wait_rabbit
1.   你说的这个分片是在ip层，这个指的是这个单独的ip包，一般是don't fragment，而你所要问的当客户端发起html的get请求后，web端给客户端的http响应包分为多个tcp包传给你，这里你去看struct tcphdr这个结构体，注意下里面的seq和ack_seq，以及客户端在返回ack确认包的序号，看完你就知道是怎么把这些tcp包重组在一起的了。
2.   并不是收到每一个tcp数据包都会返回一个ack。

   

qw10371006

回复 9# 瀚海书香
代理模式已经搞定，特来感谢两位版主的帮忙，多谢！！！

   

qw10371006

回复 14# Tinnal

代理模式已经搞定，特来感谢两位版主的帮忙，多谢！！！