特許 6963411 通信装置、通信方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6963411

(24)【登録日】2021年10月19日

(45)【発行日】2021年11月10日

(54)【発明の名称】通信装置、通信方法、およびプログラム

(51)【国際特許分類】

   H04L 29/08 20060101AFI20211028BHJP

   H04L 12/805 20130101ALI20211028BHJP

   H04L 12/951 20130101ALI20211028BHJP

【ＦＩ】

   H04L13/00 307Z

   H04L12/805

   H04L12/951

【請求項の数】8

【全頁数】10

(21)【出願番号】特願2017-100075(P2017-100075)

(22)【出願日】2017年5月19日

(65)【公開番号】特開2018-196053(P2018-196053A)

(43)【公開日】2018年12月6日

【審査請求日】2020年5月14日

(73)【特許権者】

【識別番号】000001007

【氏名又は名称】キヤノン株式会社

(74)【代理人】

【識別番号】110003281

【氏名又は名称】特許業務法人大塚国際特許事務所

(72)【発明者】

【氏名】木下 暁央

【審査官】 中川 幸洋

(56)【参考文献】

【文献】 特開２００６−０８１０３３（ＪＰ，Ａ）

【文献】 特開２０１５−１４９５６０（ＪＰ，Ａ）

【文献】 特開２０１０−０３４８６０（ＪＰ，Ａ）

【文献】 特許第５５１７９５１（ＪＰ，Ｂ２）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ ２９／０８

Ｈ０４Ｌ １２／８０５

Ｈ０４Ｌ １２／９５１

(57)【特許請求の範囲】

【請求項1】

複数の通信インターフェースを備え、当該複数の通信インターフェースのうち選択された通信インターフェースを用いて送信データを通信相手装置に送信する通信装置であって、
前記通信相手装置からウィンドウサイズの情報を取得する取得手段と、
前記ウィンドウサイズに基づいて、前記送信データを前記通信相手装置に送信する際の送信データサイズを決定する決定手段と、
パケット生成手段と、
前記決定された送信データサイズが所定のサイズを超えない場合は、前記送信データに対するヘッダを生成することにより送信パケットを生成し、前記決定された送信データサイズが前記所定のサイズを超える場合は、前記送信データに対するヘッダを生成するために必要なヘッダ情報を生成し、当該生成したヘッダ情報に基づくヘッダの生成と送信パケットの生成を前記パケット生成手段に実行させるプロトコル処理手段と、
有し、
前記プロトコル処理手段または前記パケット生成手段による送信パケットの生成は、前記複数の通信インターフェースのうち何れの通信インターフェースが選択されるかに依らず実行されることを特徴とする通信装置。

【請求項2】

前記パケット生成手段は、前記送信データを分割する分割手段を有し、
前記決定された送信データサイズが前記所定のサイズを超える場合、前記分割手段は前記送信データを前記所定のサイズのセグメントに分割し、前記パケット生成手段は、前記分割手段により生成された各セグメントに対するヘッダを生成することにより前記送信パケットを生成することを特徴とする請求項１に記載の通信装置。

【請求項3】

前記送信パケットに対して所定のセキュリティ処理が必要かを判定する判定手段と、
前記判定手段により前記所定のセキュリティ処理が必要と判定された場合に、前記送信パケットに対して前記所定のセキュリティ処理を施す処理手段と、
を更に有することを特徴とする請求項１または２に記載の通信装置。

【請求項4】

前記複数の通信インターフェースは、それぞれが異なるネットワークに接続されることを特徴とする請求項１から３のいずれか１項に記載の通信装置。

【請求項5】

前記取得手段は、前記通信装置によるパケットの送信に応答して前記通信相手装置から送信された確認応答に含まれる前記ウィンドウサイズの情報を取得することを特徴とする請求項１から４のいずれか１項に記載の通信装置。

【請求項6】

前記所定のサイズは、前記通信装置と前記通信相手装置との通信に使用される通信プロトコルにより決定されるサイズであることを特徴とする請求項１から５のいずれか１項に記載の通信装置。

