一、scoket 相關(guān)知識(shí)點(diǎn)（概念、三次握手四次斷開(kāi)、心跳包、重連以及重連次數(shù)）
Scoket 是客戶(hù)端和服務(wù)端之間相互通信的橋梁，想要實(shí)現(xiàn)兩者之間的通訊，就必須建立連接俗稱(chēng)三次握手。
第一次、由客戶(hù)端向服務(wù)端發(fā)送 SYN 同步報(bào)文。
第二次、當(dāng)服務(wù)端收到 SYN 同步報(bào)文之后，會(huì)返回給客戶(hù)端 SYN 同步報(bào)文和 ACK 確認(rèn)報(bào)文。
第三次、客戶(hù)端會(huì)向服務(wù)端發(fā)送 ACK 確認(rèn)報(bào)文，此時(shí)客戶(hù)端和服務(wù)端的連接正式建立。
建立連接之后為保證兩端時(shí)刻活躍，客戶(hù)端需要每隔一段時(shí)間向服務(wù)端發(fā)送心跳包
有時(shí)由于網(wǎng)絡(luò)波動(dòng)或則其他一些因素導(dǎo)致兩者斷開(kāi)了連接，我們需要做重連處理，一般情況重連時(shí)間2的指數(shù)級(jí)增長(zhǎng)當(dāng)達(dá)到一定次數(shù)將放棄重連。
注：SYN 同步序列編號(hào)（Synchronize Sequence Numbers）。是TCP/IP建立連接時(shí)使用的握手信號(hào)。
二、MQTT相關(guān)知識(shí)點(diǎn)（概念、訂閱、發(fā)布、心跳包、重連）
消息隊(duì)列遙測(cè)傳輸簡(jiǎn)稱(chēng)MQTT，他是發(fā)布/訂閱型消息協(xié)議，MQTT協(xié)議具有輕量、簡(jiǎn)單、開(kāi)放和易于實(shí)現(xiàn)等優(yōu)點(diǎn)因此它適用范圍非常廣泛。
MQTT協(xié)議有三種身份：發(fā)布者、代理、訂閱者，發(fā)布者和訂閱者都為客戶(hù)端，代理為服務(wù)器，同時(shí)消息的發(fā)布者也可以是訂閱者。
MQTT訂閱
傳輸?shù)南⒎譃橹黝}（Topic，可理解為消息的類(lèi)型）和負(fù)載（可以理解為消息的內(nèi)容）兩部分
通過(guò)消息的內(nèi)容我們可以得到是否訂閱成功，訂閱失敗需要重新訂閱，一般我們也會(huì)設(shè)置一個(gè)最大訂閱次數(shù)，
MQTT發(fā)布
發(fā)布消息會(huì)攜帶主題（topic）和消息內(nèi)容，我們接收到MQTT發(fā)布topic之后根據(jù)topic來(lái)做相應(yīng)的處理
三、推送相關(guān)知識(shí)點(diǎn)
推送原理：
1、App向iOS設(shè)備發(fā)送一個(gè)注冊(cè)通知,用戶(hù)需要同意系統(tǒng)發(fā)送推送。
2、iOS設(shè)備向蘋(píng)果遠(yuǎn)程推送服務(wù)器發(fā)送App的Bundle Id和設(shè)備的UDID
3、蘋(píng)果推送服務(wù)器根據(jù)設(shè)備的UDID和App的Bundle Id生成deviceToken再發(fā)回給App
4、App再將deviceToken發(fā)送給遠(yuǎn)程推送服務(wù)器(自己的服務(wù)器), 由服務(wù)器保存在數(shù)據(jù)庫(kù)中。
5、當(dāng)自己的服務(wù)器想發(fā)送推送時(shí), 會(huì)把用戶(hù)的devicetoken和消息內(nèi)容一起發(fā)送給蘋(píng)果遠(yuǎn)程推送服務(wù)器
6、蘋(píng)果遠(yuǎn)程推送服務(wù)器在自身已注冊(cè)Push服務(wù)的iOS設(shè)備列表中。查找有對(duì)應(yīng)標(biāo)識(shí)的iOS設(shè)備，并將消息發(fā)送到iOS設(shè)備
7、iOS設(shè)備接收到蘋(píng)果遠(yuǎn)程服務(wù)器push過(guò)來(lái)的消息之后，找到相應(yīng)的應(yīng)用程序。并依照設(shè)定彈出Push通知
四、MVC、MVVM相關(guān)知識(shí)點(diǎn)
MVC
MVC也就是Model View Controller（模型 視圖 控制器）
MVC 的特點(diǎn)就是View 上面顯示什么東西，取決于 Model。只要 Model 數(shù)據(jù)改了，View 的顯示狀態(tài)會(huì)跟著更改。Model 通過(guò) Notification 和 KVO 機(jī)制與 Controller 間接通信。
view和model之間的通信是通過(guò)Controler來(lái)完成。Controler負(fù)責(zé)初始化 Model且對(duì)model進(jìn)行讀寫(xiě)調(diào)用然后并將 Model的值 傳遞給 View 去解析展示。
MVC有優(yōu)點(diǎn)也有缺點(diǎn)
優(yōu)點(diǎn)是
將數(shù)據(jù)與視圖分離開(kāi)來(lái)，有一定可閱讀性。降低了代碼的耦合性有利于代碼的維護(hù)。
缺點(diǎn)
1、自身設(shè)計(jì)的缺點(diǎn)
在 MVC 模式中 view 將用戶(hù)交互通知給控制器。view 的控制器通過(guò)更新 Model 來(lái)反應(yīng)狀態(tài)的改變。Model（通常使用 Key-Value-Observation）通知控制器來(lái)更新他們負(fù)責(zé)的 view。大多數(shù) iOS 應(yīng)用程序的代碼使用這種方式來(lái)組織。
2、愈發(fā)笨重的 Controller
大量的代碼被堆放在controller中使Controller變得越來(lái)越臃腫，臃腫的Controller 不僅要管理自身的屬性狀態(tài)還要遵循許多協(xié)議，導(dǎo)致協(xié)議的響應(yīng)代碼和 controller 的邏輯代碼混淆在一起很難管理和測(cè)試。
3、太過(guò)于輕量級(jí)的 Model
ARC 普及以后我們?cè)?Model 層的實(shí)現(xiàn)文件中基本上看不到代碼，同時(shí)與控制器的代碼越來(lái)厚重形成強(qiáng)烈的反差。
4、遺失的網(wǎng)絡(luò)邏輯
開(kāi)發(fā)過(guò)程中，我們的大部分?jǐn)?shù)據(jù)來(lái)源于網(wǎng)絡(luò)請(qǐng)求，如果網(wǎng)絡(luò)請(qǐng)求放在model/view中，由于網(wǎng)絡(luò)調(diào)用大部分使用異步，可能會(huì)出現(xiàn)網(wǎng)絡(luò)請(qǐng)求比持有它的 Model /view生命周期更長(zhǎng)，這樣會(huì)導(dǎo)致網(wǎng)絡(luò)請(qǐng)求被提前釋放。放到controller中又使控制器越來(lái)越臃腫。
MVVM
MVVM 即 Model View ViewModel（模型 視圖 視圖模型）
MVVM衍生于MVC，是對(duì) MVC 的一種演進(jìn)，它促進(jìn)了 UI 代碼與業(yè)務(wù)邏輯的分離。它正式規(guī)范了視圖和控制器緊耦合的性質(zhì)，并引入新的組件。
在MVVM 中，view 和 view controller正式聯(lián)系在一起，我們把它們視為一個(gè)組件
view 和 view controller 都不能直接引用model，而是引用視圖模型（viewModel）
viewModel 是一個(gè)放置用戶(hù)輸入驗(yàn)證邏輯，視圖顯示邏輯，發(fā)起網(wǎng)絡(luò)請(qǐng)求和其他代碼的地方
使用MVVM會(huì)輕微的增加代碼量，但總體上減少了代碼的復(fù)雜性
五、數(shù)據(jù)庫(kù)相關(guān)知識(shí)點(diǎn)
iOS的存儲(chǔ)方式有以下幾種
1、plist 格式文件存儲(chǔ)
2、NSUserDefaults 沙盒存儲(chǔ)(個(gè)人偏好設(shè)置)
3、文件讀寫(xiě)存儲(chǔ)
4、解歸檔存儲(chǔ)
5、數(shù)據(jù)庫(kù)存儲(chǔ)
1、plist文件 即為屬性列表文件
可以存儲(chǔ)基本數(shù)據(jù)類(lèi)型常用于存儲(chǔ)用戶(hù)的設(shè)置，或存儲(chǔ)項(xiàng)目中經(jīng)常用到又不經(jīng)常改變的數(shù)據(jù) 不適合存儲(chǔ)大量數(shù)據(jù)，
2、文件讀寫(xiě)存儲(chǔ)
文件操作可通過(guò)單例 NSFileManager 處理。文件存儲(chǔ)的路徑可以代碼設(shè)置?？梢源鎯?chǔ)大量數(shù)據(jù)，對(duì)數(shù)據(jù)格式?jīng)]有限制。
但由于數(shù)據(jù)的存取必須是一次性全部操作，所以在頻繁操作數(shù)據(jù)方面性能欠缺。
3、解歸檔存儲(chǔ)
對(duì)于開(kāi)發(fā)中自定義的數(shù)據(jù)模型的儲(chǔ)存，我們可以考慮使用歸檔儲(chǔ)存方案。但是是使用歸檔保存的自定義模型需要實(shí)現(xiàn)NSCoding協(xié)議下的兩個(gè)方法，但在大批量處理數(shù)據(jù)時(shí)，性能上仍有所欠缺。
4、數(shù)據(jù)庫(kù)存儲(chǔ)
iOS使用的數(shù)據(jù)庫(kù)是SQlite3，通常在做大量數(shù)據(jù)存儲(chǔ)或數(shù)據(jù)操作的時(shí)候開(kāi)發(fā)者會(huì)去選擇數(shù)據(jù)庫(kù)存儲(chǔ)。
在操作數(shù)據(jù)庫(kù)的時(shí)候，很多開(kāi)發(fā)者不愿去使用SQlite語(yǔ)句去操作數(shù)據(jù)庫(kù)，因?yàn)镾Qlite語(yǔ)句比較長(zhǎng)而且區(qū)分大小寫(xiě)，使用不方便，經(jīng)常會(huì)借用第三方管理工具來(lái)對(duì)他進(jìn)行操作，如：FMDB、Core Data等
六、進(jìn)程與線(xiàn)程
一個(gè)應(yīng)用程序只有一個(gè)進(jìn)程，進(jìn)程擁有獨(dú)立運(yùn)行所需的全部資源。一個(gè)進(jìn)程中可以有一個(gè)或多個(gè)線(xiàn)程。進(jìn)程只負(fù)責(zé)資源的調(diào)度和分配，線(xiàn)程才是程序真正的執(zhí)行單元，負(fù)責(zé)代碼的執(zhí)行。
多線(xiàn)程
多線(xiàn)程是為了同步完成多項(xiàng)任務(wù)，不是為了提高運(yùn)行效率，而是為了提高資源使用效率來(lái)提高系統(tǒng)的效率。線(xiàn)程是在同一時(shí)間需要完成多項(xiàng)任務(wù)的時(shí)候?qū)崿F(xiàn)的。
iOS允許用戶(hù)自己開(kāi)辟新的線(xiàn)程，相對(duì)于主線(xiàn)程來(lái)講，這些線(xiàn)程，稱(chēng)作子線(xiàn)程。
可以根據(jù)需要開(kāi)辟若干子線(xiàn)程，子線(xiàn)程和主線(xiàn)程是 都是 獨(dú)立的運(yùn)行單元，各自的執(zhí)行互不影響，因此能夠并發(fā)執(zhí)行。有效的避免了代碼阻塞，提高程序的運(yùn)行性能。
iOS多線(xiàn)程實(shí)現(xiàn)種類(lèi) 常見(jiàn)的有4種：PThreads、NSThread、GCD、NSoperation和NSOPreationQueue
PThreads
PThreads基于C語(yǔ)言，使用難度比較大，一般是針對(duì)底層操作的線(xiàn)程。PThreads線(xiàn)程的生命周期是由程序猿來(lái)控制
NSThread
NSThread 是蘋(píng)果官方提供給我們的一種面向?qū)ο蟮妮p量級(jí)多線(xiàn)程解決方案，一個(gè)NSThread對(duì)象就代表一個(gè)線(xiàn)程。線(xiàn)程的生命周期由程序員來(lái)控制，程序員創(chuàng)建線(xiàn)程之后需要自己銷(xiāo)毀，如果不銷(xiāo)毀則造成了資源浪費(fèi)。
GCD
GCD可用于多核并行的運(yùn)算，會(huì)自動(dòng)管理線(xiàn)程的生命周期
GCD有兩個(gè)核心的概念，任務(wù)和隊(duì)列
任務(wù)：也就是執(zhí)行操作的意思
任務(wù)又分為同步執(zhí)行和異步執(zhí)行，
同步執(zhí)行：是同步添加任務(wù)到指定隊(duì)列中，在添加的任務(wù)沒(méi)有執(zhí)行結(jié)束前他會(huì)一直等待。直到隊(duì)列里面的任務(wù)執(zhí)行完畢之后才會(huì)繼續(xù)執(zhí)行其他任務(wù)。只能在當(dāng)前線(xiàn)程執(zhí)行任務(wù)，不具備開(kāi)辟新線(xiàn)程的能力。
異步執(zhí)行：是異步添加任務(wù)到指定隊(duì)列中，添加任務(wù)后他不會(huì)做任何等待，可以繼續(xù)執(zhí)行其他任務(wù)。具備開(kāi)辟線(xiàn)程的能力。
隊(duì)列：也就是存放任務(wù)的隊(duì)列
隊(duì)列又分為串行隊(duì)列和并發(fā)隊(duì)列，
串行隊(duì)列：每次只有一個(gè)任務(wù)被執(zhí)行，讓任務(wù)一個(gè)接著一個(gè)的執(zhí)行只開(kāi)辟了一個(gè)線(xiàn)程。
并發(fā)隊(duì)列：同時(shí)可以執(zhí)行多個(gè)任務(wù)，可以開(kāi)辟多個(gè)線(xiàn)程。并發(fā)隊(duì)列只有在異步函數(shù)下才能生效。
NSoperation和NSOPreationQueue
NSoperation和NSOPreationQueue：是對(duì)GCD更高一層的封裝，但是比 GCD 更簡(jiǎn)單易用、代碼可讀性也更高，他也是自動(dòng)管理線(xiàn)程的生命周期。
NSoperation和NSOPreationQueue 可以設(shè)定任務(wù)執(zhí)行的優(yōu)先級(jí)、可以隨時(shí)取消一個(gè)操作的執(zhí)行、也可以添加多個(gè)操作的依賴(lài)關(guān)系。
線(xiàn)程與RunLoop
線(xiàn)程與RunLoop密切聯(lián)系在一起，每一個(gè)線(xiàn)程都有一個(gè)RunLoop對(duì)象，我們不能創(chuàng)建線(xiàn)程的RunLoop對(duì)象，但是我們可以獲取線(xiàn)程的RunLoop對(duì)象。主線(xiàn)程的RunLoop在程序啟動(dòng)時(shí)默認(rèn)開(kāi)啟。其他線(xiàn)程的RunLoop是默認(rèn)關(guān)閉的。
Runloop 通過(guò)監(jiān)控 Source 來(lái)決定有沒(méi)有任務(wù)要做，有任務(wù)做時(shí)Runloop 會(huì)去找對(duì)應(yīng)的 Handler 處理事件，沒(méi)有任務(wù)做時(shí)，Runloop會(huì)讓線(xiàn)程進(jìn)入休眠狀態(tài)，
iOS 中公開(kāi)暴露出來(lái)的只有 NSDefaultRunLoopMode 和 NSRunLoopCommonModes。 NSRunLoopCommonModes 實(shí)際上是一個(gè) Mode 的集合，默認(rèn)包括 NSDefaultRunLoopMode 和 NSEventTrackingRunLoopMode。
事例：
日常開(kāi)發(fā)中，與 runLoop 接觸得最近可能就是通過(guò) NSTimer 了。一個(gè) Timer 一次只能加入到一個(gè) RunLoop 中。我們?nèi)粘Ｊ褂玫臅r(shí)候，通常就是加入到當(dāng)前的 runLoop 的 default mode 中，而 ScrollView 在用戶(hù)滑動(dòng)時(shí)，主線(xiàn)程 RunLoop 會(huì)轉(zhuǎn)到 UITrackingRunLoopMode 。而這個(gè)時(shí)候， Timer 就不會(huì)運(yùn)行。
有如下兩種解決方案：
第一種: 設(shè)置RunLoop Mode，例如NSTimer,我們指定它運(yùn)行于 NSRunLoopCommonModes ，這是一個(gè)Mode的集合。注冊(cè)到這個(gè) Mode 下后，無(wú)論當(dāng)前 runLoop 運(yùn)行哪個(gè) mode ，事件都能得到執(zhí)行。
第二種: 另一種解決Timer的方法是，我們?cè)诹硗庖粋€(gè)線(xiàn)程執(zhí)行和處理 Timer 事件，然后在主線(xiàn)程更新UI
七、控制器的生命周期
創(chuàng)建
1、alloc 創(chuàng)建對(duì)象 分配空間
2、init 初始化對(duì)象 初始化數(shù)據(jù)、
3、loadview 從nib載入視圖
4、viewDidLoad 載入完成 可以自定義數(shù)據(jù)以及動(dòng)態(tài)加載其他數(shù)據(jù)
5、viewWillAppear 視圖即將展示
6、viewDidAppear 視圖加載完成
消失
1、viewWillDisappear 視圖即將消失
2、viewDidDisAppear 視圖已經(jīng)消失
3、delloc 視圖已被銷(xiāo)毀
八、 weak關(guān)鍵字，相比assign有什么不同？
weak是弱引用 使用weak修飾的對(duì)象 引用計(jì)數(shù)不會(huì)增加 weak在引用對(duì)象被釋放時(shí)自動(dòng)置為nil 這樣就避免了野指針的出現(xiàn)。使用weak修飾對(duì)象可以解決循環(huán)引用。
assign可用來(lái)修飾基本數(shù)據(jù)類(lèi)型，也可修飾OC的對(duì)象，但如果用assign修飾對(duì)象類(lèi)型指向的是一個(gè)強(qiáng)指針，當(dāng)指向的這個(gè)指針釋放之后，它仍指向這塊內(nèi)存，必須要手動(dòng)給置為nil，如果不置為nil 則會(huì)出現(xiàn)野指針
weak只能用來(lái)修飾OC對(duì)象，而且相比assign比較安全，如果指向的對(duì)象消失了，那么它會(huì)自動(dòng)置為nil，不會(huì)導(dǎo)致野指針。
九、深拷貝與淺拷貝 copy 與 mutableCopy
淺拷貝拷貝的是對(duì)象的指針，拷貝之后兩個(gè)指針指向同一塊內(nèi)存空間
深拷貝拷貝的不僅僅是指針而且還有對(duì)象本身也就是指針指向的內(nèi)容?？截惡蟮闹羔樑c之前的指針指向的地址空間不同
copy方法:如果是非可擴(kuò)展類(lèi)對(duì)象，則是淺拷貝。如果是可擴(kuò)展類(lèi)對(duì)象，則是深拷貝。
mutableCopy方法:無(wú)論是可擴(kuò)展類(lèi)對(duì)象還是不可擴(kuò)展類(lèi)對(duì)象，都是深拷貝。
十、TCP 和 UDP的區(qū)別
TCP：面向連接、傳輸可靠(保證數(shù)據(jù)正確性,保證數(shù)據(jù)順序)、用于傳輸大量數(shù)據(jù)(流模式)、速度慢，建立連接需要開(kāi)銷(xiāo)較多(時(shí)間，系統(tǒng)資源)。
UDP：面向非連接、傳輸不可靠、用于傳輸少量數(shù)據(jù)(數(shù)據(jù)包模式)、速度快。
十一、 HTTP協(xié)議中 POST 方法和 GET 方法有那些區(qū)別?
- GET用于向服務(wù)器請(qǐng)求數(shù)據(jù)，POST用于提交數(shù)據(jù)
- GET請(qǐng)求，請(qǐng)求參數(shù)拼接形式暴露在地址欄，而POST請(qǐng)求參數(shù)則放在請(qǐng)求體里面，因此GET請(qǐng)求不適合用于驗(yàn)證密碼等操作
- GET請(qǐng)求的URL有長(zhǎng)度限制，POST請(qǐng)求不會(huì)有長(zhǎng)度限制
十二、代理 block 通知 之間的區(qū)別
代理和block 用于兩個(gè)對(duì)象一對(duì)一之間的通信。代理需要簽訂協(xié)議，代理對(duì)象實(shí)現(xiàn)代理方法，建立代理關(guān)系才能建立通信，block不需要簽訂復(fù)雜的協(xié)議方法 代碼簡(jiǎn)潔方便。通知一般用于一對(duì)多而且對(duì)象不需要建立關(guān)系 但是代碼可讀性差。
十三、談?wù)勀銓?duì)SDWebimage 加載原理的理解
SDWimage加載時(shí)分為三步，
1，從內(nèi)存中查找圖片，如果有就使用
2，內(nèi)存中沒(méi)有則從沙盒中提取如果有則使用
3，沙盒中也沒(méi)有的話(huà)就直接從網(wǎng)絡(luò)上下載 然后緩存 最后存到沙盒
十四、如何優(yōu)化Tableview
- 注冊(cè)重用標(biāo)識(shí)符
2.避免cell的重新布局
3.提前計(jì)算并緩存cell的屬性及內(nèi)容
4.減少cell中控件的數(shù)量
5.不要使用ClearColor，無(wú)背景色，透明度也不要設(shè)置為0因?yàn)殇秩竞臅r(shí)比較長(zhǎng)
6.使用局部更新 如果只是更新某組的話(huà)，使用reloadSection進(jìn)行局部更
7.加載網(wǎng)絡(luò)數(shù)據(jù)，下載圖片，使用異步加載，并緩存
8.少使用addView 給cell動(dòng)態(tài)添加view
9.按需加載cell，cell滾動(dòng)很快時(shí)，只加載范圍內(nèi)的cell
10.不要實(shí)現(xiàn)無(wú)用的代理方法，tableView只遵守兩個(gè)協(xié)議
11.不要做多余的繪制工作。
12.使用正確的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)。減少不必要的修改
十四、iOS有哪些常見(jiàn)的設(shè)計(jì)模式?
單例模式：
單例保證了應(yīng)用程序的生命周期內(nèi)僅有一個(gè)該類(lèi)的實(shí)例對(duì)象,而且易于外界訪(fǎng)問(wèn).在ios sdk中,UIApplication, NSBundle, NSNotificationCenter, NSFileManager, NSUserDefault, NSURLCache等都是單例.
代理模式：
委托Delegate是協(xié)議的一種,通過(guò)@protocol方式實(shí)現(xiàn)，常見(jiàn)的有tableView，textField等。
觀察者模式：
觀察者模式定義了一種一對(duì)多的依賴(lài)關(guān)系，讓多個(gè)觀察者對(duì)象同時(shí)監(jiān)聽(tīng)某一個(gè)主題對(duì)象。在iOS中,觀察者模式的具體實(shí)現(xiàn)有兩種: 通知機(jī)制(notification)和KVO機(jī)制(Key-value Observing)
十五、數(shù)據(jù)安全及加密
a、對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密的區(qū)別？
1、對(duì)稱(chēng)加密又稱(chēng)公開(kāi)密鑰加密，加密和解密都會(huì)用到同一個(gè)密鑰，如果密鑰被攻擊者獲得，此時(shí)加密就失去了意義。常見(jiàn)的對(duì)稱(chēng)加密算法有DES、3DES、AES、Blowfish、IDEA、RC5、RC6。
2、非對(duì)稱(chēng)加密又稱(chēng)共享密鑰加密，使用一對(duì)非對(duì)稱(chēng)的密鑰，一把叫做私有密鑰，另一把叫做公有密鑰；公鑰加密只能用私鑰來(lái)解密，私鑰加密只能用公鑰來(lái)解密。常見(jiàn)的公鑰加密算法有：RSA、ElGamal、背包算法、Rabin
b、簡(jiǎn)述 SSL 加密的過(guò)程用了哪些加密方法，為何這么作？
SSL 加密，在過(guò)程中實(shí)際使用了 對(duì)稱(chēng)加密 和 非對(duì)稱(chēng)加密 的結(jié)合。主要的考慮是先使用 非對(duì)稱(chēng)加密 進(jìn)行連接，這樣做是為了避免中間人攻擊秘鑰被劫持，但是 非對(duì)稱(chēng)加密 的效率比較低。所以一旦建立了安全的連接之后，就可以使用輕量的 對(duì)稱(chēng)加密。
c、iOS的簽名機(jī)制是怎么樣的
簽名機(jī)制：先將應(yīng)用內(nèi)容通過(guò)摘要算法，得到摘要
再用私鑰對(duì)摘要進(jìn)行加密得到密文
將源文本、密文、和私鑰對(duì)應(yīng)的公鑰一并發(fā)布
驗(yàn)證流程：
查看公鑰是否是私鑰方的
然后用公鑰對(duì)密文進(jìn)行解密得到摘要
將APP用同樣的摘要算法得到摘要，兩個(gè)摘要進(jìn)行比對(duì)，如果相等那么一切正常
十六、網(wǎng)絡(luò)
1、Http 和 Https 的區(qū)別？Https為什么更加安全？
區(qū)別
1.HTTPS 需要向機(jī)構(gòu)申請(qǐng) CA 證書(shū)，極少免費(fèi)。
2.HTTP 屬于明文傳輸，HTTPS基于 SSL 進(jìn)行加密傳輸。
3.HTTP 端口號(hào)為 80，HTTPS 端口號(hào)為 443 。
4.HTTPS 是加密傳輸，有身份驗(yàn)證的環(huán)節(jié)，更加安全。
安全
SSL(安全套接層) TLS(傳輸層安全)
以上兩者在傳輸層之上，對(duì)網(wǎng)絡(luò)連接進(jìn)行加密處理，保障數(shù)據(jù)的完整性，更加的安全。
