查漏補(bǔ)缺二

摘錄 只供自己學(xué)習(xí)

1.typeof 和 __typeof码耐，typeof 的區(qū)別?

__typeof __() 和 __typeof() 是 C語言 的編譯器特定擴(kuò)展琼锋，因為標(biāo)準(zhǔn) C 不包含這樣的運算符饺蚊。 標(biāo)準(zhǔn) C 
要求編譯器用雙下劃線前綴語言擴(kuò)展（這也是為什么你不應(yīng)該為自己的函數(shù)托呕，變量等做這些）

typeof() 與前兩者完全相同的差牛，只不過去掉了下劃線音羞，同時現(xiàn)代的編譯器也可以理解景描。

所以這三個意思是相同的十办，但沒有一個是標(biāo)準(zhǔn)C，不同的編譯器會按需選擇符合標(biāo)準(zhǔn)的寫法

2.談?wù)剬IResponder的理解

UIResponder類是專門用來響應(yīng)用戶的操作處理各種事件的超棺，包括觸摸事件(Touch Events)向族、運動事件(Motion Events)、
遠(yuǎn)程控制事件(Remote Control Events)棠绘。我們知道UIApplication炸枣、UIView、UIViewController這幾個
類是直接繼承自UIResponder弄唧，所以這些類都可以響應(yīng)事件适肠。當(dāng)然我們自定義的繼承自UIView的View以及自定義
的繼承自UIViewController的控制器都可以響應(yīng)事件

3.loadView的作用？

loadView方法會在每次訪問UIViewController的view(比如controller.view候引、self.view)而且view為
nil時會被調(diào)用侯养，此方法主要用來負(fù)責(zé)創(chuàng)建UIViewController的view(重寫loadView方法，并且不需要調(diào)用
[super loadView])

這里要提一下 [super loadView]澄干，[super loadView]做了下面幾件事逛揩。
1.它會先去查找與UIViewController相關(guān)聯(lián)的xib文件，通過加載xib文件來創(chuàng)建UIViewController的view麸俘，
如果在初始化UIViewController指定了xib文件名辩稽，就會根據(jù)傳入的xib文件名加載對應(yīng)的xib文件，如果沒有
明顯地傳xib文件名从媚，就會加載跟UIViewController同名的xib文件
2.如果沒有找到相關(guān)聯(lián)的xib文件逞泄，就會創(chuàng)建一個空白的UIView，然后賦值給UIViewController的view屬性

在需要自定義UIViewController的view時拜效，可以通過重寫loadView方法且不需要調(diào)用[super loadView]方法

4.使用 drawRect有什么影響喷众？

drawRect 方法依賴 Core Graphics 框架來進(jìn)行自定義的繪制 
   缺點：它處理 touch 事件時每次按鈕被點擊后，都會用 setNeddsDisplay 進(jìn)行強(qiáng)制重繪紧憾；而且不止一次到千，
每次單點事件觸發(fā)兩次執(zhí)行。這樣的話從性能的角度來說赴穗，對 CPU 和內(nèi)存來說都是欠佳的憔四。特別是如果在我們的
界面上有多個這樣的UIButton 實例膀息，那就會很糟糕了。這個方法的調(diào)用機(jī)制也是非常特別. 當(dāng)你調(diào)用 
setNeedsDisplay 方法時, UIKit 將會把當(dāng)前圖層標(biāo)記為 dirty,但還是會顯示原來的內(nèi)容,直到下一次的視
圖渲染周期,才會將標(biāo)記為 dirty 的圖層重新建立 Core Graphics 上下文,然后將內(nèi)存中的數(shù)據(jù)恢復(fù)出來, 
再使用 CGContextRef 進(jìn)行繪制

5.keyWindow 和 delegate的window有何區(qū)別

delegate.window 程序啟動時設(shè)置的window對象了赵。
keyWindow 這個屬性保存了[windows]數(shù)組中的[UIWindow]對象履婉，該對象最近被發(fā)送了[makeKeyAndVisible]消息

一般情況下 delegate.window 和 keyWindow 是同一個對象，但不能保證keyWindow就是
delegate.window斟览，因為keyWindow會因為makeKeyAndVisible而變化，例如辑奈，程序中添加了一個懸浮窗口苛茂，
這個時候keywindow就會變化

6.說一下 JS 和 OC 互相調(diào)用的幾種方式？

