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

前端进阶--计算机网络

news 2026/7/22 15:59:05

参考（强烈推荐）：「2021」高频前端面试题汇总之计算机网络篇 - 掘金 (juejin.cn)

1、HTTP 状态码

HTTP 状态码 | 菜鸟教程 (runoob.com)

1xx：消息
2xx：成功
3xx：重定向
4xx：客户端错误
5xx：服务器错误

1.1、1xx：消息

100- Continue 继续。客户端应继续其请求
101-Switching Protocols 切换协议。服务器根据客户端的请求切换协议。

1.2、2xx：成功

200 - OK 请求成功。
201-Created 已创建。成功请求并创建了新的资源、
202-Accepted 已接受。已经接受请求，但未处理完成。
203- Non-Authoritative Information 非授权信息。请求成功，但返回的meta信息不在原始的服务器，而是一个副本。
204-No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205-Reset Content 重置内容。服务器处理成功，客户端应重置文档视图。可通过此返回码清除浏览器的表单域
206-Partial Content 部分内容。服务器成功处理了部分GET请求

1.3、3xx：重定向

300- Multiple Choices 多种选择，
301-Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302- Found 临时移动。与301类似。但资源只是临时被移动。返回信息会包括新的URI。客户端应继续使用原有URI。新地址在请求头的location。会自动发起第二次请求。
303-See Other 查看其它地址。这个和302很像，但是有个细微区别是，除了会提示客户端去请求Location以外，还会要求请求要使用Location时使用GET方法。
304-Not Modified 未修改。可直接使用缓存里面内容
305 Use Proxy 使用代理。所请求的资源必须通过代理访问

306 Unused 已经被废弃的HTTP状态码
307-Temporary Redirect 临时重定向。与302类似。使用GET请求重定向

1.4、4xx：客户端错误

400 Bad Request 客户端请求的语法错误，服务器无法理解。
表示请求的报文中存在语法错误，比如url含有非法字符。提交json时，如果json格式有问题，接收端接收json，也会出现400 bad request
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留，将来使用
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（请求路径错误）。
405 Method Not Allowed 客户端请求中的方法被禁止。例如Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长，超时

1.5、5xx：服务器错误

500-Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求

2、网络模型

2.1、OSI七层模型

物理层，数据链路层，网络层，传输层，会话层，表示层，应用层。

2.2、TCP/IP四层模型

网络接口层、网络层、传输层和应用层。

2.3、各层协议

2.3.1、应用层的协议：应用层对应用程序的通信提供服务。

参考：常见应用层协议-CSDN博客参考：

【精选】一文弄懂所有应用层的协议-CSDN博客

FTP文件传输、访问和管理
SMTP邮件传输，规定了在两个互相通信的SMTP进程之间应如何交换信息。SMTP不能传送可执行文件或其他二进制对象。SMTP仅限于传送7位ACSII码，不能传送其他非英语国家的文字。SNTP服务器会拒绝超过一定长度的邮件。
MIME：解决SMTP邮件传输缺点，扩充为新协议
POP3电子邮件邮局协议（代理），工作方式：下载并保留（在服务器）下载并删除
IMAP网际报文存取协议（代理）可以预览部分邮件再考虑下载与删除
HTTP超文本传输协议，浏览器（万维网客户进程）怎样向万维网服务器请求万维网文档，以及服务器怎么把文档传送给浏览器。
DNS查询服务和远程作业登录

2.2.2、传输层：负责在网络中传输数据

UDP-用户数据报协议，UDP 使用一个简单的、具有最小协议机制的无连接通信模型。UDP 使用校验和保证数据完整性，使用端口号以区分数据发送方和接收方中不同的应用程序。它无需握手会话，即将不可靠的底层网络直接暴露给了用户的应用程序：不保证消息交付、不保证交付顺序也不保证消息不重复。

TCP和UDP的区别

TCP和UDP的使用场景

TCP应用场景：效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。例如：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
UDP应用场景：效率要求相对高，对准确性要求相对低的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

TCP传输机制

1. 提供可靠的数据传输服务：传输层协议可以通过一系列的机制来确保数据的可靠传输，例如错误检测和重传机制等。

2. 提供流量控制和拥塞控制服务：传输层协议可以通过流量控制（滑动窗口）和拥塞控制机制（慢启动即启动值小为1，指数增长到门限，线性增长到顶点（超时点），门限值为顶点值的一半半，重来）来协调发送方和接收方之间的数据传输速度，从而保证网络的稳定性和可靠性。

3. 提供多路复用和多路分解服务：传输层协议可以通过多路复用和多路分解机制来实现多个应用程序之间的数据传输，并且可以保证数据的可靠性和完整性。

