1. 進程和線程的區(qū)別

根本區(qū)別：進程是操作系統(tǒng)資源分配的基本單位，而線程是任務(wù)調(diào)度和執(zhí)行的基本單位
參考文章

2. HTTPS的握手過程

HTTPS基于SSL的HTTP協(xié)議
HTTPS = HTTP + SSL\TLS

image.png

1. 瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。
2. 網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器。證書里面包含了網(wǎng)站地址，加密公鑰，以及證書的頒發(fā)機構(gòu)等信息。
3. 瀏覽器獲得網(wǎng)站證書之后瀏覽器要做以下工作：
   • 驗證證書的合法性（頒發(fā)證書的機構(gòu)是否合法，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄里面會顯示一個小鎖頭，否則會給出證書不受信的提示。
   • b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數(shù)的密碼，并用證書中提供的公鑰加密。
   • c) 使用約定好的HASH算法計算握手消息，并使用生成的隨機數(shù)對消息進行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站。
4. 網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：

• a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發(fā)來的握手消息，并驗證HASH是否與瀏覽器發(fā)來的一致。
• b) 使用密碼加密一段握手消息，發(fā)送給瀏覽器。

5. 瀏覽器解密并計算握手消息的HASH，如果與服務(wù)端發(fā)來的HASH一致，此時握手過程結(jié)束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。

HTTPS協(xié)議和HTTP協(xié)議的區(qū)別：

1. HTTPS 協(xié)議需要到CA申請證書，一般免費證書很少，需要交費。
2. HTTP 是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議。
3. HTTP 和 HTTPS 使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
4. HTTP 的連接很簡單,是無狀態(tài)的 。
5. HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議， 要比http協(xié)議安全。
   參考文章

如何理解HTTP協(xié)議是無狀態(tài)的

HTTP協(xié)議是無狀態(tài)的，指的是協(xié)議對于事務(wù)處理沒有記憶能力，服務(wù)器不知道客戶端是什么狀態(tài)。也就是說，打開一個服務(wù)器上的網(wǎng)頁和你之前打開這個服務(wù)器上的網(wǎng)頁之間沒有任何聯(lián)系。HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP協(xié)議（無連接）。

cookie和session的區(qū)別

在這種客戶端與服務(wù)器進行動態(tài)交互的Web應(yīng)用程序出現(xiàn)之后，HTTP無狀態(tài)的特性嚴重阻礙了這些交互式應(yīng)用程序的實現(xiàn)，畢竟交互是需要承前啟后的，簡單的購物車程序也要知道用戶到底在之前選擇了什么商品。于是，兩種用于保持HTTP狀態(tài)的技術(shù)就應(yīng)運而生了，一個是Cookie，而另一個則是Session。

Cookie是客戶端的存儲空間，由瀏覽器來維持。具體來說cookie機制采用的是在客戶端保持狀態(tài)的方案，而session機制采用的是在服務(wù)器端保持狀態(tài)的方案。同時我們也看到，由于才服務(wù)器端保持狀態(tài)的方案在客戶端也需要保存一個標(biāo)識，所以session機制可能需要借助于cookie機制來達到保存標(biāo)識的目的，但實際上還有其他選擇，比如說重寫URL和隱藏表單域。
簡單的說就是cookie和session起到保存客戶端狀態(tài)的作用，但是它們并沒有改變http協(xié)議本身這種無狀態(tài)的性質(zhì)，可以理解為在應(yīng)用上做了狀態(tài)保留。

什么是長連接、短連接？

短連接的操作步驟是：
建立連接——數(shù)據(jù)傳輸——關(guān)閉連接...建立連接——數(shù)據(jù)傳輸——關(guān)閉連接
長連接的操作步驟是：
建立連接——數(shù)據(jù)傳輸...（保持連接）...數(shù)據(jù)傳輸——關(guān)閉連接

在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務(wù)器每進行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當(dāng)瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。

但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應(yīng)頭有加入這行代碼：

Connection:keep-alive
`Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。`

在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。實現(xiàn)長連接要客戶端和服務(wù)端都支持長連接。

HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接。

3. 什么是中間人攻擊？怎么預(yù)防

4. TCP、UDP的區(qū)別，為什么TCP是安全的

TCP與UDP區(qū)別總結(jié)：

1. TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接
2. TCP提供可靠的服務(wù)。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復(fù)，且按序到達;UDP盡最大努力交付，即不保證可靠交付
3. TCP面向字節(jié)流，實際上是TCP把數(shù)據(jù)看成一連串無結(jié)構(gòu)的字節(jié)流;UDP是面向報文的
   UDP沒有擁塞控制，因此網(wǎng)絡(luò)出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應(yīng)用很有用，如IP電話，實時視頻會議等）
4. 每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信
5. TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個字節(jié)
6. TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道
7. TCP傳輸速度慢，適合少量數(shù)據(jù)；UDP傳輸速度快，適合傳輸大量數(shù)據(jù)

TCP的安全可靠體現(xiàn)在：
TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接，而且在數(shù)據(jù)傳遞時，有確認、窗口、重傳、擁塞控制機制，在數(shù)據(jù)傳完后，還會四次揮手斷開連接用來節(jié)約系統(tǒng)資源。
參考文章

5. TCP的握手過程？為什么進行三次握手，四次揮手

TCP消息頭

image.png

序列號seq字段：占32比特。用來標(biāo)識從TCP源端向TCP目標(biāo)端發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的第一個數(shù)據(jù)字節(jié)。
確認號ack字段：占32比特。只有ACK標(biāo)志為1時，確認號字段才有效。它包含目標(biāo)端所期望收到源端的下一個數(shù)據(jù)字節(jié)。
標(biāo)志位字段（U、A、P、R、S、F）：占6比特。各比特的含義如下：
　URG：緊急指針（urgent pointer）有效。
　ACK：為1時，確認序號有效。
　PSH：為1時，接收方應(yīng)該盡快將這個報文段交給應(yīng)用層。
　RST：為1時，重建連接。
　SYN：為1時，同步程序，發(fā)起一個連接。
　FIN：為1時，發(fā)送端完成任務(wù)，釋放一個連接。

TCP提供一種面向連接的可靠的字節(jié)流服務(wù)，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接，建立一條連接有以下過程。

1. 請求端（客戶端）發(fā)送一個SYN段指明客戶打算連接的服務(wù)器的端口，以及初始序列號（ISN），這個SYN為報文段1.
2. 服務(wù)器發(fā)回包含服務(wù)器的初始序列號的SYN報文段（報文段2）作為應(yīng)答。同時，將確認序號設(shè)置為客戶的ISN加1以對客戶的SYN報文段進行確認。一個SYN將占用一個字符。
3. 客戶必須將明確序號設(shè)置為服務(wù)器的ISN加1以對服務(wù)器的SYN報文段進行確認（報文段3）
4. 這三個報文段完成連接的建立，這個過程成為三次握手。

image.png

在謝希仁著《計算機網(wǎng)絡(luò)》第四版中講“三次握手”的目的是“為了防止已失效的連接請求報文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯誤”。在另一部經(jīng)典的《計算機網(wǎng)絡(luò)》一書中講“三次握手”的目的是為了解決“網(wǎng)絡(luò)中存在延遲的重復(fù)分組”的問題。這兩種不用的表述其實闡明的是同一個問題。
謝希仁版《計算機網(wǎng)絡(luò)》中的例子是這樣的，“已失效的連接請求報文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接。”。 主要目的防止server端一直等待，浪費資源。

連接終止協(xié)議（四次揮手）
由于TCP連接是全雙工的，因此每個方向都必須單獨進行關(guān)閉。這原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進行關(guān)閉的一方將執(zhí)行主動關(guān)閉，而另一方執(zhí)行被動關(guān)閉。
（1） TCP客戶端發(fā)送一個FIN，用來關(guān)閉客戶到服務(wù)器的數(shù)據(jù)傳送（報文段4）。
（2） 服務(wù)器收到這個FIN，它發(fā)回一個ACK，確認序號為收到的序號加1（報文段5）。和SYN一樣，一個FIN將占用一個序號。
（3） 服務(wù)器關(guān)閉客戶端的連接，發(fā)送一個FIN給客戶端（報文段6）。
（4） 客戶段發(fā)回ACK報文確認，并將確認序號設(shè)置為收到序號加1（報文段7）。

image.png

參考文章

