在linux编程中，以下哪个TCP的套接字选项与nagle算_哔哩哔哩笔试题

推荐

guanjian

当有一个TCP数据段不足MSS，比如要发送700Byte数据，MSS为1460Byte的情况。nagle算***延迟这个数据段的发送，等待，直到有足够的数据填充成一个完整数据段。也许有人会问，这有什么影响呢？没有太大的影响，总体上来说，这种措施能节省不必要的资源消耗。但是要发送的总体数据很小时，这种措施就是拖后腿了。比如，用户请求一个网页，大约十几KB的数据，TCP先发送了***个数据包，剩下几百字节一直不发送，要等到另一个RTT才发送，这时候前面发送数据的ACK已经返回了。这样的用户体验是很不好的。所以，现在很多服务器都选择主动关闭nagle算法，因为带宽够大，资源消耗不是问题，速度反而是个大问题。

从上述描述中，禁用 nagle，实质就是不在延迟 TCP_NODELAY

编辑于 2016-05-06 10:53:32 回复(1)

黄色变白色

刚看了TCP/IP编程来刷题，知道TCP_NODELAY有关，但是这个不定项选择的提示让我怀疑人生......

发表于 2019-07-27 16:02:14 回复(0)

youloveme

Nagle算法的规则：

（1）如果包长度达到MSS，则允许发送；

（2）如果该包含有FIN，则允许发送；

（3）设置了TCP_NODELAY选项，则允许发送；

（4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；

（5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。

Nagle算法只允许一个未被ACK的包存在于网络，它并不管包的大小，因此它事实上就是一个扩展的停-等协议，只不过它是基于包停-等的，而不是基于字节停-等的。Nagle算法完全由TCP协议的ACK机制决定，这会带来一些问题，比如如果对端ACK回复很快的话，Nagle事实上不会拼接太多的数据包，虽然避免了网络拥塞，网络总体的利用率依然很低。

Nagle算法是silly window syndrome(SWS)预防算法的一个半集。SWS算法预防发送少量的数据，Nagle算法是其在发送方的实现，而接收方要做的是不要通告缓冲空间的很小增长，不通知小窗口，除非缓冲区空间有显著的增长。这里显著的增长定义为完全大小的段（MSS）或增长到大于最大窗口的一半。
注意：BSD的实现是允许在空闲链接上发送大的写操作剩下的最后的小段，也就是说，当超过1个MSS数据发送时，内核先依次发送完n个MSS的数据包，然后再发送尾部的小数据包，其间不再延时等待。（假设网络不阻塞且接收窗口足够大）

举个例子，比如之前的blog中的实验，一开始client端调用socket的write操作将一个int型数据（称为A块）写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘\r\n’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：

这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个TCP确认延迟机制。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'\r\n'（B块）总是在A块之后40ms才发出。
当然，TCP确认延迟40ms并不是一直不变的，TCP连接的延迟确认时间一般初始化为最小值40ms，随后根据连接的重传超时时间（RTO）、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。另外可以通过设置TCP_QUICKACK选项来取消确认延迟。

发表于 2016-01-21 14:57:38 回复(2)

噼里啪啦酱

答案B，这个主要是为了解决大量的小报文对通信造成的影响，提高传输效率

发表于 2015-09-10 11:06:03 回复(2)

静水云深

TCP_SYNCNT的socket选项单独设置某一个TCP连接SYN重传次数;

SO_KEEPALIVE 保持连接检测对方主机是否崩溃,避免(服务器)永远阻塞于TCP连接的输入

TCP套接字选项

1）TCP_MAXSEG 该选项允许我们设置TCP连接的最大分节大小（MSS）

2）TCP_NODELAY 开启本选项将禁止TCP的Nagle算法

通用套接字选项

1）SO_BROADCAST 本选项开启或禁止进程发送广播消息的能力，只有数据报套接字支持广播，并且还必须是在支持广播消息的网络上

2）SO_DEBUG 本选项仅由TCP支持，当TCP开启该选项时，内核将为TCP在该套接字发送和接收的所有分组保留详细跟踪信息，这些信息保存在内核的某个环形缓冲区中，并可用trpt程序进行检查

3）SO_DONTROUTE 本选项规定外出的分组将绕过底层协议的正常路由机制，路由守护进程（routed和gated）经常使用本选项来绕过路由表

4）SO_ERROR 当一个套接字上发生错误时，源自Berkeley的内核中的协议模块将该套接字的明文so_error的变量设为标准的Unix_Exxx值中的一个，我们称它为该套接字的待处理错误，内核能够以下面两种方式之一立即通知该错误：

a）如果进程阻塞在对该套接字的select调用上，那么无论是检查可读条件还是可写条件，select均返回并设置其中一个或所有两个条件；

b）如果进程使用信号驱动式I/O模型，那就给进程或进程组产生一个SIGIO信号

5）SO_KEEPALIVE 设置后，如果2小时内无数据交换，TCP就会自动发送一个保活探测分节（keep-alive probe）

6）SO_LINGER 本选项指定close函数对面向连接协议如何操作，默认操作是close立即返回，但是如果有数据残留在套接字发送缓冲区中，系统将试着把这些数据发送给对端

7）SO_RCVBUF和SO_SNDBUF 这两个套接字选项允许我们改变接收缓冲区和发送缓冲区默认大小

