NFS文件系统详解以及安全设置

2017年8月10日 评论已被关闭

## 1、什么是NFS
The Network File System(NFS),网络文件系统。它允许挂载一个远程主机的硬盘分区,就相于使用本地硬盘一样.
## 2、搭建一个NFS服务器。
### 2.1.1、安装。
#yum -y install nfs*
### 2.1.2、nfs配置文件
nfs主要有三个配置文件/etc/exports,/etc/hosts.allow,/etc/hosts.deny。通常只需要编辑一个/etc/exports文件就可以让nfs工作。但是它不够安全,要用hosts.allow和hosts.deny文件来限制一些客户的访问。我先讲解/etc/exports文件配置,稍后再来讲解/etc/hosts.allow,/etc/hosts.deny两个文件的配置。
### 2.1.3、/etc/exports
这个文件包含一个条目列表,每个条目表示一个卷的共享以及是如何共享的。例如文件中有个条目是:
/usr/local/src 192.168.1.252(rw,sync,no_root_squash)
说明:/usr/local/src: 是要共享的目录,在/usr/local/src下的所有子目录和文件也将被共享。
192.168.1.252:客户机的ip能够访问/usr/local/src目录。
(rw):设置客户机对/home目录的权限,可读可写,(ro)为只读权限。
启动服务:
# /etc/init.d/nfs start
Starting NFS services: [ OK ]
Starting NFS quotas: [ OK ]
Starting NFS daemon: [ OK ]
Starting NFS mountd: [ OK ]

### 2.1.4、解释/etc/hosts.allow和/etc/hosts.deny配置文件

这两个文件是指定网络上哪些计算机可以使用nfs服务,该文件的每一个条目录,指定一个服务和一个或一组主机。当一个主机请求nfs服务,它会进行以下操作:
首先会去检查hosts.allow文件是否匹配里面的条目,如果匹配,则允许访问nsf服务。
如果不匹配hosts.allow文件中的条目,服务将会去检查hosts.deny文件,如果匹配,则拒绝访问。
如果客户端不匹配两个文件中的条目,则允许访问。
配置/etc/hosts.deny禁止所有用户访nfs的守护进程。只有hosts.allow文件指定的ip才能访问。内容如下:
portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL
配置/etc/hosts.allow文件允许192.168.1.252访问nfs.
格式:
service: host [or network/netmask] , host [or network/netmask]
添加以下内容:
portmap: 192.168.1.252
lockd: 192.168.1.252
rquotad: 192.168.1.252
mountd: 192.168.1.252
statd: 192.168.1.252

## 3、客户端配置
在192.168.1.252上执行
#mount -t nfs 192.168.1.251:/usr/local/src /data/src
#df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda3 6.6G 3.5G 2.9G 56% /
/dev/sda1 190M 17M 164M 10% /boot
tmpfs 62M 0 62M 0% /dev/shm
/dev/hdc 2.9G 2.9G 0 100% /mnt/cdrom
192.168.1.251:/usr/local/src
7.5G 3.0G 4.1G 43% /data/src
nfs文件系统成功挂载到客户端。

分类: Linux系统管理 标签:

非常简单的PYTHON HTTP服务

2017年8月9日 评论已被关闭

非常简单的PYTHON HTTP服务

如果你急需一个简单的Web Server,但你又不想去下载并安装那些复杂的HTTP服务程序,比如:Apache,ISS等。那么, Python 可能帮助你。使用Python可以完成一个简单的内建 HTTP 服务器。于是,你可以把你的目录和文件都以HTTP的方式展示出来。佻只需要干一件事情,那就是安装一个Python。

实际上来说,这是一个可以用来共享文件的非常有用的方式。实现一个微型的HTTP服务程序来说是很简单的事情,在Python下,只需要一个命令行。下面是这个命令行:(假设我们需要共享我们的目录 /home/haoel 而IP地址是192.168.1.1)
$ cd /home/haoel
$ python -m SimpleHTTPServer

这就行了,而我们的HTTP服务在8000号端口上侦听。你会得到下面的信息:

Serving HTTP on 0.0.0.0 port 8000 …
你可以打开你的浏览器(IE或Firefox),然后输入下面的URL:

http://192.168.1.1:8000
如果你的目录下有一个叫 index.html 的文件名的文件,那么这个文件就会成为一个默认页,如果没有这个文件,那么,目录列表就会显示出来。

如果你想改变端口号,你可以使用如下的命令:
$ python -m SimpleHTTPServer 8080
如果你只想让这个HTTP服务器服务于本地环境,那么,你需要定制一下你的Python的程序,下面是一个示例:
import sys
import BaseHTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
HandlerClass = SimpleHTTPRequestHandler
ServerClass = BaseHTTPServer.HTTPServer
Protocol = “HTTP/1.0”

if sys.argv[1:]:
port = int(sys.argv[1])
else:
port = 8000
server_address = (‘127.0.0.1’, port)

HandlerClass.protocol_version = Protocol
httpd = ServerClass(server_address, HandlerClass)

sa = httpd.socket.getsockname()
print “Serving HTTP on”, sa[0], “port”, sa[1], “…”
httpd.serve_forever()
注意:所有的这些东西都可以在 Windows 或 Cygwin 下工作。

分类: Python编程 标签:

部署tinyproxy代理服务

2017年7月24日 评论已被关闭

线上需要一个https的透明代理,开始打算用nginx,调试了一段时间发现配置较复杂且没有成功。后来用的tinyproxy做的透明代理。安装配置过程就是下载、解压、编译、安装、配置、启动一波流:

安装依赖

yum install asciidoc

下载

wget https://github.com/tinyproxy/tinyproxy/releases/download/1.8.4/tinyproxy-1.8.4.tar.gz -O tinyproxy-1.8.4.tar.gz

解压

tar xvfz tinyproxy.1.8.4.tar.gz

编译配置

./configure –enable-transparent –prifix=/usr/local/tinyproxy

更多的编译选项可以参考源码目录的README文件,部分说明如下:

./configure
make

make install

in the top level directory to compile and install Tinyproxy. There are
additional command line arguments you can supply to configure. They
include:

--enable-debug        If you would like to turn on full
            debugging support
--enable-xtinyproxy    Compile in support for the XTinyproxy
            header, which is sent to any web
            server in your domain.
--enable-filter        Allows Tinyproxy to filter out certain
            domains and URLs.
--enable-upstream    Enable support for proxying connections
            through another proxy server.
--enable-transparent
            Allow Tinyproxy to be used as a
            transparent proxy daemon
--enable-static        Compile a static version of Tinyproxy

    --with-stathost=HOST    Set the default name of the stats host

Support

编译

make

安装

make install
修改配置文件一般需要指定用户、用户组、端口、访问IP段,当然这些都有默认值,然后启动程序和测试。

启动程序:

/usr/local/tinyproxy/sbin/tinyproxy -c /usr/local/tinyproxy/etc/tinyproxy.conf

测试代理节点是否生效(假设代理程序安装在10.10.10.10的机器,监听的是8888端口):

curl url –proxy 10.10.10.10:8888

如果是https代理加 -k 参数

curl url –proxy 10.10.10.10:8888 -k
关于配置文件的一点补充:

添加多段IP地址

Allow 10.27.80.0/24
Allow 11.65.48.0/24
Allow 18.90.12.145

添加head信息,https的代理不能添加(一条信息一条记录和ip访问限制设置一样)

AddHeader "Referer" "http://www.baidu.com"

分类: Linux系统管理 标签:

linux screen 命令详解

2017年4月28日 评论已被关闭

http://www.cnblogs.com/mchina/archive/2013/01/30/2880680.html

一、背景

系统管理员经常需要SSH 或者telent 远程登录到Linux 服务器,经常运行一些需要很长时间才能完成的任务,比如系统备份、ftp 传输等等。通常情况下我们都是为每一个这样的任务开一个远程终端窗口,因为它们执行的时间太长了。必须等待它们执行完毕,在此期间不能关掉窗口或者断开连接,否则这个任务就会被杀掉,一切半途而废了。

二、简介

GNU Screen是一款由GNU计划开发的用于命令行终端切换的自由软件。用户可以通过该软件同时连接多个本地或远程的命令行会话,并在其间自由切换。

GNU Screen可以看作是窗口管理器的命令行界面版本。它提供了统一的管理多个会话的界面和相应的功能。

  • 会话恢复
只要Screen本身没有终止,在其内部运行的会话都可以恢复。这一点对于远程登录的用户特别有用——即使网络连接中断,用户也不会失去对已经打开的命令行会话的控制。只要再次登录到主机上执行screen -r就可以恢复会话的运行。同样在暂时离开的时候,也可以执行分离命令detach,在保证里面的程序正常运行的情况下让Screen挂起(切换到后台)。这一点和图形界面下的VNC很相似。
  • 多窗口
在Screen环境下,所有的会话都独立的运行,并拥有各自的编号、输入、输出和窗口缓存。用户可以通过快捷键在不同的窗口下切换,并可以自由的重定向各个窗口的输入和输出。Screen实现了基本的文本操作,如复制粘贴等;还提供了类似滚动条的功能,可以查看窗口状况的历史记录。窗口还可以被分区和命名,还可以监视后台窗口的活动。
  • 会话共享
Screen可以让一个或多个用户从不同终端多次登录一个会话,并共享会话的所有特性(比如可以看到完全相同的输出)。它同时提供了窗口访问权限的机制,可以对窗口进行密码保护。

GNU’s Screen 官方站点:http://www.gnu.org/software/screen/

三、语法

# screen [-AmRvx -ls -wipe][-d <作业名称>][-h <行数>][-r <作业名称>][-s ][-S <作业名称>]

参数说明

-A  将所有的视窗都调整为目前终端机的大小。
-d <作业名称>  将指定的screen作业离线。
-h <行数>  指定视窗的缓冲区行数。
-m  即使目前已在作业中的screen作业,仍强制建立新的screen作业。
-r <作业名称>  恢复离线的screen作业。
-R  先试图恢复离线的作业。若找不到离线的作业,即建立新的screen作业。
-s  指定建立新视窗时,所要执行的shell。
-S <作业名称>  指定screen作业的名称。
-v  显示版本信息。
-x  恢复之前离线的screen作业。
-ls或–list  显示目前所有的screen作业。
-wipe  检查目前所有的screen作业,并删除已经无法使用的screen作业。

四、常用screen参数

screen -S yourname -> 新建一个叫yourname的session
screen -ls -> 列出当前所有的session
screen -r yourname -> 回到yourname这个session
screen -d yourname -> 远程detach某个session
screen -d -r yourname -> 结束当前session并回到yourname这个session

在每个screen session 下,所有命令都以 ctrl+a(C-a) 开始。
C-a ? -> 显示所有键绑定信息
C-a c -> 创建一个新的运行shell的窗口并切换到该窗口
C-a n -> Next,切换到下一个 window
C-a p -> Previous,切换到前一个 window
C-a 0..9 -> 切换到第 0..9 个 window
Ctrl+a [Space] -> 由视窗0循序切换到视窗9
C-a C-a -> 在两个最近使用的 window 间切换
C-a x -> 锁住当前的 window,需用用户密码解锁
C-a d -> detach,暂时离开当前session,将目前的 screen session (可能含有多个 windows) 丢到后台执行,并会回到还没进 screen 时的状态,此时在 screen session 里,每个 window 内运行的 process (无论是前台/后台)都在继续执行,即使 logout 也不影响。
C-a z -> 把当前session放到后台执行,用 shell 的 fg 命令则可回去。
C-a w -> 显示所有窗口列表
C-a t -> Time,显示当前时间,和系统的 load
C-a k -> kill window,强行关闭当前的 window
C-a [ -> 进入 copy mode,在 copy mode 下可以回滚、搜索、复制就像用使用 vi 一样
C-b Backward,PageUp
C-f Forward,PageDown
H(大写) High,将光标移至左上角
L Low,将光标移至左下角
0 移到行首
$ 行末
w forward one word,以字为单位往前移
b backward one word,以字为单位往后移
Space 第一次按为标记区起点,第二次按为终点
Esc 结束 copy mode
C-a ] -> Paste,把刚刚在 copy mode 选定的内容贴上

五、使用 screen

5.1 安装screen

流行的Linux发行版(例如Red Hat Enterprise Linux)通常会自带screen实用程序,如果没有的话,可以从GNU screen的官方网站下载。

[root@TS-DEV ~]# yum install screen
[root@TS-DEV ~]# rpm -qa|grep screen
screen-4.0.3-4.el5
[root@TS-DEV ~]#

5.2 创建一个新的窗口

安装完成后,直接敲命令screen就可以启动它。但是这样启动的screen会话没有名字,实践上推荐为每个screen会话取一个名字,方便分辨:

[root@TS-DEV ~]# screen -S david

screen启动后,会创建第一个窗口,也就是窗口No. 0,并在其中打开一个系统默认的shell,一般都会是bash。所以你敲入命令screen之后,会立刻又返回到命令提示符,仿佛什么也没有发生似的,其实你已经进入Screen的世界了。当然,也可以在screen命令之后加入你喜欢的参数,使之直接打开你指定的程序,例如:

[root@TS-DEV ~]# screen vi david.txt

screen创建一个执行vi david.txt的单窗口会话,退出vi 将退出该窗口/会话。

5.3 查看窗口和窗口名称

打开多个窗口后,可以使用快捷键C-a w列出当前所有窗口。如果使用文本终端,这个列表会列在屏幕左下角,如果使用X环境下的终端模拟器,这个列表会列在标题栏里。窗口列表的样子一般是这样:

0$ bash  1-$ bash  2*$ bash

这个例子中我开启了三个窗口,其中*号表示当前位于窗口2,-号表示上一次切换窗口时位于窗口1。

