存档

文章标签 ‘美国vps’

nginx通过CORS实现跨域

2020年4月10日 没有评论

1.CORS是一个W3C标准,全称是跨域资源共享(Cross-origin resource sharing)。它允许浏览器向跨源服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制。
当前几乎所有的浏览器(Internet Explorer 8+, Firefox 3.5+, Safari 4+和 Chrome 3+)都可通过名为跨域资源共享(Cross-Origin Resource Sharing)的协议支持AJAX跨域调用。
Chrome,Firefox,Opera,Safari都使用的是XMLHttpRequest2对象,IE使用XDomainRequest。
简单来说就是跨域的目标服务器要返回一系列的Headers,通过这些Headers来控制是否同意跨域。跨域资源共享(CORS)也是未来的跨域问题的标准解决方案。
CORS提供如下Headers,Request包和Response包中都有一部分。

2.HTTP Response Header

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Expose-Headers
Access-Control-Max-Age
HTTP Request Header

Access-Control-Request-Method
Access-Control-Request-Headers
其中最敏感的就是Access-Control-Allow-Origin这个Header, 它是W3C标准里用来检查该跨域请求是否可以被通过。(Access Control Check)。如果需要跨域,解决方法就是在资源的头中加入Access-Control-Allow-Origin 指定你授权的域。
启用CORS请求

假设您的应用已经在example.com上了,而您想要从www.example2.com提取数据。一般情况下,如果您尝试进行这种类型的AJAX调用,请求将会失败,而浏览器将会出现源不匹配的错误。利用CORS后只需www.example2.com 服务端添加一个HTTP Response头,就可以允许来自example.com的请求。

将Access-Control-Allow-Origin添加到某网站下或整个域中的单个资源

Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Credentials: true (可选)
将允许任何域向您提交请求

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true (可选)
3.提交跨域请求

如果服务器端已启用了CORS,那么提交跨域请求就和普通的XMLHttpRequest请求没什么区别。例如现在example.com可以向www.example2.com提交请求。

var xhr = new XMLHttpRequest();
// xhr.withCredentials = true; //如果需要Cookie等
xhr.open(‘GET’, ‘http://www.example2.com/hello.json’);
xhr.onload = function(e) {
var data = JSON.parse(this.response);

}
xhr.send();选)
对于简单请求,如GET,只需要在HTTP Response后添加Access-Control-Allow-Origin。
对于非简单请求,比如POST、PUT、DELETE等,浏览器会分两次应答。第一次preflight(method: OPTIONS),主要验证来源是否合法,并返回允许的Header等。第二次才是真正的HTTP应答。所以服务器必须处理OPTIONS应答。
流程如下

首先查看http头部有无origin字段;
如果没有,或者不允许,直接当成普通请求处理,结束;
如果有并且是允许的,那么再看是否是preflight(method=OPTIONS);
如果是preflight,就返回Allow-Headers、Allow-Methods等,内容为空;
如果不是preflight,就返回Allow-Origin、Allow-Credentials等,并返回正常内容。
用伪代码表示

location /pub/(.+) {
if ($http_origin ~ <允许的域(正则匹配)>) {
add_header ‘Access-Control-Allow-Origin’ “$http_origin”;
add_header ‘Access-Control-Allow-Credentials’ “true”;
if ($request_method = “OPTIONS”) {
add_header ‘Access-Control-Max-Age’ 86400;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS, DELETE’;
add_header ‘Access-Control-Allow-Headers’ ‘reqid, nid, host, x-real-ip, x-forwarded-ip, event-type, event-id, accept, content-type’;
add_header ‘Content-Length’ 0;
add_header ‘Content-Type’ ‘text/plain, charset=utf-8′;
return 204;
}
}
# 正常nginx配置
……
}
Nginx配置实例
实例一:允许example.com的应用在www.example2.com上跨域提取数据

在nginx.conf里找到server项,并在里面添加如下配置

location /{

add_header ‘Access-Control-Allow-Origin’ ‘http://example.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Headers’ ‘Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Requested-With’;
add_header ‘Access-Control-Allow-Methods’ ‘GET,POST,OPTIONS’;

}
如果需要允许来自任何域的访问,可以这样配置

add_header Access-Control-Allow-Origin *;
注释如下

第一条指令:授权从example.com的请求(必需)

第二条指令:当该标志为真时,响应于该请求是否可以被暴露(可选)

第三条指令:允许脚本访问的返回头(可选)

第四条指令:指定请求的方法,可以是GET, POST, OPTIONS, PUT, DELETE等(可选)

重启Nginx

$ service nginx reload
测试跨域请求

$ curl -I -X OPTIONS -H “Origin: http://example.com” http://www.example2.com
成功时,响应头是如下所示

