计算机网络常见问题

ARP与RARP的区别是什么？

这两个都是网络通信协议，用于将IP地址和MAC地址进行转换

功能不同：

ARP协议用于将IP地址转换为MAC地址，也就是在通信时需要知道目标机器的MAC地址时，ARP协议可以用来查询目标机器的MAC地址。

RARP协议则是将MAC地址转换为IP地址，也就是在启动时，需要知道自己的IP地址时，可以向网络中发送RARP请求，获取自己的IP地址。

工作方式不一样：

ARP协议是一种广播协议，当一台主机需要知道另一台主机的MAC地址时，会在本地局域网上广播一个ARP请求包，所有主机都能收到这个请求包，但只有目标主机会响应这个请求，将自己的MAC地址发送回来。

而RARP协议则是向预定义的RARP服务器发出请求，请求服务器返回自己的IP地址。

由于现代的操作系统和网络设备都可以自动分配IP地址，RARP协议已经很少使用了。而ARP协议则在现代网络通信中仍然起着重要的作用。

HTTP是无状态的，因此需要Cookie、Session，Token 等机制来实现识别用户身份

cookie：

cookie是服务端发送给用户浏览器的一个小型文本，创建之后，浏览器后续调用服务器都会带上这个值，服务器根据这个值进行解析。

cookie是不能跨域的，并且每个域名下面的cookie数量也是有限的

session：

session是服务端创建和管理的，第一次请求的时候会给这个客户端创建出唯一的sessionID，后续请求的时候客户端会将这个sessionID通过cookie携带过来，真正的session数据是存储在服务端的

session需要借助cookie来实现

cookie和session的区别：

cookie是存储在客户端的，session存储在服务端，所以session更加的安全
cookie只能存储字符串，其它的类型也需要转化成字符串再进行存储，session对存储类型没有限制
cookie一般可以设置比较长的过期时间，一般就是直到连接断开，而session时间会比较短，如果连接断开或是超时也会失效
cookie默认不能超过4kb，session没限制，但是太大的话会占用服务器太多资源

不用cookie如何实现session？

就是直接将sessionID 作为参数携带到后端，后端写一个拦截器拦截一下就行

但是在一些分布式场景的话，光是靠cookie，会有比较不安全的问题；靠session，它本身不能扩JVM，所以需要引入一些组件的辅助，比如redis之类的，不过为了避免掉这些麻烦的操作，可以直接使用token

token其实就是客户端首次请求之后，服务器生成的一段密文数据，常见的就是使用jwt实现，把一些用户的基本数据通过jwt算法加密成一串密文，客户端每次请求都要带上这个东西

jwt的原理：头部+负载+签名函数

头部记录签名算法
负载记录真正的信息
签名就是生成规则。只要你的头部或是负载被篡改就会直接失效

但是jwt也是有一定的缺点，首先就是过期时间不可变，生成的时候就需要指定，并且不适合主动下线的行为

如果需要主动下线，一般不会用这些jwt去生成，而是直接后端生成一段唯一的字符串作为标识，存储在redis，用户主动下线就把这段字符串删除掉

HTTP_2存在什么问题，为什么需要HTTP_3？

因为HTTP2只解决了HTTP的队头阻塞问题，没有解决TCP的队头阻塞问题

TCP队头阻塞问题：

TCP 为了保证 "数据按顺序到达"，如果前面一个包丢了，后面所有包都必须等着它重传，才能一起交给应用层。这就是TCP队头阻塞的原因。

而HTTP2基于TCP实现，并且多个请求会复用同一个TCP，这个队头阻塞问题会更严重

TCP网络时延问题：

TCP每次建立连接都需要三次握手，每次断开连接都需要四次挥手

而这个过程是需要耗时的，我们称为网络时延（指一个请求从客户端浏览器发送一个请求数据包到服务器，再从服务器得到响应数据包的这段时间）

那么就只能考虑对TCP协议进行升级？

但是因为TCP涉及的环节很多，如果直接升级TCP协议，就需要很多机器设备同时更新，这显然是不现实的

