nltk 是 Python 下一个自然语言处理相关的库，可以方便的实现分词，词性标注等等。

安装

pip install nltk

然后在终端执行 python， 进入交互式编辑环境

>> import nltk
>> nltk.download()

下载相关模块

分词

nltk.sent_tokenize(text) #对文本按照句子进行分割

nltk.word_tokenize(sent) #对句子进行分词

词性标注

nltk.pos_tag()

词形还原

from nltk.stem import WordNetLemmatizer
lemmatizer = WordNetLemmatizer()
lemmatizer.lemmatize(word)

reference

• https://blog.csdn.net/a18852867035/article/details/54134281

frp 是中国开发者 fatedier 的作品，frp 是一个高性能的反向代理应用，可以帮助您轻松地进行内网穿透，对外网提供服务，支持 tcp, udp, http, https 等协议类型，并且 web 服务支持根据域名进行路由转发。

frp用法和ngrok相似，但是frp比ngrok更加优秀。 配置过程很简单，但是也遇到一些问题，所以把过程记录下来。

frp 作用

• 利用处于内网或防火墙后的机器，对外网环境提供 http 或 https 服务。
• 对于 http, https 服务支持基于域名的虚拟主机，支持自定义域名绑定，使多个域名可以共用一个80端口。
• 利用处于内网或防火墙后的机器，对外网环境提供 tcp 和 udp 服务，例如在家里通过 ssh 访问处于公司内网环境内的主机。

frp 配置

frps.ini 服务端配置：

[common] 
bind_port = 7000

frpc.ini 客户端配置

[common] 
server_addr = x.x.x.x   # 填写公网服务器IP地址
server_port = 7000 

[ssh-computer-name] 
type = tcp 
local_ip = 127.0.0.1 
local_port = 22 
remote_port = 6000 #配置服务器端口

然后使用 ssh user@x.x.x.x -p 6000 或者 ssh -o Port=6000 user@x.x.x.x 来连接内网的机器。

再配置完之后可以使用 supervisor 来管理，实现进程死掉后自动重启。

reference

• https://github.com/fatedier/frp/blob/master/README_zh.md

Git 作为分布式版本控制系统，所有修改操作都是基于本地的，在团队协作过程中，假设你和你的同伴在本地中分别有各自的新提交，而你的同伴先于你 push 了代码到远程分支上，所以你必须先执行 git pull 来获取同伴的提交，然后才能 push 自己的提交到远程分支。而按照 Git 的默认策略，如果远程分支和本地分支之间的提交线图有分叉的话（即不是 fast-forwarded），Git 会执行一次 merge 操作，因此产生一次没意义的提交记录。

在 pull 操作的时候，使用 git pull --rebase 选项即可很好地解决上述问题，使用 -r 或者 --rebase 的好处是，Git 会使用 rebase 来代替 merge 的策略。

使用 man git-merge 中的示例图说明：

             A---B---C  remotes/origin/master
            /
       D---E---F---G  master

如果执行 git pull 之后，提交线是：

             A---B---C remotes/origin/master
            /         \
       D---E---F---G---H master

结果是多出了 H 这个 无意义的提交。如果执行 git pull -r 的话，提交就是：

                   remotes/origin/master
                       |
       D---E---A---B---C---F'---G'  master

本地的两次提交就使用 rebase 重新添加到了远端的提交之后，多余的 merge 无意义提交消失。

在了解 git pull -r 的前提下，来看一下如何使用 rebase 命令来将本地的多个提交合并为一次提交。

假设本地 Git 仓库中因为临时提交产生了一些 commits

commit 8b465db3672a24710207d91af74d61cee975b208
Author: Ein Verne
Date:   Thu Nov 30 20:25:52 2017 +0800

    Third commit

commit 821476d2b043e85d131483279e23778aa3fd1241
Author: Ein Verne
Date:   Thu Nov 30 14:07:08 2017 +0800

    Second commit


commit 51912266c1634dd2f0848071cc311975b6aad730
Author: Ein Verne
Date:   Thu Nov 23 20:39:42 2017 +0800

    Init commit

假设我们需要将第二次提交 821476d2b043e85d131483279e23778aa3fd1241 和 第三次提交 8b465db3672a24710207d91af74d61cee975b208 合并为一次提交，可以先使用

