Web教材一覧ネットワークTCP/IP(目次)

TCP/UDP(トランスポート層)

キーワード

TCP、TCPヘッダ、ポート番号、コネクション、セッション、ハンドシェイク、ネゴシエーション、ACK、誤り検出、順序制御、送達確認、フロー制御(流量制御)、ウィンドウ制御、ウィンドウサイズ、輻輳制御、UDP、コネクションレス、、ストリーミング、RTP


TCP(Trasmission Control Protocol)

TCPの位置づけ

TCP/IP体系では、IP層→TCP層→アプリケーション層の位置にあります。
 下位プロトコルのIP層(ネットワーク層)でパソコンとサーバの間など二つのホスト間での接続経路が見つかりました。TCPでは、そのホスト間の論理的な回線(コネクション)の接続や切断、伝送パケットのチェックなどをします、  また、TCPは上位プロトコルであるアプリケーション層との橋渡しをします。Webページ閲覧のHTTPや電子メール送信のSMTPなど多くのアプリケーションがありますが、それをポート番号で指定します。

OSI基本参照モデルとの関係では、TCPは大雑把にはトランスポート層に対応しますが、セッション層の一部も取り込んでいます。また、トランスポート層はUDPも含んでいますが、TCPでは関連するが別のプロトコルにしています。

TCPヘッダ

TCPヘッダは,次のようになっています。

TCPヘッダ

ポート番号

ポート番号はTCPから上位のプロトコルを示す番号です。IPヘッダで送信先(と送信元)のIPアドレスが確定しています。比喩的にいえば、IPアドレスは建物、ポート番号はWebページ提供部やメール受付部など業務担当部門の部屋番号に相当します。IPアドレスで相手の建物に行き、ポート番号で担当部門の部屋に入ってサービスを依頼することになります。

ポート番号により,HTTPやPOP3などのアプリケーションが起動します。その標準的なもの(会社により担当部門名が違うと面倒なので標準的な名称にする)はウェルノウン(well-known)ポート番号といい、0~1023が設定されています。その主なものを掲げます。
    ポート番号 プロトコル  サービス内容
      80  http   Webページ閲覧
     443  https  同上(セキュリティ)
      25  smtp   電子メール(送信・転送)
     110  pop3   同上(受信)
     143  imap   同上(IMAP)
      20  ftp    ファイルの転送(データ)
      21  ftp    同上(制御)
      23  telnet 遠隔ログイン
      53  DNS    名前解決(UDPでも使える)

 パソコンからWebページを閲覧するとき、送信先(Webサーバ)のポート番号は80になります。送信元(パソコン)のポート番号は、特にアプリケーションに関係せず、単に他の通信と混同しなければよいだけなので、0~1023以外の番号が適当に自動的に割り当てられます。

ftpやhttpなどの詳細は,別章「インターネットのアプリケーション」で取扱います。


コネクションの確立と解放

TCPの基本機能はコネクションの確立と解放です。

コネクションとセッション

本節では、「コネクション」という用語が重要です。それに関係して「セッション」という用語も出てきます。混同されやすいので、ここで説明しておきます。

コネクションは、トランスポート層の機能で、データ転送をする論理的な回線の接続や切断をします。
 セッションは、セッション層の機能です。対象となるアプリケーションのデータ転送を可能な状態にします。
 コネクションはセッションによって管理されます。

セッション確立 → コネクション確立の順で行います。
 まず、セッションでホスト間でのアプリケーションに関する確認(セッションの確立)を行い、セッションが確立したら、コネクションでデータ伝送の確認(コネクションの確立)をして、データ伝送とエラー制御などをします。

SSLでの暗号通信を例にします。
 実際のデータ転送に先だって、WebブラウザとWebサーバの間で、暗号の仕様がSSLであることを確認します。この確認がセッションの確立です。セッションが確立したら、暗号化したデータをSSLで転送しますが、この転送で利用する論理的な回線がコネクションです。もし、セッションなし暗号通信をすると、コネクションのたびに暗号の仕様について端末間で確認し合うことになので、最初にセッションを行うのです。

一つのセッションに一つのコネクションしかないこともあるが、一つのセッションに複数のコネクションが存在する場合もあります。

買物サイトへのアクセスを例にします。
 ログインした後、商品決定から決済手続までいくつもの画面推移をしてログアウトします。広義には、この一連の行動をセッションといいます。
 狭義には、商品決定や決済手続などの一つの画面を単位にしたものです。HTTP自体はセッションという概念をもっていません。商品決定画面から決済手続手続画面に移るには内部でHTTPでリンクしていますが、このときいったんHTTPの接続は切れてしまう(セッションが切れてしまう)のです。それで、商品決定画面にアクセスしたときのユーザIDやパスワードは失われてしまうのです。
 これでは困るので、Webサーバでは、ログインしてきたときに、ユーザを識別するセッションIDを生成し、リンクにセッションIDを付けて他画面へ推移します。これにより、サーバは広義のセッションとして取り扱うことができるのです。
 コネクションは、セッションIDを意識していないので、狭義のセッションごと(各画面ごと)にコネクションの確立が必要になります。