那放弃TCP？

如果放弃的话，可以选择创建新的协议，但是创建新的协议一样需要设别支持，那么就只能使用已经有的协议，比如UDP就不错。

HTTP3具体详情：什么是HTTP_3的QUIC协议？

HTTPS和HTTP的区别是什么？

HTTPS就是HTTP加上一个安全证书

HTTPS在进行数据传输的时候是使用了SSL或是TLS对数据进行加密的，数据比较安全，而HTTP是明文传输的

HTTPS的默认端口是443，而HTTP是80

HTTPS在性能方面也会差一点，因为需要对数据进行加密解密

ping的原理是什么？

ping就是用来检测网络是否可达，并且可以检查时延以及是否丢包

底层是基于ICMP协议实现的，执行ping的主机会向目标主机发送回显请求，目标主机收到后会返回回显响应，整个过程并不经过TCP/UDP

然后会计算出整体的时延和丢包情况

ping命令本身处于应用层，相当于一个应用程序。它使用的ICMP协议是一个网络层协议，也就是说，ping是一个应用层直接使用网络层协议的例子。像我们常见的HTTP协议是依赖的传输层协议TCP/UDP，而传输层的协议再依赖网络层的IP协议。

ping为什么不需要端口？

ping虽然在应用层，但是它使用的ICMP协议是在网络层的，并没有经过传输层，只需要ip，无需端口

TCP和UDP的区别是什么？

TCP和UDP都是位于传输层的协议

主要区别：

连接类型：

- TCP是面向连接的协议，发送数据之前需要先通过三次握手建立连接，断开连接之前需要四次挥手
- UDP是无连接协议，发送数据的时候直接发送，无序建立连接

可靠性：

- TCP是可靠传输，通过确认机制和重传机制来确保消息的可达性
- UDP是不可靠传输，只负责发送，对方是否能接收到，自己不管

速率：

- TCP的速率比较慢，因为需要等待确认和建立连接等
- UDP更快，比较适合实时性要求高的系统

拥塞控制：

- TCP内置了拥塞控制，能有效避免节点过载导致丢包现象
- UDP没有内置拥塞控制机制

头部大小

- TCP的头部一般要20字节，包含的信息比较多
- UDP头部一般是8字节，包含的信息比较少

TCP是如何保证可靠传输的？

对数据进行编号，接收方接收到数据之后，会按照编号来给发送方进行响应
校验和，把消息的长度+头部计算出长度之后塞入头部一起发送，接收方同样要判断数值是否准确，否则认为被篡改，直接丢失
三次握手，四次挥手，这个是保证通道的健壮性，确保数据能在稳定的环节进行传输
双方都有缓冲区，发送方只能发送不超过接收方缓冲区大小的数据，避免出现丢包现象
拥塞控制，避免发送速率太快，导致负载而丢包
ARQ协议，说白了就是ACK机制，发送完需要对方ACK才会继续发送
超时重传，超过一定时间没接收到ACK会重新传输

对称加密和非对称加密有什么区别？

对称加密就是加密和解密的密钥是一样的

非对称加密就是加密的密钥和公钥，但是解密的密钥是私钥，加解密密钥不同

常见的对称加密就是AES，常见的非对称就是RSA

一般的密码场景不需要解密，一般使用单向加密就行了，比如一定次数的hash算法（ BCrypt ）

简单介绍一下DNS？

DNS就是一个分布式KV系统，K就是域名，V就是真正的IP端口

作用就是把域名和真正的IP地址映射起来，并且一个域名可以有多个IP地址，主要是实现分流

解析的整个过程：

先查看浏览器缓存是否存在
不存在就查看本地的hosts文件
不存在就查看本地DNS
不存在就去问根DNS，它也不知道具体的IP是什么，但是它能根据你的一级域名告诉你这个是谁管理，比如.com是在哪个顶级域名服务器
然后你去这个顶级域名服务器找，它就管理了全部.com后缀的域名，但是它同样不知道这个具体的IP是什么，它知道这个域名是在哪个权威DNS上存在
然后你就到具体的权威DNS上根据域名找到对应的IP
并且会把这个IP记录到自己本地DNS然后再返回给浏览器

