网络编程 websocket

1. HTTP

截至 2024 年，HTTP （HyperText Transfer Protocol）已经发展到 HTTP/3 版本。

各个版本的简介：

HTTP/0.9 （1991年）：
- 最初的 HTTP 版本，非常简单，仅支持 GET 方法和传输纯文本内容，没有头部信息，也不支持状态码。
HTTP/1.0 （1996年）：
- 引入了 HTTP 请求和响应的头部，支持更多的 HTTP 方法（如 POST、HEAD）。
- 每次请求都需要新建一个 TCP 连接，传输效率较低。
HTTP/1.1 （1997年）：
- 改进了性能，支持持久连接（即在同一个 TCP 连接上传输多个请求和响应）。
- 增加了对缓存、压缩、内容协商等功能的支持，提升了性能和扩展性。
HTTP/2 （2015年）：
- 采用了二进制格式（而非 HTTP/1.1 的纯文本格式），大大提高了传输效率。
- 支持多路复用，允许多个请求和响应并发地在同一连接上传输，减少了延迟和头部开销。
- 支持头部压缩，减少了头部信息带来的开销。
HTTP/3 （2018年开始草案，2022年标准化）：
- 基于 QUIC 协议（UDP 上的一种传输协议），大幅减少了连接建立时间和网络传输中的延迟问题。
- 相比于 HTTP/2 的 TCP 连接，HTTP/3 的 QUIC 基于 UDP，使得即使网络不稳定也能更好地保持连接，并提升了传输效率。
- 提供了更好的安全性和性能，尤其是在移动网络和无线网络环境下效果更好。

主要特性对比：

版本	特点	传输方式
HTTP/1.0	每个请求创建一个新的连接，传输效率低。	基于 TCP
HTTP/1.1	支持持久连接和管道化请求，性能提高。	基于 TCP
HTTP/2	二进制传输，多路复用，头部压缩。	基于 TCP
HTTP/3	基于 QUIC 协议，减少延迟，多路复用，适应性更强，传输效率更高。	基于 QUIC（UDP）

HTTP/3 是目前最新的 HTTP 版本，并且逐步在全球范围内得到广泛应用，尤其是在现代浏览器和大型互联网服务中得到了支持。

2. HTTP vs HTTPS

HTTP（HyperText Transfer Protocol）和 HTTPS（HyperText Transfer Protocol Secure）是两种用于网络通信的协议。它们的核心区别在于数据传输的安全性。以下是 HTTP 和 HTTPS 之间的主要区别：

1. 安全性：

HTTP：是一种不安全的协议，所有传输的数据都是明文的。任何人都可以在传输过程中截获并读取数据。HTTP 不提供加密、身份验证或数据完整性保护。
HTTPS：通过使用 SSL（Secure Sockets Layer）或 TLS（Transport Layer Security）对数据进行加密，确保传输的数据是安全的。即使数据在传输中被截获，也无法被解读。此外，HTTPS 还通过数字证书来验证服务器的身份，确保数据传输的目标是合法的服务器。

2. 数据加密：

HTTP：不加密数据，传输的内容（如用户名、密码、表单数据等）都是明文的，容易受到中间人攻击（Man-in-the-Middle Attack）。
HTTPS：使用对称加密和非对称加密相结合来加密传输数据，确保数据的机密性和完整性。客户端和服务器之间的通信是加密的，外部无法窥探或篡改数据。

3. 端口号：

HTTP：默认使用端口号 80 进行通信。
HTTPS：默认使用端口号 443 进行通信。

4. SSL/TLS 证书：

HTTP：不需要 SSL/TLS 证书，通信是直接的，没有安全认证。
HTTPS：必须有有效的 SSL/TLS 证书才能建立加密连接。证书由受信任的证书颁发机构（CA）签发，用于验证服务器身份，确保用户访问的是合法的服务器，而不是伪造的网站。

5. 性能开销：

