HTTP-相关

1. DNS 查询得到 IP

• 为什么需要 IP: TCP/IP 通过 IP 地址 来确定 通信对象的。

• 域名和 IP 地址并用的理由：

  • IP 地址占内存小。IP 地址长度为 32 bit（4 字节），域名需要几十甚至 255 字节
  • IP 地址难记。
  • 人使用名称，路由器使用 IP 地址。
• DNS 解析得到的 IP，只是实体主机的 IP，并不是要访问的 web 应用服务器的 IP 地址（比如虚拟主机，实体主机会根据域名把连接转发给对应的虚拟主机）

• TCP/IP 的结构：

  • TCP/IP，由一些小的子网，通过路由器 连接起来组成的大的网络。
  • 网络中的所有设备都会被分配一个地址，这个地址就是 IP 地址，通过 IP 地址，可以判断出消息应该发送到哪个服务器。
  • 发送者发出的消息 -> (经过)子网中的集线器 ->（转发到）最近的路由器 -> 根据消息的目的地判断下一个路由器的位置 -> 将消息发送到下一个路由器（不断重复，直到目的地）

• 实际的 IP 地址：

  • 是一串 32 比特的数字，按照 8 比特 (1 字节) 为一组分成 4 组，分别用十进制表示，然后再用圆点隔开。
  • IP 地址的规则中, 网络号和主机号连起来总共 32 比特, 但这两部分的具体结构是不固定的。
  • 所以 需要用到子网掩码，子网掩码的格式是一 串与 IP 地址长度相同的 32 比特数字, 左边一半都是 1，右边一半都是 0。子网掩码为 1 的部分表示网络号，子网掩码为 0 的部分表示主机号。全 0：表示整个子网。全 1：表示向子网上所有设备发送包，即“广播。

• 查询顺序：

  • 浏览器缓存
  • 本地缓存
  • 本地 host 文件
  • 向 dns 域名服务器查询
• 优化：使用 dns-prefetch 优化

• 向 dns 域名服务器查询的过程：（比如，http://www.a.b.com）

  • 根域服务器（台数有限。没有，则告诉它 .com 的 IP 地址）
  • 顶级域名服务器（没有，则告诉它，http://b.com 的 IP 地址）
  • 二级域名服务器（没有，则告诉它，http://a.b.com 的 IP 地址）
  • 三级域名服务器（返回 http://www.a.b.com 的 IP 地址）

• 通过缓存加快 DNS 服务器的响应：

  • 真实互联网中：一台 DNS 服务器，可以管理多个域的信息。
  • DNS 服务器有缓存功能：并不需要从根域开始查找，通过缓存可以直接返回响应, 接下来的查询可以从缓存的位置开始向下进行。相比每次都从根域找起来说, 缓存可以减少查询所需的时间。
  • 信息被缓存后, 原本的注册信息可能会发生改变, 这时缓存中的信息就有可能是不正确的，因此缓存信息会设置有效期，当缓存中的信息超过有效期后, 数据就会从缓存中删除。
• 用命令来查看整个 DNS 请求过程：http://www.ruanyifeng.com/blo…

2. HTTP 劫持：

• 分为 DNS 劫持 和 内容劫持

• DNS 劫持：

  • DNS 服务器收到攻击，返回 假的 IP 地址或者不做任何处理使请求失效。最终的效果就是，特定的网络不能访问或者访问假的网址。

  • 解决：（DNS 的劫持是通过 攻击运营商的解析服务器来达到目的的）

    • 使用自己的解析服务器 或者
    • 在自己的 App 中将解析好的域名以 IP 的形式发出去

• 内容劫持：

  • 背景：

    • 运营商为了 加快 用户的 访问速度，减少自己的流量损耗做的一个缓存机制。
    • 用户 请求数据，如果缓存池中有，直接返回。
    • 如果没有，则向服务器发出请求，将返回的数据拦截，先存入缓存池，然后再返回给用户。
  • 产生：恶意篡改 服务器的缓存内容
  • 解决：这种并不多，目前没有好的解决方案

