目前造車熱的車聯(lián)網(wǎng),區(qū)塊鏈,物聯(lián)網(wǎng),其實他們所追求的核心都是想達到萬物互聯(lián).但是每個測重點可能不太一樣.車聯(lián)網(wǎng)以車切入萬物互聯(lián).區(qū)塊鏈可能更多的關(guān)注溯源可信,真正讓萬物互聯(lián)的可能就是各個賬本.物聯(lián)網(wǎng)更不用說了,智能家居典型代表.其實他們最最核心的東西就是我們今天要講的網(wǎng)絡(luò).萬物互聯(lián)靠什么互聯(lián),最基本的設(shè)施就是網(wǎng)絡(luò).

什么是網(wǎng)絡(luò)呢,有人能解釋下嗎

網(wǎng)絡(luò)是由若干節(jié)點和連接這些節(jié)點的鏈路構(gòu)成，表示諸多對象及其相互聯(lián)系。(百度的)

網(wǎng)絡(luò)有四要素

1蛛壳、通信線路和通信設(shè)備廊移；

2、有獨立功能的計算機；

3、網(wǎng)絡(luò)軟件支持；

4僻弹、實現(xiàn)數(shù)據(jù)通信與資源共享。

結(jié)合目前我們的職業(yè)和后期可能面臨研究的方向,著重講下第四條,實現(xiàn)數(shù)據(jù)通信與網(wǎng)絡(luò)資源共享

至于其他的交給運營商,運維等等他們?nèi)ッΠ?/p>

設(shè)備之間通信其實就和人一樣,我找你溝通凡爾賽,肯定得先找到你本人,然后用都能聽的懂的語言來聊.古時候?qū)ε椙倬褪且粋€很失敗的通信方案.

找你本人,其實就是目前計算機網(wǎng)絡(luò)里的MAC地址和IP地址,ip好理解,mac地址其實可以理解為接入以太網(wǎng)網(wǎng)卡地址,以太網(wǎng)要求接入必須要有網(wǎng)卡接口,從一個網(wǎng)卡發(fā)送另外一個網(wǎng)卡的數(shù)據(jù)包接收和發(fā)送地址.計算機與網(wǎng)絡(luò)設(shè)備要相互通信他嚷，雙方就必須基于相同的方法蹋绽。比如，如何探測到通信目標筋蓖、由哪一邊先發(fā)起通信卸耘、使用哪種語言進行通信、怎樣結(jié)束通信等規(guī)則都需要事先確定粘咖。不同的硬件蚣抗、操作系統(tǒng)之間的通信，所有的這一切都需要一種規(guī)則瓮下。而我們就把這種規(guī)則稱為協(xié)議（protocol）.常見的TCP翰铡、UDP.當然還有其他協(xié)議,甚至你可以自定義協(xié)議.比如我看到網(wǎng)上有移動端做APM可以分性能監(jiān)控和數(shù)據(jù)上報2個模塊,其中上報組件為了方便可擴展,并具有動態(tài)下發(fā)上報策略,同時還要高效就使用了自定義報文協(xié)議.

TCP、UDP 協(xié)議呢,也能講很久,時間有限,這里我們著重講和我們相關(guān)的TCP協(xié)議

TCP/IP 是協(xié)議簇讽坏，比如：TCP锭魔、UDP、IP路呜、FTP迷捧、HTTP织咧、ICMP、SMTP 等都屬于 TCP/IP 簇內(nèi)的協(xié)議漠秋。TCP/IP協(xié)議可以劃分為四層

鏈路層：負責(zé)封裝和解封裝 IP 報文烦感，發(fā)送和接受 ARP/RARP 報文等。

網(wǎng)絡(luò)層：負責(zé)路由以及把分組報文發(fā)送給目標網(wǎng)絡(luò)或主機膛堤。

傳輸層：負責(zé)對報文進行分組和重組，并以 TCP 或 UDP 協(xié)議格式封裝報文晌该。

應(yīng)用層：負責(zé)向用戶提供應(yīng)用程序肥荔，比如HTTP、FTP朝群、Telnet燕耿、DNS、SMTP等姜胖。

正常一條網(wǎng)絡(luò)請求需要經(jīng)過的流程是：

1.DNS 解析誉帅。請求 DNS 服務(wù)器，獲取域名對應(yīng)的 IP 地址

