Какова стоимость многих TIME_WAIT на стороне сервера?
Мы на самом деле используем комбинацию NAnt и MSBuild с CruiseControl. NAnt используется для управления потоком сценария и называет MSBuild для компиляции проектов. После того, как физическая сборка инициирована, NAnt используется для публикации отдельных выводов сборки проекта к общему ресурсу.
я не уверен, что это лучшее процесс. Я думаю, что многие из нас все еще ищут большой инструмент сборки. Одна многообещающая вещь, которую я недавно услышал на Скалах.NET, эпизод 362 , PSake James Kovac, система сборки, которую он основывал полностью на PowerShell. Это звучит действительно многообещающим начиная с того, что можно сделать с PowerShell, довольно безгранично в теории.
4 ответа
Каждый сокет в TIME_WAIT потребляет некоторую память в ядре, обычно немного меньше, чем сокет ESTABLISHED , но все же имеет значение. Достаточно большое число может исчерпать память ядра или, по крайней мере, снизить производительность, поскольку эта память может использоваться для других целей. Сокеты TIME_WAIT не содержат дескрипторы открытых файлов (при условии, что они были закрыты должным образом), поэтому вам не нужно беспокоиться об ошибке «слишком много открытых файлов».
Сокет также связывает этот конкретный src / dst IP-адрес и порт, поэтому его нельзя повторно использовать в течение интервала TIME_WAIT . (Это предполагаемая цель состояния TIME_WAIT . Связывание порта обычно не является проблемой, если вам не нужно повторно подключить порт с той же парой портов. Чаще всего на одной стороне используется временный порт, при этом только одна сторона прикреплена к хорошо известному порту. Однако очень большое количество сокетов TIME_WAIT может исчерпать временное пространство порта, если вы постоянно и часто подключаетесь между одними и теми же двумя IP-адресами. Обратите внимание, что это влияет только на эту конкретную пару IP-адресов и не повлияет на установление соединений с другими хостами.
Каждое соединение идентифицируется кортежем (IP-адрес сервера, порт сервера, IP-адрес клиента, порт клиента). Важно отметить, что каждое соединение TIME_WAIT (на стороне сервера или на стороне клиента) занимает один из этих кортежей.
С TIME_WAIT на стороне клиента, Легко понять, почему вы не можете больше подключаться - у вас больше нет локальных портов. Однако та же проблема применяется на стороне сервера - как только он имеет 64k подключений в TIME_WAIT состоянии для одного клиента , он не может принимать больше подключений от этого клиента. , потому что он не имеет возможности отличить старое соединение от нового соединения - оба соединения идентифицируются одним и тем же кортежем.
похоже, что на сервере просто закончились порты, которые нужно назначить для входящих соединений (на время существующих TIMED_WAIT) - случай DOS-атаки.
Findings so far:
Even if the server closed the socket using system call, its file descriptor will not be released if it enters the TIME_WAIT state. The file descriptor will be released later when the TIME_WAIT state is gone (i.e. after 2*MSL seconds). Therefore, too many TIME_WAITs will possibly lead to 'too many open files' error in the server process.
I believe O/S TCP/IP stack has been implemented with proper data structure (e.g. hash table), so the total number of TIME_WAITs should not affect the performance of the O/S TCP/IP stack. Only the process (server) which owns the sockets in TIME_WAIT state will suffer.