网络基础

基本概念

• TCP
• UDP
• IP
• Socket
• URL

OSI 七层网络分层模型

• 应用层 HTTP、FTP
• 表示层
• 会话层
• 传输层 TCP、UDP
• 网络层 IP
• 数据链路层
• 物理层

DNS

DNS (Domain Name System)，负责对域名的解析，是树状的结构

由根 DNS 服务器、顶级域 DNS 服务器和权威 DNS 服务器租车。

解析顺序，层层递归查询

• 浏览器缓存
• 操作系统缓存
• 本地 DNS 缓存 /etc/hosts
• 本地 DNS 服务器
• 根 DNS
• 顶级 DNS
• 权威 DNS

CDN

Content Delivery Netork 内容分发网络

云厂商在全球各地，建立服务器。

其中分为中心节点、区域节点、边缘节点等

用户请求时，找到离用户最合适的节点，然后通过 HTTP 缓存代理技术进行缓存，缓存命中就返回给用户，否则就回源站去拿。

擅长缓存静态资源。

UDP

• 无连接
  • 传输数据之前，不需要建立连接
• 不可靠
  • 面向无连接，造就了它不可靠
  • 只是数据报文的搬运工，不验证数据报文
    • 不保证有序且不丢失，发送方不会关系对方是否已经正确接收到数据了
  • 没有拥塞控制
    • 没有任何控制流量的算法
    • 即使网络环境不好，也不会对发送速率进行调整。
    • UDP 会一直以恒定的速度发送数据。
• 传输方式
  • 不但支持一对一，还支持广播、多播
• 高效轻便
  • 上面的缺点，造就了它的高效
  • 相比 TCP 轻便
  • 头部只有八字节，而 TCP 至少二十个字节
• 适合的场景
  • 对实时要求高的地方
  • 游戏
  • 直播

TCP

TCP提供了一种可靠、面向连接、字节流、传输层的服务，采用3次握手建立一个连接。采用4次挥手来关闭一个连接。

相比 UDP，更为可靠。

时序控制

三次握手

为了明确自己和对方的收和发是正常的。

• 明确自己的收发能力
• 明确对方的收发能力

TCP 层，有个 FLAGS 字段，这个字段有以下几个标识

• 标识符
  • SYN: Synchronize sequence numers 表示建立连接
  • ACK: Acknowledgment field significant 表示响应
  • FIN: 表示关闭连接
  • 当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文。
    • SYN = 1，seq = x 对应的是 ACK = 1, ack = x + 1
  • FIN=1：该字段为一表示此报文段是一个释放连接的请求报文。
  • ACK=1：该字段为一表示确认号字段有效。此外，TCP 还规定在连接建立后传送的所有报文段都必须把 ACK 置为一。
  • seq 为报文的序列号 (sequence number)
  • ack 为报文的确认序号 (Acknowledgement Number)，不是大写的 ACK

主要过程

1. 客户端主动发起

• SYN = 1，seq = x（客户端随机序号）
• 客户端进入 SYN-SENT 状态

2. 服务端看到 SYN = 1，知道客户端想建立连接，服务端将标志位 SYN = 1 和 ACK = 1 ack(确认号)为 x + 1，表示对客户端 x 的确认，服务端也产生一个随机数 y，并将该数据包发送给客户端以建立连接请求，

• SYN = 1 ACK = 1 seq = y(服务端随机生成的) ack = x + 1
• 服务端从 LISTEN 状态进入 SYN-RECEIVED 状态

3. 客户端再进行一次确认，将 ACK = 1, seq = x + 1 ack = y + 1，表示对服务端需要 y 的确认

• ACK = 1, seq = x + 1 ack = y + 1
• 客户端和服务端都进入 ESTABLISHED 状态

为什么需要三次握手？

• 第一次握手：客户端发送网络包，服务端收到了.
  • 服务端
    • 可以确保服务端的收是正常的
    • 可以确保客户端的发是正常的
  • 客户端
    • 什么都不知道
