通信プロトコルの基礎。その3/4。著者:吉田作太郎

10.ネットワーク通信の有用性。

 一般のコンピューター通信とは、1対1の通信である。
RS232Cとか、USB端子は、1対1の通信しかできない。
この点、LANだと、次の事ができる。
○ 一つの装置の一つの回線で、複数の装置をコントロールする事が可能。
○ 一つの装置の一つの回線で、複数の装置からの仕事の依頼を受け付ける事が可能。
この2点の特徴を生かして、システム作りができる。
ちなみに、インターネット回線だと、世界中のコンピューターとアクセスできるという特徴があり、この利点を生かして、コンピューター通信をする事が可能である。


11.パケット通信に関して。

世界中にインターネットによるデーター通信の通信網が設置されている。
このデーター通信の通信網の装置の仕様を簡略化するためにパケットを使う事となっている。
長すぎる通信電文は、インターネットの接続網に接続できない。
ここで、データーを送信する装置は長すぎる電文を区切って、パケットとして分解してインターネットの送信網に送り、データーを受信する装置は、このパケットを組み立て直して、元の電文を作り上げて、長い電文をインターネットの送受信網を介して送受信するために、インターネットはパケット通信を採用している。
 なぜ、データー通信には、パケットが使われるか?
パケット通信網の間にある中継局のバッファーの余裕を与えるためである。
長さが不特定な通信電文ならば、その電文を中継する中継局には収まらないぐらいの大きなメモリーを使わなければならない。
場合により、通信電文長の長さによるエラーが発生する可能性が高い。
そのために、長い電文を伝送路に使わせないために、長い電文を短いパケットに区切って活用するためにパケット通信する事を考え出された。
 このパケットは、インターネット網だけではなく、LAN網においても有効である。
例えば、LAN同士を接続するスイッチングハブやルーターなどの機器にも有効である。

11.1.パケット通信によるデジタル通信の中継局に関しての考察。

○ 通信電文をパケット化して、そのパケットをまた同じ通信電文に組み立てる仕様が必要。(中継局以外の送信局、受信局)
○ 通信品質の向上のためにパケット一つ一つに対してエラーチェックして、もし、エラーが発見されれば、パケットの送り先に同じパケットを再送してもらう様にする仕様が必要。(中継局以外の送信局、受信局)
○ パケット・エラーによるリトライシーケンスは、エラー発生時(タイムアウトとデーターエラー)、再送してもらうが、再送してもらう回数の限度を設ける事。
○ パケット・エラー発生時、もし、パケットを再送する回数が限度を超えてしまうというエラーが発生した場合、そのパケットは無視する事。無視して無くなったパケットは、受信局が通信電文を組み立てる時のチェックで、通信電文をパケット化した装置から再送要求を出す。それでも、エラーであり続けるのならば、その通信電文を無視する事。
○ 通信伝送路の障害で、「無視されて伝送漏れのあるパケットデーター」と「正常なパケットなのにエラーと判断されて出来た複数の同じパケットデーター」のパケット障害の尻ぬぐいをするのは、データーの送り元と受信先のプロトコルによって対応する事。
○ パケットには、通信電文をパケット化しているデーターと、通信電文の送り元と送り先のアドレス情報、それに、エラーチェックのためのデーターが最低限必要。
○ これらの処理を実現するためには、マルチタスクOSが欠かせない。
○ データー通信の中継局は、マルチタスクでなければ処理をする事は不可能である。受信した各パケットに関して一つずつパケットデーターのエンティティーを持ち、それを中継局が他の中継局へ再送する時、パケットデーターの中身がきちっと送信できたかをレスポンスによって確認し、正常であれば、パケットデーターのエンティティーを削除して使えない様にする。また、エラーによるリトライシーケンスの回数が多すぎる場合、パケットデーターのエンティティーを削除して使えない様にする。
以上の様な仕様が必要であろう。
 要は、エラーがあれば、リトライシーケンスを繰り返してエラー復旧を図るが、それでもダメな場合は、無視する事によって、ノンストップのデジタル通信の中継局を実現させる事が大事である。
 次にデジタル通信の中継局は、マルチタスクでなければならない。
