提起TCP協議，大多數開發者會想起的有TCP的各種狀態以及之間的轉換過程，對於TCP相關的系統呼叫也能如數家珍。但是如果說TCP網路傳輸究竟有多快，相當一部分開發者就沒有概念了。

當前絕大部分網路應用程式都是使用作業系統核心提供的網路協議棧進行通訊，因為它足夠穩定而高效。但是如果因此就不去了解網路協議棧的設計和實現，那也不能稱得上是一個優秀的開發人員。

就Linux而言，核心提供了完整的TCP/IP網路協議棧。它的表現形式為：

1. 使用核心提供的socket API來進行網路通訊相關的各種操作，與網路通訊相關的各個特性由核心實現，開發者作為使用者只需關心各個介面的作用；

2. 核心來完成各種複雜的處理，最後把使用者的資料傳送給對方，把接收到的對方的資料傳遞給使用者；

3. 核心提供了一系列配置檔案，可以通過調整網路相關的多種配置；

4. 網路的穩定性、高效率由核心來負責等等。

剩下來的，對於開發者來說，就是知道核心提供了哪些功能，以及如何使用這些功能。使用TCP連線進行通訊是絕大多數網路應用程式的實現方式，但是由於IP報文在網路上傳輸可能會丟失，超時，TCP/IP協議為TCP連線設定了超時重傳機制。

具體來說，當核心網路協議棧，對於一條TCP連線上傳送的push包，在很久之後都沒有收到對方的確認時，多久之後會重發這個push包呢？

對於Linux來說，Linux遵循著TCP協議的RFC規範，但是這裡並不想去探討Linux如何確定超時重傳的間隔時長，也不探討背後的依據。這裡只關心本文的目標：如何降低TCP通訊延時。

筆者不喜歡賣圈子，在這裡直接說方法：

1. Linux提供了一個核心引數，把檔案/proc/sys/net/ipv4/tcp_low_latency裡面的數值改為1(當你檢視這個檔案目錄時你也許會驚訝，Linux核心提供了這麼多引數，但是自己知道的卻寥寥無幾，慚愧不？)；

echo "1" >/proc/sys/net/ipv4/tcp_low_latency

2. 使用ip-route命令，把rto_min修改掉(Linux核心協議棧會檢查ip-route配置項，如果沒有配置就使用核心原始碼中的數值即200ms)，命令是：

ip route replace 0.0.0.0/0 via  172.31.223.253 rto_min 30

其中0.0.0.0/0是目標機器(這裡即任何機器)，172.31.223.253是預設閘道器,30就是30ms.