TCP长连接/HTTP长连接/HTTP长（短）轮询

TCP长连接/HTTP长连接/HTTP长轮询

TCP长连接 VS HTTP长连接

TCP长连接和HTTP长连接是两个相关但概念上有所区别的技术。

TCP长连接

TCP（Transmission Control Protocol）是互联网传输层的一个面向连接的协议，它提供可靠的数据传输服务。在TCP连接中，长连接是指客户端和服务器建立连接后，不立即断开，而是持续保持这个连接，以便后续的数据传输。这种模式适用于那些需要频繁、持续地交换数据的应用场景，比如数据库连接、即时通讯等。长连接减少了反复建立和断开连接的开销（每次连接建立需要三次握手，断开需要四次挥手），提高了通信效率。然而，它也占用连接资源，如果连接数量过多，可能会导致资源耗尽。

HTTP长连接

HTTP协议是基于TCP之上的应用层协议。在HTTP/1.0中，默认使用短连接，即每次请求完成后都会关闭TCP连接。但从HTTP/1.1开始，默认启用了Keep-Alive功能，实现了HTTP长连接。这意味着客户端和服务器之间的TCP连接在完成一个请求响应周期后不会立即关闭，而是可以被重用来发送额外的请求和接收响应，直到达到预设的超时时间或者任意一端显式关闭连接。HTTP长连接减少了建立和关闭TCP连接的频率，对于需要加载多个资源（如图片、脚本文件等）的网页来说，能够显著提升页面加载速度，因为它避免了为每个资源重复建立TCP连接的过程。

区别总结

层次不同：TCP长连接是传输层的概念，关注的是底层数据传输通道的持续性；而HTTP长连接是应用层的概念，利用了TCP长连接的特性来优化HTTP请求响应过程。
目的不同：TCP长连接主要目的是减少连接建立和拆除的开销，适用于任何需要长期数据交换的场景；HTTP长连接则专注于提高Web内容加载效率，特别是在单个网页涉及多个元素下载的情况下。
管理方式不同：TCP连接的生命周期由TCP协议栈和应用程序逻辑共同管理；而HTTP长连接的生命周期除了TCP的管理外，还受到HTTP头部字段（如Connection）和服务器配置的直接影响。

综上所述，TCP长连接是基础通信层面的连接保持机制，而HTTP长连接是在此基础之上，针对HTTP协议特性的优化措施。

HTTP长连接 VS HTTP长轮询

HTTP长连接和HTTP长轮询不是完全一样的概念，它们都是为了实现客户端与服务器之间的实时通信而采用的技术，但实现方式和目的有所不同。

HTTP长连接 (Keep-Alive)：

在HTTP/1.1中引入了Keep-Alive功能，允许在一个TCP连接上发送多个HTTP请求和响应，而不是为每个请求建立一个新的连接。这减少了建立和关闭连接的开销，提高了效率。
长连接默认情况下会有一个超时设置，如果在这个时间内没有新的请求发出，连接会被关闭。
客户端和服务器之间并没有持续的数据传输，除非客户端主动发起请求，服务器才响应数据。

HTTP长轮询 (Long Polling)：

是一种模拟实时通信的技术，客户端发送一个请求到服务器，服务器并不会立即响应，而是等待有新的数据可用时才将响应发送回客户端。
在这个等待过程中，连接是保持打开状态的，一旦有数据可提供，连接就会关闭，客户端收到数据后通常会立即发起新的长轮询请求来继续监听后续数据。
长轮询相比传统轮询减少了无意义的空请求，提高了效率，但仍然存在一定的延迟，且保持连接的时间较长可能会消耗较多的服务器资源。

总结来说，长连接主要是为了复用TCP连接，减少连接建立和断开的开销；而长轮询是一种实现数据推送的机制，通过延长单个请求的响应时间来达到近似实时的效果。两者都可以提升通信效率，但针对的场景和解决问题的侧重点不同。

HTTP短轮询和长轮询

概览

