TCPソケットだけじゃない！Node.jsのリアルタイム通信と接続管理のベストプラクティス

2025-05-27

socket.connecting そのものは、直接的に「イベント」として存在するわけではありませんが、ソケットが接続を試みている最中の状態を表すものとして理解できます。

より具体的に解説すると、Node.js の net.Socket オブジェクトには、以下のような接続関連のイベントやメソッドがあります。

socket.connect() メソッド
これは、クライアントとして特定のサーバーに接続を開始する際に呼び出すメソッドです。ポート番号、ホスト、および接続が確立された際に実行されるコールバック関数を指定できます。このメソッドが呼び出された時点から、ソケットは接続を試みる状態になります。
'connect' イベント
socket.connect() メソッドが成功し、ソケット接続が確立された直後に発火するイベントです。このイベントが発火した時点で、ソケットはデータの送受信が可能になります。
'ready' イベント
Node.js のドキュメント（特に新しいバージョン）を見ると、'connect' イベントの直後に 'ready' イベントが発火すると記載されています。これは、ソケットが実際に使用可能な状態になったことを示すものです。ほとんどの場合、'connect' と 'ready' はほぼ同時に発生しますが、内部的には微妙な違いがある可能性があります。

socket.connecting という表現は、これらのイベントやメソッドの文脈において、ソケットがまだ完全に接続されていないが、接続プロセスが進行中である状態を指すことが多いです。

例えば、socket.connect() を呼び出した直後で、まだ 'connect' イベントが発火していない期間が socket.connecting の状態であると考えることができます。

具体的な例：

const net = require('net');

const client = new net.Socket();

client.on('connect', () => {
  console.log('TCP接続が確立されました！');
  // ここでデータの送受信が可能になります
  client.write('Hello, server!');
});

client.on('data', (data) => {
  console.log('サーバーからデータを受信しました:', data.toString());
  client.end(); // 接続を終了
});

client.on('end', () => {
  console.log('サーバーとの接続が終了しました。');
});

client.on('error', (err) => {
  console.error('接続エラーが発生しました:', err.message);
});

// 接続を開始
// このconnect()呼び出し後から'connect'イベント発火までの間が
// 概念的に「socket.connecting」の状態と言えます
client.connect(3000, 'localhost', () => {
  console.log('接続試行中...');
});

上記のコード例では、client.connect(3000, 'localhost', ...) を呼び出した時点から、'connect' イベントが発火するまでの間が、ソケットが「接続中」である状態です。この「接続中」という概念を指して socket.connecting と表現されることがあります。

通常、socket.connect() メソッドを呼び出した後、'connect' イベントが発火するまでの期間が「接続中」の状態とみなされます。
具体的なイベントとしては、'connect' イベントが接続成功時に発火し、その直後に 'ready' イベントも発火します。
socket.connecting は、Node.js の net.Socket がサーバーへの接続を試みている途中の状態を指す概念的な表現です。

ECONNREFUSED (Connection Refused)

エラーの原因
これは最も一般的な接続エラーの一つです。クライアントが接続しようとしているサーバーが、指定されたポートで接続を受け付けていない場合に発生します。主な原因は以下の通りです。

サーバーがリッスンしていない
サーバーが起動していても、server.listen()が呼び出されていない、または正しく設定されていない。
ファイアウォールによるブロック
サーバー側のファイアウォールが、指定されたポートへの接続をブロックしている。
IPアドレス/ホスト名が間違っている
クライアントが接続しようとしているIPアドレスまたはホスト名が間違っているか、到達できない。
ポート番号が間違っている
クライアントが接続しようとしているポート番号と、サーバーがリッスンしているポート番号が一致していない。
サーバーが起動していない
接続しようとしているサーバープログラム（Node.jsのnet.Serverなど）が実行されていない。

トラブルシューティング

netstat コマンドの使用
サーバー側で netstat -an | grep <port_number> (Linux/macOS) または netstat -an | findstr <port_number> (Windows) を実行し、指定されたポートが LISTEN 状態になっているか確認します。
ファイアウォールの確認
サーバー側のOS（Linuxのiptables、Windows Firewallなど）やネットワーク機器（ルーターなど）のファイアウォール設定を確認し、指定されたポートへの接続が許可されていることを確認します。
IPアドレス/ホスト名の確認
localhost を使用している場合は問題ないことが多いですが、リモートサーバーに接続する場合は、IPアドレスまたはホスト名が正しいか、pingなどで到達可能かを確認します。
ポート番号の確認
クライアントとサーバーの両方で、使用しているポート番号が一致していることを二重に確認します。例えば、クライアントが client.connect(3000, 'localhost') で接続し、サーバーが server.listen(3000) でリッスンしているか確認します。
サーバーの起動確認
サーバー側の Node.js プロセスが実際に実行されているか確認します。

