加载中…
个人资料
绝世流浪汉
绝世流浪汉
  • 博客等级:
  • 博客积分:0
  • 博客访问:86,140
  • 关注人气:10
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

【互联网运维】内核升级后的一个流量疑难问题解析

(2013-03-11 14:40:42)
标签:

linux

it

mime.types

apache

deflate

分类: 互联网运维技术
系统逻辑构架:
   客户  <------>  公共互联网 <--------> apache  mod proxy (复数台,做负载平衡)  <-----> apache real server (复数台,modperl)(应用程序)

问题现象:
  所做处理:对前端的mod proxy服务器全面升级os,从 fedora8 --> fedora17,内核从2.6.26 升级到3.3.7
  现象:从rrd 的流量监控图上可以看到,每台modproxy服务器返回的流量比fedora8的操作系统多了一倍左右达到将近300mbps,而从互联网上流入的流量则没有任何改变。

问题分析:
   1 首先确认变化和不变的部分:
       1.1  变化最大的是内核(2.2.26到3.3.7),以及部分分发包(fc8到fc17的变化)
       1.2  中间件apache的配置(事后证明这里我们想当然了),aplication程序等没有任何变化;

  2 基于一的判定,我们认为应用层没有做任何改动,所以把主要的检查方向放在了内核中关于tcp/ip中的一些新的功能上。因此我们详细对比了两个内核中tcp/ip实现中的不同机制,比如 cwind从3变到10的变化,比如网卡的offload关闭打开, 比如关闭prr,比如修改tcp的初始rto,......针对其中的每一项我们都做了测试环境并且测试论证,结果都没有大幅改善服务器的返回流量,orz
   虽然修改了cwind到3之后,发现确实重传率有所降低,但是流量依然是原来的几乎两倍左右,因此问题没有得到根本性的解决。

 3 在经历了各种失败的挫折后,我们再次把目光放回到了应用层,通过模对不同内核下同一个内容的wget会话,从获取到的tcpdump的http层内容我们发现了一些问题的端倪。
    3.1 通过查看http的内容,我们发现fc8的下的数据是压缩传输的(tcpdump表现为乱码),而fc17下的数据是没有被是压缩的(直接明文传送),难倒是因为没有被压缩导致回送流量大大增加了?OMG
    3.2 于是进一步查看apache的配置(httpd.conf),由下图可以看到我们对text/css application/x-javascript 类型的文件(css和js文件)进行压缩处理后,再传送给客户端.

 <IfModule deflate_module>
      <FilesMatch "\.(css|js)$">
        BrowserMatch "MSIE" no-gzip
      </FilesMatch>
      AddOutputFilterByType DEFLATE text/css application/x-javascript
    </IfModule>
  
  3.3 那么同样的配置为什么在fc8下面有作用而在fc17下面没有作用呢,我们知道文件类型的确认是由系统或则浏览器按照mime类型来决定的,mime类型的定义则在mime.types文件里定义,确认apache的配置(httpd.conf)

 ## MIME
TypesConfig /etc/mime.types
AddLanguage en .en
AddLanguage ja .ja
AddCharset ISO-8859-1 .iso8859-1 .latin1
AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen
AddCharset ISO-8859-3 .iso8859-3 .latin3
AddCharset ISO-8859-4 .iso8859-4 .latin4
AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru
AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb
AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk
AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb
AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk
AddCharset ISO-2022-JP .iso2022-jp .jis
AddCharset ISO-2022-KR .iso2022-kr .kis
AddCharset ISO-2022-CN .iso2022-cn .cis
AddCharset Big5 .Big5 .big5
AddCharset WINDOWS-1251 .cp-1251 .win-1251
AddCharset CP866 .cp866
AddCharset KOI8-r .koi8-r .koi8-ru
AddCharset KOI8-ru .koi8-uk .ua
AddCharset ISO-10646-UCS-2 .ucs2
AddCharset ISO-10646-UCS-4 .ucs4
AddCharset UTF-8 .utf8
AddCharset GB2312 .gb2312 .gb
AddCharset utf-7 .utf7
AddCharset utf-8 .utf8
AddCharset big5 .big5 .b5
AddCharset EUC-TW .euc-tw
AddCharset EUC-JP .euc-jp
AddCharset EUC-KR .euc-kr
AddCharset shift_jis .sjis
AddType    image/x-icon .ico

由上可见,apache所参照的mime.types文件是在 /etc/mime.types里面
进一步查看mime.types的文件内容

..........省略前面内容.........
application/ipp
application/isup
application/javascript                          js
application/json                                json
.........省略后续内容..........

由此可发现,在mime.types文件里并没有定义application/x-javascript的js类型文件,从而apache无法识别js文件类型为application/x-javascript,导致对js文件不再压缩。 

4 解决方法:
  在apache配置文件的压缩配置部分加上 application/javascript 即可
 <IfModule deflate_module>
      <FilesMatch "\.(css|js)$">
        BrowserMatch "MSIE" no-gzip
      </FilesMatch>
      AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript
    </IfModule>

5 教训
 一个很脸红的事实是,这本来是一个极其简单和基本的应用层问题,却因为我们的自以为是和想当然,错误的埋着头皮,苦苦陷入内核的tcp研究不放,从而导致了大量的无用功。 其实在解决这种类似的问题,应该跳出来看,千万不要思维定势,牢牢记住分层的理念,先从应用层开始一层一层往下剥。

6 一些资料:
  6.1 cwind  http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
  6.2 prr  http://tools.ietf.org/html/draft-mathis-tcpm-proportional-rate-reduction-01
  6.3 inet lro  http://cateee.net/lkddb/web-lkddb/INET_LRO.html
  6.4 rto     http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=9ad7c049f0f79c418e293b1b68cf10d68f54fcdb
 6.6 mime.types  http://ja.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions

                                                      ----edit by andy chou 


  

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有