オフロード (コンピュータ用語)

オフロードとは、コンピュータ分野において主に以下のことを指す言葉である。

システム入替などのために、実行中のジョブを停止させること。OFF-LOADと表現される。
あるシステムの負荷（英: load）を他の機器などが肩代わりして軽減する仕組みのこと^[1]^{[注釈 1]}。
offloadやoffloadingと表現される。本項にて詳説する。

概要

システムの受け持つ機能の一部を外部システムに受け渡すことで、本体システムの負荷を軽減することは、パフォーマンス向上を目的としてしばしば用いられる手法である。負荷軽減の手法としてはロードバランシング（負荷分散）などもあるが、ロードバランシングは同等機能の機器を並列稼動させ、負荷を均等に分散する手法であるのに対し、オフロードは一部の機能だけに特化したシステムを本体システムから切り出して外部システムとする手法であり、その向かう方向は大きく異なる。この手法をオフロードと呼ぶ。この用語は、主にネットワーク通信におけるOS負荷を軽減させるという場面で用いられる。

ネットワークアダプタによるオフロード

近年、1000BASE-Tなどのような高速ネットワークが登場することで、以下に示されるような様々な処理がOSに負荷を与えていた。この負荷を軽減することを目的に、ネットワークアダプタにある程度の処理を任せるという手法がオフロードである。近年では、安価なネットワークアダプタでも標準的に行われている手法である。

チェックサムオフロード

インターネットの基盤プロトコルであり、事実上の標準であるIPを用いた通信はネットワーク通信の中心である。この状況下では、IP通信の負荷を下げることは、ネットワーク負荷を下げることとほとんど同じといえる。

IPv4では、パケットがビット化け等によって破壊されているかを検査するために、IPヘッダ内にチェックサムフィールドを持っている（参考：IPv4#パケット）。また、IP通信の約9割を占めるといわれているTCPのヘッダ内にもチェックサムフィールドが設けられている。すなわち、IPv4では大抵の場合、1つのパケットを送受信する際には、送信側と受信側でそれぞれ2回、チェックサムの算出が必要となる。

IPv6にはチェックサムフィールドは設けられていない（参考：IPv6#ヘッダ）。これはエラーチェックを上位層に任せているためであり、エラー訂正機能を持つTCPでのチェックサム算出はIPv6でも必要である。すなわち、IPv6では大抵の場合、1つのパケットを送受信する際には、送信側と受信側でそれぞれ1回、チェックサムの算出が必要となる。

このように、IP通信ではほとんどのケースにおいてパケットごとに1度以上、チェックサムの算出が必要となる。このチェックサム算出を、OSで行わずにネットワークアダプタに任せることで、OSの負荷を下げるというのがチェックサムオフロードである。IP層とTCP層、送信と受信によって、以下のように分かれる。

TCPチェックサム・オフロード（TCOとも略される）
- 受信TCPチェックサム・オフロード
- 送信TCPチェックサム・オフロード
IPチェックサム・オフロード
- 受信IPチェックサム・オフロード
- 送信IPチェックサム・オフロード

ネットワークアダプタが各オフロードに対応している場合、データ送信の際、OSはチェックサム算出を行わずネットワークアダプタに算出を任せる。ネットワークアダプタは、チェックサムの算出を行ってチェックサムを補いながら各パケットを送出する。データ受信の際、ネットワークアダプタはチェックサム算出を行い、その正否を別の形でOSに通知する。OSは、チェックサムを算出せずにネットワークアダプタから別の形で得られたチェックサム正否を用いてパケットの非破壊性を確認する。

Windowsでは、Windows 2000（NDIS 5）から実装され、Windows 2003 Server（NDIS 5.1）でデフォルト機能となった。Microsoft社が行ったテストでは、TCPチェックサムオフロードだけで、CPU使用率ベースで最大30%のパフォーマンス向上が得られたとしている^[3]。

なお、通常運用では問題とはならないが、WiresharkなどのLANアナライザを用いてパケットをキャプチャすると、チェックサムが誤っていないにもかかわらずチェックサムエラーが示されることがある。これは、送信パケットのチェックサム算出をネットワークデバイスに任せている関係で、キャプチャリングされるタイミング、つまりOSからパケットが送出される直前の段階では、チェックサムフィールドにチェックサム計算結果が含まれていないことによるものである。このような環境では、LANアナライザのチェックサムエラー検出機能を無効化しておく必要がある。受信パケットの場合はこのような事情はないため、パケットそのものが欠損していない限り、チェックサムエラーとなることはない。

