iOS網絡HTTP、TCP、UDP、Socket 知識總結


OSI 七層模型

  我們一般使用的網絡數據傳輸由下而上共有七層,分別為物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層,也被依次稱為 OSI 第一層、第二層、⋯⋯、 第七層。

如下圖:

 

各層功能簡介

 

1.物理層(Physical Layer)

  物理層位於 OSI 參考模型的最低層,它直接面向原始比特流的傳輸。為了實現原始比特流的物理傳輸,物理層必須解決好包括傳輸介質、信道類型、數據與信號之間的轉換、信號傳輸中的衰減和噪聲等在內的一系列問題。另外,物理層標准要給出關於物理接口的機械、 電氣、功能和規程特性,以便於不同的制造廠家既能夠根據公認的標准各自獨立地制造設備,又能使各個廠家的產品能夠相互兼容。

2.數據鏈路層(Data Link Layer)

  在物理層發送和接收數據的過程中,會出現一些物理層自己不能解決的問題。例如, 當兩個節點同時試圖在一條線路上發送數據時該如何處理?節點如何知道它所接收的數據 是否正確?如果噪聲改變了一個分組的目標地址,節點如何察覺它丟失了本應收到的分組呢?這些都是數據鏈路層所必須負責的工作。

  數據鏈路層涉及相鄰節點之間的可靠數據傳輸,數據鏈路層通過加強物理層傳輸原始比特的功能,使之對網絡層表現為一條無錯線路。為了能夠實現相鄰節點之間無差錯的數據傳送,數據鏈路層在數據傳輸過程中提供了確認、差錯控制和流量控制等機制。

3.網絡層(Network Layer)

  網絡中的兩台計算機進行通信時,中間可能要經過許多中間結點甚至不同的通信子網。 網絡層的任務就是在通信子網中選擇一條合適的路徑,使發送端傳輸層所傳下來的數據能 夠通過所選擇的路徑到達目的端。

  為了實現路徑選擇,網絡層必須使用尋址方案來確定存在哪些網絡以及設備在這些網絡中所處的位置,不同網絡層協議所采用的尋址方案是不同的。在確定了目標結點的位置后, 網絡層還要負責引導數據包正確地通過網絡,找到通過網絡的最優路徑,即路由選擇。如果子網中同時出現過多的分組,它們將相互阻塞通路並可能形成網絡瓶頸,所以網絡層還需要提供擁塞控制機制以避免此類現象的出現。另外,網絡層還要解決異構網絡互連問題。

4.傳輸層(Transport Layer)

  傳輸層是 OSI 七層模型中唯一負責端到端節點間數據傳輸和控制功能的層。傳輸層是 OSI 七層模型中承上啟下的層,它下面的三層主要面向網絡通信,以確保信息被准確有效地傳輸;它上面的三個層次則面向用戶主機,為用戶提供各種服務。

  傳輸層通過彌補網絡層服務質量的不足,為會話層提供端到端的可靠數據傳輸服務。它為會話層屏蔽了傳輸層以下的數據通信的細節,使會話層不會受到下三層技術變化的影響。但同時,它又依靠下面的三個層次控制實際的網絡通信操作,來完成數據從源到目標的傳輸。傳輸層為了向會話層提供可靠的端到端傳輸服務,也使用了差錯控制和流量控制等機制。

5.會話層(Session Layer)

  會話層的功能是在兩個節點間建立、維護和釋放面向用戶的連接。它是在傳輸連接的基礎上建立會話連接,並進行數據交換管理,允許數據進行單工、半雙工和全雙工的傳送。會話層提供了令牌管理和同步兩種服務功能。

6.表示層(Presentation Layer)

  表示層以下的各層只關心可靠的數據傳輸,而表示層關心的是所傳輸數據的語法和語義。它主要涉及處理在兩個通信系統之間所交換信息的表示方式,包括數據格式變換、數據加密與解密、數據壓縮與恢復等功能。

