iOS的TCP/IP協(xié)議族剖析&&Socket

2019-11-09 14:39:28

字體：大中小

供稿：網(wǎng)友

簡介

該篇文章主要回顧--TCP/ip協(xié)議族中的TCP／UDP、HTTP；還有Socket。（－－該文很干，醞釀了許久！你能耐心看完嗎？）

我在這個(gè)文章中，列舉了常見的TCP/IP族中的協(xié)議，今天主角是－－傳輸層協(xié)議。

傳輸層（Transport Layer）是OSI（七層模型)中最重要、最關(guān)鍵的一層,它負(fù)責(zé)總體的數(shù)據(jù)傳輸和數(shù)據(jù)控制的一層，傳輸層提供端到端（應(yīng)用會(huì)在網(wǎng)卡注冊一個(gè)端口號）的交換數(shù)據(jù)的機(jī)制，檢查分組編號與次序。傳輸層對其上三層如會(huì)話層等，提供可靠的傳輸服務(wù)，對網(wǎng)絡(luò)層提供可靠的目的地站點(diǎn)信息。

傳輸層中的協(xié)議

傳輸層它為應(yīng)用層提供會(huì)話和數(shù)據(jù)報(bào)通信服務(wù)。

傳輸層承擔(dān)OSI傳輸層的職責(zé)。

傳輸層的核心協(xié)議是TCP和UDP。

TCP提供一對一的、面向連接的可靠通信服務(wù)。TCP建立連接，對發(fā)送的數(shù)據(jù)包進(jìn)行排序和確認(rèn)，并恢復(fù)在傳輸過程中丟失的數(shù)據(jù)包。與TCP不同，UDP提供一對一或一對多的、無連接的不可靠通信服務(wù)。

不論是TCP/IP還是在OSI參考模型中，任意相鄰兩層的下層為服務(wù)提供者，上層為服務(wù)調(diào)用者。下層為上層提供的服務(wù)可分為兩類：面向連接服務(wù)和無連接服務(wù)。

面向連接的網(wǎng)絡(luò)服務(wù)

面向連接的網(wǎng)絡(luò)服務(wù)又稱為虛電路（Virtual Circuit）服務(wù)，它具有網(wǎng)絡(luò)連接建立、數(shù)據(jù)傳輸和網(wǎng)絡(luò)連接釋放三個(gè)階段。是按順序傳輸可靠的報(bào)文分組方式，適用于指定對象、長報(bào)文、會(huì)話型傳輸要求。

面向連接服務(wù)以電話系統(tǒng)為模式。要和某個(gè)人通話，首先拿起電話，撥號碼，通話，然后掛斷。同樣在使用面向連接的服務(wù)時(shí)，用戶首先要建立連接，使用連接，然后釋放連接。連接本質(zhì)上像個(gè)管道：發(fā)送者在管道的一端放入物體，接收者在另一端按同樣的次序取出物體；其特點(diǎn)是收發(fā)的數(shù)據(jù)不僅順序一致，而且內(nèi)容也相同。--類似打電話

無連接的網(wǎng)絡(luò)服務(wù)

無連接網(wǎng)絡(luò)服務(wù)的兩實(shí)體之間的通信不需要事先建立好一個(gè)連接。無連接網(wǎng)絡(luò)服務(wù)有3種類型：數(shù)據(jù)報(bào)（Datagram）、確認(rèn)交付（Confirmed Delivery）與請求回答（Request reply）。

無連接服務(wù)以郵政系統(tǒng)為模式。每個(gè)報(bào)文（信件）帶有完整的目的地址，并且每一個(gè)報(bào)文都獨(dú)立于其他報(bào)文，由系統(tǒng)選定的路線傳遞。在正常情況下，當(dāng)兩個(gè)報(bào)文發(fā)往同一目的地時(shí)，先發(fā)的先到。但是，也有可能先發(fā)的報(bào)文在途中延誤了，后發(fā)的報(bào)文反而先收到；而這種情況在面向連接的服務(wù)中是絕對不可能發(fā)生的。--類似發(fā)短信

