iOS 面試第八節 網絡

1.網絡七層協議

• 應用層：
  1.用戶接口、應用程序；
  2.Application典型設備：網關；
  3.典型協議、標準和應用：TELNET、FTP、HTTP

• 表示層：
  1.數據表示、壓縮和加密presentation
  2.典型設備：網關
  3.典型協議、標準和應用：ASCLL、PICT、TIFF、JPEG|MPEG
  4.表示層相當於一個東西的表示，表示的一些協議，比如圖片、聲音和視頻MPEG。

• 會話層：
  1.會話的建立和結束；
  2.典型設備：網關；
  3.典型協議、標準和應用：RPC、SQL、NFS、X WINDOWS、ASP

• 傳輸層：
  1.主要功能：端到端控制Transport；
  2.典型設備：網關；
  3.典型協議、標準和應用：TCP、UDP、SPX

• 網絡層：
  1.主要功能：路由、尋址Network；
  2.典型設備：路由器；
  3.典型協議、標準和應用：IP、IPX、APPLETALK、ICMP；

• 數據鏈路層：
  1.主要功能：保證無差錯的疏忽鏈路的data link；
  2.典型設備：交換機、網橋、網卡；
  3.典型協議、標準和應用：802.2、802.3ATM、HDLC、FRAME RELAY；

• 物理層：
  1.主要功能：傳輸比特流Physical；
  2.典型設備：集線器、中繼器
  3.典型協議、標準和應用：V.35、EIA/TIA-232.

2.Http 和 Https 的區別？Https爲什麼更加安全？

• 區別：
  1.HTTPS 需要向機構申請 CA 證書，極少免費。
  2.HTTP 屬於明文傳輸，HTTPS基於 SSL 進行加密傳輸。
  3.HTTP 端口號爲 80，HTTPS 端口號爲 443 。
  4.HTTPS 是加密傳輸，有身份驗證的環節，更加安全。

• 安全：
  SSL(安全套接層) TLS(傳輸層安全)
  以上兩者在傳輸層之上，對網絡連接進行加密處理，保障數據的完整性，更加的安全。

3.HTTPS的連接建立流程

HTTPS爲了兼顧安全與效率，同時使用了對稱加密和非對稱加密。在傳輸的過程中會涉及到三個密鑰：

• 服務器端的公鑰和私鑰，用來進行非對稱加密
• 客戶端生成的隨機密鑰，用來進行對稱加密

如上圖，HTTPS連接過程大致可分爲八步:

1. 客戶端訪問HTTPS連接。發自己支持協議、加密算法給C端。
   客戶端會把安全協議版本號、客戶端支持的加密算法列表、隨機數C發給服務端。

2. 服務端返回證書、公鑰給客戶端
   服務端接收密鑰算法配件後，會和自己支持的加密算法列表進行比對，如果不符合，則斷開連接。否則，服務端會在該算法列表中，選擇一種對稱算法（如AES）、一種公鑰算法（如具有特定祕鑰長度的RSA）和一種MAC算法發給客戶端。
   服務器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，服務器端保存着私鑰，不能將其泄露，公鑰可以發送給任何人。
   在發送加密算法的同時還會把數字證書和隨機數S發送給客戶端

3. 客戶端驗證server證書
   客戶端會對server證書進行檢查，驗證其合法性。

4. 客戶端組裝會話祕鑰
   如果證書合格，那麼客戶端會用服務器公鑰來生成一個前主祕鑰(Pre-Master Secret，PMS)，並通過該前主祕鑰和隨機數C、S來組裝成會話祕鑰

5. 客戶端將前主祕鑰加密發送給服務端
   是通過服務端的公鑰來對前主祕鑰進行非對稱加密，發送給服務端

6. 服務端通過私鑰解密得到前主祕鑰
   服務端接收到加密信息後，用私鑰解密得到主祕鑰。

7. 服務端組裝會話祕鑰
   服務端通過前主祕鑰和隨機數C、S來組裝會話祕鑰。
   至此，服務端和客戶端都已經知道了用於此次會話的主祕鑰。

8. 數據傳輸
   客戶端收到服務器發送來的密文，用客戶端密鑰對其進行對稱解密，得到服務器發送的數據。

同理，服務端收到客戶端發送來的密文，用服務端密鑰對其進行對稱解密，得到客戶端發送的數據。

4.charles如何抓到數據的

HTTPS抓包的原理還是挺簡單的，簡單來說，就是Charles作爲“中間人代理”，拿到了 服務器證書公鑰 和 HTTPS連接的對稱密鑰，前提是客戶端選擇信任並安裝Charles的CA證書，否則客戶端就會“報警”並中止連接。這樣看來，HTTPS還是很安全的。

5.HTTP TCP區別

兩者沒有什麼可比性。
HTTP是應用層的協議，以TCP協議爲基礎。
TCP是傳輸層協議，以IP協議爲基礎。
IP是網絡層協議。
可以這樣理解： IP協議作爲網絡中的“公路”，TCP協議是“公路”上面的“貨車”，而HTTP協議是用於打包“貨車”中的“貨物”的。