7.應用層(Application Layer)

  應用層是 OSI 參考模型的最高層,負責為用戶的應用程序提供網絡服務。與 OSI 其他層不同的是,它不為任何其他 OSI 層提供服務,而只是為 OSI 模型以外的應用程序提供服務。包括為相互通信的應用程序或進行之間建立連接、進行同步,建立關於錯誤糾正和控 制數據完整性過程的協商等。應用層還包含大量的應用協議,如分布式數據庫的訪問、文件的交換、電子郵件、虛擬終端等。

 

  其中物理層、數據鏈路層和網絡層通常被稱作媒體層,是網絡工程師所研究的對象;

  傳輸層、會話層、表示層和應用層則被稱作主機層,是用戶所面向和關心的內容。

   http協議   對應於應用層 

   tcp協議    對應於傳輸層  

   ip協議     對應於網絡層 

   三者本質上沒有可比性。  何況HTTP協議是基於TCP連接的。 

   TCP/IP是傳輸層協議,主要解決數據如何在網絡中傳輸;而HTTP是應用層協議,主要解決如何包裝數據。

  我們在傳輸數據時,可以只使用傳輸層(TCP/IP),但是那樣的話,由於沒有應用層,便無法識別數據內容,如果想要使傳輸的數據有意義,則必須使用應用層協議,應用層協議很多,有HTTP、FTP、TELNET等等,也可以自己定義應用層協議。WEB使用HTTP作傳輸層協議,以封裝HTTP文本信息,然后使用 TCP/IP 做傳輸層協議將它發送到網絡上。Socket是對 TCP/IP 協議的封裝,Socket 本身並不是協議,而是一個調用接口(API),通過Socket,我們才能使用TCP/IP 協議。

TCP/IP 模型

 

  TCP/IP 模型是由美國國防部創建的,所以有時又稱 DoD(Department of Defense)模型。 TCP/IP 模型分為四層,由下而上分別為網絡訪問層、網際層、傳輸層、應用層,如圖所示。

  應該指出,TCP/IP 是 OSI 模型之前的產物,所以兩者間不存在嚴格的層對應關系。 在 TCP/IP 模型中並不存在與 OSI 中的物理層與數據鏈路層相對應的部分,相反,由於 TCP/IP 的主要目標是致力於異構網絡的互連,所以在 OSI 中的物理層與數據鏈路層相對應的部分沒有作任何限定。

 

 

  在 TCP/IP 模型中,網絡訪問層是 TCP/IP 模型的最低層,負責接收從網際層交來的 IP 數據報並將 IP 數據報通過底層物理網絡發送出去,或者從底層物理網絡上接收物理幀,抽出 IP 數據報,交給互聯網層。網絡訪問層使采用不同技術和網絡硬件的網絡之間能夠互聯, 它包括屬於操作系統的設備驅動器和計算機網絡接口卡,以處理具體的硬件物理接口。

  網際層負責獨立地將分組從源主機送往目標主機,涉及為分組提供最佳路徑的選擇和 交換功能,並使這一過程與它們所經過的路徑和網絡無關。這好比你寄信時,你並不需要知道它是如何到達目的地的,而只關心它是否到達了。TCP/IP 模型的互聯網層在功能上非常類似於 OSI 參考模型中的網絡層。

  傳輸層的作用與 OSI 參考模型中傳輸層的作用是類似的,即在源結點和目的結點的兩個對等實體間提供可靠的端到端的數據通信。為保證數據傳輸的可靠性,傳輸層協議也提供了確認、差錯控制和流量控制等機制。另外,由在一般的計算機中,常常是多個應用程序同時訪問網絡,所以傳輸層還要提供不同應用程序的標識。

  應用層涉及為用戶提供網絡應用,並為這些應用提供網絡支撐服務。由於 TCP/IP 將所有與應用相關的內容都有歸為一層,所以在應用層要處理高層協議、數據表達和對話控制等任務。

 