2.與服務(wù)器建立連接右莱。包括 TCP 三次握手蚜锨，安全協(xié)議同步流程

3.連接建立完成，發(fā)送慢蜓、接收數(shù)據(jù)亚再，解碼數(shù)據(jù)

先說說DNS解析,為啥要DNS解析,因為設(shè)備太多,ip太難記,發(fā)明了DNS,DNS是一個和ip相互映射的分布式數(shù)據(jù)庫.

以瀏覽器舉例,一般會瀏覽器本身找DNS,沒有操作系統(tǒng)找DNS,沒有會找本地DNS服務(wù)器,一般在城市某個地方,如果還沒有就是13臺根DNS服務(wù)器找.根DNS服務(wù)器會返回所查詢域的主域名服務(wù)器的地址(.net)，本地DNS服務(wù)器使用該IP信息聯(lián)系負責(zé).net域的這臺服務(wù)器晨抡。這臺負責(zé).net域的服務(wù)器收到請求后氛悬，會返回.net域的下一級DNS服務(wù)器地址(blog.csdn.net)給本地DNS服務(wù)器。以此類推耘柱，直至找到.每一層都有緩存如捅，但為了域名解析的實時性。每一層緩存都設(shè)有過期時間.

那么問題來了這么復(fù)雜的流程,加上緩存,就會帶來一些問題.比如:

緩存時間設(shè)置過長调煎，域名更新不及時镜遣。設(shè)置時間短，大量 DNS 解析請求影響請求毒素

域名劫持汛蝙。容易被中間人攻擊烈涮，或者運營商劫持。把域名解析道第三方 IP 地址窖剑，據(jù)統(tǒng)計劫持率高達 7%

DNS 解析過程不受控制坚洽，無法保證最快的解析速度

一次請求只可以借此一個域名

那么我們的研究任務(wù)來了

如何防DNS劫持或者加快速度

為了解決上述問題，就有了 HTTPDNS西土。原理就是代替系統(tǒng)的 DNS 解析工作讶舰，解決上述問題。

域名解析與請求分離，所有請求都直接使用 IP 地址跳昼，無需 DNS 解析般甲，App 定時請求 HTTPDNS 服務(wù)器更新 IP 地址即可

通過簽名等方式，保證 HTTPDNS 請求的安全鹅颊，避免被劫持

DNS 解析由自己控制敷存。可以保證根據(jù)用戶所在地返回就近的 IP 地址堪伍∶常或根據(jù)客戶端測速結(jié)果使用最快的 IP

一次請求可以解析多個域名

對于 DNS 解析的情況，業(yè)界主流做法就是 HTTPDNS 或者內(nèi)置 Server IP 列表帝雇′潭恚客戶端直接訪問 HTTPDNS 接口，獲取業(yè)務(wù)在域名配置系統(tǒng)上配置的訪問延遲最優(yōu)的 IP尸闸，獲取到 IP 后就直接往此 IP 發(fā)送業(yè)務(wù)協(xié)議請求彻亲，不再需要本地 DNS 服務(wù)器進行解析，從根本上解決了劫持問題吮廉。同時可以降低網(wǎng)絡(luò)延遲苞尝，提高連接的成功率。

建立的 Server IP 列表茧痕，是在本地緩存一個 IP 映射表野来，可以在 App 啟動時請求接口下發(fā)更新。訪問其他的服務(wù)的時候根據(jù)映射拿到 IP 再發(fā)出請求踪旷。

絕大多數(shù)的 App 的第一步都是 DNS 解析曼氛，解析請求回根據(jù)當時的網(wǎng)絡(luò)情況不同而不同，各平臺的 DNS 緩存策略存在差異令野，因此對于移動 App 網(wǎng)絡(luò)性能會產(chǎn)生影響舀患。App 網(wǎng)絡(luò)情況跟很多因素都相關(guān)。但是 DNS 是第一步也是最重要的一環(huán)气破。

