1、http和https

http和https

更新于：2024年3月9日16

HTTPS重要性

HTTPS是安全的HTTP，HTTP 协议中的内容都是明文传输，HTTPS 的目的是将这些内容加密，确保信息传输安全。最后一个字母 S 指的是 SSL/TLS 协议，它位于HTTP 协议与 TCP/IP 协议中间。

HTTPS优势：

1、加密隐私数据：防止您访客的隐私信息(账号、地址、手机号等)被劫持或窃取。

2、安全身份认证：验证网站的真实性，防止钓鱼网站。

3、防止网页篡改：防止数据在传输过程中被篡改，保护用户体验。

4、地址栏安全锁：地址栏头部的“锁”型图标，提高用户信任度。

5、提高SEO排名：提高搜索排名顺序，为企业带来更多访问量。

HTTP请求是什么

HTTP超文本传输协议，是确保服务器（Server）和客户端（Client）之间的正确通信。

一个请求和响应的过程：

Request 用户通过浏览器向我们的服务端发起请求。
Response 服务端将客户端请求的资源数据进行响应。

调用接口的方法

请求类型：

GET 向指定的URL请求资源，可携带参数（明文）。
POST 向指定的URL提交资源，表单数据提交，数据进行封装（比Get方法安全）。
PUT 与POST类似，通常用于对资源数据的更新修改。
DELETE 删除指定的资源。

HTTP常见的错误码

1xx : 服务已收到请求，请求者继续执行操作。
2xx：请求成功，常见（201）
3xx：请求成功，页面发生重定向（301）
4xx：客户端发生了错误
- 常见的是资源找不到了（404）
- 资源请求需要认证认证失败（401）
- 认证成功但是权限不够（403）
5xx：服务端发生了错误
- 网关超时（504）
- 内部错误（500）
- 网关错误（502）
- 服务不可用（503）

如果响应的状态码大于等于 200 且小于400，则诊断被认为是成功的。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

302 Found 重定向

301 永久重定向

HTTP 301状态码表示永久重定向。当网站的页面被永久移动到另一个地址时，服务器会返回这个响应状态码。在实际浏览器或HTTP客户端请求一个URL时，如果接收到301状态码，客户端会自动进行重定向到在Location响应头中指定的新URL。

例如，如果你尝试访问一个已经被移动到新地址的页面，服务器会返回类似下面的响应：

HTTP/1.1 301 Moved Permanently
Location: http://www.example.com/newpage

这告诉客户端（比如你的浏览器）请求的资源已经永久移动到http://www.example.com/newpage，并且未来应该使用这个新的URL来访问资源。

搜索引擎如谷歌会根据301重定向更新他们的索引，以反映新的位置。因此，这个状态码对于SEO（搜索引擎优化）是非常重要的，因为它可以将旧页面的排名和信誉转移到新页面上。在网站重构或迁移时，使用301重定向是保持搜索引擎排名的一种有效方法。

304（说明无需再次传输请求的内容，也就是说可以使用缓存的内容。）

403（例如没有足够的权限访问该资源）

网关错误（502）

🎂

TLS 与 mTLS

1、TLS 与 mTLS 基本概念

前面我们学习了如何通过配置 Istio 实现对外部服务的 TLS 发起，这里其实还有一个 mTLS 的概念呢，由于 TLS 本身就比较复杂，对于双向 TLS（mTLS）就更复杂了。

CA：证书颁发机构

TLS 是一个连接层协议，旨在为 TCP 连接提供安全保障。TLS 在连接层工作，可以与任何使用 TCP 的应用层协议结合使用。例如，HTTPS 是 HTTP 与 TLS 的结合（HTTPS 中的 S 指的是 SSL，即 TLS 的前身），TLS 认证的流程大致如下所示：

首先向第三方机构 CA 提交组织信息、个人信息(域名)等信息并申请认证。
CA 通过多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。如信息审核通过，CA 会向申请者签发认证文件-证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。
客户端向服务端发出请求时，服务端返回证书文件。
客户端读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性。
客户端还会验证证书相关的域名信息、有效时间等信息; 客户端会内置信任 CA 的证书信息(包含公钥)，比如浏览器基本上都带有知名公共 CA 机构的证书，如 Verisign、Digicert 等，这些证书在发布时被打包在一起，当我们下载浏览器时，就经把正确的证书放进了浏览器，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。

2、HTTPS 的工作流程

当然 HTTPS 的工作流程和这个过程基本就一致了：

1.客户端发起一个 HTTPS 请求。
2.服务端把配置好的证书返回给客户端。
3.客户端验证证书：比如是否在有效期内，证书的用途是不是匹配 Client 请求的站点，是不是在 CRL 吊销列表里面，它的上一级证书是否有效等。
4.客户端使用伪随机数生成对称密钥，并通过证书里服务器的公钥进行加密，后续使用该对称密钥进行传输信息。
5.服务端使用自己的私钥解密这个消息，得到对称密钥。至此，客户端和服务端都持有了相同的对称密钥。
6.服务端使用对称密钥加密明文内容 A，发送给客户端。
7.客户端使用对称密钥解密响应的密文，得到明文内容 A。
8.客户端再次发起 HTTPS 的请求，使用对称密钥加密请求的明文内容 B，然后服务器使用对称密钥解密密文，得到明文内容 B。

当然双向 TLS 就更为复杂了，Mutual TLS（双向 TLS），或称 mTLS，对于常规的 TLS，只需要服务端认证，mTLS 相对来说有一个额外的规定：客户端也要经过认证。在 mTLS 中，客户端和服务器都有一个证书，并且双方都使用它们的公钥/私钥对进行身份验证。

TLS 保证了真实性，但默认情况下，这只发生在一个方向上：客户端对服务器进行认证，但服务器并不对客户端进行认证。为什么 TLS 的默认只在一个方向进行认证？因为客户端的身份往往是不相关的。例如我们在访问优点知识的时候，你的浏览器已经验证了要访问的网站服务端的身份，但服务端并没有验证你的浏览器的身份，它实际上并不关心你的浏览器的身份，这对于互联网上的 Web 项目来说足够了。但是在某些情况下，服务器确实需要验证客户端的身份，例如，当客户端需要访问某些敏感数据时，服务器可能需要验证客户端的身份，以确保客户端有权访问这些数据，这就是 mTLS 的用武之地，mTLS 是保证微服务之间跨服务通信安全的好方法。

首先，你想要安全的通信。当我们把我们的应用程序拆分为多个服务时，我们最终会在这些服务之间的网络上发送敏感数据。任何能够进入网络的人都有可能读取这些敏感数据并伪造请求。
其次，你关心客户端的身份。首先，你要确保你能知道调用是什么时候发生的，以便进行诊断，并正确记录指标等事项。此外，你可能想对这些身份进行授权（允许 A 调用 B 吗）。当然授权是另外的话题了。

🎂

自签证书

提供证书的方式

openssl/cfssl工具自签
权威的根证书颁发机构；（企业级域名，安全系数比较高的，1个二级域名大概需要几千块钱。有的域名几万块钱；）
通过一些工具来自动生成合法的证书（cert-manager）；（自动管理证书）

⚠️ 注意：

除了自签名证书或者购买正规机构的 CA 证书之外，我们还可以通过一些工具来自动生成合法的证书，cert-manager 是一个云原生证书管理开源项目，可以用于在 Kubernetes 集群中提供 HTTPS 证书并自动续期，支持 Let's Encrypt/HashiCorp/Vault 这些免费证书的签发。在 Kubernetes 中，可以通过 Kubernetes Ingress 和 Let's Encrypt 实现外部服务的自动化 HTTPS。