前言

WSL是Windows Subsystem for Linux的缩写，即Windows系统的Linux子系统，从WIN10 1607(内部版本14393)后内置于WIN10系统中，并且支持家庭版用户的免费使用。
WSL对于那些即想拥有WINDOWS系统成熟的桌面环境，又想方便的使用各种Linux服务并希望在Linux系统下开发的人员来说非常友好。
其实回到十多年前，也有类似功能的一款软件，它就是coLinux（Cooperative Linux的缩写）。这款软件的图标是中国的太极图：

多么形象的图标，企鹅-Linux和视窗-Windows统一在了一起。
本人曾使用coLinux很长时间，直到后来随着windows系统的升级，coLinux越来越不稳定，经常导致windows蓝屏而最终放弃。
在那个微软视开源Linux系统为毒瘤、癌症的年代里，coLinux可以说生不逢时。这样一款需要与系统底层打交道的软件，如果没有微软的合作，很难做到稳定。今天又打开coLinux官网，发现Latest News停留在了2014年5月。
十年河东十年河西，微软终于转变战略，调整方向，以开放的姿态拥抱Linux,而且这个脚步越来越快。
WSL发布不久，我就开始尝试在上面工作，我能无缝的在Windows和Linux融合环境下工作，这确实是一种非常好的体验。不过遗憾也有，比如不支持cgroup、docker、iptables、磁盘性能差等等，毕竟是windows内核，很多问题很难解决。
面对这些问题，微软开发了WSL2。虽然是2，但按微软的路线图WSL 和 WSL2 是共存、共同发展的。实际使用时，WSL 和 WSL2能够同时运行，并且其镜像也能在两种模式中转换。
WSL2是以HYPER-V虚拟化为基础，通过HYPER-V启动真正的Linux系统，使用订制的Linux内核（该订制版内核源码微软已经开源到了GITHUB上，想自己编译内核的同学可以参考我的另外一篇BLOG - 编译更新 WSL2 内核至4.19.57，增加 Squashfs 支持）。
微软公布WSL2的技术方案后，有很多用户表示失望，认为这种技术就是HYPER-V上跑的Linux虚机，担心这样会极大的牺牲性能。
本人最初也有此担心，但当体验近两个月后，本人应该不会再回到WSL：

1. HYPER-V 加 Linux内核并没有感觉到降低多少启动速度，打开WSL2容器仍然是数秒之内;
2. 真正的Linux内核，Docker、cgroup、iptables这些服务都能正常工作。装完WSL2后，我就把Windows上跑的Docker、Mysql 等服务迁进了容器;
3. 饱受诟病的磁盘性能问题得到解决，这种提升就象把机械硬盘换代成了SSD硬盘。

WSL2还在快速的更新中，在GITHUB
WSL中，微软的开发人员与用户的互动也很密切，GITHUB上提的问题都能得到及时的回复。本人提出的问题得到了 Program Manager Craig Loewen
多次及时的回复。

工作中我会保持使用WIN10+WSL2——因为这确实是很酷的模式，并将长期关注WSL2的发展。这篇博客将长期跟踪WSL2的发展，文中也会汇总使用中遇到的问题。

WIN10+WSL2 这种开发模式应该很快在开发人员中流行起来，我们拭目以待。Microsoft is in the right way ~

18945: 支持通过localhost访问WSL2容器

18945之前的WSL2版本，如果我们在容器里运行了一个网络服务，例如启动一个WEB服务。想在 Win10 宿主机中访问这个WEB服务，我们先要通过 ip a 或 ifconfig 命令查看其IP地址才能访问，而且更崩溃的是每次重启后再运行WSL2容器，其IP地址和网关会重新分配。

• 截止2019/8/3日，官方文档中还是这种方式。

这确实是件很麻烦的事情，为此有开发者特意用golang开发了一个windows服务，让用户快捷的获取到WSL2的IP。
本次更新改进了这个问题，我们在WIN10中能够直接通过localhost 访问到WSL2容器中的服务，并且WLS2容器中的网络服务也能绑定到 0.0.0.0 上

例如：WSL2 容器内启动web服务器，使用python http.server模块启动一个WEB服务
python3 -m http.server，默认端口8000
然后在win10中的web浏览器中访问 http://localhost:8000/

bug: navicat 不能通过localhost直接访问容器内的mysql

github也有用户反馈了这个问题，官方确认是BUG并正在修复中。目前我的临时解决方案是使用ssh隧道

WSL资料收集

微软WSL官方文档