TCP因为其可靠传输的特性被广泛使用,这篇博客将详细介绍一下TCP协议是如何保证它的可靠性的呢?这得主要依赖于其确认应答及超时重传机制,同时三次握手四次挥手也起到了少部分不作用,但是主要还是由确认应答和超时重传来决定的;注意:这里的可靠传输并不是说100%能把数据发送给接收方,但是至少可以知道数据是否传输到了接收方!
目录
确认应答
超时重传
发的数据丢了
返回的ack丢了
两种机制的总结
确认应答
确认应答是实现可靠传输的核心机制!
A给B发送一条"今晚吃火锅吗"的消息,站在A的角度如何知道消息是否丢包了呢?此时B给A回复了一句"好呀",这样A就可以知道消息正常到达了B,B给A返回的信息就称为应答报文(ack);生活中随处可见这样的应答机制,比如打电话就是可靠传输;现在是单条消息的发送,考虑更复杂一点的情况,多条消息的传输:
为什么会出现上图的第二种情况呢?由于网络上存在"后发先至",这个时候收到消息的顺序就可能存在变数!如何解决这种问题呢,TCP引入了序号和确认序号来区分.
任何一条数据(包括应答报文)都是有序号的,但是确认序号只有应答报文有,普通报文确认序号字段里的值没有意义,一条报文是不是应答报文取决于TCP报文格式中的ACK标志位是否是1;此时引入序号和确认序号后的交互情况如图所示:
此时引入序号后,就不怕顺序乱了,即使顺序乱了,也可以通过确认序号来区分当前应答报文是针对哪个数据进行回复的了;但是实际上TCP序号并不是按照"一条两条"这样的方式来编号的,TCP是面向字节流的,所以TCP的编号也是按照字节来编号的!
确认序号一般是接收到的数据的最后一个字节+1,这里的1001有两层含义:
- 表示1001之前的数据全部接收到了
- 表示接收方向发送方索要1001及之后的数据了
总结:
TCP可靠传输能力,最主要是通过确认应答机制来保证的,通过应答报文,就可以让发送方清楚的知道传输是否成功,进一步引入序号和确认序号,针对多组数据进行详细的区分!
超时重传
上述讨论确认应答的时候,只是讨论了顺利传输的情况,如果丢包了呢?数据丢包涉及到两种情况:
- 发的数据丢了
- 返回的ack丢了
不管是哪种,站在发送方的角度来看,就是没有收到ack,无法区分具体是哪种情况,所以这两种情况一视同仁,都认为是丢包,此时TCP就引入了超时重传机制.
超时重传机制是TCP协议针对丢包情况进行的一种挽救措施,TCP引入了一个时间阈值,发送方在这个时间阈值内如果没有接收到应答报文则默认为是丢包,此时就会重新再发一次同样的数据(简单概括就是超过一定时间还没响应就重新传输),这个时间是可以配置的,并且在不同系统上的默认值都可能存在差异,这里不做讨论.
发的数据丢了
发的数据丢了的话只需要再发送一次即可.
返回的ack丢了
返回的ack丢了的话,这个是一件比较恐怖的事情,如果这是一个支付请求的话,发送方超时重传就会造成进行了两次的支付请求,针对这种重复的数据传输,TCP也做了特殊处理:
TCP存在一个"接收缓冲区"这样的存储空间(接收方操作系统内核里的一段内存,每个TCP的socket对象,都有一个接收缓冲区),主机B收到主机A的数据其实就是B的网卡读到数据了,然后把这个数据放到B的对应socket的接收缓冲区中,后续应用程序使用getInputStream,进一步使用read就是从接收缓冲区来读数据,该缓冲区不仅有去重的作用,同时也有排序的作用.
总结:
由于去重和重排机制的存在,发送方只要发现ack没有按时到达,就会重传数据,即使重复了,即使顺序乱了,都没事,接收方都能很好的处理好,去重和排序都依赖TCP报头的序号!
两种机制的总结
可靠传输是TCP最核心的部分.
TCP的可靠传输就是通过 确认应答 + 超时重传 来进行体现的;其中确认应答描述的是传输顺利的情况,超时重传描述的是传输出现问题的情况,这两者相互配合,共同支撑的TCP的可靠性!
