v*********u 发帖数: 58 | 1 大家都知道在apache的初始配置里面,KeepAlive timeout的default value是5秒(老版
本是15秒)。如果要修改这个值,需要restart apache,然后修改的值才能生效。想问
一下大牛,有没有办法实时地给这个value赋值,但不需要重启apache.
万分感谢,请大牛不吝赐教! |
|
k****i 发帖数: 1072 | 2 keepalive, 0 idle time setting, pre-compile deployment, pre-fetch caching,
load balancing and hire me.
load |
|
w*****r 发帖数: 89 | 3 哈哈,你还记得挺清楚
还有就是把不同作用的traffic分开
html带flash image的网页和xml feed分开,不同的apache设置
降低apache的keepalive,默认300减到10
fine tune apache,
取消ns1, ns2,建立ns vip,降低ns server load
清理mess
原来俺们一团糟,把switch当hub用
不同的subnet混合,现在严格subnet,一个vlan就一个subnet
(cisco也只允许这样,之前dell的switch竟然不管,哈哈)
抛弃capped bandwidth from datacenter, 直接连isp
严格user管理,控制root (之前大家都用root, haha )
加强health check from server Iron
引入global loadbalance between data center
还有就是authorative ns做成非recursive的,减少被别人abuse
还有就是改进server farm 的synchronization,消灭不同的slave |
|
c*a 发帖数: 806 | 4 two possibilities
1) wide open on this port (then you may use putty to ssh out, which
potentially open all possibilities)
2) I've seen some weird fws check addl keepalives, keep shutting down the
tunnel, still puzzled.
abcd |
|
z**r 发帖数: 17771 | 5 don't know what is greenbow, but your issues smells like a tcp or udp
keepalive timeout issue |
|
w***s 发帖数: 321 | 6 就是个过程,当初alcatel的7770上这么多路由也有毛病,因为BGP收敛的时候CPU 100%
,keepalive都丢了,必须将hold-time加到600秒以上才可以。 |
|
a***n 发帖数: 262 | 7 VPN idle timeout value = 15 minitues on your VPN headend.
You can check remote desktop keepalive
. |
|
a***n 发帖数: 262 | 8 headend is your vpn server. Ask your sysadmins whether they can change
the idle timeout for your VPN profile.
keepalive is like heartbeat which could be used for detecting lost remote endpoint or preventing middle security device timeout your session due to no active traffic observed.
I knew SSH could be configured to keep the session up, but not sure about the remote desktop. |
|
x*********n 发帖数: 28013 | 9 interface Tunnel2
description **** TO San Diego, CA ****
ip address 10.192.168.17 255.255.255.252
ip pim sparse-dense-mode
keepalive 30 3
tunnel source 12.249.246.42
tunnel destination 208.46.190.230
tunnel key 2247179619
source就是WAN出口的interface的IP,destination是remote site的WAN IP,它们建立
tunnel 2,就是这个IP address不太明白,
这个ip addres 10.192.168.17 255.255.255.252是tunnel的ID么?
多谢。 |
|
l***y 发帖数: 791 | 10 Restarting peer will only send session reset for BGP ONLY when RP switchover
is by command; if active RP goes dead, no packet will be transmitted from
the restarting peer, not even tcp keepalives; the standby RP takes over and
initiates a new session with each peer. In this case the receiving peers
ideally have gone into HA helper mode will not flush the pfx right then but
completes the HA process with the restarting peer.
Depending on how soon the standby RP takes over and initiates the new
ses... 阅读全帖 |
|
u*****e 发帖数: 47 | 11 深夜上来向大家再请教一个问题:
我有一个路由器,上面两个ISP线路,也就是两个BGP sessions. 我的目的是在其中一
根线出问题,比如down了,我的数据流能以最短的时间,切换到另外一根线上。丢包能
越少越好。
起初我配置了两根线,两个BGP,就是希望,在一根线出问题时,另外一根线可以take
over所有的数据。实际上也是这样,但是我发现了一个问题:这个切换时间好像比较长
,不能满足我们的要求。
一下是我的分析,请大家给点意见:
当本地路由器60秒内没有收到keepalive 包(比如对方的路由器down了),他就要再等
一个holdertimer 180秒的时间,然后,BGP session 就被认为彻底的down了,TCP链接
也被关闭了。这个时候,路由器才会删除原来的路由,然后接受从另外一根线来的路由
。(两根线都是通告全网路由。)我感觉这个过程应该是对的把。可是从链路down开始
,到本地路由器完成路由表的更新,好像至少240秒。。。这个是不是太长了?
我现在想到的方法是在确认uplink down时,直接进行 BGP 软清。 但是还没有做过测
试,不知道,这样会不会... 阅读全帖 |
|
a9 发帖数: 21638 | 12 我说说我的吧:
80口开的apache,允许connect到443
openvpn开443,侦听127.0.0.1
服务器端:
mode server
tls-server
ifconfig 172.19.0.1 255.255.0.0
ifconfig-pool 172.19.0.100 172.19.254.254 255.255.0.0
proto tcp-server
port 443
local 127.0.0.1
dev tap
comp-lzo
keepalive 15 60
verb 3
ca /etc/openvpn/ca.crt
dh /etc/openvpn/dh.pem
cert /etc/openvpn/tmobilewall.crt
key /etc/openvpn/tmobilewall.key
status-version 2
status status
tmp-dir /dev/shm
auth-user-pass-verify /etc/openvpn/tmobilewall_auth.php via-file
username-as-common-... 阅读全帖 |
|
c*******y 发帖数: 3529 | 13 2. 我的服务器配置文件(your_vpn.conf)是:
#dockstar内网ip, 可以不填
;local a.b.c.d
# VPN 端口,53?玩tmo的同学,你懂得
port 53
# TCP or UDP。缺省是UDP,我觉得TCP可靠点
proto tcp
dev tun
ca keys/your_vpn_ca/ca.crt
cert keys/your_vpn_ca/your_vpn_server.crt
#openvpn是加密传送的,这个是用于解密的key,只存放在服务器端
key keys/your_vpn_ca/your_vpn_server.key
dh keys/cset_vpn_ca/dh1024.pem
#虚拟的网段
server 10.8.0.0 255.255.255.0
# ipp.txt存放连接信息,当client断线之后,用于恢复到之前的连接结构
ifconfig-pool-persist ipp.txt
#把路由信息push到client上面,
#你的路由器的内网网段
push "route 192.168.1.0 255.255.255.0... 阅读全帖 |
|
c*******y 发帖数: 3529 | 14 3. your_vpn_client.conf 改成:
client
proto tcp
dev tun
ca ca.crt
dh dh1024.pem
cert your_vpn_client.crt
key your_vpn_client.key
remote xxxx.xxxx.com 53
;cipher AES-256-CBC
verb 3
mute 20
keepalive 10 120
comp-lzo
persist-key
persist-tun
float
resolv-retry infinite
nobind
ns-cert-type server
redirect-gateway def1 |
|
f**y 发帖数: 138 | 15 When you construct a TCP RST packet, you may have to match the seq, ack as
well as src/dst IP and port with the existing TCP session, otherwise the
server may ignore the packet.
Regarding the time out, the linux system default TCP keepalive is 2 hours.
The application can not rely on 'select' or 'recv' to determine if the other
end of the socket is closed. It is simply too long. On the other hand, the
application can send packets periodically and catch the SIG_PIPE signal to
forcefully determine |
|
z**r 发帖数: 17771 | 16 established就要看tcp keepalive,这个通常时间都很长,2个小时左右。。。你总不
能改成2分钟吧,那样差别就太大了,难保其他程序不出问题。
tcp |
|
k****f 发帖数: 3794 | 17 目的:
破解只有80/443端口开放的网络的限制,使得其他的端口的程序能够正常使用,比如
ssh的22端口,ftp端口,mitbbs的web radio:8000端口。
硬件要求:
1。能够刷tomato firmware的路由器
2。路由器用了dyndns注册了域名
3。路由器启动了openvpn server功能。
4。一个跑linux的笔记本
基本原理:
在路由器上启动vpn server服务,端口设在443上。
笔记本通过openvpn client,与路由器之间建立一个vpn安全连接,
所有的网络包都先转发到路由器上openvpn server。然后再上internet
因此,笔记本上能够用到的带宽,基本就是dsl路由器上传的带宽了。
一般dsl上传带宽就300-600kbps,不做大量下载,还够用。
vpn的认证方式有两种:static key和TLS,以下步骤是TLS用的,static key应该更简
单的。
路由器上的步骤
1。路由器刷上tomatovpn http://tomatovpn.keithmoyer.com/,设置好dyndns,在port forwar... 阅读全帖 |
|
z**r 发帖数: 17771 | 18 no, most likely his windows client keeps sending keepalives to keep the
session up |
|
v*****r 发帖数: 1119 | 19 Just curious. What fault-tolerance you used on the server side?
An idle client vs a dead client, will the server behave the same?
Are you using tcp keepalive function or have your own logic?
prepare
established
onto |
|
w******p 发帖数: 166 | 20 set tcp keepalive, programmably or system setup |
|
L***s 发帖数: 1148 | 21
Client:
Enable TCP keepalives (SO_KEEPALIVE)
set the interval
Server:
vi /etc/ssh/sshd_config
TCPKeepAlive yes |
|
d****r 发帖数: 300 | 22 如果是指enable http keepalive的话,可能默认server to server只有一个或very
limited number的http connection.
这事情总算向postive方向靠近一些,大家努力,说不准还能化敌为友。 |
|
|
a***t 发帖数: 39 | 24
也不断地向server
差
The short answer is: usually not.
The longers answer is more complicated:
1. when your computer is receiving the information from the server, it also
sends the information back to server, like acknowledgement packets. TCP
traffic is always bi-directional.
2. It depends on the specific VPN. Some kind of VPN gateways like Nortel sends
the keepalive packet once every minute (tuneable) to make sure the client is
still alive, if not, it will tear down the connection.
3. It also depends |
|
A**d 发帖数: 13310 | 25
把整天在足球版喷粪的艺轮们,包括阁下在内都算进来远远不止21次了。
两任版务都胡整,纵容各位艺轮整天喷粪,这封人就是个兑子游戏了。
您老黄瓜刷绿漆装什么嫩啊,就meshwork/Aroid/keepalive那一位就差不多了,
我刚数了一下,那一位全年22次。就这22次还有若干次是私信死皮赖脸
指天发誓再也不当stalker跪求前版主sioc高抬贵手没封it,当然了,最后
你们的艺轮同道还是狗改不了吃屎。麻烦您以后不要再舔众艺轮的腚装文明人了 |
|
A**d 发帖数: 13310 | 26 懒得举sioc包庇你meshwork/Aroid/keepalive的证据,哪凉快哪呆着去。
投诉人是谁跟sioc接到举报还不管“神经病”的帖子这种赤裸裸的包庇行为没关系。 |
|
k**********s 发帖数: 6409 | 27 ATA必须开启keepalive,最好用tcp,不过xfinity wifi过一会还是会不管三七二十一
把端口关掉的,电话就打不进来了,所以可能的话让ATA每分钟就注册一次。 |
|
r******n 发帖数: 459 | 28 【 以下文字转载自 Automobile 讨论区 】
发信人: foobar (斧 把), 信区: Automobile
标 题: 车冻傻了?
发信站: BBS 未名空间站 (Wed Feb 7 19:15:51 2007)
93 Taurus 3.0L, 打不着了。电池正常.不crank.不start.
用code reader读了一下,长长一串:
116:Coolant Temperature Higher or Lower than Expected
114:Air Charge Temperature Sensor Higher or Lower than Expected
636:Transmission Oil Temperature Higher or Lower than Expected
558:EGR Valve Regulator Solenoid Circuit Fault
624:Electronic Pressure Control Solenoid Circuit Fault
512:KAM(KeepAlive Memory) Test Failure |
|
C**o 发帖数: 10373 | 29 【 以下文字转载自 Soccer 讨论区 】
发信人: predator (奥森※东西永隔如参商), 信区: Soccer
标 题: Re: 是否可以定论艺术足球已死了
发信站: BBS 未名空间站 (Fri May 2 18:54:38 2014, 美东)
丧心病狂了,您这obsessed程度跟艺轮同修下水道老鼠meshwork/keepalive/Aroid差不
多了 |
|