HTTP/1.1 200 OK
Server: nginx
Access-Control-Allow-Origin: example.com
实例二:Nginx允许多个域名跨域访问

由于Access-Control-Allow-Origin参数只允许配置单个域名或者 * ,当我们需要允许多个域名跨域访问时可以用以下几种方法来实现。

方法一
如需要允许用户请求来自www.example.com、m.example.com、wap.example.com访问www.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在nginx.conf里面,找到server项,并在里面添加如下配置

map $http_origin $corsHost {
default 0;
“~http://www.example.com” http://www.example.com;
“~http://m.example.com” http://m.example.com;
“~http://wap.example.com” http://wap.example.com;
}

server
{
listen 80;
server_name www.example2.com;
root /usr/share/nginx/html;
location /
{
add_header Access-Control-Allow-Origin $corsHost;
}
}
方法二
如需要允许用户请求来自localhost、www.example.com或m.example.com的请求访问xxx.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在Nginx配置文件中xxx.example2.com域名的location /下配置以下内容

set $cors ”;
if ($http_origin ~* ‘https?://(localhost|www\.example\.com|m\.example\.com)’) {
set $cors ‘true’;
}

if ($cors = ‘true’) {
add_header ‘Access-Control-Allow-Origin’ “$http_origin”;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘Accept,Authorization,Cache-Control,Content-Type,DNT,If-Modified-Since,Keep-Alive,Origin,User-Agent,X-Mx-ReqToken,X-Requested-With’;
}

if ($request_method = ‘OPTIONS’) {
return 204;
}
方法三
如需要允许用户请求来自*.example.com访问xxx.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在Nginx配置文件中xxx.example2.com域名的location /下配置以下内容

if ( $http_origin ~ http://(.*).example.com){
set $allow_url $http_origin;
}
#CORS(Cross Orign Resource-Sharing)跨域控制配置
#是否允许请求带有验证信息
add_header Access-Control-Allow-Credentials true;
#允许跨域访问的域名,可以是一个域的列表,也可以是通配符*
add_header Access-Control-Allow-Origin $allow_url;
#允许脚本访问的返回头
add_header Access-Control-Allow-Headers ‘x-requested-with,content-type,Cache-Control,Pragma,Date,x-timestamp’;
#允许使用的请求方法,以逗号隔开
add_header Access-Control-Allow-Methods ‘POST,GET,OPTIONS,PUT,DELETE’;
#允许自定义的头部,以逗号隔开,大小写不敏感
add_header Access-Control-Expose-Headers ‘WWW-Authenticate,Server-Authorization’;
#P3P支持跨域cookie操作
add_header P3P ‘policyref=”/w3c/p3p.xml”, CP=”NOI DSP PSAa OUR BUS IND ONL UNI COM NAV INT LOC”‘;
方法四
如需要允许用户请求来自xxx1.example.com或xxx1.example1.com访问xxx.example2.com域名时,返回头Access-Control-Allow-Origin,具体配置如下

在Nginx配置文件中xxx.example2.com域名的location /下配置以下内容

location / {

if ( $http_origin ~ .*.(example|example1).com ) {
add_header Access-Control-Allow-Origin $http_origin;
}
}
实例三:Nginx跨域配置并支持DELETE,PUT请求

默认Access-Control-Allow-Origin开启跨域请求只支持GET、HEAD、POST、OPTIONS请求,使用DELETE发起跨域请求时,浏览器出于安全考虑会先发起OPTIONS请求,服务器端接收到的请求方式就变成了OPTIONS,所以引起了服务器的405 Method Not Allowed。

解决方法

首先要对OPTIONS请求进行处理

if ($request_method = ‘OPTIONS’) {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
#其他头部信息配置,省略…
return 204;
}
当请求方式为OPTIONS时设置Allow的响应头,重新处理这次请求。这样发出请求时第一次是OPTIONS请求,第二次才是DELETE请求。

# 完整配置参考
# 将配置文件的放到对应的server {}里

add_header Access-Control-Allow-Origin *;

location / {
if ($request_method = ‘OPTIONS’) {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
return 204;
}
index index.php;
try_files $uri @rewriteapp;
}
实例四:更多配置示例

示例一

The following Nginx configuration enables CORS, with support for preflight requests.

#
# Wide-open CORS config for nginx
#
location / {
if ($request_method = ‘OPTIONS’) {
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
#
# Custom headers and headers various browsers *should* be OK with but aren’t
#
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type’;
#
# Tell client that this pre-flight info is valid for 20 days
#
add_header ‘Access-Control-Max-Age’ 1728000;
add_header ‘Content-Type’ ‘text/plain charset=UTF-8′;
add_header ‘Content-Length’ 0;
return 204;
}
if ($request_method = ‘POST’) {
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type’;
}
if ($request_method = ‘GET’) {
add_header ‘Access-Control-Allow-Origin’ ‘*’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type’;
}
}
示例二

