網絡-OSI分層模型與TCP/ IP分層模型以及相關協議



        一、Internet

      Internet爲實現網絡互連

  硬件支持--如路由器和各種線路,把分散在各地的網絡在物理上連接起來。

  軟件支持--TCP/IP協議。Internet是基於TCP/IP協議的網間網。

  二、TCP/IP分層模型

  TCP/IP分層模型(簡稱TCP/IP模型)及與OSI參考模型的對應關係如圖1所示。

iso 7 4

  圖1 TCP/IP模型及與OSI參考模型的對應關係

  

   HTTP協議:簡單對象訪問協議,對應於應用層 ,HTTP協議是基於TCP連接的

   SOAP協議:簡單對象訪問協議是交換數據的一種協議規範,是一種輕量的、簡單的、基於XML標準通用標記語言下的一個子集)的協議,它被設計成在WEB上交換結構化的和固化的信息。基於http協議上的封裝(CXF的webservice)。

   RPC協議:遠程過程調用協議,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在,如TCP或UDP,爲通信程序之間攜帶信息數據。在OSI網絡通信模型中,RPC跨越了傳輸層應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。

   接口協議選擇RPC和SOAP的對比:簡單來說: SOAP = HTTP+XML+RPC

      SOAP和RPC都是SOA的具體實現方式。

   SOAP是基於HTTP和XML的實現,因此會更容易做業務隔離,在系統可維護性和可擴展性上優於RPC,多用於外網的第三方接口服務

  對於RPC本身可以走HTTP ,TCP等不同的協議,比如淘寶的Dubbo框架,RPC是可以選擇走TCP協議還是走HTTP協議的,RPC是基於TCP或自定義協議的實現,性能會略好於SOAP,但是異構系統間(內部接口)的耦合度會更高,間接增加系統的故障率和排錯難度。

   HTTP協議:簡單對象訪問協議,對應於應用層 ,HTTP協議是基於TCP連接的。

   tcp協議:對應於傳輸層
   ip協議: 對應於網絡層 

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

   Socket:是對TCP/IP協議的封裝,Socket本身並不是協議,而是一個調用接口(API),通過Socket,我們才能使用TCP/IP協議。
http連接:http連接就是所謂的短連接,即客戶端向服務器端發送一次請求,服務器端響應後連接即會斷掉;

   

1、TCP/IP連接

手機能夠使用聯網功能是因爲手機底層實現了TCP/IP協議,可以使手機終端通過無線網絡建立TCP連接。TCP協議可以對上層網絡提供接口,使上層網絡數據的傳輸建立在“無差別”的網絡之上。
建立起一個TCP連接需要經過“三次握手”:
第一次握手:客戶端發送syn包(syn=j)到服務器,並進入SYN_SEND狀態,等待服務器確認;
第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;
第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTABLISHED狀態,完成三次握手。
握手過程中傳送的包裏不包含數據,三次握手完畢後,客戶端與服務器才正式開始傳送數據。理想狀態下,TCP連接一旦建立,在通信雙方中的任何一方主動關閉連接之前,TCP 連接都將被一直保持下去。斷開連接時服務器和客戶端均可以主動發起斷開TCP連接的請求,斷開過程需要經過“四次握手”(過程就不細寫了,就是服務器和客戶端交互,最終確定斷開).
2、HTTP連接
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束後,會主動釋放連接。從建立連接到關閉連接的過程稱爲“一次連接”。
1)在HTTP 1.0中,客戶端的每次請求都要求建立一次單獨的連接,在處理完本次請求後,就自動釋放連接。
2)在HTTP 1.1中則可以在一次連接中處理多個請求,並且多個請求可以重疊進行,不需要等待一個請求結束後再發送下一個請求。
由於HTTP在每次請求結束後都會主動釋放連接,因此HTTP連接是一種“短連接”,要保持客戶端程序的在線狀態,需要不斷地向服務器發起連接請求。通常的做法是即時不需要獲得任何數據,客戶端也保持每隔一段固定的時間向服務器發送一次“保持連接”的請求,服務器在收到該請求後對客戶端進行回覆,表明知道客戶端“在線”。若服務器長時間無法收到客戶端的請求,則認爲客戶端“下線”,若客戶端長時間無法收到服務器的回覆,則認爲網絡已經斷開。

