面經(jīng) | 好消息：字節(jié)發(fā)新年紅包了，壞消息：明年沒(méi)有了

，然后從證書(shū)拿到公鑰，并生成一個(gè)隨機(jī)數(shù)，用公鑰加密隨機(jī)數(shù)發(fā)送給中間人，中間人使用私鑰解密，得到隨機(jī)數(shù)，此時(shí)雙方都有隨機(jī)數(shù)，然后通過(guò)算法生成對(duì)稱加密密鑰（A），后續(xù)客戶端與中間人通信就用這個(gè)對(duì)稱加密密鑰來(lái)加密數(shù)據(jù)了。在中間人與服務(wù)端進(jìn)行 TLS 握手過(guò)程中，服務(wù)端會(huì)發(fā)送從 CA 機(jī)構(gòu)簽發(fā)的公鑰證書(shū)給中間人，從證書(shū)拿到公鑰，并生成一個(gè)隨機(jī)數(shù)，用公鑰加密隨機(jī)數(shù)發(fā)送給服務(wù)端，服務(wù)端使用私鑰解密，得到隨機(jī)數(shù)，此時(shí)雙方都有隨機(jī)數(shù)，然后通過(guò)算法生成對(duì)稱加密密鑰（B），后續(xù)中間人與服務(wù)端通信就用這個(gè)對(duì)稱加密密鑰來(lái)加密數(shù)據(jù)了。

后續(xù)的通信過(guò)程中，中間人用對(duì)稱加密密鑰（A）解密客戶端的 HTTPS 請(qǐng)求的數(shù)據(jù)，然后用對(duì)稱加密密鑰（B）加密 HTTPS 請(qǐng)求后，轉(zhuǎn)發(fā)給服務(wù)端，接著服務(wù)端發(fā)送 HTTPS 響應(yīng)數(shù)據(jù)給中間人，中間人用對(duì)稱加密密鑰（B）解密 HTTPS 響應(yīng)數(shù)據(jù)，然后再用對(duì)稱加密密鑰（A）加密后，轉(zhuǎn)發(fā)給客戶端。

從客戶端的角度看，其實(shí)并不知道網(wǎng)絡(luò)中存在中間人服務(wù)器這個(gè)角色。那么中間人就可以解開(kāi)瀏覽器發(fā)起的 HTTPS 請(qǐng)求里的數(shù)據(jù)，也可以解開(kāi)服務(wù)端響應(yīng)給瀏覽器的 HTTPS 響應(yīng)數(shù)據(jù)。相當(dāng)于，中間人能夠 “偷看” 瀏覽器與服務(wù)端之間的 HTTPS 請(qǐng)求和響應(yīng)的數(shù)據(jù)。

但是要發(fā)生這種場(chǎng)景是有前提的，前提是用戶點(diǎn)擊接受了中間人服務(wù)器的證書(shū)。

中間人服務(wù)器與客戶端在 TLS 握手過(guò)程中，實(shí)際上發(fā)送了自己偽造的證書(shū)給瀏覽器，而這個(gè)偽造的證書(shū)是能被瀏覽器（客戶端）識(shí)別出是非法的，于是就會(huì)提醒用戶該證書(shū)存在問(wèn)題。

如果用戶執(zhí)意點(diǎn)擊「繼續(xù)瀏覽此網(wǎng)站」，相當(dāng)于用戶接受了中間人偽造的證書(shū)，那么后續(xù)整個(gè) HTTPS 通信都能被中間人監(jiān)聽(tīng)了。

MySql索引是什么？

MySQL索引是數(shù)據(jù)庫(kù)表中的一種數(shù)據(jù)結(jié)構(gòu)，可以提高數(shù)據(jù)檢索的速度。

索引存儲(chǔ)了指向表中數(shù)據(jù)的指針，這樣數(shù)據(jù)庫(kù)在查找數(shù)據(jù)時(shí)可以使用索引來(lái)快速定位到表中的特定行，而不必掃描整個(gè)表。使用索引可以顯著提高查詢的效率，特別是在處理大量數(shù)據(jù)時(shí)。

