TCP/IP、Http、Socket、XMPP-從入門到深刻

爲了便於你們理解和記憶，咱們先對這幾個概念進行的介紹，而後分析他們的不一樣，再進行詳細的分析。php

1、TCP/IP簡介android

IP協議是網絡層，TCP協議是傳輸層，HTTP協議是應用層，socket是對TCP/IP協議的代碼封裝和應用。程序員

TPC/IP 主要解決數據如何在網絡中傳輸，HTTP主要解決如何包裝數據。數據庫

TCP/IP協議用來傳輸數據，應用層協議使傳輸的數據有意義，應用層協議有不少，好比HTTP、FTP、TELNET等，也能夠本身定義應用層協議。編程

好比：網頁使用HTTP協議封裝HTTP文本信息，再用TCP/IP作傳輸層協議將它傳送到瀏覽器。跨域

2、Socket簡介瀏覽器

Socket不是協議，而是一個能夠調用的接口（API）。咱們經過Socket，才能使用TCP/IP協議。安全

Socket跟TCP/IP協議沒有必然的聯繫。Socket編程接口在設計的時候，就但願也能適應其餘的網絡協議。因此說，Socket的出現只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而造成了咱們知道的一些最基本的函數接口，好比create、listen、connect、accept、send、read和write等等。服務器

TCP/IP只是協議，必需要具體實現，還要提供對外的操做接口，這就是Socket編程接口。Socket自己不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的接口。網絡

三、 TCP三次握手簡介

第一次握手：客戶端發送包到服務器，等待服務器確認；

第二次握手：服務器收到並確認客戶端的數據包，同時本身也發送一個數據吧回覆給客戶端；

第三次握手：客戶端收到服務器的數據包，向服務器發送確認包，此包發送完畢，就完成了三次握手。

先來個形象的比喻：我（客戶端）發了個郵件給你（服務端），（上面這是第一次握手），可是我不知道你收到沒有，因此你發了個「我已經收到」的郵件回覆給我（這是第二次握手）。我收到了你的郵件，可是你不知道我到底有沒有收到你的這封郵件，因此你不肯定我到底知不知道「你已經收到」。因此我還要再發送個郵件告知你我收到郵件了（這是第三次握手）。。

這樣就能確認彼此之間的通信是正常的。

握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。

理想狀態下，TCP鏈接一旦創建，在通訊雙方中的任何一方主動關閉鏈接以前，TCP 鏈接都將被一直保持下去。

斷開鏈接時服務器和客戶端都可以主動發起斷開TCP鏈接的請求，斷開過程須要通過「四次握手」。

4、Socket網絡鏈接的步驟

創建Socket鏈接至少須要一對套接字，其中一個運行於客戶端，稱爲ClientSocket ，另外一個運行於服務器端，稱爲ServerSocket 。

套接字之間的鏈接過程分爲三個步驟：服務器監聽，客戶端請求，鏈接確認。

一、服務器監聽：服務器端實時監控網絡狀態，處於等待鏈接的狀態，等待客戶端的鏈接請求。

二、客戶端請求：客戶端的套接字提出鏈接請求，要鏈接的目標是服務器端的套接字。客戶端的套接字必指出服務器端套接字的地址和端口號，而後就向服務器端套接字提出鏈接請求。

3。鏈接確認：當服務器端套接字監聽到客戶端套接字的請求時，就創建一個新的線程，把服務器端套接字的描述發給客戶端，一旦客戶端確認了此描述，雙方就正式創建鏈接。而服務器端套接字繼續監聽其餘客戶端的鏈接請求。

5、HTTP簡介

HTTP(Hypertext Transfer Protocol ) 超文本傳送協議，是創建在TCP協議之上的一種應用協議。

客戶端發送的每次請求都須要服務器響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

六 . TCP和UDP的區別

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

而UDP傳送數據前並不與對方創建鏈接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接收，固然也不用重發，UDP是無鏈接的、不可靠的一種數據傳輸協議。

因此UDP的開銷更小數據傳輸速率更高，實時性更好。

因此採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢，但並不能說QQ的通訊是不安全的，由於程序員能夠手動對UDP的數據收發進行驗證，好比發送方對每一個數據包進行編號而後由接收方進行驗證啊什麼的。

