【JavaWeb】传输层协议——UDP + TCP

目录

UDP协议

UDP协议结构

UDP的特点

TCP协议

TCP协议结构

TCP的特点

TCP的十个核心机制

确认应答

超时重传

连接管理

滑动窗口

流量控制

阻塞控制

延迟应答

捎带应答

粘包问题

异常处理

---

UDP协议

UDP协议结构

源端口：存储的是发送方的端口号。

目的端口：存储的是接收方的端口号。

UDP长度：存储的是UDP报文的长度。

                   UDP报文 = UDP报头 + UDP载荷

                   如果传输的数据超过64KB，那么有两个解决方案：

                        ①在应用层中把数据拆分一下

                        ②使用TCP协议进行传输

校验和：检验传输的报文是否是正确的，如果不正确直接丢弃数据

              传输过程中可能数据会发生变化，校验和存储的是对于应用层数据经过一系列                        运算后得到的16位的数据。当接收方收到数据后，以同样的的运算方法算一下报文                的数据，算出来的结果与检验和结果相同就是没有发生变化，否则就是出错了，                    丢弃数据。比较知名的算法有：①CRC ②MD5 ③SHA1

---

UDP的特点

无连接

知道对方的端口号和IP就可以直接传输，不用连接。

不可靠

如果数据由于故障没有发送到对方，UDP协议不会返回提示给应用层。

面向数据报

应用层交给UDP的数据，UDP直接打包成数据报，不会拆分。

全双工

一个通信通道，同一时间内，既可以发送也可以接收数据。(因为通信通道里有8条网线)

缓冲区

没有发送缓冲区，只有接收缓冲区。

发送数据的时候直接交给下一层，不会等待。

接收缓冲区则不能保证接收的数据是按照顺序的，同时数据存不下之后，新发来的数据就会被丢掉。

大小受限

由于结构的限制，传输的整个数据的大小不能超过64KB。

---

TCP协议

TCP协议结构

源端口号： 存储的发送发的端口号。

目的端口号：存储的接收方的端口号。

首部长度：存储的是TCP报头的长度。

                TCP报文 = TCP报头(首部) + TCP载荷

                报头中  选项  之前的是固定长度 20 字节

                首部长度虽然是 4 位，最大的表示数字就是 2^4 = 16 但是单位却是  4字节  也就                    是首部长度最大可以是 16 * 4字节 = 64 字节

选项：存储的是对TCP报文的一些属性的解释说明（可有可无）

           首部长度 * 4字节 - 20字节 = 选项大小     如果首部长度为 5，则没有选项。  

保留：保留的六位是为了以后升级使用的。以后如果新加什么内容，就可以在这里加，而且             这样未升级的设备也可以兼容

检验和：检验的是整个报文的数据。与UDP同理。

其他的结构将会在核心机制中讲解。

TCP的特点

有连接

客户端和服务器二者之间先要建立一个联系才能够相互通信。

可靠

这是TCP最大的特点，发送的数据是可靠的。主要通过 确认应答和超时重传 来保证的。

面向字节流

和之前的文件读写一样(通过字节流)，所传输的数据都是转换成了字节流。

全双工

缓冲区

在下面的机制中有所体现。

大小不受限

由于结构的原因，TCP传输的数据没有限制

---

TCP的十个核心机制

这里只是介绍十个比较重要的机制，TCP的机制远不止这么几个。

---

确认应答

主机A给主机B发送了个消息，主机B给主机A返回一个应答报文(ACK)，这样主机A就知道消息一定发过去了。

通常情况下，主机A会发很多条消息，而B要回应相对的消息。在这种情况下就可能会出现A发送的消息到B这里顺序变了。这样回复的就乱了。

为了解决这种情况，TCP将每个字节都进行了编号——序列号。如果一段报文有100个字节长，假设从 1 开始编号，A就在  序号 中只存 1 ，B收到后，返回的应答报文里的  确认序号 只存 101 （表示从序号100之前的报文都收到了，可以发后面新的了）

另外如果是应答报文，报文中的 ACK 就变成 1 ，表示该报文为应答报文。0 就不是应答报文。

TCP之所以是可靠传输，最主要靠的就是这个机制。

---

超时重传

网络传输中偶尔会出现丢包的情况。这里的丢包是指：①发送的数据丢了  ②返回的应答报文丢了

TCP判断数据丢失的规定是，从发送报文后开始计时，超出一个 时间阈值 还是没有收到ACK，就判定是丢包了。

丢了之后TCP的抢救措施是重新发一下数据。

不过，如果是返回的应答报文超时了，那么接收方不就会收到相同的数据吗？为此TCP解决方案是：使用缓冲区进行去重和排序。每一个Socket对象都有一个缓冲区(在操作系统内核中的存储空间)，当接收方收到数据之后，放到类似于一个 具有优先级队列 功能的缓冲区进行排列和去重(排列的依据就是序号)。 

确认应答是在传输顺利下的可靠传输，那么超时重传则是在传输不顺利情况下的可靠传输。

---

连接管理

连接：主机A保存着主机B的IP和端口号，主机B保存着主机A的IP和端口号，这就建立了连接。

           保存这个信息的空间也叫做连接。当保存的信息没了，连接就断开了。

建立连接的过程被称为 三次握手 ，断开连接的过程称为 四次挥手 。

三次握手