介紹一下索引有哪些類(lèi)型？

可以按照四個(gè)角度來(lái)分類(lèi)索引。

按「數(shù)據(jù)結(jié)構(gòu)」分類(lèi)：B+tree索引、Hash索引、Full-text索引。

按「物理存儲(chǔ)」分類(lèi)：聚簇索引（主鍵索引）、二級(jí)索引（輔助索引）。

按「字段特性」分類(lèi)：主鍵索引、唯一索引、普通索引、前綴索引。

按「字段個(gè)數(shù)」分類(lèi)：單列索引、聯(lián)合索引。

MySql索引底層是用的什么數(shù)據(jù)結(jié)構(gòu)？

從數(shù)據(jù)結(jié)構(gòu)的角度來(lái)看，MySQL 常見(jiàn)索引有 B+Tree 索引、HASH 索引、Full-Text 索引。

每一種存儲(chǔ)引擎支持的索引類(lèi)型不一定相同，我在表中總結(jié)了 MySQL 常見(jiàn)的存儲(chǔ)引擎 InnoDB、MyISAM 和 Memory 分別支持的索引類(lèi)型。

InnoDB 是在 MySQL 5.5 之后成為默認(rèn)的 MySQL 存儲(chǔ)引擎，B+Tree 索引類(lèi)型也是 MySQL 存儲(chǔ)引擎采用最多的索引類(lèi)型。

MySql查詢數(shù)據(jù)怎么優(yōu)化？

通過(guò) explain 執(zhí)行結(jié)果，查看 sql 是否走索引，如果不走索引，考慮增加索引?？梢酝ㄟ^(guò)建立聯(lián)合索引，實(shí)現(xiàn)覆蓋索引優(yōu)化，減少回表聯(lián)合索引符合最左匹配原則，不然會(huì)索引失效避免索引失效，比如不要用左模糊匹配、函數(shù)計(jì)算、表達(dá)式計(jì)算等等。聯(lián)表查詢最好要以小表驅(qū)動(dòng)大表，并且被驅(qū)動(dòng)表的字段要有索引，當(dāng)然最好通過(guò)冗余字段的設(shè)計(jì)，避免聯(lián)表查詢。針對(duì) limit n,y 深分頁(yè)的查詢優(yōu)化，可以把Limit查詢轉(zhuǎn)換成某個(gè)位置的查詢：select * from tb_sku where id>20000 limit 10;，該方案適用于主鍵自增的表，將字段多的表分解成多個(gè)表，有些字段使用頻率高，有些低，數(shù)據(jù)量大時(shí)，會(huì)由于使用頻率低的存在而變慢，可以考慮分開(kāi)

spring循環(huán)依賴是怎么解決？

循環(huán)依賴指的是兩個(gè)類(lèi)中的屬性相互依賴對(duì)方：例如 A 類(lèi)中有 B 屬性，B 類(lèi)中有 A屬性，從而形成了一個(gè)依賴閉環(huán)，如下圖。

循環(huán)依賴問(wèn)題在Spring中主要有三種情況：

第一種：通過(guò)構(gòu)造方法進(jìn)行依賴注入時(shí)產(chǎn)生的循環(huán)依賴問(wèn)題。第二種：通過(guò)setter方法進(jìn)行依賴注入且是在多例（原型）模式下產(chǎn)生的循環(huán)依賴問(wèn)題。第三種：通過(guò)setter方法進(jìn)行依賴注入且是在單例模式下產(chǎn)生的循環(huán)依賴問(wèn)題。

只有【第三種方式】的循環(huán)依賴問(wèn)題被 Spring 解決了，其他兩種方式在遇到循環(huán)依賴問(wèn)題時(shí)，Spring都會(huì)產(chǎn)生異常。

