Frage
Während des Entwicklungsprozesses stellten wir fest, dass die Backend-API-Anfrage sehr langsam war, also haben wir uns beim Backend beschwert.
"Warum ist die API so langsam? Es dauert mehr als zehn Sekunden, um eine Schnittstelle anzufordern."
Darüber hinaus tritt diese Situation gelegentlich auf.Front-End-Entwicklungsstudenten sagten, dass es manchmal vorkommt, aber es ist nicht notwendig.
Nach einer Operation stellten die Backend-Studenten jedoch fest, dass es kein Problem mit der Schnittstelle gab.Sie probierten es über das Postman-Tool und die Testumgebung aus und stellten fest, dass die Geschwindigkeit der Schnittstellenanfrage kein Problem war.
"Das fühlt sich an wie ein Front-End-Problem"?
Lösen wir das Problem wie folgt:
- Backend-API-Anfragen sind besonders langsam und sporadisch.
- In der Testumgebung findet keine Reproduktion statt.
- Die Anforderung des Postboten-Tools wurde nicht reproduziert.
Problemlösungsprozess
Wo ist die Zeit?
Die erste Frage, wofür wird die Zeit verwendet, die für die API aufgewendet wird?
Wir öffnen den Chrome-Debugger. Sie können den Zeitaufwand jeder Schnittstelle im Netzwerk sehen.
Bewegen Sie den Mauszeiger auf Waterful Ihrer zeitaufwändigen Benutzeroberfläche, und Sie können den spezifischen Zeitaufwand der Benutzeroberfläche sehen.
Es ist ersichtlich, dass der Zeitaufwand hauptsächlich in der Wartezeit von dem Zeitpunkt, an dem Stalledder Browser die Anweisung zum Ausgeben dieser Anfrage erhält, bis zu dem Zeitpunkt liegt, an dem die Anfrage ausgegeben werden kann , was im Allgemeinen die Zeit für die Proxy-Aushandlung und das Warten auf die Freigabe ist die wiederverwendbare TCP-Verbindung, ohne DNS-Abfrage, Aufbau einer TCP-Verbindung usw.
Daher hat die API auf die vom Browser an sie gesendeten Anweisungen gewartet.Nehmen Sie den obigen Screenshot als Beispiel: Sie hat auf 23,84 s gewartet, und ihre Anfrage- und Antwortzeit ist sehr schnell (höchstens einige hundert Millisekunden, was ist, was die Backend-Schnittstelle sagte, ist nicht langsam).
Was genau wartet die API also darauf, dass der Browser es tut?
Was blockiert die Anfrage?
Nach der Positionierung haben wir festgestellt, dass Server-Sent Events (im Folgenden als SSE bezeichnet) in unserem Projekt verwendet wird. Wie WebSocket überträgt es Informationen vom Server an den Browser. Aber der Unterschied ist, dass es das HTTP-Protokoll verwendet.
当不通过 HTTP / 2 使用时，SSE 会受到最大连接数的限制，限制为 6 次。此限制是针对每个浏览器 + 域的，因此这意味着您可以跨所有选项卡打开 6 个 SSE 连接到 www.example1.com，并打开 6 个 SSE 连接到 www.example2.com。这一点可以通过以下这个 demo 复现。
复制问题的步骤：
- 访问ssebin.btubbs.com/multi/
- 单击添加计数器6或更多次
- 尝试打开另一个标签到同一地址
结果是，第 6 次之后，SSE 请求一直无法响应，打开新的标签到同一个地址的时候，浏览器也无法访问。
效果图如下：
该问题在 Chrome 和 Firefox 中被标记为“无法解决”。
至于偶现，是因为前端开发者有时候用 Chrome 会打开了多个选项卡，每个选项卡都是同一个本地开发地址，就会导致达到 SSE 的最大连接数的限制，而它的执行时间会很长，也就会阻塞其他的请求，一致在等待 SSE 执行完。
所以解决的方法是什么？
解决方案
简单粗暴的两个方法
- 不要打开太多个选项卡。这样就不会达到它的限制数。（因为我们一个选项卡只请求一个 SSE）。
- 开发环境下，关闭该功能。
使用 HTTP / 2
使用 HTTP / 2 时，HTTP 同一时间内的最大连接数由服务器和客户端之间协商（默认为 100）
这解释了为什么我们 test 环境没有问题，因为 test 环境用的是 HTTP / 2。而在开发环境中，我们使用的是 HTTP 1.1 就会出现这个问题。
那如何在开发环境中使用 HTTP / 2 呢？
我们现在在开发环境，大部分还是使用 webpack-dev-server 起一个本地服务，快速开发应用程序。在文档中，我们找到 server 选项，允许设置服务器和配置项（默认为 'http'）。
只需要加上这一行代码即可。
devServer: {
+ server: 'spdy',
port: PORT,
}
复制代码看看效果，是成功了的。
原理使用 spdy 使用自签名证书通过 HTTP/2 提供服务。需要注意的一点是：
该配置项在 Node 15.0.0 及以上的版本会被忽略，因为 spdy 在这些版本中不会正常工作。一旦 Express 支持 Node 内建 HTTP/2，dev server 会进行迁移。
总结归纳
原本这个问题认为跟前端无关，没想到最后吃瓜吃到自己头上。提升相关技能的知识储备以及思考问题的方式，可能会方便我们定位到此类问题。
充分利用好浏览器的调试工具，对一个问题可以从多个角度出发进行思考。比如一开始，没想到本地也可以开启 HTTP / 2。后来偶然间想搜下是否有此类方案，结果还真有！
我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。