[转载]HTTP协迁浅析[2016.3.29 sina blog]
2012年7月27日，是四年一度的奥运会开幕式。在伦敦碗的舞台上，一位长者和身旁的老式电脑凝聚了全世界的目光。他发布了一条推特——"This is for everyone"，随即显示在体育馆的大屏幕上，传遍世界。
他就是57岁的Tim Berners-Lee爵士，World Wide Web的发起者，也是第一位实现HTTP的工程师。英国人不但借此传播了开放和分享的互联网精神，也展示了其在IT历史上的地位——从奠定现代计算机基础的Alan Turing，到发明分组交换的Donald Davies，再到网页之父Tim Berners-Lee，每一个重大环节都有英国人的参与。假如北京奥运会上也要推出中国的IT英雄，我想德高望重的方滨兴校长当仁不让。他也可以坐在一排闪烁的防火墙旁边，尝试发一条推特。
Tim所实现的HTTP便是我们今天浏览网页所用的协议。他当年建立的网站至今还能访问，域名为http://info.cern.ch/。虽然这个页面已经更新过，但我们还可以在http://www.w3.org/History/19921103-hypertext/hypertext/WWW/News/9201.html 看到当年的样子。
HTTP的工作方式堪称简单，先由客户机向服务器发起请求，服务器再回复一个响应。根据不同需要，客户机发送的请求会用到不同方法，例如GET, POST, PUT和HEAD等等。比如打开页面时会用到GET方法，而登录网站时则可能用到POST方法。RFC的网站http://www.rfc-editor.org/info/rfc2616比较简单，所以我在打开它时抓了包：
1) 4号包是客户机向服务器发出的"GET /info/rfc2616 HTTP1.1"请求，说白了就是想通过HTTP协议访问/info/rfc2616的内容。
2）7号包是服务器对该请求的响应，即把/info/rfc2616的内容发给客户机。
3）9号包是客户机向服务器发出的“GET /style/rfc-editor.css”请求，就是想获得该页面的格式。
4）11号包是服务器对该请求的响应，把/style/rfc-editor.css的内容发给客户机。
就这样，客户机通过两个GET方法打开了网页。点开每一个HTTP包就能看到其协议头。以4号包为例，它的协议头信息在Wireshark中如下图所示：
其包含的信息大概可以归纳为：我要通过1.1版的HTTP协议从服务器www.rfc-editor.org的/info目录里得到rfc2616的内容。
HTTP算不上一个复杂的协议，出问题的时候也能通过浏览器显示的错误代码来诊断，所以用到Wireshark的状况并不多。不过随着技术的进步，HTTP越来越多地应用到不需要浏览器的场景中，比如现在如火如荼的云存储就是一个例子。由于海量文件不适合传统的目录结构，所以云存储一般使用对象存储技术。也就是说客户机读写文件时并不使用其文件名，而是使用该文件所对应的Object ID。访问时的身份验证也可以通过HTTP来实现。工程师们处理此类问题时就能用上Wireshark了。下图是Wireshark解析后的HTTP读文件过程（只要在Wireshark上右键单击其中一个包，选择“Follow TCP Stream”就可以得到这个窗口）。
我们可以从中看到该文件的Object ID “59J5T5KV78EP0e7AJIV55UO93DVG4140QGQQ000ED7PR8EJH3OGUV”，还有身份验证时用到的用户名“paddy”及其加密后的密码。甚至可以看到服务器回复的文件内容“I am Paddy Lin. I am Paddy Lin……”在这个过程中一旦发生问题，比如身份验证出错了，就能通过Wireshark辅助诊断。
上面两个例子都用到了GET方法，因为它的确是最常见的。事实上HTTP协议最早的版本就只支持GET，Tim开发的第一个网页也是如此。这在今天的开发者看来是小菜一碟，甚至给人一种“时无英雄”的错觉。但如果放眼整个IT历史，现在看起来很了不起的技术都是从简单发展而来的。以云存储为例，底层用到的HTTP和对象存储等技术称不上高级，但组合起来的云概念就是科技前沿了。
用Wireshark来解决问题的确痛快，因为整个通信过程一览无遗。但仔细一想却令人脊背冒汗——如果连文件内容都可以清楚地看到，那我上网时的聊天记录，甚至密码是否也会被发现？答案肯定的，如果没有使用加密软件，黑客（或者你的领导）可以从网络包中看到你上班时聊了些什么，在哪些帖子上祝福楼主好人一生平安，搜索了什么关键词，甚至知道你登录论坛的用户名和密码。
上图是我在Google上搜索时抓的包。从4号包可以看到我用到的关键词 “Max is the best boss in the world”（Max是我老板的名字，希望他此时正在监控我的网络）。如果IT部门把这类包收集起来，就能统计出员工们上班时都在搜索什么。通过IP地址还能查到每一项是谁搜的。
至于更敏感的用户名和密码，这里也有个血淋淋的例子。我在登录www.mshua.net（这是我经常登录的园艺论坛）时抓了包，结果如下图所示。当客户机用POST方法把用户名和密码传给服务器时，已经在网络上暴露了身份——请看下图底部的用户名“wiresharktest”和密码“P@ssw0rd”。
可以想见这个帐号随时可能落入他人手中。事实也是如此，上个月我登录时，就发现几位平时一本正经的网友在发成人图片，显然他们的密码已经被盗了。为了防止好奇的读者用我的帐号浏览不健康信息，我已经把密码改掉了。
那要如何保护自己的信息呢？HTTPS就是一个不错的选择。比如用Google搜索时在http后加个s，变成 https://www.google.com.hk/，就不用担心老板知道你在搜些什么了。
大多数人并不需要理解HTTPS的加密算法，所以本文将不在此多费笔墨（其实是因为作者自己不懂）。但因为HTTPS会给诊断过程带来不少障碍，所以有必要知道如何对它进行解码。下图是4个HTTPS包，我们除了能看到”Application Data Protocol”是http之外，几乎对它们一无所知。所有信息都被加密了，在Wireshark里显示为“Encrypted Application Data”。
要对这些加密包进行解码，需要以下几个步骤（本例所用的网络包和密钥来自http://wiki.wireshark.org/SSL 上的snakeoil2_070531.tgz文件，建议你也下载来试试）：
1． 解压snakeoil2_070531.tgz并记住key文件的位置，比如C:tmprsasnakeoil2.key。
2． 用Wireshark打开rsasnakeoil2.cap。
3． 点击Wireshark的Edit菜单--〉Preferences--〉Protocols--〉SSL--〉RSA keys list。然后按照IPAddress,Port,Protocol,PrivateKey 的格式填好。如下图所示：
4． 点击OK，这些包就成功解码了。下图就是这4个包解码后的样子。
既然HTTPS能被解码，是不是说明它也不安全呢？事实并非如此，因为解码用到的密钥只能在服务器端导出。不同的服务器操作步骤有所不同，比如IIS服务器就可以参考这一篇：http://www.packetech.com/showthread.php?1585-Use-Wireshark-to-Decrypt-HTTPS
你的老板可能潜入Google窃取密钥吗？我相信我老板是做不到的。