Spring 解決單例模式下的setter循環(huán)依賴問(wèn)題的主要方式是通過(guò)三級(jí)緩存解決循環(huán)依賴。三級(jí)緩存指的是 Spring 在創(chuàng)建 Bean 的過(guò)程中，通過(guò)三級(jí)緩存來(lái)緩存正在創(chuàng)建的 Bean，以及已經(jīng)創(chuàng)建完成的 Bean 實(shí)例。具體步驟如下：

實(shí)例化 Bean：Spring 在實(shí)例化 Bean 時(shí)，會(huì)先創(chuàng)建一個(gè)空的 Bean 對(duì)象，并將其放入一級(jí)緩存中。

屬性賦值：Spring 開(kāi)始對(duì) Bean 進(jìn)行屬性賦值，如果發(fā)現(xiàn)循環(huán)依賴，會(huì)將當(dāng)前 Bean 對(duì)象提前暴露給后續(xù)需要依賴的 Bean（通過(guò)提前暴露的方式解決循環(huán)依賴）。

初始化 Bean：完成屬性賦值后，Spring 將 Bean 進(jìn)行初始化，并將其放入二級(jí)緩存中。

注入依賴：Spring 繼續(xù)對(duì) Bean 進(jìn)行依賴注入，如果發(fā)現(xiàn)循環(huán)依賴，會(huì)從二級(jí)緩存中獲取已經(jīng)完成初始化的 Bean 實(shí)例。

通過(guò)三級(jí)緩存的機(jī)制，Spring 能夠在處理循環(huán)依賴時(shí)，確保及時(shí)暴露正在創(chuàng)建的 Bean 對(duì)象，并能夠正確地注入已經(jīng)初始化的 Bean 實(shí)例，從而解決循環(huán)依賴問(wèn)題，保證應(yīng)用程序的正常運(yùn)行。

spring三級(jí)緩存的數(shù)據(jù)結(jié)構(gòu)是什么？

都是 Map類(lèi)型的緩存，比如Map {k:name; v:bean}。

一級(jí)緩存（Singleton Objects）：這是一個(gè)Map類(lèi)型的緩存，存儲(chǔ)的是已經(jīng)完全初始化好的bean，即完全準(zhǔn)備好可以使用的bean實(shí)例。鍵是bean的名稱，值是bean的實(shí)例。這個(gè)緩存在DefaultSingletonBeanRegistry類(lèi)中的singletonObjects屬性中。

二級(jí)緩存（Early Singleton Objects）：這同樣是一個(gè)Map類(lèi)型的緩存，存儲(chǔ)的是早期的bean引用，即已經(jīng)實(shí)例化但還未完全初始化的bean。這些bean已經(jīng)被實(shí)例化，但是可能還沒(méi)有進(jìn)行屬性注入等操作。這個(gè)緩存在DefaultSingletonBeanRegistry類(lèi)中的earlySingletonObjects屬性中。

三級(jí)緩存（Singleton Factories）：這也是一個(gè)Map類(lèi)型的緩存，存儲(chǔ)的是ObjectFactory對(duì)象，這些對(duì)象可以生成早期的bean引用。當(dāng)一個(gè)bean正在創(chuàng)建過(guò)程中，如果它被其他bean依賴，那么這個(gè)正在創(chuàng)建的bean就會(huì)通過(guò)這個(gè)ObjectFactory來(lái)創(chuàng)建一個(gè)早期引用，從而解決循環(huán)依賴的問(wèn)題。這個(gè)緩存在DefaultSingletonBeanRegistry類(lèi)中的singletonFactories屬性中。

linux中軟鏈接和硬鏈接的區(qū)別？

有時(shí)候我們希望給某個(gè)文件取個(gè)別名，那么在 Linux 中可以通過(guò)硬鏈接（_Hard Link_）?和軟鏈接（_Symbolic Link_）?的方式來(lái)實(shí)現(xiàn)，它們都是比較特殊的文件，但是實(shí)現(xiàn)方式也是不相同的。

