【iOS】架構師之路~ 網絡篇

網絡

OSI 七層模型？追問：Socket 在哪一層？WebSocket 有沒有用過？

互聯網協議按照功能不一樣分爲osi七層和tcp/ip五層或tcp/ip四層，以下圖：

套接字是工做在傳輸層和應用層之間的一個接口，將複雜的tcp/udp協議隱藏在了socket接口後面

並無用過，作如下了解：

WebSocket 是 HTML5 一種新的協議。它實現了瀏覽器與服務器全雙工通訊，能更好的節省服務器資源和帶寬並達到實時通信，它創建在 TCP 之上，同 HTTP 同樣經過 TCP 來傳輸數據，可是它和 HTTP 最大不一樣是：WebSocket 是一種雙向通訊協議.

iOS WebSocket長連接

你怎麼理解分層和協議？

A. 如何理解分層

分層的理由:

• 獨立性 經過分層，每一層值接受下一層提供的特定服務，而且負責爲上一層提供特定服務，上下層之間進行交互所遵循的約定叫「接口」，同一層之間的交互所遵循的約定叫作「協議」。每一層能夠獨立使用，及時系統中某些層次發生變化，也不會波及系統。
• 靈活性好 對於任何一層的改動，只要上下層接口不變，都不會形成系統的問題，有利於每一層功能的擴展和變更。
• 易於實現和維護 將大問題簡化爲小問題，大系統簡化爲小層次。好比將網絡的通訊過程劃分爲小一些、簡單一些的部件,所以有助於各個部件的開發、設計和故障排除。
• 能促進標準化工做 經過分層，定義在模型的每一層實現什麼功能,有利於鼓勵產業的標準化，同時容許多個供應商進行開發。

分層的原則：

• 各個層之間有清晰的邊界,便於理解;
• 每一個層實現特定的功能;
• 層次的劃分有利於國際標準協議的制定;
• 層的數目應該足夠多，以免各個層功能重複

B. 如何理解協議

協議其實是一種通訊雙方共同遵照的規範。好比我須要把性別和年齡傳遞給另一臺主機，那麼我能夠定義一個"A 協議"，協議規定數據的前 4 個字節表示性別，後四個字節表示年齡。這樣對方主機接收時就知道前 4 個字節是性別，而不會錯把它當成年齡來處理。

協議的規範和共同遵照，有利於各個分層之間的交流和處理，也有利於促進協議的標準化過程。

路由器和交換機的工做原理大概是什麼，他們分別用到什麼協議，位於哪一層

交換機:

二層交換機:

二層交換機是一種在數據鏈路層工做的網絡設備，通常要求支持802.1q（就是劃VLAN）、SNMP、限速、廣播風暴控制、ACL、組播這些常見的功能；它有多個端口，能夠鏈接不一樣的設備。交換機根據每一個幀中的目標 MAC 地址決定向哪一個端口發送數據，此時它須要參考「轉發表」 轉發表並不是手動設置，而是交換機自動學習獲得的。當某個設備向交換機發送幀時，交換機將幀的源 MAC 地址和接口對應起來，做爲一條記錄添加到轉發表中。 下圖描述了交換機自學過程的原理：

三層交換機

三層交換機具備路由器功能，工做在網絡層，在二層的基礎上支持如靜態路由、RIP(矢量路由選擇協議)、OSPF(鏈路狀態路由選擇協議)、BGP(邊界網關協議)、ISIS(分級的連接狀態路由協議)等路由協議，有時候會要求支持MPLS(多協議標籤交換)、GRE(通用路由封裝協議)、L2TP(工業標準的Internet隧道協議)、IPSec(Internet 協議安全性)等隧道協議。三層交換機上可以對分組報文根據IP地址進行轉發。

四到七層交換機

負責處理OSI模型中從傳輸層至應用層的數據。若是用TCP/IP分層模型來表述，4-7層交換機就是以傳輸層及其上面的應用層爲基礎，進行分析數據，並對其進行特定的處理。

例如：對於併發訪問量很是大的一個企業級Web站點，使用一臺服務器不足以知足前端的訪問須要，這時一般會經過多臺服務器來分擔，這些服務器前端訪問的入口地址一般只有一個（企業爲了使用者的方便，只會向最終的用戶開放一個統一的訪問URL）。爲了能經過同一個URL將前端訪問分發到後臺多個服務器上，能夠在這些服務器的前端加一個負載均衡器。這種負載均衡器就是4-7層交換機的一種。