DNS污染：

就是DNS的查询没有一些防护，一般就是基于UDP（53端口）进行查询，攻击者只需要在半路的网关或是防火墙监听到你要查询特定的域名，然后立即伪装成一个虚假的IP返回，那么你拿到的就是一个假的IP

特点：不碰真正的DNS服务器，只是在半路截胡伪造结果

DNS劫持：

直接黑进DNS服务器改数据

特点：懂了真正的DNS配置，改了真正的记录

DNS污染和DNS劫持的区别：

DNS劫持是劫持了DNS服务器，进而修改其解析结果。

DNS污染是国内的某些服务器对DNS查询进行入侵检测，发现与黑名单上匹配的请求，该服务器就伪装成DNS服务器，给查询者返回虚假结果。它利用了UDP协议是无连接不可靠性。

一个是劫持了DNS服务器，一个是伪装成DNS服务器。造成的结果都是返回错误的IP地址。

介绍下TCP是如何实现拥塞控制的？

拥塞控制就是控制发送方的数据传输速率，避免造成节点过载的技术

主要通过以下方案来实现

慢启动+拥塞避免：

慢启动：

慢启动就是限制一开始时你能发送的最大速率（拥塞窗口大小），然后每次接收到反馈回来的ACK，就会最大一下这个限制，以指数级的方式慢慢减小限制，直到阈值或是出现丢包

拥塞避免：

当发送速率达到慢启动的阈值之后，就会改成更慢的增加速率，也就是从指数增长变成线性增长

快重传和快恢复：

这个是对慢启动+拥塞避免的改进版，无需等到超时才知道包丢失，而是连续接收到3个相同的ack就判定数据丢失，出发重传

具体就是接收方每接收到一个数据，就会返回想要的下一个数据的编号作为ack信号，如果中间出现数据丢失，那么每次都是返回这个编号，发送方连续接收到3个以上的相同ack，就认为该数据丢失，出发重新传递

当检测到丢包之后，会进入快恢复阶段，具体的就是将拥塞窗口降为当前的一半，然后按照线性的速率继续增长（半跌半恢复）

介绍一下OSI七层模型？

七层模型：（应示会传，网数物）

物理层（Physical Layer）：主要规定传输介质的传输方式，包括电信号、电压、光脉冲等。该层的主要协议是物理媒介相关协议，如RS232、V.35、以太网等。
数据链路层（Data Link Layer）：在物理层上建立数据链路，对数据进行分帧、差错校验等处理，确保数据可靠地传输。该层的主要协议有点对点协议PPP（Point-to-Point Protocol）、高级数据链路控制协议HDLC（High-Level Data Link Control）、以太网协议等。
网络层（Network Layer）：主要解决数据在网络中的传输问题，包括寻址、路由选择等。该层的主要协议有IP协议、网关协议（ARP）、路由协议（RIP、OSPF、BGP等）等。
传输层（Transport Layer）：提供端到端的可靠传输服务，包括数据传输控制、流量控制等。该层的主要协议有TCP协议、UDP协议、SCTP协议等。
会话层（Session Layer）：提供会话管理功能，负责建立、维护和结束会话。该层主要实现了不同计算机之间的会话控制，为高层协议提供一个传输数据的会话环境，该层的主要协议有NetBIOS等。
表示层（Presentation Layer）：负责数据格式的转换，确保应用层数据的格式一致。该层主要实现了数据格式的转换和数据加密解密等功能，如JPEG、MPEG等。
应用层（Application Layer）：提供应用程序之间的交互，包括文件传输、电子邮件、远程登录等。该层的主要协议有HTTP、FTP、SMTP、DNS、TELNET、SNMP等。

TCP是在传输层，HTTP在应用层

