HTTP 相关

时间 2021-02-17

标签 css html jquery web 算法编程 json segmentfault 后端跨域栏目 HTTP/TCP 繁體版

原文原文链接

1. DNS 查询获得IP

为何须要IP: TCP/IP 经过 IP 地址来肯定通讯对象的。
域名和IP地址并用的理由：css
- IP 地址占内存小。IP 地址长度为 32 bit（4 字节），域名须要几十甚至255字节
- IP 地址难记。
- 人使用名称，路由器使用IP地址。
DNS 解析获得的IP，只是实体主机的IP，并非要访问的web应用服务器的IP地址（好比虚拟主机，实体主机会根据域名把链接转发给对应的虚拟主机）
TCP/IP 的结构：html
- TCP/IP ，由一些小的子网，经过路由器链接起来组成的大的网络。
- 网络中的全部设备都会被分配一个地址，这个地址就是IP地址，经过IP地址，能够判断出消息应该发送到哪一个服务器。
- 发送者发出的消息 -> (通过)子网中的集线器 -> （转发到）最近的路由器 -> 根据消息的目的地判断下一个路由器的位置 -> 将消息发送到下一个路由器（不断重复，直到目的地）
实际的IP地址：jquery
- 是一串 32 比特的数字，按照 8 比特(1 字节)为一组分红 4 组，分别用十进制表示，而后再用圆点隔开。
- IP 地址的规则中,网络号和主机号连起来总共 32 比特,但这两部分的具体结构是不固定的。
- 因此须要用到子网掩码，子网掩码的格式是一串与IP地址长度相同的32比特数字,左边一半都是1，右边一半都是0。子网掩码为1的部分表示网络号，子网掩码为0的部分表示主机号。全 0：表示整个子网。全 1：表示向子网上全部设备发送包，即“广播。
查询顺序：web
- 浏览器缓存
- 本地缓存
- 本地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 劫持：json
- DNS 服务器收到攻击，返回假的 IP 地址或者不作任何处理使请求失效。最终的效果就是，特定的网络不能访问或者访问假的网址。
- 解决：（DNS 的劫持是经过攻击运营商的解析服务器来达到目的的）segmentfault
  - 使用本身的解析服务器或者
  - 在本身的App中将解析好的域名以IP的形式发出去
内容劫持：后端
- 背景：跨域
  - 运营商为了加快用户的访问速度，减小本身的流量损耗作的一个缓存机制。
  - 用户请求数据，若是缓存池中有，直接返回。
  - 若是没有，则向服务器发出请求，将返回的数据拦截，先存入缓存池，而后再返回给用户。
- 产生：恶意篡改服务器的缓存内容
- 解决：这种并很少，目前没有好的解决方案

3. TCP/IP请求

三次握手（创建链接）
- SYN
- ACK ,SYN
- ACK
四次挥手（断开链接）
- FIN, ACK
- ACK
- FIN,ACK
- ACK
TCP 慢启动：
- TCP慢启动
  - TCP 三次握手后，如何一开始就发送大量的数据报，很容易致使网络中路由缓存空间耗尽，从而发生拥塞，因此根据出事的窗口大小逐步增长发生的数据量，窗口初始化为1个最大报文段大小，每当有一个报文段被确认，窗口呈指数增加。
- 拥塞避免
  - 窗口（cwnd）不能一直增长，增长到TCP的慢启动门限（ssthresh），慢启动阶段结束，开始避免拥塞阶段，窗口大小呈线性增加。
  - 如何判断拥塞？发送方没有在时间间隔内收到接收方的ACK，就认为网络拥塞。
  - 发生拥塞后：把启动门限将为目前窗口的通常；把目前窗口重置为1，从新进入慢启动过程。
- 快速重传
  - 接收方成功的接受了发送方发送来的M一、M2而且分别给发送了ACK，如今接收方没有收到M3，而接收到了M4，显然接收方不能确认M4，由于M4是失序的报文段。若是根据可靠性传输原理接收方什么都不作，可是按照快速重传算法，在收到M四、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 的数据是有序的，假设你发送了数据一、二、3，则只要发送端和接收端保持链接时，接收端收到的数据始终都是一、二、3。
  - 而 UDP 协议则要奔放的多，不管 server 端不管缓冲池的大小有多大，接收 client 端发来的消息老是一个一个的接收。而且因为 UDP 自己的不可靠性以及无序性，若是 client 发送了一、二、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。

适用场景：

- 长距离传输

收集网络（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. 参考：

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...