计算机网络常见八股文
计算机网络常见八股文
常见的 HTTP 状态码有哪些?
常见的 HTTP 状态码包括:
1xx (信息性状态码)
- 100 Continue:继续请求,客户端应继续发送请求的其余部分。
- 101 Switching Protocols:服务器根据客户端请求切换协议。
2xx (成功状态码)
- 200 OK:请求成功,返回请求的数据。
- 201 Created:请求成功并且创建了新的资源。
- 204 No Content:请求成功,但没有返回内容。
3xx (重定向状态码)
- 301 Moved Permanently:资源已被永久移动到新位置,客户端应使用新的 URL。
- 302 Found:资源临时被移动,客户端应继续使用原 URL。
- 304 Not Modified:资源未被修改,可以使用缓存的版本。
4xx (客户端错误状态码)
- 400 Bad Request:请求格式错误,服务器无法理解。
- 401 Unauthorized:未授权,客户端需要提供身份验证。
- 403 Forbidden:禁止访问,服务器理解请求但拒绝执行。
- 404 Not Found:请求的资源未找到。
5xx (服务器错误状态码)
- 500 Internal Server Error:服务器内部错误,无法完成请求。
- 502 Bad Gateway:作为网关或代理的服务器从上游服务器接收到无效响应。
- 503 Service Unavailable:服务不可用,服务器暂时无法处理请求,通常是由于过载或维护。
- 504 Gateway Timeout:作为网关或代理的服务器未能在规定的时间内从上游服务器获取响应。
HTTP 请求包含哪些内容,请求头和请求体有哪些类型?
一个 HTTP 请求通常包括以下几个部分:
请求行 : 请求方法 (如 GET、POST、PUT、DELETE 等)、请求目标 URI (如 /api/products)、HTTP 协议版本 (如 HTTP/1.1)
请求头 : 提供额外的信息,用于描述请求的属性,比如客户端信息、数据格式、认证信息等。
空行: 用于分隔请求头和请求体。
请求体 : 包含实际传递的数据(仅在方法如 POST、PUT 等需要时存在)。
请求头类型
通用请求头: 适用于请求和响应,如Cache-Control、Connection.
请求头部: 特定于请求的头部,如Host、User-Agent、Accept、Authorization
实体头部: 描述请求体的头部,如Content-Type、Content-Length
请求体类型:
表单数据(form): application/x-www-form-urlencoded,用于提交表单数据
多部分数据:(Multipart) multipart/form-data,用于上传文件或复杂表单数据
JSON数据 :application/json,用于提交JSON格式的数据
XML数据: application/xml,用于提交XML格式的数据
文本数据: :text/plain,用于提交纯文本数据
HTTP 中 GET 和 POST 的区别是什么?
| 特性 | GET | POST |
|---|---|---|
| 用途 | 获取数据 | 提交数据 |
| 参数传递方式 | URL 查询字符串 | 请求体 |
| 是否安全 | 参数暴露,安全性低 | 参数在请求体中,安全性更高 |
| 数据长度限制 | 有限制 | 无限制(受服务器配置限制) |
| 幂等性 | 幂等 | 非幂等 |
| 可缓存性 | 默认可缓存 | 默认不可缓存 |
| 性能 | 请求体积小,速度快 | 请求体积较大,稍慢 |
HTTP 1.0 和 2.0 有什么区别?
HTTP 1.0 的特点:
- 新增了方法:引入了
HEAD和POST方法,丰富了 HTTP 的请求能力。 - 增加了响应状态码:提供更多状态码来标识请求结果。
- 引入头部:允许请求和响应包含头部,便于传递额外的元信息。
- 引入了 Content-Type:支持多样的传输数据类型,不局限于文本。
HTTP 2.0 的特点:
- 二进制传输:与 HTTP 1.0 的纯文本传输不同,HTTP 2.0 使用二进制格式,更高效和可靠。
- 多路复用:支持在同一个连接中并发处理多个请求,而 HTTP 1.0 每次只能处理一个请求。
- 移除 pipeline:HTTP 1.0 中的 pipeline 特性被取代,更高效地解决了阻塞问题。
- 压缩头部:利用 HPACK 算法对头部进行压缩,减少传输数据量,提高传输效率。
- 服务端推送:HTTP 2.0 支持服务端主动向客户端推送数据,而 HTTP 1.0 不支持。
Pipeline:
Pipeline(管道化) 是 HTTP/1.1 中引入的一种优化技术,客户端可以在收到服务端响应之前,连续发送多个请求,而不需要等待前一个请求完成.
局限性:如果一个请求的处理时间较长,会阻塞后续请求的响应。即使后续请求已被处理,响应也不能返回,因为需要按顺序返回结果。
许多服务器和代理不完全支持管道化,可能导致不稳定的行为。
HTTP/2 移除了 Pipeline,取而代之的是更高级的 多路复用(Multiplexing) 技术。多路复用允许在同一个连接中并行处理多个请求和响应,且响应可以乱序返回,从而完全解决了 Pipeline 的队头阻塞问题。
HTTP 2.0 和 3.0 有什么区别?
| 特性 | HTTP/2 | HTTP/3 |
|---|---|---|
| 传输协议 | TCP(可实现多路复用) | QUIC (基于 UDP) |
| 性能和可靠性 | 仍受制于TCP队头阻塞 | 通过QUIC避免了队头阻塞,性能更好 |
| 安全性 | 使用TLS加密(Https)非强制 | QUIC自带TLS1.3加密,安全性更高,且强制 |
| 连接建立速度 | 需要TCP三次握手和TLS握手,速度较慢 | QUIC集成了连接建立。速度快 |
HTTP 和 HTTPS 有什么区别?
| HTTP | HTTPS | |
|---|---|---|
| 数据传输安全性 | 明文传输,容易被窃听篡改 | SSL/TLS协议加密传输,安全性有保障 |
| 端口号 | 80 | 443 |
| 性能 | 无加密过程,建立速度快 | SSL/TLS实现加密传输,加解密过程增加了开销,时间较长 |
| SEO影响 | 搜索引擎般会降低未加密站点排名 | 搜索引擎优先展示HTTPS网站 |
TCP 和 UDP 有什么区别?
TCP 主要提供了可靠、面向连接的传输,适合需要数据完整性和顺序的场景
UDP 主要提供了更轻量、面向报文的传输,适合对实时性要求高的场景
| 特性 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接(三次握手) | 无连接 |
| 是否可靠 | 可靠传输(确认、重传机制) | 不可靠传输 |
| 流量和拥塞控制 | 有 | 无 |
| 头部开销 | 大(20 字节) | 小(8 字节) |
| 速度 | 较慢 | 较快 |
| 传输方式 | 面向字节流 | 面向报文 |
| 应用场景 | 需要可靠性(文件、网页) | 实时性高(视频、游戏) |
说说 TCP 的三次握手?
TCP 的三次握手是建立可靠连接的过程,用于确保通信双方的发送和接收能力正常工作。
第一步:客户端发送 SYN:向服务器发送一个 SYN 标志位为 1 的报文,表示请求建立连接,同时指定一个初始序列号 seq=x。客户端进入 SYN_SENT 状态,等待服务器的响应。
第二步:服务器发送 SYN + ACK 服务器收到客户端的 SYN 请求后,发送一个 SYN 和 ACK 标志位都为 1 的报文,表示同意连接请求:
SYN表示服务器愿意建立连接。ACK确认收到客户端的SYN,ack=x+1(确认号为客户端的序列号加 1)。同时,服务器设置自己的初始序列号
seq=y。服务器进入 SYN_RCVD 状态。
第三步:客户端发送 ACK :客户端收到服务器的 SYN+ACK 后,发送一个 ACK 标志位为 1 的报文,确认收到服务器的 SYN
ack=y+1(确认号为服务器的序列号加 1)。客户端的序列号为
seq=x+1。客户端进入 ESTABLISHED 状态(连接建立)。
服务器收到 ACK 后也进入 ESTABLISHED 状态。
TCP 是用来解决什么问题?
数据可靠传输问题:通过确认机制(ACK)、重传机制以及序列号,确保数据在网络传输过程中不丢失、不重复、按顺序到达。
流量控制问题:通过滑动窗口机制调节发送方的数据发送速率,防止接收方因处理能力有限而被数据流淹没。
拥塞控制问题:通过拥塞避免算法(如慢启动、拥塞避免、快速重传和快速恢复)来防止网络过载,确保网络资源的公平使用和稳定性。
连接管理问题:作为面向连接的协议,TCP通过三次握手(建立连接)和四次挥手(断开连接)机制管理会话,确保通信的可靠性和状态同步。
说说 TCP 的四次挥手?
- 第一次挥手 (FIN → ACK)
- 客户端主动关闭连接,发送一个 FIN 报文。
- 客户端进入 FIN_WAIT_1 状态。
- 服务端收到 FIN 报文后,表示它不会再接收新的数据,但可能仍然会发送剩余的数据。
- 第二次挥手 (ACK)
- 服务端向客户端发送一个 ACK 报文,确认已收到客户端的 FIN。
- 服务端进入 CLOSE_WAIT 状态。
- 客户端收到这个 ACK 后,进入 FIN_WAIT_2 状态,等待服务端发送 FIN。
- 第三次挥手 (FIN → ACK)
- 服务端在完成数据传输后,发送一个 FIN 报文,表明它也准备关闭连接。
- 服务端进入 LAST_ACK 状态。
- 客户端收到服务端的 FIN 报文后,表示服务端已不再需要连接。
- 第四次挥手 (ACK)
- 客户端发送一个最后的 ACK 报文,确认收到服务端的 FIN。
- 客户端进入 TIME_WAIT 状态,等待一段时间(通常是 2MSL,即报文最大寿命的两倍)以确保服务端收到 ACK 并关闭连接。
- 如果没有问题,客户端正式关闭连接,进入 CLOSED 状态。
TCP 的粘包和拆包能说说吗?
粘包: 多个小数据包被“粘”到了一起,接收方一次性收到了一大坨数据,导致搞不清哪里是一个消息的结束,哪里是下一个消息的开始。就好比你在传递消息时,把几句话连在一起发了,接收方读到后搞不清哪句是哪句。
拆包: 一个大数据包被拆成了几块,接收方收到时分成了好几部分,导致消息变成了零散的碎片。这就像你发了一大段话,结果对方一次只能收到几句话,得把这些碎片拼起来才能完整读懂。
如何解决?
- 定长消息:每条消息固定长度,接收方每次读取固定字节长度的数据。比如,每条消息都是 20 个字节,不多不少,接收方知道该怎么拆分。
- 添加分隔符:在每条消息末尾加个特殊符号(比如
\n或#),接收方通过这个标记判断消息边界。类似于一段文字后加上句号,这样看句号就知道一段话结束了。 - 消息头标注长度:消息开头说明消息的总长度,接收方先读取长度,然后再按这个长度读取完整消息。好比发快递时,先告诉对方包裹有多重,对方就知道要一次性拿多少东西。
说说 TCP 拥塞控制的步骤?
- 慢启动 :刚上高速,小心翼翼慢慢加速。
- 开始时,TCP 不知道网络的承受能力(类似不知道路况),所以它从 慢速 开始,每次成功发送就逐渐加快速度。
- 一开始,发送的速度(称为拥塞窗口,CWND)从小值开始,每次发送成功翻倍增长。
- 直到发现网络开始拥堵(收到丢包信号)或者达到一个阈值(ssthresh,类似“路面限速”),才停止慢启动。
- 拥塞避免 :车速接近限速,开始稳稳地开,不敢加速太快了。
- 进入这个阶段后,TCP 的发送速度会缓慢增加(线性增长,而不是翻倍),以免造成拥塞。
- 就像在快车道上,车流已经较多了,你只能一点一点地踩油门试探。
- 快速重传 :前方有车突然刹车,你赶紧减速,并立即调整。
- 如果发送数据时,发现某个包丢失了(通过收到 3 次重复的 ACK 确认丢包),TCP 会认为网络出现了轻微拥塞。
- 它会快速重传丢失的数据包,而不等待超时。
- 此时,车速会稍微降下来(将拥塞窗口减小到一半)。
- 快速恢复 :调整好车速后,慢慢重新提速。
- 在快速重传后,TCP 不会回到慢启动的状态,而是从当前车速(拥塞窗口的一半)继续小心地加速。
- 就像在高速路上,遇到点小堵车后,不会直接回到慢车道,而是稳稳地恢复速度。
TCP/IP 四层模型是什么?
TCP/IP四层模型是计算机网络分层通讯的参考模型,由上到下分别是应用层、传输层、网络层和链路层。
应用层: 通过各种协议为应用程序提供网络服务,协议有HTTP、HTTPS、FTP、SMTP、DNS、Tlenet等。
传输层: 负责在两个主机之间提供端到端的通信服务,常见协议有UDP和TCP
网络层: 负责IP地址的管理和数据包的路由选择和转发,常见协议有IP、ICMP、ARP
链路层: 负责在计算机和网络硬件之间传输数据,负责在物理网络上发生和接收数据帧,协议有以太网协议、Wi-Fi等
Cookie、Session、Token 之间有什么区别?
Cookie:存储在客户端(浏览器),用于在无状态的 HTTP 协议中保存用户信息,通常用于会话管理或跨页面状态保持。
Session:存储在服务器端,通过唯一的 Session ID(通常存储在 Cookie 中)与客户端关联,适合存储敏感数据且对安全性要求更高。
Token:基于身份验证的凭证(例如 JWT),存储在客户端,服务器通过解密或验证 Token 的签名来确认用户身份,通常用于无状态的分布式系统或 API 授权。
总结:Cookie 和 Session 更适合传统网站的单次会话的认证和状态管理,Token 更适用于分布式架构和跨域场景。
从网络角度来看,用户从输入网址到网页显示,期间发生了什么?
浏览器解析 URL :浏览器解析用户输入的 URL,并根据请求信息生成对应的 HTTP 请求报文。
DNS 解析: 浏览器检查本地缓存、操作系统缓存或路由器缓存,尝试找到与域名对应的 IP 地址。如果未找到,浏览器会向配置的 DNS 服务器发起查询请求,DNS 服务器通过查询层级返回域名对应的 IP 地址。
TCP 或 UDP 连接建立 : 浏览器通过 Socket 调用建立 TCP 连接(通常是 TCP)。如果使用的是 HTTP 协议,需要通过三次握手建立与服务器的连接。此时,HTTP 请求报文会被封装到 TCP 数据包中。
IP : 在 TCP 数据包的基础上,加上源 IP 地址和目标 IP 地址等信息,形成 IP 数据包。IP 协议负责在多网络节点中确定数据包的传输路径,最终到达目标服务器。
MAC : 为了完成数据链路层的传输,在 IP 数据包的基础上加入源 MAC 地址和目标 MAC 地址。MAC 地址用于确定局域网中设备之间的通信。
网卡: 数据通过网卡从主机中传输出来,将二进制数据转换为电信号,通过物理网络线路传输。
交换机: 数据到达局域网的交换机后,交换机根据目标 MAC 地址查找转发表,确定将数据发送到目标设备的端口。
路由器: 如果目标服务器不在同一局域网内,数据会通过路由器,按 IP 地址转发到目标网络,最终到达目标服务器。
服务器响应: 服务器接收到请求后,根据 URL 解析请求,处理业务逻辑,并生成 HTTP 响应报文,将网页内容返回给浏览器。
浏览器渲染: 浏览器接收到服务器返回的 HTML、CSS、JavaScript 等内容后,开始渲染页面,将网页呈现给用户。