在互联网中真正实现的一般是五层模型或是四层模型：

四层模型

浏览器输入www.taobao.com回车之后发生了什么？

url解析：补全协议（https），解析参数，检查长度是否合法，查看浏览器缓存是否有这个页面，有就直接返回
DNS查询：查询顺序：

1. 浏览器缓存
2. 本地hosts文件
3. 路由器缓存
4. 本地DNS（运营商DNS）【本地DNS并不是在自己电脑，而是因为离得近，一般就是运营商或是校园网】
5. 根DNS ------ 顶级域名服务器 ------ 权威DNS
6. 拿到最终的IP

TCP握手，也就是和这个真正的IP建立连接
封装请求报文拉取页面信息
请求到服务器这边会经过nginx，网关层等的代理
然后会被控制器接收，并拿到真正的数据（这里是向后台拿数据）
服务端把数据封装成响应给浏览器
浏览器解析HTML等进行渲染

路由器与交换机的区别是什么？

交换机是数据链路层的，路由器是网络层的

交换机网络时，查询目标机器是通过MAC地址，而路由器是通过IP地址

什么是CDN，为什么他可以做缓存？

CDN是内容分发网络，和DNS不一样，DNS用来做域名解析，CDN存储静态资源

把网站的静态资源（图片、JS、CSS、视频、下载包）放到全国 / 全球离用户最近的节点服务器上，让用户就近访问。

它可以做缓存是因为它部署了很多边缘节点，然后用户第一次访问的时候会就到源站（资源存储服务器）获取资源，并把对应的资源放到用户的本地节点（离用户近的那个），下次直接访问这个本地节点就行

CDN适合存储静态资源，也就是那些长期不变的

能有效提高访问速率，减少源站压力

什么是HTTP_3的QUIC协议？

HTTPS是基于QUIC协议实现的，因为TCP存在是队头阻塞的问题，如果直接升级TCP协议会因为设备跟不上导致无效

QUIC是基于UDP实现的

QUIC协议的特点：

基于UDP实现
可靠性：提供了类似于TCP的可靠性方式，使得它同样可靠
无序、并发字节流：单个数据流可以保证有序交付，但多个数据流之间可能乱序，这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！
快速握手：QUIC提供0-RTT和1-RTT的连接建立
使用TLS 1.3传输层安全协议：与更早的TLS版本相比，TLS 1.3有着很多优点，但使用它的最主要原因是其握手所花费的往返次数更低，从而能降低协议的延迟。

QUIC的可靠性就是靠ACK机制，也就是每一个数据包发送过去，接收方需要回一个ACK，如果没有回就会重新发送这个丢失的包

QUIC属于传输层的协议

TCP和QUIC对比：

主要看是什么时期的用法：

HTTP1.1，这个时候其实TCP不是并行处理HTTP请求，而是客户端和服务端之间建立了多个TCP连接，然后每个TCP处理一个HTTP，看起来像是并行

HTTP2，每个HTTP请求封装成Stream，确实是并行，但是TCP本身不认识Stream，只看你一整条数据是否完整，不完整不会交付给服务端，也就无法进行后续处理，所以会出现必需阻塞等待直到所有数据包都完整才交给服务端进行拼接

而QUIC设计的时候就考虑到了Stream，所以它是认识Stream 的，它能知道是哪一个stream数据不完整，那么就让这个stream先阻塞等待，其它完整的直接交给服务端处理。这是TCP和QUIC最直接的区别，TCP不认识stream，它不知道是哪一个stream缺失数据，只能一整批都阻塞等待

什么是IPV6？和IPV4有什么区别？

IPV6就是解决IP不够用的问题

IPV4是32位，大概是42亿个，已经不太够用了

IPV6是128位，大概是3.4 × 10²⁸ 亿，基本用不完

IPV4和IPV6的区别：