ETIMEDOUT (Connection Timeout)

エラーの原因
クライアントがサーバーへの接続を試みたものの、指定された時間内に応答がなかった場合に発生します。これは通常、ネットワークの問題やサーバーの応答遅延が原因です。

存在しないIPアドレス/ホスト名
接続しようとしているIPアドレスやホスト名が存在しないか、ネットワーク上で到達不可能。
ファイアウォールによるパケット破棄
ファイアウォールが接続要求パケットを破棄しているが、ECONNREFUSED のように拒否信号を返さない場合。
サーバーの応答遅延
サーバーが過負荷状態にあるか、何らかの理由で接続要求への応答が遅れている。
ネットワークの遅延/不安定性
ネットワークの混雑や不安定さにより、接続要求がタイムアウトする。

トラブルシューティング

IPアドレスの到達可能性
traceroute (Linux/macOS) や tracert (Windows) コマンドで、サーバーへのネットワークパスを確認し、途中でパケットが失われていないか確認します。
タイムアウト値の調整
Node.jsのnet.Socketにはデフォルトの接続タイムアウトがありません。接続のタイムアウトを設定するには、socket.setTimeout() を使用し、'timeout' イベントをリッスンする必要があります。しかし、これは接続確立後のアイドルタイムアウトであり、接続試行自体のタイムアウトはOSレベルで管理されるため、調整が難しい場合があります。ネットワーク環境やサーバーの応答速度に合わせて、リトライロジックを実装することも有効です。
ファイアウォールの確認
ECONNREFUSED と同様に、ファイアウォールが原因である可能性も考慮します。
サーバーの負荷状況確認
サーバーが過負荷状態でないか、CPU使用率やメモリ使用量などを確認します。
ネットワーク接続の確認
クライアントとサーバー間のネットワーク接続が安定しているか確認します。ping コマンドでサーバーに到達できるか試します。

EADDRINUSE (Address Already in Use)

エラーの原因
これは主にサーバー側で発生するエラーです。指定されたポートがすでに別のプロセスによって使用されている場合に発生します。

別のアプリケーションがポートを使用している
他のアプリケーションが同じポートを使用している。
以前のサーバープロセスが残っている
以前に起動したサーバープロセスが終了しておらず、ポートを解放していない。

トラブルシューティング

server.on('error', ...) でハンドリング
サーバーが EADDRINUSE エラーに遭遇した場合に、それを適切に処理するロジック（例：少し待ってから再試行する）を実装することができます。
サーバーの再起動
しばらく待ってからサーバーを再起動すると、OSがポートを解放している場合があります。
ポート番号の変更
別のポート番号を使用するようにサーバーの設定を変更します。
プロセスの終了
lsof -i :<port_number> (Linux/macOS) または netstat -ano | findstr <port_number> と taskkill /PID <PID> /F (Windows) を使って、そのポートを使用しているプロセスを特定し、終了させます。

ENOTFOUND / EAI_AGAIN (DNS Resolution Errors)

エラーの原因
接続しようとしているホスト名が解決できない、またはDNSサーバーに一時的にアクセスできない場合に発生します。

ネットワーク設定の問題
DNSリゾルバにアクセスできない。
DNSサーバーの問題
ローカルのDNS設定が間違っているか、DNSサーバー自体がダウンしている。
ホスト名が間違っている
存在しないホスト名に接続しようとしている。

トラブルシューティング

一時的な問題
EAI_AGAIN は一時的なDNS解決の失敗を示すことが多いため、少し時間をおいてから再試行することで解決する場合があります。
ネットワーク設定の確認
/etc/resolv.conf (Linux/macOS) やネットワークアダプターのDNS設定が正しいか確認します。
DNS解決のテスト
ping <hostname> や nslookup <hostname> コマンドを使って、ホスト名が正しくIPアドレスに解決されるか確認します。
ホスト名の確認
接続しようとしているホスト名が正しいか、スペルミスがないか確認します。