git rebase -i 5191226

最后一次不需要修改的 commit id，然后进入 vi 的提交信息的编辑模式。

pick 821476d Second commit
pick 8b465db Third commit

# Rebase 5191226..8b465db onto 5191226 (2 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

这里可以看到，上方未注释部分填写要执行的命令，下方注释部分为支持的指令说明。指令部分由命令，commit hash 和 commit message 组成。

这里

• pick 为选择该 commit
• squash 是这个 commit 会被合并到前一个 commit
• edit 选中提交，rebase 暂停，修改该 commit 提交内容
• reword 选中提交，并修改提交信息
• fixup 与 squash 相同，但不会保存当前 commit 的提交信息
• exec 执行其他 shell 命令
• drop 抛弃提交

这里只要将第三次提交前的 pick 修改为 squash，就可以将该 commit 合并到第二次提交。修改之后保存 :wq 退出。

pick 821476d Second commit
squash 8b465db Third commit

然后会进入 commit message 界面，在该界面中修改合适的提交信息，将两次的 commit 合并为一次，保存退出即可完成合并。

注意：git rebase 是一个比较危险的命令，如果一旦中途出现错误，可以使用 git rebase --abort 来终止 rebase，回到没有合并之前的状态。

TIPS

合并本地多次提交

如果想要合并最近的多次提交，在 rebase 进入交互模式时，可以指定范围比如

git rebase -i HEAD~8

选取最近的 8 次提交。

更换本地提交的顺序

在进入 rebase -i 交互模式时，更换提交信息的顺序，保存即可修改本地提交的 commit 顺序。比如

pick 821476d Second commit
pick 8b465db Third commit

修改为

pick 8b465db Third commit
pick 821476d Second commit

可以更换次序。

注意

git rebase 操作应该只用于本地尚未提交到远程仓库的 commit，一旦 push 到远端仓库，则不再允许修改 commit，否则可能会给其他开发者带来很多麻烦。尤其是多人协作时，千万要注意。

reference

• http://hungyuhei.github.io/2012/08/07/better-git-commit-graph-using-pull---rebase-and-merge---no-ff.html

Linux 下按照正则过滤文本的命令 grep 非常强大，grep 能够把正则匹配的行打印出来。而 zgrep 则能够对压缩包内容进行正则匹配。zgrep 全称是 search compressed files for a regular expression

grep 的命令格式是

grep [option] pattern files

他的工作方式是，在一个或者多个文件中根据正则搜索匹配内容，将搜索的结果输出到标准输出，不更改源文件内容。

grep 常用的一些选项

-i   忽略字符大小写区别
-v   显示不包含正则的所有行

关于更多的 grep 的内容可以参考另外一篇文章，zgrep 和 grep 用法类似，不过操作的对象是压缩的内容。支持 bzip2，gzip，lzip， xz 等等。

zgrep 使用

但如果想要过滤 Nginx 的 access_log.gz 的压缩文件的内容，如果先解压，然后过滤出有用的文本，再把文件压缩回去，这就变的非常不方便。

gunzip access_log.gz
grep "/api" access_log
gzip access_log

需要使用三个命令来实现文件的过滤，其实 Linux 下可以使用 zgrep 来一步完成

zgrep "/api" access_log.gz

和 grep 类似， zgrep 也可以指定多个文件同时进行搜索过滤

zgrep "/api" access_log.gz access_log_1.gz

延伸

既然提到了不解压搜索压缩包内容，.gz 的文件可以使用 zgrep ，而对于 .tar.gz 文件

zcat access.tar.gz | grep -a '/api'
zgrep -a "/api" access.tar.gz

其实这些带 z 的命令都包含在 Zutils 这个工具包中，这个工具包还提供了

zcat  解压文件并将内容输出到标准输出
zcmp  解压文件并且 byte by byte 比较两个文件
zdiff 解压文件并且 line by line 比较两个文件
zgrep 解压文件并且根据正则搜索文件内容
ztest - Tests integrity of compressed files.
zupdate - Recompresses files to lzip format.

这些命令支持 bzip2, gzip, lzip and xz 格式。