2.3.3、网络层协议(典型设备:路由器，防火墙、多层交换机) 数据单元：数据包（Packet ）

参考：IP、ARP、RARP、ICMP、IGMP(网络协议：网络层协议）_请简述以下协议的基本功能。icmp:igmp:arp: rarp:-CSDN博客

IP协议：网络层的功能主要由IP来提供，提供客户端到服务端的分组分发功能。无连接的和不可靠的，它将差错控制和流量控制之类的服务授权给了其他的各层协议
ARP协议：地址解析协议用于动态地完成IP地址向物理地址的转换。物理地址通常是指计算机的网卡地址，也称为MAC(媒体访问控制)地址，每块网卡都有唯一的地址。
RARP：反向地址解析协议，用于动态完成物理地址向IP地址的转换。
ICMP：网际控制报文协议，是一个专门用于发送差错报文的协议，由于IP协议是一种尽力传送的通信协议，即传送的数据可能丢失、重复、延迟或乱序传递，所以需要一种尽量避免差错并能在发生差错时报告的机制，这就是ICMP的功能。
IGMP：网际组管理协议，允许Internet中的计算机参加多播，是计算机用做向相邻多目路由器报告多组成员的协议。多目路由器是支持组播的路由器，它向本地网络发送IGMP查询，计算机通过发送IGMP报告来应答查询。多目路由器负责将组播包转发到网络中所有组播成员。

2.3.4、网络接口层（数据链路层）(典型设备: 网卡，网桥，交换机，光纤) 数据单元：帧（Frame）

点对点协议PPP（Point to Point Protocol）
以太网（Ethernet)
高级数据链路控制协议HDLC(High-Level Data Link Control)
帧中继（Frame Relay)
异步传输模式ATM(Asynchronous Transfer Mode)
IEEE

2.4、Http短连接与Http长连接

参考：HTTP长连接，短链接，持久连接的区别-CSDN博客

2.4.1、短连接定义
Client方与server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此方式常用于一点对多点通讯。

短连接的操作步骤是：建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

短连接的适用场景：
短连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。每个TCP连接的建立都需要三次握手，每个TCP连接的断开要四次握手。
web网站的http服务一般都用短连接。因为长连接对于服务器来说要耗费一定的资源。像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。

2.4.2、长连接定义：
client方与server方先建立连接，连接建立后不断开，然后再进行报文发送和接收。这种方式下由于通讯连接一直存在。此种方式常用于P2P点对点的通信。

长连接的操作步骤是：建立连接——数据传输...（保持连接）...数据传输——关闭连接
长连接适用场景：
监控系统：后台硬件热插拔、LED、温度、电压发生变化；请求频繁的场景（直播，流媒体）。

在使用持久连接前，HTTP协议规定为获取每个URL资源都需要使用单独的一个TCP连接，这增加了HTTP服务端的负载，引起互联网拥塞。例如内嵌图片以及其他类似数据的使用要求一个客户端在很短时间内向同一个服务端发起多个请求。

总体描述
HTTP/1.1和之前版本的显著区别是HTTP/1.1默认使用持久连接。除非服务端在应答中明确指出报告错误。持久连接对关闭TCP连接的行为提供信号量机制支持。这个信号量是在HTTP头中的Connection域设置，Connection:close
使用持久连接的优点:

减少TCP连接数量：在一个连接上实现HTTP请求和应答的流水，即允许客户端发出多个请求，而不必在接收到前一请求的应答后才发出下一请求，极大减少时间消耗，后续请求延迟减少，无需再在TCP握手上耗时
可以更加优雅地实现HTTP协议，由于持续连接的存在无需报告错误后无需关闭连接，因此客户端可使用最新的协议特性发出请求，如果接收到表示错误的应答，则换用更旧的语义。

3、GET和POST的请求的区别

是否缓存：因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。
get对这个资源的查操作,post已有资源的修改。GET 请求是一个幂等的请求，重复执行多次，产生的效果是一样的，而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。
发送的报文格式： Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据
安全性： Get 请求可以将请求的参数放入 url 中向服务器发送，请求的 url 会被保留在历史记录中。
请求长度：浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。
参数类型： post 的参数传递支持更多的数据类型。

4、POST和PUT请求的区别

PUT请求：PUT用来改资源。如果两个请求相同，后一个请求会把第一个请求覆盖掉。（所以）
Post请求：Post用来增资源。每 POST 一次，一个字段就会被创建，后一个请求不会把第一个请求覆盖掉。它会创建新的内容。

5、常见的HTTP请求头和响应头

HTTP请求报文由3部分组成（请求行（请求方法，URL地址，请求协议及版本）+请求头+请求体（请求参数））：

