目录
一、TCP特性
二、报文格式
TCP十大核心特性
1. 确认应答
2. 超时重传
3. 连接管理(三次握手,四次挥手)
三次握手
四次挥手
4. 滑动窗口
情况一:接收方的ACK丢失
情况二:发送方的数据包丢失
5. 流量控制
6. 拥塞控制
7. 延迟应答
8. 捎带应答
9. 字节流粘包问题
10. TCP的异常处理
面试题:如何使用UDP来实现可靠传输?
一、TCP特性
1.有连接
2.可靠传输
3.面向字节流
4.全双工
二、报文格式
这是各大教科书上的
这个和UDP一样,是为了排版方便,容易给我们造成误解,其实真正的结构是这样的
TCP十大核心特性
1. 确认应答
发送方在发送一条数据给接收方之后,接收方会立刻返回一个ACK作为回应,表示自己收到该条数据
这就是确认应答,能够保证传输的数据一定能发送给对方
2. 超时重传
如果发送方没有接收到回来的ACK相应,等待一段时间后,发送方默认该数据已经丢失,会重新发送该条数据给对方,如果依然没有接收到ACK回应,那么会再次发送 ,但是每次发送的时间间隔会越变越长 , 这就是超时重传
3. 连接管理(三次握手,四次挥手)
三次握手
- 发送方给接收方发送一条信息(发送SYN);
- 接收方接受到信息后,发送两个消息,一个是确认应答(ACK),另一个是回复消息(SYN)
- 对于接收方发回来的ACK和SYN应答,发送方再次回复一个ACK确认应答
四次挥手
- 发送方发送FIN,请求和接收方断开连接
- 接收方回应ACK收到断开请求
- 接收方向发起方也发送FIN,请求断开连接
- ACK回应,接收方断开连接请求
4. 滑动窗口
滑动窗口的出现时为了提高TCP传输效率的,我们没有引入滑动窗口之前,TCP的大量时间都浪费在了等待ack上面,这时候我们便想到了一个办法 一次传输多个数据,
而为了保证接受方能够承担同时处理的最大数据,保证接受方不崩溃,我们限制了发送方的最大发送
也就是说,滑动窗口能够保证,接收方最大同时处理数据的上限,和发送方最大能发送数据的上限
如果在这种批量传输的情况下,出现数据丢失怎么办?
情况一:接收方的ACK丢失
这里可以看到,我们的ACK即使丢了,也无妨,下一条ACK只要能到达,ACK就不需要重新传送,因为发送5001的意思是前5000个数据全部收到了
情况二:发送方的数据包丢失
这里可以看到,即使是数据包丢失了也无所谓,主机2会持续的返回1001,这样主机1就会重新发送一次1001 , 所以滑动窗口,是很好的一种提高TCP传输速率的方法
5. 流量控制
接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制
- 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端；
- 窗口大小字段越大，说明网络的吞吐量越高；
- 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
- 发送端接受到这个窗口之后，就会减慢自己的发送速度；
- 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端
6. 拥塞控制
简单来说,就是速度如果达到了传输的上限,那么就会立刻反弹回一个较低的值,然后继续增长速率
如此反复,直到稳定在了一个比较合理的数值范围内,这就是拥塞控制
最开始我们的速率增长是指数级别的增长,比如 2的一次方 -> 2的二次方 -> 2的三次方....
然后到了一个比较高的值之后,为了防止下一个次方直接超出接受范围很多
所以从那个值之后,我们采用线性增长,而不是指数增长了
7. 延迟应答
接收方接受数据之后,不会立刻相应给发送方,而是等待一段时间,等接收方接收到多组数据后再返回
8. 捎带应答
如果在很短的时间内,接收方收到很多信息,并且都需要返回,那么多条返回消息,就可以合并为一条消息返回
9. 字节流粘包问题
当TCP发送多条数据,数据都存储再缓冲区中,由于我们的数据是字节流的,所以我们的数据很有可能会粘到一起,无法区分出哪些是一条数据
粘包问题处理方法:
1.通过分隔符:比如指定一个分隔符作为包的结束标记,这样每一个包就区分开来了
2.通过指定报的长度:比如再报文开头位置声明长度,这样读数据的时候,只读取指定长度的数据,就不会发生粘包问题了
10. TCP的异常处理
情况一:程序突然崩溃
操作系统会自动回收程序遗留/占用的资源,类似于close操作,然后发生四次挥手情况二:程序正常退出
同情况一,回收资源+四次挥手情况三:没法发送和接收数据(电脑坏了,网络断了)
接收方无法接受
接收方无法接受数据,也就是无法回应ACK相应给发送方,当发送方多次发送数据也没有ACK回应之后,就默认接收方不行了,然后停止发送数据发送方无法发送
在接收方和发送方里面存在一个"心跳包",双方会周期性发送一个小数据,判断对方是否存活,如果检测到发送方没有心跳回应,那么就默认发送方没了,接收方也就停止接收数据.注意:在接收方电脑坏了的情况下也能用心跳包判断,但是ACK更加直接
面试题:如何使用UDP来实现可靠传输?
其实是考察TCP,我们只需要基于UDP在应用层,实现确认应答,超时重传,引入序列号等待操作就可以了
