目录
- 可靠传输实现机制
- 确认应答
- 超时重传
- 连接管理
- 滑动窗口
- 流量控制
- 拥塞控制
- 延迟应答
- 捎带应答
可靠传输实现机制
确认应答
这是保证可靠性的最核心机制
TCP将每个字节的数据都进行了编号。即为序列号。
这是为了防止连续发多条数据的时候,可能出现“后发先至”的情况,也就是为了可靠性传输
由于TCP是面向字节流的,不是以“条”为单位来传输的。这里是第一条11000,第二条10012000,也可以第一条11500,第二条15012000。
- 是针对字节编号的,不是针对“条”
- 应答报文也是要和收到的数据的序号相关联的,但不是“相等”
此时就需要有办法区分出当前的这个报文是普通报文还是应答报文
就用到了6位标志位中的 ACK
ACK 为 0 表示这是一个普通的报文。此时只有 32 位序号是有效的
ACK 为 1 表示这是一个应答报文,这个报文的 序号 和 确认序号 都是有效的
ACK => acknowledge 应答
每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。
TCP报文中,开始序号+长度-1 => 最后一个序号(但TCP报文中,没有保存最后一个序号,只有开始序号,但可以通过这样算)
核心一句话:确认应答,是TCP保证可靠性的最核心机制。而超时重传是TCP可靠性机制的有效补充
网络上说TCP保证可靠性的核心机制是“三次握手”,这是错的!!!
超时重传
丢包,在网络上很可能出现发一个数据然后丢了
网络传输过程中,路由器/交换机是“交通枢纽”。如果设备太繁忙,后面新来的数据等太久了,就可能被丢弃了,网络负载越高,越繁忙,就越容易被丢包
举例:你发信息给别人,信息发丢了但你不知道,但你知道你没有收到应答,因此你就会重新发一次
而超时重传,就是等待一定时间,超过一定的时间之后,再进行重传。
超时重传相当于针对确认应答,进行的重要补充
发的信息本身丢包了
发送端发送数据给接收端之后,可能因为网络拥堵等原因,数据无法到达接收端;
如果发送端在一个特定时间间隔内没有收到接收端发来的确认应答,就会进行重发;
但是,发送端未收到接收端发来的确认应答,也可能是因为ACK丢失了;
因此接收端会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包,并且把重复的丢弃掉。
这时候我们可以利用前面提到的序列号,就可以很容易做到去重的效果。
以上两种情况无法区分,那就只能都重传咯~~
那么,如果超时的时间如何确定?
最理想的情况下,找到一个最小的时间,保证 “确认应答一定能在这个时间内返回”。
但是这个时间的长短,随着网络环境的不同,是有差异的。
如果超时时间设的太长,会影响整体的重传效率;
如果超时时间设的太短,有可能会频繁发送重复的包;
TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间。
Linux中(BSD Unix和Windows也是如此),超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。
如果重发一次之后,仍然得不到应答,等待 2*500ms 后再进行重传。
如果仍然得不到应答,等待 4*500ms 进行重传。依次类推,以指数形式递增。
重传次数达到一定程度,此时就会尝试“重置”TCP连接,TCP复位报文,是6位标志位中的RST,如果为1就是一个复位报文就尝试重新连接了
累计到一定的重传次数,如果仍无法成功,TCP认为网络或者对端主机出现异常,强制关闭连接,放弃连接了。
连接管理
在正常情况下,TCP要经过三次握手建立连接,四次挥手断开连接
握手:发一个打招呼的数据(不携带业务信息),使用这个打招呼触发“特定场景”
三次连接:A和B完成连接的过程,就需要“三次”这样的打招呼的数据交互
为啥可以合并?因为封装和分用
合并之后,节省了封装和分用的过程,降低了成本提高了效率
TCP三次握手的过程是怎么样的?
三次握手的意义是啥,要完成什么目的?初心是什么?
- 本质上是“投石问路”
- TCP要想保证可靠传输,可靠传输的前提是网络路径得畅通
- TCP三次握手,就是要验证网络通信是否通畅,以及验证每个主机的发送能力和接收能力是否正常
用打游戏连麦理解三次握手:把麦克风比作发送能力,耳机比作接收能力
第一次:
A发送“hellohellohello”,为了验证A的麦克风是否正常以及B的耳机是否正常
B收到“hellohellohello”,B就知道了A的麦克风没问题,B的耳机没问题
第二次:
B发送“hellohello”,为了验证B麦克风是否正常以及A的耳机是否正常
A收到“hellohello”,A就知道了A的耳机没问题,B的麦克风没问题
注意:到这一步,A是知道了双方的耳机和麦克风都没问题,但B还不知道B的麦克风和A的耳机是否正常,B只知道B的耳机和A的麦克风是没问题的
第三次:
A发送“hello”,就是对上述的“hellohello”进行回应
B收到“hello”,B就知道了B的麦克风没问题,A的耳机没问题
到了这一步,AB双方才都知道AB双方的麦克风和耳机都没问题
为什么是三次握手?
恰好三次,就能验证好双方的发送能力和接收能力均正常,并且把这样的信息同步给了双方
两次是否可以?
很明显不可以,虽然两次握手,可以验证完成通信能力的正确性,但是服务器这边还不知道这样验证通过的信息
四次是否可以?
可以但没必要(把中间两次拆成两次),三次即可,中间能合并就合并,这样能提高效率
三次握手还能起到“消息协商”这样的效果
通信的时候涉及到一些参数,需要双方保持一致,通过协商来决定参数具体是多少
TCP通信过程中,有很多信息是需要进行协商的。比如双方的序号从几开始(一般不会从0/1开始)
这样做主要是保证,两次连接,消息的序号能够有较大的差异,从而好去判定出某个消息是否属于这个连接
综上:三次握手,的初心主要就是两方面:
-
投石问路,验证通信路径是否畅通,双方的发送/接收能力是否正常
-
协商必要的参数,使客户端和服务器使用相同的参数进行消息传输
断开连接,四次挥手
连接:通信双方,各自在内存中保存对端的相关信息,如果不需要连接了,就得及时的释放上述存储空间
四次挥手的流程和三次握手非常相似
三次握手必定是客户端主动发起,四次挥手则不一定,服务器也可以发起,不过大多数情况是客户端主动发起
四次挥手为什么是四次,三次可以吗?
四次挥手有时候确实可以三次,但有时候不行。中间这两次不一定能合并
FIN的触发,是应用程序代码来控制的,调用
socket.close()
,或者进程结束,就会触发FIN相比之下,ACK则是内核控制的,收到FIN就会立刻返回ACK
如果服务器始终不进行close
会怎么样?客户端的连接就始终不关闭吗?
此时,服务器的TCP状态,就处于CLOSE_WAIT
状态(还没close时),如果此时close了就发送FIN并且进入LAST_ACK
状态,如果一直不close此时仍然是CLOSE_WAIT
状态
站在服务器的角度,虽然这里的连接没有关闭,但是此时这个连接已经不能正常使用了
- 针对当前socket进行读操作,如果数据还没读完(缓冲区还有数据),就能正常读到;如果数据已经读完了,此时就会读到 EOF(对于字节流来说,返回 -1。如果是scanner,hasNext就会为 false)
- 针对当前socket进行写操作,直接就会触发异常
无论如何此时连接已经无法正常使用了,关闭是唯一的选择。
极端情况代码出现bug,忘记写close了怎么办?
此时站在客户端角度,迟迟收不到对方的FIN,也会进行等待。如果一直等,都等不到,就会单方面放弃连接(客户端直接把自己保存的对端信息给删了,释放了)
目标:就是释放资源,能双方顺利释放最好,如果不方便,单方面删也行。
如果通信过程中,出现丢包了,又咋处理?
这里也是涉及到超时重传的。三次握手,和四次挥手,也都是带有重传机制的
尽可能重传,如果重传仍然失败,连续多次,此时仍然会单方面释放连接
- 如果是第一组FIN/ACK丢失,客户端直接重传FIN即可
- 如果是第二组FIN丢失,服务器重传FIN即可
- 如果是第二组ACK丢失,以下详细说明
站在A的角度,当收到这个FIN之后,并且发出去ACK了,此时A可以视为四次挥手结束,直接释放连接了吗?
不可以!!!
最后一个ACK还是很有可能丢包的。
如果最后一个 ACK 丢失, 服务器就会重新传过来一个,FIN,此时如果客户端已经把连接释放了,重传的 FIN 就无人能够进行 ACK了。
因此,就需要让客户端在发出去最后一个 ACK 之后,让连接再等一会。(主要就是看等的过程中会不会收到对方重传的 FIN)如果等了一定时间之后,对方还没有重传 FIN,就认为 ACK 已经被对方收到了此时客户端才能正确释放连接
同理这里客户端等多久?
等待时间是网络上任意两点之间传输数据的最大时间(定义为MSL)*2
举个生活例子:你送你家孩子去上幼儿园,假设你心比较大并不知道要不要上课,孩子进入幼儿园要花费t时间,你就等个2t时间看看是不是真上学,2t之后孩子没回头那你就走了
滑动窗口
作用:提高传输效率(更准确的说是让TCP在可靠传输的前提下,效率不要太低)(类似亡羊补牢的机制,是为了尽量止损)
使用滑动窗口,不能使TCP比UDP快,但可以缩小差距
刚才我们讨论了确认应答策略,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候。
没有滑动窗口,会带有确认应答
这样的传输,能够保证可靠性,但是大量的时间,都消耗在等 ack 上了
使用滑动窗口,就是为了缩短上述等待时间
既然这样一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大的提高性能(其实是将多
个段的等待时间重叠在一起了)。
一次性发出一组数据,发这一组数据的过程中,不需要等待ACK就直接往前发
此时,就相当于使用“一份等待时间”等四个ACK
把一次发多少数据,不用等ACK这样的大小,称为“窗口”
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
发送前四个段的时候,不需要等待任何ACK,直接发送;
收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据;依次类推;
操作系统内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;
窗口越大,则网络的吞吐率就越高;
滑动窗口,是一个“形象的比喻”,实际上本质就是批量发送数据。这样就可以缩短等待时间,比之前能提升一定的效率(缩短不是没有,仍然需要花时间等待,传输效率仍然不会比 UDP 更高)
那么如果出现了丢包,如何进行重传?这里分两种情况讨论。
- 数据报丢了
- ACK丢了(这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认)
比方说,假如1001确认序号丢了,2001确认序号到了,表示2001之前的数据都收到了,也包括1~1000
滑动窗口下,超时重传
当某一段报文段丢失之后,发送端会一直收到 1001 这样的ACK,就像是在提醒发送端 “我想要的是 1001” 一样;
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答,就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后,再次返回的ACK就是9001了(因为2001 - 9000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中;
这种机制被称为 “高速重发控制”(也叫 “快重传”)。
其实就是超时重传,只是结合滑动窗口,产生的变形操作
流量控制
流量控制是作为滑动窗口的补充
滑动窗口越大,传输效率越高,但也不能无限大,如果太大接收方可能处理不过来了,或者是使传输的中间链路出现处理不过来,这样就会出现丢包,就得重传了,窗口大并没有提高效率,反而影响了效率。流量控制就是给滑动窗口刹刹车,避免窗口太大,接收方处理不过来
其实流量控制也是在跟生产者消费者模型有关,发送端生产速度很快,接收端消费速度跟不上就很快满了,满了还发数据就容易丢包
因此,流量控制就是根据接收方的处理能力,来限制发送方的发送速度(窗口大小)
因此TCP支持根据接收端的处理能力,来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control)
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,通过ACK端通知发送端;
窗口大小字段越大,说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口之后,就会减慢自己的发送速度;
如果接收端缓冲区满了,就会将窗口置为0;这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。
拥塞控制
光考虑接收方,还是不够的,还需要考虑中间链路的处理能力(拥塞控制)
中间如果某个环节,转发能力特别差,此时发送端的发送速度就不应该超过这里的值
具体怎样去衡量中间设备的转发能力呢?
把中间的设备都看成一个整体而是采取“实验”的方式,动态调整,产生出一个合适的窗口大小
- 使用一个较小的窗口传输。如果传输通常,就调大窗口
- 使用一个较大的窗口传输,如果传输丢包(出现拥堵),就调小窗口
拥塞窗口:在拥塞控制机制之下,采用的窗口大小
此处引入一个概念程为拥塞窗口
发送开始的时候,定义拥塞窗口大小为1;
每次收到一个ACK应答,拥塞窗口加1;
每次发送数据包的时候,将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的窗口;
TCP中拥塞控制具体是这样展开的:
- 慢启动:刚开始进行通信的时候,会使用一个非常小的窗口,先试试水。
像上面这样的拥塞窗口增长速度,是指数级别的。“慢启动” 只是指初使时慢,但是增长速度非常快。
为了不增长的那么快,因此不能使拥塞窗口单纯的加倍。
此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候,不再按照指数方式增长,而是按照线性方式增长
- 指数增长:在传输通畅的过程中,拥塞窗口就会指数增长(* 2)
- 线性增长:指数增长当拥塞窗口达到一个值之后,就会从指数增长,转换成线性增长(+n)
- 拥塞窗口回归小窗口:当窗口大小增长过程中,如果传输出现丢包,认为当前网络出现拥堵了
此时就会把窗口大小调整成最初的小窗口,继续回到之前 指数增长 + 线性增长 的过程
另外此处也会根据当前出现丢包的窗口大小,调整值(指数增长 -> 线性增长)
当TCP开始启动的时候,慢启动阈值等于窗口最大值;
在每次超时重发的时候,慢启动阈值会变成原来的一半,同时拥塞窗口置回1;
少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞;
当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立刻下降;拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。
实际发送方的窗口=min(拥塞窗口,流量控制窗口)(此处不光考虑接收方的处理能力,更要考虑中间节点的处理能力)
拥塞控制和流量控制(这两个就可以视为保证可靠性的机制),共同限制了滑动窗口机制,可以使滑动窗口能够在可靠性的前提下,提高了传输效率了。
延迟应答
提高传输效率的机制,依然是围绕滑动窗口琢磨的
是否有办法在条件允许的基础上,尽可能的提高窗口大小呢?
如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小。因此就需要在返回ACK的时候,拖延一点时间,利用这个拖延的时间,就可以给应用程序腾出来更多的消费数据的时间。接受缓冲区的剩余空间就会更大了
假设接收端缓冲区为1M。一次收到了500K的数据;如果立刻应答,返回的窗口就是500K;
但实际上可能处理端处理的速度很快,10ms之内就把500K数据从缓冲区消费掉了;
在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来;
如果接收端稍微等一会再应答,比如等待200ms再应答,那么这个时候返回的窗口大小就是1M;
一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
那么所有的包都可以延迟应答么?肯定也不是;
数量限制:每隔N个包就应答一次;(滑动窗口)
时间限制:超过最大延迟时间就应答一次;(非滑动窗口)
具体的数量和超时时间,依操作系统不同也有差异;一般N取2,超时时间取200ms;
捎带应答
在延迟应答的基础上,引入的进一步提高效率的方式。延时应答是让ACK传输的时机更慢;捎带应答,基于延时应答,让数据进行合并
为啥说四次挥手可能是三次?
主要就是 延时应答和捎带应答 起到的效果