httpclient

微软文档地址https://docs.microsoft.com/zh-cn/dotnet/api/system.net.http.httpclient?view=netframework-4.7.2，只有get。post 的方法找了白天才解决 using System; using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; using MySql.Data.MySqlClient; using System.Timers; using Newtonsoft.Json; using System.Net.Http; using System.IO; using System.Net; public class user { public string password;//密码hash public string account;//账户 } static async void TaskAsync() { using (var client = new HttpClient()) { try { //序列化 user user = new user(); user.account = "zanllp"; user.password = "zanllp_pw";

简介 在 JDK11的新特性:新的HTTP API 中，我们介绍了通过新的HTTP API，我们可以发送同步或者异步的请求，并获得的返回的结果。 今天我们想探讨一下这些同步或者异步请求和响应和reactive streams的关系。 更多内容请访问 www.flydean.com 怎么在java中使用reactive streams reactive streams的介绍大家可以参考 reactive stream协议详解 ,使用reactive streams的目的就是为了解决发送者和消费者之间的通信问题，发送者不会发送超出消费者能力的信息。 我们再回顾一下reactive streams中的几个关键概念： Publisher 负责产生消息或者事件，并提供了一个subscribed接口来和Subscriber进行连接。 Subscriber 用来subscribe一个Publisher，并提供了onNext方法来处理新的消息，onError来处理异常，onComplete提供给Publisher调用来结束监听。 Subscription 负责连接Publisher和Subscriber，可以用来请求消息或者取消收听。 更进一步，如果我们想要自己实现一个reactive streams，我们需要做这些事情： 创建Publisher和Subscriber

这几天终于弄懂了async和await的模式，也搞明白了一直在心里面积压着的许多问题，所以写一篇博客来和大家分享一下。 关于异步机制我认为只要记住的以下几点，就可以弄明白了： 1.我认为async和awwait两个修饰符中最关键的是await，async是由于方法中包含await修饰符之后才在方法定义中添加的，表明这个方法是一个异步方法。 2.await只能用来修饰Task、Task<TResult>、ValueTask 或 ValueTask<TResult>这些类型的 变量 或者方法，他是一个分裂符， 我们需要记住的最关键一点是当程序进行到await的时候，方法会暂时返回，而await字符之后的内容会等await这一行返回后继续执行。 3.在控制台应用中，await之前的内容是一个线程执行，await以及awiat之后的内容会在另一个线程中执行。 我们在编程时很多时候其实都用错了aiwat，这也导致我一开始学习的时候对await产生了非常多的疑问，以至于一直都没有弄清楚，比如： int bytesLoaded = await DownloadDocsMainPageAsync(); 这个几乎是我们写代码时见到最多的用法了，在主方法中使用await 来做一些request的请求，当时就在想await不是异步吗，但为什么还要在这里等待这个输出才进行下一步的执行呢

问题描述 这两天用Go做一个比较简单的task：后端有HTTPServer和TCPServer。客户端通过http接入到HTTPServer，HTTPServer通过RPC将请求发送到TCPServer，所有的业务逻辑都由TCPServer处理。 压测：自己的mac电脑（CPU：Intel i7, 4核，2.7GHz。内存：16G），硬件够用。客户端用Go编写，1个goruntine启动一个HTTPClient往HTTPServer发送http请求。每个HTTPClient限定为一个HTTP长链接。 问题：压到400个HTTPClient，出现一些错误提示“read: connection reset by peer”。 问题定位以及原因 “connection reset by peer”的含义是往对端写数据的时候，对端提示已经关闭了连接。一般往一个已经被关闭的socket写会提示这个错误。但是通过log分析，服务端没有应用层面的close，客户端也没有应用层面的write。抓包发现客户端建立TCP完成3次握手后，服务端立刻就回了RST。如下图： 这个抓包很好的反应了压测中的现象：错误提示connection reset by peer，但是应用层并没有任何的读写，TCP三次握手后服务端直接通过RST关闭了连接。RST的情况见的多，这种情况着实没有遇到过。最后N次baidu

在向微服务体系架构转型的过程中，我们都会毫不意外地遇到越来越多的现实问题，而这些问题却并不是因为功能性需求而引入的。比如，服务的注册与发现，是应用程序在云中部署、提供可伸缩支持的主要实现方案，在特定的微服务架构中，实践这样的云设计模式是利远远大于弊的。今我们需要讨论的API网关也是这样的一种微服务实现方案，它解决了客户端与服务端之间繁琐的通信问题。 在进一步讨论API网关在微服务架构中的应用前，先一起了解一下目前我手上的两个微服务：A服务提供了数学计算的API，B服务则提供了天气数据查询的API。两者看上去风马牛不相及，然而，B服务中的一个需求使得两者之间产生了密不可分的联系：B服务需要提供某些城市5年来平均气温的标准差，以便用户能够了解各个城市的气温变化情况。业务需求其实挺简单，从一个外部数据源将指定城市的平均气温数据读入，然后计算标准差即可，不过从实现上看，由于A服务已经提供了计算标准差的API，因此，B服务没有必要自己再写一套，只需要调用A服务提供的API即可，也就是A和B之间存在互相调用的情况。另一方面，对于用户来说，也存在需要同时调用A和B两组API的场景，因此，A和B的API也需要向外界曝露，这样一来应用程序的结构大致如下： 也就是上图中B服务的/weather/stddev API将会用到A服务中的/calc/stddev这个API。OK

