こんにちは、こじろうです。
みなさん
別記事でインターネット上の情報のやり取りは7つのステップに分かれていて、4層目:トランスポート層ではデータのやり取り時に、送受信が成功したかどうかのチェックや、失敗した時の再送等の制御を実施していることを紹介しました。
参考:
この記事では、文系SEの方々やITビギナーの方々向けに具体的にどのような流れでこの制御(フロー制御)がなされているか紹介していきたいと思います。
【この記事でわかること】
- TCP/UDPのフロー制御とは何か?
- 具体的にはどんな仕組みなの?
- フロー制御の知識ってどこで役立つの?
ミスできない通信はTCP、順序重視ならUDPで制御する。
データ(データフロー)の制御方法(プロトコル)にはTCPとUDPがある
TCPは送信するデータが、一つ一つ確実に相手に届いたか確認する方法です。到着確認をする一方で、到着の順序についてはケアしないため、時に到達の順序が送信した順番と入れ違うことがあります。
一方、UDPは上記のような確認はせず、送信された順にデータが送付・到達するのですが、ちゃんとデータが相手に届いたか確認しないので、時々データの一部が欠損し相手に届かないということがあります。
TCP:送受信が成功したかどうかのチェックや、失敗した時の再送etcの制御を実施
上記で”ミスできない通信はTCP”と記載した理由は、TCPは送受信する内容を逐一”本当にこの内容で合っているか?”チェックするのに対し、UDPは”漏れとかあるかもしれないけど、とにかく受け取った順に早く送ってしまおう”というルールの元に送受信が行われるためです。
TCP/UDPのメリット&デメリット
どちらが良いということはなく、通信特性によりTCPまたはUDPを使い分けるべき
一見、色々確認した上で通信してくれるTCPの方がよさそうに感じるのですが、例えば電話通信などはUDPでないと会話が成り立たない可能性があります。
ちょっと想像してみてほしいのですが、電話中に30個くらいの単語を電話口で喋った時、最初に発した単語が、相手に伝わる時、一番最後に聞こえてきたら会話は成り立たないですよね?
確かにデータの欠損は無い方が良いのですが、電話でのやりとりって、多少言葉が飛んでも、前後のやり取りから想像できるじゃないですか?
こういったデータの到達順序が重要視される場面では、TCPよりもむしろUDPが利用されるのです。
具体的な制御の方法
TCP/UDP – ウインドウサイズを利用したフロー制御
TCP では3 つの技術を採用しています。
これにより、データ通信の信頼性(間違いのないデータ内容の担保)の向上を実現しています。
- 相手が通信可能かどうかを確認する機能(仮想コネクションの確立)
- 相手にパケットが届いたかどうかを確認する機能(ACKによる到達確認)
- 相手の処理能力に合わせてデータサイズを調整する機能(ウインドウサイズを使ったフロー制御)
仮想コネクションを確立は、3ウェイハンドシェイクという方法で実現しています。
参考:※設定中
ACKによる到達確認は、上記の仮想コネクションの中で、データ送信中に平行して “ACK”という パケットを使用し、到達確認を実施しています。
参考:※設定中
上記の二つだけでもかなりの信頼性向上が実現できているのですが、TCP ではさらにもう 1 つ、データ送信を制御する機能を持っているのです。
それは、送信するデータ量(データフロー)の制御です。
以下のように、送信データが大量のデータを送信したとしても、受信側のデータ処理能力が低いと、データ受信処理に時間が掛かってしまい、いつまで経ってもデータが受信できない、という事象が発生しかねません。
そこでTCPは、コネクション確立後のACKやり取り時に、受信側から送信側へ処理能力を伝達し、送信側は”相手は一度にどの程度のデータなら処理できそうか?”確認、その範囲内の量にデータを分けて送信するのです。
(受信側がどのようにウインドウサイズを通知するかといいますと、データを受信するたびに返信する ACK パケットにウインドウサイズを盛り込んで通知しているのです。)
この受信側が処理できるデータの量・範囲のことを、ウインドウサイズと言い、この一連の流れを「データのフロー制御」機能と呼びます。
もし、受信側で処理できないような大量データが来た、もしくはなんらかの理由で受信側がデータを処理できなくなった場合は、ウインドウサイズを「0」にして送信側へACK パケットを送信、送信側はデータの送信を中断します。
受信側でデータ受信が出来る状態になると、改めて ACK パケットを送信することで、データ送信が再開されます。
UDPのフロー制御
TCPのような重厚なチェックはしない
通常のデータフロー(基本フロー)は、単純に送信側から受信側へデータを送信するだけです。
- OSは、宛先ポート番号が対応するアプリケーション※が自ホストで動いているか調べる
- アプリケーションが動いている場合、OSはUDPパケットのペイロード部分を取り出し、これをアプリケーションへ渡す
- アプリケーションはペイロードの内容を処理する
※ポート番号とアプリケーションに関する説明はこちらの記事を参照ください。
もし、①で該当アプリケーションが起動していない場合は、以下の処理(代替フロー)が実行されます。
- OSは宛先ポート番号に対応するアプリケーションが自ホストで動いているか調べる
- アプリケーションが動いていない場合、OSはICMPのDestination Unreachableメッセージ(Port Unreachableコード)を送信元ホストへ返信する
順序も、内容の正確も、両方担保できる方式はないのか?
「わざわざ2つを使い分ける意味が分からん」という方もいらっしゃるかもしれません。
しかし、残念ながら、今現在TCPとUDPの良いとこ取りできる技術は無いのです。
クラウド全盛の時代に、こういった知識は不要となってしまった?
正直、ITの内容というよりは電気機器メーカーの方が勉強する内容かも。
そのため、その辺の知識を積極的に学ぶ人は少ないでしょう。
それだけに、周りに差をつけるにはうってつけの分野ですし、トラブルが起きた時の原因究明で非常に役に立つ知識です。
僕もよく経験した話なのですが、システムが出来上がり、いざお客さんの業務現場に赴き、対象のサーバへソフトウェアインストール、したけど動かない。。データが連携されないetc…なぜだ!?
「できたって言ってたじゃないか!納期遅れは許さんからな!」みたいに恫喝されて10分後くらいに、契約外のネットワーク設定が間違っていた…ってなことがしばしばあります。
強烈な営業向きスキルではありませんが、いざというとき自分の身を助けてくれる頼りになる知識です。
フロー制御を理解できた僕の現在
ITコンサルタントとしての現場において、プロジェクト内でトラブルシューティングやシステムインフラ設計において最も頼られる存在になり、安定した案件・プロジェクトアサインが実現できるようになりました。
参考:コンサルファームでアベイラブルになったら
文系SEであっても、こういった知識があると一目置かれた存在になれますし、キャリアアップの一助になります。
実際、僕はプログラマ➡SE(ネットワークエンジニア)➡ITコンサルタントとキャリアップしてきましたが、ITコンサルタントとして活動している今も本記事の様な技術的な部分を大事にしているため、’他のコンサルタントとは差別化された人材になれているな’と感じています。
本記事は技術的な内容でしたが、キャリアに関する情報をお探しの方はこちらも是非、ご覧ください。
参考:【文系 SE】ネットワークエンジニアのすすめ
それでは、Tchau◎
こじろう
※冒頭の写真はumacoさんによる写真ACからの写真でした。