国产偷窥熟女高潮精品视频,国产精品,国产精品,国产精品久久久久久久久久久久人四虎

問題

我們在開發(fā)過程中，發(fā)現(xiàn)后端 API 請求特別慢，于是跟后端抱怨。

“怎么 API 這么慢啊，請求一個接口要十幾秒”。

而且這種情況是偶現(xiàn)的，前端開發(fā)同學(xué)表示有時候會出現(xiàn)，非必現(xiàn)。

(資料圖片)

但是后端同學(xué)通過一頓操作后發(fā)現(xiàn)，接口沒有問題，他們是通過 postman 工具以及 test 環(huán)境嘗試，都發(fā)現(xiàn)接口請求速度是沒有問題的。

“那感覺是前端問題”?

我們來梳理一下問題，如下：

后端 API 請求特別慢，而且是偶現(xiàn)的。在 test 環(huán)境沒有復(fù)現(xiàn)。postman 工具請求沒有復(fù)現(xiàn)。問題解決過程時間都去哪了？

第一個問題，API 耗費的時間都用來做什么了？

我們打開 Chrome 調(diào)試工具。在 network 中可以看到每個接口的耗時。

hover 到你的耗時接口的 Waterful，就可以看到該接口的具體耗時。

可以看到，其耗時主要是在Stalled，代表瀏覽器得到要發(fā)出這個請求的指令到請求可以發(fā)出的等待時間，一般是代理協(xié)商、以及等待可復(fù)用的 TCP 連接釋放的時間，不包括 DNS 查詢、建立 TCP 連接等時間等。

所以 API 一直在等待瀏覽器給它發(fā)出去的指令，以上面截圖的為例，整整等待了 23.84S，它請求和響應(yīng)的時間很快（最多也就幾百毫秒，也就是后端所說的接口并不慢）。

所以 API 到底在等待瀏覽器的什么處理？

什么阻塞了請求？

經(jīng)過定位，我們發(fā)現(xiàn)，我們項目中使用 Server-Sent Events（以下簡稱 SSE）。它跟 WebSocket 一樣，都是服務(wù)器向瀏覽器推送信息。但不同的是，它使用的是 HTTP 協(xié)議。

當(dāng)不通過 HTTP / 2 使用時，SSE會受到最大連接數(shù)的限制，限制為 6 次。此限制是針對每個瀏覽器 + 域的，因此這意味著您可以跨所有選項卡打開 6 個 SSE 連接到 www.example1.com，并打開 6 個 SSE 連接到 www.example2.com。這一點可以通過以下這個 demo 復(fù)現(xiàn)。

復(fù)制問題的步驟：

訪問http://ssebin.btubbs.com/multi/。單擊添加計數(shù)器6或更多次。嘗試打開另一個標(biāo)簽到同一地址。

結(jié)果是，第 6 次之后，SSE 請求一直無法響應(yīng)，打開新的標(biāo)簽到同一個地址的時候，瀏覽器也無法訪問。

效果圖如下：

該問題在Chrome[1]和Firefox[2]中被標(biāo)記為“無法解決”。

至于偶現(xiàn)，是因為前端開發(fā)者有時候用 Chrome 會打開了多個選項卡，每個選項卡都是同一個本地開發(fā)地址，就會導(dǎo)致達到SSE的最大連接數(shù)的限制，而它的執(zhí)行時間會很長，也就會阻塞其他的請求，一致在等待SSE執(zhí)行完。

所以解決的方法是什么？

解決方案簡單粗暴的兩個方法不要打開太多個選項卡。這樣就不會達到它的限制數(shù)。（因為我們一個選項卡只請求一個 SSE）。開發(fā)環(huán)境下，關(guān)閉該功能。使用 HTTP / 2

使用 HTTP / 2 時，HTTP 同一時間內(nèi)的最大連接數(shù)由服務(wù)器和客戶端之間協(xié)商（默認為 100）。

這解釋了為什么我們 test 環(huán)境沒有問題，因為 test 環(huán)境用的是 HTTP / 2。而在開發(fā)環(huán)境中，我們使用的是 HTTP 1.1 就會出現(xiàn)這個問題。

那如何在開發(fā)環(huán)境中使用 HTTP / 2 呢？

我們現(xiàn)在在開發(fā)環(huán)境，大部分還是使用 webpack-dev-server 起一個本地服務(wù)，快速開發(fā)應(yīng)用程序。在文檔中，我們找到server^[3]選項，允許設(shè)置服務(wù)器和配置項（默認為 "http"）。