关于网络编程中MTU、TCP、UDP优化配置的一些总结（3） 网络编程, 服务端, 数据包, 客户端, 信息

yuyang911220

分析：
因为客户端没有设置TCP_NODELAY选项，Nagle算法强制TCP栈在发送数据包之前等待前一个数据包的ACK确认
信息。然而，客户端设置SO_SNDBUF为0，禁用了内核缓冲区。因此，10000个Send调用只能一个数据包一个数据
包的发送和确认，由于下列原因，每个ACK确认信息被延迟200毫秒：
1、当服务器获取到一个数据包，启动一个200毫秒的计时器。
2、服务端不需要向客户端发送任何数据，所以，ACK确认信息不能被发回的数据包顺路携带。
3、客户端在没有收到前一个数据包的确认信息前，不能发送数据包。
4、服务端的计时器超时后，ACK确认信息被发送到客户端。
如何提高性能：
在这个设计中存在两个问题。第一，存在延时问题。客户端需要能够在200毫秒内发送两个数据包到服务端。
因为客户端默认情况下使用Nagle算法，应该使用默认的内核缓冲区，不应该设置SO_SNDBUF为0。一旦TCP
栈拼接起来的数据包超过MTU值，这个数据包会立即被发送，不用等待前一个ACK确认信息。第二，这个设计
方案对每一个如此小的的数据包都调用一次Send。发送这么小的数据包是不很有效率的。在这种情况下，应该
把每个记录补充到100字节并且每次调用Send发送80个记录。为了让服务端知道一次总共发送了多少个记录，
客户端可以在记录前面带一个头信息。
案例二：
一个Winsock TCP客户端程序打开两个连接和一个提供股票报价服务的Winsock TCP服务端通信。第一个连接
作为命令通道用来传输股票编号到服务端。第二个连接作为数据通道用来接收股票报价。两个连接被建立后，
客户端通过命令通道发送股票编号到服务端，然后在数据通道上等待返回的股票报价信息。客户端在接收到第一
个股票报价信息后发送下一个股票编号请求到服务端。客户端和服务端都没有设置SO_SNDBUF和TCP_NODELAY
选项。
性能：
测试中发现，客户端每秒只能获取到5条报价信息。
分析：
这个设计方案一次只允许获取一条股票信息。第一个股票编号信息通过命令通道发送到服务端，立即接收到
服务端通过数据通道返回的股票报价信息。然后，客户端立即发送第二条请求信息，send调用立即返回，
发送的数据被复制到内核缓冲区。然而，TCP栈不能立即投递这个数据包到网络，因为没有收到前一个数据包的
ACK确认信息。200毫秒后，服务端的计时器超时，第一个请求数据包的ACK确认信息被发送回客户端，客户端
的第二个请求包才被投递到网络。第二个请求的报价信息立即从数据通道返回到客户端，因为此时，客户端的
计时器已经超时，第一个报价信息的ACK确认信息已经被发送到服务端。这个过程循环发生。
如何提高性能：
在这里，两个连接的设计是没有必要的。如果使用一个连接来请求和接收报价信息，股票请求的ACK确认信息会
被返回的报价信息立即顺路携带回来。要进一步的提高性能，客户端应该一次调用Send发送多个股票请求，服务端
一次返回多个报价信息。如果由于某些特殊原因必须要使用两个单向的连接，客户端和服务端都应该设置TCP_NODELAY
选项，让小数据包立即发送而不用等待前一个数据包的ACK确认信息。
提高性能的建议：
上面两个案例说明了一些最坏的情况。当设计一个方案解决大量的小数据包发送和接收时，应该遵循以下的建议：
1、如果数据片段不需要紧急传输的话，应用程序应该将他们拼接成更大的数据块，再调用Send。因为发送缓冲区
很可能被复制到内核缓冲区，所以缓冲区不应该太大，通常比8K小一点点是很有效率的。只要Winsock内核缓冲区
得到一个大于MTU值的数据块，就会发送若干个数据包，剩下最后一个数据包。发送方除了最后一个数据包，都不会
被200毫秒的计时器触发。
2、如果可能的话，避免单向的Socket数据流接连。
3、不要设置SO_SNDBUF为0，除非想确保数据包在调用Send完成之后立即被投递到网络。事实上，8K的缓冲区适合大多数
情况，不需要重新改变，除非新设置的缓冲区经过测试的确比默认大小更高效。
4、如果数据传输不用保证可靠性，使用UDP。

yuchengze

好帖，好帖，路过帮顶