一、延迟确认（延迟ACK）

在许多情况下，TCP并不对每个到来的数据包都返回ACK，利用TCP的累积ACK字段（参见TCP报文格式https://blog.csdn.net/qq_41453285/article/details/104016416）就能实现该功能
累积确认可以允许TCP延迟一段时间发送ACK，以便将ACK和相同方向上需要传的数据结合发送。这种捎带传输的方法经常用于批量数据传输
显然，TCP不能任意时长地延迟ACK；否则对方会误认为数据丢失而出现不必要的重传

不同操作系统对延迟确认的实现

采用延时ACK的方法会减少ACK传输数目，可以一定程度地减轻网络负载。对于批量数据传输通常为2:1的比例。基于不同的主机操作系统，延迟发送ACK的最大时延可以动态配置

Linux使用了一种动态调节算法，可以在每个报文段返回一个ACK (称为“快速确认”模式)与传统延时ACK模式间相互切换

Mac OS X中，可以改变系统变量net.inet. tcp.delayed_ack值来设置延时ACK。可选值如下：禁用延时(设为0)，始终延时(设为1)，每隔一个包回复一个ACK(设为2)，自动检测确认时间(设为3)。默认值为3

最新的 Windows版本中，注册表项中，每个接口的全局唯一标识（GUID）都不同（IG表示被引用的特定网络接口的GUID）。TcpAckFrequency值（需要被添加）可以设为0-255，默认为2。它代表延时ACK计时器超时前在传的ACK数目。将其设为1表明对每个收到的报文段都生成相应的ACK。ACK计时器值可以通过TcpDelAckTicks注册表项控制。该值可设为2 - 6，默认为2。它以百毫秒为单位，表明在发送延时ACK前要等待百毫秒数

之前提到过，通常TCP在某些情况下使用延时ACK的方法，但时延不会很长。在后面“TCP拥塞控制”文章中大量采用了延时ACK的方法，我们将会看到TCP怎样在处理批量数据的大数据包传输中实现拥塞控制
在小数据包传输中，如交互式应用，需要采用另外的算法。将该算法与延时ACK结合使用，如果处理不好，反而会导致性能降低。下面我们详细讨论该算法

二、Nagle算法

设计Nagle算法的初衷

从前面的小节中可以知道，在ssh连接中，通常单次击键就会引发数据流的传输。如果使用IPv4，一次接键会生成约88字节大小的TCP/IPv4包（使用加密和认证）：20字节的IP头部，20字节的TCP头部（假设没有选项），数据部分为48字节。这些小包（称为微型报）会造成相当高的网络传输代价。也就是说，与包的其他部分相比，有效的应用数据所占比例甚微

该问题对于局域网不会有很大影响，因为大部分局域网不存在拥塞，而且这些包无须传输很远。然而对于广域网来说则会加重拥塞，严重影响网络性能

John Nagle在[RFCO896]中提出了一种简单有效的解决方法，现在称其为Nagle算法

下面首先介绍该算法是怎样运行的，接着我们会讨论结合延时ACK方法使用时可能出现的一些缺陷和问题

Nagle算法实现原理

Nagle算法要求，当一个TCP连接中有在传数据时（即那些已发送但还未经确认的数据），小的报文段（长度小于SMSS）就不能被发送，直到所有的在传数据都收到ACK。并且，在收到ACK后，TCP需要收集这些小数据，将其整合到一个报文段中发送

这种方法迫使TCP遵循“停等规程”——只有等接收到所有在传数据的ACK后才能继续发送

该算法的精妙之处在于它实现了自时钟控制：ACK返回越快，数据传输也越快。在相对高延迟的广域网中，更需要减少微型报的数目，该算法使得单位时间内发送的报文段数目更少。也就是说，RTT控制着发包速率

演示案例

从前前面一篇文章的演示案例中可以看到，单个字节的发送、确认以及回显的RTT较小（15ms以下）。为更快地生成数据，我们需要每秒钟输入60个字符以上。这意味着，当两台主机之间以很小的RTT传输数据时，例如在同一个局域网中，我们将很难看到该算法的显著效果

为了显示Nagle算法的效果，我们比较分析某个TCP应用使用和禁用该算法的行为。我们对一个ssh版本的客户端做了一定的修改。利用一个RTT相对较大（约190ms）的连接，就可以看出区别

首先观察禁用Nagle算法（ssh默认）的情况，如下图所示：

上图中显示的传输是在初始的认证完成以后、登录会话开始时记录的。这时输入date命令，我们看到共捕获到了19个包，整个传输过程持续了0.58s。共有5个ssh请求包，7个ssh应答包，以及7个TCP层的纯ACK包（不包含数据）

下面我们将在使用Nagle算法的情况下重复探测这一过程（即在相似的网络环境下），如下图所示：

可以看到下图中的包数目要少于上图（少了8个）。另外一个明显的差异是，请求和响应包随时间分布呈一定的规律性。回想一下Nagle算法的原理，它迫使TCP遵循停等行为模式，因此TCP发送端只有在接收到全部ACK后才能继续发送。观察每组请求/响应的传输时刻——0.0、0.19、0.38以及0.57，我们可以发现它们遵循一定的模式：每两个间隔为190ms，恰为连接的RTT。每发送一组请求和响应包需要等待一个RTT，这就加长了整个传输过程（需要0.80s而非前面的0.58s）

Nagle算法做出了一种折中：传输的包数目更少而长度更大，但同时传输时延也更长。从下图中可以更清晰地看出差别