Screen默认会为窗口命名为编号和窗口中运行程序名的组合,上面的例子中窗口都是默认名字。练习了上面查看窗口的方法,你可能就希望各个窗口可以有不同的名字以方便区分了。可以使用快捷键C-a A来为当前窗口重命名,按下快捷键后,Screen会允许你为当前窗口输入新的名字,回车确认。

5.4 会话分离与恢复

你可以不中断screen窗口中程序的运行而暂时断开(detach)screen会话,并在随后时间重新连接(attach)该会话,重新控制各窗口中运行的程序。例如,我们打开一个screen窗口编辑/tmp/david.txt文件:

[root@TS-DEV ~]# screen vi /tmp/david.txt

之后我们想暂时退出做点别的事情,比如出去散散步,那么在screen窗口键入C-a d,Screen会给出detached提示:

暂时中断会话

半个小时之后回来了,找到该screen会话:

[root@TS-DEV ~]# screen -ls

重新连接会话:

[root@TS-DEV ~]# screen -r 12865

一切都在。

当然,如果你在另一台机器上没有分离一个Screen会话,就无从恢复会话了。

这时可以使用下面命令强制将这个会话从它所在的终端分离,转移到新的终端上来:

5.5 清除dead 会话

如果由于某种原因其中一个会话死掉了(例如人为杀掉该会话),这时screen -list会显示该会话为dead状态。使用screen -wipe命令清除该会话:

5.6 关闭或杀死窗口

正常情况下,当你退出一个窗口中最后一个程序(通常是bash)后,这个窗口就关闭了。另一个关闭窗口的方法是使用C-a k,这个快捷键杀死当前的窗口,同时也将杀死这个窗口中正在运行的进程。

如果一个Screen会话中最后一个窗口被关闭了,那么整个Screen会话也就退出了,screen进程会被终止。

除了依次退出/杀死当前Screen会话中所有窗口这种方法之外,还可以使用快捷键C-a :,然后输入quit命令退出Screen会话。需要注意的是,这样退出会杀死所有窗口并退出其中运行的所有程序。其实C-a :这个快捷键允许用户直接输入的命令有很多,包括分屏可以输入split等,这也是实现Screen功能的一个途径,不过个人认为还是快捷键比较方便些。

六、screen 高级应用 

6.1 会话共享

还有一种比较好玩的会话恢复,可以实现会话共享。假设你在和朋友在不同地点以相同用户登录一台机器,然后你创建一个screen会话,你朋友可以在他的终端上命令:

[root@TS-DEV ~]# screen -x

这个命令会将你朋友的终端Attach到你的Screen会话上,并且你的终端不会被Detach。这样你就可以和朋友共享同一个会话了,如果你们当前又处于同一个窗口,那就相当于坐在同一个显示器前面,你的操作会同步演示给你朋友,你朋友的操作也会同步演示给你。当然,如果你们切换到这个会话的不同窗口中去,那还是可以分别进行不同的操作的。

6.2 会话锁定与解锁

Screen允许使用快捷键C-a s锁定会话。锁定以后,再进行任何输入屏幕都不会再有反应了。但是要注意虽然屏幕上看不到反应,但你的输入都会被Screen中的进程接收到。快捷键C-a q可以解锁一个会话。

也可以使用C-a x锁定会话,不同的是这样锁定之后,会话会被Screen所属用户的密码保护,需要输入密码才能继续访问这个会话。

6.3 发送命令到screen会话

在Screen会话之外,可以通过screen命令操作一个Screen会话,这也为使用Screen作为脚本程序增加了便利。关于Screen在脚本中的应用超出了入门的范围,这里只看一个例子,体会一下在会话之外对Screen的操作:

[root@TS-DEV ~]# screen -S sandy -X screen ping www.baidu.com

这个命令在一个叫做sandy的screen会话中创建一个新窗口,并在其中运行ping命令。

6.4 屏幕分割

现在显示器那么大,将一个屏幕分割成不同区域显示不同的Screen窗口显然是个很酷的事情。可以使用快捷键C-a S将显示器水平分割,Screen 4.00.03版本以后,也支持垂直分屏,快捷键是C-a |。分屏以后,可以使用C-a <tab>在各个区块间切换,每一区块上都可以创建窗口并在其中运行进程。

可以用C-a X快捷键关闭当前焦点所在的屏幕区块,也可以用C-a Q关闭除当前区块之外其他的所有区块。关闭的区块中的窗口并不会关闭,还可以通过窗口切换找到它。

6.5 C/P模式和操作

screen的另一个很强大的功能就是可以在不同窗口之间进行复制粘贴了。使用快捷键C-a <Esc>或者C-a [可以进入copy/paste模式,这个模式下可以像在vi中一样移动光标,并可以使用空格键设置标记。其实在这个模式下有很多类似vi的操作,譬如使用/进行搜索,使用y快速标记一行,使用w快速标记一个单词等。关于C/P模式下的高级操作,其文档的这一部分有比较详细的说明。

一般情况下,可以移动光标到指定位置,按下空格设置一个开头标记,然后移动光标到结尾位置,按下空格设置第二个标记,同时会将两个标记之间的部分储存在copy/paste buffer中,并退出copy/paste模式。在正常模式下,可以使用快捷键C-a ]将储存在buffer中的内容粘贴到当前窗口。

6.6 更多screen功能

同大多数UNIX程序一样,GNU Screen提供了丰富强大的定制功能。你可以在Screen的默认两级配置文件/etc/screenrc和$HOME/.screenrc中指定更多,例如设定screen选项,定制绑定键,设定screen会话自启动窗口,启用多用户模式,定制用户访问权限控制等等。如果你愿意的话,也可以自己指定screen配置文件。

以多用户功能为例,screen默认是以单用户模式运行的,你需要在配置文件中指定multiuser on 来打开多用户模式,通过acl*(acladd,acldel,aclchg…)命令,你可以灵活配置其他用户访问你的screen会话。更多配置文件内容请参考screen的man页。

自动化测试的7个步骤

2017年4月17日 评论已被关闭

自动化测试的7个步骤

http://blog.sina.com.cn/s/blog_4aae007d0100s18h.html