硬鏈接是多個(gè)目錄項(xiàng)中的「索引節(jié)點(diǎn)」指向一個(gè)文件，也就是指向同一個(gè) inode，但是 inode 是不可能跨越文件系統(tǒng)的，每個(gè)文件系統(tǒng)都有各自的 inode 數(shù)據(jù)結(jié)構(gòu)和列表，所以硬鏈接是不可用于跨文件系統(tǒng)的。由于多個(gè)目錄項(xiàng)都是指向一個(gè) inode，那么只有刪除文件的所有硬鏈接以及源文件時(shí)，系統(tǒng)才會(huì)徹底刪除該文件。

軟鏈接相當(dāng)于重新創(chuàng)建一個(gè)文件，這個(gè)文件有獨(dú)立的 inode，但是這個(gè)文件的內(nèi)容是另外一個(gè)文件的路徑，所以訪問(wèn)軟鏈接的時(shí)候，實(shí)際上相當(dāng)于訪問(wèn)到了另外一個(gè)文件，所以軟鏈接是可以跨文件系統(tǒng)的，甚至目標(biāo)文件被刪除了，鏈接文件還是在的，只不過(guò)指向的文件找不到了而已。

手撕代碼

鏈表向右循環(huán)K個(gè)數(shù)

一面感受

體驗(yàn)很好，面試官很會(huì)引導(dǎo)。面試官說(shuō)我準(zhǔn)備的很充分，快要結(jié)束時(shí)直接讓我準(zhǔn)備二面，說(shuō)一面直接給我過(guò)了。

二面八股

進(jìn)程和線程的區(qū)別？

本質(zhì)區(qū)別：進(jìn)程是操作系統(tǒng)資源分配的基本單位，而線程是任務(wù)調(diào)度和執(zhí)行的基本單位

在開(kāi)銷(xiāo)方面：每個(gè)進(jìn)程都有獨(dú)立的代碼和數(shù)據(jù)空間（程序上下文），程序之間的切換會(huì)有較大的開(kāi)銷(xiāo)；線程可以看做輕量級(jí)的進(jìn)程，同一類(lèi)線程共享代碼和數(shù)據(jù)空間，每個(gè)線程都有自己獨(dú)立的運(yùn)行棧和程序計(jì)數(shù)器（PC），線程之間切換的開(kāi)銷(xiāo)小

穩(wěn)定性方面：進(jìn)程中某個(gè)線程如果崩潰了，可能會(huì)導(dǎo)致整個(gè)進(jìn)程都崩潰。而進(jìn)程中的子進(jìn)程崩潰，并不會(huì)影響其他進(jìn)程。

內(nèi)存分配方面：系統(tǒng)在運(yùn)行的時(shí)候會(huì)為每個(gè)進(jìn)程分配不同的內(nèi)存空間；而對(duì)線程而言，除了CPU外，系統(tǒng)不會(huì)為線程分配內(nèi)存（線程所使用的資源來(lái)自其所屬進(jìn)程的資源），線程組之間只能共享資源

包含關(guān)系：沒(méi)有線程的進(jìn)程可以看做是單線程的，如果一個(gè)進(jìn)程內(nèi)有多個(gè)線程，則執(zhí)行過(guò)程不是一條線的，而是多條線（線程）共同完成的；線程是進(jìn)程的一部分，所以線程也被稱為輕權(quán)進(jìn)程或者輕量級(jí)進(jìn)程

你說(shuō)到進(jìn)程是分配資源的基本單位，那么這個(gè)資源指的是什么？

虛擬內(nèi)存、文件句柄、信號(hào)量等資源。

說(shuō)一說(shuō)fork()原理？