6.解釋一下 TCP 的三次握手 和 四次揮手

• 三次握手
  1.由客戶端向服務端發送 SYN 同步報文。
  2.當服務端收到 SYN 同步報文之後，會返回給客戶端 SYN 同步報文和 ACK 確認報文。
  3.客戶端會向服務端發送 ACK 確認報文，此時客戶端和服務端的連接正式建立。

• 建立連接
  1.這個時候客戶端就可以通過 Http 請求報文，向服務端發送請求
  2.服務端接收到客戶端的請求之後，向客戶端回覆 Http 響應報文。

• 四次揮手
  1.先由客戶端向服務端發送 FIN 結束報文。
  2.服務端會返回給客戶端 ACK 確認報文 。此時，由客戶端發起的斷開連接已經完成。
  3.服務端關閉客戶端的連接，給客戶端發 FIN 結束報文。
  4.客戶端會發 ACK 確認報文到服務端，至此，由服務端方向的斷開連接已經完成。

爲什麼揮手需要四次呢？
確保數據能夠完整傳輸。

當被動方收到主動方的FIN報文通知時，它僅僅表示主動方沒有數據再發送給被動方了。
但未必被動方所有的數據都完整的發送給了主動方，所以被動方不會馬上關閉SOCKET,它可能還需要發送一些數據給主動方後，
再發送FIN報文給主動方，告訴主動方同意關閉連接，所以這裏的ACK報文和FIN報文多數情況下都是分開發送的。

7.TCP 和 UDP的區別

• TCP：面向連接(三次握手，四次揮手)、傳輸可靠(保證數據正確性,保證數據順序)、用於傳輸大量數據(流模式)、速度慢，建立連接需要開銷較多(時間，系統資源)。

• UDP：面向非連接（沒有三次握手、也無四次揮手）、傳輸不可靠、用於傳輸少量數據(數據包模式)、速度快。
  怎麼理解TCP的面向連接和UDP的無連接

8.Http協議和Socket

創建 Socket 連接的時候，可以指定傳輸層協議，可以是 TCP 或者 UDP，當用 TCP 連接，該Socket就是個TCP連接，反之。

Socket 連接,至少需要一對套接字，分爲 clientSocket，serverSocket 連接分爲3個步驟:
(1) 服務器監聽:服務器並不定位具體客戶端的套接字，而是時刻處於監聽狀態；

(2) 客戶端請求:客戶端的套接字要描述它要連接的服務器的套接字，提供地址和端口號，然後向服務器套接字提出連接請求；

(3) 連接確認:當服務器套接字收到客戶端套接字發來的請求後，就響應客戶端套接字的請求,並建立一個新的線程,把服務器端的套接字的描述發給客戶端。一旦客戶端確認了此描述，就正式建立連接。而服務器套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求.

很多情況下，都是需要服務器端向客戶端主動推送數據，保持客戶端與服務端的實時同步。

若雙方是 Socket 連接，可以由服務器直接向客戶端發送數據。

若雙方是 HTTP 連接，則服務器需要等客戶端發送請求後，才能將數據回傳給客戶端。
因此，客戶端定時向服務器端發送請求，不僅可以保持在線，同時也詢問服務器是否有新數據，如果有就將數據傳給客戶端。

9.Cookie和Session

cookie

• 1.用戶與服務器的交互
  cookie主要是用來記錄用戶狀態，區分用戶，狀態保存在客戶端。cookie功能需要瀏覽器的支持。如果瀏覽器不支持cookie（如大部分手機中的瀏覽器）或者把cookie禁用了，cookie功能就會失效。
  
  a).首次訪問amazon時，客戶端發送一個HTTP請求到服務器端 。服務器端發送一個HTTP響應到客戶端，其中包含Set-Cookie頭部

b).客戶端發送一個HTTP請求到服務器端，其中包含Cookie頭部。服務器端發送一個HTTP響應到客戶端

c).隔段時間再去訪問時，客戶端會直接發包含Cookie頭部的HTTP請求。服務器端發送一個HTTP響應到客戶端

• 2.cookie的修改和刪除

在修改cookie的時候，只需要新cookie覆蓋舊cookie即可，在覆蓋的時候，由於Cookie具有不可跨域名性，注意name、path、domain需與原cookie一致

刪除cookie也一樣，設置cookie的過期時間expires爲過去的一個時間點，或者maxAge = 0(Cookie的有效期,單位爲秒)即可

• 3、cookie的安全

事實上，cookie的使用存在爭議，因爲它被認爲是對用戶隱私的一種侵害，而且cookie並不安全

HTTP協議不僅是無狀態的，而且是不安全的。使用HTTP協議的數據不經過任何加密就直接在網絡上傳播，有被截獲的可能。使用HTTP協議傳輸很機密的內容是一種隱患。

a).如果不希望Cookie在HTTP等非安全協議中傳輸，可以設置Cookie的secure屬性爲true。瀏覽器只會在HTTPS和SSL等安全協議中傳輸此類Cookie。

