网络(3)--TCP

前言

上篇文章介绍了UDP和部分TCP的内容,这篇文章继续介绍TCP剩下的内容!

TCP原理

滑动窗口(效率机制)

TCP要保证的不仅仅是可靠性,还有效率!!!
提高可靠性,意味着损失效率!!!

此时A这边就花了大量的时间在等待ACK,想要提高效率,就需要缩短等待时间,批量发送数据了!!!
一次多发数据,一次等多个ACK!!!

这里就是批量发送四条数据,发完之后统一等待ACK
每收到一个ACK就立即发送下一条(不是收到4个ACK再发下一组
使用一份时间,等待多个ACK,总的等待时间缩短了,整体的效率就提升了!!!

注意!!!

UDP更快!
TCP再怎么提高效率也不可能比UDP快!!!
TCP的效率机制,本质上是让性能折损少一点!!!

批量传输,叫做滑动窗口
批量不是无限发送,是发送到一定程度,就等待ACK,不等待直接发送的数据是有上限的
而且是回来一个ACK就立即发下一条,就相当于总的要批量等待的数据是一致的!
批量等待数据的数量,就称为"窗口大小"!

白色区域是等待窗口
当收到2001这个ACK意味着1001-2001这个数据得到确认,就会立即发下一个5001-6001这个数据
此时就感觉窗口还是这么大,但往后挪了一个格子,如果收到的ACK非常快,这个窗口就在快速往后滑动!

批量发送的过程中,出现丢包怎么办?
可靠性第一,效率靠后!!!

1.数据包已经到达,ACK丢了

这种情况相当于什么事都没有!!!对于可靠性没有影响!!!
确认序号的含义,表示该序号之前的数据都已经收到了,后一个ACK能够涵盖前一个ACK的意思!!!
当收到3001这个ACK的时候,此时发送方就知道了3001之前的数据都收到了,2001也收到了,丢了无所谓!!!

2.数据包直接丢了!!!

当把1001-2000这个数据重传后,b收到返回ACK是7001!!!而不是2001!
因为2001-7000这些数据B都已经受到过了

上述重传的过程,没有任何冗余的操作,丢了数据才会重传,不丢的数据不必重传
整体速度是比较快的,这个重传过程也称为快速重传

流量控制(安全机制)

流量传输也是保证可靠性的机制!

滑动窗口,批量发送,窗口越大,相当于批量的数据越多,整体的速度就越快.
但是,越快越好吗?
如果你发的太快,瞬间把接收方接收缓冲区打满了,接下来继续发送,此时数据就会丢包,这种情况得不偿失,不如发的慢点!
通过流量控制,本质上就是让接收方来限制一下发送方的速度

报文中,携带一个"窗口大小"这样的字段
当ACK为1的时候,ACK报文此时窗口大小就会生效,这里的值就是建议发送方发送的窗口大小

接收方是如何计算窗口大小的?
简单粗暴,直接拿接收缓冲区,剩余空间作为窗口大小!!!

1.接收缓冲区初始的剩余空间
2,此时A根据3000这个窗口大小,批量发送了这些数据
3,此时,接收缓冲区满了!发送方就暂停发送了!
4.当发送方发现对方满了之后,就会暂停发送,但是仍然会每隔一段时间触发一个窗口探测报文,如果探测一会发现这里不是0了腾出空间了,就可以继续发送了!

上述过程是吧返回的窗口大小,当作实际的窗口,实践中可能会有出入(拥塞控制)
发送方的窗口大小=流量控制+拥塞控制

拥塞控制(安全机制)

在传输路劲上,任何一个设备,处理能力如果遇到瓶颈都会对整体的传输速率产生明显的影响!
拥塞控制就是衡量中间节点传输的能力
通过实验的方式,找到一个合适的发送速率!!!
开始的时候,按照一个小的速率发送,如果不丢包可以提高一下速率(扩大窗口大小),如果出现丢包,则立即把速率再调小,重复上述过程

另外,网络的拥堵情况,也不是一成不变的,是在时刻变化中的,此时拥塞控制这样的策略也能很好的适应变化的网络环境

拥塞窗口(拥塞控制,实验出来的窗口)
实际发送方的窗口大小=min(拥塞窗口,流控窗口)

1.刚开始传输,会给一个非常小的窗口(比较小的初始速度)
2.每次翻倍,指数增长非常快,可以让窗口大小短时间内达到一个比较大的值,快速接近当前网络传输路径的能力瓶颈
3.指数增长达到一定的阈值就变成了线性增长,避免一下突然超过上限很多,可以使传输速度逐渐接近传输上限!
4.增长到一定的成都,出现丢包,认为当前的窗口大小,已经达到当前路劲上的传输上限了!
5.此时有立即把窗口大小回归到一个比较小的初始值重复上述过程

延时应答(效率机制)

延时应答提高传输效率

应用程序从缓冲区中读数据
如果立即返回一个ACK,此时ACK里带有一个窗口大小,设为n
如果稍等片刻,再返回ACK,此时ACK里的窗口大小,大概率比n要大!(等的这一小会儿,应用程序从接收缓冲区里消费了一批数据了)

比如老师问我为什么落下了10次作业
1.我立即回答,我落下了10次作业我会马上补上的!
2.装作没看见,立马补作业,补了5次作业再和老师说,老师我落下了5次,很快就补上!

延时应答的效果就是通过这个延时,让接收方应用程序,趁机多消费点数据,此时反馈的窗口大小就会更大一点,此时发送方的效率也就能更快一点(同时也能满足让接收方能够处理过来)

捎带应答

客户端服务器之间的通信模型通常是"一问一答"这种模式

ACK是内核负责立即返回
响应中,应用程序,通过write写的数据通过一系列代码执行到才返回
这两个时机本来是不同的,但是延时应答!!!此时ACK就可能稍等一下再发送,很可能就和响应合成一个数据报!!!

为什么四次握手,有可能是三次挥完???
捎带应答起到的效果!!!

面向字节流

有一个问题暗藏杀机----粘包问题!!!

同学的缓冲区是这样的,同学的视角,从哪到哪是一句完整的话??
由于我习惯同学开头,所以同学视角是可以区分的

我的视角,同学的话是难以区分的
所谓的"一句话"就相当于一个"应用层数据报"
当A给B连续发了多个应用层数据报之后,这些就都累积到B的接收缓冲区中,紧紧挨在一起,此时B的应用程序在读数据的时候,就难以区分从哪到哪是一个完整的应用层数据报,很容易读出半个包/一个半

定义分隔符和约定长度都是粘包问题有效的解决方案

异常情况

1.进程关闭/进程崩溃
进程没了,文件随之被关闭,虽然进程没了,但链接还在,仍然可以继续四次握手

2.主机关机(正常流程关机)
先杀死所有的用户进程
也会触发四次挥手,如果挥完更好,如果没挥完,比如,对方发fin过来了,没来的及ACK就关机了,此时就会重传fin,重传几次之后,发现都没有ACK,尝试重置连接,如果还不行,就直接释放连接

3.主机掉电(拔电源)
瞬间就关机,来不及进行任何挥手操作
(1)对端是发送方
对端不会收到ACK=>超时重传=>重置连接=>释放连接
(2)对端是接收方
对端是没法立即知道
TCP内置了心跳包保活机制

4.网络断开
同主机掉电

TCP小结

1.确认应答
2.超时重传
3.连接管理
4.滑动窗口
5.流量控制
6.拥塞控制
7.延时应答
8捎带应答
9.面向字节流
10.异常处理

TCP 和 UDP的差别
TCP可靠传输,效率没那么高
UDP不可靠传输,效率高

绝大部分场景,都可以使用TCP
TCP里还有很多别的机制!!!

今天的文章到这里就结束了!!!