keepalive

系统环境： 操作系统：Centos7.2 依赖软件：net-tools 网络环境： Keepalived Master：192.168.5.251 Keepalived Backup：192.168.5.252 VIP： 192.168.5.100 RIP： 192.168.5.254 Keepalived Master ! Configuration File for keepalived global_defs { notification_email { acassen@firewall.loc failover@firewall.loc sysadmin@firewall.loc } notification_email_from Alexandre.Cassen@firewall.loc smtp_server 192.168.200.1 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_script chk_mantaince_down { script "[[ -f /etc/keepalived/down ]] && exit 1 || exit 0" interval 1 weight 2 } vrrp_instance VI_1 { state MASTER interface eno16777736

TCP是一个有状态通讯协议，所谓的有状态是指通信过程中通信的双方各自维护连接的状态。 一、TCP keepalive 先简单回顾一下TCP连接建立和断开的整个过程。（这里主要考虑主流程，关于丢包、拥塞、窗口、失败重试等情况后面详细讨论。） 首先是客户端发送syn（Synchronize Sequence Numbers：同步序列编号）包给服务端，告诉服务端我要连接你，syn包里面主要携带了客户端的seq序列号；服务端回发一个syn+ack，其中syn包和客户端原理类似，只不过携带的是服务端的seq序列号，ack包则是确认客户端允许连接；最后客户端再次发送一个ack确认接收到服务端的syn包。这样客户端和服务端就可以建立连接了。整个流程称为三次握手。 建立连接后，客户端或者服务端便可以通过已建立的socket连接发送数据，对端接收数据后，便可以通过ack确认已经收到数据。 数据交换完毕后，通常是客户端便可以发送FIN包，告诉另一端我要断开了；另一端先通过ack确认收到FIN包，然后发送FIN包告诉客户端我也关闭了；最后客户端回应ack确认连接终止。整个流程成为四次挥手。 TCP的性能经常为大家所诟病，除了TCP+IP额外的header以外，它建立连接需要三次握手，关闭连接需要四次挥手。如果只是发送很少的数据，那么传输的有效数据是非常少的。 是不是建立一次连接后续可以继续复用呢

TCP是一个有状态通讯协议，所谓的有状态是指通信过程中通信的双方各自维护连接的状态。 一、TCP keepalive 先简单回顾一下TCP连接建立和断开的整个过程。（这里主要考虑主流程，关于丢包、拥塞、窗口、失败重试等情况后面详细讨论。） 首先是客户端发送syn（Synchronize Sequence Numbers：同步序列编号）包给服务端，告诉服务端我要连接你，syn包里面主要携带了客户端的seq序列号；服务端回发一个syn+ack，其中syn包和客户端原理类似，只不过携带的是服务端的seq序列号，ack包则是确认客户端允许连接；最后客户端再次发送一个ack确认接收到服务端的syn包。这样客户端和服务端就可以建立连接了。整个流程称为三次握手。 建立连接后，客户端或者服务端便可以通过已建立的socket连接发送数据，对端接收数据后，便可以通过ack确认已经收到数据。 数据交换完毕后，通常是客户端便可以发送FIN包，告诉另一端我要断开了；另一端先通过ack确认收到FIN包，然后发送FIN包告诉客户端我也关闭了；最后客户端回应ack确认连接终止。整个流程成为四次挥手。 TCP的性能经常为大家所诟病，除了TCP+IP额外的header以外，它建立连接需要三次握手，关闭连接需要四次挥手。如果只是发送很少的数据，那么传输的有效数据是非常少的。 是不是建立一次连接后续可以继续复用呢

牢记！内核参数可以调整，但不是随便乱调，需要根据业务进行判断，并且要知道调整的后果是什么，存在哪些风险。 牢记！！！调整参数时，做好记录！！！ 网络参数 /proc/sys/net/core/wmem_max 　　 最大socket写buffer,可参考的优化值:873200 /proc/sys/net/core/rmem_max 　　 　　最大socket读buffer,可参考的优化值:873200 3. /proc/sys/net/ipv4/tcp_wmem 　　 　　TCP写buffer,可参考的优化值: 8192 436600 873200 4. /proc/sys/net/ipv4/tcp_rmem 　　 　　TCP读buffer,可参考的优化值: 32768 436600 873200 5. /proc/sys/net/ipv4/tcp_mem 　　它有3个值,意思是: 　　net.ipv4.tcp_mem[0]:低于此值,TCP没有内存压力. 　　net.ipv4.tcp_mem[1]:在此值下,进入内存压力阶段. 　　net.ipv4.tcp_mem[2]:高于此值,TCP拒绝分配socket. 　　上述内存单位是页,而不是字节.可参考的优化值是:786432 1048576 1572864 6. /proc/sys/net/core/netdev_max

keepalive 当然，在nginx中，对于http1.0与http1.1也是支持长连接的。 什么是长连接呢？我们知道，http请求是基于TCP协议之上的，那么，当客户端在发起请求前，需要先与服务端建立TCP连接，而每一次的TCP连接是需要三次握手来确定的，如果客户端与服务端之间网络差一点，这三次交互消费的时间会比较多，而且三次交互也会带来网络流量。当然，当连接断开后，也会有四次的交互，当然对用户体验来说就不重要了。而http请求是请求应答式的，如果我们能知道每个请求头与响应体的长度，那么我们是可以在一个连接上面执行多个请求的，这就是所谓的长连接，但前提条件是我们先得确定请求头与响应体的长度。 对于请求来说，如果当前请求需要有body，如POST请求，那么nginx就需要客户端在请求头中指定content-length来表明body的大小，否则返回400错误。也就是说，请求体的长度是确定的，那么响应体的长度呢？先来看看http协议中关于响应body长度的确定： 对于http1.0协议来说，如果响应头中有content-length头，则以content-length的长度就可以知道body的长度了，客户端在接收body时，就可以依照这个长度来接收数据，接收完后，就表示这个请求完成了。而如果没有content-length头，则客户端会一直接收数据，直到服务端主动断开连接

BGP邻居建立过程 BGP（Border Gateway Protocol）是一种用于自治系统（Autonomous System）之间的动态路由协议。BGP使用TCP作为其传输层协议（监听端口号为179）。 BGP对等体间通过以下5种报文进行交互，其中Keepalive报文为周期性发送，其余报文为触发式发送： • Open报文：用于建立BGP对等体连接。 • Update报文：用于在对等体之间交换路由信息。 • Notification报文：用于中断BGP连接。 • Keepalive报文：用于保持BGP连接。 • Route-refresh报文：用于在改变路由策略后请求对等体重新发送路由信息。只有支持路由刷新（Route-refresh）能力的BGP设备会发送和响应此报文。 Open报文： 是TCP连接建立后发送的第一个报文，用于建立BGP邻居之间的连接关系。BGP邻居在接收到Open报文并协商成功后，将发送Keepalive报文确认并保持连接的有效性。确认后，BGP邻居间可以进行Update、Notification、Keepalive和Route-refresh报文的交换。 Keepalive报文： BGP路由器会周期性的向邻居发出Keepalive报文，用来保持连接的有效性。 Update报文： 用于在BGP邻居之间交换路由信息

1.简介 　　定义：通用路由封装协议GRE（Generic Routing Encapsulation）可以对某些网络层协议（如IPX、IPv6、AppleTalk等）的数据报文进行封装，使这些被封装的数据报文能够在另一个网络层协议（如IPv4）中传输。 　　GRE提供了将一种协议的报文封装在另一种协议报文中的机制，是一种三层隧道封装技术，使报文可以通过GRE隧道透明的传输，解决异种网络的传输问题。 　　受益：GRE实现机制简单，对隧道两端的设备负担小。 　　GRE隧道可以通过IPv4网络连通多种网络协议的本地网络，有效利用了原有的网络架构，降低成本。 　　GRE隧道扩展了跳数受限网络协议的工作范围，支持企业灵活设计网络拓扑。 　　GRE隧道将不连续的子网连接起来，用于组建VPN，实现企业总部和分支间安全的连接。 2.基本原理 　　1）实现过程 　　报文在GRE隧道中传输包括封装和解封装两个过程。如图所示，如果X协议报文从Ingress PE向Egress PE传输，则封装在Ingress PE上完成，而解封装在Egress PE上进行。封装后的数据报文在网络中传输的路径，称为GRE隧道。 　　 　　 封装 Ingress PE从连接X协议的接口接收到X协议报文后，首先交由X协议处理。 X协议根据报文头中的目的地址在路由表或转发表中查找出接口，确定如何转发此报文

在Linux下对Web进行压力测试的小工具有很多,比较出名的有AB.虽然AB可以运行在windows下,但对于想简单界面操作的朋友有点不太习惯.其实vs.net也提供压力测试功能但显然显得太重了,在测试的时候也会占用了大量的资源导致测试效果不理想. 为了让在win下对web压力测试变得更简单方便所以用.net写了一个小工具来完成这个事情 功能介绍 这个小工具提供了一系列的参数设置,主要包换测试的类型,并发用户数和是否保持长连接状态等. KeepAlive 是否保持连接状态,如果选择是则省下了连接创建的损耗从而达到更高的吞吐测试效能 并发用户数 这个值是指同时请求的用户数,如果是局域网测试此值一般在100以内即可,最大可以设置1000;默认情况是10个用户,10用户到底会产生多大的请求压力后面会通过一个简单的测试体现出来. 测试Urls 用户可以根据需要对一个或多个URL进行压力测试,每行表示一个请求的URL路径. 测试结果 工具在测试的时候会返回一个简单的测试结果,主要包括的数据有: 运行时间,请求数(总数和秒),成功 请求数(总数和秒),接入数据量 (总数和秒)和错误 请求数(总数和秒) 10用户跑10w请求(没开启KeepAlive) 10用户跑10w请求(开启KeepAlive) 从测试来看开启KeepAlive对测试效能还是有着非常大的提高的. 下载这个小工具:

转载： https://mp.weixin.qq.com/s?__biz=MzU2MTkwMTE4Nw==&mid=2247487168&idx=1&sn=e1cc38cae47b0ea86d66d64cb081e8a3&chksm=fc70f52ccb077c3a42b4c51919bec6b77a9a26bee7840a8a5529c286f7430ecfd56e65eb133d&scene=21#wechat_redirect 存在下面两种情形： 情形一 ：一个客户端连接服务器以后，如果长期没有和服务器有数据来往，可能会被防火墙程序关闭连接，有时候我们并不想要被关闭连接。例如，对于一个即时通讯软件，如果服务器没有消息时，我们确实不会和服务器有任何数据交换，但是如果连接被关闭了，有新消息来时，我们再也没法收到了，这就违背了“即时通讯”的设计要求。 情形二 ：通常情况下，服务器与某个客户端一般不是位于同一个网络，其之间可能经过数个路由器和交换机，如果其中某个必经路由器或者交换器出现了故障，并且一段时间内没有恢复，导致这之间的链路不再畅通，而此时服务器与客户端之间也没有数据进行交换，由于 TCP 连接是状态机，对于这种情况，无论是客户端或者服务器都无法感知与对方的连接是否正常，这类连接我们一般称之为“死链”。 情形一 中的应用场景要求必须保持客户端与服务器之间的连接正常

低读低写并发、低数据量方案 方案一：双机高可用方案 1.数据库架构图 2.特点 一台机器A作为读写库，另一台B作为备份库；A库故障后B库作为读写库；A库恢复后A作为备库。 3.开发说明 此种情况下，数据源配置中的数据库IP地址，可采用虚拟的IP地址。虚拟IP地址由两台数据库机器上的keepalive配置，并互相检测心跳。当其中一台故障后，虚拟IP地址会自动漂移到另外一台正常的库上。 数据库的主备配置、故障排除和数据补全，需要DBA和运维人员来维护。而程序代码或配置并不需要修改。 具体配置可参考资料： http://lizhenliang.blog.51cto.com/7876557/1362313 http://database.51cto.com/art/201012/237204.htm http://gaoke.iteye.com/blog/2283890 4.适应场景 读和写都不高的场景（单表数据低于500万），双机高可用。 5.优缺点 优点是一个机器故障了可以自动切换；缺点是只有一个库在工作，读写并未分离，并发有限制。 方案二：主从结构方案 1.数据库架构图 2.特点 一台机器A作为写库，另一台B作为读库；A库故障后B库充当读写，A修复后，B库为写库，A库为读库。 3.开发说明 这种方案的实现，要借助数据库中间件Mycat来实现，Mycat的datahost配置如下