某天我想研究一下自己手机上某款软件的登陆认证流程，使用Fiddler代理抓包是一种常用的方法，但我发现当设置了代理之后一直无法正常登陆，Fiddler上的抓包如下：

然后就没有然后了，手机APP上显示无法登陆。

    这里我们先给出解决方案，打开Rules--->Customize Rules，找到OnBeforeResponse函数，一开始它看起来是这样的：

static function OnBeforeResponse(oSession: Session) {    if (m_Hide304s && oSession.responseCode == 304) {        oSession["ui-hide"] = "true";    }｝

    在第一个if后面加上下面这段代码：

if (oSession.oRequest["User-Agent"].IndexOf("MIUI")>-1 && oSession.HTTPMethodIs("CONNECT")){    oSession.oResponse.headers["Connection"] = "Keep-Alive";}

    它的含义是，当Fiddler作为代理对请求进行应答时，如果请求的"User-Agent"中含有“MIUI”字段（原因见上面的截图），且使用的是CONNECT方法时，就将应答首部中的"Connection"字段设置为"Keep-Alive"（通过上面的截图可以看到，登陆失败时回的是"close"）。 

    修改之后果然能够顺利登陆了，下面我们再借助Wireshark把这期间流经网卡的完整数据包都抓下来，分析一下前后两次处理流程上的区别。

    1）先看登陆失败时：

    这种情况下，客户端APP（192.168.31.29）向Fiddler代理服务器（192.168.31.193）发起CONNECT请求，目标Host是account.xiaomi.com，Fiddler代理在建立了与目标Host的连接之后，会向客户端回一条Connection Established的应答，但其中的Connection被设置为close，于是客户端在收到这条应答后关闭了连接，也就没有然后了，导致一直登陆不成功。

    2）登陆成功时的流程：

    这次我们只过滤出从客户端到代理服务器的流量，可以看到当Fiddler代理服务器对CONNECT请求回复了"Keep-Alive"之后，客户端会在这条连接上发送一些加密的数据，这些加密数据就是用来完成登陆流程的。

    keep-alive是在HTTP1.0中引入的扩展，用于进行连接持久化，表明服务器愿意为下一条请求将连接保持在打开状态。HTTP1.1中逐渐停止了对keep-alive连接的支持，而是用一种名为"持久连接"的改进型设计取代了它（但实际上keep-alive仍然受到了客户端和服务器的广泛支持）。HTTP1.1中的这种持久连接默认都是激活的，但像我们在一开始遇到的情况中，Fiddler作为代理服务器直接发送了close，导致客户端直接关闭了连接，无法在该条连接上发送更多的请求了。

    这下你应该已经完全理解了其中的前因后果了吧：）

     周末了，祝大家开心！