通过之前的抓包WireShark抓包报文结构分析，我们大概可以看出，WireShark的报文结构类似于TCP/IP四层模型。报文封装的最内层为封装的业务数据，最外层对应报文转发所需参数。
实际对应起来就是报文最外层的Ethernet II封装对应数据链路层，为TCP/IP四层模型的最底层，主要是以ARP和RARP协议为基础，实现报文数据在物理媒介上的传输；
报文第二层的Internet Protocol封装对应网络层，为TCP/IP四层模型的第二层，主要依靠IP协议（最明显的特点就是IP地址）来完成报文的网络到网络转发；
报文第三层的Transmission Control Protocol对应传输层，为TCP/IP四层模型的第三层，主要依靠TCP协议或UDP协议完成报文的端到端传输。可能有同学觉得IP到IP不就是端到端的转发了吗？其实不全是，以之前的抓包数据为例，报文是封装有源目端口号的；在实际网络中，大量使用了NAT地址转换，只将一些关键服务器的端口映射到了公网上，必须经过地址转换才能到达实际的服务器，所以一般只有通过指定的IP+端口号才能确定到指定主机（负载均衡等场景除外），所以说是IP+端口号的TCP或者UDP协议完成了报文的端到端转发；
报文第四层，一般也是最内层的Data或者其他知名协议（如HTTP、DNS、Telnet等）对应应用层，为TCP/IP四层模型的第四层，也是最上层，主要负责封装或者传递业务数据。应用层协议复杂多样，通过抓包也能看到大量的不同协议报文，如HTTP、NBNS、DHCP、DNS等等。
其实这个封装和转发过程和邮寄快递也有相似之处，比如北京A公司的AA寄一份合同给杭州B公司的BB，合同装进文件袋就是打了一层封装，AA和BB即对应TCP协议的端口号，A和B公司及对应网络层的IP地址，快递公司的转发即是数据链路层的转发。文件到达B公司并不算是完成端到端的转发，必须指定BB来收件，才算是完成了端到端的转发；而当BB签收文件袋的时刻，才完成了这一次可靠的邮件寄送；放到网络中，就是一次报文转发。而当寄送的文件过多时，就会被打包成多个包裹，在网络传输中，就是报文的分片。
之前也提过，Telnet报文交互时，数据是明文交互的，就好比AA和BB交互的合同信息被放在了一个透明的文件袋里，传输过程中的任何一个人，只要想看，就能看到报文内容；而使用SSH交互时，叫好像双方都有一对钥匙，配合使用才能打开文件袋，传输过程中报文可能被截获，但是很难被破解。
本次我就做个测试，抛开传输层以下交互，看看HTTP协议下，AA和BB交流了哪些信息，以及是怎么交互的。
HTTP报文交互一般产生在浏览器浏览网页时，常用的查看工具有HttpWatch和F12（开发人员工具）。从电脑上访问一个WEB页面（一台设备的管理页面），同时开启HttpWatch和WireShark记录，获取结果如下：
WireShark：
HttpWatch：
简单来看，可以看出报文交互过程是一致的，HttpWatch中的1个POST和9个GET动作在Wireshark中均有体现，不过顺序有细微差异。
因为使用的是基本版的HttpWatch，能看的信息很少，除了上图中的摘要信息，查看其他所有详细内容都要专业版的授权。（所以HttpWatch算是测试途中被放弃了，有人有专业版的授权或者破解版本可以共享我一下的吗？）
然后我就试了一下IE浏览器的F12（开发人员工具），能得到的内容竟然比HttpWatch基本版要详细。
然后看一下交互报文的详细信息。
网络层的封装中，可以看到请求源地址和目的地址。
传输层的TCP封装中，可以看到目的端口为80端口，为标准的HTTP协议端口。
在第一个POST报文中，可以看到客户端是在请求设备的login页面，URI为http://172.2.215.175/web/device/login?lang=1。
拆分开看，请求方式为POST，主要是用于向指定的资源提交要被处理的数据；另一种请求方式为GET，用于从指定的资源请求数据。在请求的同时，客户端还发送了自身的相关参数，如要求使用语言为中文，客户端的操作系统为Windows NT 6.1（Windows 7），64位版本,；浏览器内核为Trident/7.0，版本为11.0，也就是IE 11。至于显示的User-agent为什么是Mozilla，建议大家百度一下，有一个小故事。
https://zhidao.baidu.com/question/1767408752449075980.html
通过客户端发送自身的信息，服务侧就知道响应何种报文了。这种做法现在很有用并且也很常用，因为目前终端类型特别多，如果服务商只提供一种类型的页面很难保证都适用；所以服务商针对主流厂商和操作系统做了定制，而只需要识别到终端类型即可返回对应类型的交互页面了。（PS.现在很多浏览器也支持修改浏览器标识，比如电脑端修改为手机端，手机端修改为电脑端，安卓也可以使用Safari标识等）
报文最后还有一段上传的uid（用户ID）值，同时说明了HTML表格编码格式，此处所用的application/x-www-form-urlencoded格式为浏览器默认的编码格式。
同时对于封装的二进制报文，可以发现右侧能直接翻译出报文内容，采用的是ASCII ((American Standard Code for Information Interchange): 美国信息交换标准代码）编码格式。网上有标准的字典，同时一些工具，如EditPlus左侧现有对应的字典显示。
而在F12工具中，虽然看不到报文的封装，但是HTTP协议封装的内容看起来更加简洁明了。
在WireShark中，每个报文都是分开展示的。
而在F12工具中，则会将一组请求报文和响应报文组合在一起，按照请求标头、请求正文、响应标头、响应正文的顺序进行显示。如上图所示，可以看到正文中是一个HTML页面的代码，对于熟悉HTML编程的人员来讲，可以很清晰的了解页面格式和内容；如果有攻击行为，则可以截取报文，修改报文以达到篡改页面、欺骗最终用户的目的。
前面提到HTML页面报文，中间有部分嵌套的CSS格式、javascript、图片等资源，客户端在收到响应之后继续请求这些资源。
可以看到，客户端后续共请求了8个资源，也是路径+文件的形式进行请求的。通过这些，我们也可以探测服务侧的存储路径，如果权限或者方法合适，我们甚至可以将整个路径获取下来，或者拿到自己想要的文件信息。
而对于登录页面的验证码信息，通过多次尝试发现，每个验证码都有一个数值与之对应，我在猜测，如果找到对应的算法，是不是能破解出图片的字符。我想网上一些代理登录工具，能跳过验证码验证的就是这么做的，所以现在出了更高级的点击图片、拖动图片等高级验证码。
当然，操作有限，HTTP中的标准动作除了POST、GET之外，还有HEAD、PUT、DELETE、TRACE、CONNECT等等。如果后面会用到的话，再具体问题具体分析吧。
