JP6318453B2 - 単一接続上での多くのクライアントストリームの多重化 - Google Patents

単一接続上での多くのクライアントストリームの多重化 Download PDF

Info

Publication number
JP6318453B2
JP6318453B2 JP2015228864A JP2015228864A JP6318453B2 JP 6318453 B2 JP6318453 B2 JP 6318453B2 JP 2015228864 A JP2015228864 A JP 2015228864A JP 2015228864 A JP2015228864 A JP 2015228864A JP 6318453 B2 JP6318453 B2 JP 6318453B2
Authority
JP
Japan
Prior art keywords
tcp
client
proxy server
web server
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015228864A
Other languages
English (en)
Other versions
JP2016127597A (ja
Inventor
パールマン、ラディア
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of JP2016127597A publication Critical patent/JP2016127597A/ja
Application granted granted Critical
Publication of JP6318453B2 publication Critical patent/JP6318453B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/0001Arrangements for dividing the transmission path
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46Interconnection of networks
    • H04L12/4633Interconnection of networks using encapsulation techniques, e.g. tunneling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/30Peripheral units, e.g. input or output ports
    • H04L49/3072Packet splitting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/90Buffering arrangements
    • H04L49/9057Arrangements for supporting packet reassembly or resequencing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/566Grouping or aggregating service requests, e.g. for unified processing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163In-band adaptation of TCP data exchange; In-band control procedures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching

Description

背景情報マイクロプロセッサの導入以来、これまでに、コンピュータシステムはますます速くなってきている。ムーアの法則(集積回路上のトランジスタの数は、2年毎に2倍になると予測するIntel(r)コーポレーションの共同創業者であるGordon・Mooreの1965年出版に基づいて)におおよそ従って、その速度はほぼ30年間の間ほとんど均等な速度で増えてきている。同時に、メモリおよび不揮発性ストレージの両方のサイズもまた一定して増加してきており、それによって現在の多くのパーソナルコンピュータはつい10〜15年前のスーパーコンピュータよりも強力である。更に、ネットワーク通信の速度にも、同様に、複数の天文学的な高速化が見られている。
プロセッサ速度、メモリ、ストレージ、およびネットワーク帯域幅技術における複数の増加は、これまでに増え続ける容量を用いる複数のネットワークの構築および配置をもたらしてきている。より最近になり、アマゾン(Amazon)(例えば、Amazon Elastic Compute Cloud(EC2)およびSimple Storage Service(S3))並びにマイクロソフト(アジュールおよびオフィス365)によって提供されるものの等、クラウドに基づく複数のサービスの導入は、パブリックネットワークインフラストラクチャに対する追加のネットワーク構築、および大量データセンタの配置の追加をもたらし、プライベートネットワークインフラストラクチャを利用するこれらのサービスをサポートする。更に、複数のモバイルネットワークデータサービスの新たな世代(つまり、4G)は、近い将来、複数の地上通信線ネットワークの利用にかなり影響を与えることが予期されている。これらの、および他の考慮の結果として、複数のコンピュータネットワークの利用は、あまり遠くない将来、速い速度で成長し続けることが予期されている。
インターネットトラフィックの大部分は、ハイパーテキストトランスポートプロトコル(HTTP)またはHTTPS(HTTPの暗号化され、安全なバージョン)を用いる。基本的に、HTTPは、クライアント(例えば、ユーザデバイス上のウェブブラウザ)とHTTPサーバ(例えば、ウェブサイトへのアクセスをホスティングするおよび/または提供するサーバにおいて実行されているウェブサーバアプリケーションであって、本明細書において用いられる「ウェブ」サーバおよび「HTTPサーバ」という用語は、交換可能に用いられ得る)との間の通信を含む。HTTPは、クライアントサーバコンピューティングモデルにおいてリクエスト‐応答プロトコルとして機能する。典型的なHTTPリクエスト‐応答シーケンスにおいて、クライアントは、サーバにHTTPリクエストメッセージを提出する。複数のHTMLファイルおよび他のコンテンツ等の複数のリソースを提供する、またはクライアントの代わりに他の複数の機能を実行するサーバは、そのクライアントに応答メッセージを戻す。図1は、複数のネットワーク要素、複数のクライアントデバイス、複数のサーバ、および複数のサービスを含む、選択された複数のインターネットコンポーネントを示すインターネットアーキテクチャ100を示す。インターネットクラウド102として一般的に図示されているインターネットは、複数のリンク108によって相互接続されているゲートウェイ104およびスイッチ106を含む複数の相互接続されたネットワーキング要素の大規模な集合である。複数の携帯電話(クライアント110および112)、タブレット(クライアント114)デスクトップコンピュータ(クライアント116)、およびラップトップ(クライアント118および120)によって図示されている複数のクライアントデバイス(クライアントが、デバイス自体またはそのデバイスにおいて実行されているアプリケーションを指しているかもしれないことを認識したうえで「複数のクライアント」)は、一般的にインターネットサービスプロバイダ(ISP)またはモバイルサービスプロバイダ(モバイルネットワークを介してインターネットにアクセスしている場合)によって操作されるゲートウェイ104を介してインターネット102に接続される。簡略化のため、および乱雑さを回避するべく、複数のクライアントデバイスとゲートウェイとの間の複数の接続は、両矢印として示され、実際のところ、複数のクライアントデバイスと複数のゲートウェイとの間において様々なネットワーキング要素があり、ゲートウェイに帰する機能は、1または複数のネットワーク要素において実装され得る。
様々なサーバも、また、ウェブサーバ122およびサードパーティ電子メールサーバ124によって図示されるように、インターネット102に接続されている。ウェブサーバ122は、ウェブサイト126への「フロントエンド」アクセスを提供する。検索サイト、ニュースサイトおよびeコマースサイト等のより大きなウェブサイトは、ウェブサイトのトラフィックを処理するべく、数十、数百、さらには数千のウェブサーバを有し得る。サードパーティ電子メールサーバ124は、実際のところ、1または複数の「中間」層における複数の電子メールアプリケーションサーバまたは同様のものに結合されているフロントエンド層において、複数のウェブサーバを介して実装され得る概念的エンティティであり、それらは、今度はバックエンド層において複数のデータストアに接続されている。マイクロソフトHotmail、Google Gmail、およびヤフーメール等の大きなサードパーティ電子メールサービスは、データセンタ128によって図示されるように、複数の大きなデータセンタ(サーバファームともまた称される)を用いて実装される。
クライアントとサーバとの間のHTTP/HTTPS通信を促すべく、TCP(伝送制御プロトコル)接続が、最初に確立される。TCPはインターネットプロトコルスイート(IP)の複数のコアプロトコルのうちの1つであり、TCP接続もまた、TCP/IP接続と称されることもある。TCPは、TCP接続上の通信においてリンクされているクライアントおよびサーバに割り当てられた複数のIPアドレスをそれぞれ備える一対のTCPエンドポイント(例えば、クライアントおよびサーバ)の複数のIPアドレスを用いる。
TCPは信頼性のあるトランスポートプロトコルを提供する一方、それは、複数のTCP/IPパケットがどのようにクライアントとサーバとの間でルーティングされるべきか規定しない。例えば、クライアント110によって接続されたゲートウェイとウェブサーバ122に接続されたゲートウェイとの間に、図1において示されるように、2つのマルチホップ(multi−hop)パス(一方は実線、他方は破線)がある。トラフィックのいくつかのクラスに対して複数のパケット「フロー」が所与のパスに沿って転送され得る一方、インターネットトラフィックの大半は、パケットのための転送パスは予め規定されていないベストエフォート原理でのホップ・ツー・ホップで転送される。
所与のHTTPサーバは、何千もの同時TCP接続をサポートしてよく、各接続は、異なるクライアントTCPエンドポイントを持つ。これは、各クライアント接続に対して複数のタイムアウトタイマーおよび複数の別個のバイトシーケンス番号空間等の多くのオーバヘッドを生成する。更に、各HTTPサーバは、限りのある帯域幅制限を有し、このことにより複数のパケットがHTTPサーバでドロップされることになり得る。TCPが輻輳制御をサポートする一方、その複数の輻輳制御メカニズムは、個別のTCP接続において実装され、サーバのワークロードの機能としてはまとめて管理されない。
本発明の上述の態様および付随する多くの利点は、同様の参照数字が、異なるように明記されていない限り様々な図に亘って同様の複数の部分を指している、そうでなければ指定される添付の図面と併せて、以下の詳細な説明を参照することによってより良好に理解され、より容易に理解されるであろう。
インターネットの複数の選択されたコンポーネントのアーキテクチャ図を示す概略図である。 プロキシサーバとウェブサーバとの間の多重TCP接続を用いる例示的なネットワーク構成を示す概略図である。 複数の個別のTCP接続および図2aの多重TCP接続を更なる詳細を示すリンク接続図である。 プロキシサーバが複数の多重TCP接続を介してウェブサーバに接続された、図2bに対する選択的な構成を示すリンク接続図である。 プロキシサーバがプロキシと各ウェブサーバとの間の個別の多重TCP接続を持つ、複数のウェブサーバに対するプロキシとして用いられる、図2bに対する選択的な構成を示すリンク接続図である。 一実施形態に係る、複数のクライアントから受信された複数のTCPパケットを、多重TCP接続伝達データセグメントを介してウェブサーバに転送することに関連しプロキシサーバによって実装される複数のTCPパケットセグメントデータ転送コンポーネントを示す概略図である。 一実施形態に係る、多重TCP接続を介してプロキシサーバから受信される複数のTCPパケットデータセグメントを処理することに関連しウェブサーバによって実装される複数のサーバ側コンポーネントを示す概略図である。 一実施形態に係る、ウェブサーバから送信され、プロキシサーバで、多重TCP接続上で受信された複数の多重TCPパケットデータセグメントを処理するための複数のコンポーネントを示す概略図である。 再アセンブルされたTCPパケットがパケット出力バッファ内にロードされる、プロキシサーバで、多重TCP接続上で受信される複数の多重TCPパケットデータセグメントを処理するためのオプションである構成を示す概略図である。 一実施形態に係る、多重TCP接続上で複数の多重データセグメントとして複数のTCPパケットをウェブサーバからプロキシサーバへ送信することに関連してパケット処理を示す概略図である。 多重TCPパケットの一実施形態を示すブロック図である。 クライアントと、プロキシサーバと、ウェブサーバとの間で交換される複数のメッセージの例示的なセットを示すメッセージフロー図である。 クライアントと、プロキシサーバと、ウェブサーバとの間で交換される複数のコマンドおよび複数の制御メッセージの複数の例示的なセットを示すメッセージフロー図である。 複数のサーバブレードが設置されている例示的なブレードサーバ筐体の前方等尺図である。 図8aのブレードサーバ筐体の後方等尺図である。 図8aおよび8bに対応する複数のラックマウント式ブレードサーバ筐体が設置されている、例示的なブレードサーバラックの前方等尺図である。 一実施形態に係る、一般的なサーバブレードの複数のコンポーネントの詳細を示す図である。
単一接続上で多くのクライアントストリームを多重化するための方法および装置の複数の実施形態が、本明細書において説明される。以下の記述において、本発明の複数の実施形態の深い理解を提供するべく様々な具体的な詳細が示される。しかし、関連技術の当業者であれば、具体的な詳細の1または複数が無くても、またはその他の方法、コンポーネント、材料等を用いて、本発明が実施できることは認識するであろう。他の複数の場合において、本発明の態様を不明瞭にすることを回避するべく、周知の構造、材料、またはオペレーションは示されず、または詳細に説明されていない。
本明細書を通じて参照する「一実施形態」または「実施形態」は、実施形態に関連して説明されている特有の特徴、構造、または特性が本発明の少なくとも1つの実施形態に含まれていることを意味する。従って、「一実施形態において」または「実施形態において」という文言が本明細書全体を通して様々な個所で現れても、必ずしも全てが同じ実施形態を指す訳ではない。更に、複数の特有の特徴、構造、または特性は、1または複数の実施形態において任意の好適な態様で組み合わされてよい。
明確化のため、本明細書の複数の図における複数の個別のコンポーネントもまた、特定の参照番号によってよりむしろ、図においてそれらの複数のラベルによって称されてもよい。更に、特定のタイプのコンポーネントを指す複数の参照番号は(特定の構成要素とは対照的に)、「一般的な」を意味する「(typ)」が続く参照番号で示されてよい。これらのコンポーネントの構成は、存在し得るが、描画図では簡略化および明確化のために示されず、あるいは、そうでなければ、別個の参照番号でラベル付けされない複数の類似のコンポーネントの典型であることを理解されるであろう。逆に、「(typ)」は、そのコンポーネント、要素等を意味するとして解釈されるべきではなく、開示される機能、実装、目的等のために一般的に用いられる。
本明細書で説明され、示される複数の実施形態の態様に従って、複数の技術が、複数のクライアントからの複数の通信が単一TCP接続上でトランスポートされる、複数の多重TCP接続を実装するために開示される。これは、クライアント毎に複数の個別のTCP接続を維持することに必要なオーバヘッドを大幅に低減する。更に、あたかもクライアントとサーバとの間で個別のTCP接続が用いられたかのような、処理されるべき多重TCP接続内のクライアントTCPトラフィックに対応する複数の個別のフローを可能にする新規のフロー制御技術もまた提供される。
多重TCP実装の一態様は、複数の個別のTCP接続を用いてクライアントと直接通信するプロキシサーバを用いることである。クライアントサーバ通信のサポートに加えて、HTTPは、複数の中間ネットワーク要素が、複数のクライアントと複数のサーバとの間の通信を向上すること、または可能にすることを許容するように設計される。高トラフィックウェブサイトは、しばしば、応答時間を向上するべく、複数の上流サーバの代わりにコンテンツを提供する複数のウェブキャッシュサーバから恩恵を受ける。加えて、複数のプライベートネットワーク境界にある複数のHTTPプロキシサーバは、グローバルのルーティング可能なアドレス無しに、複数のメッセージを複数の外部サーバへリレーすることによって、複数のクライアントに対する通信を容易にする。複数のプロキシサーバは、また、Googleおよびアマゾン(Amazon)によってホスティングされるもの等の大きなウェブサイトによって広く用いられる。
図2aおよび2bは、例示的な多重TCP接続実装の複数の態様を示すのに用いられるネットワークアーキテクチャおよびリンク接続図をそれぞれ示し、複数のクライアントはプロキシサーバ200と複数の個別のTCP接続上で通信し、それは、プロキシサーバ200とウェブサーバ122との間の多重接続202を介して、対応するHTTPトラフィックを転送するように構成されている。前のように、クライアント110、112、114、116、118および120は、複数のインターネットゲートウェイまたは同様のもの等のISPまたは複数のモバイルサービスプロバイダ設備を介してインターネット102に接続される。これらのクライアントの各々は、ウェブサーバ122とHTTP接続を確立することを望む。これは、例えば、wwwドットAmazonドットcom等、ウェブサーバ122が関連するウェブサイトのURL(ユニフォームリソースロケータ)に入る複数のクライアントデバイスの複数のユーザによって一般的に達成されるであろう。インターネット上の複数のクライアントおよびサーバは、IPアドレス(例えばIPv4またはIPv6)を用いることから、複数のURLは対応するIPアドレスに変換される必要がある。複数のURLと複数のIPアドレスとの間のマッピングは、ドメインネームサーバ(DNS)によって容易となる。AmazonおよびGoogle等の大きなサイトに関して、単一のIPアドレスを持つ単一のサーバを用いてクライアントトラフィックを処理することは不可能であるだろう。場合によっては、複数のプロキシサーバがこの問題に対処するべく用いられる。一般的なプロキシサーバスキームにおいて、URLに名目上関連しているウェブサーバに対してIPアドレスを戻すよりむしろ、DNS検索によって提供されるネットワークアドレスは、プロキシサーバのアドレスを代わりに戻す。
図2bに示されるように、クライアント110、112、114、116、118および120の各々は、それぞれのTCP接続110T、112T、114T、116T、118Tおよび120Tを介してプロキシサーバ200に接続されている。従来のプロキシサーバの使用において、プロキシサーバは、各クライアント接続に対してウェブサーバとのそれぞれのTCP接続を維持するであろう。1つの一般のアプローチでは、プロキシサーバは単に、複数のTCP/IPヘッダにおける複数のソースおよび行先IPアドレスを変更し、元の複数のパケットを転送する(複数のソースおよび行先アドレスにおける複数の変更を欠く)。複数のクライアントのおよびウェブサーバの視点から、そのプロキシサーバの存在は透明であり、それらが、プロキシサーバが用いられていることを完全に認識していないことを意味する。
従来のプロキシサーバのアプローチは、いまだにウェブサーバと通信しているクライアント毎に維持される個別のTCP接続を必要とする。対照的に、図2aおよび2bに示される実施形態では、TCP接続110T、112T、114T、116T、118Tおよび120T上でトランスポートされるTCPトラフィックは、多重TCP接続202を用いてプロキシサーバ200とウェブサーバ122との間で多重化される複数のクライアントデータセグメントに分割される。多重TCP接続を実装することの一態様は、クライアントデバイスとサーバとの間の各TCPフローに対するトラフィックを処理するべく、様々なバッファキューの割り当ておよびオペレーションである。更に、フロー管理スキームは、帯域幅割り当て110BW、112BW、114BW、116BW、118BWおよび120BWによって図示されるように、多重TCP接続の帯域幅のそれぞれの部分を割り当てるべく、これらのキューに関連して実装される。
図2cは、プロキシサーバ200がm個の多重TCP接続202、202、202mを介してウェブサーバ122に接続される、図2bに対する選択的な構成を示すリンク接続図である。入ってくる複数のTCP接続(つまり、複数のクライアントからプロキシサーバまで)の数に応じて、TCP接続の数が増大するにつれて複数の減少するリターンがあってもよい。更に、プロキシサーバおよびウェブサーバの各々は、一般的に複数のネットワークポートを有し、各々には、別個のIPアドレスが割り当てられ、TCPエンドポイントであり得ることが確認される。従って、平行して動作しているプロキシサーバとウェブサーバとの間で複数の多重TCP接続を実装することが有利であろう複数の状況がある。
図2dは、プロキシサーバ200が、プロキシと各ウェブサーバとの間で個別の多重TCP接続で、k個のウェブサーバ122、1222、122kに対してプロキシとして用いられる図2bに対する他方の選択的な構成を示すリンク接続図である。プロキシサーバのワークロードは、ウェブサーバのそれよりも一般的に少ない(クライアント接続毎のベースで)であろうことから、複数のウェブサーバに対するプロキシとして動作するプロキシサーバを用いることが有利であろう複数の実装環境があってよい。図2b、2cおよび2dに示される構成に加えて、多重TCP接続を用いてウェブサーバにプロキシサーバを接続する他の構成が、実装されてもよい。
図3aは、一実施形態に従って、クライアント110、112、114、116、118および120から受信される複数のインバウンドTCPパケットに関連してプロキシサーバ200によって実行される複数の処理および転送オペレーションを概略的に描写する。複数の処理オペレーションの第1のセットは、複数のTCP接続をサポートする従来のTCPエンドポイントによって実行されるものに類似している。示されるように、TCPパケット300のシーケンスは、クライアントデバイスとプロキシサーバ200との間で確立された対応するTCP接続上で、所与のクライアントデバイスからトランスポートされる。複数のパケットの複数のストリームが、図3aにおいて例示の複数の目的で示される。所与のHTTPリクエストまたは応答に対し、クライアントは、ウェブサーバに1または複数のTCPパケットを送信してよく、時間が経つにつれ、これは、(受信デバイスの視点から)複数のパケットのストリームとして表われ得るが、一方、マルチメディアコンテンツに関連しないHTTPトラフィックは、一般的に、ストリーミング接続よりもむしろステートレスなHTTP接続を用いる。更に、クライアントからの大部分のHTTPトラフィックは、比較的小さい複数のHTTPリクエストから成り、それはしばしば単一のTCPパケットにおいてトランスポートされ得る。各TCPパケット300は、HTTPリクエスト等のパケットペイロードデータ301を含む。
実例として、クライアント110、112、114、116、118および120の各々は、それぞれのTCP接続110T、112T、114T、116T、118Tおよび120T上で複数のパケットのシーケンスを送信することとして図示される。TCP接続をサポートするべく、TCPポート(物理的ポートではなく、ソフトウェアポート)は、TCP接続の各エンドで開かれ、そうすることによって、各TCP接続(プロキシサーバ200の視点から)は、クライアントのIPアドレスおよびTCPポート番号の組み合わせによって識別され得る。(所与のクライアントは、複数のTCPポートが用いられる場合、サーバと複数の同時TCP接続を確立してよいことに留意されたい。)一実施形態では、クライアントID(識別子)マッピングテーブル302が、クライアントIPアドレス/TCPポート番号の複数の組み合わせを関連する複数のクライアントID値にマッピングするべく、プロキシサーバ200によって用いられる。例示的な目的で、本明細書の図において、複数のクライアントIDは、例えば、クライアント110IDがクライアント110に対するクライアントIDである等(TCP接続110Tを用いる場合)、「クライアント」+そのクライアントの参照番号+「ID」によって示される。
従来のTCPエンドポイントアーキテクチャと同様、入力キュー304が(図3aにおける、クライアントIDによって識別されるように)各TCP接続によって割り当てられる。TCP接続入力キュー(バッファとしてもまた称される)が、複数のパケットが受信されると一時的に複数のパケットをバッファリングし、あらゆる順序付けされていない複数のパケットを、パケットの複数のTCPヘッダにおけるTCPバイトシーケンスデータを用いて再度順序付けするために用いられる。更に、TCPは、ドロップされたパケットを検出するためのメカニズムを用い、任意のドロップされたパケットは、TCPソース(この例においてはクライアント)から再送信される必要がある。簡略化のためおよび便宜上、複数の入力キュー304は、各TCP接続に対するそれぞれの単一のキューとして図示されている。実際のところ、それらは、TCPエンドポイントにおけるメモリにおいて実装される1または複数のバッファまたはキューを用いて実装され得る。一般に、ネットワークアダプタアーキテクチャに応じて、その入力キューは、ソフトウェア層(例えば、ソフトウェアネットワーキングスタックにおけるTCP層)を介して実装されてよく、あるいはネットワークアダプタにおける埋め込みロジックまたはその2つの組み合わせによって処理されてよい。
シーケンシャル実行の複数のTCPパケットが入力キュー304において検出されている場合、そのシーケンシャル実行の全てまたは一部分は、TCPポートに関連している出力キュー306内へ転送(Fwd)される。あるいは、出力キュー306は、関連している入力キュー304からの複数のパケットの複数のシーケンシャル実行を「プル」するように構成され得る。一実施形態では、複数の出力キュー306の各々は、特定のTCPクライアント接続上で送信されたパケットペイロードデータのシーケンシャル実行を維持するであろう。更に、一実施形態では、これらのTCP/IPヘッダは、複数のクライアントデータストリーム307によって図示されるように、パケットペイロードデータから取り去られ、複数のペイロード描写マーカーがそのビットストリームに追加され、ここで、複数の実行のビットの間のパイプ記号「|」は、パケットペイロードデータの間の描写を表す。代替のスキームにおいて、複数のTCP/IPヘッダは複数のクライアントデータストリームに留まるが、ウェブサーバ122によるその次の処理の間に取り去られ、無視される。
一実施形態では、データの複数のセグメント(複数のデータセグメント)を備える複数のビットストリームの複数のシーケンシャル実行は、プロキシサーバ200とウェブサーバ122との間で送信されるように構成されている複数のTCPパケット308において多重化(MUX)される。ここで用いられる「MUX・TCP」という用語は、これらのパケットを複数のクライアントから受信される複数のTCPパケット300から区別するためのものであり、構造上、複数のMUX・TCPパケットは、多重TCP接続上でのトランスポートに関連するデータセグメントの処理を促進するための埋め込みヘッダ情報を含む複数の従来のTCPパケットを備え、それらの更なる詳細は図5に示され、以下において論じられる。好ましくは、複数のMUX・TCPパケット308は可能な限り大きく、従ってカプセル化で失われる相対的な帯域幅オーバヘッドを低減する。例えば、一実施形態では、複数のジャンボTCPパケットおよび複数のジャンボイーサネット(登録商標)フレームが用いられる。更に、複数のMUX・TCPパケットのサイズは、それらの複数のカプセル化されたデータセグメントの集合的サイズを収容するように変化し得る。パッデイングもまた、適用可能ならば、複数のMUX・TCPパケットにおいて実装されてよい。
一実施形態では、クライアント110、112、114、116、118および120から受信されたTCPパケットペイロードデータに対応する複数のビットストリームデータの複数のシーケンシャル実行を備える複数のデータセグメントは、カプセル化され、以下のやり方で多重TCP接続202上で送信される。プロキシサーバ200は、TCPアウトバウンドストリームMUX、及びキューセレクタ312、アウトバウンドパケットアセンブリブロック314、イーサネット(登録商標)フレーミングブロック316、および出力イーサネット(登録商標)ポートキュー318を含むアセンブリロジック310を含む。上述したように、複数のクライアント出力キュー306の各々は、(特定のキューが空になっていない限り)TCPパケットペイロードビットストリームデータのシーケンシャル実行を含むであろう。また、図2bを参照して上述したように、クライアント110、112、114、116、118および120の各々は、それぞれの帯域幅割り当て110BW、112BW、114BW、116BW、118BW、および120BWを受信する。
帯域幅割り当ては、キューセレクタ310によって(以下に説明されるように、プロキシサーバ200およびウェブサーバ122の両方におけるロジックと組み合わせて)管理され、それは、どのクライアント出力キュー306から所与のTCPパケット308においてカプセル化される複数のデータセグメントをプルするべきであるかを選択する。ラウンドロビン、重み付けされた、または重み付けされていないフェアキュー、キューフィルレベル等に基づいた選択等、様々なタイプの複数の選択アルゴリズムが使用されてよい。複数のクライアントに割り当てられた帯域幅スライスは、複数のトラフィックパターンにおける複数の変化および他を考慮し、動的に変更され得る。複数の新たに接続されたクライアントとプロキシサーバ200との間で新たなクライアントTCP接続が確立される場合、クライアント入力キュー304およびクライアント出力キュー306は、動的に割り当てられることに更に留意されたい。同様に、TCP接続が閉じられていることが検出された場合、そのTCP接続に関連しているクライアント入力キュー304およびクライアント出力キュー306に対して割り当てられた対応するバッファ空間は、新たなTCP接続に対して再割り当てされるべく、リリースされる。
キューセレクタ312によってクライアント出力バッファ306からプルされる複数のデータセグメントを備えるシーケンシャル実行の複数のビットは、アウトバウンドパケットアセンブリブロック314によってMUXTCPパケット308にカプセル化される。一実施形態では、多重TCP接続202は、プロキシサーバ202とウェブサーバ122との間でトランスファーされるMUX・TCPパケット308に適用されると従来のTCP接続として動作させられる。しかしながら、プロキシサーバ200でのパケットストリームの生成およびウェブサーバ122で受信されたパケットストリームの処理の両方は、非従来的な複数の技術を用いる。
図5は、MUX・TCPパケット308の一実施形態を図示し、それは、MUX・TCP/IPヘッダ308H、続いてn個のカプセル化されたデータセグメント309、...309、続いてTCPフッタ308Fパケットペイロード308Pを含む。一実施形態では、MUX・TCP/IPヘッダ308Hは、プロキシサーバ200およびウェブサーバ122に対する複数のソースおよび行先IPアドレス、TCPバイトシーケンス番号等を含む複数のかっこにおいて示される複数の従来のTCP/IPヘッダフィールド、およびTCP/IPヘッダにおいて選択的フィールドに追加され得るいくつかの追加パラメータを備える。一実施形態では、複数のパラメータは、データ/制御フラグ、クライアントID、バイトシーケンス番号、および長さ(Len)を含む。複数のパラメータは、複数の個別のフィールドに埋め込まれ、および/またはエンコードされてよく、そうすることによって、単一のフィールドを含む、より少ない数のフィールドに埋め込まれ得る。別のオプションとして、複数のパラメータは、パケットペイロード308Pの初めに位置しているパラメータストリングまたは同様のものにおいてエンコードされてよい。示される実施形態では、データセグメント309...309の各々は、クライアントID、セグメント長さ、およびバイト(シーケンス)番号を備えるヘッダ311を含む。選択的なデリミターデータが、複数のイーサネット(登録商標)フレーム(例えば、複数の1または複数の0のストリング等、予め定められたビットシーケンス)を分離するべく用いられるデリミターデータに類似して、各データセグメント309の最後に追加され得る。バイトシーケンス番号は、MUX・TCPパケット308がドロップされ再送信される必要がある場合に、ビットストリームにおいてバイトシーケンスを再度順序付けするべく用いられる。
1または複数のMUX・TCPパケット308は、従来のやり方で、イーサネット(登録商標)フレーミングブロック316におけるイーサネット(登録商標)フレームにおいてカプセル化される。好ましくは、複数のジャンボイーサネット(登録商標)フレームは、イーサネット(登録商標)フレーミングのオーバヘッドに起因して失われる帯域幅を低減するべく用いられてよい。複数のイーサネット(登録商標)フレームは、次に、出力イーサネット(登録商標)ポートキュー318においてキューに入れられ、その次にサーバ122にストリームされる。
図3bは、多重TCP接続202上でプロキシサーバ200から受信される複数のMUX・TCPパケット308がどのようにウェブサーバ122において処理されるかを図示する。パケット処理は、TCP入力ストリームDeMUXおよび分離ロジック320を介して実装され、イーサネット(登録商標)入力ポートバッファ322においてバッファリングされている、受信された複数のMUX・TCPパケット308で開始する。ブロック324において、イーサネット(登録商標)デフレーミング及びデパケット化が、複数のMUX・TCPパケット308をそれらのイーサネット(登録商標)フレームから抽出するべく実行される。薄い灰色の影で図示されるように、イーサネット(登録商標)入力ポートバッファ322および複数のイーサネット(登録商標)デフレーミングおよびデパケット化オペレーションによって実行される複数のオペレーションは、イーサネット(登録商標)入力ポートで受信される複数のTCPパケットにおいて実行される複数の従来のオペレーションである。簡略化のため不図示であるが、TCPプロトコルを実装することに関する追加の複数のオペレーションが、また、周知の複数の技術を用いて実行されるであろう。
後続の複数の処理オペレーションは、非標準的であり且つ新規である。カプセル化されたデータセグメント分離ブロック326において、デパケット化された複数のTCPパケット300は、クライアントID毎にデータセグメントデータのビットストリームを出力するべく分離される。受信された、所与のクライアントに対して複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントは、次に、キューセレクタ328によって、データセグメントヘッダ311に含まれるクライアントIDに関連する適切なTCPポート入力キュー330の中へプッシュされる。次に、複数のデータセグメントは順に処理され、それの元のフォーマットのパケットペイロードデータ301Rを含む再アセンブルされた複数のクライアントデータストリーム を生成する。再アセンブルされた複数のクライアントデータストリーム110R、112R、114R、116R、118Rおよび120Rによって図示されるように、各TCP接続のクライアントデータストリームは、ソフトウェア処理スタック332で受信される。ソフトウェア処理スタック332に関して複数の示されるコンポーネントは、クライアントストリーム処理ブロック334およびHTTP/HTTPS層338を含む。クライアントストリーム処理ブロック334は、HTTPデータを備えるパケットペイロードデータ(例えば、HTTPリクエスト)を抽出し、HTTP/HTTPS層338へそれを転送するべく用いられる。一実施形態では、クライアントストリーム処理ブロック334は、HTTP/HTTPS層338の視点から、HTTPデータは従来のTCPパケットを用いて送信されたように、実装される。HTTP/HTTPS層338は、複数の従来のHTTPまたはHTTPSサーバ機能(接続がHTTPまたはHTTPS接続であるかに応じて適用可能であれば)を実行するように構成されているHTTP/HTTPSサーバ機能ブロック340を含む。実例として、これは、クライアントID毎にHTTPクライアントセッション状態342によって更に図示され、HTTP自体は処理状態を把握しないことが認められるが、一方で、HTTPストリーミング接続は持続的な接続をサポートする。
ウェブサーバ122からクライアント110、112、114、116、118および120への、プロキシサーバ200を介した反転方向におけるトラフィックフローをサポートするべく、図3aおよび3bに示される複数の類似のコンポーネントおよびロジックが、図4a、図4bおよび図4cにおいて示されるように、スワップされる。これらの図において、同様の番号付けがされた複数のコンポーネントは、類似の複数の機能を実行する。更に、以下の複数の条件が追加される。
更に詳細には、ウェブサーバ122またはウェブサーバ122に接続された他のサーバ(例えば、アプリケーションサーバ)において実行されている複数のソフトウェアアプリケーションは、複数のクライアントから送信される複数のHTTPリクエストを受信し、複数のクライアントによって戻されることになっている複数のHTTP応答を生成する。HTTPトラフィックのいくつかは、HTTPおよびTCP接続を確立することおよび閉じること等、HTTP/HTTPSサーバ機能ブロック340によって全体的に処理され得る。他の複数の場合において、入ってくるHTTP通信に関連しているデータペイロードは、そのHTTP層において分離され、適用可能なアプリケーションに転送される。反転方向において、複数のアプリケーションは、複数のHTTPクライアントに戻されるHTTP応答データを生成する。
HTTP応答データは、HTTP層338で受信され、適用可能なHTTPヘッダが(HTTP応答のタイプに応じて)追加される。次に、パケットペイロードデータ303を備えるHTTP応答は、クライアントデータストリーム110T、112T、114T、116T、118Tおよび120Tによって図示されるように、アウトバウンドクライアントデータストリームに追加される。各TCP接続に対するアウトバウンドクライアントデータストリームは、適切なクライアント出力キュー346においてバッファリングされる。クライアントID・TCP接続をオープンすることに関連し、クライアント出力キュー346は、ウェブサーバ122によって割り当てられる。一実施形態では、適用可能なクライアント出力キュー346は、クライアントIDマッピングテーブル302の参照によって識別される。
複数のクライアントデータストリームを備えるビットストリームコンテンツは、複数のクライアント出力キュー306におけるクライアントデータストリームコンテンツがプロキシサーバ200からウェブサーバ122へ転送されるのと類似したやり方で、多重TCP接続上で複数のデータセグメントとしてプロキシサーバ200に転送される。以前のように、これは、複数のデータセグメント309を複数のMUX・TCPパケット308にカプセル化すること、および多重TCP接続上で複数のMUX・TCPパケットをトランスポートすることを含む。
図4aで継続すると、図3bを参照して上述したものと類似の方式で、MUX・TCPパケット308ストリームが、MUX・TCP入力ストリームDeMUXおよび分離ロジック320によって受信され処理される。一実施形態では、クライアントID・TCP接続をセットアップすることに関連して、クライアント出力キュー348およびクライアント入力キュー350は、プロキシサーバ200によって割り当てられる。更に、図4aに示されるように、カプセル化されたデータセグメント分離ブロック326によって分離された各データセグメントに対するビットストリームコンテンツは、キューセレクタ328によって適用可能なクライアント入力キュー350内へプッシュされ、次に、複数のクライアントデータストリームは、適用可能なクライアント出力キュー348内へプッシュされるか、またはクライアント入力キューからクライアント出力キュー内へプルされる。一度複数のクライアント出力キュー348にあると、パケットペイロードデータ303は抽出され、TCPパケット305内にカプセル化され、それは、次に従来のアウトバウンドTCPパケット処理を用いて複数のクライアントに転送され、ここで、複数のTCPパケットは、TCP/IPヘッダにおいて行先アドレスにより識別される(例えば、転送テーブル検索を介して)プロキシサーバ200においてネットワークポートから送信される。
プロキシサーバ200aに対する選択的な構成は、図4bに示される。本構成では、複数のクライアントデータストリームの全てまたは一部分は、出力パケットバッファ352へ転送され、ここで、パケットペイロードデータ303は、抽出され、複数のTCPパケット305にカプセル化される。複数のTCPパケット305は、次に、従来のやり方でプロキシサーバ200aによってクライアント110、112、114、116、118および120に転送される。
上述の複数の多重TCPパケット処理オペレーションに加え、プロキシサーバ200およびウェブサーバ122は、TCP接続セットアップ及び複数のクライアントベースのTCP接続フロー制御オペレーションを実行するための追加のロジックを含む。プロキシサーバ200において、これらのオペレーションは、プロキシサーバ制御ロジック356(複数のTCPクライアントとインタフェースをとるべく用いられる)およびプロキシサーバ‐ウェブサーバ制御ロジック358によって促進される。ウェブサーバ122において、これは、プロキシサーバ‐ウェブサーバ制御ロジック360として図示されている。複数の接続およびクライアントキューの管理は、プロキシサーバ200とウェブサーバ122との間で送信される複数の制御メッセージによって促進される。例示的なセットアップおよび/または複数の制御機能に対応する複数のメッセージフロー図は、図6および7において図示される。
図6は、クライアント120と、プロキシサーバ200と、ウェブサーバ122との間で送信される複数のメッセージを示すメッセージフロー図を表示する。メッセージシーケンスは、クライアント120からウェブサーバ122へ送信されるHTTPリクエスト600で開始する。上述したように、これは、ウェブサーバ122によってホスティングされる、あるいはそうでなければそれを介してアクセスされるウェブサイトのURLを入力するクライアント120のユーザによって達成され得る。応答して、DNSサーバ(不図示)は、ウェブサーバ122よりもむしろプロキシサーバ200のIPアドレスを戻す。
HTTPセッションは、複数のネットワークリクエスト‐応答トランザクションのシーケンスである。HTTPクライアントは、サーバ(一般的にポート80だが、多くの他のポートもまた用いられ得る)上の特定のポートへのTCP接続を確立することによってリクエストを開始する。そのポートにおける最初のHTTPリクエスト「リスニング(listening)」に含まれるIPアドレスのHTTPサーバは、TCP接続をセットするように構成されている。従来のアプローチでは、リクエストを受信すると、HTTPサーバは、「HTTP/1.1200OK」等のステータスラインを含むHTTP応答メッセージを返信する。このメッセージの本体は、一般的に、要求されるリソースであるが、エラーメッセージまたは他の情報もまた戻されてよい。
本明細書で提供されるプロキシサーバアプローチでは、異なるシーケンスが起こる。HTTPリクエスト600を受け取ると、プロキシサーバ200は、これを新たなTCP接続に対するリクエストであるとして認識し、そのリクエストをメッセージ602としてウェブサーバ122に転送する。ウェブサーバ122は、更なる複数の接続をサポートできるか、およびそうである場合、クライアントIDを含む新たなプロキシ接続割り当てリクエスト604をプロキシサーバ200に戻す。応答して、プロキシサーバ200は、適切な複数のキューのセットをそのクライアントID(利用可能な場合)に割り当て、新たなプロキシ接続肯定応答(ACK)メッセージ606を戻す。プロキシサーバ200がクライアントIDキューを割り当てできない場合、それは、新たなプロキシ接続はこの時点でサポートできないことを示す異なるメッセージを戻す。
上述したように、複数の個別のTCP接続が、複数のクライアントとプロキシサーバとの間で確立される。従って、新たなプロキシ接続割り当てが成功した場合、プロキシサーバ200は、TCP接続が確立されていることを示すHTTP応答608をクライアント120に、TCPポート番号と共に戻す。所与のクライアントが、複数のTCP接続を同一のプロキシサーバ(各々は異なる複数のTCPポートを用いる)で確立することは可能であり、各固有のTCP接続は、上記でまた識別されるように、クライアントのIPアドレスおよびTCPポート番号の組み合わせによって識別される。
この時点で、クライアント120とプロキシサーバ200との間でHTTP接続が確立される。しかしながら、全ての意図および目的のため、クライアント120およびウェブサーバ122において動作している複数のHTTP/HTTPSサーバ機能340の両方の視点から、HTTP接続は、クライアント120とウェブサーバ122との間にあるように見える。従って、クライアント120は物理的なHTTPエンドポイントであり、ウェブサーバ122は仮想のHTTPエンドポイントである。複数のHTTPリクエストおよび複数のHTTP応答の後続の交換(HTTPリクエスト610および614、並びにHTTP応答612および616によって図示される)は、次に、これらのHTTPエンドポイントの間で交換され、各HTTPリクエストは、クライアントとプロキシサーバとの間のTCP接続を第1にトラバースし、次に多重TCP接続を介してウェブサーバへ転送され、各HTTP応答は逆のパスをトラバースする。
HTTPリリースメッセージ618によって図示されるように、複数のHTTPエンドポイントはどちらも、HTTP接続をリリースするよう明示的に要求できる。例えば、Google、クロム、マイクロソフトインターネットエクスプローラ、アップルサファリ、またはモジラファイアーフォックス等の正常に動作するウェブブラウザに関し、ユーザがタブを閉じる場合、ウェブブラウザ(クライアントを備える)は、閉じられたタブに関してURLに関連付けされているウェブサーバへHTTPリリースメッセージを送信する。任意選択的に、ウェブサーバは、HTTP接続がもはや存在していないことをHTTPタイムアウト620(別個のメッセージではないが、むしろウェブサーバによって内部で判断されたものである)を介して検出できる。
この時点で、プロキシ接続が、複数のクライアントIDキューリソースと共にリリースされる。 ウェブサーバ122は、クライアントIDを含むプロキシ接続リリースメッセージ622をプロキシサーバ200に送信する。応答において、プロキシサーバ622は、クライアントIDを含むプロキシ接続リリースACKメッセージを戻す。この時点で、プロキシサーバ200およびウェブサーバ122の両方は、リリースされているプロキシ接続に対して割り当てられた複数のクライアントIDキューをリリースする。
多重TCPアーキテクチャの一つの新規の態様は、ウェブサーバが複数の個別のTCP接続毎のフロー制御をもたらす能力である。例えば、本明細書にて開示された複数の多重TCP接続は、従来の複数のトンネル接続といくつかの類似点を共有する一方、そのようなトンネル接続は、単に、複数の個別のTCP接続に対する複数の別個の帯域幅割り当ての条件無しで、複数のパケットストリームをカプセル化する。本明細書で開示される複数の技術では、ウェブサーバは、一時的に停止している接続を含む所与のTCP接続に対して割り当てられた帯域幅スライスを動的に再割り当てしてよい。ウェブサーバによって管理されるこれらのフロー制御オペレーションに関連して、プロキシサーバは、バッファのオーバーフローおよび結果として生じる複数のパケットドロップを防止する等を目的として、クライアントとの複数のTCP接続において対応するTCPフロー制御手段を(適応可能ならば)実装してよい。
一実施形態では、ウェブサーバは、プロキシサーバに、いくつのクライアントをウェブサーバがサポートできるかを通知するまたは命令することが可能になる。図7に示されるように、これは、ウェブサーバ122がサポートできるクライアントの数(n)を識別するサポートクライアント数のメッセージ700で達成され得る。応答において、プロキシサーバ200は、サポートクライアント数のACKメッセージ702を戻す。
ウェブサーバは、また、プロキシサーバに所与のクライアントをスロットルするように命令してもよく、または所与のクライアントに関して複数のパケットを転送することを一時的にシャットダウンしてよい。例えば、ウェブサーバ122は、プロキシサーバ200に、クライアントIDによって識別されるように、特定のクライアント接続に対応する複数のパケットを転送することをスロットルするように命令するスロットルコマンド704を送信してよい。応答で、プロキシサーバ200は、スロットルコマンドACKメッセージ706で返信するであろう。入ってくるデータがいまだに多すぎる場合、ウェブサーバは、1または複数のプロキシ接続に対する複数のTCPパケットの受け取りを一時的に中止することを選択的に選んでもよい。これは、中止するべきクライアントID、また同様に中止前に送信するべきである最後のバイトを表すバイトシーケンス番号を識別するシャットダウン接続メッセージ708として図7に示され、としても示される。プロキシサーバ200は、中止ACKメッセージで応答し、クライアントIDを識別する。
複数の進行中のオペレーションの間に、ウェブサーバは、それがあまりにも多くのクライアントにサービス提供している(および結果として、複数のパケットをドロップすることが強制されている)ことを検出してよい。このタイプの状況に応答し、ウェブサーバ122はクライアント拒否メッセージ712を送信し、否定するべきである複数のクライアント接続に対応する1または複数のクライアントIDを識別する。応答において、プロキシサーバ200は、クライアント否定ACKメッセージ714を戻す。また、プロキシサーバ200は、HTTP接続閉鎖メッセージ716を適用可能な(複数の)クライアントへ送信する。
プロキシサーバおよび/またはウェブサーバは、キューフィルレベル718によって図示されるように、1または複数のキューおよび関連する複数のクライアントIDのキューフィルレベルに関する情報を送信する。このタイプのメッセージもまた、スロットリングコマンドに関連して送信され得る。別のオプションとして、送信サーバは、スロットリングアップコマンドまたはリクエストを受信サーバに送信してよく、受信サーバに所与のクライアントID接続に対して増加されたパケットフローのために予測または設定するように要求するか、または命令する。
一般に、プロキシサーバとウェブサーバとの間の複数の制御メッセージは、多重TCP接続上で(例えば、インジケータを制御するためのデータ/制御フラグを設定することによって)送信されてよく、または、バックチャネル、制御チャネル、またはサイドバンド接続として時々称される、別個の接続(不図示)上で送信されてもよい。様々なパケットフォーマットが制御メッセージングを促すべく用いられ、その用いられる特定のフォーマットは、複数のサーバ間での制御メッセージングを実装するための複数の技術は周知であることから、本開示の範囲外である。更に、図7にウェブサーバ122から発信されているとして示される複数のメッセージは、また、適用可能な状況においてはプロキシサーバ200から発生してもよい。例えば、プロキシサーバは、また、ウェブサーバにスロットリングコマンドまたは一時シャットダウンコマンドを発行してもよい。
制御情報の更なる複数の例は以下を含む。プロキシからの制御情報は、「新たなクライアント、ニックネームNを用いたい」と言うかもしれない。応答において、サーバは、「あまりにも多くのクライアント」または「OK。新たなクライアントを受け入れる。」と言ってよい。一実施形態では、クライアントNに対するデータに対するシーケンス番号は、1または任意の他の予め定められた数(最初の複数のシーケンスナンバーに特異なことをするTCPとは対照的ではあるが、ここで、それはサーバとプロキシとの間のTCP接続の内部であることから、各クライアントのデータを1で開始してよい)で開始する。
接続の閉鎖を開始するべく、プロキシまたはサーバは、「クライアントNが終了しており、クライアントID#Nを再利用することがしたい。」と言う制御メッセージングを送信してよい。応答において、受信者(規定通りに、プロキシまたはサーバのどちらか)は、「クライアントNのデータをシーケンス番号S1まで受け入れ、クライアントJのデータをシーケンス番号S2まで受け入れる」と言ってよい。
更なる例として、プロキシは(サーバへのTCP情報内部で)、P−S・TCP接続に対しておそらくシーケンス番号191で送信してよい。
クライアントX、シーケンス#15、92バイトのデータ
クライアントY、シーケンス#51、12バイトのデータ
応答において、サーバは、「我々のTCPシーケンス番号305まであなたが送信した全てのデータを受け入れた」と言ってよく、または別個に、「クライアントXを106までACKし、クライアントYを63までACKする」と言ってもよい。あるいは、サーバがYからのデータをもはや受け入れられない場合、「クライアントYを53までACKする」と言ってよい(それがYからのデータの2バイトだけ受け入れた場合、プロキシは次にYからの残りを後で再送信する)。
例示的な実装環境および複数のサーバアーキテクチャ
本明細書の実施形態の態様は、データセンタおよび/またはサーバファーム環境において使用される様々なタイプのサーバ等の様々なタイプのコンピューティングおよびネットワーキング機器において実装されてよいことが想定される。一般的に、複数のデータセンタおよび複数のサーバファームにおいて用いられる複数のサーバは、複数のラックベースのサーバまたは複数のブレードサーバ等の複数の配列されたサーバ構成を備える。これらのサーバは、プライベートなイントラネットを形成する複数のLANの間の適切な複数のスイッチングおよびルーティング設備で複数のLANに複数のサーバの複数のセットを分割すること等、様々なネットワーク設備を介する通信において相互接続されている。例えば、クラウドホスティング設備は、一般的に、多数のサーバを持つ複数の大きなデータセンタを用いてよい。
概要として、複数の一般的なブレードサーバコンポーネントおよび複数のシステムは、図8a―cおよび9において示されている。一般的な構成において、ラックマウント式筐体800は、複数のサーバブレード(複数のブレードとしても知られる)802に対する電力及び複数の通信機能を提供するべく使用され、各ブレードは、対応するスロットを占有する。(筐体における全てのスロットは占領される必要はないことに留意されたい。)その代わりに、1または複数の筐体800が図8cに示されるブレードサーバラック803において取り付けられてもよい。各ブレードは、インタフェースプレーン804(例えば、バックプレーンまたはミッドプレーン)に、1または複数のコネクタを介して設置されると結合される。一般的に、インタフェースプレーンは、複数のブレードに電力および複数の通信信号を提供する複数のそれぞれの嵌合している複数のコネクタを含み、複数のブレードの間の複数のイーサネット(登録商標)信号を結合させるための複数のルーティングされた信号パスを含む。現在の実施において、多くのインタフェースプレーンは、複数のブレードがオンザフライ(on the fly)で追加されまたは除去される(「ホットスワップ(hot swap)される」)「ホット‐スワップ」機能を、全体の筐体を適切な電力およびデータ信号バッファリングを介して取り出すことなく提供する。
一般的なミッドプレーンインタフェースプレーン構成が、図8aおよび図8bにおいて示されている。インタフェースプレーン804の裏面は、1または複数の電源806に結合される。しばしば、複数の電源は、冗長でありホットスワップ可能であり、電源故障の場合において継続するオペレーションを可能にするべく、適切な電力および調整回路に結合されている。選択的な構成において、複数の電源のアレイが、複数のブレードのラック全体に電力を供給するべく用いられてよく、ここで、1対1の電源‐筐体対応は無い。複数の冷却ファン808が筐体を通じて空気を引き込むべく使用され、複数のサーバブレードを冷却する。
全てのブレードサーバに必要とされる重要な特徴は、他のITインフラストラクチャと外部で通信するための能力である。これは、一般的に、各々がインタフェースプレーン804に結合されている1または複数のネットワーク接続カード810を介して促進される。一般に、ネットワーク接続カードは、複数のネットワークポート接続(例えば、RJ−45ポート)を備える物理的インタフェースを含んでよく、またはネットワークスイッチ、ハブ、またはルータ等のネットワークデバイスに直接接続するように設計された高密度コネクタを備えてもよい。トップオブラック(ToR)スイッチアーキテクチャおよび複数の分解されたスイッチアーキテクチャ等、複数の他のネットワークアーキテクチャもまた用いられてよく、複数のネットワークリンクが複数の有線および/または光ケーブルを備えてもよいことに留意されたい。
複数のブレードサーバは、通常、複数の個別のブレードの複数のオペレーションを管理するための任意のタイプの管理インタフェースを提供する。これは、一般に、内蔵のネットワークまたは通信チャネルまたは複数のチャネルによって促進され得る。例えば、「プライベート」または「管理」ネットワークを促進するための1または複数のバスおよび適切なスイッチングが、インタフェースプレーンに内蔵され、あるいはプライベートネットワークが密に結合されたネットワークケーブル配線およびネットワークを介して実装され得る。任意選択的に、スイッチングおよび他の管理機能は、インタフェースプレーンの裏面または前面に結合されている管理スイッチカード812によって提供され得る。更に別のオプションとして、管理または構成サーバは、複数のブレードアクティビティを管理するべく使用されてよく、ここで、複数の通信は、例えばイーサネット(登録商標)等、標準のコンピュータネットワーキングインフラストラクチャを介して処理される。
図9を参照して、例示的なブレード900の更なる詳細が示される。上述したように、各ブレードは、複数のサーバタイプ機能を実行するように構成されている別個のコンピューティングプラットフォーム、つまり「カード上のサーバ」を備える。 従って、各ブレードは、メインプリント基板(メインボード901)を含む、従来の複数のサーバと共通の複数のコンポーネントを含み、適切な複数の集積回路(IC)および他のボードにマウントされる複数のコンポーネントを結合するための内部配線(つまり、複数のバス)を提供する。これらのコンポーネントは、システムメモリ904(例えば、ランダムアクセスメモリ(RAM)の任意の形態)、キャッシュメモリ906(例えば、SDRAM)、およびファームウェアストレージデバイス908(例えば、フラッシュメモリ)に結合された1または複数のプロセッサ(CPUとしても知られる)902を含む。NIC(ネットワークインタフェースコントローラ)チップ910が、ブレードと外部のネットワークインフラストラクチャとの間の通信をサポートする等、複数の従来のネットワーク通信機能をサポートすることを目的として提供される。複数の他に示されるコンポーネントは、ステータスLED(発光ダイオード)912、1または複数のRJ−45イーサネット(登録商標)ポート914(簡略化のため、それらのうちの1つだけが示される)、およびインタフェースプレーンコネクタ916を含む。複数の追加のコンポーネントは、様々な受動的コンポーネント(つまり、複数のレジスタ、複数のキャパシタ)、複数の電力調整コンポーネント、および複数の周辺デバイスコネクタを含む。
一般に、各ブレード900は、また、オンボードのストレージも提供してよい。これは、1または複数のディスクドライブ918が結合される1または複数の内蔵ディスクコントローラおよび対応するコネクタを介して一般的に促進される。例えば、一般的な複数のディスクコントローラは、SATAコントローラ、SCSIコントローラ、および同様のものを含む。一般に、ディスクドライブ918は、磁気ドライブまたはソリッドステートドライブ(SSD)を備えてよい。オプションとして、複数のディスクドライブは、大量なデータを記憶するために使用され得る、ネットワークに取り付けられたストレージ(NAS)電気機器またはバックエンドストレージサブシステムの場合等、同一または別個のラックにおいて、複数のブレードから離れて収容されてよい。
NIC910は、物理層(L1)およびデータリンク層オペレーション(L2)(例えば、イーサネット(登録商標)MACオペレーション)に対するサポート等、複数の対応するネットワーキングオペレーションを促進するための回路およびロジックを備える。一般的に、複数の上部層オペレーションは、プロセッサ902において実行されているオペレーティングシステムによってホスティングされるであろうオペレーティングシステムネットワークスタックによって促進される。しかしながら、いくつかの実施形態において、NICは、埋め込み論理または同様のものを介してそれ自身のネットワークスタックを用いてよい。
一般に、現在の複数のサーバプロセッサは、複数の機能的コンポーネント、複数のブロック、および複数のインタフェースがチップ上で集積されている複数のシステムオンチップ(SoC)アーキテクチャを用いる。いくつかのSoCアーキテクチャにおいて、プロセッサは、複数のコアを備えるCPUを含む。
一般的なデータセンタ配置において、複数のネットワークスイッチング要素は、1U、2U、または4Uスロット等を占領するであろうラックマウント式機器を備え、あるいは1または複数のサーバブレードを介して実装され得る。 任意選択的に、ネットワークスイッチング要素は、1または複数のサーバブレードを用いて実装され得る。
ワークロードに応じて、本明細書で説明されるプロキシサーバおよびウェブサーバオペレーションは、単一ブレード、筐体における複数のスロットの一部分を占有する一式のブレード、複数のブレードを持つ筐体、またはマルチソケットのサーバ等、現在および将来の複数のデータセンタ環境において配置される他のタイプの複数のサーバを介して実装されてよい。複数のプロキシサーバおよびウェブサーバは、いくつかの実施形態において複数の物理的エンティティとして実装され得るが、一方、他の複数の実施形態は、物理的および仮想のエンティティの組み合わせを用いてよい。
本明細書において記載される主題の更なる複数の態様は、以下の複数の番号付けされた節において説明される。
1.プロキシサーバで複数のクライアントとの複数のTCP接続を確立する段階であって、各TCP接続は、TCPポートを用いてプロキシサーバにクライアントを接続する段階と、
プロキシサーバを、ウェブサーバに多重TCP接続を介して通信結合させる段階と、
複数のクライアントから発信される複数の入力TCP通信をプロキシサーバで受信する段階であり、各入力TCP通信はパケットペイロードデータを含む少なくとも1つのTCPパケットを含む、段階と、
それぞれのクライアントデータストリームにおける所与のTCP接続上で受信される、複数のTCPパケットに含まれるパケットペイロードデータをバッファリングする段階と、
複数のクライアントデータストリームにおける複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントを、プロキシサーバで、複数の多重(MUX)TCPパケットにカプセル化する段階であって、複数のMUX・TCPパケットの少なくとも一部分は、少なくとも2つの別々のクライアントデータストリームからの複数のデータセグメントをカプセル化する段階と、
複数のMUX・TCPパケットをプロキシサーバから多重TCP接続上でウェブサーバにトランスポートする段階と、
ウェブサーバにおいて、複数のMUX・TCPパケットにおける複数のデータセグメントをデカプセル化し、複数のクライアントデータストリームを再アセンブルする段階と、
複数の再アセンブルされたクライアントデータストリームからパケットペイロードデータを抽出する段階と、を備える、方法。
2.節1の方法であって、第1TCP接続上で受信された1または複数のTCPパケットは、第1クライアントから送信されたハイパーテキストトランスポートプロトコル(HTTP)リクエストを備え、当該方法は、
HTTP応答を第1クライアントが行先となっているクライアントデータストリームに埋め込む段階と、
1または複数のMUX/TCPパケットにおけるクライアントデータストリームに対応する複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントをカプセル化する段階と、
1または複数のMUX/TCPパケットをウェブサーバからプロキシサーバへ多重TCP接続上でトランスポートする段階と、
MUX・TCPパケットからのデータセグメントをデカプセル化する段階と、
クライアントデータストリームを再アセンブルする段階と、
HTTP応答を抽出し、プロキシサーバから第1TCP接続上で行先クライアントへ転送される1または複数のTCPパケットにおけるHTTP応答をカプセル化する段階と、によってHTTP応答を第1クライアントへ戻す段階を更に備える、方法。
3.節1または2の方法であって、
各TCP接続に対し、プロキシサーバにおける少なくとも1つのキューをTCP接続に割り当てる段階と、
TCP接続に割り当てられた少なくとも1つのキューにおいて、TCP接続上で受信される複数のTCPパケットに含まれるパケットペイロードデータを備えるクライアントデータストリームをバッファリングする段階と、を更に備える、方法。
4.節3の方法であって、各TCP接続に対して割り当てられた、プロキシサーバにおける少なくとも1つのキューは出力キューを含み、当該方法は、
プロキシサーバの複数の出力キューにおいてTCP接続上でトランスファーされた複数のTCPパケットに含まれるパケットペイロードデータの複数のシーケンシャル実行を備えるクライアントデータストリームをバッファリングする段階であって、各出力キューはそれぞれのTCP接続に対して割り当てられる、段階と、
多重TCP接続を介してウェブサーバへトランスポートされる複数のMUX・TCPパケットのストリームを、複数のMUX・TCPパケットのストリームにおけるそれぞれの複数のMUX・TCPパケットにおいてカプセル化される複数のデータセグメントをプルするための複数の出力キューを選択するためのキューセレクタを用いて生成する段階と、を更に備える。
5.前述の節のいずれかの方法であって、
新たなクライアントから送信されるハイパーテキストトランスポートプロトコル(HTTP)リクエストを受信し、ウェブサーバを介してアクセスされるウェブサイトに対するユニバーサルリソースロケータ(URL)にアクセスする段階と、
新たなクライアントとプロキシサーバとの間で新たなTCP接続を確立する段階と、
プロキシサーバおよびウェブサーバの各々における複数のキューを割り当て、新たなクライアントからプロキシサーバで受信された複数のHTTPリクエストをウェブサーバに多重TCP接続上で転送すること、およびウェブサーバで生成された複数のHTTP応答を新たなクライアントに、多重TCP接続を介して、プロキシサーバおよび新たなTCP接続に転送することをサポートする段階と、を更に備える。
6.前述の節のいずれかの方法であって、多重TCP接続は全体の帯域幅を有し、
多重TCP接続の全体の帯域幅のそれぞれの帯域幅スライスを、プロキシサーバで確立された各TCP接続に対して、および多重TCP接続上で転送されるべきである複数のTCPパケットに対して、割り当てる段階と、
個別のTCP接続に対して割り当てられた帯域幅スライスが動的に調整されることを可能にする段階と、を更に備える。
7.ウェブサーバおよびプロキシサーバのうち少なくとも1つが、多重TCP接続上で転送される複数の個別のTCP接続に対するデータのトランスファーのレートを管理することを可能にする段階を更に備える、前述の節のいずれかの方法。
8.ウェブサーバおよびプロキシサーバのうち少なくとも1つが、選択されたTCP接続に対応するトラフィックが、多重TCP接続上で転送されることから一時的に中止させることを可能にする段階を更に備える、節7の方法。
9.節8の方法であって、ウェブサーバは、所与のTCP接続に対するトラフィックを一時的に中止するべくプロキシサーバにリクエストを送信し、
TCP接続上でクライアントから受信される入力TCPトラフィックをバッファリングすることを継続する段階と、
TCP接続に対するトラフィックが再開することが許されるという指示を受信する段階と、
バッファにおいて累積しているTCPトラフィックに対応する複数のデータセグメントをプロキシサーバからウェブサーバへ送信することを再開する段階と、を更に備える。
10.前述の節のいずれかの方法であって、
ウェブサーバからの情報をプロキシサーバへ送信し、多重化されてよく且つ多重TCP接続上で送信されてよい複数の同時データストリームの最大数を識別する段階と、
複数の同時データストリームの最大数に対応する多数のクライアント接続を確立する段階と、
プロキシサーバでウェブサーバと通信することを望む新たなクライアントからデータを受信する段階と、
新たなクライアントからのデータをバッファリングする段階と、
既存クライアントがサーバとの通信を終了したと判断することに応答して、新たなクライアントに対してウェブサーバと新たなクライアント接続をネゴシエートする段階と、を更に備える。
11.ウェブサーバ装置であって、
プロセッサと、
プロセッサに動作可能に結合されているメモリと、
プロセッサに動作可能に結合された少なくとも1つのネットワークポートを含むネットワークアダプタと、
複数の命令が中に記憶されており、
プロキシサーバとウェブサーバとの間で多重TCP接続を確立し、多重TCP接続はデータを、ネットワークアダプタにおけるネットワークポートに結合されたリンクを含む転送パスをトランスポートするように構成されており、複数のクライアントは複数のそれぞれのTCP接続を介してプロキシサーバに接続されていることと、
複数のクライアントを行先としているクライアントデータストリームデータを、複数の多重(MUX)TCPパケットのストリームとして多重TCP接続上でプロキシサーバへ送信し、各MUX・TCPパケットは、プロキシサーバとクライアントとの間のTCP接続上のクライアントに、プロキシサーバを介して転送されるべきである複数のTCPパケットにおいてカプセル化されるべきであるパケットペイロードデータを備える1または複数のクライアントデータストリームからの複数のシーケンシャル実行の複数のビットを備える、1または複数のデータセグメントをカプセル化することと、をウェブサーバ装置ができるようにするべく、プロセッサによって実行されるように構成されており、複数のMUX・TCPパケットの少なくとも一部分は少なくとも2つの別々のクライアントデータストリームに対する複数のデータセグメントをカプセル化する、複数のソフトウェアモジュールと、を備えるストレージデバイスと、を備える、ウェブサーバ装置。
12.節11のウェブサーバ装置であって、複数のソフトウェアモジュールは、更に、
多重TCP接続上で複数のMUX・TCPパケットのストリームをプロキシサーバから受信することであって、各MUX・TCPパケットは1または複数のデータセグメントをカプセル化し、各データセグメントは、TCPクライアントから受信されるクライアントデータストリームの一部分を備えることと、
複数のMUX・TCPパケットにおける複数のデータセグメントをデカプセル化し、複数のクライアントデータストリームを再アセンブルすることと、
複数の再アセンブルされたクライアントデータストリームからパケットペイロードデータを抽出することと、をウェブサーバ装置ができるようにするように構成されている。
13.節12のウェブサーバ装置であって、複数のソフトウェアモジュールは、更に、
メモリのメモリ空間における複数のキューのそれぞれのセットを、複数のクライアントをプロキシサーバに接続するべく用いられる複数のTCP接続の各々に対して割り当てることをウェブサーバ装置ができるようにするように構成されており、所与のTCP接続に対する複数のキューのそれぞれのセットは、少なくとも1つの出力キューおよび少なくとも1つの入力キューを含む。
14.節12のウェブサーバ装置であって、各TCP接続および接続に対して割り当てられた複数のキューのセットにおける複数のキューは、固有クライアント識別子によって識別される。
15.節11から15のいずれかのウェブサーバ装置であって、複数のモジュールは、ソフトウェア処理スタックを含み、当該複数のソフトウェアモジュールは、更に、
複数の出力キューにおけるソフトウェア処理スタックによって生成される複数のクライアントデータストリームをキューに加えることであって、各出力キューに対してキューに加えられた複数のクライアントデータストリームに含まれるデータは、単一のクライアントが行先となっていることと、
複数のMUX・TCPパケットのストリームにおけるそれぞれの複数のMUX・TCPパケットにおいてカプセル化されるべく、複数のデータセグメントをプルするための複数の出力キューを選択するためのキューセレクタを用いることによって、複数のMUX・TCPパケットのストリームを生成することと、をウェブサーバ装置ができるようにするように構成されている。
16.節15のウェブサーバ装置であって、複数のソフトウェアモジュールは、更に、
複数のTCP接続の各々に対して多重TCP接続のそれぞれの帯域幅スライスを割り当てることと、
複数のTCP接続に対して割り当てられた複数の帯域幅スライスに従って複数のデータセグメントをプルするための複数の出力キューを選択するキュー選択アルゴリズムを実装することと、をウェブサーバ装置ができるようにするように構成されている。
17.節16のウェブサーバ装置であって、複数のソフトウェアモジュールは、更に、
多重TCP接続を介してトランスポートされ、個々のベースで複数の選択されたTCP接続に関連している複数のクライアントデータストリームをスロットルさせる、または一時的に中止されることの少なくとも1つをウェブサーバ装置ができるようにするように構成されている。
18.プロキシサーバ装置であって、ウェブサーバに対してプロキシサーバとして動作するように構成され、
プロセッサと、
プロセッサに動作可能に結合されたメモリと、
プロセッサに動作可能に結合された複数のネットワークポートと、
複数のソフトウェアモジュールを備える複数の命令を中に記憶しているストレージデバイスと、を備え、
複数のソフトウェアモジュールは、
第1ネットワークポートでそれぞれの複数のクライアントとの複数のTCP接続を確立することと、
プロキシサーバとウェブサーバとの間の多重TCP接続を確立することであって、多重TCP接続は、プロキシサーバ装置における第2ネットワークポートに結合されたリンクを含む転送パスでデータをトランスポートするように構成されている、ことと、
複数のTCP接続上で複数のクライアントから複数のTCPパケットを受信することと、
プロキシサーバ装置を介してウェブサーバへプロキシ処理されることになっている複数のTCPパケットを識別することと、
プロキシサーバ装置を介してプロキシ処理されることになっており、それぞれのクライアントデータストリームにおける所与のTCP接続上で受信される複数のTCPパケットに含まれるデータをバッファリングすることと、
複数のシーケンシャル実行の複数のクライアントデータストリームを備える複数のデータセグメントを、複数の多重(MUX)TCPパケットにカプセル化することであって、複数のMUX・TCPパケットの少なくとも一部分は、複数のシーケンシャル実行の少なくとも2つの別々のクライアントデータストリームを備える複数のデータセグメントをカプセル化することと、
第2ネットワークポートからのアウトバウンドの複数のMUX・TCPパケットが多重TCP接続上のウェブサーバへ転送されるように送信することと、をプロキシサーバ装置ができるようにするべく、プロセッサによって実行されるように構成されている、プロキシサーバ装置。
19.節18のプロキシサーバ装置であって、複数のソフトウェアモジュールは、更に、
ウェブサーバから多重TCP接続上の複数のMUX・TCPパケットのストリームを受信することであって、各MUX・TCPパケットは、1または複数のクライアントデータストリームにおける複数のシーケンシャル実行の複数のビットを備える1または複数のデータセグメントをカプセル化することと、
複数のMUX・TCPパケットにおいてカプセル化された1または複数のデータセグメントをデカプセル化することと、
複数のクライアントデータストリームを再アセンブルすることと、
所与のクライアントデータストリームに関連しているTCP接続を識別することと、
所与のクライアントデータストリームに関連しているクライアントへ行くことになっている複数のTCPパケットにおける所与のクライアントデータストリームから抽出されたパケットペイロードデータをカプセル化することと、
クライアントに対するTCP接続上で行先クライアントへ複数のTCPパケットを転送することと、をプロキシサーバ装置ができるようにするように構成されている。
20.節18のプロキシサーバ装置であって、複数のソフトウェアモジュールは、更に、
複数のクライアントをプロキシサーバに接続するべく用いられる複数のTCP接続の各々に対し、メモリのメモリ空間における複数のキューのそれぞれのセットを割り当てることをプロキシサーバ装置ができるようにするように構成されており、所与のTCP接続に対する複数のキューのそれぞれのセットは、多重TCP接続を介してウェブサーバへ転送されることになっている複数のTCPパケットがバッファリングされる少なくとも1つの出力キューを含む。
21.節20のプロキシサーバ装置であって、複数のソフトウェアモジュールは、更に、
複数のTCP接続の各々に対して、多重TCP接続のそれぞれの帯域幅スライスを割り当てることと、
複数のTCP接続に対して割り当てられた複数の帯域幅スライスに従って、複数のデータセグメントをプルするための複数の出力キューを選択するキュー選択アルゴリズムを実装することと、をプロキシサーバ装置ができるようにするように構成されている。
22.節18のプロキシサーバ装置であって、複数のソフトウェアモジュールは、更に、
TCP接続を識別するウェブサーバからスロットルコマンドおよび中止コマンドのうち1つを受信することと、
応答において、多重TCP接続上でトランスポートされているTCP接続に関連しているクライアントデータストリームをスロットルすることおよび中止することのうち1つをすることと、をプロキシサーバ装置ができるようにするように構成されている。
23.複数の命令が記憶されている少なくとも1つの非一時的機械可読媒体であって、
プロキシサーバで複数のクライアントを持つ複数のTCP接続を確立することであって、各TCP接続は、TCPポートを用いてクライアントをプロキシサーバに接続することと、
通信しているプロキシサーバを、多重TCP接続を介してウェブサーバと結合させることと、
複数のクライアントから発信されている複数の入力TCP通信をプロキシサーバで受信することであって、各入力TCP通信は、ハイパーテキストトランスポートプロトコル(HTTP)リクエストを備えるデータを含む少なくとも1つのTCPパケットを含む、ことと、
所与のTCP接続に対し複数のTCPパケットから複数のHTTPリクエストを備えるパケットペイロードデータを抽出し、抽出されたパケットペイロードデータをクライアントデータストリームに加えることと、
プロキシサーバにおいて、複数のクライアントデータストリームの複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントを複数の多重(MUX)TCPパケットにカプセル化することであって、複数のMUX・TCPパケットの少なくとも一部分は、多重のクライアントデータストリームからの複数のデータセグメントをカプセル化することと、
プロキシサーバからの複数のMUX・TCPパケットを多重TCP接続上においてウェブサーバへトランスポートすることと、
ウェブサーバにおいて、複数のデータセグメントを複数のMUX・TCPパケットにデカプセル化し、複数のクライアントデータストリームを再アセンブルすることと、
再アセンブルされた複数のクライアントデータストリームから複数のHTTPリクエストを抽出することと、をプロキシサーバおよびウェブサーバができるようにするべく、プロキシサーバおよびウェブサーバにおいて実行されるように構成されている複数のソフトウェアモジュールを備える、少なくとも1つの非一時的機械可読媒体。
24.節23の少なくとも1つの非一時的機械可読媒体であって、一式の複数のソフトウェアモジュールは、更に、
HTTPリクエストを送信したクライアントが行先であるクライアントデータストリームにおけるHTTPリクエストにHTTP応答を埋め込むことと、
1または複数のMUX/TCPパケットにおいてクライアントデータストリームに対応する1または複数のデータセグメントをカプセル化することと、
1または複数のMUX/TCPパケットをウェブサーバからプロキシサーバへ多重TCP接続上においてトランスポートすることと、
1または複数のMUX/TCPパケットにおいてカプセル化された1または複数のデータセグメントをデカプセル化することと、
複数のクライアントデータストリームを再アセンブルすることと、
クライアントデータストリームに関連しているTCP接続を識別することと、
再アセンブルされたクライアントデータストリームからHTTP応答を抽出し、HTTP応答を、クライアントデータストリームに関連しているクライアントが行先である1または複数のTCPパケットにおいてカプセル化することと、
1または複数のTCPパケットをクライアントに対するTCP接続上において行先クライアントへ転送することと、をプロキシサーバおよびウェブサーバが、実行においてできるようにするように構成されている。
25.節24の少なくとも1つの非一時的機械可読媒体であって、HTTP応答が埋め込まれている1または複数のTCPパケットの各々は、プロキシサーバに対するIPアドレスに対応するソースインターネットプロトコル(IP)アドレスおよび行先クライアントに対するIPアドレスに対応する行先IPアドレスを有する。
26.節23―25のいずれかの少なくとも1つの非一時的機械可読媒体であって、一式の複数のソフトウェアモジュールは、更に、
各TCP接続に対して、TCP接続に対するプロキシサーバにおいて少なくとも1つのキューを割り当てることと、
TCP接続に割り当てられた少なくとも1つのキューにおいて、TCP接続上で受信された複数のTCPパケットに含まれるパケットペイロードデータを備える複数のクライアントデータストリームをバッファリングすることと、をプロキシサーバおよびウェブサーバが実行においてできるようにするように構成されている。
27.節26の少なくとも1つの非一時的機械可読媒体であって、各TCP接続に対して割り当てられたプロキシサーバにおける少なくとも1つのキューは、出力キューを含み、一式の複数のソフトウェアモジュールは、更に、
プロキシサーバにおける複数の出力キューにおいて、TCP接続上でトランスファーされる複数のTCPパケットに含まれる複数のシーケンシャル実行のパケットペイロードデータを備えるクライアントデータストリームをバッファリングすることであって、各出力キューは、それぞれのTCP接続に対して割り当てられている、ことと、
多重TCP接続を介してウェブサーバへトランスポートされることになっている複数のMUX・TCPパケットのストリームを、複数のMUX・TCPパケットのストリームにおけるそれぞれの複数のMUX・TCPパケットにおいてカプセル化されるべく、複数のデータセグメントをプルするための複数の出力キューを選択するためのキューセレクタを用いることによって、生成することと、をプロキシサーバおよびウェブサーバが実行においてできるようにするように構成されている。
28.節23―27のいずれかの少なくとも1つの非一時的機械可読媒体であって、一式の複数のソフトウェアモジュールは、更に、
新たなクライアントから送信されたHTTPリクエストを受信し、ウェブサーバを介してアクセスされるウェブサイトに対するユニバーサルリソースロケータ(URL)にアクセスすることと、
新たなクライアントとプロキシサーバとの間において新たなTCP接続を確立することと、
新たなクライアントからプロキシサーバで受信された複数のHTTPリクエストを、多重TCP接続を介してウェブサーバへ転送すること、およびウェブサーバで生成された複数のHTTP応答を、多重TCP接続を介して新たなクライアントへ、プロキシサーバおよび新たなTCP接続へ転送することをサポートするべく、プロキシサーバおよびウェブサーバの各々における複数のキューを割り当てることと、をプロキシサーバおよびウェブサーバが、実行において、できるようにするように構成されている。
29.節23から28のいずれかの少なくとも1つの非一時的機械可読媒体であって、多重TCP接続は全体の帯域幅を有し、一式の複数のソフトウェアモジュールは、更に、
プロキシサーバで確立された各TCP接続に対して、およびどの複数のTCPパケットが多重TCP接続上で転送されることになっているかに対して、多重TCP接続の全体の帯域幅のそれぞれの帯域幅スライスを割り当てることと、
個別のTCP接続に対して割り当てられた帯域幅スライスが、動的に調整されることを可能にすることと、をプロキシサーバおよびウェブサーバが、実行において、できるようにするように構成されている。
30.節23から29のいずれかの少なくとも1つの非一時的機械可読媒体であって、一式の複数のソフトウェアモジュールは、更に、ウェブサーバおよびプロキシサーバのうち少なくとも1つが、実行において、多重TCP接続上で転送される複数の個別のTCP接続に対するデータのトランスファーのレートを管理することができるようにするように構成されている。
31.節23から30のいずれかの少なくとも1つの非一時的機械可読媒体であって、一式の複数のソフトウェアモジュールは、更に、実行において、ウェブサーバおよびプロキシサーバのうち少なくとも1つが、選択されたTCP接続に対応するトラフィックが、多重TCP接続上で転送されることを中止することができるようにするように構成されている。
32.節31の少なくとも1つの非一時的機械可読媒体であって、ウェブサーバは、プロキシサーバに、所与のTCP接続に対してトラフィックを中止するリクエストを送信し、一式の複数のソフトウェアモジュールは、更に、プロキシサーバおよびウェブサーバが、実行において、
TCP接続上でクライアントから受信される入力TCPトラフィックをバッファリングすることを継続することと、
TCP接続に対するトラフィックが再開することが許されるという指示を受信することと、
バッファにおいて累積しているTCPトラフィックに対応する複数のデータセグメントのプロキシサーバからウェブサーバへの送信を再開することと、ができるようにするように構成されている。
33.節23から32のいずれかの少なくとも1つの非一時的機械可読媒体であって、一式の複数のソフトウェアモジュールは、更に、
情報をウェブサーバからプロキシサーバへ送信し、多重化されており、多重TCP接続上で送信される複数の同時データストリームの最大数を識別することと、
同時データストリームの最大数に対応する多数のクライアント接続の数を確立することと、
プロキシサーバで、ウェブサーバと通信することを望む新たなクライアントからデータを受信することと、
新たなクライアントからのデータをバッファリングすることと、
既存クライアントがサーバとの通信が終了していると判断することに応答して、新たなクライアントに対しウェブサーバとの新たなクライアント接続をネゴシエートすることと、をプロキシサーバおよびウェブサーバが実行においてできるようにするように構成されている。
34.ウェブサーバ装置であって、
プロセッサと、
プロセッサに動作可能に結合されているメモリと、
プロセッサに動作可能に結合された少なくとも1つのネットワークポートを含むネットワークアダプタと、
プロキシサーバとウェブサーバとの間で多重TCP接続を確立するためであり、多重TCP接続はデータを、ネットワークアダプタにおけるネットワークポートに結合されたリンクを含む転送パスにおいてトランスポートするように構成されており、複数のクライアントはそれぞれの複数のTCP接続を介してプロキシサーバに接続されている、且つ
複数のクライアントを行先としているクライアントデータストリームデータを、複数の多重(MUX)TCPパケットのストリームとして多重TCP接続上でプロキシサーバに送信するため、の手段と、を備え、
各MUX・TCPパケットは、プロキシサーバとクライアントとの間のTCP接続上でクライアントに、プロキシサーバを介して転送されるべき複数のTCPパケットにおいてカプセル化されるべきであるパケットペイロードデータを備える1または複数のクライアントデータストリームからの複数のシーケンシャル実行の複数のビットを備える、1または複数のデータセグメントをカプセル化し、複数のMUX・TCPパケットの少なくとも一部分は少なくとも2つの別々のクライアントデータストリームに対する複数のデータセグメントをカプセル化する、ウェブサーバ装置。
35.節34のウェブサーバ装置であって、更に、
プロキシサーバから多重TCP接続上で複数のMUX・TCPパケットのストリームを受信し、各MUX・TCPパケットは、1または複数のデータセグメントをカプセル化し、各データセグメントはTCPクライアントから受信されたクライアントデータストリームの一部分を備え、
複数のMUX・TCPパケットにおける複数のデータセグメントをデカプセル化し、複数のクライアントデータストリームを再アセンブルし、且つ
再アセンブルされた複数のクライアントデータストリームからパケットペイロードデータを抽出する、手段を備えるウェブサーバ装置。
36.複数のクライアントをプロキシサーバに接続するべく用いられる複数のTCP接続の各々に対し、メモリのメモリ空間における複数のキューのそれぞれのセットを割り当てるための手段を更に備え、所与のTCP接続に対する複数のキューのそれぞれのセットは、少なくとも1つの出力キューおよび少なくとも1つの入力キューを含む、節35のウェブサーバ装置。
37.各TCP接続および接続に対して割り当てられた複数のキューのセットにおける複数のキューは、固有クライアント識別子によって識別される、節35のウェブサーバ装置。
38.ソフトウェア処理スタックにおって生成される複数のクライアントデータストリームを複数の出力キューに加えるためであって、各出力キューに加えられた複数のクライアントデータストリームに含まれるデータは、単一のクライアントが行先であり、且つ
複数のMUX・TCPパケットのストリームにおけるそれぞれの複数のMUX・TCPパケットにおいてカプセル化されるべく、複数のデータセグメントをプルするための複数の出力キューを選択するためのキューセレクタを用いることによって、複数のMUX・TCPパケットのストリームを生成するための手段を更に備える、節34―38のいずれかのウェブサーバ装置。
39.複数のTCP接続の各々に対して、多重TCP接続のそれぞれの帯域幅スライスを割り当てるためであり、且つ
複数のTCP接続に対して割り当てられた複数の帯域幅スライスに従って、複数のデータセグメントをプルするための複数の出力キューを選択するキュー選択アルゴリズムを実装するための手段を、更に備える、節38のウェブサーバ装置
40.多重TCP接続を介してトランスポートされ、複数の選択されたTCP接続に個々のベースで関連している複数のクライアントデータストリームをスロットルまたは一時的に中止することのうち少なくとも1つのための手段を更に備える、節39のウェブサーバ装置。
41.プロキシサーバ装置であって、ウェブサーバに対してプロキシサーバとして動作するように構成され、
プロセッサと、
プロセッサに動作可能に結合されたメモリと、
プロセッサに動作可能に結合された複数のネットワークポートと、
第1ネットワークポートでそれぞれのクライアントとの複数のTCP接続を確立するため、
プロキシサーバとウェブサーバとの間の多重TCP接続を確立するためであって、多重TCP接続は、プロキシサーバ装置における第2ネットワークポートに結合されたリンクを含む転送パスでデータをトランスポートするように構成されており、
複数のTCP接続上で複数のクライアントから複数のTCPパケットを受信するためであり、
プロキシサーバ装置を介してウェブサーバへプロキシ処理されることになっている複数のTCPパケットを識別するためであり、
プロキシサーバ装置を介してプロキシ処理されることになっており、それぞれのクライアントデータストリームにおける所与のTCP接続上で受信される複数のTCPパケットに含まれるデータをバッファリングするためであり、
複数のシーケンシャル実行の複数のクライアントデータストリームを備える複数のデータセグメントを、複数の多重(MUX)TCPパケットにおいてカプセル化するためであって、複数のMUX・TCPパケットの少なくとも一部分は、複数のシーケンシャル実行の少なくとも2つの別々のクライアントデータストリームを備える複数のデータセグメントをカプセル化するためであり、且つ
第2ネットワークポートからのアウトバウンドの複数のMUX・TCPパケットが多重TCP接続上のウェブサーバへ転送されるように送信するための、手段を備える、プロキシサーバ装置。
42.ウェブサーバから多重TCP接続上で複数のMUX・TCPパケットのストリームを受信するためであって、各MUX・TCPパケットは、1または複数のクライアントデータストリームにおいて複数のシーケンシャル実行の複数のビットを備える1または複数のデータセグメントをカプセル化するためであり、
複数のMUX・TCPパケットにおいてカプセル化された1または複数のデータセグメントをデカプセル化するためであり、
複数のクライアントデータストリームを再アセンブルするためであり、
所与のクライアントデータストリームに関連しているTCP接続を識別するためであり、
所与のクライアントデータストリームに関連しているクライアントが行先である複数のTCPパケットにおいて所与のクライアントデータストリームから抽出されたパケットペイロードデータをカプセル化するためであり、且つ
クライアントに対するTCP接続上で行先クライアントに複数のTCPパケットを転送するための、手段を更に備える、節41のプロキシサーバ装置。
43.複数のクライアントをプロキシサーバに接続するべく用いられる複数のTCP接続の各々に対して、メモリのメモリ空間における複数のキューのそれぞれのセットを割り当てられるための手段を更に備え、所与のTCP接続に対する複数のキューのそれぞれのセットは、多重TCPを介してウェブサーバに転送されるべき複数のTCPパケットがバッファリングされる、少なくとも1つの出力キューを含む、節41または42のプロキシサーバ装置。
44.複数のTCP接続の各々に対して多重TCP接続のそれぞれの帯域幅スライスを割り当てるためであり、且つ
複数のTCP接続に対して割り当てられた複数の帯域幅スライスに従って、複数のデータセグメントをプルするための複数の出力キューを選択するキュー選択アルゴリズムを実装するための手段を更に備える、節43のプロキシサーバ装置。
45.TCP接続を識別するウェブサーバからスロットルコマンドおよび中止コマンドのうちの1つを受信するためであり、且つ
応答において、多重TCP接続上でトランスポートされているTCP接続に関連しているクライアントデータストリームをスロットリングまたは中止するうちの1つを行うための手段を更に備える、節41―44のいずれかのプロキシサーバ装置。
上述したように、本明細書の複数の実施形態の様々な態様は、サーバプロセッサまたは同様のものによって実行されるソフトウェアおよび/またはファームウェア等に対応する複数のソフトウェアおよび/またはファームウェアコンポーネントおよびアプリケーションによって促進され得る。従って、本発明の複数の実施形態は、ソフトウェアプログラム、ソフトウェアモジュール、ファームウェア、および/またはプロセッサ、処理コアまたは埋め込み論理の任意の形式において、またはプロセッサまたはコアにおいて実行されている仮想マシーンにおいて実行される、あるいはそうでなければコンピュータ可読または機械可読非一時的記憶媒体において、またはその内部で実装または実現される、分散型ソフトウェアとして用いられ得る、またはそれをサポートする。コンピュータ可読または機械可読非一時的記憶媒体は、情報を記憶または送信するための任意の機構を、機械(例えば、コンピュータ)によって可読な形式で含む。例えば、コンピュータ可読または機械可読非一時的記憶媒体は、記録可能/記録不可能な複数の媒体(例えば、リードオンリーメモリ(ROM)、ランダムアクセスメモリ(RAM)、)、磁気記憶媒体、光記憶媒体、フラッシュメモリデバイス等)等、コンピュータまたはコンピューティングマシーン(例えば、コンピューティングデバイス、電子システム等)によってアクセス可能な形式で情報を提供する(つまり、記憶するおよび/または送信する)任意の機構を含む。コンテンツは、直接実行可能な(「オブジェクト」または「実行可能」形式の)ソースコードまたは差分コード(「デルタ」もしくは「パッチ」 コード)であり得る。コンピュータ可読または機械可読非一時的記憶媒体は、また、コンテンツがダウンロードされ得るストレージまたはデータベースを含む。コンピュータ可読または機械可読非一時的記憶媒体は、また、販売または配達時にそれに記憶されているコンテンツを有するデバイスまたは製品を含んでもよい。従って、記憶されたコンテンツを持つデバイスを供給すること、または通信媒体上のダウンロード用のコンテンツを提供することは、本明細書で説明するようなコンテンツを持つコンピュータ可読または機械可読非一時的記憶媒体を備える製造の物品を提供することであるとして理解され得る。
本明細書で説明された複数の処理、複数のサーバまたは複数のツールとして上記で称された様々なコンポーネントは、説明された複数の機能を実行するための手段であってよい。本明細書において説明された様々なコンポーネントによって実行される複数のオペレーションおよび機能は、処理要素において、埋め込まれたハードウェアまたは同様のものを介して実行されるソフトウェア、あるいはハードウェアおよびソフトウェアの任意の組み合わせによって実装されてよい。そのような複数のコンポーネントは、複数のソフトウェアモジュール、複数のハードウェアモジュール特殊用途のハードウェア(例えば、アプリケーション特有のハードウェア、ASIC、DSP等)、複数の埋め込まれたコントローラ、ハードウェアに組み込まれた回路、ハードウェアロジック等として実装されてよい。ソフトウェアコンテンツ(例えば、データ、複数の命令、構成情報等)は、実行され得る複数の命令を表すコンテンツを提供するコンピュータ可読または機械可読非一時的記憶媒体を含む製造の物品を提供してよい。上記コンテンツは、本明細書で説明された様々な機能/オペレーションを実行するコンピュータに結果的にもたらされてよい。
いくつかの実施形態は、特定の実装を参照して説明されているが、いくつかの実施形態に従って、他の実装が可能である。更に、図面に示されたおよび/またはここ本明細書で説明された複数の要素または他の複数の特徴の構成、および/または順序は、示され、および説明された特定の方法で構成される必要はない。いくつかの実施形態に従って、多くの他の構成が可能である。
図に示される各システムにおいて、場合によって、複数の要素は、表される複数の要素が、異なるおよび/または類似してよいことを示唆すべく、それぞれ同一の参照番号を有するかまたは異なる参照番号を有してよい。しかしながら、要素は、異なる複数の実装を有し、本明細書で示された、または説明されたシステムのいくつかまたは全てと協働できるように十分に柔軟であってよい。図に示される様々な要素は、同一または異なっていてあってよい。どちらが第1の要素と称され、どちらが第2の要素と呼ばれるかは任意である。
以下の記述及び複数の請求項において、「結合」及び「接続」という用語は、それらの派生物と共に、使用されてよい。これらの複数の用語は、互いの類義語として意図されるものではないことを理解されるべきである。むしろ、複数の特定の実施形態では、「接続」は、2またはそれより多くの要素が、互いに直接物理的にまたは電気的に接触することを示すために用いられてもよい。「結合」は、2またはそれより多くの要素が、直接物理的にまたは電気的に接触することを意味してもよい。しかしながら、「結合」は、2またはそれより多くの要素が、互いに直接接触しないが、互いに連動または連携することもまた更に意味してもよい。
実施形態は発明の1つの実装例または例である。明細書における「一実施形態」、「1つの実施形態」、「いくつかの実施形態」、「様々な実施形態」または「複数の他の実施形態」に対する参照は、複数の実施形態に関連して説明された特定の特徴、構造または特徴が、本発明の、少なくともいくつかの実施形態に含まれることを意味するが、全ての実施形態に含まれることは必ずしも意味しない。「実施形態」、「一実施形態」、または「いくつかの実施形態」の様々な出現は、必ずしも全てが同じ実施形態を指しているわけではない。
本明細書で説明及び示される全てのコンポーネント、特徴、構造、特性等は、特定の実施形態または複数の実施形態に含まれる必要があるとは限らない。本明細書においてコンポーネント、特徴、構造または特性が含まれ「てもよい」、含まれる「場合がある」、含まれ「得る」、または含まれ「得た」と述べた場合には、例えば、特定のコンポーネント、特徴、構造または特性が含まれることは要求されない。明細書または請求項で、「ある」要素と参照した場合、要素が1つだけ存在することは意味しない。明細書または請求項で、「ある追加の」要素を指す場合、追加の要素が1つより多い場合は除外しない。
上述の詳細な説明の「n」等のイタリック文字は、整数を示すべく用いられ、特定の文字の使用は、特定の実施形態に限定されない。更に、同一の文字が、別々の複数の整数を表すべく別々の請求項において用いられてもよく、あるいは、異なる文字が用いられてもよい。更に、詳細な説明において特定の文字を用いることは、詳細な説明における同一の主題に関連する請求項で用いられる文字に一致してもよい、またはしなくてもよい。
本明細書で用いられるように、「少なくとも1つ」という用語が加わっているアイテムのリストは、リストされた複数の用語の任意の組み合わせを意味してよい。例えば、「A、BまたはCの少なくとも1つ」という文言は、A、B、C,AおよびB、AおよびC、BおよびC、またはA、BおよびCを意味してよい。
本発明の例示された複数の実施形態の上記の説明は、要約の記載も含めて、海自される形式が包括的であるまたは開示される形式に厳密に本発明を限定することを意図していない。本発明の特定の実施形態及び実施例は、本明細書で例示するために説明される一方、本発明の範囲内において様々な均等な変更が可能であり、そのような変更は当業者であれば認識できる。
これらの修正は、上記の詳細な説明に照らして本発明に行うことができる。以下の請求項の記載において使用される用語は、本発明を明細書および図面で開示された特定の実施形態に限定するものと解釈されるべきではない。むしろ、以下の請求項によって完全に決定される本発明の範囲は、請求項の解釈の確立された原則に従って解釈されるべきである。

