一切福田,不離方寸,從心而覓,感無不通。

Category Archives: Programming Language

C#中HttpClient使用注意:预热与长连接

原文地址:C#中HttpClient使用注意:预热与长连接 最近在测试一个第三方API,准备集成在我们的网站应用中。API的调用使用的是.NET中的HttpClient,由于这个API会在关键业务中用到,对调用API的整体响应速度有严格要求,所以对HttpClient有了格外的关注。 开始测试的时候,只在客户端通过HttpClient用PostAsync发了一个http post请求。测试时发现,从创建HttpClient实例,到发出请求,到读取到服务器的响应数据总耗时在2s左右,而且多次测试都是这样。2s的响应速度当然是无法让人接受的,我们希望至少控制在100ms以内。于是开始追查这个问题的原因。 在API的返回数据中包含了该请求在服务端执行的耗时,这个耗时都在20ms以内,问题与服务端API无关。于是把怀疑点放到了网络延迟上,但ping服务器的响应时间都在10ms左右,网络延迟的可能性也不大。 当我们正准备换一个网络环境进行测试时,突然想到,我们的测试方式有些问题。我们只通过HttpClient发了一个PostAsync请求,假如HttpClient在第一次调用时存在某种预热机制(比如在EF中就有这样的机制),现在2s的总耗时可能大多消耗在HttpClient的预热上。 于是修改测试代码,将调用由1次改为100次,然后恍然大悟地发现——只有第1次是2s,接下来的99次都在100ms以内。果然是HttpClient的某种预热机制在搞鬼! 既然知道了是HttpClient预热机制的原因,那我们可以帮HttpClient进行热身,减少第一次请求的耗时。我们尝试了一种预热方式,在正式发http post请求之前,先发一个http head请求,代码如下:

经测试,通过这种热身方法,可以将第一次请求的耗时由2s左右降到1s以内(测试结果是700多ms)。 在知道第1次HttpClient请求耗时2s的真相之后,我们将目光转向了剩下的99次耗时100ms以内的请求,发现绝大部分请求都在50ms以上。有没有可能将之降至50ms以下?而且,之前一直有这样的纠结:每次调用是不是一定要对HttpClient进行Dispose()?是不是要将HttpClient单例或者静态化(声明为静态变量)?借此机会一起研究一下。 在HttpClient的背后,有一个对请求响应速度有着不容忽视影响的东东——TCP连接。一个HttpClient实例会关联一个TCP连接,在对HttpClient进行Dispose时,会关闭TCP连接(我们用Wireshark进行网络抓包也验证了这一点)。 在之前的测试中,我们每次用HttpClient发请求时,都是新建一个HttpClient实例,用完就对它进行Dispose,代码如下:

所以每次请求时都要经历新建TCP连接->传数据->关闭连接(也就是通常所说的短连接),而且雪上加霜的是请求用的是https,建立TCP连接时还需要一个基于公私钥加解密的key exchange过程:Client Hello -> Server Hello -> Certificate -> Client Key Exchange -> New Session Ticket。 如果我们想将请求响应时间降至50ms以下,就必须从这个地方下手——重用TCP连接(也就是通常所说的长连接)。要实现长连接,首先需要的就是在HttpClient第1次请求后不关闭TCP连接(不调用Dispose方法);而要让后续的请求继续使用这个未关闭的TCP连接,我们必须要使用同一个HttpClient实例;而要使用同一个HttpClient实例,就得实现HttpClient的单例或者静态化。之前的3 个问题,由于要解决第1个问题,后2个问题变成了别无选择。 为了实现长连接,我们将HttpClient的调用代码改为如下的样子:

然后测试一下请求响应时间:

除了第1次请求,接下来的99次请求绝大多数都在50ms以内。TCP长连接的效果必须的! 通过Wireshak抓包也验证了长连接的效果: 这时,你也许会产生这样的疑问:将HttpClient声明为静态变量,会不会存在线程安全问题?我们当时也有这样的疑问,后来在stackoverflow上找到了答案:

HttpClient的所有异步方法都是线程安全的,放心使用。 到这里,HttpClient的问题是不是可以完美收官了?。。。稍等,还有一个问题。 客户端虽然保持着TCP连接,但TCP连接是两口子的事,服务器端呢?你不告诉服务器,服务器怎么知道你要一直保持TCP连接呢?对于客户端,保持TCP连接的开销不大;但是对于服务器,则完全不一样的,如果默认都保持TCP连接,那可是要保持成千上万客户端的连接啊。所以,一般的Web服务器都会根据客户端的诉求来决定是否保持TCP连接,这就是keep-alive存在的理由。 所以,我们还要给HttpClient增加一个Connection:keep-alive的请求头,代码如下:

现在终于可以收官了。但是肯定不完美,分享的只是解决问题的过程。   from:https://www.cnblogs.com/JustYong/p/5872296.html

龙生   07 Oct 2018
View Details

C# HttpClient请求

  from:https://www.cnblogs.com/louby/p/8021527.html

龙生   07 Oct 2018
View Details

c# Http请求之HttpClient

利用HttpClient进行Http请求,基于此,简单地封装了下:

有关更多的Http请求,请看这里:https://github.com/wangqiang3311/HttpRequestDemo from:http://www.cnblogs.com/wangqiang3311/p/8991214.html

龙生   07 Oct 2018
View Details

C# 中使用System.Net.Http.HttpClient 模拟登录博客园 (GET/POST)

一、 System.Net.Http.HttpClient简介 System.Net.Http 是微软.net4.5中推出的HTTP 应用程序的编程接口, 微软称之为“现代化的 HTTP 编程接口”, 主要提供如下内容: 1. 用户通过 HTTP 使用现代化的 Web Service 的客户端组件; 2. 能够同时在客户端与服务端同时使用的 HTTP 组件(比如处理 HTTP 标头和消息), 为客户端和服务端提供一致的编程模型。 个人看来是抄袭apache http client ,目前网上用的人好像不多,个人认为使用httpclient最大的好处是:不用自己管理cookie,只要负责写好请求即可。 由于网上资料不多,这里借登录博客园网站做个简单的总结其get和post请求的用法。 查看微软的api可以发现其属性方法:http://msdn.microsoft.com/zh-cn/library/system.net.http.httpclient.aspx 由其api可以看出如果想设置请求头只需要在DefaultRequestHeaders里进行设置 创建httpcliet可以直接new HttpClient() 发送请求可以按发送方式分别调用其方法,如get调用GetAsync(Uri),post调用PostAsync(Uri, HttpContent),其它依此类推。。。 二、实例(模拟post登录博客园) 首先,需要说明的是,本实例环境是win7 64位+vs 2013+ .net 4.5框架。 1.使用vs2013新建一个控制台程序,或者窗体程序,如下图所示: 2.必须引入System.Net.Http框架,否则将不能使用httpclient 3.实现代码

代码分析: 首先,从Main函数开始,调用LoginCnblogs方法; 其次,使用GET方法:

再者,使用POST方法:

最后,注意其返回值可以是string,也可以是byte[],和stream的方式,这里看你需要什么吧。   4.登录成功后的截图 1).使用浏览器登录后的截图: 2).使用Httpcliet登录后的截图:   总结,可以发现C#中HttpClient的用法和Java中非常相似,所以,说其抄袭确实不为过。   from:https://www.cnblogs.com/amosli/p/3918538.html

龙生   07 Oct 2018
View Details

C# HttpClient设置cookies的两种办法 (转发)

一般有两种办法 第一种handler.UseCookies=true(默认为true),默认的会自己带上cookies,例如

这种情况post请求登陆成功后,重定向到别的页面,也会自动带上cookies。如果把handler.UseCookies设置为false,登陆后重定向的话不会自动带上cookies,则又会跳转到登陆页面。   第二种设置 handler.UseCookies = false时,则需要手动给headers上加入cookies.

如果使用场景是:抓取需要登陆后才能看到的网页数据,建议使用第一种,不需要设置任何cookies,httpclient会自动把登陆后的cookies放置到后面的请求中。   原贴 : http://www.cnblogs.com/xiaozhu39505/p/8033108.html from:https://www.cnblogs.com/refuge/p/8060142.html

龙生   07 Oct 2018
View Details

使用ML.NET预测纽约出租车费

有了上一篇《.NET Core玩转机器学习》打基础,这一次我们以纽约出租车费的预测做为新的场景案例,来体验一下回归模型。 场景概述 我们的目标是预测纽约的出租车费,乍一看似乎仅仅取决于行程的距离和时长,然而纽约的出租车供应商对其他因素,如额外的乘客数、信用卡而不是现金支付等,会综合考虑而收取不同数额的费用。纽约市官方给出了一份样本数据。   确定策略 为了能够预测出租车费,我们选择通过机器学习建立一个回归模型。使用官方提供的真实数据进行拟合,在训练模型的过程中确定真正能影响出租车费的决定性特征。在获得模型后,对模型进行评估验证,如果偏差在接受的范围内,就以这个模型来对新的数据进行预测。   解决方案 创建项目 看过上一篇文章的读者,就比较轻车熟路了,推荐使用Visual Studio 2017创建一个.NET Core的控制台应用程序项目,命名为TaxiFarePrediction。使用NuGet包管理工具添加对Microsoft.ML的引用。 准备数据集 下载训练数据集taxi-fare-train.csv和验证数据集taxi-fare-test.csv,数据集的内容类似为:

