标签：HTTP 请求 TCP 计算机网络 面试 服务器 资源 客户端

HTTP

1. HTTP（超文本传输协议）

HTTP（Hypertext Transfer Protocol）是一个无状态的应用层协议，主要用于Web客户端（浏览器）和Web服务器之间的数据传输。它被广泛用于网页加载、文件传输等网络应用中。HTTP协议遵循请求-响应模式，即客户端（如浏览器）向服务器发送请求，服务器处理请求并返回响应。

工作原理：

• 客户端发起请求：例如，当你在浏览器输入一个URL时，浏览器会向服务器发送HTTP请求。
• 服务器返回响应：服务器根据请求处理并返回资源（如HTML页面、图片等），并附带响应状态码（如200表示成功，404表示资源未找到）。

特点：

• 无状态：每个HTTP请求是独立的，服务器不会记住上一次请求的信息。每次请求都需要包含必要的状态信息（如登录凭证等）。
• 无连接：每次请求/响应都是独立的，在完成传输后，连接会被关闭。
• 简单易用：HTTP是基于文本的协议，非常易于理解和实现。

典型HTTP请求和响应示例：

请求：

GET /index.html HTTP/1.1
Host: www.example.com

响应：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234

WEBSOCKET

2. WebSocket

WebSocket 是一种网络通信协议，它允许在客户端和服务器之间建立一个持久的、双向的、全双工（双向同时通信）连接。这与传统的HTTP协议不同，WebSocket能够让客户端和服务器实时、持续地交换数据。

工作原理：

• 握手过程：WebSocket的连接从一个标准的HTTP请求开始。在建立连接时，客户端发送一个包含WebSocket协议的请求头（包含Upgrade字段）来升级协议，服务器响应一个包含101 Switching Protocols的状态码表示同意协议升级。
• 持久连接：一旦建立连接，WebSocket会保持该连接，客户端和服务器之间可以随时互相发送数据。相比于HTTP，WebSocket的优势在于无需每次都建立连接，减少了开销，提升了实时性。
• 数据格式：WebSocket传输的数据是以帧的形式进行的，可以传输文本数据或二进制数据（如图片、音频等）。

特点：

• 全双工通信：WebSocket支持双向通信，服务器和客户端可以在任何时刻发送数据。
• 低延迟：WebSocket连接是持久的，可以随时发送和接收数据，不需要每次请求/响应的开销，因此延迟较低。
• 适用于实时应用：例如，实时聊天、股票行情、在线游戏、推送通知等。

WebSocket使用场景：

• 实时数据推送：例如新闻、天气、股票市场数据。
• 在线游戏：需要频繁、低延迟的双向通信。
• 实时聊天应用：如即时通讯工具（例如微信、Slack等）。

WebSocket的一个简单连接过程：

1. 客户端发送请求：

   GET /chat HTTP/1.1
   Host: example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Sec-WebSocket-Version: 13
   

2. 服务器响应：

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: x3JJHMbDL1EzLkh9K5Kvvxg9a7m=
   

RESTful API

3. RESTful

RESTful 是一种基于HTTP协议的架构风格，用于设计分布式系统的Web服务。RESTful的全称是Representational State Transfer（表述性状态转移），其设计理念强调简洁性、无状态性和可扩展性。

核心原则：

• 资源（Resources）：RESTful风格的Web服务将网络中的所有数据或功能都视作“资源”。每个资源通过一个唯一的URI（统一资源标识符）来表示，例如：https://api.example.com/users表示一个用户资源。
• HTTP方法（HTTP Methods）：RESTful API使用HTTP的标准方法（如GET、POST、PUT、DELETE等）来操作资源：
  • GET：获取资源。
  • POST：创建资源。
  • PUT：更新资源。
  • DELETE：删除资源。
  • PATCH：部分更新资源。
• 无状态（Stateless）：每个请求都是独立的，服务器不保存客户端的状态信息。每个请求都需要提供完成操作所需的所有信息（例如，用户认证信息等）。
• 表述性（Representation）：资源的表述（通常是JSON或XML格式）是客户端与服务器之间交换的内容。例如，当请求获取某个用户的资源时，响应体可能包含该用户的详细信息（如姓名、年龄等）。

RESTful设计的优势：

• 简洁明了：RESTful API使用标准的HTTP动词和URL，使得接口易于理解和使用。
• 无状态性：每个请求都是独立的，不依赖于之前的请求，这提高了系统的可扩展性和可靠性。
• 可扩展性：由于资源和操作的定义明确，RESTful接口具有很好的扩展性，适合分布式系统。

示例：

假设我们有一个用户资源的RESTful API：

