Updated:

大宝典-计算机网络

Table of contents

Open Table of contents

261. HTTP 请求方式

  1. GET

    • 用途：从服务器获取资源。
    • 特点：请求数据附加在 URL 中；无请求体；一般用于查询操作；对数据不产生副作用。
    • 幂等性：是。
    • 安全性：是。
    • 示例：获取网页内容、查询数据。
    • 示例代码： 
      curl -X GET http://example.com/resource

  2. POST

    • 用途：向服务器提交数据以创建或更新资源。
    • 特点：数据包含在请求体中；请求可能会更改服务器状态。
    • 幂等性：否。
    • 安全性：否。
    • 示例：提交表单数据、上传文件。
    • 示例代码： 
      curl -X POST -d "param1=value1&param2=value2" http://example.com/resource

  3. PUT

    • 用途：向服务器提交数据以创建或完全替换指定资源。
    • 特点：数据包含在请求体中；如果资源存在则更新，不存在则创建。
    • 幂等性：是。
    • 安全性：否。
    • 示例：更新或创建资源。
    • 示例代码： 
      curl -X PUT -d '{"name":"value"}' http://example.com/resource

  4. DELETE

    • 用途：删除指定的资源。
    • 特点：请求数据附加在 URL 中；删除资源。
    • 幂等性：是。
    • 安全性：否。
    • 示例：删除数据。
    • 示例代码： 
      curl -X DELETE http://example.com/resource

  5. HEAD

    • 用途：与 GET 相同，但只返回响应的头部，不包含响应体。
    • 特点：用于获取资源的元数据。
    • 幂等性：是。
    • 安全性：是。
    • 示例：检查资源是否存在，获取资源的元数据。
    • 示例代码： 
      curl -X HEAD http://example.com/resource

  6. OPTIONS

    • 用途：获取服务器支持的 HTTP 方法或对特定资源的支持情况。
    • 特点：用于获取服务器的能力。
    • 幂等性：是。
    • 安全性：是。
    • 示例：检查服务器支持哪些 HTTP 方法。
    • 示例代码： 
      curl -X OPTIONS http://example.com/resource

  7. PATCH

    • 用途：对资源进行部分修改。
    • 特点：数据包含在请求体中；与 PUT 不同，PATCH 只更新资源的部分内容。
    • 幂等性：不一定，视具体实现而定。
    • 安全性：否。
    • 示例：部分更新资源。
    • 示例代码： 
      curl -X PATCH -d '{"name":"new value"}' http://example.com/resource

幂等性和安全性

262. GET vs POST

特性GETPOST
用途获取数据发送数据
数据传输URL 参数请求体
缓存可以被缓存不会被缓存
书签可以被书签保存不能被书签保存
数据长度限制有限（取决于 URL 长度）无显著限制
幂等性是（对资源无副作用）否（可能产生副作用）
安全性是（不会改变服务器资源）否（通常用于修改资源）
数据可见性URL 中的数据对所有人可见请求体中的数据相对隐藏
使用场景查询操作，如搜索、获取数据修改操作，如表单提交、文件上传

tip: 其实参数并没有大小限制，是 URL 大小有限制，因为要保护服务器（Chrome 2M，IE 2048）

这个问题很多人都有误解，最常见的误解比如 POST 请求安全，GET参数通过 URL 传递，POST 放在请求体里等等，这些回答没有 GET 到点上，其实 GET，POST 都可以用来传输信息，GET 请求可以用 body 传输数据，在POST 请求时你可以不用不用 body 而用 url 传输数据，这都是可以实现的，这就好比你可以用救护车来运货，也可以用卡车来救人，都没有问题的，但这不符合人们的认知， 不符合 HTTP 对其定义的语义，无规矩不成方圆，遵循语义大家沟通才能更高效，所以其实它们的区别只在语义上有区别，至于安全，那是 HTTPS 的事了。

263. RESTful 规范

使用语义化的 URL 来表示资源的层级关系和操作，如 /users 表示用户资源，/user/:id 表示具体的用户，每个请求都是独立的，服务器不保存客户端的状态信息，客户端需要在请求中携带所有必要的信息。

  1. 资源: 将系统中的实体抽象为资源，每个资源都有唯一一个标识符（URL）
  2. HTTP 方法：使用 HTTP 请求方式来操作资源
  3. 状态码：使用 HTTP 状态码来表示请求的结果
  4. 无状态：每个请求都是独立的，服务器不保存客户端的状态信息，客户端需要在请求中携带所有必要的信息