1.降低 DNS 請求帶來的延遲 客戶端 App 請求第一步是 DNS 解析聊浅。但是由于 Cache 的存在，使得大部分的解析請求都不會產(chǎn)生任何延遲现使。各平臺都有自己的 Cache 過期策略低匙。像 iOS 系統(tǒng)一般都是 24h 后過期。還有就是從飛行模式切換回來碳锈、開關(guān)機顽冶、重置網(wǎng)絡(luò)設(shè)置等都會導(dǎo)致 DNS Cache 的清除。所以一般情況用戶在第二天打開你的 App 都會經(jīng)歷一次完整的 DNS 解析請求售碳。網(wǎng)絡(luò)情況差的時候會明顯的請求總耗時增加强重。如果可以直接跳過 DNS 解析這一步绞呈，就可以提高網(wǎng)絡(luò)性能了。

2.預(yù)防 NDS 劫持 DNS 劫持指的是改變 DNS請求返回的結(jié)果间景，將目的域名對應(yīng)的 IP 指向另一個地址佃声。一般有兩種方式，一種是通過病毒的方式改變本機配置的 DNS 服務(wù)器地址倘要，二是通過攻擊正常的 DNS 服務(wù)器而改變其行為圾亏。不管何種方式都會影響 App 的業(yè)務(wù)請求，如果遇到惡意的攻擊還會衍生出各種安全問題封拧≌偎唬客戶端自己做 DNS 到 IP 地址的映射就繞過了向 DNS 服務(wù)器請求而可能被遭到攻擊的可能，讓劫持者無從下手

3.服務(wù)器動態(tài)部署 DNS 映射實際上是模擬了 DNS 請求的解析行為哮缺。如果客戶端將自己的位置信息（例如ip地址、國家碼等）上傳給服務(wù)器甲喝，服務(wù)器就可以根據(jù)位置信息就近推薦合適的 Server IP 地址尝苇。從而減小了整體網(wǎng)絡(luò)請求延遲、實現(xiàn)了動態(tài)部署

如何設(shè)計自己的 DNS 映射機制埠胖？這個可以研究,時間有限先不講了.

三次握手問題,同樣帶來請求時間加長

不要每次請求都重新建立連接糠溜，復(fù)用連接或一直使用同一條連接（長連接）

對于我們來說主要研究的應(yīng)該是復(fù)用連接,長鏈接一般除了客服什么都暫時用不到

HTTP 協(xié)議里有個?keep-alive，HTTP1.1 默認開啟直撤，一定程度上緩解了每次請求都需要進行 TCP 三次握手建立連接的耗時非竿。原理是請求完成后不立即釋放連接，而是放入連接池中谋竖。若此時有另一個請求要發(fā)出红柱，如果請求的端口和域名在復(fù)用池里面有一致的，那么就直接拿出連接池中的連接進行發(fā)送和接收數(shù)據(jù)蓖乘，少了建立連接的耗時锤悄。

實際上，現(xiàn)在無論是客戶端還是瀏覽器都默認開啟了 keep-alive嘉抒，對同個域名不會再有每發(fā)一個請求就進行一次建連的情況零聚，純短連接已經(jīng)不存在了。但是有問題些侍，就是這個 keep-alive 的短連接一次只能發(fā)送接收一個請求隶症，在上一個請求處理完成之前。無法接受新的請求岗宣。若同時發(fā)起多個請求蚂会，就有兩種情況：

若串行發(fā)送請求，可以一直復(fù)用一個連接狈定，但速度很慢颂龙，每個請求都需要等待上個請求完成再進行發(fā)送

若并行發(fā)送請求习蓬，那么首次每個請求都要進行 TCP 三次握手建立新的連接，雖然第二次可以復(fù)用連接池里面的這堆連接措嵌，但若連接池里面保留的過多躲叼，對服務(wù)端資源產(chǎn)生交大浪費，若限制了保持的連接數(shù)企巢，并行請求超出的連接仍每次需要建立連接枫慷。對于這個問題新一代的 HTTP2.0 提出了多路復(fù)用解決方案。

HTTP2 的多路復(fù)用機制一樣是復(fù)用連接浪规。但它復(fù)用的這條連接支持同時處理多條請求或听，所有請求都可以在這條連接上進行，也就是解決了上面說的并發(fā)請求需要建立多條連接帶來的問題笋婿。

HTTP2 這里的多路復(fù)用協(xié)議解決了這些問題誉裆，它把在連接里傳輸?shù)臄?shù)據(jù)都封裝成一個個 stream，每個 stream 都有標識缸濒，stream 的發(fā)送和接收可以是亂序的足丢，不依賴順序，也就不會有阻塞的問題庇配，接收端可以根據(jù) stream 的標識去區(qū)分屬于哪個請求斩跌，再進行數(shù)據(jù)拼接，得到最終數(shù)據(jù)捞慌。

