keepalive

1、负载均衡典型应用场景，外网、内网、私网公共服务。 典型场景： (1)用户通过公网访问数据中心的ftp、web、https服务器。 (2) 在数据中心内部东西向访问其他服务时，例如，访问其他虚拟机、DNS等公共服务。 (3) 通过专线或者ipsec vpn访问数据中心内部服务时。 2、常见的负载均衡的技术 硬件实现（2/3层）：链路聚合、等价路由。 软件实现（4/7层）：LVS、nginx/haproxy、 　　DNS负载均衡：公网智能分配目的ip GSLB、内网DNS解析公共服务。 3、LVS的3种模式：NAT、DR、TUNNEL。 NAT： 特点，流量来回路径一致，都要经过负载均衡器，通过DNAT转换，将目的ip修改为后端VM的ip，目的MAC修改为后端VM的MAC地址。 缺点：当回程流量很大时，负载均衡器本身容易成为瓶颈。改进方案，使用DR模式。 DR：特点，回程路径直接回到客户端。不需要NAT，后端服务器都需要配置环口ip为VIP，并且配置不响应VIP的arp请求。同时要求LVS分发器和后端VM在相同网段内，这个模式是主流。 　　　　 缺点：要求后端VM和LVS分发头在相同网段。改进方案：LVS + haproxy. 隧道模式：特点，负载均衡器和后端虚拟机不是直接相连，通过隧道打通，要求双方都要支持IPinIP协议。 LVS + haproxy: 怎么解决跨网问题？

什么是KeepAlive？ 首先，我们要明确我们谈的是 TCP 的 KeepAlive 还是 HTTP 的 Keep-Alive 。TCP的KeepAlive和HTTP的Keep-Alive 是完全不同的概念，不能混为一谈 。实际上HTTP的KeepAlive写法是Keep-Alive，跟TCP的KeepAlive写法上也有不同。 TCP的 keepalive 是侧重在保持客户端和服务端的连接，一方会不定期发送心跳包给另一方，当一方端掉的时候，没有断掉的定时发送几次 心跳包 ，如果间隔发送几次，对方都返回的是RST，而不是ACK，那么就释放当前链接。设想一下，如果tcp层没有keepalive的机制，一旦一方断开连接却没有发送FIN给另外一方的话，那么另外一方会一直以为这个连接还是存活的，几天，几月。那么这对服务器资源的影响是很大的。 HTTP的 keep-alive 一般我们都会带上中间的 横杠 ，普通的http连接是客户端连接上服务端，然后结束请求后，由客户端或者服务端进行http连接的关闭。下次再发送请求的时候，客户端再发起一个连接，传送数据，关闭连接。这么个流程反复。但是一旦客户端发送connection:keep-alive头给服务端，且服务端也接受这个keep-alive的话，两边对上暗号，这个连接就可以复用了，一个http处理完之后

临时修改服务器参数: sysctl -w 永久保存需要编辑 /etc/sysctl.conf close_wait状态出现的原因是client or server 发送了关闭信息给另一端,而另一端由于非正常关闭或者网络断开没有收到你发送的关闭连接信息等原因,使得发起close端,根据tcp/ip协议要保持存活一段时间。 $ /proc/sys/net/ipv4/tcp_keepalive_time $ /proc/sys/net/ipv4/tcp_keepalive_intvl $ /proc/sys/net/ipv4/tcp_keepalive_probes 这3个参数与TCP KeepAlive有关.默认值是: tcp_keepalive_time = 7200 seconds (2 hours) tcp_keepalive_probes = 9 tcp_keepalive_intvl = 75 seconds 意思是如果某个TCP连接在idle 2个小时后,内核才发起probe.如果probe 9次(每次75秒)不成功,内核才彻底放弃,认为该连接已失效.对服务器而言,显然上述值太大. 可调整到: /proc/sys/net/ipv4/tcp_keepalive_time 1800 /proc/sys/net/ipv4/tcp_keepalive_probes 3 /proc

jmeter keep-alive 浅解 首先我们要对keepalive有个简易的理解，tcp 的keepalive是侧重客户端和服务端的连接，即只有同样的客户端才能反复使用这个连接。但是http的不一样，http请求，客户端带上了keep-alive之后，这个连接可以复用，即一个http请求处理完之后，另外一个http请求会从这个连接走。 看到这里，我们很容易会以为并发测试的时候，如果勾选了heep-alive，是不是走的都是重复的连接，即并发数和客户端的端口数应该是一样的。但并不是这个样子。 jmeter http请求默认是开启了 keep-alived的，但是在jmeter 配置文件 jmeter.properties中连接时间确实注销的，即，jmeter不会等待，一旦连接空闲 或者可以理解为接受完服务器的数据后，就立马断开连接。 所以不修改jmeter配置文件，并发时不管是否勾选keepalive，每个线程都是一个全新的（可以并发时查看客户端端口数验证，会发现不管是否带keepalive，端口数一定>=并发数，对于响应较慢的接口，端口数可能更多，更严谨的可以抓包看每个链接的客户端的端口和服务器的端口是否都是固定的）。 但是不勾选keep-alive的时候，当建立连接，数据传输完毕之后，服务器就会率先发起断开连接的操作，这个时候连接的状态为TIME_WAIT，并会保持2MSL