js調(diào)用oc的三種方式:
@根據(jù)網(wǎng)頁重定向截取字符串通過url scheme判斷
@替換方法.context[@"copyText"]
@注入對象:遵守協(xié)議JSExport,設(shè)置context[@

oc調(diào)用js代碼兩種方式
@通過webVIew調(diào)用 webView stringByEvaluatingJavaScriptFromString: 調(diào)用
@通過JSContext調(diào)用[context evaluateScript:]

7.在使用 WKWebView 時遇到過哪些問題鸠窗？

白屏問題妓羊，Cookie 問題，在WKWebView上直接使用NSURLProtocol無法攔截請求稍计，在WKWebView 上通過
loadRequ發(fā)起的post請求body數(shù)據(jù)被丟失躁绸，截屏問題等

白屏

在WKWebView上總體的內(nèi)存占用比較大的時候 webContent進(jìn)程會崩潰 從而出現(xiàn)白屏問題

@采用WKNavigationDelegate
在iOS9之后WKNavigationDelegate的一個函數(shù)
- (void)webViewWebContentProcessDidTerminate:(WKWebView *)webView API_AVAILABLE(macosx(10.11), ios(9.0));
當(dāng)WKWebView總體內(nèi)存占用過大，頁面即將白屏的時候臣嚣，系統(tǒng)會調(diào)用上面的某種函數(shù)净刮，我們在該函數(shù)里執(zhí)行
[webView reload]  （這個時候webView.URL取值尚不為nil）解決白屏問題
@并不是所有的白屏都會經(jīng)過上述方法 也可能是webView.titile被置空了 可以在viewWillAppear的時候判斷
是否webView.titile是否被置空了 這個時候[webView reload]

Cookie 問題

WKWebView Cookie的問題在于WKWebView發(fā)起的請求不會自動帶上存儲于NSHTTPCookieStorage容器中的餅干

無法解決

WKProcessPool
可以實現(xiàn)多個WKWebView之間共享的Cookie數(shù)據(jù)。不過WKWebView WKProcessPool實例在應(yīng)用殺進(jìn)程重啟后會被重置硅则，導(dǎo)致WKProcessPool中的Cookie淹父，會話Cookie數(shù)據(jù)丟失，目前也無法實現(xiàn)WKProcessPool實例本地化保存

解決方法
a.WKWebView loadRequest前怎虫，在請求標(biāo)頭中設(shè)置Cookie暑认，解決首個請求Cookie帶不上的問題

WKWebView * webView =  [ WKWebView新] ;  
NSMutableURLRequest *請求=  [ NSMutableURLRequest requestWithURL ：[ NSURL URLWithString ： @ “ http://h5.qzone.qq.com/mqzone/index” ] ] ； 
[請求的addValue ： @ “SKEY = skeyValue” forHTTPHeaderField ： @ “曲奇” ] ;  
[ webView loadRequest ： request ] ;

b.通過document.cookie設(shè)置Cookie解決后續(xù)頁面（同域）Ajax大审，iframe請求的Cookie問題
document.cookie()無法跨域設(shè)置cookie

WKUserContentController * userContentController =  [ WKUserContentController新] 蘸际； 
WKUserScript * cookieScript =  [ [ WKUserScript alloc ] initWithSource ： @ “ document.cookie ='skey = skeyValue';” injectionTime ： WKUserScriptInjectionTimeAtDocumentStart for MainFrameOnly ： NO ] ;  
[ userContentController addUserScript ： cookieScript ] ;

但是無法解決302請求的Cookie問題
可以在

- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler

方法里面攔截302請求 在請求標(biāo)頭中帶上cookie并重新加載請求

在WKWebView上直接使用NSURLProtocol無法攔截請求

WKWebView在獨立于應(yīng)用進(jìn)程之外的進(jìn)程中執(zhí)行網(wǎng)絡(luò)請求，請求數(shù)據(jù)不通過主進(jìn)程徒扶，因此粮彤，在WKWebView上直接使用NSURLProtocol無法攔截請求

+ [WKBrowsingContextController registerSchemeForCustomProtocol:]

通過注冊HTTP方案后WKWebView將可以使用NSURLProtocol攔截http（s）請求

Class cls = NSClassFromString(@"WKBrowsingContextController”); 
SEL sel = NSSelectorFromString(@"registerSchemeForCustomProtocol:"); 
if ([(id)cls respondsToSelector:sel]) { 
           // 注冊http(s) scheme, 把 http和https請求交給 NSURLProtocol處理 
           [(id)cls performSelector:sel withObject:@"http"]; 
           [(id)cls performSelector:sel withObject:@"https"]; 
}

有缺陷

在WKWebView 上通過loadRequ發(fā)起的post請求body數(shù)據(jù)被丟失

由于進(jìn)程間的通信性能問題造成的

1.替換請求方案 生成新的post request2 同時,把request1的主體連接復(fù)制到request2的header中
2.通過[-WKWebView loadRequest:] 加載新的post請求request2
3.通過+ [WKBrowsingContextController registerSchemeForCustomProtocol：]注冊方案：post：// 
4.注冊NSURLProtocol攔截請求 替換新的請求方案 生成新的請求request3 將request2的body初始復(fù)制到request3的body中 并使用NSURLConnection加載request3 最后通過NSURLProtolClient將加載結(jié)果返回WKWebView

截屏問題

8.網(wǎng)絡(luò)七層協(xié)議

*   應(yīng)用層：

    1.用戶接口、應(yīng)用程序姜骡；

    2.Application典型設(shè)備：網(wǎng)關(guān)驾诈；

    3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用：TELNET溶浴、FTP乍迄、HTTP

*   表示層：

    1.數(shù)據(jù)表示、壓縮和加密presentation

    2.典型設(shè)備：網(wǎng)關(guān)

    3.典型協(xié)議士败、標(biāo)準(zhǔn)和應(yīng)用：ASCLL闯两、PICT褥伴、TIFF、JPEG|MPEG

    4.表示層相當(dāng)于一個東西的表示漾狼，表示的一些協(xié)議重慢，比如圖片、聲音和視頻MPEG逊躁。

*   會話層：

    1.會話的建立和結(jié)束似踱；

    2.典型設(shè)備：網(wǎng)關(guān)；

    3.典型協(xié)議稽煤、標(biāo)準(zhǔn)和應(yīng)用：RPC核芽、SQL、NFS酵熙、X WINDOWS轧简、ASP

*   傳輸層：

    1.主要功能：端到端控制Transport；

    2.典型設(shè)備：網(wǎng)關(guān)匾二；

    3.典型協(xié)議哮独、標(biāo)準(zhǔn)和應(yīng)用：TCP、UDP察藐、SPX

*   網(wǎng)絡(luò)層：

    1.主要功能：路由皮璧、尋址Network；

    2.典型設(shè)備：路由器分飞；

    3.典型協(xié)議恶导、標(biāo)準(zhǔn)和應(yīng)用：IP、IPX浸须、APPLETALK惨寿、ICMP；

*   數(shù)據(jù)鏈路層：

    1.主要功能：保證無差錯的疏忽鏈路的data link删窒；

    2.典型設(shè)備：交換機(jī)裂垦、網(wǎng)橋、網(wǎng)卡肌索；

    3.典型協(xié)議蕉拢、標(biāo)準(zhǔn)和應(yīng)用：802.2、802.3ATM诚亚、HDLC晕换、FRAME RELAY；

*   物理層：

    1.主要功能：傳輸比特流Physical站宗；

    2.典型設(shè)備：集線器闸准、中繼器

    3.典型協(xié)議、標(biāo)準(zhǔn)和應(yīng)用：V.35梢灭、EIA/TIA-232.

9.Http 和 Https 的區(qū)別夷家？Https為什么更加安全蒸其？

*   區(qū)別

    1.HTTPS 需要向機(jī)構(gòu)申請 CA 證書，極少免費库快。

    2.HTTP 屬于明文傳輸摸袁，HTTPS基于 SSL 進(jìn)行加密傳輸。

    3.HTTP 端口號為 80义屏，HTTPS 端口號為 443 靠汁。

    4.HTTPS 是加密傳輸，有身份驗證的環(huán)節(jié)闽铐，更加安全蝶怔。

*   安全

    SSL(安全套接層) TLS(傳輸層安全)

    以上兩者在傳輸層之上，對網(wǎng)絡(luò)連接進(jìn)行加密處理阳啥，保障數(shù)據(jù)的完整性，更加的安全财喳。

10.HTTPS的連接建立流程

HTTPS為了兼顧安全與效率察迟，同時使用了對稱加密和非對稱加密。在傳輸?shù)倪^程中會涉及到三個密鑰：

服務(wù)器端的公鑰和私鑰耳高，用來進(jìn)行非對稱加密

客戶端生成的隨機(jī)密鑰扎瓶，用來進(jìn)行對稱加密
image
如上圖，HTTPS連接過程大致可分為八步:

1泌枪、客戶端訪問HTTPS連接概荷。

客戶端會把安全協(xié)議版本號、客戶端支持的加密算法列表碌燕、隨機(jī)數(shù)C發(fā)給服務(wù)端误证。

2、服務(wù)端發(fā)送證書給客戶端

服務(wù)端接收密鑰算法配件后修壕，會和自己支持的加密算法列表進(jìn)行比對愈捅，如果不符合，則斷開連接慈鸠。否則蓝谨，服務(wù)端會在該算法列表中，選擇一種對稱算法（如AES）青团、一種公鑰算法（如具有特定秘鑰長度的RSA）和一種MAC算法發(fā)給客戶端譬巫。

服務(wù)器端有一個密鑰對，即公鑰和私鑰督笆，是用來進(jìn)行非對稱加密使用的芦昔，服務(wù)器端保存著私鑰，不能將其泄露娃肿，公鑰可以發(fā)送給任何人烟零。

在發(fā)送加密算法的同時還會把數(shù)字證書和隨機(jī)數(shù)S發(fā)送給客戶端

3瘪松、客戶端驗證server證書

會對server公鑰進(jìn)行檢查，驗證其合法性锨阿，如果發(fā)現(xiàn)發(fā)現(xiàn)公鑰有問題宵睦，那么HTTPS傳輸就無法繼續(xù)。

4墅诡、客戶端組裝會話秘鑰

如果公鑰合格壳嚎，那么客戶端會用服務(wù)器公鑰來生成一個前主秘鑰(Pre-Master Secret，PMS)末早，并通過該前主秘鑰和隨機(jī)數(shù)C烟馅、S來組裝成會話秘鑰

5、客戶端將前主秘鑰加密發(fā)送給服務(wù)端

是通過服務(wù)端的公鑰來對前主秘鑰進(jìn)行非對稱加密然磷，發(fā)送給服務(wù)端

6郑趁、服務(wù)端通過私鑰解密得到前主秘鑰

服務(wù)端接收到加密信息后，用私鑰解密得到主秘鑰姿搜。

7寡润、服務(wù)端組裝會話秘鑰

服務(wù)端通過前主秘鑰和隨機(jī)數(shù)C、S來組裝會話秘鑰舅柜。

至此梭纹，服務(wù)端和客戶端都已經(jīng)知道了用于此次會話的主秘鑰。

8致份、數(shù)據(jù)傳輸

客戶端收到服務(wù)器發(fā)送來的密文变抽，用客戶端密鑰對其進(jìn)行對稱解密，得到服務(wù)器發(fā)送的數(shù)據(jù)氮块。

同理绍载，服務(wù)端收到客戶端發(fā)送來的密文，用服務(wù)端密鑰對其進(jìn)行對稱解密滔蝉，得到客戶端發(fā)送的數(shù)據(jù)逛钻。

11.解釋一下 三次握手 和 四次揮手

三次握手

1.由客戶端向服務(wù)端發(fā)送 SYN 同步報文。

2.當(dāng)服務(wù)端收到 SYN 同步報文之后锰提，會返回給客戶端 SYN 同步報文和 ACK 確認(rèn)報文曙痘。

3.客戶端會向服務(wù)端發(fā)送 ACK 確認(rèn)報文，此時客戶端和服務(wù)端的連接正式建立立肘。

建立連接

1.這個時候客戶端就可以通過 Http 請求報文边坤，向服務(wù)端發(fā)送請求

2.服務(wù)端接收到客戶端的請求之后，向客戶端回復(fù) Http 響應(yīng)報文谅年。

四次揮手

當(dāng)客戶端和服務(wù)端的連接想要斷開的時候茧痒，要經(jīng)歷四次揮手的過程，步驟如下：

1.先由客戶端向服務(wù)端發(fā)送 FIN 結(jié)束報文融蹂。

2.服務(wù)端會返回給客戶端 ACK 確認(rèn)報文 旺订。此時弄企，由客戶端發(fā)起的斷開連接已經(jīng)完成。

3.服務(wù)端會發(fā)送給客戶端 FIN 結(jié)束報文 和 ACK 確認(rèn)報文区拳。

4.客戶端會返回 ACK 確認(rèn)報文到服務(wù)端拘领，至此，由服務(wù)端方向的斷開連接已經(jīng)完成

12.TCP 和 UDP的區(qū)別

TCP：面向連接樱调、傳輸可靠(保證數(shù)據(jù)正確性,保證數(shù)據(jù)順序)约素、用于傳輸大量數(shù)據(jù)(流模式)、速度慢笆凌，建立連接需要開銷較多(時間圣猎，系統(tǒng)資源)。

UDP：面向非連接乞而、傳輸不可靠送悔、用于傳輸少量數(shù)據(jù)(數(shù)據(jù)包模式)、速度快爪模。

13.Cookie和Session

cookie

1.用戶與服務(wù)器的交互

cookie主要是用來記錄用戶狀態(tài)欠啤，區(qū)分用戶，狀態(tài)保存在客戶端呻右。cookie功能需要瀏覽器的支持跪妥。如果瀏覽器不支持cookie（如大部分手機(jī)中的瀏覽器）或者把cookie禁用了鞋喇，cookie功能就會失效声滥。
image
a).首次訪問amazon時，客戶端發(fā)送一個HTTP請求到服務(wù)器端 侦香。服務(wù)器端發(fā)送一個HTTP響應(yīng)到客戶端落塑，其中包含Set-Cookie頭部

b).客戶端發(fā)送一個HTTP請求到服務(wù)器端，其中包含Cookie頭部罐韩。服務(wù)器端發(fā)送一個HTTP響應(yīng)到客戶端

c).隔段時間再去訪問時憾赁，客戶端會直接發(fā)包含Cookie頭部的HTTP請求。服務(wù)器端發(fā)送一個HTTP響應(yīng)到客戶端

