実際にWSL2側へのアクセスを試す
実際に、Win32からlocalhostを指定してWSL2側のネットワークサービスをアクセスしてみよう。ここでは、簡単にするため、WSL2側でnode.jsを動かし、httpサーバーを作った。といっても、リクエストに対して文字列を返すだけの機能しかない。
var http = require('http');
var port = 3000;
http.createServer(function (req, result) {
console.log('Connect:' + result.connection.remoteAddress);
result.writeHead(200, {'Content-Type': 'text/plain'});
var now = new Date;
result.end('This is WSL2.\n'+now.toISOString()+'\n');
}).listen(port,'0.0.0.0');
console.log('Server running at http://localhost:'+port+'/');
node.jsが何なのか、どうやって使うのかは、本記事の目的ではないので、簡単に、スクリプトでhttpサーバーを作ったとだけ理解いただきたい。これをポート番号3000で動作させる。WSL2側では、ポート3000がListen Portとなる。これは、netstatコマンドで確認できる。この状態で、Win32側のnetstat.exeを使ってListen Portを調べると、wslhost.exeがポート3000で待ち受けしている状態であることがわかる。
その後、Edgeを使って、http://localhost:3000/をアクセスさせる。すると、WSL2側のnode.jsスクリプトが動作して文字列を返す。
このとき、WSL2側のnetstatコマンドでは、ポート3000に対して、127.0.0.1からアクセスされているようにみえる。実際、node.jsのスクリプトが受け取っているリクエスト情報では、127.0.0.1からのアクセスがなされているように見える。
この改良により、Win32側からは、WSL2側のネットワークサービスを常にlocalhostでアクセス可能になる。では、両方で同じポートを待ち受けに使ったらどうなるのかなのだが、TCP/IPでは、先に待ち受けを開始したほうが優先される。
こうしたネットワークサービスは、Win32側では、サービスとして起動されることがほとんどなので、たとえば、IISや付属のFTPサーバーなどは、Windowsの起動時に動作してしまい、あとからwslhost.exeが待ち受けに使うことができない。ただし、WSL2の仮想ネットインターフェース側での待ち受けは有効なので、WSL2側はエラーにはならない。
要は、Win32側のlocalhostをどっちが使うのかということであり、WSL2側のlocalhostはWSL2側からはそのまま利用できる。なお、マイクロソフトによれば、ウェブサーバなどを使った開発のことを考慮して、WSL2へlocalhostでアクセスできるようにする機能を優先して実装したとのことである。可能性としては、WSL2側でも同じようにlocalhostでWin32側のサービスにアクセスする機能が実装されるかもしれない。

この連載の記事
-
第486回
PC
Excelがあればなんでもできる -
第485回
PC
Windows Subsystem for Linux(WSL)のソースコードが公開された -
第484回
PC
WindowsのコマンドラインでGrapheme Clusterを正しく扱うには -
第483回
PC
Microsoftが作るコンソールエディタがこの時代に復活 -
第482回
PC
WSL(Windows Subsystem for Linux)向けにFedoraディストリビューション登場 -
第481回
PC
Windows 11にそろそろ聞こえる25H2の声 -
第480回
PC
PowerShellが使う色を変更する -
第479回
PC
Copilot+ PCで利用できる「Windows Copilot Runtime」を試す ローカル推論用モデル「Phi Silica」とは? -
第478回
PC
Copilot+ PCでNPUを使ってローカル推論 「Windows Copilot Runtime」を試す -
第477回
PC
Windowsで2つの文字列を同時に含むテキストファイルを探す方法を考える -
第476回
PC
さらばSkype! Windows&MSのコミュニケーションアプリの30年 - この連載の一覧へ