傳輸控制協(xié)議（TCP）

1.TCP全稱是Transmission Control PRotocol，中文名為傳輸控制協(xié)議，它可以提供可靠的、面向連接的網(wǎng)絡(luò)數(shù)據(jù)傳遞服務(wù)。傳輸控制協(xié)議主要包含下列任務(wù)和功能：

2.確保IP數(shù)據(jù)報(bào)的成功傳遞。

對程序發(fā)送的大塊數(shù)據(jù)進(jìn)行分段和重組。

確保正確排序及按順序傳遞分段的數(shù)據(jù)。

通過計(jì)算校驗(yàn)和，進(jìn)行傳輸數(shù)據(jù)的完整性檢查。

根據(jù)數(shù)據(jù)是否接收成功發(fā)送肯定消息。通過使用選擇性確認(rèn)，也對沒有收到的數(shù)據(jù)發(fā)送否定確認(rèn)。

為必須使用可靠的、基于會(huì)話的數(shù)據(jù)傳輸程序，如客戶端/服務(wù)器數(shù)據(jù)庫和電子郵件程序，提供首選傳輸方法。

3.TCP工作原理

TCP的連接建立過程又稱為TCP三次握手：

首先發(fā)送方主機(jī)向接收方主機(jī)發(fā)起一個(gè)建立連接的同步（SYN）請求；

接收方主機(jī)在收到這個(gè)請求后向發(fā)送方主機(jī)回復(fù)一個(gè)同步/確認(rèn)（SYN/ACK）應(yīng)答；

發(fā)送方主機(jī)收到此包后再向接收方主機(jī)發(fā)送一個(gè)確認(rèn)（ACK），此時(shí)TCP連接成功建立.

一旦初始的三次握手完成，在發(fā)送和接收主機(jī)之間將按順序發(fā)送和確認(rèn)段。關(guān)閉連接之前，TCP使用類似的握手過程驗(yàn)證兩個(gè)主機(jī)是否都完成發(fā)送和接收全部數(shù)據(jù)。

完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。

三次握手示意圖：

三次握手.png

TCP工作過程比較復(fù)雜，包括的內(nèi)容如下。

TCP連接關(guān)閉：發(fā)送方主機(jī)和目的主機(jī)建立TCP連接并完成數(shù)據(jù)傳輸后，會(huì)發(fā)送一個(gè)將結(jié)束標(biāo)記置1的數(shù)據(jù)包，以關(guān)閉這個(gè)TCP連接，并同時(shí)釋放該連接占用的緩沖區(qū)空間。

TCP重置：TCP允許在傳輸?shù)倪^程中突然中斷連接。

TCP數(shù)據(jù)排序和確認(rèn)*：在傳輸?shù)倪^程中使用序列號和確認(rèn)號來跟蹤數(shù)據(jù)的接收情況。

TCP重傳：在TCP的傳輸過程中，如果在重傳超時(shí)時(shí)間內(nèi)沒有收到接收方主機(jī)對某數(shù)據(jù)包的確認(rèn)回復(fù)，發(fā)送方主機(jī)就認(rèn)為此數(shù)據(jù)包丟失，并再次發(fā)送這個(gè)數(shù)據(jù)包給接收方。

TCP延遲確認(rèn)：TCP并不總是在接收到數(shù)據(jù)后立即對其進(jìn)行確認(rèn)，它允許主機(jī)在接收數(shù)據(jù)的同時(shí)發(fā)送自己的確認(rèn)信息給對方。

TCP數(shù)據(jù)保護(hù)（校驗(yàn)）：TCP是可靠傳輸?shù)膮f(xié)議，它提供校驗(yàn)和計(jì)算來實(shí)現(xiàn)數(shù)據(jù)在傳輸過程中的完整性。

用戶數(shù)據(jù)報(bào)協(xié)議（UDP）

