长连接与短连接：

简介

长连接是指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接； 短连接则是指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接， 其实长连接相较于通常的短连接，是长时间保持客户端与服务端的连接状态。

使用步骤

短连接的使用步骤： 建立连接→数据传输→关闭连接 长连接的使用步骤： 连接→数据传输→保持连接→数据传输→保持连接→……→关闭连接； 所以，这就要求长连接在没有数据通信时，定时发送数据包，以维持连接状态，而短连接在没有数据传输时直接关闭即可。

适用场景

对于长连接来说，无疑可以帮用户省去很多TCP连接建立和关闭操作，从而节约时间。所以对于频繁请求资源的客户来说，比较适合用长连接，在长连接的应用场景下，客户端一般不会主动关闭它们之间的连接，客户端与服务端之间的连接如果一直不关闭的话，随着客户端连接越来越多，服务端的性能会受到影响；对于短连接来说，不需要考虑这个问题，因为存在的连接都是有用的连接，但是如果客户请求频繁，那么在TCP的建立和关闭操作上会浪费较多的时间和带宽。 所以长连接适用于请求频繁且连接数不能太多的场景，例如数据库连接；而短连接适用于并发量大且每个客户端不会频繁操作的场景，例如网站的http服务。

当k8s遇上长连接：

问题描述

在k8s中，提供了两种方式来部署应用程序：Services和Deployments，其中： Deployments描述了需要运行的应用程序的副本数量，每一个应用程序部署为一个pod，并为其分配一个IP地址； Services则类似于负载均衡器，其旨在将流量分配到一组Pod。如下图所示，可以将Services理解成是一个IP地址集合,每次对Services发出请求时，都会从这个集合中选择其中一个IP地址并将其作为目标地址。客户端发出请求时，无需知道后端服务连接了多少个pod，也不需要知道后端pod的IP地址， 只需要将请求发送到IP地址不变的后端Services地址即可。 但是对与Services来说，其负载均衡策略存在一个问题：在客户端和其中一个后端pod建立连接后，如果这个连接没有断开，客户端就不会再和其他pod建立连接，也就是说Services事实上并没有实现真正意义上的负载均衡，后端pod从而也就失去了横向扩展的能力。

解决方案