【請求項7】

複数の通信インターフェースを備え、当該複数の通信インターフェースのうち選択された通信インターフェースを用いて送信データを通信相手装置に送信する通信装置の制御方法であって、
前記通信相手装置からウィンドウサイズの情報を取得する取得工程と、
前記ウィンドウサイズに基づいて、前記送信データを前記通信相手装置に送信する際の送信データサイズを決定する決定工程と、
パケット生成工程と、
前記決定された送信データサイズが所定のサイズを超えない場合は、前記送信データに対するヘッダを生成することにより送信パケットを生成し、前記決定された送信データサイズが前記所定のサイズを超える場合は、前記送信データに対するヘッダを生成するために必要なヘッダ情報を生成し、当該生成したヘッダ情報に基づくヘッダの生成と送信パケットの生成を前記パケット生成工程で実行させるプロトコル処理工程と、
有し、
前記プロトコル処理工程または前記パケット生成工程による送信パケットの生成は、前記複数の通信インターフェースのうち何れの通信インターフェースが選択されるかに依らず実行されることを特徴とする通信装置の制御方法。

【請求項8】

コンピュータを、請求項１から６のいずれか１項に記載の通信装置として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信装置、通信方法、およびプログラムに関する。

【背景技術】

【0002】

従来、パケット通信において、通信の信頼性を保証するため、送信側から送信されたパケットを受信した受信側がACKと呼ばれる確認応答を用いる通信方式が利用されている。例えば、インターネット通信において広く利用されているTCP/IP（Transmission Control Protocol/Internet Protocol）では、送信側は、送信データをセグメントに分割してパケット化して送信し、受信側は、セグメントをオクテット単位にシーケンス番号で管理し、受け取ったセグメントのシーケンス番号をACKとして応答する必要がある。

【0003】

TCP/IPのプロトコル処理では、送信側は、通信データのパケット化や再送処理のために、ネットワークバッファを用意している。送信側におけるTCP/IPパケットの送信処理において、ソケットAPI send()によって指定されたユーザデータがネットワークバッファに転送され、MTU（maximum transmission unit：最大伝送単位）に分割される。そして、分割されたデータと擬似ヘッダのチェックサムが計算され、TCPヘッダとIPヘッダが追加されたTCT/IPパケットが生成される。伝送経路がイーサネット（登録商標）の場合、これらのヘッダに加えて、イーサネットヘッダが付加されたイーサネットフレームが生成され、送信される。

【0004】

また、TCP/IPのプロトコル処理では、送信側のパケット送信の度に受信側がACKを送信することによる通信速度の低下を回避するために、所定のウィンドウサイズを利用するウィンドウ制御が行われる。TCP/IPのウィンドウ制御では、受信側は、受信バッファの残りサイズをウィンドウサイズに設定したACKを送信し、送信側は、ウィンドウサイズになるまでACKを待つことなく送信データを送信することができる。また、更に、TCP/IPのウィンドウ制御では、通信速度をより向上させるために、スライディングウィンドウが用いられる。スライディングウィンドウでは、受信側はパケットを受信する度にACKを送信し、送信側は最初のACKを受信するとウィンドウをスライドさせて、ACKを待つことなくウィンドウサイズ分のデータを連続的に送信することが可能となる。

【0005】

近年、TCP/IPのプロトコル処理では、CPU（Central Processing Unit）による処理軽減、及び高速送信のため、送信データのセグメント分割処理と、分割したセグメントのIPパケット化処理をネットワークI/Fでハードウェアがする技術が用いられている。このような技術は、TSO（TCP Segmentation Offload）機能により実現化されている（特許文献1参照）。TSO機能は、NIC（Network Interface Card）などのハードウェアで実施することが一般的である。TSO機能を用いることで、アプリケーションデータを従来のMSS（Maximum Segment Size）単位の送信ではなく、MSSよりも大きいデータ単位でハードウェアに送信要求を行い、ハードウェアにてMSS単位に再分割してネットワークに連続送信することが可能となる。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特許第5517951号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかしながら、マルチIF（有線LANと無線LANを同時使用）の場合、TSO機能に対応しているネットワークI/FとTSO機能に対応していないIFがあり、ネットワークスタックが処理をIF毎に変更する必要がある。

