From fdd0d72ee92ae67d4c45dec842f0fcabb131b666 Mon Sep 17 00:00:00 2001 From: white0dew <1373685219@qq.com> Date: Thu, 15 Aug 2024 08:44:54 +0000 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=E6=96=87=E6=A1=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../kxspepu7t1b7783v.md" | 562 ++++++++++++++++++ .../Go/gw3x2w4gvo9f3p6d.md" | 6 +- .../hn222ds8l0mhz091.md" | 6 +- .../ihwoz00dunyzo09m.md" | 17 +- .../JavaScript/bbsxpgzzhu3i88xy.md" | 7 +- .../JavaScript/ced0rgbttkbm4gsn.md" | 9 +- .../JavaScript/fkoyngxgpmgaeg44.md" | 7 +- .../JavaScript/lzdv93b8t8soe0mn.md" | 11 +- .../JavaScript/myrlyqga6ewhaxdm.md" | 6 +- .../JavaScript/obhmxn0wg1gxp2n6.md" | 4 +- .../JavaScript/pogg73bgofw753sb.md" | 6 +- .../JavaScript/tvi5rnx6lvl2sczq.md" | 8 +- .../JavaScript/wyh4y9de5m1h1n0e.md" | 15 +- .../JavaScript/xwdzodwra6u55sib.md" | 8 +- .../JavaScript/xwymt3c06amgkp2n.md" | 6 +- .../JavaScript/yl3i2ox3zh528deh.md" | 13 +- .../MySQL/kewfeh2gmbrr6p0q.md" | 4 +- .../MySQL/qf6b0vmagi3cbnbv.md" | 4 +- elog.cache.json | 229 ++++--- 19 files changed, 758 insertions(+), 170 deletions(-) create mode 100644 "docs/doc/\360\237\222\271 \345\244\247\345\216\202\351\235\242\347\273\217/kxspepu7t1b7783v.md" diff --git "a/docs/doc/\360\237\222\271 \345\244\247\345\216\202\351\235\242\347\273\217/kxspepu7t1b7783v.md" "b/docs/doc/\360\237\222\271 \345\244\247\345\216\202\351\235\242\347\273\217/kxspepu7t1b7783v.md" new file mode 100644 index 0000000..d89ec12 --- /dev/null +++ "b/docs/doc/\360\237\222\271 \345\244\247\345\216\202\351\235\242\347\273\217/kxspepu7t1b7783v.md" @@ -0,0 +1,562 @@ +--- +title: 计算机网络面试必问 +urlname: kxspepu7t1b7783v +date: '2024-08-07 12:53:57' +updated: '2024-08-07 20:06:22' +cover: 'https://cdn.nlark.com/yuque/0/2024/png/22382235/1722953399419-c3811ae6-707c-48c1-8a48-d32f46d24b40.png?x-oss-process=image%2Fformat%2Cwebp' +description: HTTP常用的状态码及其含义HTTP状态码是用来表示服务器响应客户端请求的状态。常用的状态码分为以下几类:状态码含义200OK:请求成功,服务器已返回所请求的数据。201Created:请求成功并且服务器创建了新的资源。204No Content:服务器成功处理了请求,但没有返回任何内容。30... +--- +# HTTP常用的状态码及其含义 +HTTP状态码是用来表示服务器响应客户端请求的状态。常用的状态码分为以下几类: + +| 状态码 | 含义 | +| --- | --- | +| 200 | OK:请求成功,服务器已返回所请求的数据。 | +| 201 | Created:请求成功并且服务器创建了新的资源。 | +| 204 | No Content:服务器成功处理了请求,但没有返回任何内容。 | +| 301 | Moved Permanently:请求的资源已被永久移动到新的URL。 | +| 302 | Found:请求的资源临时从不同的URI响应请求。 | +| 400 | Bad Request:服务器无法理解客户端的请求。 | +| 401 | Unauthorized:请求要求用户的身份认证。 | +| 403 | Forbidden:服务器理解请求但拒绝执行。 | +| 404 | Not Found:服务器找不到请求的资源。 | +| 500 | Internal Server Error:服务器内部错误,无法完成请求。 | +| 502 | Bad Gateway:作为网关或代理工作的服务器从上游服务器收到无效响应。 | +| 503 | Service Unavailable:服务器当前无法处理请求(过载或维护)。 | + +# HTTP常用的请求方式,区别和用途 +HTTP请求方式有多种,常用的有以下几种: + +| 方法 | 描述 | 区别和用途 | +| --- | --- | --- | +| GET | 请求指定的资源。 | 用于请求数据,不应修改服务器上的任何资源,且参数通过URL传递。 | +| POST | 向指定资源提交数据进行处理请求。 | 用于提交数据(如表单数据),会改变服务器上的资源,数据在请求体中。 | +| PUT | 向指定资源位置上传其最新内容。 | 用于更新数据,若资源不存在则创建,数据在请求体中。 | +| DELETE | 请求服务器删除指定的资源。 | 用于删除服务器上的资源。 | +| HEAD | 类似于GET请求,只不过返回的响应中没有具体的内容,用于获取报头。 | 用于获取报头信息,检查资源的存在性和状态。 | +| OPTIONS | 请求查询服务器的性能,或查询与资源相关的选项。 | 用于获取服务器支持的HTTP方法。 | +| PATCH | 对资源进行部分修改。 | 用于部分更新资源,与PUT类似,但更适合局部更新。 | + +# 端口及对应的服务 +计算机网络中,不同的服务使用不同的端口号来进行通信。常见的端口及其对应服务如下: + +| 端口号 | 服务 | 描述 | +| --- | --- | --- | +| 20/21 | FTP | 文件传输协议,用于文件传输。 | +| 22 | SSH | 安全外壳协议,用于安全登录和传输。 | +| 23 | Telnet | 远程登录服务(不安全)。 | +| 25 | SMTP | 简单邮件传输协议,用于发送电子邮件。 | +| 53 | DNS | 域名系统,用于域名解析。 | +| 80 | HTTP | 超文本传输协议,用于网页浏览。 | +| 110 | POP3 | 邮局协议,用于接收电子邮件。 | +| 143 | IMAP | 互联网消息访问协议,用于接收电子邮件。 | +| 443 | HTTPS | 安全的HTTP协议,用于安全的网页浏览。 | +| 3306 | MySQL | MySQL数据库服务。 | +| 6379 | Redis | Redis缓存服务。 | +| 8080 | HTTP Alternate | 常用于HTTP代理和Web服务器的备用端口。 | + +# 计算机网络体系结构 +计算机网络体系结构通常采用分层模型,其中最著名的是OSI七层模型和TCP/IP四层模型。记住下面这幅图 +![截屏2024-08-06 22.09.52.png](https://oss1.aistar.cool/elog-offer-now/a90fbb637b9be4866d65e5425d5e60c3.png) + +我简单说说两种模型的比较和主要内容: +## OSI七层模型 + +1. **物理层**:传输原始比特流,定义硬件设备标准。 +2. **数据链路层**:提供节点间数据传输,纠错、流控制。 +3. **网络层**:负责数据包路由选择和转发,IP协议。 +4. **传输层**:提供端到端的通信,TCP/UDP协议。 +5. **会话层**:管理会话和数据交换。 +6. **表示层**:数据格式转换,数据加密解密。 +7. **应用层**:提供网络服务和应用接口,HTTP/FTP等协议。 + +## TCP/IP四层模型 + +1. **网络接口层**:对应OSI的物理层和数据链路层。 +2. **网络层**:与OSI网络层相当,主要协议是IP。 +3. **传输层**:与OSI传输层相当,主要协议有TCP和UDP。 +4. **应用层**:整合了OSI的应用层、表示层和会话层。 + +# 如何理解HTTP协议是无状态的? +**「面试官」**: 如何理解HTTP协议是无状态的? +**「参考回答」**: +要理解HTTP协议的无状态特性,我们需要从以下几个方面来分析: + +1. **无状态的定义**HTTP协议的无状态性指的是**协议对于事务处理没有记忆能力**。每个请求都是独立的,服务器不会在多个请求之间保留任何信息。 +2. **无状态的表现** + - 服务器在处理HTTP请求时,不会记住之前的请求。 + - 每次请求都需要客户端提供所有必要的信息。 + - 服务器不会主动保存客户端的状态信息。 +3. **无状态的优缺点** + +优点: +TODO +缺点: + + - 简化了服务器的设计 + - 提高了服务器的扩展性 + - 减少了服务器资源的占用 + - 无法轻易实现需要状态的交互 + - 可能增加通信量(每次都要传输全部信息) +1. **无状态的应用场景:**HTTP的无状态特性非常适合于**静态内容的传输**,如网页、图片等。 +2. **如何在无状态协议上实现有状态的交互:**尽管HTTP本身是无状态的,但我们可以通过一些技术来模拟有状态的交互: + - 使用Cookies + - 使用Session + - 使用令牌(Token) + +为了更直观地理解HTTP的无状态特性,我们可以用一个简单的图表来说明: +![](https://oss1.aistar.cool/elog-offer-now/297b6ba76c3849c6b00eb69be60f3283.svg)这个图表展示了HTTP的无状态特性。即使是同一个客户端连续发送两个请求,服务器也无法识别这两个请求来自同一个客户端。每次请求对服务器来说都是全新的,没有任何上下文。 + +理解HTTP的无状态特性对于web开发非常重要,它帮助我们设计更加健壮和可扩展的系统,同时也促使我们思考如何在需要状态的场景下合理地使用各种技术来模拟有状态的交互。 + +## 你能详细说明一下如何在HTTP这种无状态协议上实现有状态的交互吗 +**「面试官」**:那么,你能详细说明一下如何在HTTP这种无状态协议上实现有状态的交互吗?特别Cookies、Session和Token这三种方式的具体实现和区别。 +**「参考回答」**: +主要有三种常用的方法:Cookies、Session和Token。让我们逐一分析: + +1. **Cookies**Cookies是存储在客户端(通常是浏览器)的小型文本文件。 + - **工作原理**: + - 服务器在HTTP响应中设置Set-Cookie头 + - 浏览器保存这个Cookie + - 之后的每次请求,浏览器都会在请求头中包含这个Cookie + - **优点**: + - 实现简单 + - 可以存储用户偏好等非敏感信息 + - **缺点**: + - 安全性较低,容易被篡改 + - 存储容量有限 + - 可能被用户禁用 +2. **Session**Session是服务器端的机制,用于跟踪用户的状态。 + - **工作原理**: + - 服务器创建Session并生成唯一的Session ID + - 服务器通过Set-Cookie头将Session ID发送给客户端 + - 客户端之后的请求都会包含这个Session ID + - 服务器根据Session ID识别用户并获取相关数据 + - **优点**: + - 安全性高,敏感数据存储在服务器 + - 可存储大量数据 + - **缺点**: + - 增加服务器负载 + - 在分布式系统中实现复杂 +3. **Token**Token是一种更现代的方法,特别适用于无状态的RESTful API。 + - **工作原理**: + - 用户登录后,服务器生成Token + - Token通常包含用户标识、过期时间等信息,并进行加密 + - 客户端存储Token(如localStorage) + - 之后的请求中,客户端在Authorization头中携带Token + - **优点**: + - 无需在服务器存储会话信息,更易于扩展 + - 可以跨域使用 + - 安全性高,特别是使用JWT(JSON Web Token)时 + - **缺点**: + - Token的管理(如过期、刷新)需要额外处理 + - 如果存储在localStorage,有XSS攻击的风险 + +为了更直观地理解这三种方法的区别,我们可以用一个图表来对比: +![](https://oss1.aistar.cool/elog-offer-now/c980eb2fb2de0e5d9415e024a692b981.svg)这个图表展示了三种方法在存储位置和状态管理方面的主要区别。 + +在实际应用中,这些方法often会结合使用。例如,使用Cookie存储Session ID,或者使用Token实现的认证系统配合Session来管理用户状态。选择哪种方法主要取决于应用的具体需求、安全要求以及系统架构。 + +理解这些方法的原理和区别,对于设计安全、高效的Web应用至关重要。它不仅帮助我们克服HTTP的无状态特性带来的限制,还能让我们更好地处理用户认证、授权等关键问题。 + +# 详细说明一下HTTP/1.0、HTTP/1.1和HTTP/2.0的主要区别 +**「面试官」**: 能否详细说明一下HTTP/1.0、HTTP/1.1和HTTP/2.0的主要区别?特别是它们在连接管理、性能优化等方面的改进。 +**「参考回答」**: +HTTP协议的演进主要体现在连接管理、性能优化、安全性等方面。让我们逐个版本分析: + +1. **HTTP/1.0**HTTP/1.0是HTTP协议的第一个广泛使用的版本。 + - **主要特点**: + - **连接管理**: 采用短连接模式。每次请求都需要建立一个新的TCP连接,请求完成后立即关闭。 + - **请求方法**: 支持GET、POST、HEAD等基本方法。 + - **缓存机制**: 引入了基本的缓存控制机制,如Expires头。 + - **局限性**: + - 每个请求都需要重新建立连接,效率低下。 + - 不支持断点续传。 + - 无法复用连接,增加了网络负载。 +2. **HTTP/1.1**HTTP/1.1是对HTTP/1.0的重大改进,至今仍被广泛使用。 + - **主要改进**: + - **持久连接**: 默认采用长连接(Connection: keep-alive),多个请求可以复用同一个TCP连接。 + - **管道机制**: 允许在同一个连接中发送多个请求,不需要等待上一个响应返回(但服务器必须按请求顺序返回响应)。 + - **断点续传**: 支持范围请求,允许传输文件的某个部分。 + - **新增请求方法**: 增加了PUT、DELETE、OPTIONS等方法。 + - **虚拟主机**: 引入Host头,允许在同一IP地址上托管多个域名。 + - **缓存增强**: 引入了更多的缓存控制机制,如ETag。 + - **局限性**: + - 队头阻塞(Head-of-line blocking)问题: 虽然可以并行发送请求,但服务器必须按顺序返回响应。 + - 头部冗余: 每次请求都会携带大量重复的头信息。 +1. **HTTP/2.0**HTTP/2.0是对HTTP/1.1的重大升级,旨在提高性能和效率。 + - **主要改进**: + - **多路复用**: 在一个TCP连接上可以同时发送多个请求和响应,解决了队头阻塞问题。 + - **二进制分帧**: 将信息分割为更小的帧,并采用二进制格式编码,提高了传输效率。 + - **头部压缩**: 使用HPACK算法压缩头部,减少了数据传输量。 + - **服务器推送**: 服务器可以主动向客户端推送资源,无需客户端请求。 + - **请求优先级**: 允许客户端设置请求的优先级,进一步优化性能。 + - **优势**: + - 显著提高了页面加载速度。 + - 减少了网络负载。 + - 更高效地利用网络资源。 + +为了更直观地理解这三个版本的主要区别,我们可以用一个图表来对比: +![](https://oss1.aistar.cool/elog-offer-now/ab67808b69fd7316fdb778cb801c7a20.svg) + +# 你能详细解释一下HTTPS的工作流程吗? +**「面试官」**: 你能详细解释一下HTTPS的工作流程吗?特别是它如何保证通信的安全性,以及在这个过程中使用了哪些加密技术? +**「参考回答」**: +HTTPS(Hypertext Transfer Protocol Secure)是HTTP的安全版本,它通过在HTTP和TCP之间添加一个安全层(通常是SSL/TLS)来保证通信的安全性。 +HTTPS的工作流程主要包含以下步骤: + +1. **客户端发起HTTPS请求** + - 客户端(通常是浏览器)向服务器的443端口发起请求。 +1. **服务器发送证书** + - 服务器向客户端发送SSL证书,该证书包含了公钥、颁发机构、有效期等信息。 +1. **客户端验证证书** + - 客户端会验证证书的合法性,包括: + - 证书是否过期 + - 证书的颁发机构是否可信 + - 证书的域名是否匹配 +1. **客户端生成随机密钥** + - 如果证书验证通过,客户端会生成一个随机的对称加密密钥。 +1. **使用公钥加密随机密钥** + - 客户端使用证书中的公钥对这个随机生成的对称密钥进行加密。 +1. **发送加密后的随机密钥** + - 客户端将加密后的随机密钥发送给服务器。 +1. **服务器解密随机密钥** + - 服务器使用自己的私钥解密,获得客户端发送的随机对称密钥。 +1. **双方使用对称密钥加密通信** + - 此后,客户端和服务器就可以使用这个对称密钥来加密和解密他们之间的通信了。 + +在这个过程中,HTTPS使用了几种不同的加密技术: + +1. **非对称加密(公钥加密)** + - 用于在不安全的通道上安全地传输对称密钥。 + - 常用算法:RSA、ECC(椭圆曲线加密) + - 优点:安全性高 + - 缺点:计算速度较慢 +1. **对称加密** + - 用于加密实际的通信内容。 + - 常用算法:AES、DES + - 优点:加解密速度快 + - 缺点:密钥管理困难 +1. **散列函数** + - 用于生成消息摘要,确保消息完整性。 + - 常用算法:SHA-256、MD5(不推荐使用) +1. **数字签名** + - 结合非对称加密和散列函数,用于身份认证和防止篡改。 + +HTTPS如何保证通信的安全性: + +1. **机密性** + - 通过对称加密保证通信内容不被窃听。 +1. **完整性** + - 通过消息认证码(MAC)或数字签名确保消息未被篡改。 +1. **认证** + - 通过数字证书确保服务器的身份。 +1. **防重放** + - 使用时间戳或序列号防止重放攻击。 + +为了更直观地理解HTTPS的工作流程,我们可以用一个图表来说明: +![](https://oss1.aistar.cool/elog-offer-now/851624f15b91230d69cc45b502343b3d.svg) +HTTPS的安全性主要依赖于以下几个方面: + +1. **证书的可靠性**:依赖于CA(证书颁发机构)的信誉和安全措施。 +2. **密钥的安全性**:私钥必须妥善保管,不能泄露。 +3. **加密算法的强度**:随着计算能力的提升,需要不断更新使用更强的加密算法。 +4. **完美前向保密(Perfect Forward Secrecy, PFS)**:即使长期使用的私钥泄露,之前的通信仍然安全。这通常通过临时的Diffie-Hellman密钥交换来实现。 + +理解HTTPS的工作原理对于开发安全的Web应用至关重要。它不仅能帮助我们正确配置和使用HTTPS,还能让我们更好地理解潜在的安全威胁和防御措施。例如,了解中间人攻击的原理,我们就能更好地理解为什么证书验证如此重要。 + +同时,HTTPS虽然大大提高了通信的安全性,但它并不能解决所有的安全问题。例如,它无法防止应用层的漏洞,如SQL注入或跨站脚本攻击(XSS)。因此,在使用HTTPS的同时,我们还需要采取其他的安全措施来全面保护我们的Web应用。 +# 你能详细说明一下GET和POST这两种常用的HTTP请求方法的区别吗? +**「面试官」**: 接下来,我想了解一下关于HTTP请求方法的问题。你能详细说明一下GET和POST这两种常用的HTTP请求方法的区别吗?特别是在使用场景、安全性、数据传输等方面的差异。 +**「参考回答」**: +GET和POST是HTTP协议中最常用的两种请求方法,它们在使用场景、安全性、数据传输等方面有很大的不同。 +让我们从以下几个方面来比较GET和POST: + +1. **用途和语义** + - **GET**: + - 主要用于获取资源 + - 应该是幂等的,即多次请求应该返回相同的结果 + - 通常用于读取或查询操作 + - **POST**: + - 主要用于提交数据 + - 可以是非幂等的,即可能会改变服务器状态 + - 通常用于创建、更新或删除操作 +1. **数据传输** + - **GET**: + - 数据附加在URL之后,作为查询字符串 + - 数据长度受限于URL的最大长度(通常为2048字符) + - 数据类型限于ASCII字符 + - **POST**: + - 数据包含在HTTP请求体中 + - 数据长度理论上没有限制 + - 可以传输任何类型的数据,包括二进制数据 +1. **安全性** + - **GET**: + - 参数暴露在URL中,不适合传输敏感信息 + - 参数可能被浏览器历史、服务器日志等记录 + - 更容易受到跨站请求伪造(CSRF)攻击 + - **POST**: + - 参数不会显示在URL中,相对更安全 + - 参数不会被浏览器缓存或保存在浏览器历史中 + - 相对不容易受到CSRF攻击,但仍需要其他安全措施 +1. **缓存** + - **GET**: + - 请求可以被缓存 + - 可以被收藏为书签 + - 可以被浏览器主动缓存 + - **POST**: + - 请求通常不被缓存 + - 不能被收藏为书签 + - 不会被浏览器主动缓存 +1. **编码类型** + - **GET**: + - application/x-www-form-urlencoded + - **POST**: + - application/x-www-form-urlencoded + - multipart/form-data + - application/json + - 等多种类型 +1. **使用场景** + - **GET**: + - 搜索表单 + - 静态内容请求 + - RESTful API中的读取操作 + - **POST**: + - 登录表单 + - 文件上传 + - 大量数据传输 + - RESTful API中的创建、更新操作 + +为了更直观地理解GET和POST的区别,我们可以用一个对比图表来说明: +![](https://oss1.aistar.cool/elog-offer-now/adfea08612bcaac7c668711aa050aa9c.svg) +理解GET和POST的区别对于Web开发者来说非常重要,它能帮助我们在不同的场景下选择合适的请求方法,并正确处理相关的安全和性能问题。例如: + +1. 在设计RESTful API时,我们通常使用GET来获取资源,POST来创建资源。 +2. 对于包含敏感信息的表单,如登录表单,我们应该使用POST方法来提交数据。 +3. 在处理大量数据或上传文件时,POST是更好的选择。 +4. 对于需要被搜索引擎索引的页面,使用GET方法更有利于SEO。 +5. 在实现缓存策略时,我们需要考虑GET请求更容易被缓存的特性。 + +需要注意的是,虽然POST相对GET来说更安全,但这并不意味着POST就是绝对安全的。在实际应用中,我们还需要采取其他安全措施,如使用HTTPS、实现CSRF保护等,来确保Web应用的整体安全性。 +# 什么是跨域请求,为什么会有跨域限制,以及如何解决跨域问题吗? +**「面试官」**: 在实际的Web开发中,我们经常需要处理跨域请求的问题。你能详细解释一下什么是跨域请求,为什么会有跨域限制,以及如何解决跨域问题吗? +**「参考回答」**: +当然,我很乐意详细解释跨域请求的相关问题。跨域请求是Web开发中常见的一个挑战,理解它对于构建现代Web应用至关重要。 + +1. **什么是跨域请求?** + +跨域请求是指在一个域名的网页中,请求另一个域名的资源。这里的"域"包括: + +- 协议(如http, https) +- 域名(如example.com, api.example.com) +- 端口号(如80, 8080) + +只要这三者之一不同,就被认为是跨域。例如: + +- [http://example.com](http://example.com) 请求 [https://example.com](https://example.com) 的资源(协议不同) +- [http://example.com](http://example.com) 请求 [http://api.example.com](http://api.example.com) 的资源(子域名不同) +- [http://example.com](http://example.com) 请求 [http://example.com:8080](http://example.com:8080) 的资源(端口不同) +1. **为什么会有跨域限制?** + +跨域限制是浏览器的一种安全机制,称为**同源策略**(Same-Origin Policy)。它的主要目的是防止恶意网站访问另一个网站的敏感数据。 +没有这种限制可能导致的安全问题包括: + +- 恶意网站可能会读取用户在其他网站上的私密信息 +- 恶意网站可能会执行未经授权的操作,如转账、发送消息等 +1. **如何解决跨域问题?** + +有几种常用的方法来解决跨域问题: +a) **CORS (Cross-Origin Resource Sharing)** + +- 这是最常用和推荐的方法 +- 服务器通过设置特定的HTTP头来允许跨域请求 +- 主要的头部包括: + - Access-Control-Allow-Origin + - Access-Control-Allow-Methods + - Access-Control-Allow-Headers + +b) **JSONP (JSON with Padding)** + +- 利用`