if ($request_method = ‘OPTIONS’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://docs.domain.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, PATCH, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token’;
return 204;
}
if ($request_method = ‘POST’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://docs.domain.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, PATCH, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token’;
}
if ($request_method = ‘GET’) {
add_header ‘Access-Control-Allow-Origin’ ‘https://docs.domain.com’;
add_header ‘Access-Control-Allow-Credentials’ ‘true’;
add_header ‘Access-Control-Allow-Methods’ ‘GET, POST, PUT, DELETE, PATCH, OPTIONS’;
add_header ‘Access-Control-Allow-Headers’ ‘DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization,token’;
}
其它技巧
Apache中启用CORS

在httpd配置或.htaccess文件中添加如下语句

SetEnvIf Origin “^(.*\.example\.com)$” ORIGIN_SUB_DOMAIN=$1
Header set Access-Control-Allow-Origin “%{ORIGIN_SUB_DOMAIN}e” env=ORIGIN_SUB_DOMAIN
PHP中启用CORS

通过在服务端设置Access-Control-Allow-Origin响应头

允许所有来源访问

header("Access-Control-Allow-Origin: *");
?>
允许来自特定源的访问

header('Access-Control-Allow-Origin: '.$_SERVER['HTTP_ORIGIN']);
?>
配置多个访问源
由于浏览器实现只支持了单个origin、*、null,如果要配置多个访问源,可以在代码中处理如下

$allowed_origins = array(
"http://www.example.com" ,
"http://app.example.com" ,
"http://cms.example.com" ,
);
if (in_array($_SERVER['HTTP_ORIGIN'], $allowed_origins)){
@header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']);
}
?>
HTML中启用CORS

vzquota : (error) Quota on syscall for id 189: Device or resource busy的解决方法(转)

2018年6月6日 没有评论

开启openvz虚拟机的时候总也失败,命令行启动提示错误如下:
vzctl start 189
Starting container …
vzquota : (error) Quota on syscall for id 156: Device or resource busy
vzquota : (error) Possible reasons:
vzquota : (error) – Container’s root is already mounted
vzquota : (error) – there are opened files inside Container’s private area
vzquota : (error) – your current working directory is inside Container’s
vzquota : (error) private area
vzquota : (error) Currently used file(s):
/vz/private/189/var/log
vzquota on failed [3]
————————————————–
最终解决方法如下:
[root@lxy conf]# lsof 2> /dev/null | egrep ‘/vz/root/189|/vz/private/189′
bash 786 root cwd DIR 8,3 4096 8192388 /vz/private/189/fs/root
[root@lxy ~]# ps auxfww |grep 786
root 786 0.0 0.0 2348 1344 pts/0 Ss+ 09:22 0:00 | \_ -bash
[root@lxy ~]# kill -s 9 786
[root@lxy ~]# vzctl start 189
Starting VE …
VE is mounted
Setup slm memory limit
Setup slm subgroup (default)
Setting devperms 20002 dev 0x7d00
Setup ioprio: 4
Adding port redirection to VE(1): 4643 8443
Adding IP address(es) to pool: 203.191.150.111
arpsend: 203.191.150.111 is detected on another computer : 00:13:d3:bf:1e:96
vz-net_add WARNING: arpsend -c 1 -w 1 -D -e 203.191.150.111 eth0 FAILED
Adding IP address(es): 203.191.150.111
arpsend: 203.191.150.111 is detected on another computer : 00:13:d3:bf:1e:96
vz-net_add WARNING: arpsend -c 1 -w 1 -D -e 203.191.150.111 eth0 FAILED
Hostname for VE set: localhost.localdomain
File resolv.conf was modified
VE start in progress…

Linux/BSD下修正磁盘的顺序编号(/dev/sdbX)(转)

2018年6月2日 没有评论

假设你现在新建一个分区在磁盘后面的区块,它的编号就应该是/dev/sdb1(假定是Primary分区,或者/dev/sda1什么的取决于第几个磁盘),好了,前面留下来的空白区域再建一个分区,结果区块前面的是/dev/sdb2,后面的反倒是/dev/sdb1了!!!强迫症患者不能忍!!!就像Windows下C、D、E、F盘错位变成了D、C、E、F一样不能忍啊!

解决办法很easy,借助fdisk这个强大的命令,各个BSD/Linux发行版都有的放心。以Fedora为例,终端下执行:

su -c ‘fdisk /dev/sdb’
x
f
w

x、f、w是进入fdisk后执行的指令,x是进入专家模式,f是修正磁盘序号,w写入分区信息并退出fdisk,别弄错了。最好不要在已经挂载的磁盘上执行,所以如果你要这样修改你的机器硬盘的话,建议从LiveCD启动来修正。

