J_Knight_ iOS 高級面試題 網絡題解答

網絡題

App 網絡層有哪些優化策略？
TCP爲何要三次握手，四次揮手？
對稱加密和非對稱加密的區別？分別有哪些算法的實現？
HTTPS的握手流程？爲何密鑰的傳遞須要使用非對稱加密？雙向認證瞭解麼？
HTTPS是如何實現驗證身份和驗證完整性的？
如何用Charles抓HTTPS的包？其中原理和流程是什麼？
什麼是中間人攻擊？如何避免？
複製代碼

App 網絡層有哪些優化策略？

首先咱們瞭解一下服務器發送一個請求的過程

* 1.DNS Lookup
2.TCP Handshake
3.TLS或SSL Handshake
4.TCP/HTTP Request/Response

網絡優化

1.優化DNS解析和緩存

APP內置Server IP列表，該列表能夠在App啓動服務中下發更新。App啓動後的首次網絡服務會從Server IP列表中取一個IP地址進行TCP鏈接，同時DNS解析會並行進行，DNS成功後，會返回最適合用戶網絡的Server IP，那麼這個Server IP會被加入到Server IP列表中被優先使用。
Server IP列表有權重機制的，DNS解析返回的IP很明顯具備最高的權重，每次從Server IP列表中取IP會取權重最高的IP。列表中IP權重也是動態更新的，根據鏈接或者服務的成功失敗來動態調整，這樣即便DNS解析失敗，用戶在使用一段時間後也會選取到適合的Server IP。

2.網絡質量檢測（根據網絡質量來改變策略）

根據用戶是在2G/3G/4G/Wi-Fi的網絡環境來設置不一樣的超時參數，以及網絡服務的併發數量。好比在環境比較差的狀況下:
1.將併發數設置爲一個改爲串行
2.動態設置超時時間
3.throttle 進行節流
AFNetworking中的throttle方法
1- (void)throttleBandwidthWithPacketSize:(NSUInteger)numberOfBytes                                   delay:(NSTimeInterval)delay;

3.管道化鏈接

若是服務器不支持管線化的話，那麼響應就會亂序。因此服務器要支持。 AFNetworking中經過HTTPShouldUsePipelining屬性來設置，默認爲NO。
減小數據傳輸量
選擇合適的數據格式進行傳輸，好比使用Protocol Buffer數等，使用WebP圖片格式
提供網絡服務重發機制
當第一次網絡請求失敗的時候，自動嘗試再次重發
使用HTTP緩存

4.針對連接創建環節的優化
使用緩存手段減小請求的發起次數
使用策略來減小請求的發起次數

更多優化請看下面這個內容

