Являются ли TCP-соединения ресурсоемкими?

Question

У меня есть TCP-сервер, который получает данные от одного (и только одного) клиента. Когда этот клиент отправляет данные, он устанавливает соединение с моим сервером, отправляет одно (логическое) сообщение, а затем больше не отправляет это соединение.

Затем будет установлено другое соединение для отправки следующего сообщения.

У меня есть сотрудник, который говорит, что это очень плохо с точки зрения ресурсов. Он говорит, что установление соединения требует больших ресурсов и занимает много времени. Он говорит, что мне нужно, чтобы этот клиент установил соединение, а затем просто продолжал использовать его до тех пор, пока нам нужно общаться (или пока не возникнет ошибка).

Одним из преимуществ использования отдельных соединений является то, что я, вероятно, могу их многопоточить и получить большую пропускную способность в линии. Я упомянул об этом своему коллеге, и он сказал мне, что наличие множества открытых сокетов убьет сервер.

Это правда? Или я могу просто позволить ему создать отдельное соединение для каждого логического сообщения, которое нужно отправить. (Обратите внимание, что под логическим сообщением я имею в виду XML-файл переменной длины.)

Answer 1

Это полностью зависит от количества соединений, которые вы собираетесь открывать и закрывать, и скорости, с которой вы собираетесь их открывать.

Если вы не выходите из своего пути, чтобы избежать состояния TIME_WAITпрерывая соединения, а не закрывая их изящно, вы будете накапливать сокеты в состоянии TIME_WAIT на клиенте или сервере.С одним клиентом на самом деле не имеет значения, где они накапливаются, поскольку проблема будет одинаковой.Если скорость, с которой вы используете свои соединения, выше, чем скорость, с которой закрываются ваши TIME_WAIT соединения, то вы в конечном итоге попадете в точку, где вы не сможете открывать какие-либо новые соединения, потому что у вас нет временных портов, так как все они находятся виспользовать с сокетами, которые находятся в TIME_WAIT.

. Я напишу об этом более подробно здесь: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

В общем, я бы посоветовал вам сохранить одно соединение и просто снова открыть егоесли он сбрасывается.Логика может показаться немного более сложной, но система будет масштабироваться гораздо лучше;у вас сейчас может быть только один клиент, и частота подключений может быть такой, что вы не ожидаете, что будете страдать от TIME_WAIT проблем, но эти факты могут не остаться неизменными на протяжении всей жизни вашей системы ...

Answer 2

С точки зрения серверов, открывать очень большое количество соединений не проблема.

Сколько сокет-соединений может обрабатывать веб-сервер?

С точки зрения клиентов, если измерение показывает, что необходимо , чтобы избежать времени инициирования соединений и вам требуется параллелизм, вы можете создать пул соединений. Несколько потоков могут повторно использовать каждое из соединений и выпустить их обратно в пул, когда они будут сделаны. Это повышает уровень сложности, поэтому еще раз убедитесь, что он вам нужен. Вы также можете иметь логику для сокращения и увеличения пула на основе активности - было бы стыдно держать соединения открытыми с сервером в течение ночи, пока приложение просто бездействует.

Answer 3

Если на вашем сервере только один клиент, я не могу представить, чтобы на практике возникли проблемы с открытием нового сокета TCP для каждого сообщения.Похоже, ваш коллега любит преждевременную оптимизацию.

Однако, если вы заполняете сервер сообщениями, это может стать проблемой.Но, тем не менее, с одним клиентом я бы не беспокоился об этом.

Просто убедитесь, что вы закрыли сокет, когда закончите с ним.Не надо хамить серверу:)

Answer 4

В дополнение к тому, что все сказали, рассмотрим UDP. Он идеально подходит для небольших сообщений, где не ожидается ответа, а в локальной сети (в отличие от Интернета) он практически надежен.

Answer 5

Последовательность инициализации TCP-соединения представляет собой очень простое трехстороннее рукопожатие, которое имеет очень низкие издержки. Нет необходимости поддерживать постоянное соединение.

Кроме того, наличие множества TCP-соединений не убьет ваш сервер так быстро. современное оборудование и операционные системы могут обрабатывать сотни одновременных TCP-соединений, если вы не боитесь атак типа «отказ в обслуживании», которые явно выходят за рамки этого вопроса.