求pdp激活信令内容详解，怎么看出是否为HTTP业务接入请求？

妖怪的故事

SysMsg
.ulSenderCpuId: ---- 0x50a80d12(1353190674) ---- 01010000,10101000,00001101,00010010
.ulSenderPid: ---- 0x7b(123) ---- 00000000,00000000,00000000,01111011
.ulReceiverCpuId: ---- 0x50a80d12(1353190674) ---- 01010000,10101000,00001101,00010010
.ulReceiverPid: ---- 0x74(116) ---- 00000000,00000000,00000000,01110100
.gb-msg-header-ns
..uoip-head-reserved
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0x2(2) ---- 00000010
...UINT8: ---- 0x70(112) ---- 01110000
...UINT8: ---- 0x0(0) ---- 00000000
...UINT8: ---- 0xff(255) ---- 11111111
..msg
...bssgp-ns-unitdata
....spare
.....auc: ---- 0x0184000000000000000F0000027600C72F185E0000201682025813 ---- 00000001,10000100,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00001111,00000000,00000000,00000010,01110110,00000000,11000111,00101111,00011000,01011110,00000000,00000000,00100000,00010110,10000010,00000010,01011000,00010011
....nseindex: ---- 0x0(0) ---- 00000000,00000000
....bvci: ---- 0x1d(29) ---- 00000000,00011101
....lsp: ---- 0x33a(826) ---- 00000011,00111010
....ns-sdu
.....msg
......unit-data
.......tlli: ---- 0x87a98ef0(2276036336) ---- 10000111,10101001,10001110,11110000
.......qos
........peakbitrate: ---- 0xc(12) ---- 00000000,00001100
........reserved: ---- '00'B(00 ) ---- 00******
........c-r: ---- '0'B(00 ) ---- **0*****
........t-bit: ---- '0'B(00 ) ---- ***0****
........a-bit: ---- '0'B(00 ) ---- ****0***
........precedence: ---- '000'B(00 ) ---- *****000
.......cell-id
........len-ex-bit: ---- 0x1(1) ---- 1*******
........length: ---- 0x8(8) ---- *0001000
........cellid: ---- 64F01072E0005407 ---- 01100100,11110000,00010000,01110010,11100000,00000000,01010100,00000111
.......align-octet
........len-ex-bit: ---- 0x1(1) ---- 1*******
........length: ---- 0x0(0) ---- *0000000
.......llpdu
........len-ex-bit: ---- 0x0(0) ---- 0*******
........llPdu
.........address-field
..........pd: ---- llc-frame(0) ---- 0*******
..........cr: ---- 0x0(0) ---- *0******
..........x1: ---- 0x0(0) ---- **00****
..........sapi
...........gmmFormat
............formatType
.............uiFormat
..............xspare1: ---- 0x0(0) ---- ***0****
..............xspare2: ---- 0x0(0) ---- ****0***
..............nu: ---- 0x3(3) ---- *****000,000011**
..............e: ---- 0x0(0) ---- ******0*
..............pm: ---- 0x1(1) ---- *******1
..............information
...............l3msg
................sm-msg
.................ti
..................transaction-value: ---- 0x0(0) ---- *000****
..................transaction-flag: ---- 0x0(0) ---- 0*******
.................msg
..................act-PDP-CONTEXT-REQUEST
...................nsapi: ---- 0x5(5) ---- 00000101
...................llc-SAPI: ---- 0x3(3) ---- 00000011
...................qos
....................reliability-class: ---- subscribed-reliability-class(0) ---- *****000
....................delay-class: ---- subscribed-delay-class(0) ---- **000***
....................spare2: ---- 0x0(0) ---- 00******
....................precedence-class: ---- subscribed-precedence(0) ---- *****000
....................spare1: ---- 0x0(0) ---- ****0***
....................peak-throughput: ---- subscribed-peak-throughput(0) ---- 0000****
....................mean-throughput: ---- best-effort(31) ---- ***11111
....................spare3: ---- 0x0(0) ---- 000*****
....................qos99
.....................delivery-of-err-SDU: ---- subscribed-delivery-of-erroneous-SDUs(0) ---- *****000
.....................delivery-order: ---- without-delivery-order(2) ---- ***10***
.....................traffic-Class: ---- subscribed-traffic-class(0) ---- 000*****
.....................max-SDU-size: ---- 0x0(0) ---- 00000000
.....................max-bit-rate-up: ---- subscribed-maximum-bit-rate-for-uplink-in-ms-to-network-direction-Or-reserved-in-network-to-ms-direction(0) ---- 00000000
.....................max-bit-rate-down: ---- subscribed-maximum-bit-rate-for-uplink-in-ms-to-network-direction-Or-reserved-in-network-to-ms-direction(0) ---- 00000000
.....................sdu-error-ratio: ---- subscribed-SDU-error-ratio(0) ---- ****0000
.....................residual-BER: ---- subscribed-residual-BER(0) ---- 0000****
.....................traffic-priority: ---- subscribed-traffic-handling-priority(0) ---- ******00
.....................transfer-delay: ---- 0x0(0) ---- 000000**
.....................guar-bit-rate-up: ---- subscribed-maximum-bit-rate-for-uplink-in-ms-to-network-direction-Or-reserved-in-network-to-ms-direction(0) ---- 00000000
.....................guar-bit-rate-down: ---- subscribed-maximum-bit-rate-for-uplink-in-ms-to-network-direction-Or-reserved-in-network-to-ms-direction(0) ---- 00000000
.....................srcstatdesp-sigind-spare: ---- 0x0(0) ---- 00000000
.....................maximum-bit-rate-for-downlink: ---- 0x0(0) ---- 00000000
.....................guaranteed-bit-rate-for-downlink: ---- 0x0(0) ---- 00000000
...................pdp-Addr
....................pdpTypeOrg: ---- ietf(1) ---- ****0001
....................spare4: ---- 0x0(0) ---- 0000****
....................pdpTypeNum: ---- ipV4(33) ---- 00100001
...................prot-conf-opt
....................configuration: ---- 0x80C023160100001600102A2A2A2A2A2A2A2A2A2A2A2A2A2A2A2A80211001020010810600000000830600000000 ---- 10000000,11000000,00100011,00010110,00000001,00000000,00000000,00010110,00000000,00010000,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,00101010,10000000,00100001,00010000,00000001,00000010,00000000,00010000,10000001,00000110,00000000,00000000,00000000,00000000,10000011,00000110,00000000,00000000,00000000,00000000
........fcs: ---- 0xA9C9AF ---- 10101001,11001001,10101111