此外，實際通訊當中，人們但願在網絡比較擁堵的時候，優先處理像語音這類對及時性要求較高的通訊請求，放緩處理像郵件或數據轉發等稍有延遲也並沒有大礙的通訊請求，這種處理被稱爲寬帶控制，也是4-7層交換機的重要功能，還有其餘不少功能，例如廣域網加速器，特殊應用訪問加速以及防火牆等。

路由器

路由器工做在網絡層，完成經過路由控制將分組數據發送到目標地址的功能。支持如靜態路由、RIP(矢量路由選擇協議)、OSPF(鏈路狀態路由選擇協議)、BGP(邊界網關協議)、EGP(外部網關協議)、ISIS(分級的連接狀態路由協議)等路由協議。 路由器中保存着路由控制表，它在路由控制表中查找目標IP地址對應的下一個路由器地址。下圖描述了這一過程：

主機A的地址是10.1.1.30,要把數據發往地址爲10.1.2.10的主機。在主機A的路由表中，保存了兩個字段，因爲目標地址10.1.2.10與10.1.1.0/24段不匹配，因此它被髮往默認路由10.1.1.1也就是圖中路由器1的左側網卡的IP地址。 路由器1繼續在它本身的路由控制表中查找目標地址10.1.2.10，它發現目標地址屬於10.1.2.0/24這一段，所以將數據轉發至下一個路由器10.1.0.2，也就是路由器2的左側網卡的地址。 路由器2在本身的路由控制表中查找目標地址10.1.2.10，根據表中記錄將數據發往10.1.2.1接口，也就是本身的右側網卡的IP地址。主機B檢查目標IP地址和本身相同，因而接收數據。

[網絡面試問題]](www.jianshu.com/p/5553ada4a…)

簡介 TCP 和 UDP 區別，他們位於哪一層？

TCP 和 UDP 位於OSI 七層模型的第四層：傳輸層，區別以下：

一、鏈接性:
	 TCP 面向鏈接（如打電話要先撥號創建鏈接）;
	 UDP 是面向無鏈接的，即發送數據以前不須要創建鏈接
二、可靠性：
   TCP 提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達; 
	 UDP盡最大努力交付，即不保證可靠交付
三、傳輸內容：
	 TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流;
	 UDP是面向報文的，UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）
四、服務性質：
	 TCP鏈接只能是點到點的;
	 UDP支持一對一，一對多，多對一和多對多的交互通訊
五、開銷：
	 TCP首部開銷20字節;
	 UDP的首部開銷小，只有8個字節
六、信道
	 TCP的邏輯通訊信道是全雙工的可靠信道
	 UDP則是不可靠信道
複製代碼

描述TCP 協議三次握手，四次釋放的過程？

TCP 三次握手

• 第一次握手: 客戶端將標誌位SYN置爲1，隨機產生一個序列值seq = x，並將該數據包發送給服務端,客戶端進入SYN_SENT狀態，等待服務端確認。

• 第二次握手: 服務端·收到數據包後由標誌位SYN=1，知道客戶端請求創建鏈接，服務端將標誌位SYN和ACK都置爲1，ack = x + 1，隨機產生一個值seq = y, 並將該數據包發送給客戶端以確認鏈接請求，服務端進入SYN_RCVD狀態。

• 第三次握手:

  客戶端收到確認後，檢查ack是否爲x+1，ACK是否爲1，若是正確將標誌位ACK置爲1，ack = y + 1, 並將該數據包發送給服務端,服務端檢查ack是否爲y+1，ACK是否爲1，若是都正確則鏈接創建成功，客戶端和服務端進入ESTABLISHED狀態，完成三次握手，隨後客戶端與服務端之間開始進行數據傳輸。

TCP 四次揮手

• 第一次揮手: 客戶端發出鏈接釋放報文，而且中止發送數據。將釋放數據報文首部的FIN置爲1，序列號seq 置爲u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
• 第二次揮手: 服務端收到報文後，檢查到首部的FIN爲1，知道客戶端請求釋放鏈接，服務端發出確認報文，並將報文首部的ACK置爲1，ack置爲u + 1,而且帶上本身的序列號v,此時服務端進入CLOSE-WAIT(關閉等待狀態)。客戶端收到服務端的確認報文後，檢查ACK是否爲1，ack是否爲u+1,若是都正確，客戶端進入FIN-WAIT-2(終止等待2)狀態。等待服務端發送鏈接釋放報文。
• 第三次揮手: 服務端將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1,ack = u+1,序列號爲seq = w(由於在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w)，此時服務端進入LASK-ACK(最後確認)狀態，等待客戶端確認。
• 第四次揮手: 客戶端接收服務器的報文後，檢查FIN爲1，知道服務端請求釋放鏈接，發出確認報文，ACK = 1， ack = w + 1, seq = u + 1, 此時客戶端進入TIME-WAIT(時間等待)狀態。注意此時TCP鏈接尚未釋放，必須通過2∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。服務端只要收到客戶端發出的確認報文，檢查ACK是否爲1，ack 是否爲 w + 1, 若是都正確，當即進入CLOSE狀態。