• 第二次握手，服务端发包，客户端收到了
  • 服务端
    • 可以确保服务端的收是正常的 第一次握手
    • 可以确保客户端的发是正常的 第一次握手
  • 客户端
    • 可以确保服务端的发是正常的 第二次握手
    • 可以确保服务端的收是正常的 第二次握手
      • 因为第一次握手是客户端发的
      • 第一次握手成功了，才会有第二次握手服务端发送，所以说明服务端收到了
    • 可以确保客户端的收是正常的 第二次握手
    • 可以确保客户端的发是正常的 第二次握手
      • 因为第一次握手是客户端发的
• 第三次握手，客户端发包，服务端收到了。
  • 服务端
    • 可以确保服务端的收是正常的 第一次握手
    • 可以确保服务端的发是正常的 第三次握手
    • 可以确保客户端的收是正常的 第三次握手
    • 可以确保客户端的发是正常的 第一次握手
  • 客户端
    • 可以确保服务端的发是正常的 第二次握手
    • 可以确保服务端的收是正常的 第二次握手
    • 可以确保客户端的收是正常的 第二次握手
    • 可以确保客户端的发是正常的 第二次握手
• 第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。
• 所以才需要三次握手

四次挥手

• A：我不爱你了
  • FIN 标记位设为 1 告诉服务器打算断开连接，后面不会再发送数据
  • FIN，seq=p
• B：我知道了，我还难舍难分
  • 服务器收到 FIN 为 1 的 TCP 头部时，同时向客户端发送一个 ACK，告诉客户端我收到了
  • ACK，ack=p+1
• B：我也不爱你了
  • 等待数据全部传输完毕，发一个 FIN 为 1 的信息，告诉对方准备断开连接，但还没有断开
  • FIN, ACK,seq=q, ack=p+1
• A: 好聚好散
  • 客户端返回 确认信号，断开连接
  • ACK, ack=q+1

TCP 状态机

滑动窗口

拥塞控制

TCP 和 UDP 区别

• 都是传输层的协议
• TCP
  • 面向连接
  • 面向字节流
  • 有状态
  • 保证可靠交付
  • 点对点传播
  • 有序
• UDP
  • 无连接
  • 面向数据包
  • 无状态
  • 不保证可靠交付
  • 广播、多播
  • 无序
  • 应用
    • DNS

HTTP/1.1

超文本传输协议，应用层的协议。传输文字、图片、音频、视频等超文本数据的约定和规范。

引入 keep-alive(保持连接)

Chrome 浏览器只允许同时打开 6 个 TCP 连接 打开多个 TCP 连接，会对服务器造成太大的压力 （DDos）

1.0的区别 没有 keep-alive，每次都要 say hi(建立 TCP 连接)

SSL

CA 证书链

首部字段

通用头部字段