2.cookie的修改和刪除

在修改cookie的時候散吵，只需要新cookie覆蓋舊cookie即可龙考，在覆蓋的時候，由于Cookie具有不可跨域名性矾睦，注意name晦款、path、domain需與原cookie一致

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

3、cookie的安全

事實上赁温，cookie的使用存在爭議坛怪，因為它被認(rèn)為是對用戶隱私的一種侵害淤齐，而且cookie并不安全

HTTP協(xié)議不僅是無狀態(tài)的，而且是不安全的袜匿。使用HTTP協(xié)議的數(shù)據(jù)不經(jīng)過任何加密就直接在網(wǎng)絡(luò)上傳播更啄，有被截獲的可能。使用HTTP協(xié)議傳輸很機(jī)密的內(nèi)容是一種隱患沉帮。

a).如果不希望Cookie在HTTP等非安全協(xié)議中傳輸锈死，可以設(shè)置Cookie的secure屬性為true。瀏覽器只會在HTTPS和SSL等安全協(xié)議中傳輸此類Cookie穆壕。

b).此外待牵，secure屬性并不能對Cookie內(nèi)容加密，因而不能保證絕對的安全性喇勋。如果需要高安全性缨该，需要在程序中對Cookie內(nèi)容加密、解密川背，以防泄密贰拿。

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

