HTTP状态码
状态码的职责是当客户端向服务器端发送请求时,描述返回的请求结果。借助状态码,用户可以知道服务器端是正常处理了请求,还是出现了错误。
状态码如:200 OK,以3位数字和原因短语组成。数字中第一位指定了响应类别,后两位无分类。响应类别有以下5种:
| 状态码 | 类别 | 原因短语 |
|---|---|---|
| 1XX | Informational(信息性状态码) | 接收的请求正在处理 |
| 2XX | Success(成功状态码) | 请求正常处理完毕 |
| 3XX | Redirection(重定向状态码) | 需要进行附加操作以完成请求 |
| 4XX | Client Error(客户端错误状态码) | 服务器无法处理请求 |
| 5XX | Server Error(服务器错误状态码) | 服务器处理请求出错 |
2XX成功
2XX的响应结果表明请求被正常处理了。
- 200 OK: 表示从客户端发来的请求在服务器端被正常处理了。在响应报文内,随状态码一起返回的信息会因方法定不同而发生改变。比如,使用GET方法时,对应请求资源的实体会作为响应返回;而使用HEAD方法时,对应请求资源的实体主体不随报文首部作为响应返回。
- 204 No Content:该状态码代表服务器接收的请求已成功处理,但在返回的响应报文中不含实体的主体部分。另外,也不允许返回任何实体的主体。一般在只需从客户端往服务器发送信息,而对客户端不需要发送新信息内容的情况下使用。
- 206 Partial Content:该状态码表示客户端进行了范围请求,而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。
3XX重定向
3XX响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。
- 301 Moved Permanently:永久性重定向。该状态码表示请求的资源已被分配了新的URI,以后应使用资源现在所指的URI。也就是说,如果已经把资源对应的URI保存为书签了,这时应该按Location首部字段提示的URI重新保存。
- 302 Found:临时性重定向。该状态码表示请求的资源已被分配了新的URI,希望用户(本次)能使用新的URI访问。和301 Moved Permanently状态码相似,但302状态码代表的资源不是被永久移动。
- 303 See Other:该状态码表示由于请求对应的资源存在着另一个URI,应使用GET方法定向获取请求的资源。303状态码和302 Found状态码有着相同的功能,但303状态码明确表示客户端应当采用GET方法获取资源,这点与302状态码有所区别。
当301、302、303响应状态码返回时,几乎所有的浏览器都会把POST改成GET,并删除请求报文内的主体,之后请求会自动再次发送。
- 304 Not Modified:该状态码表示客户端发送附带条件的请求时,服务器端允许请求访问资源,但因发生请求未满足条件的情况后,直接返回304 Not Modified(服务器端资源未改变,可直接使用客户端未过期的缓存)。304状态码返回时,不包含任何响应的主体部分。304虽然被划分在3XX类别中,但是和重定向没有任何关系。
- 307 Temporary Redirect:临时重定向,该状态码与302 Found有着相同的含义。尽管302标准禁止POST变换成GET,但实际使用时大家并不遵守。307会遵照浏览器标准,不会从POST变成GET。
4XX客户端错误
4XX的响应结果表明客户端是发生错误的原因所在。
- 400 Bad Request:该状态码表示请求报文中存在语法错误。当错误发生时,需修改请求的内容再次发送请求。另外。浏览器会像200 OK一样对待该状态码。
- 401 Unauthorized:该状态码表示发送的请求需要有通过HTTP认证的信息。另外若之前已进行过1次请求,则表示用户认证失败。返回含有401的响应必须包含一个是用于被请求资源的WWW Authenticate首部用以质询用户信息。当浏览器初次接收到401响应,会弹出认证用的对话窗口。
- 403 Forbidden:该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由,但如果想做说明的话,可以在实体的主体部分对原因进行描述,这样就能让用户看到了。
- 404 Not Found:该状态码表明服务器上无法找到请求的资源。除此之外,也可以在服务器端拒绝请求且不想说明理由时使用。
5XX服务器错误
5XX的响应结果表明服务器本身发生错误。
- 500 Internal Server Error:该状态码表明服务器端在执行请求时发生了错误。也有可能是Web应用存在bug或某些临时错误的故障。
- 503 Service Unavailable:该状态码表明服务器暂时处于超负载状态或正在进行停机维护,现在无法处理请求。如果事先得知解除以上状况需要的时间,最好写入RetryAfter 首部字段再返回给客户端。
与HTTP协作的Web服务器
HTTP通信时,除客户端和服务器以外,还有一些用于通信数据转发的应用程序,例如代理、网关和隧道。它们可以配合服务器工作。这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器,并且能接收从那台服务器发送的响应再转发给客户端。
- 代理:代理是一种有转发功能的应用程序,它扮演了位于服务器和客户端“中间人”的角色,接收由客户端发送的请求并转发给服务器,同时也接收服务器返回的响应并转发给客户端。
- 网关:网关是转发其他服务器通信数据的服务器,接收从客户端发送来的请求时,它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉,自己的通信目标是一个网关。
- 隧道:隧道是在相隔甚远的客户端和服务器两者之间进行中转,并保持双方通信连接的应用程序。
代理
代理服务器的基本行为就是接收客户端发送的请求后,转发给其他服务器。代理不改变请求URI,会直接发送给前方持有资源的目标服务器。
持有资源实体的服务器被称为源服务器,从源服务器返回的响应经过代理服务器后再传给客户端。
在HTTP通信过程中,可级联多台代理服务器。请求和响应的转发会经过数台类似锁链一样连接起来的代理服务器。转发时,需要附加Via首部字段以标记出经过的主机信息。
使用代理服务器的理由有:利用缓存技术减少网络带宽的流量,组织内部针对特定网站的访问控制,以获取访问日志为主要目的,等等。
代理有多种使用方法,按两种基准分类:一种是是否使用缓存,另一种是是否会修改报文。
- 缓存代理:代理转发响应时,缓存代理会预先将资源的副本(缓存)保存在代理服务器上。当代理再次接收到对相同资源的请求时,就可以不从源服务器那里获取资源,而是将之前缓存的资源作为响应返回。
- 透明代理:转发请求或响应时,不对报文做任何加工的代理类型被称为透明代理。反之,对报文内容进行加工的代理被称为非透明代理。
网关
网关的工作机制和代理十分相似,而网关能使通信线路上的服务器提供非HTTP协议服务。
利用网关能提高通信的安全性,因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。比如,网关可以连接数据库,使用SQL语句查询数据。另外,在Web购物网站上进行信用卡结算时,网管可以和信用卡结算系统联动。
隧道
隧道可按要求建立起一条与其他服务器的通信线路,届时使用SSL等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。
隧道本身不会去解析HTTP请求,也就是说,请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。
保存资源的缓存
缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问,因此也就节省了通信流量和通信时间。
缓存服务器是代理服务器的一种,并归类在缓存代理类型中。换句话说,当代理转发从服务器返回的响应时,代理服务器将会保存一份资源的副本。
缓存服务器的优势在于利用缓存可避免多次从源服务器转发资源。因此客户端可就近从缓存服务器上获取资源,而源服务器也不必多次处理相同的请求了。
- 缓存的有效期限:当遇上源服务器上的资源更新时,如果还使用不变的缓存 ,那就会演变成返回更新前的“旧”资源了。即使存在缓存,也会因为客户端的要求、缓存的有效期等因素,向源服务器确认资源的有效性。若判断缓存失效,缓存服务器将会再次从源服务器上获取“新”资源。
- 客户端的缓存:缓存不仅可以存在于缓存服务器内,还可以存在客户端浏览器中。浏览器缓存如果有效,就不必再向服务器请求相同的资源了,可以直接从本地磁盘内读取。另外,和缓存服务器相同的一点是,当判定缓存过期后,会向源服务器确认资源的有效性。若判断浏览器缓存失效,浏览器会再次请求新资源。
HTTP首部
HTTP协议的请求和响应报文中必定包含HTTP首部,首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。对于客户端用户来说,这些信息中的大部分内容都无须亲自查看。
HTTP首部字段是构成HTTP报文的要素之一。在客户端与服务器之间以HTTP协议进行通信的过程中,无论是请求还是响应都会使用首部字段,它能起到传递额外重要信息的作用。使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。
HTTP首部字段是由首部字段名和字段值构成的,中间用冒号“:”分割。首部字段名:字段值。对于字段值对应单个HTTP首部字段可以有多个值:Keep-Alive:timeout=15,max=100
HTTP首部字段根据实际用途被分为以下4种类型:
- 通用首部字段:请求报文和响应报文两方都会使用的首部。
- 请求首部字段:从客户端向服务端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
- 响应首部字段:从服务器端向客户端返回响应报文时使用的首部。补充了相应的附加内容,也会要求客户端附加额外的内容信息。
- 实体首部字段:针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
下面是HTTP/1.1首部字段一览,共47种:
- 通用首部字段:

- 请求首部字段:

- 响应首部字段:

- 实体首部字段:

通用首部字段
通用首部字段是指,请求报文和响应报文双方都会使用的首部。
Cache-Control
通过指定首部字段Cache-Control的指令,就能操作缓存的工作机制。指令的参数是可选的,多个指令之间通过“,”分隔。首部字段Cache-Control的指令可用于请求及时响应。下面是Cache-Control指令一览:
- 缓存请求指令:

- 缓存响应指令:

Connection
Connection首部字段具备如下两个作用:
- 控制不再转发给代理的首部字段
在客户端发送请求和服务器返回响应内,使用Connectioin首部字段,可控制不再转发给代理的首部字段。 - 管理持久连接
HTTP/1.1版本的默认连接都是持久连接。为此,客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时,则指定Connection首部字段的值为Close。HTTP/1.1之前的HTTP版本的默认连接都是非持久连接。为此如果想在旧版本的HTTP协议上维持持久连接,则需要指定Connection首部字段的值为Keep-Alive。服务器就会如图上一样加上首部字段Keep-Alive及首部字段Connection后返回响应。
Date
首部字段Date表明创建HTTP报文的日期和时间。HTTP/1.1协议规定的日期时间的格式如下:
1 | Date: Tue, 03 Jul 2012 04:40:59 GMT |
Pragma
Pragma时HTTP/1.1之前版本的历史遗留字段,仅作为与HTTP/1.0的向后兼容而定义。该首部字段只用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。HTTP/1.1完全可以使用Cache-Control:no-cache代替。
Trailer
首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。该首部字段可应用在HTTP/1.1版本分块传输编码时。
上图中,指定首部字段Trailer的值为Expires,在报文主体之后出现了首部字段Expires。
Transfer-Encoding
首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。HTTP/1.1的传输编码方式仅对分块传输编码有。效
上图正证如在首部字段Transfer-Encoding中指定的那样,有效使用分块传输编码,且分别被分成3312字节和914字节大小的分块数据。
Upgrade
首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信,其参数可以用来指定一个完全不同的通信协议。
如上图,使用首部字段Upgrade时,还需要额外指定Connection:Upgrade。对于附有首部字段Upgrade的请求,服务器可用101 Switching Protocols状态码作为响应返回。
Via
使用首部字段Via是为了追踪客户端与服务器端之间的请求和响应报文的传输路径。报文经过代理或网关时,会现在首部字段Via中附加该服务器的信息,然后再进行转发。
首部字段Via不仅用于追踪报文的转发,还可避免请求回环的发生。所以必须在经过代理时附加该首部字段内容。
Via首部是为了追踪传输路径,所以经常会和TRACE方法一起使用。比如,代理服务器接收到由TRACE方法发送过来的请求时,其中Max-Forward:0,代理服务器就不能再转发该请求了。这种情况下,代理服务器会将自身的信息附加到Via首部后,返回该去请求的响应。
Warning
HTTP/1.1的Warning首部是从HTTP/1.0的响应首部(Retry-After)演变来的。该首部通常会告知用户一些与缓存相关的问题的警告。Warning首部的格式如下,最后的日期时间部分可省略:
1 | Warning: [警告码][警告的主机:端口号]“[警告内容]”([日期时间]) |
HTTP/1.1中定义了7种警告,警告码对应的警告内容可如下参考:
请求首部字段
请求首部字段是从客户端往服务器端发送请求报文中所使用的字段,用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。
- Accept:Accept首部字段可通知服务器,用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用type/subtype这种形式,一次指定多种媒体类型。例如,文本文件:text/html,text/plain;图片文件:image/png等等。若想要给显式的媒体类型增加优先级,则使用q=来额外表示权重值,用分号“;”进行分隔。权重范围为0~1,默认为1。
- Accept-Charset:该首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外,可一次性指定多种字符集。与首部字段Accept相同的是可以使用权重。
- Accept-Encoding:Accent-Encoding首部字段可用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序,可一次性指定多种内容编码。如gzip、compress…。
- Accept-Language:该首部字段用来告知服务器用户代理能够处理的自然语言集,以及自然语言集的相对优先级。可一次指定多种自然语言集。
- Authorization:该首部字段用来告知服务器,用户代理的认证信息。通常,想要通过服务器认证的用户代理在接收到返回的401状态码响应后,把首部字段Authorization加入请求中。
- Expect:客户端使用Expect首部字段告知服务器,期望出现的某种特定行为。因服务器无法理解客户端的期望做出回应而发生错误时,会返回状态码417 Expectation Failed。等待状态码100响应的客户端在发生请求时,需要指定Expect:100-continue。
- Form:用来告知服务器使用用户代理的用户的电子邮件地址。通常其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。
- Host:该首部字段会告知服务器,请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。
- If-Match:形如If-xxx这种样式的请求首部字段,都可称为条件请求。服务器接收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。该首部字段会告知服务器匹配资源所用的实体标记(ETag)值,仅当两者一致时,才会执行请求,反之返回状态码412 Precondition Failed的响应。
- If-Modified-Since:该首部字段会告知服务器若该字段值早于资源的更新时间,则希望能处理该请求。如果在该字段值的日期时间之后,请求的资源都没有更新过,则返回状态码304 Not Modified响应。
- If-None-Match:它和首部字段If-Match作用相反,用于指定字段值的实体标记(ETag)值与请求资源的ETag不一致时,它就告知服务器处理该请求。
- If-Range:它告知服务器若指定的If-Range字段值和请求资源的ETag值或时间相一致时,则作范围请求处理,反之则返回全体资源。
- If-Unmodified-Since:它与首部字段If-Modified-Since的作用相反。
- Max-Forwards:通过TRACE方法或OPTIONS方法,发送包含首部字段Max-Forwards的请求时,该字段以十进制整数形式指定可经过的服务器最大数目。
- Proxy-Authorization:接收到从代理服务器发来的认证质询时,客户端会发送包含该首部字段的请求,以告知服务器认证所需的信息。
- Range:对于只需获取部分资源的范围请求,包含该首部字段即可告知服务器资源的指定范围。接收到附带Range首部字段请求的服务器,会在处理请求之后返回状态码206 Partial Content。无法处理该范围请求时,则会返回状态码200 OK的响应及全部资源。
- Referer:它会告知服务器请求的原始资源的URI。
- TE:它会告知服务器客户端能够处理响应的传输编码方式及相对优先级,和Accept-Encoding很像,但是用于传输编码。
- User-Agent:该首部字段会将创建请求的浏览器和用户代理名称等信息传达给服务器。
响应首部字段
响应首部字段是由服务器向客户端返回响应报文中所使用的字段,用于补充响应的附加信息、服务器信息,以及对客户端的附加要求等信息。
- Accept-Ranges:该首部字段是用来告知客户端服务器是否能够处理范围请求,以指定获取服务器端某个部分的资源。可指定的字段值有两种,可处理范围请求时指定其为byte,反之则指定为none;
- Age:告知客户端,源服务器在多久前创建了响应。字段值的单位为秒。
- ETag:告知客户端实体标识,它是一种可将资源以字符串形式做唯一性表示的方式。服务器会为每份资源分配对应的ETag值。
- 强ETag:不论实体发生多么细微的变化都会改变其值。
- 若ETag:只用于提示资源是否相同,只有资源发生了根本改变才会变该其值。会在字段值最开始附加W/。
- Location:可将响应接收方引导至某个与请求URI位置不同的资源。基本上会配合3xx:Redirecting的响应,提供重定向的URI。
- Proxy-Authenticate:会把由代理服务器所要求的认证信息发送给客户端。
- Retry-After:告知客户端多久之后再次发送请求。主要配和状态码503 Service Unavailabl使用。
- Server:告知客户端当前服务器上安装的HTTP服务器应用程序的信息,不单会标出服务器上的软件应用名称,还有可能包括版本号和安装时启用的可选项。
- Vary:可对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的命令。
- WWW-Authenticate:告知客户端适用于访问请求URI所指定资源的认证方案和带参数提示的质询。状态码401 Unauthorized响应中,肯定带有该首部字段。
实体首部字段
实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部,用于补充内容的更新时间等与实体相关的信息。
- Allow:用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时,会以状态码405 Method Not Allowed作为响应返回,同时还会把所有能支持的HTTP方法写入首部字段Allow后返回。
- Content-Encoding:告知客户端服务器对实体的主体部分选用的内容编码。如gzip、compress等。
- Content-Language:告知客户端实体主体使用的自然语言。
- Content-Length:表明实体主体部分的大小,单位是字节。当编码传输时,则不能使用Content-Length首部字段。
- Content-Location:给出与报文主体部分相对应的URI。
- Content-MD5:该字段值是一串由MD5算法生成的值,目的在于检查报文主体在传输过程中是否保持完整,以及确认传输到达。
- Content-Range:针对范围请求,返回响应时使用的首部字段Content-Range,能告知客户端作为响应返回的哪个部分符合范围请求。
- Content-Type:说明实体主体内对象的媒体类型,和Accept一样。
- Expires:会将资源失效的日期告知客户端,缓存服务器在接收到含有首部字段Expires的响应后,会以缓存来应答请求,在到该该值指定时间之前,响应的副本会一直被保存。当首部字段Cache-Control有指定max-age指令时,会优先处理max-age指令。
- Last-Modified:指明资源最终修改的时间。
为Cookie服务的首部字段
Cookie的工作机制是用户识别及状态管理。Web网站为了管理用户的状态会通过Web浏览器,把一些临时数据写入用户的计算机内。接着当用户访问该Web网站时,可通过通信方式取回之前存放的Cookie。
| 首部字段名 | 说明 | 首部类型 |
|---|---|---|
| Set-Cookie | 开始状态管理所使用的Cookie信息 | 响应首部字段 |
| Cookie | 服务器接收到的Cookie信息 | 请求首部字段 |
- Set-Cookie:下标列举了Set-Cookie的字段值

