iOS 长连接 KeepAlive

使活着使继续

1.两台业务系统启动着相同的服务，如果有一台故障，另一台自动接管，我们将中国称之为高可用。 2.系统可用率算法例： -1个9：（1-90%）*365=36.5天 ----> 表示该系统1年时间里最多可能的业务中断时间是36.5天 -2个9：（1-99%）*365=3.65天 ----> 表示该系统1年时间里最多可能的业务中断时间是3.65天 保证系统可实时不间断的使用。 软件：keepalive keepalive是通过vrrp（虚拟路由冗余协议）实现高可用。 通常业务系统需要保证7X24小时不down机。比如公司内部OA系统，每天公司人员都需要使用，则不允许down机。作为业务系统来说随时随地地都要求可用。 1.安装 2.配置[root@lb01 ~]# 3.启动 4.测试：keepalive高可用地址漂移 （1）keepalive提供一个VIP（虚拟IP）和vmac（虚拟Mac地址） （2）抓包测试 （1）默认配置为抢占式： master挂掉，backup上台，master重新启动则讲IP抢占过去。 （2）非抢占式配置： 两台均为backup，在优先级上做区分，如master挂掉，backup上台，则backup变成master，master变为backup。 a.两个节点的state均为backup(官方建议) b.两个节点都在vrrp_instance中添加nopreempt c.其中一个节点的优先级要高于另外一个节点 两台服务器角色都启用了nopreempt后，必须修改角色状态统一为backup，唯一的区别就是优先级不同。 keepalive高可用故障脑裂 由于某些原因，导致两台keepalive高可用服务器在指定时间内，无法检测到对方的心跳消息，各自取得资源及服务的所有权，而此时的两台高可用服务器又都还活着。 a.服务器网线松动等网络故障 b.服务器硬件故障发生损坏现象而奔溃 c.主备服务器都开启了firewalld防火墙 解决方法： 配置keepalived使用

keepalive起初是为LVS设计的，专门用来监控lvs各个服务节点的状态，后来加入了vrrp的功能，因此除了lvs，也可以作为其他服务（nginx，haproxy）的高可用软件。VRRP是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。VRRP的出现就是为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以keepalive一方面具有LVS cluster node healthcheck功能，另一方面也具有LVS director failover。 keepalive的两大功能： healthcheck和failover LVS cluster node healthcheck keepalive高可用服务原理介绍: keepalive director高可用之间的故障切换转移，是通过VRRP协议实现的。 在keepalive director工作时，主节点会不断的向备节点发送心跳消息，告知自己还活着，当主节点故障时，备节点无法接收主节点的心跳消息，此时就会启用自身的服务接管程序将主节点的IP和服务资源接管过来。当主节点恢复工作之后，又会释放IP资源和服务，恢复至备节点的角色。 VRRP协议原理简单介绍： VRRP是通过一种竞选协议协议机制来将路由的任务交给VRRP的路由器。在一VRRP的虚拟路由中，有多台物理的VRRP路由器，但是这多台路由器不同时工作，而是由一台Master负责路由工作，其他的都是backup，master是由backup竞争而来的，当master失去响应时，会从余下的backup中选出master来接管IP地址和服务资源。 VRRP协议的所有报文都是通过IP多播的形式传递消息，在一个虚拟路由器中，只有作为Master的VRRP路由器会一直发送VRRP广播包，当其他backup没有收到广播包时候，会迅速抢占master（谁的有限级高，谁就会抢占成功），处于安全性考虑VRRP协议传输数据时候进行了加密。 VRRP是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。 小结： 1，VRRP是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。 2，VRRP是通过一种竞选协议协议机制来将路由的任务交给VRRP的路由器。 3，VRRP协议的所有报文都是通过IP多播的形式传递消息 4，处于安全性考虑VRRP协议传输数据时候进行了加密。 官方网站： http://www.keepalived.org/ 编译安装yum安装都可 全局配置: VRRPD 配置: virtual_server VRRP同步组 两个vrrp_instance同属于一个vrrp_rsync_group，那么其中一个vrrp_instance发生故障切换时，另一个vrrp_instance也会跟着切换（即使这个instance没有发生故障）。 VRRP实例 1，Round-robin（RR）轮询：当新请求到达时候，从服务列表中选择一个Real Server，将请求重定向给这台Real Server。 2，Weighted round-robin（WRR）加权轮询：给每台Real Server分配一个权重/位列，权重越大，分到的请求数越多。 3，Destination hashing （DH）目标散列：来自于同一个IP地址的请求都被重定向到同一台Real Server上（保证目标地址不变）。 4，Source hashing（SH）源地址散列：Director必须确保响应的数据包必须通过请求数据包所经过的路由器或者防火墙（保证原地址不变）。 动态调度算法：通过检查服务器上当前连接的活动状态来重新决定下一步调度方式该如何实现。 5，Lease Connection （LC） 最少连接 哪一个Real Server上的连接数少就将下一个连接请求定向到那台Real Server上去。 【算法：连接数=活动连接数 256+非活动连接数】 6，Weight Least-Connection（WLC） 加权最少连接 在最少连接的基础上给每台Real Server分配一个权重。 【算法：连接数=（活动连接数 256+非活动连接数）÷权重】 一种比较理想的算法。 7，Shortest Expected Delay (SED) 最短期望延迟 不再考虑非活动连接数 【算法：连接数=(活动连接数+1) *256 ÷权重】 8，Never Queue (NQ) 永不排队算法，对SED的改进，当新请求过来的时候不仅要取决于SED算法所得到的值，还要取决于Real Server上是否有活动连接。 9，Locality-Based Least-Connection (LBLC) 基于本地状态的最少连接，在DH算法的基础上还要考虑服务器上的活动连接数。 10，Locality-Based Least-Connection with Replication Scheduling (LBLCR) 带复制的基于本地的最少连接 LBLC算法的改进 TCP UDP ESP (Encapsulation Security Payload) IPsec 封装安全负载 AH (Authentication Header) keepalived是实现服务器级别的接管，服务不可用无法切换keepalive，所以需要做好应用层的监控 参考链接： https://www.cnblogs.com/qq78292959/archive/2012/05/31/2528524.html http://www.keepalived.org/

