いくら100Mbpsでイーサーネット接続できていたとしても、途中経路に低速な回線や処理能力の低いルータがあれば、100Mbpsで通信することはできず、輻輳（ふくそう：通信上限に達する）が発生する。
これを防ぐために、徐々に通信量を増やして最適になるように調整するアルゴリズムがスロースタートアルゴリズムである。
(訂正のお知らせ)
kausさんのご指摘により、掲載内容が誤っていたことが判明したため以下の内容を削除しました。
”なぜpingの最初の応答が遅いのかずっと不思議でならなかったが、TCP/IPではフロー制御としてスロースタートアルゴリズムを使用しているため、この原因を説明できる。”
Pingの初めの応答が遅いのと、スロースタートは全く関係しませんよ。
①まずPingはTCPではないので、このアルゴリズムは働きません。
②Pingの初めの応答が遅いのは、Arp処理を行っている為です。
「初め」の場合によりますが..
コメントいただきましてありがとうございます。たしかにpingはICMPですから、TCPのフロー制御は当てはまりませんね。修正しておきます。
何かお気づきの点がありましたらぜひご指摘をお願いします。
もうひとつだけ..
>徐々に通信量を増やして最適にな>るように調整するアルゴリズムが>スロースタートアルゴリズムであ>る。この通信量のことをウィンド>ウサイズという。
TCPのパケット内のWindowSizeはあくまで、現在空いているWindowSize（正確にはカーネルの受信バッファサイズ）であり、スロースタートの送信量とは関係しません。スロースタートの送信量は、cwndで管理され（パケットにはのらない値。送信側だけで制御する値なので..),最後に受け取ったAckパケットに書かれている、WindowSize内で本値は変動します。受信側はTCPパケットを受け取ったら、Ackを必ず２フレーム以内に返す決まりがあるので、通常の問題ないネットワークだと、送信側は、ほぼ2フレームちょっとでAckを受け取ることになりcwnd値はどんどんWindowSize内で増えていきます。
整理すると、WindowSizeは仮に、Ackが返ってこなくても、送信側が連続して送信できるサイズで、さらに、スロースタートアルゴリズムで、現在のack応答頻度をみて、仮にackが返ってこなくても、連続して送信できる量を制御します。
※スロースタートに関するあくまで自分の認識です。
Window Sizeに関するコメントをいただきましてありがとうございます。僕はまだまだ不勉強な点がありますので、良く勉強した上で、加筆、修正を行っていきたいと思います。