計算機網(wǎng)絡是計算機科學與技術專業(yè)的必修課兼蜈，也是移動端，前端拙友，后端都會涉及并用到的知識點为狸，可想而知它的重要性。所以它也成為了iOS面試中經(jīng)常被問及的問題遗契。準備面試的話辐棒，網(wǎng)絡相關的知識點一定不能錯過。這里總結了一些我認為有用的和最近面試遇到的網(wǎng)絡相關知識點。
去年寫過一篇《圖解TCP/IP》總結的文章漾根，也可以對著看下泰涂。
計算機網(wǎng)絡是如何分層的
網(wǎng)絡有兩種分層模型，一種是ISO（國際標準化組織）制定的OSI（Open System Interconnect）模型辐怕，它將網(wǎng)絡分為七層逼蒙。一種是TCP/IP的四層網(wǎng)絡模型。OSI是一種學術上的國際標準寄疏，理想概念其做，TCP/IP是事實上的國際標準，被廣泛應用于現(xiàn)實生活中赁还。兩者的關系可以看這個圖：
注：也有說五層模型的妖泄，它跟四層模型的區(qū)別就是，在OSI模型中的數(shù)據(jù)鏈路層和物理層艘策，前者將其作為兩層蹈胡，后者將其合并為一層稱為網(wǎng)絡接口層。一般作為面試題的話都是需要講出OSI七層模型的朋蔫。
各個分層的含義以及它們之間的關系用這張圖表示：
Http協(xié)議
http協(xié)議特性
HTTP 協(xié)議構建于 TCP/IP 協(xié)議之上罚渐，是一個應用層協(xié)議，默認端口號是 80
靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象驯妄。正在傳輸?shù)念愋陀蒀ontent-Type加以標記荷并。
無狀態(tài)：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求青扔，并收到客戶的應答后源织，即斷開連接。
無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議微猖。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力谈息。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳凛剥。
請求方法
GET：請求獲取Request-URI標識的資源侠仇，請求參數(shù)附加在url上，明文展示犁珠。
POST：在Request-URI所標識的資源后附加新的數(shù)據(jù)逻炊，常用于修改服務器資源或者提交資源到服務器。POST請求體是放到body中的犁享，可以指定編碼方式余素，更加安全。
HEAD：請求獲取由Request-URI所標識的資源的響應消息報頭饼疙。
PUT：請求服務器存儲一個資源溺森，并用Request-URI作為其標識梯澜。
DELETE：請求服務器刪除Request-URI所標識的資源意狠。
TRACE：請求服務器回送收到的請求信息砚作，主要用于測試或診斷舍哄。
OPTIONS：請求查詢服務器的性能棠耕，或者查詢與資源相關的選項和需求假残。
請求和響應報文
以該鏈接為例：zhangferry.com/2019/08/31/…
在Chrome查看其請求的Headers信息绩社。
General
這里標記了請求的URL筹我，請求方法為GET卷要。狀態(tài)碼為304渣聚，代表文件未修改，可以直接使用緩存的文件僧叉。遠程地址為185.199.111.153:443奕枝，此IP為Github 服務器地址，是因為我的博客是部署在GitHub上的瓶堕。
除了304還有別的狀態(tài)碼隘道，分別是：
200 OK 客戶端請求成功
301 Moved Permanently 請求永久重定向
302 Moved Temporarily 請求臨時重定向
304 Not Modified 文件未修改，可以直接使用緩存的文件郎笆。
400 Bad Request 由于客戶端請求有語法錯誤谭梗，不能被服務器所理解。
401 Unauthorized 請求未經(jīng)授權宛蚓。這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用
403 Forbidden 服務器收到請求激捏，但是拒絕提供服務。服務器通常會在響應正文中給出不提供服務的原因
404 Not Found 請求的資源不存在凄吏，例如远舅，輸入了錯誤的URL
500 Internal Server Error 服務器發(fā)生不可預期的錯誤，導致無法完成客戶端的請求痕钢。
503 Service Unavailable 服務器當前不能夠處理客戶端的請求表谊，在一段時間之后，服務器可能會恢復正常盖喷。
Response Headers：
content-encoding：用于指定壓縮算法
content-length：資源的大小爆办，以十進制字節(jié)數(shù)表示。
content-type：指示資源的媒體類型课梳。圖中所示內容類型為html的文本類型距辆，文字編碼方式為utf-8
last-modified：上次內容修改的日期，為6月8號
status：304 文件未修改狀態(tài)碼
注：其中content-type在響應頭中代表暮刃，需要解析的格式跨算。在請求頭中代表上傳到服務器的內容格式。
Request Headers：
:method：GET請求
:path：url路徑
:scheme：https請求
accept：通知服務器可以返回的數(shù)據(jù)類型椭懊。
accept-encoding：編碼算法诸蚕，通常是壓縮算法，可用于發(fā)送回的資源
accept-language：通知服務器預期發(fā)送回的語言類型。這是一個提示背犯，并不一定由用戶完全控制:服務器應該始終注意不要覆蓋用戶的顯式選擇(比如從下拉列表中選擇語言)坏瘩。
cookie：瀏覽器cookie
user-agent：用戶代理，標記系統(tǒng)和瀏覽器內核
更多請求頭的字段含義可以參考這里：HTTP headers
TCP三次握手和四次揮手的過程以及為什么要有三次和四次
在了解TCP握手之前我們先看下TCP的報文樣式：
其中控制位（Control Flag）標記著握手階段的各個狀態(tài)漠魏。
TCP三次握手
示意圖如下：
三次握手是指建立一個TCP連接時倔矾，需要客戶端和服務器總共發(fā)送3個數(shù)據(jù)包。
1柱锹、第一次握手（SYN=1, seq=x）
客戶端發(fā)送一個 TCP 的 SYN 標志位置1的包哪自，指明客戶端打算連接的服務器的端口，以及初始序號 X,保存在包頭的序列號(Sequence Number)字段里禁熏。
發(fā)送完畢后壤巷，客戶端進入 SYN_SEND 狀態(tài)。
2瞧毙、第二次握手（SYN=1, ACK=1, seq=y, ACKnum=x+1）
服務器發(fā)回確認包(ACK)應答胧华。即 SYN 標志位和 ACK 標志位均為1。服務器端選擇自己 ISN 序列號升筏，放到 Seq 域里撑柔，同時將確認序號(Acknowledgement Number)設置為客戶的 ISN 加1，即X+1您访。 發(fā)送完畢后铅忿，服務器端進入 SYN_RCVD 狀態(tài)。
3灵汪、第三次握手（ACK=1, ACKnum=y+1）
客戶端再次發(fā)送確認包(ACK)檀训，SYN 標志位為0，ACK 標志位為1享言，并且把服務器發(fā)來 ACK 的序號字段+1峻凫，放在確定字段中發(fā)送給對方，并且在數(shù)據(jù)段放寫ISN的+1
發(fā)送完畢后览露，客戶端進入 ESTABLISHED 狀態(tài)荧琼，當服務器端接收到這個包時，也進入 ESTABLISHED 狀態(tài)差牛，TCP 握手結束命锄。
問題一：為什么需要三次握手呢？
在謝希仁著的《計算機網(wǎng)絡》里說偏化，『為了防止已失效的連接請求報文段突然又傳送到了服務端脐恩，因而產生錯誤』。怎么理解呢侦讨，我們假設一種情況驶冒，有一個建立連接的第一次握手的報文段因為滯留到網(wǎng)絡中過了較長時間才發(fā)送到服務端苟翻。這時服務器是要做ACK應答的，如果只有兩次握手就代表連接建立骗污，那服務器此時就要等待客戶端發(fā)送建立連接之后的數(shù)據(jù)崇猫。而這只是一個因滯留而廢棄的請求，是不是白白浪費了很多服務器資源身堡。
從另一個角度看這個問題邓尤，TCP是全雙工的通信模式拍鲤，需要保證兩端都已經(jīng)建立可靠有效的連接贴谎。在三次握手過程中，我們可以確認的狀態(tài)是：
第一次握手：服務器確認自己接收OK季稳，服務端確認客戶端發(fā)送OK擅这。
第二次握手：客戶端確認自己發(fā)送OK，客戶端確認自己接收OK景鼠，客戶端確認服務器發(fā)送OK仲翎，客戶端確認服務器接收OK。
第三次握手：服務器確認自己發(fā)送OK铛漓，服務器確認客戶端接收OK溯香。
只有握手三次才能達到全雙工的目的：確認自己和對方都能夠接收和發(fā)送消息。
TCP四次揮手
示意圖如下：
四次揮手表示要發(fā)送四個包浓恶，揮手的目的是斷開連接玫坛。
1、第一次揮手（FIN=1, seq=x）
假設客戶端想要關閉連接包晰，客戶端發(fā)送一個 FIN 標志位置為1的包湿镀，表示自己已經(jīng)沒有數(shù)據(jù)可以發(fā)送了，但是仍然可以接受數(shù)據(jù)伐憾。
發(fā)送完畢后勉痴，客戶端進入 FIN_WAIT_1 狀態(tài)。
2树肃、第二次揮手（ACK=1蒸矛，ACKnum=x+1）
服務器端確認客戶端的 FIN 包，發(fā)送一個確認包胸嘴，表明自己接受到了客戶端關閉連接的請求雏掠，但還沒有準備好關閉連接。
發(fā)送完畢后筛谚，服務器端進入 CLOSE_WAIT 狀態(tài)磁玉，客戶端接收到這個確認包之后，進入 FIN_WAIT_2 狀態(tài)驾讲，等待服務器端關閉連接蚊伞。
3席赂、第三次揮手（FIN=1，seq=y）
服務器端準備好關閉連接時时迫，向客戶端發(fā)送結束連接請求颅停，F(xiàn)IN 置為1。
發(fā)送完畢后掠拳，服務器端進入 LAST_ACK 狀態(tài)癞揉，等待來自客戶端的最后一個ACK。
4溺欧、第四次揮手（ACK=1喊熟，ACKnum=y+1）
客戶端接收到來自服務器端的關閉請求，發(fā)送一個確認包姐刁，并進入 TIME_WAIT狀態(tài)芥牌，等待可能出現(xiàn)的要求重傳的 ACK 包。
服務器端接收到這個確認包之后聂使，關閉連接壁拉，進入 CLOSED 狀態(tài)。
客戶端等待了某個固定時間（兩個最大段生命周期柏靶，2MSL弃理，2 Maximum Segment Lifetime）之后，沒有收到服務器端的 ACK 屎蜓，認為服務器端已經(jīng)正常關閉連接痘昌，于是自己也關閉連接，進入 CLOSED 狀態(tài)梆靖。
問題一：為什么揮手需要四次呢控汉？為什么不能將ACK和FIN報文一起發(fā)送？
當服務器收到FIN報文時返吻，很可能并不會立即關閉SOCKET姑子，所以只能先回復一個ACK報文，告訴客戶端『你發(fā)的FIN我收到了』测僵。只有等到服務端所有的報文都發(fā)送完了街佑，才能發(fā)FIN報文，所以要將ACK和FIN分開發(fā)送捍靠，這就導致需要四次揮手沐旨。
問題二：為什么TIMED_WAIT之后要等2MSL才進入CLOSED狀態(tài)？
MSL是TCP報文的最大生命周期榨婆，因為TIME_WAIT持續(xù)在2MSL就可以保證在兩個傳輸方向上的尚未接收到或者遲到的報文段已經(jīng)消失磁携，同時也是在理論上保證最后一個報文可靠到達。假設最后一個ACK丟失良风，那么服務器會再重發(fā)一個FIN谊迄，這是雖然客戶端的進程不在了闷供，但是TCP連接還在，仍然可以重發(fā)LAST_ACK统诺。
HTTPS的流程
HTTPS = HTTP + TLS/SSL歪脏，它使用的端口默認為443，它的建立可以用下圖表示：
1粮呢、客戶端首次請求服務器婿失，告訴服務器自己支持的協(xié)議版本，支持的加密算法及壓縮算法啄寡，并生成一個隨機數(shù)（client random）告知服務器豪硅。
2、服務器確認雙方使用的加密方法这难，并返回給客戶端證書以及一個服務器生成的隨機數(shù)（server random）
3舟误、客戶端收到證書后葡秒，首先驗證證書的有效性姻乓，然后生成一個新的隨機數(shù)（premaster secret），并使用數(shù)字證書中的公鑰眯牧，加密這個隨機數(shù)蹋岩，發(fā)送給服務器。
4学少、服務器接收到加密后的隨機數(shù)后剪个，使用私鑰進行解密，獲取這個隨機數(shù)（premaster secret
5版确、服務器和客戶端根據(jù)約定的加密方法扣囊，使用前面的三個隨機數(shù)（client random, server random, premaster secret），生成『對話密鑰』（session key）绒疗，用來加密接下來的整個對話過程（對稱加密）侵歇。
有一篇由淺入深介紹HTTPS的文章可以閱讀一下：看圖學HTTPS
問題一：為什么握手過程需要三個隨機數(shù)，而且安全性只取決于第三個隨機數(shù)吓蘑？
前兩個隨機數(shù)是明文傳輸惕虑，存在被攔截的風險，第三個隨機數(shù)是通過證書公鑰加密的磨镶，只有它是經(jīng)過加密的溃蔫，所以它保證了整個流程的安全性。前兩個隨機數(shù)的目的是為了保證最終對話密鑰的『更加隨機性』琳猫。
問題二：Charles如何實現(xiàn)HTTPS的攔截伟叛？
Charles要實現(xiàn)對https的攔截，需要在客戶端安裝Charles的證書并信任它脐嫂，然后Charles扮演中間人统刮，在客戶端面前充當服務器，在服務器面前充當客戶端网沾。
問題三：為什么有些HTTPS請求（例如微信）抓包結果仍是加密的癞蚕，如何實現(xiàn)的？
我在聊天過程中并沒有抓到會話的請求辉哥，在小程序啟動的時候到是抓到了一個加密內容桦山。我手動觸發(fā)該鏈接會下載一個加密文件，我猜測這種加密是內容層面的加密醋旦，它的解密是由客戶端完成的恒水，而不是在HTTPS建立過程完成的。
另外在研究這個問題的過程中饲齐，又發(fā)現(xiàn)了一些有趣的問題：
1钉凌、圖中所示的三個https請求分別對應三個不同類型的圖標，它們分別代表什么意思呢捂人？
2御雕、第三個請求https://mtalk.google.com:5228圖標和請求內容都加了鎖，這個加鎖是在https之上又加了一層鎖嗎滥搭？
這些問題暫時沒有確切的答案酸纲，希望了解的小伙伴告知一下哈。
DNS解析流程
DNS（Domain name system）域名系統(tǒng)瑟匆。DNS是因特網(wǎng)上作為域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使用戶通過域名訪問到對應的服務器（IP地址）愁溜。具體的解析流程是這樣的：
1疾嗅、瀏覽器中輸入想要訪問的網(wǎng)站域名冕象，操作系統(tǒng)會檢查本地hosts文件是否有這個網(wǎng)址的映射關系代承，如果有就調用這個IP地址映射，完成域名解析交惯。沒有的話就走第二步次泽。
2、客戶端回向本地DNS服務器發(fā)起查詢席爽，如果本地DNS服務器收到請求意荤，并可以在本地配置區(qū)域資源中查到該域名，就將對應結果返回為給客戶端只锻。如果沒有就走第三步玖像。
3、根據(jù)本地DNS服務器的設置，采用遞歸或者迭代查詢捐寥，直至解析完成笤昨。
其中遞歸查詢和迭代查詢可以用如下兩圖表示。
遞歸查詢
如圖所示握恳，遞歸查詢是由DNS服務器一級一級查詢傳遞的瞒窒。
迭代查詢
如果所示，迭代查詢是找到指定DNS服務器乡洼，由客戶端發(fā)起查詢崇裁。
DNS劫持
DNS劫持發(fā)生在DNS服務器上，當客戶端請求解析域名時將其導向錯誤的服務器（IP）地址束昵。
常見的解決辦法是使用自己的解析服務器或者是將域名以IP地址的方式發(fā)出去以繞過DNS解析拔稳。
Cookie和Session的區(qū)別
HTTP 是無狀態(tài)協(xié)議，說明它不能以狀態(tài)來區(qū)分和管理請求和響應锹雏。也就是說巴比，服務器單從網(wǎng)絡連接上無從知道客戶身份。
可是怎么辦呢礁遵？就給客戶端們頒發(fā)一個通行證吧轻绞，每人一個，無論誰訪問都必須攜帶自己通行證榛丢。這樣服務器就能從通行證上確認客戶身份了铲球。這就是Cookie的工作原理。
Cookie：Cookie是客戶端保存用戶信息的一種機制晰赞，用來記錄用戶的一些信息，實際上Cookie是服務器在本地機器上存儲的一小段文本选侨，并隨著每次請求發(fā)送到服務器。Cookie技術通過請求和響應報文中寫入Cookie信息來控制客戶端的狀態(tài)戏挡。
Session：Session機制是一種服務器端的機制晨仑，服務器使用一種類似于散列表的結構來保存信息洪己。當有用戶請求創(chuàng)建一個session時，服務器會先檢查這個客戶端里是否已經(jīng)包含了一個Session標識（session id）逝钥，如果有就通過session id把session檢索出來艘款。如果沒有就創(chuàng)建一個對應此Session的session id。這個session id會在本次響應中返回給客戶端哗咆。
兩者有以下區(qū)別：
1晌柬、存儲位置：Cookie存放在客戶端上，Session數(shù)據(jù)存放在服務器上殿衰。
2闷祥、Session 的運行依賴 session id傲诵，而 session id 是存在 Cookie 中的，也就是說悟衩，如果瀏覽器禁用了 Cookie 座泳，同時 Session 也會失效
3幕与、安全性：Cookie存在瀏覽器中啦鸣，可能會被一些程序復制，篡改香拉；而Session存在服務器相對安全很多中狂。
4吃型、性能：Session會在一定時間內保存在服務器上，當訪問增多枉层，會對服務器造成一定的壓力鸟蜡。考慮到減輕服務器壓力跳座，應當使用Cookie
CDN是干什么用的
CDN（Content Delivery Network）泣矛，根本作用是將網(wǎng)站的內容發(fā)布到最接近用戶的網(wǎng)絡『邊緣』您朽，以提高用戶訪問速度。概括的來說：CDN = 鏡像（Mirror） + 緩存（Cache） + 整體負載均衡（GSLB）几颜。
目前CDN都以緩存網(wǎng)站中的靜態(tài)數(shù)據(jù)為主蛋哭，如CSS涮母、JS哈蝇、圖片和靜態(tài)網(wǎng)頁等數(shù)據(jù)。用戶在從主站服務器請求到動態(tài)內容后再從CDN上下載這些靜態(tài)數(shù)據(jù)，從而加速網(wǎng)頁數(shù)據(jù)內容的下載速度样勃，如淘寶有90%以上的數(shù)據(jù)都是由CDN來提供的峡眶。
CDN工作流程
一個用戶訪問某個靜態(tài)文件（如CSS），這個靜態(tài)文件的域名假如是www.baidu.com峭拘，而這個域名最終會被指向CDN全局中CDN負載均衡服務器鸡挠，再由這個負載均衡服務器來最終分配是哪個地方的訪問用戶，返回給離這個訪問用戶最近的CDN節(jié)點彭沼。之后用戶就直接去這個CDN節(jié)點訪問這個靜態(tài)文件了姓惑，如果這個節(jié)點中請求的文件不存在于毙，就會再回到源站去獲取這個文件辅搬，然后再返回給用戶。
參考：深入理解Http請求烂翰、DNS劫持與解析
Socket的作用
socket位于應用層和傳輸層之間：
它的作用是為了應用層能夠更方便的將數(shù)據(jù)經(jīng)由傳輸層來傳輸甘耿。所以它的本質就是對TCP/IP的封裝佳恬，然后應用程序直接調用socket API即可進行通信毁葱。上文中說的三次握手和四次揮手即是通過socket完成的倾剿。
我們可以從iOS中網(wǎng)絡庫分層找到BSD Sockets，它是位于CFNetwork之下前痘。在CFNetwork中還有一個CFSocket芹缔，推測是對BSD Sockets的封裝瓶盛。
WebRTC是干什么用的
WebRTC是一個可以用在視頻聊天，音頻聊天或P2P文件分享等Web App中的 API蚜点。借助WebRTC吵取，你可以在基于開放標準的應用程序中添加實時通信功能。它支持在同級之間發(fā)送視頻脯倒，語音和通用數(shù)據(jù)藻丢，從而使開發(fā)人員能夠構建功能強大的語音和視頻通信解決方案摄乒。該技術可在所有現(xiàn)代瀏覽器以及所有主要平臺的本機客戶端上使用馍佑。WebRTC項目是開源的，并得到Apple茵臭，Google旦委，Microsoft和Mozilla等的支持雏亚。
如果某一請求只在某一地特定時刻失敗率較高，會有哪些原因
這個是某公司二面時的問題查辩，是一個開放性問題宜肉，我總結了以下幾點可能：
1翎碑、該時刻請求量過大
2日杈、該地的網(wǎng)絡節(jié)點較不穩(wěn)定
3、用戶行為習慣酿炸，比如該時刻為上班高峰期涨冀，或者某個群體的特定習慣
如果有對網(wǎng)絡方面比較熟悉的小伙伴也可以補充鹿鳖。