keep-alive定义： keep-alive是Vue.js的一个内置组件。它能够不活动的组件实例保存在内存中，而不是直接将其销毁，它是一个抽象组件，不会被渲染到真实DOM中，也不会出现在父组件链中。 它提供了include与exclude两个属性，允许组件有条件地进行缓存。 这里的component组件会被缓存起来。 举个栗子 在点击button时候，coma与comb两个组件会发生切换，但是这时候这两个组件的状态会被缓存起来，比如说coma与comb组件中都有一个input标签，那么input标签中的内容不会因为组件的切换而消失。 props keep-alive组件提供了include与exclude两个属性来允许组件有条件地进行缓存，二者都可以用逗号分隔字符串、正则表达式或一个数组来表示。 include: 字符串或正则表达式。只有匹配的组件会被缓存。 exclude: 字符串或正则表达式。任何匹配的组件都不会被缓存。 keep-alive的声明周期执行 页面第一次进入，钩子的触发顺序 created-> mounted-> activated，退出时触发 deactivated 当再次进入（前进或者后退）时，只触发 activated 事件挂载的方法等，只执行一次的放在 mounted 中；组件每次进去执行的方法放在 activated 中； 将缓存name为a的组件。 name为a的组件将不会被缓存。 注意：此处的name值是与在名称为component组件中的name值对应的。 生命钩子 keep-alive提供了两个生命钩子，分别是activated与deactivated。 被keepalive包含的组件不会被再次初始化，也就意味着不会重走生命周期函数 但是有时候是希望我们缓存的组件可以能够再次进行渲染，这时 Vue 为我们解决了这个问题 被包含在 keep-alive 中创建的组件，会多出两个生命周期的钩子: activated 与 deactivated： activated 当 keepalive 包含的组件再次渲染的时候触发 deactivated 当 keepalive 包含的组件销毁的时候触发 keep-alive是一个抽象的组件，keep-alive会将组件保存在内存中，并不会销毁以及重新创建，所以不会重新调用组件的created等方法，缓存的组件不会被 mounted,为此需要用activated与deactivated这两个生命钩子来得知当前组件是否处于活动状态。 参数理解 keep-alive 可以接收3个属性做为参数进行匹配对应的组件进行缓存: include 包含的组件(可以为字符串，数组，以及正则表达式,只有匹配的组件会被缓存) exclude 排除的组件(以为字符串，数组，以及正则表达式,任何匹配的组件都不会被缓存) max 缓存组件的最大值(类型为字符或者数字,可以控制缓存组件的个数) 注：当使用正则表达式或者数组时，一定要使用 v-bind 遇见 vue-router 结合router使用，缓存部分页面 所有路径下的视图组件都会被缓存 如果只想要router-view里面的某个组件被缓存，怎么办？ 1、使用 include/exclude 2、使用 meta 属性 缺点：需要知道组件的 name，项目复杂的时候不是很好的选择 优点：不需要例举出需要被缓存组件名称 使用$route.meta的keepAlive属性： 需要在router中设置router的元信息meta：说完了keep-alive组件的使用，我们从源码角度看一下keep-alive组件究竟是如何实现组件的缓存的呢？ created钩子会创建一个cache对象，用来作为缓存容器，保存vnode节点。 destroyed钩子则在组件被销毁的时候清除cache缓存中的所有组件实例。 假设这里有 3 个路由： A、B、C。 需求如下： 默认显示 A B 跳到 A，A 不刷新 C 跳到 A，A 刷新 实现方式如下： 在 A 路由里面设置 meta 属性： 在 B 组件里面设置 beforeRouteLeave： 在 C 组件里面设置 beforeRouteLeave： 这样便能实现 B 回到 A，A 不刷新；而 C 回到 A 则刷新。防坑指南 1.keep-alive 先匹配被包含组件的 name 字段，如果 name 不可用，则匹配当前组件 components 配置中的注册名称。 2.keep-alive 不会在函数式组件中正常工作，因为它们没有缓存实例。 3.当匹配条件同时在 include 与 exclude 存在时，以 exclude 优先级最高(当前vue 2.4.2 version)。比如：包含于排除同时匹配到了组件A，那组件A不会被缓存。 4.包含在 keep-alive 中，但符合 exclude ，不会调用 activated 和 deactivated。keep-alive生命周期钩子函数：activated、deactivated 使用<keep-alive>会将数据保留在内存中，如果要在每次进入页面的时候获取最新的数据，需要在activated阶段获取数据，承担原来created钩子中获取数据的任务。附录，题外话 生命周期函数：就是vue在某个时间段会自动执行的函数 1、beforeCreate(){}在执行的时候，data还有methods都没有被初始化。 2、created(){} data还有methods都被初始化好了，如果要调用 methods 方法或者操作 data 里面的数据，最早只能在 created 里面进行操作。 3、beforeMount(){} 表示模板已经在内存中编辑完成了，但是尚未渲染到模板页面中。即页面中的元素，没有被真正的替换过来，只是之前写的一些模板字符串。 4、mounted(){} 表示内存中模板已经真实的挂载到页面中去了，用户可以看到渲染好的界面了 注意这是一个生命周期函数的最后一个函数了，执行完这个函数表示 整个vue实例已经初始化完成了，组件脱离了创建阶段，进入运行阶段。 下面是运行期间的两个生命周期函数的钩子： 5、beforeUpdate(){} 表示我们的界面还没更新 但是data里面的数据是最新的。即页面尚未和最新的data里面的数据保持同步。 6、update(){} 表示页面和data里面的数据已经包吃同步了 都是最新的。 7、beforeDestory(){} 当执行这个生命周期钩子的时候 vue的实例从运行阶段进入销毁阶段 此时实例身上的data 还有 methods处于可用的状态。 8、Destoryed(){} 表示组件已经完全被销毁了 组件中所有的实例方法都是不能用了

Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。 当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。 测试结果证实是后者 http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP[连接]状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数： echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes keepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置idle（双方没有任何数据流发送往来）了tcp_keepalive_time后，服务器内核就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。 使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。 HTTP 1.0中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；HTTP 1.1中默认启用Keep-Alive，如果加入"Connection: close"，才关闭。 在HTTP/1.0版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP/1.0协议上，如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有Connection: Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。 从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接 Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间 心跳包 很多应用层协议都有HeartBeat机制，通常是客户端每隔一小段时间向服务器发送一个数据包，通知服务器自己仍然在线，并传输一些可能必要的数据。使用心跳包的典型协议是IM，比如QQ/MSN/飞信等协议。 心跳包 之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。 其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。 在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。 总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。 TCP协议的KeepAlive机制 学过TCP/IP的同学应该都知道，传输层的两个主要协议是UDP和TCP，其中UDP是无连接的、面向packet的，而TCP协议是有连接、面向流的协议。 所以非常容易理解，使用UDP协议的客户端（例如早期的“OICQ”，听说OICQ.com这两天被抢注了来着，好古老的回忆）需要定时向服务器发送心跳包，告诉服务器自己在线。 然而，MSN和现在的QQ往往使用的是TCP连接了，尽管TCP/IP底层提供了可选的KeepAlive（ACK-ACK包）机制，但是它们也还是实现了更高层的心跳包。似乎既浪费流量又浪费CPU，有点莫名其妙。 具体查了下，TCP的KeepAlive机制是这样的，首先它貌似默认是不打开的，要用setsockopt将SOL_SOCKET.SO_KEEPALIVE设置为1才是打开，并且可以设置三个参数tcp_keepalive_time/tcp_keepalive_probes/tcp_keepalive_intvl，分别表示连接闲置多久开始发keepalive的ack包、发几个ack包不回复才当对方死了、两个ack包之间间隔多长，在我测试的Ubuntu Server 10.04下面默认值是7200秒（2个小时，要不要这么蛋疼啊！）、9次、75秒。于是连接就了有一个超时时间窗口，如果连接之间没有通信，这个时间窗口会逐渐减小，当它减小到零的时候，TCP协议会向对方发一个带有ACK标志的空数据包（KeepAlive探针），对方在收到ACK包以后，如果连接一切正常，应该回复一个ACK；如果连接出现错误了（例如对方重启了，连接状态丢失），则应当回复一个RST；如果对方没有回复，服务器每隔intvl的时间再发ACK，如果连续probes个包都被无视了，说明连接被断开了。 Ref：

1.在使用keepAlive缓存是发现遇到的坑，现有A-B-C三个页面（A首页，B列表页，C详情页），从A到B刷新，C退回到B不刷新，这里是使用的结合router来实现的。 2.最开始的做法在app里面 在router路由里面设置需要缓存的组件的keepAlive:true 3.从A进入到B页面时设置B页面的meta.keepAlive==flase，让B页面刷新。 4.从C页面返回的B时设置B的meta.keepAlive==true,让B页面缓存(不刷新) 5.后面发现这样有一个问题，首次A进入B时B的keepAlive为false进入C页面时B的keepAlive为true，所以首次C退回到B时，B页面也会刷新。 导致的原因是因为当引入keep-alive 的时候它的值为true时，页面第一次进入，钩子的触发顺序created-> mounted-> activated，退出时触发deactivated。当再次进入（前进或者后退）时，只触发activated。所以会导致C第一次进入B的时候会刷新。 修改A页面的beforeRouteLeave替换为beforeRouteEnter当B进入A的时候修改B的keepAlive，这样的话，首次A进入B的时候keepAlive为true，执行created-> mounted-> activated，C首次退回的时候就不会刷新了。

问题场景： 当某个带有筛选条件查询列表的页面需要进行缓存，以便不再需要重复进行选择或者输入筛选条件的时候，我们就可以利用keepAlive来进行缓存，但keepAlive也存在着一些坑，这是需要注意的地方。 如何利用keepAlive进行缓存 1、在路由meta内定义keepAlive，来设置需要被缓存的页面 meta: { keepAlive: true } ture: 需要缓存的路由；false:不需要缓存的路由 2、判断router-view 被keep-alive包裹的为需要缓存的页面，这样我们就可以通过keepAlive来切换哪些页面需要缓存，哪些不需要缓存。 3、进入详情页面缓存，否则不缓存 路由守卫钩子 beforeRouteLeave 离开页面路由的时候出发； 当离开缓存页面，进入详情页面的时候，我们将缓存页面keepAlive设置true，如果离开缓存页面，不是进入详情页面的时候，我们设置为false，不进行缓存。 这是最基本的缓存设置，但是keepAlive也留下了一个大坑。 keepAlive二次进入页面显示首次缓存问题 第一次从缓存页面进入详情页再返回到缓存页面的时候，页面条件能被正确的缓存下来，但是当我们切换到别的路由，再一次进入该缓存页修改查询条件，并进入详情后返回缓存页，此时缓存的是页面状态是第一次进入该页面的时候的状态，也就是说，第二次进入页面的时候，该缓存读取的是第一次的缓存，这就非常的坑了。 所以通过下面的刷新缓存路由的方式来解决这个问题。 1、调整 router-view 定义一个isRouterAlive变量，用来刷新keep-alive;通过provide向下面子孙组件们暴露一个reload方法，用来刷新缓存。 2、设置缓存 子组件注册inject: ["reload"] 方法，beforeRouteEnter钩子在进入缓存页面的时候通过通过判断路由是否是来自详情页面，如果不是详情页，我们就刷新缓存，如果是详情页，就不做处理。 这样就解决了，只要是路由进入过别的页面(非详情页面)，我们就刷新缓存，这样就不会出现二次进入的时候，显示的是第一次的缓存状态，同时从详情页返回后正常显示缓存数据。

你好在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。希望对你有帮助