コネクション型通信

コネクション型通信

TCPは,コネクション型通信を行います。コネクション型とは,ホスト間で相互の状況を確認してからデータを送り,データの到着を確認してから次のデータを送るようにして,通信を確実に行う方法です(IP単独での通信,また後述のUDPはコネクションレス型であり,このような通信の保証はありません)。

コネクションの確立

データ送信に先立ち,ホストAとホストBの間で通信の準備をする必要があります。それをコネクションの確立といいます。
 まず,ホストAはホストBにSYN(SYNchronization:同期)を送ります。ホストBはそれを受けて要求を受け付けたACK(ACKnowledgement:確認応答)とSYNを返信します。それを受けてホストAはACKを送ります。
 ホストA(パソコン)がホストB(サーバ)に、SYNのTCPヘッダに始点ポート番号を2000、終点ポート番号を80として送ると、ACKでは逆に始点ポート番号が80、終点ポート番号が2000のTCPヘッダになります。つまり担当者間で相手を確認しあうのです。

これで送信する準備ができました。なお,このように3回のやりとりをするので,3ウエイハンドシェイクといいます。また,一般に相手との確認をとることをネゴシエーションといいます。

データの送信

ホストAは,データを送信します。ホストBはそれを受信するとホストAにACKを戻します。それを受けてホストAは次のデータを送ります。このとき,一定時間内にACKが来ないと,ホストAは同じデータを再送します。
 しかし,ACKが返信している間に再送すればデータが重複しますし,すべてのデータが同じ経路を通る保証はありませんから,ホストAが送信する順序とホストBに到着する順序が異なる場合があります。それを整理するのが,TCPヘッダにある「シーケンス番号」です。それにより,ホストBは次に受信するべきシーケンス番号をホストAに伝えます。このようにして,データが順序正しくホストBに送られます。

コネクションの解放

すべてのデータを送信完了したら,コネクションを解放します。まず,ホストAからFIN(FINish:終了)を送り,ホストBからACKを返信します。次に逆にホストBからFINを送り,ホストAがACKを戻すことにより終了します。
 なお,SYN,ACK,FINなどはTCPヘッダの「コントロールビット」に記入されます。


チェック機能

電文が正しく送られたかのチェックをします。それには、送られてきた電文の伝送中ビット誤りだけでなく、送った電文が到達したか、順序正しく到達したかの確認があります。このようなために、一つの電文の送受信には面倒な手続きが発生します。

誤り検出

伝送中のビット誤りを検出するために、TCPヘッダにはTCPチェックサムのフィールドがあり、チェックサム方式で確認します。ここでチェックするのは送信元と受信先のポート番号、シーケンス番号、パケット長などだけで本文などは対象にしていません。
 検出が緩やかなのは、すでにIPでのチェックをしていることと、チェック時間の短縮のためです。他のチェック方式に変更することもできます。

順序制御

電子メールなどの電文は長いので、複数のパケットに分割されます。また実際に送るときには複数のパケットを一つのフレームにして送信します。IPでの経路制御で示したように、個々のフレームは異なる経路になることもありますし、伝送している間に輻輳が発生するかもしれません。発信順序と受信順序が異なることもあるのです。それを正しく編集しなおすのがシーケンス番号です。
 いま、発信先ホストAが11、12、13番のパケットをフレームにしたとき、TCPヘッダのシーケンス番号は11になっています。
 受信先ホストBは、それを受け取ると、次に来るべきシーケンス番号14をACK(確認応答)としてAに送ります。それを受けたAは、次のフレームを14番からのパケットをシーケンス番号14としたフレームを送信します。
 このとき、シーケンス番号14のフレームをすでに送信していたならば、そのフレームが送信中に失われたとして再送信します。

送達確認

送信してから確認応答が戻るまでの時間が想定した時間よりも長くなったときは再送します。この再送するまでの待ち時間のことをRTO(Retransmission Time Out:再送タイムアウト)と呼びます。


フロー制御(流量制御)

パケットの到着間隔に比べて受信先ホストBの処理能力が極端に低いと、パケットを受けきれずオーバフローしてしまいます。また、それを懸念して発信元ホストAがパケットの送出間隔を大きくすると、通信時間が長くなってしまいます。できる限り多くのデータが流れるように制御することをプロ―制御といいます。

ウィンドウ制御

