Правильный порядок закрытия соединений TcpListener и TcpClient (какая сторона должна быть активным закрытием)

я прочитала это ответ на предыдущий вопрос он говорит:

таким образом, одноранговый узел, который инициирует завершение, т. е. сначала вызывает close (), окажется в состоянии TIME_WAIT. [...]

однако это может быть проблема с большим количеством сокетов в состоянии TIME_WAIT на сервере, поскольку это может в конечном итоге предотвратить принятие новых соединений. [...]

вместо этого создайте свой протокол приложения, чтобы соединение прекращение всегда инициируется со стороны клиента. Если клиент всегда знает, когда он прочитал все оставшиеся данные, он может инициировать последовательность завершения. Например, браузер знает из HTTP-заголовка Content-Length, когда он прочитал все данные и может инициировать закрытие. (Я знаю, что в HTTP 1.1 он будет держать его открытым некоторое время для возможного повторного использования, а затем закройте его.)

Я хотел бы реализовать это с помощью TcpClient/TcpListener, но это не понятно, как заставить его работать правильно.

подход 1: обе стороны закрываются

это типичный способ иллюстрации большинства примеров MSDN - обе стороны называют Close(), не только клиент:

private static void AcceptLoop()
{
    listener.BeginAcceptTcpClient(ar =>
    {
        var tcpClient = listener.EndAcceptTcpClient(ar);

        ThreadPool.QueueUserWorkItem(delegate
        {
            var stream = tcpClient.GetStream();
            ReadSomeData(stream);
            WriteSomeData(stream);
            tcpClient.Close();   <---- note
        });

        AcceptLoop();
    }, null);
}

private static void ExecuteClient()
{
    using (var client = new TcpClient())
    {
        client.Connect("localhost", 8012);

        using (var stream = client.GetStream())
        {
            WriteSomeData(stream);
            ReadSomeData(stream);
        }
    }
}

после того, как я запустил это с 20 клиентами,программы TCPView показывает много сокетов из клиент и сервер застрял в TIME_WAIT, которые занимают довольно много времени, чтобы исчезнуть.

подход 2: просто клиент close

согласно цитатам выше, я удалил Close() вызывает моего слушателя, и теперь я просто полагаюсь на закрытие клиента:

var tcpClient = listener.EndAcceptTcpClient(ar);

ThreadPool.QueueUserWorkItem(delegate
{
    var stream = tcpClient.GetStream();
    ReadSomeData(stream);
    WriteSomeData(stream);
    // tcpClient.Close();   <-- Let the client close
});

AcceptLoop();

теперь у меня больше нет TIME_WAIT, но я получаю сокеты, оставленные на разных этапах CLOSE_WAIT, FIN_WAIT, etc. это также занимает очень много времени, чтобы исчезнуть.

подход 3: Дайте клиенту время, чтобы закрыть первый

в этот раз я добавил задержку перед закрытием сервера соединение:

var tcpClient = listener.EndAcceptTcpClient(ar);

ThreadPool.QueueUserWorkItem(delegate
{
    var stream = tcpClient.GetStream();
    ReadSomeData(stream);
    WriteSomeData(stream);
    Thread.Sleep(100);      // <-- Give the client the opportunity to close first
    tcpClient.Close();      // <-- Now server closes
});

AcceptLoop();

это кажется лучше-теперь только клиентские сокеты находятся в TIME_WAIT; все сокеты сервера закрыты должным образом:

это, похоже, согласуется с тем, что говорится в ранее связанной статье:

таким образом, одноранговый узел, который инициирует завершение, т. е. сначала вызывает close (), окажется в состоянии TIME_WAIT.

вопросы:

1. какой из этих подходы-это правильный путь, и почему? (Предполагая, что я хочу, чтобы клиент был "активным закрытием")
2. есть ли лучший способ реализовать подход 3? Мы хотим, чтобы закрытие было инициировано клиентом (чтобы клиент остался с TIME_WAITs), но когда клиент закрывается, мы также хотим закрыть соединение на сервере.
3. мой сценарий фактически противоположно к веб-серверу; у меня есть один клиент, который подключается и отключается от различных удаленных машины. Я бы предпочел, чтобы у сервера были соединения, застрявшие в TIME_WAIT вместо этого, чтобы освободить ресурсы на моем клиенте. В этом случае, я должен заставить сервер выполнить активный закрытии, и положить сон / закрыть на моего клиента?

полный код, чтобы попробовать его себе здесь:

https://gist.github.com/PaulStovell/a58cd48a5c6b14885cf3

редактировать: еще один полезный ресурс:

http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

для сервера, который устанавливает исходящие соединения, а также принимает входящие соединения, золотое правило всегда должно гарантировать, что если TIME_WAIT должен произойти, что он заканчивается на другом узле, а не на сервере. Лучший способ сделать это-никогда не инициировать активный закрыть от сервера, независимо от причины. Если время ожидания вашего однорангового узла истекло, прервите соединение с первым, а не закрывайте его. Если ваш одноранговый узел отправляет недопустимые данные, прервите соединение и т. д. Идея заключается в том, что если ваш сервер никогда не инициирует активное закрытие, он никогда не сможет накапливать сокеты TIME_WAIT и, следовательно, никогда не будет страдать от проблем масштабируемости, которые они вызывают. Хотя легко увидеть, как вы можете прервать соединения, когда возникают ситуации ошибок, как насчет обычного соединения прекращение? В идеале вы должны разработать в своем протоколе способ для сервера сообщить клиенту, что он должен отключиться, а не просто заставить сервер инициировать активное закрытие. Поэтому, если серверу необходимо прервать соединение, сервер отправляет сообщение уровня приложения "мы закончили", которое клиент принимает за причину закрытия соединения. Если клиенту не удается закрыть соединение в разумное время, сервер прерывает соединение.

на клиенте все немного сложнее, в конце концов, кто-то должен инициировать активное закрытие, чтобы завершить TCP-соединение чисто, и если это клиент, то именно там TIME_WAIT закончится. Однако наличие TIME_WAIT в конечном итоге на клиенте имеет несколько преимуществ. Во-первых, если по какой-то причине у клиента возникают проблемы с подключением из-за накопления сокетов в TIME_WAIT, это всего лишь один клиент. Другие клиенты не будут затронуты. Во-вторых, он неэффективен для быстрого открытия и закройте TCP-соединения с тем же сервером, поэтому имеет смысл за пределами проблемы TIME_WAIT пытаться поддерживать соединения в течение более длительных периодов времени, а не более коротких периодов времени. Не создавайте протокол, по которому клиент подключается к серверу каждую минуту и делает это, открывая новое соединение. Вместо этого используйте постоянную конструкцию соединения и только повторно подключайтесь при сбое соединения, если промежуточные маршрутизаторы отказываются поддерживать соединение открытым без потока данных, вы можете реализуйте ping уровня приложения, используйте TCP keep alive или просто примите, что маршрутизатор сбрасывает ваше соединение; хорошо, что вы не накапливаете сокеты TIME_WAIT. Если работа, которую вы делаете над соединением, естественно, недолговечна, рассмотрите некоторую форму" объединения соединений", при которой соединение остается открытым и повторно используется. Наконец, если вам абсолютно необходимо быстро открывать и закрывать подключения от клиента к тому же серверу, возможно, вы могли бы создать приложение последовательность завершения уровня, которую можно использовать, а затем выполните это с прерывистым закрытием. Ваш клиент может отправить сообщение "я закончил", ваш сервер может отправить сообщение "до свидания", и клиент может прервать соединение.