HTTP（HyperText Transfer Protocol，超文本传输协议）是用于在万维网（World Wide Web）上传输超文本的基础协议。它定义了客户端（通常是浏览器）和服务器之间的文本数据传输格式和规则。以下是HTTP的详细介绍：

应用场景:

HTTP协议广泛应用于网页浏览、API通信、文件下载等场景。它的简单性和扩展性使其成为互联网数据传输的基础。

总结起来，HTTP作为应用层协议，通过定义客户端和服务器之间的通信规则，支持了现代互联网的许多关键功能。
HTTP报文格式包括请求报文和响应报文两种。每种报文由三部分组成：起始行、头部和主体。下面是详细介绍：

HTTP

1. 客户端和服务器：

   • 客户端：发起请求的一方，通常是浏览器。
   • 服务器：处理请求并返回响应的一方，通常是Web服务器。

2. 资源：

   • HTTP用于请求和传输资源，这些资源可以是HTML文档、图片、视频、脚本文件等。

HTTP请求报文

HTTP报文包括请求报文和响应报文。

请求行

包括HTTP方法、请求的资源路径和HTTP版本。例如：GET /index.html HTTP/1.1

请求方法：

1. GET： 请求指定的资源。通常用于获取数据，且不会对服务器上的资源产生副作用。

2. POST：向服务器提交数据，通常用于表单提交、文件上传等操作。

3. PUT： 向服务器上传文件或资源，可以用来创建或更新资源。

4. DELETE：请求服务器删除指定的资源。

5. HEAD：类似于GET请求，但只返回响应的头部，不返回实际内容。用于检查资源的元数据。

6. OPTIONS：请求服务器返回支持的HTTP方法。用于查询服务器的能力。

7. PATCH： 用于对资源进行部分修改。

请求头部：

包括各种请求头字段，如Host、User-Agent、Accept等。

HTTP请求报文示例:
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

常见请求头字段

1. Host：请求的主机名和端口。
2. User-Agent：客户端软件的信息。
3. Accept：客户端可处理的媒体类型。
4. Accept-Encoding：客户端可处理的内容编码。
5. Cookie：客户端存储的Cookie数据。
6. Content-Type：请求主体的媒体类型。
7. Content-Length：请求主体的长度。

请求主体：

可选，用于POST或PUT请求传输数据。一般是提交的表单数据等。GET请求通常没有主体。

请求报文示例：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

HTTP响应报文

1. 状态行 (Status Line)

状态行包含HTTP版本、状态码和状态描述。格式如下：

 <状态码> <状态描述>

例如：HTTP/1.1 200 OK

HTTP状态码
服务器在响应中返回的状态码，用于表示请求的处理结果。常见状态码有：

1. 2xx 成功：

• 200 OK：请求成功。
• 201 Created：请求成功并创建了新的资源。

2. 3xx 重定向：

• 301 Moved Permanently：资源永久移动到新位置。
• 302 Found：资源暂时移动到新位置。

3. 4xx 客户端错误：

• 400 Bad Request：请求有误，服务器无法处理。
• 401 Unauthorized：未授权，需要身份验证。
• 403 Forbidden：服务器拒绝请求。
• 404 Not Found：请求的资源不存在。

4. 5xx 服务器错误：

• 500 Internal Server Error：服务器内部错误。
• 503 Service Unavailable：服务器暂时无法处理请求。

2. 响应头部 (Response Headers)

响应头部由多个头字段组成，每个字段包含一个名称和值，用冒号分隔。头部字段提供了关于服务器和返回资源的信息。格式如下：

<头字段名>: <字段值>

例如：

Content-Type: text/html
Content-Length: 1234
Set-Cookie: sessionId=abc123

1. Date：响应生成的日期和时间。
2. Content-Type：响应主体的媒体类型。
3. Content-Length：响应主体的长度。
4. Set-Cookie：设置Cookie信息。
5. Cache-Control：缓存策略。

3. 响应主体 (Response Body)

响应主体包含实际返回的数据，如HTML文档、图片、JSON数据等。

HTTP响应报文示例

HTTP/1.1 200 OK
Date: Tue, 30 Jul 2024 12:34:56 GMT
Content-Type: text/html
Content-Length: 1234




    


    
Hello, World!

HTTPS

使用http协议在网络上传输是明文传输，没有丝毫的安全性，容易被人窃取重要数据从而造成隐式泄露和经济损失，所以需要对http的文本数据进行加密处理，https就是http协议加密版本。了解https的加密原理，需要先把下面几个概念搞清楚。以下是关于HTTPS的详细介绍：

HTTPS与HTTP的区别

安全性：
HTTPS使用SSL/TLS协议加密数据，提供安全通信。
HTTP以明文传输数据，易受攻击。
端口：
HTTPS通常使用TCP端口443。
HTTP通常使用TCP端口80。
性能：
HTTPS的加密和解密过程可能导致性能开销。
现代协议和硬件加速技术（如HTTP/2、TLS 1.3）大大减少了开销。

加密方式

对称加密：
对称加密就是加密和解密都会使用同一个密钥，例如：

加密：

明文：1234，密钥：8888   加密方式：使用密钥异或（^）明文，得到的就是加密后的数据，然后在异或就能得到原来的数据

0000 0100 1101 0010			（明文：1234的二进制数据）
0010 0010 1011 1000			（密钥：8888的二进制数据）
0010 0110 0110 1010         （密文：加密后的数据，使用异或的规则，相同为0，相异为1，十进制数据是9834）

解密：

密文：9834，密钥：8888   解密方式：使用密钥异或（^）密文，得到的就是解密后的数据。

