计算机网路基础8 -- http协议和数据加密

4.4 http协议

数据通过网络发送，到达每一层，就要封装每一层的报文首部。http是应用层协议，所以封装的应用层header。

4.4.1 http报文结构

http协议的请求报文首部和响应报文首部结构不同。

1、 http请求报文结构可分三部分：开始行、首部行、请求数据实体。

• 开始行：由方法 + url + 版本号组合而成，中间有空格，末尾为回车换行符。
• 首部行：首部的各种字段，结构为首部字段名：值CRLF，有多少字段，加多少字段，每一个字段的占一行，字段名和值之间的空格可选。
• 请求数据实体： 请求数据实体与首部行隔一个空行，即敲两个回车。对于一般的Get请求没有实体，有些方法比如上传文件，则有实体，实体就是文件的数据流。

http请求报文

http报文语法格式

请求报文首部抓包示意图

2、 http响应报文结构也分为三大部分：开始行、首部行、请求数据实体。

• 开始行： 由 版本号 + 状态码 + 短语组合而成，中间有空格，末尾为回车换行符。注意与请求报文的区别！

状态码很重要。是判断访问成功与否的判断条件。
原因短语：接收前面状态码的含义，一句话描述

• 首部行： 响应首部行包含了web服务器的版本等信息。结构为首部字段名：值CRLF。
• 响应数据实体：

通过**curl -i +IP**命令，就可以查看响应的所有信息，包括实体。
只看首部信息：curl -I +IP。

http响应报文

响应报文首部抓包示意图

4.4.2 请求中的method

GET：从服务器获取一个资源
HEAD：只从服务器获取文档的响应首部。通过curl -I +IP命令就可以查看首部信息。
POST：向服务器输入数据，通常会再由网关程序继续处理
PUT：将请求的主体部分存储在服务器中，如上传文件
DELETE：请求删除服务器上指定的文档
TRACE：追踪请求到达服务器中间经过的代理服务器
OPTIONS：请求服务器返回对指定资源支持使用的请求方法

curl命令和telnet命令模拟查看响应的header信息

4.4.3 响应中的状态码status code

状态码代表的意义：

• 1xx：100-101 信息提示
• 2xx：200-206 成功
• 3xx：300-305 重定向
• 4xx：400-415 错误类信息，客户端错误
• 5xx：500-505 错误类信息，服务器端错误

常见状态码总结：

• 200： 成功，请求数据通过响应报文的entity-body部分发送;OK
• 301： 永久重定向，意味着访问的域名以后不用了，永久重定向到新的域名。请求的URL指向的资源已经被删除；但在响应报文中通过首部Location指明了资源现在所处的新位置；Moved Permanently
• 302： 临时重定向，重定向前、后的域名都要用。响应报文Location指明资源临时新位置 Moved Temporarily
• 304： 使用本地缓存的页面。客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过响应此响应状态码通知客户端；Not Modified
• 401： 需要输入账号和密码认证方能访问资源；Unauthorized
• 403： 请求被禁止；Forbidden
• 404： 服务器无法找到客户端请求的资源；Not Found
• 500： 服务器内部错误；Internal Server Error
• 502： 大型网站的外部请求一般先通过代理服务器接收请求，然后根据请求类型转发到后端服务器处理请求，如果实际处理请求的后端服务器出故障了无法响应请求，这个时候就会报502错误码。
• 503 – 服务不可用，比如服务器处于维护状态或者过载，无法处理请求
• 504 – 网关超时，迟迟无法响应。

4.4.4 首部行中的首部字段

1、首部的分类：

• 通用首部: 请求报文和响应报文两方都会使用的首部。

通用首部

• 请求首部: 只有客户端向服务器端发送请求报文时才包含的首部字段。

请求首部

特殊的请求首部

• 响应首部：从服务器端向客户端返回响应报文时才有的首部字段，比如web服务器版本。

响应首部

• 实体首部：当报文中有实体信息时，补充了资源内容更新时间等与实体有关的的信息。

实体首部

