轻松掌握TCP与UDP核心机制

🙉专栏推荐:Java入门知识🙉

🙉 内容推荐:网络编程TCP🙉

🐹今日诗词:Best wishes🐹

⛳️点赞 ☀️收藏⭐️关注💬卑微小博主🙏

UDP协议格式

UDP协议报头传输原理

TCP协议格式

TCP协议报头传输原理

TCP十大核心机制

1.确认应答机制

问题

解决方法

2. 超时重传机制

超时时间

3. 连接管理

三次握手

经典面试题一

经典面试题二

TCP状态

四次挥手

TCP状态

经典面试题三

4. 滑动窗口

滑动窗口出现丢包

5.流量控制

6.拥塞控制

7.延时应答

8. 捎带应答

9. 面向字节流

10. 异常情况

TCP协议格式图

UDP协议格式

UDP协议报头传输原理

UDP协议注意事项

TCP协议格式

TCP协议报头传输原理

16位源端口号和16位目的端口号

表示数据从哪里来, 到哪里去

4位首部长度

准确点, 应该叫4位动态首部长度

表示TCP报头的长度, 不是总长度, UDP的长度是整个数据报的长度, 这个长度是可变的

图中的选项, 可以用来选择增加长度, 如果不加任何选项, TCP报头的长度就是20个字节

加了选项最多可以达到60个字节, 换句话说, 选项可以达到40个字节

6位保留位

UDP数据报长度只有两个字节, 很小, TCP为了解决这个问题就引入了保留位, 提前申请

一块空间, 不管用不用的上, 提前申请着, 这样的空间就是保留位

16位校验和

和UDP功能一样, 判断传输过程中数据是否发生改变

TCP协议格式我们已经学会了4个部分, 剩下部分涉及到TCP常见十大核心机制

TCP十大核心机制

十大核心机制,并不是TCP只有十个机制, 而是十个比较重要的机制

1.确认应答机制

前面我们知道TCP协议的特点: 有连接, 可靠传输, 面向字节流, 全双工

最为重要的就是可靠传输, 它与TCP的确认应答机制息息相关

问题

如果传输了很多条数据, 可能会出现后发先至的状况, 后发的信息先传输过去了

解决方法

TCP协议对数据和应答报文进行了编号, 让正确的数据对应正确的应答报文

实际上TCP不是这么简单的对数据和应答报文编号

TCP协议是对数据的每个字节进行编号

这就是TCP协议格式里的32位序号和32位确认序号

确认序号是从多少开始的呢?

应答报文的确认序号 = 最后一个字节编号 + 1

2. 超时重传机制

超时重传: 发送方在超时时间内没有接收到应答报文ack, 就会重新发送数据

确认应答机制是数据传输过程中没有丢失, 如果出现丢包了, 这时候就需要超时重传

丢包: 网络通信中, 数据传输过程中出现了丢失的状况

丢包两种情况

发送方的数据出现丢包
接收方返回的应答报文出现丢包

这两种丢包有很大的区别, 第一种是接收方没有收到数据, 第二种是接收方收到了数据但是, 返回的应答报文出现了丢包, 站在发送方的角度, 这两种都会进行超时重传, 对于第二种情况超时重传发送了重复的数据了, 接收方收到重复的数据会根据序号自动过滤掉重复的数据.

超时时间

超时时间是多少呢?

超时时间是一个动态的数值

假设丢包率是10%, 第一次丢包率是10%第二次1%......很多次还没重传成功, 说明网络出了重大故障, 丢包率不是10%

超时时间是一个动态的数值, 随着重传次数的增加会动态的延长超时时间, 如果重传了很多次还是失败, 就不继续超时重传了, 而是重新建立连接(重置连接).

重置连接

多次超时重传失败就会触发重置连接, 触发TCP复位报文, 尝试重新连接

复位报文就是TCP六个标志位的RST

如果重置连接也失败了, 就会断开连接, 释放资源

3. 连接管理

连接分为: 建立连接和断开连接

建立连接流程: 三次握手

断开连接流程: 四次挥手

三次握手

建立连接: 通信双方互相保存对方的信息, 这个过程分成三步, 因此叫做三次握手

握手: 发送一个不带有任何业务逻辑的数据报, 载荷部分是空的, 只是用来打个"招呼"

这个数据报只有TCP报头, 并且TCP六个标志位中的SYN(同步报文)这一位的值为1

三次握手: 客户端和服务器各自保存好对方的信息, 连接才算完成

经典面试题一

三次握手的意义:

1. 在正式开始传输数据前, 确保通信链路的畅通

2. 验证通信双方的接收能力和发送能力

3. 协商一些必要的参数, 比如起始序号.....

为什么要协商参数呢?

答: 防止不同连接的数据相互干扰

举个例子:好比一个人出去当兵五年, 退伍回家, 发现家里拆迁改成公园了, 虽然是同一处地方, 但已经不是他的归处了

客户端和服务器建立了两次连接

我们知道数据通信中, 数据是会按照不同的链路进行传输的, 如果第一次连接, 客户端发送了一个数据报, 这个数据报绕了一个远路传播(不是丢包),传输过程中第一次连接关闭了, 第一次连接发送的数据报由第二次连接的服务端接收, 服务器这时候就会根据序号进行匹配, 如果发现与协商的序号不同就会丢弃这个数据报

