簡而言之:
UDP:UDP是一種面向無連接的用戶數據報服務(user data protocol),不需要和服務器也能交互,只需要知道ip和監聽端口,不需要鏈接沒有目的的socket,只是將數據報投遞出去,不管接收方是否成功接收到,因此是一種不可靠的傳輸,可能會造成數據丟包,但由於這些特徵,傳輸效率要優於TCP。例如QQ傳輸
TCP:TCP是一種面向連接的傳輸控制協議(transform contorl protocol),必須要和服務器交互,具有高安全性,可靠性,需要和服務器進行三次握手,能根據具體網絡擁堵情況進行延時。例如MSN傳輸
TCP/IP實際上是一組協議,它包括上百個各種功能的協議,如:遠程登錄、文件傳輸和電子郵件等,而TCP協議和IP協議是保證數據完整傳輸的兩個基本的重要協議。通常說TCP/IP是Internet協議族,而不單單是TCP和IP。
Socket:socket就像是TCP與UDP的外接API。有兩種連接操作方式,面向連接的(TCP)和麪向無連接的(UDP)。使用UDP無需要指定一個socket目的地,而是用TCP必須要指定一個socket目的地,需要進行預鏈接,否則連接不到。
HTTP:HTTP協議即超文本傳送協議(Hypertext Transfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用、所以支持HTTP就一定支持TCP傳輸。常見的請求方式有get和post,web服務。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束後,會主動釋放連接。從建立連接到關閉連接的過程稱爲“一次連接”。
具體點來講:(以下大部分基於百度百科)
網絡、由下往上分爲
物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。
通過初步的瞭解,知道IP協議對應於網絡層,TCP協議對應於傳輸層,而HTTP協議對應於應用層,
三者從本質上來說沒有可比性,
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協議的相關只是,用博大精深來講我想也不爲過,單單查一下網上關於此類只是的資料和書籍文獻的數量就知道,
這個我打算會買一些經典的書籍(比如《TCP/IP詳解:卷一、卷二、卷三》)進行學習,今天就先總結一些基於基於TCP/IP協議的應用和編程接口的知識,也就是剛纔說了很多的HTTP和Socket。
CSDN上有個比較形象的描述:HTTP是轎車,提供了封裝或者顯示數據的具體形式;Socket是發動機,提供了網絡通信的能力。
實際上,傳輸層的TCP是基於網絡層的IP協議的,而應用層的HTTP協議又是基於傳輸層的TCP協議的,而Socket本身不算是協議,就像上面所說,它只是提供了一個針對TCP或者UDP編程的接口。
下面是一些經常在筆試或者面試中碰到的重要的概念,特在此做摘抄和總結。
一、什麼是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連接的請求,斷開過程需要經過“四次握手”(過程就不細寫了,就是服務器和客戶端交互,最終確定斷開)
二、利用Socket建立網絡連接的步驟
建立Socket連接至少需要一對套接字,其中一個運行於客戶端,稱爲ClientSocket ,另一個運行於服務器端,稱爲ServerSocket 。
套接字之間的連接過程分爲三個步驟:服務器監聽,客戶端請求,連接確認。
1、服務器監聽:服務器端套接字並不定位具體的客戶端套接字,而是處於等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。
2、客戶端請求:指客戶端的套接字提出連接請求,要連接的目標是服務器端的套接字。
爲此,客戶端的套接字必須首先描述它要連接的服務器的套接字,指出服務器端套接字的地址和端口號,然後就向服務器端套接字提出連接請求。
3、連接確認:當服務器端套接字監聽到或者說接收到客戶端套接字的連接請求時,就響應客戶端套接字的請求,建立一個新的線程,把服務器端套接字的描述發給客戶端,一旦客戶端確認了此描述,雙方就正式建立連接。
而服務器端套接字繼續處於監聽狀態,繼續接收其他客戶端套接字的連接請求。
三、HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束後,會主動釋放連接。從建立連接到關閉連接的過程稱爲“一次連接”。
簡單的說,TCP就是單純建立連接,不涉及任何我們需要請求的實際數據,簡單的傳輸。
http是用來收發數據,即實際應用上來的。
第一:從傳輸層,先說下TCP連接,我們要和服務端連接TCP連接,需要通過三次連接,包括:請求,確認,建立連接。即傳說中的“三次握手協議”。
簡單就是:請求,確認,連接。
第二:從實際上的數據應用來說http:
在前面客戶端和應用服務器建立TCP連接之後,就需要用http協議來傳送數據了,HTTP協議簡單來說,還是請求,確認,連接。
總體就是C發送一個HTTP請求給S,S收到了這個http請求,然後返回給Chttp響應,然後C的中間件或者說瀏覽器把這些數據渲染成爲了網頁,展示在用戶面前。
http請求第一步:發送一個http請求給S,這個請求包括請求頭和請求內容:
request header(請求頭)包括:
1.請求的方法是POST/GET,請求的URL,http協議版本
2.請求的數據,和編碼方式3是否有cookie和cooies,是否緩存等。
post和get請求方式的區別:
get把請求內容放在URL後面,但是URL長度有限制。而post是以表單的形勢,適合要輸入密碼之類的,因爲不在URL中顯示,所以比較安全。
request body(請求體):即請求的內容.
http請求第二步:S收到了http請求,然後根據請求頭,返回http響應。
response header:包括了1.cookies或者sessions2.狀態碼3.內容大小等
response body:即響應的內容,包括,JS什麼的。
http請求第三步:C收到了以後,就由瀏覽器完成一系列的渲染,包括執行JS腳本等。
四、TCP和UDP的區別
1、TCP是面向鏈接的,雖然說網絡的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性,但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性;
而UDP不是面向連接的,UDP傳送數據前並不與對方建立連接,對接收到的數據也不發送確認信號,發送端不知道數據是否會正確接收,當然也不用重發,所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2、也正由於1所說的特點,使得UDP的開銷更小數據傳輸速率更高,因爲不必進行收發數據的確認,所以UDP的實時性更好。
知道了TCP和UDP的區別,就不難理解爲何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了,但並不能說QQ的通信是不安全的,
因爲程序員可以手動對UDP的數據收發進行驗證,比如發送方對每個數據包進行編號然後由接收方進行驗證啊什麼的,
即使是這樣,UDP因爲在底層協議的封裝上沒有采用類似TCP的“三次握手”而實現了TCP所無法達到的傳輸效率。