赞
踩
数据通过网络发送,到达每一层,就要封装每一层的报文首部。http是应用层协议,所以封装的应用层header。
http协议的请求报文首部和响应报文首部结构不同。
1、 http请求报文结构可分三部分:开始行、首部行、请求数据实体。
首部字段名:值CRLF
,有多少字段,加多少字段,每一个字段的占一行,字段名和值之间的空格可选。2、 http响应报文结构也分为三大部分:开始行、首部行、请求数据实体。
状态码很重要。是判断访问成功与否的判断条件。
原因短语:接收前面状态码的含义,一句话描述
首部字段名:值CRLF
。通过**
curl -i +IP
**命令,就可以查看响应的所有信息,包括实体。
只看首部信息:curl -I +IP
。
GET:从服务器获取一个资源
HEAD:只从服务器获取文档的响应首部。通过curl -I +IP
命令就可以查看首部信息。
POST:向服务器输入数据,通常会再由网关程序继续处理
PUT:将请求的主体部分存储在服务器中,如上传文件
DELETE:请求删除服务器上指定的文档
TRACE:追踪请求到达服务器中间经过的代理服务器
OPTIONS:请求服务器返回对指定资源支持使用的请求方法
curl命令和telnet命令模拟查看响应的header信息
状态码代表的意义:
4xx:400-415
错误类信息,客户端错误5xx:500-505
错误类信息,服务器端错误常见状态码总结:
200
: 成功,请求数据通过响应报文的entity-body部分发送;OK301
: 永久重定向,意味着访问的域名以后不用了,永久重定向到新的域名。请求的URL指向的资源已经被删除;但在响应报文中通过首部Location指明了资源现在所处的新位置;Moved Permanently404
: 服务器无法找到客户端请求的资源;Not Found500
: 服务器内部错误;Internal Server Error1、首部的分类:
2、cookie
http协议是无状态的,协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别,协议对于发送过的请求或响应都不做持久化处理,确保协议的可伸缩性。比如淘宝购物,一旦刷新页面,购物车信息就没有了,又或者登陆一个网站,刷新或者关闭页面后重新打开,原来的登陆状态就没了。
Cookie技术可以保存通信状态。使用Cookie的状态管理技术,通过在请求和响应报文中写入Cookie信息来控制客户端的状态。Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息,通知客户端保存Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入Cookie值后发送出去。服务器端发现客户端发送过来的Cookie后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。如下图所示:
Set-cookie
字段。Cookie
字段和对应的cookie信息。Cookie
字段对应的值,识别出是哪一个客户端。Set-cookie首部字段示例:Set-Cookie: status=enable; expires=Fri, 24 Nov 2017 20:30:02 GMT; path=/;
Bool setcookie(string $name[, string $values, $expire=0[,string $path[,string $domain[, bool $secure = false[, bool $httpOnly = false]]]]] );
$name:cookie存储的名称,必填选项.
$values:cookie存储的值。这里需要注意的是,当把该值设置为false时,客户端会尝试删除这个cookie值,因此在要将值这是为true或者false的时候,我们用另外的值来代替,例如true用1代替,false用0来代替.
$expire:cookie的过期时间,秒为单位,当该值被设置时,定时删除;当该值没有设置时,该值是永久有效的.该值设置为小于当前时间时,会出发浏览器的删除机制,会自动删除cookie.
$path:cookie有效的目录,默认的目录是"/",即表示当前的正个域名都生效.
$domain:cookie的作用域名,默认的是当前域名有效,如果需要设置直接填写生效的域名即可.需要注意的是IE浏览器有长度限制,当只有大于5的时候才会生效.
$secure:cookie的加密处理,当设置为true的时候,需要使用HTTPS协议,才会生效.
$httpOnly:决定cookie是否只使用http协议,当设置为1或者true,其他非http协议是无法操作cookie的。例如我们未设置的时候,我们JavaScript是可以对cookie进行设置的.这样一定程度上保证了安全性.这种情况需考虑浏览器是否支持该配置项.
服务端未保存cookie
,只发送了Set-cookie
指令,再次通信如何根据cookie
识别出具体的客户端的? – session
3、session
session称为会话信息,位于web服务器上,主要负责访问者与网站之间的交互,当访问浏览器请求http地址时,将传递到web服务器上并与访问信息进行匹配,当关闭网站时就表示会话已经结束,网站无法访问该信息了,所以它无法保存永久数据。
session_id
发送给客户端。Set-cookie
指令,一并把session_id
保存在客户端的cookie
中。cookie
信息中识别出是哪一个客户端,并在服务端把具体的业务请求保存在session
文件中。比如,以购物车为例。初次请求客户端生成并保存了cookie文件,服务端生成并保存了session,session文件保存了购物车信息。
再次请求时,新增的物品,客户端根据cookie中的session_id直接识别出具体的客户端,直接更新session,实现了状态保持。
小结: cookie和session通常配合使用。session存储在服务端,cookie存储在客户端. 服务端向客户端发出cookie的创建指令,session的sessionid需要客户端存储.。二者的区别:
1、Cookie以文本文件格式存储在浏览器中,而session存储在服务端。
2、cookie的存储限制了数据量,只允许4KB,而session是无限量的。
3、我们可以轻松访问cookie值但是我们无法轻松访问会话值,因此它更安全。
4、设置cookie时间可以使cookie过期。
https:http over ssl。http在网络传输数据是明文的,通过wireshark等抓包工具甚至都能把用户名密码抓下来,不安全。
https基于安全的加密方式传输数据。
1、加密算法及ssl/tsl
科学的加密方式:算法可以公开,秘钥不公开,秘钥。加密算法分为对称加密和非对称(pki)加密。。加解密过程:明文data --> 加密(算法 + 秘钥key1) --> 密文data --解密(算法 + 秘钥key2) --> 明文data
非对称秘钥加密算法:key1 != key2。非对称加密算法更复杂,涉及到四把钥匙。一把公钥、一把私钥。
A给B发送数据为例:A、B都有有两把钥匙,一把公钥、一把私钥。那A给B的数据,B要能解密,则A必须用B的公钥加密(私钥不能外发,公钥可以外发,所以B可以提前拿到A的公钥),B用自己的私钥解密;B响应数据,只能用A的公钥加密,A收到响应数据,用A的私钥解密。
A用B的公钥加密:数据传出去,不被第三方截获,只有B接收道数据后能正常解密,确保了数据安全性。 – 数据加密
A用自己的私钥加密:其他人都可以拿A公钥解密,其他人的公钥解不开,且私钥只有本人持有,因此确保了消息的来源 – 数字签名
对称秘钥加密算法:key1 == key2,即数据发送方和接收方是同一把秘钥。对称加密只能实现数据的安全传输
非对称加密算法缺点:效率低,不适合加密大量数据。比如1G的数据,对称加密算法加解密可能只要几分钟,且数据不会特别大。非对称解密可能要小时计。
非对称加密算法使用场景:加密小文件。比如加密对称秘钥 – 假设A、B的对称秘钥为
key
,B的公钥为Pb
,A向B发起会话请求,则A用B的公钥Pb
加密对称秘钥key
:Pb(key) --> B
。
ssl/tsl协议就是这种通信机制。tls/ssl在传输层与应用层之间对网络连接进行加密。
https的通信机制就是ssl/tls。ip(tcp(tls(http(data)))):简单理解为https使用tls协议封装http协议的数据(tls把http数据加密了),然后再传给tcp。
A、B的公钥如何相信传过来的公钥就是对方的呢?假设还有个C,如果C劫持了A的会话请求,伪装B把自己的公钥传给A,那么A发送的所有数据C都可以解开,可怕!!! — CA证书
CA证书:颁发CA证书的机构,好比公安局,我们每个人都认可公安局颁发的身份证,自己持有的身份证就代表本人无疑,CA证书机构颁发的证书也代表了唯一的服务端。
A、B如何用CA交换公钥呢。
A、B,事先已经向互联网上可信的“公安局” – CA证书机构申请了“身份证“ – CA证书。因此A、B也有了CA的公钥。
如何生成证书:CA机构有自己的公钥和私钥。CA用自己的私钥把代表A身份的信息(A的公钥、国家、公司名称等等) + CA自己的信息 + 有效期等进行加密,加密后的东西就是CA证书了 --即上述的非对称加密的数字签名能力。
A把自己的证书发给B,B用CA机构的公钥解密证书内容就能够拿到A的公钥了。从而实现了公钥的交换。
这个时候,如果A想和B通信,A向B发起请求(首次请求的数据中,包含了自己支持哪些对称加密算法,因为对称加密要使用相同的加密算法)。
B响应请求,把证书发给A(同时选择对称加密算法),同时附带一个私钥加密的证书数字签名,用于验证证书的完整性。
A收到B发来的证书,使用CA的公钥解密得到了B的公钥。然后A再使用B的公钥解密数字签名,能解开说明证书是完整的。 另外,在一些安全性要求高的场景,B还要求(服务端)校验A的身份,这个时候A按照同样的方式把自己的证书和数字签名发给B。
验证完证书后,A使用B响应的对称加密算法,生成一个临时session secret(对称秘钥),并使用B的公钥这个数据发生给B。
B收到这个秘钥后,就用这个秘钥和之前协商好的对称算法,将A请求的数据加密发送给A。这样就建立起了SSL会话,从而使用对称加密安全的传输数据 。
PS:互联网上,涉及钱相关的网站,都已经向CA申请证书了。客户端访问这些网站的时候,都是走的https。
2、https实现
自签名证书: 自己给自己颁发证书,只需安装mod_ssl
软件包,就会生成自己的证书:yum -y install mod_ssl
。执行rpm -q -scripts mod_ssl
,可以查看生成的私钥和证书文件目录
配置httpd支持使用ssl,及使用的证书:执行完yum -y install mod_ssl
安装mod模块后,会自动在httpd的配置文件/etc/httpd/conf.d/ssl.conf
内加载了mod模块,使httpd支持ssl/tsl。同时,还会在配置文件中自动配置了证书和私钥的路径、https的443端口号监听。
查看配置文件/etc/httpd/conf.d/ssl.conf
中ssl相关的配置关键字:
SSLCertificateFile -- ssl证书文件关键字
SSLCertificateKeyFile -- ssl私钥文件关键字
ps: SSL是基于IP地址实现,单IP的主机仅可以使用一个https虚拟主机,基于域名的虚拟主机是不支持的
3、http重定向到https
Redirect代码方式实现(301、302重定向)。语法Redirect [status] URL-path URL
。status状态参数:
Permanent:Returns a permanent redirect status (301) indicating that the resource has moved permanently
Temp:Returns a temporary redirect status (302). This is the default
示例:Redirect temp / https://www.baidu.com/
。访问/
自动重定向到https://www.baidu.com/
。
存在的问题是第一次请求是http。
HSTS技术(307重定向):在有效期内浏览器内部自动跳转https。服务器端配置支持HSTS后,会在给浏览器返回的HTTP首部中携带HSTS字段。浏览器获取到该信息后,会将所有HTTP访问请求在内部做307跳转到HTTPS。而无需任何网络过程
HSTS preload list
:是Chrome浏览器中的HSTS预载入列表,在该列表中的网站,使用Chrome浏览器访问时,会自动转换成HTTPS,安装Chrome浏览器后就有了。web网站需要申请加入到HSTS列表后。Firefox、Safari、Edge浏览器也会采用这个列表。
示例,vim /etc/httpd/conf/httpd.conf。配置以下内容:
Header always set Strict-Transport-Security "max-age=15768000"
RewriteEngine on
RewriteRule ^(/.*)$ https://%{HTTP_HOST}$1 [redirect=301]
http2.4 MPM是以模块形式加载。切换mpm三种模式在配置文件修改:
cd etc/httpd/conf.modules.d/
路径下,有一个00-mpm.conf
专门的配置文件。
httpd压力测试工具ab
, 来自httpd-tools包: ab [OPTIONS] URL
-n
:总请求数
-c
:模拟的并行数
-k
:以持久连接模式测试
例如:切换mpm三种工作模式,测试处理请求能力的差异:ab -c 100 -n 1500 +url
。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。