HTTP-基础知识

// 什么是 HTTP
1. 超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据
   互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准
   设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。
2. 特点
   1. 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
   2. 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接
      比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求
      所以每次需要重新响应请求，需要耗费不必要的时间和流量。
   3. 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
   4. 简单快速、灵活
   5. 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性
----------------------------------------------------------------------------------------------
// 什么是 HTTPS
1. 超文本传输安全协议，基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护
2. HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息
3. HTTP + SSL/TLS
----------------------------------------------------------------------------------------------
// 什么是 SSL/TLS
1. SSL 是洋文“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的
   （顺便插一句，网景公司不光发明了 SSL，还发明了很多 Web 的基础设施——比如“CSS 样式表”和“JS 脚本”）
2. 为啥要发明 SSL 这个协议捏？因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。
   发明 SSL 协议，就是为了解决这些问题。
3. 到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。
   标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。
----------------------------------------------------------------------------------------------
// 5层网络模型
1. 物理层: 电脑设备(硬件)
2. 数据链路层: 在通信的实体间建立数据链路连接(0101)
3. 网络层: 为数据在结点之间传输创建逻辑链路(百度应对www.baidu.com)，提供主机之间的通信 // IP/ICMP 协议
4. 传输层: Tcp/ip协议(端到端服务,如与百度服务器传输数据),Tcp connection连接，提供主机不同进程之间的通信 // TCP/UDP 协议
5. 应用层: Http、FTP，提供不同应用之间的通信
----------------------------------------------------------------------------------------------
// url的各个部分
1. http://www.baidu.com:80/path?search#hash
2. http // 协议
3. www.baidu.com // 主机名
4. baidu.com // 主域名
5. 80 // 端口号(http默认80,https默认443)
6. path // 路径
7. search // 查询字符串
8. hash // 锚点
----------------------------------------------------------------------------------------------
// 输入url到拿到数据的过程
1. 跳转
2. 查看应用缓存
3. DNS查找
4. 创建TCP连接
5. 发送请求
6. 接收响应
----------------------------------------------------------------------------------------------
// 请求报文中包含什么东西
1. 请求方法
2. 请求 URL
3. HTTP 协议及版本
4. 报文头 // Accept、UA、Content-Type 等
5. 报文体 // 参数
----------------------------------------------------------------------------------------------
// 响应报文中包含什么东西
1. HTTP 协议及版本
2. 状态码及状态描述
3. 响应头 // cache-control、Content-Type 等
4. 响应体 // 返回值
----------------------------------------------------------------------------------------------
// 请求方法
1. GET // 获取
2. POST // 新建
3. PATCH/PUT // 更新
4. DELETEE // 删除
5. HEAD // 和 GET 类似，但服务器在响应中只返回首部，即可以实现在不获取资源的前提下检查资源状态
6. TRACE // 观察请求报文到达服务器的最终样子，中间可能经过转发、防火墙等
7. OPTIONS // 返回服务器支持的方法，常见于跨域请求中、转发请求中
8. 幂等操作：幂等操作指的是任意多次执行所产生的影响均与一次执行的影响相同
9. 幂等函数：幂等函数指的是可以使用相同参数重复执行，并能获得相同结果的函数
10. 幂等方法：GET、DELETE、HEAD、OPTIONS、TRACE
----------------------------------------------------------------------------------------------
// 状态码
1. 1xx: 服务器收到请求
2. 2xx: 成功状态码
   1. 200 OK，请求没问题，实体的主体部分包含了所请求的资源
   2. 204 No Content，响应报文中包含若干首部和一个状态行，但没有实体的主体部分
3. 3xx: 重定向状态码
   1. 301（永久重定向） 和 302（临时重定向） 浏览器会自动跳转到在返回头中的 location 地址
   2. 304 Not Modified，所请求的资源未修改，服务器返回此状态码时，不会返回任何资源，浏览器会自动取缓存
4. 4xx: 客户端错误状态码
   1. 400 Bad Request，客户端请求的语法错误，服务器无法理解
   2. 401 Unanthorized，请求客户端在获取资源的访问权之前，没有进行认证
   3. 403 Forbidden，表示没有权限，被服务器拒绝了
   4. 404 Not Found，用于说明服务器无法找到所请求的 URL