TCPで利用される代表的なフロー制御の手法にウィンドウ制御があります。
 データを1個送受信するたびにACKを取り交わすよりも,一度にいくつかのデータをまとめて送るほうが効率的です。
 そのために、受信先ホストBのメモリ上に「ウィンドウ」というバッファ領域を確保して、応答確認のあったブロック数だけウィンドウをずらすことによって、複数のデータをまとめて送ることができます。そのウィンドウのサイズ、すなわち、受信確認を待たずに送信できる最大メッセージ数をウィンドウサイズといいます。
 このウインドウサイズを発信元ホストAに通知することによりホストAの送信量を制御します。

輻輳(ふくそう)制御

輻輳とは,ネットワークの伝送能力を超える大量のトラフィックが発生し,正常な通信ができない状況のことです。輻輳状態になると、中継ルータに大量の転送待ちパケットがたまり、次のような現象が発生します。
 伝送遅延:後続のパケットが設定時間内に到着しない。
 パケット破棄:一部のパケットが消失する。データの中抜け。
 輻輳崩壊:輻輳状態の悪化よる通信効率の極度の低下

フロー制御のうち、輻輳の発生回避や回復の技術を輻輳制御(congestion control)といいます。
 通信が始まった直後では,経路のどこが混雑しているかわかりません。そのときに大量のデータを送信すると,輻輳が起こる危険があります。それを避けるために,通信開始時はウィンドウサイズを小さくしておき、ホストBから返されるウインドウサイズとを比較しながら,次第に増やしていく方法をスロースタートといいます。


UDP(User Datagram Protocol)

UDPは,TCPと同様トランスポート層のプロトコルですが,IPと同様のコネクションレス型の通信を行います。ポート番号を持つこと,チェックサムをすること以外には,IPとほとんど違いはありません。
 コネクション型通信をするための情報が不要なので,UDPヘッダは非常にシンプルです。

UDPヘッダの形式

コネクションレス型通信とは,ホストAとホストBが接続したら,直ちにデータを一方的に送りつける方式で,エラーがあってもわかりませんので再送機能もありませんし,フロー制御機能もありません。それだけ,信頼性が低いといえますが,逆に伝送効率は高くなります。
 それで,次のような用途に用いられます。

マルチメディア通信
動画や音声では,データの一部が失われても一瞬の出来事に過ぎず,数値や文字データのような深刻な影響はありません。逆に,伝送効率が悪いと途中で途切れてしまうので困ります。それで,ストリーミングでの音楽や映画の配信にはUDPが用いられます。
少量データの同報通信
送信するデータが少ないとき,TCPでは本来のデータ伝送時間に対するオーバーヘッドの時間の割合が大きくなります。しかも,多数の相手に同報するときはなおさらです。それで,ルーティングやDNS、NTP(Network Time Protocol、:コンピュータ内部時計をネットワークから標準時計に同期)などでは,UDPを用いるのが適切です。

ストリーミング

ストリーミング方式について補充しておきます。

通常のデータ伝送では、送信側にデータがすべて蓄積されており、それをすべて受信してから再生します。しかし、それではライブ動画などもいったん録画してからの送信になり、送信時間や再生時間がかかるので、視聴までに時間がかかりリアルタイム性が失われます。
 それに対して、ストリーミング方式とは、演技を撮影しつつデジタル化して送信し、受信したら同時に再生して視聴できるようにした方式です。データの完全性よりもリアルタイム性を優先した送信、例えばライブ動画のように映像や楽曲など大量マルチメディアデータをリアルタイムに視聴するのに適しています。

このような通信をリアルタイム通信といいますが、ストリーミング方式はリアルタイム通信の代表的方式です。ストリーミング方式のプロトコルには、UDP、UDPをベースにしたRTP(Real-Time Protocol)とそれを補助するRTCP(RTP Control Protokol)があります。

大量マルチメディアデータの伝送では、高速伝送が必要になります。TCPではパケット送受信のたびにネゴシエーションでの確認やにシーケンス番号での順序再編をするので、伝送効率が低くなります。それで、そのような処理を省略した、いわば垂れ流し方式のUDPを用いることにより、比較的低速な回線でも実現できます。
 UDPはデータの到着間隔が一定していない(それをジッタといいます)欠点があります。それによりデータが欠落することもあります。ジッタの発生は、取引情報のような正確性が重要なデータでは致命的ですが、動画データではデータの欠落があっても画面やスピーカーにちょっとしたノイズや音飛びが発生する程度で許容できます。しかも近年は、回線品質の向上により、このようなエラーが少なくなってきました。
 

ジッタの影響を防ぎ安定した再生をするためには、一定のデータ量をバッファに確保してから再生を開始します。バッファを大きくすればジッタを吸収できますが、バッファにデータが蓄積されるまでの遅延時間がかかります。そのため、ストリーミング方式でも厳密にはリアルタイムではないのです。

ストリーミング方式は、通常、再生したデータは消去されるので、全体のデータは保管されません。そのため、再度視聴することができません。しかし、著作権の観点では安全だといえます(法的にはいろいろな意見があります)。


本シリーズの目次へ