爱卫生

回复 妖怪的故事 的帖子

应该看不出来的。控制和用户面是独立的。就像在家用ADSL拨号一样，抓到这个PPPOE的报文是看不出来你要访问HTTP还是FTP的。另外，PDP上下文的激活可以由AT指令集来完成，只需要指定APN就可以，并不需要指定上层业务的信息。只能从请求的Qos profile来看这是一个大致什么类别的业务，是否背景类的还是交互式的，是否有GBR。但这并不能保证一定是HTTP。

妖怪的故事

回复 爱卫生 的帖子

那我把我遇到的问题详细描述下，麻烦兄弟知道下！
由于运营商没有架构自己的HTTP专用服务器，所以现在的测试采用的是公网HTTP服务器。现在要求做的方案是，根据公网HTTP测试结果大致估算架构自己的专有HTTP测试服务器后的时延，而我手里有路测的信令数据、以及后台无线信令抓包（UM+ABIS+GB），SGSN以上的信令就看不到了。

问题1：从哪条信令可以判断用户的业务请求是HTTP?
问题2：从哪条信令开始到哪条信令结束，可以估算是无线这边的业务请求已经走完，等待公网HTTP服务器响应？

mobileice

回复 爱卫生 的帖子

能不能通过TCP的port确定呢？一般HTTP用的都是80或8080端口。不过我好像也遇到过HTTP用其它端口的，会不会跟上层应用程序有关呢，不是很确定。

爱卫生

回复 妖怪的故事 的帖子

是只有信令包吗？没有数据报文？如果能够抓到用户面的Um和Gb口的用户面报文，那应该能直接看到HTTP这一层的数据啊。在HTTP之前，有一个TCP的三次握手过程，HTTP的服务器会回一个SYN ACK。正如楼上mobileice提到的，默认端口号是80端口。从MS发出TCP的Syn握手报文开始，就可以看成要等到公网HTTP服务器的响应了。

如果只能抓到GMM层3信令，里面可能就没有HTTP相关的信息了。

行虚名座画

看port 80，再得到pdp激活给MS分配的ip地址，自己上浏览器上输入一下即可。GMM信令里面没有HTTP相关信息吧