初始JavaEE篇 —— 网络原理---传输层协议：深入理解UDP/TCP

 找往期文章包括但不限于本期文章中不懂的知识点：

个人主页：我要学编程程(ಥ_ಥ)-CSDN博客

所属专栏：JavaEE

目录

UDP协议

参数解析：

校验和的计算 

TCP协议

参数解析：

确认应答机制

超时重传

连接管理

三次握手

四次挥手

滑动窗口

流量控制

拥塞控制

延时应答 

捎带应答

面向字节流

异常情况的处理

剩余参数

---

 

初始JavaEE篇 —— 网络编程（2）：了解套接字，从0到1实现回显服务器-CSDN博客

前面我们通过UDP与TCP的套接字编写了最简单服务器与客户端程序，接下来我们就来深入学习UDP与TCP协议的内容。UDP与TCP协议也是属于传输层中最核心的协议，我们在日常开发中写的程序都是基于传输层的来进行网络通信的。

我们在最开始的网络初始章节，已经了解了UDP与TCP的基本特点：

UDP —— 无连接、不可靠传输、面向数据报、全双工。

TCP —— 有连接、可靠传输、面向字节流、全双工。

UDP协议

下面来详细了解UDP的报文格式，也就是了解报头的内容。

参数解析：

UDP数据报 = UDP数据报头 + 数据载荷。

数据载荷，就是整个应用层数据报。

数据报头：包含了UDP源端口与UDP目的端口、UDP的长度、UDP校验和。报头的总长度是8个字节，分成4部分之后，每个部分占两个字节。

1、UDP源端口与UDP目的端口，指的是通信双方对应的具体应用程序所处的位置。

2、UDP长度是用来表示UDP数据报的整个长度，包括 UDP 报头和 UDP 载荷。UDP长度是两个字节，而它的计量单位是字节，也就是说其本身占两个字节，能表示的数据是 2^16 大小，0 ~ 65535，再加上原本的计量单位是字节，其表示的数据范围就是 0 ~ 65535 的字节，也就是64kb。

3、UDP校验和，也被称为 UDP checksum，这个主要是用来检验数据传输的正确与否的。 

因为信息在通过网络传输的过程中，难免会出现数据丢失或者被篡改的情况，因此数据在被另一方接收时，需要去判断接收到的数据根据校验和算法计算出来的结果是否与数据报中的校验和一致，如果一致就认为传输的数据是没问题的；反之，则认为传输的数据是错误的数据。当然也有可能校验和的结果一致，但是数据不一样，但是出现这种情况还是很小概率事件（例如，比特翻转：传输的数据比特位发生变化，但恰好变化量抵消了，最终计算出的校验和还是不发生变化的），因此就忽略了。

校验和的计算 

那如何使用校验和来完成数据的验证呢？

1）发送方将数据全部整理起来形成data1，通过一定的算法计算出校验和(checksum1)

2）发送方通过网络将数据发送出去，接收方从网络中接收到数据

3）接收方将接收到的数据解析出来，然后再将这些数据整理出来形成data2，再通过相同的算法计算出新的校验和(checksum2)

4）将新的校验和与接收到的校验和进行比较

计算校验和的算法有很多，UDP这里采用的是循环冗余算法，即CRC算法。这个算法是将要传输的数据中的每个字节都进行累加，然后将累加后的结果保存在校验和中。这个算法不是特别靠谱，容易出现误判的情况。

还有另外一种算法：md5算法，通过这个算法计算出来的结果，有以下几个特点：

1）定长。不管原始数据是多大，最终计算出来的结果的长度都是固定的长度，即 16位整数。

2）分散。当两个原始数据的差异性非常小时，只差了一个字符，但是最终计算出来的结果差异性就特别大。这个特性是非常适合作为哈希算法的，因为哈希算法的初衷就是让哈希表中的元素分散，避免哈希冲突的概率，这样即使出现了哈希冲突使用线性探测的方法也是很好解决的（虽然现在的哈希表都是使用数组+链表的方式）。

3）不可逆。原始数据通过 md5 算法计算出结果的过程是非常简单的，而 经过md5算法计算出的结果要想得到原始的数据是非常困难的。这个特性可以运用于加密的场景。

