网络原理 --- 传输层Ⅱ TCP协议中的确认应答，超时重传和连接管理

---

网络原理

介绍TCP/IP协议中每一层里面的核心内容~

• 应用层
• 传输层
• 网络层
• 数据链路层
• 物理层

传输层

传输层主要负责端到端之间的传输,重点关注的是起点和终点

核心的协议有两个:

• UDP: 无连接 ,不可靠传输,面向数据报,全双工
• TCP : 有连接,可靠传输,面向字节流,全双工

TCP 协议

作为传输层协议,协议报头中必须要明确源端口和目的端口

TCP的基本特性

面向字节流,有连接,全双工,代码中都是有所体现的~

但是可靠传输,在代码中体现不出来~

1.确认应答

确认应答机制!!

把这个应答的报文(回复的内容 : 收到)也称为ACK报文,ACK => acknowledge
ACK(acknowledge)和响应(response)是截然不同的!
ACK只是告诉发送方,我收到数据了
response是携带业务上的数据

普通报文,ACK这一位为 0
应答报文,ACK这一位为 1

确认应答机制,就是TCP保证可靠性的最核心机制!!!

🚌但是网络中传输中有可能会出现 后发先至 的情况 !
后发的请求可能会先到达对方这里!!
这样就会导致请求和应答对应错误…
后发先至,这是网络基本结构导致的,难以避免

🍟解决方案 :

针对请求和应答报文,进行编号

这两个数值就是上述的编号:

32位序号 : 针对请求数据进行编号
32位确认序号:只是针对ACK(应答)报文有效

TCP是一个字节流的协议,编号的时候,也是以字节为单位,进行编号的!

TCP将每个字节的数据都进行了编号,即为序列号

报文序号是1001,报文长度是 1000(最后一个字节的数据编号是2000)

TCP将每个字节的数据都进行了编号,即为序列号

❓序号不会溢出吗?

理论上也是会的,但是也不太影响~
TCP 32位序号和确认序号
表示的数据范围是 0- 42亿9千万
4GB,如果确实一个连接传输的数据太多太多了,那大不了序号到头了之后,再重新来算就可以了!

2.超时重传

确认应答描述的是,数据报顺利到达对方,对方给了个响应,但是传输过程中,可能会出现丢包的情况~

❓为什么会丢包?
网络环境是非常复杂的!
我可以上网,是因为接入了运营商的网络
运营商这边就有很多很多的路由器/交换机,共同组建出一个非长庞大复杂的网络
某个交换机上面,不光是传输我的数据报,也在传输别人的数据报
某个时刻,很多很多数据报都经过这个交换机
交换机的转发能力有上限,如果很多数据报都走这里,导致达到交换机的转发上限,就无法快捷的完成转发了,就可能会导致有一部分数据报就超时了~

❓如果丢包要怎么办呢?
如果数据丢包了,此时就需要考虑通过"超时重传"来进行了!

• 如果是发送方发的消息丢了,等一个特定的时间,时间过了就认为丢包了,就重新发一个消息(重传),不会有任何后果~ 这就叫超时重传!

• 如果是ACK丢了,但站在发送者的角度来看,没看到回应,无法区分是我发的数据丢了,还是ACK丢了,所以我就会觉得是我发的数据丢了,还是会进行超时重传!
  ❗ 但如果是ACK丢了,对方已经收到消息了,然后又重传,对方就受到了两个一模一样的消息…
  TCP接收方因为丢失ACK导致收到重复的消息,TCP就会针对相同的消息进行去重(根据序号来进行去重)
  保证了应用层代码通过 socket 读取数据的时候,读到的不是重复数据~

💕超时时间如何确定的?
一般系统里面会有一个配置项,描述超时的时间阈值~

例如:

