大家好，我是標題黨，啊不，我是小雨小雨，致力于分享有趣的、實用的技術文章。
內(nèi)容分為翻譯和原創(chuàng)，如果有問題，歡迎隨時評論或私信，希望和大家一起進步。
分享不易，希望能夠得到大家的支持和關注。
什么是互聯(lián)網(wǎng)
互聯(lián)網(wǎng)是指 凡是 能彼此通信的設備組成的網(wǎng)絡就叫互聯(lián)網(wǎng)，指利用TCP/IP通訊協(xié)定所創(chuàng)建的各種網(wǎng)絡，是國際上最大的互聯(lián)網(wǎng)，也稱“國際互聯(lián)網(wǎng)”。
其中TCP/IP是網(wǎng)絡的基礎通信架構，提供了點對點鏈接的機制。并且將軟件通信過程抽象化為四個抽象層，下層服務上層，也就是我們熟悉的七層OSI模型。(也就是說TPC/IP是聯(lián)網(wǎng)的基礎，由他衍生出了OSI)
OSI模型是一個視圖使各種計算機在世界范圍能互連接為網(wǎng)絡的標準框架，也就是說是網(wǎng)絡互接的標準。(大白話就是規(guī)則。按照這個規(guī)則，我們就能聯(lián)網(wǎng))
用一張圖表示OSI模型:
如果討論TCP/IP的時候，我們又可以分為四層，如下圖:
看看就好，我們要關注的是應用層的http和傳輸層的tcp，對了，兩個模型的對應關系如下：
由于TCP、UDP位于傳輸層，HTTP位于應用層，按照下層服務于上層的機制，我們從TCP、UDP開始說起。
UDP是什么
UDP位于OSI模型的傳輸層，是一種無連接的協(xié)議，該標準定義的內(nèi)容很專一，就是數(shù)據(jù)無腦發(fā)數(shù)據(jù)，不管天崩地裂，?？菔癄€，發(fā)就完了。為啥這個莽夫是不可靠的呢？
- 無連接：就比如小雨去上班，不管他周內(nèi)還是周末，上就完了，自然而然就會有一些問題發(fā)生
- 恒速：這個莽夫沒有擁塞控制系統(tǒng)，也就是不會變通，一根筋按照一個頻率進行發(fā)收運動，就算對方受不了了，UDP也不會改變它的頻率。
- 簡單：這貨頭部開銷小，只有八字節(jié)，比tcp要少三倍左右，所以就很快。
不過，正由于UDP的快，也有一些場景是非他莫屬的，比如DNS啊、音視頻啊、實時游戲啊、聊天工具啊巴拉巴拉...
可能有人會問，DNS這種使用UDP會不會有問題啊，比如UDP丟包了，那豈不是返回404了啊。
沒錯，但是瀏覽器響應時間大致分為以下三個：
DNS解析 + TCP鏈接 + HTTP請求/響應
除了DNS能用UDP，其他二位也沒法用啊，不然網(wǎng)站丟內(nèi)容了啊。而且還有備選方案，某種情況下失敗了會利用TCP重新查詢的，不只是有UDP一種。
可能還有人會問，那聊天工具這種用UDP這問題大了啊，我要是跟我女神表白，這莽夫只管發(fā)，結果各種丟包(發(fā)送失敗)，而且我還不知道，那我心態(tài)崩了啊。我以為她知道，結果她不知道，然后她還不回我，你讓我咋想...
只能說，為啥不能給女神留下神秘感，讓她來主動找你呢，哈哈哈
其實通訊工具一般會發(fā)送兩次，UDP發(fā)送一個消息后，如果服務器收到了，會用UDP在返你一個消息，如果沒返回，或者發(fā)送失敗，你就會收到發(fā)送失敗類似的消息啦，去表白吧，沒事的，消息肯定發(fā)的出去，答不答應就看自己了。
總的來說，在某些對速度要求極高，但是準確性要求低的情況，UDP是很適合的。
TCP是什么
UDP莽夫不靠譜，TCP小伙來彌補。
關于TCP，我覺得可以用擬人化來代表，眾所周知TCP是全雙工的嗎，其實就是兩個獨立的人在進行微信聊天。光一個人發(fā)是不行的，另一個人也得發(fā)，不然聊個j。
那TCP怎么就靠譜了呢？
沒錯，小伙看日歷了?。?！而且更厲害的是，他休假的時候也會看日歷！??！
其實就是TCP在發(fā)送數(shù)據(jù)的前后，會進行連接創(chuàng)建和連接終止的操作。保證事務完整性。這就是我們經(jīng)常被問到的問題：三次握手和四次揮手。
三次握手創(chuàng)建連接
提前聲明，關于每個標志的格式和內(nèi)容是什么，這里不做討論，有興趣的自行研究。這些定義用到的時候再查就好。
在此之前，要先解釋幾個名詞(又是名詞，大白話不好嗎 doge~)
- SYN: 表示建立連接，如果我給你的消息里有這個標志，說明我想和你負距離接觸，當然這是雙向的，你也可以給我發(fā)。
- FIN: 表示關閉連接，同上，不過表示我好了，請你離開
- SEQ: 表示初始包序號，隨時間變化。就是說我希望你從從這數(shù)字開始計數(shù)，其實就是確保雙方都是本人，不能隨便帶個序號來都能進行工作，那就亂了
- ACK: 表示響應，就是說我成功得到了你給我的內(nèi)容
- PSH: 表示有DATA數(shù)據(jù)傳輸
- RST: 表示連接重置。
好，進入正題，先看張圖吧
看完圖可能就豁然開朗了吧。不過，其實我還少說了一部分，這些內(nèi)容的值是什么呢？ 咱們看個建立鏈接的真實例子(訪問百度的抓包)吧！
可以清楚地看到，經(jīng)過三次tcp握手后，通道建立成功，然后發(fā)送了http請求，也側向驗證了傳輸層服務應用層。
還可以看到每次發(fā)送tcp的時候，seq ack這類值都會發(fā)生變化，這個是關鍵，上面說了他們的定義，但是沒說為啥要用這些。
這是因為我們要確認連接雙方的確定性，進而建立可靠連接。
客戶端發(fā)送請求連接百度，然后發(fā)送帶有SYN標志的tcp到服務端，告訴服務端，我想和你連接。
服務端如果沒收到，那就算了，如果收到了，就會返回表示接收到了的ACK信號，并發(fā)送服務端的SYN與客戶端建立連接，這是雙向的、可靠地。
如果服務端發(fā)送過客戶端沒收到呢？服務端會定時重新發(fā)送，知道成功或超過最大限制未知。簡化版心跳機制吧。
客戶端收到了服務端發(fā)的SYN和ACK，會再次發(fā)送代表接收到了的ACK信號，告訴服務端，我ok了
上圖中后兩次ACK的值為1就代表是響應成功1次。
其實更通俗的來講，就是下一次的tcp通信要能證明上一次的tcp通信是成功的。
就比如說ack，我第一次請求連接的時候，初始ack肯定為0，然后你發(fā)給我的為1，就證明了我第一次請求是成功的，反之亦然，可以自己思考一下，有問題歡迎交流。
到這里可能有人會問，為啥一定是三次呢？因為下一次的tcp通信要能證明上一次的tcp通信是成功的啊。不然你試試兩次，看看能不能證明。這是的三次是最小次數(shù)，保證效率，三次通信以上理論上都是可以的，但是沒必要。
四次揮手斷開連接
四次揮手其實和上面差不多，不過SYN變成了FIN，用來'觸發(fā)'斷開連接操作。操作其實是一樣的。
那為啥不能和創(chuàng)建連接一樣，三次不就好了嘛，還效率。
舉個可能不算恰當?shù)睦樱簞?chuàng)建連接是往一個空的容器里加東西，加就完了，反正剛開始是空的。而斷開連接在不加東西之后，還需要將容器里的東西清理掉，有始有終。
一圖以蔽之：
還不明白，私聊我，我懟懟你?。?！
好了，傳輸層任務完成，應用層啟動~
HTTP和HTTPS
能說的很多，但是感覺又沒啥好說的，隨便說說吧就。
首先我們知道https就是http，不過加了一層安全控制： SSL/TLS。
怎么就安全了捏？
我們知道http是明文傳輸?shù)?，也無法校驗內(nèi)容的完整性。并且由于是無狀態(tài)鏈接，所以也不知道這東西是誰發(fā)的，會不會被人改過。
那https的s到底做了啥？
加密！
對稱加密
就是我們門禁，對，就賓館的那種。我們可以將要發(fā)送的內(nèi)容保護起來，放到賓館里，然后通過門禁(密鑰)來訪問內(nèi)容?？雌饋砗馨踩５侨绻@個門禁被人偷偷拿走復制了一份，那我們的內(nèi)容就可以被其他人隨意訪問了。這是不靠譜的，我們沒隱私了，赤裸裸~
非對稱加密
我們換個方案吧，我們讓賓館提供兩張門禁卡，一個公開的，所有人都可以知道，一個是私有的，只有負責人才知道，然后賓館的房間改為兩道門，外面的門可以用公開的門禁打開(公鑰加密)，里面的門可以用私鑰打開(私鑰解密)，并且里面的門有一個通道，可以讓有公鑰的人將內(nèi)容放到房間內(nèi)。由于里面的門只能用私鑰打開，所以只有負責人能夠查看這個內(nèi)容。
這就是非對稱加密，使用兩個密鑰，一個是公開的 - 公鑰，一個是私密的 - 密鑰。然后我們把公鑰散播出去就可以了。
但是非對稱加密的速度比對稱加密要慢很多，這也不是我們想要的。并且單純的非對稱加密，只能保證用公鑰加密私密信息只能被擁有私鑰的負責人查看。
ps: 筆者還有個問題想不明白，如果公鑰隨意分發(fā)，那有圖謀不軌的人隨意進行通信，雖然沒問題，可以通過服務端進行控制。但是這樣感覺怪怪的~
怎么能讓它快起來呢？
對稱加密和非對稱加密混這用，對稱加密用于內(nèi)容，非對稱加密用于對稱加密密鑰的傳輸。
這樣我們就只用到了一次非對稱加密，然后就可以用對稱加密進行內(nèi)容的解析。大大提升的速度。
但是這其中有個很嚴重的問題。如果在服務器發(fā)送對稱加密密鑰的時候，被某個壞人截取到了，這樣不但獲取到了服務器的公鑰，還可以給瀏覽器發(fā)送他的公鑰，相當于中間人的角色。瀏覽器和服務器在不知情的情況下進行危險的通信活動。
怎么證明公鑰的正確性
這就要利用非對稱加密的另一個功能，數(shù)字證書。因為私鑰是唯一，所以我們可以用私鑰進行加密(簽名)，這樣只有正確的公鑰才能開鎖。保證了內(nèi)容是安全的。
并且需要瀏覽器內(nèi)置一些安全的公鑰，用于解析這個證書，這就是證書中心(CA)的作用了。證書中心是一個絕對有保障的組織，他們會和操作系統(tǒng)、瀏覽器廠商協(xié)定，將證書中心(CA)的公鑰提前種好。
上面是前提，接下來，服務器會提前找證書中心為公鑰做認證，然后返回服務器數(shù)字證書。證書的內(nèi)容是通過證書中心私鑰加密過得服務器相關信息和服務器公鑰，這樣就保證了公鑰無法被篡改，保障了安全。
之后瀏覽器在請求的時候，就會獲取到正確的公鑰。之后服務器返回內(nèi)容的時候也會進行一步處理，保障內(nèi)容不會被篡改。
瀏覽器會返回兩部分，一部分是明文的hash算法結果。一部分是用服務器私鑰加密過得明文的hash算法結果，然后瀏覽器在獲取后，會通過hash和服務器公鑰進行解密，得到的兩部分如果相等，那么這次傳輸?shù)膬?nèi)容就沒問題?？梢杂淇斓剡M行通信啦~
看明白了是不是會問為啥要進行hash在加密啊，直接加密不就好了嗎？答案很簡單啊，因為效率。
優(yōu)化
- tcp三次握手可以利用'會話緩存'來節(jié)省一次握手時間，其實就是緩存，和咱們平常寫代碼沒差，就是寫法不一樣。我們平常用到的很多技術很多也是一些基本的技術，舉一反三就好。
- 和上面差不多。tcp第二次握手的時候就可以發(fā)數(shù)據(jù)了，可以在這上面做手腳
- 盡量減少rsa算法，實在是慢，這個想辦法緩存或者算法優(yōu)化吧，我也不太懂~
- 證書優(yōu)化，怎么便宜怎么來唄，薅?。?！不過也得看企業(yè)/個人怎么取舍了
- 等~ 不做深入了
總結
本文內(nèi)容是理解后經(jīng)過處理展示出來的，不理解的也不會亂寫，如果仍有問題歡迎指出，我會及時回復的。
了解這幾點，對于http基礎會有一個整體的理解，不管是工作中還是求職中都能說出個一二三來，或許還應該寫一點常見問題，但是微乎其微，等用到了自然而然就知道了。
馬上清明節(jié)了吧，祝大家清明節(jié)快樂！！哈哈哈哈~
部分圖片來源自網(wǎng)絡，侵刪
