為了便于大家理解和記憶，我們先對這幾個概念進行的介紹,，然后分析他們的不同,，再進行詳細的分析。

一,、TCP/IP簡介

IP協(xié)議是網(wǎng)絡(luò)層,，TCP協(xié)議是傳輸層，HTTP協(xié)議是應(yīng)用層,，socket是對TCP/IP協(xié)議的代碼封裝和應(yīng)用,。

TPC/IP 主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，HTTP主要解決如何包裝數(shù)據(jù),。

TCP/IP協(xié)議用來傳輸數(shù)據(jù),，應(yīng)用層協(xié)議 使傳輸?shù)臄?shù)據(jù)有意義，應(yīng)用層協(xié)議有很多,，比如HTTP,、FTP、TELNET等,，也可以自己定義應(yīng)用層協(xié)議,。

比如：網(wǎng)頁使用HTTP協(xié)議 封裝HTTP文本信息,，再用TCP/IP做傳輸層協(xié)議將它傳送到瀏覽器。

二,、Socket簡介

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等等。

TCP/IP只是協(xié)議,，必須要具體實現(xiàn),，還要提供對外的操作接口，這就是Socket編程接口,。Socket本身不算是協(xié)議,，就像上面所說，它只是提供了一個針對TCP或者UDP編程的接口,。

三 ,、 TCP三次握手 簡介

第一次握手：客戶端發(fā)送包到服務(wù)器，等待服務(wù)器確認(rèn),；

第二次握手：服務(wù)器收到并確認(rèn)客戶端的數(shù)據(jù)包,，同時自己也發(fā)送一個數(shù)據(jù)吧回復(fù)給客戶端；

第三次握手：客戶端收到服務(wù)器的數(shù)據(jù)包,，向服務(wù)器發(fā)送確認(rèn)包,，此包發(fā)送完畢，就完成了三次握手,。

先來個形象的比喻：我（客戶端）發(fā)了個郵件給你（服務(wù)端）,，（上面這是第一次握手），但是我不知道你收到?jīng)]有，所以你發(fā)了個“我已經(jīng)收到”的郵件回復(fù)給我（這是第二次握手）,。我收到了你的郵件,，但是你不知道 我到底有沒有收到你的這封郵件，所以你不確定 我到底知不知道“你已經(jīng)收到”,。所以 我還要再發(fā)送個郵件 告知你 我收到郵件了（這是第三次握手）,。。

這樣就能確認(rèn)彼此之間的通訊是正常的,。

握手過程中傳送的包里不包含數(shù)據(jù),，三次握手完畢后,，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù),。

理想狀態(tài)下，TCP連接一旦建立,，在通信雙方中的任何一方主動關(guān)閉連接之前,，TCP 連接都將被一直保持下去。

斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求,，斷開過程需要經(jīng)過“四次握手”,。

四、Socket網(wǎng)絡(luò)連接的步驟

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

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

1、服務(wù)器監(jiān)聽：服務(wù)器端 實時監(jiān)控網(wǎng)絡(luò)狀態(tài),，處于等待連接的狀態(tài),，等待客戶端的連接請求。

2,、客戶端請求：客戶端的套接字提出連接請求,，要連接的目標(biāo)是服務(wù)器端的套接字?？蛻舳说奶捉幼直刂赋龇?wù)器端套接字的地址和端口號,，然后就向服務(wù)器端套接字提出連接請求。

3,。連接確認(rèn)：當(dāng)服務(wù)器端套接字監(jiān)聽到客戶端套接字的請求時,，就建立一個新的線程，把服務(wù)器端套接字的描述發(fā)給客戶端，一旦客戶端確認(rèn)了此描述,，雙方就正式建立連接,。而服務(wù)器端套接字繼續(xù)監(jiān)聽其他客戶端的連接請求。

五,、HTTP簡介

HTTP(Hypertext Transfer Protocol ) 超文本傳送協(xié)議,，是建立在TCP協(xié)議之上的一種應(yīng)用協(xié)議。

客戶端發(fā)送的每次請求都需要服務(wù)器響應(yīng),，在請求結(jié)束后,，會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”,。

六 . TCP和UDP的區(qū)別

TCP是面向鏈接的,，雖然說網(wǎng)絡(luò)的不安全不穩(wěn)定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上,，也很大程度上 保證了連接的可靠性,；

而UDP傳送數(shù)據(jù)前并不與對方建立連接，對接收到的數(shù)據(jù)也不發(fā)送確認(rèn)信號,，發(fā)送端不知道數(shù)據(jù)是否會正確接收,，當(dāng)然也不用重發(fā)，UDP是無連接的,、不可靠的一種數(shù)據(jù)傳輸協(xié)議,。

所以UDP的開銷更小數(shù)據(jù)傳輸速率更高，實時性更好,。

所以采用TCP傳輸協(xié)議的MSN比采用UDP的QQ傳輸文件慢,，但并不能說QQ的通信是不安全的，因為程序員可以手動對UDP的數(shù)據(jù)收發(fā)進行驗證,，比如發(fā)送方對每個數(shù)據(jù)包進行編號然后由接收方進行驗證啊什么的,。

七 . XMPP簡介

XMPP（Extensible Messaging and Presence Protocol，前稱Jabber）是一種以XML為基礎(chǔ)的開放式即時通信協(xié)議,，是經(jīng)由互聯(lián)網(wǎng)工程工作小組（IETF）通過的互聯(lián)網(wǎng)標(biāo)準(zhǔn),。

XMPP網(wǎng)絡(luò)是基于服務(wù)器的，即客戶端之間彼此不直接交談,。

1,、XMPP實際是怎么運行的，舉個栗子：

Jabber識別符（JID）是用戶登錄時所使用的賬號,，通常像一個電子郵件地址,，如[email protected]；前部分為用戶名,，后部分為XMPP服務(wù)器域名,。

假設(shè)朱麗葉（[email protected]）想和羅密歐（[email protected]）通話，他們兩人的賬號分別在 A.com 及 B.net 的服務(wù)器上。當(dāng)朱麗葉輸入消息并按下發(fā)送鈕之后：

朱麗葉的XMPP客戶端將她的消息發(fā)送到A.com XMPP服務(wù)器,。

A.com XMPP服務(wù)器打開與B.net XMPP服務(wù)器的連接,。

B.net XMPP服務(wù)器將消息寄送給羅密歐。如果他目前不在在線,，那么存儲消息以待稍后寄送,。

羅密歐與朱麗葉兩人的XMPP服務(wù)是由兩家不同的企業(yè)所提供的，而他們彼此傳訊時,，不須擁有對方服務(wù)器的賬號,，也不須成為對方企業(yè)的會員。

2,、XMPP特性

XMPP因為被Google Talk應(yīng)用而被廣大網(wǎng)民所接觸,。

XMPP與IMPP、PRIM,、SIP（SIMPLE）合稱四大IM協(xié)議主流,，在此4大協(xié)議中，XMPP是最靈活的,。

分布式：XMPP網(wǎng)絡(luò)的架構(gòu)和電子郵件十分相像；XMPP核心協(xié)議通信方式是先創(chuàng)建一個stream,，XMPP以TCP傳遞XML數(shù)據(jù)流,，沒有中央主服務(wù)器。任何人都可以運行自己的XMPP服務(wù)器,，使個人及組織能夠掌控他們的即時傳訊體驗,。

彈性佳：XMPP除了用在即時通信，還能用在網(wǎng)絡(luò)管理,、內(nèi)容供稿,、協(xié)同工具、文件共享,、游戲,、遠程系統(tǒng)監(jiān)控等。

安全：XMPP協(xié)議的服務(wù)器可以獨立于公眾XMPP網(wǎng)絡(luò)（例如在企業(yè)內(nèi)部網(wǎng)絡(luò)中）,，而使用SASL及TLS等技術(shù)的可靠安全性,，已內(nèi)置于核心XMPP技術(shù)規(guī)格中。

3,、與其他協(xié)議互聯(lián)

XMPP協(xié)議的另一功能是運輸（transports）,，也被稱為網(wǎng)關(guān)（gateways），可允許用戶通過網(wǎng)絡(luò)使用其它協(xié)議,。這可以是其他的即時通信協(xié)議,，也可以是不同協(xié)議，如短信（SMS）或電子郵件。

各IM之間的互傳：

4,、XMPP協(xié)議通過HTTP運輸

XMPP協(xié)議可以使用HTTP的方式有兩種：輪詢（polling）與綁定（binding）,。

輪詢現(xiàn)在不推薦，輪詢：HTTP郵件存儲在服務(wù)器端的數(shù)據(jù)庫上,，客戶端必須一再地以HTTP的GET和POST的方式去抓?。ㄒ约翱觯┢渲械南ⅰ?/p>

綁定的方式：客戶端會保留一個長存的HTTP連接,，等待一旦服務(wù)器有新的消息時,，就立刻接收消息。因為輪詢的結(jié)果往往是服務(wù)端沒有新消息,，這種推送的通知模式比輪詢的方式更有效率,。

5、再舉個栗子,，使用XMPP協(xié)議的客戶端1與服務(wù)器端對話 ：

客戶端1 連接到一個XMPP服務(wù)器,，發(fā)送一條消息（主題和內(nèi)容均為“test 1449”）到客戶端2，然后注銷,。

• 客戶端1:

• XMPP服務(wù)器：

• 客戶端1:

客戶端1

mypassword

Work

• XMPP服務(wù)器：

• 客戶端1:

test 1449

test 1449

Logged out

• XMPP服務(wù)器：

八,、TCP/IP深入

1、TCP/IP數(shù)據(jù)格式

便于大家觀看,，下面是翻譯成中文后的圖片：

每個字段的意思：

• Source Port（源端口）和Destination Port（目的端口）:分別占用16位,，用于區(qū)別主機中的不同進程，而IP地址是用來區(qū)分不同的主機的,，源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能唯一的確定一個TCP連接,。

• Sequence Number（數(shù)據(jù)序號）:用來標(biāo)識從TCP發(fā)端向TCP收端 發(fā)送的數(shù)據(jù)字節(jié)流，它表示在這個報文段中的第一個數(shù)據(jù)字節(jié)在數(shù)據(jù)流中的序號,；主要用來解決網(wǎng)絡(luò)報亂序的問題,。

• Acknowledgment Number（確認(rèn)序號）:32位，包含發(fā)送確認(rèn)的一端所期望收到的下一個序號,，因此,，確認(rèn)序號應(yīng)當(dāng)是上次已成功收到數(shù)據(jù)字節(jié)序號加1,。不過，只有當(dāng)標(biāo)志位中的ACK標(biāo)志（下面介紹）為1時該確認(rèn)序列號的字段才有效,。主要用來解決不丟包的問題,；

• Offset（偏移）:給出首部中32 bit字的數(shù)目，需要這個值是因為任選字段的長度是可變的,。這個字段占4bit（最多能表示15個32bit的的字,，即4*15=60個字節(jié)的首部長度），因此TCP最多有60字節(jié)的首部,。然而,，沒有任選字段，正常的長度是20字節(jié),；

• TCP Flags: TCP首部中有6個標(biāo)志比特,，它們中的多個可同時被設(shè)置為1，主要是用于操控TCP的狀態(tài)機的,，依次為URG,，ACK，PSH,，RST,，SYN，F(xiàn)IN,。每個標(biāo)志位的意思如下：

URG：此標(biāo)志表示TCP包的緊急指針域（后面馬上就要說到）有效,，用來保證TCP連接不被中斷，并且督促中間層設(shè)備要盡快處理這些數(shù)據(jù),；

ACK：此標(biāo)志表示應(yīng)答域有效，就是說前面所說的TCP應(yīng)答號將會包含在TCP數(shù)據(jù)包中,；有兩個取值：0和1,，為1的時候表示應(yīng)答域有效，反之為0,；

PSH：這個標(biāo)志位表示Push操作,。就是指在數(shù)據(jù)包到達接收端以后，立即傳送給應(yīng)用程序,，而不是在緩沖區(qū)中排隊,；

RST：這個標(biāo)志表示連接復(fù)位請求。用來復(fù)位那些產(chǎn)生錯誤的連接,，也被用來拒絕錯誤和非法的數(shù)據(jù)包,；

SYN：表示同步序號，用來建立連接,。SYN標(biāo)志位和ACK標(biāo)志位搭配使用,，當(dāng)連接請求的時候,，SYN=1，ACK=0,；連接被響應(yīng)的時候,，SYN=1，ACK=1,；這個標(biāo)志的數(shù)據(jù)包經(jīng)常被用來進行端口掃描,。掃描者發(fā)送一個只有SYN的數(shù)據(jù)包，如果對方主機響應(yīng)了一個數(shù)據(jù)包回來 ,，就表明這臺主機存在這個端口,；但是由于這種掃描方式只是進行TCP三次握手的第一次握手，因此這種掃描的成功表示被掃描的機器不很安全,，一臺安全的主機將會強制要求一個連接嚴(yán)格的進行TCP的三次握手,；

FIN： 表示發(fā)送端已經(jīng)達到數(shù)據(jù)末尾，也就是說雙方的數(shù)據(jù)傳送完成,，沒有數(shù)據(jù)可以傳送了,，發(fā)送FIN標(biāo)志位的TCP數(shù)據(jù)包后，連接將被斷開,。這個標(biāo)志的數(shù)據(jù)包也經(jīng)常被用于進行端口掃描,。

• Window:窗口大小，也就是有名的滑動窗口,，用來進行流量控制,；這是一個復(fù)雜的問題。

2,、TCP/IP 三次握手

TCP協(xié)議之所以能提供可靠的連接 是因為三次握手,。三次握手的目的是同步連接雙方的序列號和確認(rèn)號并交換 TCP窗口大小信息。

先簡單說下上圖中的 seq表示：Sequence Number（數(shù)據(jù)序號）,。SYN：表示同步序號,。ACK：不是TCP Flags里的標(biāo)志，而是指Acknowledgment Number（確認(rèn)序號）,。

第一次握手：客戶端發(fā)送連接請求報文段,，將SYN位置為1，Sequence Number（數(shù)據(jù)序號）為x,；然后,，客戶端進入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn),；

第二次握手：服務(wù)器收到客戶端的SYN報文段,，對這個SYN報文段進行確認(rèn),，設(shè)置Acknowledgment Number（確認(rèn)序號）為x+1(Sequence Number+1)；同時,，自己自己還要發(fā)送SYN請求信息,，將SYN位置為1，Sequence Number為y,；服務(wù)器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中,，一并發(fā)送給客戶端，此時服務(wù)器進入SYN_RECV狀態(tài),；

第三次握手：客戶端收到服務(wù)器的SYN+ACK報文段,。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報文段,，這個報文段發(fā)送完畢以后,，客戶端和服務(wù)器端都進入ESTABLISHED狀態(tài)，完成TCP三次握手,。

那么如果三次握手改成二次握手 會現(xiàn)在啥問題： 已失效的連接請求報文段突然又傳送到了服務(wù)端,，因而產(chǎn)生錯誤。詳解：

• client發(fā)出的第一個連接請求報文段并沒有丟失,，而是在某個網(wǎng)絡(luò)結(jié)點長時間的滯留了,，以致延誤到連接釋放 后 才到達server。本來這是一個早已失效的報文段,。但server收到此失效的連接請求報文段后,，就誤認(rèn)為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認(rèn)報文段,，同意建立連接,。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn),，新的連接就建立了,。

• 由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認(rèn),，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立,，并一直等待client發(fā)來數(shù)據(jù),。這樣，server的很多資源就白白浪費掉了,。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生,。例如剛才那種情況，client不會向server的確認(rèn)發(fā)出確認(rèn),。server由于收不到確認(rèn),，就知道client并沒有要求建立連接,。”

4,、三次握手后就可以傳送數(shù)據(jù)了,。數(shù)據(jù)傳送完畢后，就要斷開TCP連接了,，這就是TCP的第四次分手,。

第一次分手：主機1（可以是客戶端 或者 服務(wù)器端），設(shè)置Sequence Number和Acknowledgment Number,，向主機2發(fā)送一個FIN報文段,；此時，主機1進入FIN_WAIT_1狀態(tài),；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了,；

第二次分手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段,，Acknowledgment Number為Sequence Number加1,；主機1進入FIN_WAIT_2狀態(tài)；主機2告訴主機1,，我“同意”你的關(guān)閉請求,；

第三次分手：主機2向主機1發(fā)送FIN報文段，請求關(guān)閉連接,，同時主機2進入LAST_ACK狀態(tài),；

第四次分手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段,，然后主機1進入TIME_WAIT狀態(tài),；主機2收到主機1的ACK報文段以后，就關(guān)閉連接,；此時,，主機1等待2MSL后依然沒有收到回復(fù)，則證明Server端已正常關(guān)閉,，那好,，主機1也可以關(guān)閉連接了。

5,、分個手也要四次,，煩不煩，看看為啥分手要這么麻煩：

TCP協(xié)議是一種面向連接的,、可靠的,、基于字節(jié)流的運輸層通信協(xié)議。

TCP是全雙工模式,，這就意味著,，當(dāng)主機1發(fā)出FIN報文段時,，只是表示主機1已經(jīng)沒有數(shù)據(jù)要發(fā)送了，主機1告訴主機2,，它的數(shù)據(jù)已經(jīng)全部發(fā)送完了,；但是，這個時候主機1還是可以接受來自主機2的數(shù)據(jù),；當(dāng)主機2返回ACK報文段時,，表示它已經(jīng)知道主機1沒有數(shù)據(jù)發(fā)送了，但是主機2還是可以發(fā)送數(shù)據(jù)到主機1的,；然后主機2也發(fā)送了FIN報文段時,，這個時候就表示主機2也沒有數(shù)據(jù)要發(fā)送了，就會告訴主機1,，我也沒有數(shù)據(jù)要發(fā)送了,，之后彼此就 中斷了這次TCP連接。

6,、四次分手過程中的狀態(tài)變化,。

FIN_WAIT_1: 其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1狀態(tài)實際上是當(dāng)SOCKET在ESTABLISHED狀態(tài)時,，它想主動關(guān)閉連接,，向?qū)Ψ桨l(fā)送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態(tài),。而當(dāng)對方回應(yīng)ACK報文后,，則進入到FIN_WAIT_2狀態(tài)，當(dāng)然在實際的正常情況下,，無論對方何種情況下,，都應(yīng)該馬上回應(yīng)ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的,，而FIN_WAIT_2狀態(tài)還有時常?？梢杂胣etstat看到。（主動方）

FIN_WAIT_2：上面已經(jīng)詳細解釋了這種狀態(tài),，實際上FIN_WAIT_2狀態(tài)下的SOCKET,，表示半連接，也即有一方要求close連接,，但另外還告訴對方,，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關(guān)閉連接,。（主動方）

CLOSE_WAIT：表示在等待關(guān)閉。當(dāng)對方close一個SOCKET后發(fā)送FIN報文給自己,，你系統(tǒng)毫無疑問地會回應(yīng)一個ACK報文給對方,，此時則進入到CLOSE_WAIT狀態(tài),。接下來，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方,，如果沒有的話,，那么你也就可以 close這個SOCKET，發(fā)送FIN報文給對方,，也即關(guān)閉連接,。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關(guān)閉連接,。（被動方）

LAST_ACK: 它是被動關(guān)閉一方在發(fā)送FIN報文后,，最后等待對方的ACK報文。當(dāng)收到ACK報文后,，也即可以進入到CLOSED可用狀態(tài)了,。（被動方）

TIME_WAIT: 表示收到了對方的FIN報文，并發(fā)送出了ACK報文,，就等2MSL后即可回到CLOSED可用狀態(tài)了,。如果FINWAIT1狀態(tài)下，收到了對方同時帶FIN標(biāo)志和ACK標(biāo)志的報文時,，可以直接進入到TIME_WAIT狀態(tài),，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動方）

CLOSED: 表示連接中斷,。

九,、HTTP詳解

1、HTTP協(xié)議永遠都是客戶端發(fā)起請求,，服務(wù)器回送響應(yīng),。一個客戶端向服務(wù)器端發(fā)出請求，然后服務(wù)器返回響應(yīng)(response),，連接就被關(guān)閉了,。

2、做過Socket編程的人都知道,，消息頭/消息體”的分割方式是很常用的,，消息頭告訴對方這個消息是干什么的，消息體告訴對方怎么干,。每一個HTTP包都分為HTTP頭和HTTP體兩部分,，消息體是可選的，而消息頭是必須的。每當(dāng)我們打開一個網(wǎng)頁,，

HTTP 請求由三部分組成：請求行,、 請求頭和請求正文。請求行是指請求方法 URI 協(xié)議/版本,，

格式如：POST /index.php HTTP/1.1 也就是：請求方式 /URL 協(xié)議/協(xié)議的版本,。

3、請求方式

HTTP/2：這個版本是 2015年5月正式發(fā)布,。HTTP/2通過支持請求與相應(yīng)的多路重用來減少延遲,，通過壓縮HTTP頭字段將協(xié)議開銷降到最低，同時增加了對請求優(yōu)先級和服務(wù)器端推送的支持,。

HTTP/1.1協(xié)議中共定義了8種HTTP請求方法,。

• GET：GET請求會顯示請求指定的資源。一般來說GET方法應(yīng)該只用于數(shù)據(jù)的讀取,，而不應(yīng)當(dāng)用于會產(chǎn)生副作用的非冪等的操作中,。

GET會方法請求指定的頁面信息，并返回響應(yīng)主體,，GET被認(rèn)為是不安全的方法,，因為GET方法會被網(wǎng)絡(luò)蜘蛛等任意的訪問。

• HEAD：HEAD方法與GET方法一樣,，都是向服務(wù)器發(fā)出指定資源的請求,。但是，服務(wù)器在響應(yīng)HEAD請求時不會回傳資源的內(nèi)容部分,，即：響應(yīng)主體,。這樣，我們可以不傳輸全部內(nèi)容的情況下,，就可以獲取服務(wù)器的響應(yīng)頭信息,。HEAD方法常被用于客戶端查看服務(wù)器的性能。

• POST：POST請求會 向指定資源提交數(shù)據(jù),，請求服務(wù)器進行處理,，如：表單數(shù)據(jù)提交、文件上傳等,，請求數(shù)據(jù)會被包含在請求體中,。POST方法是非冪等的方法，因為這個請求可能會創(chuàng)建新的資源或/和修改現(xiàn)有資源,。

• PUT：PUT請求會身向指定資源位置上傳其最新內(nèi)容,，PUT方法是冪等的方法。通過該方法客戶端可以將指定資源的最新數(shù)據(jù)傳送給服務(wù)器取代指定的資源的內(nèi)容,。

• DELETE：DELETE請求用于請求服務(wù)器刪除所請求URI（統(tǒng)一資源標(biāo)識符,，Uniform Resource Identifier）所標(biāo)識的資源,。DELETE請求后指定資源會被刪除，DELETE方法也是冪等的,。

• CONNECT：CONNECT方法是HTTP/1.1協(xié)議預(yù)留的,，能夠?qū)⑦B接改為管道方式的代理服務(wù)器。通常用于SSL加密服務(wù)器的鏈接與非加密的HTTP代理服務(wù)器的通信,。

• OPTIONS：OPTIONS請求與HEAD類似，一般也是用于客戶端查看服務(wù)器的性能,。 這個方法會請求服務(wù)器返回該資源所支持的所有HTTP請求方法,，該方法會用'*'來代替資源名稱，向服務(wù)器發(fā)送OPTIONS請求,，可以測試服務(wù)器功能是否正常,。JavaScript的XMLHttpRequest對象進行CORS跨域資源共享時，就是使用OPTIONS方法發(fā)送嗅探請求,，以判斷是否有對指定資源的訪問權(quán)限,。 允許

• TRACE：TRACE請求服務(wù)器回顯其收到的請求信息，該方法主要用于HTTP請求的測試或診斷,。

4,、在HTTP/1.1標(biāo)準(zhǔn)制定之后，又陸續(xù)擴展了一些方法,。其中使用中較多的是PATCH 方法：

• PATCH：PATCH方法在2010年的RFC 5789標(biāo)準(zhǔn)中被定義,。PATCH請求與PUT請求類似，同樣用于資源的更新,。二者有以下兩點不同：

PATCH一般用于資源的部分更新,，而PUT一般用于資源的整體更新。

當(dāng)資源不存在時,，PATCH會創(chuàng)建一個新的資源,，而PUT只會對已在資源進行更新。

5,、冪等性(Idempotence)

HTTP方法的冪等性是指一次和多次請求某一個資源應(yīng)該具有同樣的副作用,。冪等性屬于語義范疇，正如編譯器只能幫助檢查語法錯誤一樣,，HTTP規(guī)范也沒有辦法通過消息格式等語法手段來定義它,，這可能是它不太受到重視的原因之一。但實際上,，冪等性是分布式系統(tǒng)設(shè)計中十分重要的概念,，而HTTP的分布式本質(zhì)也決定了它在HTTP中具有重要地位。

HTTP協(xié)議本身是一種面向資源的應(yīng)用層協(xié)議,，但對HTTP協(xié)議的使用實際上存在著兩種不同的方式：一種是RESTful的,，它把HTTP當(dāng)成應(yīng)用層協(xié)議，比較忠實地遵守了HTTP協(xié)議的各種規(guī)定；另一種是SOA的,，它并沒有完全把HTTP當(dāng)成應(yīng)用層協(xié)議,，而是把HTTP協(xié)議作為了傳輸層協(xié)議，然后在HTTP之上建立了自己的應(yīng)用層協(xié)議,。HTTP冪等性主要針對RESTful風(fēng)格的,，冪等性并不屬于特定的協(xié)議，它是分布式系統(tǒng)的一種特性,；所以,，不論是SOA還是RESTful的Web API設(shè)計都應(yīng)該考慮冪等性。下面將介紹HTTP GET,、DELETE,、PUT、POST四種主要方法的語義和冪等性,。

HTTP GET方法用于獲取資源,，不應(yīng)有副作用，所以是冪等的,。

HTTP DELETE方法用于刪除資源,，有副作用，但它應(yīng)該滿足冪等性,。比如：DELETE http://www./article/4231,，調(diào)用一次和N次對系統(tǒng)產(chǎn)生的副作用是相同的，即刪掉id為4231的帖子,；因此,，調(diào)用者可以多次調(diào)用或刷新頁面而不必擔(dān)心引起錯誤。

比較容易混淆的是HTTP POST和PUT,。POST和PUT的區(qū)別容易被簡單地誤認(rèn)為“POST表示創(chuàng)建資源,，PUT表示更新資源”；而實際上,，二者均可用于創(chuàng)建資源,，更為本質(zhì)的差別是在冪等性方面。在HTTP規(guī)范中對POST和PUT是這樣定義的：

POST所對應(yīng)的URI并非創(chuàng)建的資源本身,，而是資源的接收者,。比如用POST提交帖子，兩次相同的POST請求會在服務(wù)器端創(chuàng)建兩份資源,，它們具有不同的URI,；所以，POST方法不具備冪等性,。而PUT所對應(yīng)的URI是要創(chuàng)建或更新的資源本身,。比如：PUT 創(chuàng)建或更新ID為4231的帖子,。對同一URI進行多次PUT的副作用和一次PUT是相同的；因此,，PUT方法具有冪等性,。

比如，論壇網(wǎng)站中防止意外的重復(fù)發(fā)帖：

用POST 來實現(xiàn)發(fā)帖,；用PUT 來實現(xiàn)更新帖,。