你們好,我是標題黨,啊不,我是小雨小雨,致力於分享有趣的、實用的技術文章。 內容分爲翻譯和原創,若是有問題,歡迎隨時評論或私信,但願和你們一塊兒進步。 分享不易,但願可以獲得你們的支持和關注。html
互聯網是指 凡是 能彼此通訊的設備組成的網絡就叫互聯網,指利用TCP/IP
通信協定所建立的各類網絡,是國際上最大的互聯網,也稱「國際互聯網」。git
其中TCP/IP
是網絡的基礎通訊架構,提供了點對點連接的機制。而且將軟件通訊過程抽象化爲四個抽象層,下層服務上層,也就是咱們熟悉的七層OSI模型。(也就是說TPC/IP
是聯網的基礎,由他衍生出了OSI
)github
OSI
模型是一個視圖使各類計算機在世界範圍能互鏈接爲網絡的標準框架,也就是說是網絡互接的標準。(大白話就是規則。按照這個規則,咱們就能聯網)面試
用一張圖表示OSI
模型:算法
若是討論TCP/IP的時候,咱們又能夠分爲四層,以下圖:瀏覽器
看看就好,咱們要關注的是應用層的http和傳輸層的tcp,對了,兩個模型的對應關係以下:緩存
因爲TCP、UDP位於傳輸層,HTTP位於應用層,按照下層服務於上層的機制,咱們從TCP、UDP開始提及。安全
UDP位於OSI模型的傳輸層,是一種無鏈接的協議,該標準定義的內容很專注,就是數據無腦發數據,無論天崩地裂,海枯石爛,發就完了。爲啥這個莽夫是不可靠的呢?服務器
不過,正因爲UDP的快,也有一些場景是非他莫屬的,好比DNS啊、音視頻啊、實時遊戲啊、聊天工具啊巴拉巴拉...微信
可能有人會問,DNS這種使用UDP會不會有問題啊,好比UDP丟包了,那豈不是返回404了啊。
沒錯,可是瀏覽器響應時間大體分爲如下三個:
DNS解析 + TCP連接 + HTTP請求/響應
除了DNS能用UDP,其餘二位也無法用啊,否則網站丟內容了啊。並且還有備選方案,某種狀況下失敗了會利用TCP從新查詢的,不僅是有UDP一種。
可能還有人會問,那聊天工具這種用UDP這問題大了啊,我要是跟我女神表白,這莽夫只管發,結果各類丟包(發送失敗),並且我還不知道,那我心態崩了啊。我覺得她知道,結果她不知道,而後她還不回我,你讓我咋想...
只能說,爲啥不能給女神留下神祕感,讓她來主動找你呢,哈哈哈
其實通信工具通常會發送兩次,UDP發送一個消息後,若是服務器收到了,會用UDP在返你一個消息,若是沒返回,或者發送失敗,你就會收到發送失敗相似的消息啦,去表白吧,沒事的,消息確定發的出去,答不答應就看本身了。
總的來講,在某些對速度要求極高,可是準確性要求低的狀況,UDP是很適合的。
UDP莽夫不靠譜,TCP小夥來彌補。
關於TCP,我以爲能夠用擬人化來表明,衆所周知TCP是全雙工的嗎,其實就是兩個獨立的人在進行微信聊天。光一我的發是不行的,另外一我的也得發,否則聊個j。
那TCP怎麼就靠譜了呢?
沒錯,小夥看日曆了!!!並且更厲害的是,他休假的時候也會看日曆!!!
其實就是TCP在發送數據的先後,會進行鏈接建立和鏈接終止的操做。保證事務完整性。這就是咱們常常被問到的問題:三次握手和四次揮手。
提早聲明,關於每一個標誌的格式和內容是什麼,這裏不作討論,有興趣的自行研究。這些定義用到的時候再查就好。
在此以前,要先解釋幾個名詞(又是名詞,大白話很差嗎 doge~)
好,進入正題,先看張圖吧
看完圖可能就豁然開朗了吧。不過,其實我還少說了一部分,這些內容的值是什麼呢? 我們看個創建連接的真實例子(訪問百度的抓包)吧!
能夠清楚地看到,通過三次tcp握手後,通道創建成功,而後發送了http請求,也側向驗證了傳輸層服務應用層。
還能夠看到每次發送tcp的時候,seq ack這類值都會發生變化,這個是關鍵,上面說了他們的定義,可是沒說爲啥要用這些。
這是由於咱們要確認鏈接雙方的肯定性,進而創建可靠鏈接。
客戶端發送請求鏈接百度,而後發送帶有SYN標誌的tcp到服務端,告訴服務端,我想和你鏈接。
服務端若是沒收到,那就算了,若是收到了,就會返回表示接收到了的ACK信號,併發送服務端的SYN與客戶端創建鏈接,這是雙向的、可靠地。
若是服務端發送過客戶端沒收到呢?服務端會定時從新發送,知道成功或超過最大限制未知。簡化版心跳機制吧。
客戶端收到了服務端發的SYN和ACK,會再次發送表明接收到了的ACK信號,告訴服務端,我ok了
上圖中後兩次ACK的值爲1就表明是響應成功1次。
其實更通俗的來說,就是下一次的tcp通訊要能證實上一次的tcp通訊是成功的。 就好比說ack,我第一次請求鏈接的時候,初始ack確定爲0,而後你發給個人爲1,就證實了我第一次請求是成功的,反之亦然,能夠本身思考一下,有問題歡迎交流。
到這裏可能有人會問,爲啥必定是三次呢?由於下一次的tcp通訊要能證實上一次的tcp通訊是成功的啊。否則你試試兩次,看看能不能證實。這是的三次是最小次數,保證效率,三次通訊以上理論上都是能夠的,可是不必。
四次揮手其實和上面差很少,不過SYN變成了FIN,用來'觸發'斷開鏈接操做。操做實際上是同樣的。
那爲啥不能和建立鏈接同樣,三次不就行了嘛,還效率。
舉個可能不算恰當的例子:建立鏈接是往一個空的容器里加東西,加就完了,反正剛開始是空的。而斷開鏈接在不加東西以後,還須要將容器裏的東西清理掉,善始善終。
一圖以蔽之:
還不明白,私聊我,我懟懟你!!!
好了,傳輸層任務完成,應用層啓動~
能說的不少,可是感受又沒啥好說的,隨便說說吧就。
首先咱們知道https就是http,不過加了一層安全控制: SSL/TLS。
咱們知道http是明文傳輸的,也沒法校驗內容的完整性。而且因爲是無狀態連接,因此也不知道這東西是誰發的,會不會被人改過。
那https的s到底作了啥?
加密!
就是咱們門禁,對,就賓館的那種。咱們能夠將要發送的內容保護起來,放到賓館裏,而後經過門禁(密鑰)來訪問內容。看起來很安全哈。可是若是這個門禁被人偷偷拿走複製了一份,那咱們的內容就能夠被其餘人隨意訪問了。這是不靠譜的,咱們沒隱私了,赤裸裸~
咱們換個方案吧,咱們讓賓館提供兩張門禁卡,一個公開的,全部人均可以知道,一個是私有的,只有負責人才知道,而後賓館的房間改成兩道門,外面的門能夠用公開的門禁打開(公鑰加密),裏面的門能夠用私鑰打開(私鑰解密),而且裏面的門有一個通道,可讓有公鑰的人將內容放到房間內。因爲裏面的門只能用私鑰打開,因此只有負責人可以查看這個內容。
這就是非對稱加密,使用兩個密鑰,一個是公開的 - 公鑰,一個是私密的 - 密鑰。而後咱們把公鑰散播出去就能夠了。
可是非對稱加密的速度比對稱加密要慢不少,這也不是咱們想要的。而且單純的非對稱加密,只能保證用公鑰加密私密信息只能被擁有私鑰的負責人查看。
ps: 筆者還有個問題想不明白,若是公鑰隨意分發,那有圖謀不軌的人隨意進行通訊,雖然沒問題,能夠經過服務端進行控制。可是這樣感受怪怪的~
對稱加密和非對稱加密混這用,對稱加密用於內容,非對稱加密用於對稱加密密鑰的傳輸。
這樣咱們就只用到了一次非對稱加密,而後就能夠用對稱加密進行內容的解析。大大提高的速度。
可是這其中有個很嚴重的問題。若是在服務器發送對稱加密密鑰的時候,被某個壞人截取到了,這樣不但獲取到了服務器的公鑰,還能夠給瀏覽器發送他的公鑰,至關於中間人的角色。瀏覽器和服務器在不知情的狀況下進行危險的通訊活動。
這就要利用非對稱加密的另外一個功能,數字證書。由於私鑰是惟一,因此咱們能夠用私鑰進行加密(簽名),這樣只有正確的公鑰才能開鎖。保證了內容是安全的。
而且須要瀏覽器內置一些安全的公鑰,用於解析這個證書,這就是證書中心(CA)的做用了。證書中心是一個絕對有保障的組織,他們會和操做系統、瀏覽器廠商協定,將證書中心(CA)的公鑰提早種好。
上面是前提,接下來,服務器會提早找證書中心爲公鑰作認證,而後返回服務器數字證書。證書的內容是經過證書中心私鑰加密過得服務器相關信息和服務器公鑰,這樣就保證了公鑰沒法被篡改,保障了安全。
以後瀏覽器在請求的時候,就會獲取到正確的公鑰。以後服務器返回內容的時候也會進行一步處理,保障內容不會被篡改。
瀏覽器會返回兩部分,一部分是明文的hash算法結果。一部分是用服務器私鑰加密過得明文的hash算法結果,而後瀏覽器在獲取後,會經過hash和服務器公鑰進行解密,獲得的兩部分若是相等,那麼此次傳輸的內容就沒問題。能夠愉快地進行通訊啦~
看明白了是否是會問爲啥要進行hash在加密啊,直接加密不就行了嗎?答案很簡單啊,由於效率。
本文內容是理解後通過處理展現出來的,不理解的也不會亂寫,若是仍有問題歡迎指出,我會及時回覆的。
瞭解這幾點,對於http基礎會有一個總體的理解,無論是工做中仍是求職中都能說出個一二三來,或許還應該寫一點常見問題,可是微乎其微,等用到了天然而然就知道了。
立刻清明節了吧,祝你們清明節快樂!!哈哈哈哈~
部分圖片來源自網絡,侵刪