这是我在此次前端训练营学习中的第一篇笔记。
这篇笔记主要是将对于我这种初学者来说较为晦涩的第一节课第四小节“Web网络应用”中的老师讲解的思路进行捋清，以及对一些概念进行额外的资料搜集和整理，方便我对老师的讲说进行理解和与现实的学术学习上进行串联。
客户端与服务器之间的对话，需要一种协议进行相互约定，就如同两个人的对话之间需要一起使用一种沟通方式，是用手语还是张口说话。
在Web的发展中，HTTP协议是一种已经被普遍使用的协议。
红色是请求，蓝色是响应。
请求第一行亦称起始行，由斜杠划分了三个要素，分别是请求的方法、资源路径、HTTP版本。 跟在后面的是头部，左边是头部的名称，右边是头部的值。头部名称不区分大小写。 响应第一行亦称状态行，包含了三个要素，分别是：
- HTTP协议版本号，如HTTP/1.1；
- 状态码，用于表示请求处理的结果，如200表示请求成功，404表示请求的资源未找到等；
- 状态码对应的短语，用于描述状态码，如200对应的短语是OK，404对应的短语是Not Found。其中状态码的描述是可以自定义的。
HTTP协议的报文可以以明文显示出来的，对人友好但是对于机器相对不友好，并由此引发了问题。HTTP协议使用了典型的请求-响应模型，即当客户端发起第一个请求后，需要服务端先发回第一个请求的响应，客户端才可以发起第二个请求，则网络利用率不高。
HTTP的报文可以明文显示，因为HTTP协议是基于文本的，而且报文中的内容都是明文，不进行加密处理。所以在网络传输过程中，HTTP报文可以被中间人窃取并查看报文中的明文内容。为了保护数据的安全性，在需要传输敏感信息时，应使用HTTPS协议来进行加密传输。
同时导致了另一个问题，无法在一条链接上完成多路复用，在一个完整请求中间插入另一个请求的内容，会导致HTTP无法分辨这部分内容是来自哪个请求的，请求的头部和响应的头部都有很多重复。然后造成队头堵塞。
队头堵塞：
HTTP协议中的队头堵塞（Head-of-line blocking）指的是，当客户端发送多个请求到服务器，但是这些请求需要串行处理时，如果其中一个请求耗时很长，那么后面的请求就会被阻塞，即使这些请求可以并行处理。
这是因为HTTP/1.1中，对于同一个TCP连接，服务器必须按照请求的先后顺序依次处理请求，并将响应返回给客户端。如果前面的请求处理时间过长，那么后面的请求就必须等待，而这些请求的处理时间可能很短，但是由于等待时间过长，整个响应的时间也会变得很长，导致性能下降。
为了解决队头堵塞的问题，HTTP/2引入了多路复用（Multiplexing）机制，允许客户端发送多个请求到服务器，并将响应返回给客户端的顺序不必与请求的顺序一致，从而提高性能。
HTTP进行了升级，而在HTTP/2中，使用了帧技术。
在HTTP/2协议中，帧（frame）是最小的通信单位，承载了传输的数据和控制信息。HTTP/2协议将一个完整的HTTP消息（请求或响应）拆分为多个帧，通过二进制格式进行传输。
每个帧包含一个帧头和一个可选的帧体。帧头包含帧类型、标志位、流标识符等控制信息，帧体则是传输的数据内容。
通过将HTTP消息拆分成多个帧进行传输，HTTP/2协议实现了多路复用的功能，允许在同一TCP连接上同时传输多个HTTP请求和响应。这样可以减少TCP连接数量，提高了HTTP请求响应的效率。
当使用 HTTP/2 协议时，客户端和服务器之间的通信不再是基于原始的请求和响应消息，而是通过分解成更小的、自包含的帧来进行。帧是 HTTP/2 通信的基本单位，每个帧包含一个特定的帧类型，用于执行不同的操作。HTTP/2 中的帧分为两种类型：控制帧和数据帧。
控制帧用于管理连接、设置参数和执行其他控制任务，如流控制、优先级和帧分解。控制帧包括以下类型：
- SETTINGS：在客户端和服务器之间设置配置参数
- WINDOW_UPDATE：对流控制窗口进行更新
- PING：进行客户端和服务器之间的往返延迟测量
- GOAWAY：指示服务器停止处理当前的流，并关闭连接
- HEADERS：用于在请求和响应之间传输元数据
- PUSH_PROMISE：用于服务器向客户端推送资源
数据帧用于传输实际的请求和响应消息，每个数据帧包含有效负载。数据帧可以分解为多个大小相等的帧片段，以便更好地控制流量和增强性能。
总之，HTTP/2 帧提供了一种更有效的机制来管理连接、控制流量、支持多路复用和提高性能。
帧带来的额外好处有以下几点：
- 调整响应传输的优先级
- 头部压缩
- Server Push
但是HTTP/2仍然存在着队头堵塞，主要是发生在TCP上。
在 HTTP/2 中，一个 TCP 连接可以被视为多个独立的流（Stream），每个流可以承载多个帧（Frame），每个帧又包含了 HTTP 报文的一部分。当一个流上的某个帧正在传输时，如果这个帧占用了 TCP 流量控制窗口中的全部可用空间，那么这个流上后续的数据帧就必须等待窗口空间释放之后才能被传输，否则就会发生队头堵塞。
举个例子，假设在一个 HTTP/2 连接上有两个流，流 A 和流 B，它们共享一个 TCP 连接。如果流 A 上正在传输的某个帧占用了 TCP 窗口中的全部可用空间，那么流 B 上后续的数据帧就必须等待流 A 的帧传输完毕并释放了 TCP 窗口空间之后才能被传输，否则就会被阻塞。这种情况就叫做 HTTP/2 中的队头堵塞。队头堵塞会导致客户端和服务器的响应时间变长，从而降低了 HTTP/2 的性能表现。
两个不认识的人初次见面总是需要引起互相之间的话题，哪怕是一方对另一方有需求，也得表明自己是友非敌，而HTTP/2使用了3RTT技术。
HTTP/2中的3RTT启动是指在建立TLS连接后，客户端和服务器之间必须进行最多3次往返传输（RTT）的通信，才能开始发送实际的HTTP请求和响应。在这个过程中，客户端和服务器需要协商TLS连接的参数和HTTP/2的设置，包括使用的加密套件、压缩方法、流控参数等。这个过程可能会导致一定的延迟，但是由于HTTP/2的新特性（例如多路复用），可以提高后续请求的性能。
使用3RTT启动的好处是可以更快速地建立起一个连接，减少了等待连接建立的时间。同时，由于3RTT启动会将更多的数据传输到客户端，因此可以更快地呈现网页内容，提高了用户的体验。此外，使用3RTT启动也可以提高网络的利用率，让更多的数据可以在更短的时间内传输完成。
这种方式会带来一些问题，主要是由于3RTT启动需要客户端和服务器之间进行多次往返通信，因此会增加延迟。另外，如果其中一条链路出现问题，整个连接可能需要重新启动，进一步增加延迟。此外，由于需要等待多次往返通信才能建立连接，因此这种方式可能会导致客户端和服务器之间的并发连接数较低，从而限制了HTTP/2的性能优势。
HTTP/2的3RTT启动虽然会带来一些问题，但它的好处也是显而易见的。通过在客户端和服务器之间建立多个连接并同时发送多个请求，可以避免队头堵塞等问题，并提高页面加载速度和性能。同时，HTTP/2还使用了其他的优化技术，如头部压缩和二进制分帧等，进一步提高了性能和效率。所以3RTT的优劣势并不矛盾。
在HTTP/3中使用了QUIC技术：
- Quick UDP Internet Connection
- 现存网络设备对TCP和UDP支持已经僵化
- UDP不靠谱但是QUIC靠谱
- QUIC可以为除HTTP协议以外的应用层协议提供支持
HTTP/3是基于QUIC（Quick UDP Internet Connections）协议的，QUIC是一种由Google设计的基于UDP的传输协议，旨在解决TCP的一些问题，如队头堵塞、慢启动等，以提高Web性能。
QUIC的优势在于：
- 减少延迟：QUIC使用UDP协议，因此可以减少建立连接的时间，进而减少了延迟。
- 解决队头堵塞问题：QUIC采用了多路复用技术，可以在同一个连接上同时传输多个流，从而避免了队头堵塞问题。
- 安全性：QUIC通过TLS来保证数据的安全性，因此不需要像TCP一样在TLS之上再次封装安全层。
- 故障恢复能力强：QUIC使用的连接标识符不会因为IP地址变化而改变，因此可以实现比TCP更快的故障恢复。
然而，QUIC也存在一些缺点，如：
- 处理连接中断时，无法准确确定导致中断的具体原因。
- 部分网络不支持UDP协议，因此在这些网络环境中，QUIC无法使用。
- QUIC是一个新的协议，相比于已经广泛应用的TCP和HTTP/1.1，QUIC的普及率还相对较低，需要更多的支持和推广。
在QUIC中，使用了1RTT模式
在 QUIC 协议中，1RTT 指的是第一次往返时间（Round Trip Time），即建立连接所需的时间。在 TCP + TLS 中，建立连接需要 3 个 RTT，而在 QUIC 中，由于其设计上的优势，可以在 1 个 RTT 内建立连接。
具体来说，1RTT 握手的流程如下：
- 客户端发送连接请求（Initial Packet），该数据包包含了必要的加密信息，如客户端生成的随机数以及 TLS 版本号和加密套件信息。
- 服务端收到请求后，返回握手确认包（Handshake Packet），该数据包包含了必要的加密信息，如服务端生成的随机数以及服务端的证书和加密套件信息。
- 客户端收到服务端的握手确认包后，发送最终的握手确认包（Handshake Packet），该数据包包含了客户端的加密信息和所需的 HTTP 首部信息。
- 服务端收到客户端的握手确认包后，发送最后的确认信息（Final Packet），完成建立连接的过程。
由于 QUIC 协议的设计，可以在一个往返时间内完成建立连接的过程，因此相较于 TCP + TLS 的方式，QUIC 可以更快速地建立安全连接，从而提升用户体验。同时，QUIC 还具有抗丢包、多路复用、0-RTT 快速重连等优势，可以进一步提升网络传输效率和可靠性。
必须知道的是，协议的进步也无法突破物理极限，物理上的距离带来的延迟是不可避免的，同时数据传输的流量也是不可避免的，服务器本身的能力也是有限的。
于是如何布置服务器成为了一个需求问题，所以CDN来了。
CDN（Content Delivery Network，内容分发网络）是一种通过在多个地理位置部署节点服务器来缓存、加速和分发网络内容的技术。CDN旨在提高用户访问网站或应用程序时的响应速度和性能，同时减轻源服务器的负载。
在CDN中，当用户请求一个资源时，CDN系统会根据用户位置和内容的可用性，自动选择离用户最近的节点服务器来响应请求。这些节点服务器通常是由CDN服务提供商管理和运营的，它们位于全球各地的数据中心或网络交换中心，并且与原始服务器进行同步以获取最新内容。通过使用CDN，网站和应用程序的内容可以更快地传递给用户，同时降低原始服务器的负载和网络带宽消耗。
而CDN也会出现问题，即DNS劫持。
DNS是域名系统（Domain Name System）的缩写。它是互联网上一个分布式的命名系统，用于将域名和IP地址相互映射。通俗来讲，就是将人类可读的域名转换为机器可识别的IP地址，以便计算机在网络上寻找相应的服务器。DNS可以避免人们需要记住大量的IP地址，提高了互联网使用的便利性。 DNS劫持是指恶意攻击者通过修改DNS服务器中的记录或者利用中间人攻击等手段，将用户输入的域名解析到错误的IP地址，从而实现对用户的攻击。攻击者可以将用户重定向到恶意的网站，或者欺骗用户输入敏感信息等。DNS劫持也可以被用于网络审查和信息控制等用途。
CDN（内容分发网络）通过部署在全球各地的服务器节点，加速用户访问网站的速度。一般来说，当用户在浏览器中输入网站域名时，DNS（域名系统）服务器将解析域名并返回相应的IP地址，然后浏览器会向该IP地址发起请求以获取网站内容。CDN加速则是在这个过程中，当用户的请求到达CDN服务器后，CDN会根据用户的位置以及源服务器的位置，选择最优的CDN节点，从而加速响应时间。
DNS劫持则是攻击者篡改了用户的DNS解析结果，将用户的请求导向到错误的IP地址，从而达到攻击的目的。这会导致用户无法正确地访问网站，甚至被导向到钓鱼网站等危险网站。
因此，当DNS解析被劫持后，CDN加速可能会受到影响，用户可能无法正确地访问网站，或者访问速度变慢。一些CDN服务提供商为了防止DNS劫持，会在服务器上部署防止DNS劫持的相关措施。
除此之外，人们还采取了一些策略去弱化问题。
CDN 中的拉策略和推策略解决了 HTTP 协议中的网络延迟问题。
拉（Pull）策略是指 CDN 节点收到用户请求后，才从源站拉取数据，并将数据缓存到本地节点中。因为这种策略是按需拉取数据，所以缓存命中率相对较低。一般适用于流量较小、内容更新频率低的情况。
推（Push）策略是指源站主动将数据推送到 CDN 节点，再由 CDN 节点缓存。这种方式可以提前将热门内容缓存到 CDN 节点中，提高缓存命中率和用户访问速度。但缺点是需要预测用户请求，如果预测不准确会导致浪费 CDN 资源和带宽。
CDN中的拉取策略和推送策略主要是基于不同的需求和使用场景而设计的。综合来看，拉策略适合内容更新频率低、流量较小的场景，推策略适合热门内容更新频率高、流量较大的场景。同时，一些 CDN 服务提供商也会采用拉、推相结合的方式，以达到更好的缓存效果。
推送策略适用于需要频繁更新或动态生成的内容，例如在线视频、直播等实时内容。在推送策略下，CDN节点会主动向源站请求最新的数据，然后缓存到本地，当用户请求相应的内容时，CDN节点直接返回本地缓存的数据。
拉取策略则适用于内容相对固定、变化不频繁的网站或应用，例如静态资源、图片、文件等。在拉取策略下，CDN节点会等待用户请求相应的内容后再去源站拉取并缓存，这样可以避免浪费带宽和资源，提高缓存效率。
在传统的 HTTP 协议中，客户端向服务器请求数据，服务器返回响应，这样的方式需要往返两次，即所谓的 “2RTT”（Round Trip Time）。这种方式下，客户端需要等待服务器响应才能继续发送请求，延迟较高，尤其是在高延迟或带宽不足的情况下。
而 CDN 通过采用拉策略和推策略来解决这个问题。拉策略将数据存储在 CDN 边缘服务器上，当客户端请求数据时，边缘服务器直接返回数据，不需要等待回源服务器，可以大大减少响应时间，降低延迟。而推策略则是将数据预先推送到 CDN 边缘服务器上，当客户端需要数据时，边缘服务器直接返回数据，也可以减少响应时间，降低延迟。
因此，CDN 中的拉策略和推策略可以有效地提高 Web 应用的性能和用户体验，减少网络延迟。
后来又出现了更新的协议
WebSocket是一种协议，它提供了双向通信功能，允许服务器主动向客户端发送数据，而不需要客户端先发送请求。它建立在HTTP协议之上，使用HTTP协议的端口（通常是80或443），因此可以通过大多数防火墙。
WebSocket协议的特点包括：
- 双向通信：WebSocket支持服务器主动向客户端发送数据，而不需要客户端先发送请求。
- 实时性：由于WebSocket使用持久连接，因此可以实现实时通信。
- 更少的数据传输：由于WebSocket在连接建立后只需要发送少量的数据头，因此相比于传统的HTTP请求，WebSocket传输的数据量更小。
- 更快的响应速度：WebSocket建立连接的握手过程相对于传统的HTTP请求来说更快，从而可以提高响应速度。
WebSocket协议的实现需要客户端和服务器端都支持WebSocket协议。客户端可以使用浏览器内置的WebSocket API来实现，而服务器端可以使用各种编程语言和框架提供的WebSocket支持。
至此，第四小节结束，本次整理完毕。如果其中还有错漏的地方，请斧正。