• GET /users：获取所有用户的信息。
• GET /users/{id}：获取特定ID用户的信息。
• POST /users：创建一个新用户。
• PUT /users/{id}：更新指定ID的用户信息。
• DELETE /users/{id}：删除指定ID的用户。

RESTful API的实际应用：

• Web应用：如社交媒体网站、电子商务平台等。
• 移动应用：大多数现代的移动应用与后台服务进行数据交互时，都会使用RESTful API。

RESTful API（Representational State Transfer）是设计Web服务的一种架构风格，它通过标准的HTTP方法对资源进行操作。RESTful API的设计是基于HTTP协议，并且强调简洁、无状态和灵活。下面我将详细介绍RESTful API中的每个常用功能。

1. GET — 获取资源

• 功能：GET 方法用于从服务器获取资源。客户端通过这个请求从服务器请求数据或信息，服务器返回给客户端请求的资源，通常是一个JSON或XML格式的响应体。
• 特点：
  • 安全：GET请求是只读操作，不会改变服务器的状态。
  • 幂等性：无论执行多少次，GET请求的结果应该是相同的。
  • 不包含请求体，所有的参数通常通过URL传递。

示例：

GET /users           # 获取所有用户信息
GET /users/{id}      # 获取ID为{id}的用户信息

响应：

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com"
}

2. POST — 创建资源

• 功能：POST 方法用于向服务器提交数据，通常用于创建新资源。当客户端向服务器发送数据时，服务器会根据该数据创建一个新的资源。
• 特点：
  • 非幂等性：多次执行POST请求会创建多个资源，不是幂等的。
  • 请求体中通常包含需要创建的资源数据。

示例：

POST /users

请求体：

{
  "name": "Bob",
  "email": "bob@example.com"
}

响应：

{
  "id": 2,
  "name": "Bob",
  "email": "bob@example.com"
}

此时服务器会创建一个新的用户，通常会返回新创建资源的ID。

3. PUT — 更新资源

• 功能：PUT 方法用于更新服务器上的现有资源。客户端将更新后的资源信息发送到服务器，服务器根据该数据更新现有资源。通常，PUT是幂等的：多次发送相同的PUT请求会有相同的效果。
• 特点：
  • 幂等性：多次执行PUT请求对资源的结果不会变化（更新操作最终会一致）。
  • 请求体中包含更新后的完整资源。

示例：

PUT /users/{id}

请求体：

{
  "name": "Bob",
  "email": "bob@newdomain.com"
}

响应：

{
  "id": 2,
  "name": "Bob",
  "email": "bob@newdomain.com"
}

此时，ID为2的用户信息将被更新。

4. PATCH — 部分更新资源

• 功能：PATCH 方法用于对资源进行部分更新。与PUT不同，PATCH仅更新部分字段，不需要传输完整的资源数据。
• 特点：
  • 非幂等性：PATCH请求本身通常不是幂等的，但如果请求内容相同，效果也会相同。
  • 请求体只包含要更新的字段。

示例：

PATCH /users/{id}

请求体：

{
  "email": "bob@newdomain.com"
}

响应：

{
  "id": 2,
  "name": "Bob",
  "email": "bob@newdomain.com"
}

只更新了email字段，而不需要提供name字段。

5. DELETE — 删除资源

• 功能：DELETE 方法用于从服务器删除资源。客户端请求删除指定的资源，服务器根据该请求删除资源。
• 特点：
  • 幂等性：多次执行DELETE请求的结果是相同的（即资源删除后，继续删除不会造成错误）。
  • 一旦删除，资源不可恢复。

示例：

DELETE /users/{id}

响应：

{
  "message": "User deleted successfully."
}

此时，ID为2的用户将被删除。

6. OPTIONS — 获取支持的HTTP方法

• 功能：OPTIONS 方法用于查询服务器支持的HTTP方法，通常用于检查某个资源是否支持特定的请求操作。
• 特点：
  • 服务器响应OPTIONS请求时，会返回它支持的HTTP方法（如GET、POST、PUT等）。

示例：

OPTIONS /users/{id}

响应：

Allow: GET, PUT, DELETE

这意味着，服务器支持对/users/{id}资源进行GET、PUT和DELETE操作。

7. HEAD — 获取资源的元数据

• 功能：HEAD 方法与GET类似，但服务器只返回响应头而不返回响应体。通常用于获取资源的元数据，如内容长度、类型等信息，而不需要获取完整的资源内容。
• 特点：
  • 用于获取资源的元数据，节省带宽。
  • 响应头与GET相同，但没有响应体。

示例：

HEAD /users/{id}

响应：

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1024

---

