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服務應用。

原文地址 ： http://www.cnblogs.com/dongliu/p/5455331.html