パケットデーターを受信したら、いったんキューにため込んで、一つずつパケットを取り出して、データー分析して正常ならば、そのパケットデーターを送り出す。
これによって、パケットデーターは、伝送路に関して隙間無くデーターを送る事が可能となる。
それには、マルチタスクでなければ、対応できない。
もし、シングルタスクでやろうとすれば、パケットデーターは、伝送路に関して隙間無くデーターを送る事はできないので、伝送路の有効活用はできないため、伝送速度はいちじるしく低下する。
 次に輻輳(ふくそう)対策について考える。
パケット通信によるデジタル通信の中継局が、あまり、通信データーが多すぎてパンクしそうになる状態を輻輳と呼ぶ。
こういう時は、中継局に望まれるのはノンストップである事である。
そのためには、伝送データーを間引きする事で、デジタル通信の中継局がノンストップである事を持続し続けていなければならない。
この時、デジタル通信の中継局に「無視されて伝送漏れのあるパケットデーター」と「正常なパケットなのにエラーと判断されて出来た複数の同じパケットデーター」が存在する事となる。
中継局の仕様とは、こんなもので、完璧に通信データーの品質保証をする事はできない。
だから、最終的にデーターの面倒を見る装置は中継局の両端にあるデーターを送受信している装置であり、それが、最終的に全てのデーター通信の尻ぬぐいをする事となる。
 問題点。
○ パケットの順番、データーの順番が、
  順番通りに伝送されない事がある。
 利点。
○ データーを一度、メモリーにためて送受信するので、
  デジタル通信網での通信速度が違っても対応できる。

11.2.OSIとTCP/IP。

 OSIに関する本を読んでみたが、分らなかった。
どんな目的があってOSIの7つの階層があるのかは全然分からなかった。
このプロトコルは、リカバリー処理もないしシステムとしてやってゆけるのだろうかという疑問を持った。
だから、勝手に自分流の考えで推測したOSIの事を考えTCP/IPの事を考えた。
すると、OSIもTCP/IPも、リカバリー処理を考慮していない通信プロトコルである事がはっきりした。
更に、ポーリング電文による相手の局の存在確認や状態確認するという仕様は規定されていないのである。
リカバリーする処理、ポーリングの活用による各種のサービスする処理は、この通信プロトコルを利用して別途、独自に作ってゆかねばならない処理なのである。
以下は、その結論を考慮した上でののOSIとTCP/IPについての考察である。

OSIの7つの階層。

アプリケーション層 :不明。
プレゼンテーション層:不明。
セッション層  :今まで記述してきたRS232Cの
         通信プロトコルが担当できる部分。
トランスポート層:電文とパケットの変換に関する仕様を担当。
ネットワーク層 :パケットのネットワークの接続ルーティングに
         関する仕様を担当。
データーリンク層:物理層同士間のパケット通信の
         プロトコルに関する仕様を担当。
物理層     :通信するハードウェアに関する仕様を担当。

 まず、TCP/IPは、物理層からセッション層までしかなく、このセッション層が、すでにアプリケーション層となっていると推測する。
アプリケーション層の切り替えは、トランスポート層に番号があって、その番号に従って、それぞれのアプリケーションに対して、トランザクション・データーの送受信ができる様になっているのではなどと推測する。
 では、OSIのアプリケーション層、プレゼンテーション層、セッション層とは何か?
まずは、プレゼンテーション層を中心にして考える事が妥当であろう。
電文を送信する場合のプレゼンテーション層の役目とは、それぞれのアプリケーションから出るトランザクション・データーを結合させてまとめて電文としてセッション層に送る。電文を受信する場合のプレゼンテーション層の役目とは、セッション層から受け取った電文をトランスポート層がそれぞれのアプリケーションに対して分配する。
このパケットで生成された電文からそれぞれのアプリケーションを動かすトランザクション・データーまでのデーターの入出力のコントロールするために、この3つの層があるのではないかと推測する。
つまり、TCP/IPとOSIの通信プロトコルの思想は、この部分が大きく違っているのだと考える。
ただし、トランスポート層とネットワーク層とデーターリンク層と物理層に関しては、TCP/IPもOSIも共通の意味によって取り扱う事ができると推測する。
それは、送信する場合は1つの電文から複数のパケットを作るという仕様と、受信する場合は複数のパケットから1つの電文を作り出すという仕様を満足させる事である。

 ここでは、セッション層と物理層の説明は無視しておく。
