0

大多数时候，我的 rsh 周期一般都可以，我们可以从 rshd 获得以下日志：

Aug 19 04:36:34 shmm500 authpriv.info in.rshd[21343]: connect from 172.17.0.40 (172.17.0.40)
Aug 19 04:36:34 shmm500 auth.info rshd[21344]: root@172.17.0.40 as root: cmd='echo 481'

虽然对于某些错误情况，rsh 可能会成功但有几秒钟的延迟，请参阅以下时间戳：

Aug 19 04:12:24 shmm500 authpriv.info in.rshd[17968]: connect from 172.17.0.40 (172.17.0.40) 
Aug 19 04:12:27 shmm500 auth.info rshd[17972]: root@172.17.0.40 as root: cmd='echo 18'

我还发现，对于大多数正常情况，PID 增加 1，而对于大多数错误情况，PID 增加 4，请参阅上面日志中的 PID，似乎 rshd 分叉了一些进程。那么，您能否解释一下为什么 rshd 花了这几秒钟并且 PID 增加了。

我们的 rsh 是旧的 rsh，而不是 ssh，我不确定，但似乎 rsh 来自 netkit。这是一个带有busybox的嵌入式板，没有strace/pstack。对于客户端，我只是'rsh 172.17.0.8 pwd'，而不是使用主机名。

4

1 回答 1

0

自己回答问题：

此问题是由帧丢失引起的。由于某种原因，3 次握手中的 SYN 或 SYN+ACK 以极少的速率被丢弃，无论如何客户端对等点在 3 秒超时内没有得到 SYN+ACK（此超时在 Linux 内核中是硬编码的），然后connect() 再次重新发送 SYN，并且通常在第二次尝试时成功。

从应用的角度来看，我们有 3 秒的延迟，如果第二次尝试失败，甚至会延迟 6 秒。

其他相关信息：

第一个日志来自 tcpd（又名 tcp 包装器）

Aug 19 04:36:34 shmm500 authpriv.info in.rshd[21343]: connect from 172.17.0.40 (172.17.0.40)

第二个日志来自 netkit 0.17 中的 rshd

Aug 19 04:36:34 shmm500 auth.info rshd[21344]: root@172.17.0.40 as root: cmd='echo 481'

rsh 需要两个 tcp 连接，第一个是从 rsh 客户端到 rshd，第二个 tcp 连接是从 rshd 到 rsh 客户端，也就是说 rshd 是 tcp 客户端。我的问题是第二个 tcp 连接上的帧丢失。

于 2015-01-06T01:36:20.190 回答