【摘要】我们对自动化测试充满了希望,然而,自动化测试却经常带给我们沮丧和失望。虽然,自动化测试可以把我们从困难的环境中解放出来,在实施自动化测试解决问题的同时,又带来同样多的问题。在开展自动化测试的工作中,关键问题是遵循软件开发的基本规则。本文介绍自动化测试的 7 个步骤:改进自动化测试过程,定义需求,验证概念,支持产品的可测试性,具有可延续性的设计( design for sustainability ),有计划的部署和面对成功的挑战。按照以上 7 个步骤,安排你的人员、工具和制定你的自动化测试项目计划,你将会通往一条成功之路。
一个故事 :
我在很多软件公司工作过,公司规模有大有小,也和来自其他公司的人员交流,因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事,以便各位了解自动化测试会出现哪些问题。
以前,我们有一个软件项目,开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具,最后选择了一种,并且购买了几份拷贝。她委派一位员工 ——Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作,还有其他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候,遇到了问题。这个测试工具太复杂,难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后, Jerry 认识到,他需要测试工具的技术支持人员到现场帮助安装测试工具,并找出其中的问题。在打过几个电话后,测试工具厂商派过来一位技术专家。技术专家到达后,找出问题所在,测试工具可以正常工作了。这还算是顺利了。但是,几个月后,他们还是没有真正实现测试自动化, Jerry 拒绝继续从事这个项目的工作,他害怕自动化测试会一事无成,只是浪费时间而已。
项目经理 Anita 把项目重新指派给 Kevin Shorttimer ,一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位,希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训,避免 Kevin 步 Jerry 的后尘 —— 由于使用测试工具遇到困难而变得沮丧,导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试,有点令人讨厌,因此,他非常愿意采用自动化测试。一个主要的版本发布后, Kevin 准备开始全天的自动化测试,他非常渴望得到一个机会证明自己可以写非常复杂的,有难度的代码。他建立了一个测试库,使用了一些技巧的方法,可以支持大部分的测试,这比原计划多花费了很多时间,不过, Kevin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本,并且确实发现了 bug 。接下来, Kevin 得到一个从事软件开发职位的机会,离开了自动化的岗位。
Ahmed Hardluck 接手 Kevin 的工作,从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少,并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中, Ahmed 经历了很多失败,并且不能确信测试执行的方法是否正确。测试执行中,执行失败后的错误的提示信息也没有太多的参考价值,他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需要一些特定的测试环境搭建要求,他更新测试环境搭建文档,坚持不懈地工作。后来,在自动化测试执行中,它发现几个执行失败的结果,经过分析,是回归测试的软件版本中有 BUG ,导致测试执行失败,发现产品的 BUG 后,每个人都很高兴。接下来,他仔细分析测试套中的内容,希望通过优化测试套使测试变得更可靠,但是,这个工作一直没有完成,预期的优化结果也没有达到。按照计划,产品的下一个发布版本有几个主要的改动, Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来,在测试产品的新版本中,绝大多数测试用例执行失败了, Ahmed 对执行失败的测试研究了很长时间,然后,从其他人那里寻求帮助。经过商讨,自动化测试应该根据产品的新接口做修改,自动化测试才能运转起来。最后,大家根据新接口修改自动化测试,测试都通过了。产品发布到了市场上。接下来,用户立刻打来投诉电话,投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本,导致一些错误提示信息被忽略了。虽然,实际上测试执行是失败的,但是,由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。
这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过,我希望你没有这样的相似结局。本文将给出一些建议,避免出现这样的结局。
问题
这个故事阐明了几个使自动化测试项目陷入困境的原因:
自动化测试时间不充足:根据项目计划的安排,测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间,无法得到真正的关注。
缺乏清晰的目标:有很多好的理由去开展自动化测试工作,诸如自动化测试可以节省时间,使测试更加简单,提高测试的覆盖率,可以让测试人员保持更好的测试主动性。但是,自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望,这些希望应该提出来,否则很可能面对的是失望。
缺乏经验:尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验,很难保证自动化测试的顺利开展。
更新换代频繁( High turnover ):测试自动化往往需要花费很多时间学习的,当自动化测试更新换代频繁的时候,你就丧失了刚刚学习到的自动化测试经验。
对于绝望的反应:在测试还远没有开始的时候,问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言,测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时,测试人员变得疲劳起来。测试什么时候后结束?当按照计划的安排,软件应该交付的时候,测试人员的绝望变得尤其强烈。如果不需要测试,那该有多好呀!在这种环境中,自动化测试可能是个可以选择的解决方法。但是,自动化测试却未必是最好的选择,他不是一个现实的解决方法,更像是一个希望。
不愿思考软件测试:很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况,自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂,导致很多自动化对软件测试并没有太大的帮助。
关注于技术:如何实现软件的自动化测试是一个很吸引人的技术问题。不过,过多的关注如何实现自动化测试,导致忽略了自动化测试方案是否符合测试需要。
遵守软件开发的规则
你可能了解 SEI (软件工程研究所)提出的 CMM (能力成熟度模型)。 CMM 分为 5 个界别,该模型用来对软件开发组织划分等级。 Jerry Weinberg (美国著名软件工程专家)也创建了自己的一套软件组织模型,在他的组织模型中增加了一个额外的级别,他称之为零级别。很显然,一个零模式的组织实际上也是开发软件;零模式组织中,在开发人员和用户之间没有差别 [Weinberg 1992] 。恰恰在这类组织环境中,经常采用自动化测试方法。因此,把资源用于自动化测试,并且把自动化测试当作一个软件开发活动对待,把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。
像其他软件开发项目一样,我们需要软件开发人员专注于测试自动化的开发任务;像其他软件开发项目一样,自动化测试可以自动完成具体的测试任务,对于具体的测试任务来说,自动化开发人员可能不是这方面的专家,因此,软件测试专家应该提供具体测试任务相关的咨询,并且提供测试自动化的需求;像其他软件开发项目一样,如果在开发编码之前,对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样,自动化测试代码需要跟踪和维护,因此,需要采用源代码管理。像其他软件开发项目一样,测试自动化也会出现 BUG ,因此,需要有计划的跟踪 BUG ,并且对修改后的 BUG 进行测试。像其他软件开发项目一样,用户需要知道如何使用软件,因此,需要提供用户使用手册。
本文中不对软件开发做过多讲述。我假定您属于某个软件组织,该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发项目中采用的标准步骤组织的,重点关注测试自动化相关的事宜和挑战。
·改进软件测试过程
·定义需求
·验证概念
·支持产品的可测试性
·可延续性的设计( design for sustainability )
·有计划的部署
·面对成功的挑战
步骤一:改进软件测试过程
如果你负责提高一个商业交易操作的效率,首先,你应该确认已经很好的定义了这个操作的具体过程。然后,在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前,你想知道是否可以采用更简单、成本更低的的方法。同样的,上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率,使测试过程更为快捷,没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。
例如,很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行,再执行,去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行,并且单调乏味。怎样才能做好回归测试文档化的工作呢?通常的做法是采用列有产品特性的列表,然后对照列表检查。这是个很好的开始,回归测试检查列表可以告诉你应该测试哪些方面。不过,回归测试检查列表只是合于那些了解产品,并且知道需要采用哪种测试方法的人。
在你开始测试自动化之前,你需要完善上面提到的回归测试检查表,并且,确保你已经采用了确定的的测试方法,指明测试中需要什么样的数据,并给出设计数据的完整方法。如果测试掌握了基本的产品知识,这会更好。确认可以提供上面提到的文档后,需要明确测试设计的细节描述,还应该描述测试的预期结果,这些通常被忽略,建议测试人员知道。太多的测试人员没有意识到他们缺少什么,并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果,因为,现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前,必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过,这时候千万不要走极端去过分细致地说明测试执行的每一个步骤,只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。但是,不要假定他们理解那些存留在你头脑中的软件测试执行的想法,把这些测试设计的思路描述清楚就可以了。
我以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后,决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷,针对每个缺陷,我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表,这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后,我没有机会完成测试自动化的实现工作。不过,当我们需要对这个模块做完整回归测试的时候,我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导,几乎不需要任何指导的情况下,各自完成了回归测试,并且发现了 BUG 。从某种角度看,这实际上是一次很成功的自动化测试。在这个项目中,我们与其开发自动化测试脚本,还不如把测试执行步骤文档化。后来,在其它项目中,我们开发了自动化测试脚本,发现相关人员只有接受相关培训才能理解并执行自动化测试脚本,如果测试自动化设计的很好,可能会好一些。不过,经过实践我们总结出完成一份设计的比较好的测试文档,比完成一份设计良好的测试脚本简单的多。
另外一个提高测试效率的简单方法是采用更多的计算机。很多测试人员动辄动用几台计算机,这一点显而易见。我之所以强调采用更多的计算机是因为,我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作,这种情况下由于错误的使用了测试设备、测试环境,导致测试没有效果。因此,自动化测试需要集中考虑所需要的支撑设备。
针对改进软件测试过程,我的最后一个建议是改进被测试的产品,使它更容易被测试,有很多改进措施既可以帮助用户更好的使用产品,也可以帮助测试人员更好的测试产品。稍后,我将讨论自动化测试的可测试需求。这里,我只是建议给出产品的改进点,这样对手工测试大有帮助。
一些产品非常难安装,测试人员在安装和卸载软件上花费大量的时间。这种情况下,与其实现产品安装的自动化测试,还不如改进产品的安装功能。采用这种解决办法,最终的用户会受益的。另外的一个处理方法是考虑开发一套自动安装程序,该程序可以和产品一同发布。事实上,现在有很多专门制作安装程序的商用工具。
另一些产品改进需要利用工具在测试执行的日志中查找错误。采用人工方法,在日志中一页一页的查询报错信息很容易会让人感到乏味。那么,赶快采用自动化方法吧。如果你了解日志中记录的错误信息格式,写出一个错误扫描程序是很容易的事情。如果,你不能确定日志中的错误信息格式,就开始动手写错误扫描程序,很可能面临的是一场灾难。不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。最终用户也不愿意采用通过搜索日志的方法查找错误信息。修改错误信息的格式,使其适合日志扫描程序,便于扫描工具能够准确的扫描到所有的错误信息。这样,在测试中就可以使用扫描工具了。
通过改进产品的性能对测试也是大有帮助的。很显然的,如果产品的性能影响了测试速度,鉴别出性能比较差的产品功能,并度量该产品功能的性能,把它作为影响测试进度的缺陷,提交缺陷报告。
上面所述的几个方面可以在无需构建自动化测试系统的情况下,大幅度的提高测试效率。改进软件测试过程会花费你构建自动化测试系统的时间,不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。
步骤二:定义需求
在前面的故事中,自动化工程师和自动化测试的发起者的目标存在偏差。为了避免这种情况,需要在自动化测试需求上保持一致。应该有一份自动化测试需求,用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来,自动化测试需求描述了自动化测试的目标。很多人认为自动化测试显然是一件好事情,但是,他们不愿意对自动化测试的目标给出清晰的描述。下面是人们选用自动化测试的几个原因:
·加快测试进度从而加快产品发布进度
·更多的测试
·通过减少手工测试降低测试成本
·提高测试覆盖率
·保证一致性
·提高测试的可靠性
·测试工作可以由技术能力不强测试人员完成
·定义测试过程,避免过分依赖个人
·测试变得更加有趣
·提高了编程技能
开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。除非三者之间达成一致,否则很难定义什么是成功的自动化测试。
当然,不同的情况下,有的自动化测试目标比较容易达到,有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高,测试人员必须能理解充分的理解自动化测试,从而通过自动化测试不断发现软件的缺陷。不过,自动化测试不利于测试人员不断的积累测试经验。不管怎么样,在开始自动化测试之前应该确定自动化测试成功的标准。
手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源,建立测试环境,执行测试用例。测试过程中,如果有什么异常的情况发生,手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果,记录测试结果,复位被测试的软件系统,准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况,研究测试过程可疑的现象,寻找测试用例执行失败的过程,设计并执行其他的测试用例帮助定位软件缺陷。接下来,他们写作缺陷报告单,保证缺陷被修改,并且总结所有的缺陷报告单,以便其他人能够了解测试的执行情况。
千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分,部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择,或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲,除非测试的各个环节都采用自动化方式,否则不是真正意义上的自动化测试,这真是胡言乱语。如果仅仅是为了寻找挑战,可以尝试在测试的每个环节都采用自动化方法。但是,如果寻找成功测试的方法,请关注那些可以快速建立的,可以反复利用的自动化测试。
定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况,然后给出权衡后的需求,并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求,距离成功的自动化测试近了一步。
步骤三:验证概念
在前面的故事当中,那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过,在项目的进行中,他得到了来自各个方面的支持。
你可能还没有认识到这一点,不过,你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长,并且需要来自你身边的各种人的帮助。
很多年前,我从事一个测试自动化项目的工作,参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统,并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度,甚至演示已经完成的部分功能。但是,我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后,整个项目被取消了,此后,我再也没有犯这个错误。
你需要尽可能快地验证你采用的测试工具和测试方法的可行性,站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的,需要尽快地找出可行性问题的答案,需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性,从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。
对于很多人来说,自动化测试意味着 GUI 自动化测试,我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试,并惊奇的发现这两类测试的测试计划有很大的互补性。不过, GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的,因为,如果没有选择合适的测试工具,你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中,找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期,你可能打算现在购买一份测试工具,然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前,找出工具存在的问题。这样,你可以从测试工具供应商得到更好的帮助,当你打算更换工具的时候,你不会感觉很为难。
下面是一些候选的验证概念的试验:
回归测试:你准备在每个版本运行同样的测试用例吗?回归测试是最宜采用自动化测试的环节。
配置测试:你的软件支持多少种不同的平台?你打算在所有支持的平台上测试执行所有的测试用例吗?如果是的,那么采用自动化测试是有帮助的。
测试环境建立:对于大量不同的测试用例,可能需要相同的测试环境搭建过程。在开展自动化测试执行之前,先把测试环境搭建实现自动化。
非 GUI 测试:实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。
无论采用什么测试方法,定义一个看得见的目标,然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。
步骤四:支持产品的可测试性
软件产品一般会用到下面三种不同类别的接口:命令行接口( command line interfaces ,缩写 CLIs) 、应用程序接口( API )、图形用户接口( GUI )。有些产品会用到所有三类接口,有些产品只用到一类或者两类接口,这些是测试中所需要的接口。从本质上看, API 接口和命令行接口比 GUI 接口容易实现自动化,去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候,这两类接口隐藏在产品的内部,如果确实没有,需要鼓励开发人员在产品中提供命令行接口或者 API 接口,从而支持产品的可测试性。
下面,更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能,这确实是个很好的方法。可以手工执行测试用例,测试工具在后台记住你的所有操作,然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法,但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本,但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果, GUI 测试还是主要由手工完成。
第二个原因,把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难,解决方法总是有的,可以采用修改产品源代码的方式,也可以从测试工具供应商处升级测试工具。另外,还需要分析测试工具中的 BUG ,并且给工具打补丁。也可能测试工具需要做相当的定制,以便能有效地测试产品界面上的定制控件。 GUI 测试中,困难总是意外出现,让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。
第三个原因, GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中,图形界面经常被修改或者完全重设计,这是出了名的事情。一般来讲,第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候,就开展 GUI 自动化测试是不会有任何进展的,你只能花费大量的时间修改测试脚本,以适应图形界面的变更。不管怎样,即便界面的修改会导致测试修改脚本,你也不应该反对开发人员改进图形界面。一旦原始的设计完成后,图形界面接口下面的编程接口就固定下来了。
上面提到的这些原因都是基于采用 GUI 自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试,可以考虑实现 GUI 测试自动化。不过,你也应该考虑采用其他方法测试产品的核心功能,并且这些测试不会因为图形界面发生变化而被中断,这类测试应该采用命令行接口或者 API 接口。我曾经看到有人选择 GUI 自动化测试,因为,他们不打算修改被测试产品,但是,最终他们认识到必须对产品做修改,以保证 GUI 测试自动化可以正常工作。无论你选择哪种方法,自动化都需要对被测试的产品做修改。因此,采用可编程的接口是最可靠的。
为了让 API 接口测试更为容易,应该把接口与某种解释程序,例如 Tcl 、 Perl 或者 Python 绑定在一起。这使交互式测试成为可能,并且可以缩短自动化测试的开发周期。采用 API 接口的方式,还可以实现独立的产品模块的单元测试自动化。
一个关于隐藏可编程接口的例子是关于 InstallShield—— 非常流行的制作安装盘的工具。 InstallShield 有命令行选项,采用这种选项可以实现非 GUI 方式的安装盘,采用这种方式,从提前创建好的文件中读取安装选项。这种方式可能比采用 GUI 的安装方式更简单更可靠。
另一个例子是关于如何避免基于 WEB 软件的 GUI 自动化测试。采用 GUI 测试工具可以通过浏览器操作 WEB 界面。 WEB 浏览器是通过 HTTP 协议与 WEB 服务器交互的,所以直接测试 HTTP 协议更为简单。 Perl 可以直接连接 TCP/IP 端口,完成这类的自动化测试。采用高级接口技术,譬如客户端 JAVA 或者 ActiveX 不可能利用这种方法。但是,如果在合适的环境中采用这种方式,你将发现这种方式的自动化测试比 GUI 自动化测试更加便宜更加简单。
我曾经受雇在一家公司负责某个产品 GUI 相关的自动化测试,该产品也提供命令行接口,不过,他们已经实现了 GUI 的自动化测试。经过一段时间的研究,我发现找到图形界面中的 BUG 并不困难,不过,用户并不关注图形界面,他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能(这些功能即可通过 GUI 的方式,也可以通过命令行的方式使用)实现自动化测试。我决定推迟 GUI 自动化测试,扩展命令行测试套,测试新增的产品功能。现在回过头看这个决定,我没有选择 GUI 自动化测试是最大的成功之处,如果采用了 GUI 自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做 GUI 自动化测试了,并且已经购买了一套测试工具和其他需要的东西,但我知道在开展具体的 GUI 自动化测试活动中,会遇到各种各样的困难和障碍。
无论你需要支持图形界面接口、命令行接口还是 API 接口,如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求,未来的测试工作中,你很可能成功。尽可能早的启动自动化测试项目,提出可测试性需求,会使您走向自动化测试成功之路。
步骤五:具有可延续性的设计
在开篇的故事中,我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来,导致测试自动化达不到预期的效果。自动化测试是一个长期的过程,为了与产品新版本的功能和其他相关修改保持一致,自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的,不过,自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过,测试人员应该相信得到的结果,测试执行的实际结果也应该是通过了。其实,有很多存在问题的测试用例表面上执行通过了,实际上却执行失败了,并且没有记录任何错误日志,这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果,而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误,都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。
性能:提高代码的性能往往增加了代码的复杂性,因此,会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析,很多测试套都是花费大量的时间等候产品的运行。因此,在不提高产品运行性能的前提下,无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能,而并没有实际的操作经验。如果测试套的性能问题无法改变,那么应该考虑提高硬件的性能;测试套中经常会出现冗余,也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务,都是很好的办法。
便于分析:测试自动化执行失败后应该分析失败的结果,这是一个棘手的问题。分析执行失败的自动化测试结果是件困难的事情,需要从多方面着手,测试上报的告警信息是真的还是假的?是不是因为测试套中存在缺陷导致测试执行失败?是不是在搭建测试环境中出现了错误导致测试执行失败?是不是产品中确实存在缺陷导致测试执行失败?有几个方法可以帮助测试执行失败的结果分析,某些方法可以找到问题所在。通过在测试执行之前检查常见的测试环境搭建问题,从而提高测试套的可靠性;通过改进错误输出报告,从而提高测试自动化的错误输出的可分析性;此外,还可以改进自动化测试框架中存在的问题。训练测试人员如何分析测试执行失败结果。甚至可以找到那些不可靠的、冗余的或者功能比较独立的测试,然后安全地将之删除。上面这些都是减少自动化测试误报告警、提高测试可分析性的积极有效的方法。另外,有一种错误的测试结果分析方法,那就是采用测试结果后处理程序对测试结果自动分析和过滤,尽管也可以采用这种测试结果分析方法,不过这种方法会使自动化测试系统复杂化,更重要的是,后处理程序中的 BUG 会严重损害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为异常,那该怎么办?我曾经看到测试小组花费开发测试自动化两倍的时间来修改测试脚本,并且不愿意开展培训过程。那些仅仅关注很浅层次测试技术的测试管理者对这种方法很感兴趣,他们排斥采用隐藏测试复杂度的方法。
综上所述,应该集中精力关注可以延续使用的测试套,从以下几方面考虑,测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。
可读性: 很多情况下,在测试人员开始测试项目之前,公司已经有了一套测试脚本,并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它,但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性,在具体应用中,那些脚本常常没有多大的实用价值,越来越让人迷惑。因此,测试人员很难确定他们实际在测试什么,反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本,并且理解测试脚本究竟测试了什么,这是很关键的。好的文档是解决问题的手段之一,对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法,我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩,把所有执行的产品相关的命令记录到日志里。这样,当分析日志确定执行了哪些产品命令,命令采用了何种参数配置时,可以提供一个非常好的测试记录,里面记录了自动化测试执行了什么,没有执行什么。如果测试脚本可读性不好,很容易变得过分依赖并没有完全理解的测试脚本,很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后,可以更容易的开展同行评审活动。
可维护性:在工作中,我曾经使用过一个测试套,它把所有的程序输出保存到文件中。然后,通过对比输出文件内容和一个已有的输出文件内容的差别,可以称已有的输出文件为 “ 标准文件 ” ( “gold file” )。在回归测试中,用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了,它会产生很多错误的警告。随着时间的推移,软件开发人员会根据需要修改产品的很多输出信息,这会导致很多自动化测试失败。很明显,为了保证自动化测试的顺利进行,应该在对 “ 标准文件 ” 仔细分析的基础上,根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是,每次只检查选定的产品的某些特定输出,而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试,这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改,并研究使测试修改量最小的方法,测试中采用库是解决问题的方法。当产品发生变化的时候,只需要修改相关的库,保证测试与产品的变动同步修改即可。
完整性:当自动化测试执行后,报告测试执行通过,可以断定这是真的吗?这就是我称之为测试套的完整性。在前面的故事中,当没有对自动化测试完整性给予应有的关注的时候,发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果?自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败,但是,对于自动化测试误报告警的情况,大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效,当测试发现异常的时候,能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法,分类包括 PASS , FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果,它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分,另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ,这个 BUG 引起测试队列中部分测试用例被跳过,没有执行。当测试队列运行完毕后,没有上报任何错误,我不得不通过走读代码的方式发现了这个 BUG 。如果,我没有关注到这个 BUG ,那么可能在认识到自动化测试已经出现问题之前,还在长时间运行部分测试用例。
独立性:采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候,通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化,测试执行是由一台不会说话的计算机完成的,你必须告诉计算机什么样的情况下测试执行是失败的,并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境,因此,保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档,以便一个接着一个有序地完成测试执行,每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误,这个错误源于 “ 多米诺骨牌 ” 测试套,当一个测试执行失败,会导致后续一系列测试失败。更糟糕的是,所有的测试关联紧密,无法独立的运行。并且,这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后,人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式,不过,重要的是在不牺牲测试的可靠性的前提下保证测试的独立性,如果测试可以在无需人看守情况下运行,那么测试的执行效率就不是大问题了。
可重复性:自动化测试有时能够发现问题,有时候又无法发现问题,对这种情况实在没有什么好的的处理办法。因此,需要保证每次测试执行的时候,测试是以同样的方式工作。这意味着不要采用随机数据,在通用语言库中构造的随机数据经常隐藏初始化过程,使用这些数据会导致测试每次都以不同的方式执行,这样,对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试,需要在可预测,并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据,然后在测试过程中使用这些数据。这样做看起来似乎很好,但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候,往往匆匆忙忙整理文件名和测试数据记录。当对这些测试采用自动化测试方法,该做哪些工作呢?办法之一是,可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用,那么就需要制定命名规则,避免在不同的测试中命名冲突,采用命名规则是一种很好的方法。然而,我曾经看到有些测试只是随机的命名数据记录,很不幸,事实证明采用这种随机命名的方式不可避免的导致命名冲突,并且影响测试的可重复性。很显然,自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次,测试数据记录的名字中包含四个随机产生的数字,经过简单的推算如果我们采用这种命名方式的时候,如果测试使用了 46 条记录,会存在 10% 冲突的可能性,如果使用 118 条记录,冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录,这样引入了问题,损害了测试的可靠性和测试的完整性。
测试库:自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库,自己也写了一些。当要求测试不受被测试产品接口变动影响的时候,采用测试库方法是非常有效的。不过,根据我的观察测试库已经使用的太多了,已经被滥用了,并且测试库往往设计的不好,没有相关的文档支撑,因此,使用测试库的测试往往很难开展。当发现问题的时候,往往不知道是测试库自身的问题,还是测试库的使用问题。由于测试库往往很复杂,即便在发现测试库存在问题,相关的维护人员也很不愿意去修改问题。通过前文中的论述,可以得出结论,在一开始就应该保证测试库设计良好。但是,实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致,即 ” 你将不需要它 ” 。这会导致在测试用例之间的代码出现一些重复,我发现微小的变化可能仍然存在,很难与测试库功能协调。你可能打算对测试用例作修改,采用源代码的方式比采用库的方式更容易修改。如果有几个测试,他们有某些共同的操作,我使用剪切和粘贴的方式去复制代码,有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码,我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的,因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试,并且很方便扩展测试套。在开发软件测试项目的时候,大多数程序员找到与他们打算实现功能类似的源代码,并对源代码做修改,而不是从头开始写代码。同样,在写测试套的过程中可以采用上述方法,这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库,这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义,并且文档化,从始至终都应该保持。我会对测试库作充分的测试后,才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库,不要希望有朝一日测试人员会利用你的测试库完成大量的测试,这一天恐怕永远不会到来。
数据驱动测试: 把测试数据写入到简单表格中,这种测试技术得到了越来越广泛的应用,这种方法被称为表驱动( table-driven ),数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试( “third generation” automation )。这需要写一个解析器,用来解释表格中的数据,并执行测试。该测试架构的最主要的好处是,它允许把测试内容写在具有一定格式的表格中,这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试,采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的,所以,上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作,还存在各种困难。代码所采用的编程语言是不断发展的。也许,测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入,这样,加入了新的变量。接下来,也许有人需要让测试中的某个环节运行一百次,这样加入一个循环。你可以采用其他语言,不过,如果你预料到会面临上述情况的时候,那么做好采用一些能够通过公开的渠道获取的编程语言,比如 Perl,Python 或者 TCL ,这样比设计你自己的语言要快的多。
启发式确认:我曾经看到很多测试自动化没有真正意义上的结果校验,其原因有两个,一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的,另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过,采用手工校验测试结果的方法是真正意义上的测试校验。标准文件( Gold file )是另外一中校验测试结果的方法。首先,捕获被测试程序的输出,并检视程序的输出,然后,把输出信息文档化,并归档,作为标准文件。以后,自动化测试结果与标准文件作比较,从而达到结果校验的目的。采用标准文件的方法,也有弊端。当产品发生变化,自动化测试的环境配置发生变化,产品的输出发生变化的时候,采用标准文方法,会上报大量的误报告警。做好的测试结果校验方法是,对输出结果的特定内容作分析,并作合理的比较。有时候,很难知道正确的输出结果是什么样的,但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法,是因为担心如果结果校验漏掉了任何信息,可能导致自动化测试自身出现错误。不过,我们在测试过程中往往采用折衷的做法,没有采用大而全的测试结果校验方法,这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法,那么他必须找相关人员咨询,寻找一种合适的测试结果校验策略,这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下,找到被测试产品的缺陷。
把注意力放在通过设计保证测试的可延续性上,选择一个合适的测试体系架构,你将进一步迈向成功的自动化测试。
步骤六:有计划的部署
在前面的故事中,当自动化工程师没有提供打包后的自动化测试程序给测试执行人员,会影响到测试执行,测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。
作为自动化工程师,你知道如何利用自动化方法执行测试和分析执行失败的结果。不过,测试执行人员却未必知道如何使用自动化测试。因此,需要提供自动化测试程序的安装文档和使用文档,保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配,出现安装错误的时候,能够给出有价值的提示信息,便于定位安装问题。
能够把自动化测试程序和测试套作为产品对待,那真是太好了。你应该对自动化测试程序和测试套开展测试,保证它们不依赖于任何专用的库或者是设备上的任何其他程序。
保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作;保证自动化测试是符合一般测试执行人员的思维习惯的;保证测试执行人员能够理解测试结果,并能够正确分析失败的测试执行结果;这需要自动化工程师提供自动动化测试相关的指导性文档和培训。
作为测试管理者,你希望在自动化工程师离开前,能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的,如果你没有及时的把测试套中的问题提出来,就会面临废弃已有的测试套的决定。
良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试;良好的测试套在新的软件平台上可以很方便的验证产品的功能;良好的测试套支持每天晚上开始的软件每日构造过程;甚至开发人员在代码 check in 之前,用良好的测试套验证代码的正确性。
测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此,尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上,这是个很好的办法。这样,大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美,而没有拿出来与人分享,这种做法一定要改变,共享出来的测试套不一定非常完美,共享才是关键。
有计划的自动化测试部署,保证你的测试套能够被产品相关人员获取到,你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。
步骤七:面对成功的挑战
当你完成了所有的事情,测试套已经文档化了,并且文档已经交付了。测试执行人员能够理解要开展的测试,并知道如何完成测试执行。随着你所负责产品的进一步开发和维护,测试被反复重用。虽然,在自动化使测试变简单的同时,也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况,如果不这样做,测试执行人员会认为执行失败的情况是由自动化引起,然后,自动化工程师被叫过来帮助诊断每一个执行失败的情况,开发人员往往也会认为执行失败是由于自动化测试自身引起的问题,这样,测试执行人员就不得不学习通过手工的方式,或者通过采用少量脚本的方式重现自动化测试发现的问题,以证明他们确实发现了产品当中的 BUG 。
测试套的相关工作还没有结束,为了提高测试覆盖率或者测试新的产品特性,需要增加更多的测试。如果已有的测试不能正常工作,那么需要对之修改;如果已有的测试是冗余的,那么需要删除这部分测试。
随着时间的推移,开发人员也会研究你设计的测试,改进产品的设计并且通过模拟你的测试过程对产品做初步测试,研究如何使产品在第一次测试就通过,这样,你设计的测试很可能无法继续发现新的问题,这种现象被称为一种杀虫剂悖论。这时候,会有人对你的测试有效性提出质疑,那么,你必须考虑是否应该挖掘更严格的测试,以便能够发现开发人员优化之后的产品中的缺陷。
以前,我提到过一个基本上无法实现的设想,设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的,手工测试是永远无法完全替代的。
有些测试受测试环境的影响很大,往往需要采用人工方法获取测试结果,分析测试结果。因此,很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题,因此,千万不要陷入到一切测试都采用自动化方法的错误观念中。
我曾经主张保证给与测试自动化持续不断的投入。但是,在开展自动化测试的时候,一个问题摆在面前,测试自动化应该及时的提供给测试执行人员,这个不成问题,但是如何保证需求变更后,能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步,那么自动化测试的效果就无法保证了,测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期,然后把这个日期作为里程碑,并计划达到这个里程碑。当达到这个里程碑后,自动化工程师应该做什么呢?如果自动化工程师关注当前产品版本的发布,他需要为测试执行人员提供帮助和咨询,但是,一旦测试执行人员知道如何使用自动化测试,自动化测试工程师可以考虑下一个版本的测试自动化工作,包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候,如果考虑了自动化测试需求,那么自动化测试师的设计工作就很好开展了,采用这种方法,自动化测试工程师可以保持与开发周期同步,而不是与测试周期同步。如果不采用这种方式,在产品版本升级的过程中,自动化测试无法得到进一步的改进。
持续在在自动化投入,你会面临成功的挑战,当自动化测试成为测试过程可靠的基础后,自动化测试的道路将会越来越平坦。
参考文献:
Bach, James. 1996. “Test Automation Snake Oil.” Windows Technical Journal , (October): 40-44. http://www.satisfice.com/articles/test_automation_snake_oil.pdf
Dustin, Elfriede. 1999. “Lessons in Test Automation.” Software Testing and Quality Engineering (September): 16-22.
http://www.stickyminds.com/sitewide.asp?ObjectId=1802&ObjectType=ART&Function=edetail
Fewster, Mark and Dorothy Graham. 1999. Software Test Automation , Addison-Wesley.
Groder, Chip. “Building Maintainable GUI Tests” in [Fewster 1999].
Kit, Edward. 1999. “Integrated, Effective Test Design and Automation.” Software Development (February). http://www.sdmagazine.com/articles/1999/9902/9902b/9902b.htm
Hancock, Jim. 1997 “When to Automate Testing.” Testers Network (June).
http://www.data-dimensions.com/Testers’Network/jimauto1.htm
Hendrickson, Elisabeth. 1999. “Making the Right Choice: The Features you Need in a GUI Test Automation Tool.” Software Testing and Quality Engineering Magazine (May): 21-25. http://www.qualitytree.com/feature/mtrc.pdf
Hoffman, Douglas. 1999. “Heuristic Test Oracles: The Balance Between Exhaustive Comparison and No Comparison at All.” Software Testing and Quality Engineering Magazine (March): 29-32.
Kaner, Cem. 1997. “Improving the Maintainability of Automated Test Suites.” Presented at Quality Week. http://www.kaner.com/lawst1.htm
Linz , Tilo and Matthias Daigl. 1998. “How to Automate Testing of Graphical User Interfaces.” European Systems and Software Initiative Project No. 24306 (June). http://www.imbus.de/html/GUI/AQUIS-full_paper-1.3.html
Jeffries, Ronald E., 1997, “XPractices,”
http://www.XProgramming.com/Practices/xpractices.htm
Marick, Brian. 1998. “When Should a Test Be Automated?” Presented at Quality Week. http://www.testing.com/writings/automate.pdf
Marick, Brian. 1997. “Classic Testing Mistakes.” Presented at STAR. http://www.testing.com/writings/classic/mistakes.html
Pettichord, Bret. 1996. “Success with Test Automation.” Presented at Quality Week (May). http://www.io.com/~wazmo/succpap.htm
Thomson, Jim. “A Test Automation Journey” in [Fewster 1999]
Weinberg, Ge