ENETUNREACH (Network Unreachable)

エラーの原因
指定されたIPアドレスまたはホスト名へのルートが、クライアントのネットワーク設定で利用できない場合に発生します。これは通常、ルーティングの問題やネットワークインターフェースの無効化などが原因です。

ネットワークインターフェースの無効化
クライアント側のネットワークインターフェース（Wi-Fi、Ethernetなど）が無効になっている、または正しく設定されていない。
ルーティングの問題
ルーターの設定ミスやネットワークの分断などにより、目的のネットワークに到達できない。

ルーティングテーブルの確認
route -n (Linux/macOS) または route print (Windows) コマンドで、ルーティングテーブルに目的のIPアドレスへのルートがあるか確認します。
IPアドレス/サブネットマスク/ゲートウェイの確認
クライアントのネットワーク設定が正しいか確認します。
ネットワークケーブル/Wi-Fi接続の確認
物理的なネットワーク接続に問題がないか確認します。

ネットワークツールの活用
ping, traceroute/tracert, netstat, wireshark などのネットワークツールを積極的に活用して、通信の状況を把握します。
最小限のコードで再現
問題を切り分けるために、必要最小限のコードでエラーが再現するか試します。
詳細なログ出力
サーバー側とクライアント側の両方で、接続の成功/失敗、送受信データなどに関する詳細なログを出力するようにします。
エラーハンドリングの実装
常に socket.on('error', (err) => { ... }); を実装し、エラーの内容をログに出力するようにします。これにより、問題の特定が容易になります。

しかし、接続試行中の状態を把握するために、socket.connect() メソッドとそれに続くイベントをどのように扱うかを示すことができます。

基本的なクライアント接続とイベントハンドリング

これは最も基本的な例で、ソケットが接続を試み、その結果をイベントで受け取る方法です。

// client.js
const net = require('net');

const HOST = 'localhost'; // 接続先のホスト名
const PORT = 3000;      // 接続先のポート番号

console.log(`サーバー ${HOST}:${PORT} への接続を試行中...`);

const client = new net.Socket();

// 'connect' イベント: 接続が正常に確立されたときに発火
client.on('connect', () => {
  console.log('接続が確立されました！サーバーにデータを送信します。');
  client.write('Hello from client!');
});

// 'data' イベント: サーバーからデータを受信したときに発火
client.on('data', (data) => {
  console.log(`サーバーからデータを受信しました: ${data.toString()}`);
  client.end(); // データ受信後、接続を終了
});

// 'end' イベント: サーバーが接続を終了したときに発火
client.on('end', () => {
  console.log('サーバーが接続を終了しました。');
});

// 'close' イベント: ソケットが完全にクローズされたときに発火
client.on('close', () => {
  console.log('ソケットがクローズされました。');
});

// 'error' イベント: 接続中またはデータ送受信中にエラーが発生したときに発火
client.on('error', (err) => {
  console.error(`エラーが発生しました: ${err.message}`);
  // エラータイプに応じた処理を行う
  if (err.code === 'ECONNREFUSED') {
    console.error('接続が拒否されました。サーバーが起動しているか、ポート番号が正しいか確認してください。');
  } else if (err.code === 'ETIMEDOUT') {
    console.error('接続がタイムアウトしました。ネットワークの問題か、サーバーが応答していません。');
  } else if (err.code === 'ENOTFOUND') {
    console.error('ホスト名が見つかりません。ホスト名が正しいか確認してください。');
  }
  client.destroy(); // エラー発生時、ソケットを強制的にクローズ
});

// サーバーへの接続を開始
// このメソッド呼び出し後から 'connect' イベント発火までの間が
// 概念的に「socket.connecting」の状態
client.connect(PORT, HOST);

// server.js (上記 client.js と一緒に実行してください)
const net = require('net');

const PORT = 3000;
const HOST = 'localhost';