b).此外，secure屬性並不能對Cookie內容加密，因而不能保證絕對的安全性。如果需要高安全性，需要在程序中對Cookie內容加密、解密，以防泄密。

c).也可以設置cookie爲HttpOnly，如果在cookie中設置了HttpOnly屬性，那麼通過js腳本將無法讀取到cookie信息，這樣能有效的防止XSS（跨站腳本攻擊）攻擊

Session

• Session是服務器端使用的一種記錄客戶端狀態的機制，使用上比Cookie簡單一些，相應的也增加了服務器的存儲壓力。

• Session是另一種記錄客戶狀態的機制，不同的是Cookie保存在客戶端瀏覽器中，而Session保存在服務器上。 客戶端瀏覽器訪問服務器的時候，服務器把客戶端信息以某種形式記錄在服務器上。這就是Session。客戶端瀏覽器再次訪問時只需要從該Session中查找該客戶的狀態就可以了。
  

• 如圖：

當程序需要爲某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識（稱爲SessionId）

如果已包含則說明以前已經爲此客戶端創建過session，服務器就按照SessionId把這個session檢索出來，使用（檢索不到，會新建一個）

如果客戶端請求不包含SessionId，則爲此客戶端創建一個session並且生成一個與此session相關聯的SessionId，SessionId的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個SessionId將被在本次響應中返回給客戶端保存。

保存這個SessionId的方式可以採用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發送給服務器。但cookie可以被人爲的禁止，則必須有其他機制以便在cookie被禁止時仍然能夠把SessionId傳遞迴服務器。

Cookie 和Session 的區別：

• 1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
• 2、cookie相比session不是很安全，別人可以分析存放在本地的cookie並進行cookie欺騙,考慮到安全應當使用session。
• 3、session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能,考慮到減輕服務器性能方面，應當使用cookie。
• 4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。而session存儲在服務端，可以無限量存儲
• 5、所以：將登錄信息等重要信息存放爲session;其他信息如果需要保留，可以放在cookie中

10.DNS是什麼

因特網上的主機，可以使用多種方式標識，比如主機名或IP地址。一種標識方法就是用它的主機名（hostname），比如·www.baidu.com、www.google.com、gaia.cs.umass.edu等。這方式方便人們記憶和接受，但是這種長度不一、沒有規律的字符串路由器並不方便處理。還有一種方式，就是直接使用定長的、有着清晰層次結構的IP地址，路由器比較熱衷於這種方式。爲了折衷這兩種方式，我們需要一種能進行主機名到IP地址轉換的目錄服務。這就是域名系統（Domain Name System，DNS）的主要任務。

• DNS是：
  1、一個由分層的DNS服務器實現的分佈式數據庫
  2、一個使得主機能夠查詢分佈式數據庫的應用層協議

• DNS服務器通常是運行BIND軟件的UNIX機器，DNS協議運行在UDP上，使用53號端口

• DNS通常是由其他應用層協議所使用的，包括HTTP、SMTP等。其作用則是：將用戶提供的主機名解析爲IP地址

• DNS的一種簡單設計就是在因特網上只使用一個DNS服務器，該 服務器包含所有的映射。很明顯這種設計是有很大的問題的：
  單點故障：如果該DNS服務器崩潰，全世界的網絡隨之癱瘓
  通信容量：單個DNS服務器必須處理所有DNS查詢
  遠距離的集中式數據庫：單個DNS服務器必須面對所有用戶，距離過遠會有嚴重的時延。
  維護：該數據庫過於龐大，還需要對新添加的主機頻繁更新。

所以，DNS被設計成了一個分佈式、層次數據庫

11.DNS解析過程

以www.163.com爲例:

1. 客戶端打開瀏覽器，輸入一個域名。比如輸入www.163.com，這時，客戶端會發出一個DNS請求到本地DNS服務器。本地DNS服務器一般都是你的網絡接入服務器商提供，比如中國電信，中國移動。
2. 查詢www.163.com的DNS請求到達本地DNS服務器之後，本地DNS服務器會首先查詢它的緩存記錄，如果緩存中有此條記錄，就可以直接返回結果。如果沒有，本地DNS服務器還要向DNS根服務器進行查詢。
3. 根DNS服務器沒有記錄具體的域名和IP地址的對應關係，而是告訴本地DNS服務器，你可以到域服務器上去繼續查詢，並給出域服務器的地址。
4. 本地DNS服務器繼續向域服務器發出請求，在這個例子中，請求的對象是.com域服務器。.com域服務器收到請求之後，也不會直接返回域名和IP地址的對應關係，而是告訴本地DNS服務器，你的域名的解析服務器的地址。
5. 最後，本地DNS服務器向域名的解析服務器發出請求，這時就能收到一個域名和IP地址對應關係，本地DNS服務器不僅要把IP地址返回給用戶電腦，還要把這個對應關係保存在緩存中，以備下次別的用戶查詢時，可以直接返回結果，加快網絡訪問。