pingのようなネットワークツールによって、ラウンドトリップタイムと呼ばれる パケットの3ウェイハンドシェイクの周回遅延を測定することが可能である。
ラウンドトリップタイム（Round-Trip Time; RTT） wikipedia
ラウンドトリップタイムのみが遅延を測定する方法ではないが、
最も一般的に容易に測定できるのがこの方法である。
DSLでは遅延は100ms以内がほとんどであるが、できれば25msが望ましい。
↑光ファイバーでは8ms以内？
etc------------------------------------------------
NTTなどでは法人向けに遅延時間を保証しているサービスもある
SLA＝サービスレベルアグリーメント契約
Intra-Japan（日本国内） 25ms 等
日米間では100ms～200ms
日欧間では300～500msかかります。
画期的な技術革新がない限り、当面の間あまりこの遅延は改善しなさそうである。
インターネットは世界を区別しないが
「アメリカの新鮮な野菜」と同じで、アメリカ人に最適なのはアメリカのサービスなのは
遅延時間が大陸横断でどうしても必要だからである。
コンピューターが発達してもここ10年以上、まったくこの遅延は改善していない
とっくに光ファイバーである
etc------------------------------------------------
ある程度正しいが、パケット上限は[rwin]によってもう少し大きい
＞IPv4のパケットの全長の最大は65535bytesであり、
＞これを超えることは原理的に不可能だ(キリッ)
＞100キロバイトのパケットなんか存在しないもん
とこのページではいっているが
↑65kbのパケットを「束ねる」ことができるので、＞＞【実際はもう少し大きい】
遅延には「距離遅延」と「パケットロス」があるため、
パケットサイズを65kBより設定すれば大きくできるものの、
[RWIN 120kB～1MB]いろいろ設定できるが、
1瞬でもパケットロスが発生すると、「束ねた積み荷が異次元に消え去る」し、
パケットロスは遠距離伝送なら必ずあるので、
最適な積み荷のサイズとパケットサイズの上限は自ずと決まってくる
↑これが実際のパケット上限
まとめると
①どんだけのサイズのパケットでも送れるが＝65キロバイト制限などあるようでない。
②そのでかいパケットが相手に正常に辿り着くかどうかは別問題である。
TCPはパケット内部のエラー訂正機能などないので
安全に到達可能なパケットサイズを探すしかない。
ネットワーク遅延増加→パケロス増加→(安全に送れる)パケットサイズが減少→
単位時間の伝送データ量の低下→速度低下
よってチューニングは
「安全に送れるパケットサイズ」を
適正な上限値に設定することが重要になってくる
Storage-Service-TOP
