抓了个包，发现日本也有···
大家好，我是轩辕。
前几天，有位国外的粉丝遇到了一个网络问题，发现访问不了国内的某个网站。这让我想起三年前的一个事情，跟他的情况类似。
当时这篇文章有点敏感，发了不到半个小时就删掉了，估计有很多人都没看到过。今天我做了修改，大家可以看下。
当时的情况是这样的：
总结：人在日本，开着WIFI访问不了极客时间，为啥？
随后她还给我转发了一张浏览器的截图：
我一下发现了不对劲，请注意这几个字：
如果是我们的请求到不了服务器造成的无法访问，一般是这样提示的：
或者请求能够到达服务器，但服务器拒绝访问，一般是这样提示的：
而连接被重置，事情就不简单了。
接下来，我让这位在日本的朋友装上了抓包神器wireshark，想抓一下网络通信，看看到底发生了什么。
先看一下这位朋友的机器上，ping一下极客时间官网的域名，得到的IP地址：
这是一个阿里云的服务器，在抓到的网络通信中，我看到了浏览器发起了多次的请求尝试连接，下面每一行都是一个会话：
点开一个来看看，TCP的三次握手是正常的，服务器能够正常返回握手包，说明服务器是能够访问的，443端口也是能触达的：
因为是443端口，HTTPS，按照协议规定，三次握手之后，接下来，客户端该发起SSL握手了，但诡异的事情就发生了，客户端刚刚发出了SSL的握手包，服务器就返回了一个RST报文：
好家伙，这下知道为什么显示连接被重置了吧。
什么是RST包？
RST，就是ReSet，重置的意思，在《TCP/IP详解·卷一》中有提到：
一般来说，当发现一个到达的报文段对于相关连接而言是不正确的时, TCP就会发送一个重置报文。
并且列举了在这几种情况下，会发送RST包：
1.端口不存在
当向一台计算机未开放的端口发起连接请求，对方就会返回一个RST包。
很明显，这位朋友的电脑不属于这种情况，否则在第一次握手时，服务器也不会返回正常的握手包了。
2.终止一条连接
终止一条连接的方式，正常情况下，就是咱们熟知的四次挥手，通过发送FIN包关闭连接。
但有正常，就有不正常，RST同样可以用来终止一条连接。而与FIN不同的是，FIN是会等排队等待发送的数据全部发出去后，才会被发送，以保证数据不会丢失。而RST是不用等待排队数据发送，立即发给对方，等待发送的数据将被全部丢弃。
3.时间等待错误
TCP有一系列的计时器用来完成超时重传以及连接状态的维护等工作，但如果超过定时器的时间，服务器已经清除了一条连接的信息，在这之后，客户端新的数据才姗姗来迟，那这时候，也会收到一个RST报文。
很显然，这位朋友的电脑也不是这种情况，三次握手完成之后，便立即发起了SSL握手，没有理由超时。
那问题就来了，服务器为什么要返回一个RST包呢？
直到我看到了接下来的通信，我悟了：
发现了吗，就在返回了RST包之后，服务器后续竟然还在与客户端进行SSL握手（就是图中黄色的那根箭头，服务器返回的Hello证书）！！！
不仅如此，在客户端这边因为收到RST已经关闭连接没有反应之后，服务器还在一直尝试重传：Hello，证书来了，听到请回答，听到请回答！
顺便可以注意下TCP重传时间的变化，符合2倍增长的规律：
到底是谁发出的这个RST呢？
后面的不能再写了，就这样吧···