如何实现Tcp的可靠传输

目录

一、确认应答机制

二、超时重传机制

科普：为什么会丢包？

俩种丢包情景：

如何设置超时时间？？？

三.连接管理机制

1.建立连接 

三次握手

为什么要建立连接？建立连接的意义？（重点）

三次握手重要的tcp状态转换

断开连接：

四次挥手

对比三次握手四次挥手

---

什么是可靠传输

可靠传输指的是：数据传输过去后，发送方知道我发成功还是没发成功

典型例子：发短信：

 当a看到这个回复的消息后就能够认为上次发的数据，已经成功到达，否则过了一段时间没看到，认为上次发的数据丢了，通过这个，就知道上次发送的数据是成功还是失败，传输就变的可靠了

一、确认应答机制

确认应答机制，就是Tcp保证可靠性最核心的机制

上述例子中，b给a的回应好a好a就是应答报文，也称为 ack报文（acknowledge应答）

注意：应答报是将ack这一位设置成1

上述模型存在一定缺陷：

例子2：

假设a给b连续发送俩个信息

 有可能会出现（后发先制）网络上通信传输的路径是非常复杂的，俩点之间，俩个报文之间可能会走不同的路线难以避免）a和b之间理解会出现偏差

解决方案：针对请求和应答报文，进行编号

简单理解： 在确认应答这个机制中，引入序号来保证不出现歧义，tcp是一个字节流协议，编号的时候也是以字节为单位，进行编号的

 

演示俩个主机之间发送数据和接受数据（确认应答）

 如果传输的数据过多（4gb）2^32 序号到头，重新计算就行

二、超时重传机制

如果传输的过程中数据丢包，此时需要超时重传进行

科普：为什么会丢包？

网络环境是非常复杂的，我能上网，是因为我接入了运营商的网络，运营商这边就有很多很多的交换机/服务器共同组件庞大的网络，某个交换机上面，不光传输我的数据报，也在传输别人的数据报，某个时刻很多数据报都经过这个交换机（交换机转发能力有限），就可能导致有一部分数据报超时了

连续丢包概率是极小的：

俩种丢包情景：

还是上述例子：

1.数据报丢了

a没发送成功

 

 如果过了一会a还是接受不到b的回复，a就认为之前发的消息丢了，a重发一遍

2.ack丢了

b收到请求，没有给a发送成功：

 站在发送方A的角度来看，只是没看到，没收到ack,无法区分是我发的数据报丢了，还是ack丢了，还是要进行重传

站在b的角度，正常超时重传导致收到俩个一模一样的数据，b会根据相同序号来进行去重

必须保证引用层代码通过socket读取数据的时候，读到的不是重复数据

发送方这区分不了的俩中情况，都会触发超时重传机制

如果发送的过程网断了（连接超时）

如何设置超时时间？？？

一般系统里面会有一个配置项，描述超时的时间阈值，第一次丢包，发送方会在到达时间阈值后进行重传，如果重传的数据仍然没有相应，还会第二次重传（第二次时间比第一次长）

这样设置的好处：

由于已经讲到连续丢包概率极小，如果第二次都没有发送成功说明网络环境糟糕，网断了，再怎么着急发送都没用，不如延时发送，节省主机开销，多次尝试无果，就彻底放弃

三.连接管理机制

连接管理 描述的是tcp建立连接和断开连接的过程

网线是物理上连接，tcp的连接是逻辑上的虚拟的连接

1.建立连接 

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

三次握手

本来是四次合并了一次：

举个例子：

通信双方各自向对方申请，尝试连接，各自给对方回应（其实是四次数据交互）

 简图表示（重点）

为什么要建立连接？建立连接的意义？（重点）

1. 投石问路

检查当前网络情况是否畅通（不传输任何业务上的数据）

2.三次握手也是在检查通信双方的发送能力和接受能力都是正常的

举个例子：a和b打电话确认是否通信设备良好

 缺一不可！

3.三次握手的过程中，也在协商一些重要参数

举个例子：结婚办酒席

 tcp里面有很多参数要协商，后续介绍

例如：tcp序号不从1开始，通常先协商一个数字，目的是保证俩个连接序号有差别，断开快速重连是否是当前连接还是上个连接

三次握手重要的tcp状态转换

listen:服务器启动，绑定端口之后（new ServerSocket完成）表示手机开机，信号良好，允许通信

Established:建立好连接之后的稳定状态，表示电话接通可以说话

断开连接：

双方取消相互认同的关系：

通信双方，各自向对方申请断开连接，再各自给对方回应：

简图：

四次挥手

 

fin时机不同，由socket close触发（程序员决定）

对比三次握手四次挥手

1.时机问题

三次握手时机一定相同，四次挥手不一定相同

在三次握手中,b给a返回的ack是收到a给b的syn之后，立即触发的（内核完成），b给a发的syn也是内核触发也是立即发送的(一定会合并）（时机相同）

四次挥手数据不一定会合并（有时候也可以三次挥手------捎带应答机制实现）

 既然俩个数据时机不同，为啥可以合并,tcp还有一个机制，捎带应答

简图：

 明确俩个重要的tcp状态 close_wait ,time_wait

time_wait

如果最后一个ack丢包了，此时b就会重新发送fin,过了一会fin没有重传，就认为ack顺利到达