当前位置：首页 > news >正文

唯美音乐图文网站建设/软件开发一般需要多少钱

news 文章来源：https://blog.csdn.net/KeepPromise/article/details/134319755 2025/3/21 9:20:34

唯美音乐图文网站建设,软件开发一般需要多少钱,建设直销团队网站,新疆建设网二级域名网站title: 《网络协议》06. HTTP 补充 HTTPS SSL/TLS date: 2022-10-06 18:09:55 updated: 2023-11-15 07:53:52 categories: 学习记录：网络协议 excerpt: HTTP/1.1 协议的不足、HTTP/2、HTTP/3、HTTP 协议的安全问题、SPDY、HTTPS、SSL/TLS、OpenSSL。 comments: fa…

title: 《网络协议》06. HTTP 补充 · HTTPS · SSL/TLS
date: 2022-10-06 18:09:55
updated: 2023-11-15 07:53:52
categories: 学习记录：网络协议
excerpt: HTTP/1.1 协议的不足、HTTP/2、HTTP/3、HTTP 协议的安全问题、SPDY、HTTPS、SSL/TLS、OpenSSL。
comments: false
tags:
top_image: /images/backimg/SunsetClimbing.png

网络协议

1：HTTP/1.1 协议的不足
2：HTTP/2
- 2.1：HTTP/2 特性
- - 2.1.1：二进制格式
  - 2.1.2：多路复用
  - 2.1.3：优先级
  - 2.1.4：头部压缩
  - 2.1.5：服务器推送
- 2.2：HTTP/2 的问题
- - 2.2.1：队头阻塞
  - 2.2.2：握手延迟
3：HTTP/3
- 3.1：HTTP/3 特性
- - 3.1.1：连接迁移
  - 3.1.2：向前纠错
- 3.2：HTTP/3 的问题
4：HTTP 协议的安全问题
- 4.1：SPDY
5：HTTPS
- 5.1：HTTPS 的成本
- 5.2：HTTPS 通信过程
6：SSL/TLS
- 6.1：SSL/TLS 工作在哪一层
- 6.2：TLS 1.2 的连接
- - 6.2.1：Client Hello
  - 6.2.2：Server Hello
  - 6.2.3：Certificate
  - 6.2.4：Server Key Exchange
  - 6.2.5：Server Hello Done
  - 6.2.6：Client Key Exchange
  - 6.2.7：Change Cipher Spec
  - 6.2.8：Finished（Client）
  - 6.2.9：Change Cipher Spec
  - 6.2.10：Finished（Server）
- 6.3：OpenSSL

网络协议从入门到底层原理。

1：HTTP/1.1 协议的不足

同一时间，一个连接只能对应一个请求
针对同一个域名，大多数浏览器允许同时最多 6 个并发连接
只允许客户端主动发起请求
一个请求只能对应一个响应
同一个会话的多次请求中，头信息会被重复传输
通常会给每个传输增加 500~800 字节的开销
如果使用 Cookie，增加的开销有时会达到上千字节

2：HTTP/2

HTTP/2，于 2015 年 5 月以 RFC 7540 正式发表

根据 W3Techs 的数据，截至 2019 年 6 月，全球有 36.5% 的网站支持了 HTTP/2

下列两个网站可以进行 HTTP/1.1 和 HTTP/2 速度对比

http://www.http2demo.io/
https://http2.akamai.com/demo

HTTP/2 在底层传输做了很多的改进和优化，但在语意上完全与 HTTP/1.1 兼容

比如请求方法（如 GET、POST）、Status Code、各种 Headers 等都没有改变
因此，要想升级到 HTTP/2，开发者不需要修改任何代码，只需要升级服务器配置、升级浏览器

2.1：HTTP/2 特性

2.1.1：二进制格式

HTTP/2 采用二进制格式传输数据，而非 HTTP/1.1 的文本格式。

二进制格式在协议的解析和优化扩展上带来更多的优势和可能。

在这里插入图片描述

一些基本概念：

