计算机网络笔记

统计信息：字数 26008 阅读53分钟

原始笔记链接：https://cloud.seatable.cn/dtable/external-links/59b453a8639945478de2/

0015 简单讲解一下http2的多路复用

多路复用，这个是计算机网络底层的知识

模拟信号和数字信号下，复用情况不一样

主要有频分复用，时分复用，波分复用等，也就是在一个信道上，在不同频率或者波长，传递多个信号，实现信道复用

例如，把三个信号分别在 10mHz 20、30 三个频率，然后三个复合成一个模拟信号，在物理信道上传播，就实现了频分复用（接收端再根据不同频率提取信号）。

这个和前端没有直接关系，了解即可

0016 HTTP三次握手和四次挥手

三次握手指的是开始建立连接时，客户端和服务器进行的三次通信 4次挥手是断开连接，是客户端和服务器进行的4次通信 为什么要多次通信，就是因为某一次的通信，没有收到，避免这个问题

0044 Https握手的过程

Https也就是HTTP协议加上 SSL安全套接层 的实现

当客户端通过https向服务端请求支援时，服务端首先会将自己的公钥发送到客户端，客户端会用服务端的公钥对自己的私钥进行加密，然后传输给服务端，这样服务端和客户端分别有了对应的公钥，然后对HTTP报文进行加密之后，再进行TCP互相通信，就实现了安全传输

SSL安全套接层，使用的加密算法是什么？非对称加密算法，具体可以在 nginx 中配置。

具体参考：https://juejin.cn/post/6844903624640823310

实际前端项目不涉及

0045 HTTP协议中安全证书是什么？起到什么作用

HTTP协议客户端到服务端进行传递证书时，可能存在网络请求被拦截的过程，称为中间人攻击，如果获取了双方的公钥和私钥之后，实际上也存在一定的安全问题。

解决思路：使用一个第三方的证书管理机构 ca，来颁布证书，双方会验证第三方证书的公钥和私钥，这样的话是相对安全的，避免篡改，可以减少中间人攻击的风险。

0091 中间人攻击

中间人攻击，参考链接：https://zhuanlan.zhihu.com/p/412540663

简单说，就是客户端和服务器通信时，某个节点被劫持了（例如DNS服务器）通信发送到错误的服务器上并被错误处理

可能造成 token 泄露等情况

0104 Get 方法和 post 方法的区别

get 参数放在 URL 中，不安全，数据量较少，对应一个 TCP 报文

post 参数放在 data 中，相对安全，数据量较多，对应两个 TCP 报文，最大是2M

通常用在 RestfulAPI 中，一个是获取资源，一个是增加资源

0110 怎么处理跨域？

跨域：

浏览器的跨域限制：如果一个域名的网页，需要访问另一个域名下的API（协议域名端口号不一样），那么浏览器会显示跨域错误。这个是浏览器同源策略造成的跨域（为了安全，避免数据泄露）

几种解决方案：

1、通常前端后端发送网络请求时，约定 jsonp 允许数据跨域(只能发送get请求，不支持post put delete)

2、调试过程中，后端 nginx 转发请求，或者 express 设置允许跨域 access-control-allow-origin: *

3、前端浏览器开启调试模式，允许浏览器跨域

4、后台配置 cors，把支持的源写入服务器配置中

# 设置CORS⽩名单
CORS_ORIGIN_WHITELIST = ( 
    'http://127.0.0.1:8081',
    'http://127.0.0.1:8080', 
    'http://localhost:8080', 
    'http://www.nagle.cn:8080', 
    'http://api.nagle.cn:8083',
)

CORS_ALLOW_CREDENTIALS = True # 允许携带cookie

对于跨域，不管是 jsonp 还是其他方式，需要服务器端进行设置。浏览器单独操作，无法直接跨域访问。个人的浏览器设置允许跨域可能造成安全问题。跨域，就是浏览器和服务器共同绕过 同源策略 的解决方案。

0122 应用层中，网络协议有哪些？

1. DHCP 动态主机配置协议：在计算机网络中，新加入的主机通过 DHCP 服务自动获取 IP 等配置信息。基于下层的 UDP 协议（不可靠连接）。获取地址阶段，租约过半阶段，租约到期阶段，在不同阶段发送不同的报文等。

2. DNS 域名系统：域名的原理，域名解析规则，根域名，顶级域名等划分。原理：主机和本地域名服务器使用递归方式解析，本地域名服务器和其他域名使用迭代方式解析。域名缓存存在过期时间，到期后，需要重新解析。不同域名不同情况下，本地域名服务器发出的请求次数。