const server = net.createServer((socket) => {
  console.log(`クライアントが接続しました: ${socket.remoteAddress}:${socket.remotePort}`);

  // クライアントからデータを受信
  socket.on('data', (data) => {
    console.log(`クライアントからデータを受信しました: ${data.toString()}`);
    // 受信したデータをエコーバック
    socket.write(`Echo: ${data.toString()}`);
  });

  // クライアントが接続を終了
  socket.on('end', () => {
    console.log(`クライアントが接続を終了しました: ${socket.remoteAddress}:${socket.remotePort}`);
  });

  // エラーハンドリング
  socket.on('error', (err) => {
    console.error(`ソケットエラーが発生しました: ${err.message}`);
  });

  // ソケットが完全にクローズされたとき
  socket.on('close', () => {
    console.log(`ソケットがクローズされました: ${socket.remoteAddress}:${socket.remotePort}`);
  });
});

server.listen(PORT, HOST, () => {
  console.log(`サーバーが ${HOST}:${PORT} でリッスンを開始しました。`);
});

server.on('error', (err) => {
  if (err.code === 'EADDRINUSE') {
    console.error(`ポート ${PORT} は既に使用されています。`);
    process.exit(1);
  } else {
    console.error(`サーバーエラー: ${err.message}`);
  }
});

実行方法

server.js を実行: node server.js
別のターミナルで client.js を実行: node client.js

これにより、クライアントがサーバーに接続し、データ送受信を行う一連の流れを確認できます。

net.Socket には接続試行自体のタイムアウト設定は直接ありません。OSのタイムアウト設定に依存しますが、アプリケーション側で独自のタイムアウトを実装することで、接続が完了しない場合に備えることができます。

// client_with_timeout.js
const net = require('net');

const HOST = 'localhost';
const PORT = 3000;
const CONNECT_TIMEOUT_MS = 5000; // 5秒で接続タイムアウト

console.log(`サーバー ${HOST}:${PORT} への接続を試行中... (タイムアウト: ${CONNECT_TIMEOUT_MS}ms)`);

const client = new net.Socket();
let connectTimeoutId;

// 接続試行開始時にタイマーを設定
const startConnectTimeout = () => {
  connectTimeoutId = setTimeout(() => {
    console.error(`接続タイムアウト: ${CONNECT_TIMEOUT_MS}ms 以内に接続できませんでした。`);
    client.destroy(); // ソケットを強制的にクローズ
  }, CONNECT_TIMEOUT_MS);
};

// 接続成功時にタイマーをクリア
const clearConnectTimeout = () => {
  if (connectTimeoutId) {
    clearTimeout(connectTimeoutId);
    connectTimeoutId = null;
  }
};

client.on('connect', () => {
  clearConnectTimeout(); // 接続成功したのでタイマーをクリア
  console.log('接続が確立されました！');
  client.write('Hello from client with timeout!');
});

client.on('data', (data) => {
  console.log(`サーバーからデータを受信しました: ${data.toString()}`);
  client.end();
});

client.on('error', (err) => {
  clearConnectTimeout(); // エラー発生時もタイマーをクリア
  console.error(`エラーが発生しました: ${err.message}`);
  client.destroy();
});

client.on('close', () => {
  console.log('ソケットがクローズされました。');
});

// 接続を開始する直前にタイムアウトタイマーを設定
startConnectTimeout();
client.connect(PORT, HOST);

// わざと存在しないポートに接続してタイムアウトをテストする場合
// client.connect(9999, HOST); // 例: 存在しないポート

テスト方法

server.js を起動しない状態で client_with_timeout.js を実行してみてください。5秒後にタイムアウトエラーが表示されるはずです。
server.js を起動してから client_with_timeout.js を実行すると、正常に接続が確立され、タイムアウトタイマーはクリアされます。

厳密には、Node.js の net.Socket オブジェクトには、connecting という直接的なプロパティは存在しません。しかし、ソケットの内部状態を間接的に推測できるプロパティはいくつかあります（ただし、これらは内部的なものであり、将来のバージョンで変更される可能性があるため、依存すべきではありません）。

socket.readyState: より信頼性の高いプロパティとして socket.readyState があります。これは以下の値を取ります。
- 'opening': ソケットが作成されたばかりで、まだ接続が確立されていない状態。
- 'open': ソケットが接続され、データの送受信が可能。
- 'readOnly': 読み取りはできるが、書き込みはできない。
- 'writeOnly': 書き込みはできるが、読み取りはできない。
- 'closed': ソケットが完全にクローズされた状態。
socket.connecting: これは Node.js のドキュメントには記載されていない内部プロパティですが、古い情報や一部の環境では存在し、接続が確立されていない場合に true となることがあります。現在の推奨される方法ではありません。

