UCweb的任务请求引发的灾难

T^T，早就发现UCweb的问题，发请求后，即使刚发出，选择停止按钮，请求会保存到消息队列(而不是放弃)，在下次发出请求时继续完成前一次请求.今天用手机看blog，点错了删除，前就知道这个，so我是把UC程序退出了，又启动的，谁知还是删了，损失了6000多的累积访客(后来发现是CSDN重新调整了统计，所有人的都少了，哈哈)，100多积分，一旦删除积分不可恢复啊，泪奔啊……

稍作分析，其实在使用中稍作留意的话，会发现很多UC的处理细节。它的请求机制应该就是这么回事，当你发出后，只要不是手机当时网络状况超级差劲那种，你的请求已经无法挽回，谁也救不了你，这种解决方案非常恐怖，会带来非常严重的后果。但UC为何还要使用这种方式呢？

听听我的看法吧。

没有猜错的话，UC有一个请求的消息队列，前一个请求发出后，即使你点击了停止按钮，命令已经发出，已经加入队列，不予以驳回。虽然页面不再继续提交，但是请求会在下次请求发出后继续完成。怎么这么搞，如果我用来买进749的股票500万股，消息刚发出，就听说是同哥他们在搞幕后交易，我想停止，不是该悲剧了？是的，见鬼去吧，你必须悲剧。

别忘了，UC推出时的口号是什么？“最省流量的浏览器”，不错，这就是它的口号，它的存活和发展也是基于这个才来的。毕竟手机上网，流量是金，谁省流量并且有用户体验，谁是王。由此，一批基于缓存页的省流量浏览器诞生了，为了更好的实现这一目标，还设置了中间服务器，也就是说，你的请求(特别是www网页的优化)，会由其服务器进行预读，和图片的处理，减小页面体积后，才发给你，这样会进一步节省流量，中国人伤不起，中国的几家电信龙头也伤不起，谁让他那么贵呢。另外还提供了预读功能(就是预读下一页)，应该是基于URl识别的，因为连续的页面及分页技术的URL都是连续的，也弥补了手机网速慢，加载页面时间长的问题，这么来，那用户体验就上去了。通过技术手段弥补了很多。

可是，亲~，为了节省流量，他也忽略了很多，因为移动互联吧，有它的特殊性，这个特殊性呢，我也不知道是什么，毕竟我不是学通讯的。当你消息刚发出，然后你终止了。但这时，已经有部分请求(数据包)从你的手机飘到了服务器，还有部分数据没有发出；或许它是把发出数据做成了原子操作，即使你terminate了，它还是会默默帮你完成吧，你终止，只是不再等待UC的中间服务器给你回馈，其实这时中间服务器已经在背后代表你的终端在和网页所在的真正服务器继续着任务的进行，而任务一旦进行，就无法停止了，因为你的停止请求还是要通过中间服务器中转的，原来用来加速的提高用户体验的中间服务器现在却成了绊脚石，拦下了你的去路，一走就追不回来了，信息传输，速度太快了。

继续挖掘下去，才意识到，现在所有基于网页的请求都是不可挽回的，数据包一旦发出，追不回来了。QQ里那个你一直想删又不想删的号，一不小心一点，删了，追不回来了。发一条微博，点击发送后，唯一的晚会方式就是发出后重新删除(当然，这都是在网速不扯淡的情况下)。由此可以看出，这并不是UC的错，是整个请求/应答机制存在的问题。恕我过于激动。

为了解决类似问题，不同的服务商提供了不同的解决方案，多数博客系统会提供垃圾箱，删除的文章并不会立即清除。还如Gmail中附带的取消发出的邮件，因为邮件不像短信，是实时接收的，而是存放在服务器信箱里，刚刚发出的话，服务商会给你留个后路。而这样的解决方案又是利用的目标用户对信息使用的延缓性，已经系统对数据处理的延缓性。而此时，对于基于中间服务器的浏览器应用也存在这同样类似的延缓性，因为要经过中间服务器的请求转发处理等，那么我们可不可以做一些类似的某方面的优化呢？从而会有更好的用户体验。留给大家去思考吧。

其实是想发泄一下，哎……没了就没了吧。。。由于个人知识薄弱，错误之处，还望点评指正，谢谢。