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