数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。
所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。
消息：与逻辑 HTTP 请求或响应消息对应，由一系列帧组成。
帧：HTTP/2 通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）
来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装

在这里插入图片描述

2.1.2：多路复用

多路复用（Multiplexing），客户端和服务器可以将 HTTP 消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来

在这里插入图片描述

并行交错地发送多个请求，请求之间互不影响
并行交错地发送多个响应，响应之间互不干扰
使用一个连接并行发送多个请求和响应

在这里插入图片描述

不必再为绕过 HTTP/1.1 限制而做很多工作。比如精灵图（image sprites）、合并 CSS/JS、内嵌 CSS/JS/Base64 图片、域名分片等。

精灵图（image sprites），也叫做 CSS Sprites，将多张小图合并成一张大图。最后通过 CSS 结合小图的位置、尺寸进行精准定位。

在这里插入图片描述

2.1.3：优先级

HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系
可以向每个数据流分配一个介于 1 至 256 之间的整数
每个数据流与其他数据流之间可以存在显式依赖关系
客户端可以构建和传递 “ 优先级树 ”，表明它倾向于如何接收响应
服务器可以使用此信息通过控制 CPU、内存和其他资源的分配设定数据流处理的优先级
在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端

示例：

在这里插入图片描述

2.1.4：头部压缩

HTTP/2 使用 HPACK 压缩请求头和响应头，可以极大减少头部开销，进而提高性能。

早期版本的 HTTP/2 和 SPDY 使用 zlib 压缩请求头和响应头，可以将所传输头数据的大小减小 85% ~ 88%。
但在 2012 年夏天被攻击，导致会话劫持。
后被更安全的 HPACK 取代。

在这里插入图片描述

2.1.5：服务器推送

服务器推送（Server Push）：服务器可以对一个客户端请求发送多个响应。

除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求。

在这里插入图片描述

2.2：HTTP/2 的问题

2.2.1：队头阻塞

队头阻塞（head of line blocking）。

在这里插入图片描述

2.2.2：握手延迟

在这里插入图片描述

RTT（Round Trip Time）：往返时延，可以简单理解为通信一来一回的时间。

在这里插入图片描述

3：HTTP/3

Google 觉得 HTTP/2 仍然不够快，于是就有了 HTTP/3。

HTTP/3 由 Google 开发，弃用 TCP 协议，改为使用基于 UDP 协议的 QUIC 协议实现。

QUIC（Quick UDP Internet Connections，快速 UDP 网络连接），由 Google 在 2013 年实现
于 2018 年从 HTTP-over-QUIC 改为 HTTP/3

在这里插入图片描述

思考：

HTTP/3 基于 UDP，如何保证可靠传输？

由 QUIC 来保证

为何 Google 不开发一个新的不同于 TCP、UDP 的传输层协议？

目前世界上的网络设备基本只认TCP、UDP
如果要修改传输层，意味着操作系统的内核也要修改
另外，由 IETF 标准化的许多 TCP 新特性都因缺乏广泛支持而没有得到广泛的部署或使用，因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情

3.1：HTTP/3 特性

3.1.1：连接迁移

TCP 基于 4 要素：源 IP、源端口、目标 IP、目标端口。

切换网络时至少会有一个要素发生变化，导致连接发生变化
当连接发生变化时，如果还使用原来的 TCP 连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
所以有时发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
即使当检测到网络变化时立刻建立新的 TCP 连接，还是需要几百毫秒的时间

QUIC 的连接不受 4 要素的影响，当 4 要素发生变化时，原连接依然维持。

QUIC 连接不以 4 要素作为标识，而是使用一组 Connection ID（连接ID）来标识一个连接
即使 IP 或者端口发生变化，只要 Connection ID 没有变化，那么连接依然可以维持

例如：
当设备连接到 Wi-Fi 时，将进行中的下载从蜂窝网络连接转移到更快速的 Wi-Fi 连接。
当 Wi-Fi 连接不再可用时，将连接转移到蜂窝网络连接。

