在系统中，客户端和服务器一起通信，客户端请求和服务器通过请求的数据响应各自的客户端。现在可以选择需要更新频率的频率了吗?好吧，这一切都取决于您的目的和您的系统。在这里，我们将讨论轮询和流传输这两个基本概念。
轮询
它被定义为以下过程：客户端以固定的时间间隔(也许每x秒)请求特定数据，并且服务器以所需的数据以通常的响应进行还原。
在这些情况下，客户端需要在即时模式下定期更新数据(从服务器获取数据)，轮询可能不会使您的体系结构受益。例：您正在构建一个聊天应用程序，其中有许多旨在实时相互通信的客户端。作为系统设计专家，您需要确保客户端即时获得更新(此处的更新表示聊天，txt，消息)。但是轮询并不适合作为Chatbox的示例，您需要在另一端发送即时消息时获得即时消息，但是由于设置了x秒的间隔，您无法获得即时消息的感觉，并且您的消息会感觉到很多延误
轮询的最佳适应性可能是获取温度更新，例如定期更新30秒/ 1分钟。
流媒体
流是通过套接字完成的，您可以在此处详细了解套接字。用Layman术语来说，套接字是计算机可以与另一台计算机进行长宽度连接时进行写入/读取的文件，该连接是打开的连接，直到一台计算机将其关闭为止。
例如：像WhatsApp / Instagram和其他许多应用程序一样设计聊天应用程序
在这里，您可能会想到减少设置间隔并选择轮询而不是流式传输的选择，也就是说，您可能会考虑将设置间隔减少到1sec / 0.5sec，而不是在10秒内为单个客户端最多请求20个请求，对于数百万的客户而言，这将为我们的服务器同时处理这些请求带来麻烦。在这里，您需要注意，您可能会获得即时的消息体验，但这并不是最佳选择，因为这会给服务器增加更多的负载。
轮询v / s流
关键点：在轮询中，对于服务器的响应，将发送每个请求，但是在流传输中，客户端将在没有来自服务器的外部数据请求的情况下公开侦听。在服务器端，对于流传输，它不会等待数据针对每个请求发送，而是会在注意到任何更改的情况下推送数据。通过流式传输，您可以立即获得即时聊天体验，没有任何延迟，或者每个客户端每秒发送10-20个请求。
情境
如果客户端处理的速度慢于轮询和流传输的情况，则可能会发生不同的情况。
在流式传输中，更新将在客户端上形成一个长长的队列，并且一旦接收到第一个事件，服务器将发送下一个，然后连续发送直到结束，由于处理不善会出现延迟，但是不会。在数据中可能是零星的。
在轮询中，过程将需要一些时间来更新。一旦完成一项，它将要求另一项并立即答复。服务器始终尝试保持健壮并保持流式连接正常运行。如果它不能写，它将等待并可能过滤更新。
注意：流并不比轮询好，轮询可能比流更好，这完全取决于您的用例和系统。
一般规则：如果您需要立即更新数据(实时更新)，那么您想使用流式传输，并且如果您要构建一个仪表板而不是监视股价或这里有这种用例，则您可能更喜欢轮询，因为没有真正需要开放连接，每30秒您可以更新一次数据。