とある雑談中に
IT関係の勉強している人にヘッダーとかペイロードの意味がよーわからん。
っていわれた。
自分たち知っている人からしてみれた
は？
ってなるような質問です、ざっくりしすぎてます。
仕様書とかみてて何とかヘッダーとかペイロードとかフレームとかパケットがなんとかとかでてくるけど
さっぱりわからんのよ？
っていわれた。
まぁね、所詮ルールというか決め事のことなのでそういうものだと理解するしかないのですが、
パケットとフレームは確かに間違ってるというか同義としてとらえることもできるようなきもしなくもないししないかもしれない。
そういう意味でいえば自分だって正確には間違ってるかもしれない( ´艸｀)
あってはいけない事なのだがある程度方言的なものもある。うーん難しい( ﾟдﾟ)
※結構長文ですが中身ありません。
情報をやり取りする
どんな経路で通信するかは置いといて、業務設計をする際、必ずヘッダとペイロードの設計は電文設計で必ず実施します。
そうかんがえると、当たり前のようにやっていましたがある程度知識ではなくイメージがあったほうがとっつきやすいのではないかな？っておもいました。
なのでちょこっと考えてみます。
例えばスマホアプリを作るとしてサーバとどんなやり取りデータを送るか？
と設計する場合、考えることはたくさんあります。
が基本は、"0","1"のデジタル信号でデータを送受信する必要があるため、決まり事に従って解読していく必要があるわけです。
どうやって電気信号を・・・とかから言い始めるとはなしがながーーーーくなるので
たとえば電文をまるっと送受信するとしてどういうデータをやり取りするか？を考えるのが簡単かと思います。
例えばスマホでボタンAをユーザが押したよ！っていうのをサーバに送り、結果こうだったよ！みたいなのをサーバから返却するということを前提に考えてみましょう。
プログラムからしてみれば
細かいことはおいといて、
データをなんらかの関数で受信しました。となると、16進数のデータ羅列とそのサイズしか通常わかりません。決め打ちしない限り、、、、
例えば、
100Byteうけとりました。変数にぶち込んでおきます。みたいになります。
今の子だと
JSONだろうからパースすればいいんじゃね？
とかいうのかな？※この意味も分からないような人から質問うけましたけど( ´艸｀)
そんな甘っちょろいこといってたら本質さっぱりわからんようになるよ。
あくまでもJSONでやり取りするという取り決めをした場合JSONであるといえるわけですから。
ようは100Byteでも200Byteでも受け取ったデータを自分たちが使えるデータかどうかを判定する必要があるわけですよ。
そのためにヘッダー部とペイロード部、簡単に言うと目次と本文みたいなものを
やり取りする双方で決めておくわけです。
最初の10Byteがヘッダーです、残りがペイロードです。
みたいなことを決めておくだけです。
決めるのは設計するあなたです。
なのでなんでこうなってるの？っていうのを知りたいなら、設計者に確認です。
JSONだってこういう形式でやり取りしましょう。というのを決めているだけです。
HogeHogeDenbun、HHD高血圧性・・をつくりました！といって公開し、周りにみとめられれば、ほかの人も使ってくれるかもしれません。
例えば電文を作ろうとした場合
自分で決めた電文ヘッダーに
最初必ず0xAAを入れます。と決めるのもよし、0x00ですと決めるのもよしです、それは設計者の自由です。もちろんこの値を使うのはよした方がよいというのもあったりします。
すでに有名なヘッダーと同じとか、バグった時に送られてくる可能性があるパターンを含んでいるとか。。。その辺は経験則が必要になってきますけどそういうものもあります。
簡単な例を挙げると
1Byte目は固定
2Byte目はVersion
3Byte目は電文種別
4Byte目は予備
5Byte目は固定
6Byte目は押されたキー
7Byte目はペイロードのサイズ
8Byte目は予備
9Byte目は予備
10Byte目はチェックサム
みたいなことを決めます。
押されたキーがペイロード部にはいるんじゃねーのかよって突っ込みしないで・・・適当例だから
この決め方で設計者の思想がある程度判断できます。
例えば上記の場合、電文種別の後ろが予備としてあるのはVersionが上がった際電文種別が増えるまたはサブ種別みたいなのがつく可能性を想定している。もしくは種別にもVersionを持たせる気があるのかもしれない。
5Byte目に固定があるということは、全電文4Byteは固定でのこり4Byte*1が電文毎にことなるんだな・・・
なんてことが想像されます。
もしそういう思想で作られているなら、なんでペイロードのサイズが固定の後ろなんだよ設計者はアホか？って突っ込みを入れます。
もし、どうでもいい設計をした場合上記を簡単にしようとすると
1Byte目は電文種別
2Byte目は押されたキー
3Byte目はペイロードのサイズ
の3Byteの最小サイズですむわけです。
長ーいことシステムが稼働し改変を繰り返したり、継ぎはぎされていくと
予備を変な使い方でつかってたりして、電文種別が3Byte目と8Byte目を見ないと分からない。。なーんてこともあるわけです。
すなわちこのシステムが将来どういう使われ方をされどういうところが増えて行く可能性があるか？を設計者はある程度予測しつつ設計しなければいけません。
そしてヘッダーが大きすぎるとそれはそれで無駄になります。
さて、、どうするのがいいんでしょうね？腕の見せ所ですよぉ～
大きいデータを受信する場合は連続するデータを受ける必要があります。なのでよく先頭データである、次があるよフラグ、これが最後ですよフラグなんてものも使います。
余談ですが
200個データを受け取らないと1つのデータが完成しないとかになった場合、データ欠損や、順序がバラバラなこともよくあります。なので連番をつけて、足りないものがあれば再要求するなんてことも考える必要が出てきます。
そもそも垂れ流してるデータを受け取ってそろったら使うなんてシステムなんてものもあります。一番分かりやすいのがTVですね、電波は常にでています。受け始めるのはいつになるかわかりません、動画のストリームデータであれば欠損しながらでもなんとかなりますが、データ放送とかでテキストや画像を送るよって言った場合１Byteでもかけていれば構築できません、事故です事故。さーどうやって処理してるんでしょうね？
ARIBの仕様書読んでみましょうｗｗｗｗ
脱線しまくり
次に、、ペイロード部ですが、ぶっちゃけペイロード部は本体なので例えば画像をおくるよってなれば残りは画像データだったり、文字データであればメッセージがかかれているだけなのでこれまた決まりに従った方法で読み込んでいくだけです。
んじゃヘッダーいらねーじゃん
ってなりますよね。ぶっちゃけ全部自分で決めてるデータであれば
ヘッダーもペイロード部も一緒です( ´艸｀)
もともこもない発言ですね。
本だって目次や概要なしでいきなり本文から始まっているものもあるじゃないですか。
それとおんなじです。
なのでようは決め事です。
単純にヘッダ部分は送ってきたデータの種別や正当性を分かりやすくまとめた部分、ペイロードは送ったデータの本体が入っている部分。
ぐらいにうけとめればいいのです。
面白いものだと、ヘッダーが1KByte以上あるのに、データ（ペイロード部）は１Byteしかない。
とか普通にあります。
受信側の応答としてOK、NGを返すだけとかね、、、、本体は１Byteでいいんですよ。
そういう場合は大抵ヘッダーだけで結果とペイロード有無フラグ（もしくはSize0）とかになります。
まとめ
なにがいいたかったかというと、ただの決まり事なので、
電文や受信データを利用する場合はその構造をちゃんと理解すること、自分で作る場合は自由に設計できるけど、適当に作ると笑われるよ！ってことですね。