セッション層とは、トランザクション・データーという電文を取り扱うものだという事にしておいて、何も検討をしない事にしておこう。
物理層とは、通信に使われるハードウェアの仕様と考えておいて、無視して何も考えないでおく事にしておこう。

 次に、ネットワーク層とデーターリンク層に関して。
TCP/IPにおけるネットワーク層とは、IPに関わる部分であり、ここで、インターネットのネットワークを管理しているとの事である。
また、データーリンク層において、特にパソコンで使われているイーサーネットの役割は、物理層で指定されたMACアドレスによりLAN内の各装置にアドレス指定してパケット通信ができる様になっている。
ここに、インターネットのネットワーク用とLAN用のネットワークの識別方法があり、二重にネットワークが識別されている仕組みがあって重複している様だ。
しかし、なぜか、この二重化されたネットワークに、それぞれ別の使い方があるらしい。
例えば、ハブやブリッジは、物理層とデーターリンク層のLANのみを管理するが、ネットワーク層のIPアドレスの識別をする事は無い。
だが、ルーターは、ネットワークをIPアドレスで識別管理でき、それと同時に物理層とMACアドレスで管理されているデーターリンク層のLANもしっかり管理できる様になっているのである。

 ここで、二重になっているネットワークを接続し管理する装置について説明する。
リーピーター:物理層同士の接続する装置。
ブリッジ:外部のデーターリンク層を制御して
     LAN同士を接続する装置。
       外部のデーターリンク層を制御し、
       自物理層を管理する。
ハブ  :LAN内のデーターリンク層同士を制御して
     LANを作り上げる装置。
       外部のデーターリンク層を制御し、
       自物理層を管理する。
ルーター:外部のネットワーク層を制御して
     LANとLANを分離する。
       自データーリンク層を管理し
       自物理層を管理する。

次に、トランスポート層とは、送信の時は電文からパケットを作り、受信の時はやって来たパケットを組み合わせて電文にもどす事を目的とする。
また、それと同時に、1つの物理層に対していくつもの送受信チャンネルを論理的に作り出す事が可能な仕組みを目指して作られ、そのため一つの物理層に対して多くの局と同時送受信可能となり、マルチタスクの各タスクが一つの物理層からそれぞれの局と同時通信可能になる様に作られている。

次は、TCP/IPについて。
TCPとは、トランスポート層のプロトコルであり、IPとは、ネットワーク層のプロトコルである。
IPとは、インターネット用のアドレスにTCPで作られたパケットがアクセスする仕様。
ここで、TCP/IPを使って、セッション層から通信プロトコルを見ると、物理層では一本しかない接続が、多くの他の局の回線と物理的に接続されて並列的に送受信する事ができる様になっており、マルチタスクにおける各タスクが同時にこのTCP/IPを使用する事ができる様になっている。
このTCP/IPによって、マルチタスクの複数のタスクと他のネットワークの局との多対多の接続が可能になっているのである。
TCP/IPを使う場合、シングルタスクには意味は無い。
マルチタスクを有効に活用する通信のために有るのである。
しかしだ。
仕様をかなり限定して、シングルタスクのみで動く1チャネルで動くシングルなアプリケーション上で動かすだけの開発ならば、開発の難易度を考えると、シングルタスクのOS上でTCP/IPを開発する事ができ、最低限のネットワーク装置がある小規模なソフトウエア開発として、大いに意味あるTCP/IPのソフトウエアができるかもしれない。
 ここで、オンライン・アプリケーション開発に関して言えば、データーリンク層のMACアドレスとネットワーク層のアドレスを考慮して、セッション層では、各アプリケーションによっての通信プロトコルを決定して設計してゆく事が肝要である。

11.2.1.セッション層の工夫。
 今までの通信電文の送受信は、セッション層のプロトコルと規定しておけば、あらゆるネットワークと接続できるプロトコルが作られる事となると考えられる。
その場合、データー送信が、成功したかどうかなる問題を、データーリンク層、ネットワーク層、トランスポート層の情報を見て判断して、新たに通信プロトコルを作るのではなく、セッション層の通信プロトコルを、今まで述べてきた全二重に対応する通信プロトコルをそのまま流用して活用すれば良いだろう。
 さて、ここで、トランスポート層とは、パケットの順番管理をしてきた層であるが、短い電文の場合、トランスポート層での電文の順番管理は役に立たない場合が考えられそうである。