264. 浏览器缓存（强缓存/协商缓存）

若缓存生效，强缓存返回 200，协商缓存返沪 304

详见 HTTP 缓存机制

265. Cache-Control 的取值

Cache-Control 是 HTTP/1.1 中定义的用于指定缓存指令的头字段，可以用来控制缓存策略，决定资源如何被缓存、存储的时间长度以及缓存的权限

  1. max-age=seconds

    • 定义：指定资源在客户端缓存的最大时间（以秒为单位）。
    • 示例：Cache-Control: max-age=3600（表示资源在客户端缓存1小时）

  2. no-cache

    • 定义：强制缓存机制在使用已缓存的副本前，向原服务器进行验证。
    • 示例：Cache-Control: no-cache

  3. no-store

    • 定义：不允许缓存，任何情况下都不应缓存响应或请求的内容。
    • 示例：Cache-Control: no-store

  4. public

    • 定义：表示响应可以被任何缓存，包括CDN等中间缓存服务器缓存。
    • 示例：Cache-Control: public

  5. private

    • 定义：表示响应只能被单个用户缓存，不能被共享缓存（如CDN）缓存。
    • 示例：Cache-Control: private

  6. must-revalidate

    • 定义：要求缓存必须在过期后重新验证，而不能使用过期的缓存。
    • 示例：Cache-Control: must-revalidate

  7. proxy-revalidate

    • 定义：与 must-revalidate 类似，但该指令适用于所有缓存，包括中间代理缓存。
    • 示例：Cache-Control: proxy-revalidate

  8. s-maxage=seconds

    • 定义：与 max-age 类似，但只适用于共享缓存（如代理服务器缓存），忽略 max-age 和 Expires 头字段。
    • 示例：Cache-Control: s-maxage=3600

  9. immutable

    • 定义：表示资源是不可变的，一旦缓存，不会改变，因此在 max-age 期内不需要重新验证。
    • 示例：Cache-Control: immutable

  10. stale-while-revalidate=seconds

    • 定义：允许客户端在资源过期后仍然使用旧的缓存，同时在后台重新验证。
    • 示例：Cache-Control: stale-while-revalidate=60

  11. stale-if-error=seconds

    • 定义：在资源过期且服务器不可用时，允许客户端使用过期的缓存。
    • 示例：Cache-Control: stale-if-error=86400

组合使用

多个 Cache-Control 指令可以组合使用，以实现更复杂的缓存策略。例如：

示例

  1. 静态资源缓存（如图片、CSS、JavaScript）：

    Cache-Control: public, max-age=31536000, immutable

  2. 敏感数据缓存（如用户个人信息）：

    Cache-Control: private, no-store

  3. 动态内容缓存（需要频繁更新）：

    Cache-Control: no-cache, must-revalidate

266. 常见的 HTTP 状态码及其意义 (应用层)

1xx - 信息响应（Informational Responses）

  1. 100 Continue：表示到目前为止一切正常，客户端应继续请求。
  2. 101 Switching Protocols：服务器同意客户端的协议切换请求。

2xx - 成功（Success）

  1. 200 OK：请求成功，服务器返回请求的数据。
  2. 201 Created：请求成功且资源已被创建。通常用于 POST 或 PUT 请求。
  3. 202 Accepted：请求已接收，但尚未处理。
  4. 204 No Content：请求成功但没有内容返回。通常用于 DELETE 请求。

3xx - 重定向（Redirection）

  1. 301 Moved Permanently：请求的资源已被永久移动到新位置。响应中会包含新的 URL。
  2. 302 Found（或 Moved Temporarily）：请求的资源暂时被移动到新位置。响应中会包含新的 URL。
  3. 304 Not Modified：资源未被修改，客户端可以使用缓存的版本。

4xx - 客户端错误（Client Errors）

  1. 400 Bad Request：服务器无法理解请求的格式，客户端应修改请求后重试。
  2. 401 Unauthorized：请求未授权，需要进行身份验证。
  3. 403 Forbidden：服务器理解请求但拒绝执行。
  4. 404 Not Found：请求的资源不存在。
  5. 405 Method Not Allowed：请求方法不被服务器允许。
  6. 408 Request Timeout：服务器等待客户端发送请求超时。
  7. 409 Conflict：请求与资源的当前状态发生冲突。
  8. 410 Gone：请求的资源已永久删除，不再可用。