注意：我们前面在使用UDP协议编写服务器与客户端时，是直接将目的端口与目的IP给数据报(DatagramPacket)了，这里的UDP对应的数据报并不是DatagramPacket，后者经过了进一步的封装，因此可以包含IP，IP对应的在网络层。 

以上就是UDP协议的解析了，下面我们来学习传输层中最重要的协议：TCP协议。

TCP协议

TCP协议相较于UDP协议最大的优点就是：可靠传输。 这也是TCP协议被设计出来的初心。

上图是主要展示了TCP报头的信息。 

参数解析：

源端口与目的端口和在UDP中的含义是一样的。

数据偏移（4位首部长度）：这与UDP长度的含义不同，这里只是的TCP数据报头的长度，不包含数据载荷在内。这里的4位指的是4个比特位，表示的范围是 0~15，而其单位是4个字节，也就意味着这个数据报的报头长度最大是60个字节，但是最小并不是0而是20个字节，这些字节是用来表示其他的数据的。剩下的40字节是留给选项用的。

6位保留位是为了避免TCP出现像UDP那样只能存储64kb的情况，其相当于是给了TCP扩展的空间。

16位检验和，这个是与UDP一样的。

剩下的参数我们慢慢来解开它们神秘的面纱。

确认应答机制

可靠传输，不是说发送方能将数据100%的成功发送到接收方，而是 当发送方发送的数据没有到达 接收方时，发送方自己能知晓，并且还能继续重新传输刚才发送的数据。这才叫可靠传输。总结下来，确保以下两点之后，传输就是可靠的了：

1、能够知晓数据是否发送到了；2、即使数据没发送到，但是提供了补救的方法，即重新发送。

TCP是可靠传输，其就可以实现上述功能。

当发送方传输数据给接收方时，如果接收方成功地接收到了数据的话，就会返回一个应答报文，如果发送方也接收到了应答报文的话，就认为这一次传输成功了。

 当然，在进行多次通信的过程中，可能会出现下面这种情况：

因此为了确保信息传送的正确性，TCP就采用了32位序号与32位确认序号的方式。 

从上图可以看出，只有当发送方收到了应答数据报之后，发送方才会发送下一条数据。

 上面是区分普通数据报与应答数据报的区别。

超时重传

那如果数据在传输的过程中，出现了丢包的情况呢？接收方根本就收到不数据，谈何发送应答报文呢？TCP中就有另外一个机制：超时重传。 

超时重传就是为了处理，当发送方将数据发送之后，在传输的过程中，由于某个节点(路由器或者集线器)传输的数据过多，这时就会直接将多余的数据给丢掉，这样接收方就不能接收到发送方法数据，那么其就不会发送应答报文，发送方就会一直处于等待应答的状态。而有了超时重传之后，当发送方在等待一定的时间之后，还是没有接收到应答数据报的话，就会将数据重新进行传输。

注意：

1、只要是在网络上进行传输的数据，都有可能出现丢失的情况。

2、等待时间不是固定的，可以通过操作系统去修改对应的参数，从而改变对应的等待时间。

3、每重传一次，等待时间就会变长，当等待时间超过某个返回之后，就会触发重置连接的操作。

4、极端情况下，拥堵的数据并未被节点给丢弃，恰好被传输了过去，且此时也触发了超时重传，那么在接收方就会收到两条同样的数据，而这些数据都是处于TCP的缓冲区，当应用程序开始进行read操作时，这个缓冲区就会将其中重复的数据给删除，且按照序号的大小将数据重新排序，确保发送的数据不会混乱。

连接管理

连接管理包括建立连接与断开连接。建立连接是三次握手，断开连接是四次挥手。

这里的握手与挥手都是通信双方通过发送一个简单的、无逻辑业务的数据报。

三次握手

三次握手的过程如下所示：

上述看起来是四次握手，其实中间的两次可以合并为1次，因为这两个都只是一个标记位改为1即可，只要将一个数据报的 syn 与 ack 全部置为1即可。 

三次握手的作用：

1、确保当前网络是否处于通畅状态。如果当前网络不行，那么后续的通信肯定也是不行的。