在短轮询和长轮询两种情况下，客户端与服务器之间的交互逻辑有着本质的不同，主要体现在请求的频率、服务器响应的时机以及连接的管理上。

短轮询处理逻辑

客户端逻辑：客户端按照预设的时间间隔（如每5秒），主动向服务器发送请求，询问是否有新的数据更新。
服务器逻辑：服务器收到请求后，即时查询数据。不论数据是否有变更，都会立即响应客户端，返回当前的数据状态或一个指示无更新的信息。
客户端响应处理：客户端收到响应后，根据响应内容决定是否更新界面或采取其他动作。之后，客户端继续按照设定的间隔重复发送请求。

长轮询处理逻辑

客户端逻辑：客户端发起请求到服务器，请求建立后并不立即关闭，而是保持连接开放，等待服务器响应。
服务器逻辑：服务器接收到请求后，如果当前没有新数据，不会立即回复客户端，而是将这个请求挂起。一旦有新数据产生，服务器立即向已挂起的请求发送数据作为响应。（一旦服务器端的数据发生变化或到了预设的超时时间，服务器就会立即向这个已等待的客户端发送响应，这个响应包含了更新的数据。）
客户端响应处理：客户端收到服务器响应（含有新数据）后，处理数据并更新界面。随后，为了持续监听新数据，客户端通常会立即或稍后发起一个新的长轮询请求，重复上述过程。

主要差异总结

请求频率：短轮询固定周期发送请求，频繁且规律；长轮询在无新数据时不发送请求，减少了不必要的网络通信。
资源消耗：短轮询频繁建立和销毁连接，消耗更多资源；长轮询利用单个连接长时间保持，降低了资源开销。
实时性：长轮询在数据更新时响应更快，因为它不需要等待下一个轮询周期，实时性优于短轮询。
实现复杂度：长轮询在服务器端需要维护连接状态和数据推送机制，实现相对复杂；短轮询逻辑简单，易于实现。

长轮询的优势在于能够以相对较低的技术门槛实现实时性较高的数据交互，且兼容性好，几乎所有现代浏览器和服务器都能支持。但其缺点包括增加了服务器的负担（需要维护大量可能长时间开放的连接）、延迟相比WebSocket等双向通信技术更高，以及在高并发情况下可能的资源消耗问题。

随着WebSocket技术的普及，长轮询在某些场景下已被替代，但依然在一些对实时性要求不是极高且需要兼容老版浏览器的环境中使用。

示例

HTTP短轮询示例

短轮询是最基础的实现实时数据更新的方法，客户端定期向服务器发送请求查询是否有新数据。

应用场景：假设一个股票行情展示网站，用户希望页面上的股价能自动刷新。

前端JavaScript示例：

 1 function pollStockPrice() {
 2     fetch('/api/stockprice')
 3         .then(response => response.json())
 4         .then(data => {
 5             // 更新UI
 6             document.getElementById('stock-price').innerText = data.price;
 7         })
 8         .catch(error => console.error('Error:', error))
 9         .finally(() => {
10             // 每隔5秒再次查询
11             setTimeout(pollStockPrice, 5000);
12         });
13 }
14 
15 // 启动短轮询
16 pollStockPrice();

后端伪代码示例

// 假设使用Spring框架的Controller处理请求
@RestController
public class ShortPollingController {

    @GetMapping("/shortPoll")
    public ResponseEntity<String> shortPoll() {
        // 模拟从数据库或其他服务获取数据
        String data = fetchDataFromSource();
        
        // 不管数据是否变化都直接响应
        return ResponseEntity.ok(data);
    }
    
    private String fetchDataFromSource() {
        // 这里简化处理，实际应用中可能是数据库查询等操作
        return "Current Data"; // 返回当前数据状态
    }
}

HTTP长轮询示例

长轮询则是在服务器没有新数据时，保持连接不立即结束，直到有新数据才响应给客户端。

应用场景：同样以股票行情展示为例，但这次我们使用长轮询提高效率。