欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

多层架构业务应用场景下的网络分析

作者:易隐者 发布于:2012-11-22 13:06 Thursday 分类:网络分析

       我们在日常工作中,最为常见的网络分析场景为针对简单的C/S或B/S架构的应用的分析,在简单环境中,C/S或B/S架构的应用主要是一层架构的,如下图所示: 

点击查看原图

       在这个架构的应用中,业务的交互仅仅涉及到客户端与服务器,这样的业务交互过程和报文交互路径都非常简单清晰,分析这种架构业务应用的性能问题、故障问题并不存在很大的难度,因为不会涉及过多的中间环节,但是在规模较大、应用较为重要和复杂的环境中,最为常见的是多层架构的业务应用系统。

三层/多层架构应用

       那么什么是多层架构的应用呢?我从网上找了一段文字,应该能够将其说明清楚:“所谓三层架构,是在客户/服务之间加入了一个"中间层",也叫组件层。它与客户层、服务器层共同构成了三层体系。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才有三层体系结构,三层是指逻辑上的三层。通过引入中间层,将复杂的商业逻辑从传统的双层结构(Client-Server)应用模型中分离出来,并提供了可伸缩、易于访问、易于管理的方法,可以将多种应用服务分别封装部署于应用服务器,同时增强了应用程序可用性、安全性、封装复用性、可扩展性和可移置性,使用户在管理上所花费的时间最小化,从而实现了便捷、高效、安全、稳定的企业级系统应用。”

       三层架构主要分为表示层、业务逻辑层、数据访问层三层,每层主要负责的工作如下:

表示层:主要负责从用户收集信息,将用户信息发送到业务服务层做处理,从业务服务层接收处理结果,将结果显示给用户等;
业务逻辑层:主要负责从表示层接收输入,与数据层交互执行已设计的业务,操作(业务逻辑,系统服务等),将处理结果发送到表示层等;
数据访问层:主要负责数据存储,数据获取,数据维护,数据完整性等;

       下图为一个经典三层架构的应用示意图: 

点击查看原图

       在实际工作环境中,最为简单和常见的三层架构的应用为下图所示:

点击查看原图

       在这个架构中,其实是将表示层和业务逻辑层整合在一起,通过应用服务器统一对外提供业务访问界面和业务逻辑处理。
       我们遇到的大型、复杂的应用基本上都是基于多层架构开发的,针对多层架构应用的分析将是以后网络分析工作中无法回避的问题。

分析多层架构应用的难处

       针对多层架构应用的分析,可不像我们平时分析简单一层架构的B/S、C/S应用那样简单,分析多层架构的业务应用主要具有以下几点难度:

1, 业务数据交互路径更为复杂
       一个客户端访问多层架构的业务应用时,其业务数据交互路径一般如下图所示: 

点击查看原图

1, 客户端向Web服务器发送相关业务应用的操作
2, Web服务器将客户端的相关业务操作请求交由应用服务器处理
3, 应用服务器将业务操作涉及到的相关数据请求发往数据库服务器
4, 数据库服务器将相关数据操作结果反馈给应用服务器
5, 应用服务器根据数据库服务器反馈的数据结合业务逻辑,得出相关信息发往Web服务器
6, Web服务器将客户端相关业务操作的反馈数据显示给客户端

       纵观整个交互的过程,我们可以知道同样一个业务操作的交互,多层架构的应用跟简单的一层架构的应用相比,多出了数个中间环节,这导致业务交互路径变得复杂,我们需要在不同的环节分别抓包做关联分析。这些都会增加网络分析的工作量和难度。

2,数据加密问题:数据库加密
       基于数据安全的角度,现在很多涉及到数据库的交互,其在应用层将数据库应用字段加密,如下图所示: 

点击查看原图

       在这种情况下,我们站在网络交互的角度捕获的报文只能够提供三层和四层的相关信息,数据库应用数据信息均无法正常查看,因此我们无法分析到底哪一个报文是某个客户端的业务操作引发的应用服务器对数据库服务器的访问行为,这给我们的分析工作带来了巨大的不便。
       如果真的遇到加密的情况,那么站在网络层面对其报文进行分析已经无能为力了,建议在数据库服务器上站在业务应用的角度,调用其数据库日志进行辅助分析。

3,存在连接复用问题:连接复用
       一般情况下,如果客户端与服务器建立业务交互连接,那么可能涉及到的web服务器、应用服务器、数据库服务器之间都分别新建连接用于相关数据的交互,如下图所示: 

点击查看原图

       但是在这个情况下,一旦客户端的访问的数量非常巨大或者访问峰值时的连接非常巨大,将导致应用服务器与数据库服务器之间的连接数非常大,严重影响数据库服务器的性能,为了解决这种问题,应用服务器在与数据库服务器之间交互时,采用连接复用的方式以节省服务器的资源,提高交互的性能和效率,如下图所示: 

点击查看原图

       在这种方式下,应用服务器与数据库服务器之间只需要建立很少的连接,并将这些连接长期保持(长连接),后续的所有应用服务器与数据库服务器之间的增、删、改、查询等操作均通过已有的数条连接进行应用交互。如此大大降低了应用服务器与数据库服务器之间的连接数。

       连接复用给网络分析带来的问题是,我们不得不在数条连接中查找某个客户端具体操作对应的数据库报文,而每个数据库的连接均包含大量的数据库语句,有些是相近甚至是相同的数据库语句,这些无疑会给网络分析工作带来巨大的工作量和难度,如果同时间访问的客户端数量很多的话,这样的分析工作无异于大海捞针,基本上变得不可行了。

       上述三大难点,给我们分析多层架构的应用带来了非常大的难度,虽然如此,但是好在并不是所有的多层架构应用都是连接复用的,也不是所有的数据库交互都是加密的,如果实际工作中真的遇到了多层架构的应用需要我们进行分析,我们往往没有什么太多的选择余地,我们能做的就是尽己所能、尽力而为了。

