1、报文流
HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。可以把报文流比喻成水流，对于水来说是永远往低处流的，报文流也是如此。不论是从客户端流向服务器还是从服务器流向客户端，接收报文的那个端永远都是下游。
2、HTTP报文的组成成分。
包括起始行，首部和主体。起始行和首部是由行分割的ASCII文本。每行以一个由两个字符组成的行终止序列作为结束（CRLF）
2.1、起始行
对于请求行来说包含请求方法，请求URL以及HTTP的版本。对于响应行来说包含HTTP版本，数字状态码和原因短语。
2.1.1、方法
报纸服务器要做什么。常用的HTTP方法有7种：
GET：从服务器获取一份文档。
HEAD：只从服务器获取文档的首部。
POST：向服务器发送需要发处理的数据
PUT：将请求的主体部分存储在服务器上
TRACE：对可能经过代理服务器传送到服务器上去的报文进行追踪
OPTIONS：决定可以在服务器上执行哪些方法
DELETE：从服务器上删除一份文档。
注：除了POST和PUT包含主体外其余都不包含。而且并非所有的服务器都支持这7种方法。除了这些外，有些服务器可能还有一些自己的请求方法。
GET和HEAD方法被认为是安全方法，这意味着使用这两个方法的HTTP请求都不会产生什么动作。按照我的理解，这意思就是说服务器不会因为这两个方法而执行一个动作。例如用POST请求，服务器就会为用户执行一个动作，像登录的时候发送用户名和密码用的就是POST请求，这时服务器会在数据库中进行匹配，然后将结果返回给用户。
通常用POST来支持HTML表单。表单中填好的数据会被发送给服务器，然后由服务器将其发送到它要去的地方，比如发送到一个服务器网关程序中，然后由这个程序对其进行处理。
客户端发起一个请求时，这个请求可能会穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。这让我想起了我国伟大的防火墙——GFW。尤其是在访问国外网站时，报文在通过GFW时可能就被进行了修改，因此最终服务器返回一个404错误的响应报文。。。
DELETE方法做的事情是请服务器删除请求URL所指定的资源，但是客户端应用程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。
2.1.2、状态码
告诉客户端发生了什么。共分为5大类。
100～199——信息性状态码。它的目的是对这样的情况进行优化：HTTP客户端应用程序有一个实体的主体部分要发送给服务器，但希望在发送之前查看一下服务器是否会接收这个实体。
200～299——成功状态码
详细代码的含义请看P64
300～399——重定向状态码
返回一个可选的Location首部来告诉客户端资源被移走了，并提供一个地址。一般浏览器都在不打扰用户的前提下，直接转向那个地址。详细请看P65-67
400～499——客户端错误状态码
客户端如果发送一些服务器无法处理的东西，比如格式错误的请求报文，或是不存在的URL。这让我觉得我国的GFW是不是在请求报文传输的时候改动了URL，从而导致服务器端无法处理。
500～599——服务器错误状态码
详细看P69-70
2.2、首部
是一些名/值对列表。可以分为通用首部，请求首部，响应首部，实体首部，扩展首部。
各首部的详细信息可看书P71-76