地址长度：IPv4=32 位；IPv6=128 位
地址格式：IPv4 点分十进制；IPv6 冒号分十六进制
报文头：IPv4 变长 20~60B；IPv6 固定 40B、更简洁
安全性：IPv6 原生支持 IPSec；IPv4 需要额外配置
地址类型：IPv4 有广播；IPv6 用任播替代，无广播
解析：IPv4 用 ARP；IPv6 用 ICMPv6 邻居发现

IPv6 优点：

多：地址空间极大，几乎用不完
快：路由表更小，转发更快（因为是按照区域分配，所以一片区域用一条记录表示就行，而不是IPV4那种乱着分配）
好：支持多媒体、自动配置、质量更好
省：管理更简单，安全性更强

Pv4 迁移到 IPv6 的三种技术

双栈：设备同时跑 IPv4+IPv6
隧道：把一种包封装在另一种里传输
协议转换（NAT-PT）：IPv4 和 IPv6 互相翻译

什么是TCP的粘包、拆包问题？

粘包：

如果数据是很多个小体积数据，TCP为了效率，可能会把多份数据粘在一起进行发送，又因为TCP是以流的形式传输数据，所以可能造成接收方无法正确拆分数据

拆包：

如果数据很大，TCP为了发送效率，同样会把这个数据拆分成多份进行发送，这个时候就出现了拆包现象

出现拆包和粘包，本质都是因为TCP是以流的形式进行发送，可能会对原数据进行拆分或是合并，但是接收方无法准确重新划分成原消息

解决方式：

**定长：**直接强制固定每一条消息的长度，不够了就补占位符，超过直接不给发送

**加边界符：**用特殊的符号标识消息的边界，接收方按照这个特殊符号对消息进行划分

**消息头：**发送的时候用固定长度来标识消息的一些信息，比如标识消息的真正长度，每次读取的时候先读取这个字段，然后再读取它标识出来的消息长度

什么是TCP三次握手、四次挥手？

三次握手就是在建立连接的时候

客户端先向服务端发送一个同步信号，告诉服务端自己想进行连接（SYN=1）

服务端回一个ack，告诉客户端自己准备好了（SYN=1，ACK=1）

客户端收到ack之后，也回一个ack表示客户端也准备好了（ACK=1）

四次挥手：

客户端发送断开连接信号给服务端（FIN=1）

服务端接收到之后回一个ACK，并且告诉客户端先不要关闭，自己还要做一些后置处理工作（ACK=1）

服务端昨晚后置处理工作之后回一个信号给客户端（FIN=1）

客户端接收到之后就回一个ACK给服务端，然后两者就可以关闭连接了（ACK=1）

为什么建立连接要三次握手？

第一次客户端发送给服务端，就是告诉服务端自己的数据发送能力正常
第二次服务端回发给客户端，就是告诉客户端，自己不但发送能力正常，并且也能接收到数据
第三次客户端接收到信息发送给服务端，就是告诉服务端自己接收能力正常

总结就是要确保双方的收发能力都是正常的才进行数据传输

为什么需要四次挥手？

第一次客户端说想要关闭连接
服务端接收到后回一个ack，然后客户端向服务端发送通道会关闭
然后服务端处理完剩下的事情，会发送一个关闭服务端向客户端发送通道的关闭信号
客户端接收到之后回一个ack给服务端，然后就彻底关闭

本质就是TCP是全双工，维护了两套发送机制，需要分别关闭

而握手确认只需要三次的原因是可以将其中一个SYN+ACK一起发送给客户端

什么是TCP重传率，有什么用？如何查看？

重传率就是重传的报文数量/总发送的报文数量

主要用来判断网络好坏

linux可以通过 netstat -s | grep -i retrans 查看

或者通过一些工具

什么是跨域访问问题，如何解决？

跨域其实是浏览器的同源策略，要求你网页中的资源需要来自于同一个源，否则会出发跨域保护

同一个源要求域名相同，协议相同，端口相同

如果在浏览器访问过程中发现域名、端口或者协议不同的时候，就会出现跨域问题。

域名不同：如从a.com的页面请求b.com的资源。
协议不同：如从http的页面请求https的资源。
端口不同：当页面的端口与请求的资源的端口不一致时，同样会触发跨域问题。

