1感混、OSI與TCP參考模型
OSI七層模型：物理層端幼、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層弧满、傳輸層婆跑、會話層、表示層庭呜、應(yīng)用層滑进。
TCP/IP 四層：數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層募谎、傳輸層扶关、應(yīng)用層。
1）應(yīng)用層
應(yīng)用層(application-layer）的任務(wù)是通過應(yīng)用進程間的交互來完成特定網(wǎng)絡(luò)應(yīng)用数冬。應(yīng)用層協(xié)議定義的是應(yīng)用進程（進程：主機中正在運行的程序）間的通信和交互的規(guī)則节槐。對于不同的網(wǎng)絡(luò)應(yīng)用需要不同的應(yīng)用層協(xié)議。在互聯(lián)網(wǎng)中應(yīng)用層協(xié)議很多吉执，如域名系統(tǒng)DNS疯淫，支持萬維網(wǎng)應(yīng)用的?HTTP協(xié)議，支持電子郵件的?SMTP協(xié)議等等戳玫。我們把應(yīng)用層交互的數(shù)據(jù)單元稱為報文熙掺。
2）傳輸層
傳輸層(transport layer)的主要任務(wù)就是負(fù)責(zé)向兩臺主機進程之間的通信提供通用的數(shù)據(jù)傳輸服務(wù)。由于一臺主機可同時運行多個線程咕宿，因此運輸層有復(fù)用和分用的功能币绩。所謂復(fù)用就是指多個應(yīng)用層進程可同時使用下面運輸層的服務(wù)蜡秽，分用和復(fù)用相反，是運輸層把收到的信息分別交付上面應(yīng)用層中的相應(yīng)進程缆镣。
運輸層主要的兩種協(xié)議:
傳輸控制協(xié)議 TCP（Transmission Control Protocol）：提供面向連接的芽突，可靠的數(shù)據(jù)傳輸服務(wù)。
用戶數(shù)據(jù)協(xié)議 UDP（User Datagram Protocol）：提供無連接的董瞻，盡最大努力的數(shù)據(jù)傳輸服務(wù)（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/p>
TCP和UDP的區(qū)別：
TCP是面向連接的寞蚌、可靠的、基于字節(jié)流的傳輸層協(xié)議钠糊；UDP是一個面向無連接的傳輸層協(xié)議挟秤，即發(fā)送數(shù)據(jù)前不需要先建立鏈接。
可靠性：TCP是基于連接的抄伍，無差錯艘刚，不丟失，不重復(fù)截珍，且按序到達攀甚，可靠性高（TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接岗喉，而且在數(shù)據(jù)傳遞時秋度，有確認(rèn)、窗口钱床、重傳静陈、擁塞控制機制，在數(shù)據(jù)傳完后诞丽，還會斷開連接用來節(jié)約系統(tǒng)資源）；UDP是基于無連接的拐格，盡最大努力交付僧免，即不保證可靠交付，可靠性較低捏浊；
安全性：由于TCP是連接的通信懂衩，需要有三次握手、重新確認(rèn)等連接過程金踪，會有延時浊洞，實時性差，由于協(xié)議所致胡岔，安全性較高法希；而UDP無連接，無建立連接的過程靶瘸，因而實時性較強苫亦，安全略差毛肋；如果對實時性要求高和高速傳輸?shù)膱鼍跋滦枰褂肬DP；如果需要傳輸大量數(shù)據(jù)且對數(shù)據(jù)可靠性要求高的場景使用TCP屋剑；
TCP是面向字節(jié)流润匙，將應(yīng)用層報文看成一串無結(jié)構(gòu)的字節(jié)流，分解為多個TCP報文段傳輸后唉匾，在目的站重新裝配孕讳；UDP面向報文，不拆分應(yīng)用層報文巍膘，只保留報文邊界厂财，一次發(fā)送一個報文，接收方去除報文首部后典徘，原封不動將報文交給上層應(yīng)用蟀苛，并且網(wǎng)絡(luò)出現(xiàn)擁塞不會使得發(fā)送速率降低（因此會出現(xiàn)丟包，對實時的應(yīng)用比如IP電話和視頻會議等）逮诲。
開銷方面：在傳輸相同大小的數(shù)據(jù)時帜平，TCP首部開銷20字節(jié)；UDP首部開銷只有8個字節(jié)梅鹦，TCP報頭比UDP復(fù)雜裆甩，故實際包含的用戶數(shù)據(jù)較少。TCP無丟包齐唆，而UDP有丟包嗤栓，故TCP開銷大，UDP開銷較泄坑省茉帅；
連接數(shù)：每條tcp連接只能是點到點的；udp支持一對一锭弊、一對多堪澎、多對一、多對多的交互通信味滞。
TCP三大核心：
面向連接：所謂面向連接樱蛤，指的是客戶端與服務(wù)端的連接，在雙方互相通信之前剑鞍，TCP需要三次握手簡歷連接昨凡，而UDP沒有相應(yīng)的簡歷連接的過程
可靠性：TCP可靠性主要體現(xiàn)在有狀態(tài)和可控制资盅。有狀態(tài)是指TCP會精準(zhǔn)記錄哪些數(shù)據(jù)發(fā)送了吭从，被對方接受了，哪些沒有沥阳，而保證數(shù)據(jù)按序到達光戈，不允許差錯就轧；可控制：意識到丟包或者網(wǎng)絡(luò)環(huán)境差证杭，TCP根據(jù)具體情況調(diào)整自己的行為，控制自己發(fā)送速度或重發(fā)妒御。
面向字節(jié)流：UDP數(shù)據(jù)傳輸基于數(shù)據(jù)報解愤，僅僅是繼承了IP層的特性，而TCP為維護狀態(tài)乎莉，將IP包變成了字節(jié)流
3）網(wǎng)絡(luò)層
在計算機網(wǎng)絡(luò)中進行通信的兩個計算機之間可能會經(jīng)過很多個數(shù)據(jù)鏈路送讲，也可能還要經(jīng)過很多通信子網(wǎng)。網(wǎng)絡(luò)層的任務(wù)就是選擇合適的網(wǎng)間路由和交換結(jié)點惋啃， 確保數(shù)據(jù)及時傳送哼鬓。?在發(fā)送數(shù)據(jù)時，網(wǎng)絡(luò)層把運輸層產(chǎn)生的報文段或用戶數(shù)據(jù)報封裝成分組和包進行傳送边灭。在 TCP/IP 體系結(jié)構(gòu)中异希，由于網(wǎng)絡(luò)層使用?IP 協(xié)議，因此分組也叫?IP 數(shù)據(jù)報?绒瘦，簡稱數(shù)據(jù)報称簿。
交換機工作在數(shù)據(jù)鏈路層，路由器工作在網(wǎng)絡(luò)層
4）數(shù)據(jù)鏈路層
數(shù)據(jù)鏈路層通常簡稱為鏈路層惰帽。兩臺主機之間的數(shù)據(jù)傳輸憨降，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協(xié)議该酗。在兩個相鄰節(jié)點之間傳送數(shù)據(jù)時授药，數(shù)據(jù)鏈路層將網(wǎng)絡(luò)層交下來的 IP 數(shù)據(jù)報組裝成幀，在兩個相鄰節(jié)點間的鏈路上傳送幀呜魄。每一幀包括數(shù)據(jù)和必要的控制信息（如：同步信息悔叽，地址信息，差錯控制等）爵嗅。
5）物理層
物理層的作用是實現(xiàn)相鄰計算機節(jié)點之間比特流的透明傳送骄蝇。
2、DNS協(xié)議
DNS（Domain Names System）操骡，域名系統(tǒng)，是互聯(lián)網(wǎng)一項服務(wù)赚窃，是進行域名和與之相對應(yīng)的 IP 地址進行轉(zhuǎn)換的服務(wù)器册招。DNS相當(dāng)于一個翻譯官，負(fù)責(zé)將域名翻譯成ip地址勒极；
IP 地址：一長串能夠唯一地標(biāo)記網(wǎng)絡(luò)上的計算機的數(shù)字是掰。
域名：是由一串用點分隔的名字組成的 Internet 上某一臺計算機或計算機組的名稱，用于在數(shù)據(jù)傳輸時對計算機的定位標(biāo)識辱匿。
域名分為：根域名键痛、頂級域名炫彩、二級域名、三級域名等等絮短。
DNS 查詢的方式
DNS使用什么協(xié)議江兢？客戶端查詢DNS服務(wù)器時用 UDP；DNS服務(wù)器間進行域傳輸?shù)臅r候用TCP丁频。
1）遞歸查詢
2）迭代查詢
解析域名的過程
a杉允、首先搜索瀏覽器的 DNS 緩存，緩存中維護一張域名與 IP 地址的對應(yīng)表
b席里、若沒有命中叔磷，則繼續(xù)搜索操作系統(tǒng)的 DNS 緩存
c、若仍然沒有命中奖磁，則操作系統(tǒng)將域名發(fā)送至本地域名服務(wù)器改基，本地域名服務(wù)器采用遞歸查詢自己的 DNS 緩存，查找成功則返回結(jié)果
c咖为、若本地域名服務(wù)器的 DNS 緩存沒有命中秕狰，則本地域名服務(wù)器向上級域名服務(wù)器進行迭代查詢：
首先本地域名服務(wù)器向根域名服務(wù)器發(fā)起請求，根域名服務(wù)器返回頂級域名服務(wù)器的地址給本地服務(wù)器
本地域名服務(wù)器拿到這個頂級域名服務(wù)器的地址后案疲，就向其發(fā)起請求封恰，獲取權(quán)限域名服務(wù)器的地址
本地域名服務(wù)器根據(jù)權(quán)限域名服務(wù)器的地址向其發(fā)起請求，最終得到該域名對應(yīng)的 IP 地址
d褐啡、本地域名服務(wù)器將得到的 IP 地址返回給操作系統(tǒng)诺舔，同時自己將 IP 地址緩存起來。
e备畦、操作系統(tǒng)將 IP 地址返回給瀏覽器低飒，同時自己也將 IP 地址緩存起，至此懂盐，瀏覽器就得到了域名對應(yīng)的 IP 地址褥赊，并將 IP 地址緩存起。
3莉恼、CDN介紹
CDN (全稱 Content Delivery Network)拌喉，即內(nèi)容分發(fā)網(wǎng)絡(luò)。構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)之上的智能虛擬網(wǎng)絡(luò)俐银，依靠部署在各地的邊緣服務(wù)器尿背，通過中心平臺的負(fù)載均衡、內(nèi)容分發(fā)捶惜、調(diào)度等功能模塊田藐，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問響應(yīng)速度和命中率汽久。CDN的關(guān)鍵技術(shù)主要有內(nèi)容存儲和分發(fā)技術(shù)鹤竭。
CDN就是根據(jù)用戶位置分配最近的資源。用戶在上網(wǎng)的時候不用直接訪問源站景醇，而是訪問離他“最近的”一個 CDN 節(jié)點臀稚，術(shù)語叫邊緣節(jié)點，其實就是緩存了源站內(nèi)容的代理服務(wù)器啡直。
原理分析
我們使用域名訪問某一個站點時的路徑：用戶提交域名→瀏覽器對域名進行解釋→DNS解析得到目的主機的IP地址→根據(jù)IP地址訪問發(fā)出請求→得到請求數(shù)據(jù)并回復(fù)烁涌。
應(yīng)用CDN后，DNS返回的不再是IP地址酒觅，而是一個CNAME(Canonical Name ) 別名記錄撮执，指向CDN的全局負(fù)載均衡。
負(fù)載均衡系統(tǒng)
由于沒有返回IP地址舷丹，于是本地DNS會向負(fù)載均衡系統(tǒng)再發(fā)送請求 抒钱，則進入到CDN的全局負(fù)載均衡系統(tǒng)進行智能調(diào)度：
a、看用戶的 IP 地址颜凯，查表得知地理位置谋币，找相對最近的邊緣節(jié)點
b、看用戶所在的運營商網(wǎng)絡(luò)症概，找相同網(wǎng)絡(luò)的邊緣節(jié)點
c蕾额、檢查邊緣節(jié)點的負(fù)載情況，找負(fù)載較輕的節(jié)點彼城，還有其他的檢測诅蝶，比如節(jié)點的“健康狀況”、服務(wù)能力募壕、帶寬调炬、響應(yīng)時間等
結(jié)合上面的因素，得到最合適的邊緣節(jié)點舱馅，然后把這個節(jié)點返回給用戶缰泡，用戶就能夠就近訪問CDN的緩存代理。
緩存代理
緩存系統(tǒng)是CDN的另一個關(guān)鍵組成部分代嗤，緩存系統(tǒng)會有選擇地緩存那些最常用的那些資源棘钞。
兩個衡量CDN服務(wù)質(zhì)量的指標(biāo)：
命中率：用戶訪問的資源恰好在緩存系統(tǒng)里，可以直接返回給用戶干毅，命中次數(shù)與所有訪問次數(shù)之比宜猜。
回源率：緩存里沒有，必須用代理的方式回源站取溶锭，回源次數(shù)與所有訪問次數(shù)之比。
緩存系統(tǒng)也可以劃分出層次符隙，分成一級緩存節(jié)點和二級緩存節(jié)點：
a趴捅、一級緩存配置高一些垫毙，直連源站；
b拱绑、二級緩存配置低一些综芥，直連用戶。
回源的時候二級緩存只找一級緩存猎拨，一級緩存沒有才回源站膀藐，可以有效地減少真正的回源。
4红省、IPV4和IPV6的區(qū)別
1）IPv6把IP地址由32位（4 個字節(jié)）增加到128位（16 個字節(jié)）额各，從而能夠支持更大的地址空間。IPv4地址是以小數(shù)表示的二進制數(shù)吧恃。 IPv6地址是以十六進制表示的二進制數(shù)虾啦。
2）靈活的首部格式。IPv6將IPv4中的部分作用不大的報頭轉(zhuǎn)化為可選的擴展報頭痕寓，減輕了核心網(wǎng)路由器對數(shù)據(jù)報分析的負(fù)擔(dān)傲醉。
3）支持即插即用（即自動配置）。IPv4協(xié)議的地址可以通過手動或DHCP配置的呻率。
4）IPv6的路由表更小硬毕。可使路由器能在路由表中，用一條記錄表示一片子網(wǎng)礼仗。大大減小了路由器中路由表的長度吐咳，提高了路由器轉(zhuǎn)發(fā)數(shù)據(jù)包的速度。
5）IPv6具有更高的安全性藐守。在使用IPv6網(wǎng)絡(luò)中挪丢，用戶可以對網(wǎng)絡(luò)層的數(shù)據(jù)進行加密并對IP報文進行校驗。為用戶提供客戶端到服務(wù)端的數(shù)據(jù)安全卢厂，保證數(shù)據(jù)不被劫持乾蓬。
5、TCP粘包問題
首先我們介紹一下保護消息邊界和流慎恒。保護消息邊界任内，就是指傳輸協(xié)議把數(shù)據(jù)當(dāng)作一條獨立的消息在網(wǎng)上傳輸，接收端只能接收獨立的消息（UDP不會出現(xiàn)粘包融柬，因為它有消息邊界）死嗦。也就是說存在保護消息邊界，接收端一次只能接收發(fā)送端發(fā)出的一個數(shù)據(jù)包粒氧。而面向流則是指無保護消息保護邊界的（TCP是基于流的傳輸越除，所以無消息保護邊界），如果發(fā)送端連續(xù)發(fā)送數(shù)據(jù)，接收端有可能在一次接收動作中摘盆，會接收兩個或者更多的數(shù)據(jù)包翼雀。
例如，我們連續(xù)發(fā)送三個數(shù)據(jù)包孩擂，大小分別是2k狼渊，4k ，8k這三個數(shù)據(jù)包类垦，都已經(jīng)到達了接收端的網(wǎng)絡(luò)堆棧中狈邑，如果使用UDP協(xié)議，不管我們使用多大的接收緩沖區(qū)去接收數(shù)據(jù)蚤认，我們必須有三次接收動作米苹，才能夠把所有的數(shù)據(jù)包接收完；而使用TCP協(xié)議烙懦，我們只要把接收的緩沖區(qū)大小設(shè)置在14k以上驱入，我們就能夠一次把所有的數(shù)據(jù)包接收下來，只需要有一次接收動作氯析。
TCP無保護消息邊界的解決
針對這個問題亏较，一般有3種解決方案：
a、發(fā)送固定長度的消息掩缓。
b雪情、把消息的尺寸與消息一塊發(fā)送。
c你辣、使用特殊標(biāo)記來區(qū)分消息間隔巡通。
TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時粘成一包，從接收緩沖區(qū)看舍哄，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾宴凉。
1）沾包出現(xiàn)的原因
如果雙方建立連接，需要在連接后一段時間內(nèi)發(fā)送不同結(jié)構(gòu)數(shù)據(jù)表悬。如果發(fā)送方連續(xù)發(fā)送這個兩個包出去弥锄，接收方一次接收可能就會產(chǎn)生沾包問題。出現(xiàn)粘包現(xiàn)象的原因是多方面的蟆沫，它既可能由發(fā)送方造成籽暇，也可能由接收方造成。
a饭庞、發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去戒悠，造成粘包。由Nagle算法造成的發(fā)送端的粘包：Nagle算法是一種改善網(wǎng)絡(luò)傳輸效率的算法.簡單的說,當(dāng)我們提交一段數(shù)據(jù)給TCP發(fā)送時,TCP并不立刻發(fā)送此段數(shù)據(jù),而是等待一小段時間,看看在等待期間是否還有要發(fā)送的數(shù)據(jù),若有則會一次把這兩段數(shù)據(jù)發(fā)送出去舟山。
b绸狐、接收方不及時接收緩沖區(qū)的包卤恳，造成多個包接收。
發(fā)送方引起的粘包是由TCP協(xié)議本身造成的寒矿，TCP為提高傳輸效率纬黎，發(fā)送方往往要收集到足夠多的數(shù)據(jù)后才發(fā)送一包數(shù)據(jù)。若連續(xù)幾次發(fā)送的數(shù)據(jù)都很少劫窒，通常TCP會根據(jù)優(yōu)化算法把這些數(shù)據(jù)合成一包后一次發(fā)送出去，這樣接收方就收到了粘包數(shù)據(jù)拆座。
接收方引起的粘包是由于接收方用戶進程不及時接收數(shù)據(jù)主巍，從而導(dǎo)致粘包現(xiàn)象。這是因為接收方先把收到的數(shù)據(jù)放在系統(tǒng)接收緩沖區(qū)挪凑，用戶進程從該緩沖區(qū)取數(shù)據(jù)孕索，若下一包數(shù)據(jù)到達時前一包數(shù)據(jù)尚未被用戶進程取走，則下一包數(shù)據(jù)放到系統(tǒng)接收緩沖區(qū)時就接到前一包數(shù)據(jù)之后躏碳，而用戶進程根據(jù)預(yù)先設(shè)定的緩沖區(qū)大小從系統(tǒng)接收緩沖區(qū)取數(shù)據(jù)搞旭，這樣就一次取到了多包數(shù)據(jù)。
粘包情況有兩種：一種是粘在一起的包都是完整的數(shù)據(jù)包菇绵；另一種情況是粘在一起的包有不完整的包肄渗。
不是所有的粘包現(xiàn)象都需要處理，若傳輸?shù)臄?shù)據(jù)為不帶結(jié)構(gòu)的連續(xù)流數(shù)據(jù)（如文件傳輸）咬最，則不必把粘連的包分開（簡稱分包）翎嫡。但在實際工程應(yīng)用中，傳輸?shù)臄?shù)據(jù)一般為帶結(jié)構(gòu)的數(shù)據(jù)永乌，這時就需要做分包處理惑申。
在處理定長結(jié)構(gòu)數(shù)據(jù)的粘包問題時，分包算法比較簡單翅雏；在處理不定長結(jié)構(gòu)數(shù)據(jù)的粘包問題時圈驼，分包算法就比較復(fù)雜。特別是粘在一起的包有不完整的包的粘包情況望几，由于一包數(shù)據(jù)內(nèi)容被分在了兩個連續(xù)的接收包中绩脆，處理起來難度較大。
2）避免粘包現(xiàn)象的措施
a橄妆、對于發(fā)送方引起的粘包現(xiàn)象衙伶，用戶可通過編程設(shè)置來避免，TCP提供了強制數(shù)據(jù)立即傳送的操作指令push害碾，TCP軟件收到該操作指令后矢劲，就立即將本段數(shù)據(jù)發(fā)送出去，而不必等待發(fā)送緩沖區(qū)滿慌随；
b芬沉、對于接收方引起的粘包躺同，則可通過優(yōu)化程序設(shè)計、精簡接收進程工作量丸逸、提高接收進程優(yōu)先級等措施蹋艺，使其及時接收數(shù)據(jù)，從而盡量避免出現(xiàn)粘包現(xiàn)象黄刚；
c捎谨、由接收方控制，將一包數(shù)據(jù)按結(jié)構(gòu)字段憔维，人為控制分多次接收涛救，然后合并，通過這種手段來避免粘包业扒。
不足：
a检吆、第一種編程設(shè)置方法雖然可以避免發(fā)送方引起的粘包，但它關(guān)閉了優(yōu)化算法程储，降低了網(wǎng)絡(luò)發(fā)送效率蹭沛，影響應(yīng)用程序的性能，一般不建議使用章鲤。
b摊灭、第二種方法只能減少出現(xiàn)粘包的可能性，但并不能完全避免粘包败徊，當(dāng)發(fā)送頻率較高時斟或，或由于網(wǎng)絡(luò)突發(fā)可能使某個時間段數(shù)據(jù)包到達接收方較快，接收方還是有可能來不及接收集嵌，從而導(dǎo)致粘包萝挤。
c、第三種方法雖然避免了粘包根欧，但應(yīng)用程序的效率較低怜珍，對實時應(yīng)用的場合不適合。
6凤粗、QUIC協(xié)議
QUIC (Quick UDP Internet Connection)酥泛，又名HTTP3，它利用UDP解決了當(dāng)前基于TCP協(xié)議的HTTP的許多問題嫌拣，提升了在弱網(wǎng)環(huán)境下的網(wǎng)絡(luò)通信體驗柔袁。QUIC是谷歌推出的一套基于UDP的傳輸協(xié)議，它實現(xiàn)了TCP + HTTPS + HTTP/2的功能异逐，目的是保證可靠性的同時降低網(wǎng)絡(luò)延遲捶索。因為UDP是一個簡單傳輸協(xié)議，基于UDP可以擺脫TCP傳輸確認(rèn)灰瞻、重傳慢啟動等因素腥例，建立安全連接只需要一的個往返時間辅甥，它還實現(xiàn)了HTTP/2多路復(fù)用、頭部壓縮等功能燎竖。
1）QUIC的關(guān)鍵特性
a璃弄、連接遷移
一條 TCP 連接是由四元組標(biāo)識的（源 IP，源端口构回，目的 IP夏块，目的端口）。
連接遷移就是當(dāng)其中任何一個元素發(fā)生變化時纤掸，這條連接依然維持著拨扶，能夠保持業(yè)務(wù)邏輯不中斷。
主要關(guān)注的是客戶端的變化茁肠，因為客戶端不可控并且網(wǎng)絡(luò)環(huán)境經(jīng)常發(fā)生變化，而服務(wù)端的 IP 和端口一般都是固定的缩举。比如使用手機在 WIFI 和 4G 移動網(wǎng)絡(luò)切換時垦梆，客戶端的 IP 肯定會發(fā)生變化，需要重新建立和服務(wù)端的 TCP 連接仅孩。有些連接競爭時需要重新綁定端口托猩，導(dǎo)致客戶端的端口發(fā)生變化，同樣需要重新建立 TCP 連接辽慕。這就是TCP連接重連之痛京腥。
解決方案：基于UDP的QUIC連接遷移
當(dāng)用戶的地址發(fā)生變化時，如 WIFI 切換到 4G 場景溅蛉，基于 TCP 的 HTTP 協(xié)議無法保持連接的存活公浪。QUIC 基于連接 ID 唯一識別連接。當(dāng)源地址發(fā)生改變時船侧，QUIC 仍然可以保證連接存活和數(shù)據(jù)正常收發(fā)欠气。
QUIC是基于UDP協(xié)議的，任何一條 QUIC 連接不再以 IP 及端口四元組標(biāo)識镜撩，而是以一個 64 位的隨機數(shù)作為 ID 來標(biāo)識预柒，這樣就算 IP 或者端口發(fā)生變化時，只要 ID 不變袁梗，這條連接依然維持著宜鸯，上層業(yè)務(wù)邏輯感知不到變化，不會中斷遮怜，也就不需要重連淋袖。
b、低連接時延
以一次簡單的瀏覽器訪問為例锯梁，在地址欄中輸入https://www.abc.com适贸，實際會產(chǎn)生以下動作：
DNS遞歸查詢www.abc.com灸芳，獲取地址解析的對應(yīng)IP；
TCP握手拜姿，我們熟悉的TCP三次握手需要需要1個RTT烙样；
TLS握手，以目前應(yīng)用最廣泛的TLS 1.2而言蕊肥，需要2個RTT谒获。對于非首次建連，可以選擇啟用會話重用壁却，則可縮小握手時間到1個RTT批狱；
HTTP業(yè)務(wù)數(shù)據(jù)交互，假設(shè)abc.com的數(shù)據(jù)在一次交互就能取回來展东。那么業(yè)務(wù)數(shù)據(jù)的交互需要1個RTT赔硫；
經(jīng)過上面的過程分析可知，要完成一次簡短的HTTPS業(yè)務(wù)數(shù)據(jù)交互盐肃，需要經(jīng)歷：新連接?4RTT + DNS爪膊；會話重用3RTT + DNS。
所以砸王，對于數(shù)據(jù)量小的請求而言推盛，單一次的請求握手就占用了大量的時間，對于用戶體驗的影響非常大谦铃。同時耘成，在用戶網(wǎng)絡(luò)不佳的情況下，RTT延時會變得較高驹闰，極其影響用戶體驗瘪菌。
解決方案：真0-RTT的QUIC握手
QUIC 由于基于 UDP，無需 TCP 連接嘹朗，在最好情況下控嗜，短連接下 QUIC 可以做到 0RTT 開啟數(shù)據(jù)傳輸。
基于 TCP 的 HTTPS連接時延骡显，一方面是TCP和TLS分層設(shè)計導(dǎo)致的疆栏，分層的設(shè)計需要每個邏輯層次分別建立自己的連接狀態(tài)。另一方面是TLS的握手階段復(fù)雜的密鑰協(xié)商機制導(dǎo)致的惫谤。要降低建連耗時
QUIC具體握手過程如下：
1.客戶端判斷本地是否已有服務(wù)器的全部配置參數(shù)（證書配置信息）壁顶，如果有則直接跳轉(zhuǎn)到(5)，否則繼續(xù) 溜歪；
2.客戶端向服務(wù)器發(fā)送inchoate client hello(CHLO)消息若专，請求服務(wù)器傳輸配置參數(shù)；
3.服務(wù)器收到CHLO蝴猪，回復(fù)rejection(REJ)消息调衰，其中包含服務(wù)器的部分配置參數(shù)膊爪；
4.客戶端收到REJ，提取并存儲服務(wù)器配置參數(shù)嚎莉，跳回到(1) 米酬；
5.客戶端向服務(wù)器發(fā)送full client hello消息，開始正式握手趋箩，消息中包括客戶端選擇的公開數(shù)赃额。此時客戶端根據(jù)獲取的服務(wù)器配置參數(shù)和自己選擇的公開數(shù)，可以計算出初始密鑰K1叫确；
6.服務(wù)器收到full client hello跳芳，如果不同意連接就回復(fù)REJ，同(3)竹勉；如果同意連接飞盆，根據(jù)客戶端的公開數(shù)計算出初始密鑰K1，回復(fù)server hello(SHLO)消息次乓，SHLO用初始密鑰K1加密吓歇，并且其中包含服務(wù)器選擇的一個臨時公開數(shù)；
7.客戶端收到服務(wù)器的回復(fù)檬输，如果是REJ則情況同(4)；如果是SHLO匈棘，則嘗試用初始密鑰K1解密丧慈，提取出臨時公開數(shù)；
8.客戶端和服務(wù)器根據(jù)臨時公開數(shù)和初始密鑰K1主卫，各自基于SHA-256算法推導(dǎo)出會話密鑰K2逃默；
9.雙方更換為使用會話密鑰K2通信，初始密鑰K1此時已無用簇搅，QUIC握手過程完畢完域。之后會話密鑰K2更新的流程與以上過程類似，只是數(shù)據(jù)包中的某些字段略有不同瘩将。
C吟税、可自定義的擁塞控制
Quic使用可插拔的擁塞控制，相較于TCP姿现，它能提供更豐富的擁塞控制信息肠仪。比如對于每一個包，不管是原始包還是重傳包备典，都帶有一個新的序列號(seq)异旧，這使得Quic能夠區(qū)分ACK是重傳包還是原始包，從而避免了TCP重傳模糊的問題提佣。Quic同時還帶有收到數(shù)據(jù)包與發(fā)出ACK之間的時延信息吮蛹。這些信息能夠幫助更精確的計算RTT荤崇。此外，Quic的ACK Frame 支持256個NACK 區(qū)間潮针，相比于TCP的SACK(Selective Acknowledgment)更彈性化术荤，更豐富的信息會讓client和server 哪些包已經(jīng)被對方收到。
d然低、無隊頭阻塞
雖然 HTTP2 實現(xiàn)了多路復(fù)用喜每，但是因為其基于面向字節(jié)流的 TCP，因此一旦丟包雳攘，將會影響多路復(fù)用下的所有請求流带兜。QUIC 基于 UDP，在設(shè)計上就解決了隊頭阻塞問題吨灭。
TCP 隊頭阻塞的主要原因是數(shù)據(jù)包超時確認(rèn)或丟失阻塞了當(dāng)前窗口向右滑動刚照，解決隊頭阻塞的方案是不讓超時確認(rèn)或丟失的數(shù)據(jù)包將當(dāng)前窗口阻塞在原地。QUIC也正是采用上述方案來解決TCP 隊頭阻塞問題的喧兄。TCP 為了保證可靠性无畔，使用了基于字節(jié)序號的 Sequence Number 及 Ack 來確認(rèn)消息的有序到達。
解決方案：QUIC的無隊頭阻塞
QUIC 同樣是一個可靠的協(xié)議吠冤，它使用 Packet Number 代替了 TCP 的 Sequence Number浑彰，并且每個 Packet Number 都嚴(yán)格遞增，也就是說就算 Packet N 丟失了拯辙，重傳的 Packet N 的 Packet Number 已經(jīng)不是 N郭变，而是一個比 N 大的值，比如Packet N+M涯保。
QUIC 使用的Packet Number 單調(diào)遞增的設(shè)計诉濒，可以讓數(shù)據(jù)包不再像TCP 那樣必須有序確認(rèn)，QUIC 支持亂序確認(rèn)夕春，當(dāng)數(shù)據(jù)包Packet N 丟失后未荒，只要有新的已接收數(shù)據(jù)包確認(rèn)，當(dāng)前窗口就會繼續(xù)向右滑動及志。待發(fā)送端獲知數(shù)據(jù)包Packet N 丟失后片排，會將需要重傳的數(shù)據(jù)包放到待發(fā)送隊列，重新編號比如數(shù)據(jù)包Packet N+M 后重新發(fā)送給接收端速侈，對重傳數(shù)據(jù)包的處理跟發(fā)送新的數(shù)據(jù)包類似划纽，這樣就不會因為丟包重傳將當(dāng)前窗口阻塞在原地，從而解決了隊頭阻塞問題锌畸。
那么勇劣，既然重傳數(shù)據(jù)包的Packet N+M 與丟失數(shù)據(jù)包的Packet N 編號并不一致，我們怎么確定這兩個數(shù)據(jù)包的內(nèi)容一樣呢？
QUIC使用Stream ID 來標(biāo)識當(dāng)前數(shù)據(jù)流屬于哪個資源請求比默，這同時也是數(shù)據(jù)包多路復(fù)用傳輸?shù)浇邮斩撕竽苷＝M裝的依據(jù)幻捏。重傳的數(shù)據(jù)包Packet N+M 和丟失的數(shù)據(jù)包Packet N 單靠Stream ID 的比對一致仍然不能判斷兩個數(shù)據(jù)包內(nèi)容一致，還需要再新增一個字段Stream Offset命咐，標(biāo)識當(dāng)前數(shù)據(jù)包在當(dāng)前Stream ID 中的字節(jié)偏移量篡九。
有了Stream Offset 字段信息，屬于同一個Stream ID 的數(shù)據(jù)包也可以亂序傳輸了（HTTP/2 中僅靠Stream ID 標(biāo)識醋奠，要求同屬于一個Stream ID 的數(shù)據(jù)幀必須有序傳輸）榛臼，通過兩個數(shù)據(jù)包的Stream ID 與 Stream Offset 都一致，就說明這兩個數(shù)據(jù)包的內(nèi)容一致窜司。
2）QUIC協(xié)議組成
a紅色部分是 Stream Frame 的報文頭部沛善，有認(rèn)證。綠色部分是報文內(nèi)容塞祈，全部經(jīng)過加密金刁。
Flags：用于表示Connection ID長度、Packet Number長度等信息议薪；
Connection ID：客戶端隨機選擇的最大長度為64位的無符號整數(shù)尤蛮。但是，長度可以協(xié)商斯议；
QUIC Version：QUIC協(xié)議的版本號产捞，32位的可選字段。如果Public Flag & FLAG_VERSION != 0哼御，這個字段必填坯临。客戶端設(shè)置Public Flag中的Bit0為1艇搀，并且填寫期望的版本號尿扯。如果客戶端期望的版本號服務(wù)端不支持求晶，服務(wù)端設(shè)置Public Flag中的Bit0為1焰雕，并且在該字段中列出服務(wù)端支持的協(xié)議版本（0或者多個），并且該字段后不能有任何報文芳杏；
Packet Number：長度取決于Public Flag中Bit4及Bit5兩位的值矩屁，最大長度6字節(jié)。發(fā)送端在每個普通報文中設(shè)置Packet Number爵赵。發(fā)送端發(fā)送的第一個包的序列號是1吝秕，隨后的數(shù)據(jù)包中的序列號的都大于前一個包中的序列號；
Stream ID：用于標(biāo)識當(dāng)前數(shù)據(jù)流屬于哪個資源請求空幻；
Offset：標(biāo)識當(dāng)前數(shù)據(jù)包在當(dāng)前Stream ID 中的字節(jié)偏移量烁峭；