七 . XMPP簡介

XMPP（Extensible Messaging and Presence Protocol，前稱Jabber）是一種以XML爲基礎的開放式即時通訊協議，是經由互聯網工程工做小組（IETF）經過的互聯網標準。

XMPP網絡是基於服務器的，即客戶端之間彼此不直接交談。

一、XMPP實際是怎麼運行的，舉個栗子：

Jabber識別符（JID）是用戶登陸時所使用的帳號，一般像一個電子郵件地址，如someone@example.com；前部分爲用戶名，後部分爲XMPP服務器域名。

假設朱麗葉（juliet@capulet.com）想和羅密歐（romeo@montague.net）通話，他們兩人的帳號分別在 A.com 及 B.net 的服務器上。當朱麗葉輸入消息並按下發送鈕以後：

朱麗葉的XMPP客戶端將她的消息發送到A.com XMPP服務器。

A.com XMPP服務器打開與B.net XMPP服務器的鏈接。

B.net XMPP服務器將消息寄送給羅密歐。若是他目前不在在線，那麼存儲消息以待稍後寄送。

羅密歐與朱麗葉兩人的XMPP服務是由兩家不一樣的企業所提供的，而他們彼此傳訊時，不須擁有對方服務器的帳號，也不須成爲對方企業的會員。

二、XMPP特性

XMPP由於被Google Talk應用而被廣大網民所接觸。

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

分佈式：XMPP網絡的架構和電子郵件十分相像；XMPP核心協議通訊方式是先建立一個stream，XMPP以TCP傳遞XML數據流，沒有中央主服務器。任何人均可以運行本身的XMPP服務器，使我的及組織可以掌控他們的即時傳訊體驗。

彈性佳：XMPP除了用在即時通訊，還能用在網絡管理、內容供稿、協同工具、文件共享、遊戲、遠程系統監控等。

安全：XMPP協議的服務器能夠獨立於公衆XMPP網絡（例如在企業內部網絡中），而使用SASL及TLS等技術的可靠安全性，已內置於核心XMPP技術規格中。

三、與其餘協議互聯

XMPP協議的另外一功能是運輸（transports），也被稱爲網關（gateways），可容許用戶經過網絡使用其它協議。這能夠是其餘的即時通訊協議，也能夠是不一樣協議，如短信（SMS）或電子郵件。

各IM之間的互傳：

四、XMPP協議經過HTTP運輸

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

輪詢如今不推薦，輪詢：HTTP郵件存儲在服務器端的數據庫上，客戶端必須一再地以HTTP的GET和POST的方式去抓取（以及刊出）其中的消息。

綁定的方式：客戶端會保留一個長存的HTTP鏈接，等待一旦服務器有新的消息時，就馬上接收消息。由於輪詢的結果每每是服務端沒有新消息，這種推送的通知模式比輪詢的方式更有效率。

五、再舉個栗子，使用XMPP協議的客戶端1與服務器端對話：

客戶端1 鏈接到一個XMPP服務器，發送一條消息（主題和內容均爲「test 1449」）到客戶端2，而後註銷。

客戶端1:

<?xml version="1.0"?>

<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" to="XMPP服務器">

XMPP服務器：

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='XMPP服務器' id='1461777714'>

客戶端1:

<password>mypassword</password>

</query>

</iq>

XMPP服務器：

客戶端1:

</message>

<status>Logged out</status>

</presence>

</stream:stream>

XMPP服務器：

</stream:stream>

8、TCP/IP深刻

一、TCP/IP數據格式

便於你們觀看，下面是翻譯成中文後的圖片：

每一個字段的意思：

