hdfs中很重要的一个流程就是数据的读写，但在此之前，需要先了解数据是如何传输的，数据包的具体的传输格式是怎样的，本文就此进行总结说明。
【数据包格式】
要了解客户端写hdfs是如何组织数据的，需要先了解三个概念：block，packet，chunk。
- block
这个大家应该比较熟悉，hdfs中的文件就是由一个或多个block组成的，block的大小是可以配置的，默认是128MB。
- chunk
客户端与datanode的数据传输中进行数据checksum计算的大小。该大小可以配置，默认是512字节。
也就是说，传输数据中，每512个字节进行一次checksum计算，并生成4字节长度的checksum。因此，chunk最大长度为512字节（为什么说最大长度是512字节，因为可能存在最后一个chunk数据长度不足512字节的情况，也会当做一个完整的chunk进行发送）
- packet
介于chunk和block之间的一个单位，也是数据传输的基本单元，即客户端每次是按照一个packet进行数据发送的。
packet有固定的格式，如下图所示：
首先是4字节的packet长度（PLen）；然后是2字节的packet header长度（HLen）；接着是packet header，长度由HLen指定，再接下来是checksum列表和chunk数据列表。chunk和checksum一一对应，即有多少个chunk就有多少个checksum
packet header是按照protobuf进行编码传输的，主要包括这么几个字段：
message PacketHeaderProto {
// All fields must be fixed-length
required sfixed64 offsetInBlock = 1;
required sfixed64 seqno = 2;
required bool lastPacketInBlock = 3;
required sfixed32 dataLen = 4;
optional bool syncBlock = 5 [default = false];
}- offsetInBlock
数据在block中的偏移位置 - seqno
packet包的序号 - lastPacketInBlock
是否是block中的最后一个packet - dataLen
数据长度 - sycnBlock
指示该block是否需要datanode写完后执行sync动作，将数据刷到磁盘中
以上是一个正常数据包的格式说明。
如果客户端不是连续写入，客户端会有心跳保活机制，也就是定时向datanode发送心跳包。
心跳包的组织也是按照packet方式进行的，区别在于packet header中的几个字段的值是固定的。例如：offsetInBlock为0，seqno为-1；并且packet中没有checksum和chunk数据列表。
在写完一个block时（可能是一个block写满128MB，也可能还未达到128MB，但文件已经写完，需要关闭文件），此时，客户端会构造一个没有chunk数据的packet，同时通过packet header的lastPacketInBlock中设置为true，告知datanode，该block已经写完，准备进行相应的结束动作。这就是所谓的空数据包。
通常请求和响应都是成对的。因此，有请求数据包，自然就有对数据包应答的ack包。
ack包形式比较简单，就是一个protobuf的编码数据，原始信息为：
message PipelineAckProto {
required sint64 seqno = 1;
repeated Status reply = 2;
optional uint64 downstreamAckTimeNanos = 3 [default = 0];
repeated uint32 flag = 4 [packed=true];
}【抓包分析】
正常数据包：
结合前面的描述，可以清楚的了解到packet数据包的组成格式。
【其他组织形式】
考虑一种情况：客户端打开文件，第一次写入了300字节，然后关闭文件。接着重新append打开文件，追加写入300字节。
对于第二次的写入，按照上面的分析，理论上，客户端的数据应当是组成一个packet，其中chunk大小为300字节，发送给datanode。
然而通过抓包分析，第二次发送的300字节数据，却划分成两个packet进行了发送。
第一个packet，包含一个chunk，chunk的大小为212字节，剩余的88字节作为一个chunk，放到第二个packet中发送。
为什么会这样呢？
其主要原因是：在datanode中，对存储的数据都尽量按照完整的chunk大小进行checksum计算和存储，只有block的最后一个数据按照实际大小进行checksum和存储。
也就是说对于append操作，datanode将接收到的数据，先进行补齐操作，然后重新按照一个完整的chunk大小进行checksum计算，并覆盖原有的checksum，然后保存到文件中。
因此，出于效率的考虑，这个真正的补齐动作在客户端进行，而不是在datanode中，即客户端append打开文件后，先获取追加写入的偏移位置，计算出应该补齐的chunk数据长度，并以该长度构造对应的packet进行发送，后续的数据则继续按原有的逻辑组织chunk，packet进行发送。
这样在datanode在处理客户端发送的packet时，不需要额外再对数据进行切割补齐，大大减少了相应的处理逻辑。
【总结】
本文对hdfs数据传输的格式进行了详细说明。实际上，客户端服务端对数据也是按照packet，chunk形式组织，并构造逻辑的缓存区域，来进行数据的发送和接收。有了这个基础，接下里就可以深入分析hdfs的读写流程了。