[百度App網絡深度優化系列《二》鏈接優化](http://baijiahao.baidu.com/s?id=1625511944699576834)

[百度App網絡深度優化系列《一》DNS優化](http://baijiahao.baidu.com/s?id=1621552582705610161)
1.https://chromium.googlesource.com/chromium/src/+/HEAD/docs/android_build_instructions.md
2.https://chromium.googlesource.com/chromium/src/+/HEAD/docs/ios/build_instructions.md
3.https://github.com/Tencent/mars
4.https://tools.ietf.org/html/rfc7858
5.https://tools.ietf.org/html/rfc6555
6.https://tools.ietf.org/html/rfc8305
複製代碼

TCP爲何要三次握手，四次揮手？

TCP是主機對主機層的傳輸控制協議，提供可靠的鏈接服務，採用三次握手確認創建一個鏈接：
 
 SYN表示創建鏈接，
 
 FIN表示關閉鏈接，
 
 ACK表示響應

1, 第一次：首先A發送一個(SYN)到B，意思是A要和B創建鏈接進行通訊；

若是是隻有一次握手的話，這樣確定是不行的，A壓根都不知道B是否是收到了這個請求。 

2, 第二次：B收到A要創建鏈接的請求以後，發送一個確認(SYN+ACK)給A，意思是收到A的消息了，B這裏也是通的，表示能夠創建鏈接；
若是隻有兩次通訊的話，這時候B不肯定A是否收到了確認消息，有可能這個確認消息因爲某些緣由丟了。 

3, 第三次：A若是收到了B的確認消息以後，再發出一個確認(ACK)消息，意思是告訴B，這邊是通的，而後A和B就能夠創建鏈接相互通訊了；
必定要進行三次握手麼，不能只進行兩次或者四次？？

其實這個問題的本質是因特網中信道不可靠, 可是要在這個不可靠的信道上可靠地傳輸數據，三次握手是最小的理論值。

  若是隻進行兩次握手，那麼當客戶端發送一個SYN分組後，會發生兩種狀況：
  狀況一：服務器接收到了這個SYN並返回ACK，不管客戶端是否接收到了ACK，服務器都認爲已經與客戶端創建鏈接了，因而就開始向客戶端發送數據。可是若是客戶段沒有收到ACK，那麼客戶端會認爲與服務器沒有創建鏈接，就不會接收服務器發來的數據，也就是說直接丟棄服務器發來的數據，服務器發出的消息超時了，就重複發送數據，這就產生了死鎖。
  狀況二：客戶端發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放之後的某個時間纔到達服務器。原本這是一個早已失效的報文段。但服務器收到此失效的鏈接請求報文段後，就誤認爲是客戶端再次發出的一個新的鏈接請求。因而就向客戶端發送ACK，可是此時客戶端沒有發出請求，因此並不會理睬這個ACK，而服務器又開始發數據給客戶端了，這時候，客戶端又把這些數據都丟棄了，而服務器發出的消息超時了，就重複發送數據，也產生了死鎖。


TCP四次揮手
第一次分手：主機1（可使客戶端，也能夠是服務器端），設置Sequence Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；

第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「贊成」你的關閉請求；

第三次分手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態；

第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

問題1：爲何要四次分手？

TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經所有發送完畢了；可是，這個時候主機1仍是能夠接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，可是主機2仍是能夠發送數據到主機1的；當主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，以後彼此就會愉快的中斷此次TCP鏈接。
複製代碼

對稱加密和非對稱加密的區別？分別有哪些算法的實現？

什麼是對稱加密技術？
對稱加密採用了對稱密碼編碼技術，它的特色是文件加密和解密使用相同的密鑰加密
也就是密鑰也能夠用做解密密鑰，這種方法在密碼學中叫作對稱加密算法，對稱加密算法使用起來簡單快捷，密鑰較短，且破譯困難，除了數據加密標準（DES），另外一個對稱密鑰加密系統是國際數據加密算法（IDEA），它比DES的加密性好，並且對計算機功能要求也沒有那麼高
對稱加密算法在電子商務交易過程當中存在幾個問題：
  一、要求提供一條安全的渠道使通信雙方在首次通信時協商一個共同的密鑰。直接的面對面協商多是不現實並且難於實施的，因此雙方可能須要藉助於郵件和電話等其它相對不夠安全的手段來進行協商；
  二、密鑰的數目難於管理。由於對於每個合做者都須要使用不一樣的密鑰，很難適應開放社會中大量的信息交流；
  三、對稱加密算法通常不能提供信息完整性的鑑別。它沒法驗證發送者和接受者的身份；
  四、對稱密鑰的管理和分發工做是一件具備潛在危險的和煩瑣的過程。對稱加密是基於共同保守祕密來實現的，採用對稱加密技術的貿易雙方必須保證採用的是相同的密鑰，保證彼此密鑰的交換是安全可靠的，同時還要設定防止密鑰泄密和更改密鑰的程序。
  假設兩個用戶須要使用對稱加密方法加密而後交換數據，則用戶最少須要2個密鑰並交換使用，若是企業內用戶有n個，則整個企業共須要n×(n-1) 個密鑰，密鑰的生成和分發將成爲企業信息部門的惡夢。
常見的對稱加密算法有DES、3DES、Blowfish、IDEA、RC四、RC五、RC6和AES 

什麼是非對稱加密技術？
與對稱加密算法不一樣，非對稱加密算法須要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）。
公開密鑰與私有密鑰是一對，若是用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；若是用私有密鑰對數據進行加密，那麼只有用對應的公開密鑰才能解密。由於加密和解密使用的是兩個不一樣的密鑰，因此這種算法叫做非對稱加密算法。
非對稱加密算法實現機密信息交換的基本過程是：甲方生成一對密鑰並將其中的一把做爲公用密鑰向其它方公開；獲得該公用密鑰的乙方使用該密鑰對機密信息進行加密後再發送給甲方；甲方再用本身保存的另外一把專用密鑰對加密後的信息進行解密。甲方只能用其專用密鑰解密由其公用密鑰加密後的任何信息。
 非對稱加密的典型應用是數字簽名。
   常見的非對稱加密算法有：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）
Hash算法（摘要算法）
Hash算法特別的地方在於它是一種單向算法，用戶能夠經過hash算法對目標信息生成一段特定長度的惟一hash值，卻不能經過這個hash值從新得到目標信息。所以Hash算法經常使用在不可還原的密碼存儲、信息完整性校驗等。
常見的Hash算法有MD二、MD四、MD五、HAVAL、SHA
複製代碼

HTTPS的握手流程？爲何密鑰的傳遞須要使用非對稱加密 HTTPS是如何實現驗證身份和驗證完整性的？

https://blog.csdn.net/clh604/article/details/22179907 。 
https原理：證書傳遞、驗證和數據加密、解密過程解析

https://blog.csdn.net/zhongzh86/article/details/69389967   深度解析HTTPS原理

http://liuduo.me/2018/05/14/https-detail/   HTTPS 原理詳解

https://yq.aliyun.com/articles/625289 HTTPS原理和CA證書申請（滿滿的乾貨
複製代碼

如何用Charles抓HTTPS的包？其中原理和流程是什麼？

https://www.jianshu.com/p/870451cb4eb0
複製代碼

什麼是中間人攻擊？如何避免？

https://www.jianshu.com/p/210c296eb836
https://www.zhihu.com/question/20744215
https://www.cnblogs.com/LittleHann/p/3735602.html
http://netsecurity.51cto.com/art/201712/559836.htm
複製代碼