开发者 Curl
2021-11-28
Here is a command I use often while measuring why an HTTP request is taking too long:
curl -L -w "time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_pretransfer: %{time_pretransfer}
time_redirect: %{time_redirect}
time_starttransfer: %{time_starttransfer}
time_total: %{time_total}
" https://example.com/
Here is the same command written as a one-liner, so that I can copy it easily from this page with a triple-click whenever I need it in future:
curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" https://example.com/
Here is how the output of the above command typically looks:
$ curl -L -w "namelookup: %{time_namelookup}\nconnect: %{time_connect}\nappconnect: %{time_appconnect}\npretransfer: %{time_pretransfer}\nstarttransfer: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
time_namelookup: 0.001403
time_connect: 0.245464
time_appconnect: 0.757656
time_pretransfer: 0.757823
time_redirect: 0.000000
time_starttransfer: 0.982111
time_total: 0.982326
In the output above, I have omitted most of the HTML output and replaced the omitted part with ellipsis for the sake of brevity.
The list below provides a description of each number in the output above. This information is picked straight from the manual page of curl 7.20.0. Here are the details:
time_namelookup: The time, in seconds, it took from the start until the name resolving was completed.
time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.
time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0)
time_pretransfer: The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.
time_redirect: The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3)
time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.
time_total: The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution.
An important thing worth noting here is that the difference in the numbers for time_appconnect and time_connect time tells us how much time is spent in SSL/TLS handshake. For a cleartext connection without SSL/TLS, this number is reported as zero. Here is an example output that demonstrates this:
$ curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" http://example.com/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
time_namelookup: 0.001507
time_connect: 0.247032
time_appconnect: 0.000000
time_pretransfer: 0.247122
time_redirect: 0.000000
time_starttransfer: 0.512645
time_total: 0.512853
Also note that time_redirect is zero in both outputs above. That is because no redirection occurs while visiting example.com. Here is another example that shows how the output looks when a redirection occurs:
$ curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" https://susam.in/blog
<!DOCTYPE HTML>
<html>
...
</html>
time_namelookup: 0.001886
time_connect: 0.152445
time_appconnect: 0.465326
time_pretransfer: 0.465413
time_redirect: 0.614289
time_starttransfer: 0.763997
time_total: 0.765413
When faced with a potential latency issue in web services, this is often one of the first commands I run several times from multiple clients because the results form this command help to get a quick sense of the layer that might be responsible for the latency issue.
开发者
2021-11-21
语言指包括语言的字符集以及有关的货币符号,日期格式等。为了区分不通的语言,人们设计了一些语言代码相关的标准来。
作为开发,只要涉及多语言,都一定会接触到语言代码。在各种不通的技术、语言框架中,这些代码并没有非常统一,比如简体中文,我见过 zh, zh_CN, zh-Hans, chs, zh_chs 几种不同的表示。
开发者 移动端 推送
2021-11-20
我没有做过移动端开发,我突然想到,如果我们要给手机端推送消息,会有些什么办法。
想来想去只有短信是最容易实现的,而且效果可以接受。
开发者 开发工具 在线服务
2021-11-18
编辑器
SSH
数据库 GUI
Redis GUI
虚拟化与容器
- VirtualBox
- Vagrant
- Docker
编程相关
- gitg
- Beyond Compare 可以一直试用
- Meld Linux 下的简化版 Beyond Compare
其他
在线服务
个人 工作 开发者
2021-11-13
最近两周开发了一个功能,其实质就是做个数据统计,没啥好说的。
我是在没有产品设计的前提下开始工作,产品的设计反倒有一点依赖我所能提供的数据。
而且,和以往自己写功能逻辑不通的是,我这次只管提供数据和方案,业务逻辑的实现由别人来做。
工作过程中遇到了一些问题,这里做个总结(复盘)。
个人 开发者
2021-10-24