多层架构应用的分析

       针对多层架构的业务应用的分析,我们一般按照如下的思路开展网络分析工作:

1, 关键路径多点同时捕包
       要针对多层架构的业务应用进行分析,必须在业务数据交互路径中的每个关键点进行捕包,以便后续的关联分析和对比分析。这个在我的文章《疑难网络故障的分析方法和原理之对比分析法》中介绍得非常清楚,大家可以访问http://www.vants.org/?post=49参考。
       在多层架构的应用中,我们主要需要在客户端与Web服务器之间、Web服务器与应用服务器之间、应用服务器与数据库服务器之间同时进行业务交互报文的猜忌和捕获,如下图所示: 

点击查看原图

2, 捕包机器时间同步
       一般而言,我们可以通过NTP服务器将多台捕包机器的时间同步,但如果在条件不允许的情况下,大家可参考我的文章《如何保证中间设备两端捕获的数据包的时间同步性?》中提供的简单有效的方法来实现不同关键点捕包时间的同步,如下图所示: 

点击查看原图

       在各个关键路径上的捕包机器时间都同步了,那么在大部分的情况下,我们就可以根据连接或报文发生的时间段在海量业务交互报文中提取跟业务操作相关的报文进行关联分析,从而提高关联的分析的效率。

3, 关联分析
       一旦全部准备就绪,那么剩下的工作就是根据不同位置捕获到的业务交互报文,利用应用层字段,如cookie值、sessionID、用户名、帐号、Userid、业务号、单号、ProcessID等关键字实现客户端<->Web服务器、Web服务器<->应用服务器、应用服务器<->数据库服务器之间的关联。下面我选取了部分在实际工作中遇到的多层架构应用中可关联的关键字截图以供参考: 

点击查看原图

点击查看原图

点击查看原图

参考资料:
1,海万学——《多层结构应用性能分析与故障诊断》
       海万学是国内为数不多的网络分析方面的专家,其个人博客为:www.packetstory.com,就是更新有点慢,大家可关注。
2,gqming——《多层结构应用各层之间数据传递的问题》链接为http://bbs.csdn.net/topics/190123492

阅读全文>>

标签: 同步 日志 网络分析 对比分析法 应用字段 关联分析 C/S 多层架构 连接复用 cookie 时间同步 B/S 三层架构

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

网络分析能力修行模型

作者:易隐者 发布于:2012-11-14 20:53 Wednesday 分类:网络分析

概述
       数次应业内朋友之邀,为其团队培训网络分析技术,从第一次开始,我就着手架构这个能力修行模型的框架,但还不够完善和成熟。随着我对网络分析技术理解的深入和本身水平的提升以及培训次数的增加,我不断的将其完善,并最终形成现在的雏形。

       根据这个网络分析能力修行模型,初学者可以清晰了解如何入手学习网络分析技术,并按部就班、循序渐进的提升网络分析技术的能力水平。

       所谓“道可顿悟,术需渐修”,但愿此文能够成为诸位网络分析初学者“悟道”的法门。

络运行的本质

       网络运行的本质是什么?是数据报文与协议。 

点击查看原图

       数据报文是网络运行世界里,具有完整信息的、最小的组成单元,而协议则是数据报文在网络内交互必须遵循的规则。因此掌握了这两者,基本上就可以把握网络运行的本质。

       网络分析技术将数据报文和协议完美的结合起来,因此网络分析技术通常也被叫做协议分析、数据包分析或报文分析。那么网络分析到底是如何工作的呢? 

点击查看原图

       网络分析技术是通过捕获网络通讯过程中的数据包(数据包是网络通讯过程中有意义的、最小的组成单元),并通过对捕获到的数据包进行深入的统计和分析,从而洞穿网络各个层面(包括性能、安全、业务以及故障等)运行情况的一种技术。
       通过网络分析技术,我们可以轻松透视网络运行的本质,如果我们的网络分析技术能力非常强,我们的技术水平会远远超出那些只精通于具体设备的工程师们,成为名副其实的网络层面的专家,那么我们如何修行才能提升自己的网络分析技术呢?下面我将通过网络分析能力修行模型展开详细介绍。

网络分析能力修行模型

       我将自己的成长经验总结为下图所示的网络分析能力修行模型: 

点击查看原图

       在这个模型中,围绕网络分析能力的提升,主要包含以下四方面的内容:

 基础

       古语云“千里之行始于足下”、“万丈高楼平地起”。做任何事情都离不开基础,网络分析技术能力的提升同样需要牢固扎实的技术基础作为支撑。

 工具
       古语云“巧妇难为无米之炊”。工具可以帮助我们事半功倍,大大提高我们的工作效率,没有称手的工具,纵然你有一身本领,却难免陷入纷繁复杂的二进制世界难以自拔。

 方法
       古语云“砍柴不照纹,累死砍柴人”。有基础有工具却不得法,虽可解决一些常见问题,但往往是随性而起,难以为继。即使大部分情况下你能成功解决问题,也只能说明你的运气和感觉都还不错,但是你无法将你的运气和感觉传递给你的团队、学生及他人。简言之:无章法,不足道。

 案例
       古语云“纸上得来终觉浅,绝知此事要躬行”。基础牢靠、精通工具、掌握方法,这已经为我们践行网络分析技术做好充分的准备,我们需要在实际工作环境中,把握任何机会,践行自己的网络分析技能,在利用网络分析技术解决问题之后,不断总结,并形成文档;另外一条践行的捷径是讨论学习他人的案例,将他人的经历经验借鉴过来为己所用,在短时间内快速提升自己。总之,多践行,多总结,多学习。

       根据这个网络分析能力修行模型,我将网络分析技术的学习和提升分为四个阶段,如下图所示: 