3、SOAP連接

SOAP消息基本上是從發送端到接收端的單向傳輸,但它們常常結合起來執行類似於請求 / 應答的模式。所有的 SOAP消息都使用 XML 編碼。一條 SOAP消息就是一個包含有一個必需的 SOAP 的封裝包,一個可選的 SOAP 標頭和一個必需的 SOAP 體塊的 XML 文檔。把 SOAP 綁定到 HTTP 提供了同時利用 SOAP 的樣式和分散的靈活性的特點以及 HTTP 的豐富的特徵庫的優點。在HTTP上傳送 SOAP 並不是說 SOAP 會覆蓋現有的 HTTP 語義,而是 HTTP 上的 SOAP 語義會自然的映射到 HTTP 語義。在使用 HTTP 作爲協議綁定的場合中, RPC 請求映射到 HTTP 請求上,而 RPC 應答映射到 HTTP 應答。然而,在 RPC 上使用 SOAP 並不僅限於 HTTP 協議綁定。SOAP也可以綁定到TCP和UDP協議上。

4、RPC連接

RPC採用客戶機/服務器模式。請求程序就是一個客戶機,而服務提供程序就是一個服務器。首先,客戶機調用進程發送一個有進程參數的調用信息到服務進程,然後等待應答信息。在服務器端,進程保持睡眠狀態直到調用信息到達爲止。當一個調用信息到達,服務器獲得進程參數,計算結果,發送答覆信息,然後等待下一個調用信息,最後,客戶端調用進程接收答覆信息,獲得進程結果,然後調用執行繼續進行。
5、SOCKET連接
建立Socket連接至少需要一對套接字,其中一個運行於客戶端,稱爲ClientSocket ,另一個運行於服務器端,稱爲ServerSocket 。
套接字之間的連接過程分爲三個步驟:服務器監聽,客戶端請求,連接確認。
服務器監聽:服務器端套接字並不定位具體的客戶端套接字,而是處於等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。
客戶端請求:指客戶端的套接字提出連接請求,要連接的目標是服務器端的套接字。爲此,客戶端的套接字必須首先描述它要連接的服務器的套接字,指出服務器端套接字的地址和端口號,然後就向服務器端套接字提出連接請求。
連接確認:當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求時,就響應客戶端套接字的請求,建立一個新的線程,把服務器端套接字的描述發給客戶端,一旦客戶端確認了此描述,雙方就正式建立連接。而服務器端套接字繼續處於監聽狀態,繼續接收其他客戶端套接字的連接請求。
6、SOCKET連接與TCP/IP連接
創建Socket連接時,可以指定使用的傳輸層協議,Socket可以支持不同的傳輸層協議(TCP或UDP),當使用TCP協議進行連接時,該Socket連接就是一個TCP連接。
socket則是對TCP/IP協議的封裝和應用(程序員層面上)。也可以說,TPC/IP協議是傳輸層協議,主要解決數據 如何在網絡中傳輸,而HTTP是應用層協議,主要解決如何包裝數據。關於TCP/IP和HTTP協議的關係,網絡有一段比較容易理解的介紹:
“我們在傳輸數據時,可以只使用(傳輸層)TCP/IP協議,但是那樣的話,如 果沒有應用層,便無法識別數據內容,如果想要使傳輸的數據有意義,則必須使用到應用層協議,應用層協議有很多,比如HTTP、FTP、TELNET等,也 可以自己定義應用層協議。WEB使用HTTP協議作應用層協議,以封裝HTTP文本信息,然後使用TCP/IP做傳輸層協議將它發到網絡上。”
我們平時說的最多的socket是什麼呢,實際上socket是對TCP/IP協議的封裝,Socket本身並不是協議,而是一個調用接口(API),通過Socket,我們才能使用TCP/IP協議。 實際上,Socket跟TCP/IP協議沒有必然的聯繫。Socket編程接口在設計的時候,就希望也能適應其他的網絡協議。所以說,Socket的出現 只是使得程序員更方便地使用TCP/IP協議棧而已,是對TCP/IP協議的抽象,從而形成了我們知道的一些最基本的函數接口,比如create、 listen、connect、accept、send、read和write等等。網絡有一段關於socket和TCP/IP協議關係的說法比較容易理解:
“TCP/IP只是一個協議棧,就像操作系統的運行機制一樣,必須要具體實現,同時還要提供對外的操作接口。這個就像操作系統會提供標準的編程接口,比如win32編程接口一樣,TCP/IP也要提供可供程序員做網絡開發所用的接口,這就是Socket編程接口。”
實際上,傳輸層的TCP是基於網絡層的IP協議的,而應用層的HTTP協議又是基於傳輸層的TCP協議的,而Socket本身不算是協議,就像上面所說,它只是提供了一個針對TCP或者UDP編程的接口。socket是對端口通信開發的工具,它要更底層一些.
7、Socket連接與HTTP連接
由於通常情況下Socket連接就是TCP連接,因此Socket連接一旦建立,通信雙方即可開始相互發送數據內容,直到雙方連接斷開。但在實際網絡應用中,客戶端到服務器之間的通信往往需要穿越多箇中間節點,例如路由器、網關、防火牆等,大部分防火牆默認會關閉長時間處於非活躍狀態的連接而導致 Socket 連接斷連,因此需要通過輪詢告訴網絡,該連接處於活躍狀態。
而HTTP連接使用的是“請求—響應”的方式,不僅在請求時需要先建立連接,而且需要客戶端向服務器發出請求後,服務器端才能回覆數據。
很多情況下,需要服務器端主動向客戶端推送數據,保持客戶端與服務器數據的實時與同步。此時若雙方建立的是Socket連接,服務器就可以直接將數據傳送給客戶端;若雙方建立的是HTTP連接,則服務器需要等到客戶端發送一次請求後才能將數據傳回給客戶端,因此,客戶端定時向服務器端發送連接請求,不僅可以保持在線,同時也是在“詢問”服務器是否有新的數據,如果有就將數據傳給客戶端。