OSI 模型和 TCP/IP 模型的區別

 

 

  OSI 模型包括了七層,而 TCP/IP 模型只有四層。雖然它們具有功能相當的網絡層、傳輸層和應用層,但其它層並不相同。

  TCP/IP 模型中沒有專門的表示層和會話層,它將與這兩層相關的表達、編碼和會話控制等功能包含到了應用層中去完成。另外,TCP/IP 模型還將 OSI 的數據鏈路層和物理層包括到了一個網絡訪問層中。

  OSI 模型在網絡層支持無連接和面向連接的兩種服務,而在傳輸層僅支持面向連接的服 務。TCP/IP 模型在互聯網層則只支持無連接的一種服務,但在傳輸層支持面向連接和無連 接兩種服務。

  TCP/IP 由於有較少的層次,因而顯得更簡單,並且作為從因特網(INTERNET)上發展起來的協議,已經成了網絡互連的事實標准。但是,目前還沒有實際網絡是建立在 OSI 七層模型基礎上的,OSI 僅僅作為理論的參考模型被廣泛使用。

Http和Socket連接區別

 

短連接 
  連接->傳輸數據->關閉連接 
  HTTP是無狀態的,瀏覽器和服務器每進行一次HTTP操作,就建立一次連接,但任務結束就中斷連接。 
  也可以這樣說:短連接是指 Socket 連接后發送后接收完數據后馬上斷開連接。 
  
長連接 
  連接->傳輸數據->保持連接 -> 傳輸數據-> 。。。 ->關閉連接。 
  長連接指建立 Socket 連接后不管是否使用都保持連接,但安全性較差。 

http的長連接   

 HTTP也可以建立長連接的,使用Connection:keep-alive,HTTP 1.1默認進行持久連接。HTTP1.1和HTTP1.0相比較而言,最大的區別就是增加了持久連接支持(貌似最新的 http1.0 可以顯示的指定 keep-alive),但還是無狀態的,或者說是不可以信任的。

什么時候用長連接,短連接?    

 長連接多用於操作頻繁,點對點的通訊,而且連接數不能太多情況,。每個TCP連接都需要三步握手,這需要時間,如果每個操作都是先連接,再操作的話那么處理 速度會降低很多,所以每個操作完后都不斷開,次處理時直接發送數據包就OK了,不用建立TCP連接。例如:數據庫的連接用長連接, 如果用短連接頻繁的通信會造成 Socket 錯誤,而且頻繁的 Socket 創建也是對資源的浪費。 
  
  而像WEB網站的http服務一般都用短鏈接,因為長連接對於服務端來說會耗費一定的資源,而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接 會更省一些資源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都占用一個連接的話,那可想而知吧。所以並發量大,但每個用戶無需頻繁操作情況下 需用短連好。 
  
  總之,長連接和短連接的選擇要視情況而定。

 

1、http連接

  HTTP協議即超文本傳送協議(HypertextTransfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。

  HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束后,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

  1)在HTTP 1.0中,客戶端的每次請求都要求建立一次單獨的連接,在處理完本次請求后,就自動釋放連接。

  2)在HTTP 1.1中則可以在一次連接中處理多個請求,並且多個請求可以重疊進行,不需要等待一個請求結束后再發送下一個請求。

  由於HTTP在每次請求結束后都會主動釋放連接,因此HTTP連接是一種“短連接”,要保持客戶端程序的在線狀態,需要不斷地向服務器發起連接請求。通常的 做法是即時不需要獲得任何數據,客戶端也保持每隔一段固定的時間向服務器發送一次“保持連接”的請求,服務器在收到該請求后對客戶端進行回復,表明知道客 戶端“在線”。若服務器長時間無法收到客戶端的請求,則認為客戶端“下線”,若客戶端長時間無法收到服務器的回復,則認為網絡已經斷開。