socket.readyState を使用した例（推奨）

// client_with_readyState.js
const net = require('net');

const HOST = 'localhost';
const PORT = 3000;

const client = new net.Socket();

console.log(`初期状態: ${client.readyState}`); // 通常は 'opening' または 'closed' (接続前)

client.on('connect', () => {
  console.log(`接続後状態: ${client.readyState}`); // 'open' になる
  console.log('接続が確立されました！');
  client.write('Checking readyState!');
});

client.on('data', (data) => {
  console.log(`データ受信中状態: ${client.readyState}`); // 'open' のまま
  console.log(`サーバーからデータを受信しました: ${data.toString()}`);
  client.end();
});

client.on('close', () => {
  console.log(`クローズ後状態: ${client.readyState}`); // 'closed' になる
  console.log('ソケットがクローズされました。');
});

client.on('error', (err) => {
  console.error(`エラーが発生しました: ${err.message}`);
  // エラー発生後、readyState は 'closed' になることが多い
  console.log(`エラー発生後状態: ${client.readyState}`);
  client.destroy();
});

// 接続開始
client.connect(PORT, HOST);

// connect()呼び出し直後、readyStateは通常'opening'です。
// ただし、この時点での console.log は、イベントループの非同期性により
// connectイベント発火前でも 'opening' を示す可能性が高いです。
console.log(`connect()呼び出し直後: ${client.readyState}`);

この例では、client.connect() を呼び出した直後、'connect' イベントが発火するまでの間、client.readyState は 'opening' である可能性が高いです。接続が成功すると 'open' に変化し、閉じると 'closed' になります。

Node.js の net モジュールにおける socket.connecting の代替方法、というよりは、より現代的で高レベルな代替手段、あるいは接続管理をより容易にする方法という観点から説明します。

net.Socket は低レベルな TCP ソケット API であり、接続の確立やデータのやり取りを直接制御できます。しかし、多くの場合、より抽象化されたプロトコルやライブラリを使用することで、接続に関する複雑なロジック（再接続、エラー処理、プロトコル解析など）を簡素化できます。

HTTP/HTTPS (Webアプリケーションの最も一般的な代替手段)

Web アプリケーションを構築する場合、TCP ソケットを直接扱うことは稀です。Node.js には強力な HTTP/HTTPS モジュールが組み込まれており、これらが事実上の標準です。

使用例

// http_server.js
const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('Hello from HTTP server!\n');
});

- Web ブラウザとの互換性（HTTP/HTTPS はブラウザの標準プロトコル）。
- リクエスト/レスポンスモデルに基づいているため、サーバーとクライアント間の情報の流れが明確。
- RESTful API の構築に最適。
- Node.js に標準で組み込まれており、追加のモジュールは不要。
- 接続の確立（TCPハンドシェイクなど）は内部的に処理されるため、開発者が意識する必要がほとんどない。

server.listen(3000, () => { console.log('HTTP サーバーがポート 3000 でリッスン中'); });

// http_client.js
const http = require('http');

