TCP长连接与短连接的区别

TCP长连接与短连接的区别

TCP/IP，http，socket，长连接，短连接——小结

HTTP的长连接和短连接

http响应头首部Content-Length

 HTTP协议Keep-Alive模式详解和HTTP头字段总结

HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成 之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

 

 

http 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；http 1.1中默认启用Keep-Alive，如果加入"Connection: close "，才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。

 

1. TCP连接

 

当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的

 

 

2. TCP短连接

 

我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作

短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段

 

连接->传输数据->关闭连接

    HTTP是无状态的，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。

    也可以这样说：短连接是指SOCKET连接后发送后接收完数据后马上断开连接。

    

 

3.TCP长连接

 

接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

长连接：

     连接->传输数据->保持连接 -> 传输数据-> 。。。 ->关闭连接。

    长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差

 

    

长连接的数据传输完成识别

    使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：

    1是判断传输数据是否达到了Content-Length指示的大小；

    2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。  

=====================================================

Content-Length 实体的大小

Content-Length首部指示出报文实体主体的字节大小，这个大小是包含了所有内容编码的。比如对文本文件进行了gzip压缩的话，Content-Length首部就是压缩后的大小，而不是原始大小。

 

另外Content-Length首部对于长连接是必不可少的，长连接代表在连接期间会有多个http请求响应在排队，而服务器不能够关闭连接，客户端只能通过Content-Length知道一条报文在哪里结束，下一条报文在哪里开始。

 

除非使用了分块编码Transfer-Encoding: chunked，否则响应头首部必须使用Content-Length首部。 [摘自http权威指南]

 

传输编码和分块编码

分块编码把「报文」分割成若干个大小已知的块，块之间是紧挨着发送的，这样就不需要在发送之前知道整个报文的大小了。（也意味着不需要写回Content-Length首部了）

 

当使用持久连接时，在服务器写主体之前，必须知道它的大小并在Content-Length首部中发送。如果服务器动态创建内容，可能在发送之前无法知道主体大小，分块编码就是为了解决这种情况。服务器把主体逐块发送，说明每一块的大小。服务器再用大小为0的块作为结束块。，为下一个响应做准备。

 

再回过头看请求file文件服务器的图片时响应头的首部信息发现了这个首部：Transfer-Encoding: chunked

 

 

这也说明了这个图片请求的响应是采用分块编码的传输方式，采用这种传输方式进行响应时，没必要带上Content-Length这个首部信息。因为即使带上了也是不准确的。再回过头看上述file图片的响应头中确实没有Content-Length首部。

=====================================================   

 

 

在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

 

那什么时候用短连接呢？

 一般长连接用于少数client-end   to server-end的频繁的通信，例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

 而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源。

     

    

WebSocket 的实现分为客户端和服务端两部分，客户端（通常为浏览器）发出 WebSocket 连接请求，服务端响应，实现类似 TCP 握手的动作，从而在浏览器客户端和 WebSocket 服务端之间形成一条 HTTP 长连接快速通道。两者之间后续进行直接的数据互相传送，不再需要发起连接和相应。