51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 16058|回复: 28

请教大家一个关于Gbover IP的问题   [复制链接]

Rank: 8

发表于 2011-7-5 11:05:12 |显示全部楼层
一键分享 一键分享
附件是我们在现网实际环境中抓的Gb over ip的数据包(在SGSN侧的Gb口抓包)

我们看第555个包,发现这样一种情况:
外层的IP包(SGSN到BSC)的ip层 Total Length =455
但是里层的IP包(wapgw到ue)的ip层 Total Length =1400

按照我的理解,外层由于还有BSSGP,NS等层的封装,长度要大于1400才行
但是确出现小于1400的情况。

请教大家可能是什么原因。

455的长度如果是RLC层的456的,也说不过去呀,因为这是Gb的,而RLC是BSC到UE的。

又有一个说法是:厂家会把gb overIP的包分成1到3个分片包来传递。(这样不是消耗资源吗?难道是BSC不能处理大包)

多谢各位指教。



附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册

Rank: 8

发表于 2011-7-5 11:18:08 |显示全部楼层
本帖最后由 watson100 于 2011-7-5 15:26 编辑

在Gb 这段链路的MTU我们是设置为1500的。

咨询了一下,应该是LLC层的N201-U这个参数导致在LLC层进行分片导致。


使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-5 23:28:36 |显示全部楼层
回复 watson100 的帖子

  你的这个问题其实还是蛮经典的。我补充一下哈。请大家拍砖。
  2楼的贴其实你找到了答案,这个封装确实是由LLC层提供的参数N201-U来执行的分段,只不过分段并不是LLC层提供的,而是SNDCP层的功能。所以这个参数是LLC层通过原语告知SNDCP层,由SNDCP层实际完成的。可以参考这篇帖子:SNDCP层数据包分段及重组功能实例详解
  以你给出的包为例,说明一下这个用户面数据包的分段。应该不是555这个包,555这个包总共才104个字节。
  我们以#550,#551,#552这3个包为例来说明一下上述的分段功能。首先是原理,这个包从MS上发出去一共要经过好几次分段。
1 首先是应用层封装好后,交给TCP层分段。TCP层分段的依据是MSS(最大分段大小),将TCP的上层部分按MSS的大小进行切割,分段。而MSS的大小是在TCP的三次握手时协商的。可以点开#20号包,是TCP的3次握手,会发现MSS是1360字节。例如上层HTTP的网页大小是5000字节,TCP层就将5000/1460=4个包(取整数),到接收端再把这四个包重组进行还原。
2 TCP按照1360字节分好后,加上TCP头20字节,加上IP头20字节(假设没有Option部分),这时IP头执行分片。分片的标准是MTU。这是在设备上配置的。当然也可以协商,但需要在接口打开相应的功能。
3 IP层按MTU封装好后,交给SNDCP层处理,SNDCP层的分段标准是LLC层提供的N201-U。这个值是由LLC层的XID协商流程协商出来的,由协议间原语提供给SNDCP层使用。这个N201-U的参数是LLC层的参数,因此按N201-U分段好的数据包,应包括SNDCP的包头再加上SNDCP的上层所有数据部分。可以看到,点击#550,#551包的SNDCP层,会看到都是520字节。这个520字节其实就是N201-U的值。
4 然后可以在#552看到有包的重组,点开#552的SNDCP层会发现,有3个N-PDU的Fragment完成重组了,分别是#550的516字节,#551的517字节和#552的367字节。加起来正好是1400字节。(这里的516和517字节再加上SNDCP的包头长度正好就是N201-U的长度520字节)这个1400字节就是一个TCP的段,是MSS的1360字节+TCP 20字节+IP 20字节头部组成的,若干个TCP的段也要重组。还原出真正的payload。就像第一步提到的那样。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 8

发表于 2011-7-6 10:50:08 |显示全部楼层
没有仔细看楼主原来的帖子,真是惭愧。
另外还有一个问题,在[44.064]里面SAPI=3的N201-U的默认值是500,
我们希望能把这个值提高,以此来提高数据的传输效率(因为包头少了)。

有一种考虑是:由于LLC采用的是非确认模式,所以设置500字节可以减少重传包。还有就是BSC的处理能力限制。

我的考虑是,先不说BSC的处理能力限制,N201-U设置为500字节和1000字节,对于TCP的应用来说,也要从服务器侧重传整个数据包的。不会造成效率的降低。
对于UDP来说,也就是丢500个字节和1000个字节的区别。

缺点就是:调成1000字节需要增加LLC层的XID交互,也有可能手机不支持

不知道还有哪些方面没有考虑到呢?请大家指教。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

