http权威指南读书笔记（三）——http报文

                                                                http报文

    书已经读了差不多一半了，给我的感觉这本书的前几章主要是介绍http的规则，随着介绍的不断深入，对原理与结构方面的问题也介绍的越来越多，而且也十分深刻，通过对于这本书的学习，不光光能学习到http的知识，而且更能通过对http的了解，对整个网络是如何运行，数据是如何传输有个深刻的印象，解决了很多以前似懂非懂的问题，确实是一本好书。

   报文流

    http报文是在http应用程序之间发送的数据块，以文本形式的元信息开头，描述了报文的内容和含义，后面跟着可选的数据部分。报文在服务器和代理之间流动。

      报文流入源服务器

      http使用流入流出来描述事务处理方向，报文流入源服务器，工作完成后流回用户的Agent代理中。

      所有报文都会向下游流动，所有报文的发送者都在接受者的上游 ，例如代理1将报文发送向代理2，那么代理1就是代理2的上游，可以把报文想象成河水，上下游的关系就很容易明白了。

      报文的组成

       报文是简单的格式化数据块。它由三部分组成：对报文进行描述的起始行，包含属性的首部，以及可选的，包含数据的主体。

       起始行和首部是由行分隔的ASCII文本，每行都由一个或两个字符组成的行终止符作为结束，其中包括一个回车符和一个换行符，这个行终止符可以写作CRLF，虽然标准里是这么说，但是要有些客户端没有遵循标准，只是用了回车或者换行。主体是一个可选的数据块，可以包含二进制或文本，或者为空。

       报文的语法

    报文可以分为两类：请求报文和响应报文。请求报文是客户端向服务器发送的一个请求，响应报文将请求得到的结果返回给客户端。

       请求报文的格式：                                                                                     

          <method><request-url><version>                             

          <header>                                                                    

          <entity-body>                                                              

         响应报文的格式：

          <version><status><reason-phrase>

          <header>

          <entity-body>

       方法：客户端希望对资源执行的动作。如POST GET。          

       首部：可以有0个或者多个首部，每个首部都是name:value的形式，然后以CRLF结束。

       请求URL：提供了所请求资源的完整URL。                        

       状态码：这三位数字描述了请求中发生的情况。

       版本：HTTP协议版本号。                                                 

       原因短语：状态码的可读版本简单说明了发生的情况。

       实体的主体部分：包含任意数据组成的数据块。

       注意一组HTTP首部总是应该以一个空行（仅有CRLF）结束，甚至即使没有首部和实体的主体部分也应该如此，但是由于有些服务器并不严谨，会错误的省略最后的CRLF，需要注意。

       起始行：

       所有的HTTP报文都以一个起始行作为开始，请求起始行说明要做什么，响应起始行说明发生了什么。

       请求行：请求报文的起始行被称为请求行，包含了一个方法和一个请求URL，方法描述了服务器应该执行的操作，URL告诉服务器应该对哪个资源操作，版本告知服务器正在使用的HTTP版本信息，所有这些字段都是由空格分隔开的，例如：GET /index.html HTTP/1.1

      响应行：响应报文的起始行被称为响应行，包含http版本，数字状态码，和原因短语。

       版本号：版本号以HTTP/X,Y的形式出现，版本号说明了应用程序支持的最高HTTP版本，版本号不会被当做小数来处理，版本中每个数字都会被当做一个单独的数字处理，例如HTTP/2.22就比HTTP/2.3版本高，因为22比3大。

      首部：

       跟在起始行后面的就是零个或者多个首部字段，首部字段向请求和响应报文中添加了一些附加信息，本质上来说就是key:value列表，例如：

content-length:19 就是一个表示报文长度的首部字段。

     首部延续行：将长的首部行分为多行提高可读性，多出来的行每行前面最好有一个空格或者制表符，例如：

     Server:Test

       Version:1.0

     首部分为几个类别：

• 通用首部

    这个是客户端和服务器都可以使用的首部，提供了报文相关的最基本信息。不管是响应报文和还是请求报文。例如

1. connection   允许客户端和服务器指定与请求/响应连接有关的选项
2. Date           提供日期和事件标识，说明报文创建时间 

• 请求首部

    请求报文特有的首部。

1. Host            给出了接收请求的服务器的主机名和端口
2. Referer        提供包含当前请求URI的文档的URL
3. User-Agent   将发起请求的应用程序名告诉服务器。

     Accept首部：将客户端提供了一种将其喜好和能力告知服务器的方式，包括他们想要什么，可以使用什么，他们不想要什么。

1. Accept                告诉服务器能发送哪些媒体类型。
2. Accept-Charset    告诉服务器能发送哪些字符集。
3. Accept-Encoding  告诉服务器能够发送哪些编码。

     条件请求首部：在客户端需要为请求加上限制时使用，具有分支判断功能

