tcp连接过多导致服务器崩溃 (tcp设置mss)

问题描述

组网结构:

修改tcp的mss参数,tcp连接过多导致服务器崩溃

用户使用GE0/0/0进行PPPoE拨号上线,上线后反映网页打开较慢。

处理过程

在PPPoE场景出现上网慢的情况时,首先检查设备当前的MTU以及TCP-MSS值。了解一些基本概念:1. MTU(Maxitum Transmission Unit):最大传输单元。EthernetII帧的结构DMAC+SMAC+Type+Data+CRC。

由于以太网传输电气方面的限制,每个以太网帧都有最小的大小64bytes最大不能超过1518bytes,对于小于或者大于这个限制的以太网帧我们都可以视之为错误的数据帧,一般的以太网转发设备会丢弃这些数据帧。(注:小于64Bytes的数据帧一般是由于以太网冲突产生的“碎片”或者线路干扰或者坏的以太网接口产生的,对于大于1518Bytes的数据帧我们一般把它叫做Giant帧,这种一般是由于线路干扰或者坏的以太网口产生)。

由于以太网EthernetII最大的数据帧是1518Bytes,这样,刨去以太网帧的帧头(DMAC目的MAC地址48bit=6Bytes+SMAC源 MAC地址48bit=6Bytes+Type域2bytes)14Bytes和帧尾CRC校验部分4Bytes(这个部门有时候大家也把它叫做 FCS),那么剩下承载上层协议的地方也就是Data域最大就只能有1500Bytes这个值我们就把它称之为MTU。

2. MSS(Maxitum Segment Size):最大分段大小。MSS是TCP协议里面的一个概念。TCP协议在三次握手阶段会协商MSS值,MSS的值决定了每个TCP报文数据段的最大长度。TCP协议一般使用接口MTU来设置MSS的值,如果接口MTU为1500,减去20字节TCP头,20字节IP头,一般MSS取值为1460。如下下图报文。

修改tcp的mss参数,tcp连接过多导致服务器崩溃

当两台远程PC互联的时候,它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端,网络中不同媒介的MTU各不相同,就好比一长段的水管,由不同粗细的水管组成(MTU不同)通过这段水管最大水量就要由中间最细的水管决定。

  对于网络层的上层协议而言对水管粗细不在意,它们认为这个是网络层的事情。网络层IP协议会检查每个从上层协议下来的数据包的大小,并根据本机MTU的大小决定是否作“分片”处理。  分片最大的坏处就是降低了传输性能,本来一次可以搞定的事情,分成多次搞定,所以在网络层更高一层(就是传输层)的实现中往往会对此加以注意!有些高层协议因为某些原因就会要求我这个报文不能分片,我要完整地报文,所以会在IP数据包包头里面加上一个标签:DF(Donot Fragment)。这样当这个IP数据包在一大段网络传输的时候,如果遇到MTU小于IP数据包的情况,转发设备就会根据要求丢弃这个数据包。然后返回一个错误信息给发送者。这样往往会造成某些通讯上的问题。

  对于UDP协议而言,这个协议本身是无连接的协议,对数据包的到达顺序以及是否正确到达不甚关心,所以一般UDP应用对分片没有特殊要求。对于TCP协议而言就不一样了,这个协议是面向连接的协议,对于TCP协议而言它非常在意数据包的到达顺序以及是否传输中有错误发生。所以有些TCP应用对分片有要求---不能分片(DF)。  回到问题的本身,相对于普通以太报文,PPPoE报文多了8字节的PPPoE头,这样就导致了实际的MTU值变小(1500-8=1492),所以在PPPoE应用中MSS取值不能超过(1492-20-20=1452)。如果还有其他应用,比如L3 VPN,IPSEC等,MSS取值还要小一些。

根因

PPPoE场景,IP报文长度大于MTU,同时设置不分片标志(DF),导致设备丢弃报文,造成业务影响,通过调整防火墙mss解决问题。

解决方案

调整防火墙的tcp-mss小于1452。[USG] firewall tcp-mss 1400实际现网使用过程中,并不一定是只有PPPoE场景,当网络中设备有报文长度限制也会碰到调整tcp-mss可以解决上网慢的情况。

出口设备为路由器时参考配置举例:

配置接口GE1/0/0的TCP最大报文段长度为1200字节。<Huawei> system-view[Huawei] interface gigabitethernet 1/0/0[Huawei-GigabitEthernet1/0/0] tcp adjust-mss 1200

注意问题

tcp-mss不正确有可能影响*载下**文件的速度,因为tcp-mss偏大会导致IP包分片,链路上可能存在设备处理性能问题,导致速度变慢,tcp-mss偏小会导致包头开销占比提升,也会影响速度。