掌握网络架构核心！了解为什么要分层

1 网络是七层、五层还是四层？

常听到三层交换机、七层规则等。网络为什么要分层呢？非分不可？

网络诞生前夜，IP协议、TCP协议都不存在，而你是网络缔造者，你会选择做怎样设计？

大体有两种

1.1 设计方案

1.1.1 应用程序包办一切

程序把应用层的数据，按某种编码转化为二进制数据，然后程序去操控网卡，把二进制数据发送到网络。这期间，通信的连接方式、传输的可靠性、速度和效率的保证等等，都需要这个程序去实现。然后下次开发另外一个应用的时候，就把上面这些活，再干一遍。

大包大揽，实现难度太大、耦合度太高，怎么看都是“反面典型”。

1.1.2 应用程序、os、网络设备等环节各自分工

应用程序只负责实现应用层的业务逻辑
Os负责连接建立、处理网络拥塞和丢包乱序、优化网络读写速度等
然后把数据交给网卡，后者和交换机等设备做好联动，负责二进制数据在物理线路上的传送和接收

所以选择第二种，即分层实现。

这思路跟编程思想类似。在编程中，要把一些逻辑抽象为函数或对象，以解耦和复用。网络世界亦如此，每层干好自己的分内事，那么所有的层次配合起来工作的时候，就有条不紊。

1.2 分层模型

OSI的七层模型，和 TCP/IP的四层/五层模型。最大区别：

前者在传输层、应用层之间，还有会话层和表示层
后者没有

哪种用得最多，哪种更合理？不用纠结“谁比谁更好”，如果我们理解每层作用，就不会被表象层级束缚。两种分法都有可取之处。

一般七层模型工作谈论更多。同事会找运维“你帮我建一个七层规则吧”。这七层就指应用层，“七层规则”可能是HTTP路由规则，如把符合某种条件的HTTP请求，分流到某特定后端集群。

还有一些场景适合用七层模型解释。如TLS虽在TCP之上，按TCP/IP模型就要被归入应用层。但HTTPS场景下，HTTP协议就是运行在TLS协议上，是不是把HTTP和TLS分到不同层次更合适？正好七层模型的第5、6层可分别代表TLS的会话保持功能和数据加解密这种表示层的功能。

会话层、表示层协议确实少。控制模型复杂度角度，如把这两层合并到应用层，模型倒更简单，也适合入门。所以从这点，TCP/IP模型也有可取之处。

为何TCP/IP还有四层和五层模型这两种说法呢？其实五层模型就是OSI的前四层，加上一个应用层。这样的话，这个五层模型跟OSI七层模型，差异就比四层模型又缩小了一点。

两种分层模型最大差异，还是在会话层和表示层。1-4层已基本统一。而它们最高层，虽然一个叫第7层，一个叫第4层或第5层，表面虽不一致，但都能用“应用层”代替。既避免可能误解，也更准确表示这层具体用途。

2 啥是TCP流？

Wireshark文档中，“TCP流”很常见，即TCP Stream。Stream“流”意，也有“连续的事件”含义，所以它是有前后、有顺序，正对应TCP特性。

跟Stream相对是Datagram，指没有前后关系的数据单元，如UDP和IP。

Linux网络编程里面：

TCP对应socket类型SOCK_STREAM
UDP对应的，就是SOCK_DGRAM

DGRAM就是Datagram简写

网络报文层面，一个TCP流，对应一个五元组：

传输协议类型
源IP、源端口
目的IP、目的端口

如今天你访问javaedge网站，这次TCP流就可能是这样的五元组：

(TCP, your_ip, your_port, javaedge_ip, 443)

一个IP报文包含所有这五元素，所以Wireshark解析抓包文件时，就能通过五元组知道每个报文所属TCP流。由此，可在Wireshark里，用Follow TCP Stream的方法，找到报文所在TCP流。

不过有时也有四元组，跟五元组大体一致，只是四元组没区分传输层协议类型（TCP或UDP）。但若我们都清楚知道应用类型，如知道应用是HTTP协议，那传输层协议默认就是TCP，这一元是否算进已不重要。

