不管是阻塞還是非阻塞模式，send(...)返回的資料長度，只是表示拷貝到協議棧緩衝區中的資料長度，並不是實際傳送的資料量或對方接收的資料量。對於recv(...)，只是從緩衝區中獲取接收到的資料。傳送方先將資料拷貝到協議棧緩衝區，tcp會保證緩衝區中的資料傳送到接收方的緩衝區。至於資料如何可靠的到達，底層協議已經給我們做了很多任務作，上層的應用程式不用考慮。
阻塞與非阻塞，相對於底層協議來說沒有太大的區別（我現在是這麼認為的），如果是阻塞模式，send的時候會將要傳送的資料拷貝到緩衝區中，如果緩衝區的容量無法容納要傳送的資料，就等待緩衝區中的資料傳送，直到緩衝區可以容納資料為止，然後方法返回。而非阻塞模式，如果緩衝區的容量無法容納要傳送的資料，它先把緩衝區真滿，直接返回填入到緩衝區中的資料長度。
一些不錯的文章：
TCP非阻塞accept和非阻塞connect
非阻塞accept 當乙個已完成的連線準備好被accept的時候，select會把監聽socket標記為可讀。因此，如果用select等待外來的連線時，應該不需要把監聽socket設定為非阻塞模式，因為如果select告訴我們連線已經就緒，accept就不應該被阻塞。不過這樣做的時候有乙個bug 當...
阻塞 非阻塞
阻塞和非阻塞指 的是在接收和傳送時是否等待動作完成才返回 舉例 阻塞 block 是指，你撥通某人 的 但是此人不在，於是你拿著 等他回來，其間不能再用 非阻塞 nonblock 是指，你撥通某人 的 但是此人不在，於是你結束通話 待會兒再打。至於到時候他回來沒有，只有打了 才知道。即所謂的 輪詢 ...
阻塞非阻塞
阻塞和非阻塞 阻塞 可用在assign語句和always語句中，表示只要源訊號發生變化，目標訊號就立刻完成賦值操作，在always塊中，結果與語句順序有關，在always塊中是順序關係 非阻塞 只能用在always語句中，表示該語句結束時完成賦值操作，結果與語句順序無關，並行關係 可以這樣理解 阻塞...