UDP全稱是User Datagram Protocol，中文名為用戶數(shù)據(jù)報(bào)協(xié)議。UDP 提供無連接的網(wǎng)絡(luò)服務(wù)，該服務(wù)對消息中傳輸?shù)臄?shù)據(jù)提供不可靠的、最大努力傳送。這意味著它不保證數(shù)據(jù)報(bào)的到達(dá)，也不保證所傳送數(shù)據(jù)包的順序是否正確。

我最初就有一個(gè)疑惑：“既然UDP是一種不可靠的網(wǎng)絡(luò)協(xié)議，那么還有什么使用價(jià)值或必要呢？”

在有些情況下UDP可能會(huì)變得非常有用。因?yàn)閁DP具有TCP所望塵莫及的速度優(yōu)勢。雖然TCP中植入了各種安全保障功能，但是在實(shí)際執(zhí)行的過程中會(huì)占用大量的系統(tǒng)開銷，無疑使速度受到嚴(yán)重的影響。反觀UDP由于排除了信息可靠傳遞機(jī)制，將安全和排序等功能移交給上層應(yīng)用來完成，極大地降低了執(zhí)行時(shí)間，使速度得到了保證。

TCP與端口號

TCP和UDP都是IP層面的傳輸協(xié)議，是IP與上層之間的處理接口。TCP和UDP端口號被設(shè)計(jì)來區(qū)分運(yùn)行在單個(gè)設(shè)備上的多重應(yīng)用程序的IP地址。由于同一臺(tái)計(jì)算機(jī)上可能會(huì)運(yùn)行多個(gè)網(wǎng)絡(luò)應(yīng)用程序，所以計(jì)算機(jī)需要確保目標(biāo)計(jì)算機(jī)上接收源主機(jī)數(shù)據(jù)包的軟件應(yīng)用程序的正確性，以及響應(yīng)能夠被發(fā)送到源主機(jī)的正確應(yīng)用程序上。該過程正是通過使用TCP或UDP端口號來實(shí)現(xiàn)的。

－－即每一個(gè)應(yīng)用都會(huì)在網(wǎng)卡上注冊一個(gè)端口號用來區(qū)分同一臺(tái)設(shè)備上應(yīng)用的之間的通信

在TCP和UDP頭部分，有“源端口”和“目標(biāo)端口”段，主要用于顯示發(fā)送和接收過程中的身份識(shí)別信息。IP 地址和端口號合在一起被稱為“套接字”。TCP端口比較復(fù)雜，其工作方式與UDP端口不同。UDP端口對于基于UDP的通信作為單一消息隊(duì)列和網(wǎng)絡(luò)端點(diǎn)來操作，而所有TCP通信的終點(diǎn)都是唯一的連接。每個(gè)TCP連接由兩個(gè)端點(diǎn)唯一識(shí)別。由于所有TCP連接由兩對 IP 地址和TCP端口唯一識(shí)別（每個(gè)所連主機(jī)都有一個(gè)地址/端口對），因此每個(gè)TCP服務(wù)器端口都能提供對多個(gè)連接的共享訪問

再看一下IP數(shù)據(jù)包和TCP／UDP的數(shù)據(jù)包

數(shù)據(jù)包.png

HTTP協(xié)議

超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。

http協(xié)議規(guī)定了客戶端和服務(wù)器之間的數(shù)據(jù)傳輸格式.

http優(yōu)點(diǎn):

簡單快速:http協(xié)議簡單,通信速度很快;

靈活:http協(xié)議允許傳輸任意類型的數(shù)據(jù);

短連接:http協(xié)議限制每次連接只處理一個(gè)請求,服務(wù)器對客戶端的請求作出響應(yīng)后,馬上斷開連接.這種方式可以節(jié)省傳輸時(shí)間.

HTTP協(xié)議的使用

1.請求:客戶端向服務(wù)器索要數(shù)據(jù).

http協(xié)議規(guī)定:一個(gè)完整的http請求包含'請求行','請求頭','請求體'三個(gè)部分;

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

請求頭:包含了對客戶端的環(huán)境描述,客戶端請求的主機(jī)地址等信息.

