1．忽略返回狀態(tài)

第一個隱患很明顯，但它是開發(fā)新手最容易犯的一個錯誤。如果您忽略函數(shù)的返回狀態(tài)，當它們失敗或部分成功的時候，您也許會迷失。反過來，這可能傳播錯誤，使定位問題的源頭變得困難。

捕獲并檢查每一個返回狀態(tài)，而不是忽略它們?？紤]清單 1 顯示的例子，一個套接字 send 函數(shù)。

清單 1. 忽略 API 函數(shù)返回狀態(tài)

清單 1 探究一個函數(shù)片斷，它完成套接字 send 操作（通過套接字發(fā)送數(shù)據(jù)）。函數(shù)的錯誤狀態(tài)被捕獲并測試，但這個例子忽略了 send 在無阻塞模式（由 MSG_DONTWAIT 標志啟用）下的一個特性。

send API 函數(shù)有三類可能的返回值：

• 如果數(shù)據(jù)成功地排到傳輸隊列，則返回 0。

• 如果排隊失敗，則返回 -1（通過使用 errno 變量可以了解失敗的原因）。

• 如果不是所有的字符都能夠在函數(shù)調(diào)用時排隊，則最終的返回值是發(fā)送的字符數(shù)。

由于 send 的 MSG_DONTWAIT 變量的無阻塞性質(zhì)，函數(shù)調(diào)用在發(fā)送完所有的數(shù)據(jù)、一些數(shù)據(jù)或沒有發(fā)送任何數(shù)據(jù)后返回。在這里忽略返回狀態(tài)將導致不完全的發(fā)送和隨后的數(shù)據(jù)丟失。

2．對等套接字閉包

UNIX 有趣的一面是你幾乎可以把任何東西看成是一個文件。文件本身、目錄、管道、設備和套接字都被當作文件。這是新穎的抽象，意味著一整套的 API 可以用在廣泛的設備類型上。

考慮 read API 函數(shù)，它從文件讀取一定數(shù)量的字節(jié)。read 函數(shù)返回讀取的字節(jié)數(shù)（最高為您指定的最大值）；或者 -1，表示錯誤；或者 0，如果已經(jīng)到達文件末尾。

如果在一個套接字上完成一個 read 操作并得到一個為 0 的返回值，這表明遠程套接字端的對等層調(diào)用了 close API 方法。該指示與文件讀取相同 —— 沒有多余的數(shù)據(jù)可以通過描述符讀?。▍⒁?清單 2）。

清單 2．適當處理 read API 函數(shù)的返回值

同樣，可以用 write API 函數(shù)來探測對等套接字的閉包。在這種情況下，接收 SIGPIPE 信號，或如果該信號阻塞，write 函數(shù)將返回 -1 并設置 errno 為 EPIPE。

3．地址使用錯誤（EADDRINUSE）

你可以使用 bind API 函數(shù)來綁定一個地址（一個接口和一個端口）到一個套接字端點。可以在服務器設置中使用這個函數(shù)，以便限制可能有連接到來的接口。也可以在客戶端設置中使用這個函數(shù)，以便限制應當供出去的連接所使用的接口。bind 最常見的用法是關聯(lián)端口號和服務器，并使用通配符地址（INADDR_ANY），它允許任何接口為到來的連接所使用。

bind 普遍遭遇的問題是試圖綁定一個已經(jīng)在使用的端口。該陷阱是也許沒有活動的套接字存在，但仍然禁止綁定端口（bind 返回 EADDRINUSE），它由 TCP 套接字狀態(tài) TIME_WAIT 引起。該狀態(tài)在套接字關閉后約保留 2 到 4 分鐘。在 TIME_WAIT 狀態(tài)退出之后，套接字被刪除，該地址才能被重新綁定而不出問題。

等待 TIME_WAIT 結束可能是令人惱火的一件事，特別是如果您正在開發(fā)一個套接字服務器，就需要停止服務器來做一些改動，然后重啟。幸運的是，有方法可以避開 TIME_WAIT 狀態(tài)?？梢越o套接字應用 SO_REUSEADDR 套接字選項，以便端口可以馬上重用。

