物流网站和数据库建设,设计微信网站建设,网页制作软件名称,宁波seo怎么做优化引言
在网络通信中#xff0c;TCP是确保数据可靠传输的关键协议。但在我们深入研究TCP拥塞控制技术之前#xff0c;让我们先探索可靠数据传输的原理#xff0c;特别是TCP头部中一些重要字段的作用。 网络层提供了点对点的通信服务#xff0c;努力交付数据报#xff0c;但…引言
在网络通信中TCP是确保数据可靠传输的关键协议。但在我们深入研究TCP拥塞控制技术之前让我们先探索可靠数据传输的原理特别是TCP头部中一些重要字段的作用。 网络层提供了点对点的通信服务努力交付数据报但并不保证可靠交付。这引出了运输层的角色而TCP和UDP是两种截然不同的协议其中UDP实现了运输层的基本职能而TCP在此基础上实现了数据的可靠传输。
在这个庞大的网络中我们如何确保数据在通信过程中能够可靠传输有哪些技术和机制可以应对不同的通信问题如比特差错、乱序、丢包等 本文将基于《计算机网络*自顶向下方法》一书的第3.4节内容进行整理介绍可靠数据传输不同版本的演进过程对问题逐一进行解答。
构建可靠的数据传输协议
rdt: 可靠数据传输协议reliable data transfer protocol tcp是双向数据传输简化场景考虑单向数据传输可靠性如何来保障。从最简单的场景来逐步演化得到一个可靠的数据传输协议。
rdt1.0经完全可靠信道的可靠数据传输
这是一种最简单的场景认为网络层的信道是可靠的此时接收、发送方直接收发数据即可无需额外的动作 状态机
报文格式data
rdt2.0: 经具有比特差错信道的可靠数据传输
网络层保障数据的有序送达但不保障原样交付即数据可能会出错 发送方需要增加冗余信息即tcp头部中的校验和 接收方需要来识别数据是否损坏或者说被修改并告知发送方识别结果 接收方如果被告知数据损坏需要进行重传。 此场景下NAC或者ACK受损的情况。
状态机
报文格式。发送方data校验和接收方应答接收结果。
rdt2.1经具有比特差错和乱序信道的可靠数据传输
网络层不会丢包会保障数据的送达但不保障有序性和原样交付即在rdt2.0的基础上增加了乱序的场景 如何解决乱序问题最简单的方案增加编号。
状态机
报文格式。发送方data校验和序号接收方应答序号接收结果。
rdt2.2无NAK机制的rdt2.1实现
在rdt2.1的基础上进行了微调去掉了显示的NAK应答只回复ACK信息通过对同一个分组连续的两个ACK来隐性实现NAK的效果 状态机 报文格式和rdt2.1的相同
rdt3.0经具有比特差错的丢包信道的可靠数据传输
网络层尽力而为的交付数据报但不保证可靠交付在rdt2.2的基础上增加了丢包。此时网络模型贴合我们实际的环境即乱序、丢包、受损均可能出现。 识别丢包发送方需要增加超时机制超时未收到应答需要重传。重传的引入可能导致数据包重复接收/送达接收方需要根据序号去重。
状态机
和rdt2.2相比发送方增加了超时处理机制但对于接收方而言无感故接收方的状态机和rdt2.2的相同 报文格式和rdt2.2相同
交互过程如下
至此可靠数据传输协议原理介绍完毕它用到了校验和、序号、结果确认、定时器这些技术。
性能问题如何提升
rdt3.0保证了数据的可靠传输但存在一个性能问题即一次只能传输一个分组。 在千兆带宽、往返传播时延RTT为30ms一个分组为1500字节的情况下计算可得真实速率为400Kbps带宽利用率为万分之四。 为了提高性能我们需要提高发送数据量的大小、降低RTT并提升带宽大小。发送数据量的增加和RTT的降低可以提高真实使用速率和带宽利用率。 然而对于传输链路上的带宽发送者并不知道它的具体情况。这引出了TCP的拥塞控制机制它是如何解决这个问题的我们将在后文中介绍。
流水线可靠数据传输协议
为了提高带宽利用率我们引入了流水线作业的概念允许在未收到ACK的情况下同时发送多个数据报。
相较于rdt3.0流水线作业模式下需要做一些新的调整 增加序号范围 由于多个分组同时在传输需要有唯一的序号来区分包括确认报文。 增加缓存空间 发送方需要存储已发送但未确认的数据接收方需要存储已接收但未被上层应用读取的数据。 异常处理 在流水线作业中乱序和丢包的异常处理需要考虑。有两种处理策略回退N步和选择重传。
回退N步Go-Back-NGBN
针对异常处理的一种策略当出现丢包时从丢包的位置开发其后所有的分组全部重传。
选择重传Selective RepeatSR
针对异常处理的另一种策略当出现丢包时发送方选择性的重传。
比较GBN和SR这两种策略GBN相对简单但可能会浪费带宽资源。例如在传输10000个包的情况下仅第1000个包丢失后续的9000个包都需要全部重传这会极大增加网络负载可能导致拥塞。
而SR按需重传可能会导致网络利用率较低。例如连续10个包丢失每个包依次等待超时重传会阻塞后续包的传输。
TCP使用的SACKSelective Acknowledgment机制告知发送方接收到的失序报文段从而使发送方更快地传输丢失的数据包。
基于这两种策略我们可以对比TCP和UDP在传输大数据如一个zip文件的场景下的表现。 TCP采用类似SR策略按需传输丢失的数据包但由于握手和拥塞控制的影响前期带宽利用率较低可能会波动。 而UDP采用类似GBN策略如果出现丢包应用层需要重传整个数据但网络带宽利用率不受影响。 在具体场景中选择使用哪种协议将取决于需求和性能要求。
TCP报文格式回顾 根据前面介绍的知识点回顾TCP报文格式中部分字段的含义。 Sequence Number发送序列号 Acknowledge Number确认序列号 Window作为接收方时的窗口大小 Checksum数据校验和 Options.type5SACK机制用于对收到乱序数据包的场景进行部分确认的机制 完整格式解读参见《TCP_报文格式解读》
小结
TCP作为网络通信中的关键协议在可靠数据传输方面经过多个版本的演进逐步解决了不同的通信问题如比特差错、乱序、丢包等。流水线作业的引入为提高带宽利用率提供了思路而回退N步和选择重传这两种异常处理策略则为解决传输中的异常情况提供了灵活性选择。
在实际应用中选择TCP或UDP取决于具体场景需求。TCP通过拥塞控制机制适应网络环境变化而UDP则更适用于对时延和实时性要求较高的场景。对于性能优化需要平衡发送数据量大小、RTT和带宽以达到更高的真实速率和带宽利用率。接下来我们将聚焦于另一个关键领域TCP的拥塞控制技术。究竟是什么让TCP在网络中表现得如此出色让我们一同揭开拥塞控制的面纱深入理解其背后的原理与挑战。