我的主力开发环境是大概 14 年 4 月在 DELL 官方 (dell.com) 买的一台 Inspiron 14R (5437) 笔记本。
PS: 这台笔记本原本是我老婆办公用, 用了将近五年之后, 于 2019 年 1 月在换了一台 小米 Air 13.3, 然后我就有笔记本了...到现在我也用了两年多了。
开发者 Windows11
2021-10-15
https://www.microsoft.com/zh-cn/windows/windows-11-specifications
主要的变化
- 新的 UI 设计
根据网上流传的图片,还挺好看的,令人耳目一心
- 支持 Android App
其他:
- 新的应用商城
- 整合了微软的 Teams 作聊天功能
- 游戏相关的功能
- DirectX 12 Ultimate
- DirectStorage
- Auto HDR
- XBox 相关整合
硬件要求
CPU (1GHz,双核),内存 (4G),磁盘 (64G)
- CPU: 1GHz,双核
- 内存: 4G
- 磁盘: 64G
- UEFI 安全启动
- TPM 2.0
- 显卡:支持 DirectX 12, WDDM 2.0 驱动
CPU, 内存, 磁盘方面的要求,主流的配置应该都能满足。
UEFI 安全启动
检测工具
MS 官方工具只能给出一个是否的答复,太弱了(正在开发新的监测工具)。
社区有提供一个检测工具:WhyNotWin11.exe (GitHub 下载)
第一次检测:

- 引导方式:Legacy
- CPU 兼容性:不支持
- 硬盘分区形式:分区形式不是 GPT
- 安全启动:禁用或未检测到
- TPM 版本:不存在 TPM 模块或 BIOS 禁用
除了 CPU 之外,其他几项都可以在 BIOS 中设置。
TPM:如果是 Intel 就找一下 Platform Trust Technology, AMD 可能是 fTPM。