3. TCP/IP 请求

• 三次握手（建立连接）

  • SYN
  • ACK ,SYN
  • ACK

• 四次挥手（断开连接）

  • FIN, ACK
  • ACK
  • FIN,ACK
  • ACK

• TCP 慢启动：

  • TCP 慢启动

    • TCP 三次握手后，如何一开始就发送大量的数据报，很容易导致网络中路由缓存空间耗尽，从而发生拥塞，所以根据出事的窗口大小逐步增加发生的数据量，窗口初始化为 1 个最大报文段大小，每当有一个报文段被确认，窗口呈指数增长。

  • 拥塞避免

    • 窗口（cwnd）不能一直增加，增加到 TCP 的慢启动门限（ssthresh），慢启动阶段结束，开始避免拥塞阶段，窗口大小呈线性增长。
    • 如何判断拥塞？发送方没有在时间间隔内收到接收方的 ACK，就认为网络拥塞。
    • 发生拥塞后：把启动门限将为目前窗口的一般；把目前窗口重置为 1，重新进入慢启动过程。

  • 快速重传

    • 接收方成功的接受了发送方发送来的 M1、M2 并且分别给发送了 ACK，现在接收方没有收到 M3，而接收到了 M4，显然接收方不能确认 M4，因为 M4 是失序的报文段。如果根据可靠性传输原理接收方什么都不做，但是按照快速重传算法，在收到 M4、M5 等报文段的时候，不断重复的向发送方发送 M2 的 ACK, 如果接收方一连收到三个重复的 ACK, 那么发送方不必等待重传计时器到期，由于发送方尽早重传未被确认的报文段。
    • 把慢启动门限设置为当前窗口的一半；把当前窗口设为慢启动门限；重新进入拥塞避免阶段。

  • 快速恢复

    • 快速恢复的数据包守恒原则，即同一个时刻在网络中的数据包数量恒定，“老”数据包离开后，才能向网络中发送“新”的数据包。如果发送方收到一个重复的 ACK，TCP 的 ACK 机制就表明有一个数据包离开，此时 cwnd 加 1。
    • 当收到 3 个重复 ACK 时，把 ssthresh 设置为 cwnd 的一半，把 cwnd 设置为 ssthresh 的值加 3，然后重传丢失的报文段，加 3 的原因是因为收到 3 个重复的 ACK，表明有 3 个“老”的数据包离开了网络。
    • 再收到重复的 ACK 时，拥塞窗口增加 1。
    • 当收到新的数据包的 ACK 时，把 cwnd 设置为第一步中的 ssthresh 的值。原因是因为该 ACK 确认了新的数据，说明从重复 ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

• UDP:

  • UDP，又称 用户数据协议，属于网络传输层。

  • UDP，提供面向事务的、简单、不可靠信息传输服务。

    • 事务：原子性（要么都发生，要么都不发生），持久性（只要事务提交了，它的作用就是永久的），隔离性（各个事务之间是独立的），一致性（事务前后的状态是一致的）
  • 由于无需连接，资源消耗低，处理快速且灵活，所以常应用在丢一两个数据包也不会发生重大的影响的场景，比如音频、视频。
  • DNS 服务就是基于它实现的。

  • UDP 发送数据报的上限决定因素:

    • UDP 协议本身，UDP 协议中有 16 位的 UDP 报文长度，那么 UDP 报文长度不能超过 2^16=65536；
    • 以太网数据帧的长度，数据链路层的最大传输单位（MTU）；
    • socket 的 UDP 发送缓存区大小；
    • 在 internet 下使用 UDP 协议，每个数据报最大的字节数为：576（在 Internet 下 MTU 的值为 576 字节）– 20（IP 协议本身封装包头占 20 个字节）– 8（UDP 包头占 8 个字节）= 548