好了,强迫症患者心情舒畅了,/dev/sdb1和/dev/sdb2都领到了该有的位置。

P.S. 正因为这个序号容易变动,所以GRUB/GRUB2的配置文件中的分区强烈建议使用UUID而不是/dev/sdbX来表征!

CentOS下一网卡多IP设置

2016年11月27日 没有评论

方法1:少量IP手动绑定(这里以绑定IP到eth0为例,其它网卡的话修改相应的文件名即可)
1.复制ifcfg-eth0的网卡配置文件并改名为ifcfg-eth0:0

[root@akinlau /]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/sysconfig/network-scripts/ifcfg-eth0:0

2.编辑ifcfg-eth0:0文件

[root@akinlau /]# vim /etc/sysconfig/network-scripts/ifcfg-eth0:0

DEVICE=”eth0:0″ //这里修改为eth0:0跟文件名保持一致
BOOTPROTO=”static” //协议为静态,用none也可以
HWADDR=”00:0C:29:6F:62:A7″ //MAC地址
ONBOOT=”yes” //开机启用此网卡
IPADDR=192.168.1.3 //新绑定的IP
NETMASK=255.255.255.0 //子网掩码
GATEWAY=192.168.1.1 //网关

修改好后保存退出,然后启用这张网卡

[root@akinlau /]# ifup eth0:0

注:有人在这一步喜欢用service network restart重启网络,其实这是没必要的,只需要启用这张网卡就可以了

然后再试ping 一下,如果能ping通的话,就可以了。

方法2:自动绑定一个IP段或多个IP段(同样这里以eth0为例,其它网卡的话修改相应的文件名即可)
1.新建ifcfg-eth0-range0文件(注意这里的文件名不要调换range的位置或写错单词,不然的话绑定的IP是不会生效的,如果你还有几段IP要绑定到eth0上的话,你可以再新建ifcfg-eth0-range1, ifcfg-eth0-range2等文件,不过这里要注意每个range文件中的定义的CLONENUM_START值不能重叠,不然的话会出问题。 )

[root@akinlau /]# /etc/sysconfig/network-scripts/ifcfg-eth0-range0

#写入以下内容

DEVICE=eth0 //绑定IP段的网卡名称
ONBOOT=yes //开机启用此网卡
BOOTPROTO=static //协议为静态
IPADDR_START=192.168.0.101 //网段的起始IP
IPADDR_END=192.168.0.120 //网段的截止IP
NETMASK=255.255.255.255 //子网掩码
CLONENUM_START=0 //这个数字是网卡别名的开始位置,比如这里的3是指eth0:0,并且会把IPADDR_START设置的IP192.168.0.101绑定到eth0:0上,以此类推
NO_ALIASROUTING=yes //这个参数的作用是数据包始终通过eth0进出,不走网卡别名(如eth0:0),设置这个参数可以加快路由的响应速度,所以强烈建议配置。

修改好后保存退出,然后重启网络:

[root@akinlau /]# service network restart

再测试一下,能不能ping就大功告成了。

远程密令临时开启ssh端口

2016年5月5日 没有评论

linux服务器,我们一般是通过ssh通道远程管理,这就需要我们开启ssh端口,如22。但开启端口有被暴力破解的风险,你会说可以设置复杂的密码或使用证书避免。就算破解不了密码,但openssh也可能会有漏洞,你会说可以更改ssh端口,但还是有可能被扫描出来。还有一种选择,我们可以只允许指定IP访问ssh,通过vpn登录管理服务器,但局限很明显,万一紧急情况vpn登录不上去了怎么办。(有条件的我们可以多设置几个指定ip访问,保险些。也推荐大家用这个方法,对我们做数据中心服务器提供商多设置几个ip允许访问当然没有什么问题,因为资源多。)资源少的可以有其他办法吗?答案是肯定的。

下面给出一种个人觉得比较满意的解决方案,即使用iptables的recent模块,通过密令临时开启ssh端口。当然,密令需要保管好,防止外泄。(其实这种办法个人来讲,并不是非常推荐。因为人长时间不连服务器容易健忘密令。哈)

1、iptables规则设定

1
2
3
4
#指定78字节的icmp数据包(包含IP头部20字节,ICMP头部8字节)通过被加入openssh列表。
iptables -A INPUT -p icmp --icmp-type 8 -m length --length 78 -m recent --set --name sshopen --rsource -j ACCEPT
#检查openssh列表是否存在你的来源IP,如果存在,即从第一次使用密令开始15秒钟内开启ssh端口22,超过15秒端口自动关闭,不再允许新连接,已连接的不会断开。
iptables -A INPUT -p tcp --dport 22 --syn -m recent --rcheck --seconds 15 --name sshopen --rsource -j ACCEPT

2、临时开启ssh端口密令