用vue做后台管理项目，特别是有列表页、列表数据详情页、列表数据修改页功能的码友们，几乎都被vue前进后退都刷新的逻辑坑过，有时候需要保存组件状态, 要求 : 1.列表页进入详情页返回列表页时列表不能刷新，连页数、筛选条件等都不能变 2.列表页进列表数据编辑页若数据有改动返回列表页列表数据得刷新，但页数、筛选条件等都不能变 3.非详情页、编辑页进入列表页时列表数据得刷新，页数、筛选条件等都全部重置 总结一下就是‘这个列表页我想让它刷新，他就得刷新，不想让他刷，他就无变化 那么是啥呢?对,是keep-alive组件，对，是它。 但单纯的keep-alive是前进后退都不会刷新的，所以需要改造一下，让它乖乖听话。这个过程需要路由路由参数meta配合我们。 1.在路由文件中为目标列表页设置meta参数，里面包含keepAlive和ifDoFresh字段 复制代码 { path:'*', name:'datalists', component: resolve => require(['@/view/datalist'], resolve), meta:{ keepAlive: true, ifDoFresh:false } }, 复制代码 2.在程序主入口main.vue中设置页面根据keepAlive字段判断是否使用keep-alive组件。 复制代码 <div class="main

1. TCP连接 当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的 经典的三次握手示意图： 经典的四次握手关闭图： 2. TCP短连接 我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作 短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段 3.TCP长连接 接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。 首先说一下TCP/IP详解上讲到的TCP保活功能

1. TCP连接 当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的。 经典的三次握手示意图： 经典的四次握手关闭图： 2. TCP短连接 我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作 短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段 3.TCP长连接 接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。 首先说一下TCP/IP详解上讲到的TCP保活功能

静态LSP的详解 静态LSP的特点： 不使用标签发布协议(LDP)，不需要交互控制报文，资源消耗比较小； 通过静态方式建立的LSP不能根据网络拓扑变化动态调整，需要管理员干预。 静态LSP适用于拓扑结构简单并且稳定的网络。 实战模拟实验 R2： static-lsp ingress R2_R5 destination 5.5.5.5 32 nexthop 23.1.1.3 out-label 100 R3： static-lsp transit R2_R5 incoming-interface GigabitEthernet0/0/1 in-label 100 nexthop 34.1.1.4 out-label 200 R4： static-lsp transit R2_R5 incoming-interface GigabitEthernet0/0/1 in-label 200 nexthop 45.1.1.5 out-label 300 R5: static-lsp egress R2_R5 incoming-interface GigabitEthernet0/0/1 in-label 300 检查如下 测试如下： 动态LSP的详解 动态LSP通过LDP协议实现对FEC的分类、标签的分配及LSP的建立和维护等操作。 动态LSP的特点： 组网配置简单，易于管理和维护；

1, 如果服务端的Socket比客户端的Socket先关闭，会导致客户端出现TIME_WAIT状态，占用系统资源。 所以，必须等客户端先关闭Socket后，服务器端再关闭Socket才能避免TIME_WAIT状态的出现。 2, 在linux下写socket的程序的时候，如果尝试send到一个disconnected socket上，就会让底层抛出一个SIGPIPE信号。 client端通过 pipe 发送信息到server端后，就关闭client端, 这时server端,返回信息给 client 端时就产生Broken pipe 信号了。 当服务器close一个连接时，若client端接着发数据。根据TCP协议的规定，会收到一个RST响应，client再往这个服务器发送数据时，系统会发出一个SIGPIPE信号给进程，告诉进程这个连接已经断开了，不要再写了。 根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止、退出),所以client会退出。若不想客户端退出可以把SIGPIPE设为SIG_IGN 如: signal(SIGPIPE,SIG_IGN); 这时SIGPIPE交给了系统处理。 这个信号的缺省处理方法是退出进程，大多数时候这都不是我们期望的。因此我们需要重载这个信号的处理方法。调用以 下代码，即可安全的屏蔽SIGPIPE： struct

业务需要，为了提供高性能的查询服务，引入了一款高速搜索服务，客户端的链接使用的HTTP，测试环境使用一切正常，但上线后几乎每天都会发生异常Connection reset by peer。 具体场景如下： 两台业务服务器，用客户端（基于HTTPClient，实现了长连接）连接的搜索服务集群（集群有三台机器），客户端与服务器分别部署在不同的网段，异常会有规律的出现： 每天9点左右会发生异常Connection reset by peer. 而且是连续有三个 Connection reset by peer Caused by: java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) 这个异常到是很好解决，引入重试机制，捕获这个异常后重新发起请求，第二次都会成功，但这是治标不治本，还需要进一步探究问题的根源。 于是乎