• TCP 和 UDP 区别：

  • 建立连接方式不同：

    • UDP 不面向连接，TCP 面向连接，所有的会话都基于连接完成；
    • TCP 面向连接、可靠的、有序的传输层协议。UDP 面向数据报、不可靠、无序的传输协议。
    • 就好比发短信一样，UDP 只需要知道对方的 ip 地址，将数据报一份一份的发送过去就可以了，其他的作为发送方，都不需要关心。
    • UDP 中，一个 socket 可以与多个 UDP 通信; TCP 中，一个 socket 只能与一个 TCP 通信；每一条 TCP 连接只能是点到点的;UDP 支持一对一，一对多，多对一和多对多的交互通信；

  • 数据发送方式不同：

    • TCP，是建立在两端连接之上的协议，所以理论上发送的数据流不存在大小的限制。如果用 TCP 发送了一段很大的数据，可能会被截断成好几段，接受方依次的接收。
    • UDP，本身发送的就是一份一份的数据报，所以有上限。

  • 数据有序性的不同：

    • TCP 保证有序，UDP 不保证有序；
    • 对于 TCP 来说，本身 TCP 有着超时重传、错误重传、还有等等一系列复杂的算法保证了 TCP 的数据是有序的，假设你发送了数据 1、2、3，则只要发送端和接收端保持连接时，接收端收到的数据始终都是 1、2、3。
    • 而 UDP 协议则要奔放的多，无论 server 端无论缓冲池的大小有多大，接收 client 端发来的消息总是一个一个的接收。并且由于 UDP 本身的不可靠性以及无序性，如果 client 发送了 1、2、3 这三个数据报过来，server 端接收到的可能是任意顺序、任意个数三个数据报的排列组合。

  • 可靠性的不同：

    • TCP 本身是可靠的协议，UDP 是不可靠的协议；
    • TCP 内部的很多算法机制让他保持连接的过程中是很可靠的。比如：TCP 的超时重传、错误重传、TCP 的流量控制、阻塞控制、慢热启动算法、拥塞避免算法、快速恢复算法 等等。所以 TCP 是一个内部原理复杂，但是使用起来比较简单的这么一个协议。
    • UDP 是一个面向非连接的协议，UDP 发送的每个数据报带有自己的 IP 地址和接收方的 IP 地址，它本身对这个数据报是否出错，是否到达不关心，只要发出去了就好了。
  • TCP 面向字节流，实际上是 TCP 把数据看成一连串无结构的字节流;UDP 是面向报文的；UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）
  • TCP 首部开销 20 字节;UDP 的首部开销小，只有 8 个字节；

  • 使用场景:

    • 使用 UDP 的场景：对实时性要求高、多点通信；
    • 对实时性要求高：比如实时会议，实时视频这种情况下，如果使用 TCP，当网络不好发生重传时，画面肯定会有延时，甚至越堆越多。如果使用 UDP 的话，即使偶尔丢了几个包，但是也不会影响什么，这种情况下使用 UDP 比较好；
    • 多点通信：TCP 需要保持一个长连接，那么在涉及多点通讯的时候，肯定需要和多个通信节点建立其双向连接，然后有时在 NAT 环境下，两个通信节点建立其直接的 TCP 连接不是一个容易的事情，而 UDP 可以无需保持连接，直接发就可以了，所以成本会很低，而且穿透性好。这种情况下使用 UDP 也是没错的。

4. 五层 intel 协议栈：

• 应用层（dns，https）
• 传输层（tcp，udp）
• 网络层（ip，arp）ip 寻址【不懂这个，https://blog.csdn.net/wenqian…】
• 链路层（ppp）封装成帧
• 物理层

5. HTTP 请求：

• 构成：

  • 请求报文由请求头和请求体组成；请求头包含请求行（方法，URL，协议）和请求头字段；
  • 响应报文由响应头和响应体组成；响应头包含状态行（协议，状态码，状态码原因短语）和响应头字段；
  • 在头之后，以一个空行（两个换行符）为分隔;

