Java 工程師面試小抄——長連接與短連接

面試就是把沒做過的說的跟做過一樣， 做過的說的對方聽不懂， 這就是我寫面試小抄的核心價值觀。 有些東西肯定是要背下來的， 就算面試官很nice讓你做填空題， 甚至選擇題， 那也顯示不出你的水準。 只有你自己說出來， 才能顯示出你的專業素養和業務邏輯。

畢業時間短， 工作專案low， 這都是客觀因素， 面試官不會管的， 所以我們要自己努力， 把沒有做過的說的跟做過一樣， 把做過的說的他聽不懂， 這樣才能拿下offer。

什麼是長連接

面試時候面試官往往會啪嘰蹦出一個專業名詞問你知道不， 你要說不知道直接完蛋。

我去京東面試， 那位面試官就不厚道， 直接蹦出一個長連接（可能看我簡歷寫著socket程式設計）。

長連接第一式：概念起源， HTTP1.1協議規定了預設保持長連接（HTTP persistent connect， 也有翻譯為持久連接）， 資料傳輸完成， 保持TCP連接不斷開（不發RST包， 不四次握手）， 等待同功能變數名稱下繼續用這個通道傳輸資料；相反就是短連接。

長連接第二式：知識拓展， HTTP頭部的Connection:Keep-alive是HTTP1.0流覽器和伺服器的實驗性擴展。 當前的HTTP1.1 RFC2616文檔沒有對它做說明， 因為它所需要的功能已經預設開啟， 無須帶著它， 但是實踐中可以發現， 流覽器的報文請求都會帶上它。 如果HTTP1.1版本的HTTP請求報文不希望使用長連接， 則要在HTTP請求報文首部加上Connection: close。

流覽器發送HTTP協議的報文頭

長連接第三式：編造工作經歷，

筆者工作一年半並沒有遇到過需要考慮長連接的事例， 但這不能說， 為什麼呢面試官就出十道題， 你放棄幾道題， 成績能高嗎？比如：我遇到過一次長連接失效的情況， 一個老的專案使用HTTP1.0的代理（用戶端->代理->伺服器）不理解keep-live。 後來換成Nginx代理， 它有長連接處理邏輯， 伺服器無需做patch處理， 這樣用戶端和Nginx代理伺服器使用HTTP1.1協定和長連接， 而Nginx和後端伺服器使用HTTP1.0和短連接。

參考文章：https://www.cnblogs.com/cswuyg/p/3653263.html