3 报文、帧、分组、段、数据包是一个？

3.1 报文（packet）

一种相对宽泛和通用的说法，基本每层都能用，如：

应用层可说“HTTP报文”
传输层可说“TCP报文”
网络层即“IP报文”。网络层也是“报文”一词被使用最多的场景。

数据包类似，可在很多场景通用。

语法。packet后缀et。et结尾词多表示某个小小东西。如功能完备的一小段代码code snippet，一小段内嵌HTML的Java前端代码applet。packet就是一个小pack（包裹）。

如下就不是通用词，而是特定层专有词汇。

3.2 帧（frame）

二层也就是数据链路层，代表二层报文，包含帧头、载荷、帧尾。

帧有尾部，而其他像IP、TCP、HTTP等层级报文都没尾部。不可以说“TCP帧”或“IP帧”，虽然也许对方也明白你，但也得做得专业点嘛。

HTTP/2实现了多路复用，也有帧概念，不过那帧跟这里网络二层的帧，除了名称相同，就没别的联系。

3.3 分组

IP层报文，即狭义的packet。

3.4 段

特指TCP segment，即TCP报文。既然segment是“部分”意思，那这“整体”又是啥？它就是在应用层交付给传输层的消息（message）。

当message被交付给传输层，如果这个message的原始尺寸，超出传输层数据单元的限制（如超出TCP的MSS），它就会被划分为多个segment。这过程就是分段（segmentation），也是TCP层重要职责。

说到segmentation，你可能也会想到fragmentation（分片）。这俩是同一个东西吗？这方面的知识点也不少，我在这里就不具体展开了。不过别着急，我会在第8讲里，帮你把这两个东西梳理清楚。

Datagram中文 “数据报”，但不是“数据包”。读音类似，但意思并不完全相同。“数据包”是个通用词，所以“UDP数据包”指代“UDP数据报”没问题。但反过来，非UDP协议的数据包，如TCP段，就不能叫“TCP数据报”，因为TCP不是Datagram。

层级和术语对应关系：

4 网络各层都有哪些排查工具？

4.1 应用层

应用层排查工具太多，选个主要的应用，谈谈 HTTP应用的排查工具。

Chrome内置开发者工具，F12启动。可方便地做很多事。

① 找到有问题的服务端IP

如有用户报告死活访问不了你的网站，但你很清楚这网站域名对应很多IP地址，你怎么知道用户连哪个IP？

让客户启用开发者工具，在Network页找到主页对象，在它的Headers部分，就能看到Remote address，这IP就是当前连接的IP，如：

因为DNS解析，可能下次重连就不是这IP，所以每次都应该重新确认下这信息。

这技巧，在 排查公网的访问问题 时特别有用。现在流量大点网站都已上CDN，必然在全国乃至全球各地，有少则数十个、多则数百个CDN终端节点，在给访问者提供就近服务。如有人说他访问不了某站点，一定让他用开发者工具，找到他连的远程IP，再根据这信息排查。

② 辅助排查网页慢

访问页面感觉慢，开发者工具 时间统计功能，找到耗时高的HTTP资源对象，再针对性排查。

如访问 https://github.com 慢，打开开发者工具，然后访问站点，等全部加载完成后，到Network页查看这些HTTP对象的加载时间。

这只能排查哪个资源对象耗时长，但进步排查，如“为啥这对象加载时间比别的对象长”，开发者工具就难答。抓包分析可根本性排查这类问题。

③ 解决失效Cookie带来的问题

有时Cookie过期，导致无法正常登录站点，打开开发者工具，到Application页，找到Storage -> Cookie，把对应条目清除。下次再访问这站点，就已“洗心革面”。对站点来说，你就是一次新访问，可生成一次新Cookie。

通过删除浏览器缓存也可做到。但开发者工具可 细粒度 到这网站级别，而删除缓存就是所有站点Cookie。

4.2 表示层和会话层

表示层和会话层的协议不多，TLS可归入这俩层级。TLS问题排查推荐工具。