DotNetCore Is AnyWhere. 前言 Visual Studio 2019 已经正式发布了， DotNetCore 3.0 的正式版也指日可待。在之前的版本中，作为一名基于微软生态的传统 WPF 程序员看着隔壁同学在开发 DotNetCore 网站时用着各种特性好生羡慕，想着巨硬啥时候能让客户端开发者也能尝尝甜头。 那么，现在是时候可以尝试一下了。 需要说明的一点的是， DotNetCore 3.0 虽然跨平台，但是基于此的 WPF 却是针对 Windows 特定平台的实现，并不能跨 Linux 和 MacOS 。 开发环境准备 要想开发 DotNetCore 版本的 WPF，首先需要确保我们的机器上已经安装了如下 Visual Studio 2019 下载地址 需要安装的组件如下图所示 DotNetCore 3.0 SDK 下载地址 直接默认安装即可。 全新的开发体验 在首次使用 VS2019 创建 DotNetCore 版本的 WPF 程序时，VS 可能会给你爆个如下图所示的错误： 按照错误提示即可解决该问题，如下图所示 接着选择 TOOLS -> Options ，配置如下图所示 补充：VS2017 15.9.3 以上版本也是可以创建 DotNetCore 3.0 WPF 的项目模板，同样需要先设置，设置方法和上面叙述的是一样的。 在 16.1

一、最常用的方法（代码中限制） 1、如何限制IP function get_new_ip(){ if(getenv('HTTP_CLIENT_IP')) { $onlineip = getenv('HTTP_CLIENT_IP'); } elseif(getenv('HTTP_X_FORWARDED_FOR')) { $onlineip = getenv('HTTP_X_FORWARDED_FOR'); } elseif(getenv('REMOTE_ADDR')) { $onlineip = getenv('REMOTE_ADDR'); } else { $onlineip = $HTTP_SERVER_VARS['REMOTE_ADDR']; } return $onlineip; } $onlineip = get_new_ip(); $wip = ['127.0.0.1']; if(!in_array($onlineip, $wip)){ header("HTTP/1.1 404 Not Found"); header("Status: 404 Not Found"); exit; } 2、进行密码验证 ///////////////// Password protect ///////////////////////////////////////////////////

最近项目测试遇到个奇怪的现象，在测试环境通过 Apache HttpClient 调用后端的 HTTP 服务，平均耗时居然接近 39.2ms 。可能你乍一看觉得这不是很正常吗，有什么好奇怪的？其实不然，我再来说下一些基本信息，该后端的 HTTP 服务并没有什么业务逻辑，只是将一段字符串转成大写然后返回，字符串长度也仅只有 100 字符，另外网络 ping 延时只有 1.9ms 左右。因此，理论上该调用耗时应该在 2-3ms 左右，但为什么平均耗时 39.2ms 呢？ 由于工作原因，调用耗时的问题，对我来说，已经见怪不怪了，经常会帮业务解决内部 RPC 框架调用超时的相关问题，但是 HTTP 调用耗时第一次遇到。不过，排查问题的套路是一样的。主要方法论无外乎由外而内、至上而下等排查方法。我们先来看看外围的一些指标，看能否发现蛛丝马迹。 2. 外围指标 2.1 系统指标 主要看外围的一些系统指标（注意： 调用与被调用的机器 都要看）。例如负载、CPU。只需一个 top 命令就能一览无余。 因此，确认了下 CPU 和负载都很空闲。由于当时没有截图，这里就不放图了。 2.2 进程指标 Java 程序进程指标主要看 GC、线程堆栈情况（注意： 调用与被调用的机器 都要看）。 Young GC 都非常少，而且耗时也在 10ms 以内，因此没有长时间的 STW。 因为平均调用时间 39.2ms

1、 查看服务器上安装的nginx版本号，主要是通过nginx的-v或-V选项，查看方法如下图所示 -v 显示 nginx 的版本。 -V 显示 nginx 的版本，编译器版本和配置参数 [root@zq ~]# nginx -V nginx version: nginx/1.16.1 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) built with OpenSSL 1.0.2k-fips 26 Jan 2017 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx