传输层重点协议

---

UDP协议

UDP协议的职责：在网络层的基础之上，实现了进程到进程的通信。
UDP协议段格式：

①定长的包头：容易做解包；
②源端口号+目的端口号：做分用；
③校验和：防止数据错误的，如果数据出现错误，直接丢弃。

UDP的特点

1. 无连接：知道对方的IP的端口号就直接进行传输，不需要建立连接。
2. 不可靠：没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息。
3. 面向数据报：应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。
4. 缓冲区：UDP没有发送缓冲区，但是有接收缓冲区，但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致；如果缓冲区满了，再到达的UDP数据就会被丢弃。
5. 大小受限：UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部）。

基于UDP的应用层协议

• NFS：网络文件系统
• TFTP：简单文件传输协议
• DHCP：动态主机配置协议
• BOOTP：启动协议（用于无盘设备启动）
• DNS：域名解析协议

TCP协议

TCP协议：传输控制协议。
TCP协议段格式：

TCP的可靠性

什么是可靠性？

1. TCP会尽自己最大的努力，将数据发送给对方；
2. 如果真的遇到发送不过去的情况，TCP至少会告诉发送进程，数据发送失败了；
3. 保证不会收到错误的数据（通过校验和）；
4. TCP能保证收到的数据一定是有序的（按照发送进程发送时的顺序）；
5. TCP会根据对方的接收能力和网络线路的承载能力，进行流量的控制；

TCP做了哪些机制来保证可靠性？

确认应答机制

接收方有责任对收到的数据进行确认（ACK）应答

TCP将每个字节的数据都进行了编号，即序列号（SN），每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据、下一次你从哪里开始发。

确认段（segment）：一份数据既可以作为发送数据的角色，也可以作为确认的角色。

• 发送：携带有数据，填写正确的SN
• 确认：标志位ACK置1，代表起到了确认的作用，需要填写确认序列号（ASN）即填写下一次期望收到的数据的第一个字节编号

超时重传机制

1）当发送端发送了一份数据，没有收到应答时，可能发生了什么？
①对方没有收到；
②对方收到了，并且应答了，但应答没有发送过来。

2）当没有收到应答时：
①不应该无期限等下去；
②重新发送数据。

主机A发送数据给B之后，可能因为网络拥堵等原因，数据无法到达主机B，主机B没有收到数据：

如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。

主机B收到了主机A发送的数据，但是ACK丢了：

所以主机B就会收到很多重复的数据，此时TCP协议需要识别哪些包是重复的，并且把重复的包丢弃（利用序列号来识别哪些包是重复的）。

超时重传次数是无限制的吗？
答：有上限，当达到上限时，发送方（TCP）认为本次数据线路出现了重大问题。
解决方法：
①TCP会关闭本次连接
②TCP会通知进程（在Java中，采用异常的方式）
③TCP会发送一个 reset segment 出去

超时时间的设置：
TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间：

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍
• 如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传
• 如果仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增
• 累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接

注意：
作为TCP的发送方，经过一段时间后，是可以知道线路有问题的，但是作为TCP的接收方，是无法得知线路有问题的（无法确认对方是没有数据发送还是发送失败）。

连接管理机制

为什么TCP要设计建立连接？
①必须确认对方存在，才能 “可靠” 的传输
②交换一些必要的数据（SN不是直接从1开始的，会双方各自随机生成，随后需要交换）

在正式进行通信之前，需要一个阶段：
①确认对方在线
②“同步（synchronize）”一些信息

建立连接阶段：

说明：
①2和3基本是同一时间发生的
②TCP的segment可以既承载发送数据，又承载应答的职责
结论：2 和 3 会被合并。

TCP的三次握手过程：

从标志位角度看TCP三次握手：

第三次握手是允许携带数据的

从序列号角度看TCP三次握手：

初识序列号：ISN

从TCP状态变更角度：

CLOSED：虚拟状态
LISTEN：被动连接方服务器已经启动，但没有真正的连接建立
SYN_RCVD：收到了同步信息
SYN_SENT：同步信息已经发送了

当双方都处于 ESTABLISHED 状态时：

①双方地位是完全相等的，谁都可以通过这条连接发送数据，谁都可以通过这条连接接收数据，TCP连接时全双工的。
②
断开连接：

①三次挥手：

②四次挥手

③同时挥手

