通信協議——Http、TCP、UDP

參考:http://www.2cto.com/net/201611/569006.html

TCP HTTP UDP都是通信協議,也就是通信時所遵守的規則,只有雙方按照這個規則“說話”,對方才能理解或為之服務。

TCP HTTP UDP三者的關系:

TCP/IP是個協議組,可分為四個層次:網絡接口層、網絡層、傳輸層和應用層。

在網絡層有IP協議、ICMP協議、ARP協議、RARP協議和BOOTP協議。

在傳輸層中有TCP協議與UDP協議。

在應用層有FTP、HTTP、TELNET、SMTP、DNS等協議。

因此,HTTP本身就是一個協議,是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。

socket:

這是為了實現以上的通信過程而建立成來的通信管道,其真實的代表是客戶端和服務器端的一個通信進程,雙方進程通過socket進行通信,而通信的規則采用指定的協議。socket只是一種連接模式,不是協議,tcp,udp,簡單的說(雖然不準確)是兩個最基本的協議,很多其它協議都是基于這兩個協議如,http就是基于tcp的,.用socket可以創建tcp連接,也可以創建udp連接,這意味著,用socket可以創建任何協議的連接,因為其它協議都是基于此的。

下面我們主要來看一下和我們互聯網生活密切相關的協議:HTTP

什么是Http協議

HTTP全稱是HyperText Transfer Protocol,即:超文本傳輸協議,從1990年開始就在WWW上廣泛應用,是現今在WWW上應用最多的協議, Http是應用層協議,當你上網瀏覽網頁的時候,瀏覽器和Web服務器之間就會通過HTTP在Internet上進行數據的發送和接收。Http是一個基于請求/響應模式的、無狀態的協議。即我們通常所說的Request/Response。

URL:

URL(Uniform Resource Locator) 地址用于描述一個網絡上的資源, 基本格式如下

schema://host[:port#]/path/.../[?query-string][#anchor]

scheme 指定低層使用的協議(例如:http, https, ftp)

host HTTP服務器的IP地址或者域名

port# HTTP服務器的默認端口是80,這種情況下端口號可以省略。如果使用了別的端口,必須指明,例如http://www.cnblogs.com:8080/

path 訪問資源的路徑

query-string 發送給http服務器的數據

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 消息的結構, Request 消息分為3部分

第一部分叫Request line,

第二部分叫Request header,

第三部分是body. header和body之間有個空行,

結構如下圖

第一行中的Method表示請求方法,比如”POST”,”GET”, Path-to-resoure表示請求的資源, Http/version-number 表示HTTP協議的版本號

當使用的是”GET” 方法的時候, body是為空的

比如我們打開博客園首頁的request 如下

GEThttp://www.cnblogs.com/HTTP/1.1

Host: www.cnblogs.com

抽象的東西,難以理解,老感覺是虛的, 所謂眼見為實, 實際見到的東西,我們才能理解和記憶。 我們今天用Fiddler,實際的看看Request和Response.

下面我們打開Fiddler 捕捉一個博客園登錄的Request 然后分析下它的結構, 在Inspectors tab下以Raw的方式可以看到完整的Request的消息,

如下圖

Accept

作用: 瀏覽器端可以接受的媒體類型,

例如: Accept: text/html 代表瀏覽器可以接受服務器回發的類型為 text/html 也就是我們常說的html文檔,

如果服務器無法返回text/html類型的數據,服務器應該返回一個406錯誤(non acceptable)

通配符 * 代表任意類型

例如 Accept: / 代表瀏覽器可以處理所有類型,(一般瀏覽器發給服務器都是發這個)

Referer

作用: 提供了Request的上下文信息的服務器,告訴服務器我是從哪個鏈接過來的,比如從我主頁上鏈接到一個朋友那里,他的服務器就能夠從HTTP Referer中統計出每天有多少用戶點擊我主頁上的鏈接訪問他的網站。

例如: Referer:http://translate.google.cn/?hl=zh-cn&tab=wT

Accept-Language

作用: 瀏覽器申明自己接收的語言。

語言跟字符集的區別:中文是語言,中文有多種字符集,比如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服務器, 客戶端使用的操作系統和瀏覽器的名稱和版本.

我們上網登陸論壇的時候,往往會看到一些歡迎信息,其中列出了你的操作系統的名稱和版本,你所使用的瀏覽器的名稱和版本,這往往讓很多人感到很神奇,實際上,服務器應用程序就是從User-Agent這個請求報頭域中獲取到這些信息User-Agent請求報頭域允許客戶端將它的操作系統、瀏覽器和其它屬性告訴服務器。

例如: 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 當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的連接

例如: Connection: close 代表一個Request完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉, 當客戶端再次發送Request,需要重新建立TCP連接。

Content-Length

作用:發送給HTTP服務器數據的長度。

例如: Content-Length: 38

Host(發送請求時,該報頭域是必需的)

作用: 請求報頭域主要用于指定被請求資源的Internet主機和端口號,它通常從HTTP URL中提取出來的

例如: 我們在瀏覽器中輸入:http://www.guet.edu.cn/index.html

瀏覽器發送的請求消息中,就會包含Host請求報頭域,如下:

Host:http://www.guet.edu.cn

此處使用缺省端口號80,若指定了端口號,則變成:Host:指定端口號

Pragma

作用: 防止頁面被緩存, 在HTTP/1.1版本中,它和Cache-Control:no-cache作用一模一樣

Pargma只有一個用法, 例如: Pragma: no-cache

Cookie:

作用: 最重要的header, 將cookie的值發送給HTTP 服務器

Accept-Charset

作用:瀏覽器申明自己接收的字符集,這就是本文前面介紹的各種字符集和字符編碼,如gb2312,utf-8(通常我們說Charset包括了相應的字符編碼方案);

我們再看Response消息的結構, 和Request消息的結構基本一樣。 同樣也分為三部分

第一部分叫Response line,

第二部分叫Response header,

第三部分是body. header和body之間也有個空行,

HTTP/version-number表示HTTP協議的版本號, status-code 和message 請看下節[狀態代碼]的詳細解釋.

我們用Fiddler 捕捉一個博客園首頁的Response然后分析下它的結構, 在Inspectors tab下以Raw的方式可以看到完整的Response的消息。

Cache-Control

作用: 這個是非常重要的規則。 這個用來指定Response-Request遵循的緩存機制。各個指令含義如下

Cache-Control:Public 可以被任何緩存所緩存()

Cache-Control:Private 內容只緩存到私有緩存中

Cache-Control:no-cache 所有內容都不會被緩存

還有其他的一些用法, 我沒搞懂其中的意思, 請大家參考其他的資料

Content-Type

作用:WEB服務器告訴瀏覽器自己響應的對象的類型和字符集,

例如:

Content-Type: text/html; charset=utf-8

Content-Type:text/html;charset=GB2312

Content-Type: image/jpeg

Expires

作用: 瀏覽器會在指定過期時間內使用本地緩存

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

Last-Modified:

作用: 用于指示資源的最后修改日期和時間。(實例請看上節的If-Modified-Since的實例)

例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

Server:

作用:指明HTTP服務器的軟件信息

例如:Server: Microsoft-IIS/7.5

X-AspNet-Version:

作用:如果網站是用ASP.NET開發的,這個header用來表示ASP.NET的版本

例如: X-AspNet-Version: 4.0.30319

X-Powered-By:

作用:表示網站是用什么技術開發的

例如: X-Powered-By: ASP.NET

Connection

例如: Connection: keep-alive 當一個網頁打開完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接不會關閉,如果客戶端再次訪問這個服務器上的網頁,會繼續使用這一條已經建立的連接

例如: Connection: close 代表一個Request完成后,客戶端和服務器之間用于傳輸HTTP數據的TCP連接會關閉, 當客戶端再次發送Request,需要重新建立TCP連接。

Content-Length

指明實體正文的長度,以字節方式存儲的十進制數字來表示。在數據下行的過程中,Content-Length的方式要預先在服務器中緩存所有數據,然后所有數據再一股腦兒地發給客戶端。

例如: Content-Length: 19847

Date

作用: 生成消息的具體時間和日期

例如: Date: Sat, 11 Feb 2012 11:35:14 GMT

HTTP協議之Get和Post

Http協議定義了很多與服務器交互的方法,最基本的有4種,分別是GET,POST,PUT,DELETE. 一個URL地址用于描述一個網絡上的資源,而HTTP中的GET, POST, PUT, DELETE就對應著對這個資源的查,改,增,刪4個操作。 我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息,而POST一般用于更新資源信息.

我們看看GET和POST的區別

GET提交的數據會放在URL之后,以?分割URL和傳輸數據,參數之間以&相連,如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.

GET提交的數據大小有限制(因為瀏覽器對URL的長度有限制),而POST方法提交的數據沒有限制.

GET方式需要使用Request.QueryString來取得變量的值,而POST方式通過Request.Form來獲取變量的值,也就是說Get是通過地址欄來傳值,而Post是通過提交表單來傳值。

GET方式提交數據,會帶來安全問題,比如一個登錄頁面,通過GET方式提交數據時,用戶名和密碼將出現在URL上,





為什么MSN傳遞文件要比QQ傳文件要慢?

大學學習網絡基礎的時候老師講過,網絡由下往上分為物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。通過初步的了解,我知道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/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光一。什么是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連接的請求,斷開過程需要經過“四次握手”(過程就不細寫了,就是服務器和客戶端交互,最終確定斷開)

TCP/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光二。利用Socket建立網絡連接的步驟

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

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

1。服務器監聽:服務器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。

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

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

TCP/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光三。HTTP鏈接的特點

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。

HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束后,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

TCP/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光四。TCP和UDP的區別(考得最多。。快被考爛了我覺得- -)

1。 TCP是面向鏈接的,雖然說網絡的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性,但TCP的三次握手在最低限度上(實際上也很大程度上保證了)保證了連接的可靠性;而UDP不是面向連接的,UDP傳送數據前并不與對方建立連接,對接收到的數據也不發送確認信號,發送端不知道數據是否會正確接收,當然也不用重發,所以說UDP是無連接的、不可靠的一種數據傳輸協議。

2。也正由于1所說的特點,使得UDP的開銷更小數據傳輸速率更高,因為不必進行收發數據的確認,所以UDP的實時性更好。

知道了TCP和UDP的區別,就不難理解為何采用TCP傳輸協議的MSN比采用UDP的QQ傳輸文件慢了,但并不能說QQ的通信是不安全的,因為程序員可以手動對UDP的數據收發進行驗證,比如發送方對每個數據包進行編號然后由接收方進行驗證啊什么的,即使是這樣,UDP因為在底層協議的封裝上沒有采用類似 TCP的“三次握手”而實現了TCP所無法達到的傳輸效率。

1、TCP連接

手機能夠使用聯網功能是因為手機底層實現了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、SOCKET原理

3.1套接字(socket)概念

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

應用層通過傳輸層進行數據通信時,TCP會遇到同時為多個應用程序進程提供并發服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個 TCP協議端口傳輸數據。為了區別不同的應用程序進程和連接,許多計算機操作系統為應用程序與TCP/IP協議交互提供了套接字(Socket)接口。應用層可以和傳輸層通過Socket接口,區分來自不同應用程序進程或網絡連接的通信,實現數據傳輸的并發服務。

3.2 建立socket連接

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

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

服務器監聽:服務器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。

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

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

4、SOCKET連接與TCP連接

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

5、Socket連接與HTTP連接

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

而HTTP連接使用的是“請求—響應”的方式,不僅在請求時需要先建立連接,而且需要客戶端向服務器發出請求后,服務器端才能回復數據。

很多情況下,需要服務器端主動向客戶端推送數據,保持客戶端與服務器數據的實時與同步。此時若雙方建立的是Socket連接,服務器就可以直接將數據傳送給客戶端;若雙方建立的是HTTP連接,則服務器需要等到客戶端發送一次請求后才能將數據傳回給客戶端,因此,客戶端定時向服務器端發送連接請求,不僅可以保持在線,同時也是在“詢問”服務器是否有新的數據,如果有就將數據傳給客戶端。

下面是一些經常在筆試或者面試中碰到的重要的概念,特在此做摘抄和總結。

TCP/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光一。什么是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連接的請求,斷開過程需要經過“四次握手”(過程就不細寫了,就是服務器和客戶端交互,最終確定斷開)

TCP/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光二。利用Socket建立網絡連接的步驟

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

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

1。服務器監聽:服務器端套接字并不定位具體的客戶端套接字,而是處于等待連接的狀態,實時監控網絡狀態,等待客戶端的連接請求。

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

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

TCP/IP、Http、Socket的區別 - 粉紅色的夏天 - 追尋陽光三。HTTP鏈接的特點

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol ),是Web聯網的基礎,也是手機聯網常用的協議之一,HTTP協議是建立在TCP協議之上的一種應用。

HTTP連接最顯著的特點是客戶端發送的每次請求都需要服務器回送響應,在請求結束后,會主動釋放連接。從建立連接到關閉連接的過程稱為“一次連接”。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容