三次握手本质上是通信双方的四次交互。双方都要向对方发送一个连接的请求，各自收到对方的请求后返回应答请求，其中有一个请求和返回应答请求可以合并成一次交互，所以才叫 三次 握手。

这一次合并必须要合并，因为它效率会有所提升，资源开销更小。

用到下面两个标识：

SYN：请求连接的标识。

ACK：ACK自然就是响应连接而返回的标识了。

三次握手就像上网课的时候，老师对同学说：声音和屏幕正常吗？班长回答：正常。老师可以听到声音吗？老师：可以。  这样才开始正式上课。

三次握手的意义

1. 建立通信双方的联系。

2. 确保双方的发送和接收的消息的能力正常。

3. 握手过程中协商一些重要参数。

四次挥手

通信双方分别向对方发送一个结束连接的请求，各自在给对方会一个应答请求。这四次交互无法像三次握手一样合并其中。原因在下图解释。

用到下面两个标识：

FIN：通知对方，自己要关闭连接的标识。

ACK

上图中的TIME_WAIT 是一个比较重要状态，因为三次握手和四次挥手中同样可能会出现丢包情况。当上面的客户端发送完最后一个ACK后，如果丢包了，那么在服务器看来自己有可能是自己的FIN没有发过去，或者是ACK丢了。那么这时候服务器又会发送一次FIN。此时由于客户端的TCP处于TIME_WAIT状态，所以就可以继续发送ACK。

---

滑动窗口

上述过程中都是发一个数据，收一个ACK，收到ACK之后再发新的数据。这样确保了数据传输的可靠性，但是效率缺降低了。为了提高效率，每次发送数据的时候都是发送一些数据(大小是一个窗口)。

上述利用滑动窗口来传输数据，出现丢包了分成两种情况解决。

1. ACK丢了

上述图中的比如 确认序号为101 的ACK丢了，但是后续的 201 ACK传过去了，也就包含了 201 之前的报文都收到的信息，所以不会有影响。

2. 数据报文丢了

上述图第一个窗口中比如 序号为201 的报文丢了，如果没丢此时返回的确认序号应该是301。但是丢了确认序号还是返回的201。剩下一个窗口内返回的ACK的序号也都是201。多收到几次201后，主机A就会发现问题，不对，应该是丢包了，此时就会重传201这个报文。这种重传方式叫“快速重传”。

---

流量控制

这是改变上面滑动窗口大小的机制之一。

窗口越大越好，这样再同一个时间可以等更多的ACK，但过大窗口短时间会消耗大量系统资源，而且接收方能否处理过来也还是个未知数。为了判断接收方的处理能力，每次返回一下 缓冲区剩余空间的大小 就可以判断了。如果缓冲区比较大大，那么下次的窗口就大一些，反之亦然。

窗口大小：存储缓冲区剩余空间。从TCP结构图中可知，它只有 16 位，最多可以 2^16 = 65536 / 1024 = 64 KB。只有这么一点空间显然是不够的。

选项：这里面有一个 窗口扩展因子  在这里面写个2，意味着 64KB << 2 = 256KB. 此时就可以存最多256KB的值了。

---

阻塞控制

这是改变上面滑动窗口的另一个机制。

数据传输的过程中可能会有很多条选择的路径，这些路径由路由器和交换机等构成。每条路的传输的速率也大不相同。

流量控制从接收方能力得出窗口大小，阻塞控制从传输过程的速率得出窗口大小。最终窗口大小取二者中较小的值。 

---

延迟应答

延迟应答是在滑动窗口的基础上实现的。

通过滑动窗口收到一波数据后，存到缓冲区之中后，不立刻返回ACK，而是让接收方处理一波缓冲区里的数据，这样剩余的空间就会大一些，返回的窗口大小就会大一点。

---

捎带应答

捎带应答是在延时应答的基础上实现的。

主机A给B发送一个请求后，B应该立刻返回一个ACK，然后再返回请求处理后的结果(ACK是操作系统内核发送，结果是B的程序发送的)。这两个返回原本不可能一起发送，但是有了延时应答后就可以把ACK和处理结果一起返回。

---

粘包问题

由于TCP是面向字节流，收到数据后放到缓冲区后就无法分清楚哪些字节是一条完整的数据。这样的问题被称为粘包问题。解决方案由两种。

①最开始的地方写好数据报的长度。这样读的时候先读一下长度，然后再循环读长度次。

②约定好分隔符。当读到分隔符之后停止一次的读取。

---

异常处理

这里的异常是指传输过程中出现的不可抗力。比如停电。

主要分为两大类：

一：①进程崩溃 ②主机正常关机

进程奔溃也就是进程关闭了，正常关机是也是先关闭进程。进程没了对应的PCB也就没了，对应的文件描述符表也就释放了。这样就会触发socket中的close，进程会继续完成四次挥手。与正常断开没有区别。

二：①主机停电 ②网线断了

当接收方停电后，发送方会一直发送数据，但是一直收不到接收方返回的ACK。多次重传但是没有用，此时发送方就准备和接收方重连了(TCP结构中的RST)。重连显然也会失败。那么最后就单方面宣布断开连接了。

当发送方停电后，接收方完全不知道是数据还没过来还是上面其他原因。所以接收方会周期性的给发送方发送一个消息，确认对方是否正常工作。(这种机制被称为心跳包)

---

有什么错误评论区指出。希望可以帮到你。