点击查看原图

第一阶段:打好基础
       这个阶段较为漫长,并且会一直持续伴随整个学习成长的过程。一般而言,这个阶段主要是学习网络基础、各种网络和安全设备的工作原理和机制、不同系统或设备的报文处理流程、TCP/IP协议体系、各常见应用等。在这个阶段,大部分是通过自主学习来获得提升的。

第二阶段:熟悉工具
       在扎实的技术基础上,熟练掌握1-2种网络分析的工具,不会花费太多的时间,但是如想成为高手,必须充分理解各种常见工具的优势特点,学会在不同的情况下,选择性的综合利用这些工具的优势特性,提高我们解决问题的效率。

第三阶段:掌握方法
      掌握网络分析的常规思路,深入理解网络分析方法的原理和使用场景,能够在实际工作环境下,按照网络分析方法和思路展开网络分析工作。

第四阶段:践行案例
       综合利用已学知识和掌握的方法,不断通过实际案例践行网络分析技术,以及对他人案例的学习,让自己的网络分析技术得以快速提升和升华。

       这四个阶段在大的学习和提升方向上是线序的,但这并不是绝对的,比如我们既可以借助他人的案例加固基础知识,又可以在实际案例中提升工具使用的熟练度,也可以利用网络分析工具学习协议体系……

网络分析能力修行模型不同阶段的学习资料

       在我的个人博客蚂蚁网——www.vants.org中,基本涵盖了网络分析能力修行模型中各个阶段学习的内容,下面我将各个阶段的资料做一个统一整理,方便初学者学习参考。

网络分析基础

防火墙的状态检测 http://www.vants.org/?post=24
应用层检测/深度包检测(DPI)http://www.vants.org/?post=23
TCP异常终止(reset报文)http://www.vants.org/?post=22
TCP重传 http://www.vants.org/?post=36
ICMP重组超时 http://www.vants.org/?post=35
TCP SACK选项 http://www.vants.org/?post=74
传输层的响应时间(系统层响应时间/服务器响应时间)http://www.vants.org/?post=115
关于防火墙的arp代理功能对不同格式的arp报文的处理情况的实验 http://www.vants.org/?post=121
ARP代理(Proxy ARP)http://www.vants.org/?post=119
免费ARP(gratuitousARP)http://www.vants.org/?post=118
ARP表的更新和老化http://www.vants.org/?post=120
第三方延时http://www.vants.org/?post=117
应用响应时间(ART)http://www.vants.org/?post=116
ICMP通讯管理性过滤禁止差错报文(type 3,code 13)http://www.vants.org/?post=127
连接数相关知识http://www.vants.org/?post=126
TCP/IP 应用程序的通信连接模式http://www.vants.org/?post=182
TCP保活(TCP keepalive)http://www.vants.org/?post=162
多次RST以及不同场景下的RST报文的差异http://www.vants.org/?post=141
端系统对RST报文的过滤http://www.vants.org/?post=140
经受时延的确认(Delay ACK)http://www.vants.org/?post=114
TCP MSS与PMTUD http://www.vants.org/?post=109
IP分片(IP Fragment) http://www.vants.org/?post=106
TCP 的PUSH标志位http://www.vants.org/?post=102
TCP交互式应用http://www.vants.org/?post=101
基于UDP的应用如何保证应用数据的可靠性http://www.vants.org/?post=99
关于“client push”应用响应时间测量方法的讨论http://www.vants.org/?post=30
iPhone与Multicast DNS        http://www.vants.org/?post=130
非标准TCP三次握手建立连接过程一例http://www.vants.org/?post=91
ACK flood攻击的影响http://www.vants.org/?post=136
基于UDP组播实施分片攻击的可能性http://www.vants.org/?post=98
关于防火墙访问控制的疑问http://www.vants.org/?post=26
TCP/IP 数据包处理路径 http://www.vants.org/?post=188

网络分析工具

常见网络分析工具特色功能简介及其在实际工作中的应用之缘起 http://www.vants.org/?post=43
常见网络分析工具特色功能简介及其在实际工作中的应用之Network Monitor http://www.vants.org/?post=41
常见网络分析工具特色功能简介及其在实际工作中的应用之Omnipeek  http://www.vants.org/?post=66
Wireshark对ping报文的解码显示(BE与LE)http://www.vants.org/?post=133
利用科来与IDS Informer构建网络攻击学习平台http://www.vants.org/?post=31

网络分析方法

疑难故障分析常规流程和思路http://www.vants.org/?post=27
疑难网络故障的分析方法和原理之对比分析法http://www.vants.org/?post=49
疑难网络故障的分析方法和原理之关联分析法http://www.vants.org/?post=51
如何跟踪分析数据经过中间设备后的变化以及这些变化给客户端与服务器带来的影响http://www.vants.org/?post=93
一切皆有可能http://www.vants.org/?post=122
异常流量分析方法——发现-定位-管控http://www.vants.org/?post=185
如何保证中间设备两端捕获的数据包的时间同步性?http://www.vants.org/?post=50

网络分析案例