1
2
linux下:ping -s 50 host
windows下:ping -l 50 host

3、示例一个目前服务器上使用的iptables规则

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 123 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -m length --length 50 -m recent --set --name sshopen --rsource -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 --syn -m recent --rcheck --seconds 15 --name sshopen --rsource -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443  -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

美国服务器丢包率比较高是什么原因分析

2015年8月10日 没有评论

美国服务器虽然与中国相隔比较远,但是美国服务器通常都是通过海底光缆与中国电信和中国网通直接相连,具有很高的稳定性,通常访问ping值在180ms到220ms之间,并且丢包率维持在5%以下,如美国服务器出现丢包率比较高时,可能是受到外界干扰因素而造成的,下面我们就详细分析一下美国服务器丢包率比较高是什么原因。

美国服务器丢包率比较高是什么原因
  一.人为因素的干扰
  由于美国服务器是与电信或者网通直接相连,因而在宽带国际出口处可能会受到人为性的干扰而导致美国服务器丢包率非常高,如果是这种情况,几乎所有美国服务器都会出现高丢包率的现象。

  如何检测是否受人为因素干扰
  1.通过咨询其他美国服务器租用商或许寻找相关的新闻,了解一下是否其他服务商的美国服务器是a否也出现高丢包率的现象。

  2.美国服务器出现高丢包率时,可能也会出现ping值不正常的情况,你可以到一些例如17ce等常用测速网站,用全球的服务器来对你的美国服务器IP进行测速,如果除开中国节点外,其他地区的ping值都正常,就说明宽带国际出口受到干扰。

  二.服务器受到攻击
  如果服务器被高流量型的DDoS攻击时,服务器资源了,带宽资源都会被占用而出现高频率丢包现象。通产高防服务器不会出现这种情况,因为高防服务器机房具有充足的带宽资源,并且能够对攻击流量进行有效识别,如果流量的攻击超过机房的保护范围时,美国服务器服务商通知用户并做出高防处理。

  三.共享带宽可能会出现这种情况
  如果用户选择的是共享代理的美国服务器,在网络带宽出现峰值时,就可能会出现高丢包率的现象,因而在租用美国服务器时尽量选择独享带宽,而共享带宽就必须要根据用户对网络业务的带宽需求来定。

  以上就是美国服务器丢包率比较高是什么原因的相关介绍,这几点是美国服务器出现高丢包率的最常见因素,当然监测出现高丢包率还与本地电脑是否中毒,监测时是否在下载东西等有关因而我们需要从多个方面进行考虑,然后在找服务商协助解决。

Windows下的PHP安装文件线程安全和非线程安全的区别

2014年11月25日 没有评论

从2000年10月20日发布的第一个Windows版的PHP3.0.17开始的都是线程安全的版本,这是由于与Linux/Unix系统是采用 多进程的工作方式不同的是Windows系统是采用多线程的工作方式。如果在IIS下以CGI方式运行PHP会非常慢,这是由于CGI模式是建立在多进程 的基础之上的,而非多线程。一般我们会把PHP配置成以ISAPI的方式来运行,ISAPI是多线程的方式,这样就快多了。但存在一个问题,很多常用的 PHP扩展是以Linux/Unix的多进程思想来开发的,这些扩展在ISAPI的方式运行时就会出错搞垮IIS。而用线程安全版本的话顶多只是搞跨某个 线程,而不会影响到整个IIS的安全。

当然在IIS下CGI模式才是 PHP运行的最安全方式,但CGI模式对于每个HTTP请求都需要重新加载和卸载整个PHP环境,其消耗是巨大的。为了兼顾IIS下PHP的效率和安全, 有人给出了FastCGI的解决方案。FastCGI可以让PHP的进程重复利用而不是每一个新的请求就重开一个进程。同时FastCGI也可以允许几个 进程同时执行。这样既解决了CGI进程模式消耗太大的问题,又利用上了CGI进程模式不存在线程安全问题的优势。

因此,如果是使用ISAPI的方式来运行PHP就必须用Thread Safe(线程安全)的版本;而用FastCGI模式运行PHP的话就没有必要用线程安全检查了,用None Thread Safe(NTS,非线程安全)的版本能够更好的提高效率。
因此,如果是使用ISAPI的方式来运行PHP就必须用Thread Safe(线程安全)的版本;而用FastCGI模式运行PHP的话就没有必要用线程安全检查了,用None Thread Safe(NTS,非线程安全)的版本能够更好的提高效率。
附:德问相关问题摘录
下载PHP安装文件时,我看到有两种不同的二进制文件,像是非线程安全(Non Thread Safe)和线程安全(Thread Safe),比如该页面所列:http://windows.php.net/download/。这个是什么意思,之间有什么区别?

