IP 協(xié)議
通信的時(shí)候，雙方必須知道對(duì)方的標(biāo)識(shí)，好比發(fā)郵件必須知道對(duì)方的郵件地址。互聯(lián)網(wǎng)上每個(gè)計(jì)算機(jī)的唯一標(biāo)識(shí)就是IP地址，類(lèi)似123.123.123.123。如果一臺(tái)計(jì)算機(jī)同時(shí)接入到兩個(gè)或更多的網(wǎng)絡(luò)，比如路由器，它就會(huì)有兩個(gè)或多個(gè)IP地址，所以，IP地址對(duì)應(yīng)的實(shí)際上是計(jì)算機(jī)的網(wǎng)絡(luò)接口，通常是網(wǎng)卡。
IP協(xié)議負(fù)責(zé)把數(shù)據(jù)從一臺(tái)計(jì)算機(jī)通過(guò)網(wǎng)絡(luò)發(fā)送到另一臺(tái)計(jì)算機(jī)。數(shù)據(jù)被分割成一小塊一小塊，然后通過(guò)IP包發(fā)送出去。由于互聯(lián)網(wǎng)鏈路復(fù)雜，兩臺(tái)計(jì)算機(jī)之間經(jīng)常有多條線路，因此，路由器就負(fù)責(zé)決定如何把一個(gè)IP包轉(zhuǎn)發(fā)出去。IP包的特點(diǎn)是按塊發(fā)送，途徑多個(gè)路由，但不保證能到達(dá)，也不保證順序到達(dá)。
一個(gè)IP包除了包含要傳輸?shù)臄?shù)據(jù)外，還包含源IP地址和目標(biāo)IP地址，源端口和目標(biāo)端口。
IP 是網(wǎng)絡(luò)層協(xié)議，TCP UDP 同屬傳輸層協(xié)議，傳輸層高于網(wǎng)絡(luò)層，HTTP是應(yīng)用層，高于傳輸層，最底層是鏈路層
TCP 協(xié)議
TCP協(xié)議則是建立在IP協(xié)議之上的。TCP協(xié)議負(fù)責(zé)在兩臺(tái)計(jì)算機(jī)之間建立可靠連接，保證數(shù)據(jù)包按順序到達(dá)。
TCP協(xié)議會(huì)通過(guò)握手建立連接，然后，對(duì)每個(gè)IP包編號(hào)，確保對(duì)方按順序收到，如果包丟掉了，就自動(dòng)重發(fā)。
當(dāng)TCP發(fā)出一個(gè)報(bào)文段后，它會(huì)啟動(dòng)一個(gè)定時(shí)器，等待目的端發(fā)確認(rèn)收到這個(gè)報(bào)文段，如果沒(méi)能及時(shí)收到該確認(rèn)信息，則將重發(fā)這個(gè)報(bào)文段。
當(dāng)TCP接收端收到發(fā)送端發(fā)來(lái)的TCP報(bào)文段時(shí)，它將發(fā)送一個(gè)確認(rèn)，這個(gè)確認(rèn)不是立即發(fā)送的，通常會(huì)推遲幾分之一秒。
TCP將保持它首部和數(shù)據(jù)的校驗(yàn)和。這是一個(gè)端到端的校驗(yàn)和，如果收到的報(bào)文段的校驗(yàn)和有差錯(cuò)，TCP將丟棄該報(bào)文段，同時(shí)不發(fā)送確認(rèn)收到的消息，從而使發(fā)送端超時(shí)重發(fā)。
最可靠的方式就是只要得不到確認(rèn)，就重新發(fā)送數(shù)據(jù)，直到得到確認(rèn)為止。
- TCP協(xié)議提供面向連接的服務(wù)，通過(guò)它建立的是可靠地連接
- Socket 和 ServerSocket 類(lèi)實(shí)現(xiàn)
- 服務(wù)端對(duì)于每一個(gè)連接都需要?jiǎng)?chuàng)建新的線程來(lái)處理
TCP 連接三次握手
請(qǐng)求—應(yīng)答—再次確認(rèn)
- 客戶(hù)端發(fā)送： 標(biāo)志位和序號(hào)
- 服務(wù)器端發(fā)送： 發(fā)送序號(hào)、確認(rèn)序號(hào)、標(biāo)識(shí)位
- 客戶(hù)端發(fā)送： 發(fā)送序號(hào)、確認(rèn)序號(hào)、標(biāo)志位
TCP 四次揮手
- 客戶(hù)端發(fā)送： FIN 用來(lái)關(guān)閉客戶(hù)端到服務(wù)端的數(shù)據(jù)傳送
- 服務(wù)端發(fā)送： 發(fā)送還需要發(fā)送的數(shù)據(jù)給客戶(hù)端
- 服務(wù)端發(fā)送： FIN 用了關(guān)閉服務(wù)端到客戶(hù)端的數(shù)據(jù)傳送
- 客戶(hù)端發(fā)送： 發(fā)送確認(rèn)序號(hào)給服務(wù)端，服務(wù)端停止，完成
四次揮手原因
服務(wù)端收到客戶(hù)端的斷開(kāi)請(qǐng)求后，可以發(fā)送數(shù)據(jù)和確認(rèn)碼，這兩部分分開(kāi)發(fā)送，所以多一次。
UDP協(xié)議
使用UDP協(xié)議時(shí)，不需要建立連接，只需要知道對(duì)方的IP地址和端口號(hào)，就可以直接發(fā)數(shù)據(jù)包。但是，能不能到達(dá)就不知道了。
雖然用UDP傳輸數(shù)據(jù)不可靠，但它的優(yōu)點(diǎn)是和TCP比，速度快，對(duì)于不要求可靠到達(dá)的數(shù)據(jù)，就可以使用UDP協(xié)議。
- 面向非連接的，屬不可靠協(xié)議，UDP套接字在使用前不需要進(jìn)行連接。
- 多個(gè)請(qǐng)求都放在一個(gè)消息隊(duì)列中一次處理不需要?jiǎng)?chuàng)建新的線程
- DatagrameSocket 和 DatagramPacket 類(lèi)來(lái)實(shí)現(xiàn)，DatagramPacket 為 DatagramSocket 的 send 方法的參數(shù)和 receive 方法的返回值
- UDP數(shù)據(jù)報(bào)文所能負(fù)載的最多數(shù)據(jù)，亦及一次傳送的最大數(shù)據(jù)為65507個(gè)字節(jié)
- DatagramPacket的內(nèi)部消息長(zhǎng)度值在接收數(shù)據(jù)后會(huì)發(fā)生改變，變?yōu)閷?shí)際接收到的數(shù)據(jù)的長(zhǎng)度值。
- DatagramPacket的getData（）方法總是返回緩沖區(qū)的原始大小，忽略了實(shí)際數(shù)據(jù)的內(nèi)部偏移量和長(zhǎng)度信息。使用時(shí)應(yīng)該制定 getData 的偏移量和長(zhǎng)度
new String(dp_receive.getData(),dp_receive.getOffset(),dp_receive.getOffset() + dp_receive.getLength());
UDP程序在receive()方法處阻塞，直到收到一個(gè)數(shù)據(jù)報(bào)文或等待超時(shí)。由于UDP協(xié)議是不可靠協(xié)議，如果數(shù)據(jù)報(bào)在傳輸過(guò)程中發(fā)生丟失，那么程序?qū)?huì)一直阻塞在receive()方法處，這樣客戶(hù)端將永遠(yuǎn)都接收不到服務(wù)器端發(fā)送回來(lái)的數(shù)據(jù)，但是又沒(méi)有任何提示。為了避免這個(gè)問(wèn)題，我們?cè)诳蛻?hù)端使用DatagramSocket類(lèi)的setSoTimeout()方法來(lái)制定receive()方法的最長(zhǎng)阻塞時(shí)間，并指定重發(fā)數(shù)據(jù)報(bào)的次數(shù)，如果每次阻塞都超時(shí)，并且重發(fā)次數(shù)達(dá)到了設(shè)置的上限，則關(guān)閉客戶(hù)端。
TCP 協(xié)議和 UDP 協(xié)議區(qū)別
速度、是否連接、傳輸可靠性、應(yīng)用場(chǎng)合
0. 速度：TCP傳輸慢，UDP傳輸快，因?yàn)閁DP不面向連接
1. 是否連接：面向連接和非連接，可靠與不可靠
2. 對(duì)系統(tǒng)資源的要求，TCP較多，UDP較少，TCP需要多個(gè)線程
3. UDP程序結(jié)構(gòu)簡(jiǎn)單，客戶(hù)端只需要發(fā)送接收即可，服務(wù)端只需要接收發(fā)送即可
4. 流模式和數(shù)據(jù)報(bào)模式，TCP傳輸使用流模式，UDP使用數(shù)據(jù)報(bào)模式，使用 DatagramePacket 傳輸數(shù)據(jù)
5. TCP保證數(shù)據(jù)正確性，UDP可能丟包，TCP保證數(shù)據(jù)順序，UDP 不保證
6. TCP適合傳輸大量數(shù)據(jù)，UDP不會(huì)分片，不適合傳輸大量數(shù)據(jù)
HTTP 協(xié)議
HTTP協(xié)議是Hyper Text Transfer Protocol（超文本傳輸協(xié)議）的縮寫(xiě),是用于從萬(wàn)維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。處于應(yīng)用層
HTTP是一個(gè)基于TCP/IP通信協(xié)議來(lái)傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢(xún)結(jié)果等）。
HTTP 協(xié)議特點(diǎn)
簡(jiǎn)單快速，客戶(hù)端向服務(wù)端請(qǐng)求時(shí)，只需傳遞方法和路徑
靈活，HTTP 運(yùn)行傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象，正在傳輸?shù)念?lèi)型由 Content-Type 標(biāo)記即可
無(wú)連接，含義是限制每次連接只處理一個(gè)請(qǐng)求，服務(wù)器處理完客戶(hù)端請(qǐng)求、并受到客戶(hù)端應(yīng)答后立即斷開(kāi)連接，節(jié)約傳輸時(shí)間
無(wú)狀態(tài)，指對(duì)事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著后續(xù)處理需要前面的信息則必須重傳，導(dǎo)致傳輸數(shù)據(jù)量增大。但是在服務(wù)器不需要先前信息時(shí)應(yīng)答更快。
HTTP 的 URL
URL 是 URI 的具體實(shí)現(xiàn)形式
HTTP 的請(qǐng)求消息 Request
- 請(qǐng)求行 第一部分：請(qǐng)求行，用來(lái)說(shuō)明請(qǐng)求類(lèi)型,要訪問(wèn)的資源以及所使用的HTTP版本.
- 請(qǐng)求頭部 第二部分：請(qǐng)求頭部，緊接著請(qǐng)求行（即第一行）之后的部分，用來(lái)說(shuō)明服務(wù)器要使用的附加信息
- 空行，請(qǐng)求頭部后面的空行是必須的
- 請(qǐng)求數(shù)據(jù)，請(qǐng)求數(shù)據(jù)也叫主體，可以添加任意的其他數(shù)據(jù)。
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
HTTP 的響應(yīng) Response
- 狀態(tài)行，由HTTP協(xié)議版本號(hào)， 狀態(tài)碼， 狀態(tài)消息 三部分組成。
- 消息報(bào)頭，用來(lái)說(shuō)明客戶(hù)端要使用的一些附加信息，Date:生成響應(yīng)的日期和時(shí)間；Content-Type:指定了MIME類(lèi)型的HTML(text/html),編碼類(lèi)型是UTF-8
- 空行，消息報(bào)頭后面的空行是必須的
- 響應(yīng)正文，服務(wù)器返回給客戶(hù)端的文本信息。
HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
<html>
<head></head>
<body>
<!--body goes here-->
</body>
</html>
HTTP 的狀態(tài)嗎
1xx：指示信息--表示請(qǐng)求已接收，繼續(xù)處理
2xx: 成功，表示請(qǐng)求已被成功接收、理解、處理
3xx：重定向，302 緩存已修改，使用心得請(qǐng)求 304 緩存未修改，使用舊的
4xx：客戶(hù)端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)
5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求
常見(jiàn)狀態(tài)碼
200 OK //客戶(hù)端請(qǐng)求成功
400 Bad Request //客戶(hù)端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解
401 Unauthorized //請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用
403 Forbidden //服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)
404 Not Found //請(qǐng)求資源不存在，eg：輸入了錯(cuò)誤的URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶(hù)端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常
HTTP 工作原理
- 客戶(hù)端使用 TCP 連接服務(wù)端
- 客戶(hù)端發(fā)送 HTTP 請(qǐng)求
- 服務(wù)端接受請(qǐng)求并返回 HTTP 響應(yīng)
- 釋放 TCP 連接
- 客戶(hù)端解析返回內(nèi)容
HTTP 請(qǐng)求方法
根據(jù)HTTP標(biāo)準(zhǔn)，HTTP請(qǐng)求可以使用多種請(qǐng)求方法。
HTTP1.0定義了三種請(qǐng)求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五種請(qǐng)求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
最常用 GET POST PUT DELETE 對(duì)應(yīng) 查、改、增、刪
GET 請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。
HEAD 類(lèi)似于get請(qǐng)求，只不過(guò)返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭
POST 向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和/或已有資源的修改。
PUT 從客戶(hù)端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
DELETE 請(qǐng)求服務(wù)器刪除指定的頁(yè)面。
CONNECT HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。
OPTIONS 允許客戶(hù)端查看服務(wù)器的性能。
TRACE 回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。
GET 和 POST 區(qū)別
數(shù)據(jù)傳輸方式 GET 提交數(shù)據(jù)附在 URL 之后，使用 ? 和 & 符號(hào)連接；POST 提交數(shù)據(jù)在請(qǐng)求體中。GET，提交數(shù)據(jù)在地址欄中顯示。POSt 不會(huì)顯示
數(shù)據(jù)傳輸大小 HTTP 協(xié)議沒(méi)有對(duì)傳輸數(shù)據(jù)及 URL 長(zhǎng)度做限制。但是特定瀏覽器會(huì)限制 URL 長(zhǎng)度。所以 GET 方式 URL 長(zhǎng)度有限制，POST 對(duì)提交數(shù)據(jù)理論無(wú)限制
安全性 POST 的比 GET 安全性高
keep-alive
從 HTTP/1.1 起，默認(rèn)都開(kāi)啟了 Keep-Alive,保持連接性，當(dāng)進(jìn)行一次 HTTP 請(qǐng)求之后，客戶(hù)端和服務(wù)端之間用于傳輸 HTTP 數(shù)據(jù)的 TCP 連接不會(huì)關(guān)閉，如果客戶(hù)端再次訪問(wèn)這個(gè)服務(wù)端，會(huì)繼續(xù)使用這一條已經(jīng)建立的鏈接，
Keep-Alive 不會(huì)永久保持鏈接，它有一個(gè)保持時(shí)間，可以在不同服務(wù)器軟件中設(shè)定。
range
HTTP 區(qū)間請(qǐng)求時(shí)配置
心跳包
創(chuàng)建 TCP 連接，每隔一段時(shí)間客戶(hù)端都向服務(wù)器端發(fā)送消息提示存活。
心跳包和輪詢(xún)區(qū)別
心跳包采用 TCP Socket 長(zhǎng)連接，不需要多次連接
輪詢(xún)是每次都發(fā)送 HTTP 請(qǐng)求，每次都需要?jiǎng)?chuàng)建 TCP 連接，所以輪詢(xún)對(duì)流量資源和電量的消耗更大
參考連接：
http://blog.csdn.net/ns_code/article/details/14105457
http://m.itdecent.cn/p/80e25cb1d81a