HTTP返回码中30X对SEO的影响

2017年3月30日 评论已被关闭

HTTP返回码中30X对SEO的影响
http://www.blogjava.net/hankchen/archive/2012/09/23/388379.html
在网站中由于某种原因经常会用到页面跳转。这种跳转从底层原理来看,都是利用了HTTP协议的30X返回码来实现的。

常用的30X返回码有下面几种:
301 永久性跳转
302 暂时性跳转
304 Not Modified 文档未修改
305 Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取,属于HTTP 1.1新增内容
其中,对SEO产生影响的是前两个,即301和302。我就先详细的介绍这两个状态码的区别。

一、302
对用户而已,301,302是没有区别的。他们看到效果只是一个跳转,浏览器中旧的URL变成了新的URL。页面跳到了这个新URL指向的地方。
但是对于搜索引擎,302转向可能会有URL规范化及网址劫持的问题。可能被搜索引擎判为是作弊。网址规范化的内容可以参考这篇文章:http://www.chinamyhosting.com/seoblog/2006/04/10/url-canonicalization/
那么,网址劫持是怎么回事呢?
302重定向和网址劫持有什么关系呢?这要从搜索引擎如何处理302转向说起。从定义来说,从网址A做一个302重定向到网址B时,主机服务器的隐含意思是网址A随时有可能改主意,重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下,当收到302重定向时,一般只要去抓取目标网址就可以了,也就是说网址B。实际上如果搜索引擎在遇到302转向时,百分之百的都抓取目标网址B的话,就不用担心网址URL劫持了。

