tcp/ip通讯问题

yuxh

在发送数据包时，包文送出后需要得到对端的ACK确认，这个ACK一般都是附带在响应包中带回，如果没有响应包，则会在延时0.2秒后送回。发送端只有得到ACK确认后才能发送下个报文，如果要连续发送两个包文，则总会有0.2秒的延时，如何把这个延时去掉？
哪位大侠知道，告知一下，在下感激不尽!

linux_newbie

你不延时不就可以了吗？

benlan

我认为是去不了的,因为这关系到tcp实现,也许修改tcp的实现代码能做到
在应用层吧两个包打在一起发了,或加个发送队列,把要发送的数据包都丢进来,开个线程一直发包

yuxh

开个线程一直发包并不能提高发包的速度啊!
两个包之间还是有0.2秒的延时
不断地发100个包就要20多秒啊!

linux_newbie

你这到底是什么问题？你这个0.2秒是你自己的程序中设置的，还是TCP本身引起的？如果是你程序设置的，那你还想怎么办？

TCP应该本身没有这种限制，要不你试试设置TCP_NODELAY。

另外，由于你必须得到ACK确认后才能发送下个报文，这种效率不高，因此速度不会太快，基本上和往返时间成反比。

faint！你这个0.2秒不是指往返时间吧？如果是，那也就只能这么快了。除非修改协议，允许不收到ACK就可以发送下一个消息，即异步方式。

JohnBull

使用TCP的时候你根本不用关心这些细节,如果你想亲自实现你描述的流程,就应该使用UDP.

注:实际上你所说的流程是网络原理中的"停-等协议",TCP其实不是那样工作的,而是可变长滑动窗口协议.

flw

JohnBull 版主说得非常对。
我补充一下，
[quote]原帖由 "yuxh"]发送端只有得到ACK确认后才能发送下个报文，如果要连续发送两个包文，则总会有0.2秒的延时，如何把这个延时去掉？[/quote 发表：

你说的这个不是 TCP，
你说的这个是“简单确认”的一种模型，
而 TCP 是有“滑动窗口”的，
只有“已发送但未确认的序号个数超过了滑动窗口的大小”的时候，TCP 发送才会停滞。
这就是说，在接收方等待那个 0.2 秒的延时的时候，
发送方仍然可以继续发送数据，只要滑动窗口还有剩下的空间。
而当发送方发送完一些数据之后，接收方发出的早期发送的数据的 ACK 确认早就已经回来了，这时候，滑动窗口就可以往后“滑动”一段距离，从而可以继续发送。

ldiqing

对于这个问题，我建议你看一看TCP/IP祥解得第一卷，或者UNIX网络编成第一卷，我记得看到过，但忘了。

elssann

在发送端设置NO_DELAY
在接收回应端设置TCP_QUICKACK

yuxh

楼上的：setsockopt中有TCP_QUICKACK选项吗？
我在UNIXWARE7.1.3环境下报告没有。

说明一下：我用的就是简单的SOCKET通讯，在SCO OPENSERVER下当包文长度<5个时也会有0.2秒的延时，但当长度>;5个时就不会有。而在UNIXWARE下与包文大小无关，只要没有回应包，都会有这个延时。