请教大家一个关于Gbover IP的问题

watson100

附件是我们在现网实际环境中抓的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不能处理大包）

多谢各位指教。

watson100

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

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

爱卫生

回复 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。就像第一步提到的那样。

watson100

没有仔细看楼主原来的帖子，真是惭愧。
另外还有一个问题,在[44.064]里面SAPI=3的N201-U的默认值是500，
我们希望能把这个值提高，以此来提高数据的传输效率（因为包头少了）。

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

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

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

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

tobino1

回复 爱卫生 的帖子

爱总，从你的回答中看有几个疑问：

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

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

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

爱卫生

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秒一样，也是根据当时的用户行为调研出来的。

爱卫生

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最下面的文本解码区进行验证。

z36306610

精辟，受益匪浅！

lsjier

回复 爱卫生 的帖子

Wireshark自己对采集的数据在打开的时候进行了简单的组包，所以看起来有。实际原始信令是需要到MS在进行组包了吧

tobino1

回复 爱卫生 的帖子

" 这个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的包头？

爱卫生

lsjier 发表于 2011-7-11 21:33
回复 爱卫生 的帖子

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

   确实是Wireshark提供的组包功能。但并不是看起来有，因为Wireshark抓包是对包的镜像抓的，并不是中途截取的。所以这个包实际和在PC上抓是一样的。所以，在PC上重组后的效果和Wireshark软件提供的组包效果应该是一样的。

爱卫生

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字节。

tobino1

回复 爱卫生 的帖子

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

爱卫生

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的分段肯定是无关的。

weishengzi

回复 爱卫生 的帖子

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

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

爱卫生

明白了，多谢! {:soso_e100:}

mobileice

受益很深，晦涩的协议也可以这样来学习，不错

gcygcy

受益很深，还需要进一步学习