3.1.2：向前纠错

目前还没有成为标准，以后是否会成为标准也不确定。

HTTP/3 的向前纠错，丢包以后可以根据其他包推测出这个包的数据（只适合丢失少量数据）。

如果是之前的基于 TPC 协议，丢包以后会重传。

3.2：HTTP/3 的问题

操作系统内核、CPU 负载。

Linux 内核的 UDP 部分没有像 TCP 那样的优化，因为传统上没有使用 UDP 进行如此高速的信息传输
TCP 和 TLS 有硬件加速，而这对于 UDP 很罕见，对于 QUIC 则基本不存在

据 Google 和 Facebook 称，与基于 TLS 的 HTTP/2 相比，它们大规模部署的 QUIC 需要近 2 倍的 CPU 使用量

随着时间的推移，相信这个问题会逐步得到改善

4：HTTP 协议的安全问题

HTTP 协议默认是采取明文传输的，因此会有很大的安全隐患。

常见的提高安全性的方法是：对通信内容进行加密后，再进行传输。

常见的加密方式：

不可逆
单向散列函数：MD5、SHA 等
可逆
对称加密：DES、3DES、AES 等
非对称加密：RSA 等
其它
混合密码系统
数字签名
证书

encrypt：加密
decrypt：解密
plaintext：明文
ciphertext：密文

为了便于学习，设计 4 个虚拟人物：

Alice、Bob：互相通信
Eve：窃听者
Mallory：主动攻击者

在这里插入图片描述

如何防止被窃听：

在这里插入图片描述

4.1：SPDY

SPDY（speedy 的缩写），是基于 TCP 的应用层协议，它强制要求使用 SSL/TLS。

在这里插入图片描述

2009 年 11 月，Google 宣布将 SPDY 作为提高网络速度的内部项目。

SPDY 与 HTTP 的关系：

SPDY 并不用于取代 HTTP，它只是修改了 HTTP 请求与响应的传输方式
只需增加一个 SPDY 层，现有的所有服务端应用均不用做任何修改
SPDY 可以看做是 HTTP/2 的前身

5：HTTPS

HTTPS（HyperText Transfer Protocol Secure，超文本传输安全协议）

也称为 HTTP over TLS、HTTP over SSL、HTTP Secure
由网景公司于 1994 年首次提出
HTTPS 的默认端口号是 443（HTTP 是 80）

现在在浏览器上输入 http://www.baidu.com
会自动重定向到 https://www.baidu.com

5.1：HTTPS 的成本

证书的费用
加解密计算
降低了访问速度

有些企业的做法是：包含敏感数据的请求才使用 HTTPS，其他保持使用 HTTP。

5.2：HTTPS 通信过程

总的可以分为 3 大阶段：

在这里插入图片描述

6：SSL/TLS

SSL（Secure Sockets Layer，安全套接层），是 TLS 的前身。

TLS（Transport Layer Security，传输层安全性协议）。

HTTPS 是在 HTTP 的基础上使用 SSL/TLS 来加密报文，对窃听和中间人攻击提供合理的防护。

在这里插入图片描述

SSL/TLS 也可以用在其他协议上，比如：

FTP -> FTPS
SMTP -> SMTPS

SSL/TLS 历史版本信息

SSL 1.0：因存在严重的安全漏洞，从未公开过
SSL 2.0：1995 年，已于 2011 年弃用（RFC 6176）
SSL 3.0：1996 年，已于 2015 年弃用（RFC 7568）
TLS 1.0：1999 年（RFC 2246）
TLS 1.1：2006 年（RFC 4346）
TLS 1.2：2008 年（RFC 5246）
TLS 1.3：2018 年（RFC 8446）

6.1：SSL/TLS 工作在哪一层

在这里插入图片描述

6.2：TLS 1.2 的连接

TLS 1.2 的连接（ECDHE 密钥交换算法）大概有 10 大步骤。

下图中省略了中间产生的一些 ACK 确认。

在这里插入图片描述

6.2.1：Client Hello