TCP 三次握手過程？

結合TCP報文結構來看會比較清晰：

一、TCP服務器進程先建立傳輸控制塊TCB，時刻準備接受客戶進程的鏈接請求，此時服務器就進入了LISTEN（監聽）狀態；

二、TCP客戶進程也是先建立傳輸控制塊TCB，而後向服務器發出鏈接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但須要消耗掉一個序號。

三、TCP服務器收到請求報文後，若是贊成鏈接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要爲本身初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，可是一樣要消耗一個序號。

四、TCP客戶進程收到確認後，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，本身的序列號seq=x+1，此時，TCP鏈接創建，客戶端進入ESTABLISHED（已創建鏈接）狀態。TCP規定，ACK報文段能夠攜帶數據，可是若是不攜帶數據則不消耗序號。

五、當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就能夠開始通訊了。

參考：

[網絡相關面試題](www.javazhiyin.com/35813.html)

TCP 四次揮手過程？

一、客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。

二、服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。

三、客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。

四、服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。

五、客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。

六、服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

參考：

網絡相關面試題

如何改進TCP

採起一塊確認的機制

UDP是全雙工嗎？

所謂全雙工，半雙工，單工是指面向鏈接時纔有的說法，若是不是面向鏈接的，沒有一個肯定的鏈接的話，怎麼會出現半雙工這種只准一個來或者一個去的說法呢？ UDP支持一對一，一對多，多對一和多對多的交互通訊。若是必定要涉及到全雙工的話，大概理解爲不只提供全雙工，甚至提供全多工服務，只是UDP是不可靠的服務而已。

爲何要等待2MSL？

MSL（Maximum Segment Lifetime），TCP容許不一樣的實現能夠設置不一樣的MSL值。

1、保證客戶端發送的最後一個ACK報文可以到達服務器
		由於這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端尚未給我回應，應該是我發送的請求斷開報文它沒有收到，因而服務器又會從新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，而且會重啓2MSL計時器。
2、防止相似與「三次握手」中提到了的「已經失效的鏈接請求報文段」出如今本鏈接中。
  	客戶端發送完最後一個確認報文後，在這個2MSL時間中，就能夠使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣新的鏈接中不會出現舊鏈接的請求報文。

複製代碼

TCP/IP，你必知必會的十個問題

網絡相關面試題

爲何創建鏈接時是三次握手，兩次行不行？若是第三次握手失敗了怎麼處理

A. 爲何是三次握手:

• 爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。
• 由於在網絡請求中，咱們應該時刻記住：「網絡是不可靠的，數據包是可能丟失的」。
• 假設沒有第三次確認，客戶端向服務端發送了SYN，請求創建鏈接。因爲延遲，服務端沒有及時收到這個包。因而客戶端從新發送一個 SYN包。回憶一下介紹 TCP 首部時提到的序列號，這兩個包的序列號顯然是相同的。
• 假設服務端接收到了第二個 SYN 包，創建了通訊，一段時間後通訊結束，鏈接被關閉。這時候最初被髮送的 SYN 包剛剛抵達服務端，服務端又會發送一次 ACK確認。因爲兩次握手就創建了鏈接，此時的服務端就會創建一個新的鏈接，然而客戶端以爲本身並無請求創建鏈接，因此就不會向服務端發送數據。從而致使服務端創建了一個空的鏈接，白白浪費資源。
• 在三次握手的狀況下，服務端直到收到客戶端的應答後纔會創建鏈接。所以在上述狀況下，客戶端會接受到一個相同的ACK 包，這時候它會拋棄這個數據包，不會和服務端進行第三次握手，所以避免了服務端創建空的鏈接。

B. 第三次握手失敗了怎麼處理

• 按照 TCP 協議處理丟包的通常方法，服務端會從新向客戶端發送數據包，直至收到ACK 確認爲止。但實際上這種作法有可能遭到SYN 泛洪攻擊。所謂的泛洪攻擊，是指發送方僞造多個 IP 地址，模擬三次握手的過程。當服務器返回 ACK 後，攻擊方故意不確認，從而使得服務器不斷重發 ACK。因爲服務器長時間處於半鏈接狀態，最後消耗過多的CPU和內存資源致使死機。
• 正確處理方法是服務端發送RST 報文，進入 CLOSE狀態。這個 RST 數據包的 TCP 首部中，控制位中的 RST 位被設置爲1。這表示鏈接信息所有被初始化，原有的 TCP通訊不能繼續進行。客戶端若是還想從新創建TCP 鏈接，就必須從新開始第一次握手。

