ROS解决网页断流现象 (转)

 

“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
自用MTU

 

网页断流，就是说内网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：

img1913属性描述
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 等连接的超时。

 

posted @ 2018-11-18 11:05  yjig  阅读(3123)  评论(0)  编辑  收藏  举报