2、确保发送方与接收方都可以确认自己的发送能力与接收能力均正常。

A ---> B 成功，说明此时B的接收能力正常，能够接受到 A的发送信息。

B ---> A 成功，说明此时A的接收能力正常，能够接受B的发送信息，且A的发送信息正常，否则B接收不到信息，也就不会发送信息给A了

A ---> B 成功，说明此时B的发送能力是正常的，能够成功发送信息给A，A才会对其作出反应。

注意：这里我们不能站在上帝视角去看待问题，而是要处于A、B的视角去看待。站在A的视角，A ---> B 成功，A是不能知道它自己的接收能力与发送能力，只有通过B的反应才能得知自己的状态。

3、让通信双方，在握手过程中，针对一些重要的参数，进行协商。例如，确认序号的起始序号是多少。这样可以避免 "前朝的剑，斩本朝的官"，当网络不是很通畅时，可能会导致本次连接中断，从而开始下一次的连接，但是上一次连接时，所传输的数据刚好与此次连接所传输的数据一起到达了TCP的缓冲区（上一次连接因为网络问题，导致传输的数据处于拥堵的状态且恰好没有被丢弃），那怎么区分两者呢？如何是上一次连接传输的数据被丢弃呢？这里就是通过确认序号来辨别的，两次连接时的序号相差是比较大的。

上图描述的是 三次握手 的过程中，客户端 与 服务器的TCP层所处的状态。

上图的 closed 状态 更准确的来说，应该是 程序启动时，而不是机器启动时，但有的程序是随机器自启动的，因此说其是机器启动时，也是没问题的。

四次挥手

四次挥手的过程如下所示：

注意：上面四次挥手，正常情况下，就不能合并为三次挥手了。因为当客户端（或服务器）发送 fin 数据报之后，服务器（或客户端）会立即发送 ack数据报，但是 fin 数据报的发送，还需要看客户端的处理逻辑是啥，即客户端在针对这种情况下的代码是怎么写的，是否还有其他的罗辑要处理。例如，关闭连接资源等操作，这些操作也是需要耗费时间的，因此两者在正常的情况下是不同同时发送的，也就是四次挥手。往细了说，syn 与 ack 数据报都是由操作系统内核发送的（调用的是操作系统内核的API），而 fin数据报 是由应用程序（取决于代码怎么写）来发送的，fin数据报的发送时机是由 socket.close 来触发的。

当收到服务器传来的 fin数据报之后，如果直接变为 closed状态的话，就会出现上图描述的情况，因此得先使其处于 time_wait状态，然后再去等待 超时重传（如果需要），这样就会正常断开。 这个 time_wait 也是主动想断开连接的机器才会有的状态。

前面学习的 确认应答、超时重传、连接管理 都是确保 TCP 传输的可靠性。下面的都是在确保可靠性的基础上，提升传输的效率。

滑动窗口

前面学了确认应答之后，对每一个发送的数据段，都要给一个ACK确认应答.收到ACK后再发送下
一个数据段，这就会严重影响传输的效率。

上述的过程，可以理解为 生产员在生产一个产品之后，就交给检测人员检查是否过关，但是在检测人员返回检查的结果之前，生产员啥也不干。这就会严重影响到生产的效率。 

不再等待检测人员的检查结果返回，直接去生产下一个产品，这就提升了效率。

窗口越大，提升的效率也就越多。 

上述情况都是处于理想的条件，当传输的过程中出现了丢包的情况呢？

情况一：ack 丢了。如果只是丢了其中的某一个ack数据报，这里都是直接不去重传的。例如，当传输了1-4000的数据包时，最终返回的ack只有4001的话，也是默认前面的全部接收完毕了。因为4001都发送出来了，那么前面的ack也都是发送出来了，只是我没有收到而已，但不影响。

情况二：数据包丢了。如果在传输1-4000的过程中，2000丢掉的话，接收方就会一直发送确认序号为2001的ack数据包，当发送方连续三次都收到同样的ack数据包之后，就会将对应的数据重新发送。

注意：当接收方拿到2000的数据包之后，不会继续要3000，而是直接沿着刚才发送方发送的最后的数据来确认应答的。因为前面的数据都已经存储在了接收缓冲区里面，并未丢弃，后序直接读取就行了。