關閉鏈接時，第四次握手失敗怎麼處理？

實際上，在第三步中，客戶端收到FIN 包時，它會設置一個計時器，等待至關長的一段時間。若是客戶端返回的ACK 丟失，那麼服務端還會重發FIN並重置計時器。假設在計時器失效前服務器重發的 FIN 包沒有到達客戶端，客戶端就會進入 CLOSE狀態，從而致使服務端永遠沒法收到 ACK 確認，也就沒法關閉鏈接。

示意圖以下：

爲何TCP握手是三次，揮手倒是四次？（假設客戶端主動，服務器端被動）

在TCP三次握手中，服務器端的SYN和ACK是放在一個TCP報文段中向客戶端發送的，而在斷開鏈接的過程當中，服務器端向客戶端發送的ACK和FIN是是分別在兩個不一樣的TCP報文段中。這是由於在服務器端接收到客戶端的FIN後，服務器端可能還有數據要傳輸，因此先發送ACK，服務器端把數據發完以後就能夠發送FIN斷開鏈接了。

爲什須要三次握手？

《計算機網絡》第四版中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤」

書中的例子是這樣的，「已失效的鏈接請求報文段」的產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。

假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。」。主要目的防止server端一直等待，浪費資源。

參考：

從輸入URL到頁面展現，到底發生了什麼

TCP如何保證可靠傳輸

○ 數據包校驗
○ 超時重傳機制
○ 應答機制
○ 對失序數據包重排序
○ TCP還能提供流量控制
複製代碼

TCP 協議是如何進行流量控制，擁塞控制的？

A. 如何進行流量控制:

• 流量控制以動態調整發送空間大小(滑動窗口)的形式來反映接收端接收消息的能力，反饋給發送端以調整發送速度，避免發送速度過快致使的丟包或者過慢下降總體性能。
• 這裏採用滑動窗口機制，一是不用每次發送完成都須要等待收到確認消息才能繼續發送，二是參考接收端的接收能力，限制發送數據段大小，避免丟失現象。

B. 如何進行擁塞控制：

• 鏈接創建的初期，若是窗口比較大，發送方可能會忽然發送大量數據，致使網絡癱瘓。所以，在通訊一開始時，TCP 會經過慢啓動算法得出窗口的大小，對發送數據量進行控制。

流量控制是由發送方和接收方共同控制的。剛剛咱們介紹了接收方會把本身可以承受的最大窗口長度寫在TCP 首部中，實際上在發送方這裏，也存在流量控制，它叫擁塞窗口。TCP 協議中的窗口是指發送方窗口和接收方窗口的較小值。 慢啓動過程以下：

• 通訊開始時，發送方的擁塞窗口大小爲1。每收到一個 ACK確認後，擁塞窗口翻倍。
• 因爲指數級增加很是快，很快地，就會出現確認包超時。(超時是由於數據量大致使網絡擁塞)
• 此時設置一個「慢啓動閾值」，它的值是當前擁塞窗口大小的一半。
• 同時將擁塞窗口大小設置爲1，從新進入慢啓動過程。
• 因爲如今「慢啓動閾值」已經存在，當擁塞窗口大小達到閾值時，再也不翻倍，而是線性增長。
• 隨着窗口大小不斷增長，可能收到三次重複確認應答，進入「快速重發」階段。 (快速重發: 當發送端連續收到三個重複的ack時，表示該數據段已經丟失，須要重發。當收到三個表示同一個數據段的ack時，不須要等待計時器超時，即從新發送數據段（當時這三個ack要在超時以前到達發送端），由於可以收到接收端的ack確認信息，因此數據段只是單純的丟失，而不是由於網絡擁塞致使，)
• 這時候，TCP 將「慢啓動閾值」設置爲當前擁塞窗口大小的一半，再將擁塞窗口大小設置成閾值大小（也有說加 3）。
• 擁塞窗口又會線性增長，直至下一次出現三次重複確認應答或超時。

以上過程能夠用下圖歸納：

常見的 HTTP 狀態碼？

**1xx ：信息性狀態碼 ** 表示服務器已接收了客戶端請求，客戶端能夠繼續發送請求

• 100 Continue 初始的請求已經接受，客戶應當繼續發送請求的其他部分
• 101 Switching Protocols 服務器將聽從客戶的請求轉換到另一種協議

