四、滑动窗口机制
五、流量控制
六、拥塞控制 (安全机制)
七、延迟应答 (效率机制)
八、捎带应答 (效率机制)
九、粘包问题
十、保活机制
TCP总结
四、滑动窗口机制
滑动窗口机制,是在可靠性的前提下,进一步地提高传输效率
认识滑动窗口
一发一收的方式:TCP 协议需要对数据进行确认后,才可以发送下一个数据包,如图:
如上图,发送端每发送一个数据包,都需要得到接收端的确认应答以后,才可以发送下一个数据包,是一问一答的串行过程;即每次传输数据都需要等待一个对应的等待时间,那么传输 N 份数据,就需要等待 N 次应答时间,总的传输时间:N 份数据传输时间 + N 份应答传输时间
一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大地提高性能(其实是将多个段的等待时间重叠在一起了),如图:
滑动窗口本质上是批量传输数据
总的传输时间:N 份数据传输时间重叠成了一份时间,N 份应答传输时间重叠成了一份时间,相当于把多份数据的传输时间和等待 ACK 的时间压缩成一份了,总的等待时间少了,传输效率也就高了
a. 窗口
窗口大小: 不等待 ACK 的情况下,批量发送的最大数据量,就叫"窗口大小" (如上图,就是4000个字节,4个字段)
-
发送前四个字段的时候,不需要等待任何 ACK,直接发送;
-
收到第一个ACK后,滑动窗口向后移动,继续发送第五个字段的数据,依次类推;
-
操作系统内核为了维护这个滑动窗口;需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;
-
窗口越大, 则网络的吞吐率就越高
b. 滑动
窗口范围内的数据是在等待这些数据的 ACK (已经被发送出去)
如上图,当发送方收到 2001 的 ACK,意味着 1001 - 2000 的数据对方已经接收,此时立刻继续传输 5001 - 6000 的数据,则等待 ACK 的数据包的序号就是 2001,3001,4001,5001
丢包问题处理
丢包的两种情况如图:
情况1: 确认应答 (ACK) 丢包
不需要进行额外的处理;在这种情况下,部分 ACK 丢了并不要紧,因为可以通过后续的 ACK进 行确认
理解"确认序号"的含义
从当前序号开始,前面的数据都已经正确到了
如上图,是 1001 的 ACK 丢失,2001 的 ACK 没丢,此时,发送方收到 2001 之后,就会认为 1 - 1000 这个数据也是顺利到达的,1001 丢了无所谓,2001 的 ACK 能够包含 1001 ACK 中的信息
情况2: 数据包丢失
如下图,若是 1001-2000 丢失,然后 2001-3000,3001-4000 等后边的几个数据都顺利到达,此时主机 B 反馈的 ACK 的确认序号始终是 1001;
此时若主机 A 发现连续几个 ACK 都是1001,主机 A 就知道,1001 这个数据丢失,就会重传 1001;
在重传 1001 之前,收到的确认序号都是 1001;
当主机 B 收到 1001 这个数据的时候,由于 2001-7000 这些数据前边已经收到过,接下来的 ACK 就从 7001 开始;
此处的重传,只是重传丢了的数据,其他数据不需要额外重传—— 快速重传(搭配滑动窗口下的超时重传)
"乱序"传输:
五、流量控制
流量控制: 根据接收方的处理能力来反向制衡发送方的发送效率(窗口大小) (通过接收缓冲区的 “剩余空间大小” 来决定发送方的速率)
窗口大小不能无限大,传输速率太快,接收方可能处理不过来
在使用滑动窗口机制进行数据传输时,发送方根据实际情况发送数据包,接收端接收数据包;由于接收端处理数据包的能力是不同的,因此可能出现两种情况:
-
若窗口过小,发送端发送少量的数据包,接收端很快就处理了,并且还能处理更多的数据包;当传输比较大的数据时需要不停地等待发送方,就会造成很大的延迟
-
若窗口过大,发送端发送大量的数据包,而接收端处理不了这么多的数据包,就会堵塞链路;若丢弃这些本应该接收的数据包,又会触发重发机制
(第一次的窗口大小是根据链路带宽的大小来决定的) ,发送数据包,接收端接收这些数据包,并返回确认应答包,告诉发送端自己下次希望收到的数据包是多少(新的窗口大小),发送端收到确认应答包以后,将以该窗口大小进行发送数据包
-
接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,通过 ACK 端通知发送端
-
窗口大小字段越大,说明网络的吞吐量越高
-
接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端
-
发送端接受到这个窗口之后,就会减慢自己的发送速度
-
如果接收端缓冲区满了,就会将窗口置为0;这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端
如下图:
图解:
-
假设初始窗口大小为4000,发送端发送 4 个数据包,分别为 1-1000,1001-2000,2001-3000 和 3001-4000
-
接收端接收数据包,接收到 1-1000 数据包之后,设置窗口大小为 3000,告诉发送端自己现在只能处理 3 个数据包,下一次请发送 3 个数据包
-
发送端接收到确认应答包,查看到接收端返回窗口大小为 3000,知道接收端处理了 1 个数据包;接着继续发送: 1001-2000,2001-3000 和 3001-4000
-
接收方收到之后,缓冲区只能处理 2 个数据包,发过去的第 3 个数据包 3001-4000 没有被处理;这说明此时接收端只能处理 2 个数据包,第 3 个数据包还需要重新发送
-
当窗口为 0 时,发送方会暂停发送,也会定时发送一个探测报文;因为接收缓冲区的数据随时可能被取走,一旦取走,就可以接收新的数据(滑动窗口大小是动态变化的)
六、拥塞控制 (安全机制)
拥塞控制是考虑网络传输路径上的拥堵程度
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据;但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题;因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵,在不清楚当前网络状态下,贸然发送大量的数据,是很有可能雪上加霜,因此,TCP引入 慢启动 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据
线增积减 (和式增加,积式减少)
像上面这样的拥塞窗口增长速度,是指数级别的,“慢启动” 只是指初使时慢,但是增长速度非常快,具体的增长如下图:
刚开始的时候从1指数增长,到达阈值后开始线性增长,如果出现网络阻塞,直接减小到初始值,然后再次指数增长到达新的阈值(新阈值为上次阻塞窗口大小的一半),再次线性增长直到网络阻塞,一直这样动态变换循环
为啥要动态变化??
网络的拥堵情况是瞬息万变的,我们要随时根据网络的实际情况进行动态调整 (随时适应网络的变化过程)
七、延迟应答 (效率机制)
目的是为了提高效率,在流量控制的基础上,尽量返回一个合理但又比较大的窗口
在前面我们提到,在发送端发送数据后,接收数据的主机需要返回 ACK应答,此时若立刻返回,窗口可能比较小 (因为缓冲区的数据只处理了一部分),所以 TCP 采用了延迟应答机制,举例:
不带延迟应答:
有一个超市,假设泡面库存最多存放100箱,当前已经存了80箱,空余20箱;
第二天一早,送货小哥来问:“老板,你明天需要多少面?”
老板:“你最多送20箱就行。”
带延迟应答:
第二天一早,送货小哥来问:“老板,你明天需要多少面?”
老板:“我晚上的时候打电话告诉你需要多少。”
(可能白天又卖出了10箱,第二天最多送10箱即可)
延时应答其实就是让 ACK 的发送时间晚一会儿 (不影响可靠性的前提下);
延迟的时间中就会给应用程序提供更多的消费数据的机会,此时时间到了,再发送 ACK 的时候,得到的窗口大小(接收缓冲区的剩余空间就会更大一些)
窗口越大,网络吞吐量就越大,传输效率就越高;我们的目标是在保证网络不拥塞的情况下尽量提高传输效率
问:所有的包都可以延迟应答么?
肯定不是
-
数量限制: 每隔 N 个包就应答一次 (N一般为2)
-
时间限制: 超过最大延迟时间就应答一次 (时间一般取200 ms,延迟应答的等待时间不能超过超时重传的时间,不然就重传了)
八、捎带应答 (效率机制)
在延迟应答的基础上,为了进一步提高程序运行效率而引入的机制
在很多情况下,客户端和服务器的通信模式一般都是 Request - Response 模式,即 “一问一答”
如图:
注意:
三次握手中间的 SYN 和 ACK 都是由内核决定的,不涉及不同的时机
上述提到的四次挥手的过程,ACK 是内核决定的,发的 FIN (close方法) 是应用程序代码决定的
九、粘包问题
严格说,粘包问题不是 TCP 自身的机制,而是面向字节流传输所具备的共性问题
粘包,指粘的是应用层数据包,导致数据在处理的时候,容易读取半个应用层数据包
面向字节流: 指的是一次读一个字节,或者一次读两个字节,或者一次读 N 个字节都行
举例:双方建立连接,需要在连接后一段时间内发送不同结构数据,如连接后,有好几种结构
-
“你好不好”
-
“好个P”
读多少个字节才是一个完整的应用层数据包,这个是不清楚的
若一次读一个汉字,读出来就是 “好”;若一次读三个汉字,读出来就是 “好个P”
读法不一样,最终的含义差异也很大;读取应用层数据,就不应该只读半个包
如何避免粘包问题?
归根结底就是一句话,明确两个包之间的边界
TCP 协议本身不帮你区分应用层数据包,相对而言,UDP 协议没这个问题 (UDP 协议就是按照数据包为单位进行收发的)
-
方式1 - 使用分隔符
比如,上述回答改为 “好个P;”
用分号 ;当做两个包的分隔符,读数据,一直读到分号;才认为是一个完整的应用层数据包
应用层协议,是程序猿自己来定的,只要保证分隔符不和正文冲突即可**
-
方式2 - 明确包的长度
比如,上述用例改为 “4你好不好3好个P”
先读取最开始的四个字节,得到包的长度3;继续读取3个汉字,于是就读取一个完整的包
HTTP 协议基于 TCP 的应用层协议,自己就会处理好粘包问题,上述两种方式都使用到了:
对于 GET 请求,分隔符就是空行
对于 POST 请求,Content-length 来指定包的长度
思考:对于UDP协议来说,是否也存在 “粘包问题” 呢?
-
对于UDP,如果还没有上层交付数据,UDP的报文长度仍然在。同时,UDP是一个一个把数据交付给应用层;就有很明确的数据边界
-
站在应用层的站在应用层的角度,使用UDP的时候,要么收到完整的UDP报文,要么不收;不会出现"半个"的情况
十、保活机制
双方建立交互的连接,并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会,那么在长时间无数据交互的时间段内,交互双方都有可能出现掉电、死机、异常重启,还是中间路由网络无故断开、NAT超时等各种意外
在这些 “异常情况” 下,TCP 对于连接会有一些特殊的处理
举例:
1.进程崩溃: 这种情况,TCP 连接会正常四次挥手 (只要是进程退出,都会自动关闭相关的文件)
2.主机关机(按照流程关机):关机的时候会强制先杀进程,杀进程过程之中就要进行四次挥手了
3.主机断电 / 网线断开:
-
a) 接收方断电。 对端尝试发送消息的时候,就会出现没有 ACK 的情况 — 于是就会触发超时重传 — 重传一定次数,就会重置连接 — 放弃连接
-
b) 发送方断电。对端尝试接收消息,对于接收端来说,本来也不知道发送方什么时候发送,难道就一直等吗?
解决方案 — 心跳包 TCP 的通信双方,即使在没有数据交互的过程中,也会定时相互传输一个没有数据业务意义的 “心跳包”,只是为了证明 “我活着”,一旦隔了一段时间都没有收到对方的心跳包,就可以认为对端"挂"了
TCP总结
TCP 之所以复杂,是因为它既要保证可靠性,同时又尽可能地提高性能
可靠性:
校验和,序列号
确认应答,超时重传
连接管理,流量控制,拥塞控制
提高性能:
滑动窗口,快速重传
延迟应答,捎带应答
其他:
定时器(超时重传定时器,保活定时器,TIME_WAIT定时器等)