在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。 使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。 但是， keep-alive 并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。 Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。 当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览发过来http请求，则关闭这个http连接。 假设我们的httpd服务器是nginx， nginx的keepalive_timeout默认是60，即默认开启了http keepalive模式，而且http的长连接会保持60秒，60秒内没有数据来往即关闭连接。 这里我们设置业务sleep 60 秒 可以看到上面是经典的http过程，首先是3次握手建立连接，然后客户端发送请求，服务器处理60秒后返回数据，http响应一旦发送完毕，nginx马上关闭这个tcp连接 关闭 keepalive 情况下，一个socket资源从建立到真正释放需要经过的时间是:建立tcp连接 + 传送http请求 + 业务执行 + 传送http响应 + 关闭tcp连接 + 2MSL 可以看到这个http过程跟上面的keepalive=0情况是比较类似的，只不过当服务器响应完数据后，没有立刻发送FIN信号关闭连接，而是从38分等到43分，nginx才发送FIN信号关闭连接。说明了nginx的keepalive=300配置生效了。 这次我们开启了keepalive=180，并且连续发送了几个http请求，可以看到，都复用了同一个连接（因为没有再次的三次握手建立连接），而nginx再最后一次数据发送后，在过了180秒后，发送FIN信号关闭了连接。 这说明nginx的keepalive倒计时是从最后一个数据包开始计算的！ nginx代理与上游服务器 upstream 之间的连接默认是关闭了长连接，我们可以通过抓包来看到，通过浏览器提交上来的HTTP/1.1的请求，经过代理服务器以后改为HTTP/1.0， 所以想要代理与服务器之间使用长连接，需要修改nginx的相关配置。 upstream里面的有几个配置是跟keepalive相关的： 对于location里面的配置，主要是修改http版本为1.1, 并且把nginx默认传递给upsteam connection：close的行为去掉 http_version需要指定用1.1 ，以及原有的Connection头部要被擦掉 这样就完成了nginx转发给upstream的长连接配置了，但是，我们的upstream也要配置keepalive才行啊，否则它无视nginx发来的connection:keepalive 头部也不行。 我们用的是flask 框架，本地调试的话要加上下面的配置，才能使用上http 1.1 思考一下，用uwsgi的花需要另外配置keepalive吗？ 回答：uwsgi支持keep-alive 如果nginx通过http pass 给uwsgi， --http-keepalive 但是nginx 一般都是通过uwsgi_pass 传递请求给uwsgi，而我们说的是http协议的keepalive ，所以对于其他协议诸如，uwsgi协议，fastcgi协议都是不能生效的 参考 nginx proxy 的规则 nginx keepalive doc 那么至此，nginx跟上游服务器的长连接配置就完成了 curl后面跟随两个连接，让curl同时请求两个url 这时抓包 可以看到，两次的请求，都是使用同一个端口，请求完毕了后，curl主动关闭socket， 毕竟程序也关闭了 。 所以客户端->nginx的连接是实现了http keep-alive 而此时，如果注释掉了nginx配置， 那么此时再次请求，客户端->nginx连接还是可以keep-alive的，但是nginx->upstream就不行了，因为那是针对ngxin->upstream的配置，客户端跟nginx的配置默认就是能keep-alive 为什么这样请求过去nginx，跟nginx的连接没有复用，每次循环，客户端完了都会发送F.信号，而不会复用连接呢？ 这个问题跟一开始我想在终端curl http://xxx 一样想看到第N次curl的时候，都会复用同一个连接，但是上网查了下，使用curl -v curl默认就是http 1.1, connection: keep-alive的，但是curl这个程序结束以后，就会直接关闭socket，这也很正常，程序都关闭了，socket自然就会关闭。 但是这里的我自己写个程序，循环5次，程序没有关闭，它也会自动关闭socket，没有复用连接，看来是requests的问题。 上网查了下，是requests的问题，它默认不支持keepalive，需要使用requests.session 对象来请求，才能使用上keepalive 浏览器打开 http://app-store-server.webapp.163.com:8000/api/recommend/index?a 确实可以复用连接，因为http1.1默认开启了connection: keepalive 当connection:keep-alive的头跟随请求到达nginx，nginx就会keepalive，nginx 是否开启keep-alive的配置就是keepalive-timout, 设置成0就是不开启keepalive。 为了校验效果我我把nginx的keepalive_timeout 设置成了10 连续请求3次，tcp抓包看到 等待10秒后，nginx发送F.信号了，符合我们预期，然后浏览器也立马返回ack信号了。 但是浏览器居然没有发送F.给nginx，这时后的80端端口处于 FIN_WAIT2状态 为什么浏览器没有及时发送F.信号呢？而是在两分钟后，浏览器发送R.信号给nginx，这时的连接才被完全关闭了。 在nginx还处于FIN_WAIT2的时候，也就是说client没想过要发送Fin信号，是因为它认为自己还有数据要发，所以不关闭吗？然后设置了2分钟超时时间，发送R信号，重置连接。 那么这样服务器不是一直得占用了一个端口处于FIN_WAIT2状态吗？这不是很浪费吗？ 在nginx还处于FIN_WAIT2的时候，我让浏览器继续发送同一个请求过去nginx，看看会怎样的，抓包看到 上面的流程： 测试过程中还碰到一种情况是，nginx keepalive 超时后，发送FIN给客户端， 这时客户端再次请求，就走正常流程了，向nginx发送FIN.信号，nginx也回应ack信号。 TCP keepalive的探究 (2) : 浏览器的Keepalive机制 TCP保活（TCP keepalive） tcpdump flags HTTP Keep-Alive是什么？如何工作？ 超时与重试机制（一） FIN_WAIT2 状态 https://my.oschina.net/airship/blog/2875176 curl keep-alive https://serverfault.com/questions/199434/how-do-i-make-curl-use-keepalive-from-the-command-line requests的keep-alive http://xiaorui.cc/2017/04/03/%E6%9E%84%E5%BB%BA%E9%AB%98%E6%95%88%E7%9A%84python-requests%E9%95%BF%E8%BF%9E%E6%8E%A5%E6%B1%A0/ rst包攻击 https://blog.csdn.net/russell_tao/article/details/7228923 TCP的ack机制 http://xstarcd.github.io/wiki/shell/TCP_ACK.html 为什么基于TCP的应用需要心跳包 http://hengyunabc.github.io/why-we-need-heartbeat/ https://www.cnblogs.com/hukey/p/5481173.html

1、系统的扩展方式 2、集群类型 1、集群的实现 2、HA集群的实现 HA Nginx Proxy Service需要的关键资源 AIS可用性委员组，规定高可用集群线 1、集群的分裂（partion） 被称之为集群的分区（partion）也被称之为脑裂（brain-split））为了避免出现分裂，事先做好决策，在每个主机上都有一票，票数多的将获取主节点。如果一个服务器性能好，可以有2票。 2、多节点使用同一个共享存储 在集群发生分裂的情况下， 可能会引发多节点同时对一个块级别的共享存储写一个文件，这样会导致文件系统损坏 VRRP协议 VRRP全称 Virtual Router Redundancy Protocol，即虚拟路由冗余协议。可以认为它是实现路由器高可用的容错协议，即将N台提供相同功能的路由器组成一个路由器组(Router Group)，这个组里面有一个master和多个backup，但在外界看来就像一台一样，构成虚拟路由器，拥有一个虚拟IP（vip，也就是路由器所在局域网内其他机器的默认路由），占有这个IP的master实际负责ARP相应和转发IP数据包，组中的其它路由器作为备份的角色处于待命状态。master会发组播消息，当backup在超时时间内收不到vrrp包时就认为master宕掉了，这时就需要根据VRRP的优先级来选举一个backup当master，保证路由器的高可用。 虚拟路由冗余协议(virtual router redundancy protocol,简称VRRP)，是由IETF提出的解决局域网中配置静态网关出现单点失效现象的路由协议，1998年已推出正式的RFC2338协议标准，VRRP广泛应用在边缘网络中，它的设计目标是支持特定情况下IP数据流量失败转移不会引起混乱，允许主机使用单路由器，以及及时在实际第一跳路由器使用失败的情形下仍能够维护路由器间的连通性。 VRRP术语 VRRP工作过程 路由通告的工作原理 VRRP实现的工作 VRRP认证方式 VRRP高可用工作模型 keepalived程序是vrrp协议在linux主机上以守护进程方式的实现，能够根据配置文件生成IPVS规则 ，并对各real server的健康做检测，以及Loadbalance主机和backup主机之间failover的实现，keepalived在Centos6.4+收录到了发行版光盘中。 Keepalived高可用集群配置前提 Keepalived的程序环境 /etc/keepalived/keepalived.conf Global指令 VRRP_instance指令

使用keepalive的时候保持页面状态保证切换页面不调接口如下AutomaticKeepAliveClientMixin这个Mixin就是Flutter为了保持页面设置的。页面需要保持页面状态，就在这个页面进行混入。不过使用使用这个Mixin是有先决条件的：使用的页面必须是StatefulWidget,如果是StatelessWidget是没办法使用的。其实只有两个前置组件才能保持页面状态：PageView和IndexedStack。重写wantKeepAlive方法，如果不重写也是实现不了的。所以，使用keepalive的时候保持页面状态就可以保证切换页面不调接口。