2xx ：成功狀態碼 表示服務器已成功接收到請求並進行處理

• 200 OK 表示客戶端請求成功
• 204 No Content 成功，但不返回任何實體的主體部分
• 206 Partial Content 成功執行了一個範圍（Range）請求

3xx ：重定向狀態碼 表示服務器要求客戶端重定向

• 301 Moved Permanently 永久性重定向，響應報文的Location首部應該有該資源的新URL
• 302 Found 臨時性重定向，響應報文的Location首部給出的URL用來臨時定位資源
• 303 See Other 請求的資源存在着另外一個URI，客戶端應使用GET方法定向獲取請求的資源
• 304 Not Modified 服務器內容沒有更新，能夠直接讀取瀏覽器緩存
• 307 Temporary Redirect 臨時重定向。與302 Found含義同樣。302禁止POST變換爲GET，但實際使用時並不必定，307則更多瀏覽器可能會遵循這一標準，但也依賴於瀏覽器具體實現

4xx ：客戶端錯誤狀態碼 表示客戶端的請求有非法內容

• 400 Bad Request 表示客戶端請求有語法錯誤，不能被服務器所理解
• 401 表示請求未經受權，該狀態代碼必須與 WWW-Authenticate 報頭域一塊兒使用
• 403 表示服務器收到請求，可是拒絕提供服務，一般會在響應正文中給出不提供服務的緣由
• 404 Not Found 請求的資源不存在，例如，輸入了錯誤的URL

5xx ：服務器錯誤狀態碼 表示服務器未能正常處理客戶端的請求而出現意外錯誤

• 500 Internel Server Error 表示服務器發生不可預期的錯誤，致使沒法完成客戶端的請求
• 503 表示服務器當前不可以處理客戶端的請求，在一段時間以後，服務器可能會恢復正常

參考：

常見的HTTP狀態碼（HTTP Status Code）說明

從輸入URL到頁面展現，你想知道些什麼？

從輸入URL到頁面展現，到底發生了什麼？

過程爲：

• URL 輸入
• DNS 解析
• TCP 鏈接
• 發送 HTTP請求
• 服務器處理請求
• 服務器響應請求
• 瀏覽器解析，渲染頁面
• 連接結束

參考

從輸入URL到頁面展現，到底發生了什麼

從輸入URL到頁面展現，你想知道些什麼？

另外一個答案：

• 查詢DNS，獲取域名對應的IP地址
    ○ 瀏覽器搜索自身的DNS緩存 
    ○ 搜索操做系統的DNS緩存
    ○ 讀取本地的HOST文件
    ○ 發起一個DNS的系統調用
 • 寬帶運營服務器查看自己緩存
 • 運營商服務器發起一個迭代DNS解析請求
 • 瀏覽器得到域名對應的IP地址後，發起HTTP三次握手
 • TCP/IP鏈接創建起來後，瀏覽器就能夠向服務器發送HTTP請求了
 • 服務器接受到這個請求，根據路徑參數，通過後端的一些處理生成HTML頁面代碼返回給瀏覽器
 • 瀏覽器拿到完整的HTML頁面代碼開始解析和渲染，若是遇到引用的外部JS，CSS,圖片等靜態資源，它們一樣也是一個個的HTTP請求，都須要通過上面的步驟
 • 瀏覽器根據拿到的資源對頁面進行渲染，最終把一個完整的頁面呈現給用戶
複製代碼

網絡相關面試題

對 Cookie 的認識 ？

HTTP 協議對於發送的請求和響應不作持久化處理。這時候引入了 Cookie 技術用於狀態管理。Cookie 對用與登陸的狀態管理，沒有 Cookie 這個技術的話，由於 HTTP 不保存狀態，每次打開新網頁都必須再次登陸。

Cookie 會根據響應報文中的 Set-Cookie 字段來通知客戶端自動保存 Cookie。下次請求時會自動發送 Cookie，服務器會比對數據獲得狀態結果。

Session 和 Cookie 的做用和工做原理？

Cookie（複數形態：Cookies）：是指某些網站爲了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據（一般通過加密）。

做用：由於HTTP協議是無狀態的，即服務器不知道用戶上一次作了什麼，這嚴重阻礙了交互式Web應用程序的實現。在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅乾和兩飲料。最後結賬時，因爲HTTP的無狀態性，不經過額外的手段，服務器並不知道用戶到底買了什麼。爲了作到這點，就須要使用到Cookie了。服務器能夠設置或讀取Cookies中包含信息，藉此維護用戶跟服務器會話中的狀態。

