【Java成王之路】EE初阶第十四篇:(网络原理) 4

115 阅读 0 评论 76 点赞

我是靠谱客的博主还单身啤酒，最近开发中收集的这篇文章主要介绍【Java成王之路】EE初阶第十四篇:(网络原理) 4，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

上节回顾

TCP的核心就是可靠性!!

1.确认应答.保证可靠性的核心机制.针对传输数据以字节为单位进行编号.

2.超时重传:

①.传输的数据丢了

②.ack应答报文丢了

都要重传

超时时间是动态变化的.500ms为单位

3.连接管理(最爱考)

三次握手状态转换 LISTEN ESTABLISHED

四次挥手 CLOSE_WAIT TIME_WAIT

4.滑动窗口

在可靠性的基础上,提升通信效率

把数据进行批量发送,批量等待ACK

窗口大小.批量发送多少数据不用等待ACK

5.流量控制

根据接收方的处理能力(接收方的缓冲区剩余空间),来解决窗口大小

接上一篇继续

TCP的第六个机制

6.拥塞控制

站在另外一个角度来限制发送方的窗口大小

什么叫另外一个角度?网络传输仅仅是受限于接收方的接收速率吗?

接收方和发送方难道就是一根网线直连的吗

很明显并不是这么简单

在这中间会有很多其他的网络设备,我们的网络环境是非常的错综复杂的,发送方传输的数据可能会经过很多硬件设备,七扭八歪的才能到达接收方.

前面描述的流量控制,指的是针对接收方的处理能力.

假设接收方处理速度很快,但是中间某个节点的处理速度很慢,这个时候发的快还是不行,发的快可能就在中间节点就丢包了,还没到接收方呢.所以说这里面的情况并不能只看接收方,还得看网络中的中间过程.

拥塞控制是站在一个宏观角度来看待问题.

把整个中间的链路都看成了以整体.

只看结果

逐渐尝试的过程.

先使用一个比较小的窗口来传输数据.

看看是否丢包,如果不丢包,说明网络比较通畅.

如果丢包,说明网络发生拥堵.

当网络通畅的时候,就逐渐加大发送速率.

当网络出现丢包的时候,就立即降低发送速率.

通过这样的方式,就可以逐渐实验出一个比较合适的窗口大小.

真实的发送窗口的大小 = min(流量控制的窗口,拥塞控制的窗口)

慢启动:刚开始启动的时候,给一个较小的窗口(比较慢的发送速率)

这个图描述了拥塞控制中,窗口大小的变化规则.

此时通过指数增长,就能在很少的轮次中就把窗口大小给顶上去.

如果达到阈值,就从指数增长变成线性增长.

7.延时应答

提高效率(从窗口大小入手)

核心就是让窗口大小,在保证可靠的基础之上,能尽量再大一点.

关键在于:

流量控制来说,窗口大小就是接收缓冲区的剩余空间大小.

8.捎带应答.

延时应答的基础之上来完成的

捎带应答本身是一个"概率性的机制"

当前ACK延时的时间正好要比接下来发业务数据的时间要更长一些.

例如:

服务器从收到请求到返回响应,这个过程消耗时间50ms

但是延时应答假设最多等20ms,这个情况就无法触发延时应答了.

但是延时应答如果假设是最多等60ms,到第50ms的时候,此时出发了响应,ACK既可以和这个响应一起过去了,也就触发了延时应答.

9.面向字节流

在这种面向字节流的情况下,需要注意一个重要的问题:粘包问题(粘包指的是应用层的数据报).

这种情况就被称为粘包问题.

这不是TCP特有的问题,只要是面向字节流传输,都存在类似的问题.

类似的,像UDP这种面向数据报的机制,就没有这个问题

我们再来画一下:

如何解决粘包问题?

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

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

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

核心就要明确应用层数据中,包和包之间的边界.

10.TCP中的一些异常情况.

常见的异常情况:

1.进程终止

不管进程是咋终止的,本质上都会释放对应的PCB,也会释放对应的文件描述符,一样会触发四次挥手.进程终止,不代表连接就终止.进程终止其实就相当于调用了socket.close()而已.

2.机器重启

这个事情重启的时候,其实也是杀进程.仍然是四次挥手.

3.机器掉电/网线断开

这个是突发情况,机器来不及进行任何动作.

分两种情况讨论:

1.掉电的是接收方,此时另外一遍还在发送数据,此时显然发送方不会再有ack

于是就会超时重传.

重传几次之后,就会尝试重置连接.复位报文段

接收方一直没有反应

再然后发东方就会放弃这个连接

把连接对应的资源就回收了

2,掉电的是发送方,此时另外的一方再尝试接收数据,此时接收不到任何数据.

接收方如何知道,发送方是挂了?还是说发送方暂时还没有发呢?

此时接收方采取的策略,就是"心跳包"机制.(也称作"保活")

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

如果PING包发过去,过了很久还有PONG,并且重试几次也不行,此时就认为对方挂了.

1

心跳包,这是一个应用非常广泛的机制.不仅仅是在TCP.

总结

TCP机制:

1.确认应答(保证可靠性)

2.超时重传(保证可靠性)

3.连接管理(可靠性)

4.滑动窗口(效率)

5.流量控制(可靠性)

6.拥塞控制(可靠性)

7.延时应答(效率)

8.捎带应答(效率)

9.面向字节流(粘包问题)(其他)

10.异常情况(心跳机制) (其他)

一个非常经典的面试题:

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

让自己写代码在应用层实现.

说白了这道题看似是在问UDP,其实是在考TCP.

1.实现确认应答机制,把每个数据接收到之后,都要反馈一个ACK(这就不是内核返回了,而是应用程序自己定义一个ack包,发送回去)

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

3.超时重传

4.实现连接管理

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

6.为看限制滑动窗口,实现流量控制/拥塞控制

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

注意:这个题是在问你实现的思路,不是让你真写代码!!!

第二个:

啥样的场景中是个使用TCP,啥样的场景中适合使用UDP?

1.如果需要可靠性.肯定首选TCP

2.如果传输的单个数据报比较长超过64k还是使用TCP

3.如果特别注重效率,优先考虑UDP.(典型的场景:机房内部的主机之间通信,网络环境简单,带宽充裕,丢包的概率本身就不大.机房内部主机之间的通信,往往传输数据量更大,更需要速度.尤其是在当下的"微服务"这样的环境中,其实特别需要)但不是一定的.也有使用TCP的

4.如果是用广播,优先考虑UDP(什么是广播,就是一份数据同时发给多个主机,UDP自身就支持广播的,但是TCP自身不支持,就只能在应用层程序中通过多个连接,轮询的方式给每个主机发送数据(伪广播))

像LOL,王者农药这样的moba类游戏,传输的时候,使用是TCP还是UDP??

很可能,既不是TCP,也不是UDP!!

传输层协议,并不仅仅是TCP和UDP;两种!!

除了TCP或者UDP之外,还有很多其他的传输层协议.

有的协议就尽可能的荐股到可靠性和效率.(兼顾可靠性和效率,付出的代价可能就是更多的机器资源)