视频点播服务间歇性中断故障分析案例http://www.vants.org/?post=73
访问搜狐163时主页变为2008年某日主页面故障分析案例http://www.vants.org/?post=89
某学院专网网站打开慢故障分析案例http://www.vants.org/?post=92
FTP登陆故障分析http://www.vants.org/?post=103
某单位经过CA认证的业务应用访问缓慢故障分析案例http://www.vants.org/?post=104
网页打开慢但HTTP下载快故障分析案例http://www.vants.org/?post=128
某业务系统由于连接数限制导致间歇性访问慢故障分析案例http://www.vants.org/?post=125
数据包中出现超长帧的分析http://www.vants.org/?post=184
关于vista系统机器无法通过防火墙上网的故障分析解决案例http://www.vants.org/?post=124
关于服务器端发送FIN报文之前的数秒等待时间行为的分析http://www.vants.org/?post=95
大包传输丢包故障http://www.vants.org/?post=34
两台soho级小路由之间的“正义”之战http://www.vants.org/?post=163
某加密机经天融信防火墙后应用异常故障案例http://www.vants.org/?post=107
负载均衡故障诊断:一个MSS值引发的疑案http://www.vants.org/?post=110
关于网内抓包出现0.33.216.220IP地址问题的分析http://www.vants.org/?post=88
F5负载均衡环境下某应用故障分析案例http://www.vants.org/?post=65
某地税网上申报业务系统故障分析报告http://www.vants.org/?post=58
高新区房产局房产管理业务故障分析解决报告http://www.vants.org/?post=32
某部队部分网段访问总部网站故障分析案例http://www.vants.org/?post=25
IPS在线升级故障分析案例http://www.vants.org/?post=16
使用Omnipeek分析SSH端口攻击案例http://www.vants.org/?post=134
针对随机组播地址的ping攻击案例http://www.vants.org/?post=132
基于UDP 7000端口的DOS攻击案例http://www.vants.org/?post=131
基于UDP 80端口的DOS攻击案例http://www.vants.org/?post=113
可能的数据库密码猜解行为http://www.vants.org/?post=84
PHP漏洞扫描—morfeus fucking scanner  http://www.vants.org/?post=67
web站点cookie安全问题一例http://www.vants.org/?post=64

阅读全文>>

标签: 同步 状态检测 TCP异常终止 团队 IDS Informer 网络分析 数据包分析 协议分析 网络分析能力修行模型

评论(19) 引用(0) 浏览(20550)

【转】TCP/IP 应用程序的通信连接模式

作者:易隐者 发布于:2012-10-22 15:56 Monday 分类:网络分析

【说在之前】:

原计划准备自己写一个关于长连接短连接知识点相关的文章,但是当我看到IBM公司的这篇文章之后,觉得没有必要为这个知识点专门花费时间和精力再写一篇,这篇文章站在软件开发的角度,已经对其做了足够清晰的阐述,后续我可能会写一些跟长连接短连接有关的案例,请大家关注。

【原文链接】:

http://www.ibm.com/developerworks/cn/aix/library/0807_liugb_tcpip/#ibm-pcon

【原文作者】:

刘光宝liugb@cn.ibm.com)在加入 IBM 前有大约 10 年的金融行业和 TCP/IP 应用开发经验。加入IBM 后从事 IBM i 操作系统上的 TCP/IP 应用程序的IPv6及其他软件开发。

【原文全文】:

TCP/IP 应用层与应用程序

       TCP/IP 起源于二十世纪 60 年代末美国政府资助的一个分组交换网络研究项目,它是一个真正的开放协议,很多不同厂家生产各种型号的计算机,它们运行完全不同的操作系统,但 TCP/IP 协议组件允许它们互相进行通信。现在 TCP/IP 已经从一个只供一些科学家使用的小实验网成长为一个由成千上万的计算机和用户构成的全球化网络,TCP/IP 也已成为全球因特网(Internet)的基础,越来越多的 TCP/IP 互联网应用和企业商业应用正在改变着世界。

       TCP/IP 通讯协议采用了四层的层级模型结构(注:这与 OSI 七层模型不相同),每一层都调用它的下一层所提供的网络任务来完成自己的需求。TCP/IP 的每一层都是由一系列协议来定义的。这 4 层分别为:

  • 应用层 (Application)应用层是个很广泛的概念,有一些基本相同的系统级 TCP/IP 应用以及应用协议,也有许多的企业商业应用和互联网应用。
  • 传输层 (Transport):传输层包括 UDP 和 TCP,UDP 几乎不对报文进行检查,而 TCP 提供传输保证。
  • 网络层 (Network)网络层协议由一系列协议组成,包括 ICMP、IGMP、RIP、OSPF、IP(v4,v6) 等。
  • 链路层 (Link)又称为物理数据网络接口层,负责报文传输。

        图1显示了 TCP/IP 层级模型结构,应用层之间的协议通过逐级调用传输层(Transport layer)、网络层(Network Layer)和物理数据链路层(Physical Data Link)而可以实现应用层的应用程序通信互联。

       应用层需要关心应用程序的逻辑细节,而不是数据在网络中的传输活动。应用层其下三层则处理真正的通信细节。在 Internet 整个发展过程中的所有思想和着重点都以一种称为 RFC(Request For Comments)的文档格式存在。针对每一种特定的 TCP/IP 应用,有相应的 RFC 文档。一些典型的 TCP/IP 应用有 FTP、Telnet、SMTP、SNTP、REXEC、TFTP、LPD、SNMP、NFS、INETD 等。RFC 使一些基本相同的 TCP/IP 应用程序实现了标准化,从而使得不同厂家开发的应用程序可以互相通信。

点击查看原图

 图 1 TCP/IP 层级模型结构

       然而除了这些已经实现标准化的系统级 TCP/IP 应用程序外,在企业商业应用和互联网应用开发中,存在着大量的商业应用程序通信互联问题。如图 1 显示,其中的应用层所包含应用程序主要可以分成两类,即系统级应用和商业应用,互联网商业应用是商业应用中的主要形式之一。

       不同开发商和用户在开发各自商业应用通信程序时也存在有许多不同的设计方式。关于 TCP/IP 应用层以下的技术文献与书籍早已是汗牛充栋,但是关于 TCP/IP 应用本身,尤其是关于商业应用的通信设计模式技术讨论方面的文章还是比较少的。TCP/IP 应用通信设计模式实际上是在 TCP/IP 基础编程之上的一种应用编程设计方式,也属于一种应用层协议范畴,其可以包含有 TCP/IP 地址族模式设计、I/O 模式设计、通信连接模式设计以及通信数据格式设计等。鉴于目前讨论 TCP/IP 商业应用程序设计模式问题这方面的文章还很少见,本文尝试给出一些通信连接模式设计中共同的概念与一些典型的设计模式,在以后的文章中将继续讨论地址族模式设计、I/O 模式设计、以及通信数据格式设计等方面的模式设计实现话题。