http.get('http://localhost:3000', (res) => {
  let data = '';
  res.on('data', (chunk) => {
    data += chunk;
  });
  res.on('end', () => {
    console.log('サーバーからの応答:', data);
  });
}).on('error', (err) => {
  console.error('HTTP リクエストエラー:', err.message);
});
```

この場合、`http.get()` が内部的に TCP 接続を確立しようとしますが、開発者は `socket.connecting` のような低レベルな状態を意識することなく、レスポンスイベント (`data`, `end`) やエラーイベント (`error`) を処理するだけで済みます。

WebSocket (リアルタイム双方向通信)

TCP ソケットのような双方向の持続的な接続が必要な場合、WebSocket は非常に強力な代替手段です。HTTP プロトコルを介してハンドシェイクを行い、その後は独立した双方向のチャネルを確立します。

使用例 (ws ライブラリ)

// npm install ws
// ws_server.js
const WebSocket = require('ws');

const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', ws => {
  console.log('WebSocket クライアントが接続しました');
  ws.on('message', message => {
    console.log(`受信メッセージ: ${message}`);
    ws.send(`サーバーからの応答: ${message}`);
  });
  ws.on('close', () => {
    console.log('WebSocket クライアントが切断しました');
  });
  ws.on('error', error => {
    console.error('WebSocket エラー:', error);
  });
});

// ws_client.js
const WebSocket = require('ws');

const ws = new WebSocket('ws://localhost:8080');

ws.onopen = () => {
  console.log('WebSocket 接続が開かれました');
  ws.send('Hello from WebSocket client!');
};

ws.onmessage = event => {
  console.log(`受信メッセージ: ${event.data}`);
  ws.close();
};

ws.onerror = error => {
  console.error('WebSocket エラー:', error);
};

ws.onclose = () => {
  console.log('WebSocket 接続が閉じられました');
};

WebSocket ライブラリは、内部的に TCP 接続の確立を処理し、接続中の状態やエラーを抽象化されたイベント (open, message, error, close) として提供します。

特徴
- HTTP と異なり、一度確立されるとサーバーとクライアント間でデータを自由にプッシュできる。
- チャットアプリケーション、ゲーム、リアルタイムダッシュボードなど、低レイテンシでリアルタイムなデータ交換が必要なアプリケーションに最適。
- ブラウザとの互換性が高い（JavaScript の WebSocket API）。
- Node.js には標準で WebSocket モジュールはないが、ws や socket.io といった非常に人気の高いライブラリが存在する。

Socket.IO (WebSocket の上位レイヤー)

WebSocket の上に、再接続機能、フォールバック（WebSocket が使えない環境でロングポーリングなどに切り替える）、ルーム機能などを追加したライブラリです。

使用例

// npm install socket.io
// socketio_server.js
const { Server } = require("socket.io");
const io = new Server(3000);

io.on("connection", (socket) => {
  console.log('Socket.IO クライアントが接続しました');
  socket.emit("hello", "Hello from Socket.IO server!"); // カスタムイベントを発行

  socket.on("client_message", (data) => {
    console.log(`クライアントからのメッセージ: ${data}`);
    socket.emit("server_response", `サーバーからの応答: ${data}`);
  });

  socket.on("disconnect", () => {
    console.log('Socket.IO クライアントが切断しました');
  });
});

// npm install socket.io-client
// socketio_client.js
const io_client = require("socket.io-client");
const socket = io_client("http://localhost:3000");

socket.on("connect", () => {
  console.log('Socket.IO 接続が確立しました');
  socket.emit("client_message", "Hello from Socket.IO client!");
});

socket.on("hello", (data) => {
  console.log(`サーバーからの 'hello' イベント受信: ${data}`);
});

socket.on("server_response", (data) => {
  console.log(`サーバーからの 'server_response' イベント受信: ${data}`);
  socket.disconnect(); // 接続を切断
});

socket.on("disconnect", () => {
  console.log('Socket.IO 接続が切断されました');
});

socket.on("connect_error", (err) => {
  console.error("Socket.IO 接続エラー:", err.message);
});

Socket.IO は、接続中の状態遷移や再接続ロジックを内部で管理し、connect, disconnect, connect_error といったイベントを開発者に提供します。

特徴
- リアルタイムアプリケーション開発をさらに簡素化。
- 接続の信頼性が向上し、低レベルな接続エラー処理を開発者が直接行う必要が減る。
- 多様な環境での互換性。
- イベントベースの API で、カスタムイベントを簡単に定義・発行できる。

特定のサービス間通信（マイクロサービスなど）では、RPC フレームワークが利用されます。これは、リモートの関数をローカルの関数のように呼び出せるようにするためのものです。gRPC などがこれに該当します。

使用例 (gRPC)
複雑なためコード例は省略しますが、通常は .proto ファイルでサービスとメッセージの定義を行い、それからコードを生成して使用します。
特徴
- サービス間のインターフェースを厳密に定義できる（Protocol Buffers など）。
- 多言語対応（様々な言語で同じサービス定義からクライアント/サーバーコードを生成できる）。
- 効率的な通信（HTTP/2 上で動作し、バイナリプロトコルを使用することが多い）。
- 接続の確立やエラー処理はフレームワークが管理。

net.Socket の socket.connecting という低レベルな概念に代わる代替手段は、アプリケーションの要件によって大きく異なります。

サービス間通信や厳密なインターフェース定義が必要な場合
RPC フレームワーク (gRPCなど) を検討します。
リアルタイムな双方向通信（ブラウザ含む）
WebSocket (ws または socket.io) が最適です。
Web API の構築
HTTP/HTTPS を使うのが最も一般的で推奨されます。