前言
TCP/IP五层协议是互联网中的主流模型,为网络通信提供了一个稳固的框架。
主要包含了应用层,传输层,网络层,数据链路层,物理层。
本篇主要介绍传输层的TCP协议的核心机制
一. 确认应答(ack)
TCP最核心的机制为可靠传输,但可靠传输并不是保证100%的成功,而是尽可能的使数据能到达对方,可靠性的保证有两个重要机制
1.能感知到对方是否接收到数据
2.如果发现对方没有收到,就要进行重发
其中,通过确认应答机制来感知对方是否收到。
所谓的“感知对方是否收到”,是靠对方的通知。
应答报文(acknowledge),缩写为ack
网络传输中存在着后发先至的情况,当发送多个消息时,上诉机制可能可能产生问题,例如
甲向乙提出两问题,乙回答时可能发送后发先至的情况,变成了乙不同意一起吃饭,却同意做女朋友,此时,就产生了歧义。
此时,可以给传输的数据添加编号,通过编号,可以区分出数据的先后顺序。
TCP是面向字节流的,实际上的编号是按照字节来编号的。
按照字节编号这样的机制,就是TCP的序号
在应答报文中,针对之前收到的数据进行对应编号,称为TCP的确认序号
其中,确认序号是接收方收到的数据最后一个字节序号的下一个序号(如上图,数据最后一个字节序号是1000,ack则返回1000+1,也就是1001作为确认序号)
确认序号前的数据,全部都已经被接收方接收
如果数据在发送过程中发生后发先至,后面的数据比前面的数据先一步到达,此时接收方read就会进入阻塞等待,直到读取到开头发送的数据,确报发送方write的顺序和接收方read的顺序相同时,才会解除阻塞。
二.超时重传
网络传输中并不是一帆风顺,常常会发生丢包情况
产生丢包的原因有多种
1.数据传输过程中,发生了bit翻转,收到这个数据的接收方计算校验和对不上,此时会直接丢弃该数据包。
2.数据传输到某一节点,节点负载太高了(网络高峰期),后续传输过来的数据可能直接被节点丢弃掉
TCP需要通过应答报文来区分数据是否丢包,收到应答报文(ack),就说明数据没有丢包,没收到应答报文,就说明数据丢包了。
丢包是难以预测的,TCP再强大也难以完全避免丢包,能做的只有在感应到数据丢包时重新发一次
但数据在网络传输是需要消耗时间的,“没收到应答报文”可能只是暂时没收到,等一会可能就收到了,也有可能是确实丢失,永远收不到了。
超时重传机制通过设定一个“时间限制”,如果在这个时间限制内,没有收到ack,则视为数据丢包,随后重传文件
如果数据成功发送,但ack丢包,由于发送方无法识别对方有没有收到数据,到达限制时间后也会进行重新发送,此时接收方又收到了一份相同的数据,TCP会进行去重,确保不会read到同样的数据。
超时重传的时间不是固定不变的,而是动态变化的。
发送方第一次重传,超时时间是t1,如果仍然没有ack,则会进行第二次重传,超时时间为t2
通常情况下t2>t1,每重传一次,超时时间的间隔就会变大,反复重传多次后,都没有顺利到达,TCP不会尝试重传,会先进行复位连接,发送一个一个特殊的数据包(复位报文),如果网络这会恢复了,复位报文会重置连接,使通信可以继续运行,如果网络存在严重问题,复位报文也没得到回应,此时TCP就会单方面放弃连接,连接也就无了。
确认应答和超时重传相互补充,共同构建了TCP的可靠传输机制
三.连接管理★★★(重点)
1.建立连接(三次握手)
三次握手是客户端与服务器建立连接的过程,前面提到过,连接的实质是双方保存着对方的信息
如上图所示,A请求保存B的信息,B接收到后返回ACK,然好B请求保存A的信息,A收到后返回ACK,其中,syn和ack可以同时发送,于是将这两步合并成一步,这就是三次握手。
三次握手要解决说什么问题?意义所在?
1.投石问路,初步验证通信链路是否畅通(可靠传输的前提条件)
2.确认通信双方各自的发送能力与接收能力是否都正常
3.让通信双方在通信前,对通信过程中需要用到的一些关键参数进行协商(TCP通信时的起始数据序号,就是通过三次握手协商确定的)
上诉约定的意义,在于避免“前朝的剑斩今朝的官”
假如A和B在传输数据时,数据包传输的慢,突然A和B断开了连接,过了一会A和B又重新建立了连接,虽然还是A和B两个主机连接,但可能是不同的应用程序,此时上一个没到达的数据包可能这时才到达,A和B已经是新的连接了。
针对这样“迟到”的数据包,应当直接丢弃掉。
那么,如何区分数据包是否是前朝的?
可以给每个连接都协商不同的起始序号,如果发现收到的数据和起始序号以及和最近收到的序号差距很大,则为“迟到”的数据包
2.断开连接(四次挥手)
断开连接就是通信双方各种把对端的信息删除掉(优雅的)
前面介绍“超时重传”时提到单方面释放连接,则是没那么优雅的进行断开连接(会造成资源浪费)
通信双方各种给对方发送“FIN”,各自给对方返回“ACK”
三次握手的三次,是因为中间的syn与ack进行了合并
对于四次挥手来说,中间ACK和FIN不一定能够合并。
原因是四次挥手ACK是内核控制的,但FIN的触发则是通过应用程序调用close
这中间存在着时间间隔
3.TCP的状态
1)LISTEN状态
服务器进入的状态,表示已经绑定好端口,服务器初始化完毕,准备连接客户端
2)ESTABLISHED
客户端和服务器都保存好了对方的信息,可以传输后续数据业务(三次握手后)
3)CLOSE_WAIT
被动断开连接的一方进入的状态,等待代码执行close方法
如果发现服务器端存在大量CLOSE_WAIT状态的TCP连接,说明服务器代码可能存在问题,应检查代码是否有close操作
4)TIME_WAIT
主动断开连接的一方进入的状态,此处的TIME_WAIT按照时间等待,达到一定时间后连接也就释放了。
为何不直接释放连接?而是要等待一段时间??
TCP在传输的过程中,任何一个数据都有可能丢包
此处的等待,就是以防最后一个ACK丢包,如果最后一个ACK丢包,则会重传FIN
能够重发一次ACK的前提是A这边的连接不能释放(如果释放就无法返回数据)
保留一段时间没有收到重传的FIN,则说明刚才的ACK应该是收到了,就可以释放连接
TIME_WAIT持续时间通常为2MSL
四.滑动窗口
1.概述
提起滑动窗口,学过算法的同学应该知道,算法思想中也有滑动窗口,其实,算法中的“滑动窗口”正是借鉴自TCP的滑动窗口
为什么TCP要滑动窗口???
TCP希望能在可靠传输的基础上,也能有不错的效率,为此引入滑动窗口。
此处的提高效率,只是“亡羊补牢”,使传输的效率损失尽可能降低(效率低于UDP)
按照以上方式(无滑动窗口),A每次发送一个数据给B,都得等待B的ack才能发下一个,这种方式的低效的。
改进方案则是把“发一个等一个”改成“发送一批等待一批”,把多次等待ack的时间合并成一次,这样等待的时间少了,效率也就提高了。
批量发送的数据越多,效率越高,此时把批量发送数据且不需要等待的数据的量称为窗口大小。
以下图为例,主机A批量发送数据包后,当收到第一个ack后,就会立即发送下一条数据,窗口向右移动
2.丢包问题
情况一
数据包抵达,ACK丢包(如图)
此时不需要做任何处理,批量发数据,ACK丢失也只是丢失其中的一部分,不可能全丢了
通过确认序号,可以判定前面的数据都收到了,接下来要发送的数据就从确认序号这里往后发
情况二
发送方数据丢包
如图,确认序号会在收到后面的数据包时反复返回丢失段数据包的序号,提醒发送方进行重发,发送方识别出哪个数据包丢失后,针对这个数据包进行重传,其他顺利到达的数据包无需重传,这就是“快速重传”
快速重传可以视为滑动窗口下搭配的超时重传。
五.流量控制
滑动窗口窗口的大小对于传输数据的性能是直接相关的
窗口的大小不能无限的大,通信是双方的事情,发送方发送的快了,也得确保接收方能够处理的来。
发送方与接收方之间,有着一个接收缓冲区,用于存放发送方发送的数据(本质为阻塞队列)
如果发送速度特别快,接收方处理接收速度比较慢,就会使接收缓冲区充满,此时发送方强行发送数据则会丢包,这就需要让接收方的处理能力反向制约发送方的发送速度。
可以通过“定量”的方式,来实现制约
如果空闲空间越大,则可以认为应用程序处理速度比较快,就可以让发送方发送的快一些,设置一个更大的窗口大小。
如果空闲空间小,则可以认为应用程序处理速度比较慢,就可以让发送方发送的慢一些,设置一个更小的窗口大小shu
TCP接收方接收到数据的时候,就会把接收缓冲区剩余空间大小通过ACK数据包反馈给对方,例如
流量控制,并不是TCP独有的机制,其他的协议可能也会涉及流量控制
六.拥塞控制
拥塞控制与流量控制是有关联的,也是“踩刹车”
虽然TCP有了滑动窗⼝这个⼤杀器,能够⾼效可靠的发送⼤量的数据.但是如果在刚开始阶段就发送⼤量的数据,仍然可能引发问题。
因为⽹络上有很多的计算机,可能当前的⽹络状态就已经⽐较拥堵.在不清楚当前⽹络状态下,贸然发送⼤量的数据,是很有可能引起雪上加霜的。
如下图,有一个节点本身负载已经很高,如果A依旧快速发送数据包,这个节点可能就直接丢包了
但由于中间节点数量多,每次传输数据走的路径还不一样,哪一个节点负载高难以精确的发现
那么要怎么衡量节点的负载来控制发送速度?
拥塞控制中,把中间传输的节点,视为一个整体,不关注具体的实现细节。
通过做实验的方式,找到一个合适的发送速度(面多加水,水多加面)
例如:1.先按照一个比较小的速度发送数据,数据非常畅通,没有丢包,说明网络传输数据整体比较畅通,就可以加快发送速度
2.增大到一定的速度后,发现丢包了,说明网络上可能存在拥塞,就减慢发送速度
3.减速到一定速度后,发现不丢包了,则又开始增加数据发送速度
........
如此反复
拥塞控制的窗口是动态变化的,需根据实际情况来调整
拥塞控制和流量控制都是踩刹车,这两个机制会同时起作用,最终实际发送发送窗口的大小,取决于上述两个机制得到的方式窗口的较小值。
流量控制与拥塞控制都是对TCP可靠传输的补充
七.延时应答
延时应答的目的是为了提高效率,尽可能降低可靠传输带来的性能影响。
发送方发送数据时,接收接收后不着急马上返回ack,而是数据发送一定数量(或可以按照一定时间)后,再返回ack。
八.捎带应答
捎带应答是再延时应答的基础上,提高效率的机制
把返回的业务数据和ack合二为一(减少包的数量,提高效率)。
正常情况下,发送方和接收方数据发送为“一问一答”,ack和发送数据业务之间存在着时间间隔,无法合并。
但是ack有着延时应答,可以将ack发送的时间往后拖,这一拖,可能赶上发送数据业务的时间,于是发送数据业务时,可以把ack也一起带上。
四次挥手中,FIN和ACK无法合并也是因为两个数据包之间存在着时间间隔。
但如果此时触发延时应答,ACK等待FIN发送时捎带发送,那么四次挥手也能够变成三次挥手
九.面向字节流
TCP协议传输时是通过字节流传输的,前文已经介绍过,这里主要介绍面向字节流所产生的粘包问题。
什么是粘包问题??
以图为例,当A向主机发送数据时,数据到达接收缓冲区
当应用程序读取接收缓冲区时,有各种读法(如aa,abb,bccc等),但“aaa”,“bbb”,“ccc”才是正确的读法,如不为这样的读法,应用程序读取的数据包与原数据包有所偏差,会产生不同的结果。
粘包问题就是应用层数据包在TCP缓冲区中连城一片,粘在一起。
应如何解决粘包问题?
方案一:
关键在于明确每个数据包的边界,可通过分隔符来区分包和包的边界。
方案二:
约定每个应用层数据包的长度,利用数据包开头的两个/四个字节来定义长度
十.异常处理
在遇到一些异常情况时,TCP协议有着解决问题的方案
1)进程崩溃
在Java中表现为抛出异常,但没人catch,最终异常到了JVM里,进程直接崩溃
在这过程中,操作系统会进行善后,会关闭文件描述表里对应的文件,socket文件也会触发正常的关闭流程(四次挥手)
2)主机关机(正常流程)
操作系统会关闭掉所有的进程,关闭的过程中同样会进行四次挥手。
此时有两种情况
a)当四次挥手快时,四次挥手结束后主机关机
b)当四次挥手慢时,可能每来得及挥完就关机了(如图)
此时,B应没收到ACK,就会触发超时重传,可能会重传很多次,但达到上限后只能单方面主动放弃连接
3)主机掉电(拔电源)
分为两种情况
a)发送方掉电
此时B会发送探测报文,若A有ACK,说明A没有掉。
如果多次发送探测报文,没有回复,则认为A掉了
探测报文是周期性发送的,同时这个报文也是探测对方“生死”的,也被称为“心跳包”
b)接收方掉电
此时,B就不会发送ACK给A了,A会触发超时重传,重传的数据也没有响应,多次后会重置连接,重置连接没有响应后,A会单方面断开连接
4)网线断开
和主机掉电非常相似
站在A的视角,ACK收不到,超时重传,重置连接,最后单方面放弃连接
站在B的视角,探测报文没有回复,最后单方面放弃连接
TCP不只有10个机制,本篇只是提到较为核心的机制
以上便是全部内容,如有不对,欢迎指正