Source Port（源端口）和Destination Port（目的端口）:分別佔用16位，用於區別主機中的不一樣進程，而IP地址是用來區分不一樣的主機的，源端口號和目的端口號配合上IP首部中的源IP地址和目的IP地址就能惟一的肯定一個TCP鏈接。
Sequence Number（數據序號）:用來標識從TCP發端向TCP收端發送的數據字節流，它表示在這個報文段中的第一個數據字節在數據流中的序號；主要用來解決網絡報亂序的問題。
Acknowledgment Number（確認序號）:32位，包含發送確認的一端所指望收到的下一個序號，所以，確認序號應當是上次已成功收到數據字節序號加1。不過，只有當標誌位中的ACK標誌（下面介紹）爲1時該確認序列號的字段纔有效。主要用來解決不丟包的問題；
Offset（偏移）:給出首部中32 bit字的數目，須要這個值是由於任選字段的長度是可變的。這個字段佔4bit（最多能表示15個32bit的的字，即4*15=60個字節的首部長度），所以TCP最多有60字節的首部。然而，沒有任選字段，正常的長度是20字節；
TCP Flags: TCP首部中有6個標誌比特，它們中的多個可同時被設置爲1，主要是用於操控TCP的狀態機的，依次爲URG，ACK，PSH，RST，SYN，FIN。每一個標誌位的意思以下：

URG：此標誌表示TCP包的緊急指針域（後面立刻就要說到）有效，用來保證TCP鏈接不被中斷，而且督促中間層設備要儘快處理這些數據；

ACK：此標誌表示應答域有效，就是說前面所說的TCP應答號將會包含在TCP數據包中；有兩個取值：0和1，爲1的時候表示應答域有效，反之爲0；

PSH：這個標誌位表示Push操做。就是指在數據包到達接收端之後，當即傳送給應用程序，而不是在緩衝區中排隊；

RST：這個標誌表示鏈接復位請求。用來複位那些產生錯誤的鏈接，也被用來拒絕錯誤和非法的數據包；

SYN：表示同步序號，用來創建鏈接。SYN標誌位和ACK標誌位搭配使用，當鏈接請求的時候，SYN=1，ACK=0；鏈接被響應的時候，SYN=1，ACK=1；這個標誌的數據包常常被用來進行端口掃描。掃描者發送一個只有SYN的數據包，若是對方主機響應了一個數據包回來，就代表這臺主機存在這個端口；可是因爲這種掃描方式只是進行TCP三次握手的第一次握手，所以這種掃描的成功表示被掃描的機器不很安全，一臺安全的主機將會強制要求一個鏈接嚴格的進行TCP的三次握手；

FIN：表示發送端已經達到數據末尾，也就是說雙方的數據傳送完成，沒有數據能夠傳送了，發送FIN標誌位的TCP數據包後，鏈接將被斷開。這個標誌的數據包也常常被用於進行端口掃描。

Window:窗口大小，也就是有名的滑動窗口，用來進行流量控制；這是一個複雜的問題。

二、TCP/IP 三次握手

TCP協議之因此能提供可靠的鏈接是由於三次握手。三次握手的目的是同步鏈接雙方的序列號和確認號並交換 TCP窗口大小信息。

先簡單說下上圖中的 seq表示：Sequence Number（數據序號）。SYN：表示同步序號。ACK：不是TCP Flags裏的標誌，而是指Acknowledgment Number（確認序號）。

第一次握手：客戶端發送鏈接請求報文段，將SYN位置爲1，Sequence Number（數據序號）爲x；而後，客戶端進入SYN_SEND狀態，等待服務器的確認；

第二次握手：服務器收到客戶端的SYN報文段，對這個SYN報文段進行確認，設置Acknowledgment Number（確認序號）爲x+1(Sequence Number+1)；同時，本身本身還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述全部信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN+ACK報文段。而後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢之後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。

那麼若是三次握手改爲二次握手會如今啥問題：已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤。詳解：

client發出的第一個鏈接請求報文段並無丟失，而是在某個網絡結點長時間的滯留了，以至延誤到鏈接釋放後纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段後，就誤認爲是client再次發出的一個新的鏈接請求。因而就向client發出確認報文段，贊成創建鏈接。假設不採用「三次握手」，那麼只要server發出確認，新的鏈接就創建了。
因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建，並一直等待client發來數據。這樣，server的不少資源就白白浪費掉了。採用「三次握手」的辦法能夠防止上述現象發生。例如剛纔那種狀況，client不會向server的確認發出確認。server因爲收不到確認，就知道client並無要求創建鏈接。」

四、三次握手後就能夠傳送數據了。數據傳送完畢後，就要斷開TCP鏈接了，這就是TCP的第四次分手。