TCPセグメンテーションオフロードとLarge Receiveオフロード

ネットワーク通信では、使用するプロトコルや下位層（通信機器など）に応じて、一度に送出できるサイズに制約が生じる。例えば、イーサーネットを使う上では一度に1500オクテットまでのデータしか扱うことができないなどである。TCPにおいて、送出データを一度に送出可能なサイズに分割することをセグメンテーションと呼んでいる。TCPセグメンテーションオフロードとは、この分割処理をネットワークアダプタに任せるというものである。TSOと略される。また、TCP Large Send（略称はLSO）やGeneric Segmentation Offload（略称はGSO）と呼ぶこともある。

対して、受信側はセグメント化されたパケットを結合する必要がある。Large Receiveオフロードとは、この結合処理をネットワークアダプタに任せるというものである。LROと略される。

フルTCPオフロードエンジン

上記のような仕組みを含めて、TCPの処理のほとんどをネットワークアダプタに任せ、OSは単にネットワークアダプタに送信データを渡すのみとする手法も近年では行われている。これをフルTCPオフロードエンジンと呼び、TOEと略される。

IPSecオフロード

IPsecの暗号化および復号の部分をネットワークアダプタによって実現させる手法があり、これをIPSecオフロードと呼んでいる。

デメリット

ネットワーク分野でのオフロードは、必ずしもメリットばかりではない。以下のような点がデメリットとして挙げられる。

フィルタリングの困難さ: 例えば、セグメント化された先頭でないパケットにSYNフラグが立っていることは通常運用ではありえないパケットである。このようなパケットをルールベースのパケットフィルタリングで破棄したいという要求は容易に考えられる。しかし、そのような柔軟性はネットワークアダプタには通常設けられていないため、TCPセグメンテーションオフロードが有効な環境下では、左記のようなパケットを破棄することは困難である。
脆弱性対処の困難さ: オフロードを有効にすることが、侵入系の脆弱性という観点での影響を与えるとは考えにくいが、DoS攻撃系の脆弱性という観点での影響はありえる。RFC 4953が中心に扱っている、セグメント化されたパケットの再構築時の脆弱性が現実のものとなった場合に、オープンソース系のOSを使っていればOSによる緊急対処も容易であるが、ネットワークアダプタではメーカーによるドライバアップデートを待つことしかできなくなる。メーカーが既にサポートしなくなったネットワークアダプタの場合は、アップデートも期待できないことになる。

ネットワーク分野の、より上位層でのオフロード

ネットワーク通信において、より上位層でオフロードが実施されることもある。この場合は、ネットワークアダプタではなく、別の端末を設けて、特定の機能のみをその別端末に移すという手法で、本体システムの負荷軽減を図ることになる。以下のようなオフロードが存在する。

SSLオフロード

SSL通信の暗号化および復号を、本体システムとは別の専用端末に任せるという手法である。

→詳細は「SSLオフロード」を参照

GPUオフロード

並列計算能力の極めて高いGraphics Processing Unit（GPU）にグラフィックス処理などをオフロード（委譲）することが多い。グラフィックス処理は、画面解像度や描画内容の複雑度が増大するにつれ、膨大な量の計算が必要となっていくため、CPUでリアルタイムに実行するのは難しいことから、もともとグラフィックス処理専用チップにラスタライズや塗りつぶしなど一部の処理をオフロードすることが普通に行なわれていた。オペレーティングシステムのデスクトップ画面描画、ゲームやCADの3次元コンピュータグラフィックス（3DCG）描画、動画再生といった様々なグラフィックスタスクの快適性は、もはやGPUなしでは実現不可能となっている。また、汎用計算に対応したGPUが登場してからは、グラフィックスだけでなく科学技術計算や、機械学習あるいは深層学習による人工知能（AI）関連の高負荷処理をオフロードすることも頻繁に行なわれるようになっている（GPGPU）。GPUへのオフロードをアプリケーションソフトウェアやライブラリに組み込むには、CUDAやOpenCLといったプログラミング環境やAPIが使われることが多いが、OpenMPやOpenACCのようなAPIでは、より抽象化されたGPUオフロード機能が提供されている^[4]。