IP“迴流”，這個詞以前在搞Linux iptables的時候某次聽過，也沒去仔細思考。
之前給公司釋出web服務，網路埠對映給內網伺服器的時候碰到，但未解決（必要性很低）。最近在處理網路訪問內網，內網有跨網訪問專網這些“打洞”事宜的時候，覺得得順便把這問題給解決了。
具體例項如下：
網咖內網一臺主機192.168.0.2建了個WEB服務站點埠80，然後在閘道器(其內網地址是192.168.0.1、公網地址為166.227.96.166)上對映80埠到192.168.0.2的80埠，這樣INTERNET上就能以http://166.227.96.166:80的地址訪問到192.168.0.2的WEB站點了。
然後出現了個問題，在同網咖的另一臺電腦192.168.0.3上，鍵入http://166.227.96.166:80，卻無法訪問該WEB站點。
就這個現象，我們就稱之為“不支援迴流”了，這裡指的是閘道器上的對映方式不支援迴流，所以說“迴流”一說，是針對對映方式而言的。
現在我們來看常規情況下，是為什麼會發生這種情況的
我以前對iptables特別感興趣的時候，曾聽到過這個問題，但沒有深入瞭解。
過程如下：
192.168.0.3要請求訪問166.227.96.166的80埠，根據它掌握的路由表，它本身是不知道電腦166.227.96.166在哪裡的，所以把將這個資料包傳送給它的預設路由，即電腦192.168.0.1。
注意：這個資料包的源地址是192.168.0.3、源埠假設是1025、目標地址是166.227.96.166、目標埠是80、SYN標誌位為1、這是建立TCP連線的第一次握手。
如果“把目標地址為166.227.96.166的資料包發給了192.168.0.1”你聽起來覺得有點矛盾，那麼我解釋一下：其實這個資料包的目標IP地址是166.227.96.166，目標MAC地址卻是192.168.0.1的
電腦192.168.0.1接收到了這份資料包(因為它的身份是路由器，所以允許接收和轉發目標地址不是自已、MAC地址卻是自已介面MAC地址的資料包)，它分析這個資料包的目標地址，發現這個資料包是需要中轉到電腦192.168.0.2:80去的，於是它把這個資料包轉發給了電腦192.168.0.2:80。
電腦192.168.0.2順利接到了資料包，它馬上作出迴應，傳送一個數據包給電腦192.168.0.3。
注意：這個資料包的源地址是192.168.0.2、源埠是80、目標地址192.168.0.3、目標埠為1025、SYN標誌位為1、ACK標誌位為1、這是建立TCP連線的第二次握手。
電腦192.168.0.3順利接到了資料包，然而它發現這是一個來自192.168.0.2:80的迴應，因為ACK標誌位值為1擺在那裡呢。它想不起來什麼時候給192.168.0.2:80這個目標物件傳送過SYN請求，它認為這是一個錯誤的資料包，於是決定把這個資料包丟棄。然後繼續等待166.227.96.166:80的迴應，一直等到超時。
而電腦192.168.0.2這邊，它等192.168.0.3:1025的第三次握手請求包傳送過來，以便建立一個TCP的連線。同樣也沒有結果，一直等到超時。三次握手在規定的時間內沒有完成，訪問宣佈流產了。
IP“迴流”，這個詞以前在搞Linux iptables的時候某次聽過，也沒去仔細思考。
之前給公司釋出web服務，網路埠對映給內網伺服器的時候碰到，但未解決（必要性很低）。最近在處理網路訪問內網，內網有跨網訪問專網這些“打洞”事宜的時候，覺得得順便把這問題給解決了。
具體例項如下：
網咖內網一臺主機192.168.0.2建了個WEB服務站點埠80，然後在閘道器(其內網地址是192.168.0.1、公網地址為166.227.96.166)上對映80埠到192.168.0.2的80埠，這樣INTERNET上就能以http://166.227.96.166:80的地址訪問到192.168.0.2的WEB站點了。
然後出現了個問題，在同網咖的另一臺電腦192.168.0.3上，鍵入http://166.227.96.166:80，卻無法訪問該WEB站點。
就這個現象，我們就稱之為“不支援迴流”了，這裡指的是閘道器上的對映方式不支援迴流，所以說“迴流”一說，是針對對映方式而言的。
現在我們來看常規情況下，是為什麼會發生這種情況的
我以前對iptables特別感興趣的時候，曾聽到過這個問題，但沒有深入瞭解。
過程如下：
192.168.0.3要請求訪問166.227.96.166的80埠，根據它掌握的路由表，它本身是不知道電腦166.227.96.166在哪裡的，所以把將這個資料包傳送給它的預設路由，即電腦192.168.0.1。
注意：這個資料包的源地址是192.168.0.3、源埠假設是1025、目標地址是166.227.96.166、目標埠是80、SYN標誌位為1、這是建立TCP連線的第一次握手。
如果“把目標地址為166.227.96.166的資料包發給了192.168.0.1”你聽起來覺得有點矛盾，那麼我解釋一下：其實這個資料包的目標IP地址是166.227.96.166，目標MAC地址卻是192.168.0.1的
電腦192.168.0.1接收到了這份資料包(因為它的身份是路由器，所以允許接收和轉發目標地址不是自已、MAC地址卻是自已介面MAC地址的資料包)，它分析這個資料包的目標地址，發現這個資料包是需要中轉到電腦192.168.0.2:80去的，於是它把這個資料包轉發給了電腦192.168.0.2:80。
電腦192.168.0.2順利接到了資料包，它馬上作出迴應，傳送一個數據包給電腦192.168.0.3。
注意：這個資料包的源地址是192.168.0.2、源埠是80、目標地址192.168.0.3、目標埠為1025、SYN標誌位為1、ACK標誌位為1、這是建立TCP連線的第二次握手。
電腦192.168.0.3順利接到了資料包，然而它發現這是一個來自192.168.0.2:80的迴應，因為ACK標誌位值為1擺在那裡呢。它想不起來什麼時候給192.168.0.2:80這個目標物件傳送過SYN請求，它認為這是一個錯誤的資料包，於是決定把這個資料包丟棄。然後繼續等待166.227.96.166:80的迴應，一直等到超時。
而電腦192.168.0.2這邊，它等192.168.0.3:1025的第三次握手請求包傳送過來，以便建立一個TCP的連線。同樣也沒有結果，一直等到超時。三次握手在規定的時間內沒有完成，訪問宣佈流產了。