3,881
社区成员
发帖
与我相关
我的任务
分享如何快速判定tcp包中包含http数据包
大家好，
我对tcp协议了解甚少，请问如何快速判定tcp包中是否包含http数据包（我现在使用的办法很蠢，只直接从tcp包中查询http相关的关键字符窜，例如host:, connection等等）？
多谢解答。
我对tcp协议了解甚少，请问如何快速判定tcp包中是否包含http数据包（我现在使用的办法很蠢，只直接从tcp包中查询http相关的关键字符窜，例如host:, connection等等）？
多谢解答。
...全文
请发表友善的回复…
发表回复
mLee79 2013-07-29
- 打赏
- 举报
就判断数据的第一行是不是满足HTTP请求的样子就差不多了, 写出正则表达式(随手写的像 (GET|POST|CONNECT)[[:blank:]]+[^[:space:]]+[[:blank]]+HTTP/1.[01](\r\n|\r|\n) ), 转DFA, 有时间复杂度 O(N) , 空间复杂度O(1)的判定方法...
max_min_ 2013-07-29
- 打赏
- 举报
解析数据，判断http协议特有的一些字符串！
gaorentaba 2013-07-29
- 打赏
- 举报
其实就是在一包数据中判断是否有http数据，其实你的办法就是好办法，无非就是这些，判断是否包含http的某些字段，最好先把数据按照"\r\n"分开成几行，然后判断必须的字段是否都在。。。后徐徐图之
赵4老师 2013-04-26
- 打赏
- 举报
包内容中很多'<'和'>' ？
donny945 2013-04-26
- 打赏
- 举报
一丝晨光 2012-02-14
- 打赏
- 举报
不过，tcp包可能会包含http数据包，tcp包头应该有相关类型信息吧，这个不是很确定
楼主看看
楼主看看
一丝晨光 2012-02-14
- 打赏
- 举报
参考地址：http://www.cnblogs.com/ziwuge/archive/2011/09/27/2193431.html
对于判断是否为HTTP报文，目前还没有快速有效的方法。传统的方法依据：
①传送HTTP报文前是否有TCP的三次握手；
②判断数据包中是否含有诸如“GET”、“HTTP/1.1”等关键字。
对于这两种方法，第①点需要一定的空间开销，要判断TCP承载的是否为HTTP报文，需要分配一定的空间存储前3个数据包的相关信息（实际并不需要存储3个数据包的全部内容，但是即便是若干比特的信息，也会增加NPF的负担），这给NPF（NetgroupPacketFilter）的运行速率和存储器带来挑战；
对于第②点，由于HTTP是面向文本的，因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。请求报文中除了“GET”方法外，还有7种常用的方法，如果要一一模式匹配来确定是否是HTTP报文，显然会造成很大的时间开销。此外，响应报文含“HTTP/1.1”（或HTTP/1.0）的版本号，这个字段在请求报文中也有，具体的版本是1.1还是1.0则是不确定的。
因此，综合考虑时间和空间的开销，本文采取模式匹配“HTTP”的方法来判断是否为HTTP报文。具体方法是：捕获到的数据包从TCP的尾部（HTTP的第一个字节）开始匹配“HTTP”，如果匹配成功，则认为是HTTP报文，否则就不是。这种方法存在的问题是：①如果TCP承载的是FTP或SMTP等其他应用层协议，恰好在某个部分也含有“HTTP”字样，则会误判为HTTP报文。但是由于基于HTTP协议的Web服务已经成为Internet的主流，非HTTP协议只占到小部分，因此误判的几率很小。系统测试期间，还未发现此类误判问题，用户界面显示的明文信息表明：确为HTTP协议的请求报文或响应报文。②该方法本身不存在“漏判”，因为所有的HTTP报文都含有“HTTP”字样，而抓到的数据包只要含有“HTTP”字样，就被过滤认为HTTP报文。但是，由于该方法需要一定的时间开销，可能来不及匹配后续的数据包而造成广义上的“漏判”。这个问题通过编写高效的模式匹配算法可以得到一定的改进，但是不能解决根本问题。根本问题在于匹配速度和内核的存储器容量的限制。
对于判断是否为HTTP报文，目前还没有快速有效的方法。传统的方法依据：
①传送HTTP报文前是否有TCP的三次握手；
②判断数据包中是否含有诸如“GET”、“HTTP/1.1”等关键字。
对于这两种方法，第①点需要一定的空间开销，要判断TCP承载的是否为HTTP报文，需要分配一定的空间存储前3个数据包的相关信息（实际并不需要存储3个数据包的全部内容，但是即便是若干比特的信息，也会增加NPF的负担），这给NPF（NetgroupPacketFilter）的运行速率和存储器带来挑战；
对于第②点，由于HTTP是面向文本的，因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。请求报文中除了“GET”方法外，还有7种常用的方法，如果要一一模式匹配来确定是否是HTTP报文，显然会造成很大的时间开销。此外，响应报文含“HTTP/1.1”（或HTTP/1.0）的版本号，这个字段在请求报文中也有，具体的版本是1.1还是1.0则是不确定的。
因此，综合考虑时间和空间的开销，本文采取模式匹配“HTTP”的方法来判断是否为HTTP报文。具体方法是：捕获到的数据包从TCP的尾部（HTTP的第一个字节）开始匹配“HTTP”，如果匹配成功，则认为是HTTP报文，否则就不是。这种方法存在的问题是：①如果TCP承载的是FTP或SMTP等其他应用层协议，恰好在某个部分也含有“HTTP”字样，则会误判为HTTP报文。但是由于基于HTTP协议的Web服务已经成为Internet的主流，非HTTP协议只占到小部分，因此误判的几率很小。系统测试期间，还未发现此类误判问题，用户界面显示的明文信息表明：确为HTTP协议的请求报文或响应报文。②该方法本身不存在“漏判”，因为所有的HTTP报文都含有“HTTP”字样，而抓到的数据包只要含有“HTTP”字样，就被过滤认为HTTP报文。但是，由于该方法需要一定的时间开销，可能来不及匹配后续的数据包而造成广义上的“漏判”。这个问题通过编写高效的模式匹配算法可以得到一定的改进，但是不能解决根本问题。根本问题在于匹配速度和内核的存储器容量的限制。
