純屬個人筆記，整理包含一些自己的理解和資源
網(wǎng)絡(luò)技術(shù)概覽###
1. 延遲與帶寬
- 考慮信息傳播的路徑
- 300ms內(nèi)響應(yīng)
- cdn從物理上縮短運(yùn)輸時間，也就是延遲
- 延遲中相當(dāng)大的部分花在最后幾公里(linux下采用tracerouter -I baidu.com 查看整個路徑過程)
- 帶寬
RTT (Round-Trip Time)
2.TCP的構(gòu)成
Transmission Control Protocol ：負(fù)責(zé)在不可靠的傳輸信道上提供可靠的抽象層;
TCP三次握手：
TCP三次握手過程中交換了彼此的接收窗口rwnd（包含能夠保存數(shù)據(jù)的緩沖區(qū)空間大小信息）
TCP窗口縮放：可設(shè)定窗口縮放最大值（原本: 65 535B）到1G
慢啟動
擁塞窗口大小 cwnd：發(fā)送端對客戶端接收確認(rèn)(ACK)之前可以發(fā)送數(shù)據(jù)量的限
cwnd并不是交換發(fā)送得知的（因?yàn)榻粨Q只在握手的時候嘛），基本上靠猜: 算法
*所以說時間不僅浪費(fèi)在三次握手的階段，還有慢啟動玩焰，所以如果可以維持建立狀態(tài)的話，就會省掉不少時間 *
帶寬延遲積（發(fā)送往返時間）
隊(duì)首阻塞（HOP, Head of Line）
每個TCP分組都會帶著一個唯一的序列號被發(fā)出壳繁，而所有分組必須按照順序傳送到接收端震捣，如果中途有一個分組沒能到達(dá)接收端，那么后序分組必須保存在接收端的TCP緩沖區(qū)闹炉，等待丟失的分組重發(fā)并到達(dá)接收端。應(yīng)用程序并不知道這些润樱，必須等到分組全部到達(dá)時才能訪問數(shù)據(jù)渣触。在此之前，應(yīng)用程序只能在通過套接字讀取數(shù)據(jù)時感覺到延遲交付晦墙。
綜上窃爷，優(yōu)化TCP性能list如下：
- 把服務(wù)器內(nèi)核升級到最新版本
- 確保cwnd大小為10
- 禁用空閑后的慢啟動
- 確保啟動窗口縮放
- 減少傳輸冗余數(shù)據(jù)
- 壓縮要傳輸?shù)臄?shù)據(jù)
- 把服務(wù)器放到離用戶最近的地方以減少往返時間
- 盡最大可能重用已建立的TCP連接
** 3.UDP構(gòu)成 **
UDP -- 無協(xié)議（暫時只看到說實(shí)時視頻的時候會使用: UDP的使用 )
** NAT（network address translator）IP網(wǎng)絡(luò)地址轉(zhuǎn)換器 **
1994年因?yàn)镮Pv4地址快用完了昭灵，所以采用NAT這種ip重用方法。就內(nèi)網(wǎng)ip和外網(wǎng)ip的東東了养篓。
因?yàn)閁DP包要包含源IP和目標(biāo)IP，然后它自己和NAT都沒有記錄自己內(nèi)網(wǎng)IP赂蕴，所以需要STUN服務(wù)器來返回內(nèi)網(wǎng)ip
由于很容易被防火墻攔截柳弄，所以可以使用TURN協(xié)議，切換到TCP
實(shí)際上最好使用的是ICE協(xié)議概说，能夠自動判斷出最有效的通道
優(yōu)化看不是很懂碧注，基本上基于UDP無協(xié)議的特點(diǎn)，也就是說不管包別人收到?jīng)]有糖赔，一直發(fā)一直發(fā)的特點(diǎn)而做出類似TCP的一些算法萍丐，提到WebRTC符合優(yōu)化要求的框架（也就是真愛的意思咯）
** 4.TLS 傳輸層安全 **
TLS的前身是SSL（secure sockets layer 安全套接字層）
TLS協(xié)議的目的是為在它之上運(yùn)行的應(yīng)用提供三個基本服務(wù)： 加密，身份驗(yàn)證和數(shù)據(jù)完整性
websocket放典、spdy之類的要使用https是因?yàn)橐@過中間代理逝变，從而實(shí)現(xiàn)可靠的部署。奋构。
TLS握手（在TCP握手后還要發(fā)送自己的信息過去壳影，然后服務(wù)器發(fā)自己證書，客戶端收到再發(fā)自己證書還有對稱密鑰声怔，服務(wù)器發(fā)送finished态贤，客戶端驗(yàn)證然后建立信道發(fā)送數(shù)據(jù)）
SSL會話是可以重用的，也就是說后面的TLS連接可以重用第一個
TLS記錄： 前面提到TCP萬一中間出現(xiàn)丟包什么的醋火，要把有的包先放進(jìn)TCP緩存里面悠汽，這個時候就需要記住它們箱吕。
優(yōu)化：
- 提升TCP性能
- 把TLS升級到最新版本庫
- 啟用并配置會話緩存和無狀態(tài)恢復(fù)
- 監(jiān)控會話緩存的使用情況并做出響應(yīng)調(diào)整
- 配置TLS記錄大小
- 確保證書鏈不會超過擁塞窗口大小
- 從信任鏈中去掉不必要的證書
- 禁用服務(wù)器TLS壓縮功能
- 啟用服務(wù)器對SNI支持
- 啟用服務(wù)器OCSP封套功能
- 追加HTTP嚴(yán)格傳輸安全首部
無線網(wǎng)絡(luò)性能##
** 5.無線網(wǎng)絡(luò)概覽 **
無線網(wǎng)絡(luò)性能基礎(chǔ)（帶寬（c = BW * log2( 1 + S / N)），信號強(qiáng)度柿冲， 別人家的影響等等）
** 6.wifi（802.11）**
恩茬高，復(fù)習(xí)CSMA ‘先聽后說’ 之類的（當(dāng)年老師上課該聽不聽==）
wifi性能(看不是很懂)
** 7.移動網(wǎng)絡(luò) **
各種知識科普(RRC)
在4G手機(jī)上打開瀏覽器，輸入URL假抄，發(fā)生了：
- 初始時手機(jī)處于空閑RRC狀態(tài)怎栽，所以無線電模塊必須與附近信號塔同步，然后發(fā)送一個請求宿饱，建立無線通信環(huán)境熏瞄，需要幾次往返，花費(fèi)100ms
- 設(shè)備從信號塔得到相應(yīng)資源谬以，從而以特定速度與功率傳輸數(shù)據(jù)强饮。用戶數(shù)據(jù)從無線電模塊傳輸?shù)叫盘査臅r間成為用戶面單向延遲，4G中花費(fèi)5ms为黎。實(shí)際上邮丰，由于切換RRC，第一個分組花的時間比較多铭乾，后面只要無線電模塊保持高工率狀態(tài)剪廉，后序分組的延遲時間都是恒定的。
- 分組通過核心網(wǎng)絡(luò)從SGW傳輸?shù)絇GW
- 向外傳播到公共互聯(lián)網(wǎng)
- 瀏覽器獲取內(nèi)容炕檩，用戶查看
- 此時無線電模塊空閑十幾秒斗蒋，RRC切換到DRX狀態(tài)，此時若用戶重新觸發(fā)新請求捧书，除了第一步時時間會短一點(diǎn)吹泡，其他都是類似了。
數(shù)據(jù)返回路線：
- PGW把入站分組路由到SGW经瓷， SGW進(jìn)一步查詢MME
- 如果設(shè)備處于空閑爆哑，MME會向當(dāng)前跟蹤區(qū)內(nèi)的所有信號塔發(fā)送一條尋呼消息
- 收到消息的信號塔接著通過共享的無線信道廣播一條通知，告訴設(shè)備重建無線通信環(huán)境舆吮，以便接收數(shù)據(jù)
- 設(shè)備周期性地喚醒以監(jiān)聽尋呼消息揭朝，如果在尋呼列表里發(fā)現(xiàn)自己，就會向無線電信號塔發(fā)送一條協(xié)商請求色冀，重新建立無線通信環(huán)境
- 環(huán)境建立后潭袱，負(fù)責(zé)協(xié)商的信號塔向MME發(fā)送一條信息，表示它正在為用戶服務(wù)
- MME向服務(wù)網(wǎng)關(guān)返回一個應(yīng)答锋恬，服務(wù)網(wǎng)關(guān)于是把數(shù)據(jù)路由到該信號塔
- 信號塔再把數(shù)據(jù)發(fā)送給目標(biāo)設(shè)備
- 無線信號塔與網(wǎng)關(guān)會建立一條直通信號屯换，使得后面的數(shù)據(jù)可以跳過2-5步.
** 延遲出現(xiàn)在**
- 控制面延遲（RRC狀態(tài)切換 空閑 -> 啟動 100ms 休眠 -> 啟動 50ms）
- 用戶面延遲（分組從設(shè)備到無線電信號塔之間的固定時間 >5ms）
- 核心網(wǎng)絡(luò)延遲（從無線電信號塔到分組網(wǎng)關(guān)時間 30~100ms）
- 互聯(lián)網(wǎng)路由延遲（從運(yùn)營商分組網(wǎng)關(guān)到公共互聯(lián)網(wǎng)上的目標(biāo)地址所花時間，可變）
** 8.移動網(wǎng)絡(luò)優(yōu)化建議 **
普適建議：
- 節(jié)約用電（盡量在無線電開啟時傳輸數(shù)據(jù)，盡量把喚醒無線電以傳輸數(shù)據(jù)的次數(shù)降到最低）
- 消除周期性及無效的數(shù)據(jù)傳輸（輪詢在移動網(wǎng)絡(luò)代價極高彤悔，少用嘉抓；盡可能使用推送和通知；出站和入站請求應(yīng)合并和匯總晕窑；非關(guān)鍵性請求應(yīng)當(dāng)推遲到無線模塊活動時進(jìn)行）
- 消除不必要的長連接
- 預(yù)測網(wǎng)絡(luò)延遲上限
- 考慮RRC狀態(tài)切換
- 解耦用戶交互與網(wǎng)絡(luò)通信
- 預(yù)先獲取資源
HTTP##
** 9.HTTP簡史 **
HTTP 0.9
- 客戶端/服務(wù)器抑片、請求/響應(yīng)協(xié)議
- ASCII協(xié)議，運(yùn)行與TCP/IP上
- 設(shè)計(jì)用來傳輸超文本文檔(HTML)
- 服務(wù)器與客戶端之間的連接在每次請求后都會關(guān)閉
HTTP 1.0
- 請求可以由多行首部字段構(gòu)成
- 響應(yīng)對象前面添加了一個響應(yīng)狀態(tài)行
- 響應(yīng)對象也有自己的由換行符分割的首部字段
- 響應(yīng)對象不局限于超文本
- 服務(wù)器與客戶端之間的連接在每次請求之后都會關(guān)閉
HTTP 1.1
- 請求HTML文件及其編碼杨赤、字符集和元數(shù)據(jù)
- 對原始HTML請求的分塊響應(yīng)
- 以ASCII十六禁止數(shù)字表示分塊數(shù)據(jù)的字節(jié)數(shù)（256字節(jié)）
- 分塊數(shù)據(jù)流響應(yīng)結(jié)束
- 在同一個TCP連接上請求圖標(biāo)文件
- 通知服務(wù)器不再使用連接了
- 圖標(biāo)響應(yīng)敞斋，隨后關(guān)閉連接
*出現(xiàn)了TCP重用，可以在首部明確close還有編碼疾牲，cookie等等等 *
個人關(guān)于HTTP是無狀態(tài)連接的疑問獲得的解答：
HTTP是一個無狀態(tài)的面向連接的協(xié)議植捎，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）從HTTP/1.1起阳柔，默認(rèn)都開啟了Keep-Alive鸥跟，保持連接特性，簡單地說盔沫，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉枫匾，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁架诞，會繼續(xù)使用這一條已經(jīng)建立的連接Keep-Alive不會永久保持連接，它有一個保持時間干茉，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間
HTTP 2.0
主要目的時為了改善傳輸性能谴忧，實(shí)現(xiàn)低延遲和高吞吐量
** 10.web性能要點(diǎn) **
web應(yīng)用的執(zhí)行主要涉及三個任務(wù)：取得資源、頁面布局和渲染角虫、js執(zhí)行
各種api：Navigation Timing沾谓、User Timing、Resource Timing
瀏覽器所做的功夫：
- 資源預(yù)取和排定優(yōu)先次序
- DNS預(yù)解析
- TCP預(yù)連接
- 頁面預(yù)渲染（通過我們提示下一個可能目標(biāo)）
我們能做：
優(yōu)化頁面結(jié)構(gòu)（css頭部戳鹅，js尾部均驶，非關(guān)鍵js推遲）
-
在文檔中嵌入提示，以觸發(fā)瀏覽器為我們采用的其他優(yōu)化機(jī)制（非全面兼容）詳情
<link rel="dns-prefetch" href="xxx"> <link rel="subresource" href="xxx"> <link rel="prefetch" href="xxx"> <link rel="prerender" href="xxx">
** 11.HTTP 1.x **
- 持久連接
- HTTP管道（單純的持久連接還是FIFO枫虏，管道使并行成為可能妇穴， 雖然如此，每個資源還是要在前一個發(fā)送并接收之后才發(fā)送第二個（TCP隊(duì)首阻塞）高級選項(xiàng)）
- 使用多個TCP連接（最多6個了隶债， 減弱慢啟動腾它，但是會占用更多的客戶端緩沖和帶寬資源）
- 域名分區(qū)
- 度量和控制協(xié)議開銷（cookie、 首部之類的）
- 連接和拼合
- 嵌入資源（data uri死讹、內(nèi)聯(lián)css瞒滴、js等）一般來說只考慮嵌入1~2kb以下的資源
** 12.HTTP 2.0 **
前身是SPDY
- 二進(jìn)制分幀層（核心）
*流 *：已建立的連接上的雙向字節(jié)流
消息：與邏輯消息對應(yīng)的完整的一系列數(shù)據(jù)幀
幀：HTTP 2.0通信的最小單位，每個幀包含幀首部赞警，至少也會標(biāo)志出當(dāng)前幀所屬流
看圖應(yīng)該已經(jīng)一目了然
- 多請求與多響應(yīng)
請求優(yōu)先級
0表最高優(yōu)先級
2^31-1表最低優(yōu)先級
- 每個來源一個連接(TCP連接已經(jīng)變持久化了妓忍，慢啟動時間減少虏两，握手也不用握很多次了)
- 流量控制
- 服務(wù)器推送
- 首部壓縮
13.優(yōu)化應(yīng)用的交付
兩個原則：（1）消除或減少不必要的網(wǎng)絡(luò)延遲；（2）將需要傳輸?shù)臄?shù)據(jù)壓縮至最少
- 減少DNS查找
- 重用TCP連接
- 減少HTTP重定向
- 使用CDN
- 去掉不必要的資源
- 在客戶端緩存資源
- 傳輸壓縮過的內(nèi)容
- 消除不必要的請求開銷（比如說cookie）
- 并行處理請求和響應(yīng)
- 針對協(xié)議版本采取優(yōu)化措施
在客戶端緩存資源
首部包含合適的緩存字段：Cache-Control ; Last-Modified和ETag
墻裂推薦Alloy Team關(guān)于瀏覽器緩存機(jī)制的一系列文章
消除不必要的請求字節(jié)
瀏覽器一半把cookie限制在4KB內(nèi);可以制定一個專門無需cookie的來源服務(wù)器单默，來交付那些不需要區(qū)分客戶端的共用資源
專門針對HTTP 2.0來說碘举，要忘記域名分區(qū)，文件拼接搁廓，圖片精靈等不良習(xí)慣（==）
接下來講HTTP 1.X與HTTP 2.0過渡的問題引颈，沒有記...
瀏覽器API與協(xié)議##
14.瀏覽器網(wǎng)絡(luò)概述
15.XMLHttpRequest
CORS(這個時候是拿不到cookie和http認(rèn)證的，必須要發(fā)送withCredentials)
XHR支持?jǐn)?shù)據(jù)格式
- 接收: ArrayBuffer Blob Document JSON Text
- 發(fā)送：DOMString Document FormData Blob File以及ArrayBuffer
輪詢
最簡單輪詢：setInterval
長輪詢：每次都ajax請求境蜕，請求成功后 繼續(xù)請求蝙场。。
16.服務(wù)器發(fā)送事件（好像很牛逼的樣子~）
Server-Sent Event: 讓服務(wù)器可以向客戶端流式發(fā)送文本信息
具體使用阮一峰的博客可以看一看
** 17.websocket **
比較常見啦粱年，聊天室什么的售滤，貼一個 用socket.io與node.js實(shí)現(xiàn)聊天室的教程
18.WebRTC
Web Real-Time Communication(Web實(shí)時通信)：由一組標(biāo)準(zhǔn)、協(xié)議和js API組成台诗，用于實(shí)現(xiàn)瀏覽器之間（端到端）的音頻完箩、視頻及數(shù)據(jù)共享。
通過UDP傳輸
