我們先來聊一聊網絡超時的概念。以及模擬網絡超時對我們程序的必要性
要想了解怎樣模擬網絡超時的情況，我們須要先了解一下
為什么會網絡超時呢
簡單的說：就是你向服務端發送數據請求。然爾server沒返回數據，或返回數據太慢導致未收到返回數據。
比方，你要下載一個東東，你向server發送下載這個東東的請求。但等了好長時間都沒有收到server允許你接收下載數據的請求，所以也不能一直這樣等下去。你的電腦就會報告網絡超時。假設不是你的網絡故障，那么就是對方server的問題。
我們知道在TCP建立連接的時候有3次握手的規則
1. client發送’SYN’給服務端
2. 服務端返回確認’SYN_ACK’給client
3. client終於確定’ACK’
在這3次握手的時間內。每一次都有可能網絡會掉包,我們分析一下每一種掉包的情況：
1. SYN丟失第一次握手client發送SYN掉包的情況：這樣的情況下。client發送的SYN丟失在網絡中，沒有得到確認。client的TCP會超時重發SYN。
發送7個SYN后等待一個超時時間（比如：127秒）。假設在這段時間內仍然沒有收到ACK，則connect返回超時。
2. SYN-ACK丟失從client的角度來講曾經面一種情況類似。
從服務端的角度來講，由LISTEN狀態進入SYN_REVD狀態。服務端的TCP會重發SYN-ACK，直到超時。
SYN攻擊正是利用這一原理。攻擊方偽造大量的SYN包發送到server，server對收到的SYN包不斷回應SYN-ACK，直到超時。這會浪費server大量的資源，甚至導致奔潰。對服務端的應用層來講。什么也沒有發生。由於TCP僅僅有在經過3次握手之后才回通知應用層，有新的連接到來。
3. ACK丟失這對服務端來講與2同樣。對於client來講，由SYN_SENT狀態進入了ESTABLISED狀態，即連接成功了。連接成功后client就能夠發送數據了。
但實際上數據是發送不到服務端的（我們如果client收到SYN-ACK之后，client與服務端之間的網絡就斷開了），client發送出去的數據得不到確認。一般重發3次左右就會處於等待ACK的狀態（win7）。而ubuntu 12.10下，調用send會返回成功。直到TCP的緩沖被填滿（測試環境：局域網。感覺這個不是非常合理。依照書上所說：應該是使用“指數退避”進行重傳 -- TCP/IP協議具體解釋，大概是我的測試環境中有NAT所致
吧）。
終於。client產生一個復位信號並終止連接。
返回給應用程序的結果是Connection time out（errno: 110）
好，理解了3次握手掉包的情況下，我們就非常easy實現模擬超時情況的發生。
我們能夠在port上控制服務端無法與client握手成功來讓超時的情況發生
詳細的實現要用到 iptables 這個命令
iptables-A OUTPUT -p tcp -m tcp --tcp-flags SYN SYN --sport 9090 -j DROP
這個命令是用來drop 掉響應SYN的返回
之前我們看到第一次客服端向server請求SYN的握手信息。而這個命令就是阻止server返回SYN_ACK的確認握手信息，這樣client就無法收到服務端的握手確認信息了.
上面這樣的情況是模擬連接沒有成功的情況
以下另一種情況。就是連接已經成功了，可是在數據傳輸的時候，服務端沒有及時返回數據，我們來看看這樣的情況是怎樣模擬的：
iptables -A OUTPUT -p tcp -m tcp --tcp-flags PSH PSH --sport 9090 -j DROP
細心的童鞋會發現，這里用到的flags 是PSH ,對。PSH的意思是控制信息是能夠正常傳送的，也就是說握手是正常成功的，然后數據傳輸的時候，我們限制了server無法給client傳送數據內容，這樣就模擬了連接是成功的。可是無法正常讀取到服務端的數據的超時情況了
上面說的是最簡單手動設置超時的方式，當然還有神器能夠使用，接着就獻上這款神器名叫netem，地址在
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
Network Emulation 有興趣的童鞋能夠前往研究。
Gerry
文章轉自於小張網校博客
http://www.xiaozhangwx.com/blog/archives/73
閱讀原文
轉載於:https://www.cnblogs.com/liguangsunls/p/7210572.html