1. 为什么传输层是网络工程师的基本盘而不是理论课干了这么多年网络我有个很深的体会很多人对传输层协议的理解停留在TCP可靠、UDP快这种口号层面可真到排障、调优、设计网络架构的时候张口却说不出所以然。特别是软考网络工程师的考纲里传输层协议是必考内容但考试过了、实际干活却露馅的情况我见过太多了。传输层处在整个TCP/IP协议栈的中间位置上面是应用层下面是网络层。它的核心职责说白了就两件事提供进程到进程的通信和对数据进行分段重组。网络层解决的是数据包怎么从一台设备到另一台设备而传输层解决的是这个数据包到了主机之后应该交给哪个应用程序。这就是端口号存在的意义——IP地址定位到主机端口号定位到进程。以一次普通的网页访问为例你在浏览器输入一个网址DNS解析拿到IPTCP三次握手建立连接HTTP请求发出去服务器响应回来浏览器渲染页面。这中间拿数据的是TCP还是UDP由应用层决定。DNS查询本身用的是UDP的53端口而HTTP传输用的是TCP的80或443端口。同一个网络环境里TCP和UDP协同工作各自负责各自的任务。对网络工程师来说理解传输层不只是为了考试。你配置ACL时需要指定协议和端口排查丢包时需要判断是TCP重传还是UDP直接丢弃做流量整形时需要区分TCP和UDP的优先级甚至写脚本做网络监控时都要理解这两者的行为差异。可以说传输层知识是网络排障的底层语言。这篇文章会系统地讲清楚TCP和UDP的工作机制对比它们的核心差异应对软考和面试中的高频考点同时融入一些实际排障场景中的观察心得。文章会以项目实践的角度展开而不是那种照本宣科的理论知识点罗列。2. TCP的可靠性从三次握手就开始累积2.1 三次握手背后藏着的三个关键决策TCP的三次握手是面试和软考必问的内容但多数人只记住了SYN、SYN-ACK、ACK这个流程没有想清楚为什么是三次而不是两次或四次。这个为什么恰恰是理解TCP可靠性机制的钥匙。三次握手的本质是让通信双方确认彼此的收发能力都正常同时完成初始序列号的同步。第一次握手客户端发送SYN报文携带一个随机初始序列号比如x服务端收到后能确认客户端的发送能力正常我的接收能力正常第二次握手服务端回复SYN-ACK携带自己的初始序列号y同时确认客户端的序列号xACKx1客户端收到后能确认服务端的收发能力都正常我的收发能力也正常第三次握手客户端发送ACK确认服务端的序列号y服务端收到后确认客户端的接收能力正常我的发送能力正常。到这一步双方的收发能力才全部得到确认。那为什么两次不够假设只有两次握手服务端在收到SYN后就认为连接建立成功。如果客户端发送的SYN报文因为网络拥塞被延迟客户端超时重传了一个新的SYN服务端响应并建立连接数据传输完成后连接关闭。这时候第一个迟到的SYN又到达服务端服务端会误以为这是一个新连接请求于是再次建立连接、分配资源——但实际上客户端根本不知道这回事白白浪费了服务端的资源。三次握手通过客户端最后一次ACK来敲定连接如果服务端收到迟到的SYN并回复SYN-ACK客户端发现这不是自己期望的确认号就不会再发ACK服务端收不到最终确认就能及时释放半开连接。还有一个细节值得注意初始序列号必须随机化。这是为了防止TCP连接欺骗也为了避免新旧连接之间的序列号重叠导致数据错乱。早期实现是固定的后来发现安全隐患很大才改为随机生成。2.2 数据传输出错时TCP靠什么兜底连接建立只是开始真正体现TCP可靠性的是数据传输阶段的机制。核心机制可以概括为四个序列号与确认号、超时重传、快速重传、累计确认。序列号的作用是对每个字节编号接收方根据序列号判断数据是否有序、是否缺失。确认号表示我期望收到的下一个字节的序列号同时也告诉发送方这个序号之前的数据我都收到了。举个例子发送方发出序列号为1、长度为1000字节的数据段接收方收到后回复ACK1001表示1到1000字节已经收到下一步请从1001开始发。如果某个数据段丢失了怎么办发送方启动一个定时器如果在RTO重传超时时间内没有收到对应ACK就重传该数据段。这个RTO不是固定的TCP会根据历史往返时间动态计算。如果网络延迟增大RTO会相应增大避免过早重传造成网络负担如果网络变好RTO会减小加快丢失数据的恢复速度。在Linux下可以通过ss -ti命令查看当前连接的RTO值排查丢包时很有用。快速重传则是一种优化机制如果接收方收到乱序数据会立即重复发送对丢失数据之前那个字节的ACK也就是重复ACK。发送方连续收到3个重复ACK后不等超时定时器到期立刻判断该数据段已丢失马上重传。这个机制让TCP在网络轻微拥塞时能快速恢复不需要干等一个超时周期。累计确认是TCP的一个高效设计接收方不需要对每个数据段单独回ACK而是对最后一段连续数据的末尾序号做确认。比如收到1-1000、1001-2000、2001-3000三段数据只需要回复ACK3001即可。但如果中间丢了1001-2000这段即便收到了2001-3000也只能回复ACK1001提醒发送方从1001开始重传没收到的那部分。2.3 流量控制和拥塞控制两个窗口别搞混这是很多人容易混淆的地方。流量控制解决的是接收方来不及处理的问题拥塞控制解决的是网络中间设备处理不过来的问题。一个是端到端的节奏匹配一个是全局网络的负载管理。流量控制通过滑动窗口机制实现。TCP头部有一个16位的窗口字段接收方会在每个ACK中通告自己的可用接收缓冲区大小发送方据此调整发送速率。举个例子如果接收方缓冲区只剩2000字节它就在ACK里通告窗口为2000发送方最多只能再发2000字节未确认数据。如果缓冲区满了通告窗口为0发送方必须停止发送但会周期性地发送窗口探测报文询问接收方缓冲区是否有了空间。这个机制在接收方处理能力弱时特别重要比如服务器端应用处理缓慢的时候TCP的接收窗口会自动收窄反过来减缓了发送方的速率。拥塞控制则复杂一些主要涉及四个算法慢启动、拥塞避免、快速重传和快速恢复。TCP连接刚建立时拥塞窗口cwnd被设置为一个很小的值通常是10个MSS然后每收到一个ACKcwnd翻倍增长——这就是慢启动。这个慢是指起点低但增长速度是指数级的很快就能达到正常水平。当cwnd达到慢启动阈值ssthresh后进入拥塞避免阶段cwnd改为线性增长大约每个RTT增加一个MSS。一旦发生丢包超时或三次重复ACKTCP判定网络发生了拥塞快速恢复算法会将ssthresh降为当前cwnd的一半cwnd相应调低避免继续给网络加压。我在实际排障中遇到过这样一个场景内网传输大文件速度一直在某条线上徘徊上不去。用ss -ti看TCP的连接信息发现ssthresh非常小cwnd增长到阈值后就不再大幅上涨。最后定位到是网络中存在间歇性丢包导致TCP频繁进入拥塞控制吞吐量被限制。后来在交换机上做了端口优化丢包率降下来之后传输速度立刻翻了倍。这个案例说明TCP的可靠性机制在网络不好的情况下会主动踩刹车这是它的优势但在某些场景下也意味着性能瓶颈需要格外关注。3. UDP的不靠谱恰恰是它的高效之道3.1 八字节头部能省则省UDP的设计哲学和TCP截然不同。它只做传输层最基本的工作端口到端口的交付和校验和验证其余一切不管。UDP报文头固定只有8个字节分别是源端口16位、目的端口16位、长度16位、校验和16位。对比TCP最短20字节的头UDP省了至少12个字节。头部越短意味着有效载荷占比越高。假设一个数据包总长1500字节以太网MTU限制下的常见取值UDP的头部开销只占0.5%左右而TCP头部至少占1.3%。在大量小报文传输的场景下这个差异会被放大。比如VoIP语音报文通常只有几十字节TCP的20字节头部可能就是20%甚至更高的开销而UDP的8字节头部只有个位数百分比。这也是实时音视频应用几乎都选择UDP的原因之一。UDP校验和计算的范围涵盖伪头部、UDP头部和数据三部分。伪头部包含源IP地址、目的IP地址、协议号和UDP长度它的作用是防止IP层地址错误导致的数据误投递。这个设计利用了传输层和网络层的协作细节很巧妙。值得强调的是IPv4下的UDP校验和是可选的可以置0表示不校验但在IPv6下校验和是强制的。很多人在配置IPv6时忽略了这一点曾经有设备厂商的IPv6实现因为UDP校验和计算有bug导致数据包被接收方静默丢弃表现就是ping通但业务不通排查起来非常头疼。3.2 无连接、无状态、无背压UDP最核心的特征是无连接。发送方不需要提前与接收方建立连接直接把数据包丢到网络上接收方是否在线、是否愿意接收发送方一概不关心。这意味着UDP没有握手开销也没有连接状态需要维护。对于需要频繁发送短小请求的场景这个特性价值非常大。DNS查询就是典型例子客户端向DNS服务器发一个查询报文服务器回一个响应报文一问一答就结束了。如果用TCP做DNS先要三次握手建连再发查询收响应后再四次挥手断开开销远大于查询本身。所以常规DNS查询默认走UDP的53端口只有当响应数据量过大超过512字节在EDNS0下这个上限可以扩展到更大或者需要区域传送时才会切换到TCP。同样依赖UDP的还有DHCP67/68端口、TFTP69端口、SNMP161/162端口和RTP音视频传输。这些应用的共同特征是单个报文自包含、允许少量丢失、对延迟敏感。TFTP算是个有趣的案例它本身是UDP之上的一个简易版可靠传输通过停等式协议逐块确认来保证可靠性但每次只能等一块数据确认后再发下一块效率远不及TCP的滑动窗口。这从侧面说明开发者在设计上层应用时可以根据需要决定要可靠还是要效率而不是被底层协议绑死。没有背压机制是UDP另一个值得说的话题。TCP的接收方可以通过收紧窗口告诉发送方别发了我处理不过来但UDP没有这个能力。如果发送方速率超过接收方处理能力数据包会在接收方的套接字缓冲区排队缓冲区满了之后后续到达的数据包会被内核直接丢弃。我在抓包排查时见过太多这样的案例应用层明明在持续发送UDP数据接收方却没有收到任何上报很多人以为是网络断了实际看接收端的丢包计数器发现是缓冲区溢出导致的本地丢弃。用netstat -su可以查看这类丢包统计这个命令在UDP排障时几乎是必用的。3.3 应用层为什么需要再造一个可靠UDPUDP不保证可靠但很多应用既需要UDP的低延迟特性又需要一定程度的数据可靠性。于是出现了一个思路在UDP之上实现应用层的可靠传输机制。这是近年来网络协议演进的一个重要方向最典型的代表是QUIC协议。QUIC基于UDP实现但内部拥有类似TCP的连接管理、加密、可靠传输和拥塞控制机制。它之所以选UDP而不是直接改TCP是因为TCP在内核中实现部署升级需要修改操作系统和中间设备周期太长而UDP之上的逻辑完全在用户态实现迭代速度可以非常快。Google最初推动QUIC就是为了解决HTTP/2在TCP上存在的队头阻塞问题——一个TCP连接中如果丢了一个包后续所有数据都要等重传完成才能继续处理而在QUIC中多个数据流可以独立传输某个流丢包不影响其他流的交付。对网络工程师来说QUIC意味着防火墙和负载均衡设备需要识别UDP的443端口流量。很多企业的安全策略默认放行TCP的443而封禁其他UDP端口一旦Office 365、YouTube这类服务启用QUIC就会导致应用访问异常。我处理过一起这样的工单公司访问外部视频服务时快时慢排查到最后发现是防火墙对UDP 443限速导致QUIC的传输能力被压制。最终的安全策略调整是明确放行UDP 443问题才真正解决。这个案例提醒我们在当今的网络环境下UDP已经不只是游戏语音、视频流的代名词它还承载着未来的Web传输。4. 从Wireshark和iperf3里看TCP与UDP的真实行为4.1 Wireshark抓包验证三次握手和四次挥手学习传输层协议最快的方式不是背文档而是抓包看真实交互。我用Wireshark做一个最简单的实验访问某个网站同时抓取本机网卡上的流量然后过滤出TCP的三次握手过程。过滤器输入tcp.flags.syn 1就能看到SYN报文。第一个包是客户端发出的SYN源端口是随机的高位端口比如54321目的端口是443Flags栏显示SYN。第二个包是服务器的SYN-ACK源端口443目的端口54321标志位是SYNACK。第三个包是客户端的ACK标志位只有ACK。整个过程不到一毫秒但三个包清晰可见。注意看每个包的Sequence Number字段第一个包的Seq是0相对值显示第三个包的Acknowledgment Number是1表示期望从1开始。Wireshark默认用相对序号显示如果想看绝对的随机初始序列号可以在Preferences里关掉相对序号选项。四次挥手抓包则需要在访问完成后立刻停止抓包过滤条件可以用tcp.flags.fin 1。你会看到主动关闭方发出FIN被动方回ACK然后被动方也发出FIN主动方回ACK。值得注意的有两点一是中间被动方回ACK和发FIN之间往往有时间差因为应用程序需要处理完剩余数据再关闭套接字二是主动关闭方在发出最后一个ACK后会进入TIME_WAIT状态持续2个MSL最大报文段寿命通常为60秒之后系统才会彻底释放四元组。TIME_WAIT的作用是确保最后一个ACK能被对方收到如果丢了可以重发同时防止旧连接上的延迟报文干扰新连接。在Linux的ss -tan命令中你会看到大量TIME_WAIT状态的连接这是正常的但只要本地端口号耗尽就会导致新连接建立失败这时需要调整net.ipv4.ip_local_port_range范围或开启tcp_tw_reuse参数。4.2 用iperf3做TCP和UDP打流测试iperf3是网络工程师最常用的带宽测试工具没有之一。它默认跑TCP也可以指定UDP模式通过两组对比可以直观看出TCP和UDP的传输行为差异。TCP测试的命令很简单服务端运行iperf3 -s客户端运行iperf3 -c 服务器IP -t 30。30秒测试结束客户端会报告带宽、重传次数和CWND拥塞窗口大小。如果你的网络质量好输出中Retr那一列应该很小如果Retr数值很大说明网络存在丢包TCP正在通过重传维持传输但实际吞吐量可能达不到链路带宽。UDP测试需要额外指定带宽因为UDP自己不限制速率你不指定它就尽量往线路上塞数据。命令示例iperf3 -c 服务器IP -u -b 100M -t 30表示以100Mbps的速率发送UDP报文30秒。结束后重点看两个指标Jitter抖动和Lost/Total Datagrams丢包率。Jitter反映网络延迟的变化幅度对音视频业务至关重要丢包率则反映了这条链路对UDP流量的真实承载能力。我经常做这个测试来评估一条链路是否适合承载语音业务如果100Mbps的UDP打流丢包率超过1%语音质量大概率会受影响。做过对比测试后你会发现同样一条千兆链路TCP打流可能跑不到900Mbps而UDP打流可以轻松跑满千兆甚至更高。这不是TCP能力差而是TCP发现网络有轻微拥塞迹象就会自动降速UDP则不管不顾地猛发。理解了这个本质区别你在做网络容量规划时就能选择合适的测试工具和评估指标而不至于被表面数字误导。4.3 UDP排障时必查的内核计数器排查UDP问题比TCP麻烦因为UDP没有重传机制丢了就是丢了发送方完全不感知。好在操作系统提供了一些计数器帮助我们判断数据是在哪个环节丢的。Linux下最重要的命令是netstat -su输出中有一行以packets received开头其中包含packets to unknown port received和packet receive errors这两个计数器。前者表示收到一个UDP包但本地没有任何进程监听这个目的端口后者表示内核因为缓冲区满了或其他原因丢弃了这个包。如果packet receive errors在持续增长说明UDP接收缓冲区太小或应用处理太慢可以通过调整net.core.rmem_default和net.core.rmem_max来增大缓冲区。还有一个容易忽视的地方是网卡层面的丢包统计。用ethtool -S 网卡名可以查看rx_dropped、rx_missed_errors等计数器。如果这些值不为0说明数据包在进入内核协议栈之前就已经被网卡或驱动丢弃这类问题通常是网卡环形缓冲区太小、中断处理不及时或PCIe带宽不足导致的。有一次我排查一个UDP视频流卡顿的问题应用进程的CPU占用并不高netstat -su也没有明显的接收错误最后是在网卡统计里发现rx_missed_errors在疯狂增长。把网卡的ring buffer从默认值调大之后问题立刻消失了。这类经验在文档里很难看到但实际排查时价值极高。5. TCP与UDP的真实差异以及选型时的决策框架用一张表格来对照TCP和UDP的核心差异这种对比在软考和面试题中几乎是必考内容同时也是实际技术选型的基本参考。对比维度TCPUDP连接状态面向连接需建立/断开连接无连接直接发送数据可靠性可靠传输有序交付重传机制尽力而为可能丢包、乱序传输速度相对较慢有握手和多控制机制相对较快无复杂控制头部开销至少20字节固定8字节流量控制滑动窗口机制无拥塞控制有完整的拥塞控制算法无发送速率由应用控制数据边界字节流无消息边界数据报保留消息边界典型应用HTTP/HTTPS、FTP、SMTP、SSHDNS、DHCP、视频流、VoIP、QUIC实际选型时我习惯用三个问题来帮助决策第一个问题是数据能不能丢。金融交易、文件上传、数据库同步这些场景任何数据丢失都可能造成严重事故必须用TCP或者建立在可靠传输机制之上的协议。而视频画面偶尔丢几帧、语音电话偶尔卡顿几十毫秒人眼人耳基本无感这类场景用UDP更合适。第二个问题是延迟敏感度有多高。语音通话、互动直播、在线游戏对延迟要求极高。TCP在丢包时的重传机制会引入不可预测的延迟而UDP即使丢包也不会等待重传数据直接丢弃继续走后续流程这种丢旧保新的特性反而符合实时交互的需要。很多游戏使用UDP而非TCP核心原因就在于此。第三个问题是消息边界是否重要。TCP是字节流协议应用层写多少次写入和对方读多少次读取没有对应关系需要自己处理粘包和拆包问题。UDP则保留了数据报边界每次sendto对应对方的一次recvfrom天然是一份完整消息。如果你开发一个简单的消息通信程序用UDP可以省去处理粘包的麻烦用TCP则要设计消息帧协议比如包长度包体结构。需要特别强调的是UDP不等于一定比TCP快。在无丢包的局域网环境中两者吞吐量差距很小但在跨地域、高丢包率的网络上TCP经过调优后的有效吞吐量可能反而比盲发的UDP更高——因为UDP把带宽浪费在传输注定会被丢弃的报文上。我见过不少团队因为误以为UDP一定更快而选错协议最后骂网络不稳定的案例实际上问题出在没有针对网络条件选择合适的传输策略。6. 软考、面试和真实网络中最常踩的坑6.1 软考网络工程师的传输层高频考点软考网络工程师中级考试中传输层协议一般出现在上午的客观题里考察方式以概念辨析和流程理解为主。根据历年真题我总结了几类最常出现的考点第一类是TCP三次握手和四次挥手的具体参数。比如在TCP连接建立过程中客户端发送SYN后进入什么状态服务端收到SYN并回复SYN-ACK后处于什么状态。这类题考的是状态机客户端发送SYN后进入SYN_SENT状态服务端收到SYN后进入SYN_RCVD状态并回复SYN-ACK客户端收到SYN-ACK后回复ACK并进入ESTABLISHED状态服务端收到最后这个ACK后也进入ESTABLISHED状态。四次挥手则对应FIN_WAIT_1、CLOSE_WAIT、FIN_WAIT_2、LAST_ACK、TIME_WAIT这些状态整个过程可以画一条清晰的变迁链。第二类是TCP头部字段的作用。序列号、确认号、窗口大小、标志位SYN、ACK、FIN、RST、PSH、URG各自的用途和触发场景。RST标志位是很多考生容易忽略的——它用于异常终止连接比如访问一个不存在的端口主机直接回一个RST报文告诉对方别等了没有这个服务。curl: (35) tcp connection reset by peer这个报错对应抓包就是连接建立后收到了RST包。第三类是TCP与UDP的协议号及端口号。TCP的协议号是6UDP的协议号是17这些在配置ACL和防火墙策略时都会用到。常见应用的默认端口要能对号入座HTTP的80、HTTPS的443、FTP的21/20、SSH的22、Telnet的23、SMTP的25、DNS的53、DHCP的67/68、TFTP的69、SNMP的161/162。软考题喜欢结合场景出题比如某公司禁止员工访问外部网站但允许进行DNS解析需要在防火墙上如何配置答这类题的基础就是对端口号了如指掌。6.2 面试中追问深度的问题——从会用到理解现在网络工程师的面试越来越不满足于TCP与UDP的区别这种背诵题了。面试官更倾向于从一个基础概念展开追问考察你的理解深度。常被追问的第一个问题是TCP三次握手可以改为两次吗这个问题上文已经分析过核心在于防止迟到的连接请求导致服务端资源浪费以及双方确认收发能力需要三方验证。答出这些就算到位。第二个高频追问是粘包是什么TCP一定会粘包吗UDP会粘包吗要答好这个问题必须先理解TCP是字节流协议它只保证数据的有序和可靠到达不保证应用层消息的边界。如果应用层连续发送两个消息Hello和World接收方可能一次性读到HelloWorld。这就是粘包。TCP不一定会粘包取决于收发双方的读写节奏和缓冲区大小。UDP则因为保留了消息边界每次读取恰好对应一条完整消息不存在粘包问题。面试时如果能把粘包的四种常见处理方式说出来定长消息、长度前缀、分隔符、块结束标记并且用代码或伪代码演示一下会很加分。第三个追问是TIME_WAIT状态为什么需要等待2MSL这个也是高频中的高频。核心原因有两点一是确保最后那个ACK能到达对端如果没有等到对端会重发FIN本端可以再次发送ACK二是让本连接中的所有旧报文在网络中自然消亡避免影响下一个相同四元组的新连接。2MSL是最大报文段寿命的两倍需要确保一个报文在网络中最长存活时间内不会被重复接收。第四个追问是如果UDP丢了包应用层如何感知很多人的第一反应是感知不到这个答案不完整。实际上接收方应用层是感知不到的因为UDP内部没有通知机制但应用可以自己通过序号检测乱序和丢包——比如RTP协议中每个报文都有序号接收端如果发现序号不连续便能推断丢包。在TLS 1.3的早期版本中曾有一个著名的实验性协议TAPS尝试在UDP之上实现可靠传输说明应用层完全可以自行设计ACK和重传逻辑。这也是QUIC背后一整套机制的原理。6.3 真实网络环境中的决策教训最后分享几个真实项目中的经验教训都是踩过坑之后总结出来的。第一个教训是不要给UDP流量配置无脑的QoS标记在网络设备上配置QoS策略时很多人喜欢把UDP流量全部标记为高优先级理由是实时业务都是UDP。这个想法本身没错但忽略了一个重要事实UDP并不都是实时流量。P2P下载、BT传输大量使用UDP这类流量对延迟完全不敏感却会挤占其他业务的带宽。正确的做法是先通过DPI深度包检测识别出具体的应用类型再针对VoIP、视频会议这类真正需要低延迟的业务做优先级标记而不是一刀切对待所有UDP流量。第二个教训是UDP打流测试不能代替真实业务测试。iperf3的UDP打流结果是评估链路能力的重要参考但它只是满负荷灌包不代表真实业务的表现。真实业务有间歇性、有特定的报文大小分布、有应用层交互逻辑。我们曾经用iperf3测试一条专线丢包率不到0.1%一切正常但上线视频会议系统后频繁出现卡顿。后面深入分析才发现视频会议的报文大小比较均匀且间隔稳定网络设备上某个队列的缓存深度不足导致周期性瞬间拥塞。单纯靠打流测试是发现不了这类问题的必须在真实业务流量下做持续监测。第三个教训是排查UDP问题一定要看两端。TCP的问题通常在中间网络上能找到线索重传、乱序、超时UDP的问题则可能出在任何一端发送端的socket发送缓冲区设置、本地的路由选择、中间网络设备的防火墙策略、接收端的套接字缓冲区、应用的读取频率。有一次我排查一个跨设备UDP组播不通的问题抓包发现发送端明明在发接收端抓包也明明收到了但应用层就是收不到数据。最后定位到是接收端的防火墙没放行组播地址的入站流量数据包在netfilter层被丢弃了应用根本无从感知。两端都抓包、层层比对才是真正的排查思路。这些经验说到底是一句话TCP和UDP不是互相替代的关系而是针对不同业务需求的两套解决方案。理解它们的设计哲学和适用边界比死记硬背一堆参数和标志位重要得多。做网络这一行每天面对的设备形态千变万化但底层的数据传输逻辑始终保持稳定。把传输层这件事想透彻了后面学路由协议、学网络安全、学SDN都会顺畅很多。