Session

Session是服務(wù)器端使用的一種記錄客戶端狀態(tài)的機(jī)制，使用上比Cookie簡單一些缴允，相應(yīng)的也增加了服務(wù)器的存儲壓力荚守。

Session是另一種記錄客戶狀態(tài)的機(jī)制，不同的是Cookie保存在客戶端瀏覽器中练般，而Session保存在服務(wù)器上矗漾。 客戶端瀏覽器訪問服務(wù)器的時候，服務(wù)器把客戶端信息以某種形式記錄在服務(wù)器上薄料。這就是Session敞贡。客戶端瀏覽器再次訪問時只需要從該Session中查找該客戶的狀態(tài)就可以了摄职。
image
*   如圖：

    當(dāng)程序需要為某個客戶端的請求創(chuàng)建一個session時誊役，服務(wù)器首先檢查這個客戶端的請求里是否已包含了一個session標(biāo)識（稱為SessionId）

    如果已包含則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照SessionId把這個session檢索出來谷市，使用（檢索不到蛔垢，會新建一個）

    如果客戶端請求不包含SessionId，則為此客戶端創(chuàng)建一個session并且生成一個與此session相關(guān)聯(lián)的SessionId歌懒，SessionId的值應(yīng)該是一個既不會重復(fù)啦桌，又不容易被找到規(guī)律以仿造的字符串，這個SessionId將被在本次響應(yīng)中返回給客戶端保存。

    保存這個SessionId的方式可以采用cookie甫男，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標(biāo)識發(fā)送給服務(wù)器且改。但cookie可以被人為的禁止，則必須有其他機(jī)制以便在cookie被禁止時仍然能夠把SessionId傳遞回服務(wù)器板驳。