对字段简单说明一下: 字段名 含义 说明 vendor_id 供应商编号 特征值 rate_code 比率码 特征值 passenger_count 乘客人数 特征值 trip_time_in_secs 行程时长 特征值 trip_distance 行程距离 特征值 payment_type 支付类型 特征值 fare_amount 费用 目标值 在项目中添加一个Data目录,将两份数据集复制到该目录下,对文件属性设置“复制到输出目录”。 定义数据类型和路径 首先声明相关的包引用。

在Main函数的上方定义一些使用到的常量。

接下来定义一些使用到的数据类型,以及和数据集中每一行的位置对应关系。

  创建处理过程 创建一个Train方法,定义对数据集的处理过程,随后声明一个模型接收训练后的结果,在返回前把模型保存到指定的位置,以便以后直接取出来使用不需要再重新训练。

  评估验证模型 创建一个Evaluate方法,对训练后的模型进行验证评估。

  预测新数据 定义一个被用于预测的新数据,对于各个特征进行恰当地赋值。

预测的方法很简单,prediction即预测的结果,从中打印出预测的费用和真实费用。

  运行结果 到此我们完成了所有的步骤,关于这些代码的详细说明,可以参看《Tutorial: Use ML.NET to Predict New York Taxi Fares (Regression)》,只是要注意该文中的部分代码有误,由于使用到了C# 7.1的语法特性,本文的代码是经过了修正的。完整的代码如下:

  不知不觉我们的ML.NET之旅又向前进了一步,是不是对于使用.NET Core进行机器学习解决现实生活中的问题更有兴趣了?请保持关注吧。   from:http://www.cnblogs.com/BeanHsiang/p/9017618.html

龙生   15 Sep 2018
View Details

.NET Core玩转机器学习

ML.NET 专门为.NET开发者提供了一套跨平台的开源的机器学习框架。 ML.NET支持.NET开发者不需要过度专业的机器学习开发经验,就能轻松地训练自己的模型,并且嵌入到自己的应用中。一切尽在.NET之中。ML.NET早期是由Microsoft Research开发,近十年来逐步集成到一个大体系中被众多Microsoft产品使用,如大家熟知的Windows、Bing、PowerPoint、Excel之类。 ML.NET的第一个预览版提供了分类器(如文本分类、情感分析)和回归(如价格预测)等实用的机器学习模型。第一版发布后在既有功能之上又新增了关于训练模型的.NET API,使用这些模型进行预测,就像框架中算法、转换、数据结构一类核心组件一样的开发体验。 接下来用个示例,一起进入快速上手的实践中来。 安装.NET SDK 为了创建一个.NET应用,首先下载 .NET SDK。 创建应用 使用如下命令初始化项目,创建一个控制台应用程序,目标为myApp:

  安装ML.NET包 使用如下命令安装Microsoft.ML包:

  下载数据集 假设我们使用机器学习来预测鸢尾花的类型,比如有setosa、versicolor、virginica三种,基于特征有四种:花瓣长度、花瓣宽度, 萼片长度、萼片宽度。 去UCI Machine Learning Repository: Iris Data Set下载一个现成的数据集,复制粘贴其中的数据到任何一个文本编辑器中,然后保存命名为iris-data.txt到myApp目录中。 粘贴完文本内容应该是如下格式,每一行表示不同鸢尾花的样本,数值的部分从左到右依次是萼片长度、萼片宽度、花瓣长度、花瓣宽度,最后是鸢尾花的类型。

如果是使用了Visual Studio,将iris-data.txt添加至项目中,需要进行如下配置确保运行时数据集文件在输出的目录中。 编写代码 打开Program.cs文件,输入以下代码:

运行应用 使用如下命令行运行程序:

  在最后一行将输出对花的预测结果,你可以修改传给Predict函数各种鸢尾花的特征值看看有什么不同的结果。 恭喜,你已经跨入使用ML.NET进行机器学习的门槛了!   from:http://www.cnblogs.com/BeanHsiang/p/9010267.html

龙生   15 Sep 2018
View Details