5xx - 服务器错误（Server Errors）

  1. 500 Internal Server Error：服务器内部错误，无法完成请求。
  2. 501 Not Implemented：服务器不支持请求的功能。
  3. 502 Bad Gateway：服务器作为网关或代理，从上游服务器收到无效响应。
  4. 503 Service Unavailable：服务器暂时不可用，通常是由于维护或过载。
  5. 504 Gateway Timeout：服务器作为网关或代理，未能及时从上游服务器接收响应。

扩展状态码

某些状态码不是在 HTTP/1.0 或 HTTP/1.1 标准中定义的，而是由扩展规范或应用程序引入的。例如：

  1. 418 I’m a teapot：一个愚人节玩笑的状态码，源自 1998 年的 RFC 2324（Hyper Text Coffee Pot Control Protocol）。
  2. 429 Too Many Requests：客户端在给定的时间内发送了太多请求。通常用于速率限制策略。

状态码分类总结

267. 网络状态 301 vs 302 vs 303（应用层）

301 Moved Permanently

定义：301 状态码表示请求的资源已被永久移动到新的 URI。未来的所有请求应使用新的 URI。

特性：

使用场景：

示例：

HTTP/1.1 301 Moved Permanently
Location: https://www.newdomain.com/newpage

302 Found (Temporary Redirect)

定义：302 状态码表示请求的资源临时被移动到新的 URI。客户端应继续使用原有 URI 进行未来的请求。

特性：

使用场景：

示例：

HTTP/1.1 302 Found
Location: https://www.example.com/temporarypage

303 See Other

定义：303 状态码表示请求的资源已被移动到另一个 URI，客户端应使用 GET 方法请求新的 URI。

特性：

使用场景：

示例：

HTTP/1.1 303 See Other
Location: https://www.example.com/confirmationpage

区别总结

状态码定义持久性请求方法处理
301Moved Permanently持久保持不变
302Found (Temporary Redirect)临时通常保持不变，但可能依赖浏览器
303See Other临时转换为 GET

268. 400 vs 401 vs 403 (应用层)

HTTP 状态码 400、401 和 403 都表示客户端错误，但它们各自有不同的含义和使用场景。以下是每个状态码的详细解释及其区别：

400 Bad Request

定义：400 状态码表示服务器无法处理客户端发送的请求，因为请求有语法错误或参数错误。

特性：

使用场景：

示例：

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "Invalid request format"
}

401 Unauthorized

定义：401 状态码表示请求需要用户认证，但客户端未提供有效的身份验证凭据。

特性：

使用场景：

示例：

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Access to the site"

Content-Type: application/json

{
  "error": "Authentication required"
}

403 Forbidden

定义：403 状态码表示服务器理解请求，但拒绝执行。

特性：

使用场景：

示例：

HTTP/1.1 403 Forbidden
Content-Type: application/json

{
  "error": "Access to this resource is forbidden"
}

区别总结

状态码定义含义使用场景
400Bad Request请求有语法错误或参数错误请求格式错误、参数无效、客户端提交的 JSON 格式错误等
401Unauthorized请求需要用户认证，但未提供有效凭据用户未登录、认证信息无效或过期、需要登录才能访问的资源
403Forbidden请求已被服务器理解，但拒绝执行用户已登录但没有权限访问特定资源、资源被禁止访问

269. HTTP vs HTTPS (应用层)

  1. 安全性：

    • HTTP：数据是明文传输的，容易被中间人攻击和窃取。
    • HTTPS：数据是加密传输的，可以有效防止数据被窃取和篡改。

  2. 端口：

    • HTTP：默认使用端口 80。
    • HTTPS：默认使用端口 443。

  3. 证书：

    • HTTP：不需要 SSL/TLS 证书。
    • HTTPS：需要由可信的证书颁发机构 (CA) 颁发的 SSL/TLS 证书。

  4. 性能：

    • HTTP：性能较高，因为没有加密和解密的开销。
    • HTTPS：略有性能开销，但现代硬件和优化后的加密算法使得性能影响很小。

  5. SEO 优势：

    • HTTPS：搜索引擎（如 Google）更倾向于优先索引 HTTPS 网站，有助于提升 SEO 排名。

选择使用 HTTPS 的理由

  1. 安全性：保护用户的隐私和敏感信息，如登录凭据、支付信息等。
  2. 数据完整性：防止数据在传输过程中被篡改。
  3. 用户信任：浏览器会标识 HTTPS 网站为安全网站，提高用户的信任度。
  4. SEO 优势：搜索引擎更倾向于优先索引 HTTPS 网站，有助于提升网站排名。
  5. 符合标准：现代 Web 标准和浏览器政策越来越倾向于强制使用 HTTPS，某些浏览器甚至会对 HTTP 网站显示不安全警告。

