задержки установления TCP в течение 3 секунд

Большинства времени, мой RSH цикл вообще хорошо, мы могли бы получить следующие журналы из РСХДА:задержки установления TCP в течение 3 секунд

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]: [email protected] as root: cmd='echo 481'

В то время как для некоторых случаев ошибки, то РШ может успех, но есть несколько секунд задержка, обратитесь к следующей метке:

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]: [email protected] as root: cmd='echo 18'

Я также обнаружил, что, для большинства нормальных случае ПИД увеличивается на 1, в то время как для большинства случае ошибки, PID increasd по 4 см PID в указанных журналах, кажется РСХД развивает некоторые процессы. Итак, вы могли бы дать какое-либо объяснение, почему rshd занял эти несколько секунд, и увеличение PID.

Наш rsh - это старый rsh, а не ssh, я не уверен, но, похоже, rsh из netkit. И это встроенная плата с busybox, без strace/pstack. Для клиентской стороны я использую только «rsh 172.17.0.8 pwd», а не имя хоста.

источник

2014-12-23 Qiu Yangfan

Часто это происходит из-за того, что in.rshd пытается выполнить обратный поиск DNS, чтобы получить имя хоста удаленной системы, а запрос DNS синхронизирован. Вы можете попробовать 'strace -f -p pid-of-the-in.rshd-daemon' непосредственно перед запуском команды' rsh' и посмотреть, что делает процесс 'in.rshd' непосредственно перед паузой. –

Для клиентской стороны я просто 'rsh 172.17.0.8 pwd', не используется имя хоста. Я не уверен, запущен ли DNS-процесс для моего дела. И на моей доске нет никаких стрейсов. –

Задержка, скорее всего, на стороне сервера, а не на стороне клиента. Посмотрите на список хостов в файле '.rhosts' пользователя на сервере. Если какой-либо хост не находится в '/ etc/hosts', механизм проверки подлинности, вероятно, будет выполнять поиск DNS, что может занять несколько секунд, например, если DNS-сервер недоступен. –

Ответ на вопрос сам:

Эта проблема была вызвана потерей кадров. По какой-то причине либо SYN, либо SYN + ACK в трехстороннем рукопожатии по какой-то причине были сброшены по какой-то причине, так как клиент-партнер не получил SYN + ACK в течение 3-х секундного таймаута (этот тайм-аут жестко закодирован в ядре 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

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

rsh требуется два подключения tcp, первый - от rsh-клиента до rshd, а второй tcp connec это от rshd к rsh-клиенту, что означает, что rshd является клиентом tcp. И моя проблема - потеря кадров при втором подключении tcp.

источник

2015-01-06 01:36:20

задержки установления TCP в течение 3 секунд

ответ

Смежные вопросы