HTTP连接管理

HTTP

常见状态码：

状态码 原因短语 含义

100 Continue 说明收到了请求的初始部分，请客户端继续，发送了这个状态码之后，
服务器在收到请求之后必须进行响应。

101 Switching Protocols 说明服务器正在根据客户端的指定，将协议切换成Update首部所列的
协议

200 OK 请求没问题，实体的主体部分包含了所请求的资源

201 Created 用于创建服务器对象的请求（比如，PUT）。响应的实体主体部分中
应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。

202 Accepted 请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这
个请求；这只是意味着接受请求时，它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）

203 Non-Authoritative 实体首部包含的信息不是来自原远端服务器，而是来自于资源的一份副本。
Information 如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的
元信息进行验证，就会出现这种情况

204 No Content 响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在
浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面）

205 Reset Content 另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有HTML
表单元素

206 Partial Content 成功执行了一个部分或Range(范围)请求。稍后我们会看到，客户端可以通过
一些特殊的首部来获取部分或某个范围内的文档————这个状态码就说明范围请求成功了。

注：在对那些包含了重定向状态码的非HEAD请求进行响应时，最好要包含一个实体，并在实体中包含描述信息和指向（多个）重定向URL的链接。如：

HTTP/1.1 301 OK
Location: http://www.gentle-grooming.com/
Content-Length: 56
Content-Type: text/plain

Please go to our partner site,
www.gentle-grooming.com

300					Multiple Choices 	客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器
										上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择它希望使用的那一项了。有多个版本可用时，客户端需要沟通解决。

301					Moved Permanently	在请求的URL已被移除时使用。响应的Location首部中应该包含资源现在所处
										的URL

302 				Found 				与301状态码类似，但是，客户端应该使用Location首部给出的URL来临时定位
										资源。将来的请求仍应该使用老的URL

303 				See Other 			告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的Location
										首部。其主要母的是允许POST请求的响应将客户端定向到某个资源上去

304  				Not Modified 		客户端可以通过所包含的请求首部，使其请求变成有条件的。如果客户端发起
										了一个条件GET请求，而最近资源未被修改的话，就可以用这个状态码来说明
										资源未被修改。带有这个状态码的响应不应该包含实体的主体部分。

305 				Use Proxy  			用来说明必须通过一个代理访问资源；代理的位置由Location首部给出。很
										重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求。甚至所有对持有请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞。

307					Temporary Redireat 与301状态码类似；但客户端应该使用Location首部给出的URL来临时定位资源
										。将来的请求应该使用老的URL


  400 				Bad Request 		用于告知客户端发起了一个错误的请求
  				
  401 				Unauthorized 		返回适当的首部，用于获取客户端访问资源的权限
  				
  402         		Payment Required    此状态码未使用，保留
  				
  403                 Forbidden           服务器拒绝请求，可在响应主体中告知原因
  				
  404  				Not Found           用于告知客户端请求的资源在服务器不存在
  				
  405 				Method Not Allowd   告知客户端不支持当前方法，并在Allow首部返回支持的方法
  				
  406 				Not Acceptable     	没有客户端支持的资源类型
  				
  407 				Proxy Authentication  跟401类似，不过用户代理服务器
  					Requireed 
  				
  408 				Request Timeout     超时提醒
  				
  409      			Conflict            请求会造成服务器冲突
  				
  410  	            Gone   				跟404一样，只不过服务器曾经拥有过该请求资源
  				
  411 				Length Required    要求客户端发送Content-Length首部
  				
  412 				Precondition Failed  部分条件验证不通过
  				
  413   				Request Entity Too Large  客户端发送的主体超过了服务器的希望的长度
  				
  414 				Request  URL Too Long   客户端请求的时间比服务希望的时间长
  				
  415 				Unsupported Media Type 	服务器无法理解客户端请求的主体类型
  				
  416 				Requested Range Not    请求报文所请求的是指定资源的某个范围，而此范围无效或无法满足时
  					Satisfiable   			，使用此状态码
  				
  417					Expectation Failed 		请求中包含Expect首部，服务器无法满足
  				
  500					Internal Server Error  服务器错误
  				
  501 				Not Implemented         请求超出了服务器能处理的范围
  				
  502 				Bad Gateway 			作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条
  											伪响应（比如，它无法连接到其父网关）时，使用此状态码
  				
  503    				Service Unavailable 	用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器
  											知道什么时候资源会变为可用的，可以在响应中包含包含一个
  											Retry-After首部。
  				
  504 				Gateway Timeout 		与状态码408类似，只是这里的响应来自一个网关或代理，它们在等待另
  											一服务器对其请求进行响应时超时了
  				
  505 				HTTP Version Not        服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此
  					Supported 				状态码。有些服务器应用程序会选择不支持协议的早起版本	

HTTP常见的TCP时延：

• TCP连接建立握手。较小的HTTP事务可能会在TCP建立上花费50%，如果重用现存连接，可能会减少TCP建立时延造成的影响。
• TCP慢启动拥塞控制
• 数据聚集的Nagle算法
• 用于捎带确认的TCP延迟确认算法
• TIME_WAIT 的时延和端口耗尽

HTTP串行连接时延问题

若每个HTTP事务都串行的建立一条新连接，那么连接时延和慢启动时延就会叠加，造成可观的时延问题

优化的主要方法：

• 并行连接，代价是增加系统消耗、服务器负载

• 持久化（重用）连接

