【Q035】http 常見(jiàn)的狀態(tài)碼有哪些
在 Issue 中交流與討論: 答案解析
- 1XX 表示消息
- 2XX 表示成功
- 3XX 表示重定向
- 4XX 表示客戶(hù)端錯(cuò)誤
- 5XX 表示服務(wù)端錯(cuò)誤
常見(jiàn)的狀態(tài)碼
- 200
最喜歡見(jiàn)到的狀態(tài)碼，表示請(qǐng)求成功
- 301
永久重定向
- 302
臨時(shí)重定向
- 304
自上次請(qǐng)求，未修改的文件
- 400
錯(cuò)誤的請(qǐng)求
- 401
未被授權(quán)，需要身份驗(yàn)證，例如token信息等等
- 403
請(qǐng)求被拒絕
- 404
資源缺失，接口不存在，或請(qǐng)求的文件不存在等等
- 500
服務(wù)器端的未知錯(cuò)誤
- 502
網(wǎng)關(guān)錯(cuò)誤
- 503
服務(wù)暫時(shí)無(wú)法使用
【Q036】http 狀態(tài)碼中 301，302和307有什么區(qū)別
在 Issue 中交流與討論: 答案解析
- 301，Moved Permanently。永久重定向，該操作比較危險(xiǎn)，需要謹(jǐn)慎操作：如果設(shè)置了301，但是一段時(shí)間后又想取消，但是瀏覽器中已經(jīng)有了緩存，還是會(huì)重定向。
- 302，F(xiàn)ount。臨時(shí)重定向，但是會(huì)在重定向的時(shí)候改變 method: 把 POST 改成 GET，于是有了 307
- 307，Temporary Redirect。臨時(shí)重定向，在重定向時(shí)不會(huì)改變 method
【Q050】http 狀態(tài)碼 502 和 504 有什么區(qū)別
在 Issue 中交流與討論: 答案解析
502 Bad Gateway
The server was acting as a gateway or proxy and received an invalid response from the upstream server.
收到了上游響應(yīng)但無(wú)法解析504 Gateway Timeout
The server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
上游響應(yīng)超時(shí)
【Q079】簡(jiǎn)述 http 的緩存機(jī)制
在 Issue 中交流與討論: 答案解析
【Q081】http proxy 的原理是什么
<blockquote> 更多描述: 如 webpack-dev-server 可以設(shè)置 proxy，nginx 也可以設(shè)置 </blockquote>
在 Issue 中交流與討論: 答案解析
todo
【Q084】隨著 http2 的發(fā)展，前端性能優(yōu)化中的哪些傳統(tǒng)方案可以被替代
在 Issue 中交流與討論: 答案解析
- 雪碧圖
- 資源文件合并
【Q085】http2 與 http1.1 有什么不同
在 Issue 中交流與討論: 答案解析
【Q107】什么是 Basic Auth 和 Digest Auth
在 Issue 中交流與討論: 答案解析
【Q108】gzip 的原理是什么
在 Issue 中交流與討論: 答案解析
gzip 使用了 LZ77 算法與 Huffman 編碼來(lái)壓縮文件，重復(fù)度越高的文件可壓縮的空間就越大。
【Q109】可以對(duì)圖片開(kāi)啟 gzip 壓縮嗎，為什么
在 Issue 中交流與討論: 答案解析
不需要開(kāi)啟，如果開(kāi)啟的話(huà)，有可能使圖片變的更大。如果你注意一些網(wǎng)站的 img 資源時(shí)，就會(huì)發(fā)現(xiàn)他們都沒(méi)有開(kāi)啟 gzip
Don't use gzip for image or other binary files.
Image file formats supported by the web, as well as videos, PDFs and other binary formats, are already compressed; using gzip on them won't provide any additional benefit, and can actually make them larger. To compress images, see Optimize images.
【Q110】http 的請(qǐng)求報(bào)文與響應(yīng)報(bào)文的格式是什么
在 Issue 中交流與討論: 答案解析
以 nc 模擬 http 報(bào)文如下
$ 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-->
........內(nèi)容省略
【Q111】http 響應(yīng)頭中的 ETag 值是如何生成的
在 Issue 中交流與討論: 答案解析
關(guān)于 etag 的生成需要滿(mǎn)足幾個(gè)條件
- 當(dāng)文件不會(huì)更改時(shí)，
etag值保持不變。所以不能單純使用inode - 便于計(jì)算，不會(huì)特別耗 CPU。這樣子
hash不是特別合適 - 便于橫向擴(kuò)展，多個(gè)
node上生成的etag值一致。這樣子inode就排除了
關(guān)于服務(wù)器中 etag 如何生成可以參考 HTTP: Generating ETag Header
那么在 nginx 中的 etag 是如何生成的？
nginx 中 ETag 的生成
我在網(wǎng)上找到一些資料與源代碼了解到了 etag 的計(jì)算方法。由 python 偽代碼表示計(jì)算方法如下
etag = '{:x}-{:x}'.format(header.last_modified, header.content_lenth)
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;
總結(jié)：nginx 中 etag 由響應(yīng)頭的 Last-Modified 與 Content-Length 表示為十六進(jìn)制組合而成。
隨手在我的k8s集群里找個(gè) nginx 服務(wù)測(cè)試一下
$ 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 計(jì)算 Last-Modified 與 Content-Length，使用 js 計(jì)算如下，結(jié)果相符
> new Date(parseInt('5cbee66d', 16) * 1000).toJSON()
"2019-04-23T10:18:21.000Z"
> parseInt('264', 16)
612
Last-Modified，ETag 與協(xié)商緩存
我們知道協(xié)商緩存有兩種方式
-
Last-Modified/if-Modified-Since -
ETag/If-None-Match
既然在 nginx 中 ETag 由 Last-Modified 和 Content-Length 組成，那它便算是一個(gè)加強(qiáng)版的 Last-Modified 了，那加強(qiáng)在什么地方呢？
** Last-Modified 是由一個(gè) unix timestamp 表示，則意味著它只能作用于秒級(jí)的改變**
那下一個(gè)問(wèn)題：如果 http 響應(yīng)頭中 ETag 值改變了，是否意味著文件內(nèi)容一定已經(jīng)更改
【Q112】如果 http 響應(yīng)頭中 ETag 值改變了，是否意味著文件內(nèi)容一定已經(jīng)更改
在 Issue 中交流與討論: 答案解析
不一定，由服務(wù)器中 ETag 的生成算法決定。詳見(jiàn) #112
比如 nginx 中的 etag 由 last_modified 與 content_length 組成，而 last_modified 又由 mtime 組成
當(dāng)編輯文件卻未更改文件內(nèi)容時(shí)，或者 touch file，mtime 也會(huì)改變，此時(shí) etag 改變，但是文件內(nèi)容沒(méi)有更改。
【Q116】http 服務(wù)中靜態(tài)文件的 Last-Modified 是根據(jù)什么生成的
在 Issue 中交流與討論: 答案解析
一般會(huì)選文件的 mtime，表示文件內(nèi)容的修改時(shí)間
nginx 也是這樣處理的，源碼見(jiàn): 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;
關(guān)于為什么使用 mtime 而非 ctime，可以參考 #116
【Q117】既然 http 是無(wú)狀態(tài)協(xié)議，那它是如何保持登錄狀態(tài)
在 Issue 中交流與討論: 答案解析
通過(guò) cookie 或者 Authorization header 來(lái)傳遞憑證，在服務(wù)端進(jìn)行認(rèn)證
【Q119】https 是如何保證報(bào)文安全的
在 Issue 中交流與討論: 答案解析
https主要解決三個(gè)安全問(wèn)題：
- 內(nèi)容隱私
- 防篡改
- 確認(rèn)對(duì)方身份
https并不是直接通過(guò)非對(duì)稱(chēng)加密傳輸過(guò)程，而是有握手過(guò)程，握手過(guò)程主要是和服務(wù)器做通訊，生成私有秘鑰，最后通過(guò)該秘鑰對(duì)稱(chēng)加密傳輸數(shù)據(jù)。還有驗(yàn)證證書(shū)的正確性。
證書(shū)驗(yàn)證過(guò)程保證了對(duì)方是合法的，并且中間人無(wú)法通過(guò)偽造證書(shū)方式進(jìn)行攻擊。
【Q121】我們?nèi)绾螐?http 的報(bào)文中得知該服務(wù)使用的技術(shù)棧
在 Issue 中交流與討論: 答案解析
一般有兩個(gè) response header，有時(shí)服務(wù)端為了隱蔽自己真實(shí)的技術(shù)棧會(huì)隱蔽這兩個(gè)字段
X-Powerd-ByServer
【Q122】在發(fā)送 http 請(qǐng)求報(bào)文時(shí)，Host 是必要的嗎
在 Issue 中交流與討論: 答案解析
是有必要的，因?yàn)槲覀儾恢罆?huì)途徑會(huì)不會(huì)有代理出現(xiàn)， 如果直接到達(dá)服務(wù)器的話(huà)，服務(wù)器是可以通過(guò)路徑知道資源在哪，但是如果通過(guò)代理的話(huà)，代理無(wú)法得知具體服務(wù)器是什么地址
【Q133】http 響應(yīng)頭中如果 content-type 為 application/octet-stream，則代表什么意思
在 Issue 中交流與討論: 答案解析
代表二進(jìn)制流，一般用以下載文件
【Q136】http 向 https 做重定向應(yīng)該使用哪個(gè)狀態(tài)碼
在 Issue 中交流與討論: 答案解析
一般用作 301 的較為多，但是也有使用 302，如果開(kāi)啟了 HSTS 則會(huì)使用 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 響應(yīng)頭中的 Date 與 Last-Modified 有什么不同，網(wǎng)站部署時(shí)需要注意什么
在 Issue 中交流與討論: 答案解析
LM-Factor 與它倆有關(guān)。
簡(jiǎn)而言之，一個(gè)靜態(tài)資源沒(méi)有設(shè)置 Cache-Control 時(shí)會(huì)以這兩個(gè)響應(yīng)頭來(lái)設(shè)置強(qiáng)制緩存時(shí)間，而非直接進(jìn)行協(xié)商緩存。在涉及到 CDN 時(shí)，表現(xiàn)更為明顯，體現(xiàn)在更新代碼部署后，界面沒(méi)有更新。
【Q144】http 1.1 中的 keep-alive 有什么作用
在 Issue 中交流與討論: 答案解析
在 http 1.1 中，在響應(yīng)頭中設(shè)置 keep-alive 可以在一個(gè) TCP 連接上發(fā)送多個(gè) http 請(qǐng)求
- 避免了重開(kāi) TCP 連接的開(kāi)銷(xiāo)
- 避免了刷新時(shí)重新建立 SSL 連接的開(kāi)銷(xiāo)
- 避免了QPS過(guò)大時(shí)，服務(wù)器的連接數(shù)過(guò)大
在服務(wù)器端使用響應(yīng)頭開(kāi)啟 keep-alive
Connection: Keep-Alive
Keep-Alive: timeout=5, max=1000
我是山月，可以加我微信
shanyue94與我交流，備注交流。另外可以關(guān)注我的公眾號(hào)【全棧成長(zhǎng)之路】
