HTTP协议详解（三）

接着第二篇继续学习...

6 HTTP的几个重要概念

6.1连接：Connection

一个传输层的实际环流，它是建立在两个相互通讯的应用程序之间。

在http1，request和reponse头中都有可能出现一个connection的头，此header的含义是当client和server通信时对于长链接如何进行处理。

在http1中，client和server都是默认对方支持长链接的， 如果client使用http1协议，但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

从HTTP1之后默认使用了长连接，在HTTP1.0中使用的是HTTP首部Connection：Keep-alive来进行长连接的实验性拓展。长连接使数据传输完成之后保持TCP连接不断开，等待在同域名下继续使用这个通道传输数据，与之相对应的就是短连接，从HTTP1开始要在HTTP请求报文中使用Connection：close来通知不希望使用长连接。在短连接中，对每一个请求/响应都要建立一次TCP连接，举个例子如某一个超文本文档上有N个位于同一个服务器的图片时，那么就要先后对该图片所在的服务器打开和关闭N+1次TCP连接，短链接会给服务器带来巨大的不必要的开销，也减慢了连接建立和关闭的过程。在使用了长连接之后，服务器允许TCP连接的保持已减少握手过程，服务器也可以在客户端请求时或者请求超时时关闭这个连接，在某些情况下，服务器并不知道要发送的文档的长度，那么服务器就要把长度未知这个首部通知客户，并在发送数据后关闭这个连接，因此客户就可以知道数据结束的地方就要到了。另外在首部中可以通过定义Keep-Alive首部来定义TCP连接的最长使用限时。实际上头部有了Connection： Keep-alive这个首部并不代表服务器一定就会使用长连接，客户端和服务端都可以忽略这个首部的定义。如下所示为长连接的连接模式图：

长连接模式下。当客户端向服务器发生请求之后，客户端如何判断服务器的数据已经发生完成？除了通过服务器关闭连接来被动的关闭HTTP的TCP连接之外，可以通过消息首部字段Content-Length来判断数据传输是否完毕，单位为字节，另外也可以通过使用消息首部字段Transfer-Encoding来协助完成判断，Transfer-Encoding：clunk或者Transfer-Encoding：clunked模式可以将数据分为一块一块的传输，clunk编码的具体格式这里暂不赘述。

6.2消息：Message

HTTP通讯的基本单位，包括一个结构化的八元组序列并通过连接传输。

6.3请求：Request

一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号。

6.4响应：Response

一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如“成功”或“没找到”)和文档的MIME类型。

6.5资源：Resource

由URI标识的网络数据对象或服务。

6.6实体：Entity

数据资源或来自服务资源的回映的一种特殊表示方法，它可能被包围在一个请求或响应信息中。一个实体包括实体头信息和实体的本身内容。

6.7客户机：Client

一个为发送请求目的而建立连接的应用程序。

6.8用户代理：UserAgent

初始化一个请求的客户机。它们是浏览器、编辑器或其它用户工具。

6.9服务器：Server

一个接受连接并对请求返回信息的应用程序。

6.10源服务器：Originserver

是一个给定资源可以在其上驻留或被创建的服务器。

6.11代理：Proxy

一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的服务器中。一个代理在发送请求信息之前，必须解释并且如果可能重写它。

代理经常作为通过防火墙的客户机端的门户，代理还可以作为一个帮助应用来通过协议处理没有被用户代理完成的请求。

6.12网关：Gateway

一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。

网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。

6.13通道：Tunnel

是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。当被中继的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。

6.14缓存：Cache

反应信息的局域存储。

Cookie的实质就是一个键值对，当一个客户端向服务端发送请求的时候，浏览器就查找在Cookie目录中是否有那个服务器发送的Cookie，如果有的话就会把相应的Cookie包含对请求之中，当这个Cookie包含在请求之中的时候服务端就可以知道这个客户是一个老客户，cookie的使用者和消费者都是服务端，这对于浏览器和消费者都是透明的。在HTTP报文分组中，与其功能相关的首部是Cookie首部和Set-Cookie首部。具体格式如下所示：

Set-Cookie:value [ ;expires=date][ ;domain=domain][ ;path=path][ ;secure]

Cookie : value

Cookie:value1 ; value2 ; name1=value1

在Set-Cookie中，可以通过定义选项的值来进一步确定Cookie的功能。

1.有效期选项（The expires  option）

紧跟cookie值后面的每个选项都以分号和空格分割，并且每个选项都指定cookie何时应该被发送到服务器。第一个选项是expires，其指定了cookie何时不会再被发送到服务器端的，因此该cookie可能会被浏览器删掉。例如：