HTTP的长连接和短连接本质上是TCP长连接和短连接。 短连接 短连接，顾名思义，与长连接的区别就是，客户端收到服务端的响应后，立刻发送FIN消息，主动释放连接。也有服务端主动断连的情况，凡是在一次消息交互（发请求-收响应）之后立刻断开连接的情况都称为短连接。 长连接/http keep-alive 也叫持久连接，即一个TCP连接服务多次请求，在TCP层握手成功后，不立即断开连接，并在此连接的基础上进行多次消息（包括心跳）交互，直至连接的任意一方（客户端OR服务端）主动断开连接，此过程称为一次完整的长连接。 在HTTP/1.0中得到了初步的支持，客户端在请求header中携带Connection:Keep-Alive，即是在向服务端请求持久连接。如果服务端接受持久连接，则会在响应header中同样携带Connection: Keep-Alive，这样客户端便会继续使用同一个TCP连接发送接下来的若干请求。（Keep-Alive的默认参数是[timout=5, max=100]，即一个TCP连接可以服务至多5秒内的100次请求） HTTP/1.1开始，即使请求header中没有携带Connection: Keep-Alive，传输也会默认以持久连接的方式进行，只有加入"Connection: close "后，才关闭。 http keepalive是客户端浏览器与服务端httpd守护进程协作的结果。 TCP中的KeepAlive u2003u2003TCP协议的实现中，提供了KeepAlive报文，用来探测连接的对端是否存活。在应用交互的过程中，可能存在以下几种情况： 客户端或服务器意外断电，死机，崩溃，重启； 中间网络已经中断，而客户端与服务器并不知道； 利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP连接。TCP保活报文交互过程如下： 因此，KeepAlive并不适用于检测双方存活的场景，这种场景还得依赖于应用层的心跳。 应用层心跳也具备着更大的灵活性，可以控制检测时机，间隔和处理流程，甚至可以在心跳包上附带额外信息。 应用层心跳是检测连接有效性以及判断双方是否存活的有效方式 。但是心跳过于频繁会带来 耗电和耗流量 的弊病，心跳频率过低则会影响连接检测的实时性。业内关于心跳时间的设置和优化，主要基于如下几个因素： 理想的情况下,客户端应当以略小于NAT超时时间的间隔来发送心跳包。 根据微信团队测试的一些数据，一些常用网络的NAT超时时间如下表所示： TCP的KeepAlive机制意图在于保活、心跳，检测连接错误 如何快速区分当前连接使用的是长连接还是短连接 1、凡是在一次完整的消息交互（发请求-收响应）之后，立刻断开连接（有一方发送FIN消息）的情况都称为短连接； 2、长连接的一个明显特征是会有心跳消息（也有没有心跳的情况），且一般心跳间隔都在30S或者1MIN左右，用wireshark抓包可以看到有规律的心跳消息交互（可能会存在毫秒级别的误差）。 什么时候用长连接，短连接？ 1、需要频繁交互的场景使用长连接，如即时通信工具（微信/QQ，QQ也有UDP），相反则使用短连接，比如普通的web网站，只有当浏览器发起请求时才会建立连接，服务器返回相应后，连接立即断开。 2、维持长连接会有一定的系统开销，用户量少不容易看出系统瓶颈，一旦用户量上去了，就很有可能把服务器资源（内存/CPU/网卡）耗尽，所以使用需谨慎。 keep-alive与TIME_WAIT 使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。 短连接和长链接 图： 参考： https://caofengbin.github.io/2018/03/16/dhcp-and-nat/#4-%E5%BD%B1%E5%93%8D%E5%BF%83%E8%B7%B3%E9%A2%91%E7%8E%87%E7%9A%84%E5%85%B3%E9%94%AE%E5%9B%A0%E7%B4%A0 https://blog.csdn.net/hengyunabc/article/details/44310193 http://wingjay.com/2018/12/05/android-arch-long-link/ https://www.levicc.com/2018/06/30/yi-dong-duan-wang-luo-you-hua/ 能被我参考的都很优秀，哈哈

页面在router.js中配置好keepalive:true之后。首次进入需要路由守卫的页面，通过打印生命周期执行created->mounted->activated，退出时触发deactivated。 如果跳转的页面没有进行路由守卫的话，想要缓存的页面还是会走destroyed生命周期。导致每次重返页面还是会created，再到以上。 正确的做法应该是两个页面在beforeRouteLeave的周期中条件判定路由信息，进而进行条件控制keepalive beforeRouteEnter生命周期进行判断，然后再走类似created的生命周期，再到activated 离开页面时使用 deactivated 简单言之就是自己找问题，通过打印所有的生命周期来找到问题。 两个目标页面都要进行路由守卫的控制，从而达到keepalive缓存的效果，否则塔们直接把页面直接给你销毁咯。

我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

1.首先第一步我们是对组件进行是否缓存的路由设置在路由中加入meta属性，keepAlive为true的则需要缓存meta: { keepAlive: true}2.对组件进行keep-alive设置,绑定exclude属性设置不活跃组件名，exclude可以是字符串、数组以及正则表达式形式，同时路由中设置meta属性keepAlive为true的进入keep-alive缓存

开始--运行--cmd 进入命令提示符 输入netstat -ano 即可看到所有连接的PID 之后在任务管理器中找到这个PID所对应的程序如果任务管理器中没有PID这一项，可以在任务管理器中选"查看"-"选择列" 经常，我们在启动应用的时候发现系统需要的端口被别...

【答案】：AOSPF是分层路由协议，每个AS中，网络被分为不同区域，每个区域拥有特定标识符。OSPF区域中必须包含主干区域Area 0，其他区域必须连接Area 0。不能连接Area 0区域需要通过虚链路，通过中间区域连接。OSPF使用Hello报文用于发现邻居，保证邻居之间连接关系，而ospf中本身没有keepalive报文。

7.2.6 KeepAlive的添加下面是KeepAlive模块的添加，KeepAlive模块指的是在客户端电脑电源突然中断的情况下，为了确认客户端是否结束而定期传送的信号。如果出现了上面的情况，IOCP或者EventSelect无法测试OnIoDisconnected，因此必须定期传送数据包通过确认是否传送失败来确认是否访问中断。(ConnectedSession.h) #pragma once//继承CPacketSession的CConnectedSessionclass CConnectedSession : public CPacketSession { . . . BOOL ReStart (SOCKET hListenSocket ) ;//设置并获得m_bConnected值的函数VOID SetConnected(BOOL bConnected) { CThreadSync Sync ; m_bConnected = bConnected; } BOOL GetConnected(VOID) { CThreadSync Sync; return m_bConnected; } private://判断是否被访问的变量BOOL m_bConnected}; (ConnectedSession.cpp) CConnectedSession: :CConnectedSession(VOID) {//判断是否被访问的变量m_bConnect ed = FALSE; } (ConnectedSessionManager.h) #pragma once//管理ConnectedSession的类//为了在多线程环境中使用更加稳定，继承CMultiThreadSyncclass CConnectedSessionManager : public CMultiThreadSync< CConnectedSessionManager> { . . . VOID End(VOID) ;//给访问的所有ConnectedSession传送数据包的函数VOID WriteAll (DWORD dwProtocol , BYTE *pData , DWORD dwLength) ; private: . . . };(ConnectedSessionManager.cpp)//给访问的所有Session传送数据的函数VOID CConnectedSessionManager : :WriteAll (DWORD dwProtocol , BYTE *pData, DWORD dwLength) {//同步对象CThreadSync Sync ;//对访问的所有对象进行WritePacketfor (DWORD i =0;i <m_vConnectedSessions.size() ;i ++) {//只对访问中的对象进行WritePacketif (m_vConnectedSessions[i ] ->GetConnected()) m_vConnectedSessions[i ] ->WritePacket (dwProtocol , pData, dwLength) ; } } (ServerIocp.h) #pragma once//继承CIocpclass CServerIocp : public CIocp { . . . VOID End(VOID) ;//KeepAlive Thread Callback函数VOID KeepThreadCallback(VOID) ; . . . CConnectedSessionManager m_oConnectedSessionManager ;//管理KeepAlive Thread的句柄HANDLE m_hKeepThread; //结束KeepAlive Thread时使用的事件HANDLE m_hKeepThreadDestroyEvent ; }; (ServerIocp.cpp)//KeepAlive Thread Callback函数DWORD WINAPI KeepThreadCallback(LPVOID pParameter) { CServerIocp *pOwner = (CServerIocp*) pParameter ; pOwner->KeepThreadCallback() ; return 0; } VOID CServerIocp: :KeepThreadCallback(VOID) {//KeepAlive信号DWORD dwKeepAl ive = 0xFFFF; while (TRUE) {//30秒内结束事件没有出现的话，将跳过DWORD dwResult = WaitForSingleObject (m_hKeepThreadDestroyEvent , 30000) ;//结束时间出现的情况下，结束Threadif (dwResult == WAIT_OBJECT_0) return;//给访问中的所有Session传送数据包m_oConnect edSessionManager .WriteAll (0x3000000, (BYTE*)&dwKeepAlive , sizeof (DWORD)) ; } }//CIocp的假想函数VOID CServerIocp: :OnIoConnected(VOID *pObject ) { . . . pConnectedSession->SetConnected(TRUE) ; } VOID CServerIocp: :OnIoDisconnected(VOID *pObject ) { . . . pConnectedSession->SetConnected(FALSE) ; } BOOL CServerIocp: :Begin(VOID) { . . .//创建KeepAlive结束事件m_hKeepThreadDestroyEvent = CreateEvent (NULL, FALSE, FALSE, NULL) ; if ( !m_hKeepThreadDestroyEvent ) {//失败的情况下结束CServerIocp: :End() ; return FALSE; } //创建KeepAlive Threadm_hKeepThread = CreateThread(NULL, 0, : :KeepThreadCallback, this, 0, NULL) ; if ( !m_hKeepThread) {//创建失败的情况下结束CServerIocp: :End() ; return FALSE; } return TRUE; } VOID CServerIocp: :End(VOID) {//结束CServerIocp的时候//m_hKeepThread不是NULL的话，结束KeepAlive Threadif (m_hKeepThread) {//出现结束事件SetEvent (m_hKeepThreadDestroyEvent ) ;//等待至Thread结束为止WaitForSingleObject (m_hKeepThread, INFINITE) ;//关闭句柄CloseHandle(m_hKeepThread) ; m_hKeepThread = NULL; }//如果KeepAlive结束事件不是NULL的话if (m_hKeepThreadDestroyEvent ) {//关闭事件CloseHandle(m_hKeepThreadDestroyEvent ) ; m_hKeepThreadDestroyEvent = NULL;

