wap底层技术资料(四)
来源：网络收集 责任编辑：栏目编辑 发表时间:2013-07-01 19:12 点击:次
2.4.4.2 其他参数分析
业务模型建立的原则之一是模型尽可能简单，所以需要剔除一些冗余的参数，但是某些参数对于分析用户行为、网关性能等都具有一定的实际意义，因此，我们也对其做出了分析，这些参数列表如下：
表2.10 其他的待分析参数列表
|
参数 |
终端的主对象请求间隔 |
终端的内置对象请求间隔 |
服务器返回网关的主对象大小 |
服务器返回网关的内置对象大小 |
网关返回对象间隔（包括主对象与内置对象） |
多用户对于整个系统各部分的流量影响 |
重定向报文比例 |
参数解释：
1. 终端的主对象请求间隔：即终端向网关发出的相邻两次主对象请求的时间间隔。每次主对象请求对
应用户浏览新的网页，所以主对象请求是由用户发起的。统计数据根据网关连续收到两次主对象请求的时间
间隔。
2. 终端的内置对象请求间隔：终端向网关发出的相邻两次内置对象请求的时间间隔。终端收到网关返
回的主对象后，对主对象解析并根据其中包含的内置对象的URL地址向网关发送内置对象请求。因此，内置
对象的请求是由终端而非用户发起的。统计数据根据网关连续收到两次内置对象请求的时间间隔。
3. 服务器返回网关的主对象大小：终端由用户发起的请求都是作为主对象请求看待的，从已有数据来看，
主对象的数据量以占了数据传输量的很大一部分，一般主对象都分为3或4个包，这一般由主对象大小
确定。并且这些数据都可以从网关截取的数据得到其分布参数。
4. 服务器返回网关的内置对象大小：和主对象一起，二者构成了WAP业务中数据流量的绝大多部分。
在现有的WAP业务中，内置对象一般都是网页内包含的一些图片。终端就是根据主对象脚本中的包含URL发起对内置对象的连接的。但前面讨论过，终端对内置对象发起连接的个数并不完全由脚本中内置对象的个数
决定，而受到多方面的影响，比如终端的Cache，用户的设置等等。从发起内置对象的作用效果来说，我们也不需要关心一个主对象中包含了具体多少内置对象，而只需要知道终端在收到一个主对象后一般会发起多少次内置对象请求。所以在服务器这端我们并不去讨论主对象中包括的内置对象的数目，而只是对内置对象的大小分布感兴趣。一个内置对象都能用一个包传输完毕，并且其大小比较稳定。另外，统计服务器返回的对象大小与网关返回的对象大小也可以计算网关对数据的压缩比例。
5. 网关返回终端的对象间隔：网关向终端发送Reply的时间间隔，包括主对象和内置对象的Reply。这是从网关端考虑发送数据时需要的参数，可以与网关响应时间一起用于衡量网关的处理性能。该参数包括当
前对象的网关响应时间和上一次对象的终端处理时间。
6. 重定向报文比例：WAP网关会收到服务器发来的一类URL重定向报文，网关对这类报文的处理流程
如图2.27，
图2.27 重定向时序图
从上图可见，在这种情况下，WAP网关需要向多个服务器请求数据。这就使得WAP网关的工作量增大，从部分数据中分析得到重定向在连接请求中的比例在11％左右，这就要求我们必须将这类URL重定向的情况单独考虑。至于重定向包数在实际通信中的准确比例需要进一步采集数据分析确认。
7. 多用户时的数据请求和流量模型：指随着用户数的变化，由于用户请求而产生的数据包传送能够产生多大的流量，用以确定系统各个段（包括无线段和有线断）的数据流量随着用户数的变化规则。同时我们还需要统计当不同的用户数在线时用户端发起请求数的规律，这点很重要，因为发起的请求数是包含由于差错而引起的重传的。这对衡量不同用户数时对网关的承受负载性能也很关键。
8. 关于如何处理差错和丢包的问题，从已采集的数据报文可见，因为出错或超时都会引起终端请求的重发，从这个角度而言，我们可以将出错和重发视为一次新的请求连接，不过这个请求连接是随着网络状态的变化而发起的，这样我
相关新闻>>
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>
