计算机网络 DNS HTTP HTTPS，缓存

文章目录

• • • 输入URL之后的全过程
    • [URL URI](#URL URI)
• DNS (Domain Name System)
• • 为什么分布式
  • 域名的层级关系
  • 解析过程
  • 递归查询和迭代查询
• HTTP
• • 特性
  • 版本演变
  • • 0.9
    • 1.0
    • 1.1
    • • 问题
      • 优化
    • 2
    • • 兼容
      • 改变
      • 推送实现
      • 与HTTP1对比
      • 并发实现
      • 缺陷
    • 3
    • • 特点
      • QUIC协议
• 缓存
• • 强制缓存
  • 协商缓存
  • • • 基于`Last-Modified`和`If-Modified-Since`的协商缓存
      • 基于`ETag`的协商缓存
• [HTTPS（Hyper Text Transfer Protocol Secure）](#HTTPS（Hyper Text Transfer Protocol Secure）)
• • • 特点
    • 混合加密
    • 摘要算法+数字签名
    • 数字证书
    • • 流程
    • 证书信任链
    • • 优点
      • 缺点
      • 与HTTP对比
  • [HTTPS 建立连接的 SSL/TLS 协议流程概述](#HTTPS 建立连接的 SSL/TLS 协议流程概述)

输入URL之后的全过程

1. 从输入的URL中解析出使用的协议、主机、端口号等，构造一个HTTP请求
2. DNS解析域名，解析成对应的ip地址
3. TCP三次握手，建立连接
4. 浏览器发送HTTP/HTTPS请求到web服务器
5. 服务器处理HTTP/HTTPS请求并返回报文
6. 浏览器渲染页面
7. 断开连接，tcp四次挥手

URL URI

在网络技术中，URI（Uniform Resource Identifier，统一资源标识符）和URL（Uniform Resource Locator，统一资源定位符）是两个非常基本的概念，它们都用于在网络上标识资源，但它们之间存在一些区别：

1. URI（统一资源标识符）：

   • URI是一个用于标识某一互联网资源名称的字符串。
   • URI的主要目的是标识资源，它可以是URL或URN（Uniform Resource Name，统一资源名称）。
   • 例如，https://example.com/path?query=123 是一个URI。

2. URL（统一资源定位符）：

   • URL是URI的一个子集，不仅标识资源，还提供了找到该资源的方式。
   • URL通常包括协议（如HTTP、HTTPS）、服务器位置和资源在服务器上的具体地址。
   • 例如，https://example.com/path?query=123 是一个URL，它告诉你如何通过HTTPS协议访问example.com上的某个资源。

总结来说，每个URL都是URI，但不是每个URI都是URL。URI更广泛，它还包括URN，而URN仅仅标识资源的名称，不提供定位信息。例如，urn:isbn:0451450523是一个URN，用于标识特定的书籍，但并不提供获取书籍的具体位置。

DNS (Domain Name System)

概念：将域名转换为ip的分布式系统

为什么分布式

1. 单点故障会使整个网络瘫痪
2. 远程服务器请求时间较长，造成严重的时延
3. 维护成本过高

域名的层级关系

考点号来分隔，代表不同层次，越靠右层级越高

解析过程

1. 先查询浏览器缓存是否存有ip地址
2. 若没有，则查询计算机本地的host文件是否有缓存
3. 向本地的DNS服务器发送查询请求，有就返回
4. 若没有，本地的DNS解析器会向根DNS服务器发出查询请求，返回结果是应该向哪个顶级域的DNS服务器查询
5. 本地解析器向顶级域名DNS服务器发送请求，返回结果是向哪个权威DNS服务器查询下一步
6. 本地解析器发送请求给权威DNS服务器，返回结果是ip地址
7. 本地解析器返回结果给浏览器，同时将结果缓存本地
8. 浏览器发起连接

递归查询和迭代查询

递归查询：DNS客户端只需要发送一个查询请求，就可以等待完整的解析结果

迭代查询：DNS客户端通过向上级DNS服务器发送请求，获取更高级的域名服务器地址，向其发送请求，直到获得完整的解析结果

总结：递归查询适合普通用户和客户端，迭代查询适用于DNS服务器之间的通信

HTTP

特性

简单 ：基本报文格式为header+body，头部信息是key-value简单文本的形式
灵活和易于扩展 ：协议中的各种请求方法、URL\URI、状态码、头字段等每个组成部分没有被定死，允许自行补充；在应用层，下层可以随意变换；HTTPS是在http和tcp之间添加了ssl/tsl安全传输层，HTTP/3则是把TCP换成了基于UDP的QUIC
无状态 ：服务器不会去记忆HTTP的状态，可以减轻服务器负担
明文传输 ：信息透明易被窃取
不安全 ：通信使用明文；不验证身份、无法证明完整性
应用广泛且跨平台

版本演变

0.9

只支持GET，只能返回HTML格式

1.0

第一个正式版本

引入请求头和响应头，支持多种请求方法和状态码

不支持持久连接

1.1

提出了长连接，客户端和服务端任意一端没有明确提出断开连接，则保持tcp连接

管道网络传输：解决请求的队头堵塞；可以同时发送多个请求，服务器必须按照接受请求的顺序处理，会造成响应队头堵塞

问题

1. 延迟难以下降，达到了延迟的下限
2. 并发连接有限，而且每一个连接都要经过TCP和TLS握手耗时，以及TCP慢启动过程带来的影响
3. 头部冗余，头部巨大且重复，特别是携带cookie的，cookie的大小通常很大
4. 响应队头堵塞
5. 没有请求优先级控制
6. 不支持服务器推送消息，只能客户端发送请求，浪费了大量的带宽和服务器资源

优化

1. 将多张小图合并成大图供js切割，也就是多个请求合并成一个请求；但是当一个小图改变了就要重新请求大图
2. 将图片的二进制数据通过base64编码之后，将数据嵌入到css或者html
3. 将多个体积较小的js文件使用webpack等工具打包成一个体积更大js，带来的问题跟小图合并成大图一样
4. 将同一个页面资源分散到不同域名，提升并发连接上限

2

基于HTTPS；为改善HTTP1.1而提出，同时兼容了HTTP1.1

兼容

1. 平滑升级：没有引入新的协议名，只需要浏览器和服务器在背后升级协议
2. 只在应用层做改变，分解成语义和语法；语义方面完全一致（请求方法、状态码、头字段等）

改变

在语法方面做了很多改变，基本改变了HTTP报文传输

1. 头部压缩：使用 HPACK 压缩算法对请求响应头部进行压缩，减少了传输的头部数据量，降低了延迟。
2. 二进制帧：将数据分割成二进制帧进行传输，分为头信息帧（Headers Frame）和数据帧（Data Frame），增加了数据传输的效率。
3. 并发传输：引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接，针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送 的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
4. 服务器推送：服务器可以对客户端的一个请求发送多个响应，即服务器可以额外的向客户端推送资源，而无需客户端明确的请求。

特性	改进	HTTP1存在问题
头部压缩（HPACK）	使用HPACK压缩算法对请求和响应的头部进行压缩，减少了传输的头部数据量，降低了延迟。 HPACK算法：静态字典（为高频出现的字符串和字段建立一张静态表），动态字典（生效的前提，必须同一个连接，重复传输完全相同的HTTP头部）、Huffman编码（压缩算法）	1. 含有很多固定字段 2. 大量的请求和相应的报文有很多字段值重复 3. 字段是ASCII编码，效率低，需要改成二进制编码
二进制帧	将数据分割成二进制帧进行传输，主要有头信息帧（Headers Frame）和数据帧（Data Frame），还可以使用位运算，增加数据传输的效率。	HTTP1文本格式降低了传输效率
并发传输	引入了Stream概念，多个Stream可以复用在一条TCP连接上。每个HTTP请求用独一无二的Stream ID来标识，使得接收端可以通过Stream ID有序组装成完整的HTTP消息。不同Stream的帧可以乱序发送，允许并行交错地发送请求和响应。
服务器推送	服务器可以对一个客户端请求发送多个响应，即服务器可以在没有客户端明确请求的情况下，向客户端推送额外的资源。

但是 HTTP/2 仍然存在着队头阻塞的问题，只不过问题是在传输层

推送实现

客户端发送的请求必须是奇数号Stream，服务器主动推送的则是偶数号。

服务器推送资源时，通过帧中的Promise Stream ID告诉客户端包体的位置

与HTTP1对比

HTTP1.1 基于请求-响应模型。同一个连接中，HTTP完成一个事务（请求与响应），才能处理下一个事务。即：再发出请求等待响应的过程种是没办法做其他事情的，会造成【队头阻塞】问题。

HTTP2通过Stream这个设计（多个Stream复用一条TCP连接，达到并发的效果），解决了【队头阻塞】的问题， 提高了HTTP传输的吞吐量。

HTTP2在访问HTML的时候主动推送CSS文件，减少消息传递次数

并发实现

关键：Stream

1. HTTP消息可以由多个Frame构成
2. 一个Frame可以由多个TCP报文构成（Frame是最小的单位，以二进制压缩格式存放内容）
   不同Stream的帧可以乱序发送，可以通过StreamID组装HTTP消息。还可以设置优先级。

缺陷

队头阻塞：TCP是字节流协议

TCP与TLS的握手时延迟

网络迁移需要重新连接

3

HTTP/3 把TCP协议改成UDP，基于QUIC协议

特点

零RTT连接建立 ：允许在首次连接时进行零往返时间连接连接建立，减少连接延迟
无队头阻塞 ：使用UDP协议传输护数据时，一个连接上的多个stream没有依赖，一个丢失并不会影响后续的处理
连接迁移 ：允许在网络切换时，将连接迁移到新的IP，从而减少连接的中断时间
向前纠错机制：每个数据包包含了部分其他数据包的内容，因此少量丢包时可以通过其他包重组数据；通过牺牲数据上限减少数据重穿

QUIC协议

基于UDP在应用层实现了QUIC协议，有类似于TCP的连接管理、拥塞窗口、流量控制的网络特性，使UDP变得可靠

在协议内部包含了TLS1.3，自己的帧会携带TLS里面的记录，仅需一个RTT就可以同时完成建立连接和密钥协商；在第二次连接时，应用数据包可以和QUIC握手消息一起发送，达到0-RTT

缓存

强制缓存

浏览器判读命中资源是否有效命中强缓存，如果命中则直接读取，不需要进行通讯
Expires强缓存：使用原理是判读本地时间和时间戳，若本机时间不准则容易出问题，基本已废弃
Cache-Control强缓存：http1.1中增加该字段，单位是秒

协商缓存

定义：通过服务端告知客户端是否可以使用缓存

当请求响应码是304时，代表可以使用本地缓存的资源

基于Last-Modified和If-Modified-Since的协商缓存

1. 服务端读取文件修改时间，赋给相应头的Last-Modified字段
2. 设置Cache-Control:no-cache
3. 客户端读取到Last-Modified时候，会在下次的请求标头中携带字段If-Modified-Since也就是服务器第一次修改给他的时间，之后的每次请求都会带上此字段进行对比，状态码200说明说明资源无新更改，304走缓存
   缺点
4. 可能单纯的因为文件修改了又修改回来导致缓存失效
5. 因为记录单位为秒，所以当文件在几百毫米内完成修改，缓存不会改变

基于ETag的协商缓存

解决了上面缓存的缺陷，将比较时间戳的形式改成了比较文件指纹（根据文件内容算出唯一哈希值）

过程

缺点

1. 计算开销更大
2. 有强验证（准确到每一个字节）和弱验证（提取文件的部分属性），强缓存过于消耗性能，弱缓存准确率不高

HTTPS（Hyper Text Transfer Protocol Secure）

特点

• 信息加密：实现信息机密性；对称加密+非对称加密混合，解决了窃听的风险
• 校验机制：确保数据的完整性；用摘要算法为数据生成独一无二的指纹校验码
• 身份证书：将服务端的公钥放入到CA证书，解决服务端被冒充的冒险

混合加密

采用非对称加密的方式交换会话密钥，后续则不再使用

通信过程中，全部使用对称加密的会话密钥方式加密

使用原因：对称加密运算速度快，密钥必须保密；非对称加密解决密钥交换问题，但是速度慢

摘要算法+数字签名

摘要算法只能保证内容不被修改，不能保证发送者身份；计算机采用非对称加密来解决

数字签名

1. 发送者使用私钥对消息的摘要（通常是哈希函数计算得到）进行加密，生成数字签名
2. 数字签名是消息的哈希值经过私钥加密的结果
3. 发送者将原始消息和生成的数字签名一起发送给接收者
4. 接收者使用发送者的公钥对数字签名进行解密得到摘要值，再次使用相同的哈希函数计算收到的消息摘要，进行对比

数字证书

解决问题：缺少身份验证的过程，会存在中间人篡改公钥

流程

1. 密钥生成 ：
   • 实体生成一对密钥，包括公开的公钥和私密的私钥。
2. 证书请求（CSR） ：
   • 实体创建包含公钥和个人信息的CSR，并将其发送至数字证书颁发机构（CA）。
3. 证书颁发 ：
   • CA验证实体后，用私钥签名CSR，生成含签名的数字证书。
4. 证书验证 ：
   • 实体用CA的公钥验证数字证书的签名，核实证书的合法性。
5. 数字证书使用 ：
   • 接收者用证书中的公钥加密数据，发送给持有者，持有者再用私钥解密。
   • 持有者可用私钥创建数字签名，接收者用公钥验证以确保数据来源和完整性。

证书信任链

定义：是数字证书的验证过程的一部分，确保数字证书是由可信的证书颁发机构签发，并最终连接到根证书，形成一条链条

根证书：信任链的顶端，也称根CA证书，是数字证书体系中的根基，有操作系统或者浏览器内置

中间证书颁发机构：在信任链中，根证书下方可能有一个或多个CA，数字证书由中间CA签发

服务器证书：在最底层，由中间CA签发，包含了服务器公钥和相关信息，需在客户端验证的过程中被验证

优点

• 传输过程中，使用密钥加密，安全性跟高
• 可以认证用户和服务端，确保数据发送到正确的用户和服务器

缺点

• 握手阶段延时较高，在会话前就要进行SSL握手
• 部署成本高：需购买CA证书，占用CPU证书，需要服务器配置或者数目高

与HTTP对比

端口号：HTTP是80，HTTPS是443

HTTPS在进行完TCP三次握手之后，还需进行SSL/TSL的握手过程，才可进入加密报文传输

HTTPS协议需要向CA中心申请数字证书，保证服务器身份可靠

HTTPS 建立连接的 SSL/TLS 协议流程概述

1. 客户端请求：客户端发送加密通信请求（ClientHello），与服务器建立连接。

2. 服务器响应：服务器生成一对公私钥，并将公钥提交给CA机构。CA使用自己的私钥对服务器的公钥进行加密，生成CA数字证书。

3. 证书发送：服务器通过响应（ServerHello）将CA数字证书发送给客户端。

4. 证书验证：客户端使用内置的CA公钥解密并验证数字证书是否合法，提取出服务器的公钥。如果验证失败，客户端会发出警告。

5. 生成会话密钥：客户端使用服务器的公钥生成一个随机密钥（会话密钥），并将加密后的密钥发送给服务器。

6. 服务器解密：服务器用私钥解密该随机密钥，获得会话密钥。

7. 加密通信：双方使用会话密钥进行加密通信，确保数据的安全传输。