长连接&短连接

	长连接	短连接
浅聊背景	连接是针对传输层TCP协议而言，UDP无连接 在网络应答请求时，客户端与服务器端之间必须建立一个连接，当网络请求完成之后，双方就不再需要这个连接时就可以将连接释放。 「三次握手四次挥手」
定义	在一个连接上可以连续发送多个数据包	在数据传送过程中，只在需要发送数据时，才去建立一个连接，数据发送完成后，则断开此连接
原理 [TCP层]	整个通讯的过程client和server只用一个Socket，在一个连接上可以进行多次请求响应	每次client向Socket发送请求都会新建一个Socket
优势	服务端与客户端可以更实时的进行消息交互 在多次通信中可以省去连接建立和关闭连接的开销，并且从总体上来看，进行多次数据传输的总耗时更少	管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段
缺点	需要花费额外的精力来保持这个连接一直是可用的 1）资源消耗：长时效Ping/Pong带来的流量影响、CPU消耗 2）保底方案：存在bug的关停策略，心跳衰减，重连衰减 客户端超时处理：客户端感知到长连接是连接着的， 但是存在假死的情况	每个连接都需要经过三次握手的过程，耗时大大增加
使用场景	并发量小时频繁操作，多次请求的网络应答响应，而且是一对一，点对点的通信 直播 IM 实时命令下发（如多台设备登录同一账号，1台设备登出，另外两台同步登出）等 数据库的连接（如果使用短连接频繁的应答响应会造成socket报错，同时也会浪费资源）	并发量大，但每个用户无需频繁操作 像淘宝，京东等网站这样频繁的被用户访问，赶上双十一都是上亿规模的访问量，如果使用长连接，每个用户都占用一个TCP连接通道，对服务器压力会很大（端口0～65535）
现有技术	HTTP短、长轮询「特点：被动，通信只能由客户端发起；无状态性；」 优点：方案简单 缺点：无法保证消息的及时性 HTTP1.1 Pipelining（线头阻塞） tcp keep alive vs http keep aliive: TCP Keep Alive 用于探测对端是否存在，而 HTTP Keep Alive 用于协商以复用 TCP 连接。即便一个 TCP 连接未启用 Keep Alive 功能，也不妨碍 HTTP 层面开启长连接。 HTTP2 多路复用 Websocket 优点：解决了http的被动性和无状态性；可以减少轮询带来的流量浪费&对服务的请求压力 自定义TCP（适合IoT）「开发成本高」	HTTP1.0