Cookie 和Session 的區(qū)別：

*   1又跛、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上若治。

*   2慨蓝、cookie相比session不是很安全，別人可以分析存放在本地的cookie并進(jìn)行cookie欺騙,考慮到安全應(yīng)當(dāng)使用session端幼。

*   3礼烈、session會在一定時間內(nèi)保存在服務(wù)器上。當(dāng)訪問增多婆跑，會比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面此熬，應(yīng)當(dāng)使用cookie。

*   4滑进、單個cookie保存的數(shù)據(jù)不能超過4K犀忱，很多瀏覽器都限制一個站點最多保存20個cookie。而session存儲在服務(wù)端扶关，可以無限量存儲

*   5阴汇、所以：將登錄信息等重要信息存放為session;其他信息如果需要保留，可以放在cookie中

## [#](https://ios.nobady.cn/Network.html#_7-dns%E6%98%AF%E4%BB%80%E4%B9%88)

14.DNS是什么

因特網(wǎng)上的主機(jī)节槐，可以使用多種方式標(biāo)識搀庶，比如主機(jī)名或IP地址。一種標(biāo)識方法就是用它的主機(jī)名（hostname）疯淫，比如·www.baidu.com地来、www.google.com戳玫、gaia.cs.umass.edu等熙掺。這方式方便人們記憶和接受，但是這種長度不一咕宿、沒有規(guī)律的字符串路由器并不方便處理币绩。還有一種方式，就是直接使用定長的府阀、有著清晰層次結(jié)構(gòu)的IP地址缆镣，路由器比較熱衷于這種方式。為了折衷這兩種方式试浙，我們需要一種能進(jìn)行主機(jī)名到IP地址轉(zhuǎn)換的目錄服務(wù)董瞻。這就是域名系統(tǒng)（Domain Name System，DNS）的主要任務(wù)。

*   DNS是：

    1钠糊、一個由分層的DNS服務(wù)器實現(xiàn)的分布式數(shù)據(jù)庫

    2挟秤、一個使得主機(jī)能夠查詢分布式數(shù)據(jù)庫的應(yīng)用層協(xié)議

*   DNS服務(wù)器通常是運行BIND軟件的UNIX機(jī)器，DNS協(xié)議運行在UDP上抄伍，使用53號端口

*   DNS通常是由其他應(yīng)用層協(xié)議所使用的艘刚，包括HTTP、SMTP等截珍。其作用則是：將用戶提供的主機(jī)名解析為IP地址