当设置接收缓冲区大小时，函数调用顺序很重要，这时因为TCP的窗口规模选项是在建立连接时使用SYN分节与对端互换得到的。对于客户，这意味着SO_RCVBUF选项必须在connect之前设置，对于服务器，这意味着该选项必须在调用listen之前给监控套接字设置，给已连接的套接字设置该选项对于可能存在的窗口规模没有任何影响。TCP套接字缓冲区大小至少应该是相应连接MSS的四倍，为避免潜在的缓冲区空间浪费，TCP套接字缓冲区大小还必须是相应连接的MSS值的偶数倍。

8）SO_REUSEADDR 该选项起到以下四个功用：

a）允许启动一个监听服务器并捆绑其众所周知端口，即使以前建立的将该端口用作他们的本地端口的连接仍然存在。这个条件通常是这样碰到的：

I）启动一个监听服务器；

II）连接请求到达，派生一个子进程来处理客户；

III）监听服务器终止，但子进程继续为现有连接上的客户提供服务；

IV）重启监听服务器；

b）允许同一端口上启动同一服务器的多个实例，只要每个实例捆绑一个不同的本地IP即可。

c）允许单个进程捆绑同一端口到多个套接字上，只有每次捆绑指定不同的本地IP地址即可。

d）允许完全重复的捆绑：当一个IP地址和端口已经绑定到某个套接字时，如果传输协议支持，同样的IP地址和端口还可以绑定到另外一个套接字。一般来说仅UDP套接字支持该特性。

发表于 2017-08-30 17:05:26 回复(0)

陈让然

A. TCP_MAXSEG（Maximum Segment Size）：它指定在TCP连接中所使用的最大分段大小（即每个TCP报文段中的数据大小）。通过调整该选项可以影响TCP连接的吞吐量和延迟。较小的分段大小可以减少网络拥塞情况下的丢包率和重传时间，但会增加协议开销。

B. TCP_NODELAY：该选项用于禁用Nagle算法，它可以提高小数据包的实时性，适用于对延迟要求较高的应用程序。当使用该选项时，TCP连接将立即发送数据，而不会等待数据缓冲区填满或到达一定的延迟时间。

C. TCP_SYNCNT（Synchronize Retry Count）：它用于设置在发生连接超时或失败后的重试次数。当连接无法建立或已断开时，TCP协议将尝试重新建立连接，该选项表示重试的次数。调整该选项可以影响TCP连接的可靠性和连接建立的速度。

D. TCP_KEEPALIVE：该选项用于启用TCP连接的保活机制。当启用时，TCP连接会定期发送保活探测数据包以检测连接是否仍处于活动状态。该机制可以用于检测和清理因网络故障或其他原因导致的空闲或已失效的连接。

Nagle算法是一种流量控制算法，通过合并小数据包来减少网络传输开销，提高网络利用率，但也可能引入一定的传输延迟。为了解决延迟问题，可以使用TCP的TCP_NODELAY选项来禁用Nagle算法，从而实现小数据包的即时传输。禁用Nagle算法适用于对实时性要求较高、需要快速响应的应用程序，如在线游戏、视频流媒体等。

发表于 2023-09-24 17:14:03 回复(0)

xyfs

最讨厌不定项选择来一手单选的

发表于 2018-08-25 22:18:52 回复(0)

后劲好大

当有一个TCP数据段不足MSS，比如要发送700Byte数据，MSS为1460Byte的情况。nagle算***延迟这个数据段的发送，等待，直到有足够的数据填充成一个完整数据段。也许有人会问，这有什么影响呢？没有太大的影响，总体上来说，这种措施能节省不必要的资源消耗。但是要发送的总体数据很小时，这种措施就是拖后腿了。比如，用户请求一个网页，大约十几KB的数据，TCP先发送了***个数据包，剩下几百字节一直不发送，要等到另一个RTT才发送，这时候前面发送数据的ACK已经返回了。这样的用户体验是很不好的。所以，现在很多服务器都选择主动关闭nagle算法，因为带宽够大，资源消耗不是问题，速度反而是个大问题。

从上述描述中，禁用 nagle，实质就是不在延迟 TCP_NODELAY

发表于 2017-06-08 19:38:16 回复(0)

chinasanshi

Nagle算法用于自动连接许多的小缓冲器消息；这一过程（称为nagling）通过减少必须发送包的个数来增加网络软件系统的效率。
nagling可以通过使用TCP_NODELAY 套接字选项关闭。

发表于 2015-09-08 19:43:48 回复(2)

laymond

牛客网总有大神，都不知道nagle算法，你们是怎么知道的啊。

发表于 2018-05-01 21:52:55 回复(1)

jack_21

当有一个TCP数据段不足MSS，比如要发送700Byte数据，MSS为1460Byte的情况。nagle算***延迟这个数据段的发送，等待，直到有足够的数据填充成一个完整数据段。也许有人会问，这有什么影响呢？没有太大的影响，总体上来说，这种措施能节省不必要的资源消耗。但是要发送的总体数据很小时，这种措施就是拖后腿了。比如，用户请求一个网页，大约十几KB的数据，TCP先发送了***个数据包，剩下几百字节一直不发送，要等到另一个RTT才发送，这时候前面发送数据的ACK已经返回了。这样的用户体验是很不好的。所以，现在很多服务器都选择主动关闭nagle算法，因为带宽够大，资源消耗不是问题，速度反而是个大问题。从上述描述中，禁用 nagle，实质就是不在延迟 TCP_NODELAY 开启nagle是不是还可能造成TCP粘包问题？？

发表于 2021-10-19 15:39:08 回复(0)