270. 描述下 HTTPS 的加密过程

详见 Https 加密通信过程

定义： Cookie 是一种存储在浏览器中的小文件，用户存储网站的一些信息。通过 Cookie，服务器可以识别用户并保持会话状态，实现会话保持。

解决问题： Cookie 诞生的主要目的是为了解决 HTTP 协议的无状态性问题。HTTP 协议是一种无状态的协议，即服务器无法识别不同的用户或跟踪用户的状态

Cookie 和 Session 都是用于在用户与服务器之间传递数据的技术，但它们有一些显著的区别和不同的用途。

  1. 存储位置：Cookie 存储在客户端（即用户的浏览器）中。
  2. 生命周期：Cookie 可以具有长久的生命周期，甚至可以在浏览器关闭后依然存在（具体取决于 Cookie 的过期时间）。
  3. 数据量限制：每个 Cookie 通常只能存储约 4KB 的数据。
  4. 访问权限：Cookie 可以被客户端脚本（如 JavaScript）读取和修改。
  5. 安全性：Cookie 存储在客户端，因此更容易受到攻击（如 XSS 攻击）。

Session

  1. 存储位置：Session 数据存储在服务器上，客户端只存储一个 Session ID 用于标识会话。
  2. 生命周期：Session 通常在用户关闭浏览器或会话超时（服务器设置的超时时间）后失效。
  3. 数据量限制：Session 存储在服务器上，理论上可以存储更多的数据，具体限制取决于服务器的配置。
  4. 访问权限：Session 数据只能在服务器端访问，客户端无法直接读取或修改。
  5. 安全性：由于 Session 数据存储在服务器上，相对更安全，不容易受到客户端攻击。

用途

总结来说，Cookie 更适合需要在客户端长期存储的数据，而 Session 更适合需要临时存储且涉及敏感数据的场景。

273. TCP（传输控制协议）vs UDP（用户数据报协议）（传输层）

TCP（传输控制协议）和UDP（用户数据报协议）是两种用于传输数据的网络协议，它们在不同的方面有显著的区别。

TCP（传输控制协议）（传输层）

  1. 连接导向：TCP是面向连接的协议，在传输数据前需要建立一个连接（即三次握手）。
  2. 可靠性：TCP提供可靠的数据传输。它通过确认（ACK）、重传丢失的包、以及校验和等机制确保数据的准确性和完整性。
  3. 流量控制：TCP具有流量控制功能，通过滑动窗口机制，确保发送方不会超出接收方的处理能力。
  4. 拥塞控制：TCP有拥塞控制机制，以防止网络过载。
  5. 数据顺序：TCP保证数据包按顺序到达接收方，即使数据包乱序到达，也会重新排序。
  6. 开销：由于TCP需要维护连接状态、进行数据确认和重传，导致其头部开销较大（20字节）。

UDP（用户数据报协议）

  1. 无连接：UDP是无连接的协议，不需要建立连接即可发送数据。
  2. 不可靠传输：UDP不提供可靠性保障，不确认数据包是否成功接收，也不重传丢失的数据包。
  3. 无流量控制：UDP没有流量控制机制，因此不会调节发送速率。
  4. 无拥塞控制：UDP也没有拥塞控制机制，可能导致网络拥塞。
  5. 数据顺序：UDP不保证数据包的顺序到达，数据包可能会乱序到达接收方。
  6. 开销小：由于UDP没有复杂的连接管理和可靠性保障，其头部开销较小（8字节）。

应用场景

总结来说，TCP适用于需要高可靠性和数据顺序的场景，而UDP则适用于需要快速传输和低延迟的场景。

274. TCP 三次握手

275. 如果 TCP 变成二次握手会导致的问题

276. TCP 四次挥手

277. 描述一下 TCP 的拥塞控制

278. 什么是跨域，如何解决

279. 同源策略具体限制的具体内容

280. 发起请求是浏览器做了什么

281. XSS 攻击

282. SQL 注入

283. DDoS 攻击

284. CSRF 攻击

285. Ajax 的定义及其优缺点

286. XMLHttpRequest 对象用法

287. 封装一个 Ajax 请求方法

288. Fetch API

289. fetch vs XMLHttpRequest

290. 请求会发 2 次的原因

291. WebSocket

292. WebSocket 建立连接的过程

293. WebSocket 支持传输的数据格式

294. Server-Sent Events（SSE）

295. Server-Sent Events（SSE）示例代码

296. SSE vs WebSocket

297.http2.0