Pull to refresh

Comments 36

Возможно это www.auburn.edu/docs/apache/misc/fin_wait_2.html?
The FIN_WAIT_2 state is somewhat unusual in that there is no timeout defined in the standard for it. This means that on many operating systems, a connection in the FIN_WAIT_2 state will stay around until the system is rebooted. If the system does not have a timeout and too many FIN_WAIT_2 connections build up, it can fill up the space allocated for storing information about the connections and crash the kernel. The connections in FIN_WAIT_2 do not tie up an httpd process.


И посмотрите тут social.msdn.microsoft.com/forums/en-US/d20e5e67-d23c-42a5-95c5-ba80f4263546/keepalive-packets-continue-being-sent-after-client-closes-server-socket-is-closewait-client, не то?
Да, похоже оно.
Хорошо, что добавлен, как пишут выше, тайм-аут на это состояние в Linux, хотя конечно надо проверить своими руками это.
Насчет Windows, надо проверять точно…
Ну разница не велика, на самом деле. Хотя в случае в одним клиентом, конечно DoS.
хотя, конечно, немного похоже и на DOS.
Серверные версии ОС подвержены атаке?
Vista в качестве серверной ОС — месье знает толк.
Это нормальное решение, если речь не о запуске серверов для обслуживания сети Windows. Я имею ввиду, например, что если вы хотите запустить Apache на винде (причина не важна, просто есть такое требование — Apache на винде), то нахрена тратить ОЗУ и деньги на покупку Windows Server, когда «десктопная» винда с задачей справится абсолютно так же?
Не надо ничего покупать — возьмите Linux на отдельную машину.
Если все хочется без допжелеза — то поставьте Vagrant — он вам сам поставит Linux в виртуалке, расшарит туда папку.
Вы правите файлы на локальном компе, а их тут же подхватывает LAMP. У вас и винда и нормальная серверная среда одновременно.
Профитъ и бесплатно!
Некропостер?

Требование: «apache на windows». Какой линукс на отдельную машину? Требование прямое и недвусмысленное — «windows».
> Требование: «apache на windows». Какой линукс на отдельную машину? Требование прямое и недвусмысленное — «windows».
Ну так вы работаете в винде, а апач — в виртуалке. Каждый в своей родной среде.
Завтра появится требование «прикрутить маленький модулек» к апачу и начнутся танцы с бубном и пересборки моделей апача в винде.
Апач нужен для запуска виндовского CGI-приложения. В вайне не запустишь, исходников нет. Эта винда и есть в виртуалке. Но это неважно.

Важно то, что есть конкретное решение, из которого вытекает такое требование. Задача — внедрить, а не выпендриваться и искать другое решение.

P.S. я сам линуксоид уже почти 15 лет, джентушник,. Но красноглазики, которые пытаются пихать его везде и всюду, не задаваясь вопросами «а почему так», заколебали. Просто перестаньте.
Кто Вам сказал что это серверная ОС ???!!! Там просто поднят простейший ТСР сервер для подключения…
Читаем внимательней…
— а ваша ОС серверная?
— да, конечно, смотрите, тут у нас подняты разные TCP-серверы…
Серверная не серверная, какая практическая разница? У меня около 5 лет работал домашний шлюз на Windows XP Pro, где в качестве маршрутизирующего ПО был установлен Kerio Control, там же стояли торренты, FTP, SVN, Apache и ещё много чего, и всё это чудесно работало. Единственное, что я делал с системой это патч для TCP/IP на количество полуоткрытых соединений, но я делал его даже не потому что это шлюз, а потому что там торренты стоят :) И как верно пишет merlin-vrn — если эта машина не работает в качестве контроллера доменов — то это адекватное, и рабочее решение.

P.s: и сейчас эта машинка работает, правда я её редко включаю ибо она старая — ест много и греется :), а не используется просто потому что в качестве шлюза и домашнего сервера сейчас работает новая железка и уже с 2008R2 на борту.
А пробовали такую операцию сделать 65535 раз, чтобы забились все локальные порты?
Что будет с системой?
вопрос настоящего тестировщика)
Скорее всего, потеряется возможность соединяться именно с тем клиентом, с кем были эти 65535 соединений, а соединения с другими клиентами не должны сломаться или упасть.
Все 65535 забить не получится вроде: процесс System открывает сокет на 445/TCP, а svchost на 135/TCP
И еще момент:

Windows умеет вешать несколько процессов на один сокет.
Я столкнулся с этим, когда писал веб-сервер на Java. Например можно так:
1) первый процесс java.exe маппится на 127.0.0.1:80
2) при запуске ещё одного процесса этого сервера проверка на занятость сокета выдаст результат «сокет свободен»
3) Windows запустит ещё один процесс java.exe, который по данным netstat.exe тоже слушает 127.0.0.1:80

Все коннекты обрабатывает первый процесс java.exe


Это не эксклюзивная фича именно для 127.0.0.1? Потому, что иначе бред какой-то
Да, было такое дело. Как-то давно получалось перебивать открытый на 127.0.0.1 порт, изменив 127.0.0.1 на 0.0.0.0.
Сейчас на Windows Server 2008 R2 не получилось воспроизвести.

Но нашел скриншот, где у меня получалось 127.0.0.1 занимать двумя процессами



Возможно это из-за того что 9600 > 1024. Но Windows вроде не разделяет root-порты и клиентские.
Реквестирую DoS эксперимент на этой проблеме.
Проверили… Итого, это проблема ВСЕХ Windows что были в наличии: Vista, 7, 8, Win server…
Сервер НЕ ПРИНИМАЕТ соединение от клиента со старого порта, но принимает с нового, т.е. old src port != new src port => OK!!!
А не пытались переполнить память отведенную на поддержку TCP соединений?
Нет. Задача ставилась совсем другая — проверить возможность восстановления соединения после обрыва.
Надеюсь кто-нибудь из хабра продолжит исследование темы…
Отпишитесь пожалуйста о результатах. Ибо у меня такое ощущение, что иногда я сталкиваюсь с этой проблемой. просто не понимаю откуда она берётся.
* ранее не понимал откуда ноги растут.
Хм, я правильно понимаю — если подключаться с разных портов, то в конце-концов можно сделать сервис недоступным?
Насколько я понял, только для себя (своего IP-адреса). Ну или вариант — возможно, получится исчерпать там память ядра, отведённую для поддержки TCP-соединений, тогда да, ляжет TCP или вся ОС.
Лучше поздно чем никогда:

Сейчас увидел реальную ситуацию когда из-за этого бага перестает работать TeamCity. Оно перодически дергает Систему контроля версий и оставляет порт в FIN_WAIT2. В итоге, забивает все клиентские порты.
Sign up to leave a comment.

Articles