2、cookie
http协议是无状态的，协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理，确保协议的可伸缩性。比如淘宝购物，一旦刷新页面，购物车信息就没有了，又或者登陆一个网站，刷新或者关闭页面后重新打开，原来的登陆状态就没了。

Cookie技术可以保存通信状态。使用Cookie的状态管理技术，通过在请求和响应报文中写入Cookie信息来控制客户端的状态。Cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。如下图所示：

• 客户端首次与服务端发起请求时，服务端的响应报文首部字段中有一个Set-cookie字段。
• 服务端收到响应报文后，将cookie信息以文本形式保存在客户端本地。当下次发起请求时，在请求首部字段中带上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的创建指令。
• 服务端收到请求后，在服务端创建并保存唯一的session文件，并在响应的首部字段中将这个session文件的编号session_id发送给客户端。
• 客户端根据响应字段的Set-cookie指令，一并把session_id保存在客户端的cookie中。
• 再次通信的时候，服务端就可以从cookie信息中识别出是哪一个客户端，并在服务端把具体的业务请求保存在session文件中。

比如，以购物车为例。初次请求客户端生成并保存了cookie文件，服务端生成并保存了session，session文件保存了购物车信息。
再次请求时，新增的物品，客户端根据cookie中的session_id直接识别出具体的客户端，直接更新session，实现了状态保持。

session_cookie建立过程

小结： cookie和session通常配合使用。session存储在服务端，cookie存储在客户端. 服务端向客户端发出cookie的创建指令，session的sessionid需要客户端存储.。二者的区别：

1、Cookie以文本文件格式存储在浏览器中，而session存储在服务端。
2、cookie的存储限制了数据量，只允许4KB，而session是无限量的。
3、我们可以轻松访问cookie值但是我们无法轻松访问会话值，因此它更安全。
4、设置cookie时间可以使cookie过期。

4.4.5 https

https：http over ssl。http在网络传输数据是明文的，通过wireshark等抓包工具甚至都能把用户名密码抓下来，不安全。
https基于安全的加密方式传输数据。

1、加密算法及ssl/tsl
科学的加密方式：算法可以公开，秘钥不公开，秘钥。加密算法分为对称加密和非对称（pki）加密。。加解密过程：明文data --> 加密（算法 + 秘钥key1） --> 密文data --解密（算法 + 秘钥key2） --> 明文data

非对称秘钥加密算法：key1 != key2。非对称加密算法更复杂，涉及到四把钥匙。一把公钥、一把私钥。

• public：公钥。公开的，到处都可以发
• private（secret）：私钥。私有的，不能给别人看。
• 公钥和私钥是成对的。公钥加密的数据只能用私钥解密，而私钥加密的数据只能用公钥解密。换句话说，A的公钥加密的数据，只能用A的私钥解码;A的私钥加密的数据，只能用A的公钥解密。

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。

• 作为客户端，装上浏览器时，就已经装上了互联网上各种可信的CA公钥。
• web服务端，向CA证书颁发机构实现申请了CA证书，因此也有了CA公钥。
• 所以https请求，web服务器发来的证书后，客户端自动拿CA公钥解密拿到web服务器的公钥，从而加密实现通信。
• 有些网站，比如12306，不是用的互联网上公认的CA证书颁发机构颁发的证书，而是自己搭建的CA证书服务器，自己给自己颁发证书。因此客户端浏览器安装的时候不会带上这些非公认的证书颁发机构，因此会报"您的连接不是私密连接"告警。

查看客户端证书颁发机构

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私钥文件关键字

httpd加载mod模块

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]

4.5 http2.4

http2.4 MPM是以模块形式加载。切换mpm三种模式在配置文件修改：
cd etc/httpd/conf.modules.d/路径下，有一个00-mpm.conf专门的配置文件。

http2.4mpm配置文件

httpd压力测试工具ab, 来自httpd-tools包： ab [OPTIONS] URL

-n：总请求数
-c：模拟的并行数
-k：以持久连接模式测试
例如：切换mpm三种工作模式，测试处理请求能力的差异：ab -c 100 -n 1500 +url。