情况二触发的三次相同的ack数据包，并立即重传的操作，被称为"高速重发控制"或"快重传"。快重传和超时重传是一样的都是属于重传，只是在不同的条件下触发的，

流量控制

滑动窗口是为了提升传输的效率，窗口越大，也就说明提升的效率越大，但是窗口也不是越大越好。在生产一个产品时，即使生产的再多，检查人员检查不过来，也是白搭。而对于接收方处理更加粗暴，直接丢弃多余的数据包。因此为了协调接收方的处理能力，发送方的窗口大小要与接收方协商好。怎么协商呢？这里就需要用到TCP报头中的16位窗口大小了。接收方在发送ack时，就会将接受缓冲区剩余的大小给填充到这里面去，后续发送方就会按照这里的大小来重新设定发送窗口的大小。也就是说滑动窗口的大小是动态变化的。

注意：

1、这里的16位窗口大小是64kb，那么是不是这个接收缓冲区最大只有这么大呢？不是，选项中还有一个窗口扩展因子。而这个扩展因子是对窗口大小进行指数级增长的。

2、当发送方知道接收区满了之后，就会等待一段时间再去发送，那等待多久呢？这个是发送方随机发送一个窗口探测包去触发ack的，一旦接收缓冲区有了空闲空间，那么就会触发发送方接下来的发送操作。

拥塞控制

流量控制是根据接收方的处理能力来进行限制传输的窗口大小。除此之外，还会有传输路径上节点的转发能力影响着传输窗口大小的。如果说发送方传输的数据过多，在经过某个节点进行转发时，可能会发生丢包的情况。因此我们也是要根据传输路径的情况来控制传输窗口的大小。接收方的处理能力是通过接收缓冲区的大小来显示的，但传输路径的转发能力是怎么体现的呢？很显然，我们无法直接去观察这个，但是我们可以通过丢包的情况来观察。如果当前窗口没有出现丢包的情况，那么就增大窗口，如果后续出现了丢包的情况，我们再缩小窗口，然后再继续增大窗口，一直这样下去，达到一种动态平衡的方式。如下图所示：

延时应答 

默认情况下，接收方都是在收到数据报的那一瞬间，就返回ack，但是可以通过延时返回ack的方式来提高效率。例如，在某一个时刻发送方发送完数据之后，接收方从接收缓冲区读取了数据，但是稍等片刻再去返回ack，在此期间，接收方会将读取、处理接收缓冲区内的数据，过了一会儿，接收方再返回ack，此时接收缓冲区就不再是原来的大小，可能变得更小了，发送方所能发送的数据也就变多了。当然，也可能这段时间接收缓冲区并未发生变化。

在上述基础上，四次挥手也可以合并成三次挥手。将ack与fin一起发送出去。

注意：

1、不是所有的数据包都需要延时应答的。

2、延时应答会有两个限制：1）数量限制，每隔N个数据包，就应答一次；2）时间限制：超过最大延迟时间就应答一次。数量限制适用于数据密集的情况，而时间限制适用于数量稀疏的情况。

捎带应答

捎带应答是在延时应答的基础上进行延伸的。例如，当客户端发起一个请求之后，服务器就得返回一个响应，这时可以应用延时应答，将ack与响应绑定在一起一并发送给客户端。这就是捎带应答，本质上还是延时应答，只是在不同场景的叫法。

面向字节流

TCP传输是面向字节流的，使用TCP协议传输数据时，会建立一个连接通道。由于是使用字节流传输的，因此就会出现一个问题：一次该读取多少数据呢？很容易就会将包与包之间的边界混淆，从而不知道一次该读取多少。

注意：这里的粘包是指应用层数据包，而不是TCP数据包，不管是客户端还是服务器在读取时都是读取的应用层数据包，也只有在这时才会发生粘包的问题。

解决方法：

1、约定包与包之间的分隔符，即包的结束标记是啥。我们当时使用TCP协议编写服务器与客户端时，使用的是 "\n" 作为分隔符，双方在读取时，可以使用 next 或者 nextLine 方法，双方在写入时，使用的是 println。这样在读取时，便知道哪里到哪里是一个完整的应用层数据包。