6. 堆和棧區(qū)的區(qū)別？誰的占用內(nèi)存空間大

1.內(nèi)存分區(qū)
（1）常量區(qū)：存放常量字符串，程序結(jié)束后由系統(tǒng)釋放
（2）代碼區(qū)：存放函數(shù)的二進制代碼
（3）全局區(qū)\靜態(tài)區(qū)：包括兩個部分：

初始化過的：初始化的全局變量和靜態(tài)變量在一塊區(qū)域
未初始化過的：未初始化的全局變量和靜態(tài)變量在相鄰的另一塊區(qū)域；

（4）堆空間：動態(tài)malloc申請的空間，引用的變量實例化存儲的空間
（5）棧空間：用來存放局部變量，形參之類，未進行實例化的引用申請的變量

2.堆區(qū)和棧區(qū)區(qū)別：

（1）管理方式不同：棧直接由編譯器管理（產(chǎn)生和消除），堆由程序員管理，程序員管理其的產(chǎn)生和消除
（2）空間大小不同：棧占用的空間較小，而堆占用的空間較大
（3）能否產(chǎn)生碎片不同：棧不會產(chǎn)生碎片（連續(xù)的），但是堆會產(chǎn)生（不連續(xù)），會有內(nèi)存泄露的問題
（4）生長方向不同：棧地址從高到分配，堆區(qū)的地址是從低到高分配
（5）分配方式不同：

• 堆是動態(tài)分配和回收內(nèi)存的，沒有靜態(tài)分配的堆
• 棧有兩種分配方式：靜態(tài)分配和動態(tài)分配
  • 靜態(tài)分配是系統(tǒng)編譯器完成的，比如局部變量的分配
  • 動態(tài)分配是有alloc函數(shù)進行分配的，但是棧的動態(tài)分配和堆是不同的，它的動態(tài)分配也由系統(tǒng)編譯器進行釋放，不需要程序員手動管理

（6）分配效率不同：棧是由內(nèi)存分配的，系統(tǒng)專門為其準(zhǔn)備寄存器，同時有專門的出棧和入棧指令，因而效率比較高。而堆空間則是C庫分配的，可能會存在碎片的原因?qū)е聝?nèi)存不連續(xù)，因而效率比較低；

7. 加密算法：對稱加密算法和非對稱加密算法區(qū)別

8. 常見的對稱加密和非對稱加密算法有哪些

加密與HASH算法如下：

1. 非對稱加密算法：RSA，DSA/DSS，用于在握手過程中加密生成的密碼。
2. 對稱加密算法：AES，RC4，DES，3DES，用于對真正傳輸?shù)臄?shù)據(jù)進行加密。
3. HASH算法：MD5，SHA1，SHA256，驗證數(shù)據(jù)的完整性。

9. MD5、SHA1、SHA256區(qū)別

產(chǎn)生的哈希值不一樣
MD5輸出128位、SHA1輸出160位、SHA256輸出256位

10. charles抓包過程？不使用charles，4G網(wǎng)絡(luò)如何抓包

Charles抓包原理，就是Charles作為“中間人代理”，拿到了 服務(wù)器證書公鑰 和 HTTPS連接的對稱密鑰，前提是客戶端選擇信任并安裝Charles的CA證書，否則客戶端就會“報警”并中止連接

Charles抓包原理
4G抓包

11. HTTP的請求

HTTP請求報文解剖

HTTP 請求報文由四部分組成，分別是請求行、請求頭、空行和請求體，其中空行也是組成部分之一，作用是進行分隔，必不可少。：

image.png

1 請求行
第一行為請求行，由請求方法、URL和HTTP協(xié)議版本3個字段組成

這一行比較好理解，只有請求方法的類型比較多，有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT，其中GET、POST最為常用，這里詳細介紹下

GET和POST的區(qū)別：
1.GET將請求信息放在URL，POST放在報文體中。
2.GET參數(shù)有長度限制（受限于url長度，具體的數(shù)值取決于瀏覽器和服務(wù)器的限制），而POST無限制
3.GET是明文傳輸直接可以看到，POST是放在請求體中，但是開發(fā)者可以通過抓包工具看到，也相當(dāng)于是明文的。
4.GET請求會緩存在瀏覽器歷史記錄中，POST請求不會