8、SOAP連接與HTTP連接
是一個基於XML的協議交換消息,可以使用HTTP來傳輸這些信息。事實上HTTP是SOAP消息的最常見的傳輸工具。soap將信息進行XML的序列化後,再用http協議的方式再打包進行傳送,傳送的方式還是tcp或者udp。做個比喻就好理解了。tcp 和 udp 都是公路,暫且把tcp認爲是一般公路,udp高速公路,soap和http就都是汽車,那麼soap和http都可以在tcp和udp上跑。說soap可以通過http來傳送,實際就是說soap是小轎車,http是裝轎車的卡車,把soap的信息裝到http裏面,然後再運輸,當然走的道路還是tcp或udp。說soap可以通過http協議來傳輸,這句話不太準確,比較準確第說法是:soap信息可以通過http協議包裝後通過tcp或udp傳輸。



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

什麼時候用長連接,短連接? 
 長連接多用於操作頻繁,點對點的通訊,而且連接數不能太多情況,。每個TCP連接都需要三步握手,這需要時間,如果每個操作都是先連接,再操作的話那麼處理速度會降低很多,所以每個操作完後都不斷開,次處理時直接發送數據包就OK了,不用建立TCP連接。例如:數據庫的連接用長連接, 如果用短連接頻繁的通信會造成socket錯誤,而且頻繁的socket 創建也是對資源的浪費。 
而像WEB網站的http服務一般都用短鏈接,因爲長連接對於服務端來說會耗費一定的資源,而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都佔用一個連接的話,那可想而知吧。所以併發量大,但每個用戶無需頻繁操作情況下需用短連好。 
 總之,長連接和短連接的選擇要視情況而定。 
發送接收方式 
1、異步 
報文發送和接收是分開的,相互獨立的,互不影響。這種方式又分兩種情況: 
(1)異步雙工:接收和發送在同一個程序中,由兩個不同的子進程分別負責發送和接收 
(2)異步單工:接收和發送是用兩個不同的程序來完成。 
2、同步 
報文發送和接收是同步進行,既報文發送後等待接收返回報文。 同步方式一般需要考慮超時問題,即報文發出去後不能無限等待,需要設定超時時間,超過該時間發送方不再等待讀返回報文,直接通知超時返回。 
在長連接中一般是沒有條件能夠判斷讀寫什麼時候結束,所以必須要加長度報文頭。讀函數先是讀取報文頭的長度,再根據這個長度去讀相應長度的報文。






發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章