这个主要是针对web server 而言,在windows环境下,如果你使用的web server 是apchae 或者 iis 7以下版本,则应该选择线程安全的安装文件,而如果你使用Fast-cgi模式时,可以选择非线程安全,因为 web sever 本身能保证线程安全。
当然还有二进制文件编译时所使用的编译器:vc9 (vs系列) vc6(gcc)

如楼上所言,是针对web server的,部分web server在处理应用请求的时候是用多线程而非多进程的方式处理,线程方式因为涉及到共享寄存器和内存,所以很容易出错,这个时候程序就需要花一些额外的经历去处理寄存器中的数据一致性,即保证线程安全。
所以是否采用线程安全主要看你的web server所采用的PHP请求处理方式,如果是多线程处理,那么请选择线程安全的,否则选择非线程安全的,如楼上所说Fast-cgi方式可选择非线程安全的

iis7 下动态压缩(gzip压缩)的压缩率更改办法

2014年11月11日 没有评论

iis7下默认压缩率是静态压缩: 0, 动态压缩: 7

一般认为: 压缩率9是性价比最好的压缩率

怎么改变默认的压缩率呢? 运行以下命令即可:

%windir%\system32\inetsrv\appcmd.exe set config -section:httpCompression -[name='gzip'].dynamicCompressionLevel:9
%windir%\system32\inetsrv\appcmd.exe set config -section:httpCompression -[name='gzip'].staticCompressionLevel:9

命令运行后, 必须重启IIS, 新的压缩率才开始生效

MySQL 配置优化

2014年10月25日 没有评论

安装MySQL后,配置文件my.cnf在 /MySQL安装目录/share/mysql目录中,该目录中还包含多个配置文件可供参考,有my-large.cnf ,my-huge.cnf, my-medium.cnf,my-small.cnf,分别对应大中小型数据库应用的配置。win环境下即存在于MySQL安装目录中的.ini文件。

下面列出了对性能优化影响较大的主要变量,主要分为连接请求的变量和缓冲区变量。

1. 连接请求的变量:

1) max_connections
MySQL的最大连接数,增加该值增加mysqld 要求的文件描述符的数量。如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于MySQL会为每个连接提供连接缓冲区,就会开销越多的内存,所以要适当调整该值,不能盲目提高设值。

数值过小会经常出现ERROR 1040: Too many connections错误,可以过’conn%’通配符查看当前状态的连接数量,以定夺该值的大小。

show variables like ‘max_connections’ 最大连接数

show status like ‘max_used_connections’响应的连接数

如下:

mysql> show variables like ‘max_connections‘;

+———————–+——-+

| Variable_name | Value |

+———————–+——-+

| max_connections | 256  |

+———————–+——-+

mysql> show status like ‘max%connections‘;

+———————–+——-+

| Variable_name  | Value |

+—————————-+——-+

| max_used_connections | 256|

+—————————-+——-+

max_used_connections / max_connections * 100% (理想值≈ 85%)

如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了,低于10%则设置过大。

2) back_log
MySQL能暂存的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用。如果MySQL的连接数据达到max_connections时,新来的请求将会被存在堆栈中,以等待某一连接释放资源,该堆栈的数量即back_log,如果等待连接的数量超过back_log,将不被授予连接资源。

back_log值指出在MySQL暂时停止回答新请求之前的短时间内有多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接,你需要增加它,换句话说,这值对到来的TCP/IP连接的侦听队列的大小。

当观察你主机进程列表(mysql> show full processlist),发现大量264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL 的待连接进程时,就要加大back_log 的值了。

默认数值是50,可调优为128,对于Linux系统设置范围为小于512的整数。

3) interactive_timeout
一个交互连接在被服务器在关闭前等待行动的秒数。一个交互的客户被定义为对mysql_real_connect()使用CLIENT_INTERACTIVE 选项的客户。

默认数值是28800,可调优为7200。

2. 缓冲区变量

全局缓冲:

4) key_buffer_size
key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。

key_buffer_size只对MyISAM表起作用。即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。可以使用检查状态值created_tmp_disk_tables得知详情。

举例如下:

mysql> show variables like ‘key_buffer_size‘;

+——————-+————+

| Variable_name | Value |

+———————+————+

| key_buffer_size | 536870912 |

+———— ———-+————+

key_buffer_size为512MB,我们再看一下key_buffer_size的使用情况:

mysql> show global status like ‘key_read%‘;

+————————+————-+

| Variable_name  | Value |

+————————+————-+

| Key_read_requests| 27813678764 |

| Key_reads   | 6798830 |

+————————+————-+

一共有27813678764个索引读取请求,有6798830个请求在内存中没有找到直接从硬盘读取索引,计算索引未命中缓存的概率:

key_cache_miss_rate =Key_reads / Key_read_requests * 100%,设置在1/1000左右较好