asp.net core类库发布到nuget服务一定要建目标环境文件夹

最近公司有些小项目要用asp.net core尝试一下,局域网内建了内部的nuget服务。今天搞好.net core类库后发布过程一切顺利。 但在具体的项目中还原nuget包后直接提示: 警告 NU1701 已使用“.NETFramework,Version=v4.6.1”而不是项目目标框架“.NETCoreApp,Version=v2.1”还原包“DBCore 1.0.8”。此包可能与项目不完全兼容。 首先,怀疑是不是引用了.net core不支持的类库,然后把依赖全删除,不行。 然后,还是怀疑自己的类库有问题,就新建了一个空白的.net core类库,还原后还是提示。 然后,拿redis的nuget包发布上去,还原了一下,还是提示。 最后发现redis的类库是以目标框架作为文件夹的!!!然后在lib下增加了文件夹netcoreapp2.1,问题解决。

龙生   11 Sep 2018
View Details

在ASP.NET Core中怎么使用HttpContext.Current

一、前言 我们都知道,ASP.NET Core作为最新的框架,在MVC5和ASP.NET WebForm的基础上做了大量的重构。如果我们想使用以前版本中的HttpContext.Current的话,目前是不可用的,因为ASP.NET Core中是并没有这个API的。 当然我们也可以通过在Controller中访问HttpContext,但是某些情况下,这样使用起来还是不如HttpContext.Current方便。 二、IHttpContextAccessor 利用ASP.NET Core的依赖注入容器系统,通过请求获取IHttpContextAccessor接口,我们拥有模拟使用HttpContext.Current这样API的可能性。但是因为IHttpContextAccessor接口默认不是由依赖注入进行实例管理的。我们先要将它注册到ServiceCollection中:

来模拟一个HttpContext.Current吧:

其实说到HttpContext.Current就不得不提到多线程问题,在以前的ASP.NET版本中,如果遇到多线程环境很有可能HttpContext.Current为空的情况。说到这个问题以前就是有解决方案的,那就是CallContext; CallContext 是类似于方法调用的线程本地存储区的专用集合对象,并提供对每个逻辑执行线程都唯一的数据槽。数据槽不在其他逻辑线程上的调用上下文之间共享。当 CallContext 沿执行代码路径往返传播并且由该路径中的各个对象检查时,可将对象添加到其中。 当使用ASP.NET的时候,虽然线城池里的线程是复用的,但是CallContext并不在一个线程的多次使用中共享。因为CallContext是针对逻辑线程的TLS,线程池中被复用的线程是操作系统中的内核对象而不是托管对象。就像数据库连接池中保存的是非托管资源而不是托管资源。因此,先后执行的两个托管线程可能在底层复用了一个物理线程(内核对象),但并不能共享同一组CallContext数据槽。就像先后new的两个SqlConnection对象可能在底层使用了同一个物理连接,但是托管对象的属性已经被重置。 与此对照的是ThreadStaticAttribute,标记上这个特性的静态字段是往物理线程的TLS中保存数据(根据MSDN的描述猜的。具体没试过),因此如果两个托管线程对象内部使用的是同一个物理线程,则这个字段会复用(在两个线程通过这一字段访问同一个数据槽)。 在.NET Core中,也有新的API选择,AsyncLocal<T>。 三、HttpContextAccessor 我们来看看ASP.NET Core中的IHttpContextAccessor接口实现吧:

最后我只能说在ASP.NET Core中是万物皆DI啊,其实Core中的实现早就为我们想好了这些功能,只是改变了使用方式。   GitHub:https://github.com/maxzhang1985/YOYOFx  如果觉还可以请Star下, 欢迎一起交流。   .NET Core 开源学习群: 214741894     from:https://www.cnblogs.com/maxzhang1985/p/6186455.html

龙生   11 Sep 2018
View Details

ASP.NET Core 2.0获取IP地址

在我们用来获取客户端IP地址的传统ASP.NET中Request.UserHostAddress。但是这不适用于ASP.NET Core 2.0。我们需要一种不同的方式来检索HTTP请求信息。 1.在你的MVC控制器中定义一个变量

  2. DI进入控制器的构造函数 public SomeController(IHttpContextAccessor accessor) { _accessor = accessor; } 3.回传IP地址

  这RemoteIpAddress是在类型IPAddress,而不是string。它包含了IPv4,IPv6等信息,它不像经典的ASP.NET,对我们来说更有用。   from:https://blog.csdn.net/yzj_xiaoyue/article/details/79200714

龙生   11 Sep 2018
View Details
1 78 79 80 175