• Cache-Control
• Date 创建报文的世界
• Upgrade 升级为其他协议 请求首部字段
• Authorication 认证信息
• Accept:image/webp,image/apng,image/,/*;q=0.8
  • 客户端或代理能处理的媒体类型
• Accept-Encoding: gzip, deflate, br
• Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6
• Host 单台服务器同一个 IP 分配多个域名的情况，明确指出请求的主机名。
• 缓存相关
  • If-None-Match
  • If-Modified-Since
• Range 实体的字节范围请求
• Referer 请求的 URI 是从哪个 Web 页面发起的
• User-Agent 客户端信息 响应首部字段
• 缓存相关
  • ETag
• Location
  • 浏览器在接收到包含 Location 的响应后，都会对已提示的重定向资源尝试访问
  • 通常和 3xx Redirection 配合，提供重定向的 URI
• Server 服务器信息
• Vary 代理服务器缓存信息 实体首部字段
• 包含在 POST 请求报文和响应报文中的实体部分
• Allow
• Content-Langurage
• Content-Encoding
• Content-Length
• Content-Type
• Content-Range
  • 配合 206 状态码
  • Content-Range: bytes 5001-10000/10000 先返回 5001 - 10000 字节给你
• Expires
• Last-Modified
• 其他首部字段
  • X-Frame-Options

    防止点击劫持攻击，HTTP 响应首部，用于控制网站内容在其他 Web 网站内的 Frame 标签内的显示问题

    • DENY
    • SAMEORIGIN，
  • X-XSS-Protection

    XSS 过滤，HTTP响应首部，针对 XSS 攻击的一种对策，用来控制浏览器 XSS 防护机制的开关

    • 0
    • 1
  • DNT

    Do Not Track 拒绝个人信息被手机

    • 0
    • 1

无状态

报文

响应报文

• 响应行
• 响应头
• 响应体

请求方法

GET 和 POST 区别

• Get 请求能缓存，Post 不能

• 数据传输方式不同
  • GET 请求通过URL传输
  • POST 请求通过 body 传输

• Post 可以传送更多的数据
• Post 请求可以上传图片 支持更多的编码类型且不对数据类型限制

POST 请求格式

其他请求方法

• GET 获取资源 幂等
  • 幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同
• POST 新增资源
• PUT 更新资源 带条件时幂等
• HEAD 获取头部 幂等
• DELETE 删除资源 幂等
• OPTIONS 获取服务器支持访问资源的方法 幂等
  • CORS 预检请求
• TRACE 回显服务器收到的请求
• PATCH：用于对资源进行补发修改
  • 可以不用带很多无用的信息，比如 PUT 请求

状态码

1xx 101 切换协议 2xx 成功

• 200 成功返回响应
• 206 Partical content，表示客户端进行了范围请求，响应报文中包含由 Content-Range 指定范围的实体内容 3xx 重定向
• 301 永久重定向
  • 书签要修改了
• 302 Found 临时重定向，✨
  • 代表资源不是被永久移动，只是临时性质的。
  • 仍然返回原来的页面
  • 希望用户能使用新的 URI 访问
• 303 和 302 有相同的功能，但是 303 表示客户端应该使用 GET 来获取资源
• 304 not modefied 未修改
• 307 temporary redirect，临时重定向，和302含义相同 4xx 客户端错误
• 400 Bad Request，表示服务端无法理解客户端的请求 请求报文存在语法错误 ✨
• 401 Unauthorized 没认证 ✨
  • 该状态码表示发送的请求必须通过 HTTP 认证（BASIC认证 DIGEST 认证）
  • 返回含有 401 的响应必须包含一个 WWW-Authenticate 首部来用以质询用户信息
  • 当浏览器初次接收到 401，会弹出认证用的对话窗口
• 403 Forbidden 请求的资源被服务器拒绝 ✨
• 404 Not Found 服务器上没有请求的资源 ✨
• 405 请求方法无效 5xx 服务端错误
• 500 Internal Server Error ✨
  • 在执行请求时发生了错误
  • 内部错误了 bug 什么的
• 501 请求方法不支持
• 502 网关错误
• 503 Service Unavailable 服务不可用

  服务器超负载或者正在进行停机维护，现在无法处理请求

  • 可以配合 Retry-After 首部字段返回给客户端

缓存策略

• 强缓存
  • Cache-Control
    • private：客户端可以缓存，代理服务器不能缓存
    • public 客户端和代理服务器都可以缓存
    • max-age=xxx 单位秒
    • no-cache 可以缓存，使用前必须去服务端验证是否过期（缓存但重新验证）

    此方式下，每次有请求发出时，缓存会将此请求发到服务器（译者注：该请求应该会带有与本地缓存相关的验证字段），服务器端会验证请求中所描述的缓存是否过期，若未过期（注：实际就是返回304），则缓存才使用本地缓存副本。

    • no-store 不缓存，
  • 强缓存失效，走协商缓存
  • 大部分场景，强缓存配合协商缓存解决
    • 代码文件可以只使用强缓存，并配合文件指纹处理
    • 对于频繁变动的资源，可以使用 Cache-Control: no-cache 并配合 ETag 使用，表示该资源已被缓存，但是每次都会发送请求询问资源是否更新。
• 协商缓存
  • Etag / Last-Modified
    • 第一次无缓存的访问，下发 cache-control 和 文件 Etag
    • 如果下次强缓存不生效，下次请求带上If-None-Match，服务端会比对Etag
  • 还有一个 Last-modifled / If-Modified-Since 优先级不如上面那个高

HTTP 发展历史

HTTP/2

队头阻塞是 HTTP/1.1 的问题，导致达到最大请求数量时，需要排队。前身是SPDY，优化并解决了HTTP1.X 队头阻塞，效率低，头大（臃肿）等问题。

• 头部压缩
  • 1.1 头部会重复发送，1.1 的头部比 1.0 的多，因为多发送一个 keey-alive （重用上一次 TCP 连接）
  • 采用 HPACK 对消息头部进行压缩传输，首部只传输 新的头信息
  • 头字段进行数据压缩，发送的体积会变小，省了很多数据量（流量也省了）
  • 可以理解为只发送差异数据，而不是全部发送，从而减少头部的信息量
• 二进制分帧层 binary framing layer（核心）
  • 1.1 的问题，head of line blocking 队头阻塞（我怎么请求你怎么返回给我，先请求图片1，再请求图片2，即便图片2返回了，也要等图片1，才能处理图片2）
  • 采用二进制将消息分成帧传输数据，而非 1.1 的文本格式
• 服务端推送
• 多路复用
  • 同域名下所有通信都在单个 TCP 连接上完成。
  • 只需要一个 TCP 连接，1.1 版本需要多个 TCP 连接
  • 类似于通信工程里的时分复用
  • 并发
  • 多个请求可以同时发送（不分先后），同时响应
  • 一个 TCP 连接存在多条流
    • 也就是说可以发多个请求
    • 通过帧中的标识知道属于哪个请求

优势

1. 省数据流量
2. 网页打开速度变快
3. 只要一个 TCP，省 CPU 和 内存

HTTP/3

基于 QUIC 协议的 HTTP

• 基于 UDP
• TCP 太重，慢启动
• 基本消除了队头阻塞
• 改进的拥塞控制和流量控制

HTTPS

全称HyperText Transfer Protocol over Secure Socket Layer，基于安全套接字层的超文本传输协议。

HTTP 的不安全 - 中间人攻击。

先回答下面的问题：

1. 为什么要用对称加密+非对称加密？
2. 为什么不能只用非对称加密？
3. 为什么需要数字证书？
4. 为什么需要数字签名？

所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。在 HTTP 和 TCP 之间加入了 TLS 安全套接层。结合对称加密和非对称加密的各自优点，配合证书，既保证了安全，也保证了传输效率。

• 信息加密：使用对称加密和非对称加密的方式
  • 在交换密钥环节使用非对称加密方式
  • 交换报文阶段则使用对称加密
• 完整性校验
  • 内容传输经过完整性校验
• 身份认证
• SSL（Secure Sockets Layer）中文叫“安全套接层
  • 后来由于广泛应用，SSL标准化之后就改名为 TLS（Transport Layer Security）

对称加密

使用相同的密钥进行加密和解密

（AES）是对称密码的一个常见用例。

非对称加密

数据用公钥加密后必须用私钥解密

速度慢，CPU 开销大，常见非对称加密算法有 RSA。

• 公钥的作用
  • 加密
    • 公钥负责加密，私钥负责解密
  • 验证签名
    • 私钥负责签名，公钥负责验证

通信流程

• 客户端发起 HTTP 请求
• 服务端返回 CA 证书
  • CA 证书包含服务端的公钥

在没有引入证书颁发机构（CA）前

• 在小灰和小红建立通信的时候，小红首先把自己的公钥Key1发给小灰：
• 收到小红的公钥以后，小灰自己生成一个用于对称加密的密钥Key2，并且用刚才接收的公钥Key1对Key2进行加密，发送给小红
• 小红利用自己非对称加密的私钥，解开了公钥Key1的加密，获得了Key2的内容。从此以后，两人就可以利用Key2进行对称加密的通信了。
• 在通信过程中，即使中间人在一开始就截获了公钥Key1，由于不知道私钥是什么，也无从解密。
• 中间人攻击
  • 但是，中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰
  • 小灰不知道公钥被偷偷换过，以为Key3就是小红的公钥。于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给小红。
  • 这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红。

数字证书

CA：翻译为认证机构

CA证书 是由CA（Certification Authority 认证机构）机构发布的数字证书。

其内容包含：电子签证机关的信息、公钥用户信息、公钥、签名和有效期。

即：证书 = 公钥 + 签名 + 申请者 + 颁发者的信息

各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥

1. 作为服务端的小红，首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。
2. 证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给了服务端小红。
3. 当小灰向小红请求通信的时候，小红不再直接返回自己的公钥，而是把自己申请的证书返回给小灰
4. 小灰收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以小灰只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名
5. 接下来，小灰按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。
6. 验证成功后，小灰就可以放心地再次利用机构公钥，解密出服务端小红的公钥Key1。
7. 像之前一样，小灰生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给小红。
8. 最后，小红用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信

• 中间人可以攻击吗？
  • 证书是由服务端网址等信息生成的，并且经过机构私钥加密，中间人无法篡改。

TLS SSL

• TLS 传输层安全加密协议
• 最新推出的 TLS 协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的

抓包与反抓包

常用的 HTTPS 抓包方式是作为中间人，对客户端伪装成服务端，对服务端伪装成客户端。

为了防止中间人攻击，可以使用 SSL-Pinning 的技术来反抓包

• 中间人攻击的要点的伪造了一个假的服务端证书给了客户端，客户端误以为真
• 解决思路就是，客户端也预置一份服务端的证书，比较一下就知道真假了
  • 客户端内置证书或者公钥
    • 别人把你的证书解包解出来呢？
  • SSL-pinning有两种方式： 证书锁定（Certificate Pinning） 和公钥锁定（ Public Key Pinning
    • 公钥锁定提取证书中的公钥并内置到客户端中，通过与服务器对比公钥值来验证连接的正确性

原理

QUIC

QUIC 全称 Quick UDP Internet Connection，是由 Google 提出的使用 UDP 进行多路并发传输的协议。

其主要优势是:

1. 减少了握手的延迟（1-RTT 或 0-RTT）
2. 多路复用，并且没有 TCP 的阻塞问题
3. 连接迁移，（主要是在客户端）当由 Wifi 转移到 4G 时，连接不会被断开。

QUIC 目前处于实验期，使用了正在标准化过程中的 IETF 实现，不能保证与最终版本的兼容性。

WebSocket

• 基于 TCP 的轻量级网络通信协议
• 是一个全双工通信协议
  • HTTP 是半双工，即 请求-应答
  • 可以服务端主动推送
• Webpack 热更新就用到了 WebSocket协议
• 出现原因
  • 为了解决 HTTP 半双工的问题
  • HTTP2 为了解决 HTTP 队头阻塞的问题
• 应用场景
  • 即时通讯
  • 游戏
  • 可视化

跨域 CORS/JSONP

浏览器的同源策略，同源策略要求源相同才能正常进行通信。即协议、域名、端口号都完全一致

同源策略限制

• DOM

• Cookie、Storage

• AJAX

• 跨域只存在于浏览器端，不存在于安卓、ios、Nodejs

• 跨域请求能发出去，服务端能收到请求并正常返回结果，只是结果被浏览器拦截了

• CORS

  • 浏览器检测到响应头带上了CORS，并且允许的源包括了本网站，那么就不会拦截请求响应

• Ajax 请求跨域时会被分为两种请求

  • 简单请求
    • 三种方法之一：HEAD、GET、POST
    • 头信息不超出以下字段：Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type（不超出application/x-www-form-urlencoded、multipart/form-data、text/plain）。
  • 非简单请求
  • 预检请求 OPTIONS方法
    • 返回预检请求的有效期，在有效期内不会再发一个options请求

• JSONP 跨域

  • script 不受跨域限制
    • 优点
  • 缺点
    • 只支持 get 请求
    • 安全性问题
    • 服务端需要改造

• Nginx 反向代理

• 其他

  • postMessage() 跨域
  • WebSocket 跨域

跨域时如何避免 OPTIONS 请求？

1. 使用简单请求
2. 规避自定义头部

CORS 头信息

• 请求
• 响应
  • Access-Control-Max-Age 预检请求有效期
  • Access-Control-Allow-Headers
  • Access-Control-Expose-Headers
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Origin
  • Access-Control-Allow-Credentials

流程

telnet 协议发邮件 伪造发件人

为什么有这个教程？因为我的邮箱今天收到了一封勒索邮件，发件人是我自己，因此我开始了探索。

什么是Telnet？

Telnet是远程连接服务，它工作于在tcp/ip协议的应用层。

telnet 命令通常用来远程登录邮箱

telenet 看一个星战的ASCII电影

telnet towel.blinkenlights.nl

伪造发件人

!> 注意： 实际的发件人必须填当前账号

mail from : <xxx@163.com>
rcpt to : <xxx@163.com>

实现原理：

利用的就是data内容的的 from 和 to 可以随意填

ipv4 & ipv6

IPV4: 每個部份的數字會呈現0至255的整數，並以「.」做區隔，譬如群盟網站的IP位址為「210.200.133.161」。

IPV6: 區隔每個部分的方式亦與IPv4不同，是以「:」表示。譬如「1079:0BD3:6ED4:1D71:414B:2E2A:7144:72BE」，這樣就是一組標準的IPv6網路位址。

• 通过 IPv6 可以带来 10%~15% 的性能提升
  • IPv6 是固定报头，不像 IPv4 那样携带一堆冗长的数据，简短的报头提升了网络数据的转发效率
  • IPv6 的路由表更小，聚合能力更强，保证了数据转发的路径更短，极大的提高了转发效率
• ipv6 可以为每一粒沙子标识身份
• 更安全
  • IPv6 则是直接集成了 IPSec，在网络层认证与加密数据，为用户提供端到端的数据安全，保证数据不被劫持

Mixed content

• 解决1 我们可以在 head 中添加 meta 标签，浏览器会在加载HTTP资源时自动替换成HTTPS请求。

  meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

• 解决2 资源链接替换为自适应链接 //

HTTP 内容协商 Vary

Accept 字段

Accept-Encoding:gzip,deflate,sdch
Accept-Language:zh-CN,en-US;q=0.8,en;q=0.6

HTTP 协议规定，如果服务端提供的内容取决于 User-Agent 这样「常规 Accept 协商字段之外」的请求头字段，那么响应头中必须包含 Vary 字段，且 Vary 的内容必须包含 User-Agent

provisional headers are shown

出现的情况有这么几种

• 跨域，请求被浏览器拦截
• 请求被浏览器插件拦截
• 服务器出错或者超时，没有真正的返回
• 强缓存from disk cache或者from memory cache，此时也不会显示

前端 web 密码加密是否有意义

今年上半年，GitHub 就翻车过一次，在请求日志里发现了明文密码，然后就群发邮件通知用户改密码。

目的

• 保证中间人无法拿到明文密码
  • HTTPS 的诞生就是为了解决中间人攻击的问题
• 增加拖库后的数据破解难度

做法

• 后端不存储明文，存储哈希
  • 哈希算法不可逆
  • 后台对于用户密码处理也是用哈希算法
  • 登录时，将密码哈希和数据库对应的哈希数据比对，若一致则说明密码正确
  • 存数据库前再来一次 aes 防止脱库
• 使用 HTTPS

Base64 编码

Base64 是编码，不是加密，并且可逆

哈希与加密

哈希与加密是两个不同的东西

• 哈希算法通常用于数据摘要
  • 一个哈希算法是一个多对一的映射关系
  • 比较常用的哈希算法是 MD5 和 SHA1
  • 攻击方法：寻找碰撞法和穷举法
    • 为了保证数据的安全，可以在哈希算法的基础上进一步的加密，常见的方法有：加盐、慢哈希、密钥哈希、XOR 等。
  • 哈希算法不可逆
    • 加密算法可逆
• 加密算法中又分为对称加密（symmetric encryption）和非对称加密（asymmetric encryption）。
  • 对称加密中，加密和解密都是用同一个密钥，如 AES / DES
  • 从性能上来说，非对称加密相对于对称加密要慢很多。
  • 非对称加密算法中，加密密钥和解密密钥是不同的，分为私钥和公钥

优化哈希

前端加密后，中间人攻击者仍然可以使用拿到的哈希值进行直接登录。使用前端加密如何避免中间人重放攻击？

1. 加盐

如果 Salt 不是每次登陆不同，那么攻击者仍可以使用加密后的密码进行直接登陆

所以必须使用动态 Salt。

动态 Salt 有很多方法，可以是动态的 Token，也可以直接使用现成的图形验证码。

前端先将密码哈希，然后和用户输入的验证码进行哈希，得到的结果作为密码字段发送给服务器。服务器先确认验证码正确，然后再进行密码验证，否则直接返回验证码错误信息。

Content-Dispositio

• 作为对下载文件的一个标识字段
• 两种属性
  • inline
    • 文件内容直接显示在页面
  • attachment
    • 弹出对话框让用户下载

200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 22

<HTML>Save me!</HTML>

HTTP2 的速度是不是完胜 HTTP 了？

• 快的方面？
  • 压缩了头部
  • 二进制数据帧
  • TCP 连接多路复用
• 慢的方面
  • SSL 握手慢
    • 不对称加密慢
    • HTTP2 只能在 HTTPS 上用

responseType

• ''
  • 与 test 相同
• text
• arraybuffer
  • 包含二进制数据的 ArrayBuffer
• blob
  • 包含二进制数据的 Blob 对象
• document
• 是一个 HTML 或者 XML
• json
  • 是一个 JS 对象

mime-type

• text
  • text/plain
    • 表示文本文件的默认值
• image
  • image/png
  • image/webp
• audio
  • audio/mpeg
  • audio/mpeg
• video
• application
  • application/octet-stream
  • application/xml
  • application/pdf
  • .xls
    • application/vnd.ms-excel
  • .xlsx
    • Microsoft Excel (OpenXML)
    • application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
  • .zip
    • application/zip
  • .ppt
    • application/vnc.ms-powerpoint

Vue 项目的网络优化

• 配置缓存策略
  • 或者上传到 CDN
• 配置 gzip
  • 阿里云的CDN服务支持GZIP功能
• 开启 service worker

map $sent_http_content_type $expires {
    "text/html"                 epoch;
    "text/html; charset=utf-8"  epoch;
    "text/css"                  max;
    application/javascript     max;
    ~image/                    max;
    default                     off;
}

server {
    listen          80;             # the port nginx is listening on
    server_name     taurus-fe.test.shouqianba.com;    # setup your domain here

    gzip            on;
    gzip_types      text/plain application/xml text/css application/javascript;
    gzip_min_length 1000;
    gzip_proxied  any;
    gzip_vary on;
    gzip_comp_level 6;
    gzip_buffers 16 8k;
    gzip_http_version 1.1;

    location /MP_verify_ojJWN8wLax9C5qfJ.txt {
        return 200 'ojJWN8wLax9C5qfJ';
    }

    location / {
        expires $expires;
    }

学习

程序员小灰

极客时间 - 趣谈网络协议