发表于 2011-7-8 16:13:21 |显示全部楼层
回复 爱卫生 的帖子

爱总,从你的回答中看有几个疑问:

1.TCP包头为什么是20bytes,我从包中看到了32options=12)和44options=24)莫非是要减去可选字段?如果是这样,为什么要减呢?我看了好多TCP包都有option啊?


2.“因此按N201-U分段好的数据包,应包括SNDCP的包头再加上SNDCP的上层所有数据部分,其中N201-U为520bytes,我也看到#547#548520bytes,但这个520不应该是包头吗,就图中的方位(370bytes)?如果不是,那SNDCP包头是多少,不固定吗?,因为#547~#549分别有516,517,367字节,所以不明白"……"你引号中的话。



3.“假设HTTP的网页大小是5000字节这个在TCP层分包,再在SNDCP分段,为什么分段后接着就重组了(如#549),这个重组是经过传输后重组的吗?如果HTTP要重组,是在哪个包中看到,是200 ok吗?能看到5000bytes吗?

附件: 你需要登录才可以下载或查看附件。没有帐号?立即注册

使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-9 15:32:45 |显示全部楼层
watson100 发表于 2011-7-6 10:50
没有仔细看楼主原来的帖子,真是惭愧。
另外还有一个问题,在[44.064]里面SAPI=3的N201-U的默认值是500,
...

  不好意思,我先确认下你的问题。就是说如果不考虑BSC的处理能力限制,则N201-U为500还是1000其实没太大关系是吗?设大点还能减少重组和分片?对吗?
  我的理解是,这个问题其实超出了Gb口的范围,可以扩展到很多方面。包括为了IP层的MTU要是1500字节,设2000不更好?TCP 的MSS为什么有些默认是536字节,不再弄大些?
  其实,这里面还有Qos的考虑。如果将N201-U设置为1000。则用户的payload每个都有1000字节在Gb接口上跑,那还有很多信令包是很小的包,只有十几或几十字节,那这些1000字节的包很可能造成链路的拥塞,除非在IP的承载网络里面启用了严格的Qos队列排队和调度机制,即使这样,那也是不优化的。
  就好比,开车的话,如果全都是几十吨的大卡车在跑,还是加长的。一个车就有两个普通轿车长。如果你是普通的小车车主,让在在后面排队你也不愿意吧。还是ATM好,所有的包都是定长的。所以N201-U不能太大,否则容易造成Gb口的链路拥塞。也不能太小,否则会造成SNDCP层的分段包数量过多。至于500字节是怎么来的,我不知道。应该是做的测试调研出来的吧,就像Ready Timer 44秒一样,也是根据当时的用户行为调研出来的。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-9 18:14:41 |显示全部楼层
本帖最后由 爱卫生 于 2011-7-9 18:49 编辑
tobino1 发表于 2011-7-8 16:13
回复 爱卫生 的帖子

爱总,从你的回答中看有几个疑问:1.TCP包头为什么是20bytes,我从包中看到了32(opti ...


  我说下我的理解哈。关于你说的3个问题。
1.TCP包头为什么是20bytes,我从包中看到了32(options=12)和44(options=24)莫非是要减去可选字段?如果是这样,为什么要减呢?我看了好多TCP包都有option啊?
   我在举例的时候,没太注意这个option,也就是按照传统的TCP分段来说,因为大多数的应用在发送tcp payload的时候不带option,只有标准包头20字节。option在控制层面,例如TCP的三次握手节点可以用来协商MSS。而在用户平面,有些特殊的应用,如语音类业务,会携带时间戳来方便重组。就像我们这里看到的一样,option部分携带了时间戳。
   一个最普遍最常见的场景是:IP层MTU为1500,TCP的MSS为1460,然后再查路由表找到下一跳再交给数据链路层处理。从接口发出去的包IP层及以上部分刚好就是1500字节,不用分片。1460+20字节TCP头(假设没有option,适应于大部分的普通应用)+20字节IP头(假设也没有option,也适用于大多数场景)。

2 2.“因此按N201-U分段好的数据包,应包括SNDCP的包头再加上SNDCP的上层所有数据部分”,其中N201-U为520bytes,我也看到#547和#548是520bytes,但这个520不应该是包头吗,就图中的方位(370bytes)?如果不是,那SNDCP包头是多少,不固定吗?,因为#547~#549分别有516,517,367字节,所以不明白"……"你引号中的话。
   这个370字节不是SNDCP包头,在#552的370字节代表在#552中,SNDCP上层的payload为367字节,再加上SNDCP包头3个字节=370字节。你可以点开SNDCP层可以看到。3个包头字节包括地址字段、N-PDU编号和Segment的编号等。
   其中,N-PDU编号=155,和#550/551编号是相同的,代表着3个包是同一个SNDCP的上层用户报文。而#552中的SNDCP层的Segment=2,代表它是N-PDU编号=155分段后的第3个包,在#550/551中,你会看到Segment分别为0,和1.这样在对端SNDCP层接收后就知道怎么重组了。所以SNDCP包头是不固定的。其中#550为4字节,#551为3字节。主要是#550为分段的第一个包,在SNDCP包头中声明了没有使用压缩。#551不需要继续声明了。

3 3.“假设HTTP的网页大小是5000字节”这个在TCP层分包,再在SNDCP分段,为什么分段后接着就重组了(如#549),这个重组是经过传输后重组的吗?如果HTTP要重组,是在哪个包中看到,是200 ok吗?能看到5000bytes吗?
  能看到。你的这个问题真的很好。看来这个帖子有希望能录个视频。
  完整来看,如下:
1 首先是10.9.4.200(手机)和10.0.0.172(WAP网关)完成TCP三次握手。见533,535,540这3个包(中间夹了些杂包,不要看,你看ACK确认号就可以确定了)。533是SYN,535是SYN ACK,540是对SYN ACK的ACK。在这3个包里,完成了MSS的宣告。其中,在535的TCP的option字段,可以看到10.0.0.172告诉对方自己的MSS是1360字节,所以后续10.0.0.172发的下行包都将以1360字节进行TCP层分段)。
2 #524是手机开始了网页浏览,请求的页面是gd.sina.cn/...。
3 #543是WAP网关10.0.0.172回的一个HTTP ACK。
   接下来,WAP网关就要给手机回HTTP 200 OK。(你也提到了,确实就是这个200 OK)。
   我先说我发现的结果,再来说发现的过程。
   这个HTTP 200 OK的长度总共是3164字节。体现在#554的TCP层,点开可看。
   这个3164字节属于HTTP应用层。首先交给TCP层,TCP层将根据协商好的MSS为1360进行分段,但实际上在做TCP分段的时候,用的标准是1348字节,因为它将TCP层的option部分的12字节也算进去了。总共是1360字节。但我个人觉得这样做可能是不合规范的,因为按我对规范的理解,MSS的分段应该是不能包括TCP报文头的,而option也属于报文头的一部分。
   就这样,在TCP层,3164字节被分成了3个包,分别是#549TCP重组后的1348字节,#552的1348字节。#554的468字节。
   但1348字节在空口传仍然太大了。所以TCP层交给IP层处理,IP层加上20字节标准头部后,交给SNDCP层处理,SNDCP层则还需要执行分段,依据是LLC层提供的N201-U(U代表非确认模式)。本例的N201-U是520字节。因此1348字节又需要被分成3个包。第一个被拆分的SNDCP包是#547/548/549,第二个被拆分的SNDCP包是#550/551/552。第三个是#553/554。#549完成第一个SNDCP包的重组,#552完成第2个。#554完成第3个。最后,在#554完成TCP层的三个分段包的重组,重组完就是一个HTTP 200 OK的消息。

   几个数字如下:
1 #552里SNDCP层重组完后的N-PDU长度1400字节。是#550的516+#551的517再+#552的367得到的。并不是指#552自己的长度。#552总长度是455字节。而SNDCP及以上是370字节。包括3字节SNDCP包头和367字节payload。
2 #552里的455字节总长度(按协议栈从下往上)=IP头20字节+UDP头8字节+GPRS NS层头部4字节+BSSGP头47字节+LLC头部6字节+SNDCP头部3字节+SNDCP上层的N-PDU为367字节所组成的。可以点击来看。
3 需要注意的是,在#552里SNDCP的N-PDU的367字节只是纯用户的payload数据,并不包含#552中最上面的IP头和TCP头。最上面的IP头20字节和TCP头32字节都是在#550中包含的。因为SNDCP层分段,是不管TCP的包头和数据部分的,这些在SNDCP看来,都是上层的N-PDU。你可以对应wireshark最下面的文本解码区进行验证。


www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 2Rank: 2

发表于 2011-7-11 18:42:05 |显示全部楼层
精辟,受益匪浅!

使用道具 举报

Rank: 8

发表于 2011-7-11 21:33:17 |显示全部楼层
回复 爱卫生 的帖子

Wireshark自己对采集的数据在打开的时候进行了简单的组包,所以看起来有。实际原始信令是需要到MS在进行组包了吧
博学之,审问之,慎思之,明辨之,笃行之

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

发表于 2011-7-12 10:09:33 |显示全部楼层
回复 爱卫生 的帖子

" 这个3164字节属于HTTP应用层。首先交给TCP层,TCP层将根据协商好的MSS为1360进行分段,但实际上在做TCP分段的时候,用的标准是1348字节,因为它将TCP层的option部分的12字节也算进去了。总共是1360字节。但我个人觉得这样做可能是不合规范的"
这句话是不是可以这样理解:
规范:MTU=1360+20ip+20tcp=1400
实际:MTU=(1348+12)+20ip+20tcp=1400
默认1360里含了12bytes的包头?

使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-13 00:10:19 |显示全部楼层
lsjier 发表于 2011-7-11 21:33
回复 爱卫生 的帖子

Wireshark自己对采集的数据在打开的时候进行了简单的组包,所以看起来有。实际原始信令 ...

   确实是Wireshark提供的组包功能。但并不是看起来有,因为Wireshark抓包是对包的镜像抓的,并不是中途截取的。所以这个包实际和在PC上抓是一样的。所以,在PC上重组后的效果和Wireshark软件提供的组包效果应该是一样的。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-13 00:19:53 |显示全部楼层
tobino1 发表于 2011-7-12 10:09
回复 爱卫生 的帖子

" 这个3164字节属于HTTP应用层。首先交给TCP层,TCP层将根据协商好的MSS为1360进行分段 ...

  说说我的理解。
  “规范:MTU=1360+20ip+20tcp=1400
   实际:MTU=(1348+12)+20ip+20tcp=1400”

   按我的理解,应该是"规范MTU=1360+20ip header+20tcp basic header+20 tcp header option=1412
                                     而实际:MTU=(1348+12)+20ip+20tcp=1400”
    这样,正好没有超过IP层的MTU,这样在IP层没有分片。
  上面的MTU准确来说是IP MTU,即IP层的MTU,在IP层交给数据链路层处理的时候,数据链路层也有一个MTU,例如以太网的1518字节(源目的MAC、Type、校验和等),再交给物理层处理。
   因为我个人觉得TCP 根据MSS分段,不应该包括TCP包头中的option部分(12字节),而只应针对payload来分。这样在这个例子里,MTU就超出了,应该要分片,除非将IP MTU设置为1412字节。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

发表于 2011-7-20 11:54:43 |显示全部楼层
回复 爱卫生 的帖子

爱总,请问个问题:200 ok中在TCP层看到的3164bytes和 200 ok中HTTP层看到的 content-length中的6863bytes为什么差好多,哪个才是真正用户访问页面的大小,哪个可以算作用户产生的流量?

使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-22 22:09:53 |显示全部楼层
tobino1 发表于 2011-7-20 11:54
回复 爱卫生 的帖子

爱总,请问个问题:200 ok中在TCP层看到的3164bytes和 200 ok中HTTP层看到的 content- ...

   3164字节是针对这一次HTTP请求所带的内容的组合。但后面的content-length中的6863bytes应该是一个HTTP事务的内容的长度和。但这需要去仔细读一下HTTP协议中关于content-length字段的说明,我简单看了下,发现比较复杂,还涉及到压缩。暂时不能答复你。需要以后有时间深入学习HTTP协议。
   另外,我在本地抓了下包,从本地的IE浏览器去访问http://www.gprshome.com/static/image/common/logo.png 。这是本站的Logo。发现只有TCP的分片,但在HTTP层重组的时候,并没有看到content-length字段。需要具体再去了解它的用法。看是不是要访问页面的多个数据的时候才带着个字段,因为访问一个网站的首页,可能200多K,涉及到10多张图片和多个静态页面的组合,应该不是每个对象都出现content-length。但这个字段和TCP的分段肯定是无关的。
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

发表于 2011-7-27 18:54:08 |显示全部楼层
回复 爱卫生 的帖子

http如果带有content,那么content-length,每个请求或者响应基本上都会带的,除非是利用其它的比如trunk方式传输。

tcp看到的3164是http头+payload的长度。
3164-http头=content-length=2686,而2686是6863用gzip压缩过后的大小,是在手机端解压缩的。
所以用户产生的流量是3164,应该还包括一个tcp头和一个ip头。

使用道具 举报

Rank: 9Rank: 9

懒

发表于 2011-7-27 18:56:07 |显示全部楼层
明白了,多谢! {:soso_e100:}
www.gprshome.com: GPRS及移动通信技术学习交流分享平台。

使用道具 举报

Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6Rank: 6

发表于 2011-7-28 11:03:09 |显示全部楼层
受益很深,晦涩的协议也可以这样来学习,不错

使用道具 举报

Rank: 2Rank: 2

发表于 2011-8-29 09:14:58 |显示全部楼层
受益很深,还需要进一步学习

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-3-29 02:45 , Processed in 0.043633 second(s), 14 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部