HTTP：由于不进行加密操作，通信开销较小，性能相对较高。
HTTPS：在通信过程中需要进行加密和解密操作，涉及 SSL/TLS 握手和证书验证，因此会有一定的性能开销。不过，随着硬件和技术的进步，HTTPS 的性能开销已大幅降低，现代应用中这方面的影响已变得较小。

6. SEO （Search Engine Optimization Impact）影响：

HTTP：搜索引擎（如 Google）对使用 HTTP 的网站的排名可能较低，因为 HTTP 不安全，影响用户的信任感。
HTTPS：搜索引擎更倾向于提升使用 HTTPS 的网站排名，因此采用 HTTPS 对 SEO 友好。Google 等搜索引擎明确表示，使用 HTTPS 是一种排名信号。

7. 信任与浏览器支持：

HTTP：现代浏览器对使用 HTTP 的网站显示"不安全"警告，尤其是在涉及敏感信息（如支付、登录）时，用户通常不愿在不安全的 HTTP 网站上提交数据。
HTTPS：浏览器对使用 HTTPS 的网站显示"安全"锁标志，用户可以信任与网站的通信是安全的。尤其在电子商务和在线银行业务等场景下，HTTPS 是必须的。

8. 防止篡改和钓鱼攻击：

HTTP：由于数据是明文传输的，因此容易被中途篡改或截获，也容易被用于钓鱼攻击，因为用户无法确定服务器的真实性。
HTTPS：通过数字证书验证服务器身份，防止钓鱼网站冒充合法网站。此外，加密确保了数据在传输过程中不会被篡改或伪造。

9. 成本：

HTTP：不需要证书，使用成本为零。
HTTPS：通常需要购买 SSL/TLS 证书（尽管现在有一些免费证书提供商，如 Let's Encrypt）。为网站配置 HTTPS 可能需要一些额外的配置工作和成本。

总结：

HTTP 是不安全的明文通信协议，适合不涉及敏感信息的简单数据传输，但随着网络安全意识的提高，使用 HTTP 的场景越来越少。
HTTPS 是安全的通信协议，通过加密和身份验证来保护数据传输，适合所有需要保护用户隐私和敏感信息的网站，尤其是涉及支付、登录等敏感操作的场景。

现代网络上，HTTPS 已经成为标准，甚至浏览器和搜索引擎也强烈推荐或要求使用 HTTPS，以确保用户的数据安全。

3. POST vs GET

在 HTTP 协议中，POST 请求和 GET 请求是两种最常用的请求方法。它们之间有几个重要的区别，主要体现在数据传输方式、用途和安全性等方面。

1. 请求的用途：

GET 请求 ：
- 用于从服务器获取资源或数据。
- 常用于请求静态内容，如网页、图片、文件等，目的是获取数据，而不修改服务器端的数据。
- GET 请求是幂等的，也就是说，多次发送同样的 GET 请求，结果应该是相同的，不会对服务器的状态产生副作用。
POST 请求 ：
- 用于将数据发送到服务器，通常用于创建或更新资源。
- 常用于提交表单数据、上传文件等需要在服务器端进行数据处理的操作。
- POST 请求不是幂等的，多次发送 POST 请求可能会导致不同的结果（例如，多次提交相同的表单可能会创建多个记录）。

2. 数据传输方式：

GET 请求 ：
- 数据通过 URL 的查询字符串传递，也就是通过 URL 的一部分发送给服务器。
- 例如：https://example.com/api?name=John\&age=30
- URL 的长度有限，查询字符串通常用于传递少量的非敏感数据。
POST 请求 ：
- 数据放在请求体（body）中，而不是通过 URL 传递。因此，POST 请求没有大小限制，能够传递大量数据。
- POST 请求通常用于提交表单数据、JSON、XML、文件等复杂或大规模数据。

3. 数据的可见性和安全性：