0010 0110 0110 1010         （密文：十进制数据是9834）
0010 0010 1011 1000			（密钥：8888的二进制数据）
0000 0100 1101 0010			（明文：异或之后得到了原来的明文：1234）

对称加密特点

• 采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的
• 常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼

非对称加密：

• 非对称加密就是有两把密钥，分为公钥和私钥，一把用来加密，一把用来解密，可以用公钥加密，私钥解密，反过来也可以。
• 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。

数据摘要

数据摘要（Data Digest），又称为消息摘要（Message Digest）或哈希值（Hash Value），是一种通过哈希函数将任意长度的数据输入转换为固定长度的输出的技术。数据摘要用于验证数据的完整性，提供快速的内容识别，以及作为密码学中的重要组成部分。以下是数据摘要的详细介绍：

数据摘要的特性

1. 固定长度输出：

   • 不论输入数据的大小如何，哈希函数始终产生固定长度的输出。例如，SHA-256算法总是生成256位（32字节）的摘要。

2. 单向性：

   • 计算数据摘要是单向操作，即很难从摘要逆推出原始数据。这确保了摘要的安全性。

3. 抗碰撞性：

   • 很难找到两组不同的数据拥有相同的摘要。这意味着哈希函数能有效区分不同的数据输入。

4. 敏感性：

   • 对输入数据的微小改变（如改变一个字符）会导致输出摘要的显著变化。这种特性称为雪崩效应。

常见的哈希算法

1. MD5（Message-Digest Algorithm 5）：

   • 生成128位（16字节）的摘要。
   • 由于其抗碰撞性较弱，现已不推荐用于安全应用。

2. SHA-1（Secure Hash Algorithm 1）：

   • 生成160位（20字节）的摘要。
   • 目前也被认为不够安全，已被更强的算法取代。

3. SHA-256：

   • 属于SHA-2系列，生成256位（32字节）的摘要。
   • 提供更高的安全性，广泛用于数字签名和证书。

4. SHA-512：

   • 属于SHA-2系列，生成512位（64字节）的摘要。
   • 适用于需要更高安全性和处理能力的应用场景。

数据摘要的应用：

1. 数据完整性验证：

   • 在数据传输过程中，通过计算和比较数据摘要来验证数据是否被篡改。
   • 例如，在文件下载过程中，提供文件的哈希值供下载者验证。

2. 数字签名：

   • 数字签名算法通过对数据摘要进行加密来验证数据的来源和完整性。
   • 应用于电子邮件签名、软件发布、金融交易等场景。

3. 密码存储：

   • 用户密码存储时通常会先生成哈希值，而不是存储明文密码。
   • 结合盐值（salt）进一步提高安全性，防止彩虹表攻击。

4. 快速查找和去重：

   • 利用数据摘要快速识别和查找重复数据，提升存储和检索效率。
   • 在去重文件存储系统中应用广泛。

5. 区块链：

   • 在区块链中，区块的哈希值用于链接区块并确保链的完整性。

注意事项：

• 抗碰撞性：选择适合的哈希算法以保证安全性，避免使用已知存在漏洞的算法。
• 速度与安全性：哈希函数的性能和安全性需要平衡，高安全性的函数可能更慢。
• 盐值（Salt）：在密码存储中使用盐值提高安全性，防止哈希碰撞攻击。

数据摘要是信息安全中的重要工具，在保障数据完整性、验证数据来源及提高存储效率等方面发挥着关键作用。选择合适的哈希算法和策略对于确保应用的安全性至关重要。

CA证书

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。
如果你访问一个安全的网站，你的浏览器会检查该网站的证书是否由一个可信的CA机构颁发，并且该证书是否有效（未过期、未被撤销等）。如果一切正常，浏览器就会建立一个安全连接，保证你的通信不会被第三方窃取或篡改。

一个CA证书通常包含以下信息：

• 证书版本：证书的版本信息。
• 序列号：证书的唯一标识。
• 签名算法：用于签发证书的算法（如SHA-256）。
• 发行者信息：签发证书的CA的信息。
• 有效期：证书的生效日期和到期日期。
• 主体信息：证书所有者的信息（如域名、组织名）。
• 主体公钥信息：与证书绑定的公钥。
• 扩展信息：其他附加信息，如用途限制。
• 签名：CA对证书内容的数字签名，用于验证证书的真实性。

验证一个CA证书是否合法的方法： 计算CA证书信息的hash值未hash1，用CA证书给的公钥解密CA证书给的hash值为hash2，对比hash1和hash2是否相等，如果相等证书为真，如果不相等证书未假，如果有人想篡改CA证书的信息基本不可能，因为他们没有CA机构的私钥。

CA证书为什么不可能被篡改：

1. 中间⼈篡改了证书的明⽂
2. 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
3. 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

https通信的完整流程

1. 客户端请求某个网站
2. 网站的服务端发送自己网站的CA证书给客户端
3. 客户端验证证书合法性，从而保证后续通信的数据安全新
4. 客户端生成一个通信密钥，用CA证书中的公钥加密通信密钥，然后发送给服务端
5. 服务端用私钥解密数据，获取到通信密钥，然后就可以进行通信了。
   

反思

为什么要https的加密流程要弄的这么繁琐，直接使用对称加密或者非对称加密不可以吗？或者使用对称加密+非对称加密呢？

引入CA证书主要是为了防止中间人攻击的情况，如果有中间人在客户端和服务端最开始交换密钥信息的时候，中间人截取密钥信息，在中间篡改密钥信息，就能劫持数据。