理由は、ネットワークにおいて電文を送る順番が前後して、正しい順番の命令(トランザクション・データー)を送れなくなくなる可能性が出てくるからである。
そういう場合、電文の順番管理をセッション層で面倒を見る仕様を作った方が良いと思う。
また、セッション層で作る電文が短いものなのならば、トランスポート層は、セッション層で作った電文をそのままパケットにしてしまうのもアイデアの一つであると考える。

11.2.2.送信権の確保の工夫。(全4重通信の構想)
 送信権の確保のためにはポーリングなどの技術を活用してきた。
今までのRS232C型のポーリングのあるプロトコルを活用すると、一つのポートを利用して送信権の確保する仕組みを持たせてセッション層で電文を送受信する事ができる。
しかし、TCPの活用を考えれば、いくつものポートを活用する事ができるので、特にポーリングの技術によって送信権の確保をせずとも、送信用に2つのポートを確保し、受信用に2つのポートを確保し、電文の送受信に関してリトライシーケンスのあるプロトコルを作る事が可能である。
ただし、ポーリングする仕様は、接続チェックしてリカバリーの仕様を満足するためには使われ続けなければならないだろう。
すると、通信で使われてきた、「送受信タスク」は、役割分担して「送信タスク」、「受信タスク」として、それぞれ全二重通信してリトライシーケンスの仕様と、接続チェックしてリカバリーできる仕様を満足させる事が可能となるだろう。
つまり、「全二重通信×2=全4重通信」という通信スタイルも考えられるという事である。

11.2.3.マルチタスクとパケット。
 一台のコンピューターのネットワークに接続する部分は一つだけである。
その中身とは、ネットワークにデーターを受信する部分と送信する部分である。
そして、この二つの部分だけで、コンピューターは内部に複数あるプログラムからそれぞれの通信処理をこなさなければならない。
この仕様を満たすためには、マルチタスクを使いこなさなければならない。

 ネットワークからデーターを受信する側は、受信したデーターを各タスクにタスク間通信を経て分配せねばならない。
それは、受信したデーターの各ヘッダーに使われているネットワークアドレスによって判断して各タスクにタスク間通信を経て分配するのである。
もし、どのタスクにも使われていないネットワークアドレスの電文であるならば、無視する事となるだろう。
ネットワークへデーターを送信する側は、各タスクからの送信するデーターをタスク間通信を経て集めたデーターを順番に送らなければならない。
このデーターは、各タスクからタスク間通信によってデーターを受け取り、そのデーターをネットワークへデーターを送信するタスクへのタスク間通信のキューに接続して、そのキューから受け取ったデーターをそのままデーター送信処理によって送信すれば良いであろう。
この時、送信するデーターは、送信する電文のデーターだけではなく、受信したデーターに対するレスポンス(「ACK」、「NAK」などの制御文字)も含まれる事となる。
その上で、データーを送受信する各タスクは、データー通信プロトコルを持って、データーの送受信の仕組みを作る事ができていなければならない。

 もし、簡略化したTCP/IPの通信プロトコルを備えたソフトを作るとするならば、TCPは、1パケットの範囲内での通信で簡略化して、データーリンク層の部分をしっかり設計して通信を行えば、組み込み系の範囲内ならば、充分実用化になる設計をする事ができる様になるだろう。

シングルタスクでも、TCP/IPを作る事が可能かもしれないが、データー送受信以外にも、コンピューターのプログラムを動かさなければならない時は、どうしても、マルチタスクを使用せねばならないだろう。
 特に並列処理を実現しているマルチタスクにおいて、パケット通信は相性が合う。
シングルタスクのデーター通信は1チャネルしか通信できない。
しかし、ここでマルチタスクによるデーター通信を取り入れると、コンピューターの一つの物理チャネルに仮想的なマルチ(複数)チャネルのデーター通信が取り扱えるので、マルチタスク上で同時並行に動作している各アプリケーションに同時データー通信を実現させる事ができるのである。

11.2.4.TCPとUDP。
 OSIのトランスポート層に関して、
