查字典图书网
查字典图书网
这一节要讲的大部分内容，对HTML5 数据推送技术（SSE 和WebSocket）和将在第6 章、第7 章讲到的向后兼容解决方案都适用，它们的共同点在于，都会为每一个客户端连接打开一个专门的套接字。 首先来考虑静态的情况，不引入数据推送。每当用户打开一个页面，在浏览器和服务器之间就会打开一个套接字连接。服务器收集信息然后返回给用户，可能会很简单，就像从磁盘上加载一个静态HTML 文件或一张图片一样；也可能会很复杂，就像要运行一段用以连接很多数据库的后端语言，将CoffeeScript 编译成JavaScript，然后把它们结合到一起（用一个服务端模板）并返回。这里的关键点是，一旦返回了所需的信息，套接字就会关闭8。每个HTTP 请求都会打开一个这种生命期相对较短的套接字连接，但这些套接字是服务器上的有限资源，每当它们完成既定任务，就会被回收以循环再利用。这真是相当环保啊，居然没有政府部门给它捐款。 现在对比看一下数据推送。一个请求永远不会完成：总是有更多信息要发送，所以套接字会一直保持打开状态。显然，因为它们是有限的资源9，所以同一时刻的SSE 连接数会有限制。 可以这样想象一下：你在为你最新的一个应用提供电话服务支持，有10 个接线中心员工为1000 个用户提供服务。当一个用户遇到问题并拨打客服电话，其中一个接线员接线，帮他解决问题，然后挂线。闲的时候，一些接线员没有电话可接；忙的时候，全部10 个接线员都在忙而且还有新的客户呼叫在排队，直到其中有一个接线员挂线。这就是典型的网络服务模式。 但是，现在想象一下你有一个客户打进来并且说：“我现在没有问题，但我在接下来的几个小时会用你们的软件，并且如果遇到问题，我希望能立即答复，并且不会有被搁置的风险，所以，请问您可以就这样保持电话畅通吗？”如果你提供这项服务，而这位客户没有问题要问，那么在与他保持通话的那几个小时，呼叫中心10% 的服务资源就浪费了。如果10 个客户这样做，其他990 位客户就无法呼叫了。这就是数据推送模式。 但这并不总是坏事，想象一下，如果那个用户一下午每隔几秒钟就有一个问题。这种情况下保持电话畅通不但没有浪费10% 的服务资源，反而会增加。如果他每个问题都要重新打一个电话（就像数据拉取），想一下接线员花在接线、验证客户身份、调出他账户的时间，甚至还有在通话结束时礼貌性地说再见的时间。如果他每次呼叫都是由不同的接线员接线，他们还要花点时间聊一下问题背景之类的，这也会降低服务效率。而保持电话畅通不仅使你的客户更满意，也会提高你呼叫中心的工作效率。这是数据推送模式最适合的场景。 前面提到的外汇价格的例子就很适合用SSE 来做，有大量的价格变化，并且低延迟很重要：用户只能以当前的价格交易，而不是60 秒以前的。另一方面，考虑一下大范围的天气预报，气象局会每半小时发布一次最新的天气预报，但多数时候天气不是从“晴”变成别的，并且延迟也不是很重要的问题。如果天气预报员播报的天气预报，不是从“晴”变成“多云”，那这则天气预报真的有意义吗？这是否值得保持一个套接字一直打开，或者每30 分钟或60 分钟直接从气象服务器拉取（数据拉取）就足够了？ 那有什么是发生频率不高但又需要关心延迟问题的事件呢？假如政府将在上午8:30 发布关于经济增长的公告，我们希望在发布时立刻将公告更新到我们的网络应用上，要怎么做？ 这种情况，最好是设置一个计时器，在公告即将发布之前调用一个Ajax 长轮询（见第6章）。提前几个小时或者几天保持一个套接字一直打开是一种浪费。 一种类似的情况是可预见的停工时刻，回到接收实时外汇价格的例子，没有必要在周末还保持连接，应该在周五下午5 点（纽约当地时间）关闭连接，并且设置一个定时器在周日下午5 点重新打开。如果服务器是建立在一个运行即收费的云服务上的，那这意味着可以在周五晚上关闭一些服务请求，这可以节省大概28% 的开支！参阅5.4 节 。 注8： 事实上大部分请求使用HTTP 持久连接，它会共享第一个HTTP 请求和图片之间的套接字，这个连接会在停止活跃几秒（Apache 2.2 中是5 秒）后关闭。提到这个只是为了解释清楚，并不影响普通网络方案和数据推送方案的比较。 注9： 多少限制呢？这取决于服务器操作系统，可能是每个IP 地址60 000 个。防火墙或负载均衡器也可能会做一些限制。服务器的内存也是个关键因素。这个问题很不好说，所以我的建议是在实际使用的操作系统中找出这个限制。