TCP详解（三）

9.面向字节流

在这种面向字节流的情况下，需要注意一个重要问题：粘包问题（指的是应用侧数据报）

针对TCP来说，数据进行传输是如下图所示

但是针对UDP来说，由于UDP面向数据报进行传输的，所以是一条一条进行传输

那么问题来了，如何解决粘包问题呢？

通过设计一个合理的应用层协议来解决！！！

1.给应用层数据设定“结束符” / “分隔符”

2.给应用层数据设定“长度”

方式一：

方式二：

10.TCP中的一些异常情况

常见的异常情况：

（1）进程终止

不管进程是怎么终止的，本质上都会释放对应的PCB，也会释放对应的文件描述符 符，一样会触发四次挥手。

“进程终止”不代表连接就终止，进程中止其实就相当于调用了 socket.close()而已。

（2）机器重启

机器重启的时候，其实也是先杀进程，仍然是进行四次挥手。

（3）机器掉电/网线断开

突发情况！！机器是来不及进行任何动作的

​ <1>掉电的是接收方

此时另外一边还在发送数据，此时显然发送方不会再有ACK！

于是就超时重传，重传几次之后，就会尝试重置连接，复位报文段。再然后发送方就会放弃这个连 接，把连接对应的资源就会回收了。

​ <2>掉电的是发送方

此时另外一方在尝试接收数据，此时接收不到任何数据

接收方如何知道，发送方是挂了？还是说发送方暂时还没发呢？

此时接收方采取的策略，就是“心跳包”机制（也叫做“保活”）

每隔一段时间，向对方发送一个PING包，期待对方返回一个PONG包。

如果PING包已经发送过去，过了河你局还没有PONG，并且重试几次也不行，此时就认为对方已经挂了。

经典面试题

如何基于UDP协议实现可靠传输？

这个题看似是在问UDP，实际上是再考TCP！！！

1.实现确认应答机制，把每个数据接收到之后，大欧要反馈一个ACK（此时这个就不是内核返回的了，而是应用程序自己定义一个ACK包，发送回去）。

2.实现序号/确认序号，以及实现去重。

3.实现超时重传。

---

4.实现连接管理。

5.要想提高效率，实现滑动窗口。

6.为了限制滑动窗口，实现流量控制/拥塞控制。

---

7.实现延时应答，捎带应答，心跳机制……

什么场景中适合使用TCP，什么场景中适合使用UDP？

1.如果需要可靠性，首选TCP。

2.如果床数的单个数据表比较长（超过64K），还是使用TCP。

3.如果特别注重效率，优先考虑UDP。

​ 典型的场景：机房内部的主机间通讯。

4.如果需要广播，优先考虑UDP。

​ 一份数据同时发送给多个主机，UDP自身就支持广播的，但是TCP自身不支持，就只能在应用层程序中通过多个连接，轮询的方式给每个主机发送数据（伪广播）。