什么是 HTTP 长轮询？
Web 应用程序开始是围绕客户端/服务器模型开发的，其中 Web 客户端始终是业务的发起者，向服务器恳求数据。因而，没有任何机制可以让服务器在没有客户端先宣布恳求的情况下独登时向客户端发送或推送数据。
为了克服这个缺陷，Web 应用程序开发人员可以实施一种称为 HTTP长轮询的技能，其中客户端轮询服务器以恳求新信息。服务器坚持恳求翻开，直到有新数据可用。一旦可用，服务器就会呼应并发送新信息。客户端收到新信息后，当即发送另一个恳求，重复上述操作。
什么是 HTTP 长轮询？
那么，什么是长轮询？HTTP 长轮询是规范轮询的一种变体，它模仿服务器有效地将音讯推送到客户端（或浏览器）。
长轮询是最早开发的允许服务器将数据“推送”到客户端的技能之一，而且因为其寿命长，它在所有浏览器和 Web 技能中简直无处不在。即便在一个专门为耐久双向通讯规划的协议（例如 WebSockets）的年代，长轮询的才能依然作为一种无处不在的回退机制占有一席之地。
HTTP 长轮询怎么作业？
要了解长轮询，首先要考虑运用 HTTP 的规范轮询。
“规范”HTTP 轮询
HTTP 轮询由客户端（例如 Web 浏览器）组成，不断向服务器恳求更新。
一个用例是想要重视快速发展的新闻报道的用户。在用户的浏览器中，他们已经加载了网页，并期望该网页跟着新闻报道的展开而更新。完结这一点的一种方法是浏览器重复询问新闻服务器“内容是否有任何更新”，然后服务器将以更新作为呼应，或者如果没有更新则给出空呼应。浏览器恳求更新的速率决议了新闻页面更新的频率——更新之间的时刻过长意味着重要的更新被延迟。更新之间的时刻太短意味着会有很多“无更新”呼应，然后导致资源浪费和功率低下。
上图：Web 浏览器和服务器之间的 HTTP 轮询。服务器向当即呼应的服务器宣布重复恳求。
这种“规范”HTTP 轮询有缺陷：
- 更新恳求之间没有完美的时刻间隔。恳求总是要么太频频（功率低下）要么太慢（更新时刻比要求的要长）。
- 跟着规划的扩大和客户端数量的添加，对服务器的恳求数量也会添加。因为资源被无目的运用，这可能会变得低效和浪费。
HTTP 长轮询解决了运用 HTTP 进行轮询的缺陷
- 恳求从浏览器发送到服务器，就像曾经一样
- 服务器不会封闭衔接，而是坚持衔接翻开，直到有数据供服务器发送
- 客户端等候服务器的呼应。
- 当数据可用时，服务器将其发送给客户端
- 客户端当即向服务器宣布另一个 HTTP 长轮询恳求
上图：客户端和服务器之间的 HTTP 长轮询。请注意，恳求和呼应之间有很长的时刻，因为服务器会等候直到有数据要发送。
这比常规轮询更有功率。
- 浏览器将始终在可用时接收最新更新
- 服务器不会被永远无法满意的恳求所搞垮。
长轮询有多长时刻？
在实际国际中，任何与服务器的客户端衔接最终都会超时。服务器在呼应之前坚持衔接翻开的时刻取决于几个因素：服务器协议完结、服务器体系结构、客户端标头和完结（特别是 HTTP Keep-Alive 标头）以及用于发动的任何库并坚持衔接。
当然，许多外部因素也会影响衔接，例如，移动浏览器在 WiFi 和蜂窝衔接之间切换时更有可能暂时断开衔接。
通常，除非您可以控制整个架构堆栈，否则没有单一的轮询持续时刻。
运用长轮询时的注意事项
在您的应用程序中运用 HTTP 长轮询构建实时交互时，需求考虑几件工作，无论是在开发方面还是在操作/扩展方面。
- 跟着运用量的增长，您将怎么编列实时后端？
- 当移动设备在WiFi和蜂窝网络之间快速切换或失去衔接，IP地址发生变化时，长轮询会自动从头建立衔接吗？
- 通过长轮询，您能否管理音讯队列并怎么处理丢失的音讯？
- 长轮询是否供给跨多个服务器的负载平衡或故障搬运支撑？
在为服务器推送构建具有 HTTP 长轮询的实时应用程序时，您必须开发自己的通讯管理系统。这意味着您将负责更新、维护和扩展您的后端基础设施。
服务器性能和扩展
运用您的解决方案的每个客户端将至少每 5 分钟发动一次与您的服务器的衔接，而且您的服务器将需求分配资源来管理该衔接，直到它准备好满意客户端的恳求。一旦完结，客户端将当即从头发动衔接，这意味着实际上，服务器将需求可以永久分配其资源的一部分来为该客户端供给服务。当您的解决方案超出单个服务器的才能而且引进负载平衡时，您需求考虑会话状况——怎么在服务器之间共享客户端状况？您怎么应对衔接不同 IP 地址的移动客户端？您怎么处理潜在的拒绝服务进犯？
这些扩展挑战都不是 HTTP 长轮询独有的，但协议的规划可能会加剧这些挑战——例如，您怎么区分多个客户端宣布多个真正的连续恳求和拒绝服务进犯？
音讯排序和排队
在服务器向客户端发送数据和客户端发起轮询恳求之间总会有一小段时刻，数据可能会丢失。
服务器在此期间要发送给客户端的任何数据都需求缓存起来，并在下一次恳求时传递给客户端。
然后出现几个明显的问题：
- 服务器应该将数据缓存或排队多长时刻？
- 应该怎么处理失利的客户端衔接？
- 服务器怎么知道同一个客户端正在从头衔接，而不是新客户端？
- 如果从头衔接花费了很长时刻，客户端怎么恳求落在缓存窗口之外的数据？
所有这些问题都需求 HTTP 长轮询解决方案来答复。
设备和网络支撑
如前所述，因为 HTTP 长轮询已经存在了很长时刻，它在浏览器、服务器和其他网络基础设施（交换机、路由器、署理、防火墙）中简直得到了无处不在的支撑。这种级别的支撑意味着长轮询是一种很好的后备机制，即便对于依赖更现代协议（如 WebSockets )的解决方案也是如此。
众所周知，WebSocket 完结，尤其是早期完结，在两层 NAT 和某些 HTTP 长轮询运转良好的署理环境中挣扎。