主進(jìn)程在執(zhí)行 fork 的時(shí)候，操作系統(tǒng)會(huì)把主進(jìn)程的「頁(yè)表」復(fù)制一份給子進(jìn)程，這個(gè)頁(yè)表記錄著虛擬地址和物理地址映射關(guān)系，而不會(huì)復(fù)制物理內(nèi)存，也就是說(shuō)，兩者的虛擬空間不同，但其對(duì)應(yīng)的物理空間是同一個(gè)。

這樣一來(lái)，子進(jìn)程就共享了父進(jìn)程的物理內(nèi)存數(shù)據(jù)了，這樣能夠節(jié)約物理內(nèi)存資源，頁(yè)表對(duì)應(yīng)的頁(yè)表項(xiàng)的屬性會(huì)標(biāo)記該物理內(nèi)存的權(quán)限為只讀。

不過(guò)，當(dāng)父進(jìn)程或者子進(jìn)程在向這個(gè)內(nèi)存發(fā)起寫(xiě)操作時(shí)，CPU 就會(huì)觸發(fā)寫(xiě)保護(hù)中斷，這個(gè)寫(xiě)保護(hù)中斷是由于違反權(quán)限導(dǎo)致的，然后操作系統(tǒng)會(huì)在「寫(xiě)保護(hù)中斷處理函數(shù)」里進(jìn)行物理內(nèi)存的復(fù)制，并重新設(shè)置其內(nèi)存映射關(guān)系，將父子進(jìn)程的內(nèi)存讀寫(xiě)權(quán)限設(shè)置為可讀寫(xiě)，最后才會(huì)對(duì)內(nèi)存進(jìn)行寫(xiě)操作，這個(gè)過(guò)程被稱為「寫(xiě)時(shí)復(fù)制(Copy On Write)」。

寫(xiě)時(shí)復(fù)制顧名思義，在發(fā)生寫(xiě)操作的時(shí)候，操作系統(tǒng)才會(huì)去復(fù)制物理內(nèi)存，這樣是為了防止 fork 創(chuàng)建子進(jìn)程時(shí)，由于物理內(nèi)存數(shù)據(jù)的復(fù)制時(shí)間過(guò)長(zhǎng)而導(dǎo)致父進(jìn)程長(zhǎng)時(shí)間阻塞的問(wèn)題。

fork()會(huì)復(fù)制哪些東西？

fork 階段會(huì)復(fù)制父進(jìn)程的頁(yè)表（虛擬內(nèi)存）fork 之后，如果發(fā)生了寫(xiě)時(shí)復(fù)制，就會(huì)復(fù)制物理內(nèi)存

堆和棧的區(qū)別？

分配方式：堆是動(dòng)態(tài)分配內(nèi)存，由程序員手動(dòng)申請(qǐng)和釋放內(nèi)存，通常用于存儲(chǔ)動(dòng)態(tài)數(shù)據(jù)結(jié)構(gòu)和對(duì)象。棧是靜態(tài)分配內(nèi)存，由編譯器自動(dòng)分配和釋放內(nèi)存，用于存儲(chǔ)函數(shù)的局部變量和函數(shù)調(diào)用信息。

內(nèi)存管理：堆需要程序員手動(dòng)管理內(nèi)存的分配和釋放，如果管理不當(dāng)可能會(huì)導(dǎo)致內(nèi)存泄漏或內(nèi)存溢出。棧由編譯器自動(dòng)管理內(nèi)存，遵循后進(jìn)先出的原則，變量的生命周期由其作用域決定，函數(shù)調(diào)用時(shí)分配內(nèi)存，函數(shù)返回時(shí)釋放內(nèi)存。

大小和速度：堆通常比棧大，內(nèi)存空間較大，動(dòng)態(tài)分配和釋放內(nèi)存需要時(shí)間開(kāi)銷(xiāo)。棧大小有限，通常比較小，內(nèi)存分配和釋放速度較快，因?yàn)槭蔷幾g器自動(dòng)管理。

說(shuō)說(shuō)io多路復(fù)用？

I/O 多路復(fù)用可以只使用一個(gè)進(jìn)程來(lái)維護(hù)多個(gè) Socket?。

