Значительно увеличилось количество новых TCP-соединений # в .NET 4.5 по сравнению с 4.0?

В настоящее время я тестирую свое клиентское приложение WPF/WCF в .NET 4.5 и 4.0 с целью окончательного развертывания 4.5 на всех клиентских машинах. Часть WCF использует BasicHttpBinding/SOAP.

При тестировании двух клиентских версий в одинаковых условиях (Win7 и т. д.) мы наблюдаем 10-кратное увеличение «новых TCP-подключений» к конечной точке сервера SOAP — клиенты 4.0 устанавливают ~450 в час, а клиенты 4.5 устанавливают ~6000. Поскольку мы подключаемся к удаленному серверу, это проблематично, так как установление нового TCP-соединения увеличивает задержку вызова веб-службы.

При использовании версии 4.0 мы предварительно настроили параметры клиента ServicePointManager, чтобы максимизировать повторное использование нашего TCP-соединения, и ожидали, что эти параметры будут применимы к версии 4.5.

Мое приложение обычно выполняет один вызов за раз, возможно, в среднем каждые 10 секунд — с пакетами из 10 одновременных вызовов каждые несколько минут.

Я просмотрел журналы изменений и не нашел ссылок на исправления/изменения, внесенные в эту часть .NET. Может ли кто-нибудь пролить свет на то, что здесь может происходить?

ServicePointManager.UseNagleAlgorithm = true;
ServicePointManager.Expect100Continue = false;
ServicePointManager.DefaultConnectionLimit = 50;
ServicePointManager.MaxServicePointIdleTime = 10000;

Binding binding = new BasicHttpBinding
{
    SendTimeout = TimeSpan.FromSeconds(_settings.SendTimeout),
    ReceiveTimeout = TimeSpan.FromSeconds(_settings.SendTimeout),
    MaxReceivedMessageSize = 1024 * 1024 * 10,
    MaxBufferSize = 1024 * 1024 * 10,
    MaxBufferPoolSize = 1024 * 1024 * 100,
    Security =
        {
            Mode = BasicHttpSecurityMode.TransportCredentialOnly,
            Message = { ClientCredentialType = BasicHttpMessageCredentialType.UserName },
            Transport = { ClientCredentialType = HttpClientCredentialType.Basic },
        },
};

person jamespconnor    schedule 15.05.2013    source источник
comment
Возможно, ваша проблема связана с этим? - support.microsoft.com/kb/2538826 Проблема может быть связана с тем, как потоки назначаются для обработки запросов клиентов.   -  person Xefan    schedule 15.05.2013
comment
@Xefan Интересный момент, но эта ссылка относится к проблемам на стороне сервера, а не к пункту выше, который связан с клиентскими подключениями (сервер не является WCF и не изменился).   -  person Tim Lloyd    schedule 15.05.2013
comment
Сервер случайно отправляет фрагментированный ответ? Существует известная проблема, из-за которой фрагментированные ответы могут привести к закрытию соединения вместо его повторного использования.   -  person JonCole    schedule 15.05.2013
comment
@JonCole Является ли это известной проблемой с .Net 4.5, т. Е. Разве ее не было бы замечено с клиентом .Net 4.0?   -  person Tim Lloyd    schedule 16.05.2013
comment
@JonCole Мы установили, что служба отправляет Transfer-Encoding: chunked без указания заголовка Content-Length. Мы изучаем, почему они включили кодирование по частям, но в то же время, будет ли это причиной различий в поведении, которые мы наблюдаем между .NET 4.0 и 4.5? Служба также отправляет свои ответы, используя кодировку gzip.   -  person jamespconnor    schedule 16.05.2013


Ответы (2)


Это связано с регрессией, которая была введена при устранении другой проблемы. Это связано с фрагментированными ответами Transfer-Encoding от сервера.

Для тех, кто использует HttpWebRequest напрямую, вы можете обойти эту проблему, убедившись, что ваше приложение считывает весь поток ответов. Это означает, что вам нужно вызывать метод Read или BeginRead для потока до тех пор, пока он не вернет 0 в качестве количества прочитанных байтов.

Для тех, кто использует технологию упаковки, такую ​​как WCF, нет известного обходного пути на стороне клиента. Если у вас есть доступ к серверу, вы можете изменить свой сервер, чтобы он отправлял ответ на основе длины содержимого вместо ответа, разбитого на фрагменты, что должно позволить вам избежать проблемных путей кода на клиенте.

Было найдено исправление для этой проблемы, которое будет выпущено в следующем обновлении платформы. Если это блокирует вас, обратитесь в службу поддержки Microsoft.

person JonCole    schedule 22.05.2013
comment
Спасибо @JonCole. Мы ждем обновления фреймворка и установим обратный прокси-сервер, чтобы противодействовать проблеме с задержкой при трехэтапном рукопожатии (помимо других преимуществ, которые мы получим от этого). - person jamespconnor; 24.05.2013
comment
@jamespconnor Если это блокирует вас, вы можете обратиться в службу поддержки Microsoft для получения KB2846046. - person Varun; 29.05.2013
comment
Привет @Varun, я не могу найти подробности об этой базе знаний нигде в Интернете, кроме краткого упоминания об исправлении Win8? Является ли KB2846046 каким-то исправлением этой проблемы? Мы используем Win7 на наших рабочих станциях. - person jamespconnor; 30.05.2013
comment
Нашел его сейчас - support.microsoft.com/kb/2846046, но похоже, что он применим к Windows только 8? - person jamespconnor; 01.07.2013

Эта проблема устранена с помощью следующих исправлений:

Win7: http://support.microsoft.com/kb/2846044 Win8: http://support.microsoft.com/kb/2846046

Мы проверили, что патч для Win7 работает.

person jamespconnor    schedule 09.07.2013