jhead 是一个可以查看，修改照片 EXIF 信息的命令行工具，没有 GUI。

jhead 可以查看：

• Time and date picture was taken
• Camera make and model
• Integral low-res Exif thumbnail
• Shutter speed
• Camera F-stop number
• Flash used (yes/no)
• Distance camera was focused at
• Focal length and calculate 35 mm equivalent focal length
• Image resolution
• GPS info, if stored in image
• IPTC header
• XMP data

jhead 可以修改：

• Up-right images according to rotation tag using jpegtran
• Set or relative adjust internal exif timestamps
• Fix date / time offsets in large batches of images
• Re-name or date stamp files according to exif timestamp
• Transfer exif headers between images
• Replace thumbnails inside Exif headers
• Edit jpeg comments (but not the Exif comments)
• Delete exif or comment sections from jpeg images
• Create new minimal exif header containing date and thumbnail

installation

sudo apt install jhead

usage

jhead 的使用官方网站 有着非常详细的说明，这里只挑重点。

查看

jhead demo.jpg
jhead -v demo.jpg

将 EXIF 信息保存到文本

jhead -v demo.jpg > exif.txt

设置 comment

jhead -cl <comment> path/to/file.jpg
jhead -ce file.jpg          # 执行命令后会调用外部编辑器，保存内容到 comment
jhead -cs <output-filename> file.jpg        # 将 comment 内容保存到 output-filename
jhead -ci <input-filename> file.jpg         # 将 input-filename 中的内容保存到照片 comment

删除信息

jhead -dc 删除 jpg 信息备注
jhead -de 完全删除 EXIF
jhead -du 删除非原始信息，比如 PS 携带的额外信息
jhead -purejpg      相当于 -dc -de -du
jhead -di 删除 IPTC 信息
jhead -dx 删除 XMP 信息

其实命令行工具最大的作用就是批处理，用正则，可以同时处理非常多的文件。

其他

更强大的工具 exiftool

如果寻找编程接口 可以查看 libexif 或者 exifv2

reference

• http://www.sentex.net/~mwandel/jhead/

在熟悉 Vim 基本的 yy (yank current line) 和 p (paste) 的操作前提下，如果现在 Vim 中批量的移动某一些行，或者批量的复制从第 50 行到100 行到第200行后面，以我们之前的知识，可以先跳转到第 50 行 (:50)，然后进入 行选择模式 (V) ，往下选择 50 行 (50j)，然后再对选中的 50 行进行复制操作 (y)，然后再移动到 200 行 (:200) 粘贴 (p)。

计算一下，从选择到复制，上面的操作可以划分为 5 个步骤，需要敲击 :50V50jy:200p ，当然上面的例子只是一个极端的例子，一般这样的需求也不大可能会出现。而如果有命令可以直接拷贝某些行，那么就不需要这么复杂，Vim 提供了整行的复制和移动命令。

:[range]copy {address}

copy 命令， range 表示拷贝的范围，行号范围， address 表示要拷贝到的地方，比如上面的例子就可以使用 :50,100copy200 来完成。

copy 命令可以简写成 :co 或者 :t 。

几个常用的格式：

:t5   拷贝当前行到第5行的下一行
:t.   拷贝当前行到光标下一行，相当于 `Yp` 或者 `yyp`
:t$   拷贝当前行到文件最后一行
:'<,'>t0   拷贝选取的区域到文件开头，在 Visual 模式下选中文本，输入 `:`，再输入 `t0`

move 命令也和 copy 一样

:[range]m[ove] {address}	

这里只是将拷贝，换为移动。

可以通过 :help copy 和 :help move 来查看帮助

快速选择行

遇到一个操作，比如在一个非常大的文件中，需要快速的选择 1000 行到 4500 行，那么可以用下面的方法快速选择。

方法一

• 使用 :1000 快速移动到 1000 行
• 行选择 V4500G 快速从当前行选择到 4500 行(包括)

G Goto line [count]

方法二