2、约定好包的长度。例如在包的开头就约定好是整个数据包的长度，这样最终在读取时，只需要往后继续读取固定的长度即可。

前面学习的 http 中，就体现了上述两种解决方法：get请求没有body使用空行进行分隔，而post请求有body，就会提前告知Content-Length，来决定后续读取的长度是多少。

注意：

1、UDP是天然不存在粘包问题的，因为UDP在传输时，是一次传输一个UDP数据包。

2、只要是使用TCP协议传输就会存在粘包问题，当然具体是否有，得看应用层是如何进行处理的。如果应用层并未考虑到这种情况，就会出现粘包的问题，如果考虑到了并进行解决了，就不会出现粘包的问题。

异常情况的处理

使用TCP协议进行通信的过程中，也是会存在一些异常的情况，那这些情况怎么处理呢？我们现在就来学习。

1、进程崩溃了。例如，在执行某个代码逻辑时，出现了 "/0" 这样的严重错误，此时代码就会抛出异常，进程就会异常终止。上述过程中，在异常的处理中，还是会进行正常的关闭资源，同理四次挥手也能正常执行，这与正常的进程退出是没有啥区别的。正常的进程退出，也是会释放资源，触发四次挥手等操作的。

2、主机关机了。如果正常流程的关机（开始 -> 电源 -> 关机），也是会先去杀死所有的进程，与情况一是类似的。但存在一种情况：四次挥手并未完全搞完，主机A关机了，发送了一个fin数据包，也接收到了ack数据包，但是对端的fin并未收到，也就不会返回ack数据包，在对端看来是出现了丢包情况，此时对端就会进行超时重传操作，但很遗憾主机A已经关机了，并不会响应，因此当对端连续重传几次之后，并未收到ack，就会认为与主机A通信的链路出现了严重的故障，无法通信了，自然对端也就会将主机A的信息给释放到，连接也会释放。

3、主机掉电了。对于笔记本的话，内置电池并不会造成什么影响，但是对于台式机的话，就会直接将所有的进程全部杀死，这里并不会给这些进程时间来四次挥手的时间。

如果是接收方突然掉电的话，发送方就会拿到不到对应的ack数据包，发送方就会认为出现了丢包的情况，从而会引发超时重传，但是最终发送方还是拿不到对应的ack，当重复上述操作几次之后，这时发送方就会触发"重置TCP连接"的操作，发送一个 复位报文（RST）。但同样还是没有ack，这时发送方只能单方面释放连接。

如果是发送方突然掉电的话，接收方是不清楚对端的情况的，它会等待对端，当等待一定的时间之后，就会向对端发送一个"心跳包"，这个心跳包只是为了触发ack。如果在发送心跳包后没有收到ack，接收方会尝试重新发送直到达到最大探测次数，再之后会发送RST报文来尝试重连，失败之后只能单方面释放连接了。

4、网络出现故障（网线断开），这种情况与主机掉电是没啥区别的，对于另一端发送的消息也是收不到的。

剩余参数

URG：紧急指针位。在正常情况下，是按照32位序号的先后顺序来进行读取的，但是避免不了出现某些特殊的情况，这种情况下，就会使用紧急指针位，直接跳过前面的数据，从某个指定的需要开始读取。

PSH：催促标志位。这个和URG有些类似，当某个数据包带有催促标志位时，接收方就会尽快去读取，但不会向URG那样直接跳读，直接加快读取的时间而已。例如，本来需要等待一会儿再去读取这些数据，但发送方传输了带有PSH的数据包时，就会促使接收方立即去读取缓冲区的中的数据，即减少了该数据包在缓冲区中逗留的时间。

TCP 相较于 UDP 更加可靠，UDP 相较于 TCP传输的效率更高（即使有了滑动窗口的机制，肯定还是不如UDP的传输效率高，因为UDP并不会保证传输可靠，从而去实现重传的操作）。

好啦！本期 初始JavaEE篇 —— 网络原理---传输层协议：深入理解UDP/TCP 的学习之旅 就到此结束啦！我们下一期再一起学习吧！