從輸入 URL 到展現(xiàn)涉及哪些緩存環(huán)節(jié)(非常詳細(xì))
前言
緩存是一項(xiàng)用來(lái)提高網(wǎng)站性能不可或缺的技術(shù)，利用這項(xiàng)技術(shù)可以很好地提高 web 的性能。緩存可以很有效地降低網(wǎng)絡(luò)的時(shí)延，同時(shí)也會(huì)減少大量請(qǐng)求對(duì)于服務(wù)器的壓力。大家在繼續(xù)看下去之前可以先思考一下 “從輸入 URL 到頁(yè)面加載完成的過(guò)程中都發(fā)生了什么事情”。你現(xiàn)在所看到的其實(shí)就是這個(gè)熱點(diǎn)問(wèn)題的一個(gè)變種問(wèn)題。
不過(guò)這個(gè)問(wèn)題對(duì)緩存會(huì)有一個(gè)更詳盡的解釋。我相信你看完這篇文章后對(duì)緩存會(huì)有一個(gè)全新的認(rèn)識(shí)，如果沒(méi)有那就再看一遍。
入題
在這篇文章，我會(huì)詳盡的描述從輸入 URL 到展現(xiàn)涉及到的緩存環(huán)節(jié)，不過(guò)由于本人知識(shí)有限，很可能有某些隱藏的緩存機(jī)制在下遺漏了，還請(qǐng)大佬不吝賜教。
在講“從輸入 URL 到展現(xiàn)涉及到的緩存環(huán)節(jié)”之前，我們先了解下緩存的優(yōu)點(diǎn)：
緩存的幾個(gè)優(yōu)點(diǎn)
減少冗余的數(shù)據(jù)傳輸，可節(jié)省流量
緩解帶寬瓶頸問(wèn)題，可更快加載頁(yè)面
緩解瞬間擁塞，可緩解原始服務(wù)器的壓力
降低距離延時(shí)，加快響應(yīng)速度
目錄
地址欄網(wǎng)址緩存
檢查 HSTS 預(yù)加載列表
DNS 緩存
ARP（地址解析協(xié)議）緩存
TCP 發(fā)送緩沖區(qū) & 接收緩沖區(qū)
HTTP 請(qǐng)求緩存（ CDN 節(jié)點(diǎn)緩存、代理服務(wù)器緩存、瀏覽器緩存、后端動(dòng)態(tài)計(jì)算結(jié)果緩存等 ）
接下來(lái)我們進(jìn)入正題(帶著答案，口味更佳)：
一、地址欄網(wǎng)址緩存
輸入 url 后遇到的第一個(gè)緩存環(huán)節(jié)就是地址欄網(wǎng)址緩存。
但我們輸入一個(gè)常用的網(wǎng)址時(shí)，經(jīng)常會(huì)有這樣的情況，我們只是輸入了幾個(gè)字母，瀏覽器就自動(dòng)補(bǔ)全了該網(wǎng)址。如下圖：我只輸入 j，就自動(dòng)給我補(bǔ)全了 juejin.im：
當(dāng)我們使用這個(gè)自動(dòng)補(bǔ)全的網(wǎng)址時(shí)，你會(huì)發(fā)現(xiàn)請(qǐng)求的相關(guān)的靜態(tài)資源也是從緩存中取得的。
注意：不論什么時(shí)候，我們獲取的主頁(yè)面資源 timeline, 都應(yīng)該是重新請(qǐng)求服務(wù)器而獲得的，不可以使用本地瀏覽器的緩存。至于為什么？你看到靜態(tài)資源文件名的 hash 值你就應(yīng)該清楚了。
可以在 Chrome 的地址欄中輸入 Chrome://cache 查看緩存的信息
轉(zhuǎn)換非 ASCII 的 Unicode 字符
瀏覽器檢查輸入是否含有不是 a-z，A-Z，0-9，- 或者 . 的字符；如果有的話，瀏覽器會(huì)對(duì)主機(jī)名部分使用 Punycode 編碼
二、檢查 HSTS 預(yù)加載列表
HSTS（ HTTP Strict Transport Security ）國(guó)際互聯(lián)網(wǎng)工程組織 IETE 正在推行一種新的 Web 安全協(xié)議，作用是強(qiáng)制客戶端（如瀏覽器）使用 HTTPS 與服務(wù)器創(chuàng)建連接。
采用 HSTS 后：支持這個(gè)協(xié)議的瀏覽器，在輸入 URL 后會(huì)檢查自帶的 HSTS 預(yù)加載列表（這個(gè)列表里包含了那些請(qǐng)求瀏覽器只使用 HTTPS 進(jìn)行連接的域名），若網(wǎng)站在這個(gè)列表里，瀏覽器會(huì)使用 HTTPS 協(xié)議并且返回碼為 307。而不支持 HSTS 的瀏覽器訪問(wèn)我們的網(wǎng)站，則不會(huì)產(chǎn)生跳轉(zhuǎn)，從而提高了兼容性。這個(gè)機(jī)制對(duì)于不支持 HTTPS 的搜索引擎來(lái)說(shuō)是非常友好的！
如掘金輸入 http://juejin.im/timeline 會(huì)跳轉(zhuǎn)到 https://juejin.im/timeline:
查看 HSTS 預(yù)加載列表是否存在你想訪問(wèn)的域名你可以在輸入 qqbrowser://net-internals/#hsts，若存在會(huì)返回信息：
三、DNS 緩存
但你輸入 juejin.im 按下回車后，就開(kāi)始對(duì) juejin.im 進(jìn)行域名解析。域名解析最少涉及了三個(gè)地方的緩存：
瀏覽器的 DNS 緩存
操作系統(tǒng)中的 DNS 緩存
索操作系統(tǒng)的 hosts 文件（可手動(dòng)寫(xiě)入的緩存）
域名解析的具體過(guò)程
瀏覽器搜索自己的 DNS 緩存（瀏覽器維護(hù)一張域名與 IP 地址的對(duì)應(yīng)表）；如果沒(méi)有命中，進(jìn)入下一步；
搜索操作系統(tǒng)中的 DNS 緩存；如果沒(méi)有命中，進(jìn)入下一步；
搜索操作系統(tǒng)的 hosts 文件（ Windows 環(huán)境下，維護(hù)一張域名與 IP 地址的對(duì)應(yīng)表）；如果沒(méi)有命中，進(jìn)入下一步；
操作系統(tǒng)將域名發(fā)送至 LDNS （本地區(qū)域名服務(wù)器），LDNS 查詢自己的 DNS 緩存（一般命中率在 80% 左右），查找成功則返回結(jié)果，失敗則發(fā)起一個(gè)迭代 DNS 解析請(qǐng)求：
LDNS向 Root Name Server（根域名服務(wù)器，如com、net、im 等的頂級(jí)域名服務(wù)器的地址）發(fā)起請(qǐng)求，此處，Root Name Server 返回 im 域的頂級(jí)域名服務(wù)器的地址；
LDNS 向 im 域的頂級(jí)域名服務(wù)器發(fā)起請(qǐng)求，返回 juejin.im 域名服務(wù)器地址；
LDNS 向 juejin.im 域名服務(wù)器發(fā)起請(qǐng)求，得到 juejin.im 的 IP 地址；
LDNS 將得到的 IP 地址返回給操作系統(tǒng)，同時(shí)自己也將 IP 地址緩存起來(lái)；操作系統(tǒng)將 IP 地址返回給瀏覽器，同時(shí)自己也將 IP 地址緩存起來(lái)。
DNS Prefetch
即 DNS 預(yù)獲取，是前端優(yōu)化的一部分。一般來(lái)說(shuō)，在前端優(yōu)化中與 DNS 有關(guān)的有兩點(diǎn)：
減少 DNS 的請(qǐng)求次數(shù)
進(jìn)行 DNS 預(yù)獲取
典型的一次 DNS 解析需要耗費(fèi) 20-120 毫秒，減少DNS解析時(shí)間和次數(shù)是個(gè)很好的優(yōu)化方式。DNS Prefetching 是讓具有此屬性的域名不需要用戶點(diǎn)擊鏈接就在后臺(tái)解析，而域名解析和內(nèi)容載入是串行的網(wǎng)絡(luò)操作，所以這個(gè)方式能減少用戶的等待時(shí)間，提升用戶體驗(yàn)。
你可以通過(guò)
chrome://net-internals/#dns查找目前系統(tǒng)中的 DNS 緩存和 Chrome 中使用的情況。
提個(gè)問(wèn)題
問(wèn)：瀏覽器 DNS 緩存的時(shí)間一般不會(huì)太長(zhǎng)，一分鐘左右。為什么緩存不設(shè)置較長(zhǎng)時(shí)間呢？
答：雖然 DNS 緩存可以提高獲取 DNS 的速度，但緩存時(shí)間過(guò)長(zhǎng)也會(huì)影響 DNS 在 IP 變更時(shí)不能及時(shí)解析到最新的 IP。
四、ARP（地址解析協(xié)議）緩存
ARP 是一種用以解釋地址的協(xié)議，根據(jù)通信方的 IP 地址就可以反查出對(duì)應(yīng)方的 MAC 地址。
ARP 緩存是個(gè)用來(lái)儲(chǔ)存 IP 地址和 MAC 地址的緩沖區(qū)，其本質(zhì)就是一個(gè) IP 地址與 MAC 地址的對(duì)應(yīng)表，表中每一個(gè)條目分別記錄了其他主機(jī)的 IP 地址和對(duì)應(yīng)的 MAC 地址。
當(dāng)?shù)刂方馕鰠f(xié)議被詢問(wèn)一個(gè)已知 IP 地址節(jié)點(diǎn)的 MAC 地址時(shí)，先在 AR 緩存中查看，若存在，就直接返回與之對(duì)應(yīng)的MAC地址；若不存在，才發(fā)送 ARP 請(qǐng)求查詢。
具體的 ARP 請(qǐng)求查詢感興趣的同學(xué)可以自行研究。
五、TCP 發(fā)送緩沖區(qū) & 接收緩沖區(qū)
建立 TCP 連接這一步也涉及到緩存 —— 用來(lái)臨時(shí)存放雙方通信的數(shù)據(jù)，保證通信數(shù)據(jù)不會(huì)丟包。
每個(gè) TCP 連接在內(nèi)核中都有一個(gè)發(fā)送緩沖區(qū)和接收緩沖區(qū)，TCP 的全雙工的工作模式以及 TCP 的流量(擁塞)控制便是依賴于這兩個(gè)獨(dú)立的 buffer 以及 buffer 的填充狀態(tài)。
發(fā)送緩沖區(qū)
發(fā)送緩沖區(qū)存放的是
send()方法從應(yīng)用緩沖區(qū)拷貝過(guò)來(lái)的數(shù)據(jù)。
內(nèi)核基本上是按照 MSS（Maximum Segment Size，最大報(bào)文段長(zhǎng)度） 從緩沖區(qū)中取數(shù)據(jù)發(fā)送出去，當(dāng)緩沖區(qū)中數(shù)據(jù)小于 MSS，則將剩余數(shù)據(jù)全部發(fā)送出去。TCP 的發(fā)送緩沖區(qū)必須為已發(fā)送的數(shù)據(jù)保留一個(gè)副本，直到它被對(duì)端確認(rèn)為止，才能從緩沖區(qū)中刪掉已確認(rèn)的數(shù)據(jù)。
接收緩沖區(qū)
接收緩沖區(qū)被 TCP 用來(lái)保存接收到的數(shù)據(jù)，直到應(yīng)用程序來(lái)讀取。
接收緩沖區(qū)把數(shù)據(jù)緩存入內(nèi)核，等待 recv() 方法讀取， recv() 方法所做的工作，就是把內(nèi)核緩沖區(qū)中的數(shù)據(jù)拷貝到應(yīng)用層用戶的 buffer 里面，拷貝后就刪掉已確認(rèn)的數(shù)據(jù)。
流控制(Flow Control)
A mechanism to prevent a TCP sender from overwhelming a TCP receiver.
TCP 流控制主要用于匹配發(fā)送端和接收端的速度，即根據(jù)接收端當(dāng)前的接收能力來(lái)調(diào)整發(fā)送端的發(fā)送速度。
由于發(fā)送速度可能大于接收速度，接收端的應(yīng)用程序未能及時(shí)從接收緩沖區(qū)讀取數(shù)據(jù)，接收緩沖區(qū)不夠大不能緩存所有接收到的報(bào)文等原因，TCP接收端的接收緩沖區(qū)很快就會(huì)被塞滿；從而導(dǎo)致不能接收后續(xù)的數(shù)據(jù)，發(fā)送端此后發(fā)送數(shù)據(jù)是無(wú)效的，因此需要流控制。
TCP 的緩存就講到這里，感興趣的可以自己翻閱資料。
六、HTTP 請(qǐng)求緩存（ CDN 節(jié)點(diǎn)緩存、代理服務(wù)器緩存、瀏覽器緩存、后端動(dòng)態(tài)計(jì)算結(jié)果緩存等 ）
在建立了 TCP 連接之后，就開(kāi)始 HTTP 請(qǐng)求了；而 HTTP 緩存是優(yōu)化性能不可忽視的一部分，這一部分我會(huì)著重講解。
再講具體過(guò)程之前，我再講一遍強(qiáng)緩存和協(xié)商緩存。
強(qiáng)緩存 ( Cache-Control 和 Expires )
強(qiáng)緩存主要是采用響應(yīng)頭中的 Cache-Control 和 Expires 兩個(gè)字段進(jìn)行控制的。
其中
Expires是HTTP1.0中定義的，它指定了一個(gè)絕對(duì)的過(guò)期時(shí)期。而Cache-Control是HTTP1.1時(shí)出現(xiàn)的緩存控制字段。由于Expires是HTTP1.0時(shí)代的產(chǎn)物，因此設(shè)計(jì)之初就存在著一些缺陷，如果本地時(shí)間和服務(wù)器時(shí)間相差太大，就會(huì)導(dǎo)致緩存錯(cuò)亂。
這兩個(gè)字段同時(shí)使用的時(shí)候 Cache-Control 的優(yōu)先級(jí)會(huì)更高一點(diǎn)。
這兩個(gè)字段的效果是類似的，客戶端都會(huì)通過(guò)對(duì)比本地時(shí)間和服務(wù)器返回的生存時(shí)間來(lái)檢測(cè)緩存是否可用。如果緩存沒(méi)有超出它的生存時(shí)間，客戶端就會(huì)直接采用本地的緩存。如果生存日期已經(jīng)過(guò)了，這個(gè)緩存也就宣告失效。接著客戶端將再次與服務(wù)器進(jìn)行通信來(lái)驗(yàn)證這個(gè)緩存是否需要更新。
在請(qǐng)求頭中使用 Cache-Control 時(shí)，它可選的值有：
| 指令 | 說(shuō)明 |
|---|---|
| no-cache | 使用代理服務(wù)器的緩存之前提交原始服務(wù)器驗(yàn)證，驗(yàn)證通過(guò)才能使用 |
| no-store | 在客戶端或是代理服務(wù)器都不緩存請(qǐng)求或響應(yīng)的任何內(nèi)容 |
| max-age=[秒] | 告知服務(wù)器客戶端可接受資源的存在最大時(shí)間 |
| max-stale(=[秒]) | 可接受（代理服務(wù)器緩存的）過(guò)期資源，參數(shù)可省略 |
| min-fresh=[秒] | 可接受（代理服務(wù)器緩存的）資源更新時(shí)間小于指定時(shí)間 |
| no-transform | 代理服務(wù)器不可以更改媒體類型 |
| only-if-cached | 客戶端只接受已緩存的響應(yīng)，若緩存不命中，則返回 504 錯(cuò)誤 |
| cache-extension | 自定義擴(kuò)展值，若服務(wù)器不知?jiǎng)e該指令，就直接忽略 |
在響應(yīng)頭中使用 Cache-Control 時(shí)，它可選的值有：
| 指令 | 說(shuō)明 |
|---|---|
| public | 表明該資源可以給多個(gè)用戶使用 |
| private(= name) | 該資源是私有資源，指定的用戶可以使用的緩存 |
| no-cache | 強(qiáng)制每次請(qǐng)求直接發(fā)送給源服務(wù)器，而不經(jīng)過(guò)本地緩存版本的校驗(yàn)。 |
| no-store | 在客戶端或是代理服務(wù)器都不緩存請(qǐng)求或響應(yīng)的任何內(nèi)容 |
| no-transform | 代理服務(wù)器不可以更改媒體類型 |
| must-revalidate | 可緩存但必須再向源服務(wù)器進(jìn)行請(qǐng)求確認(rèn) |
| proxy-revalidate | 要求緩存服務(wù)器返回緩存的時(shí)候向源服務(wù)器進(jìn)行請(qǐng)求確認(rèn) |
| max-age=[秒] | 告知客戶端該資源在規(guī)定時(shí)間內(nèi)是新鮮的，無(wú)需向服務(wù)器確認(rèn) |
| s-maxage=[秒] | 告知緩存服務(wù)該資源在規(guī)定時(shí)間內(nèi)是新鮮的，無(wú)需向服務(wù)器確認(rèn) |
| cache-extension | 自定義擴(kuò)展值，若服務(wù)器不識(shí)別該指令，就直接忽略 |
可緩存性
public：響應(yīng)可以被任何對(duì)象（客戶端、代理服務(wù)器等）緩存private：只能被單個(gè)用戶緩存，不能作為共享緩存no-cache：使用緩存副本之前，需要將請(qǐng)求提交給原始服務(wù)器進(jìn)行驗(yàn)證，驗(yàn)證通過(guò)才可以使用only-if-cached：客戶端只接受已緩存的響應(yīng)，并且不向原始服務(wù)器檢查是否有更新的拷貝
到期
max-age=<seconds>：緩存存儲(chǔ)的最大周期，超過(guò)這個(gè)時(shí)間緩存被認(rèn)為過(guò)期(單位秒)。與?Expires?相反，時(shí)間是相對(duì)于請(qǐng)求的時(shí)間s-maxage=<seconds>：覆蓋?max-age?或者?Expires?頭，但是僅適用于共享緩存(比如各個(gè)代理)，并且私有緩存中它被忽略max-stale[=<seconds>]：表明客戶端愿意接收一個(gè)已經(jīng)過(guò)期的資源?？蛇x的設(shè)置一個(gè)時(shí)間(單位秒)，表示響應(yīng)不能超過(guò)的過(guò)時(shí)時(shí)間min-fresh=<seconds>：表示客戶端希望在指定的時(shí)間內(nèi)獲取最新的響應(yīng)
重新驗(yàn)證和重新加載
must-revalidate：緩存必須在使用之前驗(yàn)證舊資源的狀態(tài)，并且不可使用過(guò)期資源。proxy-revalidate：與?must-revalidate?作用相同，但它僅適用于共享緩存（例如代理），并被私有緩存忽略
其他
no-store：徹底得禁用緩沖，本地和代理服務(wù)器都不緩沖，每次都從服務(wù)器獲取no-transform：不得對(duì)資源進(jìn)行轉(zhuǎn)換或轉(zhuǎn)變。?Content-Encoding,?Content-Range,?Content-Type?等?HTTP?頭不能由代理修改。
協(xié)商緩存 ( Last-Modified 和 Etag )
協(xié)商緩存機(jī)制下，瀏覽器需要向服務(wù)器去詢問(wèn)緩存的相關(guān)信息，進(jìn)而判斷是重新發(fā)起請(qǐng)求還是從本地獲取緩存的資源。如果服務(wù)端提示緩存資源未改動(dòng)（ Not Modified ），資源會(huì)被重定向到瀏覽器緩存，這種情況下網(wǎng)絡(luò)請(qǐng)求對(duì)應(yīng)的狀態(tài)碼是
304。
*Last-Modified 和 If-Modified-Since *
基于資源在服務(wù)器修改時(shí)間而驗(yàn)證緩存的過(guò)期機(jī)制
當(dāng)客戶端再次請(qǐng)求該資源的時(shí)候，會(huì)在其請(qǐng)求頭上附帶上 If-Modified-Since 字段（值就是第一次獲取請(qǐng)求資源時(shí)響應(yīng)頭中返回的 Last-Modified 值）。如果修改時(shí)間未改變則表明資源未過(guò)期，命中緩存，服務(wù)器就直接返回 304 狀態(tài)碼，客戶端直接使用本地的資源。否則，服務(wù)器重新發(fā)送響應(yīng)資源，從而保證資源的有效性。
Etag 和 If-None-Match
基于資源校驗(yàn)碼（一般為md5值）而驗(yàn)證緩存的過(guò)期機(jī)制
當(dāng)客戶端再次請(qǐng)求該資源的時(shí)候，會(huì)在其請(qǐng)求頭上附帶上 If-None-Match 字段（值就是第一次獲取請(qǐng)求資源時(shí)響應(yīng)頭中返回的 Etag 值），其值與服務(wù)器端資源文件的驗(yàn)證碼進(jìn)行對(duì)比，如果匹配成功直接返回 304 狀態(tài)碼，從瀏覽器本地緩存取資源文件。如果不匹配，服務(wù)器會(huì)把新的驗(yàn)證碼放在請(qǐng)求頭的 Etag 字段中，并且以 200 狀態(tài)碼返回資源。
需要注意的是當(dāng)響應(yīng)頭中同時(shí)存在
Etag和Last-Modified的時(shí)候，會(huì)先對(duì)Etag進(jìn)行比對(duì)，隨后才是Last-Modified。
Etag 的問(wèn)題
相同的資源，在兩臺(tái)服務(wù)器產(chǎn)生的 Etag 是不是相同的，所以對(duì)于使用服務(wù)器集群來(lái)處理請(qǐng)求的網(wǎng)站來(lái)說(shuō)， Etag 的匹配概率會(huì)大幅降低。所在在這種情況下，使用 Etag 來(lái)處理緩存，反而會(huì)有更大的開(kāi)銷。
靜態(tài)資源和動(dòng)態(tài)資源的請(qǐng)求過(guò)程解析
靜態(tài)資源
第一次請(qǐng)求肯定是從服務(wù)器請(qǐng)求過(guò)來(lái)的資源，這個(gè)沒(méi)有什么疑問(wèn)，我們先看看第一次請(qǐng)求的響應(yīng)頭的內(nèi)容：
我們發(fā)現(xiàn)第一次的響應(yīng)頭中包含可強(qiáng)緩存的相關(guān)字段 cache-control ,同時(shí)也包含了協(xié)商緩存的相關(guān)字段 etag 和 last-modified;
當(dāng)強(qiáng)緩存和協(xié)商緩存字段同時(shí)存在時(shí)會(huì)進(jìn)行以下步驟來(lái)請(qǐng)求資源：
強(qiáng)緩存和協(xié)商緩存同時(shí)存在，如果強(qiáng)緩存還在有效期內(nèi)則直接使用緩存；如果強(qiáng)緩存不在有效期，協(xié)商緩存生效。
即：強(qiáng)緩存優(yōu)先級(jí) > 協(xié)商緩存優(yōu)先級(jí)強(qiáng)緩存的
expires和cache-control同時(shí)存在時(shí)，cache-control會(huì)覆蓋expires的效果，expires無(wú)論有沒(méi)有過(guò)期，都無(wú)效。
即：cache-control優(yōu)先級(jí) >expires優(yōu)先級(jí)。協(xié)商緩存的
Etag和Last-Modified同時(shí)存在時(shí)，Etag會(huì)覆蓋Last-Modified的效果。
即：ETag優(yōu)先級(jí) >Last-Modified優(yōu)先級(jí)。
第二次請(qǐng)求該資源的時(shí)候，就直接是從緩存中讀取的：
其實(shí)我們第一次獲取的資源極有可能是從 CDN 節(jié)點(diǎn)的緩存中獲取的，也很有可能是從中間代理服務(wù)器（nginx，node 等）的緩存中讀取的；其中的好處不言而喻。
動(dòng)態(tài)資源
由于動(dòng)態(tài)資源的返回結(jié)果不一致，所以這個(gè)我們肯定不會(huì)在瀏覽器（中間代理服務(wù)器）緩存動(dòng)態(tài)的結(jié)果。
不過(guò)這里我們可以在后端緩存一些重復(fù)率比較高的相關(guān)的計(jì)算結(jié)果。
如：這里有 60 只股票，用戶可以選擇其中幾只股票作為自己的股票投資池。用戶選擇完股票后提交，會(huì)通過(guò)相關(guān)的算法計(jì)算其預(yù)期收益效果等指標(biāo)。我們知道每次計(jì)算的時(shí)間可能會(huì)比較久，所以在這步我們可以在后端將可能的組合結(jié)果先計(jì)算好緩存起來(lái)，當(dāng)我們請(qǐng)求的時(shí)候就后端就可以直接返回已經(jīng)計(jì)算好的結(jié)果給前端。至于計(jì)算結(jié)果的緩存時(shí)間也就完全由服務(wù)器控制了。
關(guān)于動(dòng)態(tài)資源一般前端是不做緩存的。
后端緩存主要通過(guò)保留數(shù)據(jù)庫(kù)連接，存儲(chǔ)處理結(jié)果等方式縮短處理時(shí)間，盡快響應(yīng)客戶端請(qǐng)求。