在需要清除的组件内引入 ，然后使用这个方法。

印象中ospf没有keepalive报文，就靠hello包来邻居保活。能具体点吗？

winver---------检查Windows版本wmimgmt.msc----打开windows管理体系结构(WMI)wupdmgr--------windows更新程序wscript--------windows脚本宿主设置write----------写字板winmsd---------系统信息wiaacmgr-------扫描仪和照相机向导winchat--------XP自带局域网聊天 mem.exe--------显示内存使用情况Msconfig.exe---系统配置实用程序 mplayer2-------简易widnows media playermspaint--------画图板mstsc----------远程桌面连接mplayer2-------媒体播放机magnify--------放大镜实用程序mmc------------打开控制台mobsync--------同步命令dxdiag---------检查DirectX信息drwtsn32------ 系统医生devmgmt.msc--- 设备管理器dfrg.msc-------磁盘碎片整理程序diskmgmt.msc---磁盘管理实用程序dcomcnfg-------打开系统组件服务ddeshare-------打开DDE共享设置dvdplay--------DVD播放器net stop messenger-----停止信使服务net start messenger----开始信使服务 notepad--------打开记事本nslookup-------网络管理的工具向导ntbackup-------系统备份和还原narrator-------屏幕“讲述人”ntmsmgr.msc----移动存储管理器ntmsoprq.msc---移动存储管理员操作请求netstat -an----(TC)命令检查接口syncapp--------创建一个公文包sysedit--------系统配置编辑器sigverif-------文件签名验证程序sndrec32-------录音机shrpubw--------创建共享文件夹secpol.msc-----本地安全策略syskey---------系统加密，一旦加密就不能解开，保护windows xp系统的双重密码services.msc---本地服务设置Sndvol32-------音量控制程序sfc.exe--------系统文件检查器sfc /scannow---windows文件保护tsshutdn-------60秒倒计时关机命令tourstart------xp简介（安装完成后出现的漫游xp程序）taskmgr--------任务管理器eventvwr-------事件查看器eudcedit-------造字程序 explorer-------打开资源管理器packager-------对象包装程序perfmon.msc----计算机性能监测程序progman--------程序管理器regedit.exe----注册表 rsop.msc-------组策略结果集regedt32-------注册表编辑器rononce -p ----15秒关机regsvr32 /u *.dll----停止dll文件运行regsvr32 /u zipfldr.dll------取消ZIP支持cmd.exe--------CMD命令提示符chkdsk.exe-----Chkdsk磁盘检查certmgr.msc----证书管理实用程序calc-----------启动计算器charmap--------启动字符映射表cliconfg-------SQL SERVER 客户端网络实用程序Clipbrd--------剪贴板查看器conf-----------启动netmeetingcompmgmt.msc---计算机管理cleanmgr-------垃圾整理ciadv.msc------索引服务程序osk------------打开屏幕键盘odbcad32-------ODBC数据源管理器oobe/msoobe /a----检查XP是否激活lusrmgr.msc----本机用户和组logoff---------注销命令iexpress-------木马捆绑工具，系统自带Nslookup-------IP地址侦测器fsmgmt.msc-----共享文件夹管理器utilman--------辅助工具管理器gpedit.msc-----组策略 请参考

当使用 select()函数测试一个socket是否可读时，如果select()函数返回值为1，且使用recv()函数读取的数据长度为0 时，就说明该socket已经断开。为了更好的判定socket是否断开，我判断当recv()返回值小于等于0时，socket连接断开。但是还需要判断 errno是否等于 EINTR 。如果errno == EINTR 则说明recv函数是由于程序接收到信号后返回的，socket连接还是正常的，不应close掉socket连接。

<keep-alive>是Vue的内置组件，能在组件切换过程中将状态保留在内存中，防止重复渲染DOM。 prop: 在2.1.0版本Vue中 常见用法： // 组件export default { name: "test-keep-alive", data () { return { includedComponents: "test-keep-alive" } } } <keep-alive include="test-keep-alive"> <!-- 将缓存name为test-keep-alive的组件 --> <component></component></keep-alive> <keep-alive include="a,b"> <!-- 将缓存name为a或者b的组件，结合动态组件使用 --> <component :is="view"></component></keep-alive> <!-- 使用正则表达式，需使用v-bind --><keep-alive :include="/a|b/"> <component :is="view"></component></keep-alive> <!-- 动态判断 --><keep-alive :include="includedComponents"> <router-view></router-view></keep-alive> <keep-alive exclude="test-keep-alive"> <!-- 将不缓存name为test-keep-alive的组件 --> <component></component></keep-alive> 结合router，缓存部分页面 使用$route.meta的keepAlive属性： <keep-alive> <router-view v-if="$route.meta.keepAlive"></router-view></keep-alive><router-view v-if="!$route.meta.keepAlive"></router-view> 需要在router中设置router的元信息meta： //...router.jsexport default new Router({ routes: [ { path: "/", name: "Hello", component: Hello, meta: { keepAlive: false // 不需要缓存 } }, { path: "/page1", name: "Page1", component: Page1, meta: { keepAlive: true // 需要被缓存 } } ] }) 使用效果 以上面router的代码为例： <!-- Page1页面 --><template> <p class="hello"> <h1>Vue</h1> <h2>{{msg}}</h2> <input placeholder="输入框"></input> </p></template> <!-- Hello页面 --><template> <p class="hello"> <h1>{{msg}}</h1> </p></template> (1) 在Page1页面输入框输入“asd”，然后手动跳转到Hello页面； (2) 回到Page1页面发现之前输入的"asd"依然保留，说明页面信息成功保存在内存中； 图1 进入Page1页面，并输入"asd" 图2 跳转到Hello 图3 返回Page1页面，输入框数据会被保留 当然，也可以通过动态设置route.meta的keepAlive属性来实现其他需求， 借鉴一下 vue-router 之 keep-alive，作者：RoamIn这篇博客中的例子： 思路是在每个路由的beforeRouteLeave(to, from, next)钩子中设置to.meta.keepAlive： A的路由： { path: "/", name: "A", component: A, meta: { keepAlive: true // 需要被缓存 } } export default { data() { return {}; }, methods: {}, beforeRouteLeave(to, from, next) { // 设置下一个路由的 meta to.meta.keepAlive = true; // B 跳转到 A 时，让 A 缓存，即不刷新 next(); } }; export default { data() { return {}; }, methods: {}, beforeRouteLeave(to, from, next) { // 设置下一个路由的 meta to.meta.keepAlive = false; // C 跳转到 A 时让 A 不缓存，即刷新 next(); } }; 亲测有效哦~ keep-alive生命周期钩子函数：activated、deactivated 使用<keep-alive>会将数据保留在内存中，如果要在每次进入页面的时候获取最新的数据，需要在activated阶段获取数据，承担原来created钩子中获取数据的任务。

① Idle（空闲）：Idle 是BGP连接的第一个状态，在空闲状态，BGP在等待一个启动事件，启动事件出现以后，BGP初始化资源，复位连接重试计时器（Connect-Retry），发起一条TCP连接，同时转入Connect（连接）状态。② Connect（连接）：在Connect 状态，BGP发起第一个TCP连接，如果 连接重试计时器（Connect-Retry）超时，就重新发起TCP连接，并继续保持在Connect 状态，如果TCP 连接成功，就转入OpenSent 状态，如果TCP 连接失败，就转入Active 状态。③ Active（活跃）：在Active状态，BGP总是在试图建立TCP 连接，如果连接重试计时器（Connect-Retry）超时，就退回到Connect 状态，如果TCP 连接成功，就转入OpenSent 状态，如果TCP 连接失败，就继续保持在Active状态，并继续发起TCP连接。④ OpenSent（打开消息已发送）：在OpenSent 状态，TCP连接已经建立，BGP也已经发送了第一个Open报文，剩下的工作，BGP就在等待其对等体发送Open 报文。并对收到的Open报文进行正确性检查，如果有错误，系统就会发送一条出错通知消息并退回到Idle状态，如果没有错误，BGP就开始发送Keepalive 报文，并复位Keepalive 计时器，开始计时。同时转入OpenConfirm状态。⑤ OpenConfirm（打开消息确认）状态：在OpenConfirm状态，BGP发送一个Keepalive 报文，同时复位保持计时器，如果收到了一个Keepalive 报文，就转入Established 阶段，BGP邻居关系就建立起来了。如果TCP连接中断，就退回到Idle 状态。⑥ Established（连接已建立）：在Established 状态，BGP 邻居关系已经建立，这时，BGP将和它的邻居们交换Update 报文，同时复位保持计时器。