GET 请求 ：
- 由于数据包含在 URL 中，所有发送的数据都在 URL 上显示。这意味着 GET 请求的数据会出现在浏览器的地址栏中，且可能会被浏览器缓存或记录在浏览历史中。
- 因此，GET 请求不适合传递敏感信息，如密码、信用卡号等。
POST 请求 ：
- 数据被放在请求体中，不会显示在 URL 中，因此比 GET 请求更适合传递敏感数据。
- 但是，POST 请求本身并不比 GET 请求更安全，因为数据仍然可以被拦截。为了真正的安全性，应该通过 HTTPS 加密传输数据。

4. 缓存机制：

GET 请求 ：
- 通常可以被浏览器缓存。服务器也可以对 GET 请求进行缓存，以提高响应速度。
POST 请求 ：
- 不会被浏览器自动缓存。POST 请求每次都会重新发送，并且默认情况下不允许缓存。

5. 对服务器的影响：

GET 请求 ：
- 通常只用于读取数据，不会对服务器上的资源进行修改。GET 请求可以视为只读操作。
POST 请求 ：
- 通常用于发送数据到服务器并进行资源的创建、修改或删除，因此属于写操作，会对服务器上的数据产生影响。

6. URL 长度限制：

GET 请求 ：
- 因为数据是通过 URL 传递的，GET 请求的 URL 长度有限（取决于浏览器和服务器），通常不能超过 2048 字符。
POST 请求 ：
- 没有这种限制，因为数据通过请求体传输，可以传递大量数据。

7. 幂等性：

GET 请求 ：
- 幂等的，多次执行相同的 GET 请求，结果相同，不会对服务器状态产生影响。
POST 请求 ：
- 非幂等的，多次发送同样的 POST 请求可能会导致不同的结果。例如，连续多次提交一个购买订单表单可能会生成多个订单。

8. 跨域请求限制：

GET 请求 ：
- 跨域请求时，GET 请求会有一定的限制，但通常只要服务器支持，跨域 GET 请求可以正常工作。
POST 请求 ：
- 跨域 POST 请求需要更多的跨域资源共享（CORS）配置，因为浏览器会对跨域 POST 请求进行更多的检查，以确保安全性。

总结：

GET 请求：主要用于从服务器获取数据，数据通过 URL 传递，适用于查询、只读操作。数据长度有限，不适合传递敏感信息。
POST 请求：用于向服务器提交数据，数据通过请求体传递，适用于创建或修改资源。可以传递大量数据，并且不显示在 URL 中。

4. TCP 三次握手和四次挥手

TCP 三次握手 和四次挥手是用于建立和关闭 TCP 连接的两种机制，确保连接的建立与释放可靠和有序。下面是它们的详细解释：

一、TCP 三次握手（Three-way Handshake）

TCP 是一种面向连接的协议，在两个设备之间传输数据前，需要先建立一个可靠的连接。三次握手是指客户端和服务器在通信前要相互确认准备状态，确保双方都能发送和接收数据。

三次握手过程：

第一次握手（客户端发送 SYN） ：
- 客户端向服务器发送一个 SYN（Synchronize） 包，用来请求建立连接。
- SYN 包中包含客户端的初始序列号 Seq=X，标记客户端将用于数据传输的序列号。
- 客户端进入 SYN-SENT 状态。
第二次握手（服务器回应 SYN-ACK） ：
- 服务器收到客户端的 SYN 请求后，向客户端回应一个 SYN-ACK 包，表示接收到请求并同意建立连接。
- SYN-ACK 包中包含服务器的初始序列号 Seq=Y ，同时对客户端的 SYN 包中的序列号 X 做确认 Ack=X+1。
- 服务器进入 SYN-RECEIVED 状态。
第三次握手（客户端回应 ACK） ：
- 客户端收到服务器的 SYN-ACK 包后，向服务器发送一个 **ACK（Acknowledgement）**包，确认已收到服务器的响应，并表示可以开始传输数据。
- ACK 包中包含客户端对服务器序列号的确认 Ack=Y+1。
- 连接建立，客户端进入 ESTABLISHED 状态，服务器也进入 ESTABLISHED 状态。