Claims (27)

  1. 数のクライアントとの複数のTCP接続をプロキシサーバで確立する段階であって、各TCP接続は、TCPポートを用いて前記プロキシサーバにクライアントを接続する、段階と、
    重TCP接続を介して前記プロキシサーバをウェブサーバと通信結合させる段階と、
    前記複数のクライアントから発信される複数の入力TCP通信を前記プロキシサーバで受信する段階であって、各入力TCP通信は、パケットペイロードデータを含む少なくとも1つのTCPパケットを含む、段階と、
    それぞれのクライアントデータストリームにおける所与のTCP接続上で受信される複数のTCPパケットに含まれる前記パケットペイロードデータをバッファリングする段階と、
    前記プロキシサーバにおいて、複数の前記クライアントデータストリームにおける複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントを、複数の多重TCPパケット(複数のMUX・TCPパケット)にカプセル化する段階であって、前記複数のMUX・TCPパケットの少なくとも一部分は、少なくとも2つの別々のクライアントデータストリームからの複数のデータセグメントをカプセル化する、段階と、
    前記複数のMUX・TCPパケットを前記プロキシサーバから前記ウェブサーバへ前記多重TCP接続上でトランスポートする段階と、
    前記ウェブサーバで、
    前記複数のMUX・TCPパケットにおける複数のデータセグメントをデカプセル化し、前記複数のクライアントデータストリームを再アセンブルする段階と、
    再アセンブルされた前記複数のクライアントデータストリームからパケットペイロードデータを抽出する段階と
    を備え、
    前記ウェブサーバを介してアクセスされるウェブサイトに対するユニバーサルリソースロケータ(URL)にアクセスするべく新たなクライアントから送信されるハイパーテキストトランスポートプロトコル(HTTP)リクエストを受信する段階と、
    前記新たなクライアントと前記プロキシサーバとの間で新たなTCP接続を確立する段階と、
    前記プロキシサーバで受信された複数のHTTPリクエストを前記新たなクライアントから前記ウェブサーバへ前記多重TCP接続を介して転送すること、および前記ウェブサーバで生成された複数のHTTP応答を、前記新たなクライアントに、前記プロキシサーバおよび前記新たなTCP接続への前記多重TCP接続を介して転送することをサポートするべく、前記プロキシサーバおよび前記ウェブサーバの各々において複数のキューを割り当てる段階と、を更に備え、
    前記プロキシサーバおよび前記ウェブサーバに割り当てられる前記複数のキューは、新たなクライアントのための前記複数のHTTPリクエスト及び前記複数のHTTP応答の利用のために専用のものである、方法。
  2. 多重化され、前記多重TCP接続上で送信され得る複数の同時データストリームの最大数を識別する情報を、前記ウェブサーバから前記プロキシサーバへ送信する段階と、
    前記複数の同時データストリームの前記最大数に対応する複数のクライアント接続を確立する段階と、
    前記プロキシサーバで、前記ウェブサーバと通信することを望む新たなクライアントからデータを受信する段階と、
    前記新たなクライアントからの前記データをバッファリングする段階と、
    既存クライアントが前記ウェブサーバと通信することを終了していると判断することに応答して、前記ウェブサーバと新たなクライアント接続を、前記新たなクライアントのためにネゴシエートする段階と、を更に備える、請求項1に記載の方法。
  3. 多重化され、プロキシサーバとウェブサーバとの間の多重TCP接続上で送信され得る複数の同時データストリームの最大数を識別する情報を、前記ウェブサーバから前記プロキシサーバへ送信する段階と、
    前記複数の同時データストリームの前記最大数に対応する複数のクライアントとの複数のTCP接続をプロキシサーバで確立する段階であって、各TCP接続は、TCPポートを用いて前記プロキシサーバにクライアントを接続する、段階と、
    前記多重TCP接続を介して前記プロキシサーバをウェブサーバと通信結合させる段階と、
    前記複数のクライアントから発信される複数の入力TCP通信を前記プロキシサーバで受信する段階であって、各入力TCP通信は、パケットペイロードデータを含む少なくとも1つのTCPパケットを含む、段階と、
    それぞれのクライアントデータストリームにおける所与のTCP接続上で受信される複数のTCPパケットに含まれる前記パケットペイロードデータをバッファリングする段階と、
    前記プロキシサーバにおいて、複数の前記クライアントデータストリームにおける複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントを、複数の多重TCPパケット(複数のMUX・TCPパケット)にカプセル化する段階であって、前記複数のMUX・TCPパケットの少なくとも一部分は、少なくとも2つの別々のクライアントデータストリームからの複数のデータセグメントをカプセル化する、段階と、
    前記複数のMUX・TCPパケットを前記プロキシサーバから前記ウェブサーバへ前記多重TCP接続上でトランスポートする段階と、
    前記ウェブサーバで、
    前記複数のMUX・TCPパケットにおける複数のデータセグメントをデカプセル化し、前記複数のクライアントデータストリームを再アセンブルする段階と、
    再アセンブルされた前記複数のクライアントデータストリームからパケットペイロードデータを抽出する段階と、
    前記プロキシサーバで、
    前記ウェブサーバと通信することを望む新たなクライアントからデータを受信する段階と、
    前記新たなクライアントからの前記データをバッファリングする段階と、
    既存クライアントが前記ウェブサーバと通信することを終了していると判断することに応答して、前記ウェブサーバと新たなクライアント接続を、前記新たなクライアントのためにネゴシエートする段階と
    を備える、方法。
  4. 第1TCP接続上で受信される前記1または複数のTCPパケットは、第1クライアントから送信されるハイパーテキストトランスポートプロトコル(HTTP)リクエストを備え、
    前記方法は、
    前記第1クライアントが行先であるクライアントデータストリームにおいてHTTP応答を埋めこむ段階と、
    1または複数のMUX・TCPパケットの前記クライアントデータストリームに対応する複数のシーケンシャル実行の複数のビットを備える複数のデータセグメントをカプセル化する段階と、
    前記ウェブサーバからの前記1または複数のMUX・TCPパケットを前記多重TCP接続上で前記プロキシサーバへトランスポートする段階と、
    前記1または複数のMUX・TCPパケットからの前記複数のデータセグメントをデカプセル化する段階と、
    前記クライアントデータストリームを再アセンブルする段階と、
    前記HTTP応答を抽出し、前記プロキシサーバから行先の前記クライアントへ前記第1TCP接続上で転送される1または複数のTCPパケットにおいて前記HTTP応答をカプセル化する段階と、によって、前記第1クライアントへ前記HTTP応答を戻す段階を更に備える、請求項1から3のいずれか一項に記載の方法。
  5. 各TCP接続に対し、
    前記プロキシサーバの少なくとも1つのキューを前記TCP接続に対して割り当てる段階と、
    前記TCP接続に対して割り当てられた前記少なくとも1つのキューにおいて、前記TCP接続上で受信される、複数のTCPパケットに含まれるパケットペイロードデータを備えるクライアントデータストリームをバッファリングする段階と
    を更に備える、請求項1から4のいずれか一項に記載の方法。
  6. 各TCP接続に対して割り当てられた前記プロキシサーバの前記少なくとも1つのキューは、出力キューを有し、
    前記方法は、
    前記プロキシサーバの複数の前記出力キューの前記TCP接続上でトランスファーされる複数のTCPパケットに含まれる複数のシーケンシャル実行のパケットペイロードデータを備えるクライアントデータストリームをバッファリングする段階であって、各出力キューはそれぞれのTCP接続に対して割り当てられる、段階と、
    複数のMUX・TCPパケットのストリームにおけるそれぞれの複数のMUX・TCPパケットにおいてカプセル化されるべき複数のデータセグメントをプルするための複数の出力キューを選択するキューセレクタを用いることによって、前記多重TCP接続を介して前記ウェブサーバへトランスポートされるべき複数のMUX・TCPパケットの前記ストリームを、生成する段階と、
    を更に備える、請求項に記載の方法。
  7. 前記多重TCP接続は、全体の帯域幅を有し、
    前記方法は、
    前記多重TCP接続の前記全体の帯域幅のそれぞれの帯域幅スライスを、前記プロキシサーバで確立された各TCP接続に対して、および前記多重TCP接続上で転送されるべき複数のTCPパケットに対して割り当てる段階と、
    個別のTCP接続に対して割り当てられた前記帯域幅スライスが動的に調整されることを可能にする段階と、を更に備える、請求項1からのいずれか一項に記載の方法。
  8. 前記ウェブサーバおよび前記プロキシサーバのうち少なくとも1つが、前記多重TCP接続上で転送される複数の個別のTCP接続に対するデータのトランスファーのレートを管理することを可能にする段階を更に備える、請求項1からのいずれか一項に記載の方法。
  9. 前記ウェブサーバおよび前記プロキシサーバのうち少なくとも1つが、選択されたTCP接続に対応するトラフィックが前記多重TCP接続上で転送されることを、中止することを可能にする段階を更に備える、請求項に記載の方法。
  10. 前記ウェブサーバは前記プロキシサーバにリクエストを送信し、所与のTCP接続に対するトラフィックを中止し、
    前記方法は、
    前記TCP接続上でクライアントから受信される入力TCPトラフィックをバッファリングすることを継続する段階と、
    前記TCP接続に対するトラフィックが再開することが許されるという指示を受信する段階と、
    バッファに累積されている前記入力TCPトラフィックに対応する複数のデータセグメントを、前記プロキシサーバから前記ウェブサーバへ送信することを再開する段階と、を更に備える、請求項に記載の方法。
  11. プロキシサーバおよびウェブサーバに、請求項1から10のいずれか一項に記載の方法を実行させるプログラム。
  12. ウェブサーバ装置であって、
    プロセッサと、
    前記プロセッサに動作可能に結合されたメモリと、
    前記プロセッサに動作可能に結合された少なくとも1つのネットワークポートを含むネットワークアダプタと、
    複数のソフトウェアモジュールを備える複数の命令を記憶しているストレージデバイスと、を備え、
    前記複数のソフトウェアモジュールは、
    前記ウェブサーバ装置が、
    多重化され、プロキシサーバと前記ウェブサーバ装置との間の多重TCP接続上で送信され得る複数の同時データストリームの最大数を識別する情報を前記プロキシサーバへ送信することと、
    前記プロキシサーバと前記ウェブサーバ装置との間で多重TCP接続を確立することであって、前記多重TCP接続は、前記ネットワークアダプタにおけるネットワークポートに結合されたリンクを含む転送パスにおいてデータをトランスポートし、前記複数の同時データストリームの前記最大数に対応する複数のクライアントが前記プロキシサーバにそれぞれの複数のTCP接続を介して接続されている、ことと、
    前記プロキシサーバに前記複数のクライアントを接続するべく用いられる前記複数のTCP接続の各々に対して前記メモリのメモリ空間における複数のキューのそれぞれのセットを割り当てることができるようにし、所与のTCP接続に対する複数のキューのそれぞれの前記セットが、少なくとも1つの出力キューおよび少なくとも1つの入力キューを有する、ことと
    前記複数のクライアントが行先であるクライアントデータストリームデータを、複数の多重TCPパケット(複数のMUX・TCPパケット)のストリームとして前記プロキシサーバへ前記多重TCP接続上で送信することであって、各MUX・TCPパケットは、前記プロキシサーバを介して前記プロキシサーバとクライアントとの間のTCP接続上で前記クライアントに転送されるべき複数のTCPパケットにおいてカプセル化されるパケットペイロードデータを備える、1または複数のクライアントデータストリームからの複数のシーケンシャル実行の複数のビットを備える1または複数のデータセグメントをカプセル化し、前記複数のMUX・TCPパケットの少なくとも一部分は、少なくとも2つの別々のクライアントデータストリームに対する複数のデータセグメントをカプセル化する、こと、とができるようにするべく、前記プロセッサによって実行される、ウェブサーバ装置。
  13. 前記複数のソフトウェアモジュールは、更に、前記ウェブサーバ装置が、
    前記プロキシサーバから前記多重TCP接続上で複数のMUX・TCPパケットのストリームを受信することであって、各MUX・TCPパケットは、1または複数のデータセグメントをカプセル化し、各データセグメントはTCPクライアントから受信されたクライアントデータストリームの一部分を備える、ことと、
    前記複数のMUX・TCPパケットにおける複数のデータセグメントをデカプセル化し、前記複数のクライアントデータストリームを再アセンブルすることと、
    前記再アセンブルされた複数のクライアントデータストリームからのパケットペイロードデータを抽出することと、をできるようにする、請求項12に記載のウェブサーバ装置。
  14. 各TCP接続および前記接続に対して割り当てられた複数のキューのセットにおける前記複数のキューは、固有クライアント識別子によって識別される、請求項12または13に記載のウェブサーバ装置。
  15. 前記複数のソフトウェアモジュールは、ソフトウェア処理スタックを有し、前記複数のソフトウェアモジュールは、更に、前記ウェブサーバ装置が、
    前記ソフトウェア処理スタックによって生成される複数のクライアントデータストリームを複数の出力キューに加えることであって、各出力キューに加えられた前記複数のクライアントデータストリームに含まれるデータは、単一のクライアントを行先としている、ことと、
    複数のMUX・TCPパケットのストリームを、
    前記複数のMUX・TCPパケットのストリームにおけるそれぞれの複数のMUX・TCPパケットにおいてカプセル化されるべきである、複数のデータセグメントをプルするための複数の出力キューを選択するキューセレクタを用いることによって生成することと、ができるようにする、請求項12から14のいずれか一項に記載のウェブサーバ装置。
  16. 前記複数のソフトウェアモジュールは、更に、前記ウェブサーバ装置が、
    前記複数のTCP接続の各々に対して前記多重TCP接続のそれぞれの帯域幅スライスを割り当てることと、前記複数のTCP接続に対して割り当てられた複数の前記帯域幅スライスに従って複数のデータセグメントをプルするための複数の出力キューを選択するキュー選択アルゴリズムを実装することとができるようにする、請求項15に記載のウェブサーバ装置。
  17. 前記複数のソフトウェアモジュールは、更に、前記多重TCP接続を介してトランスポートされる、および選択された複数のTCP接続に個々のベースで関連している複数のクライアントデータストリームをスロットルまたは中止するうち少なくとも1つを前記ウェブサーバ装置ができるようにする、請求項16に記載のウェブサーバ装置。
  18. 前記複数のソフトウェアモジュールは、更に、前記ウェブサーバ装置が、
    複数の多重TCP接続制御コマンドを前記プロキシサーバに送信し、前記プロキシサーバから複数のコマンド応答を受信することができるようにし、前記複数の多重TCP接続制御コマンドは、前記多重TCP接続を管理するために用いられる、請求項12から17のいずれか一項に記載のウェブサーバ装置。
  19. ウェブサーバに対するプロキシサーバとして動作するプロキシサーバ装置であって、
    プロセッサと、
    前記プロセッサに動作可能に結合されたメモリと、
    前記プロセッサに動作可能に結合された複数のネットワークポートと、
    複数のソフトウェアモジュールを備える複数の命令を記憶しているストレージデバイスと、を備え、
    前記複数のソフトウェアモジュールは、
    前記プロキシサーバ装置が
    1ネットワークポートで、複数のクライアントのそれぞれと複数のTCP接続を確立することと、
    前記プロキシサーバ装置と前記ウェブサーバとの間に多重TCP接続を確立することであって、前記多重TCP接続は、前記プロキシサーバ装置における第2ネットワークポートに結合されたリンクを含む転送パスにおいてデータをトランスポートする、ことと、
    前記複数のTCP接続上で前記複数のクライアントから複数のTCPパケットを受信することと、
    前記プロキシサーバ装置を介して前記ウェブサーバへプロキシ処理される複数のTCPパケットを識別することと、
    前記プロキシサーバ装置を介してプロキシ処理される、且つそれぞれのクライアントデータストリームの所与のTCP接続上で受信される前記複数のTCPパケットに含まれるデータをバッファリングすることと、
    複数の多重TCPパケット(複数のMUX・TCPパケット)における複数のシーケンシャル実行の複数の前記クライアントデータストリームを備える複数のデータセグメントをカプセル化することであって、前記複数のMUX・TCPパケットの少なくとも一部分は、複数のシーケンシャル実行の少なくとも2つの別々のクライアントデータストリームを備える複数のデータセグメントをカプセル化する、ことと、
    転送される前記第2ネットワークポートからのアウトバウンドの前記複数のMUX・TCPパケットを、前記多重TCP接続上で前記ウェブサーバに送信することと、
    ができるようにするべく、前記プロセッサによって実行され、
    前記複数のソフトウェアモジュールは、
    前記プロキシサーバ装置が、更に、
    前記ウェブサーバを介してアクセスされるウェブサイトに対するユニバーサルリソースロケータ(URL)にアクセスするべく新たなクライアントから送信されるハイパーテキストトランスポートプロトコル(HTTP)リクエストを受信することと、
    前記新たなクライアントと前記プロキシサーバとの間で新たなTCP接続を確立することと、
    前記プロキシサーバで受信された複数のHTTPリクエストを前記新たなクライアントから前記ウェブサーバへ前記多重TCP接続を介して転送すること、および前記ウェブサーバで生成された複数のHTTP応答を、前記新たなクライアントに、前記プロキシサーバおよび前記新たなTCP接続への前記多重TCP接続を介して転送することをサポートするべく、前記プロキシサーバおよび前記ウェブサーバの各々において複数のキューを割り当てることと、
    ができるようにするべく、前記プロセッサによって実行され、
    前記プロキシサーバおよび前記ウェブサーバに割り当てられる前記複数のキューは、新たなクライアントのための前記複数のHTTPリクエスト及び前記複数のHTTP応答の利用のために専用のものである、プロキシサーバ装置。
  20. 前記複数のソフトウェアモジュールは、
    前記プロキシサーバ装置が、更に、
    多重化され、前記プロキシサーバ装置と前記ウェブサーバとの間の多重TCP接続上で送信され得る複数の同時データストリームの最大数を識別する情報を、前記ウェブサーバから受信することと、
    前記複数の同時データストリームの前記最大数に対応する複数のクライアント接続を確立する段階と、
    前記ウェブサーバと通信することを望む新たなクライアントからデータを受信することと、
    前記新たなクライアントからの前記データをバッファリングすることと、
    既存クライアントが前記プロキシサーバ装置と通信することを終了していると判断することに応答して、前記ウェブサーバと新たなクライアント接続を、前記新たなクライアントのためにネゴシエートすることと、
    ができるようにするべく、前記プロセッサによって実行される、請求項19に記載のプロキシサーバ装置。
  21. ウェブサーバに対するプロキシサーバとして動作するプロキシサーバ装置であって、
    プロセッサと、
    前記プロセッサに動作可能に結合されたメモリと、
    前記プロセッサに動作可能に結合された複数のネットワークポートと、
    複数のソフトウェアモジュールを備える複数の命令を記憶しているストレージデバイスと、を備え、
    前記複数のソフトウェアモジュールは、
    前記プロキシサーバ装置が、
    多重化され、前記プロキシサーバ装置と前記ウェブサーバとの間の多重TCP接続上で送信され得る複数の同時データストリームの最大数を識別する情報を、前記ウェブサーバから受信することと、
    第1ネットワークポートで、前記複数の同時データストリームの前記最大数に対応する複数のクライアントのそれぞれと複数のTCP接続を確立することと、
    前記プロキシサーバ装置と前記ウェブサーバとの間に多重TCP接続を確立することであって、前記多重TCP接続は、前記プロキシサーバ装置における第2ネットワークポートに結合されたリンクを含む転送パスにおいてデータをトランスポートする、ことと、
    前記複数のTCP接続上で前記複数のクライアントから複数のTCPパケットを受信することと、
    前記プロキシサーバ装置を介して前記ウェブサーバへプロキシ処理される複数のTCPパケットを識別することと、
    前記プロキシサーバ装置を介してプロキシ処理される、且つそれぞれのクライアントデータストリームの所与のTCP接続上で受信される前記複数のTCPパケットに含まれるデータをバッファリングすることと、
    複数の多重TCPパケット(複数のMUX・TCPパケット)における複数のシーケンシャル実行の複数の前記クライアントデータストリームを備える複数のデータセグメントをカプセル化することであって、前記複数のMUX・TCPパケットの少なくとも一部分は、複数のシーケンシャル実行の少なくとも2つの別々のクライアントデータストリームを備える複数のデータセグメントをカプセル化する、ことと、
    転送される前記第2ネットワークポートからのアウトバウンドの前記複数のMUX・TCPパケットを、前記多重TCP接続上で前記ウェブサーバに送信することと、
    ができるようにするべく、前記プロセッサによって実行され、
    前記複数のソフトウェアモジュールは、
    前記プロキシサーバ装置が、更に、
    前記ウェブサーバと通信することを望む新たなクライアントからデータを受信することと、
    前記新たなクライアントからの前記データをバッファリングすることと、
    既存クライアントが前記プロキシサーバと通信することを終了していると判断することに応答して、前記ウェブサーバと新たなクライアント接続を、前記新たなクライアントのためにネゴシエートすることと
    ができるようにするべく、前記プロセッサによって実行されるプロキシサーバ装置。
  22. 前記複数のソフトウェアモジュールは、更に、前記プロキシサーバ装置が、
    複数のMUX・TCPパケットのストリームを前記ウェブサーバから前記多重TCP接続上で受信することであって、各MUX・TCPパケットは、1または複数のクライアントデータストリームにおける複数のシーケンシャル実行の複数のビットを備える1または複数のデータセグメントをカプセル化する、ことと、
    前記複数のMUX・TCPパケットにおいてカプセル化された前記1または複数のデータセグメントをデカプセル化することと、
    前記複数のクライアントデータストリームを再アセンブルすることと、
    所与のクライアントデータストリームに関連しているTCP接続を識別することと、
    前記所与のクライアントデータストリームから抽出されたパケットペイロードデータを、前記所与のクライアントデータストリームと関連しているクライアントを行先としている複数のTCPパケットにおいてカプセル化することと、
    前記クライアントに対する前記TCP接続上で、行先の前記クライアントへ前記複数のTCPパケットを転送することと、ができるようにする、請求項19から21のいずれか一項に記載のプロキシサーバ装置。
  23. 前記パケットペイロードデータは、複数のハイパーテキストトランスポートプロトコル(HTTP)応答を備える、請求項22に記載のプロキシサーバ装置。
  24. 前記複数のソフトウェアモジュールは、更に、前記プロキシサーバ装置が、
    前記複数のクライアントを前記プロキシサーバ装置に接続するべく用いられる前記複数のTCP接続の各々に対して、前記メモリのメモリ空間における複数のキューのそれぞれのセットを割り当てることができるようにし、所与のTCP接続に対する複数のキューのそれぞれの前記セットは、前記ウェブサーバに前記多重TCP接続を介して転送されるべき複数のTCPパケットがバッファリングされる、少なくとも1つの出力キューを有する、請求項22に記載のプロキシサーバ装置。
  25. 前記複数のソフトウェアモジュールは、更に、前記プロキシサーバ装置が、
    前記複数のTCP接続の各々に対して前記多重TCP接続のそれぞれの帯域幅スライスを割り当てることと、
    前記複数のTCP接続に対して割り当てられた複数の前記帯域幅スライスに従って複数のデータセグメントをプルするための複数の出力キューを選択するキュー選択アルゴリズムを実装することと、ができるようにする、請求項24に記載のプロキシサーバ装置。
  26. 前記複数のソフトウェアモジュールは、更に、前記プロキシサーバ装置が、
    TCP接続を識別している前記ウェブサーバからスロットルコマンドおよび中止コマンドのうちの1つを受信することと、
    応答において、前記多重TCP接続上でトランスポートされる前記TCP接続に関連しているクライアントデータストリームのスロットルおよび中止のうち1つをすることと、ができるようにする、請求項19から25のいずれか一項に記載のプロキシサーバ装置。
  27. 請求項11に記載のプログラムを記憶しているコンピュータ可読記憶媒体。