送信する時、電文をパケットに分けて出力し、
受信する時、パケットを電文にまとめて入力するのが、TCPというトランスポート層のプログラムである。
このTCPというトランスポート層でパケットを作らないで電文をそのまま送受信するプログラムの事をUDPと呼ぶらしい。
ここで、TCPを使わず、UDPにて電文を送受信するUDP/IPのプログラムを使う場合、TCP/IP同様に今まで解説してきた通信プロトコルの基礎は役に立つと思う。

11.2.5.データーリンク層によるネットワーク通信。
 データーリンク層には、MACアドレスなるものがあるから、これだけでもネットワーク通信が可能である。
ただし、インターネットのネットワークは使えないのが難点である。
インターネットを使わないで、ハブなどを使って自ネットワーク内ならば、データーリンク層内だけの通信は可能だと言えるであろう。
ただし、パケット通信よりも長いトランザクション・データーの通信電文には不向きである。
パケットぐらいの長さの短い通信電文で自ネットワーク内の通信ならば有望な通信であろう。(推測)

11.2.6.コミュニケーションとは記憶を共有する事だ。
さて、余談として、ここで、このトランスポート層のTCPのプログラムのメカニズムを空想してみる。(本当は、トランスポート層もTCPもほとんど知らないから、イマジネーションで単純化したモデルを空想し、シミュレーションしてみる。)
送信する側はトランザクション・データーを分割してパケットデーターとして送信したら、受信する側のトランスポート層のプログラムは、いちいち受信したパケットデーターが到着した事を送信する側のトランスポート層にレスポンスとして知らせる。
そして、送信する側は、送信した全てのパケットデーターのレスポンスを受け取ったら、送信する側は終了電文のデーターを受信側に送る。
終了電文のデーターを受け取る受信側は、今まで受け取ったパケットデーターを組み立てて送信する側が送ったのと同じトランザクション・データーを組み立てて、正常ならば送信する側に正常終了のレスポンスを送り、異常ならば異常終了のレスポンスを送信する側に送る。
正常終了のレスポンスを受け取った送信する側は、トランスポート層の上位の層のプログラムに送信が正常終了した事を知らせパケットの送信を終了する。
異常終了のレスポンスを受け取った送信する側は、再度、新たにトランザクション・データーの全てのパケットデーターと終了電文のデーターを送るが、それでも異常終了のレスポンスを受け取ったら、トランスポート層の上位の層のプログラムに送信が異常終了した事を知らせパケットデーターの送信を終了する。
また、送信する側は、パケットデーターや終了電文のデーターのレスポンスがタイムアウトになるまで返って来なかったら同じデーターを送り直すが(リトライシーケンス)、何回か送り直してもレスポンスが返って来なかったら、トランスポート層の上位の層のプログラムに送信がタイムアウトで異常終了した事を知らせパケットデーターの送信を終了する。
さて、これは、空想の通信プロトコルではあるが、この様なデーターを送受信する動きとは、特にリトライシーケンスがあるデーター通信とは、受信する側と送信する側は記憶を共有する様に設計するという感覚になる。
私は、コンピューターにおける通信プロトコルにおいて、この様な設計思想を持っているので、コンピューター同士の機械のコミュニケーションとは、記憶を共有する事という感覚で設計している。
ここから、私は、全てのコミュニケーションとは記憶を共有する事ではないだろうかという思想を持っている。
この思想のため、私は、もし記憶を共有するコミュニケーションをする事ができなかったら、コミュニケーションに失敗したという感覚を持つ事になるのである。

11.3.ネットワーク通信のデバッグ環境。

 インターネットにおけるデバッグ環境は、LAN同士のデバッグでは不完全である。
完璧なデバッグ環境とは、2台のルーターを使って、そのルーターの両端に、インターネットによるデバッグ環境を作れば良い。
更に考えるのならば、2つのインターネット回線を契約して、その間で、インターネットによる通信をすれば良いだろう。
それが、実際の環境でのデバッグ環境となるのである。
これは、LAN同士のネットワークのデバッグ環境よりも、これは、金がかかると思う。




12.オンライン処理の基本的な通信エラー対策に関して。

 まずは、基本的な通信プロトコルとは、ポーリングという仕様は入っていないし、エラー復旧時にデーターをリカバリーするなどという仕様は入っていない。
これは、通信プロトコルに期待するのではなく、その通信プロトコルを利用するオンライン処理が担当する仕様なのである

