Windows Info 第184回

Windows Subsystem for Linux 2におけるネットワークの改良

実際に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で待ち受けしている状態であることがわかる。

Win32側でnetstat.exeを動かすと、WSL2側で待ち受けているポート3000はwslhost.exeが待ち受けしていることがわかる

　その後、Edgeを使って、http://localhost:3000/をアクセスさせる。すると、WSL2側のnode.jsスクリプトが動作して文字列を返す。

WSL2側のhttpサーバーをWin32側のウェブブラウザでアクセス。このとき、URLは「http://localhost:3000/」である

　このとき、WSL2側のnetstatコマンドでは、ポート3000に対して、127.0.0.1からアクセスされているようにみえる。実際、node.jsのスクリプトが受け取っているリクエスト情報では、127.0.0.1からのアクセスがなされているように見える。

WSL2側でnetstatコマンドを使うと、localhost(127.0.0.1）のポート3000で待ち受けがなされている

　この改良により、Win32側からは、WSL2側のネットワークサービスを常にlocalhostでアクセス可能になる。では、両方で同じポートを待ち受けに使ったらどうなるのかなのだが、TCP/IPでは、先に待ち受けを開始したほうが優先される。

　こうしたネットワークサービスは、Win32側では、サービスとして起動されることがほとんどなので、たとえば、IISや付属のFTPサーバーなどは、Windowsの起動時に動作してしまい、あとからwslhost.exeが待ち受けに使うことができない。ただし、WSL2の仮想ネットインターフェース側での待ち受けは有効なので、WSL2側はエラーにはならない。

　要は、Win32側のlocalhostをどっちが使うのかということであり、WSL2側のlocalhostはWSL2側からはそのまま利用できる。なお、マイクロソフトによれば、ウェブサーバなどを使った開発のことを考慮して、WSL2へlocalhostでアクセスできるようにする機能を優先して実装したとのことである。可能性としては、WSL2側でも同じようにlocalhostでWin32側のサービスにアクセスする機能が実装されるかもしれない。