解决的方式：

后端解决：后端可以通过配置或是注解配置允许的源

但是更好的方式是前端的配置文件（vite.config.ts）或是nginx直接配置，这两种本质都是骗过前端

什么是网络分区？

网络分区指的是在一个分布式网络 中，由于网络故障导致网络被划分为两个或多个互不通信的区域的情况。

脑裂现象就是网络分区的一个经典情况

什么是正向代理和反向代理？

正向代理：代理客户端，替客户端去访问访问服务器

例如常见的科学上网等。服务端不知道客户端的情况

反向代理：代理服务端，替服务端接收客户端请求

例如常见的nginx和CDN等。就是请求直接打到这个上面，不是打到服务端

为什么需要HTTP_2，他解决了什么问题？

需要回看HTTP的发展历史

HTTP1.0：

HTTP1.0为了提高系统的效率，每次请求的时候都需要重新建立TCP连接，用完就会断开，但是也带来了一个问题，频繁的创建和关系开销是很大的

HTTP1.1：

HTTP1.1就解决了这个问题，主要就是TCP能被复用，也就是创建之后，可以传输多个HTTP请求，有效的提升了性能

HTTP2：

虽然HTTP1.1已经很强，但是还是不能应对这种高并发的场景，那么HTTP2就使用了SPDY协议进行改进

SPYD 主要就是引入了：

多路复用：多个请求共享一个TCP，不过和HTTP1.1不同的是，这多个请求是可以并行过来的，无需排队等待
header压缩：删除或是压缩HTTP头
服务端推送：服务端也能主动向客户端推送数据
那既然HTTP2基于SPYD，那有哪些改进呢？
二进制分帧：就是在HTTP层和TCP层之间加上一层缓冲，把请求切成一个个帧，以二进制的格式发送，到了目的机器再进行组装，好处就是可以乱序发，并且不会因为其中一个阻塞而拖慢所有，真正的并行处理
多路复用：就是多个HTTP请求共用一个TCP连接，但是每个HTTP请求是单独的Stream，不会造成混乱，并且是并行流处理的模式
header压缩：客户端和服务端维护一张共享map表，对于重复的内容，只发送对饮的索引，并且还对整体做哈夫曼编码
服务端推送：这个就没什么说的，就是服务端也能推送数据给客户端

HTTP队头阻塞是什么？

其实就是HTTP1.1引入的TCP持久化带来的问题，因为可以同时发送多个HTTP请求，那么就要维护一个请求队列，服务端必需按照请求的顺序进行响应，那也意味着假设一个请求延迟了，其它请求一样会造成阻塞，这就是队头阻塞。

不过HTTP2就解决了这个问题，主要是通过将请求全部拆分成帧的形式，发送方和接受方直接乱序发送，另一方拿到之后再进行组装和对应到具体的请求，避免了队头阻塞的现象

不过HTTP2只是解决了HTTP的队头阻塞问题，并没有解决TCP的队头阻塞问题

HTTP1.1和HTTP2请求的方式有什么区别？

HTTP1.1使用的是管道发送，也就是请求往一个管道里面发送，但是不需要等待前一个响应再发送第二个，而是可以按顺序直接发送，但是要求服务端返回的时候需要按照请求顺序返回，这带来的一个问题就是如果一个请求响应慢了，会阻塞后续请求的响应，也叫队头阻塞

HTTP2采用的是Stream的发送方式，也就是发送方直接把请求拆成帧（一小段二进制），每一段帧会标识属于哪一个请求，发送过去之后，服务端自己拼接，处理，响应的时候也是按照帧的方式，客户端自己拼接出响应结果

总的来看，HTTP2解决了HTTP中存在的效率问题。它主要引入了 二进制分帧、多路复用、header压缩、以及服务端推送 的新特性，大大的提升了效率。

而且，在HTTP/2中还解决了一个重要的问题，那就是HTTP的 队头阻塞 问题。