帐前卒专栏

前几天在研究 http keepalive，使用pipeline的方式。结果发现server端只能接收到100个请求。必须断开连接后才能继续发送更多的请求。

问题…问题出在哪里？

1. 路由和中间节点

2. nginx

3. web服务器

4. 程序写bug了

第一个“中间路由和节点”很好排除。只要把程序放在和nginx 同一台机器上就可以了。

第二个“nginx”,这个把nginx的log打开，看看收到多少个请求。
第三个"web服务器"，这个也好排除，只要把web服务器的log打开，打印一下就好了。

第四个那就是使用client访问时，用wireshark抓个包。看看第100个请求和101个请求到底有什么不同。

结果1，2，4都被排除了。只有nginx的问题。关键是没有做什么特殊设置。到底为什么只能收100个呢？扫了一下源代码，发现 keepalive_requests这个值被设置为了100，大于这个数值nginx就会发送RST包回来。和wireshark中看到的server端发送RST包的现象一致。然后改动了该值为1000，发现pipeline的请求就可以发送1000个了。

另外这个100值，不知道是nginx看了tomcat,还是tomcat抄袭了nginx。反正这个设置出奇的诡异。

最近开始关注安全问题。 同时也在关注由于关注了安全导致的性能问题。

第一件事是 微信收藏。 详细的内容点击： 微信公众平台的安全问题。 另外再原文的基础上补充几点：微信公众平台最不安全的地方就是它的内容是通过http方式传输的。只要能抓到包，内容都很容易知道。关键问题就是非常不容易抓到包。所以微信平台才不使用Https传输。而不使用https传输的第二个原因是因为 https ssl密钥交换协议很耗时。第三个原因，强求第三方内容供应商提供https支持的话，第三方供应商需要申请相应的域名证书，然后还需要配置，非常繁琐。所以微信客户端传输到微信服务器走的是https,而微信服务器到第三方服务器走的是http.

第二件事是 https 传输时需要注意 连接重用和密钥重用。 http connection能开重用就重用吧。另外同时找到了windows 库中connection虽然重用，但是new request仍然不断的和server交换ssl密钥的问题。详见 这篇blog（winInet对于https保持keep alive需要注意的地方） 。大意就是HttpOpenRequest 这个函数中需要去掉INTERNET_FLAG_IGNORE_CERT_CN_INVALID这个 Flag，然后需要添加OnWinInetError代码。如果证书出错（ERROR_INTERNET_INVALID_CA），那么就重新试一次。这样就可以保证INTERNET_FLAG_KEEP_CONNECTION。

第三件事是 https的请求中夹杂着http请求的问题。这个问题在FireFox 23.0.1中出现。其他各个浏览器都是成功的。详细原因在： 火狐混合内容拦截 。也就是说如果是https的页面，里面的任何请求都需要是Https的。否则请求是不能发送出去的。而在chrome下，显示的就是此网页包含不安全的内容 。该问题在IE10下面，会在最下面弹出一个小tab，问你是否继续。

0. 我在开发中

    近期一直在利用有道云笔记API在微信上开发一款应用。因为是服务器端与服务器端的交互。所以有很多安全问题值得考虑。

1. 微信的认证

    微信的认证很简单，标准的认证是这样子的：

    微信这种授权模式相当的山寨，如果只是单纯的靠这种token授权，服务器很容易被攻破。这里需要填写的url必须是使用80端口，而且url中也不能有很特殊的字符。不过token中可以有特殊字符。所以开发者需要尽量将自己的token设的复杂。微信首先认证连接时会将signature,echostr,nonce,timestamp这四个URL参数以GET请求的方式发送过来。数据则以POST请求的方式发送到同样的URL上，并且URL参数变为signature,echostr,nonce。nonce是和请求中的timestamp成对的。也就是说timestamp+nonce是唯一的。所以这里可以防止重放攻击。另外server与server通信之间,timestamp的单位是秒，一般误差也就是分钟级别的。这样可以从另外一个角度防止重放攻击。所以开发者应该在GET,POST请求中都加入这些参数的校验。

昨天调用第三方库的JNI时发现如下问题：

elf file OS ABI invalid

问题出自ldd，先看一下ldd的版本号。使用： ldd --version

这个问题是因为在ldd 为2.12的机器上编译。拿到ldd 为2.5的机器上去运行加载，然后就挂掉了。解决方法就是使用ldd 2.5的机器编译。

JNI的问题一般出自OS不兼容，gcc版本，glibc版本（libc.so.6）,ldd版本( ld-x.xx.so )不一致。

    昨日和老婆大人一起看了致青春这部电影。这个电影总体感觉挺不错的。而我个人的感觉是电影里郑微和老婆大人有几分相似。要说哪几分，应该是暴力的那几分。嗯…

    昔日的同学也各有成绩。每个人或许都少了些过去的狂妄和稚嫩。但总有些值得记忆的往事。这或许就是导演希望告诉我们的。但是无论如何，青春不在，如何重来？所以感情的重新开始…就只能从青春的记忆和自己的臆想里继续了。

    老婆大人说：如果不是赵薇导演的，这部影片应该是没有人去看的。而我认为：如果不是老婆大人打开这个电影，我是绝对不会看的。嗯，就是这样…