HTTP响应报文由3部分组成（响应行（报文协议及版本，状态码、状态描述）+响应头+响应体（响应内容））：

5.1、HTTP Request Header 常见的请求头：

Accept:浏览器能够处理的内容类型
Accept-Charset:浏览器能够显示的字符集
Accept-Encoding：浏览器能够处理的压缩编码
Accept-Language：浏览器当前设置的语言
Cookie：当前页面设置的任何Cookie
Host：发出请求的页面所在的域
Referer：发出请求的页面的URL
User-Agent：浏览器的用户代理字符串

5.2、HTTP Responses Header 常见的响应头：

Date：表示消息发送的时间，时间的描述格式由rfc822定义
server:服务器名称
Cache-Control：控制HTTP缓存
content-type:表示后面的文档属于什么MIME类型

6、HTTP1.0 、HTTP 1.1 、 HTTP 2.0和 HTTP 3.0区别

6.1、HTTP 1.0和 HTTP 1.1 有以下区别：

连接方面：http1.0 默认使用无连接无状态，每次发送请求都要进行TCP连接，且不记录过去的请求。而 http1.1 默认使用持久连接。http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。
资源请求方面：在 http1.0 中不支持部分请求，不支持断点续传功能。而 http1.1 支持，方便了开发者自由的选择以便于充分利用带宽和连接。部分请求
缓存方面：http1.1 则引入了更多可供选择的缓存头来控制策略，如在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准，http1.1 则引入了更多的缓存控制策略，例如 Etag、If-None-Match、cache-control 等更多可供选择的缓存头来控制缓存策略。
http1.1 中新增了 host 字段,新增了很多请求方法，如 PUT、HEAD、OPTIONS 等
HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，引起队头阻塞。HTTP/1.1 采用了长连接，管道传输，客户端可以发起多个请求。HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

6. 2、HTTP 1.1 和 HTTP 2.0 的区别

头信息压缩：HTTP/2 实现了头信息压缩，由于 HTTP 1.1 协议不带状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如 Cookie 和 User Agent ，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。HTTP/2 对这一点做了优化，引入了头信息压缩机制。一方面，头信息使用 gzip 或 compress 压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了
二进制协议：HTTP/2 是一个二进制协议。在 HTTP/1.1 版中，报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制。
多路复用：在 HTTP/2 中每个请求或响应以数据流形式发送，每个数据流都标记着一个独一无二的编号。HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。只要再根据每个帧头部的流标识符(Stream_id)重新封装就行。彻底解决「队头阻塞」问题。
服务器推送： HTTP/2 允许服务器未经请求，主动向客户端发送资源。服务器推送提前给客户端推送必要的资源，这样就可以相对减少一些延迟时间。
数据流：HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的请求。HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。每个数据流都有一个独一无二的编号。数据包发送时，都必须标记数据流 ID ，用来区分它属于哪个数据流。

6.3、说一下HTTP 3.0

HTTP/3基于UDP协议实现了类似于TCP的多路复用数据流、传输可靠性等功能，这套功能被称为QUIC协议。

HTTP/3基于UDP协议实现了类似于TCP的多路复用数据流。
HTTP/3有更好的移动端表现，因为TCP是基于IP识别连接，而QUIC是通过ID识别链接。无论网络环境如何变化，只要ID不变，就能迅速重新连上。
HTTP/3集成TLS加密功能
快速握手：由于基于UDP，HTTP/3可以实现使用0 ~ 1个RTT来建立连接。

7、对请求头的keep-alive的理解

HTTP1.0 中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接，这就是长连接。其使用方法如下：

HTTP1.0版本是默认没有Keep-alive的（也就是默认会发送keep-alive），所以要想连接得到保持，必须手动配置发送Connection: keep-alive字段。若想断开keep-alive连接，需发送Connection:close字段；
HTTP1.1规定了默认保持长连接，数据传输完成了保持TCP连接不断开，等待在同域名下继续用这个通道传输数据。如果需要关闭，需要客户端发送Connection：close首部字段

8、HTTPS协议

8.1、什么是HTTPS协议？

超文本传输安全协议是一种通过计算机网络进行安全通信的传输协议，HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTP协议采用明文传输信息，存在信息窃听、信息劫持和的信息篡改风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

8.2、TLS/SSL的工作原理

安全传输层协议，是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，主要利用了散列函数hash、非对称加密、对称加密算法。

（1）散列函数hash

该函数的特点是单向不可逆，对输入数据非常敏感，输出的长度固定，任何数据的修改都会改变散列函数的结果，可以用于防止信息篡改并验证数据的完整性。

（2）非对称加密

