HTTP 报文总结、外送两本电子书
写在前面的话：喜欢这个比喻：如果说HTTP是因特网的信使，那么HTTP报文就是它用来搬东西的包裹。
HTTP是一个应用层协议，研究它的内容的确很枯燥，没啥意思，都是规定好的，我们只需要知道是什么就好了，在此基础上如果能从协议的设计中得到一些实际开发中的启发，那就更好了。
这篇算是我的读书笔记吧，看过权威指南的同学都知道，基本上是照抄过来的（不过绝对没有 ctrl-c 哦），
这里顺带捎带一句，读书笔记只是一个引子，详细内容还得从书中找，或者通过引子能回忆起详细内容，我这种读书笔记就有点粗放型了，谁让咱智商捉急呢。
我建议读书笔记使用某种思维导图工具比较好，逻辑性也清晰。
带着问题在书中找答案：
没有目录的博文（读书笔记）都是耍流氓：
报文是如何流动的？
HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以文本形式的元信息开头，描述了报文的内容和含义，后面跟着的是可选的数据部分。报文在客户端、服务器和代理之间流动。术语“流入”、“流出”、“上游”和“下游”都是用来描述报文方向的。
流入和流出描述事务处理的方向，报文流入服务器，处理完成之后，会流出服务器，流入客户端。
上游和下游，所有报文的发送者都在接收者的上游(upstream)。不管发送者和接收者是服务器还是客户端或者是代理。
报文的组成部分？
HTTP报文是简单的格式化数据块。每条报文都包含来自客户端的请求，或者一条来自服务器的响应。
它们由三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部块（header）以及可选的、包含数据的主体（body）部分。
起始行和首部是由行分隔的ASCII文本。每行都以一个由两个字符组成的行终止序列作为结束，其中包括一个回车符（ASCII码13）和一个换行符（ASCII码10）。这个终止序列可以写做CRLF。
报文的主体是一个可选的数据块。与起始行和首部不同的是，主体可以包含文本或二进制数据，也可以为空。
报文的语法
所有的HTTP报文都可以分为两类：请求报文和响应报文。
请求报文会向Web服务器请求一个动作，响应报文会将请求的结果返回给客户端。两种报文的结构相同。
请求报文的格式
<method> <request-url> <version>
<headers>
<entity-body>
响应报文的格式
<version> <status> <reason-phrase>
<headers>
<entity-body>
对各个部分的简要描述
方法(method)
客户端希望服务器对资源执行的动作。比如GET、HEAD或POST等
请求URL(request-url)
命名了所请求的资源，或者URL路径组件的完整URL。如果直接与服务器进行对话，只要URL的路径组件是资源的绝对路径，通常就不会有什么问题。
版本(version)
报文所使用的HTTP版本，其格式看起来是这样：HTTP/<major>.<minor>主次版本号都要是整数。
状态码(status-code)
这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字用来描述状态的一般类别（成功、出错）。
原因短语(reason-phrase)
数字状态码的可读版本，包含行终止序列之前的所有文本。
首部(header)
可以有零个或者多个首部，每个首部都包含一个名字，后面跟着一个冒号，然后是一个可选空格，接着是一个值，最后是一个CRLF（行终止序列）。
首部是由一个空行(CRLF)结束的，表示了首部列表的结束和实体主体部分的开始。
主体部分(entity-body)
实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分。
请求报文支持的各种方法
请求报文支持的方法有很多，但并不是每台服务器都实现了所有的方法，下面介绍一些常用的方法。
GET ，通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。
HEAD，该方法和GET方法的行为类似，但服务器在响应中只返回首部。不会返回实体的主体部分。那么问题来了，没有主体部分的响应报文我们有什么用呢？
- 在不获取资源的情况下了解资源的情况（判断资源类型）
- 通过查看响应中的状态码，看看某个对象是否存在
- 通过查看首部，测试资源是否被修改了。
服务器开发者必须确保返回的首部和GET请求返回报文的首部完全相同。HTTP/1.1要求服务器必须实现此方法。
PUT，与GET从服务器读取文档相反，PUT方法会向服务器写入文档。PUT方法的语义是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用这个主体来替代它。
POST，此方法起初是用来向服务器输入数据的。实际上，通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方
TRACE，客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或者其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE方法允许客户端在最终将请求发送给服务器时，看看请求变成了什么样子。
TRACE请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端可以查看在所有中间HTTP应用程序组成的请求/响应链上，原始报文如何被修改过或者毁坏过。
该方法主要用于验证请求是否如愿的穿过了请求/响应链。它假定中间应用程序对不同类型的请求的处理是相同的，TRACE方法并不提供区别这些方法的机制，通常，中间应用程序会自行决定对TRACE请求的处理方式。
TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。
DELETE方法，请服务器删除URL指定的资源。但是，客户端应用无法保证删除操作一定会执行。HTTP规范允许服务器在不通知客户端的情况下撤销请求。
和响应报文一起返回的各种状态码都什么意思？
HTTP状态码被分为5大类，其中100~199是信息性状态码，200~299是成功状态码，300~399是重定向状态码，400~499是客户端错误状态码，500~599是服务器错误状态码。
每个状态码的意思我觉得没有必要一一列举出来，也没必要全记住，记住几个常见的就好了，其他的用的时候再查。书就是用来查的么 : )
各种各样的HTTP首部都是用来做什么的？
首部和方法配合工作，共同决定了客户端和服务器能做什么事情。
在请求和响应报文中都可以用首部来提供信息，有些首部是某种报文专用的，有些是通用的。首部可以分为五个主要类型。
通用首部：客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。比如：Date 首部，说明构建报文的时间和日期。
请求首部：请求报文特有的，它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据。
响应首部：响应报文特有的，为客户端提供信息，比如客户端在与哪种类型的服务器进行交互。
实体首部：用于应对主体部分的首部。比如，用实体首部来说明主体部分的数据类型。Content-type
扩展首部：非标准的首部，有应用程序开发者创建。
写在后面的话，协议是枯燥的，只是一种规定，我分享这篇博文主要是我的读书笔记，当然可能作为笔记内容多了点，其实书中说的已经很言简意赅了，有兴趣的同学可以针对章节选择性的阅读。
HTTP权威指南中英文版下载链接：HTTP权威指南中英文版