*   DNS的一種簡單設(shè)計就是在因特網(wǎng)上只使用一個DNS服務(wù)器攀甚，該服務(wù)器包含所有的映射。很明顯這種設(shè)計是有很大的問題的：

    單點故障：如果該DNS服務(wù)器崩潰岗喉，全世界的網(wǎng)絡(luò)隨之癱瘓

    通信容量：單個DNS服務(wù)器必須處理所有DNS查詢

    遠(yuǎn)距離的集中式數(shù)據(jù)庫：單個DNS服務(wù)器必須面對所有用戶秋度，距離過遠(yuǎn)會有嚴(yán)重的時延曲秉。

    維護(hù)：該數(shù)據(jù)庫過于龐大剿骨，還需要對新添加的主機(jī)頻繁更新。

所以螟碎，DNS被設(shè)計成了一個分布式诞丽、層次數(shù)據(jù)庫

15.DNS解析過程

以www.163.com為例:

客戶端打開瀏覽器鲸拥，輸入一個域名。比如輸入www.163.com僧免，這時刑赶，客戶端會發(fā)出一個DNS請求到本地DNS服務(wù)器。本地DNS服務(wù)器一般都是你的網(wǎng)絡(luò)接入服務(wù)器商提供懂衩，比如中國電信撞叨，中國移動。

查詢www.163.com的DNS請求到達(dá)本地DNS服務(wù)器之后浊洞，本地DNS服務(wù)器會首先查詢它的緩存記錄牵敷，如果緩存中有此條記錄，就可以直接返回結(jié)果法希。如果沒有枷餐，本地DNS服務(wù)器還要向DNS根服務(wù)器進(jìn)行查詢。

根DNS服務(wù)器沒有記錄具體的域名和IP地址的對應(yīng)關(guān)系苫亦，而是告訴本地DNS服務(wù)器毛肋，你可以到域服務(wù)器上去繼續(xù)查詢，并給出域服務(wù)器的地址屋剑。

本地DNS服務(wù)器繼續(xù)向域服務(wù)器發(fā)出請求润匙，在這個例子中，請求的對象是.com域服務(wù)器唉匾。.com域服務(wù)器收到請求之后孕讳，也不會直接返回域名和IP地址的對應(yīng)關(guān)系，而是告訴本地DNS服務(wù)器，你的域名的解析服務(wù)器的地址厂财。

最后油啤，本地DNS服務(wù)器向域名的解析服務(wù)器發(fā)出請求，這時就能收到一個域名和IP地址對應(yīng)關(guān)系蟀苛，本地DNS服務(wù)器不僅要把IP地址返回給用戶電腦益咬，還要把這個對應(yīng)關(guān)系保存在緩存中，以備下次別的用戶查詢時帜平，可以直接返回結(jié)果幽告，加快網(wǎng)絡(luò)訪問

16.UIView動畫與核心動畫的區(qū)別?

核心動畫只作用在layer
核心動畫修改的值都是假象 它的真實位置沒有發(fā)生變化
當(dāng)需要與用戶進(jìn)行交互時用UIView動畫 不需要與用戶進(jìn)行交互時兩個都可以

17.當(dāng)我們要做一些基于 CALayer 的動畫時，有時需要設(shè)置 layer 的錨點來配合動畫裆甩，這時候我們需要注意什么

設(shè)置秒點可能會引起原來position的變化

// 為 layer 的動畫設(shè)置不同的 anchor point冗锁，但是又不想改變 view 原來的 position，則需要做一些轉(zhuǎn)換嗤栓。
- (void)setAnchorPoint:(CGPoint)anchorPoint forView:(UIView *)view {
    // 分別計算原來錨點和將更新的錨點對應(yīng)的坐標(biāo)點冻河，這些坐標(biāo)點是相對該 view 內(nèi)部坐標(biāo)系的。
    CGPoint oldPoint = CGPointMake(view.bounds.size.width * view.layer.anchorPoint.x,
                                   view.bounds.size.height * view.layer.anchorPoint.y);
    CGPoint newPoint = CGPointMake(view.bounds.size.width * anchorPoint.x,
                                   view.bounds.size.height * anchorPoint.y);
    
    // 如果當(dāng)前 view 有做過 transform茉帅，這里要同步計算叨叙。
    oldPoint = CGPointApplyAffineTransform(oldPoint, view.transform);
    newPoint = CGPointApplyAffineTransform(newPoint, view.transform);
    
    // position 是當(dāng)前 view 的 anchor point 在其父 view 的位置。
    CGPoint position = view.layer.position;
    // anchor point 的改變會造成 position 的改變堪澎，從而影響 view 在其父 view 的位置擂错，這里把這個位移給計算回來。
    position.x = position.x + newPoint.x - oldPoint.x;
    position.y = position.y + newPoint.y - oldPoint.y;
    
    view.translatesAutoresizingMaskIntoConstraints = YES;
    view.layer.anchorPoint = anchorPoint; // 設(shè)置了新的 anchor point 會改變位置樱蛤。
    view.layer.position = position; // 通過在 position 上做逆向偏移钮呀，把位置給移回來。
}