总结：

三次握手的目的是确认客户端和服务器的发送和接收能力，并确保连接的可靠性。建立完连接后，双方即可开始数据传输。

二、TCP 四次挥手（Four-way Handshake）

当数据传输完成后，TCP 需要通过四次挥手来释放连接，确保双方都正确关闭通信。

四次挥手过程：

第一次挥手 （客户端发送 FIN）：
- 当客户端完成数据传输后，它会发送一个 FIN（Finish） 包，表示不再发送数据，但仍然可以接收数据。
- 客户端进入 FIN-WAIT-1 状态。
第二次挥手 （服务器回应 ACK）：
- 服务器收到客户端的 FIN 包后，向客户端发送一个 ACK 包，表示确认已收到客户端的 FIN 请求，但服务器可能还有未发送完的数据。
- 服务器进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
第三次挥手 （服务器发送 FIN）：
- 服务器确认所有数据发送完成后，向客户端发送一个 FIN 包，表示也不再发送数据，准备关闭连接。
- 服务器进入 LAST-ACK 状态。
第四次挥手 （客户端回应 ACK）：
- 客户端收到服务器的 FIN 包后，向服务器发送一个 ACK 包，确认收到服务器的 FIN 请求。
- 客户端进入 TIME-WAIT 状态，此时要等待一段时间（通常是 2 倍的最大报文段生存时间），以确保服务器接收到了 ACK 包，然后彻底关闭连接。
- 服务器接收到 ACK 包后，立即进入 CLOSED 状态，连接正式关闭。

总结：

四次挥手的目的是确保双方都完成了数据传输，并有序地关闭连接，防止任何数据丢失或被中途截断。

为什么是三次握手，四次挥手？

三次握手 是为了确保双方的发送和接收能力正常。客户端和服务器各自需要确认自己能发送数据并能接收对方的确认消息，因此需要三次通信来完成这个过程。
四次挥手 是因为 TCP 是全双工通信（即双方可以同时发送和接收数据），因此每一方都需要独立关闭自己的发送数据通道，这就需要分别发出 FIN 和 ACK，形成四次通信。

图示总结：

三次握手：

lua 复制代码

客户端                       服务器
  SYN  ------------------>  
                           SYN-ACK
  ACK  <------------------

四次挥手：

lua 复制代码

客户端                       服务器
  FIN  ------------------>  
                           ACK
                           FIN
  ACK  <------------------

总结：

三次握手 用于建立连接，保证通信的可靠性。
四次挥手 用于关闭连接，确保双方都完成数据传输并有序断开。

5. TCP vs UDP

TCP （Transmission Control Protocol，传输控制协议）和 UDP（User Datagram Protocol，用户数据报协议）是两种常用的传输层协议，它们的主要区别在于数据传输的可靠性、顺序性、连接性等方面。以下是 TCP 和 UDP 之间的详细区别：

1. 连接与无连接：

TCP：面向连接的协议。在传输数据之前，TCP 需要通过三次握手来建立连接，确保客户端和服务器之间的通信通道已准备好。数据传输完成后，还需要通过四次挥手来关闭连接。
UDP：无连接的协议。在传输数据之前，UDP 不需要建立连接，直接发送数据。这意味着 UDP 没有建立连接的开销，因此传输速度更快，但可靠性较低。

2. 数据传输的可靠性：

TCP：提供可靠的数据传输。它通过确认机制、超时重传、流量控制和拥塞控制来确保数据包的正确传输和接收。TCP 会确认每个数据包的到达，并且如果某个数据包丢失，TCP 会重新发送。
UDP：不保证可靠性。UDP 只负责将数据包发送出去，不关心数据包是否到达目的地，也不确认数据的接收情况。没有重传机制，也没有流量或拥塞控制。

3. 有序性：

