Ubuntu apt-get update 一直 0% 等待报头 waiting for headers

这个问题属实太烦了。上次也是遇到一次类似的问题。

先上结论，如果遇到这个问题，但是 curl 可以走通没问题，可能就是 mtu 的问题，一般可以用 ifconfig  来改 mtu，但是新版的 ubuntu 确实离谱，什么都没有，要安装 net-tools 又要 apt-get，经典鸡蛋问题。

 sudo ip link set mtu 1492 eth0

问题是今天用 Ubuntu apt-get update 准备安装一些编译内核的工具，然后他就一直卡着。换了好几个源和文明上网都没用。最后想起来是不是校园网拨号的问题。

现在的一般家用宽带、校园网都是走的 PPPoE，然后 PPPoE 的包要占用 8个 bytes。

链路上的 MTU 一般是 1500 （古早路由器交换机就支持 1500）.MTU一般也是设置为 1492 。有的可能默认是 1500. 之前我在 TCP 笔记里面写了这些东西：

• MTU 与 数据链路层：我们看 netstat -if  显示的 lo 的 MTU 是 65535， while eth0 是 1500， 1500 这个我们在计网笔记里面已经讲过了， 是因为早期的 Ethernet CSMA 的保证能持续监听 5.12km 的限制至少64byte, 谁是被约定好了在所有以太网设备上，然后一开始是 10Mbps ，用 1500 是为了保证复用的时候一个用户不会超过 50ms 延时，补充一个点是玩游戏要设置 1480，因为 PPPoE 多了 6bytes，导致路由器再拆分，输！）。而 IP 包最大支持 65535（由长度字段 bytes 数 uint 范围决定），所以 IP 到数据链路可能被分片。lo 的话直接内存复制或者映射就行了，赢！
• 不想让IP分片是为了节约上层重发 since ip 分片并不会重发，tcp 通过自学习（设置 ip 包 don't fragment 进行试探）获取链路最小 mtu，称为路径MTU发现机制。
• 分段最大选项： MSS tcp 上用 segment 讲， 所以是 MSS
• 窗口规模选项（RFC1323）：窗口由于用 16位字段负责通告大小，限制了 65535 大小（因为uint 无法表示65536）。为了适应，可以让一个选项（比如 syn 或者ack的时候payload里双方指定？）让窗口大小字段实际<<1。
• 时间戳选项（RFC1323），这个我们之前的笔记讲过了测量 RTT 的时候可以想办法让报文带上时间戳，这样方便测量每个报文的 RTT instead of 每个窗口只有一个计时器。而且时间戳的存在（4.2提到就是复用之前测量 RTT 的时间戳来实现这个目的）可以避免失而复得包（第三版中文翻译说这个不是重复的包而是失去的包，我认为失去的包延迟到达，此时不会复用新一轮序号，这一点暂时存疑，RFC里面主要讲的是 lost 的情况？）可能和 32 位序列号重复。作者说网络编程实际我们不用管他😓

鬼知道为什么路径发现都没用了，难道是虚拟机的问题？感觉是 DF 设置不设置都没用，链路机器直接把超大的IP包给丢掉了。