输入URL之后的全过程
- 从输入的URL中解析出使用的协议、主机、端口号等，构造一个HTTP请求
- DNS解析域名，解析成对应的ip地址
- TCP三次握手，建立连接
- 浏览器发送HTTP/HTTPS请求到web服务器
- 服务器处理HTTP/HTTPS请求并返回报文
- 浏览器渲染页面
- 断开连接，tcp四次挥手
URL URI
在网络技术中，URI（Uniform Resource Identifier，统一资源标识符）和URL（Uniform Resource Locator，统一资源定位符）是两个非常基本的概念，它们都用于在网络上标识资源，但它们之间存在一些区别：
-
URI（统一资源标识符）：
- URI是一个用于标识某一互联网资源名称的字符串。
- URI的主要目的是标识资源，它可以是URL或URN（Uniform Resource Name，统一资源名称）。
- 例如，
https://example.com/path?query=123是一个URI。
-
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的分布式系统
为什么分布式
- 单点故障会使整个网络瘫痪
- 远程服务器请求时间较长，造成严重的时延
- 维护成本过高
域名的层级关系
考点号来分隔，代表不同层次，越靠右层级越高
解析过程
- 先查询浏览器缓存是否存有ip地址
- 若没有，则查询计算机本地的host文件是否有缓存
- 向本地的DNS服务器发送查询请求，有就返回
- 若没有，本地的DNS解析器会向根DNS服务器发出查询请求，返回结果是应该向哪个顶级域的DNS服务器查询
- 本地解析器向顶级域名DNS服务器发送请求，返回结果是向哪个权威DNS服务器查询下一步
- 本地解析器发送请求给权威DNS服务器，返回结果是ip地址
- 本地解析器返回结果给浏览器，同时将结果缓存本地
- 浏览器发起连接
递归查询和迭代查询
递归查询：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连接
管道网络传输：解决请求的队头堵塞；可以同时发送多个请求，服务器必须按照接受请求的顺序处理，会造成响应队头堵塞
问题
- 延迟难以下降，达到了延迟的下限
- 并发连接有限，而且每一个连接都要经过TCP和TLS握手耗时，以及TCP慢启动过程带来的影响
- 头部冗余，头部巨大且重复，特别是携带cookie的，cookie的大小通常很大
- 响应队头堵塞
- 没有请求优先级控制
- 不支持服务器推送消息，只能客户端发送请求，浪费了大量的带宽和服务器资源
优化
- 将多张小图合并成大图供js切割，也就是多个请求合并成一个请求；但是当一个小图改变了就要重新请求大图
- 将图片的二进制数据通过base64编码之后，将数据嵌入到css或者html
- 将多个体积较小的js文件使用webpack等工具打包成一个体积更大js，带来的问题跟小图合并成大图一样
- 将同一个页面资源分散到不同域名，提升并发连接上限
2
基于HTTPS；为改善HTTP1.1而提出，同时兼容了HTTP1.1
兼容
- 平滑升级：没有引入新的协议名，只需要浏览器和服务器在背后升级协议
- 只在应用层做改变，分解成语义和语法；语义方面完全一致（请求方法、状态码、头字段等）
改变
在语法方面做了很多改变，基本改变了HTTP报文传输
- 头部压缩：使用
HPACK压缩算法对请求响应头部进行压缩，减少了传输的头部数据量，降低了延迟。 - 二进制帧：将数据分割成二进制帧进行传输，分为头信息帧（Headers Frame）和数据帧（Data Frame），增加了数据传输的效率。
- 并发传输：引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接，针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送 的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
- 服务器推送：服务器可以对客户端的一个请求发送多个响应，即服务器可以额外的向客户端推送资源，而无需客户端明确的请求。
| 特性 | 改进 | 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
- HTTP消息可以由多个Frame构成
- 一个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的协商缓存
- 服务端读取文件修改时间，赋给相应头的
Last-Modified字段 - 设置
Cache-Control:no-cache - 客户端读取到
Last-Modified时候，会在下次的请求标头中携带字段If-Modified-Since也就是服务器第一次修改给他的时间，之后的每次请求都会带上此字段进行对比，状态码200说明说明资源无新更改，304走缓存
缺点 - 可能单纯的因为文件修改了又修改回来导致缓存失效
- 因为记录单位为秒，所以当文件在几百毫米内完成修改，缓存不会改变
基于ETag的协商缓存
解决了上面缓存的缺陷，将比较时间戳的形式改成了比较文件指纹（根据文件内容算出唯一哈希值）
过程
1.
缺点
- 计算开销更大
- 有强验证（准确到每一个字节）和弱验证（提取文件的部分属性），强缓存过于消耗性能，弱缓存准确率不高
HTTPS（Hyper Text Transfer Protocol Secure）
特点
- 信息加密：实现信息机密性；对称加密+非对称加密混合，解决了窃听的风险
- 校验机制：确保数据的完整性；用摘要算法为数据生成独一无二的指纹校验码
- 身份证书：将服务端的公钥放入到CA证书，解决服务端被冒充的冒险
混合加密
采用非对称加密的方式交换会话密钥，后续则不再使用
通信过程中，全部使用对称加密的会话密钥方式加密
使用原因：对称加密运算速度快，密钥必须保密；非对称加密解决密钥交换问题，但是速度慢
摘要算法+数字签名
摘要算法只能保证内容不被修改，不能保证发送者身份；计算机采用非对称加密来解决
数字签名
- 发送者使用私钥对消息的摘要（通常是哈希函数计算得到）进行加密，生成数字签名
- 数字签名是消息的哈希值经过私钥加密的结果
- 发送者将原始消息和生成的数字签名一起发送给接收者
- 接收者使用发送者的公钥对数字签名进行解密得到摘要值，再次使用相同的哈希函数计算收到的消息摘要，进行对比
数字证书
解决问题：缺少身份验证的过程，会存在中间人篡改公钥
流程
- 密钥生成：
- 实体生成一对密钥，包括公开的公钥和私密的私钥。
- 证书请求（CSR）：
- 实体创建包含公钥和个人信息的CSR，并将其发送至数字证书颁发机构（CA）。
- 证书颁发：
- CA验证实体后，用私钥签名CSR，生成含签名的数字证书。
- 证书验证：
- 实体用CA的公钥验证数字证书的签名，核实证书的合法性。
- 数字证书使用：
- 接收者用证书中的公钥加密数据，发送给持有者，持有者再用私钥解密。
- 持有者可用私钥创建数字签名，接收者用公钥验证以确保数据来源和完整性。
证书信任链
定义：是数字证书的验证过程的一部分，确保数字证书是由可信的证书颁发机构签发，并最终连接到根证书，形成一条链条
根证书：信任链的顶端，也称根CA证书，是数字证书体系中的根基，有操作系统或者浏览器内置
中间证书颁发机构：在信任链中，根证书下方可能有一个或多个CA，数字证书由中间CA签发
服务器证书：在最底层，由中间CA签发，包含了服务器公钥和相关信息，需在客户端验证的过程中被验证
优点
- 传输过程中，使用密钥加密，安全性跟高
- 可以认证用户和服务端，确保数据发送到正确的用户和服务器
缺点
- 握手阶段延时较高，在会话前就要进行SSL握手
- 部署成本高：需购买CA证书，占用CPU证书，需要服务器配置或者数目高
与HTTP对比
端口号：HTTP是80，HTTPS是443
HTTPS在进行完TCP三次握手之后，还需进行SSL/TSL的握手过程，才可进入加密报文传输
HTTPS协议需要向CA中心申请数字证书，保证服务器身份可靠
HTTPS 建立连接的 SSL/TLS 协议流程概述
-
客户端请求：客户端发送加密通信请求（ClientHello），与服务器建立连接。
-
服务器响应：服务器生成一对公私钥，并将公钥提交给CA机构。CA使用自己的私钥对服务器的公钥进行加密，生成CA数字证书。
-
证书发送：服务器通过响应（ServerHello）将CA数字证书发送给客户端。
-
证书验证：客户端使用内置的CA公钥解密并验证数字证书是否合法，提取出服务器的公钥。如果验证失败，客户端会发出警告。
-
生成会话密钥：客户端使用服务器的公钥生成一个随机密钥（会话密钥），并将加密后的密钥发送给服务器。
-
服务器解密：服务器用私钥解密该随机密钥，获得会话密钥。
-
加密通信：双方使用会话密钥进行加密通信，确保数据的安全传输。
扫一扫
285
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