TLS 的版本号
支持的加密组件（Cipher Suite）列表
加密组件是指所使用的加密算法及密钥长度等
一个随机数（Client Random）

在这里插入图片描述

6.2.2：Server Hello

TLS 的版本号
选择的加密组件
是从接收到的客户端加密组件列表中挑选出来的
一个随机数（Server Random）

在这里插入图片描述

6.2.3：Certificate

服务器的公钥证书（被 CA 签名过的）

在这里插入图片描述

6.2.4：Server Key Exchange

用以实现 ECDHE 算法的其中一个参数（Server Params）
ECDHE 是一种密钥交换算法
为了防止伪造，Server Params 经过了服务器私钥签名

在这里插入图片描述

6.2.5：Server Hello Done

告知客户端：协商部分结束

在这里插入图片描述

到目前为止，客户端和服务器之间通过明文共享了：

Client Random
Server Random
Server Params

而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实有效性。

6.2.6：Client Key Exchange

用以实现 ECDHE 算法的另一个参数（Client Params）

在这里插入图片描述

目前为止，客户端和服务器都拥有了 ECDHE 算法需要的 2 个参数：

Server Params
Client Params

客户端、服务器都可以使用 ECDHE 算法根据 Server Params、Client Params 计算出一个新的随机密钥串：Pre-master secret。

然后结合 Client Random、Server Random、Pre-master secret 生成一个主密钥。

最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥、服务器发送用的会话密钥等。

6.2.7：Change Cipher Spec

告知服务器：之后的通信会采用计算出来的会话密钥进行加密

在这里插入图片描述

6.2.8：Finished（Client）

包含连接至今全部报文的整体校验值（摘要），加密之后发送给服务器
这次握手协商是否成功，要以服务器是否能够正确解密该报文作为判定标准

在这里插入图片描述

6.2.9：Change Cipher Spec

在这里插入图片描述

6.2.10：Finished（Server）

到此为止，客户端服务器都验证加密解密没问题，握手正式结束
后面开始传输加密的 HTTP 请求和响应

在这里插入图片描述

6.3：OpenSSL

OpenSSL 是 SSL/TLS 协议的开源实现，始于 1998 年，支持 Windows、Mac、Linux 等平台。

官网：https://www.openssl.org/

Linux、Mac 一般自带 OpenSSL。
Windows 下载安装 OpenSSL：https://www.openssl.org/source/

常用命令：

生成私钥：
openssl genrsa -out my.key

生成公钥：
openssl rsa -in my.key -pubout -out my.pem

可以使用 OpenSSL 构建一套属于自己的 CA，自己给自己颁发证书，称为 “ 自签名证书 ”。

除此以外，一个生成免费证书的网站：https://freessl.org

人生如逆旅，我亦是行人。

——《临江仙 · 送钱穆父》（宋）苏轼

网络协议

1：HTTP/1.1 协议的不足

2：HTTP/2

2.1：HTTP/2 特性

2.1.1：二进制格式

2.1.2：多路复用

2.1.3：优先级

2.1.4：头部压缩

2.1.5：服务器推送

2.2：HTTP/2 的问题

2.2.1：队头阻塞

2.2.2：握手延迟

3：HTTP/3

3.1：HTTP/3 特性

3.1.1：连接迁移

3.1.2：向前纠错

3.2：HTTP/3 的问题

4：HTTP 协议的安全问题

4.1：SPDY

5：HTTPS

5.1：HTTPS 的成本

5.2：HTTPS 通信过程

6：SSL/TLS

6.1：SSL/TLS 工作在哪一层

6.2：TLS 1.2 的连接

6.2.1：Client Hello

6.2.2：Server Hello

6.2.3：Certificate

6.2.4：Server Key Exchange

6.2.5：Server Hello Done

6.2.6：Client Key Exchange

6.2.7：Change Cipher Spec

6.2.8：Finished（Client）

6.2.9：Change Cipher Spec

6.2.10：Finished（Server）

6.3：OpenSSL

相关文章：