- Cookie:会告知服务器,当客户端想获得HTTP状态管理支持时,就会在请求中包含从服务器接收到的Cookie。
HTTPS
在HTTP协议中有可能存在信息窃听或身份伪装等安全问题。使用HTTPS通信机制可以有效地防止这些问题。
HTTP的缺点
到目前为止,已经了解了HTTP具有相当优秀和方便的一面,然而HTTP并非只有好的一面,它也有不足之处:
- 通信使用明文(不加密),内容可能会被窃听。
- 不验证通信方的身份,因此有可能遭遇伪装。
- 无法证明报文的完整性,所以有可能已遭篡改。
HTTPS是身披SSL外壳的HTTP
HTTPS的加密方式就是通信加密。HTTP协议中没有加密机制,但可以通过和SSL或TLS的组合使用,加密HTTP的通信内容。
用SSL建立安全通信线路之后,就可以在这条线路上进行HTTP通信了,与SSL组合使用的HTTP被称为HTTPS。因此HTTPS并非应用层的一种新协议,知识HTTP通信接口部分用SSL和TLS协议代替而已。
通常,HTTP直接与TCP通信。当使用SSL时,则变成先和SSL通信,再由SSL和TCP通信了,简言之,所谓HTTPS就是身披着SSL协议这层外壳的HTTP。
在采用SSL后,HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。SSL是独立于HTTP的协议,所以不光是HTTP协议,其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。
HTTPS加密过程
HTTPS使用非对称加密,具体过程如下:
- 服务端先把自己的公钥(key1)发给证书颁发机构,向证书颁发机构申请证书。
- 证书颁发机构也有自己的一对公钥私钥,机构使用自己的私钥来加密key1,并且通过服务端网址等信息生成一个数字签名信息,证书签名同样经过机构的私钥加密。证书制作完成后,把这个证书返回给服务端。
- 当客户端向服务端请求通信时,服务端把自己申请的证书返回给客户端。
- 客户端收到证书以后,要做的第一件事情就是验证证书的真伪性。因为各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥,所以客户端根据证书颁发的机构,使用那个机构的公钥对证解密,书上的数字签名进行验证。
- 客户端对证书验证成功后,就可以放心的再次利用机构公钥,解密出服务端的公钥key1。
- 客户端生成自己的对称加密密钥key2,并且用服务端的公钥key1加密key2,发送给服务端。
- 服务端使用自己的私钥解密,得到对称加密的密钥key2,于是客户端与服务端之间开始使用key2进行对称加密的通信。
HTTPS也有缺点
HTTPS也存在一些问题,那就是当使用SSL时,它的处理速度会变慢。SSL的慢分为两种:一种是指通信慢,另一种是指由于大量消耗CPU及内存等资源,导致处理速度变慢。
和使用HTTP相比,网络负载可能会变慢2到100倍,除去和TCP连接、发送HTTP请求/响应以外,还必须进行SSL通信,因此整体上处理通信量不可避免会增加。
另一点就是SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理,因此从结果上来讲,比起HTTP会更多的消耗服务器和客户端的硬件资源,导致负载增强。
基于HTTP的功能追加协议
虽然HTTP协议简单又简捷,但随着时代的发展,其功能使用上捉襟见肘的疲态已经凸显,因此下面将讲解一下基于HTTP新增的功能的协议。
SPDY
Google在2010年发布了SPDY(取自speedy),其开发目标旨在解决HTTP的性能瓶颈,缩短Web页面的加载时间(50%)。若想在现有Web实现所需的功能,以下这些HTTP标准就会成为瓶颈:
- 一条连接上只可发送一个请求。
- 请求只能从客户端开始,客户端不可以接收除响应以外的指令。
- 请求/响应首部未经压缩就发送,首部信息越多延迟越大。
- 发送冗长的首部,每次互相发送相同的首部造成的浪费较多。
- 可任意选择数据压缩格式,非强制压缩发送。
长轮询与短轮询
长轮询与短轮询是基于Ajax实现的解决办法,使用局部刷新的方法可以达到实时更新的效果,但是依旧没有解决HTTP协议本身的问题。
- 长轮询:长轮询是服务器收到请求后如果有数据,立刻响应请求;如果没有数据,就会保持连接一段时间,这段时间内如果有数据立刻响应请求,如果时间到了还没有数据,则响应HTTP请求。浏览器在收到请求后,再立刻发送一个同样HTTP请求查询是否有数据。长轮询的局限在与:
- 浏览器对同一服务器同时HTTP连接有最大限制,最好同一用户只存在一个长轮询。
- 服务端没有数据时,保持连接时会造成浪费,容易产生服务器瓶颈。
- 短轮询:短轮询是服务器收到请求时不管是否有数据都直接响应HTTP请求,浏览器收到HTTP响应隔一段时间后,再发送同样的HTTP请求查询是否有数据。HTTP短轮询的局限性在于实时性相对低一些。
Comet的解决办法
一旦服务器有内容更新,Comet不会让请求等待,而是直接给客户端返回响应,这是一种通过延迟应答,模拟实现服务器端向客户端推送的功能。
通常,服务器端接收到请求,在处理完毕后就会立即返回响应,但为了实现推送功能,Comet会先将响应置于挂起状态,当服务器端有内容更新时,再返回该响应。因此,服务端一旦有更新,就可以立即反馈给客户端。
内容上虽然可以做到实时更新,但为了保留响应,一次连接的持续时间也变长了。期间,为了维持连接会消耗更多的资源。另外,Comet也仍未解决HTTP协议本身的问题。
SPDY的设计与功能
处于持续开发状态中的SPDY协议,正是为了在协议级别消除HTTP所遭遇的瓶颈。SPDY没有完全改写HTTP协议,而是在TCP/IP的应用层与传输层之间通过新加会话层的形式运作。同时考虑到安全性问题,SPDY规定通信中使用SSL。
SPDY以会话层的形式加入,控制对数据的流动,但还是采用HTTP建立通信连接,因此可照常使用HTTP的GET和POST等方法、Cookie以及HTTP报文等。
使用SPDY后,HTTP协议额外获得以下功能:
- 多路复用流:通过单一的TCP连接,可以无限制处理多个HTTP请求,所有请求的处理都在一条TCP连接上完成,因此TCP的处理效率得到提高。
- 赋予请求优先级:SPDY不仅可以无限制的并发处理请求,还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时,解决因带宽低而导致响应变慢的问题。
- 压缩HTTP首部:压缩HTTP请求和响应的首部,这样通信产生的数据包流量和发送的字节数就更少了。
- 推送功能:支持服务器主动向客户端推送数据的功能,这样服务器就可直接发送数据,而不必等待客户端的请求。
- 服务器提示功能:服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在,因此在资源已缓存等情况下,可以避免发送不必要的请求。
全双工通信的WebSocket
WebSocket视野更独立的协议标准,即Web浏览器与Web服务器之间全双工通信标准,一旦Web服务器与客户端之间建立起WebSocket协议的通信连接,之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送JSON、XML、HTML或图片的等任意格式的数据。
由于是建立在HTTP基础上的协议,因此连接的发起方仍是客户端,而一但确立WebSocket通信连接,不论服务器还是客户端,任意一方都可直接向对方发送报文。下面是WebSocket协议的主要特点:
- 推送功能:支持由服务器向客户端推送数据的推送功能,这样服务器可直接发送数据,而不必等待客户端的请求。
- 减少通信量:只要建立起WebSocket连接,就希望一直保持连接状态。和HTTP相比,不但每次连接时的总开销减少,而且由于WebSocket的首部信息很小,通信量也相应减小了。
HTTP/2.0
HTTP/2.0的目标是改善用户在使用Web是的速度体验,HTTP/2.0围绕着主要的7项技术进行讨论,现阶段大都倾向于采用以下协议的技术:
- 多路复用
- TLS义务化
- 协商
- 客户端拉拽/服务器推送
- 流量控制
- WebSocket