• 常用的请求头和响应头有哪些？

  • 请求头：

    • Accept-Encoding/Accept-Language/Accept-chart
    • connection：keep-Alive/close
    • referer: 请求的原始 URL
    • origin：请求的协议和域名
    • host：发送目的地的协议和域名
    • cookie：cookie 值
    • if-modified-since：对应服务器的 last-modified
    • if-no-match：对应服务端的 etag
    • cache-control: 控制缓存的时效性
    • Access-Control-Request-Method
    • Access-Control-Request-Headers
    • user-agent: 客户端标识，多数浏览器这个字段比较复杂，差别十分微妙。

  • 响应头：

    • content-type/content-encoding/content-language
    • cache-control
    • Max-age：客户端的本地资源应该缓存多少秒，开启了 Cache-Control 后有效
    • last-modified
    • etag
    • connection：keep-Alive/close
    • Keep-Alive: timeout=50,max=100。保持连接不断时需要的一些信息。
    • set-cookie：设置 cookie。
    • Acccess-Control-Allow-origin
    • Server：服务器的一些相关信息

• 请求 / 响应实体：

  • 请求实体：参数的序列化形式（a=1&b=2），或 表单对象（Form Date 对象）
  • 响应实体：服务端需要传给客户端的内容

• http 请求方法？

  • get（获取数据）
  • post (传输数据)
  • put (传输文件，不安全)
  • delete ()
  • head (获取报文首部，没有实体，用于确认 UTI 的有效性及资源的更新日期)
  • patch ()
  • options (询问支持的方法，非简单缓存的时候会用到)
  • connect (建立管道化)

• get 和 post 的区别？

  • get 传输数据是在 url 中传输的，所以大小有限制；
  • get 可以用于分享；
  • get 会主动缓存；

• 状态码？

  • 1**：状态；101 用于切换协议；
  • 2**：成功；200— 请求成功；204– 服务器成功处理了请求，但不需要返回任何实体内容；
  • 3**：301— 永久重定向，302— 临时重定向，304— 缓存成功；
  • 4**：请求错误；400— 请求报文错误；401— 需认证 / 认证失败；403—- 无访问资源权限；404—- 无请求的资源；
  • 5**：服务器错误；500– 服务端错误；503 — 服务不可用

• URL 后面的 #是什么？

  • 代表网页中的一个位置；
  • http 请求中不包含；
  • 改变 #后面的内容，浏览器滚动到相应的位置，不会重新加载页面；
  • 改变 #后面的内容，会改变浏览器的访问历史；
  • ？和 & 是传参的分隔符；
• 请求体的格式：content-type 设置为，application/json；application/x-www-form-urlencoded；multipart/form-data；text/xml；
  xhr.setRequestHeader(‘content-type’, ‘application/x-www-form-urlencoded’);

6. 长连接、短连接、长轮询、短轮询

• 长连接与短连接

  1. HTTP 协议是基于请求 / 响应模式的，因此只要服务端给了响应，本次 HTTP 连接就结束了。
  2. TCP 是一种双向的通道，可以保持一段时间不关闭，因此 TCP 连接才有真正的长连接何短连接。
  3. HTTP 协议是应用层协议，TCP 是传输层协议，只有负责传输的这一层才需要建立连接。
  4. HTTP 请求和 HTTP 响应都是通过 TCP 连接这个通道来回传输的。
  5. 短连接：
     连接只保持在数据传输过程中，请求发起，连接建立，数据返回。连接断开。
     适用于一些实时数据请求，配合轮询进行新旧数据的更替。（用的很少）
  6. 长连接：
     连接发起后，在请求关闭连接前客户端与服务器保持连接，实质是保持这个通信管道，之后进行复用，避免了频繁的连接请求，提高了效率。
  7. 如何设置长连接：
     在 http 请求头中设置 Connection: keep-alive;
     只有在 HTTP1.1 中才有长连接，而且默认长连接，HTTP1.0 中是短连接。
     Connection 还可以设置为 close。
  8. 长连接的好处：
     多个 HTTP 请求可以复用同一个 TCP 连接，节省了很多 TCP 连接建立和断开的消耗。（前一个请求返回后才会再发请求，HTTP2 类似管道的，没有收到返回就再次发送请求。）
  9. 长连接并不是永久连接的，如果再超时时间后，这个连接没有 HTTP 请求发出，那这个长连接就会被断掉。