Http打开的连接默认支持KeepAlive，即当后续连接同一个服务器的时候，使用的是之前建立的Socket连接，默认最大连接数为5，可通过设置http.keepAlive为“true”或“false”来启用/禁用HTTP KeepAlive。 转自（侵删）： https://www.cnblogs.com/foodoir/p/5911099.html 【GET：获取资源】 GET方法用来请求已被URI识别的资源。指定的资源经服务器端解析后返回响应内容（也就是说，如果请求的资源是文本，那就保持原样返回；如果是CGI[通用网关接口]那样的程序，则返回经过执行后的输出结果）。 最常用于向服务器查询某些信息。必要时，可以将查询字符串参数追加到URL末尾，以便将信息发送给服务器。 使用GET请求时经常会发生的一个错误，就是查询字符串的格式有问题。查询字符串中每个参数的名称和值都必须使用encodeURLComponent()进行编码，然后才能放到URL的末尾；而且所有的名-值对都必须由（&）分离，如下面的例子： xhr.open("get","01.php?name=foodoir&age=21",true); 下面这个函数可以辅助现有URL的末尾添加查询字符串参数：

ipvs用于负载均衡，分担服务器压力，keepalived实现高可用，通常会对负载均衡集群实现高可用

对 于一个已经建立的tcp连接。如果在keepalive_time时间内双方没有任何的数据包传输，则开启keepalive功能的一端将发送 keepalive数据包，若没有收到应答，则每隔keepalive_intvl时间再发送该数据包，发送keepalive_probes次。

就是不要保活机制了，一般都是起动态协议令居或者tunnel邻居会设置这个，用来监控对端是否正常。

主要介绍如何让服务器自动踢除SDE死连接，希望能对您有所帮助。一、设置TCPKEEPALIVE参数为TRUE方法一：用PLSQL或TOAD打开SDE用户下的表SEVER_CONFIG，编辑字段CONNECTIONS值为你的最大连接数。设置字段TCPKEEPALIVE值为TRUE。方法二：打开SDE的安装目录下的（一般安装路径为C:arcgisArcSDEsqlexeetc）giomgr.defs文件进行编辑，设置CONNECTIONS参数为你的最大连接数。然后设置TCPKEEPALIVE参数为TRUE。 通过命令导入到数据库中：sdeconfig –o import –f C:arcgisArcSDEsqlexeetcgiomgr.defs –i esri_sde(数据库实例名) –s (ServerName) –u sde(用户名) –p sde(密码) 。 设置好后需要重启SDE服务才能生效。二、设置KeepAliveTime参数值在 Microsoft Windows 设置 KeepAliveTime 为 300000. HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTCPIPParametersKeepAliveTime.If the如果这个注册表键值不存在，则要自己创建这个值. 同进这个时间指的是毫秒.其中当线程资料超过corePoolSize的值时，则线程时间超过KeepAliveTime的则自动断开，KeepAliveTime＝300000。当TCPKEEPALIVE参数设置为TRUE后，数据库会根据SDE服务所在机器的注册表项KEEPALIVETIME所提供的响应时间， 不断侦测所有连接是否为无效连接，如果为无效连接，则自动删除该连接。 对默认安装操作系统的机器而言KEEPALIVETIME注册表项是没有的。 如果没有话，服务器不会主动发送KeepAlive数据包来确认空闲连接是否依然毫无变化。也就不会进行删除操作。 所以上面提到的无效连接会越来越多。可以在如下路径中：Local_MachinesystemCurrentControlSetServicesTcpipParameters 添加DWORD项：KeepAliveTime。 如果不设置值的话默认为两小时。具体时间可以看情况而定。一般推荐为5分钟。然后重启机器（一定要重启，注册表的新加项才生效）。关于SDE连接Oracle数据库的知识就介绍到这里了，希望通过这几次的介绍，能让您对SDE连接Oracle数据库的知识会有一个比较深刻的理解吧！您的收获将是我们最大的快乐！

keepalive是为了能保持连接状态而定期发送的数据包。如果超过一段时间收不到就意味着邻居挂了或者链路断了。。后面那个是用于设备之间做热备份的