我的 CPU 是六代 i5,这就真的没办法了,i5 的话,最低要求是八代 (完整的 CPU 要求清单:Windows 11 supported Intel processors。
抛弃才发布六年(2015/09)的六代 CPU 绝壁是一个愚蠢的决定,希望微软耗子喂汁!
Tiny11(2023-02-07)
根据微信公众号高效程序员文章《Win11 极限精简版发布:2G内存就能流畅运行!》中的信息,有人基于 Windows 11 Pro 22H2 打造了 Tiny11,不需要 TPM 和安全启动。
开发者
2021-09-29

织梦官网放出上面这张公告:除了 “个人非盈利” 网站,其他没有拿到正式授权的织梦网站需要交 5800 授权费。
他们可能已经把清单列好了,律师团队也准备好了,正磨刀霍霍向着小站长们。
这可能就是中国特色开源协议的正确使用方式。
PS: 虽然我觉得 织梦CMS 是个垃圾,但我也不知道为啥,据说很多小站都是用的这个系统。
开发者 URI
2021-09-24
URI 与 URL
hierarchical part
┌───────────────────┴─────────────────────┐
authority path
┌───────────────┴───────────────┐┌───┴────┐
abc://username:password@example.com:123/path/data?key=value&key2=value2#fragid1
└┬┘ └───────┬───────┘ └────┬────┘ └┬┘ └─────────┬─────────┘ └──┬──┘
scheme user information host port query fragment
urn:example:mammal:monotreme:echidna
└┬┘ └──────────────┬───────────────┘
scheme path
URI
URI (统一资源标识符),标识一个资源主要有两种方法,根据名称(URN),根据路径(URL)。
URI 语法:

有一个问题就是注册的 URI scheme 基本上都可以认为是用于资源定位,所以 URI 和 URL 的概念就比较模糊了。
有的 scheme,比如说 data:<mediatype>[;base64],<data>,既不算 URL,也不算 URI。
有的 scheme,比如说 sms:<phone number>?<action>,我觉得是属于名称标识,但是不符合 URN 的定义(必须 urn:)。
而且实际上,就比如说 URL http://example.com/user/create,我们用来创建一个用户,如果套用万维网创建时的学院派设想,我们只能把创建这个动作理解成一个资源了。所以,我认为深入讨论这几个 “统一资源” 的概念之间到底存在什么差异没有什么意义,大致知道他们的渊源就够了:先随着 WWW 出来了 URL 的概念,然后又有人整出来一个 URN,再后来统一为 URI 标准,这几个概念本来就是混乱的,这就是现实生活,泾渭分明的概念只存在于那些教授们的理想中。
如果感兴趣可以参考 RFC 3305,这是一个 Infomational RFC,就是试图解释这几个概念,并向社区作出使用建议。
URL
URL (统一资源定位符) = 协议://认证信息@主机名:端口号/路径?查询字符串#片段
协议必须是在 IANA 注册的合法 URI scheme。
我们最熟悉的是 HTTP URL,协议是 http 或者 https,除此之外还有其他的 IANA 批准的协议,比如:
mailto:<address>[?<header1>=<value1>[&<header2>=<value2>]]
imap://[<user>[;AUTH=<type>]@]<host>[:<port>]/<command>
git://github.com/user/project-name.git
file://[host]/path or file:[//host]/path
view-source:<absolute-URI>
URN
URN (统一资源名称) is 资源名称(唯一标识),格式:urn:<NID>:<NSS>
urn 就是 IANA 注册的众多 URI scheme 之一。
-
这个命名空间标识 NID 也需要在 IANA 注册。
-
urn:isbn:0451450523
urn:ietf:rfc:2648
实际上,我好像没有见过什么地方在使用 URN,更别提设想中的统一资源属性 URC 了。
就好比上面提到的两个例子,ISBN: 0451450523,RFC 2648,直接这么写就是了,按照 RFC 定义写成标准的那一串实在是没见过。
总结
URL 是 URI 中的因特网部分,用来指示网络资源位置。
Python 示例
import urllib.parse
a = urllib.parse.urlunparse('http', 'user:pass@example.com:8080', '/path', 'param1=a', 'a=1&b=2', 'Title')
# 'http://user:pass@example.com:8080/path;param1=a?a=1&b=2#Title'
b = urllib.parse.urlparse(a)
b.scheme # 0 'http'
b.netloc # 1 'user:pass@example.com:8080'
b.path # 2 '/path'
b.params # 3 'param1=a'
b.query # 4 'a=1&b=2'
b.fragment # 5 'Title'
b.username # 'user'
b.password # 'pass'
b.hostname # 'example.com'
b.port # 8080
print(b[2]) # '/path'
b = urllib.parse.urlparse(('pymysql+mysql://root:111111@1.1.1.1:3306/xiaorui_master?charset=utf8mb4'))
print(repr((b.scheme, b.netloc, b.path, b.params, b.query, b.fragment, b.username, b.password, b.hostname, b.port)))
('pymysql+mysql', 'root:111111@1.1.1.1:3306', '/xiaorui_master', '', 'charset=utf8mb4', '', 'root', '111111', '1.1.1.1', 3306)
参考资料与拓展阅读
个人 开发者
2021-09-19
比如:Tornado 框架的 stars 数量:
、
,再比如说这种:
外国人真是会玩,总有这样的好点子,在有限的环境(Markdown)中也能弄的丰富多彩的。
上面都是用的 shields.io 提供的服务,它内置了很多种类的图标,GitHub 关注数、Fork 数、Star 数、协议,Twitter 关注数、NPM 包大小、PyPI 下载数量等等,这些看他们官网提供的示例,照着用就是了。
还有一种,就是用户定制接口,格式:
- Static:URLPath
https://img.shields.io/badge/<LABEL>-<MESSAGE>-<COLOR>
- Static:QueryString
https://img.shields.io/static/v1?label=<LABEL>&message=<MESSAGE>&color=<COLOR>
- Endpoint
https://img.shields.io/endpoint?url=<URL>&style<STYLE>
- Dynamic
https://img.shields.io/badge/dynamic/json?url=<URL>&label=<LABEL>&query=<$.DATA.SUBDATA>&color=<COLOR>&prefix=<PREFIX>&suffix=<SUFFIX>
还有好多更加细致的规则,用来定制自己的图标,就不细说了,自己看文档就行。
其实我用的多的还是上面的第一种接口,因为它比较简单,只要把 label 和 message 修改就可以了。
https://img.shields.io/badge/site-markjour.com-brightgreen.svg?style=plastic&logo=nginx

https://img.shields.io/badge/-doing-green

参考资料与拓展阅读