JP2015228864A 2014-12-26 2015-11-24 単一接続上での多くのクライアントストリームの多重化 Active JP6318453B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/583,337 US9923677B2 (en) 2014-12-26 2014-12-26 Multiplexing many client streams over a single connection
US14/583,337 2014-12-26

Publications (2)

Publication Number Publication Date
JP2016127597A JP2016127597A (ja) 2016-07-11
JP6318453B2 true JP6318453B2 (ja) 2018-05-09

Family

ID=56117053

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015228864A Active JP6318453B2 (ja) 2014-12-26 2015-11-24 単一接続上での多くのクライアントストリームの多重化

Country Status (4)

Country Link
US (1) US9923677B2 (ja)
JP (1) JP6318453B2 (ja)
CN (1) CN105743812B (ja)
DE (1) DE102015119893B4 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107666474B (zh) 2016-07-30 2021-04-20 华为技术有限公司 一种网络报文处理方法、装置及网络服务器
CN106302661B (zh) * 2016-08-02 2019-08-13 网宿科技股份有限公司 P2p数据加速方法、装置和系统
US10291750B1 (en) * 2016-12-13 2019-05-14 Juniper Networks, Inc. Aggregating data sessions between autonomous systems
WO2018188068A1 (en) * 2017-04-14 2018-10-18 Intel Corporation Server-and network-assisted dynamic adaptive streaming over hypertext transport protocol signaling
US10320694B2 (en) * 2017-05-04 2019-06-11 Nokia Of America Corporation Methods, apparatuses and computer-readable storage mediums for communication via user services platform
BR112019024070A2 (pt) * 2017-05-16 2020-06-02 Telefonaktiebolaget Lm Ericsson (Publ) Método de ingestão e de distribuição de mídia, aparelho empacotador de mídia, servidor de origem, nó de ponto terminal, e, rede de transmissão contínua em mídia
CN107911415A (zh) * 2017-10-20 2018-04-13 深圳市网心科技有限公司 Tcp流的多路复用系统及其方法、存储介质与终端
CN107872538B (zh) * 2017-12-07 2021-02-02 浙江大华技术股份有限公司 解耦tcp长连接的业务处理方法、反向代理和业务服务器
US10686910B2 (en) * 2018-02-02 2020-06-16 Servicenow, Inc. Distributed queueing in a remote network management architecture
US11617224B2 (en) * 2018-02-15 2023-03-28 Telefonaktiebolaget Lm Ericsson (Publ) Gateway, a frontend device, a method and a computer readable storage medium for providing cloud connectivity to a network of communicatively interconnected network nodes
US11249857B2 (en) 2018-10-19 2022-02-15 Netapp, Inc. Methods for managing clusters of a storage system using a cloud resident orchestrator and devices thereof
US10820057B2 (en) * 2018-11-07 2020-10-27 Nvidia Corp. Scalable light-weight protocols for wire-speed packet ordering
CN111262715B (zh) * 2018-11-30 2021-04-02 贵州白山云科技股份有限公司 一种虚拟内网加速方法、系统和计算机设备
US11108704B2 (en) 2018-12-04 2021-08-31 Nvidia Corp. Use of stashing buffers to improve the efficiency of crossbar switches
CN111367650B (zh) * 2018-12-26 2023-11-21 浙江大学 一种输入输出流的处理方法、装置及系统
TWI758680B (zh) * 2019-01-31 2022-03-21 日商日本電氣股份有限公司 資料中繼裝置、方法、發送系統及程式
CN110784444B (zh) * 2019-09-09 2021-10-15 航天行云科技有限公司 一种嵌套数据流处理的方法及相关设备
CN112929393A (zh) * 2019-12-05 2021-06-08 中兴通讯股份有限公司 一种建立http/2连接的方法、系统、装置和电子设备
CN113453378B (zh) * 2020-03-26 2023-06-16 成都鼎桥通信技术有限公司 一种s1应用协议链路的建立方法和装置
CN113973093B (zh) * 2020-07-24 2023-10-13 中移(苏州)软件技术有限公司 数据传输方法及装置、电子设备、可读存储介质
US11595502B2 (en) * 2020-10-15 2023-02-28 Pensando Systems Inc. Methods and systems for layer 7 hardware assist and CPU task offloads
CN112671933B (zh) * 2021-02-23 2022-04-26 浙江中控技术股份有限公司 一种数据处理方法及系统
CN113472875A (zh) * 2021-06-28 2021-10-01 深信服科技股份有限公司 一种连接复用方法、装置、电子设备及存储介质
US11770215B2 (en) 2022-02-17 2023-09-26 Nvidia Corp. Transceiver system with end-to-end reliability and ordering protocols
CN114884881B (zh) * 2022-05-12 2023-07-07 福建天晴在线互动科技有限公司 一种数据压缩传输方法及终端
CN115348332B (zh) * 2022-07-08 2023-08-29 宜通世纪科技股份有限公司 一种信令分析场景中http数据流会话的重组方法

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3707927B2 (ja) 1998-04-14 2005-10-19 富士通株式会社 サーバスループット予約システム
US7013338B1 (en) * 2000-07-28 2006-03-14 Prominence Networks, Inc. Multiplexing several individual application sessions over a pre-allocated reservation protocol session
US20020042839A1 (en) * 2000-10-10 2002-04-11 Christopher Peiffer HTTP multiplexor/demultiplexor
US7801978B1 (en) * 2000-10-18 2010-09-21 Citrix Systems, Inc. Apparatus, method and computer program product for efficiently pooling connections between clients and servers
JP2002185488A (ja) 2000-12-14 2002-06-28 Nippon Telegr & Teleph Corp <Ntt> 通信効率増幅装置
US7003572B1 (en) 2001-02-28 2006-02-21 Packeteer, Inc. System and method for efficiently forwarding client requests from a proxy server in a TCP/IP computing environment
US6934257B2 (en) * 2001-04-04 2005-08-23 Intel Corporation Transferring transmission control protocol packets
US8090866B1 (en) * 2002-01-18 2012-01-03 Cisco Technology, Inc. TCP proxy connection management in a gigabit environment
US7406087B1 (en) * 2002-11-08 2008-07-29 Juniper Networks, Inc. Systems and methods for accelerating TCP/IP data stream processing
US7936674B2 (en) * 2005-08-11 2011-05-03 Telekom Malaysia Berhad Distributed digital subscriber line access multiplexer
US20080304486A1 (en) * 2007-06-08 2008-12-11 Joshua Verweyst Graessley Multiplexed data stream protocol
WO2010100837A1 (ja) * 2009-03-06 2010-09-10 日本電気株式会社 通信レート制御方法、送信装置および通信システム
US8780858B2 (en) * 2010-01-05 2014-07-15 Qualcomm Incorporated Controlling transmission control protocol (TCP) transmissions in handover
WO2011143094A2 (en) * 2010-05-09 2011-11-17 Citrix Systems, Inc. Systems and methods for allocation of classes of service to network connections corresponding to virtual channels
US20120054316A1 (en) 2010-09-01 2012-03-01 Canon Kabushiki Kaisha Tcp multiplexing over a proxy
US8996657B2 (en) * 2010-09-01 2015-03-31 Canon Kabushiki Kaisha Systems and methods for multiplexing network channels
US8400923B2 (en) * 2010-10-15 2013-03-19 Telefonaktiebolaget L M Ericsson (Publ) Multipath transmission control protocol proxy
US20120151087A1 (en) * 2010-12-14 2012-06-14 Nuvel, Inc. System and method for providing a network proxy data tunnel
US9215131B2 (en) * 2012-06-29 2015-12-15 Cisco Technology, Inc. Methods for exchanging network management messages using UDP over HTTP protocol
CN103023987A (zh) 2012-11-27 2013-04-03 蓝盾信息安全技术股份有限公司 一种基于tcp连接的多路复用的方法
US9531846B2 (en) * 2013-01-23 2016-12-27 A10 Networks, Inc. Reducing buffer usage for TCP proxy session based on delayed acknowledgement
US20150256493A1 (en) * 2014-03-05 2015-09-10 David Wilson System and Method for Document Processing