解釋下多路復(fù)用這個詞耀鸦，多路可以認為是多個連接，多個操作啸澡，復(fù)用就是 復(fù)用一條連接或一個線程袖订。HTTP2 這里是連接的多路復(fù)用，網(wǎng)絡(luò)相關(guān)的還有一個 I/O 的多路復(fù)用(select/epoll)嗅虏，指通過事件驅(qū)動的方式讓多個網(wǎng)絡(luò)請求返回的數(shù)據(jù)在同一條線程里完成讀寫著角。

客戶端來說，iOS9 以上 NSURLSession 原生支持 HTTP2旋恼，只要服務(wù)端也支持就可以直接使用吏口，Android 的 okhttp3 以上也支持了 HTTP2，國內(nèi)一些大型 APP 會自建網(wǎng)絡(luò)層冰更，支持 HTTP2 的多路復(fù)用产徊，避免系統(tǒng)的限制以及根據(jù)自身業(yè)務(wù)需要增加一些特性，例如微信的開源網(wǎng)絡(luò)庫?mars蜀细，做到一條長連接處理微信上的大部分請求舟铜，多路復(fù)用的特性上基本跟 HTTP2 一致。

HTTP2 的多路復(fù)用看起來是完美的解決方案奠衔，但還有個問題谆刨，就是隊頭阻塞塘娶，這是受限于 TCP 協(xié)議，TCP 協(xié)議為了保證數(shù)據(jù)的可靠性痊夭，若傳輸過程中一個 TCP 包丟失刁岸，會等待這個包重傳后，才會處理后續(xù)的包她我。HTTP2的多路復(fù)用讓所有請求都在同一條連接進行虹曙，中間有一個包丟失，就會阻塞等待重傳番舆，所有請求也就被阻塞了酝碳。

對于這個問題不改變 TCP 協(xié)議就無法優(yōu)化，但 TCP 協(xié)議依賴操作系統(tǒng)實現(xiàn)以及部分硬件的定制恨狈，改進緩慢疏哗，于是 GOOGLE 提出 QUIC 協(xié)議，相當于在 UDP 協(xié)議之上再定義一套可靠傳輸協(xié)議禾怠，解決 TCP 的一些缺陷沃斤，包括隊頭阻塞。具體解決原理網(wǎng)上資料較多刃宵，可以看看。

QUIC 處于起步階段徘公，少有客戶端接入牲证，QUIC 協(xié)議相對于 HTTP2 最大的優(yōu)勢是對TCP隊頭阻塞的解決，其他的像安全握手 0RTT / 證書壓縮等優(yōu)化 TLS1.3 已跟進关面，可以用于 HTTP2坦袍，并不是獨有特性。TCP 隊頭阻塞在 HTTP2 上對性能的影響有多大等太，在速度上 QUIC 能帶來多大提升待研究捂齐。

第三步連接完成數(shù)據(jù)傳輸過程

這個過程要講內(nèi)容就比較多了.先講講最主要的點,網(wǎng)絡(luò)速度.

為了提升用戶體驗,我們最好可以壓縮數(shù)據(jù)，減小傳輸數(shù)據(jù)的大小

傳輸數(shù)據(jù)大小問題缩抡。數(shù)據(jù)對請求速度的影響分兩方面奠宜，一是壓縮率，二是解壓序列化反序列化的速度瞻想。目前最流行的兩種數(shù)據(jù)格式是 json 和 protobuf(Google ?提供)压真。json 是字符串，protobuf 是二進制蘑险。即使采用各種壓縮算法壓縮后滴肿，protobuf 仍會比 json 小。protobuf 在數(shù)據(jù)量和序列化速度上均占優(yōu)勢佃迄。IOS里的KVStorage,集成微信的MMKV采用的就是這種存儲方式.大家可以底下研究下.

除了傳輸數(shù)據(jù)的 body 大小泼差，每個 HTTP 協(xié)議頭的數(shù)據(jù)也不可忽視贵少，HTTP2 里對 HTTP 協(xié)議頭也進行了壓縮，HTTP 頭大多是重復(fù)數(shù)據(jù)堆缘，固定的字段如 method 可以用靜態(tài)字典滔灶，不固定但多個請求重復(fù)的字段例如 cookie 用動態(tài)字典，可以打到非常高的壓縮率.

