なぜTCPは正しくデータを送ることができるのか - 30代専業主婦の独学エンジニア挑戦ブログ

現在、ネットワークの勉強をしています。
今回はトランスポート層のTCP プロトコルがなぜ正しくデータを送ることができるのかについてまとめました。

勉強のために読んでるのはこちらの技術書です！
ネットワークに関しては難しそうだな・・・というイメージでしたが、こちらはイラスト図解で全ページカラーなので、すごく読みやすいです！
初心者の私でもイラストをみて、ネットワークの仕組みを理解できるようになりました。

前回はTCPのおおまかな仕事の流れや、３ウェイ・ハンドシェイクについて書きました。
programming-kanamama.hatenablog.com

前回の記事で、TCPヘッダーにシーケンス番号（送信済みバイト数を表す）と確認応答番号（受信済みのバイト数を表す）という情報などが含まれていることを説明しました。

データ転送中は送ったデータのバイト数をシーケンス番号に加算します。
受け取ったデータのバイト数は確認応答番号に加算されるので、この２つの番号を帳簿のように控えておいて正しくデータをやりとり出来ているのかチェックしています。

インターネット上の通信では、一部のパケットが届かなかったり、届いているのに確認応答のパケットが届かなかったりすることがある。

パケットを送ったのに一定時間待っても確認応答が返ってこない場合、送れなかったと判断して同じデータを再送します。

このように、TCPではデータのやり取りが正しくできているかチェックを行い、データの送信を失敗したと判断したときにはデータの再送を行うことで、確実にデータを届けることができています。

いくら確実にデータを送るためとは言っても、確認応答を待ってから次のデータを送るという方法では、通信が完了するのに時間がかかってしまいます。

そのため、TCPは確認応答を待たずにまとめてデータを送ることで通信を高速化することができます。

まとめて送る量が多すぎてしまうと、受信する側が処理しきれなくなってしまうことがあります。

サーバーとクライアントでそれぞれデータを一時的に溜めておくことができる、バッファという記憶領域をもっています。
TCPヘッダーの「ウィンドウサイズ」にバッファの空き容量を入れておくことで、お互いにあとどれくらいまでまとめて受信できるのかを伝え合うことができます。

受信した側は届いたパケットをバッファに溜めつつ、バッファからデータを取り出して処理をしていきます。
受信側は確認応答にウィンドウサイズをセットして、どのくらい受信可能かを送信側に伝えています。
このしくみをフロー制御（流量制御）といいます。

バッファがいっぱいになってしまったら、ウィンドウサイズ０の確認応答が送られ、データの送信はいったんストップするようになっています。

送信再開のタイミングは、送信側がウィンドウロープと呼ばれるパケットを送り、その確認応答でウィンドウサイズを調べています。

バッファに空きがあったとしても、ネットワークの経路の途中が混雑していて通信速度を落とさなければならないときもあります。

その場合、インターネット層のヘッダー内の混雑フラグがオンになるので、ECEフラグ（通信経路が混雑して受信できなくなる恐れがあることを伝える）とCWRフラグ（通信経路が混雑したので、送信量を減らしたことを伝える）で通信相手とやりとりをして、通信速度を落とします。

※混雑フラグはインターネット層がつけるIPヘッダー内にあります。