我認為，想要熟練掌握Linux下的TCP/IP網路程式設計，至少有三個層面的知識需要熟悉：

1. TCP/IP協議（如連線的建立和終止、重傳和確認、滑動視窗和擁塞控制等等）

2. Socket I/O系統呼叫（重點如read/write），這是TCP/IP協議在應用層表現出來的行為。

3. 編寫Performant, Scalable的伺服器程式。包括多執行緒、IO Multiplexing、非阻塞、非同步等各種技術。

關於TCP/IP協議，建議參考Richard Stevens的《TCP/IP Illustrated，vol1》（TCP/IP詳解卷1）。

關於第二層面，依然建議Richard Stevens的《Unix network proggramming，vol1》（Unix網路程式設計卷1），這兩本書公認是Unix網路程式設計的聖經。

至於第三個層面，UNP的書中有所提及，也有著名的C10K問題，業界也有各種各樣的框架和解決方案，本人才疏學淺，在這裡就不一一敷述。

本文的重點在於第二個層面，主要總結一下Linux下TCP/IP網路程式設計中的read/write系統呼叫的行為，知識來源於自己網路程式設計的粗淺經驗和對《Unix網路程式設計卷1》相關章節的總結。由於本人接觸Linux下網路程式設計時間不長，錯誤和疏漏再所難免，望看官不吝賜教。

一. read/write的語義：為什麼會阻塞？

先從write說起：

#include <unistd.h>
ssize_t write(int fd, const void *buf, size_t count);

首先，write成功返回，只是buf中的資料被複制到了kernel中的TCP傳送緩衝區。至於資料什麼時候被髮往網路，什麼時候被對方主機接收，什麼時候被對方程序讀取，系統呼叫層面不會給予任何保證和通知。

write在什麼情況下會阻塞？當kernel的該socket的傳送緩衝區已滿時。對於每個socket，擁有自己的send buffer和receive buffer。從Linux 2.6開始，兩個緩衝區大小都由系統來自動調節（autotuning），但一般在default和max之間浮動。

# 獲取socket的傳送/接受緩衝區的大小：（後面的值是在我在Linux 2.6.38 x86_64上測試的結果）

sysctl net.core.wmem_default       #126976
sysctl net.core.wmem_max　　　　    #131071
sysctl net.core.wmem_default       #126976
sysctl net.core.wmem_max           #131071

已經發送到網路的資料依然需要暫存在send buffer中，只有收到對方的ack後，kernel才從buffer中清除這一部分資料，為後續傳送資料騰出空間。接收端將收到的資料暫存在receive buffer中，自動進行確認。但如果socket所在的程序不及時將資料從receive buffer中取出，最終導致receive buffer填滿，由於TCP的滑動視窗和擁塞控制，接收端會阻止傳送端向其傳送資料。這些控制皆發生在TCP/IP棧中，對應用程式是透明的，應用程式繼續傳送資料，最終導致send buffer填滿，write呼叫阻塞。

一般來說，由於接收端程序從socket讀資料的速度跟不上傳送端程序向socket寫資料的速度，最終導致傳送端write呼叫阻塞。

而read呼叫的行為相對容易理解，從socket的receive buffer中拷貝資料到應用程式的buffer中。read呼叫阻塞，通常是傳送端的資料沒有到達。

二. blocking（預設）和nonblock模式下read/write行為的區別：

將socket fd設定為nonblock（非阻塞）是在伺服器程式設計中常見的做法，採用blocking IO併為每一個client建立一個執行緒的模式開銷巨大且可擴充套件性不佳（帶來大量的切換開銷），更為通用的做法是採用執行緒池+Nonblock I/O+Multiplexing（select/poll，以及Linux上特有的epoll）。

幾個重要的結論：

1. read總是在接收緩衝區有資料時立即返回，而不是等到給定的read buffer填滿時返回。

只有當receive buffer為空時，blocking模式才會等待，而nonblock模式下會立即返回-1（errno = EAGAIN或EWOULDBLOCK）

2. blocking的write只有在緩衝區足以放下整個buffer時才返回（與blocking read並不相同）

nonblock write則是返回能夠放下的位元組數，之後呼叫則返回-1（errno = EAGAIN或EWOULDBLOCK）

 對於blocking的write有個特例：當write正阻塞等待時對面關閉了socket，則write則會立即將剩餘緩衝區填滿並返回所寫的位元組數，再次呼叫則write失敗（connection reset by peer），這正是下個小節要提到的：

三. read/write對連線異常的反饋行為：

對應用程式來說，與另一程序的TCP通訊其實是完全非同步的過程：

1. 我並不知道對面什麼時候、能否收到我的資料

2. 我不知道什麼時候能夠收到對面的資料

3. 我不知道什麼時候通訊結束（主動退出或是異常退出、機器故障、網路故障等等）

對於1和2，採用write() -> read() -> write() -> read() ->...的序列，通過blocking read或者nonblock read+輪詢的方式，應用程式基於可以保證正確的處理流程。

對於3，kernel將這些事件的“通知”通過read/write的結果返回給應用層。

假設A機器上的一個程序a正在和B機器上的程序b通訊：某一時刻a正阻塞在socket的read呼叫上（或者在nonblock下輪詢socket）

當b程序終止時，無論應用程式是否顯式關閉了socket（OS會負責在程序結束時關閉所有的檔案描述符，對於socket，則會發送一個FIN包到對面）。

”同步通知“：程序a對已經收到FIN的socket呼叫read，如果已經讀完了receive buffer的剩餘位元組，則會返回EOF:0

”非同步通知“：如果程序a正阻塞在read呼叫上（前面已經提到，此時receive buffer一定為空，因為read在receive buffer有內容時就會返回），則read呼叫立即返回EOF，程序a被喚醒。

socket在收到FIN後，雖然呼叫read會返回EOF，但程序a依然可以其呼叫write，因為根據TCP協議，收到對方的FIN包只意味著對方不會再發送任何訊息。 在一個雙方正常關閉的流程中，收到FIN包的一端將剩餘資料傳送給對面（通過一次或多次write），然後關閉socket。

但是事情遠遠沒有想象中簡單。優雅地（gracefully)關閉一個TCP連線，不僅僅需要雙方的應用程式遵守約定，中間還不能出任何差錯。

假如b程序是異常終止的，傳送FIN包是OS代勞的，b程序已經不復存在，當機器再次收到該socket的訊息時，會迴應RST（因為擁有該socket的程序已經終止）。a程序對收到RST的socket呼叫write時，作業系統會給a程序傳送SIGPIPE，預設處理動作是終止程序，知道你的程序為什麼毫無徵兆地死亡了吧：）

from 《Unix Network programming, vol1》 3rd Edition：

"It is okay to write to a socket that has received a FIN, but it is an error to write to a socket that has received an RST."

通過以上的敘述，核心通過socket的read/write將雙方的連線異常通知到應用層，雖然很不直觀，似乎也夠用。

這裡說一句題外話：

不知道有沒有同學會和我有一樣的感慨：在寫TCP/IP通訊時，似乎沒怎麼考慮連線的終止或錯誤，只是在read/write錯誤返回時關閉socket，程式似乎也能正常執行，但某些情況下總是會出奇怪的問題。想完美處理各種錯誤，卻發現怎麼也做不對。

原因之一是：socket（或者說TCP/IP棧本身）對錯誤的反饋能力是有限的。

考慮這樣的錯誤情況：

不同於b程序退出（此時OS會負責為所有開啟的socket傳送FIN包），當B機器的OS崩潰（注意不同於人為關機，因為關機時所有程序的退出動作依然能夠得到保證）/主機斷電/網路不可達時，a程序根本不會收到FIN包作為連線終止的提示。

如果a程序阻塞在read上，那麼結果只能是永遠的等待。

如果a程序先write然後阻塞在read，由於收不到B機器TCP/IP棧的ack，TCP會持續重傳12次（時間跨度大約為9分鐘），然後在阻塞的read呼叫上返回錯誤：ETIMEDOUT/EHOSTUNREACH/ENETUNREACH

假如B機器恰好在某個時候恢復和A機器的通路，並收到a某個重傳的pack，因為不能識別所以會返回一個RST，此時a程序上阻塞的read呼叫會返回錯誤ECONNREST

恩，socket對這些錯誤還是有一定的反饋能力的，前提是在對面不可達時你依然做了一次write呼叫，而不是輪詢或是阻塞在read上，那麼總是會在重傳的週期內檢測出錯誤。如果沒有那次write呼叫，應用層永遠不會收到連線錯誤的通知。

write的錯誤最終通過read來通知應用層，有點陰差陽錯？

四. 還需要做什麼?

至此，我們知道了僅僅通過read/write來檢測異常情況是不靠譜的，還需要一些額外的工作：

1. 使用TCP的KEEPALIVE功能？

cat /proc/sys/net/ipv4/tcp_keepalive_time
7200

cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75

cat /proc/sys/net/ipv4/tcp_keepalive_probes
9

以上引數的大致意思是：keepalive routine每2小時（7200秒）啟動一次，傳送第一個probe（探測包），如果在75秒內沒有收到對方應答則重發probe，當連續9個probe沒有被應答時，認為連線已斷。（此時read呼叫應該能夠返回錯誤，待測試）

但在我印象中keepalive不太好用，預設的時間間隔太長，又是整個TCP/IP棧的全域性引數：修改會影響其他程序，Linux的下似乎可以修改per socket的keepalive引數？（希望有使用經驗的人能夠指點一下），但是這些方法不是portable的。

2. 進行應用層的心跳

嚴格的網路程式中，應用層的心跳協議是必不可少的。雖然比TCP自帶的keep alive要麻煩不少（怎樣正確地實現應用層的心跳，我或許會用一篇專門的文章來談一談），但有其最大的優點：可控。

當然，也可以簡單一點，針對連線做timeout，關閉一段時間沒有通訊的”空閒“連線。這裡可以參考一篇文章：

參考資料：

《TCP/IP Illustrated, vol 1》 by Richard Stevens

《Unix Network Programming， vol 1》(3rd Edition) by Richard Stevens