连接管理

套接字流程

服务器：
     创建套接字(socket) => 将套接字绑定到端口(bind) => 监听套接字(listen) => 等待连接(accept)
     通知应用程序有连接到来 => 读取请求(read) => 处理请求报文 => 回送请求报文 => 关闭连接(close)
客户端：
     获取IP地址和端口号 => 创建套接字(socket) => 连接服务器IP:PORT(connect)
     连接成功 => 发送请求(write) => 等待响应(read) => 处理响应 => 关闭连接(close)

相关概念

  HTTP请求流程：DNS查询 => 连接 => 请求 => 处理 => 响应 => 关闭
  TCP握手流程：SYN => SYN + ACK => ACK
  TCP慢启动：每成功接收一个分组，就可以再发送两个分组
  TIME_WAIT累积与端口耗尽：已close端口在2MSL内不能重用
  最后一次ACK捎带数据  
  延迟确认：确认信息在下一次发送数据时捎带
  Nagle算法：在一定时延范围内，凑满报文再发送
  串行连接：
  并行连接：通过多条TCP连接发起并发的HTTP请求
  持久连接：重用TCP连接，以消除连接及关闭时延
  管道化连接：通过共享的TCP连接发起并发的HTTP请求

keep-alive

a 用于HTTP/1.0中，在HTTP/1.1中被persistent代替
     Connection: Keep-Alive
     Keep-Alive: max=5, timeout=120
b 哑代理
     有些代理，无法处理Connection: Keep-Alive，并将该首部转发后端服务器，并将后台服务器的回传报文中的Connection: Keep-Alive转发客户端，导致客户端和服务器均以为Keep-Alive生效。而代理本身却不能处理Keep-Alive。
c Proxy-Connection
     网景浏览器提出的针对哑代理的变通做法，浏览器用Proxy-Connection: Keep-Alive代替Connection: Keep-Alive，正常的代替在遇到Proxy-Connection: Keep-Alive时会将其转换为Connection: Keep-Alive发给服务器，而哑代理仍盲目转发。该方法可以应对都是哑代理或正常代理的情况，但对于既有哑代理又有正常代理则还是无法解决。
d 代理约束
     为避免类似哑代理问题的发生，现在的代理绝不能转发Connection首部和所有名字出现在Connection中的首部。
     有些不能作为Connection值的首页也不能被代理转发，如：Proxy-Authenticate、Proxy-Connection、Transfer-Encoding、Upgrade

HTTP/1.1 持久连接

  a. HTTP/1.1 持久连接默认情况下是激活的，而HTTP/1.0 的keep-alive默认是关闭的
  b. 若响应中包含Connection: close首部，则服务器应关闭该持久连接
  c. 就算报文中不包含Connection: close首部，客户端和服务器也可以根据需要关闭持久连接
  d. 若客户端不想在连接上发送其他请求，应该在最后一个请求中发送一个Connection: close请求首部
  e. 只有连接上的报文都有正确的、自定义长度时，连接才能持久保持
  f. HTTP/1.1的代理必须能够分别管理与客户端和服务器的持久连接，每个持久连接也只适用于一跳传输
  g. HTTP/1.1的代理不应与HTTP/1.0客户端建立持久连接。(因为老的代理只会转发Connection首部)
  h. HTTP/1.1应用程序必须能够从异步的关闭中恢复
  i. 除非重复发起请求会产生副作用，否则就算客户端收到整条响应之前连接关闭了，也应要重新发起请求
  j. 一个用户客户端对任何服务器或代理最多只能维护两条持久连接，以防止服务器过载

管道化连接

  串行连接：连接1 => 请求1 => 响应1=> 连接2 => 请求2 => 响应2 => 关闭1
  并行连接：
        连接1 => 请求1 => 响应1 => 关闭1
        连接2 => 请求2 => 响应2 => 关闭1
  持久连接：
        连接 => 请求1 => 响应1 => 请求2 => 响应2 => 关闭
  管道化持久连接：
        连接
          请求1 => 响应1
            请求2 => 响应2
        关闭

连接关闭

a. 幂等：不管是执行一次还是很多次，得到的结果都相同，这个事物就是幂等的。如：GET、HEAD、PUT、DELETE、TRACE、OPTIONS等
b. 非幂等：执行多次后结果不一样。如：POST
c. 客户端、服务器可以也可能意外的关闭连接，客户端和服务器都应做好正确处理非预期关闭的准备，除非有副作用，否则客户端应该发起重试。
d. 全关闭：
e. 半关闭：
f. 正常关闭：关闭输出信道 => 对方关闭输出信道 => 关闭输入信道
      然而，实际上无法确保对等实体会实现半关闭，因此，正常关闭连接的应用程序应先半关闭其输出信道，然后周期性地检查其输入信道的状态(查找数据或流的末尾)。如果一定的时间区间内对端没有关闭输入信道，应用程序也可以强制关闭连接，以节省资源。

推荐阅读更多精彩内容