TCP和UDP详解1:https://developer.aliyun.com/article/1473423
TCP 短连接和长连接的区别
短连接
短连接：
Client 向 Server 发送消息，Server 回应 Client，然后一次读写就完成了，这时候双方任何一个都可以发起 close 操作，不过一般都是 Client 先发起 close 操作。短连接一般只会在 Client/Server 间传递一次读写操作。
短连接的优点：管理起来比较简单，建立存在的连接都是有用的连接，不需要额外的控制手段。
长连接
长连接：
Client 与 Server 完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
在长连接的应用场景下，Client 端一般不会主动关闭它们之间的连接，Client 与 Server 之间的连接如果一直不关闭的话，随着客户端连接越来越多，Server 压力也越来越大，这时候 Server 端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致 Server 端服务受损；如果条件再允许可以以客户端为颗粒度，限制每个客户端的最大长连接数，从而避免某个客户端连累后端的服务。
长连接和短连接的产生在于 Client 和 Server 采取的关闭策略，具体的应用场景采用具体的策略。
TCP粘包、拆包及解决办法
什么是粘包、拆包？
假设 Client 向 Server 连续发送了两个数据包，用 packet1 和 packet2 来表示，那么服务端收到的数据可以分为三种情况，现列举如下：
- 第一种情况，接收端正常收到两个数据包，即没有发生拆包和粘包的现象。
- 第二种情况，接收端只收到一个数据包，但是这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。
- 第三种情况，这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。
为什么会发生TCP粘包、拆包？
要发送的数据大于 TCP 发送缓冲区剩余空间大小，将会发生拆包。
待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包。
要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。
接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
粘包、拆包解决办法
由于 TCP 本身是面向字节流的，无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决，根据业界的主流协议的解决方案，归纳如下：
消息定长：发送端将每个数据包封装为固定长度（不够的可以通过补 0 填充），这样接收端每次接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
设置消息边界：服务端从网络流中按消息边界分离出消息内容。在包尾增加回车换行符进行分割，例如 FTP 协议。
将消息分为消息头和消息体：消息头中包含表示消息总长度（或者消息体长度）的字段。
更复杂的应用层协议比如 Netty 中实现的一些协议都对粘包、拆包做了很好的处理。
为什么常说TCP有粘包和拆包的问题而不说UDP？
由前两节可知，UDP 是基于报文发送的，UDP首部采用了 16bit 来指示 UDP 数据报文的长度因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。
而 TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 并没有把这些数据块区分边界，仅仅是一连串没有结构的字节流；另外从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段，基于上面两点，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。
TCP 可靠传输
TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。
一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT，加权平均往返时间 RTTs 计算如下：
其中，0 ≤ a ＜ 1，RTTs 随着 a 的增加更容易受到 RTT 的影响。超时时间 RTO 应该略大于 RTTs，TCP 使用的超时时间计算如下：
其中 RTTd 为偏差的加权平均值。
TCP 流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
实际上，为了避免此问题的产生，发送端主机会时不时的发送一个叫做窗口探测的数据段，此数据段仅包含一个字节来获取最新的窗口大小信息。
TCP 拥塞控制
如果网络出现拥塞，分组将会丢失，此时发送方会继续重传从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。
TCP怎么解决拥塞控制
TCP 主要通过四个算法来进行拥塞控制：
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
拥塞窗口与发送方窗口的区别
拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。
提供网络利用率
- Nagle 算法
- 发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送的一种处理机制。具体来说，就是仅在下列任意一种条件下才能发送数据。如果两个条件都不满足，那么暂时等待一段时间以后再进行数据发送。
已发送的数据都已经收到确认应答。
可以发送最大段长度的数据时。
延迟确认应答
接收方收到数据之后可以并不立即返回确认应答，而是延迟一段时间的机制。
在没有收到 2*最大段长度的数据为止不做确认应答。
其他情况下，最大延迟 0.5秒 发送确认应答。
TCP 文件传输中，大多数是每两个数据段返回一次确认应答。
捎带应答
在一个 TCP 包中既发送数据又发送确认应答的一种机制，由此，网络利用率会提高，计算机的负荷也会减轻，但是这种应答必须等到应用处理完数据并将作为回执的数据返回为止。
