CentOS6服务管理之WEB-http协议详解
超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。收录在RFC 2616中。
注：
1.Request For Comments（RFC），是一系列以编号排定的文件。文件收集了有关互联网相关信息，以及UNIX和互联网社区的软件文件。目前RFC文件是由Internet Society（ISOC）赞助发行。基本的互联网通信协议都有在RFC文件内详细说明。RFC文件还额外加入许多的论题在标准内，例如对于互联网新开发的协议及发展中所有的记录。因此几乎所有的互联网标准都有收录在RFC文件之中。
2.超文本标记语言（英文：HyperText Markup Language，HTML）是为“网页创建和其它可在网页浏览器中看到的信息”设计的一种标记语言。HTML被用来结构化信息――例如标题、段落和列表等等，也可用来在一定程度上描述文档的外观和语义。HTML档案最常用的扩展名（扩展名）为.html。
一.HTTP协议概述
HTTP是一个客户端终端（用户）和服务器端（网站）请求和应答的标准（TCP）。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口（默认端口为80）。我们称这个客户端为用户代理程序（user agent）。应答的服务器上存储着一些资源，比如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个“中间层”，比如代理、网关或者隧道（tunnel）。
尽管TCP/IP协议是互联网上最流行的应用，HTTP协议中，并没有规定必须使用它或它支持的层。事实上，HTTP可以在任何互联网协议上，或其他网络上实现。HTTP假定其下层协议提供可靠的传输。因此，任何能够提供这种保证的协议都可以被其使用。因此也就是其在TCP/IP协议族使用TCP作为其传输层。
通常，由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。
一次HTTP请求与其对应的响应，称之为HTTP的事务
二.HTTP报文解析
HTTP报文分类
HTTP报文分为请求报文(request message)与响应报文(response message)
一个HTTP报文由四部分组成，分别是:
起始行(start line)
首部(header)
空行
主体(body)
1）.HTTP请求报文格式
<method> <request-URL> <version> #请求行 <headers> #请求头 #空行 <body> #主体
注：请求行和标题必须以<CR><LF>作为结尾。空行内必须只有<CR><LF>而无其他空格。在HTTP/1.1协议中，所有的请求头，除Host外，都是可选的。
实例：
[root@www ~]# telnet www1.stu31.com 80 Trying 172.16.31.31... Connected to www1.stu31.com. Escape character is '^]'. GET /index.html HTTP/1.1 Host:172.16.31.31
HTTP/1.1 200 OK Date: Sun, 14 Dec 2014 01:33:01 GMT Server: Apache/2.2.15 (CentOS) Last-Modified: Sat, 13 Dec 2014 04:55:43 GMT ETag: "14-f-50a11d25e0c6c" Accept-Ranges: bytes Content-Length: 15 Connection: close Content-Type: text/html; charset=UTF-8 www1.stu31.com Connection closed by foreign host.
上面一段是请求报文，下面一段是响应报文
2).HTTP请求报文详细解析
A.请求方法
HTTP/1.1协议中共定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：
OPTIONS：这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用'*'来代替资源名称，向Web服务器发送OPTIONS请求，可以测试服务器功能是否正常运作。
HEAD：与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部份。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。
GET：向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据，而不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。参见安全方法
POST：向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。
PUT：向指定资源位置上传其最新内容。
DELETE：请求服务器删除Request-URI所标识的资源。
TRACE：回显服务器收到的请求，主要用于测试或诊断。
CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。
HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。
B.URL
一个完整的包括类型、主机名和可选路径名的统一资源引用名，可以是相对的URL ，也可以是绝对路径URL。
C.HTTP版本：HTTP协议的版本；HTTP/<major>.<minor>；
超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本号的用法。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。
HTTP/0.9
已过时。只接受GET一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持POST方法，因此客户端无法向服务器传递太多信息。
HTTP/1.0
这是第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用，特别是在代理服务器中。
HTTP/1.1
当前版本。持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。
HTTP/1.1相较于HTTP/1.0协议的区别主要体现在：
缓存处理
带宽优化及网络连接的使用
错误通知的管理
消息在网络中的发送
互联网地址的维护
安全性及完整性
HTTP/2
由互联网工程任务组的httpbis工作小组开发中的下一代HTTP协议。计划于2015年2月作为互联网标准正式发布。
3).HTTP响应报文格式：
<version> <status> <reason-phrass> #响应行 <headers> #响应头 #空行 <body> #主体
一个响应报文实例：
[root@www ~]# curl -I http://www1.stu31.com HTTP/1.1 200 OK Date: Sun, 14 Dec 2014 01:29:27 GMT Server: Apache/2.2.15 (CentOS) Last-Modified: Sat, 13 Dec 2014 04:55:43 GMT ETag: "14-f-50a11d25e0c6c" Accept-Ranges: bytes Content-Length: 15 Connection: close Content-Type: text/html; charset=UTF-8
4).HTTP响应报文详解
响应行：
所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。
状态代码的第一个数字代表当前响应的类型：
1xx消息：请求已被服务器接收，继续处理 2xx成功：请求已成功被服务器接收、理解、并接受 3xx重定向：需要后续操作才能完成这一请求 4xx请求错误：请求含有词法错误或者无法被执行 5xx服务器错误：服务器在处理某个正确请求时发生错误
虽然RFC 2616中已经推荐了描述状态的短语，例如"200 OK"，"404 Not Found"，但是WEB开发者仍然能够自行决定采用何种短语，用以显示本地化的状态描述或者自定义信息。
介绍一些常用的状态码：
100：客户端应当继续发送请求。
101：服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade 消息头中定义的那些协议。只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。
200：请求已成功，请求所希望的响应头或数据体将随此响应返回。
原因短语：OK
201：请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 '202 Accepted'。
301：被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。在响应报文首部通过Location指明了资源现在所处的位置。
原因短语：Moved Permanently
302：请求的资源现在临时从不同的 URI 响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。在响应报文首部通过Location指明了资源现的临时位置。
原因短语：Found
303：对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。
304：如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。
原因短语：Not Modified
401：该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。
原因短语：Unauthorized
403：服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。
原因短语：Forbidden
404：请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
原因短语：Not Found
405：请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表。 鉴于 PUT，DELETE 方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。
500：服务器内部错误
原因短语：Internal Server Error
502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应，无法将其反馈个客户端；
原因短语：Bad Gateway
503：由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息，那么客户端应当以处理500响应的方式处理它。 注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
原因短语：Service Unvaliable
5).原因短语
原因短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的解释。比如在HTTP/1.0 200 OK 中，OK就是原因短语。原因短语和状态码是成对出现的。原因短语是状态码的可读版本，应用程序开发者将其传送给用户，用以说明请求期间发生了什么情况。
6).持续连接：
在HTTP 0.9和1.0使用非持续连接，在非持续连接下，每个tcp只连接一个web对象，连接在每个请求-回应对后都会关闭，一个连接可被多个请求重复利用的保持连接机制被引入。这种连接持续化显著地减少了请求延迟，因为客户不用在首次请求后再次进行TCP交互确认创建连接。现在在HTTP 1.1使用持续连接，不必为每个web对象创建一个新的连接，一个连接可以传送多个对象。
7).HTTP首部
HTTP首部分类
通用首部：请求报文和响应报文都可以使用 请求首部：仅能用于请求报文中 响应首部：仅能用于响应报文中 实体首部：or主体首部，描述body部分所包含的长度和内容格式等信息 扩展首部：规范中未定义的新首部
A.通用首部：既可以出现在请求报文中，也可以出现在响应报文中。
这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。他们像和事佬一样，，不论报文是何种类型，都为其提供一些有用的信息。例如不管是构建请求报文还是响应报文，创建报文的日期时间都是同一个意思，因此提供这类信息的首部对这两种类型的报文来说都是通用的。下面用表格的形式给出通用的信息性首部。
通用的信息性首部：
首部 描述 Connection 允许客户端和服务器指定与请求/响应连接有关的选项 Date 提供日期和时间标志，说明报文是什么时间创建的 MIME-Version 给出了发送端使用的MIME版本 Trailer 如果报文采用了分块传输编码(chunked transfer encoding)方式， 就可以用这个首部列出位于报文拖动(trailer)部分的首部集合。 Transfer-Encoding 告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。 Update 给出了发送端可能想要"升级"使用的新版本或协议 Via 显示了报文经过的中间节点(代理、网关)
通用缓存首部：
首部 描述 Cache-Control 用于随报文传送缓存指示 Pragma 另一种随报文传送指示的方式，但并不专用于缓存
B.请求首部：提供更多有关请求的信息。
请求首部是在请求报文中有意义的首部。用于说明是谁或什么在发送请求，请求源自何处，或者客户端的喜好及能力。服务器可以根据请求首部给出的客户端的信息，试着为客户端提供更好的响应。
（1）.请求的信息性首部：
首部 描述 Client-IP 提供了运行客户端的机器的IP地址 From 提供了客户端用户的E-mail地址 Host 给出了接收请求的服务器的主机名和端口号 Referer 提供了包含当前请求URI的文档的URL UA-Color 提供了与客户端显示器的显示颜色有关的信息 UA-CPU 给出了客户端CPU的类型或制造商 US-Disp 提供了与客户端显示器(屏幕)能力有关的信息 US-OS 给出了客户端显示器的像素信息 UA-Pixels 提供了客户端显示器的像素信息 User-Agent 将发起请求的应用程序名称告知服务器(User-Agent)用户代理， 其实不就是浏览器吗
（2）.Accept首部
为客户端提供了一种将其喜好和能力告知服务器的方式，包括他们想要什么，可以使用什么，以及最重要的，他们不想要什么。这样服务器就可以根据这些额外信息，对要发送的内容做出更明智的决定。Accept首部会使连接的两端都受益。客户端会得到他们想要的内容，服务器则不会浪费其时间和带宽来发送客户端无法使用的东西。
首部 描述 Accept 告诉服务器能够发送哪些媒体类型 Accept-Charset 告诉服务器能够发送哪些字符集 Accept-Encoding 告诉服务器能够发送哪些编码方式 Accept-Language 告诉服务器能够发送哪些语言 TE 告诉服务器可以使用哪些扩展传输编码
（3）.条件请求首部：
有时客户端希望为请求加上某些限制。比如客户端已经有了一份副本，就希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。通过条件请求首部，客户端就可以加上这种限制，要求服务器在对请求进行相应之前，确保某个请求为真。
条件请求首部：
首部 描述 Expect 允许客户端列出某请求所要求的服务器行为 If-Match 如果实体标记与文档当前的实体标记相匹配，就或者这份文档 If-Modified-Since 除非在某个指定的日期之后资源被修改过，否则就限制这个请求 If-Range 允许对文档的某个范围进行条件请求 If-Unmodified-Since 除非在某个指定的日期之后资源没有被修改过，否则就限制这个请求 Range 如果服务器支持范围请求，就请求资源的指定范围
（4）.安全请求首部：
HTTP本身就支持一种简单的机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定的资源之前，先对自身进行认证，这样就可以使事务稍微安全一些。
首部 描述
Authorization 包含了客户端提供给服务器，以便对其自身进行认证的数据 Cookie 客户端用它想服务器传送一个令牌-他并不是真正的安全首部， 但却是隐含了安全功能 Cookie2 用来说明请求端支持的cookie版本为2
（5）.代理请求首部：
随着因特网上代理的普遍应用，人们定义了几个首部来协助其更好地工作。
代理请求首部：
首部 描述 Max-Forword 在通往源端服务器的路径上， 将请求转发给其他代理或网关的最大次数-与TRACE方法一同使用 Proxy-Authorization 与Authorization首部相同，但这个首部是在与代理进行认证时使用的 Proxy-Connection 与Connection首部相同，但这个首部是在于代理建立连接时使用的
C.响应首部：提供更多有关响应的信息。
响应报文由自己的响应首部集。响应首部为客户端提供了一些额外的信息，比如谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些首部有助于客户端处理响应，并在将来发起更好的请求。
（1）.响应的信息性首部：
首部 描述 Age (从最初创建开始)响应持续时间 Public 服务器为其资源支持的请求方法列表 Retry-After 如果资源不可用的话，再次日期或时间重试 Server 服务器应用程序软件的名称和版本 Title 对HTML文档来说，就是HTML文档的源端给出的标题 Warning 比原因短语中更详细的一些警告报文
（2）.协商首部：如果资源有多种表示方法；
比如，如果服务器上有某文档的法语和德语译稿，HTTP/1.1可以为服务器和客户端提供对资源进行协商的能力。
首部 描述 Accept-Ranges 对此资源来说，服务器可接受的范围类型 Vary 服务器查看的其他首部的列表，可能会使响应发生变化； 也就是说，这是一个首部列表，服务器会根据这些首部的 内容挑选出最合适的资源版本发送给客户端。
（3）.安全响应首部：
我们已经看到过安全请求首部了，本质上这里说的就是HTTP的质询/响应认证机制的响应侧。
首部 描述 Proxy-Authenticate 来自代理的对客户端的质询列表 Set-Cookie 不是真正的安全首部，但隐含有安全功能； 可以在客户端设置一个令牌，以便服务器对客户端进行标识。 Set-Cookie2 与Set-Cookie类似。 WWW-Authenticate 来自服务器的对客户端的质询列表
D.实体首部：描述主体的长度和内容，或者资源自身。
有很多首部可以用来描述HTTP报文的负荷。由于请求和响应文本中都可能包含实体部分，所以在这两种类型的报文中都可能出现这些首部。实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。总之，实体首部可以告知报文的接收者它在对什么进行处理。
（1）.实体信息性首部：
首部 描述 Allow 列出了可以对此实体执行的请求方法 Location 告知客户端实体实际上位于何处；用于将接收端定向到资源的位置上去
（2）.内容首部：
内容首部提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。
比如，Web浏览器可以通过查看返回的内容类型，得知如何显示对象。
首部 描述 Content-Base 解析主体中的相对URL时使用的基础URL Content-Encoding 对主体执行的任意编码方式 Content-Language 理解主体时最适宜使用的自然语言 Content-Length 主体的长度或尺寸 Content-Location 资源实际所处的位置 Content-MD5 主体的MD5校验 Content-Range 在整个资源中此实体表示的字节范围 Content-Type 这个主体的对象模型
（3）.实体缓存首部：
通用的缓存首部说明了如何或什么时候进行缓存。实体的缓存首部提供了与被缓存实体有关的信息，比如验证已缓存的资源副本是否仍然有效所需的信息，以及更好地估计已缓存资源合适失效所需的线索。
首部 描述 ETag 与此实体有关的实体标记 Expires 实体不在有效，要从原始的源端再次获取此实体的日期和时间 Last-Modified 这个实体最后一次被修改的日期和时间
E.扩展首部：规范中没有定义的新首部。
每个HTTP首部都有一种简单的语法：名字后面跟着冒号(:)，然后跟上可选的空格，再跟上字段值。最后是一个回车换行。
8).实体部分
HTTP的第四部分是可选的实体主体部分，实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。
HTTP报文可以承载很多类型的数字数据，图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。
下面来实战下，我们用浏览器打开www.baidu.com首页，将HTTP报文解析下：
请求报文：
GET / HTTP/1.1 #请求方法为GET，HTTP协议为1.1 Host: www.baidu.com #URL为www.baidu.com Connection: keep-alive #连接，keep-alive保持状态 Pragma: no-cache Cache-Control: no-cache #上面两项缓存控制无 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 #服务器能够发送的文件类型 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 #用户代理，也就是浏览器了，显示了浏览器的详细信息 Referer: http://www.baidu.com/s?ie=utf-8&f=8&rsv_bp=1&rsv_idx=2&tn=baiduhome_pg&wd=%E9%9D%9E%E6%8C%81%E7%BB%AD%E8%BF%9E%E6%8E%A5&rsv_pq=8598553d000fc591&rsv_t=4251YMY3BAk%2FVeJKQwM3NBJl2coq27nCzjtZsHlUEIttmkF%2BfqUsODPLlte4YgbLWSvA&rsv_enter=1&inputT=3475&rsv_sug1=19&rsv_sug3=35&rsv_sug4=2895&rsv_sug2=0 #提供了包含当前请求URI的文档的URL Accept-Encoding: gzip,deflate,sdch #服务器能够发送的编码格式为gzip，deflate,sdch，编码格式不符合浏览器会解释不了 Accept-Language: zh-CN,zh;q=0.8 #服务器能够发送的语言 Cookie: BAIDUID=2CE13E7BE9ACA8F9E169F60BE8EB25C7:FG=1; BAIDUPSID=2CE13E7BE9ACA8F9E169F60BE8EB25C7; BDUSS=TRWcTlkcDN-Y0FsWElxRlh6NEFiZX5BMFNwU2lFUmQ2MDI2RERoZ3Fwd3gxS2RVQVFBQUFBJCQAAAAAAAAAAAEAAACZEzAUMzMyMTE5MzkzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADFHgFQxR4BUW; cflag=65535%3A2; __zpspc=188.2.1418298582.1418298582.2%234%7C%7C%7C%7C%7C%23; B64_BOT=1; BDRCVFR[feWj1Vr5u3D]=I67x6TjHwwYf0; H_PS_645EC=0368f0L2lWXrHWFjuCmRoD9dhLVaFfwvxtrlEXdWrmb2%2FgnpoMq06rALm2Vu1cLt5GBA; BD_CK_SAM=1; BD_HOME=1; H_PS_PSSID=10588_10162_1460_10624_10571_9583_10212_10500_10497_10017_10647_10459_10065_10218_9769_9392_10355_9094_10095_10008_10461_10171_10360_9023_10627; sugstore=1; BD_UPN=12314353 #cookie，服务器存储在客户端的信息，每次请求都会将服务器保存在客户端的cookie一并发送上服务器。
响应报文
HTTP/1.1 200 OK #HTTP版本 1.1 状态码200 原因短语OK Date: Sun, 14 Dec 2014 02:37:20 GMT #响应的时间日期 Content-Type: text/html #响应类型为HTML文本 Connection: Close #连接状态关闭 Vary: Accept-Encoding #服务器会根据这些首部的内容挑选出最合适的资源版本发送给客户端；接受编码 Cache-Control: private #缓存控制：私有的 Expires: Sun, 14 Dec 2014 02:37:20 GMT Server: BWS/1.1 #服务器应用程序软件的名称和版本 BDPAGETYPE: 2 BDQID: 0xc6e35f1c001da4ec BDUSERID: 338695065 #好像跟python架构相关的 Set-Cookie: BDSVRTM=124; path=/ Set-Cookie: BD_HOME=1; path=/ Set-Cookie: H_PS_PSSID=10588_10162_1460_10624_10571_9583_10212_10500_10497_10017_10647_10459_10065_10218_9769_9392_10355_9094_10095_10008_10461_10171_10360_9023_10627; path=/; domain=.baidu.com #设置Cookie相关的
三.一个web请求的基本过程
建立请求
接受请求
处理请求
访问资源
构建响应
发送响应
记录日志