18.如何計算圖片加載內(nèi)存中所占的大小

圖片內(nèi)存大小的計算公式 寬度 * 高度 * bytesPerPixel/8昨凡。

bytesPerPixel : 每個像素所占的字節(jié)數(shù)爽醋。

RGBA顏色空間下 每個顏色分量由32位組成

所以一般圖片的計算公式是 wxhx4

19.isa指針有哪兩種類型？

純指針便脊，指向內(nèi)存地址
NON_POINTER_ISA蚂四，除了內(nèi)存地址，還存有一些其他信息

20.Objective-C 如何實現(xiàn)多重繼承就轧？

Object-c的類沒有多繼承,只支持單繼承,如果要實現(xiàn)多繼承的話证杭，可使用如下幾種方式間接實現(xiàn)
*   通過組合實現(xiàn)
    A和B組合田度，作為C類的組件

*   通過協(xié)議實現(xiàn)
    C類實現(xiàn)A和B類的協(xié)議方法

*   消息轉(zhuǎn)發(fā)實現(xiàn)
    forwardInvocation:方法

21.runtime 如何實現(xiàn) weak 屬性妒御？

weak 此特質(zhì)表明該屬性定義了一種「非擁有關(guān)系」(nonowning relationship)。為這種屬性設(shè)置新值時镇饺，設(shè)置方法既不持有新值（新指向的對象）乎莉，也不釋放舊值（原來指向的對象）。

runtime 對注冊的類，會進(jìn)行內(nèi)存布局惋啃，從一個粗粒度的概念上來講哼鬓，這時候會有一個 hash 表，這是一個全局表边灭，表中是用 weak 指向的對象內(nèi)存地址作為 key异希，用所有指向該對象的 weak 指針表作為 value。當(dāng)此對象的引用計數(shù)為 0 的時候會 dealloc绒瘦，假如該對象內(nèi)存地址是 a称簿，那么就會以 a 為 key，在這個 weak 表中搜索惰帽，找到所有以 a 為鍵的 weak 對象憨降，從而設(shè)置為 nil。

runtime 如何實現(xiàn) weak 屬性具體流程大致分為 3 步：

1该酗、初始化時：runtime 會調(diào)用 objc_initWeak 函數(shù)授药，初始化一個新的 weak 指針指向?qū)ο蟮牡刂贰?
2、添加引用時：objc_initWeak 函數(shù)會調(diào)用 objc_storeWeak() 函數(shù)呜魄，objc_storeWeak() 的作用是更新指針指向（指針可能原來指向著其他對象悔叽，這時候需要將該 weak 指針與舊對象解除綁定，會調(diào)用到 weak_unregister_no_lock）爵嗅，如果指針指向的新對象非空骄蝇，則創(chuàng)建對應(yīng)的弱引用表，將 weak 指針與新對象進(jìn)行綁定操骡，會調(diào)用到 weak_register_no_lock九火。在這個過程中，為了防止多線程中競爭沖突册招，會有一些鎖的操作岔激。

3、釋放時：調(diào)用 clearDeallocating 函數(shù)是掰，clearDeallocating 函數(shù)首先根據(jù)對象地址獲取所有 weak 指針地址的數(shù)組虑鼎，然后遍歷這個數(shù)組把其中的數(shù)據(jù)設(shè)為 nil，最后把這個 entry 從 weak 表中刪除键痛，最后清理對象的記錄

22.runtime如何通過selector找到對應(yīng)的IMP地址炫彩？

每一個類對象中都一個對象方法列表（對象方法緩存）

類方法列表是存放在類對象中isa指針指向的元類對象中（類方法緩存）。

方法列表中每個方法結(jié)構(gòu)體中記錄著方法的名稱,方法實現(xiàn),以及參數(shù)類型絮短，其實selector本質(zhì)就是方法名稱,通過這個方法名稱就可以在方法列表中找到對應(yīng)的方法實現(xiàn)江兢。

當(dāng)我們發(fā)送一個消息給一個NSObject對象時，這條消息會在對象的類對象方法列表里查找丁频。

當(dāng)我們發(fā)送一個消息給一個類時杉允，這條消息會在類的Meta Class對象的方法列表里查找邑贴。

23.怎么理解Objective-C是動態(tài)運行時語言

主要是將數(shù)據(jù)類型的確定由編譯時,推遲到了運行時 
簡單來說 運行時機(jī)制使我們直到運行時才去決定一個對象的類別 以及調(diào)用該類別對象指定方法
多態(tài): 不同對象以自己的方式響應(yīng)相同的消息的能力叫做多態(tài)

24.對稱加密和非對稱加密的區(qū)別？

