HTTP协议抓包分析

        本次使用的测试的网站是：http://www.people.com.cn
        15 Agu 2019记下：最好是就使用http的网站来分析。因为现在很多网站都是支持的https协议。但是因为我现在也是一个小白，所以，具体他们之间的区别还不是特别清楚。所以，对于这一点以后再深究。

HTTP请求报文和响应报文的结构示意图

为了方便分析我先将HTTP的请求报文和响应报文格式贴出来：图片来源于网络

请求报文分析

        首先分析从我电脑上发出的一个请求，也就是这个请求：

我双击之后打开就是这样子：因为这里主要就是分析HTTP协议的东西，所以仅仅只截下了HTTP请求报文的内容。

       请求行分析：

• method:GET；
• URL：是一个相对的URL。是相对下面的Host来说的。两者组合就是一个完整的URL；这里联合http组合之后就是：http://www.people.com.cn/
• 版本：HTTP/1.1；
• CRLF:\r\n

       首部分析：在首部中，每一个字段名最后面都是会有一个cr和lf的。所以，我就在下面的内容中就不提及这个了。

• Host: www.people.com.cn
  也就是是你要访问的主机的名字；
• Connection：keep-alive
  值代表的意思是保持连接。这样子有利于在你访问的网页中有很多图片等其他资源的时候，可以使用同一个TCP连接接收，而不是针对每一个文件都建立一次TCP/IP的连接。这个也就是课本上面说的“持久连接”。
• Upgrade-Insecure-Request:1。
  这个具体的意思我也不太清楚，要详细了解还是得自己去查；在我后面的参考资料中有提到。
• User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36\r\n
  指明了发出请求的用户代理的浏览器的一些信息；
• Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3\r\n
  指明了浏览器接收对象的顺序，优先接收text/html文件，这个也是为什么每次服务器返回第一个文件是html了。
• Referer: http://www.people.com.cn/
  这个代表服务器该该请求时从这个链接进来的。
• Accept-Encoding: gzip, deflate
  说明该浏览器支持的编码格式，这里是压缩编码的方式。我猜想应该是服务器将浏览器请求的文件都是以压缩文件发送过来的。
• Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
  指明了该浏览器支持的语言类型，支持zh-CN,zh,en。然后优先发送zh-CN和zh的语言，因为他们的权重是0.9
• \r\n 代表下面的信息就是请求体的实体部分了。

       实体部分分析：下面是我的实体截图

按照理论上上来说，这里应该是一些实体的内容，但是我从抓包看到的数据却不是这个样子。可以看到箭头所指的方向，我个人感觉就是上面请求行和首部行的数据的总和而已.。在我百思不得其解的时候，在《计算机网络：自顶向下方法》中看到了这样的一句话：“使用GET方法是实体体为空，而是用post方式是才有该实体体。”所以我觉得应该是这里的是因为这里请求报文没有必要加上请求实体，所以就没有吧。但是后面响应报文的就是包含了响应实体的，通过抓包工具看到，转送过来的就是html代码。

响应报文分析

        接下来分析的就是这个响应请求了。

        具体的内容是这样的：

        响应行分析：HTTP/1.1 200 OK\r\n

• Response Version: HTTP/1.1
• Status Code: 200 （这个就是那个OK的的Description）
• Response Phrase: OK
• crlf

        首部行分析：

• Content-Type: text/html\r\n
  就是说服务器给客户端传回来的是html的文件格式。这个也验证了请求报文中的Accept字段的值。因为那个字段表示的是浏览器优先接收的对象。的确是text/html文件排在第一个。
• Connection: keep-alive\r\n
  同上
• X-Cache: HIT from PDcache-42 :www.people.com.cn\r\n
  一看到Cache就想到了计组中的高速缓存Cache,和Linux内核中的热冷页。我查了一下，这里和其它Cache是一样的，就是为了增加存取效率出现的。后面的HIT就是表示命中了。具体的话还是得自己查资料看啦。后面的参考文献中也有。
• Powered-By-ChinaCache: HIT from CHN-LN-u-3OZ\r\n
  这个暂时我还是一个刚刚学计网的孩子，我之后一定弄清楚，这里我就不深究了。不过查了一些文章，应该是想说这是一个CDN技术。
• ETag: W/“5d53bd8c-256d3”\r\n
  Etag中有种Weak Tag，值为 W/“xxxxx”。他声明Tag是弱匹配的，只能做模糊匹配，在差异达到一定阈值时才起作用。（来自百度百科）
• Content-Length: 36488\r\n
  这个是返回的实体在压缩之之后的长度为36488Byte,这个长度还是可以深究，看后面参考。
• X-Cache-Hits: 21\r\n
  略去
• Date: Wed, 14 Aug 2019 08:19:44 GMT\r\n
  这个就是你请求的东西被服务器创建的时间。时间格式是GMT，和北京时间有点误差。
• Expires: Wed, 14 Aug 2019 08:20:44 GMT\r\n
  这个就是如果你在这个时间之内去再次访问的话，得到就是缓存中的内容
• CACHE: TCP_HIT\r\n
  略去
• Content-Encoding: gzip\r\n
  压缩方式
• Last-Modified: Wed, 14 Aug 2019 07:51:40 GMT\r\n
  你所请求的东西上次修改的时间
• age: 53\r\n
  代表该响应在缓存代理中存放了53秒。
• Vary: Accept-Encoding\r\n
  我的理解就是：因为客户端和服务器之间可能有1个或者多个缓存服务器。那么，有时候会将缓存服务器的内容返回给客户端。现在有这样一个情景，A和B都请求的是文件C，文件C在缓存服务器中。但是两个用户使用的浏览器支持的编码不同，A仅仅支持gzip，而B仅仅支持的是compress，那么你把文件C使用gzip压缩的给B就是不对的，因为B无法解压得到一个正确的结果。所以Vary字段就是看看到底要不要把这个文件从缓存中拿出来给A和B。
• Server: nginx\r\n
  设置服务器名称
• Powered-By-ChinaCache: HIT from CMN-WH-3-D08\r\n
  略去
• CC_CACHE: TCP_HIT\r\n
  略去
• Accept-Ranges: bytes\r\n
  表示该服务器是否支持文件的范文请求。也就是说，我不想要一整个文件，而是32Byte~1024Btye之间的文件。
• \r\n

        实体体分析

按道理说应该只有箭头所指的地方才是实体体的内容，那么方框里面的内容是什么呢？目前我还是不知道。我还想要把这个实体信息复制下来看看是不是和书本上说到一样的，首先传输的是html页面，可能没有图片什么的。但是发现复制不了，所以这个还没有验证。

       这个是本人第一次实现抓包协议的分析，肯定有很多不足。之后如果有一些更新的话，再回来更新。

参考资料

HTTP协议常用头部实例详解（Request、Response）
https://blog.csdn.net/selinda001/article/details/79338766
Etag 和 If-None-Match
https://www.cnblogs.com/xuzhudong/p/8339853.html
【http】Keep-alive 知多少？作用？默认时长？
https://blog.csdn.net/qfzhangwei/article/details/90614253
从HTTP响应头看各家CDN缓存技术
https://segmentfault.com/a/1190000006673084
Http协议之Content-Length
https://blog.csdn.net/love_hot_girl/article/details/81163085
HTTP请求的响应头部Vary的理解
https://blog.csdn.net/qq_29405933/article/details/84315254
https://luchuan.iteye.com/blog/1058563