TCP/UDP、IP 、Socket、HTTP筆記

1.1 TCP/IP協(xié)議組

TCP/IP協(xié)議(傳輸控制協(xié)議)由網(wǎng)絡層的IP協(xié)議和傳輸層的TCP協(xié)議組成

IP層負責網(wǎng)絡主機的定位,數(shù)據(jù)傳輸?shù)穆酚?由IP地址可以唯一的確定Internet上的一臺主機。

TCP層負責面向應用的可靠的或費可靠的數(shù)據(jù)傳輸機制,這是網(wǎng)絡編程的主要對象。

TCP/IP是個協(xié)議組,可分為三個層次:網(wǎng)絡層,傳輸層和應用層:

網(wǎng)絡層:IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議

傳輸層:TCP協(xié)議與UDP協(xié)議;

應用層:FTP、HTTP、TELNET、SMTP、DNS等協(xié)議

HTTP是應用層協(xié)議,其傳輸都是被包裝成TCP協(xié)議傳輸。可以用Socket實現(xiàn)HTTP。Socket是實現(xiàn)傳輸層協(xié)議的一種編程API,可以是TCP,也可以是UDP。

1.2 TCP

TCP(Transmission Control Protocol),即傳輸控制協(xié)議,提供的是面向連接、可靠的字節(jié)流服務。當客戶和服務器彼此交換數(shù)據(jù)前,必須先在雙方之間建立一個TCP連接,之后才能傳輸數(shù)據(jù)。TCP提供超時重發(fā),丟棄重復數(shù)據(jù),檢驗數(shù)據(jù),流量控制等功能,保證數(shù)據(jù)能從一端傳到另一端。理想狀態(tài)下,TCP連接一旦建立,在通信雙方中的任何一方主動關閉連接前,TCP連接都將被一直保持下去。斷開連接時服務器和客戶端均可以主動發(fā)起斷開TCP連接的請求。

TCP是一種面向連接的保證可靠傳輸?shù)膮f(xié)議。通過TCP協(xié)議,得到的是一個順序的無差錯的數(shù)據(jù)流。發(fā)送方和接收方的成對的兩個Socket之間必須建立連接,以便在TCP協(xié)議的基礎上進行通信,當一個Socket(通常都是Server Socket)等待建立連接時,另一個Socket可以要求進行連接,一旦這兩個Socket連接起來,它們就可以進行雙向數(shù)據(jù)傳輸,雙方都可以進行發(fā)送和接收操作。

TCP特點

1.TCP是面向連接的協(xié)議,通過三次握手建立連接,通訊完成時要拆除連接,由于TCP是面向連接協(xié)議,所以只能用于點對點的通訊。而且建立連接也需要消耗時間和開銷。2.TCP傳輸數(shù)據(jù)無大小限制,進行大數(shù)據(jù)傳輸。3.TCP是一個可靠的協(xié)議,它能保證接收方能夠完整正確地接收到發(fā)送方發(fā)送的全部數(shù)據(jù)。

TCP的三次握手

第一次握手:客戶端發(fā)送syn包(syn=j)到服務器,并進入SYN_SEND狀態(tài),等待服務器確認;第二次握手:服務器收到syn包,必須確認客戶的SYN(ack=j+1),同時自己也發(fā)送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態(tài);第三次握手:客戶端收到服務器的SYN+ACK包,向服務器發(fā)送確認包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務器進入ESTABLISHED狀態(tài),完成三次握手;

【適用情況】

TCP發(fā)送的包有序號,對方收到包后要給一個反饋,如果超過一定時間還沒收到反饋就自動執(zhí)行超時重發(fā),因此TCP最大的優(yōu)點是可靠。一般網(wǎng)頁(http)、郵件(SMTP)、遠程連接(Telnet)、文件(FTP)傳送就用TCP

TCP在網(wǎng)絡通信上有極強的生命力,例如遠程連接(Telnet)和文件傳輸(FTP)都需要不定長度的數(shù)據(jù)被可靠地傳輸。但是可靠的傳輸是要付出代價的,對數(shù)據(jù)內容正確性的檢驗必然占用計算機的處理時間和網(wǎng)絡的帶寬,因此TCP傳輸?shù)男什蝗鏤DP高。

1.3 UDP

