“pppoe-client”接口，將“MAX MTU”和“MAX MRU”都設置成“1492” /ip firewall mangle add action=change-mss chain=forward comment=\ "\D0\DE\B8\C4Lan to PPPoe MTU=1472" disabled=no in-interface=lan new-mss=\ 1472 out-interface=pppoe1 passthrough=yes protocol=tcp tcp-flags=syn
網頁斷流，就是說內網TCP傳輸具有時效性，不能保存過久，包一多路由就負擔了，太短就是變連接不上了。游戲的TCP包就不存在這樣的問題，因為游戲包小，時時通信，即使被刷新失效，馬上也會有的。
網頁就不一樣的了，有時候發現網頁打不開，其它都正常這個就叫網頁斷流
網頁斷流幾個關系的問題：
8.1.tracking問題
使用本站提供的，保證無問題，一個SYN推薦大家調高一點點為好
/ ip firewall connection tracking
set enabled=yes tcp-syn-sent-timeout=2m30s tcp-syn-received-timeout=2m30s \
tcp-established-timeout=10h tcp-fin-wait-timeout=2m30s \
tcp-close-wait-timeout=2m30s tcp-last-ack-timeout=2m30s \
tcp-time-wait-timeout=2m30s tcp-close-timeout=30s udp-timeout=2m30s \
udp-stream-timeout=6m icmp-timeout=2m30s generic-timeout=20m \
tcp-syncookie=yes
8.2.防火牆問題 防火牆把TCP3129-3198給禁用了 刪除31XX一系列規則
8.3.Queue Tree 限制線程問題
這里說明下，我們只限制速度，不限制線程數為好
8.4.修改MSS值
最近發現很多關於MSS值的問題。我剛裝上ROS的時候也是遇到這樣的問題（我用的是pppoe-client+NAT方式），主要表現在打開一部分國內網站（比如淘寶）和大部分國外網站（比如yahoo和Microsoft），打開這些網頁的速度慢得出奇，基本上打不開。而其它的就用則沒有什么不正常。開始我也想到了是MSS設置的問題，但是按照很多人說的“將MSS值改成1400、1440、1480等等”都不起作用。最后打到一篇文章，說是DSL方式MTU值默認是“1492”（不是MSS值）。這才解決了問題：
打開winbox，在PPP中選擇你添加的“pppoe-client”接口，將“MAX MTU”和“MAX MRU”都設置成“1492”，然后在“IP－firewall－mangle”中添加一條改變默認MSS值的規則：general選項里：chain:forword;protocol:6(tcp); Advanced選項里面：tcp flags:syn; Action選項里面：action:change mss;New tcp mss:1440 。
MTU，相信大家都很了解的。那么MSS就是屬於MTU中的一部分。MSS=MTU-40。具體的請到百度搜下吧。
網吧，50M電信，200台機器，路由ROS，限速BURST 10M、MAX 2M、TIME 20秒。問題是打開QQ空間時，要等一下才可以。按照速度來算的話，我這網吧的速度已經更快的了，空間應該是瞬間就打開，才是對的。
那么在網速夠快的前提下，打開空間卻慢，這時候第一個想到的就是MTU的問題。舉個簡單的例子：
A機通過B機向C機發送數據，MTU分別為：A-1472、B-1440、C-1400。那么就可以看到了，A-B-C傳輸入數據時，MTU值不同，這時候就要取最小值，因為，要把大包分為小包，進行重組。問題就是在這了。
我們要找到一個合適的MTU值，即將MSS修改成一個合適的值。這個值，我們可以通過PING來獲取：
ping qzone.qq.com -f -l 1500 會返回：Packet needs to be fragmented but DF set.就表明沒有通。繼續
ping qzone.qq.com -f -l 1496 返回：Packet needs to be fragmented but DF set. 再繼續，1500-1496是以每次減4來算的。
我這邊一直到1472才通的。如：
C:\>ping qzone.qq.com -f -l 1472
Pinging qzone.qq.com [58.61.166.85] with 1472 bytes of data:
Reply from 58.61.166.85: bytes=1472 time=41ms TTL=54
Reply from 58.61.166.85: bytes=1472 time=41ms TTL=54
Reply from 58.61.166.85: bytes=1472 time=41ms TTL=54
Reply from 58.61.166.85: bytes=1472 time=41ms TTL=54
Ping statistics for 58.61.166.85:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 41ms, Maximum = 41ms, Average = 41ms
這樣的話，我這邊的MSS值就改為1472。在ROS里添加 IP-FIREWALL-MANGLE
連接追蹤為 nat 地址轉換提供每條 TCP/UDP 連接的轉換狀態跟蹤，提供了連接超時（ timeout）參數， 當在指定的超時時間過后， 相應的條目將會從連接狀態列表中刪除。 下面是 tracking 的配置，在 RouterOS 6.0 后開始新增 FastPath 功能， Enabled 由原來的雙選，變為 auto、 no 和 yes：
屬性描述
count-curent (只讀: 整數) – 在連接狀態列表中記錄的當前連接數
count-max (只讀: 整數) – 取決於總內存量的連接狀態列表，自動計算出最大連接數
enable (yes | no|auto; 默認: auto|yes) –允許或禁止連接追蹤， nat 被使用的情況下必須開啟；根據硬件平台不同，
x86 不具備 Fastpath，默認是 yes，而 RouterBOARD 具備 Fastpath 功能，默認是 auto。
generic-timeout (時間; 默認: 10m) – 連接列表中追蹤既非 TCP 又非 UDP 包的條目的最大時間量將會在看到匹配此
條目最后一個包之后存活
icmp-timeout (時間; 默認: 10s) – 連接追蹤條目將在看到 ICMP 請求后存活最的大時間量
tcp-close-timeout (時間; 默認: 10s) – TCP 連接追蹤條目在看到連接復位請求（ RST）或來自連接釋放初始化機連接
終端請求確認通知（ ACK）之后存活的最大時間
tcp-close-wait-timeout (時間; 默認: 10s) – 當來自應答器的終端請求（ FIN）之后連接追蹤條目存活的最大時間
tcp-established-timeout (時間; 默認: 1d) – 當來自連接初始化機的確認通知后連接追蹤條目存活的最大時間
tcp-fin-wait-timeout (時間; 默認: 10s) – 當來自連接釋放初始化機的連接終端請求（ FIN）后存后連接追蹤條目存活
的最大時間
tcp-syn-received-timeout (時間; 默認: 1m) – 當匹配連接請求（ SYN）之后連接追蹤條目存活的最大時間
tcp-syn-sent-timeout (時間; 默認: 1m) – 當來自連接初始化機的連接請求（ SYN）后連接追蹤條目存活的最大時間
tcp-time-wait-timeout (時間; 默認: 10s) – 當緊隨連接請求（ SYN）的連接終端請求（ FIN）之后或在看到來自連接
釋放初始化機的其他終端請求（ FIN）之后連接追蹤條目存活的最大時間
udp-timeout (時間; 默認: 10s) – 當匹配此條目的最后一個包之后連接追蹤條目存活的最大時間
udp-stream-timeout (時間; 默認: 3m) – 在匹配此連接（連接追蹤條目是確定的）的最后一個包的響應被看到之后連
接追蹤條目存活的最大時間。它用於增加對 H323， VoIP 等連接的超時。