tcp/ip通讯问题

flw

[quote]原帖由 "yuxh"]说明一下：我用的就是简单的SOCKET通讯，在SCO OPENSERVER下当包文长度<5个时也会有0.2秒的延时，但当长度>;5个时就不会有[/quote 发表：

这正是 Nagle 算法优化的效果！
这个现象可以通过在发送端设置 TCP_NODELAY 来解决。

大多数 TCP 实现都会将确认延迟以便于捎带传送一些数据，这实际上并不会影响发送性能，刚才 elssann 所述的 TCP_QUICKACK 选项大抵就是用来关闭这种优化的，可惜并非所有的操作系统都支持 TCP_QUICKACK。

LAPUTAIN

每当我浏览帖子的时候猜发觉我还没有将学过的知识全忘掉！

yuxh

原帖由 "flw" 发表：

这正是 Nagle 算法优化的效果！
这个现象可以通过在发送端设置 TCP_NODELAY 来解决。

大多数 TCP 实现都会将确认延迟以便于捎带传送一些数据，这实际上并不会影响发送性能，刚才 elssann 所述的 TCP_QUICKACK ?.........

在OPENSERVER上不支持TCP_NODELAY，在UNIXWARE下设了没用

flw

原帖由 "yuxh"]在OPENSERVER上不支持TCP_NODELAY，在UNIXWARE下设了没用[/quote 发表：

如果真是这样的话，那就没有办法了。
不过，可以讲讲你的应用要达到一个什么样目的吗？
正如我签名所说：
[quote]当你为了寻找解决问题的方法而累得筋疲力尽时，不妨向后看看，看看你是不是已经迷路了？你的问题究竟是什么？

yuxh

在长连接中发送报文时要先发送一个长度，为了统一起见，写一个库函数供调用。原型：
int PutMessage(int nSock, char *strBuff, int nLen);
strBuff为要发送的数据，不带长度。所以发送就会成为这样：
sprintf(temp, "%05d", nLen);
write(nSock, temp, 5);
write(nSock, strBuff, nLen);
就会有连续两次的写操作。

现在只能改成这样
char *temp;
temp = (char *)malloc(nLen+6);
sprintf(temp, "%05d", nLen);
memcpy(temp+5, strBuff, nLen);
write(nSock, temp, nLen+5);

感觉很不爽!

flw

原帖由 "yuxh" 发表：
在长连接中发送报文时要先发送一个长度，为了统一起见，写一个库函数供调用。原型：
int PutMessage(int nSock, char *strBuff, int nLen);
strBuff为要发送的数据，不带长度。所以发送就会成为这样：
sprintf(temp, "%05d", nLen);
write(nSock, temp, 5);
write(nSock, strBuff, nLen);
就会有连续两次的写操作。

现在只能改成这样
char *temp;
temp = (char *)malloc(nLen+6);
sprintf(temp, "%05d", nLen);
memcpy(temp+5, strBuff, nLen);
write(nSock, temp, nLen+5);

感觉很不爽!

哈哈哈！
真的被我说中了……

1. write(nSock, temp, 5);
   
2. write(nSock, strBuff, nLen);

复制代码

和

1. write(nSock, temp, nLen+5);

复制代码

的效果是一样的！
没错，

1. write(nSock, temp, 5);

复制代码

的确会被延迟发送，
可是你要知道：
1，延迟的原因是什么？
是因为 Nagle 算法优化的结果。
2，Nagle 算法优化的目的是什么？
是为了防止小数据量传送时造成的网络带宽的浪费。（注一）
3，Nagle 算法实现了一个什么效果？
Nagle 算法可以延迟发送太小的报文，直到：(1)，所有已发送的小分组都已被确认；(2)，所有待发送的数据累计起来以后，已经不再是一个“小分组”了。

总结：

1. write(nSock, temp, 5);

复制代码

的确可能被延迟了，
可是因为你紧接着又有一个

1. write(nSock, strBuff, nLen);

复制代码

所以，TCP 最终会把这两个 write 调用提供的数据打在一个 TCP 分组中发送出去！
也就是说，和你

1. write(nSock, temp, nLen+5);

复制代码

的效果几乎是完全相同的！


注一：
因为一个 TCP 报文的报头部分再加上 IP 报头一共有近百个字节，
因此，仅仅只发送象 5 个字节这样的小分组显然是浪费了很多带宽。

flw

最后，再把这句话送给各位，也送给我自己：

当你为了寻找解决问题的方法而累得筋疲力尽时，不妨向后看看，看看你是不是已经迷路了？你的问题究竟是什么？

yuxh

然而情况并没有如此简单。。。
我试过发送200个字节的报文，连续发送时也会延时
在发送第一个包文后，接收端能立即收到，延时出现在接收第二个包文时。

实际过程如下：
第一个报文发送后，接收端正确接收；这时接收端应向发送端回应ACK，为减少包文交换次数，ACK并没有立即发出，而企图附在回应报中一起发出；由于此时没有回应包，接收端在等待了0.2秒后强制回应ACK

发送端发出第一个包文后等待接收端的ACK确认，在未等到确认之前无法发送第二个包文；0.2秒后，接收到ACK确认于是发送第二个包文

按TCP/IP"滑动窗口"的原理，发送端应该可以在收到ACK之前发出第二个报文，不知什么原因未起作用。

现在是想找到一个办法，使接收端立即回应ACK，或使"滑动窗口"起效

yuxh

TCP_QUICKACK应该能起到这样的作用，可惜UNIXWARE不支持
Nagle 算法是指发送多个包文时，若是小包文，则会将他们并在一起发送，TCP_NODELAY可以使该算法失效，使TCP/IP不管包文大小，立即发送。

如果这里发送两个包文之间有时间差，即发送第一个包文后，再去做一些别的操作，再发送第二个包文，如果第一个包文太小，按Nagle 算法可能这个包文不被立即发送，而是等待下一个包文一起发送，以提高效率。

但现在的情况并非如此。

flw

发送端发出第一个包文后等待接收端的ACK确认，在未等到确认之前无法发送第二个包文；0.2秒后，接收到ACK确认于是发送第二个包文

按照 TCP 协议标准，
这个情形是不会出现的。
也许是你分析错了？
或者是 UNIXWARE 的实现问题？
不得可知。

建议你用 TCPDUMP 观察一下，
到底是不是你说的这种情形。

很可惜我现在没有条件试。