2016-03-29 3 views
1

У нас есть приложение, которое использует HTTP-привязки, которая имеет такую ​​конфигурацию на стороне клиента:ошибка WCF при использовании SSL/TLS

<binding name="SecureStreamedHttpBinding" 
      transferMode="Streamed" 
      maxReceivedMessageSize="8000000000" 
      maxBufferSize="65536" 
      sendTimeout="00:20:00"> 
     <security mode="Transport"> 
     <transport clientCredentialType="None" /> 
     </security> 
    </binding> 

И эту конфигурацию на стороне сервера:

<binding name="SecureStreamedHttpBinding_IHub" 
      transferMode="Streamed" 
      maxReceivedMessageSize="8000000000" 
      maxBufferSize="65536" 
      receiveTimeout="00:20:00"> 
     <security mode="Transport"> 
     <transport clientCredentialType="None"/> 
     </security> 
    </binding> 

канал быть открытым клиентом путем создания ChannelFactory, а затем призывают CreateChannel:

   ChannelFactory<IHub> channelFactory = new ChannelFactory<IHub>(endpointConfigurationName); 
      IHub hub = channelFactory.CreateChannel(); 
      ((IClientChannel)hub).Open(); 

Иногда, когда мы пытаемся передать большие файлы по этому соединению, мы получаем сообщение об ошибке с сервера: «Удаленный сервер вернул неожиданный ответ: (413) Request Entity Too Large». Я иногда говорю, потому что, похоже, существует ряд факторов времени/скорости, которые могут вызвать ошибку. Например, ошибки кажутся более распространенными на машинах с высокой пропускной способностью. Они, кажется, менее распространены, когда начинаются хорошо после установления связи. Однако последствия синхронизации/скорости несовместимы.

Если TLS выключен, у нас никогда не возникло проблем.

У нас есть провод Проведено подключение и установлено, что клиент отправляет сообщение «FIN» на порт примерно в то же время ошибки, но мы точно не знаем, когда возникает ошибка 413, Это видно в Wire Shark. Таким образом, мы не знаем, является ли это причиной или следствием.

Мы также рассмотрели информацию о запрошенном запросе запроса из IIS и обнаружили, что «Request Entity Too Large» перечислено вместе с данными, которые были переданы в то время, но мы не уверены, как интерпретировать то, что мы видим.

Мы не знаем, почему клиент выпускает FIN? Это нормально? Является ли это причиной ошибки «Request Entity Too Large» на сервере или наоборот. Или просто совпадение? В любом случае эффект заключается в том, что мы должны перезапустить передачу файлов в этой точке. Любая мысль о том, что может быть основной причиной ошибки?

Заранее за вашу помощь.

+0

Насколько велики отправленные файлы? Какой худший вариант? То, что я получаю, это ваш maxReceivedMessageSize или maxBufferSize –

+0

Максимальный размер файла реалистично около 4 ГБ, но мы хотели установить ограничение на 8 гб на всякий случай. Мы устанавливаем максимальный размер буфера 65536. Одна вещь, которую мы видели, - это то, что настройка uploadReadAheadSize на большее число полезна, но вы не можете установить ее больше, чем около 2 гб, так что это не поможет с действительно большими файлами. –

+0

Еще одно замечание, хотя максимальный размер файла, который мы ожидаем передать, составляет 4 ГБ, это будут двоичные кодированные данные, которые, я полагаю, расширят размер файла до более чем 5 ГБ. –

ответ

0

Итак, прошло некоторое время с тех пор, как я коснулся WCF, но я думаю, что нашел одну возможную вещь. Ваша проблема может не быть WCF, но вместо этого может быть IIS. После некоторого расследования вы можете столкнуться с проблемами с сертификатом SSL из-за размера запроса.

Этот другой SO ответ хорошо читать, хотя он только частично покрывает ваш вопрос:

IIS7 - (413) Request Entity Too Large | uploadReadAheadSize

Если вы застряли, это может быть стоит выстрел, чтобы позволить переговоры клиента для SSL на ящик IIS. Код копирования/макаронных изделий из исходной ссылки в случае спуска:

Одна из причин, перечисленных в сообщении об ошибке: «Веб-сервер не может обслуживать запрос, поскольку он пытается согласовать сертификат клиента, но объект запроса слишком большой". Решением для этой проблемы было установить значение clientcertnegotiation = enable. Получение этого набора в IIS 7 было немного связано. Следующий, но можно запустить через командную строку:

Netsh HTTP показать sslcert

ПРИМЕЧАНИЕ Вам понадобятся эти настройки для следующего набора команд.

Чтобы удалить текущие настройки (вы не можете изменить существующие настройки, вы должны удалить и readd) Netsh HTTP удалить sslcert:

IP-адрес и порт, полученные из результатов шоу команды. Пример: Netsh HTTP удалить sslcert 0.0.0.0:443

Чтобы добавить настройки CERT назад правильно: Netsh HTTP добавить sslcert ipport =: certhash = AppID = certstorename = clientcertnegotiation = включить

Оригинал статьи:

http://forums.newatlanta.com/messages.cfm?threadid=554611A2-E03F-43DB-92F996F4B6222BC0&#top

Кроме того, обратите внимание на увеличение вашей загрузки упреждающего чтения размер: http://www.iis.net/configreference/system.webserver/serverruntime

Смежные вопросы