關於大廠面試中問到的二十幾個 HTTP 面試題

時間 2020-01-06

標籤關於大廠面試問到二十幾個 http 欄目快樂工作简体版

原文原文鏈接

我在 github 上新建了一個倉庫日問，天天一道面試題，有關前端，後端，devops以及軟技能，促進職業成長，敲開大廠之門，歡迎交流css

而且記錄個人面試經驗html

【Q035】http 常見的狀態碼有哪些

1XX 表示消息
2XX 表示成功
3XX 表示重定向
4XX 表示客戶端錯誤
5XX 表示服務端錯誤

常見的狀態碼

【Q036】http 狀態碼中 301，302和307有什麼區別

301，Moved Permanently。永久重定向，該操做比較危險，須要謹慎操做：若是設置了301，可是一段時間後又想取消，可是瀏覽器中已經有了緩存，仍是會重定向。
302，Fount。臨時重定向，可是會在重定向的時候改變 method: 把 POST 改爲 GET，因而有了 307
307，Temporary Redirect。臨時重定向，在重定向時不會改變 method

【Q050】http 狀態碼 502 和 504 有什麼區別

502 Bad Gateway

The server was acting as a gateway or proxy and received an invalid response from the upstream server.
收到了上游響應但沒法解析webpack

504 Gateway Timeout

The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
上游響應超時nginx

【Q079】簡述 http 的緩存機制

【Q081】http proxy 的原理是什麼

<blockquote> 更多描述: 如 webpack-dev-server 能夠設置 proxy，nginx 也能夠設置 </blockquote>

todo

【Q084】隨着 http2 的發展，前端性能優化中的哪些傳統方案能夠被替代

雪碧圖
資源文件合併

【Q085】http2 與 http1.1 有什麼不一樣

【Q107】什麼是 Basic Auth 和 Digest Auth

【Q108】gzip 的原理是什麼

gzip 使用了 LZ77 算法與 Huffman 編碼來壓縮文件，重複度越高的文件可壓縮的空間就越大。

【Q109】能夠對圖片開啓 gzip 壓縮嗎，爲何

不須要開啓，若是開啓的話，有可能使圖片變的更大。若是你注意一些網站的 img 資源時，就會發現他們都沒有開啓 gzip

參考: https://webmasters.stackexcha...

【Q110】http 的請求報文與響應報文的格式是什麼

以 nc 模擬 http 報文以下

$ nc www.baidu.com 80
GET / HTTP/1.1
Host: www.baidu.com

HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 14615
Content-Type: text/html
Date: Tue, 10 Dec 2019 02:48:44 GMT
P3p: CP=" OTI DSP COR IVA OUR IND COM "
P3p: CP=" OTI DSP COR IVA OUR IND COM "
Pragma: no-cache
Server: BWS/1.1
Set-Cookie: BAIDUID=F0FC6B3A056DEA285F51A1F2F8A170BB:FG=1; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BIDUPSID=F0FC6B3A056DEA285F51A1F2F8A170BB; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: PSTM=1575946124; expires=Thu, 31-Dec-37 23:55:55 GMT; max-age=2147483647; path=/; domain=.baidu.com
Set-Cookie: BAIDUID=F0FC6B3A056DEA287CB2B9422E09E30E:FG=1; max-age=31536000; expires=Wed, 09-Dec-20 02:48:44 GMT; domain=.baidu.com; path=/; version=1; comment=bd
Traceid: 1575946124058431156210725656341129791126
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1

<!DOCTYPE html><!--STATUS OK-->
........內容省略

【Q111】http 響應頭中的 ETag 值是如何生成的

關於 etag 的生成須要知足幾個條件

當文件不會更改時，etag 值保持不變。因此不能單純使用 inode
便於計算，不會特別耗 CPU。這樣子 hash 不是特別合適
便於橫向擴展，多個 node 上生成的 etag 值一致。這樣子 inode 就排除了

關於服務器中 etag 如何生成能夠參考 HTTP: Generating ETag Header

那麼在 nginx 中的 etag 是如何生成的？

nginx 中 ETag 的生成

我在網上找到一些資料與源代碼瞭解到了 etag 的計算方法。由 python 僞代碼表示計算方法以下

etag = '{:x}-{:x}'.format(header.last_modified, header.content_lenth)

源碼: ngx_http_core_modules.c

etag->value.len = ngx_sprintf(etag->value.data, "\"%xT-%xO\"",
                                  r->headers_out.last_modified_time,
                                  r->headers_out.content_length_n)
                      - etag->value.data;

總結：nginx 中 etag 由響應頭的 Last-Modified 與 Content-Length 表示爲十六進制組合而成。

隨手在個人k8s集羣裏找個 nginx 服務測試一下

$ curl --head 10.97.109.49
HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Tue, 10 Dec 2019 06:45:24 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Apr 2019 10:18:21 GMT
Connection: keep-alive
ETag: "5cbee66d-264"
Accept-Ranges: bytes

