= Сообщение: 842 из 3153 ================================== RU.LINUX.CHAINIK =
От : Serguei E. Leontiev 2:5020/400 21 Apr 15 13:42:16
Кому : Eric Pozharski 21 Apr 15 13:42:16
Тема : Re: port
FGHI : area://RU.LINUX.CHAINIK?msgid=<1187500739@ddt.demos.su>+0850581b
На : area://RU.LINUX.CHAINIK?msgid=<slrnmj99v2.uqn.whynot@orphan.zombinet>+01c8de82
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX.CHAINIK?msgid=<1187500742@lnfm1.sai.msu.ru>+34f8fbca
Ответ: area://RU.LINUX.CHAINIK?msgid=2:463/94.101+fd153036
==============================================================================
From: "Serguei E. Leontiev" <leo@sai.msu.ru>
Привет Эрик,
От 20 апреля 2015 г., 10:16:50 в fido7.ru.linux.chainik ты писал:
SEL>>>> Если память меня не подводит TIME-WAIT - это для
SEL>>>> того, кто соединение закрывает (кто сокет
SEL>>>> закрывает или сам безвременно умирает).
EP>>> Строго наоборот -- RFC761, page 21
Прошу прощения, сразу не отметил, что следует читать не RFC 761, а RFC
793, в деле TIME-WAIT они немного отличаются.
SEL>> По моему, ты плохо прочитал:
SEL>> TIME-WAIT - represents waiting for enough time to pass
SEL>> to be sure the remote TCP received the acknowledgment
SEL>> of its connection termination request.
SEL>> Или поясни, как ты это понимаешь.
EP> Двумя страницами ниже (page 22 реально короткий) есть
EP> flow-chart. Из него следует, что в состояние TIME-WAIT переход
EP> из состояния FIN-WAIT-2 и только из этого состояния.
Строго говоря, если мне не изменяет память, это была ошибка в RFC 761,
которую исправили в действующем RFC 793, т.е. в TIME-WAIT попадают, как
из FIN-WAIT-2, так из CLOSING.
EP> Далее:
EP> FIN-WAIT-2 - represents waiting for a connection termination
EP> request from the remote TCP.
EP> Теперь, сокет привязан к дескриптору, дескриптор к процессу.
EP> Положим процесс умер, и, действительно, ядро может доделать всю
EP> FIN-вакханалию. По идее, должен быть зомби. Иначе, получается
EP> что должен быть порт в состоянии отличном от CLOSED для
EP> которого нет процесса, пусть даже зомби.
Всё правильно (с точностью до ошибки в RFC 761), только зачем процессу
становится зомби? (Впрочем, во времена оные на каких-то системах вроде
бы так бывало, у меня есть какие-то смутные, смутные воспоминания).
Состояние TIME_WAIT - чисто "защитное" состояние протокола TCP,
завершение которого практически никак не влияет на процесс (хотя смотри
ниже, если подходить математически строго, то каждое TCP соединение
должно закрываться 2MSL секунд).
Как легко видеть в предыдущих экспериментах с netcat на Linux и FreeBSD
таки появляется порт в состоянии TIME_WAIT, для которого нет процесса.
Впрочем, точно так же происходит, и на Windows 8.1:
C:\Program Files>nc -l 8901
mmmm
(здесь Ctrl-C)
C:\Program Files>netstat -an | grep 8901
TCP 10.228.12.6:8901 10.228.12.2:61025 TIME_WAIT
И на Solaris 11:
Oracle Corporation SunOS 5.11 11.2 September 2014
leo@vms11leom:~$ nc -l 8901
mmm
^C
leo@vms11leom:~$ netstat -na | grep 8901
10.228.12.12.8901 10.228.12.2.61684 131744 0 128872 0
TIME_WAIT
leo@vms11leom:~$
Только на Mac OSX, настроенной по умолчанию, происходит немного иначе
(смотри предыдущие сообщения), Apple большие оптимизаторы, надо будет
как нибудь посмотреть какие sysctl и как они настроили.
EP> Теперь, получается такая херня -- для сервера это не должно быть
EP> проблемой (accept(2) возвращает дескриптор отличный от того на
EP> котором висит listen(2); TCB, in essence, это две пары IP-port
EP> -- локальная и удаленная; положим, сервер отвалил и оставил
EP> после себя соединения не в CLOSED -- это *не* проблема (потому
EP> что соединение это две пары IP-port), иначе рестарт регулярно
EP> занимал бы до четырех минут (тот самый 2MSL))).
Строго говоря, для сервера это может быть проблемой, т.к. он открывает
сокет для приёма соединений. И может так получится, если мне не изменяет
память, что он воспримет отставшие пакеты закрытого соединения
предыдущего сервера как пакеты открытия нового соединения.
Собственно поэтому, "строгие" разработчики стека TCP/IP и настаивают,
либо на задержке 2MSL секунд, либо на использовании SO_REUSEADDR, а
"мягкие" разработчики предусматривают всяческие нестандартные флаги
SO_REUSEPORT и прочие отклонения от стандарта POSIX.
Если мы взглянем в FAQ эхи RU.UNIX.PROG
https://groups.google.com/forum/#!topic/fido7.ru.unix.prog/MEDYd9pCOGk ,
то увидим соответствующий вопрос и ответ:
================================================================
Q: Пишу демона, если демон перезапускается - не может сделать bind()
A: Смотреть в сторону setsockopt с опциями SO_REUSEADDR, SO_REUSEPORT.
SO_REUSEPORT есть не везде.
EP> Однако, если клент (тот самый мистический java-что-то)
EP> *абсолютно* настаивает на том, что бы создавать соединение с
EP> того же самого порта (а IP, ессно, тот же самый), то,
EP> действительно, может быть проблема продолжительностью до 2MSL
EP> (IP:port принимающей стороны один и тот же -- иначе это не было
Тот самый мистический java-что-то, поскольку он Java, вероятно написан
без использования нестандартных SO_REUSEPORT и т.п., таким образом ему
предписано соблюдать задержку 2MSL между убийством и повторным запуском,
либо требуется настроить sysctl в Linux.
EP> бы сервером). (761-го со-товарищи (а их есть) читал давно, и
EP> точных формулировок ессно не помню, но ощущение такое, что там
EP> (в со-товарищах) прямо сказано, что исходящий порт должен
EP> выбираться рандомно, иначе кирдык.) *SKIP*
Честно говоря, не помню такого. Да и диапазон клиентских портов в районе
15 бит, ну даже если случайно, всё равно вероятность конфликтов будет
порядка 10^-2, т.е. "кирдык".
Разве что как дополнительная мера защита от "хакеров" класса "пионер" :)
EP>>> Я перестаю понимать -- у тебя есть: процессы, порты,
EP>>> инструменты. Посмотри кто что держит и по результатам
EP>>> разберись. Зачем спекуляции разводить?
SEL>> Голова рукам покоя не даёт, истина дороже :)
EP> Это не science-way. Должно быть в такой последовательности:
EP> [1] провести наблюдения; [2] сформулировать гипотезу; [3]
EP> сформулировать и провести мысленный эксперимент; [4] провести
EP> реальный эксперимент; [5] сравнить результаты мысленного и
EP> реального эксперимента; [6] по резульатам сравнения либо
EP> перейти к пункту [1] (гипотеза отвергнута), либо к пункту [1]
EP> (гипотеза требует уточнения), либо принять гипотезу как
EP> подтвержденную и перейти к пункту [1] (в поисках нового
EP> геморроя). Ты находишься в пункте [4], при этом ты не знаешь
EP> кто держит (и держит ли вообще) IP:port на стороне клиента;
EP> второе ты не знаешь как фактически умирает клиент (после
EP> горячего рестарта). Или знаешь. Hо скрываешь.
Вообще-то, это Олег Редут убивает ява-приложения.
А я же только дал анализ его следующего утверждения (который ты вроде
как частично подтвердил):
"...Кстати, если я убиваю нормально работающий процесс, то порт не
захватывается. А если процесс крэшнулся по внутренним причинам и не
работает нормальный выход из него, то тогда после убиения и порт не
освобождается..."
С советом использовать, либо:
sleep 240 # 2*msl
, либо:
man sysctl
+ документация на ядро Linux
и по результатам
sysctl net.ipv4.tcp_tw_recycle
sysctl net.ipv4.tcp_timestamps
sysctl net.ipv4.tcp_tw_reuse
sysctl net.ipv4.tcp_rfc1337
--
Успехов, Сергей Леонтьев. E-mail: lse@CryptoPro.ru
--- ifmail v.2.15dev5.4
* Origin: ГАИШ МГУ (2:5020/400)
|