Cookie的根本做用就是在客戶端存儲用戶訪問網站的一些信息。典型的應用有

一、記住密碼，下次自動登陸

二、購物車功能

三、記錄用戶瀏覽數據，進行商品（廣告）推薦

工做原理：

1.建立 Cookie

​ 當用戶第一次瀏覽某個使用Cookie的網站時，該網站的服務器就進行以下工做

​ 1.1 該用戶生成一個惟一的識別碼（Cookie id），建立一個Cookie對象

​ 1.2 默認狀況下它是一個會話級別的cookie，存儲在瀏覽器的內存中，用戶退出瀏覽器以後被刪除。若是網站但願瀏覽器將該Cookie存儲在磁盤上，則須要設置最大時效（maxAge），並給出一個以秒爲單位的時間（將最大時效設爲0則是命令瀏覽器刪除該Cookie）

​ 1.3 將Cookie放入到HTTP響應報頭，將Cookie插入到一個 Set-Cookie HTTP請求報頭中

​ 1.4 發送該HTTP響應報文

2.設置存儲 Cookie

​ 瀏覽器收到該響應報文以後，根據報文頭裏的Set-Cookied特殊的指示，生成相應的Cookie，保存在客戶端。該Cookie裏面記錄着用戶當前的信息。

3.發送Cookie

​ 當用戶再次訪問該網站時，瀏覽器首先檢查全部存儲的Cookies，若是某個存在該網站的Cookie（即該Cookie所聲明的做用範圍大於等於將要請求的資源），則把該cookie附在請求資源的HTTP請求頭上發送給服務器

4.讀取Cookie

​ 服務器接收到用戶的HTTP請求報文以後，從報文頭獲取到該用戶的Cookie，從裏面找到所須要的東西

Session:表明服務器與瀏覽器的一次會話過程，這個過程是連續的，也能夠時斷時續的。Session是一種服務器端的機制，Session 對象用來存儲特定用戶會話所需的信息

工做原理：建立session、使用session，具體看參考url

做用：Session的根本做用就是在服務端存儲用戶和服務器會話的一些信息

一、判斷用戶是否登陸

二、購物車功能

參考：

Cookie和Session的做用和工做原理

談對 5G技術的認識？

簡單說，5G就是第五代通訊技術，主要特色是波長爲毫米級，超寬帶，超高速度，超低延時。

5G若是要實現端到端的高速率，重點是突破無線這部分的瓶頸。

光速 = 波長 * 頻率

爲了實現更高效的傳輸速率必須使用更短的波，5G採用毫米波（1~10 mm）

電磁波的顯著特色：頻率越高，波長越短，越趨近於直線傳播（繞射和穿牆能力越差）。****頻率越高，在傳播介質中的衰減也越大。

因此，5G須要很是多的微基站。對人體是有益的，減少了輻射。

第一次有人把5G講的這麼簡單明瞭

若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲2小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。

網絡相關面試題

Http 和 Https的區別？

1. 安全性：
   http是HTTP協議運行在TCP之上。全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份。
   https是HTTP運行在SSL/TLS之上，SSL/TLS運行在TCP之上。全部傳輸的內容都通過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。此外客戶端能夠驗證服務器端的身份，若是配置了客戶 端驗證，服務器方也能夠驗證客戶端的身份。

2. 證書
   https協議須要到ca申請證書，通常免費證書不多，須要交費。

3. 傳輸協議
   http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議

4. 端口
   http和https使用的是徹底不一樣的鏈接方式用的端口也不同,前者是80,後者是443。
複製代碼

HTTPS 原理?

HTTPS實際上是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會經過TLS進行加密，因此傳輸的數據都是加密後的數據。

HTTPS 是 HTTP 創建在 SSL/TLS 安全協議上的。

在 iOS 中，客戶端本地會存放着 CA 證書，在HTTPS 請求時，會首先像服務器索要公鑰，得到公鑰後會使用本地 CA 證書驗證公鑰的正確性，而後經過正確的公鑰加密信息發送給服務器，服務器會使用私鑰解密信息。

HTTPS 相對於 HTTP 性能上差點，由於多了 SSL/TLS 的幾回握手和加密解密的運算處理，可是加密解密的運算處理已經能夠經過特有的硬件來加速處理。

1. 客戶端發起HTTPS請求
   這個沒什麼好說的，就是用戶在瀏覽器裏輸入一個https網址，而後鏈接到server的443端口。
   