• 长轮询与短轮询

  1. 轮询：在一个循环内不断发起请求来得到数据的机制。只要有请求的地方，都可以实现轮询。
  2. 短轮询：一个循环内，不断发起请求，每一次请求都乐基返回结果，根据新旧数据对比决定是否使用这个结果；
  3. 长轮询：在请求的过程中，如果服务端数据没有更新，则将这个连接挂起，直到服务器推送新的数据，然后再进入循环周期。长轮询请求挂起会导致资源浪费。
  4. 不管是长轮询还是短轮询，都不太适用于访问量过大的情况，因为每个服务器所能承载的 TCP 连接数是有上限的，这种轮询很容易把连接数顶满。

• 长短轮询和长短连接的区别：

  1. 决定的方式：
     长短连接，在 HTTP 请求头和响应头中设置，需要两边都设置哦；
     长短轮询，根据服务端的处理方式决定，与客户端没有关系；
  2. 实现的方式：
     长短连接，通过协议来规定和实现的；
     长短轮询，是服务器通过编程的方式手动挂起请求来实现的。

7. HTTP 版本：

• HTTP 1.0：

  • 短连接，发送一次数据后就断开 TCP 连接

• HTTP 1.1:

  • 默认是长连接，可以用 connection:keep-alive/close 来设置
  • 服务器和浏览器都要支持
  • 长连接，在请求关闭连接前客户端与服务器保持连接。
  • 如果长连接在超时时间后，这个 http 没有发送请求，那么此时这个长连接就会被断开。
  • Connection:keep-alive Keep-Alive: timeout=60，表示空闲时间为 60s。
  • Connection:keep-alive，不设置超时时间，就是永久有效。
  • TCP 连接默认闲置时间是 2 小时，一般设置为 30 分钟足够了。
  • http 连接保持时间是由服务端的消息头 connection 字段和 keep-alive 字段定的。

• HTTP 2.0:

  • 首部压缩。对消息头采用 HPACK 进行压缩传输，节省消息头占用的网络流量（HTTP1.1 带有大量的冗余头信息）
  • 二进制传输。采用二进制格式传输数据（HTTP1.1 是问二八年格式），在协议解析和优化扩展上带来更多优势和可能。
  • 多路复用。采用多路复用的单一长连接
  • 服务端推送。主动把客户端可能需要的推送给客户端。
  • 请求优先级。如果流被赋予了优先级，它就会基于这个优先级来处理，由服务器决定需要多少资源来处理该请求。
  • HTTP2，在底层传输机制上完全重构，采用 Frame，包含 frame-header 和 frame-data，每个 frame header 都有一个 stream-ID，每次请求 / 响应使用不同的 stream-ID，从而实现多路复用。
  • server-push，当服务端主动推送某个资源的时候，便会发送一个 frame-type 为 push—promise 的 frame，里面有 push 需新建的 stream-id，客户端接收到后发现是 push—promise，就准备好接收。