5. 5xx: 服务器端错误状态码
   1. 500 Internal Server Error，表示服务器内部错误，无法完成请求
   2. 502 Bad Gateway，作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
   3. 503 Service Unavailable，用来说明服务器现在无法为该请求提供服务
   4. 504 Gateway Timeout，网关或代理的服务器，未及时从远端服务器获取请求，网关超时
----------------------------------------------------------------------------------------------
// Restful-API
1. 传统的API设计: 把每个url当做一个功能
2. Restful-API设计: 把每个url当做一个唯一的资源
3. 如何设计成一个资源？
      尽量不用url参数
         传统API: /api/list?id=2
         Restful-API: /api/list/2
      用method表示操作类型
         传统API:
               post请求 /api/create-blog // 创建
               post请求 /api/update-blog?id=2 // 更新
               get请求 /api/get-blog?id=2 // 获取
         Restful-API:
               post请求 /api/blog
               patch请求 /api/blog/100
               get请求 /api/blog/100
----------------------------------------------------------------------------------------------
// tcp连接
1. 一个tcp连接对应多个http请求,http基于tcp/ip
2. 创建一个tcp连接需要经过三次握手,解决网络传输中的问题
3. tcp连接在同域下最多6个,在http1.1中http请求在tcp连接中是有先后顺序的,在http2.0可以并发
4. 在请求头connection: keep-alive/close,可以保持长连接,在请求时可复用tcp连接,也可以设置连接保持多长时间
  1. 如果设置了 connection: keep-alive，则可以再设置 Keep-Alive 配置，如
     Keep-Alive: timeout=5, max=10 // 空闲 5s，最多接收 10 次请求就断开
5. 为什么要三次握手？
   1. 因为要保证双方都能明确自己和对方的收、发能力是正常的
   2. 举一个例子：已失效的连接请求报文段：
      client发送了第一个连接的请求报文，但是由于网络不好，这个请求没有立即到达服务端，而是在某个网络节点中滞留了，
      直到某个时间才到达server，本来这已经是一个失效的报文，但是server端接收到这个请求报文后，还是会想client发出确认的报文，
      表示同意连接。假如不采用三次握手，那么只要server发出确认，新的建立就连接了，但其实这个请求是失效的请求，
      client是不会理睬server的确认信息，也不会向服务端发送确认的请求，但是server认为新的连接已经建立起来了，
      并一直等待client发来数据，这样，server的很多资源就没白白浪费掉了，采用三次握手就是为了防止这种情况的发生，
      server会因为收不到确认的报文，就知道client并没有建立连接。这就是三次握手的作用。
6. 为什么要四次挥手？
   1. 服务端接收到关闭连接报文后，很可能不会立即关闭，会等所有报文都发送完后再关闭，所以需要四次
6. 三次握手流程
   1. 客户端 ===> 在么
   2. 服务端 ===> 在
   3. 客户端 ===> 知道了
7. 四次挥手流程
   1. 客户端 ===> 我要关闭连接了
   2. 服务端 ===> 知道了，等我发完包先
   3. 服务端 ===> 我也关闭连接了
   4. 客户端 ===> 好的，知道了
----------------------------------------------------------------------------------------------
// 强制缓存cache-control
1. 服务器设置cache-control: max-age = 3153600(单位是s)
2. cache-control的值:
   max-age // 过期时间
   no-cache // 不用强制缓存,到服务器请求
   no-store // 不用缓存,也不用服务端的缓存措施(协商缓存)
   private // 只允许最终用户做缓存
   public // 也允许中间代理做缓存