RESTful API的最佳实践：

1. 资源的命名：

   • 使用名词复数表示资源。例如：/users表示用户集合，/users/{id}表示单个用户资源。

2. 使用标准HTTP状态码：

   • 200 OK：请求成功。
   • 201 Created：资源创建成功。
   • 400 Bad Request：客户端请求错误。
   • 401 Unauthorized：未授权。
   • 404 Not Found：资源未找到。
   • 500 Internal Server Error：服务器内部错误。

3. 无状态：

   • 每个请求都应该包含所有需要的信息，服务器不保存客户端的状态。每次请求都是独立的。

4. 版本管理：

   • 使用版本控制来管理API的变化，常见的做法是通过URL路径表示版本，例如：/api/v1/users。

5. 支持多种数据格式：

   • 常见的数据格式有JSON和XML。通常RESTful API使用JSON，因为它更轻量且易于解析。

---

总结：

RESTful API是一个基于HTTP协议的设计风格，使用标准的HTTP方法对资源进行CRUD操作（创建、读取、更新、删除）。这些方法与资源通过URL进行映射，并且使用HTTP状态码传递操作的结果。RESTful API简洁、无状态，并且易于扩展，广泛应用于现代Web应用和移动应用的后端服务。

TCP/IP

4. TCP/IP（传输控制协议/互联网协议）

TCP/IP 是一组用于互联网上通信的协议集合，是计算机网络的基础协议。它由两个主要部分组成：TCP（传输控制协议）和IP（互联网协议）。这两个协议分别负责数据的可靠传输和数据包的路由与转发。

主要组成部分：

1. IP（互联网协议）：

   • 作用：IP协议负责将数据包从源主机传输到目标主机。IP协议会根据每个数据包的目的地地址（IP地址）决定该数据包的传输路径。
   • 工作原理：每个计算机和网络设备都有一个唯一的IP地址。IP协议通过这个地址识别设备，确保数据包能够准确到达目标设备。IP协议是无连接的，也就是说，它不能保证数据包按顺序到达或不丢失。
   • IPv4与IPv6：IPv4（Internet Protocol version 4）是最常用的IP版本，但由于IP地址的枯竭，IPv6（Internet Protocol version 6）被引入，具有更大的地址空间。

2. TCP（传输控制协议）：

   • 作用：TCP协议负责提供可靠的数据传输服务。它确保数据的完整性、顺序，并能检测和恢复丢失的数据包。
   • 工作原理：TCP在数据传输之前会先建立连接（通过三次握手过程），然后开始传输数据。在传输过程中，TCP会对数据进行分段，每一段都有一个序列号。接收端会发送确认应答，确保数据包已成功接收。如果丢失了数据包，TCP会请求重传。通过这种方式，TCP能够确保数据按顺序、无差错地到达目的地。
   • 可靠性：TCP的可靠性来源于流量控制、拥塞控制和错误检测机制。

TCP/IP协议的工作过程：

1. 数据分割：当一个程序需要传输数据时，数据被分成多个小的数据包。每个数据包包括目标IP地址、源IP地址、序列号等信息。
2. 路由转发：IP协议将每个数据包从源主机传送到目标主机。路由器根据目标IP地址决定数据包的路径。
3. 数据重组：TCP协议在接收端确保所有的数据包按正确顺序到达，并将它们重组为原始数据。

典型应用：

• Web通信：浏览器与服务器之间的HTTP请求与响应通常通过TCP/IP协议进行。
• 电子邮件：通过SMTP、POP3和IMAP等协议使用TCP/IP发送和接收电子邮件。
• 文件传输：FTP（文件传输协议）基于TCP/IP用于文件上传和下载。

TCP/IP与其他协议的关系：

• HTTP、FTP、SMTP等协议都依赖于TCP/IP作为传输层协议。也就是说，应用层协议（如HTTP）使用TCP/IP协议来实际发送数据。
  好的，关于TCP/IP协议的三次握手（Three-Way Handshake）和四次挥手（Four-Way Handshake），这两者是TCP连接的建立和断开过程。下面分别详细解释：

1. 三次握手（三次握手过程）

三次握手是TCP建立连接时的过程，用来确保客户端和服务器之间的连接是可靠的。它的目的是同步双方的序列号和确认号，并确认双方的接收和发送能力。

三次握手过程：

1. 第一次握手（客户端 → 服务器）：

   • 客户端发送一个SYN（同步）包，表示希望建立连接。此包中包含一个初始序列号（ISN）。
   • 这一包是用来启动连接的，告诉服务器客户端希望与它建立连接，并且携带客户端的初始序列号。

