【面试】计算机网络
计算机网络
- 1、说说 HTTP 常用的状态码及其含义
- 2、HTTP 常用的请求方式，区别和用途
- 3、GET 请求和 POST 请求区别
- 4、HTTP 的长链接和短链接区别
- 5、HTTP 和 HTTPS 的区别
- 6、Cookie 和 Session 的区别
- 7、TCP 和 UDP 的区别
- 8、TCP 的三次握手
- 9、为什么是三次握手
- 10、TCP 的四次挥手
1、说说 HTTP 常用的状态码及其含义
| 状态码 | 类别 |
|---|---|
| 1xx | 信息性状态码 |
| 2xx | 成功状态码 |
| 3xx | 重定向状态码 |
| 4xx | 客户端状态码 |
| 5xx | 服务端状态码 |
日常开发中这几个状态码
| 状态码 | 含义 |
|---|---|
| 101 | 切换请求协议 |
| 200 | 请求成功 |
| 301 | 永久重定向，会缓存 |
| 302 | 临时重定向，不会缓存 |
| 400 | 客户端请求语法错误 |
| 403 | 服务器禁止访问，权限有关 |
| 404 | 服务器无法根据客户端的请求找到资源 |
| 500 | 服务端错误 |
2、HTTP 常用的请求方式，区别和用途
| 请求方式 | 用途 |
|---|---|
| GET | 对服务器资源获取的简单请求 |
| POST | 用于发送包含用户提交数据的请求 |
| PUT | 向服务器提交数据，以修改数据 |
| HEAD | 请求页面的首部，获取资源的元信息 |
| DELETE | 删除服务器上的某些资源 |
| CONNECT | 用于ssl隧道的基于代理的请求 |
| OPTIONS | 返回所有可用的方法，常用于跨域 |
| TRACE | 追踪请求-响应的传输路径 |
3、GET 请求和 POST 请求区别
- 请求体
GET没有请求体，数据通过 URL 传递。POST有请求体，数据通过请求体传输。
- 安全性
GET数据暴露在 URL 中，容易被缓存、记录或泄露，不适合传输敏感信息（如密码）。POST数据在请求体中传输，相对更安全，但仍需使用 HTTPS 加密以确保安全性。
- 数据长度限制
GET由于数据附加在 URL 中，受 URL 长度限制（通常为 2048 字符）。POST数据通过请求体传输，理论上没有长度限制，但服务器可能会限制请求体大小。
4、HTTP 的长链接和短链接区别
- 短链接：简单但性能较低，适合低频请求。
- 长链接：性能更高，适合高频请求，是现代 HTTP 协议的默认行为。
5、HTTP 和 HTTPS 的区别
HTTP（超文本传输协议）和 HTTPS（超文本传输安全协议）是用于在客户端和服务器之间传输数据的协议，但它们在工作方式、安全性和性能等方面有显著区别。以下是它们的主要差异
6、Cookie 和 Session 的区别
- 存储位置
Cookie数据存储在客户端（浏览器）中。每次请求时会自动附加到 HTTP 头部，发送到服务器。Session数据存储在服务器中。客户端仅保存一个 Session ID（通常通过 Cookie 存储），用于标识会话。
- 安全性
Cookie数据存储在客户端，可能被篡改或窃取。Session数据存储在服务器，安全性较高。仅传输 Session ID，敏感数据不会暴露在客户端。
- 生命周期
Cookie可以设置过期时间（Expires 或 Max-Age）。如果未设置过期时间，则为会话 Cookie，浏览器关闭后失效。Session生命周期由服务器控制。通常在用户关闭浏览器或长时间无活动后失效（可配置超时时间）。
- 存储容量
Cookie单个 Cookie 大小限制为 4KB。每个域名下的 Cookie 数量有限（通常为 20-50 个）。Session存储容量取决于服务器配置，通常远大于 Cookie。适合存储大量数据。
- 适用场景
Cookie存储少量非敏感数据，如用户偏好、主题设置。适合需要持久化数据的场景。Session存储敏感数据，如用户登录状态、购物车信息。适合需要高安全性和临时存储的场景。
7、TCP 和 UDP 的区别
TCP（传输控制协议）和 UDP（用户数据报协议）是两种主要的传输层协议，它们在功能和应用场景上有显著区别。以下是它们的主要差异：
- 连接方式
TCP：面向连接。通信前需通过三次握手建立连接，确保双方准备好数据传输。UDP：无连接。直接发送数据，无需预先建立连接。
- 数据顺序
TCP：保证数据按发送顺序到达。UDP：不保证顺序，数据可能乱序到达。
- 速度
TCP：由于连接建立和可靠性机制，速度较慢。UDP：无连接和可靠性机制，传输速度更快。
- 头部大小
TCP：头部较大，通常20字节，包含更多控制信息。UDP：头部较小，仅8字节，信息较少
应用场景
TCP：可靠、有序，适合对数据完整性要求高的场景。UDP：快速、高效，适合对实时性要求高的场景。
TCP：适用于要求高可靠性的应用，如网页浏览、文件传输、电子邮件等。UDP：适用于实时性要求高的应用，如视频流、在线游戏、VoIP等。
8、TCP 的三次握手
TCP 的三次握手是建立连接的关键步骤，确保双方能够正常通信。以下是详细过程：
- 第一次握手（SYN）
- 客户端向服务器发送 SYN（同步）报文，包含初始序列号（ISN），表示请求建立连接。
- 客户端状态：SYN_SENT
- 第二次握手（SYN-ACK）
- 服务器收到 SYN 报文后，回复 SYN-ACK 报文，包含自己的 ISN 和对客户端 ISN 的确认。
- 服务器状态：SYN_RECEIVED
- 第三次握手（ACK）
- 客户端收到 SYN-ACK 报文后，发送 ACK（确认）报文，确认服务器的 ISN。
- 服务器状态：ESTABLISHED
- 客户端状态：ESTABLISHED
9、为什么是三次握手
- 防止旧的重复连接初始化造成混乱
在网络中，数据包可能会延迟或重复到达。如果只有两次握手，服务器无法区分当前请求是新的还是旧的重复连接请求。三次握手通过客户端的最后一次确认（ACK），确保连接是基于最新的请求建立的。
例子：
- 假设客户端发送了一个 SYN 请求，但由于网络延迟，这个请求在连接关闭后才到达服务器。
- 如果没有第三次握手，服务器可能会误认为这是一个新的连接请求，从而建立无效连接。
- 通过第三次握手，客户端可以明确告知服务器这是对最新 SYN 请求的确认，避免旧请求干扰。
- 确保双方都能发送和接收数据
三次握手确保双方都具备发送和接收数据的能力：
- 第一次握手：客户端发送 SYN，证明客户端能发送数据。
- 第二次握手：服务器回复 SYN-ACK，证明服务器能接收和发送数据。
- 第三次握手：客户端发送 ACK，证明客户端能接收数据。
如果只有两次握手，服务器无法确认客户端是否具备接收数据的能力。
- 同步双方的初始序列号（ISN）
TCP 使用序列号来保证数据的有序性和可靠性。三次握手确保双方都明确对方的初始序列号：
- 第一次握手：客户端发送自己的 ISN。
- 第二次握手：服务器确认客户端的 ISN，并发送自己的 ISN。
- 第三次握手：客户端确认服务器的 ISN。
通过三次握手，双方都确认了对方的初始序列号，为后续数据传输奠定基础。
- 避免资源浪费
如果只有两次握手，服务器在收到 SYN 后会直接进入连接状态并分配资源。但如果客户端没有响应，服务器会一直等待，导致资源浪费。三次握手通过客户端的最后一次确认，确保双方都同意建立连接，避免无效的资源分配。
两次握手：无法确认客户端的接收能力，也无法避免旧连接的干扰。四次握手：三次握手已经足够保证可靠性和同步性，增加次数只会带来不必要的开销。
10、TCP 的四次挥手
TCP 的四次挥手是关闭连接的过程，确保双方都能安全地终止通信。以下是详细步骤：
- 第一次挥手（FIN）
- 主动关闭方（通常是客户端）发送 FIN（结束）报文，表示不再发送数据。
- 主动关闭方状态：FIN_WAIT_1
- 第二次挥手（ACK）
-
被动关闭方（通常是服务器）收到 FIN 报文后，发送 ACK（确认）报文，表示已收到关闭请求。
-
被动关闭方状态：CLOSE_WAIT
-
主动关闭方状态：FIN_WAIT_2
- 第三次挥手（FIN）
-
被动关闭方完成数据发送后，发送 FIN 报文，表示准备关闭连接。
-
被动关闭方状态：LAST_ACK
- 第四次挥手（ACK）
-
主动关闭方收到 FIN 报文后，发送 ACK 报文，确认关闭请求。
-
主动关闭方状态：TIME_WAIT（等待 2MSL 后进入 CLOSED）
-
被动关闭方状态：CLOSED