3. 相当于浏览器本地缓存，当发现 cache-control 还没有过期，则会直接拿本地缓存，不会请求到服务端
4. Expires 是之前的写法，现在被 cache-control 代替，两种同时存在会优先使用 cache-control
5. 只缓存静态资源，如 js、css、img
----------------------------------------------------------------------------------------------
// 协商缓存
1. 服务器缓存策略
2. 服务器判断客户端资源,是否和服务器端资源一样
3. 一致则返回304,否则返回200和最新的资源
4. 浏览器请求服务器时第一次请求会返回资源和资源标识,再次请求会带上资源标识,由服务器判断返回304或返回新的资源和新的资源标识
5. 和强制缓存的区别就是协商缓存会请求到服务端，而强制缓存不会
----------------------------------------------------------------------------------------------
// 资源标识
1. Last-Modified资源的最后修改时间只能精确到秒
2. Etag资源的唯一标识(一个字符串,类似人类指纹)
3. 1和2可以共存不互斥,会优先使用Etag
4. 服务器返回的last-modifed和浏览器带上的if-modified-since的值是一样的
5. 服务器返回的Etag和浏览器带上的if-none-match的值是一样的
----------------------------------------------------------------------------------------------
// 刷新页面的操作
1. 正常输入url地址: 强制缓存有效,协商缓存有效
2. 手动刷新F5: 强制缓存失效,协商缓存有效
3. 强制刷新ctrl+F5: 强制缓存失效,协商缓存失效
----------------------------------------------------------------------------------------------
// 数据协商
1. q为权重,q=0.8 > q=0.9
2. 请求头:
   Accept: '想要的数据类型'
   Accept-Encoding: '编码方式,数据压缩'
   Accept-Language: '语言'
   Content-Type: '发送数据的格式'
   User-Agent: '浏览器的信息'
3. 响应头
   Content-Type: '返回的数据类型'
   Content-Encoding: '哪种压缩方式'
   Content-Language: '返回的语言'
----------------------------------------------------------------------------------------------
// 内容安全策略
1. content-security-policy: default-src、connect-src、img-src、style-scr
2. 限制资源获取
3. 报告资源获取越权
----------------------------------------------------------------------------------------------
// HTTP0.9
1. HTTP 协议原型
2. 设计缺陷
3. 只支持 GET 方法
4. 不支持多媒体内容
5. 只有 HTML 对象
----------------------------------------------------------------------------------------------
// HTTP1.0
1. 最基础的 HTTP 协议
2. 支持基本的 GET、POST 方法
3. 支持多媒体对象
4. 无连接、无状态
----------------------------------------------------------------------------------------------
// HTTP1.1
1. 广泛使用
2. 长链接，Connection: keep-alive，一次 TCP 连接多次请求
3. 管道化
4. 缓存处理，cache-control、E-tag 等
5. 断点传输，状态码 206
6. 支持新的方法 PUT、DELETE 等，可以用与 Restful API
----------------------------------------------------------------------------------------------
// HTTP2.0
1. 信道复用: 在一个tcp连接上可以有多个 http 请求,不需要先后顺序
2. 二进制分帧传输: 分成不同的帧发送,并发的发送不同的请求
3. server push: 服务器主动推送
4. 性能进一步提升
5. header 压缩，减少体积
6. 大部分浏览器都支持，需要 HTTPS 才支持
----------------------------------------------------------------------------------------------
// UDP vs TCP
1. TCP 提供的是可靠的有连接服务（相当于打电话）
   1. 建立连接
   2. 通过连接进行通信
   3. 释放连接
   4. 特点：有连接、有断开、稳定传输
2. UDP 提供的是不可靠的无连接服务（相当于写信）
   1. 可靠传输：无差错、不丢失、不重复
   2. 按序到达：数据有序
   3. 特点：无连接、无断开、稳定传输、但效率高
3. 对比
   1. 性能：UDP 性能负载低，TCP 性能负载高
   2. 速度：UDP 速度快，TCP 速度慢
   3. 实现难度：UDP 实现简单，TCP 实现复杂
   4. 应用场景：UDP 简单场景，TCP 复杂场景
   5. 面向连接：UDP 无连接服务，TCP 有连接服务
   6. 可靠性：UDP 不可靠服务，TCP 可靠服务