基于浏览器

做初步检查，主要围绕证书本身做检查。

浏览器地址栏有按钮，点开查看TLS证书等信息。继续点开【连接是安全的】按钮：

进而点击【证书有效】按钮：

就能查看证书：

使用开发者工具的【安全】菜单，还可查看更为详细的TLS信息，包括协议版本、密钥交换算法、证书有效期等：

tcpdump和Wireshark

TLS握手、密钥交换、密文传输等排查，还是要用专业工具。在Wireshark可更全面查看TLS细节。

如直接看到TLS握手阶段，双方协商 过程中 各自展示的Cipher suite，

而【开发者工具】只能看到协商 完成后 的选择。

4.3 传输层

重中之重，工具很多。按排查场景介绍。

① 路径可达性测试

测试TCP握手，有 telnet、nc 。如telnet：

$ telnet www.baidu.com 443
Trying 180.101.49.12...
Connected to www.a.shifen.com.
Escape character is '^]'.

用nc：

$ nc -w 2 -zv www.baidu.com 443
Connection to www.baidu.com 443 port [tcp/https] succeeded!

② 查看当前连接状况

netstat 获取当前TCP、UDP等连接信息，如：

$ netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0    280 10.0.2.15:22            10.0.2.2:56669          ESTABLISHED
tcp6       0      0 :::22                   :::*                    LISTEN

③ 查看当前连接的传输速率

有时，你的网络跑得挺繁忙，但你却不知道哪个连接占用大量带宽？用 iftop。这工具不是系统自带，要安装。要有sudo权限，即执行sudo iftop，然后就能看到不同连接的传输速率，把祸害你带宽的连接给找到。如：

④ 查看丢包和乱序等的统计

netstat除了获取实时连接状况，还可获取历史统计信息。

如怀疑一台机器网络不稳定，除了用ping简单测试，还可用

netstat -s

获取更详细的统计信息。如其中的TCP丢包和乱序计数值，就能帮你判断传输层状况。

$ netstat -s
......
Tcp:16 active connection openings1 passive connection openings8 failed connection attempts1 connection resets received1 connections established6254 segments received4035 segments sent out1 segments retransmitted0 bad segments received3 resets sent
......
TcpExt:1 ICMP packets dropped because socket was locked3 TCP sockets finished time wait in fast timer8 delayed acks sent4674 packet headers predicted10 acknowledgments not containing data payload received1008 predicted acknowledgmentsTCPTimeouts: 1TCPBacklogCoalesce: 1401 connections reset due to early user closeTCPRcvCoalesce: 2187TCPAutoCorking: 110TCPSynRetrans: 1TCPOrigDataSent: 1041TCPDelivered: 1049

这些不是静态值吗，我想知道当前情况啊？

watch --diff netstat -s

会把变化数值高亮：

上面这算运维“青铜”版。你也可写个简单脚本，在两次netstat -s之间执行sleep，然后计算两个读数间差值，并除以sleep时间，得到大致变化速度。这就又升级一点。

若你想做得再到位，可将netstat -s输出值写入TSDB，然后用Grafana展示，不仅有视图，也有历史值，运维“王者”！

ss 命令是Iproute2包里的命令，也是netstat“取代者”。提供对socket的丰富统计信息。如下查看当前连接统计信息：

$ ss -s
Total: 164
TCP:   5 (estab 1, closed 0, orphaned 0, timewait 0)Transport Total     IP        IPv6
RAW	  1         0         1
UDP	  2         2         0
TCP	  5         4         1
INET	  8         6         2
FRAG	  0         0         0

netstat命令功能被拆分到ss、ip两个命令，并分别得到丰富和加强。

4.4 网络层

在这一层，除了能直接用ping，还应掌握：

traceroute
mtr

查看网络路径状况

traceroute典型输出：

