如果「服務端掛掉」指的是「服務端進程崩潰」，那么這個讀者猜的想法是對的，服務端的進程在發(fā)生崩潰的時候，內核會發(fā)送 FIN 報文，與客戶端進行四次揮手。
大家好，我是小林。之前有讀者問我平時怎么充電的？為什么寫出那么多深入淺出的好文章？那當然還是看書，可能大部分人喜歡看視頻，看視頻沒錯，視頻可以作為我們入門的輔助方式，但是真的要深入到細節(jié)，真的離不開書。
咋一看，以為是在問操作系統(tǒng)的問題，其實這兩個題目都是在問如何改進 LRU 算法。因為傳統(tǒng)的 LRU 算法存在這兩個問題：
之前我也提到過，MySQL InnoDB 引擎的默認隔離級別雖然是「可重復讀」，但是它很大程度上避免幻讀現(xiàn)象（并不是完全解決了），解決的方案有兩種：
客戶端主動調用關閉連接的函數(shù)，于是就會發(fā)送 FIN 報文，這個 FIN 報文代表客戶端不會再發(fā)送數(shù)據(jù)了，進入 FIN_WAIT_1 狀態(tài)；
上周有位讀者字節(jié)一二面時，被問到：Redis 的大 Key 對持久化有什么影響？
之前寫過一篇 Redis 數(shù)據(jù)類型的底層數(shù)據(jù)結構的實現(xiàn)：為了拿捏 Redis 數(shù)據(jù)結構，我畫了 40 張圖
因為 URL 的信息都是保存在 HTTP Header 中的，而 HTTPS 是會對 HTTP Header + HTTP Body 整個加密的，所以 URL 自然是會被加密的。
這個問題的場景是這樣的：客戶端通過瀏覽器向服務端發(fā)起 HTTPS 請求時，被「假基站」轉發(fā)到了一個「中間人服務器」，于是客戶端是和「中間人服務器」完成了 TLS 握手，然后這個「中間人服務器」再與真正的服務端完成 TLS 握手。
大家好，我是小林。前幾天發(fā)了一篇「為了拿捏Redis數(shù)據(jù)結構，我畫了20張圖」，收獲了很多好評，但是當時急于發(fā)文，有些地方沒有寫完，也有些地方寫的不是很完善。然后我最近花了很多時間來完善文章，不僅加入了Redis新版本的兩個數(shù)據(jù)結構，也在之前的文章內容加入了很多內容。這次完整版終...
twtw
289117336
Tronlong創(chuàng)龍
大有可為
xingnan123
xiaoguaixh
liqinglong1023
sigma527