Accept: text/html ( 客戶端所能接收的數(shù)據(jù)類型 )

Accept-Language: zh-cn ( 客戶端的語言環(huán)境 )

Accept-Encoding: gzip( 客戶端支持的數(shù)據(jù)壓縮格式 )

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

請求體:客戶端發(fā)給服務(wù)器的具體數(shù)據(jù),比如文件/圖片等.

2.響應(yīng):服務(wù)器返回客戶端想要的數(shù)據(jù)

http協(xié)議規(guī)定:一個(gè)完整的http響應(yīng)包含'狀態(tài)行','響應(yīng)頭','實(shí)體內(nèi)容'三個(gè)部分;

狀態(tài)行:包含了http協(xié)議版本,狀態(tài)嗎,狀態(tài)英文名稱.

"HTTP/1.1 200 OK"

響應(yīng)頭:包含了對服務(wù)器的描述,對返回?cái)?shù)據(jù)的描述.

Content-Encoding: gzip(服務(wù)器支持的數(shù)據(jù)壓縮格式) Content-Length: 1528(返回?cái)?shù)據(jù)的長度)

Content-Type:application/xhtml+xml;charset=utf-8(返回?cái)?shù)據(jù)的類型)

Date: Mon,15Jun201509:06:46GMT(響應(yīng)的時(shí)間) Server: apache (服務(wù)器類型)

實(shí)體內(nèi)容:服務(wù)器返回給客戶端的具體數(shù)據(jù)(圖片/html/文件...).

3.發(fā)送http請求

在iOS開發(fā)中,發(fā)送http請求的方案有很多,常見的有如下幾種:

蘋果原生:

1.NSURLConnection:用法簡單,古老經(jīng)典的一種方案.

2.NSURLsession:iOS7以后推出的技術(shù),功能NSURLConnection更加強(qiáng)大.

3.CFNetWork:NSURL的底層,純C語言,一般不用.

第三方框架:

AFNetWorking（OC）；Alamofire（swift）；

HTTP方法

http協(xié)議定義了很多方法對應(yīng)不同的資源操作,其中最常用的是GET和POST方法。

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

增:PUT

刪:DELETE

改:POST

查:GET

因?yàn)镚ET和POST可以實(shí)現(xiàn)上述所有操作,所以,在現(xiàn)實(shí)開發(fā)中,GET和POST方法使用的最為廣泛，除此以外HEAD請求使用頻率也比較高；

GET

在請求URL后面以?的形式跟上發(fā)給服務(wù)器的參數(shù),參數(shù)以"參數(shù)名"="參數(shù)值"的形式拼接,多個(gè)參數(shù)之間用&分隔;

GET的本質(zhì)是從服務(wù)器得到數(shù)據(jù),效率更高.并且GET請求可以被緩存.

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

POST

POST的本質(zhì)是向服務(wù)器發(fā)送數(shù)據(jù),也可以獲得服務(wù)器處理之后的結(jié)果,效率不如GET.POST請求不可以被緩存,每次刷新之后都需要重新提交表單.

發(fā)送給服務(wù)器的參數(shù)全部放在'請求體'中;

理論上,POST傳遞的數(shù)據(jù)量沒有限制.

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

HEAD

HEAD方法通常用在下載文件之前,獲取遠(yuǎn)程服務(wù)器的文件信息!相比于GET請求,不會(huì)下載文件數(shù)據(jù),只獲得響應(yīng)頭信息!

一般,使用HEAD方法的目的是提前告訴用戶下載文件的信息,由用戶確定是否下載文件!所以, HEAD方法,最好發(fā)送同步請求!

響應(yīng)消息

1xx:信息響應(yīng)類，表示接收到請求并且繼續(xù)處理

2xx:處理成功響應(yīng)類，表示動(dòng)作被成功接收、理解和接受

3xx:重定向響應(yīng)類，為了完成指定的動(dòng)作，必須接受進(jìn)一步處理