說到速度就要說到一個安全了.因為為了安全可能會犧牲一部分速度了.

標準安全協(xié)議?TLS?保證了網(wǎng)絡(luò)傳輸?shù)陌踩灼。吧硎?SSL宽气，不斷在演進。我們?nèi)粘Ｊ褂玫?HTTPS 就是 HTTP 協(xié)議加上 TLS 安全協(xié)議潜沦。大家底下可以了解下TLS 安全協(xié)議的設(shè)計理念.

這里我們主要講講在這個之外的我們約定的前后端數(shù)據(jù)加解密的.

以前我們用的基本都是RSA的前后端加密,國外設(shè)計的,然后有些漏洞我們也不一定知道,所以國內(nèi)推出了國密SM2,SM3,SM4,SM9,ZUC.具體算法原理就不多講了,這個要講很久.

我就講講我們項目為什么用了SM2WithSM3簽名這種數(shù)據(jù)傳輸模式.

其實提升網(wǎng)絡(luò)傳輸速度,我們其實還需要研究一個東西,那就是保證安全的情況下,降低加密成本,因為加密本身就對前后端都有一定的時間損耗.那么我們?yōu)樯哆€要用SM2WithSM3加簽驗簽這種復(fù)雜的方式呢.

我先講講他為啥復(fù)雜了,首先我們都知道加解密對吧,但是這個SM2WithSM3,是先對摘要信封進行SM2加密信封,然后用信封對明文SM4加密.將版本號時間戳隨機數(shù)sm4加密后的密文再進行SM2簽名,其中sm2簽名涉及到sm3雜湊算法值.具體不多講因為支付好像他們分享過.

為啥不直接sm4加密下,對稱加密不安全,為啥不sm2加密下,要這么多.首先我們要明白一個東西.加解密和簽名的分別作用是什么.

加解密是數(shù)據(jù)的安全性萄涯，簽名是防篡改。

如果不在意數(shù)據(jù)丟失泄漏但是防篡改可以用簽名驗證唆鸡。

如果在意數(shù)據(jù)安全涝影，也防篡改，就兩者都用争占。

不知道大家還注意里面一個東西沒.你既然都加密了,簽名了,為啥里面還搞時間戳,隨機數(shù)啥的干嘛.我們都知道數(shù)據(jù)安全了,并且防篡改了.理論上確實沒問題.但是漏了一種問題,防重放攻擊,別人不篡改,不獲取數(shù)據(jù),就用重放攻擊你.

時間戳是一種防重放攻擊,但是也有漏洞比如業(yè)界一直認定的60秒,合法,60秒內(nèi)就會鉆漏洞,所以有了隨機數(shù)加持.

講完這個,還想給大家講講抓包

截獲真實客戶端的HTTPS請求燃逻，偽裝客戶端向真實服務(wù)端發(fā)送HTTPS請求

接受真實服務(wù)器響應(yīng)，用Charles自己的證書偽裝服務(wù)端向真實客戶端發(fā)送數(shù)據(jù)內(nèi)容

客戶端收到服務(wù)器回應(yīng)以后臂痕，首先驗證服務(wù)器返回的證書伯襟。如果證書不是可信機構(gòu)頒發(fā)，或者證書中的域名與實際域名不一致握童，或者證書已經(jīng)過期姆怪，以瀏覽器為例客戶端會向網(wǎng)頁訪問者顯示一個警告，由其選擇是否還要繼續(xù)通信澡绩。 如果證書沒有問題稽揭，客戶端就會從證書中取出服務(wù)器的公鑰。然后生成密碼肥卡、公鑰加密溪掀。 生成密碼的過程會先產(chǎn)生一個隨機數(shù)Pre-master key，該隨機數(shù)是整個握手階段出現(xiàn)的第三個隨機數(shù)步鉴，稍后會經(jīng)過公鑰加密發(fā)送到服務(wù)端揪胃，有了它以后，客戶端和服務(wù)器就同時有了三個隨機數(shù)——RandomC氛琢，RandomS只嚣，Pre-master key，接著雙方就用事先商定的加密方法艺沼，各自生成本次會話所用的同一把“協(xié)商密鑰”册舞。