Tcp Http相关

• 目前默认的 HTTP 协议版本是 HTTP/2。
• 304（未修改）：表示客户端发送的请求中包含了“if-Modified-Since”或“if-None-Match”等条件头，服务器根据这些条件头判断资源是否被修改过。如果资源未被修改，服务器将返回 304 状态码，告诉客户端可以使用本地缓存的资源。
• 403（禁止）：表示服务器拒绝了客户端的请求，通常是因为客户端没有足够的权限访问该资源。
• 401（未授权）：表示客户端发送的请求中缺少身份验证信息，或者身份验证信息不正确，服务器无法验证客户端的身份。
• 405（方法不允许）：表示客户端发送的请求方法不被服务器允许，例如服务器只允许 GET 请求，而客户端发送了 POST 请求。

• 连接方式：
  • HTTP1.0默认使用非持久连接，每次请求都需要建立新的连接；
  • HTTP1.1默认使用持久连接，可以在一个连接上发送多个请求；
  • HTTP2.0使用二进制分帧层，实现了多路复用，可以在一个连接上同时发送多个请求。
• 缓存处理：
  • HTTP1.0主要使用标头中的If-Modified-Since和Expires来做为缓存的判断标准；
  • HTTP1.1引入了更多的缓存策略，例如Etag、If-Unmodified-Since、If-Match和If-None-Match等；
  • HTTP2.0则进一步优化了缓存的实现。
• 错误处理：
  • HTTP1.0和HTTP1.1的错误处理方式比较简单，主要是通过状态码来表示；
  • HTTP2.0则引入了更多的错误处理机制，例如二进制分帧层中的错误处理和流控制等。
• 性能优化：
  • HTTP2.0通过二进制分帧层实现了多路复用和流控制，提高了性能；
  • HTTP1.1则通过持久连接和缓存处理等方式提高了性能。

目前常用的HTTP版本是HTTP2.0。

HTTPS 的实现原理主要包括证书验证和数据传输两个阶段，具体的交互过程如下：

• 证书验证阶段：
  • 浏览器发起 HTTPS 请求。
  • 服务端返回 HTTPS 证书。
  • 客户端验证证书是否合法，如果不合法则提示告警。
    • 要判断一个数字证书是否有效，可以通过以下几个步骤进行：
    • 验证证书的颁发机构：确认证书是由一个受信任的证书颁发机构（CA）签发的。 这可以通过查看证书中的CA信息来完成。
    • 检查证书的有效期：每个证书都有一个起始和结束日期，确保证书在当前日期仍在有效期内。
    • 核对证书持有者信息：核实证书中列出的组织名称、位置等信息与你预期的是否一致。
    • 确认证书链的完整性：验证证书链上的每一级证书都是合法且未被篡改的。 这涉及到使用上级证书的公钥来解密下级证书的数字签名，并核对得到的摘要是否匹配。
    • 检查证书的加密算法：确认证书使用的加密算法是否是安全且未被破解的。
    • 使用在线工具检测：可以使用在线SSL检测工具来验证SSL证书是否正确安装和配置。
• 数据传输阶段：
  • 当证书验证合法后，在本地生成随机数。
  • 通过公钥加密随机数，并把加密后的随机数传输到服务端。
  • 服务端通过私钥对随机数进行解密。
  • 服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。

三次握手的目的 是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

• 第一次握手 ：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
• 第二次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
• 第三次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

要四次挥手的目的 ：TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。

举个例子：A 和 B 打电话，通话即将结束后。

• 第一次挥手 ： A 说“我没啥要说的了”
• 第二次挥手 ：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
• 第三次挥手 ：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
• 第四次挥手 ：A 回答“知道了”，这样通话才算结束。

• 前端轮询
  • 短轮询：客户端定时向服务端发送请求，服务端直接返回响应数据（即使没有数据更新）
    • 优点：简单、易理解、易实现；
    • 缺点：实时性太差，无效请求太多，频繁建立连接太耗费资源；
  • 长轮询：与短轮询不同是，长轮询接收到客户端请求之后等到有数据更新才返回请求；
    • 优点：减少了无效请求；
    • 缺点：挂起请求会导致资源浪费；
• iframe 流
  • 服务端和客户端之间创建一条长连接，服务端持续向iframe传输数据。
    • 优点：简单、易理解、易实现
    • 缺点：维护一个长连接会增加开销，效果太差（图标会不停旋转）
• SSE
  • (Server-Sent Events)，简称 SSE。这是一种服务器端到客户端(浏览器)的 单向 消息推送。
  • ChatGPT 就是采用的 SSE。对于需要长时间等待响应的对话场景，ChatGPT 采用了一种巧妙的策略：它会将已经计算出的数据“推送”给用户，并利用 SSE 技术在计算过程中持续返回数据。这样做的好处是可以避免用户因等待时间过长而选择关闭页面。
  • SSE 基于 HTTP 协议的。SSE 在服务器和客户端之间打开一个单向通道，服务端响应的不再是一次性的数据包而是text/event-stream类型的数据流信息，在有数据变更时从服务器流式传输到客户端。
  • 整体的实现思路有点类似于在线视频播放，视频流会连续不断的推送到浏览器，你也可以理解成，客户端在完成一次用时很长（网络不畅）的下载。
    • 优点：简单、易实现，功能丰富；
    • 缺点：不支持双向通信；
• Websocket
  • 是一种在 TCP 连接上进行全双工通信的协议，建立客户端和服务器之间的通信渠道。
  • 浏览器和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
  • 除了最初建立连接时用 HTTP 协议，其他时候都是直接基于 TCP 协议进行通信的，可以实现客户端和服务端的全双工通信。
    • 优点：性能高、开销小；
    • 缺点：对开发人员要求更高，实现相对复杂一些；
• MQTT (Message Queue Telemetry Transport)
  • MQTT是一种基于发布/订阅（publish/subscribe）模式的轻量级通讯协议，通过订阅相应的主题来获取消息。
  • 是物联网（Internet of Thing）中的一个标准传输协议。
  • 该协议将消息的发布者（publisher）与订阅者（subscriber）进行分离，因此可以在不可靠的网络环境中，为远程连接的设备提供可靠的消息服务。
  • 使用方式与传统的 MQ 有点类似。
  • TCP 协议位于传输层，MQTT 协议位于应用层；
  • MQTT 协议构建于 TCP/IP 协议上，也就是说只要支持 TCP/IP 协议栈的地方，都可以使用 MQTT 协议。
    • 优点：成熟稳定，轻量级；
    • 缺点：对开发人员要求更高，实现相对复杂一些；