• 管道化连接，在持久连接的情况下，在响应到达之前，可以将多条请求放入队列。当第一条请求到达后，第二、三条请求也可以发送。

HTTP/1.1持久连接

HTTP1.0使用 keep-alive ，而HTTTP/1.1停止了对keep-alive 连接的支持，而是持久连接的设计，目的相同，但工作机制更优。

与HTTP/1.0的keep-alive连接不同，HTTP/1.1持久连接在默认情况下是激活的，除非特别指明，否则HTTP/1.1所有连接都是持久的。要在事务处理结束之后将连接关闭，HTTP/1.1应用程序必须向报文中显式添加一个Connection:close 首部。

当然HTTP/1.1客户端和服务器仍然可以随时关闭空闲的连接。不发送Connection:close并不意味着服务器承诺永远将连接保持在打开状态。

管道化连接的限制：

• 如果不是持久连接就不要使用管道连接
• 接收端必须按收到请求报文的顺序返回响应报文，因为HTTP报文中没有序列号标签。所以必须靠按序发送响应报文来达到“数据对应”
• 发送端应该做好数据没有发送完连接就关闭的准备，并开始重新发送未完成数据。
• HTTP客户端不应该用管道化的方式发送会产生副作用的请求（比如POST）。客户端不应该以管道化的方式传送非幂等请求。

连接关闭管理的问题

HTTP客户端、服务器或代理都可以在任意时刻关闭一条TCP传输连接。问题是，服务器永远都无法确定在它关闭连接的那一刻（以及因错误而关闭时），对端的客户端是否有数据要发送。（所以关闭连接需要使用“半关闭”、“等待一段时间空闲”等方式）

一般客户端在执行事务的过程中，如果传输连接关闭了，一般会重新打开连接并重新发送一次，但此重试要考虑是否会有副作用，即重试的处理行为必须是幂等的。

HTTP应用程序复杂之后，关闭连接需要使用半关闭来防止写入错误。一般应先关闭其输出信道，然后周期性地检查其输入信道的状态（查找数据，或流的末尾）。

HTTP重定向与负载均衡

现代网络中重定向是比较普遍的，HTTP重定向的原因：

1)可靠地执行HTTP事务

2)最小化时延

3)节约网络带宽

由于这些原因，web内容通常分布在很多地方。（出于可靠性原因：如果一个位置出问题了，还有其他的可用；客户端选择较近的资源，可以降低响应时间；将目标服务器分散，还可以减少网络拥塞。）

大多数重定向部署都包含了某些形式的负载均衡；反之因为输入报文一定会在分担负荷的服务器之间进行某种分布，所以任意形式的负载均衡中都包含了重定向。

浏览器配置、DNS、TCP/IP路由以及HTTP都提供了重定向报文的机制。

将报文重定向到服务器的方法：

机制	工作方式	重新路由的基础	局限性
HTTP重定向	HTTP请求到达首个服务器后，该服务器选择一台最佳的服务器为其提供内容。第一台服务器会向客户端发送一条到指定服务器的HTTP重定向。客户端会将请求重新发送到选中的服务器上。	选择最短路径时可用的选项较多，包括轮询负载均衡、最小化时延等	可能会很慢——每个事物都包含了附加的重定向步骤。而且，第一台服务器一定要能够处理处理请求负载
DNS重定向	DNS服务器决定在URL的主机名中返回多个IP地址中的哪一个	选择最短路径时可用的选项较多，包括轮询负载均衡、最小化时延等	需要配置DNS服务器
任播寻址	几台服务器使用相同的IP地址。每台服务器都会伪装成一个骨干路由器。其他路由器会将共享IP地址分组发送给最近的服务器	路由器有内建的最短路径路由功能	需要配置路由器。有地址冲突的风险。
IP MAC 转发	交换机或路由器这样的网元会读取分组的目的地址。如果应该将分组重定向，交换机会将服务器或代理的目标MAC地址赋予分组	节省带宽，提高QOS。负载均衡	服务器或代理的跳距必须是1
IP地址转发	第四层交换机会评估分组的目的端口并将重定向分组的IP地址改成代理或镜像服务器的IP地址

HTTP重定向

在服务器收到请求报文后，服务器没有回送带有HTTP状态码200的Web 页面主体，而是回送了一个带有状态码：302的重定向报文：

HTTP/1.0 302 Redirect
Server:Stronghold/2.4.2 Apache/1.3.6
Location: http://161.58.228.45/hammers.html

这时浏览器会用重定向URL重新发送请求，这次会发送给主机161.58.228.45：

GET /hammers.html HTTP/1.0
Host: 161.58.228.45
User-Agent: Mozilla/4.51 [en] (X11; U; IRIX 6.2 IP22)

当然另一个客户端可能会被重定向到另一台服务器上去。

HTTP 重定向的缺点：

• 需要原始服务器进行大量处理来判断要重定向到哪台服务器上去。有时，发布重定向所需的处理量几乎与提供页面本身所需的处理量一样。
• 增加了用户时延，因为访问页面时要进行两次往返。
• 如果重定向服务器出故障，站点就会瘫痪。

由于存在这些弱点，HTTP重定向通常都会与其他一种或多种重定向技术结合使用。

DNS重定向

DNS允许将几个IP地址关联到一个域中，可以配置DNS解析程序，或对其进行编程，以返回可变的IP地址。

解析程序返回IP地址时的算法策略较多，包括轮询负载均衡、最小化时延等