1. Expect                允许客户端列出某请求所学要的服务器行为。
2. If-Match              如果实体标记与文档当前的实体标记相匹配，就获取这个文档（缓存相关）
3. If-Modified-Since  如果资源在指定日期之后修改过，那么就获取这个文档。（缓存相关）

     安全请求首部：简单的安全机制，要求客户端在获取特定的资源之前，先对自身进行验证。

1. Authorization        包含了客户端提供给服务器，以便对其自身进行认证的数据。
2. Cookie                  客户端用它向服务器传送了一个令牌——他并不是真正的安全首部，但确实包含了安全功能

     代理请求首部：关于代理控制的首部。

1. Max—Forward       在通往源服务器的路径上，将请求转发给其他代理或者网关的最大次数，与TRACE方法一起使用。

• 响应首部

     同上，响应报文特有的首部。

1. Age           从最初创建开始响应持续时间。
2. Public        服务器为其资源支持的请求方法列表
3. Server        服务器应用程序软件的名称和版本。

     协商首部：如果资源有多重表示方法，如某文档有中文和英文两个版本，就可以通过这些首部与服务器进行协商。

1. Accept-Ranges   对此资源来说，服务器可接受的范围类型。

     安全响应首部：与安全响应首部相关，实现安全功能。

• 实体首部

    用来描述HTTP报文的负荷，请求响应报文都可能出现。

1. Allow                列出了可以对此实体执行的请求方法
2. Location            告知客户端实体处于何处;用于将接收端定向到资源的（可能是新的）位置（URL）上去。

     内容首部：提供了与实体内容有关的特定信息，说明了其类型尺寸以及处理它所需的有用信息。

1. content-Base       解析主体中的相对URL时使用的基础URL。
2. content-Encoding  对主体执行的任意编码方式
3. content-Language 理解主体时最合适的自然语言。
4. content-Length     主体的长度或尺寸
5. content-Type        这个主体的对象类型

     实体缓存首部：说明何时如何进行缓存。

1. ETag                    与此实体相关的实体标记
2. Expires                 实体不再有效，要从原始的源再次获取此实体的日期和事件
3. Last-Modified         这个实体最后一次被修改的日期和时间。

• 扩展首部：用户自定义的首部。

   （以上的首部都是比较常用的首部，并不是全部的首部，如果需要查询其他首部的相信信息，可以去维基百科）

    方法：

   方法也就是method，并不是每个服务器都实现了所有方法。HTTP定义了一组被称为安全方法的方法，GET方法和HEAD方法都被认为是安全的，原则上来说不会对服务器产生不好的影响，例如GET正常的来说只是获取服务器的资源。

•  GET

     最常见的方法，通常用于获取服务器的某个资源，HTTP/1.1要求服务器实现该方法。

     

•  HEAD

     与GET方法类似，但服务器响应中只返回首部，不会返回实体的部分，这允许客户端在未获取实际资源的情况下，对资源首部进行检查，HEAD可以：

1. 在不获取资源的情况下了解资源情况，如类型。
2. 通过查看响应中的状态码，判断资源是否存在。
3. 通过查看首部，测试资源是否被修改了。

•  PUT

     PUT方法会向服务器写入文档，语义为让服务器用请求的主体部分创建一个由请求URL命名的新文档，如果URL已经存在了文件，那么就覆盖它。

•  POST

     POST方法起初是向服务器输入数据的，现在通常用它来实现HTML表单。

•  TRACE

    TRACE方法允许客户端在最终将请求发送给服务器时，看到它会变成什么样子，TARCE请求会发起“环回”诊断，报文最后一站会发挥一条TRACE响应，并在响应主体中携带他收到的原始报文，这样客户端就可查看它所发送的请求经过网络时候是否发生了变化，例如：

    请求报文：

    TRACE /index.html HTTP/1.1

    Accept:*/*

    Host:www.baidu.com

    响应报文：

    HTTP/1.1 200 OK

    Content-type:text/plain

    Content-length:96

    

    TRACE /index.html HTTP/1.1

    Accept:*/*

    Host:www.baidu.com

    TRACE可以很方便的诊断，但他也有缺点，网络中间的应用程序可能会根据请求的方法不通，而采取不同的处理方式，但TRACE并不能提供区分这些方法的机制。同时TRACE请求中不能带有实体的主体部分，而其相应部分为服务器收到的TRACE请求的精确副本。

•  OPTIONS

      OPTIONS方法请求服务器告知其支持的各种功能，可以询问服务器对于特定资源支持哪些方法，如对index.html，支持GET,POST请求。

•  DELETE

       DELETE方法请服务器删除请求URL所指定的资源，但是是否删除是由服务器进行决定的。

•  扩展方法

       未定义在HTTP标准中的，由服务器自行实现的一些方法。

     状态码：

      写了这么多了，状态码这部分有点懒得写了。。。。

      正好看到了一篇好文，引用过来吧：http://www.cnblogs.com/TankXiao/archive/2013/01/08/2818542.html

      这次的笔记就到这里，估计下一章节要拆分，主要介绍的是连接管理，和TCP方面的问题。