• HTTP 3.0：

  • https://www.jianshu.com/p/bb3…
  • QUIC（quick udp internet connections），基于 UDP 的传输层协议，提供像 TCP 一样的可靠性。
  • HHTP/2，虽然，不同流之间相互独立，但是数据还是一帧一帧的发送和接受的，一旦一个包丢失，后面的就会阻塞。QUIC，基于 UDP，让不同的流之间真正实现相互独立传输，互不干扰。
  • 切换网络时的连接保持。基于 TCP 的协议，切换网络后，IP 会变，因此连接会断开。基于 UDP，则可以内建与 TCP 不同的连接标识方法，从而在网络完成切换后，恢复之前与服务器的连接。
  • 目前 TCP 与 SSL/TLS(1.0,1.1,1.2)每次建连需要 TCP 三次握手 + 安全握手，需要 4~5 个 RRT。QUIC 实现零 RTT 建立连接。

  • 连接：

  • • client -> server: 发送一个 hello package
    • server -> client: 安全证书和对应客户端的唯一的 SYN cookie
    • client：解码，保存 SYN cookie【此时使用了一个 RRT】
    • client 如果解码失败。lient -> server: 要求重新发送安全证书，并将 SYN cookie 附加到这个请求包中，以便让服务器验证请求的正确性和有效性。【此时，建立连接需要 2 个 RTT。】
    • client -> server: 加密一个 Hello Packet 并发送。不用等恢复，继续发送数据包。
    • server：接到 Hello 包之后，用自己现有的秘钥解码，如果解码不成功，将把客户端的连接当做第一次连接，重发安全证书等信息。同上介绍的一样。此时，通常会有 2 个 RTT，极端情况下是 3 个 RTT。
    • 服务器成功解码之后，验证了客户端的安全性之后，就可以继续处理接下来收到的数据包。此时延时是 0 个 RTT。
  • 为了预防丢包等问题，Hello Packet 可能会隔一段时间被重传多次，保证减少丢包造成的延迟。比如，先发一个 Hello 包，之后发送数据包，再发送一个 Hello 包。

  • 优雅的丢包处理：

  • • FEC 前向纠错：

      • 数据包 = 本身数据 + 其他数据包部分数据。
      • 在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。
      • 具体实现类似于 RAID5，将 N 个包的校验和（异或）建立一个单独的数据包发送，这样如果在这 N 个包中丢了一个包可以直接恢复出来。除此之外还可以用来校验包的正确性。
  • 关键包发送多次：
  • 快速重启会话：支持网络切换。

- 长距离传输

8. HTTPS：

• 特点：

  • 请求前，会建立 ssl 连接，确保接下来的通信都是加密的，无法被轻易截取。
  • 需要后端的支持（后端需要申请证书等）
  • 开销比 http 更大

• 加密算法：

  • 对称加密：

    • 特点：加密、解密用的同一把钥匙。
    • 优点：速度快、适合大量数据
    • 缺点：需同步密钥，安全性差

  • 非对称加密：

    • 特点：公钥 + 私钥。
    • 优点：安全
    • 缺点：速度快、适合少量数据
  • hash 加密：将任意长度的二进制值映射为固定长度的二进制值（成为哈希值）。常用于检验数据的完整性，有没有被篡改（md5）

• 过程：

  • client -> server: 客户端支持的加密算法和 hash 算法。
  • server – > client: 从中挑选出 服务端支持的加密算法和 hash 算法，以及 证书。
  • client: 验证证书的有效性，并获得公钥。生成一个随机数 R
  • client -> server: 公钥加密 R，R 加密握手消息，握手消息的 hash 值。
  • server：私钥解密得到 R，用 R 解密得到握手消息，求握手消息的 hash 值，对比两个 hash 值是否一致。
  • server – > client: R 加密握手消息，握手消息的 hash 值。
  • client：解密握手消息，求 hash 值，然后对比，一致则后续的消息都用这个 R 加密。

9. HTTP 缓存机制：

• 强制缓存：

  • 浏览器判定 本地缓存可用，就直接使用，不会发起 http 请求。
  • 只考虑是否过期，但是没有考虑服务端数据是否更新，导致可能得到的不是最新数据。

