在这里插入图片描述

时间就是性命。
无端的空耗别人的时间,
其实是无异于谋财害命的。
--- 鲁迅 ---

1 拥塞控制

尽管TCP拥有滑动窗口这一高效的数据传输机制,能够确保在对方接收能力下将大量数据可靠发送,但在通信初期若盲目发送大量数据,仍有可能触发网络问题。

当网络出现问题时,通过滑动窗口等机制是没有办法解决的。网络拥塞就是一种情况,网络中需要处理的数据太多了,导致十分堵塞,此时就需要拥塞控制进行管理!那么如何识别出来时网络出现问题呢?当出现了大量报文的丢失问题时,就可以大概率确定网络出现了严重的拥塞问题!

考虑到网络中众多计算机的交互,当前网络状态可能已经处于相对拥堵的状况。在不明确当前网络状况的前提下,大量数据的急速发送很可能加剧网络拥堵,造成“雪上加霜”的效应。

为此,TCP采用了慢启动机制,它首先发送少量的数据包,以此作为“探针”来感知和评估当前网络的拥堵程度。在此基础上,TCP会根据网络的实际状况,逐步调整数据传输的速度,确保数据传输的平稳与高效。这样才能更高效的进行处理! 此处引入一个概念:拥塞窗口

  • 每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口

通过拥塞窗口,可以保证传输的数据不会超出网络的承载能力,也能保证不会超出接收端的接收能力! 网络的状态是浮动的,拥塞窗口的大小也是浮动的!那么主机如何得知拥塞窗口的接近大小是多大呢?这个大小是通过尝试出来的,是一个经验数据!
在这里插入图片描述
发送开始的时候, 定义拥塞窗口大小为 1,接受到ACK时就通过指数规律进行增长,这就是慢启动窗口。指数在变量较大时会发生指数爆炸,所以就有慢启动的阈值!当拥塞窗口超过这个阈值的时候,会改为线性增长,避免造成拥塞!

  • 前期慢,可以慢慢减少网络发送,让网络发送
  • 网络恢复之后,我们的通信过程也要恢复起来,中期增速快,快速提高效率;后期慢线性增长,避免指数爆炸,同时可以准确找到拥塞的边界值!
  • 阈值也是可以动态调整的,可以根据网络拥塞的边界值调整慢启动算法的阈值!

网络中每个主机都使用这样的拥塞控制机制,遇到网络拥塞时,所有主机都调整窗口为1,然后同一个慢启动算法逐渐恢复,最终找到下一次拥塞的临界值,继续调整… 这样动态调节,保证网络传输的效率最大!

2 延迟应答

在发送方和接收方进行通信时,接收方的接收缓冲区收到了来自发送方的一批报文(滑动窗口机制),接收方收到第一个数据时,不会立刻进行ACK,会延迟一会再进行发送!这个延迟时间不会超过超时重传的时间。这个延迟一会,就能保证,向发送方的ACK可以是更大的接收窗口,通过滑动窗口算法,就能让下次并发发送的数据更多!

一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高。 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率!

那么所有的包都可以延迟应答么? 肯定也不是!

  • 数量限制: 每隔 N 个包就应答一次;
  • 时间限制: 超过最大延迟时间就应答一次;

具体的数量和超时时间,依操作系统不同也有差异。一般 N 取 2, 超时时间取 200ms。

延迟应答的效果再单台主机的通信中可能不明显,因为延迟的一会不一定会等到更大的接收窗口。但是网络中并不是只有一台主机!主机的数量是很多的,那么再小的概率,在如此大的基数中也是不容小觑的大小!所以延迟应答的效果在网络中是很棒的!

3 捎带应答

捎带应答(Piggybacking)是TCP协议中一种优化网络传输效率的机制。在TCP通信过程中,数据的发送方和接收方需要通过确认应答(ACK)来确保数据的可靠传输。捎带应答技术允许在数据传输的过程中,将确认应答信息“捎带”在数据包中一起发送,而不是单独发送一个ACK包!

通过我们对TCP报头结构的学习,捎带应答的本质就是在通过6位标志位:

  • URG:指示紧急指针字段是否有效,用于处理紧急数据。
  • ACK:确认号字段是否有效,用于确认已成功接收的数据。
  • PSH:提示接收端的应用程序应立即从TCP缓冲区中读取数据。
  • RST:要求对方重新建立连接,携带RST标志的报文段被称为复位报文段。
  • SYN:用于发起连接请求,携带SYN标志的报文段被称为同步报文段。
  • FIN:通知对方本端即将关闭连接,携带FIN标志的报文段被称为结束报文段。

每次传输的报文中,可以同时将多个标记位设置为1,那么这份报文就具有了多重含义!这样的传输策略大大提供了通信效率!

  1. 减少网络流量:由于不需要单独发送ACK包,因此可以减少网络上的数据包数量,降低网络负载。
  2. 提高网络利用率:通过减少数据包数量,网络带宽可以被更有效地利用。
  3. 降低延迟:减少了单独ACK包的传输,可以减少通信的往返时间(RTT)