2、Socket

 

  Socket 是應用層與TCP/IP協議族通信的中間軟件抽象層,它是一組接口。首先讓我們通過一張圖知道Socket在哪里?

a、套接字(Socket)概念

  套接字(Socket)是通信的基石,是支持TCP/IP協議的網絡通信的基本操作單元。它是網絡通信過程中端點的抽象表示,包含進行網絡通信必須的五種信息:連接使用的協議,本地主機的IP地址,本地進程的協議端口,遠地主機的IP地址,遠地進程的協議端口。

  應用層通過傳輸層進行數據通信時,TCP會遇到同時為多個應用程序進程提供並發服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個 TCP協議端口傳輸數據。為了區別不同的應用程序進程和連接,許多計算機操作系統為應用程序與TCP/IP協議交互提供了套接字(Socket)接口。應用層可以和傳輸層通過Socket接口,區分來自不同應用程序進程或網絡連接的通信,實現數據傳輸的並發服務。

b 、建立Socket連接

  建立 Socket 連接至少需要一對套接字,其中一個運行於客戶端,稱為ClientSocket,另一個運行於服務器端,稱為ServerSocket。

  套接字之間的連接過程分為三個步驟:服務器監聽,客戶端請求,連接確認。

  服務器監聽:服務器端套接字並不定位具體的客戶端套接字,而是處於等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。

  客戶端請求:指客戶端的套接字提出連接請求,要連接的目標是服務器端的套接字。為此,客戶端的套接字必須首先描述它要連接的服務器的套接字,指出服務器端套接字的地址和端口號,然后就向服務器端套接字提出連接請求。

  連接確認:當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求時,就響應客戶端套接字的請求,建立一個新的線程,把服務器端套接字的描述發給客戶端,一旦客戶端確認了此描述,雙方就正式建立連接。而服務器端套接字繼續處於監聽狀態,繼續接收其他客戶端套接字的連接請求。

 c、Socket連接與TCP連接

  創建Socket連接時,可以指定使用的傳輸層協議,Socket可以支持不同的傳輸層協議(TCP或UDP),當使用TCP協議進行連接時,該Socket連接就是一個TCP連接。

 d、Socket連接與HTTP連接

  由於通常情況下 Socket 連接就是TCP連接,因此 Socket 連接一旦建立,通信雙方即可開始相互發送數據內容,直到雙方連接斷開。但在實際網絡應用中,客戶端到服務器之間的通信往往需要穿越多個中間節點,例如路由器、網關、防火牆等,大部分防火牆默認會關閉長時間處於非活躍狀態的連接而導致 Socket 連接斷連,因此需要通過輪詢告訴網絡,該連接處於活躍狀態。

  而HTTP連接使用的是“請求—響應”的方式,不僅在請求時需要先建立連接,而且需要客戶端向服務器發出請求后,服務器端才能回復數據。

  很多情況下,需要服務器端主動向客戶端推送數據,保持客戶端與服務器數據的實時與同步。此時若雙方建立的是Socket連接,服務器就可以直接將數據傳送給 客戶端;若雙方建立的是HTTP連接,則服務器需要等到客戶端發送一次請求后才能將數據傳回給客戶端,因此,客戶端定時向服務器端發送連接請求,不僅可以保持在線,同時也是在“詢問”服務器是否有新的數據,如果有就將數據傳給客戶端。

 

