@oyjc @hibobby 想要的功能实现不了，新手吐槽一下而已，别这么认真

#66 还有 #29 我站着不动，你们去拿刀。

要用 socket 实现 httpclient，不否认可以实现，里面的工作量有多大，写出来比框架自带的是好还是坏，我就不知道了。老是诱导我们这群小白去磨一些很基础但很重要，深入发现里面异常庞大的东西。

@wizardforcel 98%情况下是有用的，我需要那 2%，嘿嘿

@nannanziyu 嗯嗯，还在学，新收到 Task.WhenAny、Task.Delay 新知识。

查询了一下 Task.Delay，https://blog.csdn.net/wushang923/article/details/41015063 本质上是开了一个计时器。

试了一下 WebRequest 的 GetRequestStreamAsync、GetResponseAsync，昨天测试没发现这两个方法，和 BeginGetRequestStream 和 BeginGetResponse 一样是异步方法，功能差不多，前面的两个简洁多了。

现在已经换掉了昨天写的 BeginGetRequestStream、BeginGetResponse，直接用的 BeginGetRequestStream().Wait(timeout)，这部分代码少了一半。

隐约发现 HttpWebRequest 好像已经过时了。。

-----------

#45 这几点如果抛开上下文来看，确实很滑稽，我现在看一遍我自己也发笑。

--

ConnectTimeout 是 WebRequest 没有提供的，看文档这个应该是和 GetRequestStream 超时差不多，所以 ConnectTimeout≈Timeout(GetRequestStream 之前设置值)，但 Timeout 有点小缺陷（ dns 查询部分）。

所以就有了“拿到请求 Stream 才能处理 ConnectTimeout ”

--

GetRequestStream 方法 GET、HEAD method 是禁止调用的，就有了“ get 里发 body ”，并非真要往 stream 里面塞数据。

--

一个 task 对象背后的具体实现由于不明确，认定有 0-50ms 延时不为过，参考 Task.Delay，测试过程中发会多出 30ms 左右。

done.


------------------


其实写这个帖子根源还是我想要一个 ConnectTimeout 设定，因为请求一个 url，如果连接不上服务器应该立即返回错误，而 ConnectTimeout 应该远远小于 GetResponse 的超时。比如：ConnectTimeout=2 秒能满足 99.9%的需求，但 GetResponseTimeout 就需要根据不同业务来定，如访问 V2EX，会 GetResponseTimeout=10 秒，虽然很多情况下 1 秒就能拿到响应，但很多时候 V2 会卡很久才会开始返回响应头(经常刷 V2 就是这个感觉)。

应用场景：用户提交任意 URL，尽快速度测试 URL 是否有效，URL 中 50%可能是被墙地址，比如 google.com ，先决条件：需要让 V2EX 等可能会响应慢的地址尽可能通过测试。

简单有效的解决方案就是使用 ConnectTimeout=2 秒，如果连接不上服务器 2 秒就超时了，不管是被墙还是服务器宕机。GetResponseTimeout=10 秒，让响应慢的地址尽可能通过测试。

回到.net ，POST 可以用 GetRequestStream 来支持 ConnectTimeout。GET 目前学习发现暂时无解，只能等到 GetResponseTimeout 超时。


又洋洋洒洒的写了一篇作文，耗时半小时，划水，划水



----

@passerbytiny 好吧，发现帖子正文和上面楼层自己回复的和想要的功能有点出入，这个里在详细重新描述了一下。缺乏一个功能肯定会带来某些功能的丧失，我这个请求功能是从 java 里写的一个类中移植过来的，java 里面 HttpURLConnection 可控制的参数多些，有 setConnectTimeout。

@forerunner .net framework 4.5

----
.net core 的实现瞄了一下文档发现没什么区别好像，dns 查询部分都是没纳入 timeout 中

@verrickt 嗯，学习了。IAsyncResult 估计是历史包袱。

@liuguang public abstract class WebRequest

abstract 需要查实现 public class HttpWebRequest : System.Net.WebRequest 然后会发现帖子正文中的引用内容

@verrickt 嗯嗯，HttpClient 和 WebRequest 一个尿性：it may take 15 seconds or more before a WebException is thrown to indicate a timeout on your request，timeout 是不管 dns 解析部分超时

用 CancallationTokenSource 和 @ZhLTE #16 的建议一个意思，HttpClient 有相应方法支持，WebRequest 有点不好办

@fwee 研究 get request body 的时候发现的一篇文章： https://blog.csdn.net/q_an1314/article/details/51298073，我不是要用 GET 来发请求体，而是遇上了需要拿到请求 Stream 才能处理 ConnectTimeout，但 GET 不让拿 RequestStream，导致 GET 部分无解，真遇上了“ GET 不让发请求体”，有点为难

@xupefei 不要在意其他人的回复，我回复 19 楼是很认真的，task 你没有遇到 task 的线程池占满的情况，不排除永远等待的可能

其他楼层杠的我脾气很暴躁，包涵包涵~

@luozic
@zkd8907
@cdwyd

我也是一个杠精，何况在我自己写的帖子里面，百毒不侵，(doge+滑稽+辣稽

@xupefei 隔壁 java 笑了，哈哈哈，一些简单功能的缺失，用大的代价来弥补一下的做法，不到万不得已，不开相对重量级的 task，毕竟大部分请求 50ms 以内就完成了，一个 task 下来可能额外需要等待 0-50ms 才会做实际的任务

@daigouspy 一样

网络请求这种耗费时间的，按理应该提供比较精细的超时控制，jdk 就没有这个问题。
想到正则表达式都有超时控制，一个网络请求基本的东西，还要开线程控制超时，就是底层太简陋了。
.net 明显的缺陷看 dns 查询部分，太不靠谱

@yulitian888 字面意思 HttpClient extend WebClient，WebClient using HttpWebRequest，仅字面意思

@ZhLTE 差不多这意思，从请求创建开始，不管是哪里卡了，只要到时间还么有最终结果就是超时

@catcn 刀呢

@ZhLTE 比如 get 一下 www.dropbox.com ，能达到预期（ 2 秒超时就是 2 秒超时）的语言就是 ok，.net 就是渣渣

@cjw1115 @daigouspy 用什么都无所谓，关键是需要的功能有没有，有 System.Net.Http.HttpClient 这个框架自带的，配置设置基本没有，因为够简单，满足 98%的需求吧，2%就呵呵，仅此而已

辣眼睛 绝对是没有经过设计，然后没有前端写 css，100%是后端人员临时写的 html 代码

备案：
http://wx4.sinaimg.cn/large/a32300cdgy1fv2x1nwpnmj20zha4eb2g.jpg

是时候展现真正的技术了 代码改一改绝对管用：fooB( Cls cls_If_传_Null_弹小 JJ )

看到 private 我就笑了笑 不说话