计算机网络常考八股

发布日期: 2025-12-15

文章字数: 3.6k

阅读时长: 12 分

grpc和http有什么区别

RPC 是一种远程调用的架构思想，它可以通过各种协议（包括 HTTP）实现，并围绕这一思想构建了一整套高效的服务治理体系。
HTTP 是一种网络协议，它本身不关心调用模式，但基于它构建的 RESTful API 成为了一种简单、通用的实现远程调用的方式。

场景	推荐选择	理由
内部微服务	RPC (如 gRPC)	性能高、延迟低、服务治理完善，适合高并发、低延迟的内部通信。
对外提供 API	HTTP (RESTful API)	通用性强，所有客户端（浏览器、移动端、第三方）都能轻松调用，无需依赖特定框架。
多语言异构系统	gRPC 或 HTTP	gRPC 原生支持多语言，是很好的选择。如果环境复杂，无法统一 RPC 框架，则使用通用的 HTTP RESTful API。
需要浏览器直接调用	HTTP (RESTful API)	浏览器对 HTTP 有原生支持，而大多数 RPC 协议（如原生 gRPC-Web）需要额外的网关转换。

特性	RPC	HTTP
定位	一种设计模式/框架，目标是实现透明的远程调用。	一种网络通信协议，是 Web 的基础。
协议与性能	通常使用自定义的二进制协议（如 gRPC 使用的 HTTP/2 + Protobuf），报文更小，序列化/反序列化效率高，性能更优。	使用标准的 HTTP/1.1 或 HTTP/2 协议，通常携带人类可读的文本（如 JSON/XML），头部信息较大，性能相对较低。
传输层	可以直接基于 TCP，也可以基于 HTTP/2（如 gRPC）。	基于 TCP。
序列化	支持高效的二进制序列化（Protobuf,），体积小，速度快。	通常使用文本序列化（JSON, XML），可读性好，但体积大，解析慢。
耦合性与服务治理	强耦合，通常需要配套的客户端和服务端 Stub。天生集成服务治理功能，如服务发现、负载均衡、熔断降级、链路追踪等。	弱耦合，只依赖接口规范（如 Swagger/OpenAPI）。服务治理需要借助外部组件（如 API 网关、服务网格）。
适用场景	公司内部微服务之间的调用，对性能、吞吐量要求高的场景。	对外提供开放 API，需要跨语言、跨平台、对浏览器友好的场景。
开发体验	像调用本地方法一样，IDE 支持好，有代码自动生成，但需要依赖特定的 RPC 框架。	需要显式地处理 HTTP 请求和响应，更灵活，但需要手动构造 URL、解析 Body。
典型代表	gRPC	RESTful API

查看某个进程监听在哪个端口有哪些命令

proc
查看进程打开的文件描述符（包括网络连接）
ls -l /proc/<PID>/fd/ | grep socket
查看进程详细信息
cat /proc/<PID>/net/tcp
cat /proc/<PID>/net/udp
lsof

# 查看所有监听端口
lsof -i -P -n | grep LISTEN
# 查看特定进程的端口（通过进程名）
lsof -i -P -n | grep <进程名>

# 查看所有监听端口及进程
ss -tlnp
# 查找特定进程的监听端口
ss -tlnp | grep nginx

netstat

# 查看所有监听端口及对应进程
netstat -tlnp
# 查找特定进程的监听端口（例如查找nginx）
netstat -tlnp | grep nginx

ping命令基于哪个网络控制协议，及其实现原理

Ping 是基于 ICMP 协议的回显请求（Echo Request）和回显应答（Echo Reply），用来测试主机之间是否可达。
发送端构造一个 ICMP Echo Request 报文，带上一个序列号和时间戳。接收端收到后，返回一个 ICMP Echo Reply。如果超时没收到回复，就认为不可达。通过 RTT（往返时间）估算延迟。

Ping 不通不一定代表网络断了，可能是目标主机禁用了 ICMP，或者中间防火墙丢弃了 ICMP 包。

traceroute的原理

Traceroute 利用 IP 包的 TTL 字段，逐跳触发 ICMP 超时消息，从而画出整条路径。发送 UDP 或 ICMP 报文，初始 TTL=1。每经过一个路由器，TTL 减 1，TTL=0 时路由器丢弃包，并返回 ICMP Time Exceeded。源地址就是当前跳的路由器 IP。逐步增加 TTL（2、3、4…），直到收到目标主机的 ICMP Port Unreachable（UDP）或 Echo Reply（ICMP）。

457层模型

物理层：0，1编码转换为电信号，这⼀层的数据叫做bit.

数据链路层：通过ARP协议将路由器算出的IP地址转化为MAC地址，交换机，传输单位是帧。会封装帧头和尾。（Wi-Fi 在这里不处理路由功能，它只是将数据帧在本地网络（如你的手机和路由器之间）传输。路由器的“Wi-Fi 功能”本质上是数据链路层和物理层的实现，而路由器的“路由功能”才是网络层的任务。）

网络层：子网和子网之间的路由通过IP协议完成。会加上IP报文头部，需要的话会再次分片。路由器，毕竟这一层负责数据的路由和转发。

传输层：提供端到端的数据传输服务。有TCP协议和UDP协议，TCP 相比UDP 多了很多特性，比如流量控制、超时重传、拥塞控制等，这些都是为了保证数据包能可靠地传输给对方。

会话层：SSL/TLS安全传输协议（http的s），RPC也在这一层啊~

表示层

应用层：HTTP、FTP这些是常见的TCP协议；DHPC也是这一层基于UDP的；同时使用的是DNS.

null

https与http的区别，多了哪些步骤

HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议（会话层吧），使得报文能够加密传输。
HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输。
两者的默认端口不一样，HTTP默认端口号是80，HTTPS默认端口号是443。
HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

从输入URL到页面展示发生了什么

解析URL，确定web服务器名和文件名，生成HTTP请求。
查询服务器域名对应IP；通过域名系统（DNS）将域名解析为 IP 地址；不过会先检查应用程序或系统DNS缓存（如systemd-resolved、nscd等服务的缓存）；接着查询本地静态主机表文件 /etc/hosts；最后都没有才去DNS发起递归查询。
通过DNS获取到IP后，应用程序（浏览器）通过调用Socket库，就可以把HTTP的传输工作交给操作系统中的协议栈。TCP和UDP协议。
在HTTP报文加上TCP报文、加上IP报文、加上帧、按照7层模型发走了。
服务器接收到请求后，根据请求的内容和路径，处理请求并返回响应。服务器可能从数据库中获取数据，⽣成动态内容，然后将响应发送回浏览器。
浏览器接收到服务器的响应，响应包含了 HTTP 状态码、头部信息和页面内容等。
解析和渲染。页面的所有内容和资源加载完成后，浏览器显示完整的页面。

三次握手

在客户端和服务器准备开始通信之前，为了确认双方的发送和接收能力都正常，并同步初始序列号而进行的三次报文交换过程。

这个过程涉及两个角色：客户端（主动发起连接）和服务器（被动监听，等待连接）。
握手过程中会交换几种 TCP 标志位：

SYN：Synchronize Sequence Numbers，同步序列号，用于发起连接。
ACK：Acknowledgment，确认，表示收到了对方的报文。

第一步：客户端发送 SYN 报文（第一次握手）

动作：客户端向服务器发送一个 TCP 报文。
内容：
- 标志位 SYN 设置为 1。
- 同时会选择一个初始序列号 seq = x（是一个随机数）。
- 此时不携带应用数据。
含义：客户端对服务器说：“你好，我想和你建立连接。我的初始序列号是 x。”
状态变化：客户端进入 SYN_SENT 状态。

第二步：服务器回复 SYN-ACK 报文（第二次握手）

动作：服务器收到客户端的 SYN 报文后，如果同意连接，则回复一个报文。
内容：
- 标志位 SYN 和 ACK 都设置为 1。
- 确认号 ack = x + 1（表示“我收到了你的序列号 x，我期待你下次发送 x+1 的数据”）。
- 服务器也选择一个自己的初始序列号 seq = y。
含义：服务器对客户端说：“收到你的连接请求了（ACK），我同意连接。我的初始序列号是 y（SYN）。”
状态变化：服务器进入 SYN_RCVD 状态。

