前言:
上一篇博文已经说到了,apache2.4简单的配置,端口,持久连接,MPM,DSO,路径下基于来源控制,页面特性,日志设置
安全域,虚拟主机等等。
一:URL
URL是互联中获取标记资源的方式,URL的组成由URL方案(scheme),服务器地址(ip+port)和资源路径构成。例如http://www.xxyy.com/bbs/index.index
语法:<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
- scheme:资源的访问方法,例如http,ftp
- user:password:访问网站的账号密码,一般只用于http协议本身的Basic认
- host:主机地址
- port:端口号,http协议默认使用80
- path:(/)下相对http主页下的相对资源路径
- params:参数,url能提供多个参数中间使用&隔开
- query:查询语句,问号(?)之后调用查询语句,多个语句使用&隔开
- frag:片断,类似书签,能够标识网络资源中的具体地址
这里重点介绍query和frag:
query是简单的调用查询语句,在搜索引擎中通常将其键值输出给其引擎,例如:http://www.baidu.com/baidu?&ie=utf-8&word=1
frag类似于书签的功能,能够准确标明资源中的片段,例如:http://baike.baidu.com/item/黄蓉?fr=aladdin#2_5
二、协议
http协议是一种无状态(stateless)协议,自身不能辨认客户端,无法追踪访问者来源。虽然tcp/ip协议在一定程度上辅助http确认客户端来源,但是在某些特定情况下,比如keepalive的时候,不会第一时间断开tcp连接能够在未达到访问限制之前的无限请求资源,这种情况下tcp/ip协议并不能发挥作用。
如果这时候刷新一下页面,购物车里的物体全部消失(这样的世界真美好),连买买买的*都没有,何谈用户体验。
所以嘛,需要一种机制能够准确的追踪客户端来源,标识客户端,此方式表示cookie机制。
当客户端第一次访问某站点时,站点响应客户端资源,同时会发送一串唯一的随即数据,也就是cookie,以便标记客户端。cookie会记录客户端所有的访问行为,且有着属于自己的的作用范围,换言之,只要访问同一站点,皆会被服务器辨识。
不过,由于所有的访问行为都由cookie记录,同时也就注定自身安全性不足。
任何人,只要能够获取到某用户的cookie,便能完全访问过去该用户所进行的所有资源。
显然,存在缺陷的cookie,并不能让用户完全的放心使用。这就需要另一种全新的机制,即轻cookie+session
轻cookie同样保存用户信息,但却不记录用户的访问行为,访问行为由服务器通过session机制进行保存。(session保存着客户端的精简数据结构)
当用户第一次访问站点时,站点同样是响应资源和发送cookie,只是此后所有的访问行为都是存储在服务器的RAM中,每次访问都会跟新其值。
服务器通过cookie和session二者结合的数据结构便能辨别客户端。
当然,这仅仅只是精简的说明。
三、事务:
http事务:
请求:request
响应:response
报文语法:
request:
<method><request:URL><version>
<headers>
<request>
response:
<version><status><reason-phrase>
<headers>
<entity-body>
method:请求方法:标明客户端希望服务器对资源执行的操作
GET:从服务器上获取资源
HEAD:只从服务器上获取响应首部
POST:向服务器发送要处理的数据
PUT:将请求的主体部分存储在服务器上
DELETE:删除服务器上的文档
TRACE:追踪请求到服务器过程中经过的代理服务器
OPTIONS:请求服务器放回对指定资源使用的请求方法
这里主要讨论POST和PUT区别,POST方法作用于一个资源集(bbs/)上,PUT方法作用于一个具体资源(bbs/index.html)上,换句话说POST相当于创建一个资源会生成全新的URL,且每次使用POST都是创建全新资源,(通常而言,服务器不允许过多的创建文件),而PUT相当于更新资源,即无论操作多少次都不会出现不同URL,且PUT方法本身是幂等的。
version:HTTP的版本号
status:状态码,如201,304,403
常见状态码:
200:成功,请求的所有数据通过响应报文的entity-body发送;ok
301:请求的URL指向的资源已经被删除,但响应报文通过首部Location指向现在的新位置;Moved Permanently
302:与301相似,但在响应报文中透过首部Location指明资源临时新位置;Found
304:客户端发起条件式请求,但服务器端资源没有发生改变,则通过响应此状态码回应客户端;Not Modifed
401:需要输入账号密码才能访问;Unauthorized
403:请求被拒绝;Forbidden
404:服务器无法找到客户端请求的资源;Not Found
505:服务器内部错误;internal Server Error
502:代理服务器从后端服务器收到了一条伪响应;bad Gateway
reason-phrase:
状态码的简易描述
headers:
每个请求或响应报文可包含任意首部;每个首部都有首部名称,后面跟一个冒号,而后跟上一个空格,接着一个值
格式:
Name: value
首部分类:
通用首部
请求首部
响应首部
实体首部
扩展首部
通用首部:
Date:报文响应日期
connecttion:连接方式,如keepalive
Via:显示报文经过的中间节点
cache-Control:缓存控制
pragma:HTTP1.0缓存
请求首部:
Accept:告诉服务器端自己可接受的的MIME类型
Accept-Charset 可接受的字符集
Accept-Encoding 可接受的编码格式,如gzip
Accept-Language 可接受的语言
Host:请求服务器的名称和端口号
Referer:告诉服务器自己是从哪个页面跳转过来的
User-Agent:客户端代理
条件是请求首部:
Expect:希望服务器发送的
If-Modifed-since:自从某个时间点后资源是否有发生变化
If-Unmodifed-since:自从某个时间点后资源是否没有发生变化
If-None-Match:本地缓存中的文档的ETag标签是否与服务器端ETag的不匹配
if-Match:本地缓存中的文档的ETag标签是否与服务器端ETag的匹配
安全请求首部:
Authorization:向服务器提供认证信息,如帐号密码
cookie:向服务器端发送cookie
代理请求首部:
Proxy-Authorization:相代理服务器认证
响应首部:
Age:响应持续时长
Server:服务器程序名称和版本
协商响应首部:
Accept-Ranges:服务器可接受的请求范围
Vary:服务器查看的其他首部列表(之中包含都是可变化的值)
安全响应首部:
Set-Cookie:向客户端设置cookie
www-Authenticate 服务器端对客户端的咨询认证表单
实体首部:
Allow:列出对资源可请求的方法
Location:告诉客户端真正实体位于何处
Content-Ecoding:主体编码格式
Content-Language:主体语言
Content-Lengh:主体长度
Content-Location:主体真正所在位置
Content-type:主体类型
缓存相关:
ETag:实体扩展的标签
Expires:实体过期的时间
Last-Modifed:主体最后一次修改的时间
这里主要讨论Vary、Location、Content-Location的区别,放入Vary的首部信息的内容皆是不确定的可变化的值,当需要获取一个不确定值时,便可将其放入。
比如Vary:Accept-Ecoding能够使得服务器端获取各式各样的编码格式。
如此在缓存服务器下,不同资源便是采取不同的缓存编码,css,jpg的静态资源启动gzip;php则不采取缓存。
再比如,Vary:User-agent能够使得缓存服务器根据不同的浏览器类型缓存不同的内容。
Location和Content-Location皆是指明主体资源真正的所在位置,前者指的是重定向的地址,后者指的时能够直接访问资源的地址,不需要进一步内容协商。
entity-body:
文档主体,使用PUT和POST方法才有主体,一般而言使用GET方法没有主体信息
一次完整http事务由http请求和http响应构成,请求报文和响应报文包含大量的headers来描述资源之间的交换。通过了解首部信息,能够判断资源是否能够完成的基本标准。
更重要的是,能够通过首部进行负载均衡。
四、https
http是明文协议,注定了信息的不安全性。
https协议便是http的通信加密方式。
https协议先进行tcp/443三次握手,之后进行ssl回话握手,随后再进行http协议。http和http除却tcp连接之外,还多进行了一次ssl握手,进行ssl握手之后所有进出的信息皆会被加密。
ssl位于传输层和应用层之间的半层,所以进行传输前必须要后tcp建立ssl连接,先tcp断开ssl连接。
注:https进行加密传输,必定会有额外消耗,在高负载的情况下会给CPU极大的压力,所以一般需要能够缓存ssl回话的硬件缓存,以便减少服务器压力。
以下是SSL简易会话过程:
(1)客户端发送可供选择的加密方法发送给服务器端
(2)服务器端发送证书及选定的加密方法给客户端
(3)验证证书:
如果信任发证书的CA:
(a)验证证书来源合法性,用CA的公钥解密证书上数字签名
(b)验证证书的内容合法性,完整性验证
(c)检查证书的有效期限
(d)检查证书是否被吊销
(e)证书中拥有者的姓名,与访问的目标主机要一致
(4)客户端生成临时会话密钥(对称密钥),并使用服务器端侧的公钥加密发送给服务器端,完成密钥交换
(5)服务器用此密钥加密用户请求的资源,响应给客户端
注:ssl是基于IP地址创建的,所以单IP主机上,仅可以使用一个https虚拟主机(一般而言)
以下,内部网络的私有CA建立过程及ssl回话过程。
#cd /etc/pki/CA #建立私有CA,在另一条主机上完成
#(umask 077;openssl genrsa -out private/cakey.pem 2048) #密钥
#touch index.txt
#echo 01> serial
#openssl req -new x509 -key private/cakey.pem -out cacert.pem -days 7200 #私有证书
#cd /etc/httpd/ #客户端
#mkdir ssl
#cd ssl
#(umask 077;openssl genrsa -out httpd.key 1024) #生成密钥
#openssl req -new -key httpd.key -out httpd.csr -days 3600 #证书签署请求
#scp httpd.csr root@172.16.100.1:/tmp #发送给服务器
#openssl ca -in /tmp/httpd.csr -out certs/httpd.crt -days 3600 #CA服务器签署证书
#ls certs/
#scp certs/httpd.crt root@192.168.139.134:/etc/httpd/ssl/ #发还给客户端
#yum -y install mod_ssl #客户端
#cd /etc/httpd/conf.d
#cp ssl.conf{,.bak}
#vim ssl.conf
DocumentRoot “/vhosts/web2htdocs”
ServerName web1.xxyy.com
SSLCertificateFile /etc/httpd/ssl/httpd.crt #证书文件,签署过的证书
SSLCertificateKeyFile /etc/httpd/ssl/httpd.key #密钥
<VirtualHost *:80> #在虚拟主机设置中打开SSL引擎
SSLengine on
SSLCertificateFile /etc/httpd/ssl/httpd.crt
SSLCertificateKeyFile /etc/httpd/ssl/httpd.key
以上,便是SSL的简易配置。