第一次分手：主機1（能夠是客戶端或者服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了；

第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「贊成」你的關閉請求；

第三次分手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態；

第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

五、分個手也要四次，煩不煩，看看爲啥分手要這麼麻煩：

TCP協議是一種面向鏈接的、可靠的、基於字節流的運輸層通訊協議。

TCP是全雙工模式，這就意味着，當主機1發出FIN報文段時，只是表示主機1已經沒有數據要發送了，主機1告訴主機2，它的數據已經所有發送完了；可是，這個時候主機1仍是能夠接受來自主機2的數據；當主機2返回ACK報文段時，表示它已經知道主機1沒有數據發送了，可是主機2仍是能夠發送數據到主機1的；而後主機2也發送了FIN報文段時，這個時候就表示主機2也沒有數據要發送了，就會告訴主機1，我也沒有數據要發送了，以後彼此就中斷了此次TCP鏈接。

六、四次分手過程當中的狀態變化。

FIN_WAIT_1: 其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別是：FIN_WAIT_1狀態其實是當SOCKET在ESTABLISHED狀態時，它想主動關閉鏈接，向對方發送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，固然在實際的正常狀況下，不管對方何種狀況下，都應該立刻迴應ACK報文，因此FIN_WAIT_1狀態通常是比較難見到的，而FIN_WAIT_2狀態還有時經常能夠用netstat看到。（主動方）

FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半鏈接，也即有一方要求close鏈接，但另外還告訴對方，我暫時還有點數據須要傳送給你(ACK信息)，稍後再關閉鏈接。（主動方）

CLOSE_WAIT：表示在等待關閉。當對方close一個SOCKET後發送FIN報文給本身，你係統毫無疑問地會迴應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態。接下來，實際上你真正須要考慮的事情是察看你是否還有數據發送給對方，若是沒有的話，那麼你也就能夠 close這個SOCKET，發送FIN報文給對方，也即關閉鏈接。因此你在CLOSE_WAIT狀態下，須要完成的事情是等待你去關閉鏈接。（被動方）

LAST_ACK: 它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也便可以進入到CLOSED可用狀態了。（被動方）

TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後便可回到CLOSED可用狀態了。若是FINWAIT1狀態下，收到了對方同時帶FIN標誌和ACK標誌的報文時，能夠直接進入到TIME_WAIT狀態，而無須通過FIN_WAIT_2狀態。（主動方）

CLOSED: 表示鏈接中斷。

9、HTTP詳解

一、HTTP協議永遠都是客戶端發起請求，服務器回送響應。一個客戶端向服務器端發出請求，而後服務器返回響應(response)，鏈接就被關閉了。

二、作過Socket編程的人都知道，消息頭/消息體」的分割方式是很經常使用的，消息頭告訴對方這個消息是幹什麼的，消息體告訴對方怎麼幹。每個HTTP包都分爲HTTP頭和HTTP體兩部分，消息體是可選的，而消息頭是必須的。每當咱們打開一個網頁，

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

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

三、請求方式

HTTP/2：這個版本是 2015年5月正式發佈。HTTP/2經過支持請求與相應的多路重用來減小延遲，經過壓縮HTTP頭字段將協議開銷降到最低，同時增長了對請求優先級和服務器端推送的支持。

HTTP/1.1協議中共定義了8種HTTP請求方法。

GET：GET請求會顯示請求指定的資源。通常來講GET方法應該只用於數據的讀取，而不該當用於會產生反作用的非冪等的操做中。

GET會方法請求指定的頁面信息，並返回響應主體，GET被認爲是不安全的方法，由於GET方法會被網絡蜘蛛等任意的訪問。