第一次出现丢包,发送方就会在到达超时时间阈值,之后,进行重传
如果重传的数据仍然无响应~
还会继续超时重传,第二次的超时时间一般要比第一次更长~
(超时时间并非是均等的,而是逐渐变大的)
如果单个数据报丢包概率较小,这个时候,第二次传输,大概率是可以到达的
如果第二次传输也没有达到,说明当前网络环境比较糟糕~ 单个数据报丢包概率就非常大了…(甚至100%,比如断网了)
如果网都断了,再怎么频繁的重传,也没什么用,就不如穿的频率降低一点(时间间隔长一点),至少可以节省点主机的开销~

这样的重传,重试几次之后,仍然无法传输,就像会尝试重置 TCP 连接 (断开重连)
如果还是连不上,此时就直接释放连接(彻底放弃)

描述上述过程,并没有带入具体数字:

比如 基础的重传间隔是多少,每次间隔增加多少,最多重传多少次~
这里的具体参数,不同的系统不一样,并且一般也是可配置的

3.连接管理

描述的就是TCP 建立连接和断开连接的过程

TCP的连接,只是一个"逻辑上的",“虚拟的连接”

主机A 和 主机B 建立连接~
主机A的系统内核里,记录了一个数据结构,包含了和他连接的对方(IP端口,使用的协议)
主机B的系统内核里,记录了一个数据结构,包含了和他连接的对方…

❗❗①建立连接(三次握手)

建立连接: 双方建立一个相互认同的关系

建立连接的过程,我们就把它称为 " 三次握手 "

建立连接的过程其实是四次的数据交互!!
本来是四次,但是中间两次可以合并在一起!
上图就可以直接发一条消息 : 收到,你愿意当我男朋友吗?

SYN这一位如果为1,说明这是一个同步报文段(尝试和对方连接的)

建立连接(三次握手)的意义:

1. 投石问路 ~ 检查一下当前的网络情况是否畅通
   三次握手建立连接并不传输任何业务数据 ~
2. 三次握手同时也是在检查通信双方的 发送能力 和 接收能力 都是正常的
3. 三次握手过程中,也在协商一些重要的参数
   TCP里面有很多参数需要协商的,但是并不详细介绍
   👗举个例子:
   TCP的序号并非是从1开始的,通常都是建立连接的时候协商了一个数字~
   目的保证两个连接的序号有差别,如果连接断开又快速重连,接收方就可以区分当前收到的数据是当前连接的还是上个连接的

两个重点的TCP 状态:

• LISTEN : 服务器启动之后,绑定端口之后(new SeverSocket 完成),表示手机开机,信号良好,就可以让别人给它打电话
• ESTABLISHED:连接建立好了之后的稳定状态,表示电话接通,可以说话了~

②断开连接(四次挥手)

断开连接: 双方取消相互认同的关系

通信双方,各自向对方申请断开连接,在各自给对方回应

FIN: 结束报文段

❓为什么四次挥手不能简化为三次呢?
因为ACK和FIN 不一定能合并在一起发!!

在三次握手中,B给A返回的 ACK 是收到A给B的syn之后,立即触发的(ack和syn发送的时机完全相同)!!,是内核完成的~
B给A发送的syn也是内核触发,立即发送的~
操作系统就会把两个包合并成一个~

---

但是在四次挥手中ACK是收到FIN立即触发的,发送FIN是应用程序显式调用close方法触发的~(有可能不是立即触发的)

既然两个数据时机都不相同,为什么还有可能合并呢?
因为TCP中还有一个捎带应答的机制~
捎带应答后续单独介绍~

两个重要的TCP状态:

• CLOSE_WAIT :等待代码中调用close操作~
  如果服务器上出现大量的CLOSE_WAIT 状态的连接,说明close没有及时被调用到
• TIME_WAIT 主动发起关闭的一方,会进入 TIME_WAIT
  处理完最后一个ACK之后,不能立即释放连接,而需要保持一定的时间~ 这个是为了万一最后的ACK丢了,还有机会进行重传!!
  
  MSL : 网络上两个位置之间传输数据消耗的最大时间~
  TIME_WAIT 只需要等待 2 MSL 即可

总结

你可以叫我哒哒呀 本篇到此结束 “莫愁千里路，自有到来风。” 我们顶峰相见！