Tcpdump与Wireshark的渊源

1988年春,Steve McCanne在加州大学伯克利分校修完了计算机科学中的编译器课程,当时负责授课的是来自劳伦斯伯克利国家实验室的教授Van Jacobson,这个课程主要讨论了标准编译器的工作原理,包括:词法分析,语法分析,目标代码生成,程序优化等主题。学期末,Steve获得了Van研究小组的暑期实习机会。

不久之后,Steve便成为了由Van领导的“网络研究小组”的正式科研人员。在Steve刚加入这个网络研究小组的时候,Van正致力于TCP拥塞控制方面的研究,他对ARPANET频繁崩溃的机理做出了合理推测,为彻底查明问题,实施有效修复,他需要一个可靠的网络分析工具来进行分析和研究。

起初,Van用的是SunOS平台上的网络分析工具:etherfind,然而,其表现却不尽如人意,复杂的命令格式,令人困惑的协议解析,糟糕的性能,总之,你无法准确高效地看到自己想要的东西,尤其是当LAN中存在大量广播数据包的时候。

在这种情况下,研究工作无法展开,于是,Van放弃了etherfind,进而开发了全新的工具,叫做tcpdump,初期的tcpdump参考了etherfind的部分代码,为避免版权纠纷,Steve ...


lobby game后端架构

大厅是供用户选择游戏对象的场所。图中是大厅的基本形式,左侧的目录树有三个层级:游戏(game)、分区(zone)和房间(room)。每款游戏都会基于某些规则来划分zone和room 。游戏的基本单元是游戏桌,即图中右侧的那些table,当table上“积攒”的玩家数满足要求时,该table上的游戏即可开始。

若要搭建一个大厅系统,后端应该具备一个负责客户登陆的loginsvrd,一个主管各游戏服的lobbysvrd,一个用于访问数据库的dbsvrd ...


逐步实现TCP服务端Step05:分布协作

迄今为止讨论的都是使用单个服务程序对外提供服务的情况。虽然netio和s是两个进程,但它俩其实是分管了一个服务程序的通信和业务逻辑两个部分,这里把它们视为一体。

假设s在处理业务的时候需要访问数据库,等从数据库提出数据后,又要进行复杂的数学运算。此种情况,只有单个线程的s势必会在某些环节因耗时过多,而影响到其他客户的服务受理。

若继续坚持单线程的路线,就必须对s进行拆分。就像当初从s中拆分出netio一样。假设用于访问数据库的进程叫做dbsvr,用于计算的服务叫做calsvr ...


逐步实现TCP服务端Step04-2:处理client断开

当某个client断开连接时,后端系统要做相应的“清理”工作。具体说来就是netio要销毁TCPSocket对象,s要销毁用户对象。

问题在于,client断开连接,s是不知道的,除非netio以某种方式告知它。

可以在c2s_code_queue中push一个特殊的code以表明某个client已经离线了。这样,一旦s取到该code就触发”清理“操作。

这个特殊的code其实不用专门去设计。考虑一下client断开时,TCP的做法是向对端发送一个不携带数据的报文段 ...


SSH客户端"SSH Broken Pipe"问题

SSH客户与服务端建立连接后闲置一段时间,再次使用时出现"SSH Broken Pipe”: 客户端发出数据包后,服务器返回的是RST包:

由于是NAT网络,这种情形可以做如下解释

当客户与服务器建立TCP连接时,NAT设备中会产生一个对应于该连接的Session,NAT利用这个Session来完成内外网IP:Port的转换 ...


逐步实现TCP服务端Step03-15:小结

这是一个里程碑,到目前为止,基本的构件都已实现,为下一步的扩展打下了基础。

所谓的“扩展”是指把对单个客户的服务扩展为对n个客户,目前这个版本只针对一个客户。

再明确一下目标,我们要实现的是一个暂时不关注具体业务的基于TCP连接的后端系统。所谓的“不关注具体业务”,就是说要做的“抽象”一些。它更像是一个骨架,如果需要的话,可以把具体的业务逻辑填充进去 ...