javaedge@JavaEdgedeMac-mini ~ % traceroute www.baidu.com
traceroute: Warning: www.baidu.com has multiple addresses; using 180.101.50.242
traceroute to www.a.shifen.com (180.101.50.242), 64 hops max, 52 byte packets1  * * *2  180.156.60.1 (180.156.60.1)  5.187 ms  21.989 ms  35.530 ms3  * 61.152.46.197 (61.152.46.197)  5.917 ms  31.525 ms4  61.152.25.198 (61.152.25.198)  3.704 ms101.95.120.54 (101.95.120.54)  3.566 ms61.152.25.198 (61.152.25.198)  3.324 ms5  202.97.72.202 (202.97.72.202)  20.957 ms202.97.29.126 (202.97.29.126)  8.328 ms202.97.66.206 (202.97.66.206)  16.003 ms6  58.213.95.174 (58.213.95.174)  8.515 ms58.213.94.110 (58.213.94.110)  12.978 ms58.213.94.30 (58.213.94.30)  9.487 ms7  * * *8  58.213.96.66 (58.213.96.66)  9.059 ms  9.095 ms58.213.96.50 (58.213.96.50)  9.014 ms9  * * *
10  * * *
11  * * *

为何第9跳开始就没IP，只有星号？你是不是也遇到过这情况？稍改命令，加上 -I 参数（I代表ICMP），就能正常跑到底：

$ traceroute  www.baidu.com -I
traceroute to www.a.shifen.com (180.101.49.12), 64 hops max1   10.0.2.2  0.099ms  2.363ms  0.078ms2   192.168.1.1  3.320ms  1.220ms  1.204ms3   100.65.0.1  8.737ms  4.872ms  6.403ms4   61.152.54.125  5.035ms  3.397ms  4.288ms5   *  61.152.25.110  4.176ms  *6   202.97.101.30  7.447ms  6.399ms  5.936ms7   58.213.95.110  10.488ms  *  9.014ms8   *  58.213.95.134  11.064ms  *9   58.213.96.74  10.997ms  10.042ms  10.592ms10   *  *  *11   *  *  *12   *  *  *13   180.101.49.12  11.269ms  9.518ms  8.779ms

背后原理，就是traceroute默认用UDP作为探测协议，但很多网络设备不会对UDP回应。所以改成ICMP协议做探测后，网络设备就有回应。

Windows上的tracert，就默认ICMP，和Linux正好反过来。

但traceroute也有明显不足： 它不能对这个路径做连续多次探测。

于是，mtr出现，可算traceroute的超集，除类似traceroute功能，mtr还能实现丰富的探测报告。尤其是它对每一跳的丢包率的百分比，是用来定位路径中节点问题的重要指标。当你遇到 “连接状况时好时坏” ，一次性traceroute难以看清，那就能用mtr获取更全面和动态的链路状态信息。

$ mtr www.baidu.com -r -c 10
Start: 2022-01-07T04:05:02+0000
HOST: victorebpf                  Loss%   Snt   Last   Avg  Best  Wrst StDev1.|-- _gateway                   0.0%    10    0.3   0.4   0.2   1.2   0.32.|-- 192.168.1.1                0.0%    10    1.6   1.8   1.4   3.2   0.53.|-- 100.65.0.1                 0.0%    10    3.8   7.0   3.8  10.3   2.04.|-- 61.152.54.125              0.0%    10    4.0   4.3   3.6   5.1   0.55.|-- 61.152.25.110             30.0%    10    5.0   6.8   4.4  18.9   5.46.|-- 202.97.101.30             20.0%    10    7.8   6.6   5.4   7.8   0.87.|-- 58.213.95.110             80.0%    10   10.0   9.8   9.6  10.0   0.38.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.09.|-- 58.213.96.74               0.0%    10   10.5  12.7   9.9  24.7   4.910.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.011.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.012.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.013.|-- 180.101.49.12              0.0%    10    9.4   9.1   8.3   9.7   0.5

查看路由

route 能查看路由表，不过这命令较老：

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 enp0s3
10.0.2.2        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

传输层工具里介绍的 netstat，其实也能帮我们查看路由，只要加上 -r 参数：