• 协商缓存：

  • 向服务端发送 http 请求确定缓存是否有效，有效返回 304，则使用缓存，不可用，则返回 200 和数据，将新数据缓存并使用新数据。
  • 强制缓存不可用时，才用？

• 使用缓存的策略：

  • 频繁变动的资源：cache-control：no-cache；etag/last-modified
  • 不常变动的资源：cache-control：max-age = 很大的数，在文件名中加入动态字符（hash/ 版本号），更新时更新动态字符，导致之前的强制缓存失效（只是不用了）

• HTTP 1.0：

  • 强制缓存：

    • expires：相对时间，对应服务端的时间。
    • 例子：Expires：Fri, 30 Oct 1998 14:19:41

  • 协商缓存：

    • if-modified-sice：请求头。
    • last-modified：响应头。在服务器端设置的 文件最后修改事件。

• HTTP 1.1：

  • 强制缓存：

    • cache-control：

      • public：响应可被客户端和代理服务器缓存。
      • private：响应只可被客户端缓存。
      • max-age = 30：30s 后缓存过期，需重新发送请求。
      • s-maxage = 30：30s 后缓存过期，在代理服务器中覆盖 max-age。
      • no-store：不缓存
      • no-cache：不使用 cache-control 来控制缓存。
      • max-stale = 30：过期 30s 内仍可用。
      • min-fresh =30：30s 内获取最新响应。
    • max-age 中保存的是绝对时间，时间由浏览器计算。
    • 比 http1.0 的进步：时间是对于浏览器而言的，如果浏览器和服务器时间不一致也没用关系。

  • 协商缓存：

    • if-none-match：请求头。
    • etag：响应头。是文件的特殊标识（一般都是 hash 生成的）

    • 比 http1.0 的进步：

      • last-modified：最小单位是 s；负载均衡的服务器，各个服务器生成的时间可能不一致；文件内容不变但是修改日期变了会导致缓存失效。
      • etag：精度高；性能差一点（需要计算 hash 值）；优先级更高。

• 用户的不同操作使用的缓存：

  • 打开网页：查找硬盘中是否有。
  • 普通刷新（F5）：tab 未关闭，内存可用，没有采取硬盘找。
  • 强制刷新（ctrl+F5）：不适用缓存。

10. CDN：

• CDN = 镜像 + 缓存 + 整体负载均衡
• 作用：将网站的内容发布到离用户更近的网络‘边缘’，提高响应速度。
• 缓存内容：静态资源（css，js，图片，静态网页。用户从主站服务器请求到动态内容，再从 CDN 上下载静态数据）

• 工作流程：

  • 浏览器向本地的 DNS 服务器请求对该域名的解析，DNS 系统会最终将解析权交给 CNAME 指向的 CDN 专用 DNS 服务器。
  • CDN 的 DNS 服务器将 CDN 的全局负载均衡设备 IP 地址返回用户。
  • 用户向 CDN 的全局负载设备发起内容 URL 访问请求。
  • CDN 的全局负载设备 根据用户的 IP 地址，以及用户请求的内推 URL, 选择一台用户所属区域的区域负载均衡设备，告诉用户向这台设备发起请求。
  • 区域负载均衡设备会为用户选择一台合适的缓存服务器提供服务，选择的依据包括：根据用户 IP 地址，判断哪一台服务器距用户最近；根据用户所请求的 URL 中携带的内容名称，判断哪一台服务器上有用户所需内容；查询各个服务器当前的负载情况，判断哪一台服务器尚有服务能力。基于以上这些条件的综合分析之后，区域负载均衡设备会向全局负载均衡设备返回一台缓存服务器的 IP 地址。
  • 用户向缓存服务器发起请求，缓存服务器响应用户请求，将用户所需内容传送到用户终端。如果这个节点中请求的文件不存在，就会再回到源站去获取这个文件，然后再返回给用户。