2. 第二次握手（服务器 → 客户端）：

   • 服务器收到客户端的SYN包后，回复一个SYN-ACK包，表示同意建立连接，并同时将客户端的序列号加1作为对客户端的确认号（ACK）。同时，服务器自己也选择一个初始序列号（ISN）。
   • 服务器的响应表示它准备好建立连接，并且确认了客户端的请求。

3. 第三次握手（客户端 → 服务器）：

   • 客户端收到服务器的SYN-ACK包后，发送一个ACK包，表示服务器的序列号加1已收到确认。
   • 这一包确认服务器的序列号，并且客户端也完成了连接的建立。

结果：

• 客户端和服务器之间的TCP连接已经建立。此时，双方都能开始数据传输。

三次握手的作用：

• 同步序列号：通过三次握手，客户端和服务器能够同步各自的初始序列号，确保后续数据传输的正确性。
• 确认双方都能收发数据：三次握手确保了客户端和服务器都准备好接收和发送数据。

---

2. 四次挥手（四次挥手过程）

四次挥手是TCP断开连接时的过程，目的是优雅地断开连接，确保双方的数据都能正确传输完成后，再关闭连接。

四次挥手过程：

1. 第一次挥手（客户端 → 服务器）：

   • 客户端发送一个FIN（终止）包，表示客户端已经没有数据发送了，准备关闭连接。此时，客户端进入FIN_WAIT_1状态。
   • 该包告诉服务器客户端希望关闭连接。

2. 第二次挥手（服务器 → 客户端）：

   • 服务器收到客户端的FIN包后，回复一个ACK包，确认客户端的FIN包（序列号+1）。此时，服务器进入CLOSE_WAIT状态。
   • 这一确认表示服务器已经知道客户端关闭连接的请求。

3. 第三次挥手（服务器 → 客户端）：

   • 当服务器处理完剩余的数据后，准备关闭连接时，它发送一个FIN包，表示服务器也没有数据发送了，准备关闭连接。此时，服务器进入LAST_ACK状态。
   • 服务器的FIN包表示它已经准备好关闭连接。

4. 第四次挥手（客户端 → 服务器）：

   • 客户端收到服务器的FIN包后，发送一个ACK包，确认服务器的FIN包（序列号+1）。此时，客户端进入TIME_WAIT状态。
   • 客户端确认后，连接最终关闭。

结果：

• 当客户端收到服务器的最后一个ACK包后，连接彻底关闭。

四次挥手的作用：

• 优雅地断开连接：四次挥手确保了双方都能完成数据的发送和接收，避免数据丢失。
• 半关闭状态：由于数据的方向是独立的，所以TCP协议允许客户端和服务器各自独立关闭各自的连接。这样，一方可以先关闭发送数据的通道，而另一方可以继续接收数据，直到确认没有更多的数据。

---

总结：

• 三次握手确保TCP连接的可靠建立，双方同步初始序列号并确认彼此准备好发送和接收数据。
• 四次挥手确保连接的可靠断开，允许双方分别关闭各自的数据传输通道，确保数据的完整传输。

---

HTTP状态码

以下是常见的HTTP状态码，按照类别进行分类：

1. 1xx（信息性状态码）

这些状态码表示请求已被接受，需要继续处理。

• 100 Continue：表示客户端应继续请求，客户端已发送的部分请求可以继续发送，服务器会告诉客户端继续进行后续的请求。
• 101 Switching Protocols：服务器理解并接受客户端的协议切换请求（如从HTTP/1.1切换到WebSocket）。
• 102 Processing：服务器正在处理请求，但尚未完成。

2. 2xx（成功状态码）

这些状态码表示请求已成功处理。

• 200 OK：请求成功，服务器返回请求的数据（GET请求）或确认已处理数据（POST请求）。
• 201 Created：请求成功并且服务器创建了新资源，通常用于POST请求创建资源时。
• 202 Accepted：请求已被接受，但尚未处理完成。
• 203 Non-Authoritative Information：请求成功，但返回的元数据可能来自不同的服务器。
• 204 No Content：请求成功，但服务器没有返回任何内容（通常用于DELETE请求）。
• 205 Reset Content：请求成功，客户端应该重置（清空）页面。
• 206 Partial Content：服务器返回部分内容，通常用于支持断点续传的情况（例如下载文件时分块下载）。

3. 3xx（重定向状态码）

这些状态码表示需要进一步的操作才能完成请求。