$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         _gateway        0.0.0.0         UG        0 0          0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U         0 0          0 enp0s3
_gateway        0.0.0.0         255.255.255.255 UH        0 0          0 enp0s3
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0

我前面说过，netstat是被ss和ip这两个命令替代了。所以我们同样可以用 ip命令 查看路由。比如这样：

$ ip route
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

4.5 数据链路层和物理层

这一层离应用层已经很远了，一般来说是专职的网络团队在负责。如果这一层有问题，就会直接体现在网络层表现上面，比如IP会有丢包和延迟等现象，然后会引发传输层异常（如丢包、乱序、重传等）。所以， 一个稳定的数据链路层乃至物理层，是网络可靠性的基石。

既然底下这两层稳定性如此重要，那上层TCP不是号称还有传输可靠性保障？

难道这保障形同虚设？

TCP传输可靠性是通过序列号、确认号、重传机制等保证，通过这种机制，TCP可 一定程度 网络不稳定场景下，依然保证传输可靠，但不等于TCP能无限容忍底层的不稳定，因为各种TCP拥塞控制算法都会由于这种问题，而极大降低传输性能。

如你想查看这两层，可用 ethtool：

# ethtool -S enp0s3
NIC statistics:rx_packets: 45897tx_packets: 9457rx_bytes: 59125524tx_bytes: 834625rx_broadcast: 0tx_broadcast: 17rx_multicast: 0tx_multicast: 59rx_errors: 0tx_errors: 0tx_dropped: 0

网卡驱动会到内核中注册ethtool回调函数，然后我们用ethtool命令就能查看这些信息。由于信息由网卡驱动提供，十分“接地气”。

如你在传输层和网络层的排查工具，已看到明确的链路不稳定的信息，那就直接找网络团队吧。

总结

回顾网络分层模型，也了解OSI模型和TCP/IP模型的区别和联系。对分层模型有了更加深入的理解，这个对我们开展网络排查工作，有指导性意义。

应用层以HTTP为例，可以用 浏览器开发者工具，实现远程IP识别、耗时分析、Cookie删除等需求。
会话层和表示层以TLS为主，我们还是用 浏览器开发者工具，可以查看证书细节、协商后使用的Cipher suite等信息，属于静态信息。然后学习了 用tcpdump和Wireshark 查看更详细的TLS握手细节的方法。这些信息是动态的，也只有用抓包分析的手段才能做到。
在传输层，我们学到了 telnet、nc、netstat、ss 等命令，通过它们，我们可以测试连通性，也可以获取连接状况和统计信息，对于传输问题的排查都很有帮助。
在网络层及以下的部分，我们学习了 traceroute、mtr、ip 等工具，可以检测网络路径状况。
在数据链路层和物理层，我们可以做的不多，主要依靠网络层观察到的链路质量来推断这两层的情况。当然，也可以用 ethtool 这个工具查看这两层的详情。

FAQ

traceroute默认是用UDP来做探测的，那这个又是基于啥原理？通和不通，我们会收到怎样的回复？

traceroute使用UDP协议发送探测包，因为UDP协议无需像TCP协议握手和拆除连接，所以traceroute可更快发送探测包，且不对目标主机产生太大负载。

当traceroute发探测包时，每一跳的路由器都会将接收到的探测包的TTL值减1，并将该探测包返回给源主机。当TTL值减为0，路由器会将该探测包丢弃，并向源主机发送一个ICMP超时消息。因此，traceroute可通过TTL值的递减确定每一跳的路由器，并通过接收到的ICMP消息，确定探测包是否到达目标主机。

如果探测包成功到达目标主机，目标主机会向源主机发送一个ICMP端口不可达消息，告诉源主机该端口无法访问。因此，traceroute可以通过接收到的ICMP消息来确定目标主机是否可达，并计算出每一跳的延迟时间。

有时候运行telnet后命令就挂起，没响应了，说明啥问题？

运行telnet后命令挂起可能是因telnet连接已断开或网络连接出现问题。可尝试重新连接并检查您的网络连接是否正常。如果问题仍然存在，可能需要检查您的telnet服务器或客户端的配置是否正确。