下图显示了Nagle算法的停等行为。左侧显示双向传输，而右侧使用Nagle算法，使得在任一给定时刻，只有一个方向保持传输状态

延迟ACK与Nagle算法结合

若将延时ACK与Nagle算法直接结合使用，得到的效果可能不尽如人意。

考虑如下情形，客户端使用延时ACK方法发送一个对服务器的请求，而服务器端的响应数据并不适合在同一个包中传输（见下图）

从图中可以看到：
客户端：在接收到来自服务器端的两个包以后，客户端并不立即发送ACK，而是处于等待状态，希望有数据一同捎带发送。通常情况下，TCP在接收到两个全长的数据包后就应返回一个ACK，但这里并非如此

服务器端：由于使用了Nagle算法，直到收到ACK前都不能发送新数据，因为任一时刻只允许至多一个包在传

因此延时ACK与Nagle算法的结合导致了某种程度的死锁（两端互相等待对方做出行动）。幸运的是，这种死锁并不是永久的，在延时ACK计时器超时后死锁会解除。客户端即使仍然没有要发送的数据也无需再等待，而可以只发送ACK给服务器。然而，在死锁期间整个传输连接处于空闲状态，使性能变差。在某些情况下，如这里的ssh传输，可以禁用Nagle算法

禁用Nagle算法

从前面的例子可以看到，在有些情况下并不适用Nagle算法。典型的包括那些要求时延尽量小的应用，如远程控制中鼠标或接键操作需要及时送达以得到快捷的反馈。另一个例子是多人网络游戏，人物的动作需要及时地传送以确保不影响游戏进程（也不致影响其他玩家的动作）

禁用Nagle算法有多种方式，主机需求RFC列出了相关方法：
若某个应用使用Berkeley套接字API，可以设置TCP_NODELAY选项（见文章：https://blog.csdn.net/qq_41453285/article/details/89541693）

另外，也可以在整个系统中禁用该算法。在Windows系统中，使用如下的注册表项：
这个双字节类型的值必须由用户添加，应将其设为1。为使更改生效,消息队列也需要重新设置

TCP/IP卷一:80---TCP数据流与窗口管理之（延时确认(延迟ACK)、Nagle算法）相关推荐

TCP/IP卷一:87---TCP拥塞控制之（对标准算法的改进：NewReno、采用选择确认机制、转发确认(FACK)和速率减半、限制传输、拥塞窗口校验）
经典的标准TCP算法在传输控制领域做出了重大贡献,尤其针对网络拥塞崩溃这一难题,取得了显著效果然而,仍然可以找到值得改进的地方.考虑到TCP的普遍使用性,越来越多的研究致力于使TCP在更广泛的环境里 ...
TCP/IP学习笔记:TCP/IP协议介绍
TCP/IP的通讯协议这部分简要介绍一下TCP/IP的内部结构,为讨论与互联网有关的安全问题打下基础.TCP/IP协议组之所以流行,部分原因是因为它可以用在各种各样的信道和底层协议(例如T1和X.2 ...
TCP/IP卷一:83---TCP数据流与窗口管理之（紧急机制(URG字段)）
一.紧急机制概述 URG字段我们在前面已经提到,TCP头部有一个位字段URG用来指示"紧急数据" 发送端行为应用在执行写操作时,可通过设置Berkeley套接字API (MSG ...
TCP/IP卷一:26---Internet协议之（IPv4、IPv6数据报，Internet校验和）
一.IP简介以及一些特性 IP是TCP/IP协议族中的核心协议.所有TCP. UDP. ICMP和IGMP数据都通过IP数据报传输 IP的可靠性 IP提供了一种尽力而为.无连接的数据报交付服务.&q ...
TCP/IP卷一:20---链路层之（环回地址）
一.概念尽管可能看起来很奇怪,但在很多情况下,客户机可能希望使用Internet协议(例如 TCP/IP)与同一计算机上的服务器通信为了实现这个目标,大多数实现支持一种工作在网络层的环回(或称& ...
《TCP/IP 卷一》笔记、ping和traceroute 的实现思路
一.TCP协议相关笔记 Normally TCP does not send an ACK the instant it receives data. Instead, it delays the A ...
tcp/ip卷一学习-乱记之概述
一.tcpip协议簇作用:很多不同的厂家生产各种型号的计算机,它们运行完全不同的操作系统,但TCP/IP协议族允许它们互相进行通信. 二.分层网络协议通常分不同层次进行开发,每一层分别负责不同的通信 ...
JavaEE|TCP/IP协议栈之TCP协议端格式详解
文章目录一.对TCP协议的感性认识简介特点二.TCP的报文结构概览 16位端口号和16位目的端口号 32位序号和32位确认序号 4位首部长度保留位(6位) 6个标志位 16位窗口大小 16 ...
TCP/IP详解--TCP/IP中三次握手四次握手状态分析
TCP(Transmission Control Protocol) 传输控制协议 TCP是主机对主机层的传输控制协议,提供可靠的连接服务,采用三次握手确认建立一个连接: 位码即tcp标志位,有6种标 ...

TCP/IP卷一:80---TCP数据流与窗口管理之（延时确认(延迟ACK)、Nagle算法）

一、延迟确认（延迟ACK）

不同操作系统对延迟确认的实现

二、Nagle算法

设计Nagle算法的初衷

Nagle算法实现原理

演示案例

延迟ACK与Nagle算法结合

禁用Nagle算法

TCP/IP卷一:80---TCP数据流与窗口管理之（延时确认(延迟ACK)、Nagle算法）相关推荐

最新文章

热门文章