HttpWebRequest некоторые неочевидности

Я последнее время достаточно много работал с классом HttpWebRequest (позволяет делать запросы к серверу на .NET) и столкнулся с некоторыми моментами, которые весьма неочевидны, но о которых следует знать, если им активно пользоваться.

• Сколько бы вы не создали клиентов, в реальности одновременно к серверу будут идти 2 запроса, остальные попадут в очередь. Планируйте это при реализации параллельности. Изменить количество можно установив ServicePoint.ConnectionLimit или уникальный ConnectionGroupName
• Балансировка запросов в настоящий момент достаточно туповатая, поэтому, если вам в принципе достаточно небольшого количества одновременных коннекций, но некоторые могут занимать долгое время, вы можете получить нехорошую проблему: запрос зависнет в очереди. Происходит это тогда, когда кончаются все доступные коннекшены, запрос уходит в очередь к какому-либо из них, и продолжится когда тот закончится. Если при этом освобождаются другие — это ни на что не влияет. Т.е. вы можете получить пиковую нагрузку, очередь и толпу отвалившихся запросов, в случае если один будет долгим, а другие пристроятся ему в хвост.
• Timeout на самом деле ограничивает время выполнения всего запроса, а не ожидания данных. Т.е. если вы не спеша получаете файл в 10Gb, вам плюнется таймаут. Не забудьте увеличить. А проблемы с долгим соединением решайте вручную парой Begin/End
• Если вы используете Begin/End (BeginGetRequestStream, например), и решаете забросить запрос в случае долгого ответа, не забудьте сделать Abort, а то запрос может дойти, когда его уже никто не ждёт и не хочет обрабатывать
• Несмотря на возможность установить AllowWriteStreamBuffering в false, память всё равно будет сжираться где-то в его недрах (возможно поправят поведение, ибо кажется багом, т.к. данные уходят по факту), так что при передаче гигабайт данных для надёжноти включите чанкинг
• Размер данных, при которых будет отправка не регулируется, опытным путём установлено, что при чанкинге он 1024 байта. Т.е. если вы хотите медленно посылать небольшие порции данных на сервер, вы можете посылать их тупо в буфер, так что лучше не делать подобное и посылать всё целиком (получать данные с сервера маленькими кусками можно)
• Если на сервере используется недоверенный https сертификат, то чтобы не получать ошибку соединения, надо подписаться на ServicePointManager.ServerVerificationCallback и там проверять сертификат на корректность. Метод статичный, так что следите за тем, чтобы не перехватывать чужие запросы (если в вашем приложении ещё кто-то посылает данные)
• HttpWebRequest использует своё кеширование DNS, по умолчанию 2 минуты. Что странно, т.к. резолв идёт через системный DNS-кеш, т.е. накладных расходов не происходит. Можно изменить это время в ServicePointManager.DnsRefreshTimeout, и аккуратнее с KeepAlive, т.к. при его наличии будет держаться коннекшен к серверу некоторе время, и резолва не произойдёт.
• Если сервер вам посылает данные очень медленно, то проверить не умер ли он, можно установив ServicePoint.SetTcpKeepAlive, что позволит пинговать сервер средствами TCP, и получить ошибку в случае если сервер реально пропал.

На этом пока всё, если будут ещё интересные моменты, то буду обновлять пост.