コネクションタイムアウト

友達に電話をかけて誰も出ないとき、呼び出し音が永遠に鳴り続けるのをずっと聞き続ける人はいませんよね。しばらく待って応答がなければ、自分から電話を切るはずです。もし延々と呼び出し音だけが鳴り続けたら、かけた側も次の行動に移れず足止めを食らってしまいます。

インターネットの世界でも、これとまったく同じルールが常に働いています。スマホで特定のウェブサイトやアプリを開くとき、端末はまず通信先のサーバーに向けて「今、会話できますか？」という挨拶の合図を送ります。

しかし、相手のサーバーの電源が落ちていたり、ネットワーク回線が切れていたりすると、何の返事も返ってきません。返事のないサーバーをいつまでも待ち続けていたら、画面は読み込み中のまま固まり、端末の処理能力も無駄に消費されてしまいます。そこでプログラムは、あらかじめ設定した待機時間だけ待って、反応がなければ接続の試みをきっぱり諦めるように作られているのです。

もう少し正確に言うと、コネクションタイムアウトは実際のデータをやり取りしている最中に起きる問題ではなく、会話の通り道を最初に作る段階で発生します。

インターネット上で2台のコンピューターが通信するときは、「3ウェイ・ハンドシェイク（3-Way Handshake）」と呼ばれる手順を踏みます。まずこちらの端末が「繋いでもいいですか？」と手を差し伸べ（SYN）、サーバーが「いいですよ、繋ぎましょう」と応じ（SYN-ACK）、さらに端末が「了解しました」と確認の合図を送る（ACK）ことで、初めて信頼できる通信路が完成します。

ところが、サーバーの手前を守るファイアウォール（セキュリティシステム）が許可されていないアクセスとみなして合図を黙って捨ててしまったり、途中のネットワーク機器でデータが迷子になったりすると、最初の握手すら成立しません。こちらの端末は返事を待ちながらタイマーをカウントダウンし、約束された秒数に達した瞬間に接続失敗エラーを表示するのです。

コネクションタイムアウトとよく混同されるのが、リードタイムアウト（Read Timeout）です。この2つはエラーが起きるタイミングも原因もまったく異なります。飲食店に例えると、その違いがとてもよく分かります。

コネクションタイムアウトは、お店のドアをいくらノックしても中から返事がなく、店内に入ることすらできずに店の前を立ち去るような状況です。もし店員が出てきて「本日は休業です」と断られたなら、それは接続拒否（Connection Refused）という別のエラーになります。いずれにせよ、対話の窓口そのものが開いていません。

一方のリードタイムアウトは、お店に無事入店し、店員と会話して料理の注文まで済ませた状態です。しかし、厨房が混雑しすぎて1時間経っても料理が出てこず、待ちくたびれた客が帰ってしまうような状況にあたります。

つまり、コネクションタイムアウトが起きた場合は、サーバーがダウンしているか、ファイアウォールで遮断されているか、途中の通信経路が切れている可能性が高く、リードタイムアウトが出た場合は、サーバー側の処理が遅延している（負荷が高い、データベースの処理待ちなど）可能性が高いのです。