通信连接模式设计主要考虑内容有:

  • 通信两端程序建立通信方式
  • 通信连接方式
  • 通信报文发送与接收方式

以下内容将介绍建立通信的 Client/Server 模型,然后逐一介绍通信连接模式设计所需要考虑的这些内容。

APIs 与 TCP/IP 应用程序 C/S 模型 |outline">传输层接口 APIs 与 TCP/IP 应用程序 C/S 模型

传输层接口 APIs

       TCP/IP 应用层位于传输层之上,TCP/IP 应用程序需要调用传输层的接口才能实现应用程序之间通信。目前使用最广泛的传输层的应用编程接口是套接字接口(Socket)。Socket APIs 是于 1983 年在 Berkeley Socket Distribution (BSD) Unix 中引进的。 1986 年 AT&T 公司引进了另一种不同的网络层编程接口 TLI(Transport Layer Interface),1988 年 AT&T 发布了一种修改版的 TLI,叫做 XTI(X/open Transport interface)。XTI/TLI 和 Socket 是用来处理相同任务的不同方法。关于 TCP/IP APIs 使用文章与书籍已相当多,本文则是侧重于如何组合使用这些 APIs 来进行 TCP/IP 应用程序连接模式设计,并归纳出几种基本应用连接模式。

如图 2 显示,应用层是通过调用传输层接口 APIs(Socket 或 XTI/TLI)来与传输层和网络层进行通信的。

点击查看原图

图 2 传输层接口

       不管是使用何种编程接口,要在两个机器或两个程序之间建立通信,通信双方必须建立互相一致的通信模式。如果双方的通信设计模式不一致就无法建立有效的通信连接。

        以下是经常使用的 socket APIs,是建立 TCP/IP 应用程序的标准接口,也是影响 TCP/IP 应用程序通信方式的几个主要 APIs,不同 APIs 组合再结合系统调用可以实现不同方式的应用。Sockets 支持多种传输层和网络层协议,支持面向连接和无连接的数据传输,允许应用分布式工作。

  • socket():是用来创建一个 socket,socket 表示通信中的一个节点,其可以在一个网络中被命名,用 socket 描述符表示,socket 描述符类似于 Unix 中的文件描述符。
  • bind():是用来把本地 IP 层地址和 TCP 层端口赋予 socket。
  • listen() :把未连接的 socket 转化成一个等待可连接的 socket,允许该 socket 可以被请求连接,并指定该 socket 允许的最大连接数。
  • accept():是等待一个连接的进入,连接成功后,产生一个新的 socket 描述符,这个新的描述符用来建立与客户端的连接。
  • connect():用来建立一个与服务端的连接。
  • send():发送一个数据缓冲区,类似 Unix 的文件函数 write()。另外 sendto() 是用在无连接的 UDP 程序中,用来发送自带寻址信息的数据包。
  • recv():接收一个数据缓冲区,类似 Unix 的文件函数 readI()。另外 recvfrom() 是用在无连接的 UDP 程序中,用来接收自带寻址信息的数据包。
  • close():关闭一个连接

Client/Server 模型

Sockets 是以 Client 和 Server 交互通信方式来使用的。典型的系统配置是把 Server 放在一台机器中,而把 Client 放在另一台机器中,Client 连接到 Server 交换信息。一个 socket 有一系列典型的事件流。例如,在面向连接的 Client/Server 模型中,Server 端的 socket 总是等待一个 Client 端的请求。要实现这个请求,Server 端首先需要建立能够被 Client 使用的地址,当地址建立后,Server 等待 Client 请求服务。当一个 Client 通过 socket 连接到 Server 后,Client 与 Server 之间就可以进行信息交换。Client/Server 是通信程序设计的基本模式。从软件开发的角度讲,TCP/IP 应用程序都是基于 Client/Server 方式的。注意本篇文章以下 Client/Server 概念是针对程序内部调用 Socket API 所讲的概念,与针对整个程序甚至针对机器而讲的客户端 / 服务器概念有所不同。用 Server APIs 建立的程序可以被当作客户端使用,用 Client APIs 建立的程序也可以被用作服务器端使用。建立 Server 需要的 APIs 有 socket(), bind(), listen(), accept(),建立 Client 需要的 APIs 有 Socket(), Connect()。在实际应用开发中,同一个程序里往往同时可以有 Client 和 Server 的代码,或者多种形式的组合。在实际应用编程中,针对 Socket APIs 不同有效组合,结合系统调用可以有多种复杂的设计变化。

面向连接的应用编程存在三类基本的不同级别的设计方式范畴,根据 Socket APIs 从上到下顺序依次是:

  • Client/Server 通信建立方式
  • Client/Server 通信连接方式
  • Client/Server 通信发送与接收方式

下面内容以面向连接的 Socket 应用编程为例来说明这几种不同通信范畴的设计实现。

Client/Server 建立方式设计概述

一个 Client 连接一个 Server

        如果只有两台机器之间连接,那么一个是 Client,另一个是 Server,如下面图 3 所示。这是最简单的 TCP/IP 的应用,也是 TCP/IP 应用早期的 Peer to Peer (P2P) 概念。其流程基本如图 4 所示。

点击查看原图

图 3 TCP/IP 应用单点 Client/Server

         图 4 显示了 TCP/IP 应用编程最基本的 Client/Server 模式,显示了基本的 Client/Server 通信所需要调用的 Socket APIs 以及顺序。