服务器上出现大量的 CLOSE_WAIT 时什么原因？
①CLOSE_WAIT：出现在挥手阶段
②CLOSE_WAIT：出现在被动关闭方这一侧
③CLOSE_WAIT：对方进程要求关闭连接，但我方进程还没要求关闭连接
通过上面三条分析，原因就是服务器没有正确的关闭 socket，导致四次挥手没有正确完成。这是一个 BUG，只需要加上对应的 close 即可解决问题。

为什么要有一个 TIME_WAIT 状态？

①防止最后一个ACK丢失，A不能保证最后的ACK能达到B，如果最后的ACK丢失， 那么B显然收不到, B于是发起了重传FIN的操作， 此时如果A处于CLOSED的状态， 就没办法给对端发ACK了；
②当TCP关闭连接后，五元组释放，后面新的连接可能会用到这个五元组，此时，新五元组和旧五元组完全一致，所以就要有TIME_WAIT这个状态，让旧的五元组对应的所有网络包都消失（等一段时间），才允许新的五元组建立。

为什么是TIME_WAIT的时间是2MSL？

MSL是TCP报文的最大生存时间，因此TIME_WAIT持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失（否则服务器立刻重启，可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的）；同时也是在理论上保证最后一个报文可靠到达（假设最后一个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK）；

流量控制

什么是流量控制？
流量控制（Flow Control）：TCP支持根据接收端的处理能力，来决定发送端的发送速度。（发送量控制）

为什么要进行流量控制？
接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

TCP的接收缓冲区装的是：接受到的数据&&还没有被应用层读走的数据。
接受能力就是：接受缓冲区还能装多少数据。

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端，发送端接收到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。

如何进行发送量的控制？
发送方的发送量 <= 接收窗口

发送方利用滑动窗口机制进行发送量的控制：

拥塞控制

为什么要引入拥塞控制？
因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

拥塞控制的机制：

TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据。

• 慢开始不是指cwnd的增长速度慢（指数增长），而是指TCP开始发送设置cwnd=1
• 为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限（ssthresh状态变量）
  当cnwd＜ssthresh，使用慢开始算法（指数增长）
  当cnwd=ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
  当cnwd＞ssthresh，使用拥塞避免算法（线性增长）
• 无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。
• 少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞。

提高TCP性能

延迟应答机制：
数据传输的时候，发送端给接收端发送数据，接收端给发送端发去确认应答信息，这样比较耗时，效率低下，延迟应答就是接收端收到数据之后，稍微等一会再应答，这样可以提高数据的传输效率，因为发送端发好几次数据，接收端只需要一次来确认应答，这样可以降低网络拥塞的概率。

捎带应答机制：
虽然有延迟应答，但是客户端和服务器在应用层还是”一发一收”，此时就会导致数据传输效率低下，捎带应答就是接收端在给发送端发送数据的时候，捎带着向发送端发去确认应答，应答的内容是接收端已经收到发送端发送的数据。

快重传机制：
快重传要求，接收者如果接收到一个乱序的分组的话，就返回对前一个正确分组的确认应答，当发送方连续收到三个冗余ACK，就会马上快速重传丢失数据，不必等到超时时间再重传。

TCP异常情况

1、直接使用任务管理器关闭一个进程，被这个进程持有的连接会怎么办？
虽然进程不会执行关闭操作，但OS会执行四次挥手的正常关闭。

2、点击重启，运行着的进程管理的连接会怎么办？
OS会执行四次挥手的正常关闭，点击关机，也是如此。

3、机器掉电/网线断开，进程持有的连接会怎么样？
接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使没有写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在。如果对方不在，也会把连接释放。

粘包问题

什么是粘包问题？
首先要明确，粘包问题中的 “包” ，是指的应用层的数据包。在TCP的协议头中，没有如同UDP一样的 “报文长度” 这样的字段，但是有一个序号这样的字段。站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。站在应用层的角度，看到的只是一串连续的字节数据。那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

怎么解决粘包问题？

• 对于定长的包，保证每次都按固定大小读取即可。
• 对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置。
• 对于变长的包，还可以在包和包之间使用明确的分隔符。

TCP和UDP对比

UDP：不可靠、无连接、面向数据流，用于对高速传输和实时性要求较高的通信领域，例如，早期的QQ，视频传输等。另外UDP可以用于广播。
TCP：可靠、有连接、面向字节流，应用于文件传输，重要状态更新等场景。

---

总结

以上就是今天要讲的内容，本文仅仅简单介绍了传输层的UDP和TCP协议，如果你觉得有收获的话，就留下你的👍吧！