Fw: [技術] tcp over tcp: 關掉tcp retransmission?

[kdjf (我抓得到什麼呢?)]

※ [本文轉錄自 Network 看板 #1Ghpy3VD ]

剛剛在網路上看文章:
http://sites.inka.de/~W1011/devel/tcp-tcp.html

他提到了這個在tcp over tcp時(ex.ssh port forward/sslvpn/...)會碰到的狀況
剛好和我在無線網路tunneling跑server時會碰到的情形有點像
所有的東西都比沒有tunnel時慢很多
（無線網路是學校的,我不能去設定port forwarding）

所以我在想:有沒有可能吧上面那一層（被tunnel）的retransmission關掉
（OS: linux）

可是linux下只有一個共用的tcp stack設定( /proc/sys/net/ip4/* )
沒有辦法在不同的interface有不同的參數

還有什麼方法嗎？
像是在iptables(netlimiter)中砍掉重複的封包？
如果可以的話,要怎麼做呢？

先謝謝大家看完這麼怪的問題Orz


※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: kdjf (140.112.245.32), 時間: 11/23/2012 17:19:07
※ 編輯: kdjf            來自: 140.112.245.32       (11/23 17:20)
→ kdjf:沒掉封包都很好/一開始掉就崩潰了
→ bitlife:不過看文章是用udp來閃,有沒有可能退化用fix timeout來解
→ bitlife:決？(有沒有這設定項我不清楚)
→ bitlife:fixed timeout
→ kdjf:可是整個系統一起fixed timeout,可能還沒掉封包我就先受不了
→ kdjf:架這個tunnel時,我也會用同一個wlan上網/做別的事
→ kdjf:是說改天先試看fixed timeout好了
→ kdjf:再去看看iptables rule有沒有可能把完全一樣的封包擋掉
→ bitlife:比對封包超耗資源(CPU/RAM),直覺認為不太可能有此項功能
→ kdjf:只是要比對seq/ack/checksum就好了吧  conntrack原本就在做了
→ bitlife:問題是TCP重傳是藉由IP,你不能保證會是同樣的封包,有可能
→ bitlife:是seg1(先前送的)和要新傳送的seg2,一起合併用單一IP送出
→ kdjf:那樣只看一樣的seq/ack呢？是說看了一下conntrack(8)可能只用
→ kdjf:flag去猜status, 而不是分析完整的tcp header
→ bitlife:突然想到你把完全一樣的封包擋掉,假設萬一真的需要重傳,不
→ bitlife:是永遠就卡住了嗎?理論上你沒實作一個完整的tcp(或至少重
→ bitlife:要的部分),很難在ip層只靠簡單的判斷就判斷哪個封包不要
→ kdjf:因為包了兩層TCP,只要有一層會重傳就夠了  不過我原本沒有想
→ kdjf:到封包可能被合並的問題
→ bitlife:iptables不也是全系統共用的嗎?還是你上層有VM?如果你讓
→ bitlife:iptables丟棄重覆的IP封包,豈不連底下那層都不會重傳了?
→ bitlife:我換一個方式重述,iptables和在其之上的tcp模組,在對方送
→ bitlife:來ack之前,兩者都不會知道重傳到底需不需要,只能timeout後
→ bitlife:重傳.所以所謂的'重覆',在收到對方ack之前,都不可能判定一
→ bitlife:不需要,所以光靠比對是否重覆封包不足以判定是否該丟棄
→ bitlife:^定不需要
→ kdjf:上下兩層可以跑不同的interface/user,下面那層跑正常的tcp
→ kdjf:iptables rule只會丟掉上層的retrans. (-i ppp/tap/tun)
→ kdjf:可是我現在在iptables中找不到可用的extension...
→ kdjf:看來離想要的東西有點遠了
u32好像有能力抓出packet.seq, 可是不能存變數
我想要像這樣: (if (packet.seq > latest_seq -10) DROP)
                                ^^^^^^^^^^  不知到要存在哪裡
※ 編輯: kdjf            來自: 140.112.245.32       (11/24 16:36)

突然想到:retransmission不會發生的太快,可以用LAG target把seq抓到userspace
用script去改寫新的rule~
改天要用到tunnel時來試試看好了XDD
如果有成果的話,也許是第一次變成developer?  (逃
※ 編輯: kdjf            來自: 140.112.245.32       (11/24 16:43)
※ 編輯: kdjf            來自: 140.112.245.32       (11/24 16:46)
→ bitlife:我剛發現,有人為了tcp over tcp的問題弄ssh over udp,不過
→ bitlife:略略搜尋下沒有看到有什麼專案
→ kdjf:over udp中間搞個不友善的NAT就掛點了啊QQ