ネットワークがクイズでわかる！ 誰が正解？「TCP/IP」 第4回

TCPの信頼性を担保する仕組みで正しいのは誰だ！

データ受信時の「ACK番号」はどう増える？

「クイズでわかる誰が正解？」の時間がやってきました。このクイズでは、ケンイチ君、いずみちゃん、竹田君の3人が私の質問に答えます。ただし、正解なのは1人だけですよ。クイズのテーマは「TCP/IP」、ネットワークの基本です。さてさて、誰が正解か当てられますか？

---

誰が正解？（間違いが2人いますので要注意！）

確認応答番号（ACK番号）の意味

　TCPでは、アプリケーションから受け取ったデータを細切れにして、相手に送信している。そのため、細切れにしたデータの順序を正しく管理する仕組みが必要になる。それが、シーケンス番号とACK番号である。シーケンス番号は、スリーウェイハンドシェイクで決めた初期シーケンス番号を基点にしたバイト数を表わしている。

　一方受信側が応答するACK番号は、スリーウェイハンドシェイクでは「シーケンス番号＋1」となっていた。しかし、コネクションが確立して実際にデータを送受信する段階では、「送信側のシーケンス番号＋受信データバイト数」をACK番号として応答する。送信側では、このACK番号を見ることで相手がどこまで正しくデータを受信できたかがわかるわけだ（図1）。

図1●シーケンス番号（SQ）と確認応答番号（ACK#）によるデータ受信の確認

　しかし、セグメントを1つ送信してはACKセグメントの受信を待つという通信手順では、信頼性の高い通信は実現できるものの、効率的ではない。そこでTCPでは、ACKを待たず、連続してセグメントを送信できるようになっている。連続してセグメントを送信する場合は、受信側があとからまとめて1つだけACKセグメントを応答することで、どこまで受信できたかを通知するのだ。

　ここで1つ考慮しなければならないことがある。何らかの理由で途中のセグメントが欠落した場合である。

　受信側が返すACK番号を、単純に受信したセグメントのシーケンス番号に、受信したデータのバイト数を加えただけでは、途中で欠落したセグメントがあることを送信側に伝えることができない。そこで、万が一セグメントが欠落して連続性が途絶えた場合、ACK番号は「最初のシーケンス番号＋連続して正常に受信できたバイト数」として応答する。ここで仮に次のセグメントを受信しても、ACKセグメントに設定されるACK番号は更新されない（図2）。欠落したセグメントが再送されて正常に受信されるまで、同じACK番号を返し続ける。

図2●セグメントが届かない場合の挙動

　この仕組みにより、送信側は同じACK番号を続けて受信した場合、欠落したセグメントがあることを知るとともに、どこが欠落したか（どこまで連続して受信できているかまで）をACK番号によって知ることができるのである。

　つまり、ケンイチくんも竹田君も、シーケンス番号に受信データのバイト数を加算していない点が誤り。正解は、データのバイト数を加算するといういずみちゃんの答えである。

通信効率を高めるスライディングウィンドウ

　また、データ転送を効率よく実現するために、TCPでは「スライディングウィンドウ」というフロー制御の仕組みが使われている（図3）。ここでいうウィンドウとは、受信したデータを一時的に溜めておくためのバッファ領域のことである。容量はセグメントサイズの整数倍以上が用意されるため、上位アプリケーションにデータが渡されるまでの間、受信したセグメントをいくつも溜めておくことができる。

図3●スライディングウィンドウ

　受信バッファの受信可能領域は、セグメントを受信するたびに減少していくが、受信したデータを上位のアプリケーションに渡せば受信可能領域が増え、次のTCPセグメントを受信できるようになる。スライディングウィンドウの名前は、この増減の様子が受信可能領域を表わすウィンドウをスライドさせているように見えることから来ている。ウィンドウサイズは、受信側が送信側へ返すACKセグメントのウィンドウサイズフィールドに設定して通知する。

　本記事は、ネットワークマガジン2007年8月号の特集1『クイズでわかる 誰が正解？「TCP/IP」』を再編集したものです。内容は原則として掲載当時のものであり、現在とは異なる場合もあります。