4xx:客戶端錯(cuò)誤，客戶請求包含語法錯(cuò)誤或者是不能正確執(zhí)行

5xx:服務(wù)端錯(cuò)誤，服務(wù)器不能正確執(zhí)行一個(gè)正確的請求;

詳細(xì)描述：狀態(tài)碼

Socket

Socket 簡介

Socket起源于 20 世紀(jì) 80 年代早期,最早由 4.1c BSD UNIX 引入,所以也稱之為“BSD Socket 或者 Berkeley Socket”。BSD Socket 是事實(shí)上的網(wǎng)絡(luò)應(yīng)用編程接口標(biāo)準(zhǔn),其它編程語言往往也是用與這套（用C寫成的編程接口）類似接口。

用 Socket 能夠?qū)崿F(xiàn)網(wǎng)絡(luò)上的不同主機(jī)之間或同一主機(jī)的不同對象之間的數(shù)據(jù)通信。所以,現(xiàn)在 Socket 已經(jīng)是一類通用通信接口的集合。

大的類型可以分為網(wǎng)絡(luò) Socket 和本地 Socket 兩種。

本地上的兩個(gè)進(jìn)程如何通信?

內(nèi)存共享(munmap())；

消息和隊(duì)列；

管道(匿名管道pipe()和命名管道m(xù)kfifo())；

信號量（P V操作）;

RPC remote protocol control

本地Socket;

網(wǎng)路上的兩個(gè)進(jìn)程如何通信？

本地進(jìn)程間通信(IPC)通過PID(在終端中輸入ps -ef可查看PID)可以唯一確定彼此，然后通過共享內(nèi)存，消息隊(duì)列來通;網(wǎng)絡(luò)上的兩個(gè)進(jìn)程確定彼此需要IP與端口號，通過傳輸層(TCP/UDP)協(xié)議進(jìn)行通信；

這就是網(wǎng)絡(luò) Socket 。

socket可以理解為：在TCP/UDP 加一個(gè)端口(在網(wǎng)卡注冊的，還記得吧)綁定。

網(wǎng)路socket和本地 Socket對比

在同一個(gè)設(shè)備上，兩個(gè)進(jìn)程如果需要進(jìn)行通訊最基本的一個(gè)前提能能夠唯一的標(biāo)示一個(gè)進(jìn)程，在本地進(jìn)程通訊中可以使用PID來唯一標(biāo)示一個(gè)進(jìn)程；

PID只在本地唯一，網(wǎng)絡(luò)中的兩個(gè)進(jìn)程PID沖突幾率很大，此時(shí)顯然不行了，怎么辦？

IP層的ip地址可以唯一標(biāo)示主機(jī)，而TCP層協(xié)議和端口號可以唯一標(biāo)示主機(jī)的一個(gè)進(jìn)程，所以可以利用ip地址＋協(xié)議＋端口號唯一標(biāo)示網(wǎng)絡(luò)中的一個(gè)進(jìn)程。

Socket通信就是一種確定了端口號的TCP/IP通信，或者說Socket通信與IP通信差別就是端口確定，協(xié)議確定。

用一張圖表達(dá)一下：

Socket.png

端口的打開是雙方的，在C/S（Client&&Server）結(jié)構(gòu)的TCP連接中不僅僅要注意到S的端口(監(jiān)聽的)，實(shí)際上C也開了一個(gè)端口，而C端的端口是動(dòng)態(tài)端口，TCP連接建立的時(shí)候，C端的端口會(huì)在三次握手結(jié)束后確定，動(dòng)態(tài)打開一個(gè),這個(gè)端口不受用戶/程序員的控制。

Socket C 端書寫步驟

創(chuàng)建客戶端Socket

創(chuàng)建服務(wù)器Socket

連接到服務(wù)器(Socket編程)

發(fā)送數(shù)據(jù)給服務(wù)器

接收服務(wù)器返回的數(shù)據(jù)

關(guān)閉Socket : close(socketNumber)

一張經(jīng)典的Socket C/S的步驟圖。