经典面试题二

TCP为什么要经过三次握手呢?两次行不行, 四次行不行?

两次: 不行, 两次握手服务器还没进行发送能力和接收能力的验证

四次: 可以,但没必要, 四次是把客户端的ack和服务器的syn拆开了, 会降低性能

TCP状态

四次挥手

结束连接: 通信双方互相删除对方的信息, 这个一般过程分成四步(特殊情况三步), 因此叫做四次挥手

与三次握手不同的是: 三次握手一定是由客户端发起, 而四次挥手客户端和服务器发起都可以

什么情况下可以合并呢?

TCP有个机制叫做延时应答

这种情况下, 服务器收到fin(结束报文), 可以不用立即返回ack(应答报文), 等一会再返回,等的时间里, 如果执行到了close方法, 就会合并在一起了

TCP状态

经典面试题三

如果发现服务器这边存在大量的Time_wait, 如何处理?

说明服务器触发了大量的主动断开连接操作, 这样的操作是不科学的, 断开连接一般是客户端

主动断开

4. 滑动窗口

那么什么是滑动呢?

如果收的的序号不连续, 该怎么办呢?

滑动窗口出现丢包

采用滑动窗口的方法, 如果出现数据丢包, 应该怎么办?

这里丢包分成了两种情况:

1. ack(应答报文)丢包

2. 数据丢包

ack丢包

处理方法: 凉拌, 不需要管它

数据丢包

处理方式: 这个就比较麻烦了, 下面的处理方式叫做快速重传

5.流量控制

前面滑动窗口中, 我们说到了窗口大小,

窗口越大, 单位时间发送的数据量就越多,

窗口越小, 单位时间发送的数据量就越少

窗口大小是动态可变的, 但不是窗口越大, 传输效率就越高, 你传的快不代表服务器顶得住,

例如: 客户端一下把所有数据发送过去, 服务器按照顺序返回ack,但是数据量太多了

导致客户端长时间没收到返回的ack,就会触发超时重传,又进一步加大了服务器的压力,

让本不富裕的家庭雪上加霜.

正确的做法就是, giegie你慢点, 妹妹我顶不住了, 控制传输速率(窗口大小)

这种机制就叫做流量控制

那么具体是怎么进行流量控制的呢?

答: 在接收方有一个接收缓冲区(阻塞队列)

窗口探测包

问题: 如果接收缓冲区满了, 窗口大小变成0, 发送方就不会发送数据了, 此时改怎么办

答: 当窗口大小为0时, 发送方会每隔一段时间就会发送窗口探测包, 用于重新确定窗口大小

6.拥塞控制

拥塞控制和流量控制一样, 也是配合滑动窗口一起使用的

拥塞控制: 根据当前网络环境动态调整发送速率, 同时减少丢包现象的过程

拥塞控制和流量控制的区别:

流量控制是站在接收方的角度区影响发送方的发送效率

而拥塞控制是站在发送方和中间各种交换机路由器的角度看待

拥塞控制的拥塞窗口大小是动态变化的
当网络能力宽松时窗口大小就会扩大,
网络拥挤时窗口大小就会减少, 在拥挤和放松的边缘反复试探, 压榨网络

那么拥塞窗口大小是怎么增大和缩小的呢?

通过这样的方式动态调整拥塞窗口大小, 达到最佳传输效率

流量控制和拥塞控制谁来决定网络传输的效率

木桶效应: 当两个效果同时存在时, 选择最小的速率作为网络传输的速率

7.延时应答

前面介绍四次挥手时, 我们提到了延时应答, 他可以让四次挥手变成三步

延时应答: 不立刻返回ack, 等一段时间后再返回

延时方式一般有两种

1. 按照时间延时, 让服务器处理一定时间后返回

2. 按照数据量延时, 服务器处理一定量的数据后再返回ack

这两种方式一般会相互结合

8. 捎带应答

捎带应答是建立在延时应答的基础上的

将响应数据和ack报文合并在一起返回给客户端

9. 面向字节流

粘包问题: 多个请求混合在一起, 导致服务器无法做出正确的响应

例如: 翻译服务器中

10. 异常情况

这里异常情况指的是因为异常导致客户端和服务器断开了连接

大致分成四种:

1.进程崩溃

2. 主机主动关机

3. 主机意外关机(拔电源之类的)

4. 网线断了

进程崩溃

进程崩溃本质也是强制结束进程, 释放文件描述符表, 和调用close方法差不多

主机主动关机

我们手动关机时, 如果此时客户端和服务器的连接还在, 此时主机就会尝试结束所有进程

告诉他们要关机了, 然后这些进程结束也是正常流程, 四次挥手

主机意外关机

如果正在连接时, 客户端和服务因为意外关机, 没有提前通知, 这时候会出现两种情况

1. 客户端意外关机

此时服务器返回ack, 发现客户端没有响应, 就会触发超时重传, 重传几次都失败后, 发送rst(复位报文)尝试重新连接, 连接不成功, 服务器就会删除对端信息释放连接

2. 服务器意外关机

由于服务器挂了, 客户端也不知道服务器什么时候给我返回数据, 超过一定时间后, 客户端就会发送"心跳包", 尝试重新连接, 连续几次都没反应, 客户端也就释放对方的信息了

心跳包: 可以理解为一个没有载荷的数据包