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

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 openings
    1 passive connection openings
    8 failed connection attempts
    1 connection resets received
    1 connections established
    6254 segments received
    4035 segments sent out
    1 segments retransmitted
    0 bad segments received
    3 resets sent
......
TcpExt:
    1 ICMP packets dropped because socket was locked
    3 TCP sockets finished time wait in fast timer
    8 delayed acks sent
    4674 packet headers predicted
    10 acknowledgments not containing data payload received
    1008 predicted acknowledgments
    TCPTimeouts: 1
    TCPBacklogCoalesce: 140
    1 connections reset due to early user close
    TCPRcvCoalesce: 2187
    TCPAutoCorking: 110
    TCPSynRetrans: 1
    TCPOrigDataSent: 1041
    TCPDelivered: 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 packets
 1  * * *
 2  180.156.60.1 (180.156.60.1)  5.187 ms  21.989 ms  35.530 ms
 3  * 61.152.46.197 (61.152.46.197)  5.917 ms  31.525 ms
 4  61.152.25.198 (61.152.25.198)  3.704 ms
    101.95.120.54 (101.95.120.54)  3.566 ms
    61.152.25.198 (61.152.25.198)  3.324 ms
 5  202.97.72.202 (202.97.72.202)  20.957 ms
    202.97.29.126 (202.97.29.126)  8.328 ms
    202.97.66.206 (202.97.66.206)  16.003 ms
 6  58.213.95.174 (58.213.95.174)  8.515 ms
    58.213.94.110 (58.213.94.110)  12.978 ms
    58.213.94.30 (58.213.94.30)  9.487 ms
 7  * * *
 8  58.213.96.66 (58.213.96.66)  9.059 ms  9.095 ms
    58.213.96.50 (58.213.96.50)  9.014 ms
 9  * * *
10  * * *
11  * * *

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

$ traceroute  www.baidu.com -I
traceroute to www.a.shifen.com (180.101.49.12), 64 hops max
  1   10.0.2.2  0.099ms  2.363ms  0.078ms
  2   192.168.1.1  3.320ms  1.220ms  1.204ms
  3   100.65.0.1  8.737ms  4.872ms  6.403ms
  4   61.152.54.125  5.035ms  3.397ms  4.288ms
  5   *  61.152.25.110  4.176ms  *
  6   202.97.101.30  7.447ms  6.399ms  5.936ms
  7   58.213.95.110  10.488ms  *  9.014ms
  8   *  58.213.95.134  11.064ms  *
  9   58.213.96.74  10.997ms  10.042ms  10.592ms
 10   *  *  *
 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 StDev
  1.|-- _gateway                   0.0%    10    0.3   0.4   0.2   1.2   0.3
  2.|-- 192.168.1.1                0.0%    10    1.6   1.8   1.4   3.2   0.5
  3.|-- 100.65.0.1                 0.0%    10    3.8   7.0   3.8  10.3   2.0
  4.|-- 61.152.54.125              0.0%    10    4.0   4.3   3.6   5.1   0.5
  5.|-- 61.152.25.110             30.0%    10    5.0   6.8   4.4  18.9   5.4
  6.|-- 202.97.101.30             20.0%    10    7.8   6.6   5.4   7.8   0.8
  7.|-- 58.213.95.110             80.0%    10   10.0   9.8   9.6  10.0   0.3
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- 58.213.96.74               0.0%    10   10.5  12.7   9.9  24.7   4.9
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 13.|-- 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: 45897
     tx_packets: 9457
     rx_bytes: 59125524
     tx_bytes: 834625
     rx_broadcast: 0
     tx_broadcast: 17
     rx_multicast: 0
     tx_multicast: 59
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0

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

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

总结

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

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

1. 在数据链路层和物理层，我们可以做的不多，主要依靠网络层观察到的链路质量来推断这两层的情况。当然，也可以用 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服务器或客户端的配置是否正确。