3. FTP 是文件传输协议，存在两个链接，控制链接和数据链接。控制链接在会话阶段始终保持，主要沟通 FTP 的报文。数据链接只有在传输文件时，才进行链接，传输结束后，断开链接。FTP 用户可以设置文件的格式，以及存取文件的权限。WWW 之前，FTP 应用非常广。

详细的协议参考计算机网络课件。

0123 常见的web攻击有哪些

XSS：cross site scripting 跨站脚本攻击；有漏洞的网站运行攻击者的脚本命令。可以利用虚假表单获取个人信息。利用 JS 获取用户的cookie值。被害者在不知情的情况下，帮助攻击者发送恶意请求（显示伪造的文章或者图片，显示伪造的网页登录情况）。

- 例子：被攻击的A网站中，通过URL传值，获取登录用户名。那么攻击者在URL中设置自己的攻击脚本，获取cookie等信息。`localhost:3000/?id=\` 进一步执行远程脚本 `localhost:3000/?id=\` 获取信息。

- XSS 解决方法，避免把用户传递的变量，直接和 HTML 拼接，然后执行。解决：将用户的输入通过下面函数转换成合法的HTML，先创建文本节点，然后在获取内部HTML。然后把生成的HTML，使用 `\ + str + \` 包起来，这样就避免了XSS

HTMLescape: function(html) {
  return document.createElement('div')
    .appendChild(document.createTextNode(html))
    .parentNode
    .innerHTML;
}

- SQL注入：用户在提交数据时（用户名密码），可能把非法的用户名（例如某一段SQL语句）提交到服务器。服务器在查找数据库时，`select * from db where username is XXX ` 把非法的SQL执行，造成数据损失等。避免方法：永远不要相信用户的输入；对用户的输入进行校验和转换；不要使用超级管理员权限执行某些操作等。

- CSRF

- 点击劫持

- OS注入

- 请求劫持

- DDOS

开课吧笔记有两节安全的课程，可以参考

0124 SMTP 和 POP3 和 IMAP 的区别

了解即可

相同点：这三个都是运行在邮件服务器的服务（例如QQ邮件服务器，163邮件服务器等）

SMTP 服务：处理发送邮件。如果发件人和收件人是同一个域（都是163自己的域），那么直接转；如果不是同一个域（163发给QQ），首先要进行 DNS 查询，然后找到 host 并发送。

POP3 和 IMAP ：处理接受邮件。POP3 比较旧，IMAP 较新。

POP3：本地读到邮件后，邮件从服务器上删除，邮件进行本地编辑。如果多个终端链接服务器有问题。

IMAP：本地读到邮件后，邮件不会从服务器上删除。

详情参考：https://www.zhihu.com/question/24605584

0286 浏览器 Security 面板的内容

这个偏向于计算机网络安全和加密，下面是具体的截图

基本概念：HTTP SSL HTTPS 不赘述，详细参考链接，了解一下即可

参考链接：

• HTTPS TLS 1.2：https://zhuanlan.zhihu.com/p/563453306
• RSA & ECDHE 算法：https://blog.csdn.net/weixin_50999696/article/details/131710006
• AES-128-GCM加密、解密算法：https://www.cnblogs.com/shenjp/p/16423487.html
• SAN和NAS： https://blog.csdn.net/weixin_43025343/article/details/132555188
• 证书透明度： https://blog.csdn.net/qq_35324057/article/details/114293734

0170 HTTP请求包括哪几个部分？

协议（https），域名(www.zhihu.com)，端口号(80)

https://www.zhihu.com/

具体如何传参有什么特征（查询参数）

https 协议

域名 www.zhihu.com

端口号默认是 80

0173 HTTP有多少种方法？具体作用是什么？

get

post

put

delete

这四个主要用于 restful API 查询获取数据

options

head

这两个使用不多

0179 POST 请求的数据格式

POST 请求发送数据时，有三种格式，通过 enctype 属性判断

1、enctype 设置为空，这是默认的 POST 请求发送方式，数据以application/x-www-form-urlencoded格式发送

Content-Type: application/x-www-form-urlencoded
foo=bar&baz=The+first+line.%0D%0AThe+second+line.%0D%0A

2、enctype="text/plain" 以纯文本形式发送

Content-Type: text/plain

foo=bar
baz=The first line.
The second line.

3、enctype="multipart/form-data" 数据将以混合的格式发送（文件上传以这种形式）

<form method="post" enctype="multipart/form-data"></form>

Content-Type: multipart/form-data; boundary=

Content-Disposition: form-data; name="foo"

bar

Content-Disposition: form-data; name="baz"

The first line.
The second line.

参考链接：https://michael18811380328.github.io/book/site/ebook-JS-basic/10-3-%E8%A1%A8%E5%8D%95/#enctype

0182 CDN 是什么？

CDN（Content Delivery Network，内容分发网络）是指一种通过互联网互相连接的电脑网络系统，利用最靠近每位用户的服务器，更快、更可靠地将音乐、图片、视频、应用程序及其他文件发送给用户，来提供高性能、可扩展性及低成本的网络内容传递给用户。

典型的CDN系统由下面三个部分组成：

• 分发服务系统：​

最基本的工作单元就是Cache设备，cache（边缘cache）负责直接响应最终用户的访问请求，把缓存在本地的内容快速地提供给用户。同时cache还负责与源站点进行内容同步，把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache设备的数量、规模、总服务能力是衡量一个CDN系统服务能力的最基本的指标。

• 负载均衡系统：​

主要功能是负责对所有发起服务请求的用户进行访问调度，确定提供给用户的最终实际访问地址。两级调度体系分为全局负载均衡（GSLB）和本地负载均衡（SLB）。

**全局负载均衡：​**主要根据用户就近性原则，通过对每个服务节点进行“最优”判断，确定向用户提供服务的cache的物理位置。

**本地负载均衡：​**主要负责节点内部的设备负载均衡

• 运营管理系统：​

运营管理系统分为运营管理和网络管理子系统，负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作，包含客户管理、产品管理、计费管理、统计分析等功能。

0184 XSS 攻击

1 使用纯前端的方式，不用服务器端拼接后返回（不使用服务端渲染）。

2 对需要插入到 HTML 中的代码做好充分的转义。对于 DOM 型的攻击，主要是前端脚本的不可靠而造成的，对于数据获取渲染和字符串拼接的时候应该对可能出现的恶意代码情况进行判断。

3 使用 CSP ，CSP 的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行，从而防止恶意代码的注入攻击。

4 对一些敏感信息进行保护，比如 cookie 使用 http-only，使得脚本无法获取。也可以使用验证码，避免脚本伪装成用户执行一些操作。

0191 CSRF 攻击

CSRF 攻击指的是**跨站请求伪造攻击**，攻击者诱导用户进入一个第三方网站，然后该网站向被攻击网站发送跨站请求。如果用户在被攻击网站中保存了登录状态，那么攻击者就可以利用这个登录状态，绕过后台的用户验证，冒充用户向服务器执行一些操作。

链接：https://juejin.cn/post/7197061916904898616

CSRF 攻击的**本质是利用 cookie 会在同源请求中携带发送给服务器的特点，以此来实现用户的冒充。**

常见的 CSRF 攻击有三种：

• GET 类型的 CSRF 攻击，比如在网站中的一个 img 标签里构建一个请求，当用户打开这个网站的时候就会自动发起提交。
• POST 类型的 CSRF 攻击，比如构建一个表单，然后隐藏它，当用户进入页面时，自动提交这个表单。
• 链接类型的 CSRF 攻击，比如在 a 标签的 href 属性里构建一个请求，然后诱导用户去点击。

0199 options 请求有什么作用？

问题：为什么在 POST 请求前，需要发送一个 options 请求？options 请求的作用？options 请求直接返回 200？

‌OPTIONS请求‌在HTTP协议中，主要用于获取服务器支持的HTTP方法，和进行跨域资源共享（CORS）的预检。OPTIONS请求的主要作用包括以下几个方面：

1. ‌获取服务器支持的HTTP方法‌：Options 属于“预检请求”的一部分，客户端可以通过发送OPTIONS请求来查询服务器支持哪些HTTP方法（如GET、POST、PUT等），而无需实际访问资源‌。

2. ‌跨域资源共享预检‌：在跨域资源共享（CORS）场景中，当浏览器发起跨域的复杂请求（如使用非简单方法的请求或自定义请求头）之前，会先发送一个OPTIONS请求到服务器，以确认服务器是否允许这样的跨域请求。这个过程称为“预检请求”‌。

3. ‌探测服务器能力‌：客户端可以通过发送OPTIONS请求来查询服务器支持哪些HTTP方法和头信息，以及是否支持CORS等，从而了解服务器的具体能力‌。

实际应用场景：在跨域请求中，浏览器会自动发出OPTIONS请求，确认服务器是否允许该请求的实际执行。例如，当使用非简单方法的请求或自定义请求头进行跨域访问时，浏览器会先发送一个OPTIONS请求到服务器，以检查服务器是否允许该跨域请求‌。

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/OPTIONS

https://cloud.tencent.com/developer/article/1046663

0713 head 请求有什么作用？

‌HEAD请求的主要作用是获取资源的元数据，检查资源是否存在，以及验证资源是否被修改。​‌

HEAD请求的基本概念和用途：HEAD请求是HTTP协议中的一种请求方法，与GET请求类似，但HEAD请求不返回实际的响应主体，只返回资源的元数据。这些元数据包括Content-Type、Content-Length、Last-Modified等，用于描述资源的属性而不包含实际的数据内容。因此，HEAD请求主要用于获取资源的元信息，从而节省带宽和提高性能‌。

HEAD请求的应用场景

1. ‌获取资源的元数据‌：通过发送HEAD请求，可以获取资源的元数据，如文件的大小、修改时间等。这对于只需要了解资源的基本信息而不需要下载实际内容的情况非常有用‌。

2. ‌检查资源是否存在‌：通过发送HEAD请求，可以检查资源是否存在。如果服务器返回404 Not Found状态码，则表示资源不存在；如果返回200 OK状态码，则表示资源存在‌。

3. ‌验证资源是否被修改‌：通过发送HEAD请求，可以获取资源的ETag或Last-Modified头信息，用于验证资源是否被修改‌。

在实际应用中，HEAD请求常用于以下场景：

• ‌浏览器缓存机制‌：浏览器在加载网页之前，可能会先发送一个HEAD请求，来检查网页是否有所更新。如果网页没有更新，浏览器可以直接使用之前缓存的网页内容，从而节省时间和流量‌。

• ‌API调用‌：在API调用中，有时只需要获取资源的元数据而不是实际内容，此时使用HEAD请求更为高效‌。

0324 强缓存和协商缓存的区别？

这个算高频面试题

缓存

优点：避免每一个客户端多次下载文件，节省服务器带宽，加快网站访问速度。

问题：如果服务器文件更改了，客户端没有同步更改，那么可能造成问题。——例如翻译文本不显示。

强缓存

服务器强制缓存，服务器返回资源中，设置

respone header 的 cache-control，例如 cache-control:max-age=31536000,public,immutable

max-age 表示缓存的时间是31536000秒（1年）

public 表示可以被浏览器和代理服务器缓存，代理服务器一般可用nginx来做。

immutable表示该资源永远不变，但是实际上该资源并不是永远不变，它这么设置的意思是为了让用户在刷新页面的时候不要去请求服务器

其他具体配置：

• cache-control: max-age=xxxx，public 客户端和代理服务器都可以缓存该资源； 客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存,statu code:200 ，如果用户做了刷新操作，就向服务器发起http请求
• cache-control: max-age=xxxx，private 只让客户端可以缓存该资源；代理服务器不缓存 客户端在xxx秒内直接读取缓存,statu code:200
• cache-control: max-age=xxxx，immutable 客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存,statu code:200 ，即使用户做了刷新操作，也不向服务器发起http请求
• cache-control: no-cache 跳过设置强缓存，但是不妨碍设置协商缓存；一般如果你做了强缓存，只有在强缓存失效了才走协商缓存的，设置了no-cache就不会走强缓存了，每次请求都回询问服务端。
• cache-control: no-store 不缓存，这个会让客户端、服务器都不缓存，也就没有所谓的强缓存、协商缓存了。

协商缓存

客户端请求该资源时发现其过期了，这是就会去请求服务器了，而这时候去请求服务器的这过程就可以设置协商缓存。

• etag：每个文件有一个，改动文件了就变了，就是个文件hash，每个文件唯一，就像用webpack打包的时候，每个资源都会有这个东西，如： app.js打包后变为 app.c20abbde.js，加hash，也是为了解决缓存问题。
• last-modified：文件的修改时间，精确到秒

每次请求返回来 response header 中的 etag 和 last-modified，在下次请求时在 request header 就把这两个带上，服务端把你带过来的标识进行对比，然后判断资源是否更改了，如果更改就直接返回新的资源，和更新对应的response header的标识etag、last-modified。如果资源没有变，那就不变etag、last-modified，这时候对客户端来说，每次请求都是要进行协商缓存了

发请求→看资源是否过期→过期→请求服务器→服务器对比资源是否真的过期→没过期→返回304状态码→客户端用缓存的老资源。

发请求→看资源是否过期→过期→请求服务器→服务器对比资源是否真的过期→过期→返回200状态码→客户端如第一次接收该资源一样，记下它的cache-control中的max-age、etag、last-modified等

所以协商缓存步骤总结：

请求资源时，把用户本地该资源的 etag 同时带到服务端，服务端和最新资源做对比。

如果资源没更改，返回304，浏览器读取本地缓存。

如果资源有更改，返回200，返回最新的资源。

后端设置强缓存与协商缓存

后端服务器如 nodejs 设置响应头:

res.setHeader('max-age': '3600 public')
res.setHeader('etag': '5c20abbd-e2e8')
res.setHeader('last-modified': Mon, 24 Dec 2018 09:49:49 GMT)

nginx 中间件

add_header Cache_Control: "no-cache no-control"

前端设置缓存

index.html文件采用协商缓存，理由就是要用户每次请求index.html不拿浏览器缓存，直接请求服务器，这样就保证资源更新了，用户能马上访问到新资源，如果服务端返回304，这时候再拿浏览器的缓存的index.html，**切记不要设置强缓存！！！**其他资源采用强缓存 + 协商缓存,理由就不多说了。

参考链接：

https://www.jianshu.com/p/9c95db596df5

https://juejin.im/post/5c417993f265da61285a6075

http://www.cnblogs.com/ziyunfei/p/5642796.html

0353 websocket 握手过程

参考：https://blog.csdn.net/qq_54773998/article/details/123863493

对比 HTTP 请求

建立连接后，客户端和服务器可以互相发送消息，实现真实的长连接

主要用于实时通信（聊天室，共同编辑文档等）

0381 浏览器同域名请求的最大并发数限制

问题：客户端每隔1s发送一个请求轮询，实际上服务器接受到的请求并不是每隔1s，刚开始 1s 一个，后续突然很多集中发过来。这个是什么问题？

原因：JS 和 python 部分设置基本没问题。这个是浏览器内部限制。

参考：https://cloud.tencent.com/developer/article/1683127

不同浏览器对同域名请求的最大并发数限制，大部分是4-8。所以当某一个请求还没有返回时，后续的请求就在浏览器本地阻塞没有发出（但是JS还在定时器中循环发送）。当某个耗时的请求返回结果后，已有阻塞的请求会并行发送，就会出现截图后面的问题。

解决思路：前端避免通过 setInterval 发送请求。应该在 API 返回结果后，根据结果情况，自调用执行函数发送请求，这样即使某个耗时请求卡顿，也不会在浏览器阻塞太多请求。

0711 TCP 如何实现流量控制和拥塞控制？

TCP 协议可以流量控制和拥塞控制，UDP 协议不可以实现。

算法：**滑动窗口、拥塞窗口**这两个简单的窗口算法

滑动窗口由接收端控制，向发送端通告，这样就可以保证发送端发出的包数量上限是明确的，也就不会存在淹没接收端导致来不及处理的情况。

滑动窗口算法，主要用来处理接收端收报文比较慢的情况，发送端可以控制发送报文的数量。

拥塞窗口由发送端控制，它会根据网络中的情况动态的调整，通过慢启动、拥塞避免、拥塞发生、快速恢复四个算法，就可以很好地调整窗口的大小。和滑动窗口一起限制了发送端最大的发送范围，从而保证了拥塞在网络上不会发生。

如下图，理想状况下实际数据量 = 吞吐量，实际上类似高速公路，网络中某个节点的性能可能不佳，造成这个节点出现丢包造成拥塞，如下图。服务器发送请求时，不确定具体拥塞的最值是多少。

那么可以设置一个初始慢启动门槛。当发送量小于慢启动门槛时，使用指数增加形式进行发送，当到达慢启动门槛时，变成线性发送模式。当出现拥塞是（出现了超时重传现象），那么将慢启动门槛设置成 CWND 最大值的二分之一，拥塞窗口重置为1。

快速重传算法，前半部分和超时重传类似，当达到拥塞点，CWND 还是变成原来的一半，快恢复点不一样。

​

详细参考计算机网络笔记，或者参考：https://blog.csdn.net/guojiaqi_/article/details/140928582

​

0714 常用网络协议和对应的端口？

常用服务，协议，端口号

服务	协议	端口号
HTTP 网络	TCP	80
HTTPS 网络	TCP	443
Telnet 远程登录	TCP	23
DNS 域名服务	UDP	53
SMTP 邮件服务	TCP	25
POP3 邮件服务	TCP	110
IMAP4 邮件服务	TCP	143
FTP 文件传输（控制连接）	TCP	21
FTP 文件传输（数据连接）	TCP	20
LDAP 轻型目录访问协议	TCP + UDP	389
LDAPS（ldap + ssl）	TCP	636

​

---

Last update: November 9, 2024