記錄 - 4.27
mysql
如何比較日期數(shù)據(jù)？diffdate 函數(shù)和 timestampdiff 函數(shù)
“diffdate(a.日期, b.日期) = 1”或者“timestampdiff(day, a.日期, b.日期) = -1”
DNS 服務(wù)
瀏覽器會先看自身有沒有對這個域名的緩存
就去問操作系統(tǒng)，操作系統(tǒng)也會去看自己的緩存
去 hosts 文件看
「本地 DNS 服務(wù)器」。
如果本地DNS服務(wù)器緩存中沒有，會一級一級往上找，直到根域名服務(wù)器。根域名服務(wù)器是最高層次的，它不直接用于域名解析，但能指明一條道路。只指路不帶路。
HTTP
HTTPS 的優(yōu)化
對于硬件優(yōu)化的方向，選擇計算力更強(qiáng)的 CPU，而且最好選擇支持 AES-NI 特性的 CPU，這個特性可以在硬件級別優(yōu)化 AES 對稱加密算法，加快應(yīng)用數(shù)據(jù)的加解密。
對于軟件優(yōu)化的方向，如果可以，把軟件升級成較新的版本，比如將 Linux 內(nèi)核 2.X 升級成 4.X，將 openssl 1.0.1 升級到 1.1.1，因為新版本的軟件不僅會提供新的特性，而且還會修復(fù)老版本的問題。
協(xié)議優(yōu)化：
密鑰交換算法應(yīng)該選擇 ECDHE 算法，而不用 RSA 算法，因為 ECDHE 算法具備前向安全性，而且客戶端可以在第三次握手之后，就發(fā)送加密應(yīng)用數(shù)據(jù)，節(jié)省了 1 RTT。
將 TLS1.2 升級 TLS1.3，因為 TLS1.3 的握手過程只需要 1 RTT，而且安全性更強(qiáng)。
證書優(yōu)化：
服務(wù)器應(yīng)該選用 ECDSA 證書，而非 RSA 證書，因為在相同安全級別下，ECC 的密鑰長度比 RSA 短很多，這樣可以提高證書傳輸?shù)男剩?/span>
服務(wù)器應(yīng)該開啟 OCSP Stapling 功能，由服務(wù)器預(yù)先獲得 OCSP 的響應(yīng)，并把響應(yīng)結(jié)果緩存起來，這樣 TLS 握手的時候就不用再訪問 CA 服務(wù)器，減少了網(wǎng)絡(luò)通信的開銷，提高了證書驗證的效率；
重連 HTTPS 時，進(jìn)行會話復(fù)用
常見的會話重用技術(shù)有 Session ID 和 Session Ticket，用了會話重用技術(shù)，當(dāng)再次重連 HTTPS 時，只需要 1 RTT 就可以恢復(fù)會話。對于 TLS1.3 使用 Pre-shared Key 會話重用技術(shù)，只需要 0 RTT 就可以恢復(fù)會話。
這些會話重用技術(shù)雖然好用，但是存在一定的安全風(fēng)險，它們不僅不具備前向安全，而且有重放攻擊的風(fēng)險，所以應(yīng)當(dāng)對會話密鑰設(shè)定一個合理的過期時間。
HTTP /2
二進(jìn)制幀
幀類型后面的一個字節(jié)是標(biāo)志位，可以保存 8 個標(biāo)志位，用于攜帶簡單的控制信息，比如：
END_HEADERS 表示頭數(shù)據(jù)結(jié)束標(biāo)志，相當(dāng)于 HTTP/1 里頭后的空行（“\r\n”）；
END_Stream 表示單方向數(shù)據(jù)發(fā)送結(jié)束，后續(xù)不會再有數(shù)據(jù)幀。
PRIORITY 表示流的優(yōu)先級；
幀頭的最后 4 個字節(jié)是流標(biāo)識符（Stream ID），但最高位被保留不用，只有 31 位可以使用，因此流標(biāo)識符的最大值是 2^31，它用來標(biāo)識該 Frame 屬于哪個 Stream，接收方可以根據(jù)這個信息從亂序的幀里找到相同 Stream ID 的幀，從而有序組裝信息。
最后面就是幀數(shù)據(jù)了，它存放的是通過 HPACK 算法壓縮過的 HTTP 頭部和包體。
并發(fā)傳輸
不同 Stream 的幀是可以亂序發(fā)送的（因此可以并發(fā)不同的 Stream ），因為每個幀的頭部會攜帶 Stream ID 信息，所以接收端可以通過 Stream ID 有序組裝成 HTTP 消息，而同一 Stream 內(nèi)部的幀必須是嚴(yán)格有序的。
同一個連接中的 Stream ID 是不能復(fù)用的，只能順序遞增，所以當(dāng) Stream ID 耗盡時，需要發(fā)一個控制幀 GOAWAY，用來關(guān)閉 TCP 連接。
能對Stream進(jìn)行優(yōu)先級的設(shè)定，可以讓圖片等資源后傳輸。
HTTP /2 存在的缺陷
隊頭阻塞、TCP與TLS的握手延遲、網(wǎng)絡(luò)遷移需要重新連接
HTTP /3
連接遷移：
通過連接ID來標(biāo)記通信，即使ip地址變化了，只要仍保有上下文信息，就可以復(fù)用連接。
HTTP/2 和 HTTP/3 的 Huffman 編碼并沒有多大不同，但是動態(tài)表編解碼方式不同。
所謂的動態(tài)表，在首次請求-響應(yīng)后，雙方會將未包含在靜態(tài)表中的 Header 項更新各自的動態(tài)表，接著后續(xù)傳輸時僅用 1 個數(shù)字表示，然后對方可以根據(jù)這 1 個數(shù)字從動態(tài)表查到對應(yīng)的數(shù)據(jù)，就不必每次都傳輸長長的數(shù)據(jù)，大大提升了編碼效率。
動態(tài)表是具有時序性的，如果首次出現(xiàn)的請求發(fā)生了丟包，后續(xù)的收到請求，對方就無法解碼出 HPACK 頭部，因為對方還沒建立好動態(tài)表，因此后續(xù)的請求解碼會阻塞到首次請求中丟失的數(shù)據(jù)包重傳過來。
HTTP/3 的 QPACK 解決了這一問題：QUIC 會有兩個特殊的單向流。
一個叫 QPACK Encoder Stream，用于將一個字典（Key-Value）傳遞給對方，比如面對不屬于靜態(tài)表的 HTTP 請求頭部，客戶端可以通過這個 Stream 發(fā)送字典；
一個叫 QPACK Decoder Stream，用于響應(yīng)對方，告訴它剛發(fā)的字典已經(jīng)更新到自己的本地動態(tài)表了，后續(xù)就可以使用這個字典來編碼了。
