网络编程中Nagle算法和Delayed ACK的测试

所有发帖的人都希望自己的观点被别人认同，这很正常，大家都一样。

1、不管你自己认为你懂不懂应用，你不能从所谓理论知识来给一个应用的对错下结论，更不用说是更多的应用，应用的对错都是要靠实际验证，至少是测试验证（人家开发者自己没验证过用不用delay会有什么影响吗？）。你最多是说是用delay可能会对一些应用有所帮助，根本没资格说一个应用这么做就一定不对，任何人都没资格。
   给你取个例子：前段时间我们一个系统在测试当中出现了性能瓶颈问题，大家开会讨论，找到了一段有问题的代码，而且一直认为这段代码的逻辑有问题，很可能（虽然我个人认为100%是在这里)问题就出在这里。这是结论吗？这只是讨论结果，最终的结论必需等开发人员对针对这段代码及其改进后实际的测试结果才能得出。这么一个特定的、具体的问题都不可以从理论分析和经验上直接下结论，更别说是都确定是什么应用了。
2、你的demo只是在证明delay在特定场合下会发生作用,根本证明不了不用就一定不行，或者说用了就一定比不用好。我这么说不是不尊重系统作者，人家可没认为写出来的东西是万能药，用在哪里都合适。实际的网络应用远比这复杂得多。
凭你现的哪些论述，根本不能证明你的结论，也没有什么说服力。如果你坚持那么认为的话，欢迎你继续研究，再发表更多的论据和经验案例。

说个题外话，前两天我们对刚开发的一个网络通讯系统做测试，在单客户端的时候性能非常差，但随着客户端数量原来越多，性能反而会越来越高。最终发现原来是delay忘了关掉了。包括我在内，相当一部分人对delay这个东西并不感冒，开发应用的时候总是先把它关掉，除非后来实际验证delay有用（很少遇到)。

其实我一直有个困惑，为什么Socket系统不提供个flush指令，在应用通知flush之前，系统可以根据实际情况怎么优化合并都可以，但应用通知socket flush之后，就需要尽可能立即发送数据。不需要人为造出那200毫秒来搞所谓智能合并。如果没有那200毫秒的延迟，应用程序当然欢迎系统去优化合并数据包。

PS：我刚翻了一下WindowsAPI，还真有个SIO_FLUSH 控制指令，只可惜功能不是我上面描述的那样。SIO_FLUSH 
Discards current contents of the sending queue associated with this socket

您啥时候能改掉好为人师的毛病呢，看看您说的话

你都不知道自己在说啥了吧。

另外，Nagle算法跟什么delay是两个事情,nagle也没有什么200ms的概念，如果您没看明白这文章，麻烦再看看，别满嘴跑火车了。
最后，我对您所谓经验感想不感兴趣，您也不用在布道了，就此为止吧。

LZ总结的很好,存在即合理,强行关闭有时是能解决一些问题.

为什么自己写的网络程序性能那么差？看了LZ的文章确实发现很多自己的不足之处，先谢谢LZ了。
PS：难得看到论坛里有人和LZ较真（或是较劲？）的，哈，有点意思。就是感觉他貌似有点钻牛角尖了，讨论的主题有点对人不对事了。。。

看完大家的讨论，我感觉我非常有必要买TCP/Ip看看，就知道socket简单的编程，以前来几个线程套线程就以为自己高手了，实在惭愧

写的不错 看到了一些感兴趣的地方

我有一个疑问啊。如果我服务器端不反回数据。那客户端什么时候发送数据？

我看了一下“延时确认”的概念如果没有返回包是延时200毫秒返回确认包。

这样的话客户端根据Nagle算法应该是 200毫秒发送一次。为什么我测试来看 没有等确认包啊？？？？

用代码示例阐释原理，喜欢这种风格，楼主对setTcpNoDelay()有深入研究，另外，楼主能否给点自己的学习经历，说说如何深入掌握java网络编程，书籍，网站，或可以动手操作的小例子(动手做才能更好掌握)，谢谢了