前几天在调查一个Kafka服务器tcp连接数过大的问题。具体情况是单台Kafka的tcp连接数超过了3万，都是ESTABLISHED状态，到部分remote ip的连接数达到了几百，且连接数每天还在持续增加。这批remote ip都是属于同一个业务。 刚开始怀疑是Kafka某些条件下存在socket leakage的bug。但后来调查证实是防火墙引起的问题——Kafka服务器与这批业务服务器间存在一个防火墙，且配置了清理半小时的空闲连接。而我们使用的Kafka版本较低(0.8.2.1)，在创建连接时没有使用tcp keepalive。于是有些连接长时间没有数据传输就被防火墙在中间悄悄干掉了，而Kafka broker端没有发现，残留了大量无效连接。 其实Kafka官网已经记录了这个issue( https://issues.apache.org/jira/browse/KAFKA-2096 )，解决方案就是在创建tcp连接时加上keepalive选项，在0.9.0版本中已经解决。我们的Kafka由于升级影响较大，为降低风险采取了patch回当前版本的解决方案。 之前一直没太深入了解过TCP Keepalive，借此机会补一下课，也在此简单记录。 TCP keepalive选项，在创建tcp socket时默认是不打开的。默认的发送间隔较长，为7200秒，即2小时。在linux内核中相关的配置参数为 如果需要修改为更短的keepalive间隔，可以用命令 查看一个tcp连接是否使用了keepalive，可以用netstat -o查看，最后一列会是keepalive和倒计时。 要注意tcp keepalive是单向的，即只是单向的发送keepalive包且不需要response。 一个简单例子。 server端： client端，用python实现： 连接状态： 从上面的最后一列可以看到，client到server的连接使用了keepalive，下次发送keepalive的倒计时为7184秒。 参考资料：

使用过 Vue 的小伙伴们肯定都知道，Vue 的内部组件 keep-alive 是用来缓存我们不活动的组件的。 但是在某些情况下，我们需要缓存，某些情况下希望及时释放掉缓存，那我们应该怎么做呢？ 有个场景是，希望模仿App的方式，每次push到当前页面的时候，触发 mounted 进行组件初始化，而从其他页面返回到当前页面时，希望可以保留当前组件的状态。 举个例子： 移动端的分页列表页面，加载了几页，并且有滑动记录，但是希望进详情页后，返回列表页时，可以保持分页的状态以及滑动的轨迹。 需求如上，这就需要 keep-alive 帮助我们缓存组件了。 但是用过 keep-alive 组件的小伙伴肯定明白，如果 include 当前列表页面，虽然可以做到返回列表页保持状态，但是从其他页面前往列表页时，依然会加载缓存的状态，我们不得不采用 activated 钩子方法来处理，但这样总归是不优雅的。 看过一些文字有人说让include的数组变成动态的是否能达到类似的效果，这种方式也非常好，可以很容易的达到我们想要的效果。 阅读过源码之后发现， keep-alive 内部实现是将组件缓存在一个 caches 数组中的，如果我们可以操作这个数组，是否可以达到灵活控制缓存组件的效果呢？ 方法一比较繁琐，但是用起来还是很直接的，比较灵活，可以应付浏览器刷新的场景 方法二比较简单，适合在移动app中使用，自己维护页面栈，不会有浏览器刷新等操作，否则include的内容可能会由于刷新而出现栈异常

　　对于Win2K/XP/2003，可以从下面的注册表项找到影响整个系统所有连接的keepalive参数：　　[HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters]　　“KeepAliveTime”=dword:006ddd00　　“KeepAliveInterval”=dword:000003e8　　“MaxDataRetries”=”5″

TCP keepalive是TCP的保活定时器。通俗地说，就是TCP有一个定时任务做倒计时，超时后会触发任务，内容是发送一个探测报文给对端，用来判断对端是否存活。 （想到一个桥段：“如果2小时后没等到我的消息，你们就快跑”） 正如概念中说的，用于探测对端是否存活，从而防止连接处于“半打开”状态。 所谓半打开，就是网络连接的双端中，有一端已经断开，而另一端仍然处于连接状态。 （图一）TCP keepalive 流程图 建立连接的双端在通信的同时，存在一个定时任务A，每当传输完一个报文，都会重置定时任务A。如果在定时任务的时限 tcp_keepalive_time 内不再有新的报文传输，便会触发定时任务A，向对端发送存活探测报文。根据响应报文的不同情况，有不同的操作分支，如上图所示。 定时任务B会被循环执行，具体逻辑是：定时任务A的探测报文没有得到响应报文，开始执行定时任务B。任务B的内容同样是发送探测报文，但不同的是，B会被执行 tcp_keepalive_probes 次，时间间隔为 tcp_keepalive_intvl 。B的探测报文同样也是在收到响应报文后，重置定时任务A，维持连接状态。 上文提到的三个参数存在于系统文件中，具体路径如下： 通信双端都存在一个文件作为数据缓冲区，对端发送给本地当前端口的数据都会缓冲在这个文件中。上文中讲的“断开连接”就是关闭这个文件，关闭后所有发送到当前端口的数据将无法存储到缓冲区，即数据被丢弃了。 通过指令 lsof -i :8080 ，8080改成你的端口号，便能看到这个缓冲区文件。 HTTP keepalive指的是持久连接，强调复用TCP连接。（类似场景：挂电话之前总会问句，没啥事就先挂了，延长通话时长来确认没有新话题） 延长TCP连接的时长，一次TCP连接从创建到关闭期间能传输更多的数据。 （图二）HTTP keepalive 流程图 通信连接的双端在通信的同时，存在一个HTTP层面的keepalive定时任务。当客户端发起Request，并且接收到Response之后，触发定时任务。定时任务会开始计时，达到keepalive的时间距离后，关闭连接。如果在计时期间，客户端再次发起Request，并且接收到Response，定时任务会被重置，从头计时。 图二用Python的socket库为示例进行说明，在HTTP的“请求-响应”过程中，HTTP keepalive（或者称为HTTP持久连接）在底层是如何作用于连接释放流程，从而延长连接时长的。 为什么不用Python的requests库来举例说明？requests底层也是socket连接管理，不同的是requests支持HTTP协议，可以解析出HTTP各部分信息；socket仅仅是从文件缓冲区读取二进制流。同样地，各种Web框架中的Request和Response对象的内部仍然是socket连接管理，只提socket可以排除很多干扰信息。 服务端HTTP keepalive超时后的数据丢弃的说明。刚入门的同学可能也会像我一样感到疑惑：服务端keepalive超时后再收到数据就会丢弃，那么服务端后续还怎么接收端口的数据？ 这就不得不提到服务端的fork模型了：服务端主进程监听端口，当数据到来时便交给子进程来处理，主进程继续循环监听端口。 具体地说，当数据到来时，主进程先创建新的socket连接句柄（本质就是生成了socket文件描述符落在磁盘上，端口数据会存储在该文件中缓冲），随后fork出子进程；主进程关闭新的socket句柄，子进程则维持socket句柄的连接（当一个socket句柄在所有进程中都被close之后才会开始TCP四次挥手）；此后，子进程接管了与客户端的通信。 正如（图三）的例子，主进程会fork出很多子进程，A和B分别对接的是不同客户端发来的请求，socket文件描述符a不会影响b的数据读写。 （图三）fork模型下传递socket句柄的过程 结论是，服务端与外界建立的每一个socket连接，都有独立的文件描述符和独立的子进程与客户端通信。服务端断开连接是指关闭了某个文件描述符的读写，并非关闭了整个端口的数据往来，不影响其他的socket连接之间通信。至于丢弃，就是说外界如果还有发往这个socket文件描述符的数据被丢弃，因为这个文件描述符已经禁止写入，自然地数据便无法落地。 TCP keepalive更像是保障系统有序工作的兜底机制，确保系统最终能收回半打开的socket连接，否则长期运行后无法再接收更多的请求（系统的socket最大连接数限制）。 HTTP keepalive则是应用层的骚操作，使得服务端的应用程序能自主决定socket的释放，因为TCP keepalive的倒计时默认值很长，web服务的某次连接通常不需要等待那么久。说直白点，就是TCP有一个计时器，HTTP也可以自己搞个计时器，如果HTTP的计时器先超时，同样有权利让TCP进入四次挥手流程。 在某个数据包传输后，两个keepalive的定时任务同时存在且一起进入倒计时状态，一个是系统内核TCP相关代码的程序，另一个是高级编程语言（Python/Java/Go等）Web框架代码的程序，他们一起运行并不冲突。 HTTP keepalive是应用层的东西，在上生产时对外提供服务的应用程序都会有keepalive参数，例如Gunicorn的keepalive、Nginx的keepalive_timeout。通过这个参数，我们能在更高级的层面控制等待下一个数据的时长。 还有，如果同一台服务器有N个Web服务，TCP keepalive参数是全局生效，众口难调。 如果你的网络结构是类似client-nginx-web server，那么你就要同时考虑nginx和web server的keepalive参数大小搭配的问题，此处引用Gunicorn对keepalive参数的使用建议： 假设web等待时间比nginx短很多，client-nginx的连接还在，nginx-web就已经断开了，web就会错过一些数据，对于客户来说好端端的我拿不到结果是无法容忍的。因此最好是和nginx的等待时间协调好，不要相差太多（不要太短，也不要长很多）。 关于不要太长，多说一句。如果等待很久，web服务会累积维持非常多的连接，这样子新的请求无法打进来，正在维持的连接不见得利用率很高（可能客户端的代码在打断点、可能客户端早就close）。结果就是服务端netstat显示一堆连接，新的请求全都被挂起甚至丢弃。

我觉得一般情况下的话，这个缓存可以直接就从官网里面进行查看

如果设置为0，则不会进行Keepalive检测

法一：当recv()返回值小于等于0时，socket连接断开。但是还需要判断 errno是否等于 EINTR，如果errno == EINTR 则说明recv函数是由于程序接收到信号后返回的，socket连接还是正常的，不应close掉socket连接。法二：struct tcp_info info;int len=sizeof(info);getsockopt(sock, IPPROTO_TCP, TCP_INFO, &info, (socklen_t *)&len);if((info.tcpi_state==TCP_ESTABLISHED)) 则说明未断开 else 断开法三：若使用了select等系统函数，若远端断开，则select返回1，recv返回0则断开。其他注意事项同法一。法四：int keepAlive = 1; // 开启keepalive属性int keepIdle = 60; // 如该连接在60秒内没有任何数据往来,则进行探测 int keepInterval = 5; // 探测时发包的时间间隔为5 秒int keepCount = 3; // 探测尝试的次数.如果第1次探测包就收到响应了,则后2次的不再发.setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));设置后，若断开，则在使用该socket读写时立即失败，并返回ETIMEDOUT错误法五：自己实现一个心跳检测，一定时间内未收到自定义的心跳包则标记为已断开。

打开消息(open)、存活消息(keepalive)、更新消息(update)、通知消息(notification)

① Idle（空闲）：Idle 是BGP连接的第一个状态，在空闲状态，BGP在等待一个启动事件，启动事件出现以后，BGP初始化资源，复位连接重试计时器（Connect-Retry），发起一条TCP连接，同时转入Connect（连接）状态。② Connect（连接）：在Connect 状态，BGP发起第一个TCP连接，如果 连接重试计时器（Connect-Retry）超时，就重新发起TCP连接，并继续保持在Connect 状态，如果TCP 连接成功，就转入OpenSent 状态，如果TCP 连接失败，就转入Active 状态。③ Active（活跃）：在Active状态，BGP总是在试图建立TCP 连接，如果连接重试计时器（Connect-Retry）超时，就退回到Connect 状态，如果TCP 连接成功，就转入OpenSent 状态，如果TCP 连接失败，就继续保持在Active状态，并继续发起TCP连接。④ OpenSent（打开消息已发送）：在OpenSent 状态，TCP连接已经建立，BGP也已经发送了第一个Open报文，剩下的工作，BGP就在等待其对等体发送Open 报文。并对收到的Open报文进行正确性检查，如果有错误，系统就会发送一条出错通知消息并退回到Idle状态，如果没有错误，BGP就开始发送Keepalive 报文，并复位Keepalive 计时器，开始计时。同时转入OpenConfirm状态。⑤ OpenConfirm（打开消息确认）状态：在OpenConfirm状态，BGP发送一个Keepalive 报文，同时复位保持计时器，如果收到了一个Keepalive 报文，就转入Established 阶段，BGP邻居关系就建立起来了。如果TCP连接中断，就退回到Idle 状态。⑥ Established（连接已建立）：在Established 状态，BGP 邻居关系已经建立，这时，BGP将和它的邻居们交换Update 报文，同时复位保持计时器。

不同的系统不一样的，windows一般是通过改注册表来改变keepalivetime的值。linux或unix下这个值也是基于整个内核的，它的改变会影响本机所有设置了这个选项的socket。

【总结】此处GetResponse超过的原因是，当前存在太多数目的alive的http连接（大于10个），所以再次提交同样的http的request，再去GetResponse，就会超时死掉。解决办法就是，把DefaultConnectionLimit 设置为一个比较大一点的数值，此数值保证大于你当前已经存在的alive的http连接数即可。【经验总结】以后写http的request代码，如果不是必须的要keepalive的，那么就要设置KeepAlive为false：req.KeepAlive = false;以及做对应的收尾动作：if (resp != null) { resp.Close(); } if (req != null) { req.Abort(); }

这是我网络中找的参考，希望对你有帮助。在多线程任务中，TCP任务通过三次握手能建立可靠的连接，但是经常会发生在数据传输或通信时发生网络突然断开或者长时间连接空循环监听而未进行操作，需要在软件设计时考虑程序运行中检测到服务器对客户端的这一“虚连接”现象。如果主机崩溃，write是否阻塞取决于内核的tcp缓冲区，但read将一直阻塞，直到超时ETIMEOUT，或由于某些中间路由器的原因返回EHOSTUNREACH/ENETUNREACH。select不能检测到该情况。如果主机崩溃并重起，客户的write到达主机时主机响应RST，客户的read将返ECONNRESET。此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等物理链路的原因,还有突然主机断电等原因 。心跳机制有两种方法可以检测:1.TCP连接双方定时发握手消息 2.利用TCP协议栈中的KeepAlive探测第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测,所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试)1）Windows平台C代码//定义结构及宏 struct TCP_KEEPALIVE { u_longonoff; u_longkeepalivetime; u_longkeepaliveinterval; } ; #define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4) //KeepAlive实现 TCP_KEEPALIVE inKeepAlive = {0}; //输入参数 unsigned long ulInLen = sizeof(TCP_KEEPALIVE); TCP_KEEPALIVE outKeepAlive = {0}; //输出参数 unsigned long ulOutLen = sizeof(TCP_KEEPALIVE); unsigned long ulBytesReturn = 0; //设置socket的keep alive为5秒，并且发送次数为3次 inKeepAlive.onoff = 1; inKeepAlive.keepaliveinterval = 5000; //两次KeepAlive探测间的时间间隔 inKeepAlive.keepalivetime = 5000; //开始首次KeepAlive探测前的TCP空闭时间 if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen, (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL) == SOCKET_ERROR) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) WSAIoctl failed. error code(%d)! "), WSAGetLastError())); } //定义结构及宏 struct TCP_KEEPALIVE { u_longonoff; u_longkeepalivetime; u_longkeepaliveinterval; } ; #define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4) //KeepAlive实现 TCP_KEEPALIVE inKeepAlive = {0}; //输入参数 unsigned long ulInLen = sizeof(TCP_KEEPALIVE); TCP_KEEPALIVE outKeepAlive = {0}; //输出参数 unsigned long ulOutLen = sizeof(TCP_KEEPALIVE); unsigned long ulBytesReturn = 0; //设置socket的keep alive为5秒，并且发送次数为3次 inKeepAlive.onoff = 1; inKeepAlive.keepaliveinterval = 5000; //两次KeepAlive探测间的时间间隔 inKeepAlive.keepalivetime = 5000; //开始首次KeepAlive探测前的TCP空闭时间 if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen, (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL) == SOCKET_ERROR) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) WSAIoctl failed. error code(%d)! "), WSAGetLastError())); }2）Linux平台C代码#include …… ////KeepAlive实现 //下面代码要求有ACE,如果没有包含ACE,则请把用到的ACE函数改成linux相应的接口 int keepAlive = 1;//设定KeepAlive int keepIdle = 5;//开始首次KeepAlive探测前的TCP空闭时间 int keepInterval = 5;//两次KeepAlive探测间的时间间隔 int keepCount = 3;//判定断开前的KeepAlive探测次数 if(setsockopt(s,SOL_SOCKET,SO_KEEPALIVE,(void*)&keepAlive,sizeof(keepAlive)) == -1) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) setsockopt SO_KEEPALIVE error! "))); } if(setsockopt(s,SOL_TCP,TCP_KEEPIDLE,(void *)&keepIdle,sizeof(keepIdle)) == -1) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPIDLE error! "))); } if(setsockopt(s,SOL_TCP,TCP_KEEPINTVL,(void *)&keepInterval,sizeof(keepInterval)) == -1) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPINTVL error! "))); } if(setsockopt(s,SOL_TCP,TCP_KEEPCNT,(void *)&keepCount,sizeof(keepCount)) == -1) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t)setsockopt TCP_KEEPCNT error! "))); } 心跳机制：定时发送一个自定义的结构体(心跳包)，让对方知道自己还活着，以确保连接的有效性。网络中的接收和发送数据都是使用WINDOWS中的SOCKET进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”。以确保链接的有效性。所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可以是客户也可以是服务端，看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项。系统默认是设置的是2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。心跳包一般来说都是在逻辑层发送空的包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀当然，这个自然是要由逻辑层根据需求去做了。总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。TCP连接异常断开后操作系统会告诉你，你查询套接字的状态会得到异常，或者当发现函数失败WSAGetLastError的时候也会得到内核的通知。// 发送回应消息int nSend = Send4IntMsg(sock, (char*)(LPCTSTR)strSendBuf, strSendBuf.GetLength(), errMsg);if (nSend < 0) // 发送消息失败closesocket(sock);//重新连接在B/S编程和UDP编程时才用到心跳。比如定期向web服务器发一个request证明自己在线。http协议是请求一下就断开了，每次都要重新连接，重新请求，这种情况下才有必要用心跳机制。一般的TCP通信都是长连接，不可能频繁连接和断开。对于长期保持连接的情况，一旦断开，操作系统底层都会通知你，你需要解决的是如何获取到系统的通知。