由 etag 計算 Last-Modified 與 Content-Length，使用 js 計算以下，結果相符

> new Date(parseInt('5cbee66d', 16) * 1000).toJSON()
"2019-04-23T10:18:21.000Z"
> parseInt('264', 16)
612

Last-Modified，ETag 與協商緩存

咱們知道協商緩存有兩種方式

Last-Modified/if-Modified-Since
ETag/If-None-Match

既然在 nginx 中 ETag 由 Last-Modified 和 Content-Length 組成，那它便算是一個增強版的 Last-Modified 了，那增強在什麼地方呢？

Last-Modified 是由一個 unix timestamp 表示，則意味着它只能做用於秒級的改變

那下一個問題：若是 http 響應頭中 ETag 值改變了，是否意味着文件內容必定已經更改

【Q112】若是 http 響應頭中 ETag 值改變了，是否意味着文件內容必定已經更改

不必定，由服務器中 ETag 的生成算法決定。詳見 #112

好比 nginx 中的 etag 由 last_modified 與 content_length 組成，而 last_modified 又由 mtime 組成

當編輯文件卻未更改文件內容時，或者 touch file，mtime 也會改變，此時 etag 改變，可是文件內容沒有更改。

【Q116】http 服務中靜態文件的 Last-Modified 是根據什麼生成的

通常會選文件的 mtime，表示文件內容的修改時間

nginx 也是這樣處理的，源碼見: ngx_http_static_module.c

r->headers_out.status = NGX_HTTP_OK;
    r->headers_out.content_length_n = of.size;
    r->headers_out.last_modified_time = of.mtime;

關於爲何使用 mtime 而非 ctime，能夠參考 #116

【Q117】既然 http 是無狀態協議，那它是如何保持登陸狀態

經過 cookie 或者 Authorization header 來傳遞憑證，在服務端進行認證

【Q119】https 是如何保證報文安全的

https主要解決三個安全問題：

內容隱私
防篡改
確認對方身份

https並非直接經過非對稱加密傳輸過程，而是有握手過程，握手過程主要是和服務器作通信，生成私有祕鑰，最後經過該祕鑰對稱加密傳輸數據。還有驗證證書的正確性。
證書驗證過程保證了對方是合法的，而且中間人沒法經過僞造證書方式進行攻擊。

【Q121】咱們如何從 http 的報文中得知該服務使用的技術棧

通常有兩個 response header，有時服務端爲了隱蔽本身真實的技術棧會隱蔽這兩個字段

X-Powerd-By
Server

【Q122】在發送 http 請求報文時，Host 是必要的嗎

是有必要的，由於咱們不知道會途徑會不會有代理出現，若是直接到達服務器的話，服務器是能夠經過路徑知道資源在哪，可是若是經過代理的話，代理沒法得知具體服務器是什麼地址

【Q133】http 響應頭中若是 content-type 爲 application/octet-stream，則表明什麼意思

表明二進制流，通常用如下載文件

【Q136】http 向 https 作重定向應該使用哪一個狀態碼

通常用做 301 的較爲多，可是也有使用 302，若是開啓了 HSTS 則會使用 307

如知乎使用了 302，淘寶使用了 301

$ curl --head www.zhihu.com
HTTP/1.1 302 Found
Date: Tue, 24 Dec 2019 00:13:54 GMT
Content-Length: 22
Connection: keep-alive
Server: NWS_TCloud_IPV6
Location: https://www.zhihu.com/
X-NWS-LOG-UUID: 0e28d9a1-6aeb-42cd-9f6b-00bd6cf11500

$ curl --head www.taobao.com
HTTP/1.1 301 Moved Permanently
Server: Tengine
Date: Tue, 24 Dec 2019 00:13:58 GMT
Content-Type: text/html
Content-Length: 278
Connection: keep-alive
Location: https://www.taobao.com/
Via: cache20.cn1480[,0]
Timing-Allow-Origin: *
EagleId: 6f3f38a815771464380412555e

【Q141】http 響應頭中的 Date 與 Last-Modified 有什麼不一樣，網站部署時須要注意什麼

LM-Factor 與它倆有關。

簡而言之，一個靜態資源沒有設置 Cache-Control 時會以這兩個響應頭來設置強制緩存時間，而非直接進行協商緩存。在涉及到 CDN 時，表現更爲明顯，體如今更新代碼部署後，界面沒有更新。

【Q144】http 1.1 中的 keep-alive 有什麼做用

在 http 1.1 中，在響應頭中設置 keep-alive 能夠在一個 TCP 鏈接上發送多個 http 請求

避免了重開 TCP 鏈接的開銷
避免了刷新時從新創建 SSL 鏈接的開銷
避免了QPS過大時，服務器的鏈接數過大

在服務器端使用響應頭開啓 keep-alive

Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。