HTTP协议

我是你的小阿磊

已于 2023-03-07 09:43:00 修改

阅读量317

点赞数

文章标签： http 服务器 java

于 2022-11-16 22:01:43 首次发布

原文链接：https://xiaolincoding.com/networ

版权

常见面试题

http缓存

强制缓存
协商缓存

他们虽然是客户端http的缓存，但是他们都是在服务端中设置，例如nginx

头部cache-control字段

此字段可以在请求头和响应头中设置，不过一般都是在响应头中返回。他是用来控制是否需要http缓存。作用域是http,server,location，示例

http{
    add_header Cache-Control private,max-age=36000;	//单位是秒
}

他的属性有（部分属性）：

max-age：缓存时间
no-cache：无需缓存
public：发送请求方是任何对象都可以缓存此资源，例如:发送请求的客户端，发送请求的服务器
private：只能是客户端才能缓存此资源
no-store：不缓存，类似于no-cache

强制缓存

http响应头会带有cache-control，expire 字段

cache-control优先级高于expire,会覆盖后者的信息。

http{
    add_header Cache-Control private,max-age=3600;	//单位是秒
    location ~ .*\.(js|css)$ {
     expires 10d;
	}
}

上面是缓存了1个小时，覆盖了expires

协商缓存

协商缓存是需要对比来判断是否判断使用缓存

有两种方法:

Last-Modified 和 expires
Etag 和 expire

Last-Modified 和 expires

客户端第一次请求服务端
服务端响应头返回Last-Modified (最后修改时间)
```
Last-Modified:Tue, 24 Feb 2019 08:01:04 GMT
```
客户端第二次请求服务端，请求头发送If-Modified-Sinice
```
If-Modified-Since:Tue, 24 Feb 2019 08:01:04 GMT
```
服务端获得If-Modified-Sinice，如果在这个时间之后有修改过资源则不走缓存

Etag 和 expire

HTTP协议规格说明定义ETag为“被请求变量的实体标记”。简单点即服务器响应时给请求URL标记，并在HTTP响应头中将其传送到客户端，类似服务器端返回的格式:

Etag:“5d8c72a5edda8d6a:3239″

客户端的查询更新格式是这样的:

If-None-Match:“5d8c72a5edda8d6a:3239″

如果ETag没改变，则返回状态304

不推荐，因为现在的服务都是集群形式，每台机器对资源的标识都是不同的，所以会Etag会对应不上，所以不走缓存

基于nginx配置

关闭Etag

http {
    etag off;
}

配置last-modified(默认开启)和expires

location ~.*\.(gif|jpg|jpeg|png|bmp|swf)$
{
    expires      30d;
}

location ~.*\.(js|css)?$
{
    expires      12h;
}

参考:https://www.cnblogs.com/kevingrace/p/10459429.html

https与http区别

http是明文传输，所以抓包是可以获取到内容信息并篡改，https解决了安全问题，他在http和tcp协议层中加了SSL/TSL协议，将数据进行了加密
http只需要在tcp层进行3次握手，就可以按http协议进行报文传输。https在tcp握手之后还需要进行SSL的握手过程
https默认是443端口
HTTPS需要向CA申请数字证书，来保证服务器身份可靠。（虽然服务器内也可以生成SSL公密钥，但是不是三方认证，所以客户端还是会显示不安全服务）

https解决了http的哪些问题

窃听风险：明文传输，混合加密的方式实现信息机密名
篡改风险：植入代码，摘要算法的方式实现完整性
冒充风险：假冒网站，将服务器公钥放入数字证书中，解决冒充风险

混合加密

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」(对称加密时使用的密钥)，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

对称加密只使用一个密钥(客户端和服务端都有一个密钥)，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥(客户端和服务端都有一对不同的公和私密钥)，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法

数字证书

户端没法保证服务端发过来的公钥就是安全的密钥，所以需要服务端拿着自己的公钥去去CA机构认证
CA机构用自己的私钥对 服务端的公钥+CA的数字签名+服务端信息 进行加密，生成数字证书
客户端发出https请求时，服务端向客户端发送数字证书，客户端获得数字证书去CA机构求证
CA通过他自己的私钥对数字证书进行解密，验证里面存放的数字签名
客户端求证数字证书合法，用CA的公钥去解数字证书，获得服务端的公钥。

TLS协议建立

clientHello

首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

在这一步，客户端主要向服务器发送以下信息：

（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

（2）客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。

（3）客户端支持的密码套件列表，如 RSA 加密算法。

serverHello

服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

（2）服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。

（3）确认的密码套件列表，如 RSA 加密算法。

（4）服务器的数字证书。

客户端响应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它非对称加密报文，向服务器发送如下信息：

（1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

（2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

服务端响应

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

然后，向客户端发送最后的信息：

（1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

http特性

http1.1 优缺点

优点

简单：header + body组成
灵活，易于扩展：
- 头部字段可以随意添加，状态码可以自定义
- 可以在传输层和应用层间扩展，例如TSL/SSL
应用广泛可跨平台

缺点

无状态（双刃剑）
- 好处：服务端不用做更多的标记，cpu占用率降低了
- 坏处：多个请求没有关联性，例如登陆成功后，下一个请求依然不法知道是否登陆。（需要借助cookie等外界存储）
明文传输
- 好处：调试方便
- 坏处：不完全，容易被篡改

https中间人

https绝对安全吗？

在这里插入图片描述
具体过程如下：

客户端向服务端发起 HTTPS 建立连接请求时，然后被「假基站」转发到了一个「中间人服务器」，接着中间人向服务端发起 HTTPS 建立连接请求，此时客户端与中间人进行 TLS 握手，中间人与服务端进行 TLS 握手；
在客户端与中间人进行 TLS 握手过程中，中间人会发送自己的公钥证书给客户端，客户端验证证书的真伪，然后从证书拿到公钥，并生成一个随机数，用公钥加密随机数发送给中间人，中间人使用私钥解密，得到随机数，此时双方都有随机数，然后通过算法生成对称加密密钥（A），后续客户端与中间人通信就用这个对称加密密钥来加密数据了。
在中间人与服务端进行 TLS 握手过程中，服务端会发送从 CA 机构签发的公钥证书给中间人，从证书拿到公钥，并生成一个随机数，用公钥加密随机数发送给服务端，服务端使用私钥解密，得到随机数，此时双方都有随机数，然后通过算法生成对称加密密钥（B），后续中间人与服务端通信就用这个对称加密密钥来加密数据了。
后续的通信过程中，中间人用对称加密密钥（A）解密客户端的 HTTPS 请求的数据，然后用对称加密密钥（B）加密 HTTPS 请求后，转发给服务端，接着服务端发送 HTTPS 响应数据给中间人，中间人用对称加密密钥（B）解密 HTTPS 响应数据，然后再用对称加密密钥（A）加密后，转发给客户端。

从客户端的角度看，其实并不知道网络中存在中间人服务器这个角色。那么中间人就可以解开浏览器发起的 HTTPS 请求里的数据，也可以解开服务端响应给浏览器的 HTTPS 响应数据。相当于，中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。

但是要发生这种场景是有前提的，前提是用户点击接受了中间人服务器的证书。

中间人服务器与客户端在 TLS 握手过程中，实际上发送了自己伪造的证书给浏览器，而这个伪造的证书是能被浏览器（客户端）识别出是非法的，于是就会提醒用户该证书存在问题。