深刻淺出--iOS的TCP/IP協議族剖析&&Socket（1）

傳輸層中的協議

       傳輸層它爲應用層提供會話和數據報通訊fu務。

       傳輸層承擔OSI傳輸層的職責。

       傳輸層的核心協議是TCP和UDP。

TCP提供一對一的、面向鏈接的可靠通訊fu務。TCP創建鏈接，對發送的數據包進行排序和確認，並恢復在傳輸過程當中丟失的數據包。與TCP不一樣，UDP提供一對一或一對多的、無鏈接的不可靠通訊fu務。

不管是TCP/IP仍是在OSI參考模型中，任意相鄰兩層的下層爲fu務提供者，上層爲fu務調用者。下層爲上層提供的fu務可分爲兩類：面向鏈接fu務和無鏈接fu務。

       面向鏈接的網絡fu務

面向鏈接的網絡fu務又稱爲虛電路（Virtual Circuit）fu務，它具備網絡鏈接創建、數據傳輸和網絡鏈接釋放三個階段。是按順序傳輸可靠的報文分組方式，適用於指定對象、長報文、會話型傳輸要求。

面向鏈接fu務以phone系統爲模式。要和某我的通話，首先拿起phone，撥號碼，通話，而後掛斷。一樣在使用面向鏈接的fu務時，用戶首先要創建鏈接，使用鏈接，而後釋放鏈接。鏈接本質上像個管道：發送者在管道的一端放入物體，接收者在另外一端按一樣的次序取出物體；其特色是收發的數據不只順序一致，並且內容也相同。--相似打phone

       無鏈接的網絡fu務

無鏈接網絡fu務的兩實體之間的通訊不須要事先創建好一個鏈接。無鏈接網絡fu務有3種類型：數據報（Datagram）、確認交付（Confirmed Delivery）與請求回答（Request reply）。

無鏈接fu務以郵政系統爲模式。每一個報文（信件）帶有完整的目的地址，而且每個報文都獨立於其餘報文，由系統選定的路線傳遞。在正常狀況下，當兩個報文發往同一目的地時，先發的先到。可是，也有可能先發的報文在途中延誤了，後發的報文反而先收到；而這種狀況在面向鏈接的fu務中是絕對不可能發生的。--相似發短信

傳輸控制協議（TCP）

1.TCP全稱是Transmission Control Protocol，中文名爲傳輸控制協議，它能夠提供可靠的、面向鏈接的網絡數據傳遞fu務。傳輸控制協議主要包含下列任務和功能：

2.確保IP數據報的成功傳遞。

       對程序發送的大塊數據進行分段和重組。

       確保正確排序及按順序傳遞分段的數據。

       經過計算校驗和，進行傳輸數據的完整性檢查。

       根據數據是否接收成功發送確定消息。經過使用選擇性確認，也對沒有收到的數據發送否認確認。

爲必須使用可靠的、基於會話的數據傳輸程序，如ke戶端/fu務器數據庫和電子郵件程序，提供首選傳輸方法。

3.TCP工做原理

TCP的鏈接創建過程又稱爲TCP三次握手：

       首先發送方主機向接收方主機發起一個創建鏈接的同步（SYN）請求；

       接收方主機在收到這個請求後向發送方主機回覆一個同步/確認（SYN/ACK）應答；

       發送方主機收到此包後再向接收方主機發送一個確認（ACK），此時TCP鏈接成功創建.

一旦初始的三次握手完成，在發送和接收主機之間將按順序發送和確認段。關閉鏈接以前，TCP使用相似的握手過程驗證兩個主機是否都完成發送和接收所有數據。

完成三次握手，ke戶端與fu務器開始傳送數據。

三次握手示意圖：

三次握手.png

TCP工做過程比較複雜，包括的內容以下。

       TCP鏈接關閉：發送方主機和目的主機創建TCP鏈接並完成數據傳輸後，會發送一個將結束標記置1的數據包，以關閉這個TCP鏈接，並同時釋放該鏈接佔用的緩衝區空間。

       TCP重置：TCP容許在傳輸的過程當中忽然中斷鏈接。

       TCP數據排序和確認*：在傳輸的過程當中使用序列號和確認號來跟蹤數據的接收狀況。

       TCP重傳：在TCP的傳輸過程當中，若是在重傳超時時間內沒有收到接收方主機對某數據包的確認回覆，發送方主機就認爲此數據包丟失，並再次發送這個數據包給接收方。

       TCP延遲確認：TCP並不老是在接收到數據後當即對其進行確認，它容許主機在接收數據的同時發送本身的確認信息給對方。

       TCP數據保護（校驗）：TCP是可靠傳輸的協議，它提供校驗和計算來實現數據在傳輸過程當中的完整性。

用戶數據報協議（UDP）

UDP全稱是User Datagram Protocol，中文名爲用戶數據報協議。UDP 提供無鏈接的網絡fu務，該fu務對消息中傳輸的數據提供不可靠的、最大努力傳送。這意味着它不保證數據報的到達，也不保證所傳送數據包的順序是否正確。

我最初就有一個疑惑：「既然UDP是一種不可靠的網絡協議，那麼還有什麼使用價值或必要呢？」

在有些狀況下UDP可能會變得很是有用。由於UDP具備TCP所可望不可即的速度優點。雖然TCP中植入了各類安全保障功能，可是在實際執行的過程當中會佔用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP因爲排除了信息可靠傳遞機制，將安全和排序等功能移交給上層應用來完成，極大地下降了執行時間，使速度獲得了保證。

TCP與端口號