【0008】

本発明は、上記課題に鑑みてなされたものであり、ネットワークI/Fに依存せずに、パケット化処理を行うことを目的とする。
を目的とする。

【課題を解決するための手段】

【0009】

上記目的を達成するための一手段として、本発明の通信装置は以下の構成を有する。すなわち、複数の通信インターフェースを備え、当該複数の通信インターフェースのうち選択された通信インターフェースを用いて送信データを通信相手装置に送信する通信装置であって、前記通信相手装置からウィンドウサイズの情報を取得する取得手段と、前記ウィンドウサイズに基づいて、前記送信データを前記通信相手装置に送信する際の送信データサイズを決定する決定手段と、パケット生成手段と、前記決定された送信データサイズが所定のサイズを超えない場合は、前記送信データに対するヘッダを生成することにより送信パケットを生成し、前記決定された送信データサイズが前記所定のサイズを超える場合は、前記送信データに対するヘッダを生成するために必要なヘッダ情報を生成し、当該生成したヘッダ情報に基づくヘッダの生成と送信パケットの生成を前記パケット生成手段に実行させるプロトコル処理手段と、有し、前記プロトコル処理手段または前記パケット生成手段による送信パケットの生成は、前記複数の通信インターフェースのうち何れの通信インターフェースが選択されるかに依らず実行される。

【発明の効果】

【0010】

本発明によれば、ネットワークI/Fに依存せずに、パケット化処理を行うことが可能となる。

【図面の簡単な説明】

【0011】

【図1】実施形態における通信装置のハードウェア構成例を示すブロック図。

【図2】実施形態における通信装置の機能構成例を示すブロック図。

【図3】実施形態1における処理を示すフローチャート。

【図4】実施形態2における処理を示すフローチャート。

【発明を実施するための形態】

【0012】

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

【0013】

［実施形態1］
図1は、実施形態1における通信装置10のハードウェア構成例を示すブロック図である。RAM（Random Access Memory）101は、各種データの保存やワークメモリとして使用される。RAM101は送信データを格納して管理するための送信バッファ114を有する。ROM（Read Only Memory）103には、CPU102により実行される各種プログラム等を記憶する。CPU102は、RAM101をワークメモリとして、ROM103や図示していないハードディスクなどの、プログラム格納部としての記録媒体に格納された各種プログラムを実行する。

【0014】

第1通信部110は、MAC（Media Access Control）モジュール108とPHY（Physical Layer）モジュール109を有し、Ethernet（商標登録）などのネットワークを介した通信相手装置との通信を行う。同様に、第2通信部113は、MACモジュール111とPHYモジュール112を有し、第1通信部110と異なるネットワークを介した通信相手装置との通信を行う。データの送受信は、CPU102によりネットワークドライバが実行され、これに応じてMACモジュール108（および／またはMACモジュール111）が制御されることにより行われる。なお、本実施形態では、第1通信部110と第2通信部113は、イーサネット（登録商標）を介した通信を行うものとするが、これに替えて、無線LAN（Wi-Fi）など、IP通信可能な媒体を介して通信を行うことが可能である。

【0015】

以上の構成は、通常の通信装置と同様であるが、本実施形態における通信装置10は更に、データ転送部105、フレーム生成部106、およびパケット生成部107を有する。データ転送部105は、例えばDMA（Direct Memory Access）により構成され、RAM101に記憶されているデータを、フレーム生成部106やパケット生成部107に転送する。データ転送部105は、CPU102により転送制御されてもよい。フレーム生成部106は、送信する送信データサイズを決定し、決定したサイズの送信データと、送信データに対するヘッダ情報を生成するためのヘッダ情報生成処理を行う。パケット生成部107は、フレーム生成部106により生成された送信データとヘッダ情報に基づいて、送信データのセグメント化およびヘッダの生成を行い、当該セグメントとヘッダから送信パケットを生成する。タイマ管理部104は、パケット送信に関して必要な所定時間を管理する。なお、以下に説明する（送信）パケットは、IP通信上で送受信されるデータの単位である。このパケットの組み立て方法については、本実施形態の本質ではないので、省略する。