1	Set-Cookie:name=Nicholas;expires=Sat, 02 May 2009 23:38:25 GMT

在没有expires选项时，cookie的寿命仅限于单一的会话中。浏览器的关闭意味这一次会话的结束，所以会话cookie只存在于浏览器保持打开的状态之下。这就是为什么当你登录到一个web应用时经常看到一个checkbox，询问你是否选择存储你的登录信息：如果你选择是的话，那么一个expires选项会被附加到登录的cookie中。如果expires选项设置了一个过去的时间点，那么这个cookie会被立即删除。

2.域选项（The domain option）

下一个选项是domain，指示cookie将要发送到哪个域或那些域中。默认情况下，domain会被设置为创建该cookie的页面所在的域名。例如本站中的cookie的domain属性的默认值为www.nczonline.com。domain选项被用来扩展cookie值所要发送域的数量。例如:

1	Set-Cookie:name=Nicholas;domain=nczonline.net

domain设置的值必须是发送Set-Cookie消息头的域名。例如，我无法向google.com发送一个cookie，因为这个产生安全问题。不合法的domain选项只要简单的忽略即可。

3.Path选项（The path option）

另一个控制何时发送Cookie消息头的方式是指定path选项。与domain选项相同的是，path指明了在发Cookie消息头之前必须在请求资源中存在一个URL路径。这个比较是通过将path属性值与请求的URL从头开始逐字符串比较完成的。如果字符匹配，则发送Cookie消息头，例如：

1	Set-Cookie:name=Nicholas;path=/blog

在这个例子中，path选项值会与/blog,/blogrool等等相匹配；任何以/blog开头的选项都是合法的。要注意的是只有在domain选项核实完毕之后才会对path属性进行比较。path属性的默认值是发送Set-Cookie消息头所对应的URL中的path部分。

4.secure选项（The  secure  option）

最后一个选项是secure。不像其它选项，该选项只是一个标记并且没有其它的值。一个secure cookie只有当请求是通过SSL和HTTPS创建时，才会发送到服务器端。这种cookie的内容意指具有很高的价值并且可能潜在的被破解以纯文本形式传输。例如

1	Set-Cookie:name=Nicholas;secure

现实中，机密且敏感的信息绝不应该在cookies中存储或传输，因为cookies的整个机制都是原本不安全的。默认情况下，在HTTPS链接上传输的cookies都会被自动添加上secure选项。

7 关于HTTP以及HTTPS的安全性

HTTP本身并不提供安全，然而通过在传输层和应用层中使用安全套接层（SSL）可以使HTTP运行在安全的环境下，即HTTPS，HTTPS可以提供保密性，客户和服务器鉴别以及数据的完整性。

SSL的设计时为了给应用层生成的数据提供安全以及压缩服务，一般来说SSL能接收来自任何应用层协议的数据，但最多情况下这个应用层的协议就是HTTP，SSL对应用层传来的数据提供多种服务：

分片：SSL把数据划分为长度小于或者等于2的14次字节的数据分片

压缩：数据分片通过使用一种由客户端和服务器协商好的无损压缩方式进行压缩，这个服务是可选的。

报文完整性：为了保护数据的完整性，SSL使用密钥散列函数来创建MAC。

保密：为了提供保密性，原始的数据和MAC一起用对称密钥加密技术来加密。

组帧：先在被加密的有效载荷上添加一个首部，然后再把这个恶有效载荷传递给可靠的运输层协议。

8 GET与POST方法的区别

（1）   在客户端，Get方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放置在HTML HEADER内提交。

（2）   GET方式提交的数据最多只能有1024字节，而POST则没有此限制。

（3）   安全性问题。正如在（1）中提到，使用 Get 的时候，参数会显示在地址栏上，而 Post 不会。所以，如果这些数据是中文数据而且是非敏感数据，那么使用 get；如果用户输入的数据不是中文字符而且包含敏感数据，那么还是使用 post为好。

（4）   安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。幂等的意味着对同一 URL 的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。换句话说，GET 请求一般不应产生副作用。从根本上讲，其目标是当用户打开一个链接时，她可以确信从自身的角度来看没有改变资源。比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。反之亦然。POST 请求就不那么轻松了。POST 表示可能改变服务器上的资源的请求。仍然以新闻站点为例，读者对文章的注解应该通过 POST 请求实现，因为在注解提交之后站点已经不同了（比方说文章下面出现一条注解）。

后面还有....