keepalive虚拟ip不是随便写的。keepalive虚拟ip是以VRRP协议为实现基础的，决定着网络的连接，属于重要的数据，所以keepalive虚拟ip不是随便写的。

背景： 1、A列表页面 --- 跳转到 --- B填写页面 (B页面不要缓存)。 2、A列表页面 --- 跳转到 --- B填写页面(填写了内容) --- 跳转到(B页面需要缓存) --- C选择单位页面再回到B页面，要显示 B页面之前填写的内容。 用vue-router中的keepAlive设置为true是不可行的。 注：：：：：以上这种方式是不行的。 可行方案： 结合keep-alive的include属性和vuex进行缓存。 这种方式不依赖于vue-router中的keepAlive值，那怕设置为false，也可以通过上面的方式进行页面缓存。 这样就OK了！！！

很多人认为，TCP协议有KeepAlive机制，为何基于它的通讯链接仍然需要在应用层实现额外的心跳保活呢？本文将从移动端IM的角度告诉你，即使使用的是TCP协议，应用层的心跳保活仍旧必不可少。 在使用TCP长连接的IM服务设计中，往往都会涉及到心跳。心跳一般是指客户端每隔一定时间向服务端发送自定义指令，以判断双方是否存活，因其按照一定间隔发送，类似于心跳，故称为心跳指令。 TCP是一个基于连接的协议，其连接状态是由一个状态机进行维护，连接完毕（三次握手）后，双方都会处于established状态，这之后的状态并不会主动进行变化。也就是说，即使上层不进行任何调用，一直使TCP连接空闲，那么它仍然是保持连接的状态。这个时候就需要一种机制来检测TCP连接的状态，KeepAlive就是背负这个使命出现的。 那么问题来了，KeepAlive是用来检测TCP连接状态的，那为什么还需要心跳呢？这里就需要考虑一种情况了，假如某台服务器因为某些原因导致负载超高，CPU100%，无法响应任何业务需求，但是使用TCP探针仍旧能够确定连接状态，这就是典型的连接活着但业务提供方已死的状态，对客户端而言，这时最好的选择就是断线后重新连接其他服务器，而不是一直认为当前服务器是可用状态，一直向当前服务器发送些必然后失败的请求。 从上面我们可以知道，KeepAlive并不适合检测双方存活的场景，这种场景还得依赖于应用层的心跳。应用层的心跳有着更大的灵活性，可以控制检测时机、间隔和处理流程，甚至可以在心跳包上附带额外信息。从这个角度而言，应用层的心跳的确是最佳实践。 TCP KeepAlive用于检测连接的死活，而心跳机制则附带一个额外的功能：检测通讯双方的存活状态。 从上面我们可以得出结论，目前而言，应用层心跳的确是检测连接有效性，双方是否存活的最佳实践，那么剩下的问题就是怎么实现。 最简单粗暴的方法是定时心跳，如每隔30秒心跳一次，15秒内没有收到心跳包则认为当前连接已失效，断开连接并进行重连。这种做法最直接，实现也简单。唯一的问题就是耗电和耗流量。以一个协议包 5 个字节计算，一天收发 2880 个心跳包，一个月就是 5 x 2 x 2880 x 30 = 0.8 M 的流量，如果手机上多装几个 IM 软件，每个月光心跳就好几兆流量没了，更不用说频繁的心跳带来的电量损耗。 既然频繁心跳会带来耗电和耗流量的弊端，改进的方向自然就是减少心跳频率，但也不能过于影响连接检测的实时性。基于这个需求，一般可以将心跳间隔根据程序状态进行调整，当程序在后台时（这里主要指安卓），尽量拉长心跳间隔，5分钟、甚至10分钟都可以。 而当App在前台时则按照原来规则操作。连接可靠性的判断也可以放宽，避免一次心跳超时就认为连接无效的情况，使用错误积累，只在心跳超时n次后才判定当前连接不可用。

发送端发送一个SYN=1，ACK=0标志的数据包给接收端，请求进行连接，这是第一次握手；接收端收到请求并且允许连接的话，就会发送一个SYN=1，ACK=1标志的数据包给发送端，告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；最后，发送端发送一个SYN=0，ACK=1的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之后，一个TCP连接建立，开始通讯。发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的TCP数据包后，连接将被断开。

应该请计算机高手来翻

通过keepalive地址登陆mc-lag的另一台交换机的方法如下：1、用一根RJ45转RS232转接线（厂家提供）和一根RS232转USB转接线（自备）组合，将交换机的console口连接到电脑串口。2、打开电脑。在PC上安装终端仿真软件。可以在PC上使用Windows2000的内置超级终端。要是没有内置终端仿真软件，准备SecureCRT、开源Putty等终端仿真软件。3、给交换机上电，打开安装好的登录软件（这里以软件Putty为例），选择串口登录方式，端口由设备管理器决定。波特率1是15200，停止位是1。

好像是保持在线升级的意思..不过我不肯定

这种问题你应该果断MSDN！作用一撇：KeepAlive 方法的目的是确保对对象的引用存在，该对象有被垃圾回收器过早回收的危险。..