有两个秘钥，分别为公钥和私钥。公钥是公开的，私钥是保密的。用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。服务器将公钥公布出去，任何想和服务器通信的客户，都可以使用其公钥对数据进行加密，这样服务器就可以使用私钥进行解密，这样就能保证数据的安全了。

例如有客户端A，与服务器B。客户端A发送随机数a1与算法给服务器B，同样服务器B发送随机数b1与算法、公钥给客户端A。客户端利用算法与公钥加密随机数为a2(预主密钥），并发送给服务器B。然后会话密钥（密码）就是客户端A的信息a1+b1+a2(===信息b1+a2。其中信息可以理解为密钥。
之后大家利用这个会话密钥（不传送，只是彼此解密规则）解码，对称加密

（3）对称加密

对称加密的方法是，双方使用同一个秘钥对数据进行加密和解密。发送密文的一方使用对方的公钥进行加密处理『对称的密钥』，然后对方用自己的私钥解密拿到『对称的密钥』，这样可以确保交换的密钥是安全的前提下，使用对称加密方式进行通信。

（4）解决报文可能遭篡改问题（数字签名）

假如有中间者，就会篡改。为了保证公钥是可信的，假设对网站信息加密后，然后通过第三方机构的私钥再次对其加密，（浏览器会去安装一些比较权威的第三方认证机构的公钥），这样的话，数字证书包含有两个特别重要的信息，即某网站公钥 + 数字签名，假如中间人拦截后把服务器的公钥替换为自己的公钥，因为数字签名的存在，会导致客户端验证签名不匹配，这样就防止了中间人替换公钥的问题

8.3、HTTPS通信（握手）过程

参考：HTTPS通信的过程的三个随机数的作用_tls随机数的作用_程序员小x的博客-CSDN博客

客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数A、以及客户端支持的加密方法。
服务器端接收到请求后，确认双方使用的加密方法以及一个服务器生成的随机数B。
服务器发送Certificate报文。报文中包含公开密钥证书。
服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥加密成为Pre-master secret的随机密码串。（预主密钥）
客户端继续发送Change Cipher Spec报文，客户端使用已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值（也就是HASH值），用来供服务器校验。
服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器同样发送Change Cipher Spec报文。
服务器同样发送Finished报文，用来供客户端校验。
从此处开始进行应用层协议的通信，即客户端发送HTTP请求。
应用层协议通信，即发送HTTP响应。
最后由客户端断开连接。断开连接时，发送close_notify报文。这步之后再发送TCP FIN报文来关闭与TCP的通信。

8.3.1、为什么最后客户端和服务端都要发送一个Finish报文？

上面已经提及，Finish报文是对至今全部报文的整体校验值（也就是HASH值）。当客户端把这个值通过得到的公钥进行加密的时候，服务器得到之后对其进行解密，然后再对全部报文进行一个HASH求值。如果这个值跟解密得到的值相等的话，那么说明客户端是可信赖的。
同样的，服务器发送这样的一个整体校验值，用来客户端验证服务器是否是真正要进行通信的那一个。
综上，这个Finish报文就是用来校验双方的身份的。

8.3.2、整个过程中产生的三个随机数有什么用呢？
还有，后面进行HTTP通信的时候，是用哪一个密钥进行加密，还有怎么保证报文的完整性。
对于客户端：
当其生成了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。

对于服务端：
当其解密获得了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。

在客户端和服务端的master secret是依据三个随机数推导出来的，它是不会在网络上传输的，只有双方知道，不会有第三者知道。同时，客户端推导出来的session secret和hash secret与服务端也是完全一样的。

8.3.3、为什么要使用三个随机数呢？

pre-master secret本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。pre-master secret的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre-mastersecret就有可能被猜出来，那么仅适用pre-master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

8.3.4、如果黑客拦截了服务器把证书发送给客户端，并对证书进行恶意修改，会出现什么情况？

需要补充证书知识？？？

第一种情况，假如黑客只是单纯的修改数字证书中的内容，那么由于数字签名的存在，客户端会很容易的判断出报文是否被篡改。

第二种情况，黑客不仅修改了数字证书的内容，并且把数字签名替换掉了，由于黑客不可能知道CA的私钥，于是在客户端用CA的公钥进行解密的时候，解密之后得不到正确的信息，也很容易判断出报文是否被修改。

第三种情况，黑客恶意的从相同的第三方CA申请了一个数字证书。由于这个CA是真实存在的，所以客户端是可以用CA的公钥进行解密，得到了黑客提供的数字证书中的公钥。但是，由于数字证书在申请的时候，会绑定一个域名，当客户端比如说浏览器，检测到这个数字证书中的域名和我们现在网页访问的域名不一致，便会发出警告，此时我们也能得知数字证书被替换了。发出的警告如下：

查看全文

http://www.jsqmd.com/news/1242106/