Panda Noir

JavaScript の限界を究めるブログでした。最近はいろんな分野を幅広めに書いてます。

ネットワークでよく出てくる「コネクション」ってなんなんだろう?

ネットワークにおいて「コネクション」という単語はよく耳にします。

  • 「WebSocketはコネクションを確立後、ずっとそのコネクションを使う」
  • 「ロングポーリングは返すたびにクライアントがコネクションを確立し直す」
  • 「TCPでは3ウェイハンドシェイクでコネクションを確立する」

これらを見ると「コネクションは通信経路のことなのかな?」と勘違いしそうになります。実際僕はそう勘違いしていました。今回はそんな実態のよくわからない「コネクション」について解説します。

tl;dr

コネクションが確立されていれば情報を確実に伝えることができる。

コネクションとはネットワーク上の経路ではない。

コネクション≠ネットワーク上の経路

TCP・UDPはそれぞれコネクション型プロトコル、コネクションレス型プロトコルと呼ばれています。この2つを例に、コネクションについて説明していきたいと思います。

TCPもUDPも、どちらもルーターを中継しながらデータを届けています。しかし、経路は固定ではありません。もし経路が固定だったら、ルーターの意味がありません。つまり、コネクション型もコネクションレス型も経路は固定されていないということです。

コネクションを確立しても、経路が一定でないので、これでコネクションは経路のことではないとお分かりいただけたかと思います。

(余談ですが、経路を固定するコネクション型通信も存在します。これも混乱を招く一因です。)

コネクションとは何なのか?

TCPでは「通信をはじめるよ」「いいよ」というように通信可能かきちんと確認してから通信を行います。通信が可能かを確認できたことを「コネクションが確立できた」と言います。

それに対し、UDPでは「送るよ。返事はいらないよ」と相手が受信できるか確認せずに送信します。つまり、コネクションを確立しないで通信をします。ここがTCPとの最大の違いです。

TCPは相手が通信可能か確認してから通信をはじめます。また、一度通信を始めたらコネクションを解放するまでお互いに通信状態を維持します。それに対してUDPでは相手が通信可能なのか確認せず、ひたすら投げます。

コネクションを確立するというのは、相手がきちんと受信できる状態にあると確認することです。基本的に、コネクションを解放するまでは常に相手が受信できるかを確認する手続きを踏みます。TCPでは、受信側は情報を受信したら、受信できたという通知とともに、今受け取ることが出来る情報量を送信側に伝えます。そうすることで情報を送りすぎるということがなくなり、相手から情報をちゃんと受け取ることが出来ます。

様々なコネクション

HTTPでは、クライアントがリクエストするときにコネクションを確立します。サーバーがレスポンスを返すとコネクションを切断します。

ロングポーリングもHTTPと同様に、コネクションをリクエスト時に確立し、レスポンスを返すときに切断します。レスポンスを返した後、再度コネクションを確立する必要が有ります。

WebSocketでは一度コネクションを確立すると、以降はそれを使って通信を行います。サーバーがレスポンスを返しても切断をしません。

このように、コネクションをどう扱うかが各方法で異なっています。