考慮清單 3 的例子。在綁定地址之前，我以 SO_REUSEADDR 選項調(diào)用 setsockopt。為了允許地址重用，我設置整型參數(shù)（on）為 1 （不然，可以設為 0 來禁止地址重用）。

清單 3．使用 SO_REUSEADDR 套接字選項避免地址使用錯誤

在應用了 SO_REUSEADDR 選項之后，bind API 函數(shù)將允許地址的立即重用。

4．發(fā)送結構化數(shù)據(jù)

套接字是發(fā)送無結構二進制字節(jié)流或 ASCII 數(shù)據(jù)流（比如 HTTP 上的 HTTP 頁面，或 SMTP 上的電子郵件）的完美工具。但是如果試圖在一個套接字上發(fā)送二進制數(shù)據(jù)，事情將會變得更加復雜。

比如說，您想要發(fā)送一個整數(shù)：你可以肯定，接收者將使用同樣的方式來解釋該整數(shù)嗎？運行在同一架構上的應用程序可以依賴它們共同的平臺來對該類型的 數(shù)據(jù)做出相同的解釋。但是，如果一個運行在高位優(yōu)先的 IBM PowerPC 上的客戶端發(fā)送一個 32 位的整數(shù)到一個低位優(yōu)先的 Intel x86，那將會發(fā)生什么呢？字節(jié)排列將引起不正確的解釋。

字節(jié)交換還是不呢？

Endianness?是指內(nèi)存中字節(jié)的排列順序。高位優(yōu)先（big endian）?按最高有效字節(jié)在前排列，然而?低位優(yōu)先（little endian）?按照最低有效字節(jié)在前排序。

高位優(yōu)先架構（比如 PowerPC?）比低位優(yōu)先架構（比如 Intel? Pentium? 系列，其網(wǎng)絡字節(jié)順序是高位優(yōu)先）有優(yōu)勢。這意味著，對高位優(yōu)先的機器來說，在 TCP/IP 內(nèi)控制數(shù)據(jù)是自然有序的。低位優(yōu)先架構要求字節(jié)交換 —— 對網(wǎng)絡應用程序來說，這是一個輕微的性能弱點。

通過套接字發(fā)送一個 C 結構會怎么樣呢？這里，也會遇到麻煩，因為不是所有的編譯器都以相同的方式排列一個結構的元素。結構也可能被壓縮以便使浪費的空間最少，這進一步使結構中的元素錯位。

幸好，有解決這個問題的方案，能夠保證兩端數(shù)據(jù)的一致解釋。過去，遠程過程調(diào)用（Remote Procedure Call，RPC）套裝工具提供所謂的外部數(shù)據(jù)表示（External Data Representation，XDR）。XDR 為數(shù)據(jù)定義一個標準的表示來支持異構網(wǎng)絡應用程序通信的開發(fā)。

現(xiàn)在，有兩個新的協(xié)議提供相似的功能?？蓴U展標記語言/遠程過程調(diào)用（XML/RPC）以 XML 格式安排 HTTP 上的過程調(diào)用。數(shù)據(jù)和元數(shù)據(jù)用 XML 進行編碼并作為字符串傳輸，并通過主機架構把值和它們的物理表示分開。SOAP 跟隨 XML-RPC，以更好的特性和功能擴展了它的思想。，獲取更多關于每個協(xié)議的信息。

【文章福利】小編推薦自己的Linux內(nèi)核技術交流群:【749907784】整理了一些個人覺得比較好的學習書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實戰(zhàn)項目及代碼)? ? ??

5．TCP 中的幀同步假定

TCP 不提供幀同步，這使得它對于面向字節(jié)流的協(xié)議是完美的。這是 TCP 與 UDP（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）的一個重要區(qū)別。UDP 是面向消息的協(xié)議，它保留發(fā)送者和接收者之間的消息邊界。TCP 是一個面向流的協(xié)議，它假定正在通信的數(shù)據(jù)是無結構的，如圖 1 所示。

圖 1．UDP 的幀同步能力和缺乏幀同步的 TCP

