这些年，接触了形形色色的项目，写了不少网络编程的代码，从windows到linux，跌进了不少坑，由于网络编程涉及很多细节和技巧，一直想写篇文章来总结下这方面的心得与经验，希望对来者有一点帮助，那就善莫大焉了。 本文涉及的平台包括windows和linux，下面开始啦。 一、非阻塞的的connect()函数如何编写 我们知道用connect()函数默认是阻塞的，直到三次握手建立之后，或者实在连不上超时返回，期间程序执行流一直阻塞在那里。那么如何利用connect()函数编写非阻塞的连接代码呢？ 无论在win
这些年，接触了形形色色的项目，写了不少网络编程的代码，从windows到linux，跌进了不少坑，由于网络编程涉及很多细节和技巧，一直想写篇文章来总结下这方面的心得与经验，希望对来者有一点帮助，那就善莫大焉了。 本文涉及的平台包括windows和linux，下面开始啦。 一、非阻塞的connect()函数如何编写 我们知道用connect()函数默认是阻塞的，直到三次握手建立之后，或者实在连不上超时返回，期间程序执行流一直阻塞在那里。那么如何利用connect()函数编写非阻塞的连接代码呢？ 无论在wind
在写TCP服务程序时，除了要处理SIGPIPE外，还要有客户端连接检测机制，用于及时发现崩溃的客户端连接。一般来说，有两种检测方式：1. 在应用层，由业务程序自己检测；2. 使用TCP的KeepAlive机制。
VuGen判断脚本是否执行成功是根据服务器返回的状态来确定的，如果服务器返回的是HTTP状态为200 OK，那么VuGen就认为脚本正确地运行了，并且是运行通过的。而大多数系统出错时是不会返回错误页面的，而是返回一个消息提示框，来提升用户体验感。
某部分客户业务使用cos的node.js的sdk来进行上传下载等操作，近期客户端偶尔触发上传文件报错{ error: { code: 'ECONNRESET' } } 的异常。
导读 导致“Connection reset”的原因是服务器端因为某种原因关闭了Connection，而客户端依然在读写数据，此时服务器会返回复位标志“RST”，然后此时客户端就会提示“java.net.SocketException: Connection reset”。可能有同学对复位标志“RST”还不太了解，这里简单解释一下：
2、尽量不要“批量”修改内核参数，笔者就曾这么干过，结果“调优”后，性能反而下降，事务出错数反而增加，所以，调优的时候可以考虑逐个参数进行调优，然后对比效果。
本文是根据有赞中间件团队多年的TCP网络编程实践经验总结而来，目的是为了避免应用因各种网络异常而出现各种非预期行为，从而造成非预期的影响，影响系统稳定性与可靠性。
3.在有限资源的情况下，一定是先解决当下最核心的问题，预测并发现未来可能出现的问题，一步步解决最痛点的问题，即满足需求的系统是不断迭代优化出来的 A.高并发原则 1.无状态：比较容易进行水平扩展，应用无状态，配置文件有状态 2.拆分：在系统设计初期，是做一个大而全的系统还是按功能模块拆分系统，这个需要根据环境进行权衡
一、 操作系统提供的网络接口 为了能更好的排查网络通信问题，我们需要熟悉操作系统提供的以下网络接口函数，列表如下： 接口函数名称接口函数描述接口函数签名socket创建套接字int socket(int domain, int type, int protocol);connect连接一个服务器地址int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);send发送数据ssiz
NodeJS的错误处理让人痛苦，在很长的一段时间里，大量的错误被放任不管。但是要想建立一个健壮的Node.js程序就必须正确的处理这些错误，而且这并不难学。如果你实在没有耐心，那就直接绕过长篇大论跳到“总结”部分吧。
nginx-gateway部署在公有云 A, 业务测试服务器部署在办公区机房B, 公有云region A 和 办公区机房 B通过soft V**互连。B机房中有不同类型的应用服务器【nodejs,java(tomcat)】做nginx-gateway的后端upstream节点。nginx-gateway编译安装了ngx_http_upstream_check_module插件，ngx_http_upstream_check_module用于做后端upstream节点的健康监测, healthcheck为每个upstream的后端节点配置有一个raise_counts/fall_couts状态的计数器。业务方同事反馈:从外部访问内部某些应用有概率出现超时, 经观察, nodejs,java(tomcat)的raise_counts计数器概率性地重置为0，
为了能更好的排查网络通信问题，我们需要熟悉操作系统提供的以下网络接口函数，列表如下：
可能很多 Java 程序员对 TCP 的理解只有一个三次握手，四次挥手的认识，我觉得这样的原因主要在于 TCP 协议本身稍微有点抽象（相比较于应用层的 HTTP 协议）；其次，非框架开发者不太需要接触到 TCP 的一些细节。其实我个人对 TCP 的很多细节也并没有完全理解，这篇文章主要针对微信交流群里有人提出的长连接，心跳的问题，做一个统一的整理。
接下来cillianplatform项目的更新频率保持一周一次，等稳定了到公开测试版本，会告知大家。
gRPC 是一款高性能、开源的 RPC 框架，产自 Google，基于 ProtoBuf 序列化协议进行开发，支持多种语言（C++、Golang、Python、Java等） gRPC 对 HTTP/2 协议的支持使其在 Android、IOS 等客户端后端服务的开发领域具有良好的前景。 gRPC 提供了一种简单的方法来定义服务，同时客户端可以充分利用 HTTP2 stream 的特性，从而有助于节省带宽、降低 TCP 的连接次数、节省CPU的使用等。
调试Python程序时，经常会报出一些异常，异常的原因一方面可能是写程序时由于疏忽或者考虑不全造成了错误，这时就需要根据异常Traceback到出错点，进行分析改正；另一方面，有些异常是不可避免的，但我们可以对异常进行捕获处理，防止程序终止。
kubernetes是master-slave结构，master node是集群的大脑，当master node发生故障时整个集群都"out of control"。master node中最重要的当属apiserver组件，它负责处理所有请求，并持久化状态到etcd。一般我们会部署多份apiserver实现高可用。官方建议在多个apiserver前面部署一个LB进行负载均衡，当其中一台apiserver发生故障之后，LB自动将流量切换到其他实例上面。这样虽然简单，但是也引入了额外的依赖，如果LB发生故障将会导致全部apiserver不可用。我们知道在kubernetes中node节点上kubelet与apiserver心跳超时后，controller-manager会将该node状态置为notReady，随后驱逐其上的pod，使这些pod在其他地方重建。所以当LB发生故障时，集群中所有的node都会变为notReady状态，进而导致大规模的pod驱逐。
脚本是如何运行的以及每个Action和Action之间运行的先后顺序就是在这里设置的。
5100=准备连接无线宽带(WLAN)网络\r无线模块装载成功。 5101=正在为当前上网卡设置3G模式，请稍候。 5102=正在为当前上网卡设置1X模式，请稍候。 5103=为当前上网卡设置3G模式失败，请稍候再试。(5103) 5104=为当前上网卡设置1X模式失败，请稍候再试。(5104) 5105=当前上网卡设置3G模式失败。(5105) 5106=当前上网卡设置1X模式失败。(5106) 5107=当前上网卡不支持3G模式。(5107) 5108=未检测到无线宽带(1X)网络。(5108) 5109=您的上网卡硬件没有插好或者UIM卡无效。(5008) 5110=您的PIN码验证失败，该项无线宽带接入功能无法使用。(5017) 5111=您的UIM卡PUK码已经锁定，无法使用该卡，请在PIN码管理菜单中解锁。(5018) 5112=您的UIM卡PIN码已经锁定，无法使用该卡，请使用手机解锁UIM卡PIN码。(5112) 5113=系统文件被破坏或系统环境没配置好，无线宽带接入模块不可用。(5015) 5114=初始化连接发生错误，请确认Remote Access Connection Manager服务已经启动。(5009) 5115=无线宽带(WLAN)的接入网络号为空。(5115) 5116=无法获取无线宽带(WLAN)的网络信息。(5116) 5117=连接无线宽带(WLAN)网络出错。(5117) 5118=连接无线宽带(WLAN)网络超时，请尝试重新连接。(5118) 5119=正在初始化拨号模块。 5120=已经成功连接。 5121=正在断开。 5122=连接已经断开或者连接错误。 5123=连接已经断开。 5124=断开失败，请稍候重试。(5124) 5125=正在取消。 5126=未检测到无线宽带(WLAN)网络。(5007) 5127=正在同步登录认证信息。 5128=发送登录认证请求失败，请重新尝试登录或者拔出上网卡进行无线宽带(WLAN)连接。(5128) 5129=登录认证信息无法解释，请重新尝试登录或者拔出上网卡进行无线宽带(WLAN)连接。(5129) 5130=接收登录认证信息超时，请重新尝试登录或者拔出上网卡进行无线宽带(WLAN)连接。(5130) 5131=接收登录认证请求失败(用户为非上网卡用户)，请拔出上网卡进行无线宽带(WLAN)连接。(5131) 5132=接收登录认证请求失败(imsi不匹配)，请更换UIM卡或者拔出上网卡进行无线宽带(WLAN)连接。(5132) 5133=接收登录认证请求失败(其它原因)，请重新尝试登录或者拔出上网卡进行无线宽带(WLAN)连接。(5133) 5134=获取帐号信息出错，请稍候重试。(5134) 5135=未检测到PPPOE网络。(5135) 5136=正在将您的无线网卡IP设置为自动获取。 5137=设置无线网卡IP失败，可能是用户权限不够，请和管理员联系。(5137) 5138=正在连接无线宽带(WLAN)网络。 5139=正在登录无线宽带(WLAN)网络。 5140=无线宽带(1X)无法连接，请选用其他无线宽带进行拨号接入。(5140) 5141=无线宽带(3G)无法连接，请选用其他无线宽带进行拨号接入。(5141) 5142=无线宽带(WLAN)网络连接失败，请检查您的账号、密码和开户地设置。(5142) 5143=未检测到无线宽带(3G)网络。(5143) 5144=无线宽带(ADSL)无法连接，请选用其他无线宽带进行拨号接入。(5144) 5145=断开成功。 5146=准备连接无线宽带(1X)网络。 5147=准备连接无线宽带(3G)网络。 5200=正在打开端口... 5201=端口已经成功打开... 5202=正在连接设备... 5203=连接设备成功... 5204=设备链上的所有设备已经成功连接... 5205=正在验证用户名和密码... 5206=验证过程完毕... 5207=客户端使用一个新的帐号/密码/域进行请求验证... 5208=RAS服务器请求一个回叫号码... 5209=客户端请求改变本帐号的密码... 5210=开始发送状态，正在在网络上登记您的计算机... 5211=开始计算连接速度... 5212=认证请求正在应答... 5213=开始重新认证... 5214=客户端成功完成认证... 1100=错误: 无法得到Portal重新定位的URL。(1100) 1101=无法解析Portal重新定位的XML文件。(1101) 1102=无法解析Portal重新定位的XML文件。(1102) 1103=无法得到URL的内容。(1103) 1104=无法解析Portal返回的XML文件。(1104) 1105=无法解析Portal返回的XML文件。(1105) 1106=Radius出错。(1106
Nginx Ingress Controller 基于 Nginx 实现了 Kubernetes Ingress API，Nginx 是公认的高性能网关，但如果不对其进行一些参数调优，就不能充分发挥出高性能的优势。Nginx Ingress工作原理：
我们通过了解TCP各个状态，可以排除和定位网络或系统故障时大有帮助。（总结网络上的内容）
这个问题在于你输入的网址有错误。有可能是你要连接的服务器不能识别你要求浏览的文档，或者你没有访问它的权利甚至它根本就是不存在的。仔细检查一下 你是否将网址写错，包括大小写（一般网址是不分大小写的，可是某些特殊文档例外）、符号或是多打了空格。这是最常见的一类错误。
Uber 的业务遍布全球，每天需要处理全球数百万人次的出行，实时性对 Uber 而言非常重要。在一次行程中，多个参与者可以修改和查看正在进行中的行程状态，这需要实时更新。无论是取车时间、到达时间、路线还是在打开应用时附近的司机数量，所有参与者和应用都必须保持实时信息同步。本文介绍了 Uber 如何通过轮询保持信息实时更新以及基于 gRPC 双向流协议构建应用。
对于 .NET 的每个新版本，我们都希望发布一篇博客文章，重点介绍网络的一些变化和改进。在这篇文章中，我很高兴谈论 .NET 6 中的变化。
本文主要介绍了在.NET中如何实现HTTP请求的拦截，包括介绍.NET中的IHttpClientFactory和HttpClient，以及如何使用HttpClientFactory来拦截HTTP请求并处理异常。同时，还介绍了一种基于IHttpClientFactory的HTTP请求调度器，用于实现高效的HTTP请求调度。
curl是一个命令行工具，用于使用任何受支持的协议HTTP、FTP、IMAP、POP3、SCP、SFTP、SMTP、TFTP、TELNET、LDAP或FILE向网络服务器传输数据或从网络服务器传输数据，其被设计成无需用户交互即可工作，因此非常适合在shell脚本中使用，该软件提供代理支持、用户身份验证、FTP上传、HTTP posting、SSL连接、cookie、文件断点传输、metalink等功能。
上面两节，讲了大量的理论与实际工作中碰到的相关案例，现在就来讲一下在我们第一天和第二天中的ApacheHttp Server + Tomcat这样的架构，怎么来做优化吧。
HTTP1.0协议不支持长连接，从HTTP1.1协议以后，连接默认都是长连接。那么长连接和短连接有什么不同呢？
1、适用场景 kafka适合日志处理 rocketmq适合业务处理 结论：两者没有区别，根据具体业务定夺 2、性能 kafka单机写入TPS号称在百万条/秒 rocketmq大约在10万条/秒 结论：追求性能方面，kafka单机性能更高 3、可靠性 kafka使用异步刷盘方式，异步Replication rocketmq支持异步/同步刷盘，异步/同步Replication 结论：rocketmq所支持的同步方式提升了数据的可靠性 4、实时性 kafka和rocketmq均支持pull长轮询，rocketmq消息实时性更高 结论：rocketmq胜出 5、支持的队列数 kafka单机超过64个队列/分区，消息发送性能降低严重 rocketmq单机支持最高5W个队列，性能稳定 结论：长远看，rocketmq胜出， 6、消息顺序性 kafka某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序 rocketmq支持严格的消息顺序，一台Broker宕机后，发送消息会失败，但是不会乱序 结论：rocketmq胜出 7、消息失败重试机制 kafka消费失败不支持重试 rocketmq消费失败支持定时重试，每次重试间隔时间顺延 8、定时/延时消息 kafka不支持定时消息 rocketmq支持定时消息 9、分布式事务消息 kafka不支持分布式事务消息 rocketmq未来会支持 10、消息查询机制 kafka不支持消息查询 rocketmq支持根据message id查询消息，也支持根据消息内容查询消息 11、消息回溯 kafka可以按照offset回溯消息 rocketmq支持按照时间回溯消息，例如从一天之前的某时某分开始重新消费消息 问题一：push和pull模式 push模式：客户端与服务端建立连接后，当服务端有消息时，将消息推送到客户端 pull模式：客户端不断的轮询请求服务端，来获取新的消息 在具体实现时，push和pull模式都是采用消费端主动拉取的方式，即consumer轮询从broker拉取消息 区别： push 方式中，consumer把轮询过程封装了，并注册了MessageListener监听器，取到消息后，唤醒MessageListener的consumerMessage来消费，用户而言，觉得消息被推送过来的 pull方式中，取消息的过程需要用户自己写，首先通过打算消费的Topic拿到MessageQueue的集合，遍历MessageQueue集合，然后针对每个MessageQueue批量获取消息，一次取完之后，记录该队列下一次要取的开始offset，直到取完了，再换另一个MessageQueue 疑问：既然都是采用pull方式实现，rocketmq怎么保证消息的实时性？ 长轮询：rocketmq时采用长轮询的方式实现的，指的是在请求的过程中，若是服务器端数据并没有更新，那么则将这个连接挂起，直到服务器推送新的数据，再返回，然后进入循环周期 客户端像传统轮询一样从服务端请求数据，服务端会阻塞请求不会立刻返回，直到有数据或者超时才返回给客户端，然后关闭连接，客户端处理完响应信息后再向服务器发送新的请求
Tengine本质上就是nginx，用法跟nginx一模一样，由淘宝团队进行二次开发。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。Tengine的性能和稳定性已经在大型的网站如淘宝网，天猫商城等得到了很好的检验。它的最终目标是打造一个高效、稳定、安全、易用的Web平台。
linux查看tcp的状态命令： 1）、netstat -nat 查看TCP各个状态的数量 2）、lsof -i:port 可以检测到打开套接字的状况 3)、 sar -n SOCK 查看tcp创建的连接数 4)、tcpdump -iany tcp port 9000 对tcp端口为9000的进行抓包 5)、tcpdump dst port 9000 -w dump9000.pcap 对tcp目标端口为9000的进行抓包保存pcap文件wireshark分析。 6)、tcpdump tcp port 9000 -n -X -s 0 -w tcp.cap 对tcp/http目标端口为9000的进行抓包保存pcap文件wireshark分析。
缓慢的http拒绝服务攻击是一种专门针对于Web的应用层拒绝服务攻击，攻击者操纵网络上的肉鸡，对目标Web服务器进行海量http request攻击，直到服务器带宽被打满，造成了拒绝服务。 慢速HTTP拒绝服务攻击经过不断的演变和发展，主要有三种攻击类型，分别是Slow headers、Slow body、Slow read。以Slow headers为例，Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部，因为HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点，发起一个HTTP请求，一直不停的发送HTTP头部，消耗服务器的连接和内存资源。抓包数据可见，攻击客户端与服务器建立TCP连接后，每40秒才向服务器发送一个HTTP头部，而Web服务器再没接收到2个连续的rn时，会认为客户端没有发送完头部，而持续的等等客户端发送数据。如果恶意攻击者客户端持续建立这样的连接，那么服务器上可用的连接将一点一点被占满，从而导致拒绝服务。这种攻击类型称为慢速HTTP拒绝服务攻击。
链接：cnblogs.com/wei325/archive/2021/09/27/15308498.html
ByteBuf 是必须要掌握的核心工具类，并且能够理解 ByteBuf 的内部构造。ByteBuf 包含三个指针：读指针 readerIndex、写指针 writeIndex、最大容量 maxCapacity，根据指针的位置又可以将 ByteBuf 内部结构可以分为四个部分：废弃字节、可读字节、可写字节和可扩容字节。如下图所示。
编者：本文作者为携程无线开发总监陈浩然。陈浩然，计算机博士，2008年iOS SDK发布后，投身移动互联网。先后在外企、创业型和国内一线旅游公司从事无线App的开发工作，从企业级App、独立App到亿级用户量级的App都有全程参与。 App网络服务的高可靠和低延迟对于无线业务稳定发展至关重要，过去两年来我们一直在持续优化App网络服务的性能，到今年Q2结束时基本完成了App网络服务通道治理和性能优化的阶段性目标，特此撰文总结其中的经验教训，为以后的工作打下基础。 一、携程App无线网络服务架构 2014年携
中间件是Scrapy里面的一个核心概念。使用中间件可以在爬虫的请求发起之前或者请求返回之后对数据进行定制化修改，从而开发出适应不同情况的爬虫。
当客户端与服务器建立了tcp连接后，如果客户端一直不发送数据, 或者隔很长时间才发送一次数据。当连接很久没有数据报文传输时，服务器如何去确定对方还在线。到底是掉线了还是确实没有数据传输，连接还需不需要保持，这种情况在TCP协议设计中是需要考虑的。TCP协议通过一种巧妙的方式去解决这个问题，当超过一段时间(tcpkeepalivetime)之后，TCP自动发送一个数据为 空的报文给对方， 如果对方回应了这个报文，说明对方还在线，连接可以继续保持，如果对方没有报文返回并且重试了多次之后则认为连接丢失，没有必要保持连接。这个过程相当于服务器向客户端发送心跳包， 确认客户端是否还在线。对应的内核参数:
年前就计划把以前项目的一些理念和设计方案融合到sample里来。但是内容比较多，一直也没太多时间去完成它。所幸虽然断断续续但终归是完成了。并且在之前的一些实现上还做了一些细节的优化。内容比较多我感觉我自己写的也比较乱，仅当作一个参照和小计吧。
背景 使用golang进行业务开发时，通常会遇到需要发起HTTP调用请求，用于获取业务所需的数据进行下一步处理。 golang在标准库中直接提供了net/http包，通过这个包可以很方便的去发起一个HTTP请求。 对于golang的net/http库其使用通常有两种方式： 1. 使用DefaultClient；2. 使用自定义Client。下面来看看两种方式的用法 net/http使用 1. 使用DefalutClient 对于没有高并发的场景下，使用DefaultClient十分简单，能够快速达到目的。下
在Go微服务博客系列的这一部分，我们将探讨如何使用Netflix Hystrix的Go实现和go-resilience重试包，使用断路器模式使我们的服务间通信更具弹性。
在nginx中connection就是对tcp连接的封装，其中包括连接的socket，读事件，写事件。利用nginx封装的connection，我们可以很方便的使用nginx来处理与连接相关的事情，比如，建立连接，发送与接受数据等。而nginx中的http请求的处理就是建立在connection之上的，所以nginx不仅可以作为一个web服务器，也可以作为邮件服务器。当然，利用nginx提供的connection，我们可以与任何后端服务打交道。
在我们平时的工作中，我们经常会遇到要调用内部API或者其他第三方服务的API，在遇到Fegin之前我们基本会使用以下几种方式。
HTTP 的 Keep-Alive，是由应用层（用户态） 实现的，称为 HTTP 长连接； TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制；
在前面一节，我们实现了 FeignClient 粘合 resilience4j 的 Retry 实现重试。细心的读者可能会问，为何在这里的实现，不把断路器和线程限流一起加上呢：
在互联网系统中，服务提供方（upstream）因访问压力过大而响应变慢或失败，服务发起方（downstream）为了保护系统整体的可用性，可以临时暂停对服务提供方的调用，这种牺牲局部，保全整体的措施就叫做熔断。
HttpClient优化思路1、池化 2、长连接 3、httpclient和httpget复用 4、合理的配置参数（最大并发请求数，各种超时时间，重试次数）5、异步 6、多读源码
情形一：一个客户端连接服务器以后，如果长期没有和服务器有数据来往，可能会被防火墙程序关闭连接，有时候我们并不想要被关闭连接。例如，对于一个即时通讯软件，如果服务器没有消息时，我们确实不会和服务器有任何数据交换，但是如果连接被关闭了，有新消息来时，我们再也没法收到了，这就违背了“即时通讯”的设计要求。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