HEAD：HEAD方法與GET方法同樣，都是向服務器發出指定資源的請求。可是，服務器在響應HEAD請求時不會回傳資源的內容部分，即：響應主體。這樣，咱們能夠不傳輸所有內容的狀況下，就能夠獲取服務器的響應頭信息。HEAD方法常被用於客戶端查看服務器的性能。
POST：POST請求會向指定資源提交數據，請求服務器進行處理，如：表單數據提交、文件上傳等，請求數據會被包含在請求體中。POST方法是非冪等的方法，由於這個請求可能會建立新的資源或/和修改現有資源。
PUT：PUT請求會身向指定資源位置上傳其最新內容，PUT方法是冪等的方法。經過該方法客戶端能夠將指定資源的最新數據傳送給服務器取代指定的資源的內容。
DELETE：DELETE請求用於請求服務器刪除所請求URI（統一資源標識符，Uniform Resource Identifier）所標識的資源。DELETE請求後指定資源會被刪除，DELETE方法也是冪等的。
CONNECT：CONNECT方法是HTTP/1.1協議預留的，可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接與非加密的HTTP代理服務器的通訊。
OPTIONS：OPTIONS請求與HEAD相似，通常也是用於客戶端查看服務器的性能。這個方法會請求服務器返回該資源所支持的全部HTTP請求方法，該方法會用'*'來代替資源名稱，向服務器發送OPTIONS請求，能夠測試服務器功能是否正常。JavaScript的XMLHttpRequest對象進行CORS跨域資源共享時，就是使用OPTIONS方法發送嗅探請求，以判斷是否有對指定資源的訪問權限。容許
TRACE：TRACE請求服務器回顯其收到的請求信息，該方法主要用於HTTP請求的測試或診斷。

四、在HTTP/1.1標準制定以後，又陸續擴展了一些方法。其中使用中較多的是PATCH 方法：

PATCH：PATCH方法在2010年的RFC 5789標準中被定義。PATCH請求與PUT請求相似，一樣用於資源的更新。兩者有如下兩點不一樣：

PATCH通常用於資源的部分更新，而PUT通常用於資源的總體更新。

當資源不存在時，PATCH會建立一個新的資源，而PUT只會對已在資源進行更新。

五、冪等性(Idempotence)

HTTP方法的冪等性是指一次和屢次請求某一個資源應該具備一樣的反作用。冪等性屬於語義範疇，正如編譯器只能幫助檢查語法錯誤同樣，HTTP規範也沒有辦法經過消息格式等語法手段來定義它，這多是它不太受到重視的緣由之一。但實際上，冪等性是分佈式系統設計中十分重要的概念，而HTTP的分佈式本質也決定了它在HTTP中具備重要地位。

HTTP協議自己是一種面向資源的應用層協議，但對HTTP協議的使用實際上存在着兩種不一樣的方式：一種是RESTful的，它把HTTP當成應用層協議，比較忠實地遵照了HTTP協議的各類規定；另外一種是SOA的，它並無徹底把HTTP當成應用層協議，而是把HTTP協議做爲了傳輸層協議，而後在HTTP之上創建了本身的應用層協議。HTTP冪等性主要針對RESTful風格的，冪等性並不屬於特定的協議，它是分佈式系統的一種特性；因此，不管是SOA仍是RESTful的Web API設計都應該考慮冪等性。下面將介紹HTTP GET、DELETE、PUT、POST四種主要方法的語義和冪等性。

HTTP GET方法用於獲取資源，不該有反作用，因此是冪等的。

HTTP DELETE方法用於刪除資源，有反作用，但它應該知足冪等性。好比：DELETE http://www.xxxxx.com/article/4231，調用一次和N次對系統產生的反作用是相同的，即刪掉id爲4231的帖子；所以，調用者能夠屢次調用或刷新頁面而沒必要擔憂引發錯誤。

比較容易混淆的是HTTP POST和PUT。POST和PUT的區別容易被簡單地誤認爲「POST表示建立資源，PUT表示更新資源」；而實際上，兩者都可用於建立資源，更爲本質的差異是在冪等性方面。在HTTP規範中對POST和PUT是這樣定義的：

POST所對應的URI並不是建立的資源自己，而是資源的接收者。好比用POST提交帖子，兩次相同的POST請求會在服務器端建立兩份資源，它們具備不一樣的URI；因此，POST方法不具有冪等性。而PUT所對應的URI是要建立或更新的資源自己。好比：PUT 建立或更新ID爲4231的帖子。對同一URI進行屢次PUT的反作用和一次PUT是相同的；所以，PUT方法具備冪等性。

好比，論壇網站中防止意外的重複發帖：

用POST 來實現發帖；用PUT 來實現更新帖。

本文爲頭條號做者發佈，不表明今日頭條立場。