点击查看原图

图 4 TCP/IP 应用编程基本 Client/Server 模式

 多个 Client 连接一个 Server

       多个 Client 同时连接一个 Server 是 TCP/IP 应用的主流形式,如图 5 所示,其中 Client 连接数可以从几个到成千上万。

点击查看原图

图 5 TCP/IP 应用多 Client 端的 Client/Server

       由于 socket APIs 缺省方式下都是阻塞方式的,实现多个 Client 同时连接一个 Server 就需要特别的设计。其实现方式可以有多种不同的设计,这其中也涉及 I/O 模式设计。下面将展开介绍其中几种设计形式。

利用一个 Client 连接一个 Server 形式实现多 Client 连接

        从程序设计角度讲,只要 Client 和 Server 端口是一对一形式,那么就属于一个 Client 连接一个 Server 形式。在处理多个 Client 端连接时,Server 端轮流使用多个端口建立多个 Client-Server 连接,连接关闭后,被释放端口可以被循环使用。在这种多连接形式中需要谨慎处理 Client 端如何获取使用 Server 端的可用端口。比如图 6 显示 Server 有一个服务于所有进程的进程可以先把 Server 端的可用端口发送给 Client 端,Client 端再使用该端口建立连接来处理业务。Server 针对每一个 Client 连接用一个专门的进程来处理。由于可用端口数有限,Server 用一个有限循环来处理每一个可用的端口连接。由于新端口需要用 bind() 来绑定,所以需要从 bind() 开始到 close() 结束都需要包含在循环体内。

点击查看原图

 图 6 利用一对一 Client-Server 模式实现多 Client 连接

使用多个 accept() 实现多 Client 连接

       多进程 Server 一般有一个专注进程是服务于每一个连接的。当 Client 端完成连接后,专注进程可以循环被另外的连接使用。使用多个 accept() 也可以实现处理多 Client 连接。多 accept() 的 Server 也只有一个 socket(),一个 bind(),一个 listen(),这与通常情况一样。但是它建立许多工作子进程,每一个工作子进程都有 accept(),这样可以为每一个 Client 建立 socket 描述符。如图 7 所示,由于 accept() 连接成功后,会产生一个新的 socket 描述符,这样通过循环多进程利用 accept() 产生的多 socket 描述符就可以与多个 Client 进行连接通信。循环体是从 accept() 开始到 close() 结束的。

点击查看原图

图 7 使用多 accept() 实现多 Client 连接

使用并发 Server 模式实现多 Client 连接

       并发服务器模式曾经是 TCP/IP 的主流应用程序设计模式,得到广泛使用,目前互联网上仍有相当多的应用使用此种模式。其设计思路是在 accept 之后 fork 出一个子进程。因为 socket 会产生监听 socket 描述符 listenfd,accept 会产生连接 socket 描述符 connfd。连接建立后,子进程继承连接描述符服务于 Client,父进程则继续使用监听描述符等待另外一个 Client 的连接请求,以产生另外一个连接 socket 描述符和子进程。如图 8 所示,accept() 接收到一个 Client 连接后,产生一个新的 socket 描述符,通过 fork() 系统调用,用一个子进程来处理该 socket 描述符的连接服务。而父进程可以立即返回到 accept(),等待一个新的 Client 请求,这就是典型的并发服务器模式。并发服务器模式同时处理的最大并发 Client 连接数由 listen() 的第二个参数来指定。

点击查看原图

图 8 TCP/IP 应用并发 Server

使用 I/O 多路技术实现多 Client 连接

       以上三种连接设计,多 Server 端口、多 accept() 和并发服务器模式,都是通过 fork() 系统调用产生多进程来实现多 Client 连接的。使用 I/O 多路技术也可以同时处理多个输入与输出问题,即用一个进程同时处理多个文件描述符。I/O 多路技术是通过 select() 或 poll() 系统调用实现的。poll() 与 select() 功能完全相同,但是 poll() 可以更少使用内存资源以及有更少的错误发生。select() 调用需要与操作文件描述符集的 APIs 配合使用。select() 系统调用可以使一个进程检测多个等待的 I/O 是否准备好,当没有设备准备好时,select() 处于阻塞状态中,其中任一设备准备好后,select() 函数返回调用。select() API 本身也有一个超时时间参数,超时时间到后,无论是否有设备准备好,都返回调用。其流程如图 9 所示。在 socket APIs listen() 和 accept() 之间插入 select() 调用。使用这三个宏 FD_ZERO()、FD_CLR() 和 FD_SET(),在调用 select() 前设置 socket 描述符屏蔽位,在调用 select() 后使用 FD_ISSET 来检测 socket 描述符集中对应于 socket 描述符的位是否被设置。 FD_ISSET() 就相当通知了一个 socket 描述符是否可以被使用,如果该 socket 描述符可用,则可对该 socket 描述符进行读写通信操作。通常,操作系统通过宏 FD_SETSIZE 来声明在一个进程中 select() 所能操作的文件或 socket 描述符的最大数目。更详细的 I/O 多路技术实现,可以参考其他相关文献。

点击查看原图

图 9 I/O 多路技术实现多连接的 Server

一个 Client 连接多个 Server

         一个 Client 连接多个 Server 这种方式很少见,主要用于一个客户需要向多个服务器发送请求情况,比如一个 Client 端扫描连接多个 Server 端情况。如图 10 所示。此种方式设计主要是 Client 端应用程序的逻辑设计,通常需要在 Client 端设计逻辑循环来连接多个 Server,在此不做更多描述。

点击查看原图

图 10 单 Client 对多 Server

