「MMCFTP」は何を解決したのか？

　この成功を生んだのは、もちろん物理的インフラとしての学術情報ネットワークの高速化がベースにあるのだが、最大の要因は従来のTCPプロトコルの特徴を生かしながら、その制約を取り除く工夫を凝らしたMMCFTPである。

　NIIで開発に携わっている山中顕次郎特任准教授は、「TCPの弱点は高速化を目指すと不安定になり、増速が頭打ちになることです。MMCFTPはその弱点をカバーし、高速な長距離伝送路を前提に、一定速度でのデータ転送が行えるのがポイント。つまり高速でありながら“恒速”でもあるところがキモなのです」と語る。

　TCPはご存じの通り、確実なデータ配送のためには欠かせないプロトコルだ。エラー検出／再送、データ順制御、重複排除、フロー制御、輻輳（ふくそう）制御といった機能で信頼性を保証する。

　そのためにオーバーヘッドも大きく、実際のデータ本体の転送速度は回線そのものの最大転送速度よりもずっと低速になることが多い。特に長距離伝送の場合に問題になるのがネットワーク遅延だ。これは単純に距離の問題でもあるが、ルーターなど通信機器の処理時間なども影響する。

　TCPはデータ送信のたびに相手側に到着しているか否かの確認応答を行うため、やりとりの往復のための時間が1回の送受信ごとに必要になる（RTT／ラウンドトリップタイム）。これが高速化の1つのネックだ。

　一度に大量のデータが送れれば確認応答回数が減るので好都合だが、規格上その上限は決まっている。それをウィンドウサイズというが、TCP本来のウィンドウサイズは64kBしかない。スライディングウィンドウプロトコルを利用して送受信を効率化することはできるが、ウィンドウサイズの上限が制約になる。

　そこでウィンドウサイズを拡張することが考えられた。TCPの改良技術としては、ウィンドウサイズを1GBにまで拡張するスケールオプションが規格化されている。しかしこれでは日米間などで200ミリ秒の遅延がある場合だと、40Gbps程度の転送速度が限界である（転送速度（bps）は、「ウィンドウサイズ（バイト）×8÷RTT（秒）」で計算できる）。この速度を超えるべく、現在さまざまなTCP改良または新プロトコルの開発が行われているところだ。

　しかしウィンドウサイズが拡張されても、1コネクションの通信処理は1CPUコアが担当しなければならず、並列化ができない。そのためCPUコアの負荷が増大する。コアごとの性能が向上を続けていた時代ならそれでもよかったが、現在はその性能が頭打ちになってきている。さらなる増速のためにはCPU性能がネックになると考えられる。そこで山中氏は「マルチコネクションを利用した増速の方が可能性がある」と考えた。

　複数のTCPコネクションを使って1つのデータを並列的に送受信すれば、ウィンドウサイズは一定でもコネクションの数だけ多くのデータが送れる。これがマルチコネクションの基本的考え方だ。MPTCP、bbftp、gridftpは、この考え方にのっとったプロトコルである。

　ただしこの方向でも問題がある。TCPの輻輳制御は、輻輳するまでウィンドウサイズを拡大して帯域探索を行い、自分が起こす輻輳を自分で回避する仕組みである。この輻輳制御が各コネクションで行われると、それぞれがいわば帯域を取り合う形になり、帯域制限をしないと回線帯域を使い切ってしまい、通信は不安定になり、速度はそれ以上に上がらなくなる。他の通信と回線を共用している場合なら、他のサービスに悪影響を及ぼしてしまう。