文章出自:http://blog.csdn.net/cumtwyc/article/details/48273085
在我們平時的開發(fā)中用到的最多的是HTTP協(xié)議，而HTTP協(xié)議本身是一種應用層協(xié)議，屬于文本協(xié)議；并且這種協(xié)議也基本上滿足了應用的大部分需求。HTTP協(xié)議當初的設計并沒有想到它應用的是如此的廣泛，所以設計的時候考慮的比較簡單實用，也許也就是這種簡單實用才這么廣泛；但如今，HTTP協(xié)議似乎并不能滿足所有的需求，特別是當今的web2.0時代，瀏覽器應用橫行的年代，也越來越多需要長連接的應用，所以在HTML5以及Flash等客戶端應用中都加入了長連接的定義，并且我也相信在未來的互聯(lián)網(wǎng)開發(fā)中會出現(xiàn)很多的長連接應用。在我們公司也曾經自己開發(fā)過長連接的應用，前端是基于flash的，后端是基于Java的實現(xiàn)，自己基于TCP/IP協(xié)議制定了一套穩(wěn)定，安全，可靠的應用層協(xié)議，至今一直在線上運行，情況也比較穩(wěn)定；在此，我想基于我的知識和對于socket的理解在這里做一次分享，也許不是很深入和透徹，但絕對很基礎。
其實如果不理解套接字的具體實現(xiàn)所關聯(lián)的數(shù)據(jù)結構和底層協(xié)議的工作細節(jié)，就很難抓住網(wǎng)絡編程的精妙之處，對于TCP套接字（即Socket的實例）來說更是如此。這里我就對創(chuàng)建和使用Socket和ServerSocket實例的底層細節(jié)進行介紹。請注意，這些內容僅僅涵蓋了一些普通的事件實例，略去了很多細節(jié)。盡管如此，我相信即使是這樣的基礎的理解也是有用的。如果希望了解更詳盡的內容，可以參考TCP規(guī)范，或關于該方面的其他著作（例如TCP/IP詳解）。
圖1是一個Socket實例所關聯(lián)的一些信息的簡化視圖。JVM或其運行的平臺（即，主機操作系統(tǒng)中的“套接字層”）為這些類的支持提供了底層實現(xiàn)。Java對象上的操作則轉換成了這種底層抽象上的操作。在這里，“Socket”指的是圖1中的類之一，而“套接字（socket）”指的是底層抽象，這種抽象是有操作系統(tǒng)提供或由JVM自己實現(xiàn)（例如在嵌入式系統(tǒng)中）。有一點需要注意，即運行在統(tǒng)一主機上的其他程序可能也會通過底層套接字抽象來使用網(wǎng)絡，因此會與Java Socket實例競爭系統(tǒng)資源，如端口等。
圖1
在此，“套接字結構”是指底層實現(xiàn)（包括JVM和TCP/IP，但通常是后者）的數(shù)據(jù)結構集，這些數(shù)據(jù)結構包括了特定Socket實例所關聯(lián)的信息。例如，套接字結構除其他信息外還包括：
l 該套接字說關聯(lián)的本地和遠程互聯(lián)網(wǎng)地址和端口號。本地互聯(lián)網(wǎng)地址（圖中標記為“Local IP”）是賦值給本地主機的；本地端口號在Socket實例創(chuàng)建時設置的。遠程地址和端口號標記了與本地套接字連接的遠程套接字（如果沒有連接的話）。不久，我們將對這些值確定的時間和方式做進一步介紹。
l 一個FIFO（先進先出，F(xiàn)irst In First Out）隊列用于存放接收到的等待分配的數(shù)據(jù)，以及一個用于存放等待傳輸?shù)臄?shù)據(jù)的隊列。
l 對于TCP套接字，還包括了與打開和關閉TCP握手相關的額外協(xié)議狀態(tài)信息。圖1中，狀態(tài)是“關閉”；所有套接字的起始狀態(tài)都是關閉的。
一些多用途操作系統(tǒng)為用戶提供了獲取底層數(shù)據(jù)結構“快照”的工具，netstat是其中之一，太在UNIX（Linux）和Windows平臺上都可用。只要給定適當?shù)倪x項，netstat就能顯示和圖1的那些信息：SendQ和RecvQ中的字節(jié)數(shù)，本地和遠程IP地址和端口號，以及連接狀態(tài)等。netstat的命令行選項有多種，但它輸出看起來是這樣的：
Active Internet connections(server and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:36045 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53363 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 128.133.190.219:34077 4.71.104.187:80 TIME_WAIT
tcp 0 0 128.133.190.219:43346 79.62.132.8:22 ESTABLISHED
tcp 0 0 128.133.190.219:875 128.133.190.43:2409 ESTABLISHED
tcp6 0 0 :::22 :::* LISTEN
前4行和最后一行描述了正在偵聽連接的服務器套接字。第5行代表了到一個Web服務器（80端口）的連接，該服務器已經單方面關閉。倒數(shù)第2行是先有的TCP連接。如果系統(tǒng)支持的話，你可能想要嘗試一下netstat，來檢測下上文描述的場景的連接狀態(tài)。然而要知道，這些圖中描述的狀態(tài)轉換過程轉瞬即逝，可能很難通過netstat提供的“快照”功能將其捕獲。
了解這些數(shù)據(jù)結構，以及底層協(xié)議如何對其進行影響是非常有用的，因為它們控制了各種Socket對象行為的各個方面。例如，由于TCP提供了一種可信賴的字節(jié)流服務，任何寫入Socket的OutputStream的數(shù)據(jù)副本都必須保留，直到其在連接的另一端被成功接收。向輸出流寫數(shù)據(jù)并不意味著數(shù)據(jù)實際上已經被發(fā)送，他們只是被復制到了本地緩沖區(qū)。就算在Socket的OutputStream上進行flush操作，也不能保證數(shù)據(jù)能夠立即發(fā)送到信道。此外，字節(jié)流服務的自身屬性決定了其無法保留輸入流中消息的邊界信息，這里的邊界信息的意思就是上一個數(shù)據(jù)包和下一個數(shù)據(jù)包之間的區(qū)別信息。這使一些協(xié)議的接收和解析過程變得復雜。另一方面，對于DatagramSocket，數(shù)據(jù)包并沒有為重傳而進行緩存，任何時候調用send()方法返回后，數(shù)據(jù)就已經發(fā)送給了執(zhí)行傳輸任務的網(wǎng)絡子系統(tǒng)。如果網(wǎng)絡子系統(tǒng)由于某種原因無法處理這些消息，該數(shù)據(jù)包將毫無提示地被丟棄（不過這種情況很少發(fā)生）。
1、緩沖區(qū)和TCP
作為程序員，在使用TCP套接字時需要記住的最重要一點是：
不能假設在連接的一端將數(shù)據(jù)寫入輸出流和在另一端從輸入流讀取數(shù)據(jù)之間有任何一致性。
尤其是在發(fā)送端由單個輸出流的write()方法傳輸?shù)臄?shù)據(jù)，可能會通過另一端的多個輸入流的read()方法來獲取；而一個read()方法可能會返回多個write()方法傳輸?shù)臄?shù)據(jù)。
為了展示這種情況，考慮如下程序：
byte[] buf0 = new byte[1000];
byte[] buf1 = new byte[2000];
byte[] buf2 = new byte[5000];
…
Socket s = new Socket(destAddr, destPort);
OutputStream out = s.getOutputStream();
…
out.write(buf0);
…
out.write(buf1);
…
out.write(buf2);
…
s.close();
其中，圓點代表了設置緩沖區(qū)數(shù)據(jù)的代碼，但不包括對out.write()方法的調用。在本節(jié)的討論中，“in”代表接收端Socket的InputStream，“out”代表發(fā)送端Socket的OutputStream。
這個TCP連接想接收端傳輸8000字節(jié)。在連接的接收端，這8000字節(jié)的分組方式取決于連接兩端out.write()方法和in.read()方法的調用時間差，以及提供給in.read()方法的緩沖區(qū)大小。
我們可以認為TCP連接上發(fā)送的所有字節(jié)序列在某一瞬間被分成了3個FIFO隊列；
l SendQ：在發(fā)送端底層實現(xiàn)中緩存的字節(jié)，這些字節(jié)已經寫入了輸出流，但還沒在接收端主機上成功接收。
l RecvQ：在接收端底層實現(xiàn)中緩存的字節(jié)，等待分配到接收程序，即從輸入流中讀取。
l Delivered：接收者從輸入流已經讀取到的字節(jié)。
調用out.write()方法將向SendQ追加字節(jié)。TCP協(xié)議負責將字節(jié)按順序從SendQ移動到RecvQ。有重要的一點需要明確，這個轉移過程無法由用戶程序控制或直接觀察到，并且在塊中（chunk）發(fā)生，這些塊的大小在一定程度上獨立于傳遞給write()方法的緩沖區(qū)大小。
接收程序從Socket的InputStream讀取數(shù)據(jù)時，字節(jié)就從RecvQ移動到Delivered中，而轉移的塊的大小依賴于RecvQ中的數(shù)據(jù)量和傳遞給read()方法緩沖區(qū)大小。
圖2展示了上例中3次調用out.write()方法后，另一端調用in.read()方法前，以上3個隊列的可能狀態(tài)。不同的陰影效果分別代表了上文中3次調用write()方法傳輸?shù)牟煌瑪?shù)據(jù)。
圖2描述的發(fā)送端主機的netstat輸出的瞬間狀態(tài)中，會包含類似于下一行的內容：
在接收端主機，netstat會顯示：
圖2 3次調用write()方法后3個隊列的狀態(tài)
現(xiàn)在假設接收者調用read()方法時使用的緩沖區(qū)數(shù)組大小為2000字節(jié)，read()調用則將把等待分配隊列(RecvQ)中的1500字節(jié)全部移動到數(shù)組中，返回值為1500。注意，這些數(shù)據(jù)包括了第一次和第二次調用write()方法時傳輸?shù)淖止?jié)。在過一段時間，但TCP連接傳完更多數(shù)據(jù)后，這三部分的狀態(tài)可能如圖3所示。
圖3 第一次調用read()方法后
如果接收者現(xiàn)在調用read()方法時使用4000字節(jié)的緩沖區(qū)數(shù)組，將有很多字節(jié)從等待分配隊列（RecvQ）轉移到已分配隊列（Delivered）中。這包括第二次調用write()方法時剩下的1500字節(jié)加上第三次調用write()的前2500字節(jié)。此時隊列的狀態(tài)如圖4所示。
圖4 另一次調用read()后
下次調用read()方法返回的字節(jié)數(shù)，取決于緩沖區(qū)數(shù)組的大小，以及發(fā)送方套接字/TCP實現(xiàn)通過網(wǎng)絡向接收方實現(xiàn)傳輸數(shù)據(jù)的時機。數(shù)據(jù)從SendQ到RecvQ緩沖區(qū)的移動過程對應用程序協(xié)議的設計有重要的指導性。我們已經遇到過需要對使用帶內（in-band）分隔符，并通過Socket來接收的消息進行解析的情況。
