程序员如何学习和构建网络知识体系

大家学习网络知识的过程中经常发现当时看懂了，很快又忘了，最典型的比如TCP三次握手、为什么要握手，大家基本都看过，但是种感觉还差那么一点点。都要看是因为面试官总要问，所以不能不知道啊。

我们来看一个典型的面试问题：

问：为什么TCP是可靠的？
答：因为TCP有连接（或者回答因为TCP有握手）

追问：为什么有连接就可靠了？（面试的人估计心里在骂，你这不是傻逼么，有连接就可靠啊）

追问：这个TCP连接的本质是什么？网络上给你保留了一个带宽所以能可靠？
答：……懵了（或者因为TCP有ack，所以可靠）

追问：握手的本质是什么？为什么握手就可靠了
答：因为握手需要ack
追问：那这个ack也只是保证握手可靠，握手是怎么保证后面可靠的？握手本质做了什么事情？

追问：有了ack可靠后还会带来什么问题（比如发一个包ack一下，肯定是可行的，但是效率不行，面试官想知道的是这里TCP怎么传输的，从而引出各个buffer、拥塞窗口的概念）

基本上我发现99%的程序员会回答TCP相对UDP是可靠的，70%以上的程序员会告诉你可靠是因为有ack（其他的会告诉你可靠是因为握手或者有连接），再追问下次就开始王顾左右而言他、胡言乱语。

我的理解：

物理上没有一个连接的东西在这里，udp也类似会占用端口、ip，但是大家都没说过udp的连接。而本质上我们说tcp的握手是指tcp是协商和维护一些状态信息的，这个状态信息就包含seq、ack、窗口/buffer，tcp握手就是协商出来这些初始值。这些状态才是我们平时所说的tcp连接的本质。

这说明大部分程序员对问题的本质的理解上出了问题，或者教科书描述的过于教条不够接地气所以看完书本质没get到。

想想 费曼学习方法 中对事物本质的理解的重要性。

曾经碰到过 nslookup OK but ping fail–看看老司机是如何解决问题的，解决问题的方法肯定比知识点重要多了，同时透过一个问题怎么样通篇来理解一大块知识，让这块原理真正在你的知识体系中扎根下来 , 这个问题Google上很多人在搜索，说明很普遍，但是没找到有资料能把这个问题说清楚，所以借着这个机会就把 Linux下的 NSS（name service switch）的原理搞懂了。要不然碰到问题老司机告诉你改下 /etc/hosts 或者 /etc/nsswitch 或者 /etc/resolv.conf 之类的问题就能解决，但是你一直不知道这三个文件怎么起作用的，也就是你碰到过这种问题也解决过但是下次碰到类似的问题你不一定能解决。

当然对我来说为了解决这个问题最后写了4篇跟域名解析相关的文章，从windows到linux，涉及到vpn、glibc、docker等各种场景，我把他叫做场景驱动。后来换来工作环境从windows换到mac后又补了一篇mac下的路由、dns文章。

关于场景驱动学习的方法可以看这篇总结

TCP是最复杂的，要从实用出发

比如拥塞算法基本大家不会用到，了解下就行，你想想你有碰到过因为拥塞算法导致的问题吗？极少是吧。还有拥塞窗口、慢启动，这个实际中碰到的概率不高，面试要问你基本上是属于炫技类型。

实际碰到更多的是传输效率（对BDP、Buffer、各种窗口、rt的理解和运用），还有为什么连不通、连接建立不起来、为什么收到包不回复、为什么要reset、为什么丢包了之类的问题。

关于为什么连不通，我碰到了这个问题，随后在这个问题的基础上进行了总结，得到客户端建立连接的时候抛异常，可能的原因（握手失败，建不上连接）：

• 网络不通，诊断：ping ip
• 端口不通, 诊断：telnet ip port
• rp_filter 命中(rp_filter=1, 多网卡环境）， 诊断: netstat -s | grep -i filter
• 防火墙、命中iptables 被扔掉了，可以试试22端口起sshd 能否正常访问，能的话说明是端口被干了
• snat/dnat的时候宿主机port冲突，内核会扔掉 syn包。诊断: sudo conntrack -S | grep insert_failed //有不为0的
• Firewalld 或者 iptables
• 全连接队列满的情况，诊断： netstat -s | egrep “listen|LISTEN”
• syn flood攻击, 诊断：同上
• 若远端服务器的内核参数 net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_timestamps 的值都为 1，则远端服务器会检查每一个报文中的时间戳（Timestamp），若 Timestamp 不是递增的关系，不会响应这个报文。配置 NAT 后，远端服务器看到来自不同的客户端的源 IP 相同，但 NAT 前每一台客户端的时间可能会有偏差，报文中的 Timestamp 就不是递增的情况。nat后的连接，开启timestamp。因为快速回收time_wait的需要，会校验时间该ip上次tcp通讯的timestamp大于本次tcp(nat后的不同机器经过nat后ip一样，保证不了timestamp递增），诊断：是否有nat和是否开启了timestamps
• NAT 哈希表满导致 ECS 实例丢包 nf_conntrack full， 诊断: dmesg |grep conntrack

总结

• 一定要会用tcpdump和wireshark（纯工具，没有任何门槛，用不好？只有一个原因: 懒）
• 多实践（因为网络知识离我们有点远、有点抽象）,用好各种工具，工具能帮我们看到、摸到
• 不要追求知识面的广度，深抠几个具体的知识点然后让这些点建立体系
• 不要为那些基本用不到的偏门知识花太多精力，天天用的都学不过来，对吧？