UDP(User Datagram Protocol),即用戶數(shù)據(jù)報協(xié)議,是一個無連接的簡單的面向數(shù)據(jù)報的運輸層協(xié)議。UDP不提供可靠性,它只是把應用程序傳給IP層的數(shù)據(jù)報發(fā)送出去,但是并不能保證它們能到達目的地。由于UDP在傳輸數(shù)據(jù)報前不用在客戶端和服務器之間建立一個連接,且沒有超時重發(fā)等機制,固而傳輸速度很快。

UDP是一種面向無連接的協(xié)議,每個數(shù)據(jù)報都是一個獨立的信息,包括完整的源地址或目的地址,它在網(wǎng)路上以任何可能的路徑傳往目的地,因此能否到達目的地,到達目的地的時間已經(jīng)內容的正確性都是不能被保證的。

UDP特點:

UDP是面向無連接的通訊協(xié)議,UDP數(shù)據(jù)包括目的端口號和源端口號信息,由于通訊不需要連接,所以可以實現(xiàn)廣播發(fā)送。

UDP傳輸數(shù)據(jù)時有大小限制,每個被傳輸?shù)臄?shù)據(jù)報必須限定在64KB之內。

UDP是一個不可靠的協(xié)議,發(fā)送方所發(fā)送的數(shù)據(jù)報并不一定以相同的次序到達接收方。

【適用情況】

UDP是面向消息的協(xié)議,通訊時不需要建立連接,數(shù)據(jù)的傳輸自然是不可靠的,UDP一般多用于多點通訊和實時的數(shù)據(jù)業(yè)務,比如語音廣播、視頻、QQ、TFTP(簡單文件傳送)、SNMP(簡單網(wǎng)絡管理協(xié)議)、RTP(實時傳送協(xié)議)RIP(路由信息協(xié)議,如報告股票市場,航空信息)、DNS(域名解釋)。注重速度流暢。

UDP操作簡單,而且僅需要較少的監(jiān)護,因此通常用于局域網(wǎng)高可靠性的分散系統(tǒng)中client/server應用程序。例如視頻會議系統(tǒng),并不要求音頻視頻數(shù)據(jù)絕對的正確,只要保證連貫性就可以了,這種情況下顯然使用UDP會更合理一些。

1.4 TCP和UDP區(qū)別

TCP是面向流字符的,數(shù)據(jù)流間無邊界;UDP是面向分組的,分組間有明確的邊界。

對于TCP,發(fā)送一串數(shù)字(1,2,3,4,5),接收時有可能變成兩次(1,2)和(2,4,5),或者變成任意接收方式,協(xié)議棧只保證接收順序正確;UDP發(fā)送一個分組,接收方或者接收完全失敗,如果成功整個分組都會接收到。

TCP是面向連接的,UDP是無連接的。類比于打電話和發(fā)電報的關系。

TCP建立一個連接需要3次握手IP數(shù)據(jù)包,斷開連接需要4次握手。另外斷開連接時發(fā)起方可能進入TIME_WAIT狀態(tài)長達數(shù)分鐘(視系統(tǒng)設置,windows一般為120秒),在此狀態(tài)下連接(端口)無法被釋放

TCP是可靠的,通過數(shù)據(jù)校驗保證發(fā)送和接收到的數(shù)據(jù)是一致的;UDP是不可靠的,發(fā)送一串數(shù)字分組(1,2,3)可能接收到時就變成(1,0,0)了,做UDP連接時需要自己做數(shù)據(jù)校驗。

TCP數(shù)據(jù)是有序的,以什么順序發(fā)送的數(shù)據(jù),接收時同樣會按照此順序;UDP是無序的,發(fā)出(1,2,3),有可能按照(1,3,2)的順序收到。應用程序必須自己做分組排序。

TCP因為建立連接、釋放連接、IP分組校驗排序等需要額外工作,速度較UDP慢許多。TCP適合傳輸數(shù)據(jù),UDP適合流媒體。

UDP比TCP更容易穿越路由器防火墻。

1.5 Socket

Socket通常也稱作“套接字”,用于描述IP地址和端口,是一個通信鏈的句柄。網(wǎng)絡上的兩個程序通過一個雙向的通訊連接實現(xiàn)數(shù)據(jù)的交換,這個雙向鏈路的一端稱為一個Socket,一個Socket由一個IP地址和一個端口號唯一確定。應用程序通常通過“套接字”向網(wǎng)絡發(fā)送請求或者應答網(wǎng)絡請求。Socket是TCP/IP協(xié)議的一個十分流行的編程界面,但是,Socket所支持的協(xié)議種類也不光TCP/IP一種,因此兩者之間是沒有必然聯(lián)系的。

Socket通訊過程:服務器監(jiān)聽某個端口是否有連接請求,客戶端向服務端發(fā)送連接請求,服務端收到連接請求向客戶端發(fā)出接收信息,這樣一個連接就建立起來了。客戶端和服務端都可以相互發(fā)送消息與對方進行通訊。

Socket是應用層與TCP/IP協(xié)議族通信的中間軟件抽象層,它是一組接口。在設計模式中,Socket其實就是一個門面模式,它把復雜的TCP/IP協(xié)議族隱藏在Socket接口后面,對用戶來說,一組簡單的接口就是全部,讓Scoket去組織數(shù)據(jù),以符合指定的協(xié)議。

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

優(yōu)點:

1.傳輸數(shù)據(jù)為字節(jié)級,傳輸數(shù)據(jù)可自定義,數(shù)據(jù)量小。相應的移動端開發(fā),手機費用低2.傳輸數(shù)據(jù)時間短,性能高3.適合C/S之間信息實時交互4.可以加密,數(shù)據(jù)安全性高

缺點:

1.需要對傳輸?shù)臄?shù)據(jù)進行解析,轉化為應用級的數(shù)據(jù)2.對開發(fā)人員的開發(fā)水平要求高3.相對于Http協(xié)議傳輸,增加了開發(fā)量

適用場景:

網(wǎng)絡游戲,銀行交互,支付。

1.套接字(socket)概念

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

應用層通過傳輸層進行數(shù)據(jù)通信時,TCP會遇到同時為多個應用程序進程提供并發(fā)服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個TCP協(xié)議端口傳輸數(shù)據(jù)。為了區(qū)別不同的應用程序進程和連接,許多計算機操作系統(tǒng)為應用程序與TCP/IP協(xié)議交互提供了套接字(Socket)接口。應用層可以和傳輸層通過Socket接口,區(qū)分來自不同應用程序進程或網(wǎng)絡連接的通信,實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務。

2.建立socket連接

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

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

服務器監(jiān)聽:服務器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態(tài),實時監(jiān)控網(wǎng)絡狀態(tài),等待客戶端的連接請求

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

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

3.Socket連接與TCP連接

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

【適用情況】

很多情況下,需要服務器端主動向客戶端推送數(shù)據(jù),保持客戶端與服務器數(shù)據(jù)的實時與同步。此時若雙方建立的是Socket連接,服務器就可以直接將數(shù)據(jù)傳送給客戶端;

1.6 HTTP

HTTP(Hypertext Transfer Protocol )協(xié)議是建立在TCP協(xié)議之上的一種應用,HTTP連接使用的是“請求—響應”的方式,不僅在請求時需要先建立TCP連接,而且需要客戶端向服務器發(fā)出請求請求中包含請求方法、URI、協(xié)議版本以及相關的MIME樣式的消息,服務器端才能回復數(shù)據(jù)。服務器響應包含消息的協(xié)議版本、一個成功和失敗碼以及相關的MIME式樣的消息。在請求結束后,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。由于HTTP在每次請求結束后都會主動釋放連接,因此HTTP連接是一種“短連接”,要保持客戶端程序的在線狀態(tài),需要不斷地向服務器發(fā)起連接請求。通常的做法是即使不需要獲得任何數(shù)據(jù),客戶端也保持每隔一段固定的時間向服務器發(fā)送一次“保持連接”的請求,服務器在收到該請求后對客戶端進行回復,表明知道客戶端“在線”。若服務器長時間無法收到客戶端的請求,則認為客戶端“下線”,若客戶端長時間無法收到服務器的回復,則認為網(wǎng)絡已經(jīng)斷開。

為了獲得適當?shù)膫鬏斔俣龋瑒t需要TCP花費額外的回路鏈接時間(RTT)。每一次鏈接的建立需要這種經(jīng)常性的開銷,而其并不帶有實際有用的數(shù)據(jù),只是保證鏈接的可靠性。因此HTTP/1.1提出了可持續(xù)鏈接的實現(xiàn)方法:HTTP/1.1將只建立一次TCP的鏈接而重復地使用它傳輸一系列的請求/響應消息,因此減少了鏈接建立的次數(shù)和經(jīng)常性的鏈接開銷。

