蚂蚁网-多维人生，三实而立！

【转】七武士：到底为何而战？

作者：易隐者 发布于：2012-12-13 20:14 Thursday 分类：影音书评

       转好友影评一篇。

【原文全文】：

       饥饿的人总是在不停觅食。一不小心，碰到了黑大师的《七武士》，先看的动漫，看了 9 集，对原作好奇，便找来看看，结果只能感慨：大师就是大师啊 ~ ！又找来影评来看，结果发现十篇里面大概只有两到三篇是原创的，其余皆是抄袭之作，而原创作者有的可能是电影相关专业，写的有点小专业，看不懂呢 ~ ！比较郁闷，这种郁闷就像是一个饿汗吃了一个滋味丰富的东西，却不知道到底吃了啥东西，便想找个人探讨探讨，一起回味回味，结果却找不到这么一个人的感觉一样，不是很尽兴啊！于是，没办法了，只好自己写，自给自足吧 ~ ！

   《七武士》故事大背景：“战国年代，战祸连绵，盗贼趁乱而起，人民受尽蹂躏，惶惶不可终日。”主线故事其实比较简单，一个小山村的农民受山贼欺压，粮食被抢，女人也被抢，穷则思变，狗急跳墙，一个叫利吉的家伙脑子一热，咱杀了山贼，把他们都杀了，就没有人来抢了。当然了，有人反对，咱怎么可能打的过山贼呢？明摆着找死嘛！不要因为自己女人被抢了，不要命了，就拉着我们一起啊！（后半句我加的）有矛盾，找村长，村长最终站在了利吉一边，并且做出了一个更大胆的决定，雇佣武士。于是，故事便这么开始了，几个农民带上大米，去寻找武士，饥饿的武士。七武士依次登场，组队成功，跟农民回村，巩固防御，以待山贼。山贼姗姗来迟，开战。战局结果，七武士以死亡四人的代价，灭了山贼四十骑的团。农民手舞足蹈，武士黯然退场，全剧终。

    看的时候，其实没觉得经典，只是觉得不无聊而已，俺们非电影相关专业的，光影方面的门道啥的完全看不出来，只能看到热闹，所以看的时候在想，也就一般啊，咋就被奉为神作了呢？传说黑泽明在导演本片时是想整成一部完全娱乐性质的影片，就娱乐层面来说，好像不如《笑傲江湖》呢！可看完《七武士》两天后，现在排序的话，果断将武士放在江湖前，江湖看完就看完了，而七武士看完了后，会不自觉的想到一些其他东西。

    一、七武士到底为何而战？

    七武士到底为何而战呢？或者说勘兵卫为啥要接受农民的委托？勘兵卫是个头发花白了的武士，一个看清了世态的武士，一个厌倦了打斗的武士。他在募集其他武士的时候，明确地说明受托的任务是一场毫无益处的战争，而且可能会赔上性命。所以不解了，勘兵卫明知帮助农民杀山贼是对自己来说是一场毫无益处的战争，却为何参战？武士为何会帮助农民？回头看，影片开始时候，作为农民智慧代表的村长似乎给了自己的答案，熊也会因为饥饿而下山的。只是这个答案是经不住推敲的，熊会因为饥饿而下山不假，可是因饥饿而下山的熊怕多半也是会吃人的。按照村长的逻辑来，饥饿的武士应当上山，当山贼（貌似翻译过来的“盗贼”在电影原文里写的是“野武士”）。农民器量的狭小显露无遗，农民的脑袋是参悟不了武士的思想的。影片中，勘兵卫对于农民的请求，从一开始就没有拒绝，只是在思考了一番后，认为要想完成任务，包括自己在内至少需七名武士，除非有好管闲事的武士，不然是办不到的。帮农民杀山贼，用勘兵卫自己的话说，是管闲事。只是这时候勘兵卫是站在当时传统武士的立场来说的，并不是他自己的真实想法。答案在影片中没有直接给出，看来只能自己揣测了。

    于是跳出电影，看下影片的拍摄时间， 1954 年，对日本的历史不是很了解，只是印象中记得有人描述是，“战后的日本，百废待兴，却人心涣散，迫切 需要一个精神支柱…… ”，想象一下，大概是土地上一片废墟，精神上也一片废墟吧。黑泽明是年 44 岁，四年前导出了《罗生门》，已经有相当名气。没看过《罗生门》，搜了下影评，了解到大概是反映人性丑恶的，且刻画的极为深刻，虽然在西方大获成功，在日本却首映失败。我想黑泽明在导《罗生门》的时候，是真切地体会到了人性的丑恶，猜想当时的日本社会的社会风气也是道德沦丧，或许跟今天我们身处的环境有点类似。《罗生门》在国内首映失败，黑泽明一定是进行过反思的，指出丑恶，并没有什么太大意义，只会让沦丧的道德更加沉沦。日本需要的是积极的力量，需要的是建设性力量，而不是批判，在一片废墟上批判废墟，没有任何意义。而反思的成果，便是《七武士》，这部在日本权威电影杂志《电影旬报》选出的二十世纪百佳日本片中排名第一的作品。将电影里人物身上的诸如农民、武士、山贼等身份标签撕掉，而将其代表的人格抽出，有没有种感觉，他们一直就活在我们身边，(省略XX字）。黑泽明借《七武士》向有识之士发出了组队邀请，让我们一起战斗吧！为了什么？大概是为了让社会朝好的方向发展。对自己有什么好处？什么好处也没有。那为什么要去战斗？因为是有识之士。黑泽明借七武士之名，重新诠释了武士精神，（不展开鸟，太麻烦）。新时代的武士已经不必再去依附潘主，或者其他任何势力，新时代的武士应该是独立的，只需遵从最纯粹的善（姑且用这个词吧）的指引；新时代的武士却又是最团结的，因为他们皆是善的信徒；新时代的武士还将是日益壮大的，总有一天，我们身边的每个人都是武士。所以，以武士之名，我们一起去战斗吧！纵使我们会失败，我们一无所得 ~

    二、对武士旗帜的望形生义，直接将自己秒杀。

       七武士到达村子后，准备防御工事闲暇时。平八做了面旗帜，上面的图案是六个圆圈、一个三角形、一个田字，平八解释说，田字代表农民，也是这个山村。菊千代问，那圆圈呢？圆圈代表我们，平八用手指画了一圈。看到这里，我脑子里的第一反应是：六个圆圈代表六个队员，三角形无疑是队长了。可听完平八的解释，我郁闷了，那个三角形代表的居然是菊千代。这算个啥啊？难道不该是一个三角形领导六个圆圈共创建村大业么？唉，没品的黑泽明 ~

       在平八解释的基础上，重新解读。圆圈代表武士，田字代表土地，三角形代表农民出身的准武士。做适当联想与延伸，田字代表土地，代表实业；三角形代表农民出身的准武士，代表思想进步的实业者，三角形同时代表向上的方向，代表趋势；圆圈代表武士，代表品行完美的人。武士旗帜传达的价值观与期望仿佛可以解读成：要务实，土地（实业）是立身之根本，成长于这片土地上的人，都应当好好地耕耘脚下的土地（发展实业）；生长在这片土地上的人，同时应当在思想上不断追求进步，努力会成为品行完美的人，成为新时代的武士；美好的期望是，繁荣的土地上，生活着一群品行完美的人。

 

阅读全文>>

标签: 七武士 黑泽明

评论(1) 引用(0) 浏览(6591)

糟糕的业务网络行为

作者：易隐者 发布于：2012-12-11 15:40 Tuesday 分类：网络分析

       我之前在讲解业务应用分析评估时，重点分析业务应用的网络行为特征、业务基线、响应时间等内容。很多人认为：我的业务应用操作我们自己都是非常熟悉的，为什么还要这么复杂的来分析业务应用的网络行为呢？这是因为业务应用系统在开发的时候，由于各种原因，可能导致业务应用本身在交互的过程中，存在一些不合理的网络行为，进而影响业务运行的效率，造成网络资源的消耗和浪费。我们对业务应用系统进行网络交互行为的分析和评估，可以发现这些不合理的网络行为，帮助改进完善业务应用系统，提高业务应用交互的效率。

       近日正好在Laura Chappell的网站上下载了一个应用异常网络行为的数据包文件，这是一个FTP登录交互的报文，其交互过程如下： 

       客户端与服务器三次握手建立TCP连接之后，服务器端应用响应：220 FTP Service ，此时客户端发出应用请求“USER  FRED”，但我们可以清晰的看到其请求过程是：先将第一个字符发送过去，在收到服务器的确认之后，客户端再传输第二个字符，如此一个字符一个字符的传输。

       在后续的客户端密码传输过程中，客户端的网络行为跟传输用户名的网络行为一样。如下图所示： 

       服务器与客户端之间几十毫秒的RTT往返时间，加上客户端本身动辄数百毫秒甚至几秒的延时，造成整个FTP登录过程持续近14秒，如下图所示：

        我们再来一起看一个正常的FTP登录过程： 

       从这个FTP登录的过程我们可以清晰的看到，FTP客户端是将用户名、密码放在一个报文中一次性传送给服务器的。

       一个最为常见的FTP应用，一个最为普通的登录操作，正常情况下，数秒内完成，但是由于这个FTP应用不合理的网络行为，共消耗了近14秒的时间。

       什么是糟糕的应用网络行为？这个就是！为什么需要分析评估业务应用的网络行为特征，这个就是明证！

阅读全文>>

标签: FTP 行为特征 网络行为 应用分析 RTT 业务评估 往返时间

评论(0) 引用(0) 浏览(6198)

可能的URL超长导致丢包案例

作者：易隐者 发布于：2012-12-10 14:03 Monday 分类：案例讨论

       上周五，有网友兄弟给我发了一个报文，让我帮忙查看是否存在什么异常问题。我查看其TCP会话交互过程，如下图所示： 

       单从这个报文交互来看，客户端与服务器的TCP连接建立正常，客户端已经向服务器发送过get请求，并得到了服务器的确认，问题出在客户端向服务器发送的第二个get请求：“
http://192.168.0.12/Default_Login.aspxusercode=x6x9&password=81xx9xxx52x04xx20036xxx8313xx055&

MyCurrentCompany=&rdnum=0.5966797953405811”。

       客户端发出这个get请求之后，在37秒的时间内重传了5次，服务器端无应用数据需要主动的发给客户端，因此在这个时间段内我们未见来自于服务器的报文，而如果客户端的发送的这个get请求到达了服务器端，则服务器会根据其请求内容作出应用响应，最起码服务器端会对客户端的TCP报文发送ACK确认。但是这些都没有出现，这能够说明客户端的get请求报文根本未到达服务器端，即客户端的这个get请求报文被中间设备丢弃了，我们查看客户端的发送的第二个get请求报文的解码：

       我们发现这个报文除了其请求的URL长度较长（420字节）外，其他似乎也没什么特别的，因此，个人推测其被中间设备丢弃的原因可能是其URL超出了防火墙/负载均衡/WAF/IPS等设备的限制，或者是URL中包含“uesr”、“password”等敏感字段而被中间设备丢弃了。

阅读全文>>

标签: TCP 负载均衡 解码 ACK确认 防火墙 IPS get URL超长 get请求

评论(3) 引用(0) 浏览(6537)

TCP确认机制异常案例

作者：易隐者 发布于：2012-12-8 15:06 Saturday 分类：案例讨论

缘起
        一个好友通过Sina微博转发了一个兄弟的问题给我，其问题如下：
“AB机器tcp，A发送100字节给B，B返回数据但是其ACK=1，这期间A均正确ACK B的所有序列号，B置FIN位，A发 FIN+ACK 给B，此后B返回的ACK=2，那么此时A是应该重传之前的99字节，还是直接重传之前的FIN+ACK包给B？”。

       通过这样的描述我认为这在实际环境中应该不会存在，结果这个兄弟告诉我是在实际环境中发生的，并将交互的报文传一份给我。

       好奇之余，对这个报文进行了仔细的分析，接下来跟我一起来看一下整个分析的过程。

分析产生这个交互的原因

       选取其中一个TCP会话，查看其具体的报文交互情况，如下图所示： 

       这个报文交互的情况截图结合下面的TCP交互流图一起，看起来更清晰一些：

        通过交互报文的解码，我们可以清晰的看到，服务器192.168.104.229已经对客户端发送的get请求作出了应用层的响应，如下图所示：

       其响应为：HTTP/1.0 403 Forbdden
       但是其ACK号却为1，接收并处理了客户端的应用请求报文，但却并未对其进行确认，这充分证明服务器192.168.114.229的TCP确认机制出现了异常！

       我们再来一起看看客户端主动发送FIN报文之后的交互情况：
 
       客户端在发送FIN报文之后，服务器的ACK号变为2，这对于客户端来说，这是对其应用字段的确认，这说明服务器端仅收到客户端1字节的应用字段，因此客户端将剩下的303字节的应用字段放在FIN报文中一起发给服务器端，而服务器在收到这个报文后，回应客户端的ACK号变为3，客户端接着将剩下的302字节的应用字段放在FIN报文中再次重传给服务器端，如此反复。
       至此，我们已经能够意识到，服务器端的ACK确认并不是针对客户端的应用字段的，而是针对客户端的FIN报文的，服务器的确认机制出现了异常，服务器不再确认客户端的应用字段，而只确认客户端的SYN报文和FIN报文。

分析结论

       此问题产生的原因为：服务器的TCP确认机制出现异常，其只确认SYN报文和FIN报文而不对应用数据进行确认。

       另外，我们还留意到一个有意思的现象：正常情况下，端系统一般都会在发送的数据段获得对端确认之后，才会主动发送FIN报文，释放TCP连接，如果在多次重传之后仍未得到对端的确认，通常会向对端发送RST报文，异常释放TCP连接，但是此处可能为了提高交互的效率，客户端与服务器在发送的数据段未收到对端的确认报文就主动发送FIN报文释放TCP连接。

阅读全文>>

标签: TCP SYN FIN ACK TCP确认机制

评论(0) 引用(0) 浏览(7687)

由TCP保活引起的业务访问故障案例

作者：易隐者 发布于：2012-12-7 15:18 Friday 分类：网络分析

1 故障环境

1.1  故障拓扑

       故障发生的网络拓扑结构如下图所示： 

1.2  业务报文交互路径

1，客户端通过网闸映射地址218.X.X.151访问内部业务服务器10.X.X.209；
2，客户端经过网闸后，源地址变为网闸内口地址10.X.X.160访问真实的业务服务器。

2  故障现象

       故障现象主要表现为：
 客户端访问业务服务器出现中断现象，并且故障基本都发生是在夜间12点以后；
 第二天重启网闸后，业务访问恢复正常，但是到夜间12点左右业务连接会再次中断；
 在业务访问出现中断以后，偶尔会不定时的可以成功进行连接，但是持续时间不长就再次中断；
 仅此业务应用存在这个异常，其他的业务基本正常。

3 故障分析

3.1 分析思路

       考虑到故障都发生在夜间12点左右，因此在网闸内外网口同时部署网络分析产品，对内外网口交互的报文进行长时间的捕获存储，第二天，我们分别选取故障发生时间内的报文进行关联分析和对比分析。

3.2 分析过程

3.2.1 异常出现时，网闸外口的报文交互情况
       我们选取故障发生时，网闸外网口的交互报文进行查看，我们在“TCP会话”视图中，发现了大量交互报文少、流量小、收发报文特征明显的TCP会话，如下图所示： 

       我们选取其中任意一个TCP会话，查看其详细的报文交互情况，如下图所示： 

       我们可以清楚地看到，客户端与服务器映射的外网地址通过三次握手建立TCP连接之后，服务器映射地址立即向客户端发送了FIN报文，主动释放TCP连接，后续的带有应用字段的客户端报文到达后，服务器直接向客户端回应RST报文。
       我们查看了其他的TCP会话的详细报文交互情况，基本与上述情况一样。由此来看，似乎是网闸主动发送FIN报文导致了业务应用出现异常，网闸为什么会在已经建立三次握手之后立即主动发送FIN报文呢？难道是服务器主动发送的FIN报文？或者是网闸的BUG导致网闸主动发送FIN报文？我们需要在内网端做个关联对比分析才能确定。

3.2.2 在网闸内口发现保活报文
       当我们取故障时内网的报文时，发现内网在做捕包存储时出现异常，抓包工具在故障出现之前崩溃了，并未将故障发生时的网闸内口报文捕获保存下来，而由于时间紧急，我们没有机会再花费一天的时间去捕获内网的报文，这些故障现场的不确定性现象发生了，我们只能抓取当下的网闸内口报文进行辅助分析。
       我们在网闸内网口抓包发现大量的特征明显的TCP会话，如下图所示：

       这些TCP会话仅有几个报文的交互，不像正常的业务数据交互报文，我们选择其中一个TCP会话查看其具体的交互报文，如下图所示： 

       这是服务器发给客户端的报文，下面是客户端给服务器的报文： 

       结合这两个报文，我们可以肯定，这是一个TCP保活报文。这些仅交互2个报文的TCP会话是服务器发给客户端的TCP保活行为！

3.2.3合理推测
       这些数量众多的保活行为的TCP会话，引起了我们的关注，那么是否是保活行为导致业务应用出现问题呢？保活的功能之一是维持已有TCP连接，关于TCP保活的详尽描述大家可参考我博客的文章《TCP保活（TCP keepalive）》。
       TCP保活的这个特性很自然的让我们想到可能是TCP保活功能引起网闸连接表满从而导致业务异常。但是网闸作为一个网关类设备一般都支持几十万甚至数百万的连接数，在无异常攻击报文的情况下不至于24小时连接表就全部满了，并且也只有这个业务应用出现异常，其他应用都是正常的。
       我们发现外网的客户端访问到内网时，其源地址全部转换为网闸内口地址10.X.X.160，至此我们恍然大悟：源IP、源端口、目的IP、目的端口、协议类型等五元组信息决定一个连接，而在网闸内口，源IP、目的IP、目的端口、协议类型都已经确定，只有源端口是变换的，而端口范围只能在0-65535之间，还要去除一些常用的端口，如此一来，网闸内口跟服务器之间能够建立的TCP连接数只能在65535以内！
       在这种情况下，客户端访问业务服务器的TCP连接在24小时内达到近65535个，从而导致后续的客户端与业务服务器无法正常建立连接，引起业务访问故障。
       至于故障后又能偶尔连接正常但很快再次异常的原因也很好解释，那就是网闸内口在维护如此众多的连接时，总会由于各种原因导致几个连接异常释放，如此一来则紧接着的业务访问连接会正常建立，但是一旦用完为数不多的几个连接后，后续的业务连接将再次出现异常。
       整个交互过程涉及到的客户端、网闸外口、网闸内口、服务器的状态变化如下图所示： 

3.2.4验证
       我们建议用户在下班后手动清空网闸内口已有连接，观察夜间12点故障是否出现来验证我们的推测。后经用户反馈，在清空连接后夜间12点左右故障未再现，如此充分证明我们上述的推测是正确的。

3.3 分析结论

       服务器端设置了TCP保活功能，对所有的TCP连接主动实行TCP保活探测，这导致网闸内口与服务器建立的TCP连接无法得到释放，在24小时以内，TCP连接数接近65535个，而此时客户端再次发起与服务器之间的业务连接之后，网闸内口已经无法再与服务器新建TCP连接，如此导致业务连接无法建立。

4 故障解决

       在找到导致此业务故障的真正原因之后，我们就可以对症下药，通过任意选择如下几种方式之一来彻底解决这个故障：
1， 可以在服务器上关闭TCP保活功能；
2， 在网闸内口关闭源地址转换（SNAT）功能；
3， 将网闸内口TCP连接释放时间调整至小于服务器发送TCP保活的间隔时间，这样可以在服务器发送保活报文之前，让网闸内口提前释放该连接；
4， 网闸内口使用TCP连接复用功能，让大部分的外网客户端访问连接仅通过少量的内部连接实现正常的业务交互，而服务器则可以与网闸内口之间少量连接保持保活。

阅读全文>>

标签: 疑难故障 五元组 连接表 TCP保活 TCP keepalive 连接复用 网闸 SNAT

评论(0) 引用(0) 浏览(6477)