12.1.ノンストップのシステムを作る事。

 オンライン処理で必要な仕様とは、リトライシーケンスとリカバリー処理が無ければならない。
問題点があると自動的にリトライシーケンスが発生し、そのリトライシーケンスによってデーターが壊れない様にする様にデーター設計やシステムを設計する事。
リトライシーケンスしても復旧しないとすれば、その装置は故障したとみなしてリトライシーケンスを停止させ、次は故障した装置をポーリングなどによって常に監視し、その装置が復旧した事をポーリングなどによって監視できたのならば、手動によるのではなく、自動で復旧させるシステムを作る事。
まずは、これが、ノンストップのシステムを作る事の基本である。
装置の二重化などの方法によってノンストップシステムが作られているという話を聞く。
では、どの様に二重化して、自動的に故障した装置を切り離して、安全な装置に切り替えてノンストップのシステムを作ってゆくかという設計をする時、リトライシーケンスの自動化と自動復旧のための自動リカバリーの仕様だけは基本的な仕様だと心得ておく事。

12.2.エラー対策。

 通信障害が発生した事は、通信プロトコルにおいて発見する事ができるだろう。
データーを送信した時、レスポンスが返って来なかった場合、次の事が考えられる。
○ 伝送路エラー1.(伝送路にノイズが侵入して通信エラーになった)
○ 伝送路エラー2.(伝送路が切断された)
○ 通信装置の故障。
伝送路にノイズが侵入して通信エラーになった場合は、リトライシーケンス(同じ電文を再送する事)によって通信電文が復旧する事が考えられる。
しかし、伝送路が切断されていたり、通信装置が故障したりしていては、どんなにリトライシーケンスを繰り返した所で、障害がなおる事は無い。
この場合、通信障害がある事から、装置からエラーメッセージを出す事や、警告のためのサイレンなどを鳴らす事によって、その装置を使っている人達に知らせねばならない。
 この以上を検知するには、次の方法が考えられる。

○ 二つの装置間では、一定時間は、必ず、通信をしていなければならない。もし、送るべき通信内容が無い場合、空の内容の通信電文を送る事を義務付けなければならない。
○ データーを受信する装置は、一定期間以上データーを受信できない場合は、通信エラーがあるとみなして、エラー警報を出す事。
○ データーを送信する装置は、データーを送信した時に返ってくるレスポンスが来ない時、何度か、リトライシーケンスを繰り返し、それでも正常なレスポンスが返って来なかった場合、通信エラーがあったとみなし、エラー警報を出す事。
この様な障害の復旧には、次の様な事が考えられる。
○ 伝送路をチェックして切断されていないか、伝送路の中に入っている装置が故障もしくは電源が切断されていないか。
装置の電源が切れていないか、装置が、異常状態になっていないか、その異常状態はその装置をリセットする事で回復できないか、もしくは、その装置を取り換える事によって復旧しなければならないか。

 さて、リカバリー機能の付いていないオンライン処理だと、通信プロトコルでリトライシーケンスエラーが発生した後、どの様な仕様でシステムを作れば良いか分からないでいる事になり、エラーメッセージを出してユーザーに障害対策をしてもらうという操作説明書しか書けない製品しか作れなくなるだろう。
それは、もし、通信エラーという障害が発生した時、その商品を設計した人しか対応する事ができない、ユーザーが対処する事が難しい難解な製品しか開発する事ができないだろう。
ここで、オート・リカバリーの機能を取り付けた装置だと、「従属局」の障害は、「主局」のリカバリー処理で、電源を入れなおした時に、このオート・リカバリー機能で全て解決できるという仕様が書ける様になる。(通信回線の接続を確認して断線かどうかを判断する必要があるが)
すると、ユーザー自身にも使いやすいシステムを作る事ができる。
 システムの仕様を作る上で、コンピューター上のトラブルがあったら、電源を入れなおせば全て問題解決できるという仕様が書けるSEは、障害対策の時のオペレーションの仕様がすっきり簡単となり、それが操作説明書を書く事にも生かされて簡潔になり、誰もが使いやすいシステムを作る事ができる様になるだろう。
 特に、ここで私が強調して言いたい事とは、オンラインシステムの仕様を決定して作る上で、リトライシーケンスとオート・リカバリー処理は、必須の仕様である事を思いとどめて欲しい。

この記事へのコメント

この記事へのトラックバック