李洪强经典面试题146-网络
李洪強(qiáng)經(jīng)典面試題146-網(wǎng)絡(luò)
?網(wǎng)絡(luò)
http請(qǐng)求方式？
通常，HTTP的請(qǐng)求方式有3種，分別是：POST、GET、HEAD。POST和GET方法是用于數(shù)據(jù)發(fā)送的。
POST：它將要發(fā)送的數(shù)據(jù)單獨(dú)放在一個(gè)流中進(jìn)行發(fā)送，而不是附加在URL地址后面，這樣做的好處是這些數(shù)據(jù)不會(huì)出現(xiàn)在URL地址中。
GET：它將要發(fā)送的數(shù)據(jù)直接添加在URL后面，如：www.sina.com.cn?username=""&password=""，這樣的好處是可以直接將數(shù)據(jù)加在URL后，而不需在用另外的流來發(fā)送這些數(shù)據(jù)，但是缺點(diǎn)也顯而易見，它將用戶的信息顯示出來了。
HEAD：它是請(qǐng)求資源的元數(shù)據(jù)方法。在具體的應(yīng)用中，我暫時(shí)還沒遇到過，也不去對(duì)它進(jìn)行研究，需要是在學(xué)習(xí)。
Http定義了與服務(wù)器交互的不同方法，最基本的方法有？
-
URL全稱是資源描述符，我們可以這樣認(rèn)為：一個(gè)URL地址，它用于描述一個(gè)網(wǎng)絡(luò)上的資源，而HTTP中的GET，POST，PUT，DELETE就對(duì)應(yīng)著對(duì)這個(gè)資源的查，改，增，刪4個(gè)操作。
-
GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。
socket編程簡述
它是基于TCP/IP協(xié)議，Socket就是一個(gè)可以連通網(wǎng)絡(luò)上不同計(jì)算機(jī)程序之間的管道，把一堆數(shù)據(jù)從管道的A端扔進(jìn)去，則會(huì)從管道的B端（也許同時(shí)還可以從C、D、E、F……端冒出來）。管道的端口由兩個(gè)因素來唯一確認(rèn)，即機(jī)器的IP地址和程序所使用的端口號(hào)。
Socket可以支持?jǐn)?shù)據(jù)的發(fā)送和接收，它會(huì)定義一種稱為套接字的變量，發(fā)送數(shù)據(jù)時(shí)首先創(chuàng)建套接字，然后使用該套接字的sendto等方法對(duì)準(zhǔn)某個(gè)IP/端口進(jìn)行數(shù)據(jù)發(fā)送；接收端也首先創(chuàng)建套接字，然后將該套接字綁定到一個(gè)IP/端口上，所有發(fā)向此端口的數(shù)據(jù)會(huì)被該套接字的recv等函數(shù)讀出。如同讀出文件中的數(shù)據(jù)一樣。
TCP/IP的socket提供下列三種類型套接字。 流式套接字、數(shù)據(jù)報(bào)式套接字、原始式套接字。
客戶端編程步驟：
1：加載套接字庫，創(chuàng)建套接字(WSAStartup()/socket())；
??2：向服務(wù)器發(fā)出連接請(qǐng)求(connect())；
??3：和服務(wù)器端進(jìn)行通信(send()/recv())；
??4：關(guān)閉套接字，關(guān)閉加載的套接字庫(closesocket()/WSACleanup())。
常用第三方庫：1，Asyncsocket庫
asihttp代碼原理，異步請(qǐng)求的原理，異步請(qǐng)求最大數(shù)目，為什么只能這么多？
ASIHTTPRequest是一個(gè)簡易使用的類庫,通過包裝CFNetwork API 來簡化 和服務(wù)器端的通訊. 它編寫的語言是Objective-C 能夠應(yīng)用于Mac OS X and iPhone 平臺(tái)的應(yīng)用程序.
異步: 請(qǐng)求通過事件觸發(fā)->服務(wù)器處理（這是瀏覽器仍然可以作其他事情）->處理完畢這個(gè)數(shù)量是跟cpu有關(guān)的,并發(fā)性取決于cpu核數(shù),每個(gè)核只能同時(shí)處理一個(gè)任務(wù).4核cpu理論上可以并發(fā)處理4個(gè)任務(wù),如果按http來算就是4個(gè)請(qǐng)求,但是cpu是搶占式資源,所以一般來說并發(fā)量是要根據(jù)任務(wù)的耗時(shí)和cpu的繁忙度來計(jì)算4個(gè)左右只是個(gè)經(jīng)驗(yàn)值你開10個(gè)短耗時(shí)的任務(wù)和幾個(gè)長耗時(shí)任務(wù)的效率是不同的。
JSONKit、SBJson、TouchJSON和原生的區(qū)別?
JSONKit、SBJson、TouchJSON（性能從左到右，越右越差,主要就是性能上的差別）
App需要加載超大量的數(shù)據(jù)，給服務(wù)器發(fā)送請(qǐng)求，但是服務(wù)器卡住了如何解決？
1> 設(shè)置請(qǐng)求超時(shí)
2> 給用戶提示請(qǐng)求超時(shí)
3> 根據(jù)用戶操作再次請(qǐng)求數(shù)據(jù)
HTTP的通信的 發(fā)送請(qǐng)求、接收響應(yīng) 包含哪些內(nèi)容？OC中是怎樣實(shí)現(xiàn)的？
GET /XXServer/resources/images/1.jpg HTTP/1.1
請(qǐng)求頭：包含了對(duì)客戶端的環(huán)境描述、客戶端請(qǐng)求的主機(jī)地址等信息
- Host: 192.168.1.105:8080 // 客戶端想訪問的服務(wù)器主機(jī)地址
- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9) Firefox/30.0
// 客戶端的類型，客戶端的軟件環(huán)境 - Accept: text/html,?/?// 客戶端所能接收的數(shù)據(jù)類型
- Accept-Language: zh-cn // 客戶端的語言環(huán)境
- Accept-Encoding: gzip // 客戶端支持的數(shù)據(jù)壓縮格式
- 請(qǐng)求體：客戶端發(fā)給服務(wù)器的具體數(shù)據(jù)，比如文件數(shù)據(jù)
- OC中請(qǐng)求NSURLRequest
- 發(fā)送給服務(wù)器的請(qǐng)求包含：
- 請(qǐng)求行： 包含了請(qǐng)求方法、請(qǐng)求資源路徑、HTTP協(xié)議版本
- 請(qǐng)求頭： 對(duì)客戶端的環(huán)境描述、客戶端請(qǐng)求的主機(jī)地址等信息
- 請(qǐng)求體： 客戶端發(fā)給服務(wù)器的具體數(shù)據(jù)
- 默認(rèn)超時(shí)時(shí)常：60s
- 響應(yīng)：
- 一個(gè)響應(yīng)包括：
- 狀態(tài)行：包含了HTTP協(xié)議版本、狀態(tài)碼、狀態(tài)英文名稱 HTTP/1.1 200 OK
- 響應(yīng)頭：包含了對(duì)服務(wù)器的描述、對(duì)返回?cái)?shù)據(jù)的描述
- Server: Apache-Coyote/1.1 // 服務(wù)器的類型
- Content-Type: image/jpeg // 返回?cái)?shù)據(jù)的類型
- Content-Length: 56811 // 返回?cái)?shù)據(jù)的長度
- Date: Mon, 23 Jun 2014 12:54:52 GMT // 響應(yīng)的時(shí)間
- 實(shí)體內(nèi)容：服務(wù)器返回給客戶端的具體數(shù)據(jù)，比如文件數(shù)據(jù)
-
OC中響應(yīng)用NSURLRespose：返回給客戶端的回應(yīng)包含：
- 狀態(tài)行 ： 包含了HTTP協(xié)議版本、狀態(tài)碼、狀態(tài)英文名稱
- 響應(yīng)頭 ： 包含了對(duì)服務(wù)器的描述、對(duì)返回?cái)?shù)據(jù)的描述
-
實(shí)體內(nèi)容：服務(wù)器返回給客戶端的具體二進(jìn)制數(shù)據(jù)
-
常用屬性： expectedContentLength （下載時(shí)返回文件的長度）
suggestedFilename（建議保存的文件名）
http 的post與get區(qū)別與聯(lián)系，實(shí)踐中如何選擇它們？
| 用途 | 從服務(wù)器上獲取數(shù)據(jù) | 向服務(wù)器傳送數(shù)據(jù)提交方式 |
| 服務(wù)器解析 | Request.QueryString獲取變量的值 | Request.Form獲取提交的數(shù)據(jù) |
| 數(shù)據(jù)大小 | 最大1024字節(jié) | 無限制 |
| 安全性 | URL中能看到提交的數(shù)據(jù) | 隱藏在請(qǐng)求頭中 |
知道TCP/UDP嗎？說說關(guān)于UDP/TCP的區(qū)別？
- UDP: 是用戶數(shù)據(jù)報(bào)協(xié)議: 主要用在實(shí)時(shí)性要求高以及對(duì)質(zhì)量相對(duì)較弱的地方,但面對(duì)現(xiàn)在高質(zhì)量的線路不是容易丟包除非是一些擁塞條件下, 如流媒體
- TCP: 是傳輸控制協(xié)議:是面連接的,那么運(yùn)行環(huán)境必然要求其可靠性不可丟包有良好的擁塞控制機(jī)制如http ftp telnet 等
| 發(fā)送與接收 | 安全送達(dá) | 只管發(fā)送 |
| 建立連接 | 是（三次握手） | 否（有數(shù)據(jù)包，無需連接） |
| 數(shù)據(jù)大小 | 無限制 | 每個(gè)數(shù)據(jù)報(bào)64k |
| 可靠性 | 可靠 | 不可靠 |
| 速度 | 慢（三次握手才能完成連接 | 快（無需連接） |
| 應(yīng)用 | 流媒體 |
什么是三次握手與四次揮手？
-
三次握手實(shí)現(xiàn)的過程：
- 第一次握手：建立連接時(shí)，客戶端發(fā)送同步序列編號(hào)到服務(wù)器，并進(jìn)入發(fā)送狀態(tài)，等待服務(wù)器確認(rèn)
- 第二次：服務(wù)器收到同步序列編號(hào)，確認(rèn)并同時(shí)自己也發(fā)送一個(gè)同步序列編號(hào)+確認(rèn)標(biāo)志，此時(shí)服務(wù)器進(jìn)入接收狀態(tài)
- 第三次：客戶端收到服務(wù)器發(fā)送的包，并向服務(wù)器發(fā)送確認(rèn)標(biāo)志，隨后鏈接成功。
- 注意：是在鏈接成功后在進(jìn)行數(shù)據(jù)傳輸。
-
四次揮手：
- 第一次： 客戶端向服務(wù)器發(fā)送一個(gè)帶有結(jié)束標(biāo)記的報(bào)文。
- 第二次：服務(wù)器收到報(bào)文后，向客戶端發(fā)送一個(gè)確認(rèn)序號(hào)，同時(shí)通知自己相應(yīng)的應(yīng)用程序：對(duì)方要求關(guān)閉連接
- 第三次： 服務(wù)器向客戶端發(fā)送一個(gè)帶有結(jié)束標(biāo)記的報(bào)文。
- 第四次： 客戶端收到報(bào)文后，向服務(wù)器發(fā)送一個(gè)確認(rèn)序號(hào)。鏈接關(guān)閉。
分析json、xml的區(qū)別?json、xml解析方式的底層是如何處理的?
Json與xml的區(qū)別:
- 可讀性方面:基本相同,xml的可讀性比較好
- 可擴(kuò)展性方面:都具有很好的擴(kuò)展性
- 編碼難度方面:相對(duì)而言:JSON的編碼比較容易
- 解碼難度:json的解碼難度基本為零,xml需要考慮子節(jié)點(diǎn)和父節(jié)點(diǎn)
- 數(shù)據(jù)體積方面:json相對(duì)于xml來講,數(shù)據(jù)體積小,傳遞的速度跟快些
- 數(shù)據(jù)交互方面:json與JavaScript的交互更加方面,更容易解析處理,更好的數(shù)據(jù)交互
- 數(shù)據(jù)描述方面:xml對(duì)數(shù)據(jù)描述性比較好
- 傳輸速度方面:json的速度遠(yuǎn)遠(yuǎn)快于xml
JSON底層原理:
- 遍歷字符串中的字符,最終根據(jù)格式規(guī)定的特殊字符,比如{}號(hào),[]號(hào), : 號(hào) 等進(jìn)行區(qū)分,{}號(hào)是一個(gè)字典 的開始,[]號(hào)是一個(gè)數(shù)組的開始, : 號(hào)是字典的鍵和值的分水嶺,最終乃是將json數(shù)據(jù)轉(zhuǎn)化為字典,字典中值可能是字典,數(shù)組,或字符串而已。
XML底層原理:
- XML解析常用的解析方法有兩種:DOM解析和SAX解析。
- DOM 采用建立樹形結(jié)構(gòu)的方式訪問 XML 文檔,而 SAX 采用的事件模型。
- DOM 解析把 XML 文檔轉(zhuǎn)化為一個(gè)包含其內(nèi)容的樹,并可以對(duì)樹進(jìn)行遍歷。
- 使用 DOM 解析器的時(shí)候需 要處理整個(gè) XML 文檔,所以對(duì)性能和內(nèi)存的要求比較高。
- SAX在解析 XML 文檔的時(shí)候可以觸發(fā)一系列的事件,當(dāng)發(fā)現(xiàn)給定的tag的時(shí)候,它可以激活一個(gè)回調(diào)方法,告訴該方法制定的標(biāo)簽已經(jīng)找到。
- SAX 對(duì)內(nèi)存的要求通常會(huì)比較低,因?yàn)樗岄_發(fā)人員自己來決定所要處理的tag。特別是當(dāng)開發(fā)人員只需要處理文檔中所包含的部分?jǐn)?shù)據(jù)時(shí),SAX 這種擴(kuò)展能力得到了更好的體現(xiàn)。
http和scoket通信的區(qū)別?socket連接相關(guān)庫,TCP,UDP的連接方法,HTTP的幾種常用方式?
- http是客戶端用http協(xié)議進(jìn)行請(qǐng)求,發(fā)送請(qǐng)求時(shí)候需要封裝http請(qǐng)求頭,并綁定請(qǐng)求的數(shù)據(jù),服務(wù)器一般有web服務(wù)器配合(當(dāng)然也非絕對(duì))。 http請(qǐng)求方式為客戶端主動(dòng)發(fā)起請(qǐng)求,服務(wù)器才能給響應(yīng),一次請(qǐng)求完畢后則斷開連接,以節(jié)省資源。服務(wù)器不能主動(dòng)給客戶端響應(yīng)(除非采取http長連接技術(shù))。iphone主要使用類是NSUrlConnection。
- scoket是客戶端跟服務(wù)器直接使用socket“套接字”進(jìn)行連接,并沒有規(guī)定連接后斷開,所以客戶端和服務(wù)器可以保持連接通道,雙方都可以主動(dòng)發(fā)送數(shù)據(jù)。一般在游戲開發(fā)或股票開發(fā)這種要求即時(shí)性很強(qiáng)并且保持發(fā)送數(shù)據(jù)量比較大的場(chǎng)合使用。主要使用類是CFSocketRef。
通信底層原理（OSI七層模型）
-
OSI簡介：OSI采用了分層的結(jié)構(gòu)化技術(shù)，共分七層，物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層、應(yīng)用層。
-
物理層：主要定義物理設(shè)備標(biāo)準(zhǔn)，如網(wǎng)線的接口類型、光纖的接口類型、各種傳輸介質(zhì)的傳輸速率等。它的主要作用是傳輸比特流（就是由1、0轉(zhuǎn)化為電流強(qiáng)弱來進(jìn)行傳輸,到達(dá)目的地后在轉(zhuǎn)化為1、0，也就是我們常說的數(shù)模轉(zhuǎn)換與模數(shù)轉(zhuǎn)換）。這一層的數(shù)據(jù)叫做比特。
-
數(shù)據(jù)鏈路層：定義了如何讓格式化數(shù)據(jù)以進(jìn)行傳輸，以及如何讓控制對(duì)物理介質(zhì)的訪問。這一層通常還提供錯(cuò)誤檢測(cè)和糾正，以確保數(shù)據(jù)的可靠傳輸。
-
網(wǎng)絡(luò)層：：在位于不同地理位置的網(wǎng)絡(luò)中的兩個(gè)主機(jī)系統(tǒng)之間提供連接和路徑選擇。Internet的發(fā)展使得從世界各站點(diǎn)訪問信息的用戶數(shù)大大增加，而網(wǎng)絡(luò)層正是管理這種連接的層。
-
傳輸層：定義了一些傳輸數(shù)據(jù)的協(xié)議和端口號(hào)（WWW端口80等），如：TCP（傳輸控制協(xié)議，傳輸效率低，可靠性強(qiáng)，用于傳輸可靠性要求高，數(shù)據(jù)量大的數(shù)據(jù)），UDP（用戶數(shù)據(jù)報(bào)協(xié)議，與TCP特性恰恰相反，用于傳輸可靠性要求不高，數(shù)據(jù)量小的數(shù)據(jù)，如QQ聊天數(shù)據(jù)就是通過這種方式傳輸?shù)?#xff09;。 主要是將從下層接收的數(shù)據(jù)進(jìn)行分段和傳輸，到達(dá)目的地址后再進(jìn)行重組。常常把這一層數(shù)據(jù)叫做段。
-
-
會(huì)話層：通過傳輸層（端口號(hào)：傳輸端口與接收端口）建立數(shù)據(jù)傳輸?shù)耐贰Ｖ饕谀愕南到y(tǒng)之間發(fā)起會(huì)話或者接受會(huì)話請(qǐng)求（設(shè)備之間需要互相認(rèn)識(shí)可以是IP也可以是MAC或者是主機(jī)名）
-
表示層：：可確保一個(gè)系統(tǒng)的應(yīng)用層所發(fā)送的信息可以被另一個(gè)系統(tǒng)的應(yīng)用層讀取。例如，PC程序與另一臺(tái)計(jì)算機(jī)進(jìn)行通信，其中一臺(tái)計(jì)算機(jī)使用擴(kuò)展二一十進(jìn)制交換碼（EBCDIC），而另一臺(tái)則使用美國信息交換標(biāo)準(zhǔn)碼（ASCII）來表示相同的字符。如有必要，表示層會(huì)通過使用一種通格式來實(shí)現(xiàn)多種數(shù)據(jù)格式之間的轉(zhuǎn)換。
-
應(yīng)用層：是最靠近用戶的OSI層。這一層為用戶的應(yīng)用程序（例如電子郵件、文件傳輸和終端仿真）提供網(wǎng)絡(luò)服務(wù)。
all people seem to need date processing這一句話的意思是所有的人似乎都需要處理數(shù)據(jù)
| Application | all |
| Presentation | people |
| Session | seem |
| Transport | to |
| Network | need |
| Data | date |
| Physical | processing |
設(shè)計(jì)一套大文件（如上百M(fèi)的視頻）下載方案
-
NSURLSession
-
支持?jǐn)帱c(diǎn)下載，自動(dòng)記錄停止下載時(shí)斷點(diǎn)的位置
- 遵守NSURLSessionDownloadDelegate協(xié)議
- 使用NSURLSession下載大文件，被下載文件會(huì)被自動(dòng)寫入沙盒的臨時(shí)文件夾tmp中
- 下載完畢，通常需要將已下載文件移動(dòng)其他位置（tmp文件夾中的數(shù)據(jù)被定時(shí)刪除），通常是cache文件夾中
-
下載步驟：
-
設(shè)置下載任務(wù)task的為成員變量
@property (nonatomic, strong) NSURLSessionDownloadTask *task;-
獲取NSURLSession對(duì)象
NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:[[NSOperationQueue alloc] init]];
-
初始化下載任務(wù)任務(wù)
self.task = [session downloadTaskWithURL:（此處為下載文件路徑URL）];
-
實(shí)現(xiàn)代理方法
/*每當(dāng)寫入數(shù)據(jù)到臨時(shí)文件的時(shí)候，就會(huì)調(diào)用一次該方法，通常在該方法中獲取下載進(jìn)度/
// 計(jì)算下載進(jìn)度CGFloat progress = 1.0 * totalBytesWritten / totalBytesExpectedToWrite;
-(void)URLSession:(NSURLSession?)session downloadTask: (NSURLSessionDownloadTask?)downloadTask didWriteData:(int64_t)bytesWritten totalBytesWritten:(int64_t)totalBytesWritten totalBytesExpectedToWrite:(int64_t)totalBytesExpectedToWrite
{}
/*任務(wù)終止時(shí)調(diào)用的方法，通常用于斷點(diǎn)下載/
//fileOffset：下載任務(wù)中止時(shí)的偏移量
-(void)URLSession:(NSURLSession?)session downloadTask:(NSURLSessionDownloadTask?)downloadTask didResumeAtOffset:(int64_t)fileOffset expectedTotalBytes:(int64_t)expectedTotalBytes
{}
/*遇到錯(cuò)誤的時(shí)候調(diào)用，error參數(shù)只能傳遞客戶端的錯(cuò)誤/
-(void)URLSession:(NSURLSession?)session task:(NSURLSessionTask?)task didCompleteWithError:(NSError *)error
{ }/*下載完成的時(shí)候調(diào)用，需要將文件剪切到可以長期保存的文件夾中/
//生成文件長期保存的路徑NSString *file = [[NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES) lastObject] stringByAppendingPathComponent:downloadTask.response.suggestedFilename]; //獲取文件句柄 NSFileManager *fileManager = [NSFileManager defaultManager]; //通過文件句柄，將文件剪切到文件長期保存的路徑 [fileManager moveItemAtURL:location toURL:[NSURL fileURLWithPath:file] error:nil];
-(void)URLSession:(NSURLSession?)session downloadTask:(NSURLSessionDownloadTask?)downloadTask didFinishDownloadingToURL:(NSURL *)location
{}
-
操作任務(wù)狀態(tài)
/*開始/繼續(xù)下載任務(wù)/
[self.task resume];/*暫停下載任務(wù)/
[self.task suspend];
-
-
HTTP協(xié)議的特點(diǎn)，關(guān)于HTTP請(qǐng)求GET和POST的區(qū)別?
HTTP協(xié)議的特點(diǎn): - HTTP超文本傳輸協(xié)議，是短連接，是客戶端主動(dòng)發(fā)送請(qǐng)求，服務(wù)器做出響應(yīng)，服務(wù)器響應(yīng)之后，鏈接斷開。HTTP是一個(gè)屬于應(yīng)用層面向?qū)ο蟮膮f(xié)議，HTTP有兩類報(bào)文：請(qǐng)求報(bào)文和響應(yīng)報(bào)文。 - HTTP請(qǐng)求報(bào)文：一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù)4部分組成。 - HTTP響應(yīng)報(bào)文：由三部分組成：狀態(tài)行、消息報(bào)頭、響應(yīng)正文。即時(shí)聊天App不會(huì)采用的網(wǎng)絡(luò)傳輸方式
A UDP B TCP C HTTP D FTP 參考答案：D 理由：FTP是文件傳輸協(xié)議，是File Transfer Protocol的簡稱，它的作用是用于控制互聯(lián)網(wǎng)上文件的雙向傳輸，因此一定不會(huì)是即時(shí)聊天使用的；UDP是面向無連接的傳輸層協(xié)議，數(shù)據(jù)傳輸是不可靠的，它只管發(fā)，不管收不收得到；TCP是面向連接的，可靠的傳輸層協(xié)議；HTTP是超文本傳輸協(xié)議，對(duì)應(yīng)于應(yīng)用層，而HTTP是基于TCP的。在App中混合HTML5開發(fā)App如何實(shí)現(xiàn)的。在App中使用HTML5的優(yōu)缺點(diǎn)是什么？
在iOS中，通常是用UIWebView來實(shí)現(xiàn)，當(dāng)然在iOS8以后可以使用WKWebView來實(shí)現(xiàn).有以下幾種實(shí)現(xiàn)方法： 通過實(shí)現(xiàn)UIWebView的代理方法來攔截，判斷scheme是否是約定好的，然后iOS調(diào)用本地相關(guān)API來實(shí)現(xiàn)： - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType; 在iOS7以后，可以直接通過JavaScripteCore這個(gè)庫來實(shí)現(xiàn)，通過往JS DOM注入對(duì)象，而這個(gè)對(duì)象對(duì)應(yīng)于我們iOS的某個(gè)類的實(shí)例。更詳細(xì)請(qǐng)閱讀： OC JavaScriptCore與js交互 WKWebView新特性及JS交互 Swift JavaScriptCore與JS交互 可以通過WebViewJavascriptBridge來實(shí)現(xiàn)。具體如何使用，請(qǐng)大家去其它博客搜索吧！ 優(yōu)缺點(diǎn)： iOS加入H5響應(yīng)比原生要慢很多，體驗(yàn)不太好，這是缺點(diǎn)。 iOS加入H5可以實(shí)現(xiàn)嵌入別的功能入口，可隨時(shí)更改，不用更新版本就可以上線，這是最大的優(yōu)點(diǎn)。介紹一下XMPP?有什么優(yōu)缺點(diǎn)嗎?
XMPP(Extensible Messaging and Presence Protocol,前稱)是一種以XML為基礎(chǔ)的開放式實(shí)時(shí)通信協(xié)議,是 經(jīng)由互聯(lián)網(wǎng)工程工作小組(IETF)通過的互聯(lián)網(wǎng)標(biāo)準(zhǔn)。簡單的說,XMPP就是一種協(xié)議,一種規(guī)定。就是說,在網(wǎng)絡(luò)上傳 東西,要建立連接,TCP/IP連接,建立后再傳東西,而XMPP就是規(guī)定你傳的東西的格式。XMPP是基于XML的協(xié)議。 優(yōu)點(diǎn) 開放: XMPP協(xié)議是自由、開放、公開的,并且易于了解。 而且在客戶端 、 服務(wù)器 、 組件 、 源碼庫等方面,都已經(jīng)各自有多種實(shí)現(xiàn)。 標(biāo)準(zhǔn): 互聯(lián)網(wǎng)工程工作小組( IETF )已經(jīng)將Jabber的核心XML流協(xié)議以XMPP之名,正式列為認(rèn)可的實(shí)時(shí)通信及Presence技術(shù)。 而XMPP的技術(shù)規(guī)格已被定義在RFC 3920及RFC 3921 。 任何IM供應(yīng)商在遵循XMPP協(xié)議下,都可與Google Talk實(shí)現(xiàn)連接。 證實(shí)可用: 第一個(gè)Jabber(現(xiàn)在XMPP)技術(shù)是Jeremie Miller在1998年開發(fā)的,現(xiàn)在已經(jīng)相當(dāng)穩(wěn)定;數(shù)以百計(jì)的開發(fā)者為XMPP技術(shù)而努 力。 今日的互聯(lián)網(wǎng)上有數(shù)以萬計(jì)的XMPP服務(wù)器運(yùn)作著,并有數(shù)以百萬計(jì)的人們使用XMPP實(shí)時(shí)傳訊軟件。 分散式: XMPP網(wǎng)絡(luò)的架構(gòu)和電子郵件十分相像;XMPP核心協(xié)議通信方式是先創(chuàng)建一個(gè)stream,XMPP以TCP傳遞XML數(shù)據(jù)流,沒有 中央主服務(wù)器。 任何人都可以運(yùn)行自己的XMPP服務(wù)器,使個(gè)人及組織能夠掌控他們的實(shí)時(shí)傳訊體驗(yàn)。 安全: 任何XMPP協(xié)議的服務(wù)器可以獨(dú)立于公眾XMPP網(wǎng)絡(luò)(例如在企業(yè)內(nèi)部網(wǎng)絡(luò)中),而使用SASL及TLS等技術(shù)的可靠安全性,已自 帶于核心XMPP技術(shù)規(guī)格中。 可擴(kuò)展: XML 命名空間的威力可使任何人在核心協(xié)議的基礎(chǔ)上建造定制化的功能;為了維持通透性,常見的擴(kuò)展由XMPP標(biāo)準(zhǔn)基金會(huì) 。 彈性佳: XMPP除了可用在實(shí)時(shí)通信的應(yīng)用程序,還能用在網(wǎng)絡(luò)管理、內(nèi)容供稿、協(xié)同工具、文件共享、游戲、遠(yuǎn)程系統(tǒng)監(jiān)控等。 多樣性: 用XMPP協(xié)議來建造及布署實(shí)時(shí)應(yīng)用程序及服務(wù)的公司及開放源代碼計(jì)劃分布在各種領(lǐng)域;用XMPP技術(shù)開發(fā)軟件,資源及支持的 來源是多樣的,使得使你不會(huì)陷于被“綁架”的困境。 缺點(diǎn) 數(shù)據(jù)負(fù)載太重: 隨著通常超過70%的XMPP協(xié)議的服務(wù)器的數(shù)據(jù)流量的存在和近60%的被重復(fù)轉(zhuǎn)發(fā),XMPP協(xié)議目前擁有一個(gè)大型架空中存在的 數(shù)據(jù)提供給多個(gè)收件人。 新的議定書正在研究,以減輕這一問題。 沒有二進(jìn)制數(shù)據(jù): XMPP協(xié)議的方式被編碼為一個(gè)單一的長的XML文件,因此無法提供修改二進(jìn)制數(shù)據(jù)。 因此, 文件傳輸協(xié)議一樣使用外部的 HTTP。 如果不可避免,XMPP協(xié)議還提供了帶編碼的文件傳輸?shù)乃袛?shù)據(jù)使用的Base64 。 至于其他二進(jìn)制數(shù)據(jù)加密會(huì)話 (encrypted conversations)或圖形圖標(biāo)(graphic icons)以嵌入式使用相同的方法。NSURLConnection的幾個(gè)常用的代理?
- NSURLConnectionDownloadDelegate :能夠?qū)崿F(xiàn)監(jiān)聽下載進(jìn)度!但是下載之后,找不到下載好的文件!
- NSURLConnectionDataDelegate 是針對(duì)數(shù)據(jù)下載提供的方法!需要注意的是,需要自己實(shí)現(xiàn)監(jiān)聽進(jìn)度的業(yè)務(wù)邏輯!
- 利用 NSURLConnection 的異步回調(diào)進(jìn)行文件下載:
- 如果是小文件下載,問題不大! 可以直接使用異步回調(diào)進(jìn)行下載
- 如果使用異步回調(diào)的方法進(jìn)行大文件下載,則會(huì)出現(xiàn)內(nèi)存暴漲的情況!
- 內(nèi)存暴漲的原因: 大文件下載之后,默認(rèn)是放在內(nèi)存中的,所以下載的文件越大,越耗費(fèi)內(nèi)存.
- 存在的缺點(diǎn): 使用異步回調(diào)實(shí)現(xiàn)文件,無法監(jiān)聽下載進(jìn)度!并且對(duì)于大文件下載,會(huì)造成內(nèi)存暴漲!
- 基于以上兩點(diǎn),一般,在進(jìn)行文件下載的時(shí)候,使用代理回調(diào)監(jiān)聽下載進(jìn)度!并且在下載文件的時(shí)候,手動(dòng)管理內(nèi)存!
NSURLConnection&NSURLSession的區(qū)別?
- 雖然 NSURLConnection 在 iOS 9.0 中已經(jīng)被廢棄，但是作為資深的 iOS 程序員，必須要了解 NSURLConnection 的細(xì)節(jié),
- NSURLSession: 用于替代 NSURLConnection
- 支持后臺(tái)運(yùn)行的網(wǎng)絡(luò)任務(wù)
- 暫停、停止、重啟網(wǎng)絡(luò)任務(wù)，不再需要 NSOperation 封裝
- 請(qǐng)求可以使用同樣的配置容器
- 不同的 session 可以使用不同的私有存儲(chǔ)
- block 和代理可以同時(shí)起作用
- 直接從文件系統(tǒng)上傳、下載
XML是什么? XML與HTML的區(qū)別?
- XML的簡單使其易于在任何應(yīng)用程序中讀寫數(shù)據(jù)，這使XML很快成為數(shù)據(jù)交換的唯一公共語言，雖然不同的應(yīng)用軟件也支持其它的數(shù)據(jù)交換格式，但不久之后他們都將支持XML，那就意味著程序可以更容易的與Windows,Mac OS,Linux以及其他平臺(tái)下產(chǎn)生的信息結(jié)合，然后可以很容易加載XML數(shù)據(jù)到程序中并分析他，并以XML格式輸出結(jié)果。
- XML去掉了之前令許多開發(fā)人員頭疼的SGML（標(biāo)準(zhǔn)通用標(biāo)記語言）的隨意語法。在XML中，采用了如下的語法：
- 任何的起始標(biāo)簽都必須有一個(gè)結(jié)束標(biāo)簽。
- 可以采用另一種簡化語法，可以在一個(gè)標(biāo)簽中同時(shí)表示起始和結(jié)束標(biāo)簽。這種語法是在大于符號(hào)之前緊跟一個(gè)斜線（/），例如<tag/ >。XML解析器會(huì)將其翻譯成<tag></tag>。
- 標(biāo)簽必須按合適的順序進(jìn)行嵌套，所以結(jié)束標(biāo)簽必須按鏡像順序匹配起始標(biāo)簽，例如this is asamplestring。這好比是將起始和結(jié)束標(biāo)簽看作是數(shù)學(xué)中的左右括號(hào)：在沒有關(guān)閉所有的內(nèi)部括號(hào)之前，是不能關(guān)閉外面的括號(hào)的。
- 所有的特性都必須有值。
- 所有的特性都必須在值的周圍加上雙引號(hào)。
- XML與HTML的設(shè)計(jì)區(qū)別是：XML的核心是數(shù)據(jù)，其重點(diǎn)是數(shù)據(jù)的內(nèi)容。而HTML 被設(shè)計(jì)用來顯示數(shù)據(jù)，其重點(diǎn)是數(shù)據(jù)的顯示。
- XML和HTML語法區(qū)別：HTML的標(biāo)記不是所有的都需要成對(duì)出現(xiàn)，XML則要求所有的標(biāo)記必須成對(duì)出現(xiàn)；HTML標(biāo)記不區(qū)分大小寫，XML則 大小敏感,即區(qū)分大小寫。
網(wǎng)絡(luò)圖片處理問題中怎么解決一個(gè)相同的網(wǎng)絡(luò)地址重復(fù)請(qǐng)求的問題？
利用字典（圖片地址為key，下載操作為value）
sip是什么？
1> SIP（Session Initiation Protocol），會(huì)話發(fā)起協(xié)議 2> SIP是建立VOIP連接的 IETF 標(biāo)準(zhǔn)，IETF是全球互聯(lián)網(wǎng)最具權(quán)威的技術(shù)標(biāo)準(zhǔn)化組織 3> 所謂VOIP，就是網(wǎng)絡(luò)電話，直接用互聯(lián)網(wǎng)打電話，不用耗手機(jī)話費(fèi)TCP/IP四層模型
-
TCP/IP是一組協(xié)議的代名詞，它還包括許多協(xié)議，組成了TCP/IP協(xié)議簇。TCP/IP協(xié)議簇分為四層，IP位于協(xié)議簇的第二層(對(duì)應(yīng)OSI的第三層)，TCP位于協(xié)議簇的第三層(對(duì)應(yīng)OSI的第四層)。
-
應(yīng)用層：應(yīng)用程序間溝通的層，如簡單電子郵件傳輸（SMTP）、文件傳輸協(xié)議（FTP）、網(wǎng)絡(luò)遠(yuǎn)程訪問協(xié)議（Telnet）等。
-
傳輸層：在此層中，它提供了節(jié)點(diǎn)間的數(shù)據(jù)傳送服務(wù)，如傳輸控制協(xié)議（TCP）、用戶數(shù)據(jù)報(bào)協(xié)議（UDP）等，TCP和UDP給數(shù)據(jù)包加入傳輸數(shù)據(jù)并把它傳輸?shù)较乱粚又?#xff0c;這一層負(fù)責(zé)傳送數(shù)據(jù)，并且確定數(shù)據(jù)已被送達(dá)并接收。
-
互連網(wǎng)絡(luò)層：負(fù)責(zé)提供基本的數(shù)據(jù)封包傳送功能，讓每一塊數(shù)據(jù)包都能夠到達(dá)目的主機(jī)（但不檢查是否被正確接收），如網(wǎng)際協(xié)議（IP）。
-
網(wǎng)絡(luò)接口層：對(duì)實(shí)際的網(wǎng)絡(luò)媒體的管理，定義如何使用實(shí)際網(wǎng)絡(luò)（如Ethernet、Serial Line等）來傳送數(shù)據(jù)。
文章如有問題，請(qǐng)留言，我將及時(shí)更正。
總結(jié)
以上是生活随笔為你收集整理的李洪强经典面试题146-网络的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Codevs2157 配对
- 下一篇： MySQL存储过程相互调用