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

時間 2019-11-16

標籤 ios 網絡 http tcp udp socket 知識總結欄目 iOS 简体版

原文原文鏈接

OSI 七層模型

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

以下圖:編程

各層功能簡介

1.物理層(Physical Layer) 瀏覽器

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

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

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

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

3.網絡層(Network Layer) 框架

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

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

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網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源，若是用長鏈接，並且同時有成千上萬的用戶，若是每一個用戶都佔用一個鏈接的話，那可想而知吧。因此併發量大，但每一個用戶無需頻繁操做狀況下需用短連好。

　　總之，長鏈接和短鏈接的選擇要視狀況而定。

一、http鏈接

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

　　HTTP鏈接最顯著的特色是客戶端發送的每次請求都須要服務器回送響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

　　1）在HTTP 1.0中，客戶端的每次請求都要求創建一次單獨的鏈接，在處理完本次請求後，就自動釋放鏈接。

　　2）在HTTP 1.1中則能夠在一次鏈接中處理多個請求，而且多個請求能夠重疊進行，不須要等待一個請求結束後再發送下一個請求。

　　因爲HTTP在每次請求結束後都會主動釋放鏈接，所以HTTP鏈接是一種「短鏈接」，要保持客戶端程序的在線狀態，須要不斷地向服務器發起鏈接請求。一般的作法是即時不須要得到任何數據，客戶端也保持每隔一段固定的時間向服務器發送一次「保持鏈接」的請求，服務器在收到該請求後對客戶端進行回覆，代表知道客戶端「在線」。若服務器長時間沒法收到客戶端的請求，則認爲客戶端「下線」，若客戶端長時間沒法收到服務器的回覆，則認爲網絡已經斷開。

二、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是有區別的，這裏給出這兩種的設計框架