HTTP3
HTTP2协议虽然大幅提升了HTTP/1.1的性能，也解决了一部分的问题，但基于TCP实现的HTTP2仍有遗留的问题。
- 在HTTP2中虽然解决了http层面的队头阻塞，但是在tcp层面仍然存在堵头堵塞，使得多路复用的能力大大的折扣。
假如在http2中存在4个帧（0，1，2，3），分别由4个tcp数据包承载。假设因为网络波动等原因，第1个数据包丢失了，因为存在tcp的丢包重传机制（ARQ），tcp并不会继续发送后面2，3号数据包。tcp会告诉服务器数据包1丢失，需要重新发送，等数据包1成功被客户端接收，才会继续发送后面的数据包，即使丢失的包与后面要发送的包毫无关系。仍然会阻塞后面的包。
- TCP与TLS叠加了握手时延，要启动一个HTTPS连接要启动3个RTT “ 来回通信延迟（Round-trip delay time）”，然后才能发送http报文。
上述存在的问题在已有协议的基础上很难做出改变，因此出现了基于UDP的QUIC “ 快速UDP互联网连接 （Quick UDP Internet Connection）最初由Google设计”。
- QUIC
QUIC实现了自己的流量控制机制。
在连接创建期间大大减少开销。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。实现初次1RTT后续0RTT
QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务。 这在提高易出错链路的性能方面非常有用，因为在大多数情况下TCP协议通知数据包丢失或损坏之前可能会收到大量的正常数据，但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC在修复单个流时可以自由处理其他数据，也就是说即使一个请求发生了错误也不会影响到其他的请求。
CDN
CDN（内容分发网络）的总承载量可以比单一骨干最大的带宽还要大。这使得内容分发网络可以承载的用户数量比起传统单一服务器多。也就是说，若把有100Gbps处理能力的服务器放在只有10Gbps带宽的数据中心，则亦只能发挥出10Gbps的承载量。但如果放到十个有10Gbps的地点，整个系统的承载量就可以到10*10Gbps。
同时，将服务器放到不同地点，可以减少互连的流量，进而降低带宽成本。
对于TCP传输而言，TCP的速度（throughput）会受到延迟时间（latency）与数据包漏失率（packet loss）影响。为了改善这些负面因素，内容分发网络通常会指派较近、较顺畅的服务器节点将资料传输给用户。虽然距离并不是绝对因素，但这么做可以尽可能提高性能，用户将会觉得比较顺畅。这使得一些比较高带宽的应用（传输高清视频）更容易推动。
内容分发网络另外一个好处在于有异地备援。当某个服务器故障时，系统将会调用其他邻近地区的服务器服务，进而提供接近100%的可靠度。
任播（anycast）是一种网络寻址和路由的策略，使得资料可以根据路由拓扑来决定送到“最近”或“最好”的目的地。
任播是与单播（unicast）、广播（broadcast）和多播（multicast）不同的方式。
在单播中，在网络地址和网络节点之间存在一一对应的关系。 在广播和多播中，在网络地址和网络节点之间存在一对多的关系：每一个发送地址对应一群接收可以复制信息的节点。 在任播中，在网络地址和网络节点之间存在一对多的关系：每一个地址对应一群接收节点，但在任何给定时间，只有其中之一可以接收到发送端来的信息。 在互联网中，通常使用边界网关协议（BGP）来实现任播。
-
大型网站本身的数据一般是非常庞大的，如果在全国的CDN服务都维护一份拷贝那成本是非常大的，因此通过一些策略来维护部分内容。
- 拉策略：主要以用户决定维护的拷贝内容，根据用户的请求来拷贝。并定期清理一些老旧的
- 推策略：以网站决定拷贝的内容，例如电影网站，会根据当前电影的热度，点击量，等决定拷贝的内容，清理热度不高，播放量较小的内容。