问题就在于,有的时候搜索引擎,尤其是Google,并不能总是抓取目标网址。为什么呢?比如说,有的时候A网址很短,但是它做了一个302重定向到B网址,而B网址是一个很长的乱七八糟的URL网址,甚至还有可能包含一些问号之类的参数。很自然的,A网址更加用户友好,而B网址既难看,又不用户友好。这时Google很有可能会仍然显示网址A。
由于搜索引擎排名算法只是程序而不是人,在遇到302重定向的时候,并不能像人一样的去准确判定哪一个网址更适当,这就造成了网址URL劫持的可能性。也就是说,一个不道德的人在他自己的网址A做一个302重定向到你的网址B,出于某种原因, Google搜索结果所显示的仍然是网址A,但是所用的网页内容却是你的网址B上的内容,这种情况就叫做网址URL劫持。你辛辛苦苦所写的内容就这样被别人偷走了。

二、301
当网页A用301重定向转到网页B时,搜索引擎可以肯定网页A永久的改变位置,或者说实际上不存在了,搜索引擎就会把网页B当作唯一有效目标。301的好处是:
(1)没有网址规范化问题。
(2)网页A的PR网页级别会传到网页B,这对SEO非常重要!

在实际操作过程中,我和同事对一个站点(www.woshuone.com)做了实验。结果发现不管是使用301还是302,很容易被Google “K掉”,取消跳转之后过一周左右的时间就又恢复了。看来搜索引擎蜘蛛现在对页面跳转还是比较反感,认为作弊的可能性大,宁可错杀一百也不放过一人!

分类: 互联网知识库 标签:

jstack -F 命令在Linux 64位机器报错:get_thread_regs failed for a lwp

2017年3月30日 评论已被关闭

最近发现一个线上项目运行一段时间之后会僵死。程序不报任何异常,占有系统资源也都正常,就是对外提供不了服务了。

