HTTP长链接和短链接
1. HTTP协议与TCP/IP协议的关系数据库
HTTP的长链接和短链接本质上是TCP长链接和短链接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠的传递数据包，使在网络上的另外一端收到发端发出的全部包，而且顺序与发出顺序一致。TCP有可靠，面向链接的特色。后端
2. 如何理解HTTP协议是无状态的浏览器
HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和你以前打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向链接的协议，无状态不表明HTTP不能保持TCP链接，更不能表明HTTP使用的是UDP协议（无链接）。服务器
3. 什么是长链接、短链接？网络
在HTTP/1.0中，默认使用的是短链接。也就是说，浏览器和服务器每进行一次HTTP操做，就创建一次链接，但任务结束就中断链接。若是客户端浏览器访问的某个HTML或其余类型的 Web页中包含有其余的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会创建一个HTTP会话。并发
但从 HTTP/1.1起，默认使用长链接，用以保持链接特性。使用长链接的HTTP协议，会在响应头有加入这行代码：socket
Connection:keep-alive
|
在使用长链接的状况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP链接不会关闭，若是客户端再次访问这个服务器上的网页，会继续使用这一条已经创建的链接。Keep-Alive不会永久保持链接，它有一个保持时间，能够在不一样的服务器软件（如Apache）中设定这个时间。实现长链接要客户端和服务端都支持长链接。网站
HTTP协议的长链接和短链接，实质上是TCP协议的长链接和短链接。
3.1 TCP链接spa
当网络通讯时采用TCP协议时，在真正的读写操做以前，server与client之间必须创建一个链接，当读写操做完成后，双方再也不须要这个链接 时它们能够释放这个链接，链接的创建是须要三次握手的，而释放则须要4次握手，因此说每一个链接的创建都是须要资源消耗和时间消耗的code
经典的三次握手示意图：
经典的四次握手关闭图：
3.2 TCP短链接
咱们模拟一下TCP短链接的状况，client向server发起链接请求，server接到请求，而后双方创建链接。client向server 发送消息，server回应client，而后一次读写就完成了，这时候双方任何一个均可以发起close操做，不过通常都是client先发起 close操做。为何呢，通常的server不会回复完client后当即关闭链接的，固然不排除有特殊的状况。从上面的描述看，短链接通常只会在 client/server间传递一次读写操做
短链接的优势是：管理起来比较简单，存在的链接都是有用的链接，不须要额外的控制手段
3.3 TCP长链接
接下来咱们再模拟一下长链接的状况，client向server发起链接，server接受client链接，双方创建链接。Client与server完成一次读写以后，它们之间的链接并不会主动关闭，后续的读写操做会继续使用这个链接。
首先说一下TCP/IP详解上讲到的TCP保活功能，保活功能主要为服务器应用提供，服务器应用但愿知道客户主机是否崩溃，从而能够表明客户使用资源。若是客户已经消失，使得服务器上保留一个半开放的链接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务 器端检测到这种半开放的链接。
若是一个给定的链接在两小时内没有任何的动做，则服务器就向客户发一个探测报文段，客户主机必须处于如下4个状态之一：
- 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。
- 客户主机已经崩溃，而且关闭或者正在从新启动。在任何一种状况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每一个间隔75秒。若是服务器没有收到一个响应，它就认为客户主机已经关闭并终止链接。
- 客户主机崩溃并已经从新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个链接。
- 客户机正常运行，可是服务器不可达，这种状况与2相似，TCP能发现的就是没有收到探查的响应。
3.4 长链接短链接操做过程
短链接的操做步骤是：
创建链接——数据传输——关闭链接...创建链接——数据传输——关闭链接
长链接的操做步骤是：
创建链接——数据传输...（保持链接）...数据传输——关闭链接
4. 长链接和短链接的优势和缺点
由上能够看出，长链接能够省去较多的TCP创建和关闭的操做，减小浪费，节约时间。对于频繁请求资源的客户来讲，较适用长链接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP链接的存活，属于比较斯文的作法，遇到恶意的链接时，保活功能就不够使了。在长链接的应用场景下，client端通常不会主动关闭它们之间的链接，Client与server之间的链接若是一直不关闭的话，会存在一个问题，随着客户端链接愈来愈多，server迟早有扛不住的时候，这时候server端须要采起一些策略，如关闭一些长时间没有读写事件发生的链接，这样可 以免一些恶意链接致使server端服务受损；若是条件再容许就能够以客户端机器为颗粒度，限制每一个客户端的最大长链接数，这样能够彻底避免某个蛋疼的客户端连累后端服务。
短链接对于服务器来讲管理较为简单，存在的链接都是有用的链接，不须要额外的控制手段。但若是客户请求频繁，将在TCP的创建和关闭操做上浪费时间和带宽。
长链接和短链接的产生在于client和server采起的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。
5. 何时用长链接，短链接？
长链接多用于操做频繁，点对点的通信，并且链接数不能太多状况，。每一个TCP链接都须要三步握手，这须要时间，若是每一个操做都是先链接，再操做的话那么处理速度会下降不少，因此每一个操做完后都不断开，次处理时直接发送数据包就OK了，不用创建TCP链接。例如：数据库的链接用长链接， 若是用短链接频繁的通讯会形成socket错误，并且频繁的socket 建立也是对资源的浪费。
而像WEB网站的http服务通常都用短连接，由于长链接对于服务端来讲会耗费必定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的链接用短链接会更省一些资源，若是用长链接，并且同时有成千上万的用户，若是每一个用户都占用一个链接的话，那可想而知吧。因此并发量大，但每一个用户无需频繁操做状况下需用短连好。