【0016】

図2は、本実施形態における通信装置10の機能構成例を示すブロック図である。アプリケーション201は、ユーザアプリケーションを指す。アプリケーション201により、任意のサイズの、送信対象のアプリケーションデータ（送信データ）がプロトコルスタック202に入力される。プロトコルスタック202は、ネットワークバッファ管理部203、セグメント処理部204、通信プロトコル処理部205、コネクション管理部206、TCPウィンドウ制御部207、輻輳制御部208から構成される。

【0017】

ネットワークバッファ管理部203は、アプリケーション201から入力された送信データをRAM101の送信バッファ114に格納して管理する。ネットワークバッファ管理部203はまた、送信バッファ114に格納されている送信データのサイズを管理する。コネクション管理部206は、通信装置10の通信コネクションを管理する。例えば、コネクション管理部206は、アプリケーション201に対する通信コネクションにおけるMSS（Maximum Segment Size）等のコネクション情報を管理する。TCPウィンドウ制御部207は、第1通信インタフェース制御部209および第2通信インタフェース制御部211を介して受信した確認応答から、TCPコネクションの送信ウィンドウサイズを取得し、管理する。輻輳制御部208は、TCPコネクションにおける輻輳制御を管理する。例えば、輻輳制御部208は、アプリケーション201に対する通信コネクションにおける輻輳ウィンドウを管理する。

【0018】

セグメント処理部204は、ネットワークバッファ管理部203により管理されているRAM101内の送信バッファ114に格納されている送信データのサイズ、コネクション管理部206で管理されているMSS、TCPウィンドウ制御部207で管理されている送信ウィンドウサイズ、輻輳制御部208で管理されている輻輳ウィンドウサイズ等に基づいて、送信データサイズを決定する。通信プロトコル処理部205は、TCPセグメントのTCPヘッダやIPヘッダの生成と、それに伴うチェックサム計算等の処理を行い、送信パケットとして生成する。

【0019】

パケット生成部300は図1のパケット生成部107に対応し、分割部301、イーサネット／TCP／IPヘッダ生成部302、パケット生成部303から構成される。分割部301は、送信データを所定の単位（例えばMSS単位）に分割する。イーサネット／TCP／IPヘッダ生成部302は、所定のヘッダ情報に基づいて、TCP/IPヘッダとイーサネットヘッダを生成する。パケット生成部303は、分割部301とイーサネット／TCP／IPヘッダ生成部302から出力されたデータから、パケット化処理を行う。

【0020】

本実施形態では、セグメント処理部204により決定された送信データサイズに応じて、通信プロトコル処理部205またはパケット生成部300が、送信パケットを生成する。送信パケットの生成手法については、図3を用いて後述する。

【0021】

通信プロトコル処理部205またはパケット生成部300により生成された送信パケットは、送信先によって、第1通信インタフェース制御部209または第2通信インタフェース制御部211に入力される。第1通信インタフェース制御部209は、プロトコルスタック202と第1通信インタフェース210との間でデータや情報のやり取りを担う。同様に、第2通信インタフェース制御部211は、プロトコルスタック202と第2通信インタフェース212との間でデータや情報のやり取りを担う。第1通信インタフェース210および第2通信インタフェース212は、図1のMACモジュール108、PHYモジュール109およびMACモジュール111、PHYモジュール112に対応し、ネットワークに接続されている。送信パケットの送信は、タイマ管理部104により一定時間以上経過したことが通知された場合に、行われてもよい。

【0022】

次に、図3を参照して、本実施形態における処理について説明する。図3は、本実施形態におけるデータ送信処理を説明するフローチャートである。本フローチャートは、ソケットAPI send()によるデータ送信処理を想定する。

【0023】