复杂 Client/Server 设计与现代 P2P

        最近几年,对等网络技术 ( Peer-to-Peer,简称 P2P) 迅速成为计算机界关注的热门话题之一,以及影响 Internet 未来的科技之一。与早期点对点 (Peer to Peer) 的 Client/Server 模式不同,现在的 P2P 模式是指每个结点既可充当服务器,为其他结点提供服务,同时也可作为客户端享用其他结点提供的服务。实际上 P2P 模式仍然是基于 Client/Server 模式的,每个通信节点都既是 Server,又是 Client,P2P 是基于复杂 Client/Server 设计的 TCP/IP 应用。图 11 显示 P2P 模式下两个用户 PC 之间的对等连接。

点击查看原图

图 11 P2P 模式

       在技术上,P2P 本身是基于 TCP/IP Client/Server 技术的一种设计模式思想, P2P 也属于网络应用层技术,与 Web 和 FTP 等应用是并列的。只是 P2P 应用在设计实现上更要复杂的多。P2P 技术实现的协同工作是无需专门的服务器支持的 (Serverless),这里的服务器概念与 Client/Server 中的 Server 概念是不一样的。在传统意义上中心服务器机器上往往运行的是 TCP/IP 应用的 Server 端程序,所以传统意义上的 Server 概念在机器与应用上是重合的。如果更改 TCP/IP 的应用设计,使应用程序既可做 Server 又可做 Client,就可以实现无中心服务器的 P2P 模式。

       在设计模式上,P2P 模式实现了网络终端用户不依赖中心服务器或者服务商而直接进行信息和数据交换的可能,因此 P2P 正在改变着整个互联网的一些基础应用,从而极大地增加了用户之间的信息沟通和交流能力。目前互联网的 P2P 应用与网络都正在飞速发展,一些典型的 P2P 应用程序比如有 BitTorrent, eDonkey 等,另外一些即时通信(IM)类软件比如 MSN、QQ 等也正在向无中心服务器模式转变。无中心服务器的 Internet 应用程序大大降低应用提供商的运营成本,而且减少人们对于 Server 稳定性的依赖。

Client/Server 通信连接方式设计

       Client/Server 通信方式建立后,下一步就需要考虑通信连接的方式,主要有两种方式的连接,即长连接通信与短连接通信。通信连接方式涉及到的 APIs 主要是 connect() 和 accept()。要实现某种 Client/Server 方式,就必须考虑用某种特定的连接方式。

短连接通信

       短连接通信是指 Client 方与 Server 方每进行一次通信报文收发交易时才进行通讯连接,交易完毕后立即断开连接。此种方式常用于多个 Client 连接一个 Server 情况,常用于机构与用户之间通信,比如 OLTP(联机事务处理)类应用。在短连接情况下,Client 端完成任务后,就关闭连接并退出。在 Server 端,可以通过循环 accept(),使 Server 不会退出,并连续处理 Client 的请求。图 12 显示了一般情况下短连接通信模式的 Socket 事件流,不同设计的连接多 Client 的 Server 有不同的循环流程。

点击查看原图

图 12 短连接模式通信

长连接通信

       长连接通信是指 Client 方与 Server 方先建立通讯连接,连接建立后不会断开,然后再进行报文发送和接收,报文发送与接收完毕后,原来连接不会断开而继续存在,因此可以连续进行交易报文的发送与接收。这种方式下由于通讯连接一直存在,其 TCP/IP 状态是 Established,可以用操作系统的命令 netstat 查看连接是否建立。由于在长连接情况下,Client 端和 Server 端一样可以固定使用一个端口,所以长连接下的 Client 也需要使用 bind() 来绑定 Client 的端口。在长连接方式下,需要循环读写通信数据。为了区分每一次交易的通信数据,每一次交易数据常常需要在数据头部指定该次交易的长度,接收 API 需要首先读出该长度,然后再按该长度读出指定长度的字节。长连接方式常用于一个 Client 端对一个 Server 端的通讯,一般常用于机构与机构之间的商业应用通信,以处理机构之间连续的大量的信息数据交换。或者说可用于两个系统之间持续的信息交流情况。通常为了加快两个系统之间的信息交流,通常还需要建立几条长连接的并行通信线路。图 13 显示了一般情况下长连接通信模式的 socket 事件流,可见其最大特点是 Client 和 Server 都有循环体,而且循环体只包含读写 APIs。

点击查看原图

图 13 长连接模式通信


Client/Server 通信发送与接收方式设计

       在通信数据发送与接收之间也存在不同的方式,即同步和异步两种方式。这里的同步和异步与 I/O 层次的同异步概念不同。主要涉及 socket APIs recv() 和 send() 的不同组合方式。

同步发送与接收

       从应用程序设计的角度讲,报文发送和接收是同步进行的,既报文发送后,发送方等待接收方返回消息报文。同步方式一般需要考虑超时问题,即报文发出去后发送方不能无限等待,需要设定超时时间,超过该时间后发送方不再处于等待状态中,而直接被通知超时返回。同步发送与接收经常与短连接通信方式结合使用,称为同步短连接通信方式,其 socket 事件流程可如上面的图 12 所示。

异步发送与接收

       从应用程序设计的角度讲,发送方只管发送数据,不需要等待接收任何返回数据,而接收方只管接收数据,这就是应用层的异步发送与接收方式。要实现异步方式,通常情况下报文发送和接收是用两个不同的进程来分别处理的,即发送与接收是分开的,相互独立的,互不影响。异步发送与接收经常与长连接通信方式结合使用,称为异步长连接通信方式。从应用逻辑角度讲,这种方式又可分双工和单工两种情况。

异步双工

       异步双工是指应用通信的接收和发送在同一个程序中,而有两个不同的子进程分别负责发送和接收,异步双工模式是比较复杂的一种通信方式,有时候经常会出现在不同机构之间的两套系统之间的通信。比如银行与银行之间的信息交流。它也可以适用在现代 P2P 程序中。如图 14 所示,Server 和 Client 端分别 fork 出两个子进程,形成两对子进程之间的连接,两个连接都是单向的,一个连接是用于发送,另一个连接用于接收,这样方式的连接就被称为异步双工方式连接。

