因为最近对网络传输层协议进行了一番调研，对当代互联网的基础设施有了全方位的立体认识，当然也包括科学上网的传输原理。这里就具体讲一讲我对科学上网之科学性有何新认识。其实很多内容都是老生常谈，但是我希望补充一点视角。

首先谈论一下一些定义，诸如“机场”，“起飞”，“落地”，“中转”，“入口”，“出口”等概念。（补充）

已经被广泛讨论的好处

提升至传输层的好处

  1. 常常提及的一点是DNS从本地移到了落地侧进行。
  2. 更好的路由，直连避免绕路。
  3. 更好的链路（CN2,CMI,IPLC等），避免丢包。

TCP层面的优化

实际上机场还做了一件事情，就是把单个TCP连接分成多个串联的TCP连接。这种方式改变了原来连接的端到端特性，带来了以下潜在好处：

  1. 如果假设每一跳丢包概率独立，那么原来的单个TCP的连接的丢包率是现在每个参与串联的TCP连接丢包概率的乘积。也就是说，每个单一的TCP连接的丢包概率更小了。
  2. 每个TCP连接有更小的RTT，这使得反馈控制更加高效，重传、速率恢复都更加及时。
  3. 由于两头设备的TCP协议栈通常无法修改，这种方式减小了两头TCP流控对整个传输的影响，机场方可以着重优化中间这段的TCP。

下面的这个实验可以验证TCP分段的机制。 首先，以下拓扑是通常上网的流程：

本地设备 ------TCP------ 远端服务

使用机场后TCP至少会分成两段进行，这是因为机场通常提供的是加密TCP代理服务，本地连接机场的实际上是一个代理协议的TCP连接，而机场到远端是被代理的实际TCP链接，这两个TCP连接自然不是同一个。常见的中转型机场更是把传输层分成了三段，即下图的情况：

本地通常用诸如SS协议

本地设备 --TCP-- 机场入口 ---- 机场出口 --TCP-- 远端服务

我们可以通过测量RTT的方式来进行验证。第一段RTT可以通过tcping来进行测量，计为RTT1。最后一段RTT可以通过在远端运行iperf3程序，然后查看测算出的TCP RTT数值，计为RTT2。如果RTT1+RTT2与本地到远端的距离相符，那么我们可以视为两段TCP；如果RTT1+RTT2显著小于上述距离，则中间还有一段TCP是隐藏的。隐藏的TCP通常是机场入口到机场出口的专线连接。

我们在深圳向华南的机场入口进行tcping测试，得到RTT1大约是10ms左右:

➜  ~ tcping hidden.domain.here yyyyy
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 26.977ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 13.107ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 11.418ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 16.292ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 10.029ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 11.629ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 31.357ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 11.012ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 35.704ms
hidden.domain.here:yyyyy has address: xxx.xxx.xxx.xxx:yyyyy - Connected - 69.483ms
Ping statistics hidden.domain.here:yyyyy
    10 probes sent.
    10 successful, 0 failed.
Approximate trip times:
    Minimum = 10.029ms, Maximum = 69.483ms, Average = 23.701ms

我们在本地通过iperf3使用代理连接位于日本大阪的iperf3服务器，命令如下：

iperf3 -c XXX.XXX.XXX.XXX -p 12345 -R

当使用机场东京的节点时，远端iperf3显示结果如下，可以看到此时RTT2也为10ms左右：

root@unknown:~/iperf-3.11# iperf3 -s --json -p 12345 | grep rtt
					"rtt":	8014,
					"rttvar":	237,
					"rtt":	21207,
					"rttvar":	20504,
					"rtt":	16051,
					"rttvar":	14332,
					"rtt":	20545,
					"rttvar":	19737,
					"rtt":	21202,
					"rttvar":	20611,
					"rtt":	21202,
					"rttvar":	20611,
					"rtt":	20911,
					"rttvar":	19984,
					"rtt":	20911,
					"rttvar":	19984,
					"rtt":	20645,
					"rttvar":	19614,
					"rtt":	7945,
					"rttvar":	95,
					"rtt":	7990,
					"rttvar":	144,
					"max_rtt":	21207,
					"min_rtt":	7945,
					"mean_rtt":	16965,

显然这说明到远端服务器的TCP是从机场出口开始的而非机场入口。作为验证我们又使用机场香港节点进行相同测试，远端iperf3结果如下：

root@unknown:~/iperf-3.11# iperf3 -s --json -p 12345 | grep rtt
					"rtt":	57932,
					"rttvar":	36,
					"rtt":	73185,
					"rttvar":	24815,
					"rtt":	75732,
					"rttvar":	24646,
					"rtt":	71160,
					"rttvar":	17239,
					"rtt":	80564,
					"rttvar":	26611,
					"rtt":	86339,
					"rttvar":	31206,
					"rtt":	78852,
					"rttvar":	26721,
					"rtt":	83994,
					"rttvar":	30324,
					"rtt":	80714,
					"rttvar":	28751,
					"rtt":	61555,
					"rttvar":	7384,
					"rtt":	71581,
					"rttvar":	21469,
					"max_rtt":	86339,
					"min_rtt":	57932,
					"mean_rtt":	74691,

即此时的RTT2是65ms左右，与香港到大阪的延迟相符。