2019 iOS面試題大全---全方面剖析面試
2019 iOS面試題-----網絡相關之HTTP協議
2019 iOS面試題-----網絡相關之HTTPS、對稱加密、非對稱加密
2019 iOS面試-----一個基于UDP的簡單的聊天Demo（用C語言、python、GCDAsyncUdpSocket來實現UDP通信）
2019 iOS面試題-----網絡相關之UDP的特點、UDP的報文結構及差錯檢測
2019 iOS面試題-----網絡相關之TCP、三次握手、四次揮手、代碼實現
2019 iOS面試題-----網絡相關之TCP進階：可靠數據傳輸、流量控制(滑動窗口)、擁塞控制
2019 iOS面試題-----網絡相關之DNS
2019 iOS面試題-----網絡相關之Cookie和Session
2019 iOS面試題-----網絡相關之IP協議、IP數據報分片、IPv4編址、網絡地址轉換（NAT）
2019 iOS面試題-----網絡相關之IPv6、從IPv4到IPv6的遷移
HTTP協議：超文本傳輸協議
是一種詳細規定了瀏覽器和萬維網(WWW = World Wide Web)服務器之間互相通信的規則，通過因特網傳送萬維網文檔的數據傳送協議。
HTTP是基于TCP的應用層協議
(OSI網絡七層協議從上到下分別是 應用層、表示層、會話層 、傳輸層、網絡層 、數據鏈路層、物理層）
- 請求/響應報文
- 連接建立流程
-
HTTP的特點
image.png
一、請求報文和響應報文
1、請求報文
如下:
POST /somedir/page.html HTTP/1.1
//以上是請求行:方法字段、URL字段和HTTP版本字段
Host: www.user.com
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
User-agent: Mozilla/5.0.
Accept-lauguage: fr
//以上是首部行
（此處必須有一空行） //空行分割header和請求內容
name=world 請求體
Host：指明了該對象所在的主機
Connection：Keep-Alive首部行用來表明該瀏覽器告訴服務器使用持續連接
Content-Type: x-www-form-urlencoded首部行用來表明 HTTP會將請求參數用key1=val1&key2=val2的方式進行組織，并放到請求實體里面
User-agent：首部行用來指明用戶代理，即向服務器發送請求的瀏覽器類型
Accept-lauguage：首部行表示用戶想得到該對象的法語版本（如果服務器中有這樣的對象的話），否則，服務器應發送它的默認版本
2、響應報文
如下：
HTTP/1.1 200 OK
//以上是狀態行：協議版本字段、狀態碼、相應狀態信息
Connection：close
Server:Apache/2.2.3(CentOS)
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html
Content-Length: 122
//以上是首部行
（此處必須有一空行） //空行分割header和實體主體
(data data data data)//響應實體主體
狀態碼及其相應的短語指示了請求的結果。
一些常見的狀態碼和對應的短語：
- 200 OK：請求成功，信息在返回的響應報文中
- 301 Moved Permanently：請求的對象已經被永久轉移了，新的URL定義在響應報文中的Location：首部行中。客戶軟件將自動獲取新的URL
- 400 Bad Request：一個通用差錯代碼，指示該請求不能被服務器理解
- 404 Not Found：被請求的文件不在服務器上
-
505 HTTP Version Not Supported：服務器不支持請求報文使用的HTTP協議版本
<4開頭的狀態碼通常是客戶端的問題，5開頭的則通常是服務端的問題>
Connection：close首部行告訴客戶，發送完報文后將關閉TCP連接。
Date:指的不是對象創建或最后修改的時間，而是服務器從文件系統中檢索到該對象，插入到響應報文，并發送該響應報文的時間。
Server: 首部行指示該報文是由一臺Apache Web服務器產生的，類似于HTTP請求報文里的User-agent
Content-Length：首部行指示了被發送對象中的字節數
Content-Type：首部行指示了實體體中的對象是HTML文本
二、HTTP的請求方式
GET、POST、PUT、DELETE、HEAD、OPTIONS
1、GET和POST方式的區別
從語法角度來看，最直觀的區別就是
- GET的請求參數一般以
?分割拼接到URL后面，POST請求參數在Body里面 - GET參數長度限制為2048個字符，POST一般是沒限制的
- GET請求由于參數裸露在URL中， 是不安全的，POST請求則是相對安全
之所以說是相對安全，是因為，如果POST雖然參數非明文，但如果被抓包，GET和POST一樣都是不安全的。(HTTPS該用還是得用)
而從語義的角度來看：
GET：獲取資源是 安全的，冪等的(只讀的，純粹的)， 可緩存的
POST：獲取資源是 非安全的，非冪等的，不可緩存的
- 這里的
安全是指不應引起Server端的任何狀態變化
GET的語義就是獲取數據，是不會引起服務器的狀態變化的，即是安全的。（HEAD，OPTIONS也是安全的）
而POST語義則是提交數據，是可能會引起服務器狀態變化的，即是不安全的 -
冪等:同一個請求方法執行多次和執行一次的效果完全相同
顯然GET請求是冪等而POST請求是非冪等的。
這里用冪等形容GET還不夠，因為GET不止是執行多次和執行一次的效果完全相同，而且是執行一次和執行零次的效果也是完全相同的。 -
可緩存的
請求是否可以被緩存。
GET請求會主動進行Cache
以上特性，并非并列，正是因為GET是冪等的只讀的，即GET請求除了返回數據不會有其他副作用，所以GET才是安全的，從而可以直接由CDN緩存，大大減輕服務器的負擔，也就是可緩存的。
而POST是非冪等的，即除了返回數據還會有其他副作用，所以POST是不安全的，必須交由web服務器處理，即是 不可緩存的
GET和POST本質上就是TCP鏈接，并無差別。但是由于HTTP的規定和瀏覽器/服務器的限制，導致他們在應用過程中體現出一些不同。
在響應時，GET產生一個TCP數據包；POST產生兩個TCP數據包:
對于GET方式的請求，瀏覽器會把Header和實體主體一并發送出去，服務器響應200（返回數據）；
而對于POST，瀏覽器先發送Header，服務器響應100 Continue，瀏覽器再發送實體主體，服務器響應200 OK（返回數據）。
2、GET 相對 POST 的優勢是什么？
1、最大的優勢就是方便。GET 的URL可以直接手輸，從而GET請求中的URL可以被存在書簽里，或者歷史記錄里
2、可以被緩存，大大減輕服務器的負擔
所以大多數情況下，還是用GET比較好。
三、HTTP的特點
無連接、 無狀態
HTTP的持久連接、Cookie/Session
1、HTTP的無狀態
即協議對于事務處理沒有記憶能力。
每次的請求都是獨立的，它的執行情況和結果與前面的請求和之后的請求時無直接關系的，它不會受前面的請求應答情況直接影響，也不會直接影響后面的請求應答情況
也就是說服務器中沒有保存客戶端的狀態，客戶端必須每次帶上自己的狀態去請求服務器
標準的HTTP協議指的是不包括cookies，session，application的HTTP協議
2、HTTP的持久連接
非持久連接：每個連接處理一個請求-響應事務。
持久連接：每個連接可以處理多個請求-響應事務。
持久連接情況下，服務器發出響應后讓TCP連接繼續打開著。同一對客戶/服務器之間的后續請求和響應可以通過這個連接發送。
HTTP/1.0 使用非持久連接。 HTTP/1.1 默認使用持久連接 <keep-alive>。
非持久連接的每個連接，TCP得在客戶端和服務端分配TCP緩沖區，并維持TCP變量，會嚴重增加服務器負擔。而且每個對象都有2個RTT(Round Trip Time，也就是一個數據包從發出去到回來的時間)的延遲，由于TCP的擁塞控制方案,每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段
HTTP持久連接怎么判斷一個請求是否結束的？
-
Content-length：根據所接收字節數是否達到Content-length值 -
chunked(分塊傳輸):Transfer-Encoding。當選擇分塊傳輸時，響應頭中可以不包含Content-Length，服務器會先回復一個不帶數據的報文（只有響應行和響應頭和\r\n），然后開始傳輸若干個數據塊。當傳輸完若干個數據塊后，需要再傳輸一個空的數據塊，當客戶端收到空的數據塊時，則客戶端知道數據接收完畢。