• 特点：

  • “分布式存储”：将中心平台的内容分发到各地的边缘服务器，使用户能够就近获取所需内容，降低网络用时，提高用户访问响应速度和命中率。利用了索引、缓存等技术。
  • “负载均衡”：对所有发送的请求进行访问调度，确定提供给用户的最终实际访问地址。
  • “内容管理”：负责对存储内容的监管、数据分析等。

• 为什么使用：

  • 服务器的带宽有限，如果超过限制，网页半天都反应不过来。而 CDN 可以通过不同的域名来加载文件，从而使下载文件的并发连接数大大增加。
  • jquery 一类的库文件，如果访问你网站的用户的浏览器之前在访问别的网站时通过和你相同的 CDN 已经加载了 jquery，由于该文件已经被缓存，就不用重新下载了。
  • CDN，具有更好的可用性，更低的网络延迟和丢包率。
  • CDN 能提供本地的数据中心，那些远离网站主服务器的用户也能就近很快下载文件。
  • 很多商业付费的 CDN 能提供使用报告，这可以作为你自己网站分析报告的补充。
  • CDN 能够分配负载，节省带宽，提高网站的性能，降低网站托管的成本，通常是免费的。
  • 大型 Web 应用对速度的追求并没有止步于仅仅利用浏览器缓存，因为浏览器缓存始终只是为了提升二次访问的速度，对于首次访问的加速，我们需要从网络层面进行优化，最常见的手段就是 CDN

• CDN 的缺点：

  • 在开发阶段如果处在断网环境下，CDN 文件是无法加载的。
  • 不够灵活。比如你只使用 jquery 库的一小部分，如果使用 CDN 上提供的文件就没办法进行拆分，还是得下载原来的大小，反而没有自己拆分后加载速度来得快。
  • 尽管一些流行的 CDN 文件事先缓存过的几率较大，但并不是一定的，一些移动设备的缓存可能很小而且效率很低，CDN 的优势就不明显了，特别是当你可以在本地服务器上存放比 CDN 文件更小的文件时。
  • 由于地理、法律、政策和商业上的阻隔，你所在的地区可能屏蔽了一些流行的免费 CDN 服务的域名或者 IP 地址。
  • CDN 会有出故障的时候，这时候要有备用方案，也就是你的本地文件，这种处于稳定考虑的冗余会增大开发工作量和复杂度。
  • 如果安全性对你的网站很重要，就不要使用公共的 CDN，因为当你远程从 CDN 请求文件时，你的访问来源信息也被发送过去，一些远程的 js 文件可能被修改用来搜集你的用户或者系统信息，而当你使用 https 协议时，能选择的 CDN 就更加有限。

• 如何使用：

  • 1. 将静态资源部署到不同网络线路的服务器中，以加速对应网络中 CDN 节点无缓存时溯源的速度。
  • 2. 加载静态资源时使用与页面不同的域名，一方面是便于接入为 CDN 而设置的智能 DNS 解析服务，另一方面因为静态资源和主页面不同域，这样加载资源的 HTTP 请求就不会带上主页面中的 Cookie 等数据，较少了数据传输量，又进一步加快网络访问。

11. 跨域：

• https://segmentfault.com/a/11…
• https://segmentfault.com/n/13…
• https://segmentfault.com/n/13…

12. 安全；

• https://segmentfault.com/n/13…
• https://segmentfault.com/n/13…

11. 参考：

• https://www.cnblogs.com/kabi/…
• https://www.jianshu.com/p/00d…
• https://www.cnblogs.com/ediso…
• https://blog.csdn.net/jtracyd…
• DNS 解析：https://www.jianshu.com/p/827…
• HTTP 劫持：https://juejin.im/post/59ba14…
• CDN https://www.cnblogs.com/Ron-Z…
• CDN https://blog.csdn.net/weixin_…
• CDN http://www.cnblogs.com/minigr…
• https://juejin.im/post/59ba14…