まず、ステップS101において、CPU102により、ROM103に格納されている所定のプログラムが実行されることに応じて、アプリケーション201は、send()を呼び出す。send()が呼び出されると、データ転送部105は、ステップS102で、不図示のユーザバッファのデータ転送先であるRAM101内の送信バッファ114へ送信データを転送する。転送の際、データ転送部105は、データをMSS単位に分割して送信バッファ114に格納しても良い。

【0024】

ステップS103では、セグメント処理部204が、送信バッファ114に格納されている送信データのサイズが、TCPウィンドウ制御部207により管理されている送信ウィンドウサイズを超えるかどうかを判定する。送信ウィンドウサイズが送信バッファ114に格納されている送信データのサイズを超える場合は（ステップS103でYes）、処理はステップS104に進み、セグメント処理部204は、送信バッファ114に格納されている送信データのサイズを、送信データサイズとして決定する。一方、送信ウィンドウサイズが送信バッファ114に格納されている送信データのサイズ以下の場合は（ステップS103でNo）、処理はステップS105に進み、セグメント処理部204は、送信ウィンドウサイズを、送信データサイズとして決定する。

【0025】

ステップS106では、通信プロトコル処理部205が、ステップS105またはS104で決定した送信データサイズが、コネクション管理部206で管理されているMSSを超えるかどうか判定する。決定した送信データサイズがMSS以下の場合は（ステップS106でNo）、処理はステップS107に進む。ステップS107では、通信プロトコル処理部205は、パケット生成部107を制御してチェックサムを計算してTCP/IPヘッダを生成し、TCP/IPヘッダを用いて送信データをパケット化し、TCP/IPパケットを生成する。通信プロトコル処理部205は、更に、イーサネットヘッダを生成し、生成したイーサネットヘッダを用いて、生成したTCP/IPパケットをイーサネットフレーム化し、ステップS113に進む。

【0026】

一方、決定した送信データサイズがMSSを超える場合は（ステップS106でYes）、処理はステップS108へ進む。ステップS108では、フレーム生成部106は、TCP/IPヘッダとイーサネットヘッダを生成するための情報としてヘッダ情報を生成し、ステップS109へ進む。ステップS109〜S112は、パケット生成部107に対応するパケット生成部300による処理である。ステップS109では、分割部301は、送信データがMSS単位に分割されているかどうかを判定し、送信データがMSS単位に分割されていない場合は（ステップS109でNo）、処理はステップS110へ進む。ステップS110では、分割部301は、送信データをMSS単位に再分割し、処理をステップS111へ進める。送信データがMSS単位に分割されている場合は（ステップS109でYes）、処理はステップS111へ進む。ステップS111では、イーサネット／TCP／IPヘッダ生成部302は、ステップS108で生成されたヘッダ情報を使用し、送信データがMSS単位に分割された各セグメントに対してTCP/IPヘッダとイーサネットヘッダを（自動）生成する。テップS112では、パケット生成部303は、S111で生成されたTCP/IPヘッダとセグメントを連結し、TCP/IPパケット化した後、イーサネットヘッダを付加し、イーサネットフレーム化する。なお、一度に連結できるセグメントの数は、輻輳ウィドウサイズに基づいて決定され得る。

【0027】

ステップS113では、通信プロトコル処理部205は、送信先で通信インタフェースを選択し、イーサネットフレームを第1通信インタフェース制御部209または第2通信インタフェース制御部211に送信し、処理を終了する。

【0028】

このように、送信データのセグメント分割とTCP/IPヘッダ生成とイーサネットフレーム化を実施するハードウェアによる処理（ステップS109〜S112の処理）が通信インタフェースに依存せずに使用できる。なお、ハードウェアによる処理をソフトウェアで処理を実行した場合においても、本実施形態を適用可能である。

【0029】