默认配置数值是8388600(8M),主机有4GB内存,可以调优值为268435456(256MB)。

5) query_cache_size
使用查询缓冲,MySQL将查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。

通过检查状态值Qcache_*,可以知道query_cache_size设置是否合理(上述状态值可以使用SHOW STATUS LIKE ‘Qcache%’获得)。如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况,如果Qcache_hits的值也非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。

与查询缓冲有关的参数还有query_cache_type、query_cache_limit、query_cache_min_res_unit。

query_cache_type指定是否使用查询缓冲,可以设置为0、1、2,该变量是SESSION级的变量。

query_cache_limit指定单个查询能够使用的缓冲区大小,缺省为1M。

query_cache_min_res_unit是在4.1版本以后引入的,它指定分配缓冲区空间的最小单位,缺省为4K。检查状态值Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多,这就表明查询结果都比较小,此时需要减小query_cache_min_res_unit。

举例如下:

mysql> show global status like ‘qcache%‘;

+——————————-+—————–+

| Variable_name | Value  |

+——————————-+—————–+

| Qcache_free_blocks  | 22756  |

| Qcache_free_memory  | 76764704 |

| Qcache_hits      | 213028692 |

| Qcache_inserts     | 208894227 |

| Qcache_lowmem_prunes | 4010916 |

| Qcache_not_cached | 13385031 |

| Qcache_queries_in_cache | 43560 |

| Qcache_total_blocks | 111212  |

+——————————-+—————–+

mysql> show variables like ‘query_cache%‘;

+————————————–+————–+

| Variable_name      | Value  |

+————————————–+———–+

| query_cache_limit      | 2097152 |

| query_cache_min_res_unit  | 4096   |

| query_cache_size      | 203423744 |

| query_cache_type      | ON  |

| query_cache_wlock_invalidate | OFF  |

+————————————–+—————+

查询缓存碎片率= Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是小数据量的话。

查询缓存利用率= (query_cache_size – Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小;查询缓存利用率在80%以上而且Qcache_lowmem_prunes > 50的话说明query_cache_size可能有点小,要不就是碎片太多。

查询缓存命中率= (Qcache_hits – Qcache_inserts) / Qcache_hits * 100%

示例服务器查询缓存碎片率=20.46%,查询缓存利用率=62.26%,查询缓存命中率=1.94%,命中率很差,可能写操作比较频繁吧,而且可能有些碎片。

每个连接的缓冲

6) record_buffer_size
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。

默认数值是131072(128K),可改为16773120 (16M)

7) read_rnd_buffer_size
随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时,MySQL会首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL会为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大。

一般可设置为16M

8) sort_buffer_size
每个需要进行排序的线程分配该大小的一个缓冲区。增加这值加速ORDER BY或GROUP BY操作。

默认数值是2097144(2M),可改为16777208 (16M)。

9) join_buffer_size
联合查询操作所能使用的缓冲区大小

record_buffer_size,read_rnd_buffer_size,sort_buffer_size,join_buffer_size为每个线程独占,也就是说,如果有100个线程连接,则占用为16M*100

10) table_cache
表高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的状态值Open_tables和Opened_tables,可以决定是否需要增加table_cache的值。如果你发现open_tables等于table_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW STATUS LIKE ‘Open%tables’获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。

1G内存机器,推荐值是128-256。内存在4GB左右的服务器该参数可设置为256M或384M。

11) max_heap_table_size
用户可以创建的内存表(memory table)的大小。这个值用来计算内存表的最大行数值。这个变量支持动态改变,即set @max_heap_table_size=#

这个变量和tmp_table_size一起限制了内部内存表的大小。如果某个内部heap(堆积)表大小超过tmp_table_size,MySQL可以根据需要自动将内存中的heap表改为基于硬盘的MyISAM表。

12) tmp_table_size
通过设置tmp_table_size选项来增加一张临时表的大小,例如做高级GROUP BY操作生成的临时表。如果调高该值,MySQL同时将增加heap表的大小,可达到提高联接查询速度的效果,建议尽量优化查询,要确保查询过程中生成的临时表在内存中,避免临时表过大导致生成基于硬盘的MyISAM表。

mysql> show global status like ‘created_tmp%‘;

+——————————–+———+

| Variable_name   | Value |

+———————————-+———+

| Created_tmp_disk_tables | 21197 |

| Created_tmp_files   | 58  |

| Created_tmp_tables  | 1771587 |

+——————————–+———–+

每次创建临时表,Created_tmp_tables增加,如果临时表大小超过tmp_table_size,则是在磁盘上创建临时表,Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数,比较理想的配置是:

Created_tmp_disk_tables / Created_tmp_tables * 100%

默认为16M,可调到64-256最佳,线程独占,太大可能内存不够I/O堵塞

