Прерванные TCP-соединения

Я смотрю на этот вопрос: .NET создает поврежденные файлы, в частности комментарий @CodesInChaos:

Иногда прерванное TCP-соединение не дает никаких ошибок, а просто ведет себя так, как будто достигнут конец потока.

Я искал больше об этом и нашел здесь: Тайны Соединение закрыть

Любой HTTP-клиент, сервер или прокси-сервер может закрыть транспортное соединение TCP в любое время. Соединения обычно закрываются в конце сообщения[18], но в условиях ошибки соединение может быть закрыто в середине строки заголовка или в других странных местах
...
Когда клиент или прокси-сервер получает HTTP-ответ, завершающийся закрытием соединения, а фактическая длина переданного объекта не соответствует соответствию Content-Length (или отсутствует Content-Length), получатель должен усомниться в правильности длины.

Вопрос. Как возможно, что ошибка транспортного уровня может незаметно распространяться вверх, не вызывая исключения? Я думал, что стандарт TCP включает обработку ошибок - контрольные суммы, порядковые номера пакетов и так далее. У кого-нибудь есть дополнительная информация, например, что может вызывать такие ошибки, или шаги по устранению неполадок?


Изменить: пример 1

некоторые ответы содержат усеченный JSON. то есть мы получаем статус 200, однако JSON искажен и усечен
...
Также отправил детали в поддержку MS с исходным кодом, и они также могут воспроизвести на своей стороне

пример 2

У нас есть пользователь, который получает сообщение об ошибке на странице из-за усечения HTTP-запроса.


person user5226582    schedule 03.04.2017    source источник
comment
Комментарий @CodesInChaos неверен. Ничто не завершает TCP-соединение чисто, кроме закрытия или отправки dshutdown узлом. Если вы используете HTTP, вы должны проверить правильность длины содержимого, и если вы используете приличную библиотеку HTTP, она должна сделать это за вас.   -  person user207421    schedule 03.04.2017
comment
Я видел отчеты об этом поведении, например, stackoverflow .com/questions/29918455/, forums.xamarin.com/ обсуждение/8892/   -  person user5226582    schedule 03.04.2017
comment
Итак, если бы это произошло, всегда ли это было бы вызвано реализацией библиотеки HTTP?   -  person user5226582    schedule 03.04.2017