なお、ステップS102において、データ転送部105が送信バッファ114へ送信データを転送するに際、MSS単位に分割して送信バッファ114格納できた場合は、通信プロトコル処理部205は、MSS単位のデータに対してチェックサム計算を行い、チェックサム値をデータと対で保持し、ステップS111において、イーサネット／TCP／IPヘッダ生成部302は、保持されているチェックサム値を使用して、TCP/IPヘッダを生成してもよい。また、通信インタフェースが複数存在する例を挙げたが、通信インタフェースが一つの場合にも本発明を適用することができる。また、本実施形態では、TCP/IPプロトコルを例にして説明したが、UDP（User Datagram Protocol）プロトコル等の他のプロトコルを適用することも可能である。

【0030】

［実施形態2］
次に、実施形態2について説明する。なお、本実施形態において、実施形態1と同様の構成については、同一符号を付して、その詳細説明を省略する。

【0031】

図4を参照して、本実施形態における処理について説明する。図3は、本実施形態におけるデータ送信処理を説明するフローチャートである。本フローチャートは、ソケットAPI send()によるデータ送信処理を想定する。なお、S201〜S212の処理は実施形態1において説明した図3のステップS101〜S112と同様の処理のため、説明を省略する。

【0032】

ステップS213では、通信プロトコル処理部205は、TCP/IPパケットに所定のセキュリティ処理としてのIPsec処理が必要かどうかを判定する。IPsec処理が必要な場合は（ステップS210でYes）、処理ステップS214へ進む。ステップS214では、通信プロトコル処理部205は、TCP/IPパケットへIPsec処理を実行し、処理をステップS215へ進める。IPsec処理が必要でない場合は（ステップS210でNo）、処理はステップS215へ進む。ステップS215では、通信プロトコル処理部205は、送信先で通信インタフェースを選択し、イーサネットフレームを第1通信インタフェース制御部209または第2通信インタフェース制御部211に送信し、処理を終了する。

【0033】

このように、送信データのセグメント分割とTCP/IPヘッダ生成とイーサネットフレーム化を実施するハードウェアによる処理（ステップS209〜S212の処理）が通信インタフェースに依存せずに使用できる。なお、ハードウェアによる処理をソフトウェアで処理を実行した場合においても、本実施形態を適用可能である。また、通信相手装置とIPsec通信が必要な場合、送信パケット化した後、当該送信パケットに対してIPsecの処理を施すことができる。

【0034】

なお、ステップS202において、データ転送部105が送信バッファ114へ送信データを転送するに際、MSS単位に分割して送信バッファ114格納できた場合は、通信プロトコル処理部205は、MSS単位のデータに対してチェックサム計算を行い、チェックサム値をデータと対で保持し、ステップS211において、イーサネット／TCP／IPヘッダ生成部302は、保持されているチェックサム値を使用して、TCP/IPヘッダを生成してもよい。また、通信インタフェースが複数存在する例を挙げたが、通信インタフェースが一つの場合にも本発明を適用することができる。また、本実施形態では、TCP/IPプロトコルを例にして説明したが、UDP（User Datagram Protocol）プロトコル等の他のプロトコルを適用することも可能である。

【0035】

このように、以上に説明した実施形態によれば、ネットワークI/Fへ依存しないレイヤで、データの「セグメント分割」と「IPヘッダ/TCPヘッダ生成」を実施することで、ネットワークスタックがネットワークI/F毎に処理を変更する必要がなくなるという利点がある。以上に説明した実施形態によれば、確認応答が受信できないために送信データを再送する場合に、再送する送信データに対してヘッダを生成し、送信パケットとするも可能である。また、以上に説明した実施形態によれば、送信データのプロコルタイプや送信データの種別によって、送信データに対するヘッダ生成と送信パケット化の実施をするか、ヘッダを生成するために必要なヘッダ情報の生成を行ってから、送信パケット化の実施をするか否かを切り換えることが可能となる。

【0036】

［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

【符号の説明】

【0037】

101 RAM、102 CPU、103 ROM、104 タイマ管理部、105 データ転送部、106 フレーム生成部、107 パケット生成部、108 MACモジュール、109 PHY モジュール、 110 第1通信部、 111 MACモジュール、112 PHYモジュール

【図1】

【図2】

【図3】

【図4】