インターネットでの信頼性の高いデータ伝送は、TCP（
伝送制御プロトコル ）
プロトコルに基づいています。この
プロトコルの仕様は、ほぼ30年前に公開されました。 TCPアルゴリズム（
RFC793 ）により、接続されたデバイスは、数十メガビット/秒以内の速度および最大100秒の遅延でネットワーク上で動作するように適応できます。 新しいデータ転送技術の急速な発展により、
導入後10年でプロトコルのパフォーマンスがより広いチャネルに十分ではないことが明らかになりました。
1）TCPの制限
データ転送速度は、ネットワークとシステムの特性に依存します。
img1ネットワークを介してデータを送信するプロセスa）バッファー元のTCP構成は、バッファーの送信速度を制限し（ウィンドウサイズオプション-「ウィンドウサイズ」）、サイズが2 ^ 16バイト（最大64 KB）のフィールドです。 この場合の最大スループット：
例：インターネットへの100メガビット接続と、サーバーへの100ミリ秒の遅延があります。
標準のTCPスタックでは、最大データ転送速度は10 Mbpsを超えません
（524288ビット/ 0.1秒= 5.24 Mb / s 100メガビットのリンクがあるという事実にもかかわらず）。
b）帯域幅遅延積（BDP）原則として、TCPのパフォーマンスはチャネル速度にそれほど依存せず、いわゆる「帯域幅*遅延積」またはBDP（スループット*遅延の結果）に依存します。これは、TCP接続を最大化するために送信者と受信者に必要なバイト数です。
いわゆる「ロングファットネットワーク」（LFN）の場合、パフォーマンスの問題が発生します。これは、この場合のBDPがTCPウィンドウのサイズを超え、それにより伝送速度が制限されるためです。
img2最大TCPスループットに対する遅延の影響例は、モバイルインターネットまたは高速光リンクです。
BDPの計算例：
a）モバイルブロードバンド：10 Mb / s、100 ms RTT
B×D = 10^7 b/s × 10^-1 s = 10^6 b, or 1 Mb / 125 kBb）高速地上ネットワーク：1 Gb / s、10 ms RTT
B×D = 10^9 b/s × 10^-2 s = 10^7 b, or 10 Mb / 1.25 MBここで BDPを計算でき
ます 。
最大チャネル負荷を達成するには、TCPの「ウィンドウサイズ」がBDPを超える必要があります。
c）プロトコルのオーバーヘッド一部の推定によると、世界のコンピューターの約95％がイーサネットテクノロジーを介して接続されています。
イーサネットMTU（イーサネットフレームペイロード）=最大 1500バイト。
Ethernet、IP、TCPのすべてのヘッダーを考慮すると、図は次のようになります。
img3 1つのイーサネットフレームの送信数字は、特定のプロトコルのヘッダーのサイズ（バイト単位）を示します。
IFG（フレーム間ギャップ）-必要なフレーム間スペース。
ヘッダー：プリアンブル、フレーム区切り、イーサネットヘッダー/ FCS-26バイト、IFG-12バイト、IPヘッダー-20バイト、TCPヘッダー-20バイト。
VLANタギング、TCPタイムスタンプ、およびその他のオプション機能を除外すると、イーサネットネットワーク上のTCPの最大ペイロードは次のようになります。
最大TCPペイロード =（MTU – TCP – IP）/（MTU +イーサネット+ IFG）=（1500–40）/（1500 + 26 + 12）=
94.9％d）遅延とパケット損失信頼性の高い情報送信であるため、ネットワーク上のパケット損失により、TCPは強制的にセグメントを再送信し、速度の低下に直接影響します。
パケット損失に対するTCP速度の依存性は、Mathisの式によって決定されます。
ここで、MSS（最大セグメントサイズ）-最大TCPセグメントサイズ（MSS = MTU-パケットヘッダー= 1460バイト）、
MTU-下位レベルOSIの送信ブロックの最大サイズ（イーサネットMTU = 1500バイト）、
RTT-双方向遅延の時間（一方の端からもう一方の端まで、および英語の往復時間から）
Ploss-損失の確率。
Ploss = 0の場合、式は無効であることに注意してください。現実には常にパケット損失があるため、これは正常です。
img4最大TCPスループットに対する遅延とパケット損失の影響ほとんどのプロバイダーは、0.01％未満（1万パケットのうち1パケット）の損失を保証しません。
「netstat -s」コマンドを使用して、プロトコルの統計を確認できます。
2）TCP最適化
a）プロトコルの強化この点で、制限を解決するために設計された、
高性能TCP拡張 （
RFC1323 ）
標準で説明されているプロトコル拡張が開発されました。
それらの中には：
-TCP
ウィンドウスケールオプション：ウィンドウサイズを2 ^ 30（1 GB）に増やす機能、
-TCP選択的肯定応答（
SACK ）オプション：受信側は、ストリーム内のどのパケットが肯定応答（肯定または否定）されるかを示します（
RFC2018 ）、
-TCP
タイムスタンプ ：RTT測定の改善（ラウンドトリップ時間測定-RTTM）、シーケンス番号の重複防止ACK（ラップされたシーケンス番号の防止-PAWS）、
-
パスMTUディスカバリー ：最大MTUをすべて決定し、
-明示的な輻輳通知（
ECN ）：パケットをドロップせずにパスの輻輳を示します（
RFC3168 ）。
ここで現在のコンピューターのTCP / IP設定を確認してください。
b）オペレーティングシステムの適応RFC1323文書は1992年に公開されたという事実にもかかわらず、変更はOSにすぐには導入されませんでした。
OS WindowsRFC1323のサポートはWindows 2000（XP、Server 2003）以降に登場し、オプションを有効にするにはレジストリを変更する必要があります。
Windows Server 2008、Vista、7システムには、次世代TCP / IPスタックと呼ばれるTCP / IPプロトコルスタックの新しい実装が含まれています。 これは、今後数年間、Windowsネットワークテクノロジーを提供するように設計されています。 革新の中で：
-受信ウィンドウの自動調整（受信ウィンドウの自動調整）、
-複合TCP：他のプラットフォームで使用されているアルゴリズムの代わりに新しいアルゴリズムを使用して、高帯域幅のネットワークでの低パフォーマンスの問題を解決
-高損失環境などの機能強化。
多くのオプションはデフォルトで有効になっています。 コマンドラインを介した設定。
さまざまなオペレーティングシステム （Windows XP、FreeBSD、Linux、Solaris、Mac OS X）の詳細な構成手順
は、ピッツバーグスーパーコンピューターセンターのWebサイトで見つけることができます。
注：ほとんどのトラフィックはルーター（異なるネットワーク間）を通過しますが、TCPはOSIネットワークモデルの下位レベルで機能し、最適なルートを決定し、パケットを配信する機能のみを実行するため、最適化に間接的にのみ関連します（場合によって）目的地。
3）TCP / IPスタックのパフォーマンス測定
ネットワーク上のインターネット接続の速度を測定するには、多くの方法があります。
ここでは、
nuttcpユーティリティ（「New TTCP」）を使用する場合を検討します。これにはいくつかの優れた利点があります。
-TCPまたはUDP経由のチャネルスループットを測定するためのシンプルで効果的な方法、
-クロスプラットフォームの単一ファイルプログラム（CLI）、
-ローカルTCP / IPスタック（ループバック）の有効性を検証する機能、
-安定したサーバー操作（TCPセッションの正しい完了）、フリーズやクラッシュなし
（iperfの場合と同様）、
-NATからのクライアントの仕事。
ちょっとした歴史：1980年、Mike Muuss（pingの作成者）は、最初のTCP帯域幅テストツールの1つであるttcp（「Test TCP」）を作成しました。 その後、さまざまな実装で新しい機能を使用して多くの変更が作成されました。
Nuttcpもその1つです。 最新のベータ版は2010年4月です。
テストは、クライアント/サーバースキームに従って機能します。
ペイロードが測定されます-ペイロード（ヘッダーなし）。
ポート5000での接続。データ転送-5001（およびマルチスレッドテストを指定する場合はそれ以上）。
サーバー-
#nuttcp -Sを指定するだけ
クライアント-
多くのオプションを指定できます。
例：
FreeBSDサーバー、Windows XP SP3クライアント、FastEthernet（100Mbps）。
server-ip＃nuttcp –Sクライアントオプション：
-w128-TCP受信ウィンドウサイズ= 128 KB
-r-受信（受信、クライアント用）
-F-NATを使用している場合に発生する可能性のある接続の問題を修正
-i5-5秒ごとに結果を表示します
-T15-テスト時間（15秒）。
TX％とRX％は、送信機と受信機のプロセッサ負荷です。
ハードウェアとTCP / IP OSスタックのパフォーマンスの確認：
C：\> nuttcp.exe -w1m 127.0.0.1205.0625 MB / 10.00秒= 172.0189 Mbps 19％TX 12％RX
結果の例：
-Intel Core 2 Duo（2コア）@ 1.6 GHz / 1 GB RAM / Windows XP = 1300/1400 Mbps
-AMD Athlon X2 Dual-Core 4600 @ 2.4 GHz / 2 GB RAM / Windows 7 = 2000/2100 Mbps
-Intel XEON X5650（24コア）@ 2.67GHz / 8 GB RAM / FreeBSD = 16600/18000 Mbps
ダウンロードの確認（サーバーからクライアントへ） ：
C：\> nuttcp.exe -w128 -r -F –i5 -T15 server-ip56.0166 MB / 5.00秒= 93.9803 Mbps
56.0575 MB / 5.00秒= 94.0489 Mbps
56.0338 MB / 5.00秒= 94.0090 Mbps
168.2676 MB / 15.00秒= 94.1020 Mbps 3％TX 10％RX
some-unix-client＃nuttcp -r -F -i5 -T15 server-ip429.0000 MB / 5.02秒= 717.3541 Mbps
526.0000 MB / 5.00秒= 882.0518 Mbps
1371.1741 MB / 15.00秒= 766.6703 Mbps 26％TX 39％RX 3153 host-retrans 0.29 msRTT
アップロードの確認（クライアントからサーバーへ） ：
C：\> nuttcp.exe -w128 –i5 -T15 server-ip55.6250 MB / 5.00秒= 93.3169 Mbps
55.8125 MB / 5.00秒= 93.6562 Mbps
55.6875 MB / 5.00秒= 93.4277 Mbps
167.2500 MB / 15.12秒= 92.7664 Mbps 17％TX 6％RX
some-unix-client＃nuttcp -i5 -T15 server-ip422.9375 MB / 5.00秒= 709.5294 Mbps
420.6875 MB / 5.00秒= 705.9357 Mbps
456.3750 MB / 5.00秒= 765.6674 Mbps
1305.3853 MB / 15.06秒= 727.0077 Mbps 20％TX 48％RX 24478 host-retrans 0.29 msRTT
4）結論の代わりに
テスト中、
個々のTCP接続の最大速度はさまざまな要因によって決定されることに注意する必要があります。
-トラックの最も遅いストレッチの最大スループット、
-リクエストを送信してからレスポンスを受信するまでの時間（RTT）
-遠距離での遅延のほとんどは、ファイバ内の光の速度（〜200 km / ms）が原因です。
-ネットワークまたはデバイスの過負荷時に追加の遅延が発生する場合があります（サーバー、ルーター、PC）、
-パケット損失が検出された場合の自動スローダウン（標準TCP輻輳回避メカニズム）、
-他の悪影響がない（物理レベルでのビットエラーの最小数（ビットエラー率<10 ^ -8）、
-ネットワークカードの正常性とドライバーの正しい操作）、
-1つの物理リンクで多数の同時TCP接続を伝送できます。
-1つのホストは、同じリモートホストであっても、複数の同時接続を行うことができます（
TCPViewまたは
TCPEyeですばやく確認できます）。
人気のあるスピードテストは通常、多くのブラウザで動作し、フラッシュ+最寄りの利用可能なサーバーへのジオロケーションにより、次のものが作成されます。
-ローカルマシン（CPU、メモリ）およびネットワーク（WWWヘッダーなど）の追加負荷、
-サーバーの選択が最適でない場合があります。
-誤った結果の可能性。
最後に、ネットワークパフォーマンスが低い場合に頻繁に発生する問題に注目します。
-狭いTCPウィンドウ（ウィンドウサイズ）、
-イーサネットデュプレックスの不一致、
-ネットワークケーブルが不良です。
関連リンク：
technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspxfasterdata.es.net/fasterdata/host-tuning