• 300 Multiple Choices：请求有多个可能的响应，客户端应根据情况选择合适的响应。
• 301 Moved Permanently：资源已永久移动到新位置，客户端应使用新的URL访问。
• 302 Found：资源临时移动，客户端应使用临时的URL。
• 303 See Other：响应可以在不同的URL处找到，客户端应使用GET请求访问该URL。
• 304 Not Modified：请求的资源未修改，客户端可继续使用缓存的版本。
• 305 Use Proxy：请求应该通过指定的代理服务器进行处理。
• 307 Temporary Redirect：资源临时移动，客户端应使用临时的URL，且应保持原有请求方法（POST、GET等）。
• 308 Permanent Redirect：资源永久移动，客户端应使用新的URL。

4. 4xx（客户端错误状态码）

这些状态码表示客户端提交的请求有错误，通常是请求格式不正确或缺少必要的权限。

• 400 Bad Request：请求无效或无法理解，通常是因为请求的格式错误。
• 401 Unauthorized：请求缺少有效的认证信息，客户端必须进行身份验证。
• 402 Payment Required：尚未实施，原本为支付要求，但目前通常未被使用。
• 403 Forbidden：服务器拒绝请求，客户端无权限访问指定资源。
• 404 Not Found：请求的资源未找到，URL可能错误。
• 405 Method Not Allowed：请求的方法（如GET、POST等）不被允许用于请求的资源。
• 406 Not Acceptable：服务器无法根据客户端的请求头返回符合条件的响应内容（如数据格式不匹配）。
• 407 Proxy Authentication Required：需要通过代理进行身份验证。
• 408 Request Timeout：客户端请求超时，服务器等待客户端请求时超时。
• 409 Conflict：请求与服务器的当前状态冲突，通常在修改资源时出现冲突。
• 410 Gone：请求的资源不再可用且没有任何转发地址。
• 411 Length Required：服务器要求请求中必须包含Content-Length头。
• 412 Precondition Failed：请求头中的某些前提条件失败。
• 413 Payload Too Large：请求的负载太大，服务器无法处理。
• 414 URI Too Long：请求的URL过长，服务器无法处理。
• 415 Unsupported Media Type：请求的媒体类型不被服务器支持。
• 416 Range Not Satisfiable：请求的范围无法满足，通常与文件的分块请求相关。
• 417 Expectation Failed：服务器无法满足Expect请求头中的要求。
• 418 I'm a teapot：愚人节的一个状态码，表示服务器是一个茶壶，无法泡茶。通常用作玩笑。
• 421 Misdirected Request：请求的目标服务器错误地处理了请求。
• 422 Unprocessable Entity：请求的语法正确，但服务器无法处理请求的内容，通常与语义错误有关。
• 423 Locked：资源被锁定，无法访问。
• 424 Failed Dependency：由于之前的操作失败，导致当前操作无法继续执行。
• 425 Too Early：服务器不愿意处理当前请求，通常用于防止早期请求。
• 426 Upgrade Required：客户端需要升级协议（例如从HTTP/1.1升级到HTTP/2）。
• 428 Precondition Required：要求请求必须满足某些前提条件。
• 429 Too Many Requests：客户端发送的请求次数过多，通常是速率限制。
• 431 Request Header Fields Too Large：请求头字段太大，服务器无法处理。
• 451 Unavailable For Legal Reasons：由于法律原因，资源不可用。

5. 5xx（服务器错误状态码）

这些状态码表示服务器遇到错误或无法完成合法的请求。

• 500 Internal Server Error：服务器内部错误，导致无法完成请求。
• 501 Not Implemented：服务器不支持请求所需的功能。
• 502 Bad Gateway：作为网关或代理的服务器从上游服务器收到无效响应。
• 503 Service Unavailable：服务器暂时无法处理请求，通常是因为过载或维护。
• 504 Gateway Timeout：作为网关或代理的服务器未能及时从上游服务器获取响应。
• 505 HTTP Version Not Supported：服务器不支持请求中使用的HTTP版本。
• 506 Variant Also Negotiates：服务器内部配置错误，导致无法进行内容协商。
• 507 Insufficient Storage：服务器无法存储完成请求所需的内容。
• 508 Loop Detected：服务器在处理请求时检测到无限循环。
• 510 Not Extended：请求未满足扩展要求，必须提供更多信息以完成请求。

---

总结：

HTTP状态码为Web开发者和用户提供了处理请求结果的重要信息，常见的状态码包括成功状态码（2xx）、客户端错误状态码（4xx）、服务器错误状态码（5xx）等。通过这些状态码，客户端和服务器能够快速识别请求的处理情况，并采取相应的措施。如果需要更多细节，随时可以询问！

标签：HTTP,请求,TCP,计算机网络,面试,服务器,资源,客户端
From： https://www.cnblogs.com/colommar-blog/p/18672771