2. 服務端的配置
   採用HTTPS協議的服務器必需要有一套數字證書，能夠本身製做，也能夠向組織申請。
   區別就是本身頒發的證書須要客戶端驗證經過，才能夠繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。
   這套證書其實就是一對公鑰和私鑰。若是對公鑰和私鑰不太理解，能夠想象成一把鑰匙和一個鎖頭，只是全世界只有你一我的有這把鑰匙，你能夠把鎖頭給別人，別人能夠用這個鎖把重要的東西鎖起來，而後發給你，由於只有你一我的有這把鑰匙，因此只有你才能看到被這把鎖鎖起來的東西。
   
3. 傳送證書
   這個證書其實就是公鑰，只是包含了不少信息，如證書的頒發機構，過時時間等等。
   
4. 客戶端解析證書
   這部分工做是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，好比頒發機構，過時時間等等，若是發現異常，則會彈出一個警告框，提示證書存在問題。
   若是證書沒有問題，那麼就生成一個隨即值。而後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，否則看不到被鎖住的內容。

5. 傳送加密信息
   這部分傳送的是用證書加密後的隨機值，目的就是讓服務端獲得這個隨機值，之後客戶端和服務端的通訊就能夠經過這個隨機值來進行加密解密了。

6. 服務段解密信息
   服務端用私鑰解密後，獲得了客戶端傳過來的隨機值(私鑰)，而後把內容經過該值進行對稱加密。
   所謂對稱加密就是，將信息和私鑰經過某種算法混合在一塊兒，這樣除非知道私鑰，否則沒法獲取內容，而正好客戶端和服務端都知道這個私鑰，因此只要加密算法夠彪悍，私鑰夠複雜，數據就夠安全。

7. 傳輸加密後的信息
   這部分信息是服務段用私鑰加密後的信息，能夠在客戶端被還原

8. 客戶端解密信息
   客戶端用以前生成的私鑰解密服務段傳過來的信息，因而獲取瞭解密後的內容。整個過程第三方即便監聽到了數據，也一籌莫展。
複製代碼

https工做原理

簡單粗暴系列之HTTPS原理

經典面試題21 - HTTPS 和 SSL證書原理

HTTP 請求中的 get 和 post 的區別?

1. GET使用URL或Cookie傳參，而POST將數據放在BODY中，這個是由於HTTP協議用法的約定。並不是它們的自己區別。
2. GET方式提交的數據有長度限制，則POST的數據則能夠很是大，這個是由於它們使用的操做系統和瀏覽器設置的不一樣引發的區別。也不是GET和POST自己的區別。
3. POST比GET安全，由於數據在地址欄上不可見，這個說法沒毛病，但依然不是GET和POST自己的區別。
4. 最大的區別主要是GET請求是冪等性的，POST請求不是

HTTP｜GET 和 POST 區別？網上多數答案都是錯的！

另外一個答案：

• GET 被強制服務器支持
• 瀏覽器對URL的長度有限制，因此GET請求不能代替POST請求發送大量數據
• GET請求發送數據更小
• GET請求是不安全的
• GET請求是冪等的
• POST請求不能被緩存
• POST請求相對GET請求是「安全」的

• 在如下狀況中，請使用 POST 請求:
  1. 沒法使用緩存文件(更新服務器上的文件或數據庫)
  2. 向服務器發送大量數據(POST 沒有數據量限制)
  3. 發送包含未知字符的用戶輸入時，POST 比 GET 更穩定也更可靠 
  4. post比Get安全性更高
複製代碼

網絡面試題

Session 和 Cookie 的區別?

HTTP 是一種無狀態的鏈接，客戶端每次讀取web 頁面時，服務器都會認爲這是一次新的會話。但有時候咱們又須要持久保持某些信息，好比登陸時的用戶名、密碼，用戶上一次鏈接時的信息等。這些信息就由 Cookie 和Session 保存。 這二者的根本性區別在於，cookie保存在客戶端上，而 session 則保存在服務器中。由此咱們還能夠拓展出如下結論：

• cookie 相對來講不安全，瀏覽器能夠分析本地的 cookie 進行 cookie 欺騙。
• session 能夠設置超時時間，超過這個時間後就失效，以避免長期佔用服務端內存。
• 單個cookie 的大小有限制（4 Kb），每一個站點的 cookie數量通常也有限制（20個）。
• 客戶端每次都會把 cookie發送到服務端，所以服務端能夠知道cookie，可是客戶端不知道 session。

當服務器接收到cookie 後，會根據cookie 中的 SessionID 來找到這個客戶的 session。若是沒有，則會生成一個新的 SessionID發送給客戶端。

談談你對 HTTP 1.1，2.0 和 HTTPS 的理解?

1、HTTP

HTTP（超文本傳輸協議，HyperText Transfer Protocol)是應用層的協議，目前在互聯網中應用普遍。

