https四次握手
HTTPS 的握手过程实际上是一个三次握手的过程，与普通的 HTTP 的三次握手相似。下面是 HTTPS 的握手过程：
- 客户端向服务器发送 SSL/TLS 版本和加密算法的支持列表。
- 服务器从客户端支持的加密算法中选择一个，并发送自己的数字证书给客户端。该证书包含服务器的公钥、证书的有效期和其他相关信息。
- 客户端收到服务器的证书后，会验证证书的合法性。如果证书有效，客户端会生成一个用于后续通信的随机对称密钥，并使用服务器的公钥进行加密。然后，客户端将加密后的对称密钥发送给服务器。
- 服务器使用自己的私钥解密客户端发送的加密对称密钥，并获取到对称密钥。
此时，SSL/TLS 握手过程完成，后续的通信将使用对称密钥来进行加密和解密。
SSL加密过程：
强缓存协商缓存的header参数
| 标题 | http1.0 | http1.1 |
|---|---|---|
| 强缓存 | Expires | Catch-Control |
| 协商缓存 | Last-Modified/If-Modified-Since | Etag/If-None-Match |
Catch-Control设置值：
（1） max-age：用来设置资源（representations）可以被缓存多长时间，单位为秒；
（2） s-maxage：和max-age是一样的，不过它只针对代理服务器缓存而言；
（3）public：指示响应可被任何缓存区缓存；
（4）private：只能针对个人用户，而不能被代理服务器缓存；
（5）no-cache：强制客户端直接向服务器发送请求,也就是说每次请求都必须向服务器发送。服务器接收到 请求，然后判断资源是否变更，是则返回新内容，否则返回304，未变更。这个很容易让人产生误解，使人误 以为是响应不被缓存。实际上Cache-Control: no-cache是会被缓存的，只不过每次在向客户端（浏览器）提供响应数据时，缓存都要向服务器评估缓存响应的有效性。
（6）no-store：禁止一切缓存（这个才是响应不被缓存的意思）。
页面渲染过程
- 解析 HTML：浏览器从服务器获取到 HTML 文件后，会对 HTML 进行解析。解析过程包括标记化（tokenization）和构建 DOM（Document Object Model）树。标记化将 HTML 文档分解为一系列的标记（tokens），构建 DOM 树则是将这些标记组织成一个树状结构，表示文档的层次关系。
- 解析 CSS：在解析 HTML 的同时，浏览器还会解析 CSS 文件。解析过程包括词法分析和构建 CSSOM（CSS Object Model）。词法分析将 CSS 文件分解为一系列的词法单元，构建 CSSOM 则是将这些词法单元组织成一个树状结构，表示样式的层次关系。
- 构建渲染树：在解析 HTML 和 CSS 后，浏览器将根据 DOM 树和 CSSOM 来构建渲染树。渲染树是由可见的 DOM 元素和与之关联的样式信息组成的树状结构。渲染树中的每个节点都对应一个可见的页面元素。
- 布局（Layout）：在构建渲染树后，浏览器会计算每个节点在页面中的位置和大小，这个过程被称为布局。布局过程会考虑页面元素的盒模型、文档流和浮动等因素。
- 绘制（Painting）：在布局完成后，浏览器会根据渲染树和布局信息来绘制页面。绘制过程将页面元素转换为实际的像素，并应用样式、颜色和图像等视觉效果。
- 合成（Compositing）：在绘制完成后，浏览器会将不同的图层合成为最终的页面。图层是浏览器内部的优化手段，用于提高页面的渲染性能和交互体验。
遇到defer或者async时： 当遇到
- defer 属性：当浏览器遇到带有 defer 属性的 属性的脚本会按照它们在文档中的顺序依次执行。
应对策略：您可以将脚本标签放在 标签中，因为它们不会阻塞文档的解析过程。这样可以确保脚本在文档解析完成后执行，但仍然可以在文档加载期间进行其他资源的加载。
- async 属性：当浏览器遇到带有 async 属性的
应对策略：如果您的脚本不依赖于其他资源（如 DOM 元素或其他脚本），并且可以独立运行，则可以考虑使用 async 属性。这样可以提高脚本的加载和执行性能，但需要注意脚本之间的依赖关系。
需要注意的是，使用 defer 和 async 属性可以提高页面的性能，但需要根据具体情况来选择适合的属性。如果脚本之间有依赖关系，或者需要在文档解析过程中操作 DOM 元素，那么最好不要使用 async 属性，并将脚本放在文档的底部。
TCP四次挥手
`最后一次挥手 怎么知道发送给服务器的确认报文有没有丢失？`
> > 在 TCP 四次挥手的最后一步，客户端发送确认报文后，如果确认报文丢失了，服务器会在超时时间内没有收到确认报文，会重新发送最后的确认报文。这是因为 TCP 协议中有超时重传的机制，如果发送的数据没有得到确认，发送方会进行重传，直到得到确认或达到最大重传次数。在四次挥手的过程中，客户端的确认报文如果丢失，服务器会等待一段时间，如果在超时时间内没有收到确认，会重新发送最后的确认报文。这样可以确保双方都能够安全地关闭连接，并且在关闭连接后的一段时间内，保证了之前发送的数据都能够被正确接收。
粘包
在计算机网络通信中，粘包（Packet Pasting）是指接收方在接收数据时，由于某种原因（例如缓冲区大小限制、接收方处理速度慢等），多个数据包被“粘”在一起，形成了一个大的数据包，导致接收方无法正确解析和处理每个独立的数据包。 粘包可能发生在各种网络通信协议中，包括TCP、UDP等。它可能会导致接收方无法准确地识别消息的边界，从而影响数据的正确性和完整性。
常见导致粘包的原因包括：
- 发送方连续发送数据，接收方缓冲区大小有限，无法及时处理所有数据。
- 网络传输过程中，数据包被合并成一个大的数据包。
- 接收方处理速度慢，无法及时处理所有接收到的数据。
为了解决粘包问题，可以采取一些解决方案，例如：
- 使用消息边界：在数据包中添加消息边界标识，接收方根据消息边界来划分数据包。
- 使用固定长度的数据包：发送方将数据按照固定长度进行切分，接收方根据固定长度来解析数据包。
- 使用消息头包含消息长度信息：在数据包的头部添加消息长度信息，接收方首先读取消息长度，然后根据消息长度来接收完整的数据包。
