HTTP协议

最新推荐文章于 2024-06-04 14:24:20 发布

原创最新推荐文章于 2024-06-04 14:24:20 发布 · 416 阅读

1 ·

CC 4.0 BY-SA版权

分布式专栏收录该内容

7 篇文章

订阅专栏

Http协议的组成

Request

Response

URL (Uniform Resource Locator)

URI (Uniform Resource Identifier)

Http协议的组成

通过抓包工具，可以看到如下的请求数据和响应数据。分为两部分，一个是客户端的请求信息，一个是服务端的响应信息。信息如下

Request

Response

URL (Uniform Resource Locator)

URL (Uniform Resource Locator)地址用于描述一个网络上的资源，基本格式。例如：https://tieba.baidu.com/f?ie=utf-8&kw=%E5%91%B5%E5%91%B5%E5%93%92&fr=search

schema://host[:port#]/path/.../?[url-params]#[ query-string]

schema：指定应用层使用的协议(如：http，https，ftp)

host：HTTP服务器的IP地址或者域名

port#：HTTP服务器的默认端口是80，这种情况下端口号可以省略。如果使用了别的端口号，必须指明

path：访问资源的路径

query-string：查询字符串

#：片段表示符(使用片段标识符通常可以标记出已获取资源中的子资源(文档内的某个位置))

URI (Uniform Resource Identifier)

每个web服务器资源都有一个名字，这样客户端就可以根据这个名字来找到对应的资源，这个资源称之为(统一资源标识符)

总结：URI是用一个字符串来表示互联网上的某一个资源。而URL表示资源的地点(互联网所在的位置)

方法

HTTP发起的每个请求，都需要告诉服务器要执行什么动作，那么这个动作就是前面报文中看到的method。http协议中提供了多个方法，不同方法的使用场景也不一样

GET：一般适用于客户端发送一个URI地址去获取服务端的资源（一般用于查询操作）

POST：一般客户端传输一个实体给到服务端，让服务端去保存（一般用于创建操作）

PUT：向服务器发送数据，一般用于更新数据的操作

HEAD：用于向服务端发起一个查询请求获取head信息，比如获取index.html的有效性、最近更新时间等等。

DELETE：客户端发起一个Delete请求要求服务端把某个数据删除（一般用于删除操作）

OPTIONS：查询指定URI支持的方法类型（get/post）

http1.1：还支持trace（追踪路径）和connect方法类型

HTTP协议的特点

HTTP协议是无状态的，就是说HTTP协议本身不会对请求和响应之间的通信状态做保存。

如何实现由状态的协议

http协议中引入了cookie技术，用来解决http协议无状态的问题。通过在请求和响应报文中写入Cookie信息来控制客户端的状态；Cookie会根据从服务端发送的响应报文内的一个Set-Cookie的首部字段信息，统治客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。

在基于tomcat这类的jsp/servlet容器中，会提供session这样的机制来保存服务端的对象状态。那么整个状态协议的流程就是这样的

HTTP协议的缺陷

1、通信过程中是使用明文的，内容可能会被窃听

2、不验证通信双方的身份

3、无法验证报文的完整性，报文可能被篡改

HTTPS的原理

HTTPS简介

由于HTTP协议通信的不安全性，所以人们为了防止信息在传输过程中遭到泄露或者篡改，就想出来对传输通道进行加密的方式https。

https是一种加密的超文本传输协议，它与http协议的差异在于对数据传输的过程中，https对数据做了完全加密。由于http协议或者https协议都是处于TCP传输层之上，同时网络协议又是一个分层的结构，所以在TCP协议层之上增加了一层SSL(Secure Socket Layer，安全层)或者TLS(Transport Layer Security)安全层传输协议组合使用用于构造加密通道。

HTTPS的实现原理

客户端发起请求(Client Hello 包)
1. 三次握手，建立TCP连接
2. 支持的协议版本(TLS/SSL)
3. 客户端生成的随机数client.random，后续用于生成“对话密钥”
4. 客户端支持的加密算法
5. sessionid，用于保持同一个会话(如果客户端与服务器费尽周折建立了一个HTTPS连接，刚建完就断了，是很可惜的一件事情)
服务端收到请求，然后响应(Server Hello)
1. 确认加密通道协议版本
2. 服务端生成的随机数server.random，后续用于生成“对话密钥”
3. 确认使用了加密算法(用于后续的握手消息进行签名防止篡改)
4. 服务器证书(CA机构办法给服务端的证书)
客户端收到证书进行验证
1. 验证证书是否是上级CA签发的，在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证，只有路径中所有的证书都是受信的，整个验证的结果才是受信
2. 服务端返回的证书中会包含证书的有效期，可以通过失效日期来验证，证书是否过期
3. 验证证书是否被吊销
4. 前面我们知道CA机构在签发证书的时候，都会使用自己的私钥对证书进行签名。证书里的签名算法字段sha256RSA表示CA机构使用sha256对证书进行摘要，然后使用RSA算法对摘要进行私钥签名，而我们也知道RSA算法中，使用私钥签名之后，只有公钥才能进行验签。
5. 浏览器使用内置在操作系统上的CA机构的公钥对服务器的证书进行验签。确定这个证书是不是由正规的机构颁发。验签之后得知CA机构使用sha256进行证书摘要，然后客户端再使用sha256对证书内容进行一次摘要，如果得到的值和服务端返回的证书验签之后的摘要相同，表示证书没有被修改过
6. 验证通过后，就会显示绿色的安全字样
7. 客户端生成随机数，验证通过之后，客户端会生成一个随机数pre-master secret，客户端根据之前的：Client.random + server.random + pre-master 生成对称密钥然后使用证书中的公钥进行加密，同时利用前面协商好的加密算法，讲握手消息取hash值，然后用”随机数加密“握手消息+握手消息hash值(签名)然后传递给服务器端；(在这里之所以要取握手消息的hash值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。)
服务器接收随机数
1. 服务端收到客户端的加密数据以后，用自己的私钥对密文进行解密。然后得到client.random/server.random/pre-master secret，再用随机数密码解密握手消息与hash值，并与传过来的hash值做对比确认是否一致。
2. 然后用随机密码加密一段握手消息(握手消息+握手消息的hash值)给客户端
客户端接收消息
1. 客户端用随机数解密并计算握手消息的hash，如果与服务端发来的hash一致，此时握手过程结束；
2. 之后所有的通信数据将由之前交互过程中生成的pre-master secret/client.random/server.random通过算法得出session Key，作为后续交互过程中的对称密钥