TCP和UDP都是IP層面的傳輸協議，是IP與上層之間的處理接口。TCP和UDP端口號被設計來區分運行在單個設備上的多重應用程序的IP地址。因爲同一臺計算機上可能會運行多個網絡應用程序，因此計算機須要確保目標計算機上接收源主機數據包的軟件應用程序的正確性，以及響應可以被髮送到源主機的正確應用程序上。該過程正是經過使用TCP或UDP端口號來實現的。

－－即每個應用都會在網卡上註冊一個端口號用來區分同一臺設備上應用的之間的通訊

在TCP和UDP頭部分，有「源端口」和「目標端口」段，主要用於顯示發送和接收過程當中的身份識別信息。IP 地址和端口號合在一塊兒被稱爲「套接字」。TCP端口比較複雜，其工做方式與UDP端口不一樣。UDP端口對於基於UDP的通訊做爲單一消息隊列和網絡端點來操做，而全部TCP通訊的終點都是惟一的鏈接。每一個TCP鏈接由兩個端點惟一識別。因爲全部TCP鏈接由兩對 IP 地址和TCP端口惟一識別（每一個所連主機都有一個地址/端口對），所以每一個TCPfu務器端口都能提供對多個鏈接的共享訪問

再看一下IP數據包和TCP／UDP的數據包

數據包.png

HTTP協議

超文本傳輸協議（HTTP，HyperText Transfer Protocol)是互聯網上應用最爲普遍的一種網絡協議。

http協議規定了ke戶端和fu務器之間的數據傳輸格式.

http優勢:

       簡單快速:http協議簡單,通訊速度很快;

       靈活:http協議容許傳輸任意類型的數據;

       短鏈接:http協議限制每次鏈接只處理一個請求,fu務器對ke戶端的請求做出響應後,立刻斷開鏈接.這種方式能夠節省傳輸時間.

HTTP協議的使用

1.請求:ke戶端向fu務器索要數據.

http協議規定:一個完整的http請求包含'請求行','請求頭','請求體'三個部分;

       請求行：包含了請求方法,請求資源路徑,http協議版本. "GET /resources/images/ HTTP/1.1"

       請求頭:包含了對ke戶端的環境描述,ke戶端請求的主機地址等信息.

Accept: text/html ( ke戶端所能接收的數據類型 )

Accept-Language: zh-cn ( ke戶端的語言環境 )

Accept-Encoding: gzip( ke戶端支持的數據壓縮格式 )

Host: m.baidu.com( ke戶端想訪問的fu務器主機地址 ) User-Agent: Mozilla/5.0(Macintosh;Intel Mac OS X10.10 rv:37.0) Gecko/20100101Firefox/37.0( ke戶端的類型,ke戶端的軟件環境 )

       請求體:ke戶端發給fu務器的具體數據,好比文件/圖片等.

2.響應:fu務器返回ke戶端想要的數據

http協議規定:一個完整的http響應包含'狀態行','響應頭','實體內容'三個部分;

       狀態行:包含了http協議版本,狀態嗎,狀態英文名稱.

"HTTP/1.1 200 OK"

       響應頭:包含了對fu務器的描述,對返回數據的描述.

Content-Encoding: gzip(fu務器支持的數據壓縮格式) Content-Length: 1528(返回數據的長度)

Content-Type:application/xhtml+xml;charset=utf-8(返回數據的類型)

Date: Mon,15Jun201509:06:46GMT(響應的時間) Server: apache (fu務器類型)

       實體內容:fu務器返回給ke戶端的具體數據(圖片/html/文件...).

3.發送http請求

在iOS開發中,發送http請求的方案有不少,常見的有以下幾種:

       蘋果原生:

1.NSURLConnection:用法簡單,古老經典的一種方案.

2.NSURLSession:iOS7之後推出的技術,功能NSURLConnection更增強大.

3.CFNetWork:NSURL的底層,純C語言,通常不用.

       第三方框架:

AFNetWorking（OC）；Alamofire（swift）；

HTTP方法

http協議定義了不少方法對應不一樣的資源操做,其中最經常使用的是GET和POST方法。

eg：GET、POST、OPTIONS、HEAD、PUT、DELETE、TRACE、CONNECT、PATCH

增:PUT

刪:DELETE

改:POST

查:GET

由於GET和POST能夠實現上述全部操做,因此,在現實開發中,GET和POST方法使用的最爲普遍，除此之外HEAD請求使用頻率也比較高；

       GET

在請求URL後面以?的形式跟上發給fu務器的參數,參數以"參數名"="參數值"的形式拼接,多個參數之間用&分隔;

GET的本質是從fu務器獲得數據,效率更高.而且GET請求能夠被緩存.

注意:GET的長度是有限制的,不一樣的瀏覽器有不一樣的長度限制,通常在2~8K之間;

       POST

POST的本質是向fu務器發送數據,也能夠得到fu務器處理以後的結果,效率不如GET.POST請求不能夠被緩存,每次刷新以後都須要從新提交表單.

發送給fu務器的參數所有放在'請求體'中;

理論上,POST傳遞的數據量沒有限制.

注意:全部涉及到用戶隱私的數據(密碼/銀行卡號等...)都要用POST的方式傳遞.

       HEAD

HEAD方法一般用在下載文件以前,獲取遠程fu務器的文件信息!相比於GET請求,不會下載文件數據,只得到響應頭信息!

通常,使用HEAD方法的目的是提早告訴用戶下載文件的信息,由用戶肯定是否下載文件!因此, HEAD方法,最好發送同步請求!

響應消息

1xx:信息響應類，表示接收到請求而且繼續處理

2xx:處理成功響應類，表示動做被成功接收、理解和接受

3xx:重定向響應類，爲了完成指定的動做，必須接受進一步處理

4xx:ke戶端錯誤，ke戶請求包含語法錯誤或者是不能正確執行

5xx:fu務端錯誤，fu務器不能正確執行一個正確的請求;

詳細描述：狀態碼