13) thread_cache_size
可以复用的保存在中的线程的数量。如果有,新的线程从缓存中取得,当断开连接的时候如果有空间,客户的线置在缓存中。如果有很多新的线程,为了提高性能可以这个变量值。

通过比较 Connections和Threads_created状态的变量,可以看到这个变量的作用。

默认值为110,可调优为80。

14) thread_concurrency
推荐设置为服务器 CPU核数的2倍,例如双核的CPU, 那么thread_concurrency的应该为4;2个双核的cpu, thread_concurrency的值应为8。默认为8

15) wait_timeout
指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。

3. 配置InnoDB的几个变量

innodb_buffer_pool_size

对于InnoDB表来说,innodb_buffer_pool_size的作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器,最大可以把该值设置成物理内存的80%。

根据MySQL手册,对于2G内存的机器,推荐值是1G(50%)。

innodb_flush_log_at_trx_commit

主要控制了innodb将log buffer中的数据写入日志文件并flush磁盘的时间点,取值分别为0、1、2三个。0,表示当事务提交时,不做日志写入操作,而是每秒钟将log buffer中的数据写入日志文件并flush磁盘一次;1,则在每秒钟或是每次事物的提交都会引起日志文件写入、flush磁盘的操作,确保了事务的ACID;设置为2,每次事务提交引起写入日志文件的动作,但每秒钟完成一次flush磁盘操作。

实际测试发现,该值对插入数据的速度影响非常大,设置为2时插入10000条记录只需要2秒,设置为0时只需要1秒,而设置为1时则需要229秒。因此,MySQL手册也建议尽量将插入操作合并成一个事务,这样可以大幅提高速度。

根据MySQL手册,在允许丢失最近部分事务的危险的前提下,可以把该值设为0或2。

innodb_log_buffer_size

log缓存大小,一般为1-8M,默认为1M,对于较大的事务,可以增大缓存大小。

可设置为4M或8M。

innodb_additional_mem_pool_size

该参数指定InnoDB用来存储数据字典和其他内部数据结构的内存池大小。缺省值是1M。通常不用太大,只要够用就行,应该与表结构的复杂度有关系。如果不够用,MySQL会在错误日志中写入一条警告信息。

根据MySQL手册,对于2G内存的机器,推荐值是20M,可适当增加。

innodb_thread_concurrency=8

推荐设置为 2*(NumCPUs+NumDisks),默认一般为8

Win2003下Apache性能优化

2014年9月12日 没有评论

一直习惯在Solaris和linux下跑amp,前些时服务器硬盘坏掉,所以启用新服务器。新系统是Windows 2003 Server,在上面按Unix上的经验配置Apache和Mysql时问题多多,经过折腾,总算是让服务器稳定下来,总结问题和解决办法如下(apache2.2.8+Mysql5.0.51a+php5.2.5):

1、Apache线程数和超时设置

Apache的线程数控制文件为conf/exrtra/http-mpm.conf,需要在httpd.conf中将 Include conf/extra/httpd-mpm.conf前#去掉,以使得http-mpm.conf生效。

在Windows系统中,起作用的是Winnt mpm段,


ThreadsPerChild 150
MaxRequestsPerChild 0

缺省的配置一般够用,但负荷大的网站就要修改了,否则网站一下就变慢或没有响应了。实际可以根据apache-status查看apache实时连接状态,我的服务器最后设置如下:


ThreadsPerChild 350
ThreadLimit 350
MaxRequestsPerChild 10000

Win32DisableAcceptEx
EnableMMAP Off
EnableSendfile Off

其中ThreadLimit是占用系统线程数限制,最好加上,否则会产生内存溢出导致Apache当掉。

MaxRequestsPerChild我理解是请求的缓存数,太小了影响性能,占用cpu时间,太大了占用内存资源,想象一下你网站的文件个数,然后自己设定,只要不为0就可以,防止内存溢出。

ThreadsPerChlid是apache的线程数,就是开了这么多的线程来等待响应客户端请求,需要根据apache-status实时的监控调节,大了会占用过多内存,小了会导致连接不上。而且应该同时修改httpd-default.php超时设置来配合。

在httpd.conf中去掉Include conf/extra/httpd-default.conf前的#以使httpd-default.php生效。

其中调节以下参数

Timeout 15 (连接超时缺省为300,太大了,缩小会减少同时连接数,即上面占用的实际线程数)

KeepAlive On (开启可以提高性能,因为一个页面一般会有多个请求)

MaxKeepAliveRequests 50 (这个数目自己根据网页内容调节)

KeepAliveTimeout 5 (这个小于Timeout就行)

Windows下长期运行Apache还是不如Unix稳定,可以让Apache在凌晨人少时自动重启,用Windows的计划任务可以非常方便的实现这一点,这样网管基本上可以安心睡觉了。