http报文
懂得http报文，对http学习有很大的帮助
1：报文的组成
所有的报文都有两部分组成：请求报文与响应报文
请求报文的格式：
<method> <request-URL> <version>
<headers>
<entity-body>
响应报文格式：
<version> <status> <reason-phrase>
<headers>
<entity-body>
方法（method）:客户端希望服务器对资源执行的动作。（如get,head,post等）。
请求地址（request-URL）:服务器或服务器资源地址（URL）。
版本（version）:报文所使用的HTTP版本。
状态码（status-code）:描述了请求过程中所发生的情况（三位数字，如 200）。
原因语句（reason-phrase）:如OK。
首部（header）:名字 冒号（：） 空格 值 最后回车或换行（CRLF）。
实体部分（entity-body）：任意数据组成的数据块，可为空。
一组http首部总是应该已一个（CRLF）结束。
2：起始行
http版本比较：HTTP/1.11 要比 HTTP/1.2 版本高。（因为11比2大）
3：首部
http规范定义了几种首部字段。应用程序也可以随意发布自己所用的首部。
通用首部：既可以出现在请求报文中，也可以出现在响应报文中。
请求首部：提供更多有关请求的信息。
响应手部：提供更多有关响应的信息。
实体首部：描述主体的长度和内容，或者资源本身。
拓展首部：规范中没有定义的新首部。
常见的首部：
Data:Tue 30ct 2019 09：00：00 GMT 服务器产生响应的时间
Content-length:20000 实体的主体部分包含了20000字节的数据
content-type:image/gif 实体的主体部分是一个GIF图片
Accept:image/gif,image/png 客户端可以接收gif图片和png图片
首部延续：
Content-length:20000
content-type:image/gif
Server:Test Server
version 1.0
Server部分包括（Test Server version 1.0）
4：实体
实体的主体就是HTTP要传输的内容（可选）。包括图片，视频，音乐等。
4：方法
4.1：安全方法
安全方法：使用get或head方法的HTTP请求不会产生什么动作，也就不会再服务器上产生什么结果。
4.2：GET方法
get方法：最常用的方法，通常用于请求服务器发送某个资源。
4.3：HEAD方法
HEAD与GET方法的区别：
1：GET：服务器在响应过程中可以返回首部与实体的主体部分。
2：HEAD：服务器在响应过程中只返回首部，并不返回实体的主体部分。
HEAD：
1：在不获取资源的情况下了解资源的情况（如，判断其类型）；
2：通过查看响应中的状态码，查看某个对象是否存在；
3：通过查看首部，判断资源是否被修改了；
4.4：PUT方法
put方法可以向服务器写入文档，创建的web页面，使用put方法将其直接安装到web服务器上去。
语义：让服务器用请求的主体部分来创建一个由所请求的url部分命名的新文档。如果那个url已存在，就用这个主体来替代它。
4.5：POST方法
post方法：通常用于将表单中填好的数据发送给服务器，然后由服务器将其发送能到它要去的地方。
post和put方法的区别：post用于向服务器发送数据。put用于向服务器上的资源中（如：文件）存储数据。
4.6：TRACE方法
trace方法：trace方法主要用于诊断。用于验证请求是否穿过了请求/响应链。可以用来查看代理和其他应用程序对用户请求所产生的效果。
缺点：代理可能会将post请求直接发送给服务器，而将get请求发送给另一个HTTP应用程序（比如web缓存），trace并不提供区分这些方法的机制。
效果：trace请求中并不能带有实体的主体部分，trace响应的主体实体部分包含了响应服务器收到的请求的精确副本。
4.7：OPTIONS方法
options方法：options方法请求web服务器告知其支持的各种功能。（如get,post,put等）
4.8：DELETE方法
delete方法：请服务器删除请求url所指定的资源。
缺点：无法保证删除操作一定会执行。
原因：HTTP规范允许服务器在不通知客户端的情况下撤销请求。
4.9：拓展方法
拓展方法：自定义方法。
缺点：自定义的拓展方法，很可能大部分HTTP应用程序都无法理解。
5：状态码
5.1：100~199 信息性状态码
5.2：200~299 成功状态码
5.3：300~399 重定向状态码
如果资源已被移走，可发送一个重定向状态码和一个可选的Location首部来告知客户端资源已被移走，以及现在在哪里可以找到它。这样，浏览器就可以在不打扰使用者的情况下，透明地转入新的位置了。
5.4：400~499 客户端错误状态码
5.4：500~599 服务器错误状态码
有时候客户端发送了一条有效请求，服务器自身却出错了。（比如网关资源）
6：首部
6.1：通用首部
通用首部：客户端和服务器都可以使用的首部。（如data）
它就像一个事佬。无论报文是什么类型，都为其提供一些有用的信息。
还有一个通用缓存首部，最早在HTTP/1.0引入（后续有更详细的介绍）
6.2：请求首部
请求首部：在请求报文中有意义的首部。
作用：用于说明谁或者什么在发送请求，请求源自何处，或者客户端的喜好及能力。服务器可以根据请求首部中给出的客户端信息，试着为客户端提供更好的响应。
6.2.1：请求的信息性首部
6.2.2：Accept首部
Accept首部：Accept首部为客户端提供了一种将喜好和能力告知服务器的方式（包括，想要什么，可以使用什么，不想使用什么等），服务器根据这些额外信息，对要发送的内容作出更明智的决定。
优点：客户端可以得到想要的内容。服务器不会浪费时间和宽带来发送客户端无法使用的东西。
6.2.3：条件请求首部
条件请求首部：为请求加上某些限制。（如：在客户端已经有了一份文档副本，希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。）
6.2.4：安全请求首部
安全请求首部：客户端在获取特定的资源之前，先对自身进行认证，已使事务稍微安全一些。（后续将详细介绍）
6.2.4：代理请求首部
用于协助人们更好的工作。
6.3：响应首部
响应首部：为客户端提供一些额外信息。（如：谁在发送响应，响应者的功能，与响应相关的一些特殊指令等。）
6.3.1：响应的信息性首部
6.3.2：协商首部
协商首部：如果资源有多种表示方法，HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。
6.3.3：安全响应首部
6.4：实体首部
实体首部：提供了有关实体及其内容的大量信息。
6.4.1：实体的信息性首部
6.4.2：内容首部
内容首部：提供了与实体有关的特定信息，说明了其类型，尺寸以及处理它所需的其他有用信息。（如：web浏览器可以通过查看返回的内容类型，得知如何显示对象。）
6.4.3：实体缓存首部
实体缓存首部：提供了与被缓存实体的有关信息。（如：验证已缓存的资源副本是否仍然有效所需的信息）