它被設計用於Web瀏覽器和Web服務器之間的通訊，但它也能夠用於其餘目的。 HTTP遵循經典的客戶端-服務端模型，客戶端打開一個鏈接以發出請求，而後等待它收到服務器端響應。HTTP是 無狀態協議，意味着服務器不會在兩個請求之間保留任何數據（狀態）。

2、HTTP1.0 ——構建可擴展性

HTTP 1.0規定瀏覽器與服務器只保持短暫的鏈接，瀏覽器的每次請求都須要與服務器創建一個TCP鏈接，服務器完成請求處理後當即斷開TCP鏈接，服務器不跟蹤每一個客戶也不記錄過去的請求。

3、HTTP1.1 ——標準化的協議

HTTP/1.0的多種不一樣的實現運用起來有些混亂，HTTP1.1是第一個標準化版本，重點關注的是校訂HTTP1.0設計中的結構性缺陷：

• 鏈接能夠重複使用，節省了屢次打開它的時間，以顯示嵌入到單個原始文檔中的資源。
• 增長流水線操做，容許在第一個應答被徹底發送以前發送第二個請求，以下降通訊的延遲。
• 支持響應分塊。
• 引入額外的緩存控制機制。
• 引入內容協商，包括語言，編碼，或類型，並容許客戶端和服務器約定以最適當的內容進行交換。
• 添加Host 頭，可以使不一樣的域名配置在同一個IP地址的服務器。
• 安全性獲得了提升

在http1.1中，client和server都是默認對方支持長連接的， 若是不但願使用長連接，則須要在header中指明connection:close；

4、HTTP2.0——爲了更優異的表現

HTTP/2.0在HTTP/1.1有幾處基本的不一樣:

• HTTP2是二進制協議而不是文本協議。再也不可讀和無障礙的手動建立，改善的優化技術如今可被實施。
• 這是一個複用協議。並行的請求能在同一個連接中處理，移除了HTTP/1.x中順序和阻塞的約束。
• 壓縮了headers。由於headers在一系列請求中經常是類似的，其移除了重複和傳輸重複數據的成本。
• 其容許服務器在客戶端緩存中填充數據，經過一個叫服務器推送的機制來提早請求。

5、HTTPS

咱們知道HTTP 協議直接使用了TCP 協議進行數據傳輸。因爲數據沒有加密，都是直接明文傳輸，因此存在如下三個風險：

• 竊聽風險：第三方節點能夠獲知通訊內容。
• 篡改風險：第三方節點能夠修改通訊內容。
• 冒充風險：第三方節點能夠冒充他人身份參與通訊。

好比你在手機上打開應用內的網頁時，有時會看到網頁底部彈出了廣告，這實際上就說明你的HTTP 內容被竊聽、並篡改了。 HTTPS 協議旨在解決以上三個風險，所以它能夠：

• 保證全部信息加密傳輸，沒法被第三方竊取。
• 爲信息添加校驗機制，若是被第三方惡意破壞，能夠檢測出來。
• 配備身份證書，防止第三方假裝參與通訊。

HTTPS 的結構如圖所示：

可見它僅僅是在 HTTP 和TCP 之間新增了一個TLS/SSL 加密層，這也印證了一句名言：「一切計算機問題均可以經過添加中間層解決」。 使用HTTPS 時，服務端會將本身的證書發送給客戶端，其中包含了服務端的公鑰。基於非對稱加密的傳輸過程以下：

• 客戶端使用公鑰將信息加密，密文發送給服務端
• 服務端用本身的私鑰解密，再將返回數據用私鑰加密發回客戶端
• 客戶端用公鑰解密

這裏的證書是服務器證實本身身份的工具，它由權威的證書頒發機構（CA）發給申請者。若是證書是虛假的，或者是本身給本身頒發的證書，服務器就會不承認這個證書併發出警告：

總結一下 HTTPS 協議是如何避免前文所說的三大風險的：

• 先用非對稱加密傳輸密碼，而後用這個密碼對稱加密數據，使得第三方沒法得到通訊內容
• 發送方將數據的哈希結果寫到數據中，接收方解密後對比數據的哈希結果，若是不一致則說明被修改。因爲傳輸數據加密，第三方沒法修改哈希結果。
• 由權威機構頒發證書，再加上證書校驗機制，避免第三方假裝參與通訊.

網絡層面試題

爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？

這是由於服務端在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。而關閉鏈接時，當收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，己方也未必所有數據都發送給對方了，因此己方能夠當即close，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送。

參考：

從輸入URL到頁面展現，到底發生了什麼