网络基础(2)--通信过程之一HTTP协议

从在浏览器中输入一个网址如www.baidu.com到百度首页呈现的过程,大致可以简单的分为以下几个关键的部分:

1) 封装HTTP请求

2) DNS, 获取www.baidu.com对应的IP地址.

3) ARP 获取IP对应的MAC地址

4) TCP链接

5) HTTP响应

6) 浏览器解析与渲染

注:有些部分可能同时存在.

本篇将从其中涉及的HTTP, DNS, ARP,TCP进行逐步介绍.同时,本篇采用每个部分集中介绍并不完全按照流程.如在介绍HTTP时,将会将会介绍它的请求和响应,在介绍TCP时也是如此.

1 HTTP协议

HTTP是一个无状态的应用层协议.该协议包含两个部分: HTTP请求和HTTP响应.

通用的消息格式含三个部分:开始行, 消息头域和消息实体.其中开始行又分为请求行和状态行

2 HTTP请求格式

HTTP请求行 
（请求）头 
空行 
可选的消息体 

注：请求行和标题必须以<CR><LF> 作为结尾（也就是，回车然后换行）。空行内必须只有<CR><LF>而无其他空格。在HTTP/1.1协议中，所有的请求头，除Host外，都是可选的。

实例：

GET / HTTP/1.1

Host: gpcuster.cnblogs.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

If-Modified-Since: Mon, 25 May 2009 03:19:18 GMT

请求方法（所有方法全为大写）有多种，各个方法的解释如下：
GET     请求获取Request-URI所标识的资源
POST    在Request-URI所标识的资源后附加新的数据
HEAD    请求获取由Request-URI所标识的资源的响应消息报头
PUT     请求服务器存储一个资源，并用Request-URI作为其标识
DELETE  请求服务器删除Request-URI所标识的资源
TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

3 HTTP响应

HTTP状态行 
（应答）头 
空行 
可选的消息体 

实例：

HTTP/1.1 200 OK

Cache-Control: private, max-age=30

Content-Type: text/html; charset=utf-8

Content-Encoding: gzip

Expires: Mon, 25 May 2009 03:20:33 GMT

Last-Modified: Mon, 25 May 2009 03:20:03 GMT

Vary: Accept-Encoding

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

Date: Mon, 25 May 2009 03:20:02 GMT

Content-Length: 12173

 

消息体的内容（略）

Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK      //客户端请求成功
400 Bad Request  //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 
403 Forbidden  //服务器收到请求，但是拒绝提供服务
404 Not Found  //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable  //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

4 关键点

4.1 持久链接与非持久链接

HTTP长连接，与一般每次发起http请求或响应都要建立一个tcp连接不同，http长连接利用同一个tcp连接处理多个http请求和响应，也叫HTTP keep-alive，或者http连接重用。使用http长连接可以提高http请求/响应的性能.

使用http长连接有很多好处，包括：
1)更少的建立和关闭tcp连接，可以减少网络流量。
2)因为已建立的tcp握手，减少后续请求的延时。
3)长时间的连接让tcp有充足的时间判断网络的拥塞情况，方便做出下步操作。

4.2 如何确定消息长度

1) 不含消息实体的消息通过协议规范,空行来识别.

2) transfer-coding: chunked编码

3) Content-Length字段: 16进制.

3) 媒体类型

4) 服务端关闭链接

RFC2616文档:

消息长度是指在传输编码使用后消息体的长度。当一个消息体被包含在一个消息中时，体长由下面决定（按优先级的顺序）：

1．   任何肯定不包含一个消息体的 response 消息总是在第一个空行处终结，而无论出现在消息中的实体的头区。

2．   如果一个 Transfer-Encoding 头区（ sec14.41 ）被给出而且只有 ”identity” ，那么传输长度是使用“chunked ”传输编码，直到连接被关闭消息被终结。

3．  如果一个 Content-Length 头区（ sec14.13 ）被给出，那么它既代表了实体长度也代表了传输长度。如果这两个长度不相等肯定不会有 Content-Length 。如果一个消息既存在 Transfer-Encoding 又存在 Content-Length ，后者被忽略。

4 ．如果消息使用 “multipart/byteranges” 做媒体类型，并且 transfer-length 也没被给出，那么这个自定界的媒体类型定义了传输长度。这个类型如果接收者无法解析它那肯定不能被使用；在一个 request 中，如果包含一个 Range 头和若干 byte-range 说明那个 client 能够解析 multipart/ranges 。一个 rang 头可能被一个不理解multipart/byteranges 的 proxy 传递，在这种情况下， server 必须使用 1 ， 3 ， 5 提供的方法定界。

5 ．到 server 关闭一个连接（关闭连接不能被用来指示一个 request 的结束，因为那样将导致 server 无法发送一个response 。）

为了和 HTTP/1 。 0 应用兼容，包含一个消息体的。 1 请求肯定包含一个有效的 Content-Length

除非知道 server 是 HTTP/1 。 1 兼容。如果一个 request 包含一个消息体而没有

Content-Length ，那么 server 如果不能决定消息的长度应该回以 400 ，或 411 如果它坚持接收一个有效Content-Length 。

所有接收实体的 HTTP/1 。 1 应用必须接收“ chunked ”传输编码（ sec3.6 ），因此允许使用这个机制决定消息长度。

消息绝对不能同时包含 Content-Length 头区和一个非 identity 传输编码。如果一定包含，那么 Content-Length被忽略。

如果一个 Content-Length 真被给出了，那 它一定对应消息体的字节个数。 HTTP/1 。 1user agent 必须告诉用户如果一个无效长度被接受和看到。

4.3 Cookie和Session

cookie的作用就是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案： 
1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。 
2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。 
3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。 

由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的，但实际上它还有其他选择。 

Cookie是在HTTP协议下，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由Web服务器保存在用户浏览器上的小文本文件，它可以包含有关用户的信息（如身份识别号码、密码、用户Web站点购物的方式或用户访问该站点的次数）。无论何时用户链接到服务器，Web站点都可以访问Cookie信息。

Session是前端浏览器与服务器每一次会话的表示变量，它附在每次会话的所有网页数据中，在一段时间内有效。每个访问用户都可单独拥有一个Session变量，存储会话的信息。

Session与Cookie概念相似，区别在于，Cookie是把信息记录在客户端的浏览器中，而Session对象则把信息记录在服务器中。

 Session是存储在服务器端的，但是SessionID是以Cookie方式存储在客户端的，客户端没有了Cookie再燃就找不到Session，也就不能够使用Session对象来存放数据了。Cookie的不可跨域名性.

Session的实现方式有两种: Cookie实现, URL回显实现.