注意,三次握手的最后一次是可以进行捎带数据的 !

4 面向字节流

创建一个 TCP 的 socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区。

  • 调用 write 时, 数据会先写入发送缓冲区中;
  • 如果发送的字节数太长, 会被拆分成多个 TCP 的数据包发出;
  • 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了,或者其他合适的时机发送出去;
  • 接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
  • 然后应用程序可以调用 read 从接收缓冲区拿数据;
  • 另一方面, TCP 的一个连接, 既有发送缓冲区, 也有接收缓冲区,那么对于这一个连接, 既可以读数据, 也可以写数据。这个概念叫做 全双工

由于缓冲区的存在, TCP 程序的读和写不需要一一匹配, 例如:

  • 写 100 个字节数据时, 可以调用一次 write 写 100 个字节, 也可以调用 100 次write, 每次写一个字节;
  • 读 100 个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100 个字节, 也可以一次 read 一个字节, 重复 100 次;

所以说TCP协议是面向字节流的,对方发送的数据不一定是一个完整的报文。发送的数据是对方操作系统从缓冲区中刷新过来的,也就是说这些数据是不确定的,不一定完整!

这种面向字节流的通信过程必然会有粘包问题:多个报文粘连在一起,无法区分!那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界!

所以为了保证面向字节流的通信过程可以正常读取报文,就需要一些特殊处理,保证我们可以找到边界!之前在使用TCP进行Socket套接字编程时,通过设计报文为:"len"\r\n"{json}"\r\n 我们通过\r\n找到len报文长度,然后来判断是否有完整报文!

UDP协议中,有一个16位UDP长度。操作系统可以知道报文多长,一次性就能将整个完整报文发送出去!而在TCP中是没有TCP长度的!TCP是面向字节流的,不需要对长度进行处理!TCP协议不需要解决粘包问题,粘包问题是应用层需要解决的!TCP协议是通过字节流保证了通信的可靠性!

5 TCP异常情况

TCP在通信过程中如果发生异常怎么办?

  1. 进程终止: 进程终止会释放文件描述符,仍然可以发送 FIN。和正常关闭没有什么区别。我们测试的时候一般都是通过ctrl+c关闭服务端或客户端,这种就是进程终止,和正常关闭时一样的!操作系统会自动进行四次挥手
  2. 机器关机/重启: 机器关机/重启需要所有进程关闭才可以,所以这种情况和进程终止的情况相同。也会自动进行四次挥手!
  3. 机器掉电/网线断开: 这种情况下接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了,就会进行 reset。即使没有写入操作,TCP协议内部设置了一个保活定时器,会定期询问对方是否还在。如果对方不在,也会把连接释放。生活中我们长时间挂载一个APP在后台也是同样的道理!

TCP小结

经过三篇文章的讲解,现在我们已经对TCP协议有了一个大概的了解!
TCP的可靠性通过:

  1. 16位校验和:确保数据不被修改
  2. 32位序列号/32位确认号:这两个字段用于管理TCP连接中的数据传输顺序,确保数据的有序交付!保证不会出现丢包问题
  3. 确认应答机制:通过应答机制,必要时进行重发,确保了数据一定可以被接收端接收
  4. 超时重传:长时间没有接受到应答,会触发超时重传机制,确保了数据一定可以被接收端接收
  5. 连接管理机制:三次握手保证了双方具有发送接收的能力,以及连接的意向!四次挥手保证了在双方都要断开连接时才断开连接!
  6. 流量控制机制:通过滑动窗口来保证发送的数据不会超出接收端的能力范畴!
  7. 拥塞控制机制:通过对网络状况的动态监测,避免发生网络拥塞,最大程度地保证网络通畅!

TCP中提高性能的机制也很多:

  1. 滑动窗口:并发的发送一批数据,与确认序号机制配合,大大提高发送效率!
  2. 快速重传:发送一批数据出现丢包问题时,快重传机制能够快速完成处理工作,不需要等待触发超时!
  3. 延迟应答:通过延迟一段时间,尽可能将更大的窗口大小通过ACK返回给发送端,提高并发发送的效率!
  4. 捎带应答: 合并多种属性的报文,减少使用网络流量,大大提高效率!

实际使用中如何选择TCP/UDP ?
我们说了 TCP 是可靠连接, 那么是不是 TCP 一定就优于 UDP 呢? TCP 和 UDP 之间的优点和缺点, 不能简单的,绝对的进行比较

  • TCP 用于可靠传输的情况,应用于文件传输,重要状态更新等场景。
  • UDP 用于对高速传输和实时性要求较高的通信领域,例如,早期的 QQ,视频传输等。另外 UDP 可以用于广播。

归根结底,TCP 和 UDP 都是程序员的工具,什么时机用,具体怎么用,还是要根据具体的需求场景去判定!!!

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部