HTTP 相关

2024年4月10日 118次阅读 来源: 默_hjh

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个包中丢了一个包可以直接恢复出来。除此之外还可以用来校验包的正确性。
        • 关键包发送多次：
        • 快速重启会话：支持网络切换。

  • 适用场景：

    - 长距离传输
    • 收集网络（wifi切4G）
    • 强求的页面资源数较多，兵法的连接数多
    • 要求加密传输

    • 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. 跨域：

    12. 安全；

    11. 参考：

        原文作者：默_hjh
        原文地址: https://segmentfault.com/a/1190000019936525
        本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
    点赞