很多时候，Mvn中的repository会被墙掉。最简单的做法就是对mvn加入proxy.具体做法是：

 <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.xxx.com</host>
      <port>8080</port>
      <username>yourname</username>
      <password>yourpassword</password>
      <nonProxyHosts>*.yourhost.com | chillyc.info </nonProxyHosts>
    </proxy>

这样可以去掉mvn install中，request retry, request fail的问题。印象中
http://dstovall.org/maven2/这个应该是被墙掉了.

首先mvn这个东西和ant差不多。都是编译工程+打包的东西。 很多开源软件都用。这些开源软件里面有大量的第三方依赖。很可惜，这些第三方依赖很有可能在很多个r
epository中。查找StackOverFlow发现大多回答是这样的：

在conf/setting.xml中写入：

  <mirrors>
    <mirror>
      <id>UK</id>
      <name>UK Central</name>
      <url>http://uk.maven.org/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
  </mirrors>

这样就加入了一个。

  <mirrors>
    <mirror>
      <id>UK</id>
      <name>UK Central</name>
      <url>http://uk.maven.org/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
        <mirror>  
            <id>soap</id>  
            <name>internal nexus repository</name>  
            <url>http://www.soapui.org/repository/maven2</url>
						<mirrorOf>!UK,*</mirrorOf>
        </mirror>
  </mirrors>

这样就加入俩。

这是StackOverflow的解答。那么如果加入三个是否是下面这样：

<mirrors>
    <mirror>
      <id>UK</id>
      <name>UK Central</name>
      <url>http://uk.maven.org/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
        <mirror>  
            <id>soap</id>  
            <name>internal nexus repository</name>  
            <url>http://www.soapui.org/repository/maven2</url>
						<mirrorOf>!UK,*</mirrorOf>
        </mirror>
<mirror>  
            <id>nightlabs</id>  
            <name>internal nexus repository</name>  
            <url>http://dev.nightlabs.org/maven-repository/maven.jahia.org-cache/</url>
						<mirrorOf>!UK,!soap,*</mirrorOf>
        </mirror>  
  </mirrors>

对不起…答案是错误的…

所以三个及以上的做法是这样的：

<mirrors>
    <mirror>
      <id>UK</id>
      <name>UK Central</name>
      <url>http://uk.maven.org/maven2</url>
      <mirrorOf>central</mirrorOf>
    </mirror>
<mirror>  
            <id>nexus-central</id>  
            <name>internal nexus repository</name>  
            <url>http://nexus.corp.com/nexus/content/repositories/public/</url>
						<mirrorOf>central</mirrorOf>
        </mirror>  
        <mirror>  
            <id>soap</id>  
            <name>internal nexus repository</name>  
            <url>http://www.soapui.org/repository/maven2</url>
						<mirrorOf>!UK,central</mirrorOf>
        </mirror>
<mirror>  
            <id>nightlabs</id>  
            <name>internal nexus repository</name>  
            <url>http://dev.nightlabs.org/maven-repository/maven.jahia.org-cache/</url>
						<mirrorOf>!UK,!soap,central</mirrorOf>
        </mirror>  
  </mirrors>

要把改为central,
因为mvn碰到就后边的都不会继续做下去了。虽然apache的官方文档说，只能有一个central,但其实可以有多个加上!mirrorId的central.

#前言

    barchart UDT 最近还是做了些实验。发现在内网中，这个表现实在不怎么样。测试了一下内网字节=32 时间=2ms TTL=60,外网字节=32 时间=27ms TTL=53.这两个环境中UDT表现不好。下面给出一些结论：

#结论

1. 内网基本不丢包的情况下， udt在15-30并发时upload表现较好。

2. 在外网偶发丢包率的情况下， UDT在上传中，多并发（并发数不超过15）表现较为优异，会偶尔高于TCP.

3. TCP 在偶发丢包/不丢包 网络状态下，性能稳定，而且不会有IO异常情况。

4. UDT在偶发丢包情况下，会有连接失败/重传超时后连接断开等情况发生。需要修改代码逻辑保证完整的数据传输。

5. UDT在大多数情况下，传输率不及TCP。

UDT简单介绍

    最近在研究UDT相关的东西。这个主要用于高带宽时延积。也就是适用于网络带宽较高，但是丢包还是比较频繁的网络。给个公式：

    高带宽时延积（缩写）=带宽 * RTT   

    UDT相关的可以在这里找到：http://udt.sourceforge.net 另外对于UDT原版(c++)版，这里有两个下载路径。一个是CVS的。另外一个是git的。

0. 前言

    最近在看Octopress的代码，然后想想可能Octopress要更新了。于是手贱了一下，把整个Octopress重新更新了一下。然后整个blog乱成一团了。所以说千万别更新，更新之前一定要git push保存一下进度。如果真的更新挂了，就再rollback.