----------------------------------------------------------------------------------------------
// TCP 粘包
1. TCP 粘包是因为两个报文被错误的解析了或被错误的拆分了
2. TCP 协议是面向字节流的协议，它可能会组合或拆分应用层协议的数据
3. 粘包并不是 TCP 协议造成的，而是应用层协议设计缺陷导致的问题
4. 应用层协议需要自行设计消息边界，以正确分离消息，避免消息粘连
5. 应用层的数据拆分的两个方法
   1. 基于长度的表示：Content-Length
   2. 基于特殊分隔符
----------------------------------------------------------------------------------------------
// VPN
1. 产生的背景
   1. 一些机构组织不需要所有计算机都接入网络
   2. 机构成员跨地域通信存在加密安全的需求（内容的 IP 通信）
----------------------------------------------------------------------------------------------
// 其他
1. 爬虫是服务器端发出的请求
2. get 请求没有 Content-Type
----------------------------------------------------------------------------------------------
// 散列算法即哈希算法（MD5）
1. 散列函数又称散列算法、哈希函数，是一种从任何一种数据中创建小的数字指纹的方法，
   散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来
2. 加盐操作
   1. 在进行加密的时候会加入自定义字符配合哈希算法进行加密，从而提高安全性
3. 从严格意义来说，哈希散列算法不能算加密算法，因为哈希散列是单向的，不具备逆向解密的能力
----------------------------------------------------------------------------------------------
// HTTPS = HTTP + TLS（传输层安全性协议）
1. HTTP 是明文传输，敏感信息容易被中间劫持
2. HTTPS = HTTP + 加密，劫持了也无法解密
3. 现代浏览器已开始强制 HTTPS 协议
4. 加密方式
   1. 对称加密：一个 Key 同时负责加密和解密
   2. 非对称加密：一对 Key，公钥加密之后，使用秘钥进行解密
   3. HTTPS 同时用到了这两种加密方式，即先通过非对称加密生成一个随机字符串
      再基于这个随机字符串进行对称加密
   4. 为什么不直接使用非对称加密
      1. 原因就是对称加密成本低，比较容易
   5. 加密过程
      1. 服务端保存着私钥和公钥，在进行通信时会把公钥传递给客户端，客户端拿到公钥后
         会使用公钥加密生成一个随机字符串，再把这个随机字符串传递给服务端，然后两端基于这个随机
         字符串进行对称加密的数据传输
      2. 存在的问题
         1. 被替换成别的公钥就完了，即中间人攻击
         2. 避免不了中间人攻击，所以需要 CA 证书
5. HTTPS 证书
   1. CA 数字证书
      1. 公钥、私钥
      2. 颁发机构信息
      3. 公司信息
      4. 域名
      5. 有效期
      6. ...
   2. 中间人攻击就是劫持了服务端的证书（包含公钥），再把服务端的证书信息替换成自己的证书信息传递给客户端
      这样客户端拿到的证书信息就是中间人的证书信息，然后客户端需要把生成的随机字符传递给服务端
      此时中间人就能通过劫持获取到随机字符串并通过自己的私钥解密客户端生成的随机字符串
      后面客户端基于随机字符串传递的信息就能够被中间人所解密，这就是中间人攻击
   3. 如何避免中间人攻击
      1. 使用第三方证书，阿里云等 // 慎用免费、不合规的证书
      2. 浏览器会自动校验证书，如果校验不通过会在页面上提示，如果通过就是显示正常地址前面的锁
6. 完整的加密过程
   1. 服务端向第三方机构申请证书，证书中包含了公钥和私钥，客户端和服务端进行通信之前，浏览器会自动
      校验证书的合法性，如果不合法则会在页面上进行提示，如果合法就会走上面的流程，即把证书（包含公钥）传递给客户端
      客户端通过公钥生成一个随机字符串传递给服务端，然后两端基于这个随机字符串进行数据传输
----------------------------------------------------------------------------------------------
// 其他
1. axios 的拦截器可以设置多个，请求拦截器如果存在多个，后面添加的会先执行，响应拦截器如果存在多个，前面添加的会先执行
  请求拦截器会返回一个 id，可以调用 eject 删除对应 id 的请求拦截器
2. axios 可以捕获到服务端的 401 或 500 异常而 fetch 不能