tcp和udp的區別

  TCP是面向連接的、傳輸可靠(保證數據正確性且保證數據順序)、用於傳輸大量數據(流模式)、速度慢,建立連接需要開銷較多(時間,系統資源)。

  TCP是一種流模式的協議,是面向連接的,也就是說,在連接持續的過程中,Socket 中收到的數據都是由同一台主機發出的(劫持什么的不考慮),因此,知道保證數據是有序的到達就行了,至於每次讀取多少數據不關心。

  TCP:面向連接、傳輸可靠(保證數據正確性,保證數據順序)、用於傳輸大量數據(流模式)、速度慢,建立連接需要開銷較多(時間,系統資源)。

  UDP:面向非連接、傳輸不可靠、用於傳輸少量數據(數據包模式)、速度快。

  關於TCP是一種流模式的協議,UDP是一種數據報模式的協議,這里要說明一下,TCP是面向連接的,也就是說,在連接持續的過程中,socket 中收到的數據都是由同一台主機發出的(劫持什么的不考慮),因此,知道保證數據是有序的到達就行了,至於每次讀取多少數據自己看着辦。

  而UDP是無連接的協議,也就是說,只要知道接收端的IP和端口,且網絡是可達的,任何主機都可以向接收端發送數據。這時候,如果一次能讀取超過一個報文的數據,則會亂套。比如,主機A向發送了報文P1,主機B發送了報文P2,如果能夠讀取超過一個報文的數據,那么就會將P1和P2的數據合並在了一 起,這樣的數據是沒有意義的。

TCP三次握手和四次揮手

  相對於SOCKET開發者,TCP創建過程和連接拆除過程是由 TCP/IP 協議棧自動創建的。因此開發者並不需要控制這個過程。但是對於理解TCP底層運作機制,相當有幫助。

  因此在這里詳細解釋一下這兩個過程。

TCP三次握手

  所謂三次握手(Three-way Handshake),是指建立一個TCP連接時,需要客戶端和服務器總共發送3個包。

  三次握手的目的是連接服務器指定端口,建立TCP連接,並同步連接雙方的序列號和確認號並交換 TCP 窗口大小信息.在 Socket 編程中,客戶端執行connect()時。將觸發三次握手。 

  首先了解一下幾個標志,SYN(synchronous),同步標志,ACK (Acknowledgement),即確認標志,seq應該是Sequence Number,序列號的意思,另外還有四次握手的fin,應該是final,表示結束標志。

  第一次握手:客戶端發送一個TCP的SYN標志位置1的包指明客戶打算連接的服務器的端口,以及初始序號X,保存在包頭的序列號(Sequence Number)字段里。

  第二次握手:服務器發回確認包(ACK)應答。即SYN標志位和ACK標志位均為1同時,將確認序號(Acknowledgement Number)設置為客戶的序列號加1以,即X+1。

  第三次握手:客戶端再次發送確認包(ACK) SYN標志位為0,ACK標志位為1。並且把服務器發來ACK的序號字段+1,放在確定字段中發送給對方.並且在數據段放寫序列號的+1。

tcp四次揮手

  TCP的連接的拆除需要發送四個包,因此稱為四次揮手(four-way handshake)。客戶端或服務器均可主動發起揮手動作,在socket

  編程中,任何一方執行close()操作即可產生揮手操作。

  其實有個問題,為什么連接的時候是三次握手,關閉的時候卻是四次揮手?

  因為當Server端收到Client端的SYN連接請求報文后,可以直接發送SYN+ACK報文。其中ACK報文是用來應答的,SYN報文是用來 同步的。但是關閉連接時,當Server端收到FIN報文時,很可能並不會立即關閉SOCKET,所以只能先回復一個ACK報文,告訴Client端,” 你發的FIN報文我收到了”。只有等到我Server端所有的報文都發送完了,我才能發送FIN報文,因此不能一起發送。故需要四步握手。

  tcpsocket和udpsocket的具體實現

  tcp和udp的socket是有區別的,這里給出這兩種的設計框架

基本TCP客戶—服務器程序設計基本框架

 

基本UDP客戶—服務器程序設計基本框架流程圖

 

  常用的Socket類型有兩種:流式Socket(SOCK_STREAM)和數據報式Socket(SOCK_DGRAM)。流式是一種面向連接的 Socket,針對於面向連接的TCP服務應用;數據報式 Socket 是一種無連接的 Socket ,對應於無連接的UDP服務應用。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM