当前位置：首页 > article >正文

Java后端高频面经——计算机网络

article 2025/3/13 15:14:28

TCP/IP四层模型？输入一个网址后发生了什么，以百度为例？（美团）

（1）四层模型
- 应用层：支持 HTTP、SMTP 等最终用户进程
- 传输层：处理主机到主机的通信（TCP、UDP）
- 网络层：寻址和路由数据包（IP 协议）
- 链路层：通过网络的物理电线、电缆或无线信道移动比特
（2）网络过程
- 解析URL:分析 URL 所需要使用的传输协议和请求的资源路径。如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。如果没有问题，浏览器会检査 URL 中是否出现了非法字符，则对非法字符进行转义后在进行下一过程。
- 缓存判断:浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里且没有失效，那么就直接使用，否则向服务器发起新的请求。
- DNS解析:如果资源不在本地缓存，首先需要进行DNS解析。浏览器会向本地DNS服务器发送域名解析请求，本地DNS服务器会逐级查询，最终找到对应的IP地址。
- 获取MAC地址:当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作头源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将IP 地址与本机的子网掩码相结合，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC地址，此时目的主机的 MAC地址应该为网关的地址。
- 建立TCP连接:主机将使用目标 IP地址和目标MAC地址发送一个TCP SYN包，请求建立一个TCP连接然后交给路由器转发，等路由器转到目标服务器后，服务器回复一个SYN-ACK包，确认连接请求。然后，主机发送一个ACK包，确认已收到服务器的确认，然后 TCP 连接建立完成。
- HTTPS 的 TLS 四次握手:如果使用的是 HTTPS 协议，在通信前还存在 TLS 的四次握手。
- 发送HTTP请求:连接建立后，浏览器会向服务器发送HTTP请求。请求中包含了用户需要获取的资源的。信息，例如网页的URL、请求方法(GET、POST等)等。
- 服务器处理请求并返回响应:服务器收到请求后，会根据请求的内容进行相应的处理。例如，如果是请求网页，服务器会读取相应的网页文件，并生成HTTP响应。
http和https的区别？（百度）Https的ssl要加密解密，握手过程说一下（百度、字节、腾讯）

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

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件其实就是服务端的公钥，会在 TLS 握手阶段传递给客户端，而服务端的私钥则一直留在服务端，一定要确保私钥不能被窃取。
在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。
- TLS第一次握手：客户端向服务器发起加密通信请求，ClientHello请求。
  
  ①客户端支持的TLS协议版本。②客户端生产的随机数（Client Random），用于生成会话密钥。③客户端支持的密码套件列表，如RSA加密算法。
- TLS第二次握手：服务端向客户端发出响应，SeverHello请求。
  
  ①确认TLS协议版本，如浏览器不支持则关闭加密通话。②服务器产生的随机数(Sever Random)，用于会话密钥生成。③确认密码套件列表。④服务器的数字证件（证件里包含非对称加密的公钥）。
- TLS第三次握手：客户端通过浏览器或者操作系统中的公钥确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文。
  
  ①一个随机数（pre-master secret），该随机数会被服务器公钥加密。②加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。③客户端握手结束通知，表示客户端的握手阶段已经结束。
  
  此时，浏览器会根据前三次握手中的三个随机数，通过双方协商的加密算法生成会话密钥
- TLS第四次握手：服务端用公钥对第三个随机数解密，并通过协商的加密算法生成会话密钥
  
  ①加密通信算法改变通知。②服务端握手结束通知。
接下来，客户端与服务器进入加密通信，本质上是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。（后面就是对称加密解密的过程了，因为会话密钥已经安全的“传送”给了通信的双方。）
TCP三次握手过程？为啥是三次？两次呢？每一次握手中间网络阻塞会出现什么情况？（滴滴）

TCP三次握手过程:

TCP（Transmission Control Protocol, 传输控制协议）的三次握手过程是为了在通信双方之间建立可靠的连接，确保双方都具备发送和接收数据的能力。

第一次握手:客户端 -> 服务端: 发送 SYN 包
- 客户端发送一个 SYN（Synchronize, 同步）报文给服务端，表示请求建立连接。
- 这个报文中包含一个初始序列号 seq = x。
- 状态变化:
  - 客户端: CLOSED → SYN-SENT
  - 服务端: 依旧是 LISTEN
第二次握手:服务端 -> 客户端: 发送 SYN + ACK 包
- 服务端收到 SYN 后，确认连接请求，同意建立连接。
- 服务端发送一个包含 SYN 和 ACK 的报文，表示“我收到了你的请求”。
  - SYN: 用于同步序列号，服务端发送 seq = y。
  - ACK: 确认客户端的 SYN，设置 ack = x + 1。
- 状态变化:
  - 服务端: LISTEN → SYN-RECEIVED
第三次握手:客户端 -> 服务端: 发送 ACK 包
- 客户端收到服务端的 SYN + ACK 后，发送一个 ACK 报文，确认连接建立成功。
  - ACK: 设置 ack = y + 1，确认服务端的 SYN。
- 状态变化:
  - 客户端: SYN-SENT → ESTABLISHED
  - 服务端: SYN-RECEIVED → ESTABLISHED
为啥是三次？两次不行吗？
1. 保证双向通信能力:
- 三次握手:
  - 确保 客户端和服务端都可以发送和接收数据。
  - 第一次: 客户端确认自己发送能力。
  - 第二次: 服务端确认自己接收和发送能力。
  - 第三次: 客户端确认自己接收能力。
- 两次握手:
  - 只能确认单向能力，无法确保双向通信正常。
  - 风险: 服务端可能一直等待客户端的数据，导致资源浪费。
1. 防止历史连接造成的误判:
- 三次握手: 能有效避免旧的连接请求（比如网络延迟导致的失效报文）造成误判，浪费资源。
- 两次握手: 无法确认是否是历史连接，会导致伪连接（假死连接），浪费资源。
如果某次握手中网络阻塞了会咋样？
1. 第一次握手阻塞（SYN 丢失）:
- 情况: 客户端发出的 SYN 报文丢失。
- 结果: 客户端超时后会重新发送 SYN，直到达到重试上限。
- 影响: 连接延迟，但不会建立伪连接。
1. 第二次握手阻塞（SYN + ACK 丢失）:
- 情况: 服务端发送的 SYN + ACK 报文丢失。
- 结果: 客户端超时后会重发第一次握手的 SYN。
- 影响: 连接延迟，服务端会重新发送 SYN + ACK。
1. 第三次握手阻塞（ACK 丢失）:
- 情况: 客户端发送的 ACK 报文丢失。
- 结果:
  - 服务端会认为连接未成功，超时后关闭连接。
  - 客户端认为连接已建立，会发送数据，导致服务端发送 RST（复位报文），断开连接。
- 影响: 连接失败，客户端收到 RST 报文后，知道连接未成功。
总结一下:
- 为啥是三次: 保证双向通信能力，防止历史连接误判。
- 两次不行的原因: 无法确认双向通信，容易产生伪连接。
- 网络阻塞时:
  - 第一次阻塞: 客户端重试。
  - 第二次阻塞: 客户端重试，服务端重新发送 SYN + ACK。
  - 第三次阻塞: 服务端断开，客户端收到 RST。

tcp、udp在哪一层？有什么区别？各自的应用场景（美团、滴滴）

TCP 和 UDP 在哪一层？

TCP（Transmission Control Protocol, 传输控制协议） 和 UDP（User Datagram Protocol, 用户数据报协议） 都属于 OSI 七层模型 和 TCP/IP 协议模型 中的 传输层 (Transport Layer)。
传输层的作用:
- 负责端到端的通信。
- 提供差错检测、流量控制、数据传输等功能。

TCP 和 UDP 的区别:

对比维度	TCP 🌟(可靠，面向连接)	UDP ⚡(不可靠，面向无连接)
协议类型	面向连接的协议	无连接的协议
是否建立连接	需要三次握手建立连接	不需要建立连接
可靠性	可靠，保证数据按顺序到达	不可靠，可能丢包
流量控制和拥塞控制	有流量控制和拥塞控制	无流量控制和拥塞控制
数据传输方式	面向字节流，按顺序发送和接收	面向报文，不拆分和重组
头部开销	比较大 (20-60 字节)	比较小 (8 字节)
传输效率	相对较低 (因为要保证可靠性)	高 (因为无确认机制)
适用场景	可靠性要求高的场景	实时性要求高但不强调可靠性的场景

各自的应用场景:

TCP 适用场景 (可靠传输，慢一点也没关系的场景):

HTTP/HTTPS:
- 网页浏览、登录、电商网站等，必须保证所有数据正确无误地到达。
FTP (文件传输协议):
- 传文件必须保证完整性。
Email (SMTP, IMAP, POP3):
- 邮件传输要求数据完整可靠。
数据库通信 (如 MySQL):
- 数据查询和更新需要保证无丢失。

UDP 适用场景 (实时传输，丢一点也无所谓的场景):

视频直播 (如 RTSP, RTP):
- 允许少量丢包，保证实时性。
语音通话 (如 VoIP, Skype):
- 轻微丢包不会明显影响体验，实时性优先。
游戏通信 (如 FPS, MOBA 游戏):
- 位置和动作数据偶尔丢失没关系，必须快。
DNS (域名解析):
- 请求和响应都很短，不需要复杂的确认机制。
广播与组播:
- 如视频会议，多人同时接收数据。

总结一下:

TCP: 可靠、面向连接，适合要求高可靠性的场景，比如网页、邮件、文件传输。
UDP: 不可靠、面向无连接，适合要求实时性高但不强调可靠性的场景，比如直播、语音、游戏。
应用场景:
- TCP: HTTP, FTP, 邮件, 数据库。
- UDP: 视频直播, 语音通话, 游戏, DNS。

http在七层模型中的哪一层？（美团）

HTTP 在七层模型中的哪一层？

HTTP（HyperText Transfer Protocol, 超文本传输协议） 属于 OSI 七层模型 中的 应用层 (Application Layer)，也是 TCP/IP 协议模型 中的应用层协议。

HTTP 的工作机制:
- 协议类型: 应用层协议，基于 TCP 传输层。
- 工作方式: 请求-响应模式 (Client-Server)。
- 传输协议: 通过 TCP（传输层） 进行数据传输。
- 特点: 无状态协议 (每次请求独立)，可以通过 Cookie 和 Session 实现状态保持。
ping命令用了udp还是tcp？ping命令使用了什么协议？（美团）

ping 命令用了 UDP 还是 TCP？

都不是！ ping 命令使用的是 ICMP 协议 (Internet Control Message Protocol, 因特网控制报文协议)，而不是 UDP 或 TCP。

ICMP 是什么？
- 协议层: 属于 OSI 七层模型 和 TCP/IP 协议模型 中的 网络层 (Network Layer)。
- 作用: 用于传递控制消息，比如网络连通性测试、错误报告等。
- 特点:
  - 不负责数据传输，只用于发送诊断和控制信息。
  - 不使用端口号（TCP 和 UDP 才用端口）。
ping 命令的工作原理:
1. 发送 ICMP 请求报文 (Echo Request):
  - 你的电脑向目标 IP 发送一个 ICMP Echo Request（回显请求）报文。
  - 包含一个序列号和时间戳，用来计算往返时间 (RTT)。
2. 接收 ICMP 回复报文 (Echo Reply):
  - 目标 IP 收到请求后，回复一个 ICMP Echo Reply（回显回复）报文。
3. 计算网络延迟:
  - 根据 Echo Request 和 Echo Reply 的时间差，计算网络延迟 (RTT, Round-Trip Time)。