第三步：客户端发送 ACK 报文（第三次握手）

动作：客户端收到服务器的 SYN-ACK 报文后，会再向服务器发送一个确认报文。
内容：
- 标志位 ACK 设置为 1。
- 确认号 ack = y + 1（表示“我收到了你的序列号 y，我期待你下次发送 y+1 的数据”）。
- 自己的序列号 seq = x + 1（因为第一次握手的 SYN 包消耗了一个序列号）。
- 这次报文可以携带应用数据了。
含义：客户端对服务器说：“好的，确认收到你的回复了。我们可以开始传数据了。”
状态变化：
- 客户端进入 ESTABLISHED（连接已建立）状态。
- 服务器收到这个 ACK 后，也进入 ESTABLISHED 状态。

至此，三次握手完成，一个可靠的 TCP 连接就建立起来了，双方可以开始全双工的数据传输。

null

为什么需要三次握手？

主要为了解决三个核心问题：

确认双方的收发能力：两次握手只能确认客户端的发送能力、服务器的接收和发送能力是正常的，但无法确认客户端的接收能力是否正常。第三次握手就是为了让服务器知道客户端的接收能力没问题。
同步序列号：TCP 协议是可靠的，它依靠序列号来保证数据包的有序和不丢。三次握手是双方交换初始序列号的关键步骤。
防止已失效的连接请求报文突然又传到了服务器：网络延迟可能会让一个很早以前发出的连接请求（已经失效）突然到达服务器。如果没有第三次握手，服务器会直接建立连接并等待数据，造成资源浪费。

泛洪攻击

攻击者伪造大量的 IP 地址，向服务器发送大量的 SYN 请求报文，但并不发送对应的 ACK 响应报文。服务器在收到 SYN 请求后，会为每个请求分配一定的资源，如内存和 CPU 时间，并进入 SYN-RECV 状态等待客户端的 ACK 响应。由于伪造的 IP 地址几乎不可能存在，服务器无法收到 ACK 响应，但会一直维护这个半连接等待列表，并不断对列表中的 IP 地址进行遍历和重试，最终导致服务器资源耗尽。

IO复用

特性	select	poll	epoll
操作方式	遍历	遍历	回调
底层实现	数组	链表	红黑树+就绪链表
效率	每次调用都线性遍历 O(n)	每次调用都线性遍历 O(n)	事件通知，O(1)或O(就绪数)
最大连接数	1024（可调，但有上限）	无限制	无限制
fd 拷贝	每次调用 `select` 都需要拷贝	每次调用 `poll` 都需要拷贝	仅 `epoll_ctl` 时拷贝一次

Web服务中4xx和5xx报错区别是什么

错误主体不同

4xx错误：是客户端错误，表示客户端在请求过程中存在错误，服务器无法理解或无法处理客户端的请求。
5xx错误：是服务器错误，表示服务器在处理客户端的请求时发生了错误。

常见错误及原因不同

4xx常见错误及原因：
- 400 Bad Request：请求报文存在语法错误。
- 401 Unauthorized：请求要求用户的身份认证。
- 403 Forbidden：服务器收到请求，但拒绝提供服务。
- 404 Not Found：请求的资源在服务器上未找到。
- 405 Method Not Allowed：请求方法被禁止。
- 429 Too Many Requests：用户在给定时间内发送了太多请求。
5xx常见错误及原因：
- 500 Internal Server Error：服务器内部错误，无法完成请求，可能是代码错误、数据库连接失败等。
- 502 Bad Gateway：作为网关或代理的服务器从上游服务器收到了无效响应，可能是上游服务器挂掉或返回了无效的响应数据。
- 503 Service Unavailable：服务器暂时无法处理请求，通常是由于过载或维护。
- 504 Gateway Timeout：网关或代理服务器在等待上游服务器响应时超时，可能是上游服务器响应太慢。