一個(gè)進(jìn)程雖然任一時(shí)刻只能處理一個(gè)請(qǐng)求，但是處理每個(gè)請(qǐng)求的事件時(shí)，耗時(shí)控制在 1 毫秒以內(nèi)，這樣 1 秒內(nèi)就可以處理上千個(gè)請(qǐng)求，把時(shí)間拉長(zhǎng)來(lái)看，多個(gè)請(qǐng)求復(fù)用了一個(gè)進(jìn)程，這就是多路復(fù)用，這種思想很類(lèi)似一個(gè) CPU 并發(fā)多個(gè)進(jìn)程，所以也叫做時(shí)分多路復(fù)用。

select/poll/epoll 內(nèi)核提供給用戶態(tài)的多路復(fù)用系統(tǒng)調(diào)用，進(jìn)程可以通過(guò)一個(gè)系統(tǒng)調(diào)用函數(shù)從內(nèi)核中獲取多個(gè)事件。在獲取事件時(shí)，先把所有連接（文件描述符）傳給內(nèi)核，再由內(nèi)核返回產(chǎn)生了事件的連接，然后在用戶態(tài)中再處理這些連接對(duì)應(yīng)的請(qǐng)求即可。

tcp與udp的區(qū)別

連接：TCP 是面向連接的傳輸層協(xié)議，傳輸數(shù)據(jù)前先要建立連接；UDP 是不需要連接，即刻傳輸數(shù)據(jù)。服務(wù)對(duì)象：TCP 是一對(duì)一的兩點(diǎn)服務(wù)，即一條連接只有兩個(gè)端點(diǎn)。UDP 支持一對(duì)一、一對(duì)多、多對(duì)多的交互通信可靠性：TCP 是可靠交付數(shù)據(jù)的，數(shù)據(jù)可以無(wú)差錯(cuò)、不丟失、不重復(fù)、按序到達(dá)。UDP 是盡最大努力交付，不保證可靠交付數(shù)據(jù)。但是我們可以基于 UDP 傳輸協(xié)議實(shí)現(xiàn)一個(gè)可靠的傳輸協(xié)議，比如 QUIC 協(xié)議擁塞控制、流量控制：TCP 有擁塞控制和流量控制機(jī)制，保證數(shù)據(jù)傳輸的安全性。UDP 則沒(méi)有，即使網(wǎng)絡(luò)非常擁堵了，也不會(huì)影響 UDP 的發(fā)送速率。首部開(kāi)銷(xiāo)：TCP 首部長(zhǎng)度較長(zhǎng)，會(huì)有一定的開(kāi)銷(xiāo)，首部在沒(méi)有使用「選項(xiàng)」字段時(shí)是 20 個(gè)字節(jié)，如果使用了「選項(xiàng)」字段則會(huì)變長(zhǎng)的。UDP 首部只有 8 個(gè)字節(jié)，并且是固定不變的，開(kāi)銷(xiāo)較小。傳輸方式：TCP 是流式傳輸，沒(méi)有邊界，但保證順序和可靠。UDP 是一個(gè)包一個(gè)包的發(fā)送，是有邊界的，但可能會(huì)丟包和亂序。應(yīng)用場(chǎng)景：TCP 是面向連接，能保證數(shù)據(jù)的可靠性交付，因此經(jīng)常用于：FTP、HTTP/HTTPS協(xié)議。UDP 面向無(wú)連接，它可以隨時(shí)發(fā)送數(shù)據(jù)，再加上 UDP 本身的處理既簡(jiǎn)單又高效，經(jīng)常用于視頻、音頻等多媒體通信等。

說(shuō)說(shuō)HTTP頭部字段

Host?字段

客戶端發(fā)送請(qǐng)求時(shí)，用來(lái)指定服務(wù)器的域名。

Host:?www.A.com

有了 Host 字段，就可以將請(qǐng)求發(fā)往「同一臺(tái)」服務(wù)器上的不同網(wǎng)站。