結論:HTTP是應用層協(xié)議,其傳輸都是被包裝成TCP協(xié)議傳輸。可以用SOCKET實現(xiàn)HTTP。SOCKET是實現(xiàn)傳輸層協(xié)議的一種編程API,可以是TCP,也可以是UDP。

優(yōu)點:

1.基于應用級的接口使用方便2.要求的開發(fā)水平不高,容錯性強

缺點:

1.傳輸速度慢,數(shù)據(jù)包大。2.如實現(xiàn)實時交互,服務器性能壓力大3.數(shù)據(jù)傳輸安全性差

適用場景:

公司OA服務,互聯(lián)網(wǎng)服務

【適用情況】

若雙方建立的是HTTP連接,則服務器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端,因此,客戶端定時向服務器端發(fā)送連接請求,不僅可以保持在線,同時也是在“詢問”服務器是否有新的數(shù)據(jù),如果有就將數(shù)據(jù)傳給客戶端。

1.7 網(wǎng)絡協(xié)議總結

網(wǎng)絡由下往上分為

物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層和應用層

通過初步的了解,知道IP協(xié)議對應于網(wǎng)絡層,TCP協(xié)議對應于傳輸層,而 HTTP協(xié)議對應于應用層,

三者從本質上來說沒有可比性

socket則是對TCP/UDP協(xié)議的封裝和應用(程序員層面上)。

也可以說,TPC/UDP協(xié)議是傳輸層協(xié)議,主要解決數(shù)據(jù)如何在網(wǎng)絡中傳輸,而HTTP是應用層協(xié)議,主要解決如何包裝數(shù)據(jù)。

關于TCP/IP和HTTP協(xié)議的關系,網(wǎng)絡有一段比較容易理解的介紹

我們在傳輸數(shù)據(jù)時,可以只使用(傳輸層)TCP/IP協(xié)議,但是那樣的話,如果沒有應用層,便無法識別數(shù)據(jù)內容

如果想要使傳輸?shù)臄?shù)據(jù)有意義,則必須使用到應用層協(xié)議。

應用層協(xié)議有很多,比如HTTP、FTP、TELNET等,也可以自己定義應用層協(xié)議。

CSDN上有個比較形象的描述

HTTP是轎車,提供了封裝或者顯示數(shù)據(jù)的具體形式;Socket是發(fā)動機,提供了網(wǎng)絡通信的能力。

實際上,傳輸層的TCP是基于網(wǎng)絡層的IP協(xié)議的,而應用層的HTTP協(xié)議又是基于傳輸層的TCP協(xié)議的,而Socket本身不算是協(xié)議,就像上面所說,它只是提供了一個針對TCP或者UDP編程的接口。

WEB使用HTTP協(xié)議作應用層協(xié)議,以封裝HTTP文本信息,然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡上。

實際上,Socket跟TCP/IP協(xié)議沒有必然的聯(lián)系

Socket編程接口在設計的時候,就希望也能適應其他的網(wǎng)絡協(xié)議。所以說,Socket的出現(xiàn)只是使得程序員更方便地使用TCP/IP協(xié)議棧而已,是對TCP/IP協(xié)議的抽象,從而形成了我們知道的一些最基本的函數(shù)接口,比如create、listen、connect、accept、send、read和write等等。

網(wǎng)絡有一段關于socket和TCP/IP協(xié)議關系的說法比較容易理解

“TCP/IP與UDP只是一個協(xié)議棧,就像操作系統(tǒng)的運行機制一樣,必須要具體實現(xiàn),同時還要提供對外的操作接口。這個就像操作系統(tǒng)會提供標準的編程接口,比如win32編程接口一樣,TCP/IP也要提供可供程序員做網(wǎng)絡開發(fā)所用的接口,這就是Socket編程接口。”

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,224評論 6 529
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 97,916評論 3 413
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,014評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,466評論 1 308
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,245評論 6 405
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 54,795評論 1 320
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,869評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,010評論 0 285
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,524評論 1 331
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,487評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,634評論 1 366
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,173評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 43,884評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,282評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,541評論 1 281
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,236評論 3 388
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,623評論 2 370

推薦閱讀更多精彩內容