在阿里云部署了自己的服务器，一直使用Linode做DNS解析。当初使用Linode的原因是不想去做备案，不过最近遇到了新的问题。
原本Linode的DNS解析速度还是很快的，从没想过访问服务速度缓慢是名称解析的问题。最近两天访问自己的开发服务器以及git服务器非常缓慢，ping值破千ms，在服务器上top看下来，也找不到任何性能问题，满头疑惑。
后来测试支付宝接口的时候，发现原本可以走通的支付宝接口，在成功支付的情况下，支付宝服务器没有给我们调用回调函数，反复查找原因都没有找到。
多种异状结合在一起，终于开始想到，会不会是名称解析的问题。果然，测试代码改用IP而不是域名作为接口后，速度大大加快，支付宝的回调也成功接收到了。更为可观的是，由于测试用例中大量使用域名作为数据库地址，原本10分钟才能跑完的测试用例，现在仅需几秒钟就能完成。
这才意识到名称解析对于提高服务性能的重要性，开始考虑切换到使用国内名称解析了。不想做免费广告，就不提目前试用的是哪家的服务了。总之先试一试，看一看服务的情况如何，再做进一步的考虑。
最近用python写一个简单的爬虫，在模拟网站登录时遇到问题，就是登录后紧跟着302重定向，这时候cookie获取没做好，就会登录失败。
网上找了很多文章，可能是因为python版本不同之类的原因吧，很多方法试了都没用。这里踏破铁鞋找到了可用的方案，记录一下，希望能帮到后来的朋友。
鉴于python的版本浆糊问题，这里声明下，我使用的python版本2.7.3，并且使用的是urllib2库。
解决这个问题，其实说起来很简单，就是要自己定义一个RedirectHandler,在创建opener的时候作为参数放进去。
cj = cookielib.LWPCookieJar()
opener = urllib2.build_opener(MyRedirectHandler,
urllib2.HTTPCookieProcessor(cj))
这里我还要记录cookie信息因此还使用了cookiejar。
现在难点就在于这个RedirectHandler如何重写了。
urllib2.HTTPRedirectHandler.http_error_302(self, req, fp,
code, msg, headers)
通过这样一句调用，默认的redirectHandler已经支持在发现302头部的时候自动跳转到新的location去。但问题是返回的response中缺少了前一个请求返回的cookie信息。因此重点是如何在redirect handle中把前一个请求的cookie设置到新的请求中去。
class MyRedirectHandler(urllib2.HTTPRedirectHandler):
def http_error_302(self, req, fp, code, msg, headers):
setcookie = str(headers["Set-Cookie"])
cookieTokens = ["Domain","Expires", "Path", "Max-Age"]
tokens = setcookie.split(";")
for cookie in tokens:
cookie = cookie.strip()
if cookie.startswith("Expires="):
cookies = cookie.split(",", 2)
if len(cookies) > 2:
cookie = cookies[2]
cookie = cookie.strip()
else :
cookies = cookie.split(",", 1)
if len(cookies) > 1:
cookie = cookies[1]
cookie = cookie.strip()
namevalue = cookie.split("=", 1)
if len(namevalue) > 1:
name = namevalue[0]
value = namevalue[1]
if name not in cookieTokens:
cookiemap[name] = value
newcookie = cookiestring(cookiemap)
req.add_header("Cookie", newcookie)
return urllib2.HTTPRedirectHandler.http_error_302(
self, req, fp, code, msg, headers)
这里我处理cookie使用了比较土的方法手动解析的，各位如果有更好的方法也请不吝赐教。
重点其实就是那一句req.add_header(“Cookie”, newcookie)，这里是从set-cookie中解析出cookie串后拼接成请求头填入req中，在接下来的一句调用默认handle的函数时请求头就会附有新的cookie信息了。
如此处理后的请求，返回后即可从response中读取出cookie信息
response = opener.open(request)
cookies = cj.make_cookies(response, request)
我发现我前两天发的博nslookup-解决ssh隧道无法访问twitter很受大家的欢迎，sjw同学也说到，其实使用OpenDNS就可解决这个问题。
因为我之前尝试过OpenDNS仍然发现问题，才出此下策的，因此专门去研究了一下，发现其实@williamlong有一篇老文，早就可以解决这个问题。OpenDNS不能解决DNS解析错误，而这文的解决方案，比我提出的要简单许多，就是使用远程解析DNS。
关于如何使用远程DNS解析，月光博客提到了firefox的启动参数。至于我所喜爱的chrome，网上的讨论也很多。具体的方法就是使用sock代理和switchy扩展的自动模式(auto switch mode)。当然，正如sjw同学提到的，使用vpn的同学直接使用墙外dns就可以了，有些客户端似乎是默认使用本地dns，可能是需要配置一下的。因为我不用vpn所以不是很了解。
我找到的比较好的参考是这篇chrome 扩展： Proxy Switchy!之图解使用方法和这篇在 Chrome + Switchy 下使用 AutoProxy gfwList PAC这篇正是来自autoproxy的博，下面回复讨论很多，很值得看。而这一篇关于 SOCKS 代理的远端 DNS 解析的讨论则可让我们把一些原理搞得更清楚。
昨天做了这个http://pp.hawkwithwind.net/nslookup.php之后，忽然想到，其实完全可以做一个网页版的命令行，远程控制服务器，其实相当于网页版的ssh了。转念一想，不行，因为那样的话安全性没有保障，等于是把自家后院交给人家随意践踏了。
想到这里，忽然意识到，自己写的那个nslookup.php，其实只是简单的把用户提交的字符串前面加一个"nslookup "然后给系统调用，这样其实是非常危险的。例如我尝试在输入框里面输入twitter.com & whoami，结果除了返回twitter的ip信息，也返回了我在服务器上的用户名。这种可怕的缺陷给黑客太多可趁之机了。立刻修改。
我目前的想法是，字符串里包含后台符号 &，分号 ; ， 管道符号 | ， 重定向符号 > 或者选项符号 – 的时候，就拒绝服务。另外也禁止了字符串内部的空格或者换行符。这样的话，似乎就没有其他的问题了吧？我在这方面不是很熟，估计还会有问题，欢迎黑客及爱好者们赐教～
后来又发现了好多其他可能的符号会导致插入语句。。现在我禁止的符号更多了。。包括大括号{}还有问号冒号等等都被我禁掉了。。
另外，虽然只有几行代码，我把他放到了github上，希望能给大家提供一点帮助～
https://github.com/hawkwithwind/phpNetTools
我最近发现，即使使用ssh隧道，有时也会无法访问twitter, facebook等知名网站，但查询自己的ip地址已经在美国，并且另外一些被墙的网站如blogger等，却又能访问。想到应该是最近GFW的新动作造成的。网上查了查，在google的实时搜索中发现了很多关于最近GFW升级的传闻，很多人抱怨自己ssh或者VPN开始不好用了。
只要能够连上ssh或者vpn，GFW就无法真正对我们造成威胁。仍然无法访问这些网站，极有可能是dns污染造成的。只要能获取到正确的ip地址，就可以访问到对应的网站。然而，网上搜索到的ip地址，往往比较旧，可能已经失效。想要得到最新最正确的dns对应ip地址，最好的方法是通过墙外的主机ping得的ip地址。将其写入自己的hosts文件就好了。
为此，我自己写了一个小小的服务，用美国主机nslookup你想问的域名，给出对应的ip。
pp.hawkwithwind.net/nslookup.php
我还提供了他的api版本，只要使用如下格式的命令，就可得到 json 格式的返回包：
pp.hawkwithwind.net/nslookup.php?server=google.com
返回形式如下
['74.125.224.176', '74.125.224.177', '74.125.224.178', '74.125.224.179', '74.125.224.180']
相信还是蛮有用的。至于原理，非常简单，用php的exec函数执行nslookup命令就可以了。
本科阶段没好好学网络，最近正好做TCP/IP协议栈的项目，7层协议挨个好好研究研究。
今天花了一下午的时间，翻译了维基百科上的以太网帧结构的说明，很有助益。
http://zh.wikipedia.org/wiki/以太网帧格式
说实话，翻译维基百科条目其实挺有意思的。