圖 1 的上部說明一個 UDP 客戶端和服務器。左邊的對等層完成兩個套接字的寫操作，每個 100 字節(jié)。協(xié)議棧的 UDP 層追蹤寫的數(shù)量，并確保當右邊的接收者通過套接字獲取數(shù)據(jù)時，它以同樣數(shù)量的字節(jié)到達。換句話說，為讀者保留了寫者提供的消息邊界。

現(xiàn)在，看圖 1 的底部．它為 TCP 層演示了相同粒度的寫操作。兩個獨立的寫操作（每個 100 字節(jié)）寫入流套接字。但在本例中，流套接字的讀者得到的是 200 字節(jié)。協(xié)議棧的 TCP 層聚合了兩次寫操作。這種聚合可以發(fā)生在 TCP/IP 協(xié)議棧的發(fā)送者或接收者中任何一方。重要的是，要注意到聚合也許不會發(fā)生 —— TCP 只保證數(shù)據(jù)的有序發(fā)送。

對大多數(shù)開發(fā)人員來說，該陷阱會引起困惑。您想要獲得 TCP 的可靠性和 UDP 的幀同步。除非改用其他的傳輸協(xié)議，比如流傳輸控制協(xié)議（STCP），否則就要求應用層開發(fā)人員來實現(xiàn)緩沖和分段功能。

調(diào)試套接字應用程序的工具

GNU/Linux 提供幾個工具，它們可以幫助您發(fā)現(xiàn)套接字應用程序中的一些問題。此外，使用這些工具還有教育意義，而且能夠幫助解釋應用程序和 TCP/IP 協(xié)議棧的行為。在這里，您將看到對幾個工具的概述。查閱下面的 了解更多的信息。

查看網(wǎng)絡子系統(tǒng)的細節(jié)

netstat 工具提供查看 GNU/Linux 網(wǎng)絡子系統(tǒng)的能力。使用 netstat，可以查看當前活動的連接（按單個協(xié)議進行查看），查看特定狀態(tài)的連接（比如處于監(jiān)聽狀態(tài)的服務器套接字）和許多其他的信息。清單 4 顯示了 netstat 提供的一些選項和它們啟用的特性。

清單 4．netstat 實用程序的用法模式

盡管存在許多其他的實用程序，但 netstat 的功能很全面，它覆蓋了 route、ifconfig 和其他標準 GNU/Linux 工具的功能。

監(jiān)視流量

可以使用 GNU/Linux 的幾個工具來檢查網(wǎng)絡上的低層流量。tcpdump 工具是一個比較老的工具，它從網(wǎng)上“嗅探”網(wǎng)絡數(shù)據(jù)包，打印到 stdout 或記錄在一個文件中。該功能允許查看應用程序產(chǎn)生的流量和 TCP 生成的低層流控制機制。一個叫做 tcpflow 的新工具與 tcpdump 相輔相成，它提供協(xié)議流分析和適當?shù)刂貥嫈?shù)據(jù)流的方法，而不管數(shù)據(jù)包的順序或重發(fā)。清單 5 顯示 tcpdump 的兩個用法模式。

清單 5．tcpdump 工具的用法模式

tcpdump 和 tcpflow 工具有大量的選項，包括創(chuàng)建復雜過濾表達式的能力。查閱下面的 獲取更多關于這些工具的信息。

tcpdump 和 tcpflow 都是基于文本的命令行工具。如果您更喜歡圖形用戶界面（GUI），有一個開放源碼工具 Ethereal 也許適合您的需要。Ethereal 是一個專業(yè)的協(xié)議分析軟件，它可以幫助調(diào)試應用層協(xié)議。它的插入式架構（plug-in architecture）可以分解協(xié)議，比如 HTTP 和您能想到的任何協(xié)議（寫本文的時候共有 637 個協(xié)議）。

總結

套接字編程是容易而有趣的，但是您要避免引入錯誤或至少使它們?nèi)菀妆话l(fā)現(xiàn)，這就需要考慮本文中描述的這 5 個常見的陷阱，并且采用標準的防錯性程序設計實踐。GNU/Linux 工具和實用程序還可以幫助發(fā)現(xiàn)一些程序中的小問題。

原文作者：一起學嵌入式