利用wireshark分析github连接超时

事件描述

---

最近为了做一些管理后台相关的东西，想了解一下前端的一些东西(后端狗也有一颗全栈的心啊O(∩_∩)O)，经过调研最终决定使用vue2加上饿了么开源的element-ui。因为不想每天背公司的电脑回家，于是决定在自己家里也搭建一套开发环境。

按照官方文档一阵鼓捣，终于要npm install了，结果进度条读了半天，来了句：cannot connect to github.com,timeout....！！！！！尼玛我爬过了千坑万水，终于要看到胜利的曙光，踏上成为全栈工程师的金光大道了你告诉我无法连接到github？？？难道是我办了假的电信宽带么？？？

如果我是一只前端汪，或许我会立马打电话给电信客服骂他们个狗血淋头，或者洗洗睡了期待第二天有奇迹发生，然而我不服！！！我要证明我每年给电信交几千块而不是办个坑爹的长城宽带是物有所值的，所以我掏出了神器wireshark，准备抓个包，看看timeout的原因，期待会有奇迹发生。

抓包结果

---

作为一个后端狗，我和小姑娘们有一个共同的爱好，那就是看包：用Charles抓客户端和服务器交互的http包和前端撕逼，或者是在服务器上用tcpdump抓包试图把锅甩给别人。

废话了半天，先来看看抓包的结果：

wireshark抓包结果

这就奇了怪了，我向github连续发了7次syn，结果github完全没有鸟我。约妹子几次约不出来人家都知道找个借口继续风筝我一下，你一个破网站这找你握手找了7次你为啥连个屁都不放呢？

再仔细看一下，发现了一个可疑的地方：

TSVal

这个是什么呢？点开包的详情看一下，发现原来我的电脑开启了tcp_timestamp：

timestamp

关于tcp_timestamp，这里就不仔细分析了，感兴趣的可以看看这里，总结一下就是如果服务器开启了tcp_tw_recyclehe tcp_timestamps，那么要求60s内同一源ip主机的socket connect请求中的timestamp必须是递增的，而我家里有2台电脑，另外一台也一直在访问github，两台电脑是经过NAT连接到网络的，在github看来我就是同一个ip，所以丢弃了timestamp没有递增的包，所以我们才会看到连续7个syn包都没有收到任何回复。关闭计算机的tcp_timestamp，重新尝试了一下npm install，终于成功的安装了所依赖的包。

总结

---

在平时的工作中，包括后端同学在内的很多人都觉得没必要了解操作系统和计算机网络的相关知识，毕竟各种框架已经帮我们做好了封装，似乎我们需要做的就是学会框架，然后了解业务，做出符合需求的产品，但是上面这个例子告诉我们，多了解一点相对底层的东西，还是会对我们的工作和学习有所帮助的，如果我不知道tcp是什么，或者不会用wireshark、tcpdump之类的工具抓包，很可能就会花整晚的时间解决一个开发环境搭建的问题。