Also Published As

Publication number Publication date
DE102015119893B4 (de) 2021-11-18
CN105743812A (zh) 2016-07-06
JP2016127597A (ja) 2016-07-11
CN105743812B (zh) 2019-08-27
US9923677B2 (en) 2018-03-20
DE102015119893A1 (de) 2016-06-30
US20160191672A1 (en) 2016-06-30

Similar Documents

Publication Publication Date Title
JP6318453B2 (ja) 単一接続上での多くのクライアントストリームの多重化
CN108476208B (zh) 多路径传输设计
US8396954B2 (en) Routing and service performance management in an application acceleration environment
US9438701B2 (en) Systems and methods for a SPDY to HTTP gateway
CN110022264B (zh) 控制网络拥塞的方法、接入设备和计算机可读存储介质
US7970951B2 (en) Method and system for media-based data transfer
TW201215037A (en) Switch system, switch control method, and non-transitory computer readable storage medium
US9998373B2 (en) Data routing acceleration
US10205660B2 (en) Apparatus and method for packet header compression
EP3225014A1 (en) Source ip address transparency systems and methods
JP2017010537A (ja) コンテンツセントリックネットワークにおける柔軟なコマンドおよび制御
JP2016521501A (ja) ブロードキャスティングシステムにおける動的キュー管理方法及び装置
CN110545230B (zh) 用于转发vxlan报文的方法和装置
WO2012121098A1 (ja) ネットワークシステム、パケット処理方法、及び記憶媒体
US10298494B2 (en) Reducing short-packet overhead in computer clusters
US9847929B2 (en) Cluster and forwarding method
EP3275139B1 (en) Technologies for network packet pacing during segmentation operations
US9531629B2 (en) Fibre channel over Ethernet switch system
US20050195851A1 (en) System, apparatus and method of aggregating TCP-offloaded adapters
JP2017147601A (ja) 通信装置および通信方法
US10148576B2 (en) Network processing unit (NPU) integrated layer 2 network device for layer 3 offloading
US10897488B1 (en) Multiplexing traffic from multiple network namespaces to a single listener in a stream-based server application
WO2016079626A1 (en) Reducing short-packet overhead in computer clusters

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161026

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161115

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170620

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170920

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180306

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180316

R150 Certificate of patent or registration of utility model

Ref document number: 6318453

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250