(友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen

根据经验,应该是程序有死锁情况,于是在线上运行“jstack –F <pid>”命令,想把线程堆栈dump下来。

但是,发现这个命令老是报下面的错误:

Thread 27316: (state = BLOCKED)
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp

线上环境是:

Linux 2.6.18-194.el5 x86_64 x86_64 x86_64 GNU/Linux

java version “1.6.0_21”
Java(TM) SE Runtime Environment (build 1.6.0_21-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

经过分析发现,这是JDK6u23之前版本的一个Bug,将JDK升级到最新版本(1.6.0_31)就可以解决问题了。

{B0E1C5D8-CE33-4940-B416-2E75003A59FA}

分类: Java技术栈 标签:

java CPU 100% 排查

2017年3月30日 评论已被关闭

java CPU 100% 排查

http://www.cnblogs.com/lishijia/p/5549980.html

一个应用占用CPU很高,除了确实是计算密集型应用之外,通常原因都是出现了死循环。

(友情提示:本博文章欢迎转载,但请注明出处:hankchen,http://www.blogjava.net/hankchen

以我们最近出现的一个实际故障为例,介绍怎么定位和解决这类问题。

 

根据top命令,发现PID为28555的Java进程占用CPU高达200%,出现故障。

通过ps aux | grep PID命令,可以进一步确定是tomcat进程出现了问题。但是,怎么定位到具体线程或者代码呢?

首先显示线程列表:

ps -mp pid -o THREAD,tid,time

 

找到了耗时最高的线程28802,占用CPU时间快两个小时了!

其次将需要的线程ID转换为16进制格式:

printf “%x\n” tid

 

最后打印线程的堆栈信息:

jstack pid |grep tid -A 30

 

找到出现问题的代码了!

现在来分析下具体的代码:ShortSocketIO.readBytes(ShortSocketIO.java:106)

ShortSocketIO是应用封装的一个用短连接Socket通信的工具类。readBytes函数的代码如下:

public byte[] readBytes(int length) throws IOException {

if ((this.socket == null) || (!this.socket.isConnected())) {

throw new IOException(“++++ attempting to read from closed socket”);

}

byte[] result = null;

ByteArrayOutputStream bos = new ByteArrayOutputStream();

if (this.recIndex >= length) {

bos.write(this.recBuf, 0, length);

byte[] newBuf = new byte[this.recBufSize];

if (this.recIndex > length) {

System.arraycopy(this.recBuf, length, newBuf, 0, this.recIndex – length);

}

this.recBuf = newBuf;

this.recIndex -= length;

} else {

int totalread = length;

if (this.recIndex > 0) {

totalread -= this.recIndex;

bos.write(this.recBuf, 0, this.recIndex);

this.recBuf = new byte[this.recBufSize];

this.recIndex = 0;

}

int readCount = 0;

while (totalread > 0) {

if ((readCount = this.in.read(this.recBuf)) > 0) {

if (totalread > readCount) {

bos.write(this.recBuf, 0, readCount);

this.recBuf = new byte[this.recBufSize];

this.recIndex = 0;

} else {

bos.write(this.recBuf, 0, totalread);

byte[] newBuf = new byte[this.recBufSize];

System.arraycopy(this.recBuf, totalread, newBuf, 0, readCount – totalread);

this.recBuf = newBuf;

this.recIndex = (readCount – totalread);

}

totalread -= readCount;

}

}

}

问题就出在标红的代码部分。如果this.in.read()返回的数据小于等于0时,循环就一直进行下去了。而这种情况在网络拥塞的时候是可能发生的。

至于具体怎么修改就看业务逻辑应该怎么对待这种特殊情况了。

 

最后,总结下排查CPU故障的方法和技巧有哪些:

1、top命令:Linux命令。可以查看实时的CPU使用情况。也可以查看最近一段时间的CPU使用情况。

2、PS命令:Linux命令。强大的进程状态监控命令。可以查看进程以及进程中线程的当前CPU使用情况。属于当前状态的采样数据。

3、jstack:Java提供的命令。可以查看某个进程的当前线程栈运行情况。根据这个命令的输出可以定位某个进程的所有线程的当前运行状态、运行代码,以及是否死锁等等。

4、pstack:Linux命令。可以查看某个进程的当前线程栈运行情况。

分类: Java技术栈 标签:

订阅基础:RSS、ATOM、FEED、聚合、供稿、合烧与订阅

2017年3月27日 评论已被关闭

订阅基础:RSS、ATOM、FEED、聚合、供稿、合烧与订阅

http://www.metsky.com/archives/361.html

很多网友对这类名词概念非常陌生,如果没用过FEED订阅,肯定还会对诸多网站显示的FEED聚合、订阅、ATOM等等非常郁闷,虽然这几个名字间的很多并非并列关系,天缘只是有意把它们放到一起,方便对比参考,因为天缘每次看到这些东西,都要楞一下才能反应过来,越发感觉中文演绎词的虚假和忽悠,其实不过是把人家网站的XML格式文件打个包、分个类然后输出,仅此而已,反而如果只说聚合会越看越糊涂。

一、RSS是什么

RSS(全称RDF Site Summary,网景的最初定义),RSS也是一种“类网页”描述语言(或叫文档格式),最初由网景公司(Netscape)定义,RSS只是有个相对统一的规范(注意只是规范),前途未卜(RSS 2.0的版权问题)。RSS作为网站内容分享的一种便利接口,创立随早,但只是从博客(BLOG)风行才开始广为流传。

关于RSS的更多介绍请参考维基百科:http://en.wikipedia.org/wiki/RSS(英文),http://zh.wikipedia.org/zh-cn/RSS(中文)

二、ATOM是什么

由于RSS前途未卜,而且RSS标准发展存在诸多问题或不足,于是ATOM横空出世,可以先简单的理解为RSS的替代品。ATOM是IETF的建议标准,Atom Syndication Format是基于XML格式(RFC 4287),Atom Publishing Protocol则是基于HTTP协议格式(RFC 5023)。

RSS与ATOM比较,请参考:ATOM

三、FEED是什么

FEED(中文发音“肥的”、“废了”都可以)只是一个中间过程,所以全世界没人能给FEED下一个准确的定义,所以还是按照天缘的观点理解,大家不用关心FEED的定义,其实FEED什么都不是。如果非得给个说法,最好还是放到英文环境下理解似乎更加合理,FEED其实就是RSS(或ATOM)和订阅用户之间的“中间商”,起到帮忙批发传递信息的作用。所以,FEED的常见格式就是RSS和ATOM,网络上说的FEED订阅,更确切的说法应该仍然是RSS或ATOM订阅。

FEED更多介绍:http://en.wikipedia.org/wiki/Feed

四、什么是订阅

订阅跟普通大家订阅报刊类似,不过几乎所有网站的RSS/ATOM订阅都是免费的,也有一些“非主流”一族要收费订阅的,当然FEED订阅只是网络上的信息传递,一般不涉及实体资料传递,所以大家遇到喜欢的网站,并且也喜欢使用在线或离线阅读,尽可订阅,而且可以随时退订,实际订阅一般有如下几种方式:

在线订阅:

一般有浏览器、网页、邮件等方式,在线的最多,比如Google Reader、鲜果、抓虾、Netvibes、雅虎、有道等等,如果是订阅到邮箱,只需要输入个人邮箱就可以了,然后自会有FEED“中间商”把最新的订阅内容发到您的邮箱。另外,比如FIREFOX等浏览器也有订阅功能,比如访问天缘博客,地址栏回有订阅图标提示,只需要点击即可订阅。

离线订阅:

一般都是安装到本机的订阅软件,也称RSS阅读器、Feed阅读器或新闻阅读器等等,比如POTU、新闻蚂蚁、易搜比等等,反正就是个下载并解析RSS/ATOM的软件,然后把文件中的内容提取并展示出来。

五、其它被搞复杂的一些概念

FEED聚合是什么——聚合就是FEED

FEED供稿是什么——还是FEED,但按照上文介绍FEED只是一个中间过程,所以聚合和供稿一样理解。

FEED合烧是什么——如果你有多个网站,一般会对应多个RSS,然后让FEED“中间商”帮忙合做成一个,这样用户只需要订阅一个就可以。

六、最常用的FEED管理服务商

对于站长,肯定对以下几个网址都很熟悉,普通用户就不用关心,但是作为站长还是需要考虑找个好点的FEED“中间商”,当然如果你的网站或博客没有RSS或ATOM输出也不用考虑:

http://www.feedburner.com/,该网站经常撞墙,2007年被GOOGLE 1亿美金收购。

http://www.feedsky.com,国产FEED管理服务商,还不错,虽然也是三天两头有点小问题。

注:

1、文中部分概念解释纯粹是为了化繁为简,方便理解而提炼,如有不当,欢迎留言指出修正。

2、本文图片来源GOOGLE图片搜索。

分类: 技术周边大全 标签:

Java出错 Error:Could not create the Java Virtual Machine Error:A fatal exception has occurred

2017年2月23日 评论已被关闭

Java出错 Error:Could not create the Java Virtual Machine Error:A fatal exception has occurred

http://blog.csdn.net/y6300023290/article/details/45478009

提示如下:

scala compile server. error:could not create the java machine.Error: A fatal exception has occurred. program will exit.

这个原因是因为在安装JDK的时候在C:\Windows\System32生成的java.exe、javaw.exe、javaws.exe这个3个引起的;只要把这3个运行文件删除掉就可以了

java -version
分类: Java技术栈 标签:

自动化运维工具puppet安装配置

2017年2月21日 评论已被关闭

自动化运维工具puppet安装配置
http://blog.csdn.net/linuxlsq/article/details/50838189
1. 准备工作

两台机器:
192.168.1.100(服务端)
192.168.1.101 (客户端)
两台机器关闭selinux,清空iptables规则,并保存,设置hostname

100上
hostname master.aming.com
编辑/etc/sysconfig/network 定义hostname

101上
hostname client.aming.com
编辑/etc/sysconfig/network 定义hostname
重启服务器

编辑hosts文件
100和101全部为
192.168.1.100 master.aming.com
192.168.1.101 client.aming.com
安装ntpdate,并建立自动同步时间的任务计划:
yum install -y ntp
crontab -e //加入
*/10 * * * * ntpdate time.windows.com
2. 服务端安装

安装puppet 源
rpm -ivh http://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-7.noarch.rpm

安装服务端程序
yum install -y puppet-server
启动服务
service puppetmaster start

开机启动
chkconfig puppetmaster on

3. 客户端安装

安装puppet 源
rpm -ivh http://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-7.noarch.rpm

安装客户端程序
yum install -y puppet

修改配置文件
vi /etc/puppet/puppet.conf
在最后面添加:
listen = true
server = master.aming.com
runinterval = 30 //主动更新,每隔30s

然后启动puppet服务
/etc/init.d/puppet start

手动生成ssl证书
puppet agent –test –server master.aming.com

4. 服务端查看,签发客户端的证书

puppet cert list –all
会看到client.aming.com 的key,正常应该会在行首有一个+,如果没有说明还没有签发

签发客户端
puppet cert –sign client.aming.com

5. 测试

服务端上
vi /etc/puppet/manifests/site.pp
加入如下内容:
node default {
file {
“/tmp/123.txt”: content => “test,test”;
}
}
客户端上
puppet agent –test –server master.aming.com
这样会在客户端上生成一个 /tmp/123.txt的文件,并且内容为 testtest
6. 配置自动签发证书

服务端上删除客户端证书
puppet cert clean client.aming.com

客户端上删除ssl下的文件
rm -rf /var/lib/puppet/ssl/*

服务端更改配置文件
vim /etc/puppet/puppet.conf在[main]下面加一行
autosign = true
服务端创建自动签发的配置文件
vim /etc/puppet/autosign.conf
加入如下内容:
*.aming.com

重启puppetmaster服务
/etc/init.d/puppetmaster restart

客户端重启puppet服务
/etc/init.d/puppet restart

这样就能在服务端上自动签发证书了。当然不重启服务,手动连一下服务端也可以
客户端执行:
puppet agent –test –server master.aming.com

扩展: puppet更新方式 http://www.cnphp6.com/archives/66975

7. 模块管理

首先要理解几个概念,模块、类、资源。 模块是puppet的最大单元,模块里面有类,类下面有资源。 puppet管理的文件、用户、服务、任务计划等全部由这些单元组成。

下面我们来定义一个模块:
在服务端上做如下操作:
mkdir /etc/puppet/modules/testm //模块名字就是testm
cd !$
mkdir {files,manifests,templates} //一个模块下需要有这三个目录,files存一些文件(可以为空),manifests存配置文件,templates存模板(可以留空)
touch manifests/init.pp //这个是必须的
vi manifests/init.pp //内容如下
class testm{
file {“/tmp/2.txt”:
owner => “root”,
group => “root”,
mode => 0400,
source => “puppet://$puppetserver/modules/testm/1.txt”
}
}

说明:类名字也叫做testm, 类下面定义了一个资源file,文件名字叫做/tmp/2.txt ,owner,group,mode定义文件的属主、数组以及权限,source定义这个文件从哪里获取。 $puppetserver一会也要定义一下,这里指的是puppet server服务器上/etc/puppet/modules/testm/files/1.txt

下面要继续定义一个很关键的配置文件:
vim /etc/puppet/manifests/site.pp //内容如下
$puppetserver = ‘master.aming.com’

node ‘client.aming.com'{
include testm
}
说明:$puppetserver 定义服务端的主机名,node后面为客户端的主机名,这里面定义该客户端要加载的模块
配置完成后,在客户端执行命令:
puppet agent –test –server=master.aming.com //如果客户端上启动了puppet服务,不用执行这命令,它也会自动同步的
上面的模块其实只是同步了一个文件而已,那么要想同步一个目录如何做?我们可以通过实现同步一个目录来做一个包发布系统。 比如在一台机器上编译安装好了apache,那么就可以通过这样的模块把这个apache目录整个分发到其他机器上。

模块配置文件如下:
class apache{
file {“/usr/local/apache2”:
owner => “root”,
group => “root”,
source => “puppet://$puppetserver/modules/apache/apache2”,
recurse => true,
purge => true

}
}
其中recurse=>true 这个参数很关键,它表示递归的意思,没有这个不能同步目录。purge参数可以保证当服务端删除某个文件,客户端可以跟着删除。

远程执行命令:
exec {“123”:
unless => “test -f /tmp/aminglinux.txt”,
path => [“/bin”, “/sbin”, “/usr/bin”, “/usr/sbin”],
command => “/bin/touch /tmp/aminglinux.txt”
}
说明:unless后面的命令作为一个条件,当条件成立时,不会执行下面的命令,如果想要条件成立时,执行下面的命令,用 onlyif。要注意的是,我们一定要给执行的这条命令加个条件,使用unless就可以,必须满足这个条件才能执行命令,否则这个命令会一直执行,不太妥当。
cron资源:
cron {“aming1”:
command => “/sbin/ntpdate time.windows.com”,
user => “root”,
minute => “*/10”,
# ensure => “absent” //当增加了这行配置,则会把该cron删除掉
}

说明:分时日月周分别对应puppet里面的minute,hour,monthday,month,weekday
扩展学习 http://blog.chinaunix.net/uid-20639775-id-3314583.html

资源:

package http://puppet.wikidot.com/package
service http://puppet.wikidot.com/srv
exec http://puppet.wikidot.com/exec
cron http://puppet.wikidot.com/cron

ubuntu永久修改主机名

2017年2月21日 评论已被关闭

ubuntu永久修改主机名
http://blog.csdn.net/ruglcc/article/details/7802077
ubuntu永久修改主机名

1、查看主机名

在Ubuntu系统中,快速查看主机名有多种方法:
其一,打开一个GNOME终端窗口,在命令提示符中可以看到主机名,主机名通常位于“@”符号后;
其二,在终端窗口中输入命令:hostname或uname –n,均可以查看到当前主机的主机名。

2、临时修改主机名

命令行下运行命令:“hostname 新主机名”
其中“新主机名”可以用任何合法字符串来表示。不过采用这种方式,新主机名并不保存在系统中,重启系统后主机名将恢复为原先的主机名称。
例子:hostname ubuntu-temp
这样主机名字就临时被修改为ubuntu-temp,但是终端下不会立即显示生效后的主机名,重开一个终端窗口(通过ssh连接的终端需要重新连接才可以);
3、永久修改主机名

在Ubuntu系统中永久修改主机名也比较简单。主机名存放在/etc/hostname文件中,修改主机名时,编辑hostname文件,在文件中输入新的主机名并保存该文件即可。重启系统后,参照上面介绍的快速查看主机名的办法来确认主机名有没有修改成功。

值的指出的是,在其它Linux发行版中,并非都存在/etc/hostname文件。如Fedora发行版将主机名存放在/etc/sysconfig/network文件中。所以,修改主机名时应注意区分是哪种Linux发行版。

3、/etc/hostname与/etc/hosts的区别
/etc/hostname中存放的是主机名,hostname文件的一个例子:
v-jiwan-ubuntu-temp

/etc/hosts存放的是域名与ip的对应关系,域名与主机名没有任何关系,你可以为任何一个IP指定任意一个名字,hostname文件的一个例子:
127.0.0.1 localhost
127.0.1.1 v-jiwan-ubuntu

常用 Git 命令清单

2017年2月16日 评论已被关闭

常用 Git 命令清单

一般来说,日常使用只要记住下图6个命令,就可以了。但是熟练使用,恐怕要记住60~100个命令。

下面是我整理的常用 Git 命令清单。几个专用名词的译名如下。

Workspace:工作区

Index / Stage:暂存区

Repository:仓库区(或本地仓库)

Remote:远程仓库

一、新建代码库

# 在当前目录新建一个Git代码库

$ git init

# 新建一个目录,将其初始化为Git代码库

$ git init [project-name]

# 下载一个项目和它的整个代码历史

$ git clone [url]

二、配置

Git的设置文件为.gitconfig,它可以在用户主目录下(全局配置),也可以在项目目录下(项目配置)。

# 显示当前的Git配置

$ git config –list

# 编辑Git配置文件

$ git config -e [–global]

# 设置提交代码时的用户信息

$ git config [–global] user.name “[name]”

$ git config [–global] user.email “[email address]”

三、增加/删除文件

# 添加指定文件到暂存区

$ git add [file1] [file2] …

# 添加指定目录到暂存区,包括子目录

$ git add [dir]

# 添加当前目录的所有文件到暂存区

$ git add .

# 添加每个变化前,都会要求确认

# 对于同一个文件的多处变化,可以实现分次提交

$ git add -p

# 删除工作区文件,并且将这次删除放入暂存区

$ git rm [file1] [file2] …

# 停止追踪指定文件,但该文件会保留在工作区

$ git rm –cached [file]

# 改名文件,并且将这个改名放入暂存区

$ git mv [file-original] [file-renamed]

四、代码提交

# 提交暂存区到仓库区

$ git commit -m [message]

# 提交暂存区的指定文件到仓库区

$ git commit [file1] [file2] … -m [message]

# 提交工作区自上次commit之后的变化,直接到仓库区

$ git commit -a

# 提交时显示所有diff信息

$ git commit -v

# 使用一次新的commit,替代上一次提交# 如果代码没有任何新变化,则用来改写上一次commit的提交信息

$ git commit –amend -m [message]

# 重做上一次commit,并包括指定文件的新变化

$ git commit –amend [file1] [file2] …

五、分支

# 列出所有本地分支

$ git branch

# 列出所有远程分支

$ git branch -r

# 列出所有本地分支和远程分支

$ git branch -a

# 新建一个分支,但依然停留在当前分支

$ git branch [branch-name]

# 新建一个分支,并切换到该分支

$ git checkout -b [branch]

# 新建一个分支,指向指定commit

$ git branch [branch] [commit]

# 新建一个分支,与指定的远程分支建立追踪关系

$ git branch –track [branch] [remote-branch]

# 切换到指定分支,并更新工作区

$ git checkout [branch-name]

# 切换到上一个分支

$ git checkout –

# 建立追踪关系,在现有分支与指定的远程分支之间

$ git branch –set-upstream [branch] [remote-branch]

# 合并指定分支到当前分支

$ git merge [branch]

# 选择一个commit,合并进当前分支

$ git cherry-pick [commit]

# 删除分支

$ git branch -d [branch-name]

# 删除远程分支

$ git push origin –delete [branch-name]

$ git branch -dr [remote/branch]

六、标签

# 列出所有tag

$ git tag

# 新建一个tag在当前commit

$ git tag [tag]

# 新建一个tag在指定commit

$ git tag [tag] [commit]

# 删除本地tag

$ git tag -d [tag]

# 删除远程tag

$ git push origin :refs/tags/[tagName]

# 查看tag信息

$ git show [tag]

# 提交指定tag

$ git push [remote] [tag]

# 提交所有tag

$ git push [remote] –tags

# 新建一个分支,指向某个tag

$ git checkout -b [branch] [tag]

七、查看信息

# 显示有变更的文件

$ git status

# 显示当前分支的版本历史

$ git log

# 显示commit历史,以及每次commit发生变更的文件

$ git log –stat

# 搜索提交历史,根据关键词

$ git log -S [keyword]

# 显示某个commit之后的所有变动,每个commit占据一行

$ git log [tag] HEAD –pretty=format:%s

# 显示某个commit之后的所有变动,其”提交说明”必须符合搜索条件

$ git log [tag] HEAD –grep feature

# 显示某个文件的版本历史,包括文件改名

$ git log –follow [file]$ git whatchanged [file]

# 显示指定文件相关的每一次diff

$ git log -p [file]

# 显示过去5次提交

$ git log -5 –pretty –oneline

# 显示所有提交过的用户,按提交次数排序

$ git shortlog -sn

# 显示指定文件是什么人在什么时间修改过

$ git blame [file]

# 显示暂存区和工作区的差异

$ git diff

# 显示暂存区和上一个commit的差异

$ git diff –cached [file]

# 显示工作区与当前分支最新commit之间的差异

$ git diff HEAD

# 显示两次提交之间的差异

$ git diff [first-branch]…[second-branch]

# 显示今天你写了多少行代码

$ git diff –shortstat “@{0 day ago}”

# 显示某次提交的元数据和内容变化

$ git show [commit]

# 显示某次提交发生变化的文件

$ git show –name-only [commit]

# 显示某次提交时,某个文件的内容

$ git show [commit]:[filename]

# 显示当前分支的最近几次提交

$ git reflog

八、远程同步

# 下载远程仓库的所有变动

$ git fetch [remote]

# 显示所有远程仓库

$ git remote -v

# 显示某个远程仓库的信息

$ git remote show [remote]

# 增加一个新的远程仓库,并命名

$ git remote add [shortname] [url]

# 取回远程仓库的变化,并与本地分支合并

$ git pull [remote] [branch]

# 上传本地指定分支到远程仓库

$ git push [remote] [branch]

# 强行推送当前分支到远程仓库,即使有冲突

$ git push [remote] –force

# 推送所有分支到远程仓库

$ git push [remote] –all

九、撤销

# 恢复暂存区的指定文件到工作区

$ git checkout [file]

# 恢复某个commit的指定文件到暂存区和工作区

$ git checkout [commit] [file]

# 恢复暂存区的所有文件到工作区

$ git checkout .

# 重置暂存区的指定文件,与上一次commit保持一致,但工作区不变

$ git reset [file]

# 重置暂存区与工作区,与上一次commit保持一致

$ git reset –hard

# 重置当前分支的指针为指定commit,同时重置暂存区,但工作区不变

$ git reset [commit]

# 重置当前分支的HEAD为指定commit,同时重置暂存区和工作区,与指定commit一致

$ git reset –hard [commit]

# 重置当前HEAD为指定commit,但保持暂存区和工作区不变

$ git reset –keep [commit]

# 新建一个commit,用来撤销指定commit# 后者的所有变化都将被前者抵消,并且应用到当前分支

$ git revert [commit]

# 暂时将未提交的变化移除,稍后再移入

$ git stash

$ git stash pop

十、其他

# 生成一个可供发布的压缩包

$ git archive

分类: Git版本管理工具 标签:

TCP,IP,HTTP,SOCKET区别和联系

2017年2月15日 评论已被关闭

TCP,IP,HTTP,SOCKET区别和联系

网络由下往上分为:        对应

物理层–

数据链路层–

网络层–IP协议

传输层–TCP协议

会话层–

表示层和应用层–HTTP协议

 

socket则是对TCP/IP协议的封装和应用(程序员层面上)。也可以说,TPC/IP协议是传输层协议,主要解决数据 如何在网络中传输,而HTTP是应用层协议,主要解决如何包装数据。关于TCP/IP和HTTP协议的关系,网络有一段比较容易理解的介绍:

“我们在传输数据时,可以只使用(传输层)TCP/IP协议,但是那样的话,如 果没有应用层,便无法识别数据内容,如果想要使传输的数据有意义,则必须使用到应用层协议,应用层协议有很多,比如HTTP、FTP、TELNET等,也 可以自己定义应用层协议。WEB使用HTTP协议作应用层协议,以封装HTTP文本信息,然后使用TCP/IP做传输层协议将它发到网络上。”

我们平时说的最多的socket是什么呢,实际上socket是对TCP/IP协议的封装,Socket本身并不是协议,而是一个调用接口(API),通过Socket,我们才能使用TCP/IP协议。 实际上,Socket跟TCP/IP协议没有必然的联系。Socket编程接口在设计的时候,就希望也能适应其他的网络协议。所以说,Socket的出现 只是使得程序员更方便地使用TCP/IP协议栈而已,是对TCP/IP协议的抽象,从而形成了我们知道的一些最基本的函数接口,比如create、 listen、connect、accept、send、read和write等等。网络有一段关于socket和TCP/IP协议关系的说法比较容易理 解:

“TCP/IP只是一个协议栈,就像操作系统的运行机制一样,必须要具体实现,同时还要提供对外的操作接口。这个就像操作系统会提供标准的编程接口,比如win32编程接口一样,TCP/IP也要提供可供程序员做网络开发所用的接口,这就是Socket编程接口。”

总结一些基于基于TCP/IP协议的应用和编程接口的知识,也就是刚才说了很多的 HTTP和Socket。

CSDN上有个比较形象的描述:HTTP是轿车,提供了封装或者显示数据的具体形式;Socket是发动机,提供了网络通信的能力。

实际上,传输层的TCP是基于网络层的IP协议的,而应用层的HTTP协议又是基于传输层的TCP协议的,而Socket本身不算是协议,就像上面所说,它只是提供了一个针对TCP或者UDP编程的接口。

下面是一些经常在笔试或者面试中碰到的重要的概念,特在此做摘抄和总结。

一、什么是TCP连接的三次握手

第一次握手:客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;

第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

握手过程中传送的包里不包含数据,三次握手完毕后,客户端与服务器才正式开始传送数据。理想状态下,TCP连接一旦建立,在通信双方中的任何一方主动关闭 连接之前,TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求,断开过程需要经过“四次握手”(过程就不细写了,就是服务器和客 户端交互,最终确定断开)

二、利用Socket建立网络连接的步骤

建立Socket连接至少需要一对套接字,其中一个运行于客户端,称为ClientSocket ,另一个运行于服务器端,称为ServerSocket 。

套接字之间的连接过程分为三个步骤:服务器监听,客户端请求,连接确认。

1。服务器监听:服务器端套接字并不定位具体的客户端套接字,而是处于等待连接的状态,实时监控网络状态,等待客户端的连接请求。

2。客户端请求:指客户端的套接字提出连接请求,要连接的目标是服务器端的套接字。为此,客户端的套接字必须首先描述它要连接的服务器的套接字,指出服务器端套接字的地址和端口号,然后就向服务器端套接字提出连接请求。

3。连接确认:当服 务器端套接字监听到或者说接收到客户端套接字的连接请求时,就响应客户端套接字的请求,建立一个新的线程,把服务器端套接字的描述发给客户端,一旦客户端 确认了此描述,双方就正式建立连接。而服务器端套接字继续处于监听状态,继续接收其他客户端套接字的连接请求。

三、HTTP链接的特点

HTTP协议即超文本传送协议(Hypertext Transfer Protocol ),是Web联网的基础,也是手机联网常用的协议之一,HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应,在请求结束后,会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

四、TCP和UDP的区别

1。TCP是面向链 接的,虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性,但TCP的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的 可靠性;而UDP不是面向连接的,UDP传送数据前并不与对方建立连接,对接收到的数据也不发送确认信号,发送端不知道数据是否会正确接收,当然也不用重 发,所以说UDP是无连接的、不可靠的一种数据传输协议。

2。也正由于1所说的特点,使得UDP的开销更小数据传输速率更高,因为不必进行收发数据的确认,所以UDP的实时性更好。

知道了TCP和 UDP的区别,就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了,但并不能说QQ的通信是不安全的,因为程序员可以手动对UDP 的数据收发进行验证,比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的,即使是这样,UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。

MySQL重置root密码方法

2017年2月15日 评论已被关闭

MySQL重置root密码方法

/etc/init.d/mysqld stop

mysqld –skip-grant-tables &

mysql -u root

update mysql.user set password=PASSWORD(‘root’) where User=’root’;

flush privileges;

quit

 

MySQL有时候忘记了root密码是一件伤感的事。这里提供Windows 和 Linux 下的密码重置方法。

Windows:

1.以系统管理员身份登陆系统。

2.打开cmd—–net start 查看mysql是否启动。启动的话就停止net stop mysql.

3.我的mysql安装在d:\usr\local\mysql4\bin下。

4.跳过权限检查启动mysql.

d:\usr\local\mysql\bin\mysqld-nt –skip-grant-tables

5.重新打开cmd。进到d:\usr\local\mysql4\bin下:

d:\usr\local\mysql\bin\mysqladmin -u root flush-privileges password “newpassword”

d:\usr\local\mysql\bin\mysqladmin -u root -p shutdown  这句提示你重新输密码。

6.在cmd里net start mysql

7.搞定了。

Linux:

MySQL root密码的恢复方法之一

如果忘记了MySQL root密码,可以用以下方法重新设置:

1.KILL掉系统里的MySQL进程;

killall -TERM MySQLd

2.用以下命令启动MySQL,以不检查权限的方式启动;

safe_MySQLd –skip-grant-tables &

3.然后用空密码方式使用root用户登录 MySQL;

MySQL -u root

4.修改root用户的密码;

MySQL> update MySQL.user set password=PASSWORD(‘新密码’) where User=’root’;

MySQL> flush privileges;

MySQL> quit

重新启动MySQL,就可以使用新密码登录了。

MySQLroot密码的恢复方法二

有可能你的系统没有 safe_MySQLd 程序(比如我现在用的 ubuntu操作系统, apt-get安装的MySQL) , 下面方法可以恢复

1.停止MySQLd;

sudo /etc/init.d/mysql stop

(您可能有其它的方法,总之停止MySQLd的运行就可以了)

2.用以下命令启动MySQL,以不检查权限的方式启动;

mysqld –skip-grant-tables &

3.然后用空密码方式使用root用户登录 MySQL;

MySQL -u root

4.修改root用户的密码;

MySQL> update MySQL.user set password=PASSWORD(‘newpassword’) where User=’root’;

MySQL> flush privileges;

MySQL> quit

重新启动MySQL

/etc/init.d/MySQL restart

就可以使用新密码 newpassword 登录了。

 

 

[root@TEST ~]# /etc/init.d/mysqld stop

Shutting down MySQL. SUCCESS!

[root@TEST ~]# mysqld –skip-grant-tables &

[2] 2425

170205 16:49:56 [Note] –secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled

170205 16:49:56 [Note] mysqld (mysqld 5.5.53-log) starting as process 2425 …

[root@TEST ~]# mysql -u root

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 1

Server version: 5.5.53-log MySQL Community Server (GPL)

 

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

 

Oracle is a registered trademark of Oracle Corporation and/or its

affiliates. Other names may be trademarks of their respective

owners.

 

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

 

MySQL [(none)]>

MySQL [(none)]> update mysql.user set password=PASSWORD(‘root’) where User=’root’;

Query OK, 2 rows affected (0.00 sec)

Rows matched: 2  Changed: 2  Warnings: 0

 

MySQL [(none)]> flush privileges;

Query OK, 0 rows affected (0.00 sec)

 

MySQL [(none)]> quit

Bye

[2]+  Exit 1                  mysqld –skip-grant-tables

[root@TEST ~]# /etc/init.d/mysqld start

Starting MySQL SUCCESS!

分类: Mysql数据库 标签:

PowerPC架构与X86架构

2017年2月14日 评论已被关闭

PowerPC架构与X86架构
http://blog.sina.com.cn/s/blog_6c9670bb0101slkh.html
PowerPC架构
PowerPC是一种精简指令集(RISC)架构的中央处理器(CPU),其基本的设计源自IBM(国际商用机器公司)的POWER(Performance Optimized With Enhanced RISC;《IBM Connect电子报》2007年8月号译为“增强RISC性能优化”)架构。POWER是1991年,Apple(苹果电脑)、IBM、Motorola(摩托罗拉)组成的AIM联盟所发展出的微处理器架构。PowerPC是整个AIM联盟平台的一部分,并且是到目前为止唯一的一部分。但苹果电脑自2005年起,将旗下电脑产品转用Intel CPU。

PowerPC的历史可以追溯到早在1990年随RISC System/6000一起被介绍的IBM POWER架构。该设计是从早期的RISC架构(比如IBM 801)与MIPS架构的处理器得到灵感的。

1990年代,IBM、Apple和Motorola开发PowerPC芯片成功,并制造出基于PowerPC的多处理器计算机。PowerPC架构的特点是可伸缩性好、方便灵活。第一代PowerPC采用0.6微米的生产工艺,晶体管的集成度达到单芯片300万个。1998年,铜芯片问世,开创了一个新的历史纪元。2000年,IBM开始大批推出采用铜芯片的产品,如RS/6000的X80系列产品。铜技术取代了已经沿用了30年的铝技术,使硅芯片多CPU的生产工艺达到了0.20微米的水平,单芯片集成2亿个晶体管,大大提高了运算性能;而1.8V的低电压操作(原为2.5V)大大降低了芯片的功耗,容易散热,从而大大提高了系统的稳定性。
X86架构
30年多前的1978年6月8日,Intel发布了新款16位微处理器“8086”,也同时开创了一个新时代:x86架构诞生了。 x86指的是特定微处理器执行的一些计算机语言指令集,定义了芯片的基本使用规则,一如今天的x64、IA64等。

事实上,8086处理器发布之初并没有获得太多关注,开始也没有被大范围采用,但它在PC业界的地位怎么形容都不为过,这就是因为它带来了x86。它不仅成就了Intel如日中天的地位,也成为了一种业界标准,即使是在当今强大的多核心处理器上也能看到x86的身影。在30年的发展史中,x86家族不断壮大,从桌面转战笔记本、服务器、超级计算机、编写设备,期间还挫败或者限制了很多竞争对手的发展,让不少处理器厂商及其架构技术成为历史名字,即使有些封闭发展的也难以为继,比如苹果就已经放弃PowerPC了。

当然,我们不能忘了x86-64和EM64T的斗争。2003年,AMD推出了业界首款64位处理器Athlon 64,也带来了x86-64,即x86指令集的64位扩展超集,具备向下兼容的特点。当时Intel也在推行64位技术,但其IA64架构并不兼容x86,只是用在服务器处理器Itanium上。为了和AMD展开竞争,Intel也在2004年推出了自己的64位版x86,也就是EM64T。对此,AMD和Intel互相指责对方,但无论如何至少推广了64位技术的发展和普及,也让x86技术得以继续发扬光大。加州大学伯克利分校计算机科学教授、RISC发明人之一David Patterson表示:“这证明,x86指令集的弹性完全可以拿来对付Intel,所以即使Intel统治了整个市场,其他公司依然可以改变x86的发展方向。”

x86是一个intel通用计算机系列的标准编号缩写,也标识一套通用的计算机指令集合,X与处理器没有任何关系,它是一个对所有*86系统的简单的通配符定义,例如:i386, 586,奔腾(pentium)。由于早期intel的CPU编号都是如8086,80286来编号,由于这整个系列的CPU都是指令兼容的,所以都用X86来标识所使用的指令集合如今的奔腾,P2,P4,赛扬系列都是支持X86指令系统的,所以都属于X86家族 。X86指令集是美国Intel公司为其第一块16位CPU(i8086)专门开发的,美国IBM公司1981年推出的世界第一台PC机中的CPU–i8088(i8086简化版)使用的也是X86指令,同时电脑中为提高浮点数据处理能力而增加的X87芯片系列数学协处理器则另外使用X87指令,以后就将X86指令集和X87指令集统称为X86指令集。虽然随着CPU技术的不断发展,Intel陆续研制出更新型的i80386、i80486直到今天的Pentium 4(以下简为P4)系列,但为了保证电脑能继续运行以往开发的各类应用程序以保护和继承丰富的软件资源,所以Intel公司所生产的所有CPU仍然继续使用X86指令集,所以它的CPU仍属于X86系列。

另外除Intel公司之外,AMD和Cyrix等厂家也相继生产出能使用X86指令集的CPU,由于这些CPU能运行所有的为Intel CPU所开发的各种软件,所以电脑业内人士就将这些CPU列为Intel的CPU兼容产品。由于Intel X86系列及其兼容CPU都使用X86指令集,所以就形成了今天庞大的X86系列及兼容CPU阵容。当然在目前的台式(便携式)电脑中并不都是使用X86系列CPU,部分服务器和苹果(Macintosh)机中还使用美国DIGITAL(数字)公司的Alpha 61164和PowerPC 604e系列CPU。

Intel从8086开始,286、386、486、586、P1、P2、P3、P4都用的同一种CPU架构,统称X86。英特尔推出X86架构已满30年了,同486相比,Pentium向前迈进了一大步, 而PⅡ的前进步伐则没有这么大了,X86 CPU的发展似乎已到了尽头。 英特尔非常清楚,是X86指令集限制了CPU性能的进一步提高,因此,他们正同惠普共同努力开发下一代指令集架构(Instruction Set Architecture ,ISA): EPIC(Explicitly Parallel Instruction Computing,显性并行指令计算)。对英特尔而言, IA-64(英特尔的64位架构)是下一个10到15年的架构。新的ISA将使英特尔摆脱X86架构的限制,从而设计出超越所有现有RISC CPU和X86 CPU的新型处理器。那么EPIC的先进之处在什么地方呢?为什么英特尔会放弃使它成为芯片巨人的X86架构呢? 一、IA-32的问题 我们知道,工程师可以通过提高每个时钟的指令执行数来提高性能,英特尔新的指令集的首要目的在于,让指令更容易解码,更容易并行执行。这样就可以不受限制地开发新型处理器。 但是,对工程师而言,兼容8086的X86指令集一直是必须完成的任务。毕竟,兼容前代产品是使英特尔成长壮大起来的关键因素,而且还可以保护用户原先的投资和使用数以百万计应用软件。

既然如此,为什么又要放弃整个X86指令集重新开始呢?X86的不足在什么地方?
(1)可变的指令长度 X86指令的长度是不定的,而且有几种不同的格式,结果造成X86 CPU的解码工作非常复杂,为了提高CPU的工作频率,不得不延长CPU中的流水线,而过长的流水线在分支预测出错的情况下,又会带来CPU工作停滞时间较长的弊端。
(2)寄存器的贫乏 X86指令集架构只有8个通用寄存器,而且实际只能使用6个。这种情况同现代的超标量CPU极不适应,虽然工程师们采用寄存器重命名的技术来弥补这个缺陷,但造成了CPU过于复杂,流水线过长的局面。
(3)内存访问 X86指令可访问内存地址,而现代RISC CPU则使用LOAD/STORE模式,只有LOAD和STORE指令才能从内存中读取数据到寄存器,所有其他指令只对寄存器中的操作数计算。在目前CPU的速度是内存速度的5倍或5倍以上的情况下,后一种工作模式才是正途。
(4)浮点堆栈 X87 FPU是目前最慢的FPU,主要的原因之一就在于X87指令使用一个操作数堆栈。如果没有足够多的寄存器进行计算,你就不得不使用堆栈来存放数据,这会浪费大量的时间来使用FXCH指令(即把正确的数据放到堆栈的顶部)。
(5)4GB限制 这似乎不是问题,但是,在6年前,主流PC只有4MB内存,而目前的绝大部分PC装备了64MB以上的内存,是以前的16倍,所以,在下一个十年,PC内存突破1GB绝对不会令人惊讶,而且目前的大型服务器已经使用了1GB以上的内存,突破4GB内存的情况很快就会出现。
(6)芯片变大 所有用于提高X86 CPU性能的方法,如寄存器重命名、巨大的缓冲器、乱序执行、分支预测、X86指令转化等等,都使CPU的芯片面积变得更大,也限制了工作频率的进一步提高,而额外集成的这些晶体管都只是为了解决X86指令的问题。

linux(centos)下安装php gd库

2017年2月13日 评论已被关闭

linux(centos)下安装php gd库

http://www.phpddt.com/server/984.html

最近帮人搭建了一个b2b网站,(Lamp安装教程),网站测试图片不能上传,经检查图片其实已经上传成功,只是因为php没有开启php gd库(上传图片后php对图片进行处理,加logo等),好吧,我就来搭建gd库了:

运行:  yum -y install php-gd

失败,显示如下:

yum.jpg这是因为没有第三方yum源支持的原因,于是我安装了:

wget http://www.atomicorp.com/installers/atomic

再次运行了命令,安装成功,测试 phpinfo();  还是没有成功,半天也没找到gd库!

我找到gd库的安装路径:/etc/php.d/gd.ini  发现内容为空,难怪,打开文件,加上这句:

extension=gd.so

重启服务器  service  httpd restart  终于看到亲爱的gd库了。

题外话:不用把全部东西都写在php.ini这个文件里,只是需要把*.ini文件写在/etc/php.d/文件夹就可以了,系统会自动把这个目录下的*.ini读入php.ini ; gd库的文件存放在:/usr/lib/php/modules/gd.so

分类: LAMP应用服务器 标签:

useradd

2017年2月13日 评论已被关闭

useradd 

http://sunwj.blog.51cto.com/5969096/1652978

【功能说明】:

create a new user or update default new user information   #新建用户或者更新用户信息

【语法格式】:

useradd [options] LOGIN

 

【选项参数】:

参数 说明
-c, –comment COMMENT 添加用户备注内容,对应/etc/passwd的第五列
-d, –home-dir HOME_DIR 制定用户家目录,而不使用默认值
-e, –expiredate EXPIRE_DATE 设置用户账号失效日期,格式为“YYYY-MM-DD”
-g, –gid GROUP 指定用户的初始用户组
-G, –groups GROUPS 指定用户的次要用户组
-m, –create-home 强制!要创建用户主文件夹(一般账号默认值)
-M, –no-create-home 强制!不要创建用户主文件夹(系统账号默认值)
-N, –no-user-group 不创建以用户名为名称的用户组
-r, –system 创建一个系统账号
-s, –shell SHELL 指定用户的shell,默认为/bin/bash
-u, –uid UID 指定用户的UID

【实践操作】:

1、创建用户useraa ,并添加说明内容

[root@Mode /]# useradd -c “boss” useraa

[root@Mode /]# tail -n 5 /etc/passwd

postfix:x:89:89::/var/spool/postfix:/sbin/nologin

sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin

tcpdump:x:72:72::/:/sbin/nologin

sun:x:500:500::/home/sun:/bin/bash

useraa:x:501:501:boss:/home/useraa:/bin/bash

2、创建用户userdd,并指定用户家目录为/dd/ 。 该目录无需事先创建

[root@Mode /]# useradd -d /dd/ userdd

[root@Mode /]# tail -n 3 /etc/passwd

userdd:x:504:504::/dd/:/bin/bash

useree:x:505:505::/home/useree:/bin/bash

userff:x:506:506::/home/userff:/bin/bash

3、创建用户useree,设置用户明天失效 。 下图中的16573为距离1970年1月1日,还有多少天账号失效

[root@Mode /]# date

Sun May 17 19:54:15 CST 2015

[root@Mode /]# useradd -e 2015-05-18 useree

[root@Mode /]# tail -n 2 /etc/shadow

userdd:!!:16572:0:99999:7:::

useree:!!:16572:0:99999:7::16573:

4、创建用户usergg,并指定初始用户组为groupa,次要用户组为groupb

[root@Mode /]# useradd  -g groupa -G groupb usergg

[root@Mode /]# id usergg

uid=507(usergg) gid=506(groupa) groups=506(groupa),507(groupb)

5、创建用户userhh,但不创建与其用户名相同的组 。 不过用户还是会归属于一个默认的组

[root@Mode /]# useradd -N userhh

[root@Mode /]# id userhh

uid=508(userhh) gid=100(users) groups=100(users)

6、创建系统账号userii。下面可看到该用户的uid 小于500,而且/home目录里面也没有该用户的主目录

[root@Mode /]# id userii

uid=498(userii) gid=498(userii) groups=498(userii)

[root@Mode /]# tail -n 2 /etc/passwd

userhh:x:508:100::/home/userhh:/bin/bash

userii:x:498:498::/home/userii:/bin/bash

[root@Mode /]# ls /home

sun  useraa  useree  userff  usergg  userhh

7、创建用户userjj,且不允许该账号登录系统(指定该用户的shell为/sbin/nologin)

[root@Mode /]# useradd -s /sbin/nologin userjj

[root@Mode /]# su – useraa

[useraa@Mode ~]$ exit

logout

[root@Mode /]# su – userjj

This account is currently not available.

[root@Mode /]#

[root@Mode /]# tail -n 2 /etc/passwd

userii:x:498:498::/home/userii:/bin/bash

userjj:x:509:509::/home/userjj:/sbin/nologin

8、创建用户userboss,指定UID为1000,初始用户组为 groupb ,次要用户组为 groupa ,添加用户说明,而且不创建与用户名同名的组

[root@Mode /]# useradd -u 1000 -g groupb -G groupa -N -c “this account is for boss” userboss

[root@Mode /]#

[root@Mode /]# id userboss

uid=1000(userboss) gid=507(groupb) groups=507(groupb),506(groupa)

[root@Mode /]#

[root@Mode /]# tail -n 1 /etc/passwd

userboss:x:1000:507:this account is for boss:/home/userboss:/bin/bash

分类: Linux命令大全 标签:

Mysql 5.7 root密码修改

2017年2月6日 评论已被关闭

Mysql 5.7 root密码修改

MySQL管理者密码设置或修改:

依据官方说明5.6以后版本,第一次启动时会在root目录下生产一个随机密码,文件名.mysql_secret。

[root@bright ~]# cat /root/.mysql_secret

# Password set for user ‘root@localhost’ at 2015-03-27 23:12:10

:Jj+FTiqvyrF

[root@bright ~]# cd /usr/local/mysql/bin/

[root@bright bin]# ./mysqladmin -u root -h localhost password ‘123456’ -p

Enter password: #此行输入.mysql_secret里第二行内容

mysqladmin: [Warning] Using a password on the command line interface can be insecure.

Warning: Since password will be sent to server in plain text, use ssl connection to ensure password safety.

官方的方式,笔者无论是否使用–skip-grant-tables启动mysql都测试失败,亲们可以测试:

shell>mysql -uroot -p’password’ #password即.mysql_secret里的密码

mysql>SET PASSWORD = PASSWORD(‘newpasswd’);

 

旧版本,安装后ROOT无密码,按如下操作:

方法一:

shell>service mysqld stop #停止mysql服务

shell>mysqld_safe –skip-grant-tables & #以不启用grant-tables模式启动mysql

shell>mysql -uroot -p #输入命令回车进入,出现输入密码提示直接回车。

mysql>use mysql;

mysql>update user set password=PASSWORD(“123456″)where user=”root”; #更改密码为 newpassord

mysql>flush privileges; #更新权限

mysql>quit #退出

方法二:

shell>service mysqld stop #停止mysql服务

shell>mysqld_safe –skip-grant-tables & #以不启用grant-tables模式启动mysql

shell>mysql -uroot -p #输入命令回车进入,出现输入密码提示直接回车。

mysql > set password for root@localhost = password(‘mysqlroot’);

方法三:

shell>/path/mysqladmin -u UserName -h Host password ‘new_password’ -p

 

分类: Mysql数据库 标签:

在nginx中禁止直接用ip访问及server_name特性

2017年2月6日 评论已被关闭

在nginx中禁止直接用ip访问及server_name特性

https://javawind.net/p121
看了很多nginx的配置,好像都忽略了ip直接访问web的问题,不利于SEO优化,所以我们希望可以避免直接用IP访问网站,而是域名访问,具体怎么做呢,看下面。
官方文档中提供的方法:
If you do not want to process requests with undefined “Host” header lines, you may define a default server that just drops the requests:
server {
listen 80 default_server;
server_name _;
return 444;
}
说白了就是只要是ip访问的直接重置444错误。但是这样好像又不太友好,如果能直接给跳转到该web server的网址就好了。
配置如下:
server {
listen 80 default_server;
server_name _;
rewrite ^ http://www.domain.com$request_uri?;
}
这样还是有一点问题,某些特别的地址,我需要用ip访问,其他的都禁止,如何配置呢?
比如说我想让监控宝直接用ip访问我的机器的nginx状态信息,其他的用ip访问的所有请求都跳转到域名上。
server {
listen 80 default_server;
server_name _;
location /xxxxx{
stub_status on;
access_log off;
}
location /{
rewrite ^ http://www.nginxs.com$request_uri?;
}
}
这样就实现了我们想要的功能了。
另外,在这里说一下server_name。server_name 是可以使用正则表达式的,这个功能因该说相当实用。
Nginx中的server_name指令主要用于配置基于名称的虚拟主机,server_name指令在接到请求后的匹配顺序分别为:
1、准确的server_name匹配,例如:
server {
listen 80;
server_name domain.com www.domain.com;

}
2、以*通配符开始的字符串:
server {
listen 80;
server_name *.domain.com; …
}
3、以*通配符结束的字符串:
server {
listen 80;
server_name www.*;

}
4、匹配正则表达式:
server {
listen 80;
server_name ~^(?.+)\.domain\.com$; …
}
nginx将按照1,2,3,4的顺序对server name进行匹配,只有有一项匹配以后就会停止搜索,所以我们在使用这个指令的时候一定要分清楚它的匹配顺序(类似于location指令)。
server_name指令一项很实用的功能便是可以在使用正则表达式的捕获功能,这样可以尽量精简配置文件,毕竟太长的配置文件日常维护也很不方便。下面是2个具体的应用:
1、在一个server块中配置多个站点:
server
{
listen 80;
server_name ~^(www\.)?(.+)$;
index index.php index.html;
root /data/wwwsite/$2;
}
站点的主目录应该类似于这样的结构:
/data/wwwsite/domain.com
/data/wwwsite/nginx.org
/data/wwwsite/baidu.com
/data/wwwsite/google.com
这样就可以只使用一个server块来完成多个站点的配置。
2、在一个server块中为一个站点配置多个二级域名。
实际网站目录结构中我们通常会为站点的二级域名独立创建一个目录,同样我们可以使用正则的捕获来实现在一个server块中配置多个二级域名:
server
{
listen 80;
server_name ~^(.+)?\.domain\.com$; index index.html;
if ($host = domain.com){ rewrite ^ http://www.domain.com permanent; }
root /data/wwwsite/domain.com/$1/; }
站点的目录结构应该如下:
/data/wwwsite/domain.com/www//data/wwwsite/domain.com/nginx/
这样访问www.domain.com时root目录为/data/wwwsite/domain.com/www/,nginx.domain.com时为/data/wwwsite/domain.com/nginx/,以此类推。
后面if语句的作用是将domain.com的方位重定向到www.domain.com,这样既解决了网站的主目录访问,又可以增加seo中对www.domain.com的域名权重。