TCP：保证数据按顺序到达。TCP 协议会给每个数据包分配一个序列号，并确保数据包按照发送的顺序到达接收方。即使某些数据包延迟，TCP 也会重新排序，确保顺序正确。
UDP：不保证数据包的顺序。由于 UDP 是无连接的协议，数据包的顺序可能会被打乱，接收方无法确保数据包按发送顺序到达。

4. 传输速度：

TCP：由于需要建立连接、确认数据接收、进行流量和拥塞控制，因此 TCP 的传输速度相对较慢。但它的可靠性使其适用于对数据完整性要求较高的场景。
UDP：由于没有连接建立、确认机制和流量控制，UDP 传输速度较快，适合需要快速传输、但对数据完整性要求不高的场景。

5. 头部开销：

TCP：TCP 的头部较大，通常有 20 个字节的头部信息。TCP 头部包含序列号、确认号、窗口大小、标志位等信息，用于实现数据传输的可靠性。
UDP：UDP 的头部较小，只有 8 个字节，包含源端口、目的端口、数据长度和校验和。由于头部较小，UDP 的开销更低，适合传输效率要求高的场景。

6. 流量控制与拥塞控制：

TCP：具备流量控制和拥塞控制功能。TCP 会根据网络状况动态调整传输速率，防止网络拥堵，确保发送方不会过度发送数据导致网络堵塞。
UDP：没有流量控制和拥塞控制机制。UDP 不关心网络状况，数据包一旦发送，不会进行速率调整，可能导致网络拥塞。

7. 适用场景：

TCP ：适用于对数据传输可靠性和顺序性要求较高的场景。例如：
- 网页浏览（HTTP/HTTPS）：需要确保所有网页资源完整传输。
- 文件传输（FTP）：要求文件完整、准确地到达。
- 电子邮件（SMTP、IMAP）：邮件内容必须完整传输。
UDP ：适用于对传输速度要求高、但对数据完整性和顺序性要求不高的场景。例如：
- 视频会议、实时流媒体（如 Zoom、YouTube、Twitch）：对延迟要求敏感，允许少量数据丢失。
- 在线游戏：游戏中的动作需要快速传递，短暂的数据丢失不会影响整体体验。
- DNS 查询：查询结果通常很小，并且如果丢失可以快速重新发送。

8. 流量模式：

TCP：是面向流的协议，数据作为无边界的字节流传输，发送方和接收方之间的数据传输通过 TCP 管道进行，数据流可以持续不断地发送。
UDP：是面向消息的协议。每个 UDP 数据包是独立的消息单元，不需要保持数据的持续性，也不会合并数据包。因此，每个数据包都是独立的、完整的。

9. 使用的协议：

TCP ：常用于需要高可靠性的应用层协议，如：
- HTTP/HTTPS（网页浏览）
- FTP（文件传输）
- SMTP（电子邮件）
- SSH（安全登录）
UDP ：常用于需要快速传输的应用层协议，如：
- DNS（域名解析）
- DHCP（动态主机配置协议）
- TFTP（简单文件传输协议）
- RTP（实时传输协议，用于视频/音频流）

总结对比表：

特性	TCP	UDP
是否连接	面向连接	无连接
可靠性	提供可靠传输，确保数据完整性	不提供可靠传输，可能丢包
有序性	确保数据按顺序到达	不保证数据包顺序
传输速度	较慢（由于需要握手、确认等）	较快（无连接、无确认机制）
头部开销	较大（20 字节）	较小（8 字节）
流量控制和拥塞控制	有	无
适用场景	需要数据完整性和可靠性的场景	需要快速传输、允许丢包的场景

总结：

TCP 提供连接性、可靠性和有序性，适用于需要确保数据完整和顺序的应用，但传输速度相对较慢，开销较大。
UDP 传输速度快，头部开销小，适用于对速度要求高、但对可靠性要求不高的场景，如实时通信和流媒体等。