• 使用 :1000 移动到 1000 行，然后按下 m + a，标记 a
• 然后 :4500 移动到 4500 行，按下 V + \` + a 选择

方法三

• 使用 :1000 移动到 1000 行，然后按下 V
• 然后输入 3500j 向下移动 3500 行

这是 《精通正则表达式》第 3 版 的读书笔记。

技术图书的主要使命是传播专业知识，专业知识分为框架性知识和具体知识。框架性知识需要通过系统的阅读和学习掌握，而大量的具体知识，则主要通过日常生活的积累以及随用随查的学习来填充。

完整的正则表达式由两种字符构成，特殊字符，元字符，另外一种就是普通文本字符。

完整的正则表达式由小的构建模块单元 building block unit 构成，每个单元都很简单，不过他们能够以无穷多种方式组合，所以可以提供无限的可能。

字符组

匹配若干字符之一，使用中括号 [ea] 匹配 a 或者 e

gr[ae]y 表示匹配 gray 或者 grey

其他元字符

量词，定义了元素可以发生的频率

正则表达式可以使用多个括号，使用 \1, \2, \3 等来匹配括号的内容

([a-z])([0-9])\1\2 其中的 \1 代表的就是 [a-z] 匹配的内容，而 \2 就代表 [0-9] 匹配的内容

匹配引号内的字符串

"[^"]*"

两端引号用来匹配字符串开头和结尾的引号，中间 [^"] 用来匹配除引号之外的任何字符，* 用来表示任意数量的非引号字符

匹配 URL

grep, 和 egrep 的历史

正则表达式的流派

正则表达式的处理方式

集成式

Perl 中的例子

if ($line =~ m/^Subject: (.*)/i) {
    $subject = $1
}

取邮件标题的正则，内建在程序内，隐藏了正则表达式的预处理，匹配，应用，返回结果，减轻了常见任务的难度。

程序式处理和面向对象式处理

由普通函数和方法来提供

Java 中处理正则，Sun 提供了 java.util.regex 包来在 Java 中更加方便的使用正则。

import java.util.regex.*;

Pattern r = Pattern.compile("^Subject: (.*)", Pattern.CASE_INSENSITIVE);
Matcher m = r.matcher(line);
if (m.find()) {
    subject = m.group(1);
}

Perl 隐藏了绝大部分细节， Java 则暴露了一些正则的细节，编译正则表达式到 Pattern 对象，将正则和匹配的文本联系到一起，得到 Matcher 对象，在应用正则之前，检查是否存在匹配，返回结果，如果存在匹配，则捕获括号内的子表达式文本。

Java 也提供了函数式处理的例子， Pattern 类提供了静态方法

if (! Pattern.matches("\\s*", line)) {
    // 如果 line 不是空行
}

函数包装一个隐式的正则表达式，返回一个 Boolean。

Sun 也会把正则表达式整合到 Java 的其他部分，比如 String 类中 matches 函数

if (! line.matches("\\s*")) {
    // line 不为空行
}

String 中的方法不适合在对时间要求很高的循环中使用。

Python 中的处理， Python 也使用面向对象的方法

import re

r = re.compile("^Subject: (.*)", re.IGNORECASE)
m = r.search(line)
if m:
    subject = m.group(1)

这个例子和 Java 中的非常类似。

正则匹配规则

优先选择最左端匹配结果

从左往右匹配，左侧的结果优先于右侧

标准量词优先匹配

标准量词 ?, *, +, {m,n} 都是优先匹配 greedy 的。例如 a? 中的 a ，[0-9]+ 中的 [0-9]，在匹配成功之前，进行尝试的次数是有上限和下限的，规则 2 表明，尝试总是获得最长的匹配。

标准匹配量词的结果可能并非所有可能中最长的，但是它们总是尝试匹配尽可能多的字符，直到匹配上限为止。如果最终结果并非该表达式的所有可能中最长的，原因肯定是匹配字符过多导致匹配失败。

举例， \b\w+s\b 来匹配包含 s 的字符串，比如 regexes ，\w+ 完全能够匹配整个单词，但如果 \w+ 来匹配整个单词 s 就无法匹配，为了完成匹配， \w+ 必须匹配 regexes ，最后把 s\b 留出来。

NFA 称为“表达式主导”引擎，对应的 DFA 称为 “文本主导” 引擎。

NFA 引擎

NFA 引擎中，每一个子表达式都是独立的，子表达式之间不存在内在的联系，子表达式和正则表达式的控制结构（多选分支、括号以及匹配量词）的层次关系控制了整个匹配过程。NFA 引擎是正则表达式主导，编写正则的人有充分的机会来实现期望的结果

DFA 文本主导

DFA 在扫描字符串时，会记录“当前有效”的所有匹配。比如正则

to(nite|knight|night)

来匹配文本

after ... tonight ...

对比

一般情况下，文本主导的 DFA 引擎要快一些，NFA 正则表达式引擎，因为需要对同样的文本尝试不同的表达式匹配，可能会产生不同的分支浪费时间。

NFA 匹配的过程中，目标文本中的某个字符串可能会被正则表达式中不同部分重复检查。相反，DFA 引擎是确定性，目标文本中的每个字符只会检查一遍。

这两种技术，都有对应的正式名字：非确定型有穷自动机 NFA，和 确定型有穷自动机 DFA。

正则引擎的分类

粗略分为三类

• DFA 符合或者不符合 POSIX 标准的都属于此类
• 传统 NFA
• POSIX NFA

部分程序及其所使用的正则引擎 引擎 | 程序 ————–|————- DFA | 大多数版本的 awk, egrep， flex, lex, MySQL 传统型 NFA | GNU Emacs, Java, 大多数版本的 grep, less, more, .NET ，Perl， PHP，Python， Ruby， 大多数版本的 sed, vi POSIX NFA | mawk, GUN Emacs 明确指定时使用 DFA/NFA 混合 | GNU awk, GNU grep/egrep, Tcl

实用技巧

匹配 IP 地址

匹配 IPv4 的地址，用点号分开的四个数组，0-255

[01]?[d\d?|2[0-4][d|25[0-5]

这个表达式能够匹配 0 到 255 之间的数，然后重复 4 遍。这样这个表达式会异常复杂，通常情况下，更合适的做法是不依赖正则完成全部的工作，使用

^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\$

来匹配，然后将匹配的数字拿出来，使用其他程序来进行验证。

匹配堆成括号

匹配括号的内容，或许会想到 \bfoo\([^)])

为了匹配括号

`(.*)`    括号及括号内任何字符
`([^)]*)`  从一个开括号到最近的闭括号
`([^()]*)` 从一个开括号到最近的闭括号，但是不容许其中包含开括号

对于文本

var = foo(bar(this), 3.7) + 2 * (that - 1);

第一个正则会匹配 (bar(this), 3.7) + 2 * (that - 1) ， 而第二个正则表达式只会匹配 (bar(this) , 而第三个表达式能够匹配 (this) ，但是如果想要匹配 foo 后面的括号，则无能为力，所以三个表达式都不合格。

Java 正则

通过 java.util.regex 使用正则非常简单，一个接口一个 exception

java.util.regex.Pattern
java.util.regex.Matcher
java.util.regex.MatchResult
java.util.regex.PatternSyntaxException

通过 Pattern 构造编译正则表达式，通过正则匹配构建 Matcher 对象。

优化 Java 正则表达式

Java 的正则对性能影响非常大，如果在程序中大量使用正则，一定要对正则进行一定优化。

• 多次使用同一个正则，Pattern.compile() 预先编译正则表达式

• 选择 （X

  Y

  Z） 会显著降低正则的匹配速度，优先考虑 ac(cd

  ef) 而不是 (abcd

  abef)

• 如果不需要分组内文本，尽量使用非捕获分组

reference

常用的 ping，tracert，nslookup 一般用来判断主机的网络连通性，其实 Linux 下有一个更好用的网络联通性判断工具，它可以结合ping nslookup tracert 来判断网络的相关特性，这个命令就是 mtr。mtr 全称 my traceroute，是一个把 ping 和 traceroute 合并到一个程序的网络诊断工具。

traceroute默认使用UDP数据包探测，而mtr默认使用ICMP报文探测，ICMP在某些路由节点的优先级要比其他数据包低，所以测试得到的数据可能低于实际情况。

安装

Debian/Ubuntu/Linux Mint 下

sudo apt install mtr-tiny
sudo apt install mtr    # with GUI

使用

简单使用，查看本地到 google.com 的路由连接情况：

mtr google.com

输出参数解释：

• 第一列是IP地址
• 丢包率：Loss
• 已发送的包数：Snt
• 最后一个包的延时：Last
• 平均延时：Avg
• 最低延时：Best
• 最差延时：Wrst
• 方差（稳定性）：StDev

参数说明

report

使用 mtr -r google.com 来打印报告，如果不使用 -r or --report 参数 mtr 会不断动态运行。使用 report 选项， mtr 会向 google.com 主机发送 10 个 ICMP 包，然后直接输出结果。通常情况下 mtr 需要几秒钟时间来输出报告。mtr 报告由一系列跳数组成，每一跳意味着数据包通过节点或者路由器来达到目的主机。

一般情况下 mtr 前几跳都是本地 ISP，后几跳属于服务商比如 Google 数据中心，中间跳数则是中间节点，如果发现前几跳异常，需要联系本地 ISP 服务提供上，相反如果后几跳出现问题，则需要联系服务提供商，中间几跳出现问题，则两边无法完全解决问题。

packetsize

使用 -s 来指定ping数据包的大小

mtr -s 100

100 bytes 数据包会用来发送，测试，如果设置为负数，则每一次发送的数据包的大小都会是一个随机数。

指定发送数量

默认使用 -r 参数来生成报告，只会发送10个数据包，如果想要自定义数据包数量，可以使用 -c 参数

mtr -c 100 google.com

不进行主机解释

使用 -n 选项来让 mtr 只输出 IP，而不对主机 host name 进行解释

mtr -n github.com

延伸

在晚上或者 VPS 交流的时候经常能看到别人用可视化的方式展示路由跳转，其实都是使用的 best trace 这样一个软件。

官网地址: https://www.ipip.net/download.html

对于 Windows，Mac 和 Android 页面上都有相应的GUI客户端，Linux 下可使用命令行：

wget http://cdn.ipip.net/17mon/besttrace4linux.zip
unzip besttrace4linux.zip
chmod +x besttrace32
sudo ./besttrace -q 1 www.google.com

如果下载地址失效了，去官网上找最新的即可。

reference

• http://www.bitwizard.nl/mtr/

Instagram 在他的API文档和网站地址栏中对同一个 Post，使用了两种不一样的ID。在他们的 API 文档中，ids 类似于 908540701891980503_1639186 ， 但是在网站浏览器中则使用的是 ybyPRoQWzX 这样的ID。如果查看几组 ids，能够确性这两种类型的 ids 之间存在关联，Instagram 内部也不可能为同一个帖子存储两套 ids。

在仔细看一下数字的ID，908540701891980503 显然下划线分割的后面为作者的id，前面18位的id 被转为 ybyPRoQWzX 10 位的长度。URL 中的ID信息的密度显然要比数字的id要高。

如果做一个测试，将数字id由base10转为 base64，就得到

9:0:8:5:4:0:7:0:1:8:9:1:9:8:0:5:0:3_10
50:27:50:15:17:40:16:22:51:23_64

这样两组数据，如果将 base64 的数组和10位的id比较，得到

如果对该映射重新排序，则得到

看到该映射，很容易联想到由 A-Z 和 a-z 的关系

这个表和标准 base64 的加密表几乎一致，除了将 + 和 / 变为了 - 和 _ 。这个变动大概因为 / 在URLs中是特殊字符，而 + 号在 URL 中是特殊的请求字符。

启示

知道了两种ids之间的关系，联系一些已知的事实可以知道

唯一性

Instagram 在全平台使用唯一的ID，在 Web 端是 https://instagram.com/p/ybyPRoQWzX , 而这个 ID 能够被转成数字ID，因此我们也知道这个 ID 也是唯一的。

更加惊奇的是数字ID也能够被用于请求 Instagram 内部的接口，比如查看 Instagram 网站的请求，可以发现请求特定用户的 Posts 的接口为

https://instagram.com/<username>/media/?max_id=<numeric id>

比如说 https://instagram.com/gitamba/media/?max_id=915362118751716223_7985735 而事实上，省略了后面的用户ID 也能更能够照样获得结果。而后面加任意内容都会被忽略

https://instagram.com/gitamba/media/?max_id=915398248830305252_whatever

这个请求的到内容和之前的内容一样。

进一步分析

如果知道 Instagram 产生 posts 的唯一ID 的原理 那么可以从 ID 中获取更多信息。在 Instagram 的文章中，没有提及内部的 epoch 是什么时候，但是可以通过计算来获取一个比较准确的值。

上面是三个已知发布时间的IDs， post 的id 是64bit ，如果转成 64 bits

截取前41bits，表示的从 Instagram 内部 epoch 开始流逝的时间，毫秒

最后在用创建post 的时间 unix time 来减去从 id 中获取的时间，得到

如果计算一切都正确，得到的值应该是相等的。微小的误差来自，创建 post 的时间是秒，而 id中获取的时间是毫秒。

经过一系列计算，大致可以知道 Instagram epoch 时间开始于 1314220021 ，也就是 9:07pm UTC on Wednesday, August 24, 2011 看起来是一个随机的 epoch，但猜测可能是 Instagram 内部将 id 由自增长模式转变为现在模式的时间。

ids for testing

翻译自： https://carrot.is/coding/instagram-ids

iperf 命令是一个网络性能测试工具。iperf 可以测试 TCP 和 UDP 带宽质量。iperf 可以测量最大 TCP 带宽，具有多种参数和 UDP 特性。iperf 可以报告带宽，延迟抖动和数据包丢失。利用 iperf 这一特性，可以用来测试一些网络设备如路由器，防火墙，交换机等的性能。

iperf 在内存中运行，不会涉及到文件系统。iperf 存在非常多的版本，Windows，Linux，Android，iOS 都有对应的版本。可以到官网下载

安装

Linux 下

apt-get install iperf

其他系统到参考官网

iperf 是一个命令行工具，当然如果搜索也能发现 GUI 的工具，比如 jperf, xjerf 等等。不过还是推荐使用命令行。

iperf 使用非常简单的 C/S 架构，client 使用 -c 服务端使用 -s。

实例

宽带测试通常采用 UDP 模式，首先以链路理论带宽作为数据发送速率进行测试，从客户端到服务器之间的链路理论带宽为 100 Mbps，先使用 -b 100M 测试，然后根据测试结果，以实际带宽测试

服务端：

iperf -u -s # UDP 模式

客户端第一种模式

iperf -u -c server_address -b 100M -t 60

在 UDP 模式下，以 100Mbps 为数据发送速率，客户端到 IP 上传带宽测试，测试时间 60 秒。

客户端同时发起 30 个线程连接，以 5Mbps 为数据发送速率

iperf -u -c server_address -b 5M -P 30 -t 60

或者客户端直接进行上下行带宽测试

iperf -u -c server_address -b 100M -d -t 60

如果不加 -u 则使用 TCP 模式

iperf -s

客户端持续 60 秒

iperf -c server_address -t 60

设置服务端端口

使用 -p port 来指定服务端端口，默认是 5201

间隔时间报告

使用 -i interval 参数来表示间隔时间

iperf -c 192.168.2.105(server address) -i 2

表示间隔 2 秒打印结果

iperf 版本区别

iperf 自身存在很多个版本，Ubuntu 默认源中可能有一个叫做 iperf, 也有一个叫做 iperf3, 这两个是不同版本的 iperf, 在使用 iperf 的时候要确保版本一致。不同的版本有不同的架构和不同的特性。

然而这两个版本 iperf3 是不兼容 iperf 2.x 的。可以这么理解 iperf 是内存中的网络性能测试工具，而 iperf3 是从头还是编写的一套新程序，目标是简化代码量，并且设计为工具库，可以嵌入到其他工具中。¹

两者不同的区别

服务端：

客户端：

iperf3 增加了一些额外的功能，比如 -i 模式可以提供 TCP retransit （中继）结果，并且 verbose 模式可以打印更多有效的信息，比如 CPU 利用率等等。

更多的使用可以参考这里

更多 iperf 2.0.5 和 iperf 2.0.8+ 和 iperf 3.1.5+ 的区别可以在这里 查看。

使用

外延

• 另外一个 TCP 性能测试工具 nuttcp

reference

• https://youtu.be/W9o7L-GWxNY
• http://man.linuxde.net/iperf