1叔磷、對稱加密又稱公開密鑰加密拢驾，加密和解密都會用到同一個密鑰，如果密鑰被攻擊者獲得改基，此時加密就失去了意義
常見的對稱加密算法有DES繁疤、3DES、AES秕狰、Blowfish嵌洼、IDEA、RC5封恰、RC6麻养。
2、非對稱加密又稱共享密鑰加密诺舔，使用一對非對稱的密鑰鳖昌，一把叫做私有密鑰，另一把叫做公有密鑰低飒；公鑰加密只
能用私鑰來解密许昨，私鑰加密只能用公鑰來解密。常見的公鑰加密算法有：RSA褥赊、ElGamal糕档、背包算法、Rabin（RSA的特例）拌喉、
迪菲－赫爾曼密鑰交換協(xié)議中的公鑰加密算法速那、橢圓曲線加密算法）

25簡述 SSL 加密的過程用了哪些加密方法，為何這么作

SSL 加密尿背，在過程中實際使用了 對稱加密 和 非對稱加密 的結(jié)合端仰。主要的考慮是先使用 非對稱加密 進(jìn)行連接，
這樣做是為了避免中間人攻擊秘鑰被劫持田藐，但是 非對稱加密 的效率比較低荔烧。所以一旦建立了安全的連接之后，就
可以使用輕量的 對稱加密

26.iOS的簽名機(jī)制是怎么樣的

簽名機(jī)制：

先將應(yīng)用內(nèi)容通過摘要算法汽久，得到摘要

再用私鑰對摘要進(jìn)行加密得到密文

將源文本鹤竭、密文、和私鑰對應(yīng)的公鑰一并發(fā)布

驗證流程：

查看公鑰是否是私鑰方的

然后用公鑰對密文進(jìn)行解密得到摘要

將APP用同樣的摘要算法得到摘要景醇，兩個摘要進(jìn)行比對臀稚，如果相等那么一切正常
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市啡直，隨后出現(xiàn)的幾起案子烁涌，更是在濱河造成了極大的恐慌苍碟，老刑警劉巖酒觅，帶你破解...
    沈念sama閱讀 207,248評論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件撮执，死亡現(xiàn)場離奇詭異，居然都是意外死亡舷丹，警方通過查閱死者的電腦和手機(jī)抒钱，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,681評論 2贊 381
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來颜凯，“玉大人谋币，你說我怎么就攤上這事≈⒏牛” “怎么了蕾额？”我有些...
    開封第一講書人閱讀 153,443評論 0贊 344
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長彼城。 經(jīng)常有香客問我诅蝶，道長，這世上最難降的妖魔是什么募壕？ 我笑而不...
    開封第一講書人閱讀 55,475評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任调炬，我火速辦了婚禮，結(jié)果婚禮上舱馅，老公的妹妹穿的比我還像新娘缰泡。我一直安慰自己，他們只是感情好代嗤，可當(dāng)我...
    茶點故事閱讀 64,458評論 5贊 374
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布棘钞。 她就那樣靜靜地躺著，像睡著了一般干毅。 火紅的嫁衣襯著肌膚如雪武翎。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,185評論 1贊 284
  • 城市分裂傳說
    那天溶锭，我揣著相機(jī)與錄音宝恶，去河邊找鬼。 笑死趴捅，一個胖子當(dāng)著我的面吹牛垫毙，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播拱绑，決...
    沈念sama閱讀 38,451評論 3贊 401
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼综芥，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了猎拨？” 一聲冷哼從身側(cè)響起膀藐，我...
    開封第一講書人閱讀 37,112評論 0贊 261
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤屠阻，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后额各，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體国觉，經(jīng)...
    沈念sama閱讀 43,609評論 1贊 300
  • ?護(hù)林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,083評論 2贊 325
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年虾啦，在試婚紗的時候發(fā)現(xiàn)自己被綠了麻诀。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,163評論 1贊 334
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡傲醉，死狀恐怖蝇闭，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情硬毕，我是刑警寧澤呻引，帶...
    沈念sama閱讀 33,803評論 4贊 323
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站吐咳，受9級特大地震影響逻悠，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜挪丢，卻給世界環(huán)境...
    茶點故事閱讀 39,357評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一蹂风、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧乾蓬，春花似錦惠啄、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,357評論 0贊 19
  • 一樁弒父案撵渡，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至死嗦，卻和暖如春趋距，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背越除。 一陣腳步聲響...
    開封第一講書人閱讀 31,590評論 1贊 261
  • 情欲美人皮
    我被黑心中介騙來泰國打工节腐， 沒想到剛下飛機(jī)就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人摘盆。 一個月前我還...
    沈念sama閱讀 45,636評論 2贊 355
  • 代替公主和親
    正文 我出身青樓翼雀，卻偏偏與公主長得像，于是被迫代替她去往敵國和親孩擂。 傳聞我的和親對象是個殘疾皇子狼渊，可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 42,925評論 2贊 344