点击查看原图

图 14 长连接异步双工模式

异步单工

       应用通信的接收和发送是用两个不同的程序来完成,这种异步是利用两对不同程序依靠应用逻辑来实现的。图 15 显示了长连接方式下的异步单工模式,在通信的 A 和 B 端,分别有两套 Server 和 Client 程序,B 端的 Client 连接 A 端的 Server,A 端的 Server 只负责接收 B 端 Client 发送的报文。A 端的 Client 连接 B 端的 Server,A 端 Client 只负责向 B 端 Server 发送报文。

点击查看原图

图 15 长连接异步单工模式


 

典型通信连接模式

       综上所述,在实际 TCP/IP 应用程序设计中,就连接模式而言,我们需要考虑 Client/Server 建立方式、Client/Server 连接方式、Client/Server 发送与接收方式这三个不同级别的设计方式。实际 TCP/IP 应用程序连接模式可以是以上三类不同级别 Client/Server 方式的组合。比如一般 TCP/IP 相关书籍上提供的 TCP/IP 范例程序大都是同步短连接的 Client/Server 程序。有的组合是基本没有实用价值的,比较常用的有价值的组合是以下几种:

       其中异步长连接双工是较为复杂的一种通信方式,有时候经常会出现在不同银行或不同城市之间的两套系统之间的通信,比如国家金卡工程。由于这几种通信方式比较固定,所以可以预先编制这几种通信方式的模板程序。

总结

       本文探讨了 TCP/IP 应用程序中连接模式的设计。在以后的文章中还将继续讨论 TCP/IP 应用程序设计中的其他方面的设计话题,包括地址族模式设计、I/O 模式设计、以及通信数据格式设计等。


参考资料

  • AIX V5.3 中 IPv4 和 IPv6 的网络接口操作 : 通过本文,您将了解更多关于套接字 I/O 控制 (ioctl) 命令的内容,以及如何使用它们完成各种网络相关的操作 . 操作系统为套接字、路由表、ARP 表、全局网络参数和接口提供了相应的控制操作方式。
  • Unix Network Programming Volume 1: 帮助您全面地了解 Unix 网络编程的知识。
  • AIX and UNIX 专区 :developerWorks 的“AIX and UNIX 专区”提供了大量与 AIX 系统管理的所有方面相关的信息,您可以利用它们来扩展自己的 UNIX 技能。
  • AIX and UNIX 新手入门 :访问“AIX and UNIX 新手入门”页面可了解更多关于 AIX 和 UNIX 的内容。
  • AIX and UNIX 专题汇总 :AIX and UNIX 专区已经为您推出了很多的技术专题,为您总结了很多热门的知识点。我们在后面还会继续推出很多相关的热门专题给您,为了方便您的访问,我们在这里为你把本专区的所有专题进行汇总,让您更方便的找到你需要的内容。

阅读全文>>

标签: 同步 TCP ARP 稳定 长连接 短连接 TCP/IP IBM C/S API

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

TCP交互式应用

作者:易隐者 发布于:2012-8-30 21:29 Thursday 分类:网络分析

       TCP交互式应用由于其交互的特性,一般对时延的要求较高,因此一旦有应用数据时便立即向对端发送并要求对端能够及时处理,其交互的报文基本上都是小包(小于MSS),常见的TCP交互式应用主要有telnet、rlogin、互动游戏等,我们先来看一个TCP交互应用的报文分析:

点击查看原图

其具有以下三个明显特点:

1,客户端与服务器端的数据传输是交互式进行的;

2,应用字段长度均较小;

3,带有应用字段的TCP报文PUSH位均置一。

TCP交互式应用的场景(以游戏为例):

       对于实时网络游戏这种交互应用,如果TCP接收方不立即将应用数据提交应用程序处理的话,很可能会导致游戏应用出现卡、客户端与服务器端不同步故障,严重影响游戏应用的正常运行。你想啊,你在玩CS,扮演警察,突然一个悍匪跟你正面冲突,悍匪那边快速操作已经移动位置了,但是悍匪移位这个应用信息却被你的TCP放在接收缓存里,你机器显示器上看到的悍匪还在原来的位置,然后你自然向悍匪原来的位置开枪,结果呢,肯定没伤到悍匪,却被早就移位的悍匪爆头击毙,这时候你会爽吗?肯定骂死这个游戏应用了,呵呵。
        那么交互式应用如何保证应用字段能够被立即处理呢答案就是将带有应用字段的TCP报文(不论应用字段大小)的PUSH位全部置一,虽是小包,但TCP一旦接收到便立即将其交付应用程序处理。

       我在08年做内部《TCPIP详解卷一》培训在讲到第19章《TCP的交互数据流》时,曾今专门捕获了WAR 3的局域网游戏的交互报文,用于讲解TCP交互式应用的特性,现在把这个报文一并放在此供各位参考。

WAR 3的局域网游戏的报文:

点击查看原图

        交互式应用并不是非常常见,因此经常被大家忽略,导致有时在遇到交互应用场景的分析时,将其当作HTTP等常见应用的特性来进行分析,可想而知,如此将走向错误的分析方向,望各位兄弟姐妹引以为鉴。

        这里提到了TCP报文的一个非常重要的标志位——PUSH,我下一篇文章将会针对PUSH位做一个详尽的讨论和分析,望大家关注。

阅读全文>>

标签: 同步 TCP 应用字段 故障 push 交互式应用 交互

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

百度空间同步插件测试文章

作者:易隐者 发布于:2012-3-2 22:35 Friday

百度空间同步插件测试文章

阅读全文>>

标签: 同步

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

Powered by 易隐者 基于emlog 皖ICP备12002343号-1