Content-Length 字段

服務(wù)器在返回?cái)?shù)據(jù)時(shí)，會(huì)有 Content-Length 字段，表明本次回應(yīng)的數(shù)據(jù)長(zhǎng)度。

Content-Length:?1000

如上面則是告訴瀏覽器，本次服務(wù)器回應(yīng)的數(shù)據(jù)長(zhǎng)度是 1000 個(gè)字節(jié)，后面的字節(jié)就屬于下一個(gè)回應(yīng)了。大家應(yīng)該都知道 HTTP 是基于 TCP 傳輸協(xié)議進(jìn)行通信的，而使用了 TCP 傳輸協(xié)議，就會(huì)存在一個(gè)“粘包”的問(wèn)題，HTTP 協(xié)議通過(guò)設(shè)置回車(chē)符、換行符作為 HTTP header 的邊界，通過(guò) Content-Length 字段作為 HTTP body 的邊界，這兩個(gè)方式都是為了解決“粘包”的問(wèn)題。

Connection 字段

Connection 字段最常用于客戶端要求服務(wù)器使用「HTTP 長(zhǎng)連接」機(jī)制，以便其他請(qǐng)求復(fù)用。

HTTP 長(zhǎng)連接的特點(diǎn)是，只要任意一端沒(méi)有明確提出斷開(kāi)連接，則保持 TCP 連接狀態(tài)。

HTTP/1.1 版本的默認(rèn)連接都是長(zhǎng)連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。

Connection:?Keep-Alive

開(kāi)啟了 HTTP Keep-Alive 機(jī)制后， 連接就不會(huì)中斷，而是保持連接。當(dāng)客戶端發(fā)送另一個(gè)請(qǐng)求時(shí)，它會(huì)使用同一個(gè)連接，一直持續(xù)到客戶端或服務(wù)器端提出斷開(kāi)連接。

Content-Type 字段

Content-Type 字段用于服務(wù)器回應(yīng)時(shí)，告訴客戶端，本次數(shù)據(jù)是什么格式。

Content-Type:?text/html;?Charset=utf-8

上面的類(lèi)型表明，發(fā)送的是網(wǎng)頁(yè)，而且編碼是UTF-8?？蛻舳苏?qǐng)求的時(shí)候，可以使用 Accept 字段聲明自己可以接受哪些數(shù)據(jù)格式。

Accept:?*/*

上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。

說(shuō)說(shuō)HTTP2

HTTP/2 相比 HTTP/1.1 性能上的改進(jìn)：

頭部壓縮：HTTP/2 會(huì)壓縮頭（Header）如果你同時(shí)發(fā)出多個(gè)請(qǐng)求，他們的頭是一樣的或是相似的，那么，協(xié)議會(huì)幫你消除重復(fù)的部分。這就是所謂的 HPACK 算法：在客戶端和服務(wù)器同時(shí)維護(hù)一張頭信息表，所有字段都會(huì)存入這個(gè)表，生成一個(gè)索引號(hào)，以后就不發(fā)送同樣字段了，只發(fā)送索引號(hào)，這樣就提高速度了。

二進(jìn)制格式：HTTP/2 不再像 HTTP/1.1 里的純文本形式的報(bào)文，而是全面采用了二進(jìn)制格式，頭信息和數(shù)據(jù)體都是二進(jìn)制，并且統(tǒng)稱為幀（frame）：頭信息幀（Headers Frame）和數(shù)據(jù)幀（Data Frame）。這樣雖然對(duì)人不友好，但是對(duì)計(jì)算機(jī)非常友好，因?yàn)橛?jì)算機(jī)只懂二進(jìn)制，那么收到報(bào)文后，無(wú)需再將明文的報(bào)文轉(zhuǎn)成二進(jìn)制，而是直接解析二進(jìn)制報(bào)文，這增加了數(shù)據(jù)傳輸?shù)男?/strong>。