序、前言
emmmmm，首先这篇文章讲的不是用binaryformatter来进行结构体的二进制转换，说真的binaryformatter这个类其实现在的作用并不是特别大了，因为binaryformatter二进制序列化出来的结果只能用于.net平台，现在可能就用于如存入redis这种情况下会在使用。
去年年尾的样子，我阅读学习某c++开发的程序源码时，发现作者用了一个很骚的操作直接将byte[]数组转为了结构体对象：
![C#如何从byte[]中直接读取Structure实例详解](/uploads/allimg/220709/091A13W9-0.png "C#如何从byte[]中直接读取Structure实例详解")
上面的data变量是一个指向unsigned char类型的指针，就只要一个简单的类型转换就可以将一堆unsigned char转换成想要的结构体，这着实有点让笔者有点羡慕。
后来，笔者想用c#开发一个流量分析程序，由于需要对ip报文进行仔细的特征提取，所以不能直接使用第三方数据包解析库（如：packetdotnet）直接解析，会丢失部分特征，然而使用binaryreader进行报文头解析的话，整个解析代码会写的丧心病狂的恶（e）心（xin），正在苦恼的时候，突然想起上面提到的那个骚操作时，笔者突然冒出了一个想法，c#里也支持结构体，那我能不能也像c++这样直接从字节序列中读取出结构体呢？
注：本文所有代码在.net standard 2.0上测试通过。
一、先声明，后调用~
那么在开始前，我们先定义一下要用到的ipv4报文头结构体，各位同学ipv4报文头结构有没有忘掉啊，如果忘了的话记得先去补补tcp网络基础哈~
![C#如何从byte[]中直接读取Structure实例详解](/uploads/allimg/220709/091A14b4-1.png "C#如何从byte[]中直接读取Structure实例详解")
因为ipv4头是允许可变长度的，所以我们的结构体只需要解析到目的地址就够了，后面的可变选项部分在报文头前16字节解析完成之前是不知道会有多长的。
ipv4头部结构体定义如下，由于ipv4头部定义中，各个字段并不是都8位整长的，所以有几个字段是相互并在一起的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
public struct ipv4header{ /// <summary> /// ip协议版本及头部长度 /// </summary> private byte _verhlen; /// <summary> /// 差异化服务及显式拥塞通告 /// </summary> private byte _dscpecn; /// <summary> /// 报文全长 /// </summary> private ushort _totallength; /// <summary> /// 标识符 /// </summary> private ushort _identification; /// <summary> /// 标志位及分片偏移 /// </summary> private ushort _flagsoffset; /// <summary> /// 存活时间 /// </summary> private byte _ttl; /// <summary> /// 协议 /// </summary> private byte _protocol; /// <summary> /// 头部检验和 /// </summary> private ushort _checksum; /// <summary> /// 源地址 /// </summary> private int _srcaddr; /// <summary> /// 目标地址 /// </summary> private int _dstaddr;} |
当然，为了方便后续的使用，还可以在此技术上设置一些可读属性：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
|
public struct ipv4header{ /// <summary> /// ip协议版本及头部长度 /// </summary> private byte _verhlen; /// <summary> /// 差异化服务及显式拥塞通告 /// </summary> private byte _dscpecn; /// <summary> /// 报文全长 /// </summary> private ushort _totallength; /// <summary> /// 标识符 /// </summary> private ushort _identification; /// <summary> /// 标志位及分片偏移 /// </summary> private ushort _flagsoffset; /// <summary> /// 存活时间 /// </summary> private byte _ttl; /// <summary> /// 协议 /// </summary> private byte _protocol; /// <summary> /// 头部检验和 /// </summary> private ushort _checksum; /// <summary> /// 源地址 /// </summary> private int _srcaddr; /// <summary> /// 目标地址 /// </summary> private int _dstaddr; /// <summary> /// ip协议版本 /// </summary> public int version { get { return (this._verhlen & 0xf0) >> 4; } } /// <summary> /// 头部长度 /// </summary> public int headerlength { get { return this._verhlen & 0x0f; } } /// <summary> /// 差异化服务 /// </summary> public int dscp { get { return (this._dscpecn & 0xfc) >> 2; } } /// <summary> /// 显式拥塞通告 /// </summary> public int ecn { get { return this._dscpecn & 0x03; } } /// <summary> /// 报文全长 /// </summary> public ushort totallength { get { return this._totallength; } } /// <summary> /// 标识符 /// </summary> public ushort identification { get { return this._identification; } } /// <summary> /// 保留字段 /// </summary> public int reserved { get { return (this._flagsoffset & 0x80) >> 7; } } /// <summary> /// 禁止分片标志位 /// </summary> public bool df { get { return (this._flagsoffset & 0x40) == 1; } } /// <summary> /// 更多分片标志位 /// </summary> public bool mf { get { return (this._flagsoffset & 0x20) == 1; } } /// <summary> /// 分片偏移 /// </summary> public int fragmentoffset { get { return this._flagsoffset & 0x1f; } } /// <summary> /// 存活时间 /// </summary> public byte ttl { get { return this._ttl; } } /// <summary> /// 协议 /// </summary> public byte protocol { get { return this._protocol; } } /// <summary> /// 头部检验和 /// </summary> public ushort headerchecksum { get { return this._checksum; } } /// <summary> /// 源地址 /// </summary> public ipaddress srcaddr { get { return new ipaddress(bitconverter.getbytes(this._srcaddr)); } } /// <summary> /// 目的地址 /// </summary> public ipaddress dstaddr { get { return new ipaddress(bitconverter.getbytes(this._dstaddr)); } }} |
二、byte[]转structure第一版
首先笔者先看了一圈文档，看看c#有没有什么方法支持将byte[]转为结构体，逛了一圈发现一个有这么一个函数：
system.runtime.interopservices.marshal.ptrtostructure<t>(intptr)
这个方法接收两个参数，一个结构体泛型和一个指向结构体数据的安全指针（intptr），然后这个方法就能返回一个结构体实例出来了。
那么现在的问题就是该如何取得一个byte[]对象的安全指针呢？这里笔者第一反应是利用system.runtime.interopservices.marshal.allochglobal方法分配一块堆外内存出来，然后将待转换的byte[]对象复制到这块堆外内存中，接着利用ptrtostructure<t>函数将byte[]对象转换成我们想要的结构体对象实例，最后释放掉堆外内存就可以了。
将上面的步骤转换为c#代码，就形成了第一版的bytestostructure<t>函数：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/// <summary>/// 将 byte[] 转为指定结构体实例/// </summary>/// <typeparam name="t">目标结构体类型</typeparam>/// <param name="bytes">待转换 byte[]</param>/// <returns>转换后的结构体实例</returns>public static t bytestostructure<t>(byte[] bytes) where t : struct{ int size = marshal.sizeof(typeof(t)); intptr ptr = marshal.allochglobal(size); try { marshal.copy(bytes, 0, ptr, size); return marshal.ptrtostructure<t>(ptr); } finally { marshal.freehglobal(ptr); }} |
之后就只要抓一下包看看效果就好了。
抓包我们用sharppcap，顺便让它帮我们过滤一下仅捕获ip报文。代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
public static void main(string[] args){ capturedevicelist devices = capturedevicelist.instance; if (devices.count <= 0) { console.writeline("no device found on this machine"); return; } else { console.writeline("available devices:"); console.writeline("-----------------------------"); } int index = 0; foreach (icapturedevice item in devices) { console.writeline($"{index++}) {item.name}"); } console.write("enter your choose: "); index = int.parse(console.readline()); console.writeline(); icapturedevice device = devices[index]; device.onpacketarrival += new packetarrivaleventhandler((sender, e) => { packet packet = packet.parsepacket(e.packet.linklayertype, e.packet.data); if (packet.extract(typeof(ippacket)) is ippacket ippacket) { ipv4header header = structhelper.bytestostructure<ipv4header>(ippacket.bytes); console.writeline($"{header.srcaddr} ==> {header.dstaddr}"); } }); device.open(devicemode.promiscuous, 1000); device.filter = "ip"; console.cancelkeypress += new consolecanceleventhandler((sender, e) => device.close()); device.capture();} |
启动上面的代码，选择需要捕获数据包的网卡，就可以看到此网卡上所有ip报文记录及其源地址与目标地址了：
![C#如何从byte[]中直接读取Structure实例详解](/uploads/allimg/220709/091A11435-2.jpg "C#如何从byte[]中直接读取Structure实例详解")
三、大端字节序、小端字节序……
刚刚上面我们已经成功的将byte[]对象转换为我们想要的结构体了，但我们转换出来的结构体真的正确吗，我们可以将我们读取出来的结构体和packetdotnet包解析出来的ip报文头数据进行比较：
![C#如何从byte[]中直接读取Structure实例详解](/uploads/allimg/220709/091A121S-3.jpg "C#如何从byte[]中直接读取Structure实例详解")
我们可以看到我们转换出来的ipv4报文头结构体中的报文总长字段和packetdotnet解析出来的数据不一致，我们的转换函数出来的包总长是15872，而packetdotnet解析出来的包总长只有62。
到底谁是对的呢，不用猜，肯定是我们的转换函数有问题，如果看官您不相信，可以用wireshark抓包做比较，看看wireshark会挺谁的结果。
那么到底是哪里错了呢？相信不少有实战经验的看官已经知道问题的原因了：大小字节序。
我们分别将15872和62转为二进制格式：
| 数值 | 15872 | 62 |
| 二进制 | 00111110 00000000 | 00000000 00111110 |
15872和62这两个数字转换为二进制之后，15872的00111110在前面，00000000在后面，而62则正好相反。
一般来说计算机硬件有两种储存数据的方式：大端字节序（big endian）和小端字节序（little endian）。
举例来说，数值0x2211使用两个字节储存：高位字节是0x22，低位字节是0x11。
大端字节序：
高位字节在前，低位字节在后，这是人类读写数值的方法。
小端字节序：
低位字节在前，高位字节在后，即以0x1122形式储存。
在网络中传输数据，一般使用的是大端字节序，然而在计算机内部中，为了方便计算，大多都会使用小端字节序进行储存。
.net clr默认会使用当前计算机系统使用的字节顺序，而笔者测试时用的系统是windows 7 x64，内部默认用的是小端字节序，所以在一切均为默认的情况下，多字节字段在转换后都会因为字节序不正确而读取为错误值。
.net提供了一个属性用于开发者获取当前计算机系统使用的字节序：
system.bitconverter.islittleendian
如果此属性为true，则表示当前计算机正在使用小端字节序，否则为大端字节序。
回到刚刚的问题，为了防止大小端字节序对转换产生影响，我们可以使用attribute对结构体中各个多字节字段进行标记，并在转换前判断字节序是否一致，如果不一致则进行顺序调整，代码如下：
首先定义一个大小端字节序枚举：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
/// <summary>/// 字节序枚举/// </summary>public enum endianness{ /// <summary> /// 大端字节序 /// </summary> bigendian, /// <summary> /// 小端字节序 /// </summary> littleendian} |
然后定义大小端字节序声明特性
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
/// <summary>/// 字节序特性/// </summary>[attributeusage(attributetargets.field)]public class endianattribute : attribute{ /// <summary> /// 标记字段的字节序 /// </summary> public endianness endianness { get; private set; } /// <summary> /// 构造函数 /// </summary> /// <param name="endianness">字节序</param> public endianattribute(endianness endianness) { this.endianness = endianness; }} |
我们在这里使用attributeusage特性限制此endianattribute特性仅限字段使用。
然后是转换函数：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
/// <summary>/// 调整字节顺序/// </summary>/// <typeparam name="t">待调整字节顺序的结构体类型</typeparam>/// <param name="bytes">字节数组</param>private static byte[] respectendianness<t>(byte[] bytes){ type type = typeof(t); var fields = type.getfields(bindingflags.instance | bindingflags.public | bindingflags.nonpublic) .where(f => f.isdefined(typeof(endianattribute), false)).select(field => new { field = field, attribute = (endianattribute)field.getcustomattributes(typeof(endianattribute), false).first(), offset = marshal.offsetof(type, field.name).toint32() }).tolist(); foreach (var field in fields) { if ((field.attribute.endianness == endianness.bigendian && bitconverter.islittleendian) || (field.attribute.endianness == endianness.littleendian && !bitconverter.islittleendian)) { array.reverse(bytes, field.offset, marshal.sizeof(field.field.fieldtype)); } } return bytes;} |
此函数会先使用反射获取所有含有endianattribute特性的公开或非公开实例字段，然后依次求出其偏移，最后判断字段标注的字节序是否与当前计算机的字节序相同，如果不同则进行顺序翻转。另外上面的函数使用了linq，需要引入system.linq命名空间，且linq函数中还使用到了匿名类。
接下来要对转换函数进行修改，只需要在转换前调用一下调序函数即可。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
/// <summary>/// 将 byte[] 转为指定结构体实例/// </summary>/// <typeparam name="t">目标结构体类型</typeparam>/// <param name="bytes">待转换 byte[]</param>/// <returns>转换后的结构体实例</returns>public static t bytestostructure<t>(byte[] bytes) where t : struct{ bytes = respectendianness<t>(bytes); int size = marshal.sizeof(typeof(t)); intptr ptr = marshal.allochglobal(size); try { marshal.copy(bytes, 0, ptr, size); return marshal.ptrtostructure<t>(ptr); } finally { marshal.freehglobal(ptr); }} |
当然了，我们还要对结构体中的各个多字节字段标记上endianattribute特性：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
public struct ipv4header{ /// <summary> /// ip协议版本及头部长度 /// </summary> private byte _verhlen; /// <summary> /// 差异化服务及显式拥塞通告 /// </summary> private byte _dscpecn; /// <summary> /// 报文全长 /// </summary> [endian(endianness.bigendian)] private ushort _totallength; /// <summary> /// 标识符 /// </summary> [endian(endianness.bigendian)] private ushort _identification; /// <summary> /// 标志位及分片偏移 /// </summary> [endian(endianness.bigendian)] private ushort _flagsoffset; /// <summary> /// 存活时间 /// </summary> private byte _ttl; /// <summary> /// 协议 /// </summary> private byte _protocol; /// <summary> /// 头部检验和 /// </summary> [endian(endianness.bigendian)] private ushort _checksum; /// <summary> /// 源地址 /// </summary> private int _srcaddr; /// <summary> /// 目标地址 /// </summary> private int _dstaddr;} |
需要说一点，就是最后的源地址和目标地址，笔者上面用的是
|
1
|
public ipaddress(byte[] address) |
这个构造函数来构造ipaddress类，并且是使用bitconverter.getbytes这个方法将int类型转为byte[]并传入构造函数的，所以不用注明大端序，否则会导致转换结果不正确（错误结果和正确结果会正好颠倒）。
重启程序，看看现在我们的转换函数转换出来的结果是不是和packetdotnet转换结果一样了？
![C#如何从byte[]中直接读取Structure实例详解](/uploads/allimg/220709/091A13525-4.jpg "C#如何从byte[]中直接读取Structure实例详解")
四、性能提升！性能提升！
在解决了大字节序小字节序的问题之后，让我们重新审视一下刚刚上面的转换函数，可以看到在刚才的函数中，每次要从byte[]中读取结构体时，都要经过“申请堆外内存——复制对象——读取结构体——释放堆外内存”这四步，申请堆外内存，复制对象和释放堆外内存这三步照理来说是浪费性能的，明明byte[]已经在内存中了，但就是为了获取它的安全句柄而大费周章的再去申请一块内存，毕竟申请和释放内存也算是一笔不小的开支了。
那除了marshal.allochglobal以外还有别的什么方法能获取到托管对象的安全句柄呢？笔者又去网上找了一下，您还别说，这还真的有。朋友，您听说过gchandle吗？
system.runtime.interopservices.gchandle.alloc
此方法允许传入任意一个object对象，它将返回一个gchandle实例并保护传入的对象不会被gc回收掉，当使用完毕后，需要调用此gchandle实例的free方法进行释放。而gchandle结构体有一个实例方法addrofpinnedobject，此方法将返回此固定对象的地址及安全指针（intptr）。
利用gchandle.alloc方法，就可以避免重复的申请、复制和释放内存了，由此我们对刚刚的第一版bytestostructure函数进行改进，第二版bytestostructure函数闪亮登场：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
/// <summary>/// 将 byte[] 转为指定结构体实例/// </summary>/// <typeparam name="t">目标结构体类型</typeparam>/// <param name="bytes">待转换 byte[]</param>/// <returns>转换后的结构体实例</returns>public static t bytestostructurev2<t>(byte[] bytes) where t : struct{ bytes = respectendianness<t>(bytes); gchandle handle = gchandle.alloc(bytes, gchandletype.pinned); try { return marshal.ptrtostructure<t>(handle.addrofpinnedobject()); } finally { handle.free(); }} |
现在我们来比较两个转换函数的效率试试：
我们使用相同的数据包，让两个转换函数重复运行1000w次，查看两个函数使用的时间差距：
注意：因为调整大小端字节序会使用到反射，会严重的影响到函数本身的运行效率（运行时间大部份都在用于反射），所以在测试时，笔者会注释掉调整字节序调整的代码。
| bytestostructure<t> | bytestostructurev2<t> | |
| 1000w次转换耗时 | 5069 ms | 2914 ms. |
五、榨干潜能，使用不安全代码！
我们在刚刚的代码里通过避免“申请内存——复制数据——释放内存”的步骤来提升函数的执行效率，那经过上面的改造，我们的转换函数还有提升的空间吗？
答案是有的。
c#和java最大的不同点在于c#允许程序员使用不安全代码，这里的不安全代码并不是指一定存在漏洞会被攻击者利用的不安全，而是使用指针的代码。是的！c#允许使用指针！只需要在编译时打开/unsafe开关。
文章一开始的c++代码利用指针进行转换，c#其实也可以：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
/// <summary>/// 将 byte[] 转为指定结构体实例/// </summary>/// <typeparam name="t">目标结构体类型</typeparam>/// <param name="bytes">待转换 byte[]</param>/// <returns>转换后的结构体实例</returns>public static unsafe t bytestostructurev3<t>(byte[] bytes) where t : struct{ bytes = respectendianness<t>(bytes); fixed (byte* ptr = &bytes[0]) { return (t)marshal.ptrtostructure((intptr)ptr, typeof(t)); }} |
这个第三版函数使用了两个关键字unsafe和fixed，unsafe表示此代码为不安全代码，c#中不安全代码必须在unsafe标识区域内使用，且编译时要启用/unsafe开关。fixed在这里主要是为了将指针所指向的变量“钉住”，避免gc误重定位变量以产生错误。
同样，我们注释掉大小端字节序调整函数，再次重复运行1000w次，看看三个函数的用时：
| bytestostructure<t> | bytestostructurev2<t> | bytestostructurev3<t> | |
| 1000w次转换耗时 | 5069 ms | 2914 ms. | 2004 ms |
又比之前缩短了进1s的时间。当然了因为这是重复1000w次的耗时，而因为我们注释掉了大小端字节序调整函数，实际情况下启用大小端字节序调整函数的话，时间会爆炸性的增长。可见反射是一个多么浪费性能的操作。
六、小结
emmmmm，说一个比较尴尬的事情，其实本文讨论的这种byte[]转为结构体的情况其实在日常开发中很少会用到，首先是因为结构体这种数据结构在日常开发中就很少会用到，平时开发的话类才是大头，另外如果是因为要和c/c++开发的dll交互，可以利用.net中system.runtime.interopservices命名空间下的structlayoutattribute、fieldoffset等特性自定义标记结构体的结构，clr会在结构体传入或传出时自动进行托管内存与非托管内存之间内存格式的转换。
所以本文其实是为了后面的博客做服务的，那就是不安全代码，这个看似神秘，实则锋利无比的双刃剑，尽请期待。
原文链接：https://www.yanning.wang/archives/767.html