2 請求頭
請求頭部由 鍵/值對 組成，每行一對，鍵和值用冒號“:”（英文）分隔。請求頭部告知服務(wù)器所有有關(guān)于客戶端請求的信息，典型的請求頭有：

User-Agent：產(chǎn)生請求的用戶代理信息（瀏覽器信息）： Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36等；
Accept：客戶端可識別的內(nèi)容類型列 ：text/html, application/xhtml+xml, application/xml；
Accept-Language：客戶端可接受的自然語言 - zh-CN,zh;q=0.8,en;q=0.6,id;q=0.4；
Accept-Encoding：客戶端可接受的編碼壓縮格式 - gzip, deflate, sdch, br
Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機
connection：連接方式，有close和keep-alive兩種。

close：告訴WEB服務(wù)器或代理服務(wù)器，在完成本次請求的響應(yīng)后，斷開連接
keep-alive：告訴WEB服務(wù)器或代理服務(wù)器。在完成本次請求的響應(yīng)后，保持連接，以等待后續(xù)請求

Cookie：存儲于客戶端擴展字段，向同一域名的服務(wù)端發(fā)送屬于該域的cookie - PSTM=1490844191; BIDUPSID=2145FF54639208435F60E1E165379255;

3 空行
用戶進行內(nèi)容分割，表示請求頭到此為止，下一行的內(nèi)容不再是請求頭。

4 請求體
請求體包含的就是請求數(shù)據(jù)，它將一個頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數(shù)的數(shù)據(jù)。不但報文體可以傳遞請求參數(shù)，請求URL也可以通過類似于“? param1=value1&param2=value2”的方式傳遞請求參數(shù)。

HTTP 響應(yīng)報文
HTTP響應(yīng)也由四個部分組成，分別是：狀態(tài)行、響應(yīng)頭、空行和響應(yīng)體。形式上除了狀態(tài)行之外，其他三個部分與請求報文類似。

image.png

1. 狀態(tài)行（響應(yīng)行）

①報文協(xié)議及版本；
②狀態(tài)碼及狀態(tài)描述；

狀態(tài)代碼由三位數(shù)字組成，第一個數(shù)字定義了響應(yīng)的類別，且有五種可能取值。

1xx：指示信息--表示請求已接收，繼續(xù)處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)。
5xx：服務(wù)器端錯誤--服務(wù)器未能實現(xiàn)合法的請求。

各類型常見狀態(tài)代碼、狀態(tài)描述的說明如下：

200 OK：客戶端請求成功。
400 Bad Request：客戶端請求有語法錯誤，不能被服務(wù)器所理解。
401 Unauthorized：請求未經(jīng)授權(quán)，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用。
403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)。
404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯誤。
503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請求，一段時間后可能恢復(fù)正常，舉個例子：HTTP/1.1 200 OK（CRLF）。

2. 響應(yīng)頭

和請求報文的請求頭類似，響應(yīng)頭也由鍵值對組成，每行一對，鍵和值用英文冒號 : 分隔。響應(yīng)頭域允許服務(wù)器傳遞不能放在狀態(tài)行的附加信息，這些域主要描述服務(wù)器的信息和Request-URI進一步的信息，典型的響應(yīng)頭有：

Server：包含處理請求的原始服務(wù)器的軟件信息；
Date：服務(wù)器日期；
Content-Type：返回的資源類型 (MIME)；
Connection：連接方式；

close：連接已經(jīng)關(guān)閉；
keep-alive：連接已保持，在等待本次連接的后續(xù)請求；

Cache-Control：緩存控制；
Expires：設(shè)置過期時間；
Set-Cookie：設(shè)置 Cookie 信息。

4. 響應(yīng)體
服務(wù)器返回的數(shù)據(jù)，就是我們通常的 json 數(shù)據(jù)

12. 說一下NSURLSession具體的實現(xiàn)原理

NSURLSession 是 iOS7.0 后推出的,用于代替 NSURLConnection.

NSURLSession提供了四大任務(wù)：

DataTask 數(shù)據(jù)請求，網(wǎng)絡(luò)請求中最常用的請求之一
DownloadTask 文件下載，獲取進度、斷點續(xù)傳
UploadTask 文件上傳
StreamTask TCP鏈接（iOS 9+）

image.png