目錄
一、基礎協議
1、網絡分層模型
爲了使不同計算機廠家生產的計算機能夠相互通信，以便在更大的範圍內建立計算機網絡，國際標準化組織（ISO）在1978年提出了“開放系統互聯參考模型”，即著名的OSI/RM模型（Open System Interconnection/Reference Model）。它將計算機網絡體系結構的通信協議劃分爲七層，自下而上依次爲：物理層（Physics Layer）、數據鏈路層（Data Link Layer）、網絡層（Network Layer）、傳輸層（Transport Layer）、會話層（Session Layer）、表示層（Presentation Layer）、應用層（Application Layer）。
2、協議劃分
物理層：以太網 · 調制解調器 · 電力線通信(PLC) · SONET/SDH · G.709 · 光導纖維 · 同軸電纜 · 雙絞線等
數據鏈路層：Wi-Fi(IEEE 802.11) · WiMAX(IEEE 802.16) ·ATM · DTM · 令牌環 · 以太網 ·FDDI · 幀中繼 · GPRS · EVDO ·HSPA · HDLC · PPP · L2TP ·PPTP · ISDN·STP · CSMA/CD等
網絡層協議：IP (IPv4 · IPv6) · ICMP· ICMPv6·IGMP ·IS-IS · IPsec · ARP · RARP · RIP等
傳輸層協議：TCP · UDP · TLS · DCCP · SCTP · RSVP · OSPF 等
應用層協議：DHCP ·DNS · FTP · Gopher · HTTP· WS· IMAP4 · IRC · NNTP · XMPP ·POP3 · SIP · SMTP ·SNMP · SSH ·TELNET · RPC · RTCP · RTP ·RTSP· SDP · SOAP · GTP · STUN · NTP· SSDP · BGP 等
3、重點解析
1）TCP/IP和UDP協議
TCP（Transmission Control Protocol，傳輸控制協議）是面向連接的協議，即在收發數據前 ，都需要與對面建立可靠的鏈接，TCP的三次握手以及TCP的四次揮手！
TCP的6種標誌位的分別代表：
SYN(synchronous建立聯機)
ACK(acknowledgement 確認)
PSH(push傳送)
FIN(finish結束)
RST(reset重置)
URG(urgent緊急)
Sequence number(順序號碼)
Acknowledge number(確認號碼) (ack)
各個狀態的意義如下：
LISTEN - 偵聽來自遠方TCP端口的連接請求；
SYN-SENT -在發送連接請求後等待匹配的連接請求；
SYN-RECEIVED - 在收到和發送一個連接請求後等待對連接請求的確認；
ESTABLISHED- 代表一個打開的連接，數據可以傳送給用戶；
FIN-WAIT-1 - 等待遠程TCP的連接中斷請求，或先前的連接中斷請求的確認；
FIN-WAIT-2 - 從遠程TCP等待連接中斷請求；
CLOSE-WAIT - 等待從本地用戶發來的連接中斷請求；
CLOSING -等待遠程TCP對連接中斷的確認；
LAST-ACK - 等待原來發向遠程TCP的連接中斷請求的確認；
TIME-WAIT -等待足夠的時間以確保遠程TCP接收到連接中斷請求的確認；
CLOSED - 沒有任何連接狀態；
三次握手： 建立一個TCP連接時，需要客戶端和服務端總共發送3個包以確認連接的建立， 在Socket編程中，這一過程由客戶端執行connect來觸發，具體流程圖如下：
- 第一次握手：Client將標誌位SYN置爲1，隨機產生一個值seq=J，並將該數據包發送給Server， Client進入SYN_SENT狀態，等待Server確認。
- 第二次握手：Server收到數據包後由標誌位SYN=1知道Client請求建立連接，Server將標誌位 SYN和ACK都置爲1，ack=J+1，隨機產生一個值seq=K，並將該數據包發送給Client以確認連接請求 ，Server進入SYN_RCVD狀態。
- 第三次握手：Client收到確認後，檢查ack是否爲J+1，ACK是否爲1，如果正確則將標誌位ACK 置爲1，ack=K+1，並將該數據包發送給Server，Server檢查ack是否爲K+1，ACK是否爲1，如果正確則 連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以 開始傳輸數據了。
四次揮手： 終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發送4個包以確認連接的斷開。 在Socket編程中，這一過程由客戶端或服務端任一方執行close來觸發，具體流程圖如下：
- 第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入 FIN_WAIT_1狀態
- 第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同， 一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
- 第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK 狀態。
- 第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。 另外也可能是同時發起主動關閉的情況：
另外還可能有一個常見的問題就是：爲什麼建立連接是三次握手，而關閉連接卻是四次揮手呢？ 答：因爲服務端在LISTEN狀態下，收到建立連接請求的SYN報文後，把ACK和SYN放在一個報文裏 發送給客戶端。而關閉連接時，當收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還 能接收數據，己方也未必全部數據都發送給對方了，所以己方可以立即close，也可以發送一些 數據給對方後，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會 分開發送。
UDP(User Datagram Protocol)用戶數據報協議，非連接的協議，傳輸數據之前源端和終端不 建立連接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘可能快地把它扔到網絡上。 在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬 的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。 相比TCP就是無需建立鏈接，結構簡單，無法保證正確性，容易丟包。UDP協議多應用於廣播。
TCP協議在底層機制上解決了UDP協議的順序和丟包重傳問題。但相比UDP又帶來了新的問題，TCP協議是流式的，數據包沒有邊界。應用程序使用TCP通信就會面臨這些難題。
因爲TCP通信是流式的，在接收1個大數據包時，可能會被拆分成多個數據包發送。多次Send底層也可能會合併成一次進行發送。這裏就需要2個操作來解決：
- 分包：
Server收到了多個數據包，需要拆分數據包 - 合包：
Server收到的數據只是包的一部分，需要緩存數據，合併成完整的包
所以，TCP網絡通信時需要設定通信協議。常見的TCP網絡通信協議有HTTP、HTTPS、FTP、SMTP、POP3、IMAP、SSH、Redis、Memcache、MySQL
2）HTTP和HTTPS協議
Http(超文本傳輸協議)， 是用於傳輸諸如HTML的超媒體文檔的應用層協議。它被設計用於Web瀏覽器和Web服務器之間的通信，但它也可以用於其他目的。 HTTP遵循經典的客戶端-服務端模型，客戶端打開一個連接以發出請求，然後等待它收到服務器端響應。HTTP是無狀態協議，意味着服務器不會在兩個請求之間保留任何數據（狀態）。
Http1.0協議，客戶端與web服務器建立連接後，只能獲得一個web資源！
Http1.1協議，允許客戶端與web服務器建立連接後，在一個連接上獲取多個web資源！
前面講過了三次握手，再看一下Http操作的一個流程了：
- 用戶點擊瀏覽器上的url(超鏈接)，Web瀏覽器與Web服務器建立連接
- 建立連接後，客戶端發送請求給服務器，請求的格式爲: 統一資源標識符(URL)+協議版本號(一般是1.1)+MIME信息(多個消息頭)+一個空行
- 服務端收到請求後，給予相應的返回信息，返回格式爲: 協議版本號 + 狀態行(處理結果) + 多個信息頭 + 空行 + 實體內容(比如返回的HTML)
- 客戶端接收服務端返回信息，通過瀏覽器顯示出來，然後與服務端斷開連接；當然如果中途 某步發生錯誤的話，錯誤信息會返回到客戶端，並顯示，比如：經典的404錯誤！
Http的幾種請求方式
實際開發中我們用得較多的方式是Get和Post，但是實際開發可能還會用到其他請求方式。
- Get：請求獲取Request-URI所標識的資源
- POST：在Request-URI所標識的資源後附加新的數據
- HEAD 請求獲取由Request-URI所標識的資源的響應信息報頭
- PUT：請求服務器存儲一個資源，並用Request-URI作爲其標識
- DELETE：請求服務器刪除Request-URI所標識的資源
- TRACE：請求服務器回送收到的請求信息，主要用於測試或診斷
- CONNECT：保留將來使用
- OPTIONS：請求查詢服務器的性能，或者查詢與資源相關的選項
Get請求和Post請求的對比：
Get產生一個TCP數據包；Post產生兩個TCP數據包。
對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
對於POST，瀏覽器先發送header，服務器響應100（continue），然後再發送data，服務器響應200（返回數據）；
Http狀態碼合集
當然，這些狀態碼只是要給參考，實際上決定權在服務器端(後臺的)手上，一種方案是請求後， 服務器返回給我們的是狀態，或者另一種，在應用不用弄多語言版本的時候最好用，直接返回 一串結果信息的Json給我們，我們直接顯示就好，這樣可以偷懶不少！下面列下狀態碼合集，參考 下就好：
- 100~199 : 成功接受請求，客戶端需提交下一次請求才能完成整個處理過程
- 200: OK，客戶端請求成功
- 300~399：請求資源已移到新的地址(302,307,304)
- 401：請求未授權，改狀態代碼需與WWW-Authenticate報頭域一起使用
- 403：Forbidden，服務器收到請求，但是拒絕提供服務
- 404：Not Found，請求資源不存在，這個就不用說啦
- 500：Internal Server Error，服務器發生不可預期的錯誤
- 503：Server Unavailable，服務器當前不能處理客戶端請求，一段時間後可能恢復正常
HTTP Request Header請求頭信息對照表:
|
Header |
解釋 |
示例 |
|
Accept |
指定客戶端能夠接收的內容類型 |
Accept: text/plain, text/html |
|
Accept-Charset |
瀏覽器可以接受的字符編碼集。 |
Accept-Charset: iso-8859-5 |
|
Accept-Encoding |
指定瀏覽器可以支持的web服務器返回內容壓縮編碼類型。 |
Accept-Encoding: compress, gzip |
|
Accept-Language |
瀏覽器可接受的語言 |
Accept-Language: en,zh |
|
Accept-Ranges |
可以請求網頁實體的一個或者多個子範圍字段 |
Accept-Ranges: bytes |
|
Authorization |
HTTP授權的授權證書 |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
|
Cache-Control |
指定請求和響應遵循的緩存機制 |
Cache-Control: no-cache |
|
Connection |
表示是否需要持久連接。（HTTP 1.1默認進行持久連接） |
Connection: close |
|
Cookie |
HTTP請求發送時，會把保存在該請求域名下的所有cookie值一起發送給web服務器。 |
Cookie: $Version=1; Skin=new; |
|
Content-Length |
請求的內容長度 |
Content-Length: 348 |
|
Content-Type |
請求的與實體對應的MIME信息 |
Content-Type: application/x-www-form-urlencoded |
|
Date |
請求發送的日期和時間 |
Date: Tue, 15 Nov 2010 08:12:31 GMT |
|
Expect |
請求的特定的服務器行爲 |
Expect: 100-continue |
|
From |
發出請求的用戶的Email |
From: [email protected] |
|
Host |
指定請求的服務器的域名和端口號 |
Host: www.zcmhi.com |
|
If-Match |
只有請求內容與實體相匹配纔有效 |
If-Match: "737060cd8c284d8af7ad3082f209582d" |
|
If-Modified-Since |
如果請求的部分在指定時間之後被修改則請求成功，未被修改則返回304代碼 |
If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
|
If-None-Match |
如果內容未改變返回304代碼，參數爲服務器先前發送的Etag，與服務器迴應的Etag比較判斷是否改變 |
If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
|
If-Range |
如果實體未改變，服務器發送客戶端丟失的部分，否則發送整個實體。參數也爲Etag |
If-Range: "737060cd8c284d8af7ad3082f209582d" |
|
If-Unmodified-Since |
只在實體在指定時間之後未被修改才請求成功 |
If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
|
Max-Forwards |
限制信息通過代理和網關傳送的時間 |
Max-Forwards: 10 |
|
Pragma |
用來包含實現特定的指令 |
Pragma: no-cache |
|
Proxy-Authorization |
連接到代理的授權證書 |
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
|
Range |
只請求實體的一部分，指定範圍 |
Range: bytes=500-999 |
|
Referer |
先前網頁的地址，當前請求網頁緊隨其後,即來路 |
Referer: http://blog.csdn.net/coder_pig |
|
TE |
客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息 |
TE: trailers,deflate;q=0.5 |
|
Upgrade |
向服務器指定某種傳輸協議以便服務器進行轉換（如果支持） |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
|
User-Agent |
User-Agent的內容包含發出請求的用戶信息 |
User-Agent: Mozilla/5.0 (Linux; X11) |
|
Via |
通知中間網關或代理服務器地址，通信協議 |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
|
Warning |
關於消息實體的警告信息 |
Warn: 199 Miscellaneous warning |
HTTP Responses Header 響應頭信息對照表：
|
Header |
解釋 |
示例 |
|
Accept-Ranges |
表明服務器是否支持指定範圍請求及哪種類型的分段請求 |
Accept-Ranges: bytes |
|
Age |
從原始服務器到代理緩存形成的估算時間（以秒計，非負） |
Age: 12 |
|
Allow |
對某網絡資源的有效的請求行爲，不允許則返回405 |
Allow: GET, HEAD |
|
Cache-Control |
告訴所有的緩存機制是否可以緩存及哪種類型 |
Cache-Control: no-cache |
|
Content-Encoding |
web服務器支持的返回內容壓縮編碼類型 |
Content-Encoding: gzip |
|
Content-Language |
響應體的語言 |
Content-Language: en,zh |
|
Content-Length |
響應體的長度 |
Content-Length: 348 |
|
Content-Location |
請求資源可替代的備用的另一地址 |
Content-Location: /index.htm |
|
Content-MD5 |
返回資源的MD5校驗值 |
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
|
Content-Range |
在整個返回體中本部分的字節位置 |
Content-Range: bytes 21010-47021/47022 |
|
Content-Type |
返回內容的MIME類型 |
Content-Type: text/html; charset=utf-8 |
|
Date |
原始服務器消息發出的時間 |
Date: Tue, 15 Nov 2010 08:12:31 GMT |
|
ETag |
請求變量的實體標籤的當前值 |
ETag: "737060cd8c284d8af7ad3082f209582d" |
|
Expires |
響應過期的日期和時間 |
Expires: Thu, 01 Dec 2010 16:00:00 GMT |
|
Last-Modified |
請求資源的最後修改時間 |
Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
|
Location |
用來重定向接收方到非請求URL的位置來完成請求或標識新的資源 |
Location: http://blog.csdn.net/coder_pig |
|
Pragma |
包括實現特定的指令，它可應用到響應鏈上的任何接收方 |
Pragma: no-cache |
|
Proxy-Authenticate |
它指出認證方案和可應用到代理的該URL上的參數 |
Proxy-Authenticate: Basic |
HTTPS 協議，是由 HTTP 加上 TLS/SSL 協議構建的可進行加密傳輸、身份認證的網絡協議，主要通過數字證書、加密算法、非對稱密鑰等技術完成互聯網數據傳輸加密，實現互聯網傳輸安全保護。設計目標主要有三個。
（1）數據保密性：保證數據內容在傳輸的過程中不會被第三方查看。就像快遞員傳遞包裹一樣，都進行了封裝，別人無法獲知裏面裝了什麼。
（2）數據完整性：及時發現被第三方篡改的傳輸內容。就像快遞員雖然不知道包裹裏裝了什麼東西，但他有可能中途掉包，數據完整性就是指如果被掉包，我們能輕鬆發現並拒收。
（3）身份校驗安全性：保證數據到達用戶期望的目的地。就像我們郵寄包裹時，雖然是一個封裝好的未掉包的包裹，但必須確定這個包裹不會送錯地方，通過身份校驗來確保送對了地方。
HTTPS協議的改進
雙向的身份認證
客戶端和服務端在傳輸數據之前,會通過基於X.509證書對雙方進行身份認證 。具體過程如下 [3] :
客戶端發起 SSL 握手消息給服務端要求連接。
服務端將證書發送給客戶端。
客戶端檢查服務端證書，確認是否由自己信任的證書籤發機構簽發。 如果不是，將是否繼續通訊的決定權交給用戶選擇 ( 注意，這裏將是一個安全缺陷 )。如果檢查無誤或者用戶選擇繼續，則客戶端認可服務端的身份。
服務端要求客戶端發送證書，並檢查是否通過驗證。失敗則關閉連接，認證成功則從客戶端證書中獲得客戶端的公鑰，一般爲1024位或者 2048位。到此，服務器客戶端雙方的身份認證結束，雙方確保身份都是真實可靠的。
數據傳輸的機密性
客戶端和服務端在開始傳輸數據之前，會協商傳輸過程需要使用的加密算法。 客戶端發送協商請求給服務端, 其中包含自己支持的非對成加密的密鑰交換算法 ( 一般是RSA), 數據簽名摘要算法 ( 一般是SHA或者MD5) , 加密傳輸數據的對稱加密算法 ( 一般是DES),以及加密密鑰的長度。 服務端接收到消息之後，選中安全性最高的算法，並將選中的算法發送給客戶端，完成協商。客戶端生成隨機的字符串，通過協商好的非對稱加密算法，使用服務端的公鑰對該字符串進行加密，發送給服務端。 服務端接收到之後，使用自己的私鑰解密得到該字符串。在隨後的數據傳輸當中，使用這個字符串作爲密鑰進行對稱加密 [3] 。
防止重放攻擊
SSL使用序列號來保護通訊方免受報文重放攻擊。這個序列號被加密後作爲數據包的負載。在整個SSL握手中,都有一個唯一的隨機數來標記SSL握手。 這樣防止了攻擊者嗅探整個登錄過程，獲取到加密的登錄數據之後，不對數據進行解密, 而直接重傳登錄數據包的攻擊手法。
可以看到，鑑於電子商務等安全上的需求，HTTPS對比HTTP 協議，在安全方面已經取得了極大的增強。總結來說，HTTPS的改進點在於創造性的使用了非對稱加密算法，在不安全的網路上，安全的傳輸了用來進行非對稱加密的密鑰，綜合利用了非對稱加密的安全性和對稱加密的快速性 。
與HTTP原理區別
HTTPS 主要由兩部分組成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過 TLS 進行加密，所以傳輸的數據都是加密後的數據。
3）WS和WSS協議
WebSocket協議是html5的一種通信協議，該協議兼容我們常用的瀏覽器。例如Chrome、 Firefox、IE等。它可以使客戶端和服務端雙向數據傳輸更加簡單快捷，並且在TCP連接進行一次握手後，就可以持久性連接，同時允許服務端對客戶端推送數據。外加傳統模式的協議一般HTTP請求可能會包含較長的頭部，但真正有效的可能只有小部分，從而就佔用了很多資源和帶寬。因此WebSocket協議不僅可以實時通訊，支持擴展；也可以壓縮節省服務器資源和帶寬。
WS協議和WSS協議兩個均是WebSocket協議的SCHEM，兩者一個是非安全的，一個是安全的。也是統一的資源標誌符。就好比HTTP協議和HTTPS協議的差別。非安全的沒有證書，安全的需要SSL證書。（SSL是Netscape所研發，用來保障網絡中數據傳輸的安全性，主要是運用數據加密的技術，能夠避免數據在傳輸過程被不被竊取或者監聽。）其中WSS表示在TLS之上的WebSocket。WS一般默認是80端口，而WSS默認是443端口，大多數網站用的就是80和433端口。（在高防防護過程中，80和433端口的網站是需要備案纔可以接入國內的。）當然網站也會有別的端口，這種如果做高防是方案是可以用海外高防的。WS和WSS的體現形式分別是TCP+WS AS WS ，TCP+TLS+WS AS WS。服務器網址就是 URL。
最後再說下WebSocket協議的特點：建立在 TCP 協議之上，服務端實現容易；與 HTTP 協議有良好的兼容性，握手時不容易被屏蔽，可以通過各種 HTTP 代理服務器；數據輕量，實時通訊；可以發送文本和二進制數據。不限制同源，客戶端可以與任意服務器端進行通訊。因此WebSocket協議的出現，爲很多人解決了關於擴展以及兼容性協議的煩惱問題。
4）SSL、TLS和SSH協議
- SSL（Secure Socket Layer--安全套接字層）：爲網絡通信安全以及數據完整性提供保障的一種安全協議，在TCP/IP的傳輸層對網絡連接進行加密；
- TLS（Transport Layer Security--傳輸層安全）：爲SSL 3.0的後繼版本，TSL與SSL 3.0的顯著差別在於加密算法不同，TSL的主要目的是使SSL更加安全，使協議的規範更加精確和完善，在TCP/IP的傳輸層對網絡連接進行加密；
- SSH（Secure Shell）：由 IETF 的網絡工作小組（Network Working Group）所制定；SSH 爲建立在應用層和傳輸層基礎上的安全協議。SSH 是目前較可靠，專爲遠程登錄會話和其他網絡服務提供安全性的協議。利用 SSH 協議可以有效防止遠程管理過程中的信息泄露問題。
以上各協議通常使用的摘要算法：
SHA （全稱Secure Hash Algorithm） 譯作安全散列算法，是一種能將任意長度的消息映射成一個固定長度散列值（又稱消息摘要）的算法。
SHA家族的五個算法，分別是SHA-1、SHA-224、SHA-256、SHA-384,和SHA-512,後四者有時並稱爲SHA-2.SHA-1在許多安全協議中廣泛使用，包括TLS和SSL、PGP、SSH、S/MIME和IPsec.在2005年，密碼學家就證明SHA-1的破解速度比預期提高了2000倍，雖然破解仍然是極其困難和昂貴的，但隨着計算機變得越來越快和越來越廉價，SHA-1算法的安全性也逐年降低，已被密碼學家嚴重質疑，希望由安全強度更高的SHA-2替代它。
5）SOAP協議
SOAP（Simple Object Accrss Protocol，簡單對象訪問協議）是一種簡單的基於XML的協議，可以使應用程序在分散或分佈式的環境中通過HTTP來交換信息。
SOAP基於XML語言和XSD標準，其定義了一套編碼規則，編碼規則定義如何將數據表示爲消息，以及怎樣通過HTTP協議來傳輸SOAP消息，由四部分組成：
（1） SOAP信封（Envelope）：定義了一個框架，框架描述了消息中的內容是什麼，包括消息的內容、發送者、接收者、處理者以及如何處理消息。
（2）SOAP編碼規則：定義了一種系列化機制，用於交換應用程序所定義的數據類型的實例。
（3） SOAP RPC表示：定義了用於表示遠程過程調用和應答協定。
（4）SOAP綁定：定義了一種使用底層傳輸協議來完成在節點間交換SOAP信封的約定。
SOAP消息基本上是從發送端到接收端的單向傳輸，常常結合起來執行類似於請求/應答的模式。不需要把SOAP消息綁定到特定的協議，SOAP可以運行在任何其他傳輸協議（HTTP、SMTP、FTP等）上。另外，SOAP提供了標準的RPC方法來調用Web Service以請求/響應模式運行。
SOAP是Web Service的通信協議。當用戶通過UDDI找到你的WSDL描述文檔後，他通過可以SOAP調用你建立的Web服務中的一個或多個操作。SOAP是XML文檔形式的調用方法的規範，可以支持不同的底層接口，像HTTP(S)或者SMTP。
應用程序通過使用遠程過程調用（RPC）在諸如 DCOM 與 CORBA 等對象之間進行通信的方式會產生兼容性以及安全問題；防火牆和代理服務器通常會阻止此類流量。通過 HTTP 在應用程序間通信是更好的方法，因爲 HTTP 得到了所有的因特網瀏覽器及服務器的支持。SOAP 提供了一種標準的方法，使得運行在不同的操作系統並使用不同的技術和編程語言的應用程序可以互相進行通信。
-
SOAP是一種輕量級通信協議
-
SOAP用於應用程序之間的通信
-
使用SOAP的應用使用HTTP協議通信
-
SOAP獨立於平臺
-
SOAP獨立於編程語言
-
SOAP基於XML
-
SOAP很簡單並可擴展
-
SOAP允許繞過防火牆
PHP SOAP擴展，提供 SoapClient 和 SoapServer 類，實現web service接口服務，支持提供wsdl文檔和不提供wsdl文檔兩種方式。（參考：https://blog.csdn.net/ljl890705/article/details/79142383）
二、應用知識
1、PHP Curl 、Ajax 和 調試用Postman 支持HTTP客戶端請求（GET、POST）
2、SocketJS 和 html5 WebSocket 支持WS客戶端請求
3、\Swoole\Coroutine\Http\Client、\Swoole\Http\WebSocket異步和\EasySwoole\HttpClient\HttpClient（封裝前者，協程異步）支持HTTP和WS客戶端請求
4、\Swoole\Client(SWOOLE_SOCK_TCP) 支持TCP客戶端請求
5、\Swoole\Coroutine\Client 提供了支持TCP、UDP和UnixSocket協議的socket客戶端封裝，底層實現協程調度，並且支持異步併發請求
