首页   注册   登录
 dawnh 最近的时间轴更新
dawnh

dawnh

V2EX 第 36834 号会员,加入于 2013-03-30 19:34:19 +08:00
今日活跃度排名 17946
dawnh 最近回复了
@iccfish 官方文档 https://docs.microsoft.com/en-us/windows/wsl/wsl2-about:
Increased file IO performance
File intensive operations like git clone, npm install, apt update, apt upgrade, and more will all be noticeably faster. The actual speed increase will depend on which app you’re running and how it is interacting with the file system. Initial versions of WSL 2 run up to 20x faster compared to WSL 1 when unpacking a zipped tarball, and around 2-5x faster when using git clone, npm install and cmake on various projects.

Channel9 开发者频道有视频演示实际速度比较,在重 IO 访问情况下保底有 2 倍性能提升,具体就不放链接了。
@iccfish 关于磁盘性能实际上 wsl 的目标和你的结果是相反的,也就是提供更加高的 IO 性能。其实 WSL1 的 IO 反倒是一直被诟病的。WSL2 则是给了 2 个方式:
在根目录下的文件访问是走 utility VM 的原生 ext4 文件读写是.vhdx,性能接近原生 ext4 。支持 POSIX 文件权限和 ACL 。但是如果要在 Windows 下访问则需要\\WSL$\path\to\file 这样走 Plan9 。
/mnt/<drive>是用 Plan9 mount 的 Windows 文件系统,性能一般,但可以无缝在 Windows 下互操作,对于文件系统特性支持有限。

你如果追求 IO 性能,则不应该把 WSL2 的文件放在 /mnt/<drive>下面,而是保持在 ext4 文件系统下。另外好像 WSL2 还有方法 mount 一个新的.vhdx 作为数据盘。
单纯只看连接流量统计的话可以看一下 SysInternals 的 TCPView,它底层是通过 ETW 做 trace 拿到的消息。
如果是要抓包,Network Monitor 可以,但是也是需要单独安装的。目前这个感觉是最稳定好用的 。还有一个是 Message Analyzer,这个复杂但不是很好用。
另外 Windows 10 从 RS5 开始自带一套新的抓包工具,pktmon,貌似也是通过 ETW 弄出来的数据。所以真要自己搞,研究一下 ETW Trace 相关的 API 应该是条不错的思路。

上面提到的所有产品现在都是微软第一方的。
109 天前
回复了 Poto 创建的主题 程序员 Win10 如何快捷睡眠?
一行命令搞定,建立快捷方式爱放哪里点放哪里:

rundll32.exe powrprof.dll,SetSuspendState 0,1,0
146 天前
回复了 superhxl 创建的主题 宽带症候群 上海电信桥接 IPTV 问题
@superhxl 你光猫是什么型号的?貌似现在的上海电信 SDN 的光猫已经不限定 iptv 绑哪个口了吧。
Azure 的上海-香港是怎么做到的?
216 天前
回复了 yding 创建的主题 宽带症候群 喜提上海电信 ipv6
今天发现也有 ipv6 地址了,不过路由器默认 native 的方式获得不了 LAN prefix,只有 WAN 的 /64 地址。切换到 passthrough 方式所有的机器都能获得一个 /64 地址了。
这么多年了,原来移动还没解决这个缓存服务器经常挂的问题啊。
另外,不要以为有了 HTTPS 就万无一失了,移动的缓存可是有连 SSL 都给你 proxy 的行为的,而且它的缓存服务器也经常炸,表现在 HTTPS 上就是证书拿不到。
也不知道 lz 的意图到底是加速下载还是如同上面某些回答的歪到攻击思路去了。不过无论怎样,提前预测 ACK 序列号于这两者恐怕都没有实际应用价值。
窗口固定,但是一次发送中未确认的也就是一个窗口大小的数据而已,你提前确认了,你预测了确认的 ACK,并确实发送到达了服务器,那服务器开始下一个数据发送,然而你完全无视是否接受继续预测 ACK,此时服务器还不一定发完数据就受到 ACK,那服务器的行为恐怕是忽略,或者直接 RST 了。具体看实现。
按窗口的极限算是 65535 字节也就是 64K。也就是说你基本上能骗服务器发一个 64K,基本上下一个 64K 就很难预测准了。这对于下载加速来说基本达不到目的,可能对于攻击有点作用?不知道 64K 算不算放大攻击了。不过要达成这个攻击自己也要完成三次握手并发送实际请求,至少也要 1K 左右的数据发送吧。
2019-01-11 17:33:34 +08:00
回复了 daijinming 创建的主题 程序员 dotnet core 多语言问题请教
简单搜索了一下连接里的代码,似乎是直接调用.net core 的 UseRequestLocalization(),那在 startup()设置一下应该就好了吧,直接贴.net core 的样例麻烦自己改吧:

var supportedCultures = new[]
{
new CultureInfo("en-US"),
new CultureInfo("fr"),
};

app.UseRequestLocalization(new RequestLocalizationOptions
{
DefaultRequestCulture = new RequestCulture("en-US"),
// Formatting numbers, dates, etc.
SupportedCultures = supportedCultures,
// UI strings that we have localized.
SupportedUICultures = supportedCultures
});

app.UseStaticFiles();
// To configure external authentication,
// see: http://go.microsoft.com/fwlink/?LinkID=532715
app.UseAuthentication();
app.UseMvcWithDefaultRoute();
来自: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/localization?view=aspnetcore-2.2
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1193 人在线   最高记录 5168   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 10ms · UTC 23:13 · PVG 07:13 · LAX 16:13 · JFK 19:13
♥ Do have faith in what you're doing.