參考:http://www.2cto.com/net/201611/569006.html
TCP HTTP UDP都是通信協(xié)議,也就是通信時所遵守的規(guī)則,只有雙方按照這個規(guī)則“說話”,對方才能理解或為之服務(wù)。
TCP HTTP UDP三者的關(guān)系:
TCP/IP是個協(xié)議組,可分為四個層次:網(wǎng)絡(luò)接口層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。
在網(wǎng)絡(luò)層有IP協(xié)議、ICMP協(xié)議、ARP協(xié)議、RARP協(xié)議和BOOTP協(xié)議。
在傳輸層中有TCP協(xié)議與UDP協(xié)議。
在應(yīng)用層有FTP、HTTP、TELNET、SMTP、DNS等協(xié)議。
因此,HTTP本身就是一個協(xié)議,是從Web服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
socket:
這是為了實現(xiàn)以上的通信過程而建立成來的通信管道,其真實的代表是客戶端和服務(wù)器端的一個通信進(jìn)程,雙方進(jìn)程通過socket進(jìn)行通信,而通信的規(guī)則采用指定的協(xié)議。socket只是一種連接模式,不是協(xié)議,tcp,udp,簡單的說(雖然不準(zhǔn)確)是兩個最基本的協(xié)議,很多其它協(xié)議都是基于這兩個協(xié)議如,http就是基于tcp的,.用socket可以創(chuàng)建tcp連接,也可以創(chuàng)建udp連接,這意味著,用socket可以創(chuàng)建任何協(xié)議的連接,因為其它協(xié)議都是基于此的。
下面我們主要來看一下和我們互聯(lián)網(wǎng)生活密切相關(guān)的協(xié)議:HTTP
什么是Http協(xié)議
HTTP全稱是HyperText Transfer Protocol,即:超文本傳輸協(xié)議,從1990年開始就在WWW上廣泛應(yīng)用,是現(xiàn)今在WWW上應(yīng)用最多的協(xié)議, Http是應(yīng)用層協(xié)議,當(dāng)你上網(wǎng)瀏覽網(wǎng)頁的時候,瀏覽器和Web服務(wù)器之間就會通過HTTP在Internet上進(jìn)行數(shù)據(jù)的發(fā)送和接收。Http是一個基于請求/響應(yīng)模式的、無狀態(tài)的協(xié)議。即我們通常所說的Request/Response。
URL:
URL(Uniform Resource Locator) 地址用于描述一個網(wǎng)絡(luò)上的資源, 基本格式如下
schema://host[:port#]/path/.../[?query-string][#anchor]
scheme 指定低層使用的協(xié)議(例如:http, https, ftp)
host HTTP服務(wù)器的IP地址或者域名
port# HTTP服務(wù)器的默認(rèn)端口是80,這種情況下端口號可以省略。如果使用了別的端口,必須指明,例如http://www.cnblogs.com:8080/
path 訪問資源的路徑
query-string 發(fā)送給http服務(wù)器的數(shù)據(jù)
anchor- 錨
URL 的一個例子
aspx?name=sviergn&x=true">http://www.mywebsite.com/sj/test/test.aspx?name=sviergn&x=true
Schema: http
host: www.mywebsite.com
path: /sj/test/test.aspx
Query String: name=sviergn&x=true
Anchor: stuff
HTTP的Request/Response:
先看Request 消息的結(jié)構(gòu), Request 消息分為3部分
第一部分叫Request line,
第二部分叫Request header,
第三部分是body. header和body之間有個空行,
結(jié)構(gòu)如下圖

第一行中的Method表示請求方法,比如”POST”,”GET”, Path-to-resoure表示請求的資源, Http/version-number 表示HTTP協(xié)議的版本號
當(dāng)使用的是”GET” 方法的時候, body是為空的
比如我們打開博客園首頁的request 如下
GEThttp://www.cnblogs.com/HTTP/1.1
Host: www.cnblogs.com
抽象的東西,難以理解,老感覺是虛的, 所謂眼見為實, 實際見到的東西,我們才能理解和記憶。 我們今天用Fiddler,實際的看看Request和Response.
下面我們打開Fiddler 捕捉一個博客園登錄的Request 然后分析下它的結(jié)構(gòu), 在Inspectors tab下以Raw的方式可以看到完整的Request的消息,
如下圖
Accept
作用: 瀏覽器端可以接受的媒體類型,
例如: Accept: text/html 代表瀏覽器可以接受服務(wù)器回發(fā)的類型為 text/html 也就是我們常說的html文檔,
如果服務(wù)器無法返回text/html類型的數(shù)據(jù),服務(wù)器應(yīng)該返回一個406錯誤(non acceptable)
通配符 * 代表任意類型
例如 Accept: / 代表瀏覽器可以處理所有類型,(一般瀏覽器發(fā)給服務(wù)器都是發(fā)這個)
Referer
作用: 提供了Request的上下文信息的服務(wù)器,告訴服務(wù)器我是從哪個鏈接過來的,比如從我主頁上鏈接到一個朋友那里,他的服務(wù)器就能夠從HTTP Referer中統(tǒng)計出每天有多少用戶點擊我主頁上的鏈接訪問他的網(wǎng)站。
例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT
Accept-Language
作用: 瀏覽器申明自己接收的語言。
語言跟字符集的區(qū)別:中文是語言,中文有多種字符集,比如big5,gb2312,gbk等等;
例如: Accept-Language: en-us
Content-Type
作用:
例如:Content-Type: application/x-www-form-urlencoded
Accept-Encoding:
作用: 瀏覽器申明自己接收的編碼方法,通常指定壓縮方法,是否支持壓縮,支持什么壓縮方法(gzip,deflate),(注意:這不是只字符編碼);
例如: Accept-Encoding: gzip, deflate
User-Agent
作用:告訴HTTP服務(wù)器, 客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本.
我們上網(wǎng)登陸論壇的時候,往往會看到一些歡迎信息,其中列出了你的操作系統(tǒng)的名稱和版本,你所使用的瀏覽器的名稱和版本,這往往讓很多人感到很神奇,實際上,服務(wù)器應(yīng)用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域允許客戶端將它的操作系統(tǒng)、瀏覽器和其它屬性告訴服務(wù)器。
例如: User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)
Connection
例如: Connection: keep-alive 當(dāng)一個網(wǎng)頁打開完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉,如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁,會繼續(xù)使用這一條已經(jīng)建立的連接
例如: Connection: close 代表一個Request完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉, 當(dāng)客戶端再次發(fā)送Request,需要重新建立TCP連接。
Content-Length
作用:發(fā)送給HTTP服務(wù)器數(shù)據(jù)的長度。
例如: Content-Length: 38
Host(發(fā)送請求時,該報頭域是必需的)
作用: 請求報頭域主要用于指定被請求資源的Internet主機和端口號,它通常從HTTP URL中提取出來的
例如: 我們在瀏覽器中輸入:http://www.guet.edu.cn/index.html
瀏覽器發(fā)送的請求消息中,就會包含Host請求報頭域,如下:
此處使用缺省端口號80,若指定了端口號,則變成:Host:指定端口號
Pragma
作用: 防止頁面被緩存, 在HTTP/1.1版本中,它和Cache-Control:no-cache作用一模一樣
Pargma只有一個用法, 例如: Pragma: no-cache
Cookie:
作用: 最重要的header, 將cookie的值發(fā)送給HTTP 服務(wù)器
Accept-Charset
作用:瀏覽器申明自己接收的字符集,這就是本文前面介紹的各種字符集和字符編碼,如gb2312,utf-8(通常我們說Charset包括了相應(yīng)的字符編碼方案);
我們再看Response消息的結(jié)構(gòu), 和Request消息的結(jié)構(gòu)基本一樣。 同樣也分為三部分
第一部分叫Response line,
第二部分叫Response header,
第三部分是body. header和body之間也有個空行,
HTTP/version-number表示HTTP協(xié)議的版本號, status-code 和message 請看下節(jié)[狀態(tài)代碼]的詳細(xì)解釋.
我們用Fiddler 捕捉一個博客園首頁的Response然后分析下它的結(jié)構(gòu), 在Inspectors tab下以Raw的方式可以看到完整的Response的消息。
Cache-Control
作用: 這個是非常重要的規(guī)則。 這個用來指定Response-Request遵循的緩存機制。各個指令含義如下
Cache-Control:Public 可以被任何緩存所緩存()
Cache-Control:Private 內(nèi)容只緩存到私有緩存中
Cache-Control:no-cache 所有內(nèi)容都不會被緩存
還有其他的一些用法, 我沒搞懂其中的意思, 請大家參考其他的資料
Content-Type
作用:WEB服務(wù)器告訴瀏覽器自己響應(yīng)的對象的類型和字符集,
例如:
Content-Type: text/html; charset=utf-8
Content-Type:text/html;charset=GB2312
Content-Type: image/jpeg
Expires
作用: 瀏覽器會在指定過期時間內(nèi)使用本地緩存
例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT
Last-Modified:
作用: 用于指示資源的最后修改日期和時間。(實例請看上節(jié)的If-Modified-Since的實例)
例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT
Server:
作用:指明HTTP服務(wù)器的軟件信息
例如:Server: Microsoft-IIS/7.5
X-AspNet-Version:
作用:如果網(wǎng)站是用ASP.NET開發(fā)的,這個header用來表示ASP.NET的版本
例如: X-AspNet-Version: 4.0.30319
X-Powered-By:
作用:表示網(wǎng)站是用什么技術(shù)開發(fā)的
例如: X-Powered-By: ASP.NET
Connection
例如: Connection: keep-alive 當(dāng)一個網(wǎng)頁打開完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉,如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁,會繼續(xù)使用這一條已經(jīng)建立的連接
例如: Connection: close 代表一個Request完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接會關(guān)閉, 當(dāng)客戶端再次發(fā)送Request,需要重新建立TCP連接。
Content-Length
指明實體正文的長度,以字節(jié)方式存儲的十進(jìn)制數(shù)字來表示。在數(shù)據(jù)下行的過程中,Content-Length的方式要預(yù)先在服務(wù)器中緩存所有數(shù)據(jù),然后所有數(shù)據(jù)再一股腦兒地發(fā)給客戶端。
例如: Content-Length: 19847
Date
作用: 生成消息的具體時間和日期
例如: Date: Sat, 11 Feb 2012 11:35:14 GMT
HTTP協(xié)議之Get和Post
Http協(xié)議定義了很多與服務(wù)器交互的方法,最基本的有4種,分別是GET,POST,PUT,DELETE. 一個URL地址用于描述一個網(wǎng)絡(luò)上的資源,而HTTP中的GET, POST, PUT, DELETE就對應(yīng)著對這個資源的查,改,增,刪4個操作。 我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息,而POST一般用于更新資源信息.
我們看看GET和POST的區(qū)別
GET提交的數(shù)據(jù)會放在URL之后,以?分割URL和傳輸數(shù)據(jù),參數(shù)之間以&相連,如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中.
GET提交的數(shù)據(jù)大小有限制(因為瀏覽器對URL的長度有限制),而POST方法提交的數(shù)據(jù)沒有限制.
GET方式需要使用Request.QueryString來取得變量的值,而POST方式通過Request.Form來獲取變量的值,也就是說Get是通過地址欄來傳值,而Post是通過提交表單來傳值。
GET方式提交數(shù)據(jù),會帶來安全問題,比如一個登錄頁面,通過GET方式提交數(shù)據(jù)時,用戶名和密碼將出現(xiàn)在URL上,
為什么MSN傳遞文件要比QQ傳文件要慢?
大學(xué)學(xué)習(xí)網(wǎng)絡(luò)基礎(chǔ)的時候老師講過,網(wǎng)絡(luò)由下往上分為物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層和應(yīng)用層。通過初步的了解,我知道IP 協(xié)議對應(yīng)于網(wǎng)絡(luò)層,TCP協(xié)議對應(yīng)于傳輸層,而HTTP協(xié)議對應(yīng)于應(yīng)用層,三者從本質(zhì)上來說沒有可比性,socket則是對TCP/IP協(xié)議的封裝和應(yīng)用(程序員層面上)。也可以說,TPC/IP協(xié)議是傳輸層協(xié)議,主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸,而HTTP是應(yīng)用層協(xié)議,主要解決如何包裝數(shù)據(jù)。關(guān)于TCP /IP和HTTP協(xié)議的關(guān)系,網(wǎng)絡(luò)有一段比較容易理解的介紹:
“我們在傳輸數(shù)據(jù)時,可以只使用(傳輸層)TCP/IP協(xié)議,但是那樣的話,如果沒有應(yīng)用層,便無法識別數(shù)據(jù)內(nèi)容,如果想要使傳輸?shù)臄?shù)據(jù)有意義,則必須使用到應(yīng)用層協(xié)議,應(yīng)用層協(xié)議有很多,比如HTTP、FTP、TELNET等,也可以自己定義應(yīng)用層協(xié)議。WEB使用HTTP協(xié)議作應(yīng)用層協(xié)議,以封裝 HTTP 文本信息,然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡(luò)上?!?/p>
而我們平時說的最多的socket是什么呢,實際上socket是對TCP/IP協(xié)議的封裝,Socket本身并不是協(xié)議,而是一個調(diào)用接口(API),通過Socket,我們才能使用TCP/IP協(xié)議。實際上,Socket跟TCP/IP協(xié)議沒有必然的聯(lián)系。Socket編程接口在設(shè)計的時候,就希望也能適應(yīng)其他的網(wǎng)絡(luò)協(xié)議。所以說,Socket的出現(xiàn)只是使得程序員更方便地使用TCP/IP協(xié)議棧而已,是對TCP/IP協(xié)議的抽象,從而形成了我們知道的一些最基本的函數(shù)接口,比如create、 listen、connect、accept、send、read和write等等。網(wǎng)絡(luò)有一段關(guān)于socket和TCP/IP協(xié)議關(guān)系的說法比較容易理解:
“TCP/IP只是一個協(xié)議棧,就像操作系統(tǒng)的運行機制一樣,必須要具體實現(xiàn),同時還要提供對外的操作接口。這個就像操作系統(tǒng)會提供標(biāo)準(zhǔn)的編程接口,比如win32編程接口一樣,TCP/IP也要提供可供程序員做網(wǎng)絡(luò)開發(fā)所用的接口,這就是Socket編程接口?!?/p>
關(guān)于TCP/IP協(xié)議的相關(guān)只是,用博大精深來講我想也不為過,單單查一下網(wǎng)上關(guān)于此類只是的資料和書籍文獻(xiàn)的數(shù)量就知道,這個我打算會買一些經(jīng)典的書籍(比如《TCP/IP詳解:卷一、卷二、卷三》)進(jìn)行學(xué)習(xí),今天就先總結(jié)一些基于基于TCP/IP協(xié)議的應(yīng)用和編程接口的知識,也就是剛才說了很多的 HTTP和Socket。
CSDN上有個比較形象的描述:HTTP是轎車,提供了封裝或者顯示數(shù)據(jù)的具體形式;Socket是發(fā)動機,提供了網(wǎng)絡(luò)通信的能力。
實際上,傳輸層的TCP是基于網(wǎng)絡(luò)層的IP協(xié)議的,而應(yīng)用層的HTTP協(xié)議又是基于傳輸層的TCP協(xié)議的,而Socket本身不算是協(xié)議,就像上面所說,它只是提供了一個針對TCP或者UDP編程的接口。
下面是一些經(jīng)常在筆試或者面試中碰到的重要的概念,特在此做摘抄和總結(jié)。
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光一。什么是TCP連接的三次握手
第一次握手:客戶端發(fā)送syn包(syn=j)到服務(wù)器,并進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn);
第二次握手:服務(wù)器收到syn包,必須確認(rèn)客戶的SYN(ack=j+1),同時自己也發(fā)送一個SYN包(syn=k),即SYN+ACK包,此時服務(wù)器進(jìn)入SYN_RECV狀態(tài); 第三次握手:客戶端收到服務(wù)器的SYN+ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài),完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù),三次握手完畢后,客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下,TCP連接一旦建立,在通信雙方中的任何一方主動關(guān)閉連接之前,TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求,斷開過程需要經(jīng)過“四次握手”(過程就不細(xì)寫了,就是服務(wù)器和客戶端交互,最終確定斷開)
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光二。利用Socket建立網(wǎng)絡(luò)連接的步驟
建立Socket連接至少需要一對套接字,其中一個運行于客戶端,稱為ClientSocket ,另一個運行于服務(wù)器端,稱為ServerSocket 。
套接字之間的連接過程分為三個步驟:服務(wù)器監(jiān)聽,客戶端請求,連接確認(rèn)。
1。服務(wù)器監(jiān)聽:服務(wù)器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態(tài),實時監(jiān)控網(wǎng)絡(luò)狀態(tài),等待客戶端的連接請求。
2。客戶端請求:指客戶端的套接字提出連接請求,要連接的目標(biāo)是服務(wù)器端的套接字。為此,客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字,指出服務(wù)器端套接字的地址和端口號,然后就向服務(wù)器端套接字提出連接請求。
3。連接確認(rèn):當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時,就響應(yīng)客戶端套接字的請求,建立一個新的線程,把服務(wù)器端套接字的描述發(fā)給客戶端,一旦客戶端確認(rèn)了此描述,雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài),繼續(xù)接收其他客戶端套接字的連接請求。
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光三。HTTP鏈接的特點
HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol ),是Web聯(lián)網(wǎng)的基礎(chǔ),也是手機聯(lián)網(wǎng)常用的協(xié)議之一,HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。
HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng),在請求結(jié)束后,會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光四。TCP和UDP的區(qū)別(考得最多。??毂豢紶€了我覺得- -)
1。 TCP是面向鏈接的,雖然說網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性,但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性;而UDP不是面向連接的,UDP傳送數(shù)據(jù)前并不與對方建立連接,對接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號,發(fā)送端不知道數(shù)據(jù)是否會正確接收,當(dāng)然也不用重發(fā),所以說UDP是無連接的、不可靠的一種數(shù)據(jù)傳輸協(xié)議。
2。也正由于1所說的特點,使得UDP的開銷更小數(shù)據(jù)傳輸速率更高,因為不必進(jìn)行收發(fā)數(shù)據(jù)的確認(rèn),所以UDP的實時性更好。
知道了TCP和UDP的區(qū)別,就不難理解為何采用TCP傳輸協(xié)議的MSN比采用UDP的QQ傳輸文件慢了,但并不能說QQ的通信是不安全的,因為程序員可以手動對UDP的數(shù)據(jù)收發(fā)進(jìn)行驗證,比如發(fā)送方對每個數(shù)據(jù)包進(jìn)行編號然后由接收方進(jìn)行驗證啊什么的,即使是這樣,UDP因為在底層協(xié)議的封裝上沒有采用類似 TCP的“三次握手”而實現(xiàn)了TCP所無法達(dá)到的傳輸效率。
1、TCP連接
手機能夠使用聯(lián)網(wǎng)功能是因為手機底層實現(xiàn)了TCP/IP協(xié)議,可以使手機終端通過無線網(wǎng)絡(luò)建立TCP連接。TCP協(xié)議可以對上層網(wǎng)絡(luò)提供接口,使上層網(wǎng)絡(luò)數(shù)據(jù)的傳輸建立在“無差別”的網(wǎng)絡(luò)之上。
建立起一個TCP連接需要經(jīng)過“三次握手”:
第一次握手:客戶端發(fā)送syn包(syn=j)到服務(wù)器,并進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn);
第二次握手:服務(wù)器收到syn包,必須確認(rèn)客戶的SYN(ack=j+1),同時自己也發(fā)送一個SYN包(syn=k),即SYN+ACK包,此時服務(wù)器進(jìn)入SYN_RECV狀態(tài);
第三次握手:客戶端收到服務(wù)器的SYN+ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài),完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù),三次握手完畢后,客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下,TCP連接一旦建立,在通信雙方中的任何一方主動關(guān)閉連接之前,TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求,斷開過程需要經(jīng)過“四次握手”(過程就不細(xì)寫了,就是服務(wù)器和客戶端交互,最終確定斷開)
2、HTTP連接
HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol ),是Web聯(lián)網(wǎng)的基礎(chǔ),也是手機聯(lián)網(wǎng)常用的協(xié)議之一,HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。
HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng),在請求結(jié)束后,會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。
1)在HTTP 1.0中,客戶端的每次請求都要求建立一次單獨的連接,在處理完本次請求后,就自動釋放連接。
2)在HTTP 1.1中則可以在一次連接中處理多個請求,并且多個請求可以重疊進(jìn)行,不需要等待一個請求結(jié)束后再發(fā)送下一個請求。
由于HTTP在每次請求結(jié)束后都會主動釋放連接,因此HTTP連接是一種“短連接”,要保持客戶端程序的在線狀態(tài),需要不斷地向服務(wù)器發(fā)起連接請求。通常的做法是即時不需要獲得任何數(shù)據(jù),客戶端也保持每隔一段固定的時間向服務(wù)器發(fā)送一次“保持連接”的請求,服務(wù)器在收到該請求后對客戶端進(jìn)行回復(fù),表明知道客戶端“在線”。若服務(wù)器長時間無法收到客戶端的請求,則認(rèn)為客戶端“下線”,若客戶端長時間無法收到服務(wù)器的回復(fù),則認(rèn)為網(wǎng)絡(luò)已經(jīng)斷開。
3、SOCKET原理
3.1套接字(socket)概念
套接字(socket)是通信的基石,是支持TCP/IP協(xié)議的網(wǎng)絡(luò)通信的基本操作單元。它是網(wǎng)絡(luò)通信過程中端點的抽象表示,包含進(jìn)行網(wǎng)絡(luò)通信必須的五種信息:連接使用的協(xié)議,本地主機的IP地址,本地進(jìn)程的協(xié)議端口,遠(yuǎn)地主機的IP地址,遠(yuǎn)地進(jìn)程的協(xié)議端口。
應(yīng)用層通過傳輸層進(jìn)行數(shù)據(jù)通信時,TCP會遇到同時為多個應(yīng)用程序進(jìn)程提供并發(fā)服務(wù)的問題。多個TCP連接或多個應(yīng)用程序進(jìn)程可能需要通過同一個 TCP協(xié)議端口傳輸數(shù)據(jù)。為了區(qū)別不同的應(yīng)用程序進(jìn)程和連接,許多計算機操作系統(tǒng)為應(yīng)用程序與TCP/IP協(xié)議交互提供了套接字(Socket)接口。應(yīng)用層可以和傳輸層通過Socket接口,區(qū)分來自不同應(yīng)用程序進(jìn)程或網(wǎng)絡(luò)連接的通信,實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。
3.2 建立socket連接
建立Socket連接至少需要一對套接字,其中一個運行于客戶端,稱為ClientSocket ,另一個運行于服務(wù)器端,稱為ServerSocket 。
套接字之間的連接過程分為三個步驟:服務(wù)器監(jiān)聽,客戶端請求,連接確認(rèn)。
服務(wù)器監(jiān)聽:服務(wù)器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態(tài),實時監(jiān)控網(wǎng)絡(luò)狀態(tài),等待客戶端的連接請求。
客戶端請求:指客戶端的套接字提出連接請求,要連接的目標(biāo)是服務(wù)器端的套接字。為此,客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字,指出服務(wù)器端套接字的地址和端口號,然后就向服務(wù)器端套接字提出連接請求。
連接確認(rèn):當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時,就響應(yīng)客戶端套接字的請求,建立一個新的線程,把服務(wù)器端套接字的描述發(fā)給客戶端,一旦客戶端確認(rèn)了此描述,雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài),繼續(xù)接收其他客戶端套接字的連接請求。
4、SOCKET連接與TCP連接
創(chuàng)建Socket連接時,可以指定使用的傳輸層協(xié)議,Socket可以支持不同的傳輸層協(xié)議(TCP或UDP),當(dāng)使用TCP協(xié)議進(jìn)行連接時,該Socket連接就是一個TCP連接。
5、Socket連接與HTTP連接
由于通常情況下Socket連接就是TCP連接,因此Socket連接一旦建立,通信雙方即可開始相互發(fā)送數(shù)據(jù)內(nèi)容,直到雙方連接斷開。但在實際網(wǎng)絡(luò)應(yīng)用中,客戶端到服務(wù)器之間的通信往往需要穿越多個中間節(jié)點,例如路由器、網(wǎng)關(guān)、防火墻等,大部分防火墻默認(rèn)會關(guān)閉長時間處于非活躍狀態(tài)的連接而導(dǎo)致 Socket 連接斷連,因此需要通過輪詢告訴網(wǎng)絡(luò),該連接處于活躍狀態(tài)。
而HTTP連接使用的是“請求—響應(yīng)”的方式,不僅在請求時需要先建立連接,而且需要客戶端向服務(wù)器發(fā)出請求后,服務(wù)器端才能回復(fù)數(shù)據(jù)。
很多情況下,需要服務(wù)器端主動向客戶端推送數(shù)據(jù),保持客戶端與服務(wù)器數(shù)據(jù)的實時與同步。此時若雙方建立的是Socket連接,服務(wù)器就可以直接將數(shù)據(jù)傳送給客戶端;若雙方建立的是HTTP連接,則服務(wù)器需要等到客戶端發(fā)送一次請求后才能將數(shù)據(jù)傳回給客戶端,因此,客戶端定時向服務(wù)器端發(fā)送連接請求,不僅可以保持在線,同時也是在“詢問”服務(wù)器是否有新的數(shù)據(jù),如果有就將數(shù)據(jù)傳給客戶端。
下面是一些經(jīng)常在筆試或者面試中碰到的重要的概念,特在此做摘抄和總結(jié)。
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光一。什么是TCP連接的三次握手
第一次握手:客戶端發(fā)送syn包(syn=j)到服務(wù)器,并進(jìn)入SYN_SEND狀態(tài),等待服務(wù)器確認(rèn);
第二次握手:服務(wù)器收到syn包,必須確認(rèn)客戶的SYN(ack=j+1),同時自己也發(fā)送一個SYN包(syn=k),即SYN+ACK包,此時服務(wù)器進(jìn)入SYN_RECV狀態(tài); 第三次握手:客戶端收到服務(wù)器的SYN+ACK包,向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1),此包發(fā)送完畢,客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài),完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù),三次握手完畢后,客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下,TCP連接一旦建立,在通信雙方中的任何一方主動關(guān)閉連接之前,TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求,斷開過程需要經(jīng)過“四次握手”(過程就不細(xì)寫了,就是服務(wù)器和客戶端交互,最終確定斷開)
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光二。利用Socket建立網(wǎng)絡(luò)連接的步驟
建立Socket連接至少需要一對套接字,其中一個運行于客戶端,稱為ClientSocket ,另一個運行于服務(wù)器端,稱為ServerSocket 。
套接字之間的連接過程分為三個步驟:服務(wù)器監(jiān)聽,客戶端請求,連接確認(rèn)。
1。服務(wù)器監(jiān)聽:服務(wù)器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態(tài),實時監(jiān)控網(wǎng)絡(luò)狀態(tài),等待客戶端的連接請求。
2。客戶端請求:指客戶端的套接字提出連接請求,要連接的目標(biāo)是服務(wù)器端的套接字。為此,客戶端的套接字必須首先描述它要連接的服務(wù)器的套接字,指出服務(wù)器端套接字的地址和端口號,然后就向服務(wù)器端套接字提出連接請求。
3。連接確認(rèn):當(dāng)服務(wù)器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求時,就響應(yīng)客戶端套接字的請求,建立一個新的線程,把服務(wù)器端套接字的描述發(fā)給客戶端,一旦客戶端確認(rèn)了此描述,雙方就正式建立連接。而服務(wù)器端套接字繼續(xù)處于監(jiān)聽狀態(tài),繼續(xù)接收其他客戶端套接字的連接請求。
TCP/IP、Http、Socket的區(qū)別 - 粉紅色的夏天 - 追尋陽光三。HTTP鏈接的特點
HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol ),是Web聯(lián)網(wǎng)的基礎(chǔ),也是手機聯(lián)網(wǎng)常用的協(xié)議之一,HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。
HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng),在請求結(jié)束后,會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。