1. 程式人生 > >被問到到http的時候你就這麼回答!

被問到到http的時候你就這麼回答!

> 大家好,我是標題黨,啊不,我是小雨小雨,致力於分享有趣的、實用的技術文章。 > 內容分為翻譯和原創,如果有問題,歡迎隨時評論或私信,希望和大家一起進步。 > 分享不易,希望能夠得到大家的支援和關注。 ### 什麼是網際網路 網際網路是指 凡是 能彼此通訊的裝置組成的網路就叫網際網路,指利用`TCP/IP`通訊協定所建立的各種網路,是國際上最大的網際網路,也稱“國際網際網路”。 其中`TCP/IP`是網路的基礎通訊架構,提供了點對點連結的機制。並且將軟體通訊過程抽象化為四個抽象層,下層服務上層,也就是我們熟悉的七層OSI模型。(也就是說`TPC/IP`是聯網的基礎,由他衍生出了`OSI`) `OSI`模型是一個檢視使各種計算機在世界範圍能互連線為網路的標準框架,也就是說是網路互接的標準。(大白話就是規則。按照這個規則,我們就能聯網) 用一張圖表示`OSI`模型: ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff4b5caf6c62?w=1656&h=930&f=png&s=205002) 如果討論TCP/IP的時候,我們又可以分為四層,如下圖: ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff5687e3dc49?w=1784&h=650&f=png&s=195819) 看看就好,我們要關注的是應用層的http和傳輸層的tcp,對了,兩個模型的對應關係如下: ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff502fea24c6?w=1118&h=926&f=png&s=263844) 由於TCP、UDP位於傳輸層,HTTP位於應用層,按照下層服務於上層的機制,我們從TCP、UDP開始說起。 ### UDP是什麼 UDP位於OSI模型的傳輸層,是一種無連線的協議,該標準定義的內容很專一,就是資料無腦發資料,不管天崩地裂,海枯石爛,發就完了。為啥這個莽夫是不可靠的呢? - 無連線:就比如小雨去上班,不管他周內還是週末,上就完了,自然而然就會有一些問題發生 - 恆速:這個莽夫沒有擁塞控制系統,也就是不會變通,一根筋按照一個頻率進行發收運動,就算對方受不了了,UDP也不會改變它的頻率。 - 簡單:這貨頭部開銷小,只有八位元組,比tcp要少三倍左右,所以就很快。 ![](https://user-gold-cdn.xitu.io/2020/3/28/1711fff4a59afdf5?w=451&h=233&f=gif&s=3925094) 不過,正由於UDP的快,也有一些場景是非他莫屬的,比如DNS啊、音視訊啊、實時遊戲啊、聊天工具啊巴拉巴拉... 可能有人會問,DNS這種使用UDP會不會有問題啊,比如UDP丟包了,那豈不是返回404了啊。 沒錯,但是瀏覽器響應時間大致分為以下三個: > DNS解析 + TCP連結 + HTTP請求/響應 除了DNS能用UDP,其他二位也沒法用啊,不然網站丟內容了啊。而且還有備選方案,某種情況下失敗了會利用TCP重新查詢的,不只是有UDP一種。 可能還有人會問,那聊天工具這種用UDP這問題大了啊,我要是跟我女神表白,這莽夫只管發,結果各種丟包(傳送失敗),而且我還不知道,那我心態崩了啊。我以為她知道,結果她不知道,然後她還不回我,你讓我咋想... 只能說,為啥不能給女神留下神祕感,讓她來主動找你呢,哈哈哈 其實通訊工具一般會發送兩次,UDP傳送一個訊息後,如果伺服器收到了,會用UDP在返你一個訊息,如果沒返回,或者傳送失敗,你就會收到傳送失敗類似的訊息啦,去表白吧,沒事的,訊息肯定發的出去,答不答應就看自己了。 總的來說,在某些對速度要求極高,但是準確性要求低的情況,UDP是很適合的。 ### TCP是什麼 UDP莽夫不靠譜,TCP小夥來彌補。 關於TCP,我覺得可以用擬人化來代表,眾所周知TCP是全雙工的嗎,其實就是兩個獨立的人在進行微信聊天。光一個人發是不行的,另一個人也得發,不然聊個j。 那TCP怎麼就靠譜了呢? 沒錯,小夥看日曆了!!!而且更厲害的是,他休假的時候也會看日曆!!! ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff503004de81?w=240&h=240&f=jpeg&s=4495) 其實就是TCP在傳送資料的前後,會進行連線建立和連線終止的操作。保證事務完整性。這就是我們經常被問到的問題:三次握手和四次揮手。 #### 三次握手建立連線 > 提前宣告,關於每個標誌的格式和內容是什麼,這裡不做討論,有興趣的自行研究。這些定義用到的時候再查就好。 在此之前,要先解釋幾個名詞(又是名詞,大白話不好嗎 doge~) - SYN: 表示建立連線,如果我給你的訊息裡有這個標誌,說明我想和你負距離接觸,當然這是雙向的,你也可以給我發。 - FIN: 表示關閉連線,同上,不過表示我好了,請你離開 - SEQ: 表示初始包序號,隨時間變化。就是說我希望你從從這數字開始計數,其實就是確保雙方都是本人,不能隨便帶個序號來都能進行工作,那就亂了 - ACK: 表示響應,就是說我成功得到了你給我的內容 - PSH: 表示有DATA資料傳輸 - RST: 表示連線重置。 好,進入正題,先看張圖吧 ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff7a1b12e158?w=601&h=832&f=png&s=40429) 看完圖可能就豁然開朗了吧。不過,其實我還少說了一部分,這些內容的值是什麼呢? 咱們看個建立連結的真例項子(訪問百度的抓包)吧! ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff4b6eec871a?w=1240&h=83&f=png&s=18652) 可以清楚地看到,經過三次tcp握手後,通道建立成功,然後傳送了http請求,也側向驗證了傳輸層服務應用層。 還可以看到每次傳送tcp的時候,seq ack這類值都會發生變化,這個是關鍵,上面說了他們的定義,但是沒說為啥要用這些。 這是因為我們要確認連線雙方的確定性,進而建立可靠連線。 客戶端傳送請求連線百度,然後傳送帶有SYN標誌的tcp到服務端,告訴服務端,我想和你連線。 服務端如果沒收到,那就算了,如果收到了,就會返回表示接收到了的ACK訊號,併發送服務端的SYN與客戶端建立連線,這是雙向的、可靠地。 如果服務端傳送過客戶端沒收到呢?服務端會定時重新發送,知道成功或超過最大限制未知。簡化版心跳機制吧。 客戶端收到了服務端發的SYN和ACK,會再次傳送代表接收到了的ACK訊號,告訴服務端,我ok了 上圖中後兩次ACK的值為1就代表是響應成功1次。 其實更通俗的來講,就是下一次的tcp通訊要能證明上一次的tcp通訊是成功的。 就比如說ack,我第一次請求連線的時候,初始ack肯定為0,然後你發給我的為1,就證明了我第一次請求是成功的,反之亦然,可以自己思考一下,有問題歡迎交流。 到這裡可能有人會問,為啥一定是三次呢?因為下一次的tcp通訊要能證明上一次的tcp通訊是成功的啊。不然你試試兩次,看看能不能證明。這是的三次是最小次數,保證效率,三次通訊以上理論上都是可以的,但是沒必要。 ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ffecac154430?w=451&h=233&f=gif&s=3822367) #### 四次揮手斷開連線 四次揮手其實和上面差不多,不過SYN變成了FIN,用來'觸發'斷開連線操作。操作其實是一樣的。 那為啥不能和建立連線一樣,三次不就好了嘛,還效率。 舉個可能不算恰當的例子:建立連線是往一個空的容器里加東西,加就完了,反正剛開始是空的。而斷開連線在不加東西之後,還需要將容器裡的東西清理掉,有始有終。 一圖以蔽之: ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff503f8b8ef7?w=602&h=1032&f=png&s=48201) 還不明白,私聊我,我懟懟你!!! ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff5040096126?w=240&h=240&f=png&s=22952) 好了,傳輸層任務完成,應用層啟動~ ### HTTP和HTTPS 能說的很多,但是感覺又沒啥好說的,隨便說說吧就。 首先我們知道https就是http,不過加了一層安全控制: SSL/TLS。 #### 怎麼就安全了捏? 我們知道http是明文傳輸的,也無法校驗內容的完整性。並且由於是無狀態連結,所以也不知道這東西是誰發的,會不會被人改過。 那https的s到底做了啥? 加密! ##### 對稱加密 就是我們門禁,對,就賓館的那種。我們可以將要傳送的內容保護起來,放到賓館裡,然後通過門禁(金鑰)來訪問內容。看起來很安全哈。但是如果這個門禁被人偷偷拿走複製了一份,那我們的內容就可以被其他人隨意訪問了。這是不靠譜的,我們沒隱私了,赤裸裸~ ##### 非對稱加密 我們換個方案吧,我們讓賓館提供兩張門禁卡,一個公開的,所有人都可以知道,一個是私有的,只有負責人才知道,然後賓館的房間改為兩道門,外面的門可以用公開的門禁開啟(公鑰加密),裡面的門可以用私鑰開啟(私鑰解密),並且裡面的門有一個通道,可以讓有公鑰的人將內容放到房間內。由於裡面的門只能用私鑰開啟,所以只有負責人能夠檢視這個內容。 ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff4b71b6ca06?w=952&h=442&f=png&s=27949) 這就是非對稱加密,使用兩個金鑰,一個是公開的 - 公鑰,一個是私密的 - 金鑰。然後我們把公鑰散播出去就可以了。 但是非對稱加密的速度比對稱加密要慢很多,這也不是我們想要的。並且單純的非對稱加密,只能保證用公鑰加密私密資訊只能被擁有私鑰的負責人檢視。 > ps: 筆者還有個問題想不明白,如果公鑰隨意分發,那有圖謀不軌的人隨意進行通訊,雖然沒問題,可以通過服務端進行控制。但是這樣感覺怪怪的~ ##### 怎麼能讓它快起來呢? 對稱加密和非對稱加密混這用,對稱加密用於內容,非對稱加密用於對稱加密金鑰的傳輸。 這樣我們就只用到了一次非對稱加密,然後就可以用對稱加密進行內容的解析。大大提升的速度。 但是這其中有個很嚴重的問題。如果在伺服器傳送對稱加密金鑰的時候,被某個壞人擷取到了,這樣不但獲取到了伺服器的公鑰,還可以給瀏覽器傳送他的公鑰,相當於中間人的角色。瀏覽器和伺服器在不知情的情況下進行危險的通訊活動。 ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff67e0b00e13?w=741&h=511&f=png&s=37094) ##### 怎麼證明公鑰的正確性 這就要利用非對稱加密的另一個功能,數字證書。因為私鑰是唯一,所以我們可以用私鑰進行加密(簽名),這樣只有正確的公鑰才能開鎖。保證了內容是安全的。 並且需要瀏覽器內建一些安全的公鑰,用於解析這個證書,這就是證書中心(CA)的作用了。證書中心是一個絕對有保障的組織,他們會和作業系統、瀏覽器廠商協定,將證書中心(CA)的公鑰提前種好。 上面是前提,接下來,伺服器會提前找證書中心為公鑰做認證,然後返回伺服器數字證書。證書的內容是通過證書中心私鑰加密過得伺服器相關資訊和伺服器公鑰,這樣就保證了公鑰無法被篡改,保障了安全。 ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff4c07163deb?w=650&h=427&f=png&s=15243) 之後瀏覽器在請求的時候,就會獲取到正確的公鑰。之後伺服器返回內容的時候也會進行一步處理,保障內容不會被篡改。 瀏覽器會返回兩部分,一部分是明文的hash演算法結果。一部分是用伺服器私鑰加密過得明文的hash演算法結果,然後瀏覽器在獲取後,會通過hash和伺服器公鑰進行解密,得到的兩部分如果相等,那麼這次傳輸的內容就沒問題。可以愉快地進行通訊啦~ 看明白了是不是會問為啥要進行hash在加密啊,直接加密不就好了嗎?答案很簡單啊,因為效率。 #### 優化 - tcp三次握手可以利用'會話快取'來節省一次握手時間,其實就是快取,和咱們平常寫程式碼沒差,就是寫法不一樣。我們平常用到的很多技術很多也是一些基本的技術,舉一反三就好。 - 和上面差不多。tcp第二次握手的時候就可以發資料了,可以在這上面做手腳 - 儘量減少rsa演算法,實在是慢,這個想辦法快取或者演算法優化吧,我也不太懂~ - 證書優化,怎麼便宜怎麼來唄,薅!!!不過也得看企業/個人怎麼取捨了 - 等~ 不做深入了 ### 總結 本文內容是理解後經過處理展示出來的,不理解的也不會亂寫,如果仍有問題歡迎指出,我會及時回覆的。 瞭解這幾點,對於http基礎會有一個整體的理解,不管是工作中還是求職中都能說出個一二三來,或許還應該寫一點常見問題,但是微乎其微,等用到了自然而然就知道了。 馬上清明節了吧,祝大家清明節快樂!!哈哈哈哈~ ![](https://user-gold-cdn.xitu.io/2020/3/28/1711ff7a1b7d3056?w=240&h=212&f=jpeg&s=9442) > 部分圖片來源自網路,侵刪 [面試答案(滑稽~](https://github.com/wolverinn/Waking-Up/blob/master/Computer%20Network.md#HTTP%E5%92%8CHTTPS%E6%9C%89%E4%BB%80%E4%B9%88%E5%8C%BA%E5%88%AB) [面試答案(老稽~](https://zhuanlan.zhihu.com/p/86426969) [wireshark血淚史](https://www.zhoulujun.cn/html/tools/NetTools/PacketCapture/7908.html) [含義](https://blog.csdn.net/wudiyi815/article/details/8505726) [如何使用wireshark](https://zhuanlan.zhihu.com/p/82498482) [TCP&UDP](https://zhuanlan.zhihu.com/p/60017840) [DNS為什麼用UDP](https://www.zhihu.com/question/310145373) [介倆活寶啊(一)](https://songlee24.github.io/2015/05/03/public-key-and-private-key/) [介倆活寶啊(二)](https://blog.csdn.net/21aspnet/article/details/7249401) [峰寶](https://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signatur