有人问我学计算机网络概述这一章到底有什么用反正后面讲TCP、讲IP的时候还得重新学一遍。我当时没直接回答而是让他打开浏览器随便输个网址然后在按下回车之后的三秒钟里把屏幕上发生的事按顺序讲一遍。他讲了DNS、讲了TCP握手、讲了HTTP卡在数据怎么从我的电脑跑到服务器上这一步就说不下去了。这恰恰是概述这一章真正要解决的问题它不教你任何一条协议的细节它教的是一张地图告诉你数据在这个系统里要经过哪些关卡、每个关卡由谁负责、关卡之间靠什么衔接。地图没画清楚后面学再多协议也只是背名词。这篇东西面向的是刚接触计算机网络、或者学过一遍但脑子里还是散装知识点的朋友。我会从一次真实的网页加载出发把分层模型、封装解封装、IP与端口、TCP与UDP这些概述阶段的核心概念串成一条线中间穿插我自己踩过的坑和几段可以直接抄下来用的命令。读完你应该能做到看到一个网络故障现象先判断它大概发生在哪一层而不是上来就重启路由器。1. 打开一个网页的三十毫秒里网络概述里的概念全都上场了1.1 从地址栏回车到首字节到达的时间线很多教材讲概述喜欢从计算机网络是连接多台计算机的系统这种定义开始讲完你依然不知道它长什么样。我习惯反过来先看一次真实的访问过程把里面出现的每个角色都标注出来概念自然就落地了。你在地址栏敲下一个域名并回车浏览器做的第一件事不是发数据而是查这个域名对应哪个IP。它先翻自己的缓存再问操作系统操作系统再看本机的hosts文件和DNS缓存都没有才往外发DNS查询。这一步对应的是应用层的活儿只不过DNS本身也是一个应用层协议它跑在UDP的53端口上——注意这里已经出现分层的影子了一个应用层的东西要靠传输层来送。拿到IP之后浏览器要和对方建立连接。如果是HTTP通常是TCP需要三次握手。握手这个过程里你的机器要知道对方的IP、要知道走哪个网卡出去、如果对方不在同一个网段还要知道网关是谁。判断在不在同一网段靠的是子网掩码做与运算这个动作发生在网络层。而真正把帧发到下一个设备的网卡上靠的是MAC地址这属于数据链路层。连接建好浏览器把HTTP请求报文交给操作系统报文一层层加上头部最后变成电信号或者光信号从网卡出去。对方的服务器收到之后一层层剥开处理完再原路返回。整个过程里你的机器可能还经过了家里的路由器、运营商的多台设备、机房的负载均衡器每一跳都在做转发判断。这条时间线上域名解析、连接建立、数据封装、路由转发、解封装、响应返回六个动作分别落在不同的层上。概述这一章要你记住的就是这套分工。1.2 为什么概述这门课值得慢下来啃我见过太多人把概述当成序言翻两页就跳去学TCP三次握手结果学到拥塞控制就卡住了因为他不知道TCP的报文段最终要装进IP数据报IP数据报又要装进以太网帧而以太网帧有1500字节的上限这个上限反过来约束了TCP每次能发多少数据。这条因果链在概述里其实已经埋好了只是当时没人在意。另一个常见的问题是概念混淆。比如有人会问IP地址和MAC地址有什么区别如果他脑子里有分层这张图答案几乎是自动浮现的IP是网络层的逻辑地址负责端到端的寻址可以变MAC是链路层的物理地址负责同一段链路上的下一跳投递出厂就定了。两者不在一个层面上谈不上谁替代谁。所以我的建议是概述这一章不要追求速度要追求建立索引。你不需要记住OSI七层每一层的完整定义但你需要知道遇到一个现象时该往哪一层去找。这个能力在后面排查问题时价值极高——我处理过的网络问题里一多半是有人在应用层的问题上反复折腾网络层配置。提示学习概述阶段与其背物理层传输比特流这种定义不如给自己提一个问题——如果网线坏了现象是什么如果IP配错了现象是什么如果端口没开现象又是什么把现象和层对应起来比背定义有用得多。2. 分层不是画着好看OSI七层与TCP/IP四层到底在解决什么麻烦2.1 分层的真实动机是让改动不外溢教科书上讲分层的好处通常列三条各层独立、灵活性好、易于实现和维护。这些话没错但太抽象理解不了为什么非得这么设计。换个说法。假设没有分层你要实现一个网页访问功能就得自己处理网卡驱动、自己处理信号编码、自己处理路由选择、自己处理丢包重传、自己处理字符编码。这些东西里网卡型号换了你要改代码线路从铜缆换成光纤你要改代码中间经过的某台设备不支持某个特性你还要改代码。一个功能牵动全身根本没法维护。分层就是把这一大坨切成几段每段只对上下相邻的层负责并且约定好接口。网卡换了只要新网卡还符合链路层的接口约定上面的网络层完全不用动。传输介质从双绞线换成无线物理层和数据链路层的实现换了IP层照样工作。这就是改动不外溢。我做项目时体会特别深的一点是分层带来的其实是责任边界。当一个问题出现你先判断它归哪一层管然后只在这个层的范围内排查不必把所有配置翻一遍。这个思维方式比任何具体协议都值钱。2.2 七层没死四层在用两套模型的对照OSI七层模型和TCP/IP四层模型的关系是概述阶段绕不开的一个点。很多人记不住对应关系其实只要理解两套模型的出发点不同就通了。OSI是一个理论参考模型先设计框架再填协议追求完备TCP/IP是先有实现后有模型是从实际运行的协议族里归纳出来的。OSI 七层TCP/IP 四层这一层实际在忙什么典型代表应用层应用层面向具体业务的数据交换HTTP、DNS、SMTP表示层应用层数据格式、编码、压缩、加密字符编码、序列化格式会话层应用层会话的建立、保持与同步会话管理机制传输层传输层端到端的可靠或高效传输TCP、UDP网络层网际层跨网络的路由与寻址IP、ICMP数据链路层网络接口层同一链路上的帧传输与差错检测以太网、PPP物理层网络接口层比特流的电/光/无线信号传输双绞线、光纤、无线电表里能看出来TCP/IP把OSI的上三层合并成了应用层把下两层合并成了网络接口层。合并的原因很实在会话层和表示层在实际协议里很少独立存在它们的职责往往被具体的应用协议顺手做掉了物理层和数据链路层在网卡驱动和硬件里本来就是一起实现的硬拆开意义不大。那为什么还要学OSI七层因为它拆得细用来做问题定位特别顺手。比如页面显示乱码用OSI一看就知道是表示层的事跟网络传输没关系连接老是断可能是会话层或者传输层的事。这套细分框架当诊断工具用比当协议规范用有价值得多。2.3 分层带来的代价也要认分层不是白送的它有成本。最直接的成本是头部开销。你的HTTP请求可能只有几十字节的正文但加上TCP头20字节、IP头20字节、以太网帧头14字节加尾部4字节实际在线上跑的可能是原数据的两三倍。对于小包密集的场景这个开销不小。第二个成本是层与层之间的信息不透明。TCP不知道下面走的是以太网还是无线它只能按最保守的假设来设计应用层也不知道下面的路径质量如何只能靠超时重试来兜底。这种各扫门前雪的设计带来了通用性也带来了优化上的天花板。后来出现的一些跨层优化方案本质上都是在突破这个边界但代价是牺牲了通用性。第三个成本是抽象泄漏。分层理论上应该让你不用关心下层但现实中下层的问题总会冒上来。最典型的就是MTU应用层写了个大报文传输层老老实实分段结果中间某条链路MTU更小包被丢弃现象是小文件能传大文件卡住。这时候你不得不往下看去理解分片和路径MTU发现。所以我的态度是分层是一张有用的地图但别把它当法律。真出问题时该往下钻就得往下钻。3. 数据从你的键盘爬到网线里一次完整封装的拆解3.1 逐层加头应用数据如何变成以太网帧封装是概述里最核心的一个动作理解了它后面所有协议的位置你都清楚了。我用一个具体例子走一遍。假设你的程序要向对方发一段内容长度是100字节。这个过程从应用层开始应用层构造出业务数据比如一个HTTP请求假设整体100字节。这一层的数据单元一般就叫报文。交给传输层如果是TCP它在前面加上TCP头。TCP头最少20字节里面装着源端口、目的端口、序号、确认号、窗口大小、标志位这些信息。加上之后变成120字节这个单元叫报文段。交给网络层加上IP头。IPv4头最少20字节装着源IP、目的IP、协议号标明上层是TCP还是UDP、TTL、校验和等。变140字节这个单元叫数据报或者分组。交给数据链路层加上以太网帧头。帧头14字节包含目的MAC、源MAC和类型字段帧尾4字节是帧校验序列。变158字节这个单元叫帧。最后交给物理层把这158字节变成比特流按线路的编码规则发出去。用一段示意性的结构表示[以太网头 14B][IP头 20B][TCP头 20B][应用数据 100B][帧尾 4B]每一层只关心自己加的那个头也只读取对方同层加的头。网卡不关心里面是不是HTTP路由器不关心里面是不是TCP这就是分层的实际体现。有个细节值得注意TCP头里有源端口和目的端口IP头里有源IP和目的IP这四样东西合起来源IP、源端口、目的IP、目的端口唯一标识一条连接通常叫四元组。这也是为什么同一台机器能同时开多个浏览器标签访问同一个网站——目的IP和端口相同但源端口不同四元组不同连接就能区分开。3.2 MTU与MSS那个1500是怎么卡住一切的以太网帧的数据部分上限是1500字节这个值叫MTU最大传输单元。这个数字不是随便定的早期以太网定这个值是在传输效率和冲突检测之间取的折中后来就成了事实标准。1500字节要装下IP头和TCP头所以TCP能携带的数据最多是 1500 - 20 - 20 1460 字节。这个值叫MSS最大报文段长度。注意MSS不是协商出来的固定值双方在握手时会各自通告自己能接受的MSS实际传输取较小的那个。这个计算在概述阶段就应该弄明白因为后面很多现象都由它引起。比如你发一个3000字节的报文TCP会拆成两个报文段一个1460一个1540不对第二个也得在1460以内所以是1460加1540这种情况不会出现实际是拆成1460和1540以内的合理切分具体取决于实现但每段都不会超过MSS。再比如路径上某一段链路的MTU只有1400而你按1500发的包这个包到了那里就会被丢弃或者被分片。IPv4允许中间设备分片IPv6不允许只能靠源端做路径MTU发现。现象就是能ping通但传不了大数据或者小请求正常上传大文件卡死。这种问题我第一次遇到时排查了很久最后抓包看到需要分片的ICMP消息才反应过来。注意如果你的服务出现小请求正常、大响应超时的规律性现象优先怀疑MTU问题而不是先去查带宽或者代码逻辑。3.3 收包方向解封装与层层校验收包是发包的逆过程但不是简单倒放因为每一层都会做校验和判断。物理层收到信号还原成比特流交给链路层。链路层检查帧尾的校验序列如果对不上直接丢弃不会往上报。这一步能挡住线路噪声造成的错误。校验通过后看帧头的类型字段知道里面是IP就剥掉帧头帧尾交给网络层。网络层检查IP头的校验和看目的IP是不是自己。如果不是自己且本机开启了转发就往下一跳送如果是自己就看协议号TCP就交给传输层。这里还会做TTL减一TTL减到0就丢弃并回一个ICMP超时消息——traceroute就是靠这个机制工作的。传输层根据目的端口找到对应的进程检查序号处理乱序和重传。如果是TCP还要回确认。校验通过后把数据交给对应的应用。应用层拿到数据按自己的协议解析。这中间每一层的校验范围是不一样的。链路层校验的是整个帧网络层只校验IP头IPv4如此IPv6干脆取消了头部校验和传输层校验头加数据。这种分工也反映了各层的关注点链路层保证这一段链路没传错网络层保证头部没被改坏传输层保证端到端的数据完整。4. 把抽象摁到地上五个命令行工具和一次抓包实录4.1 定位问题的工具顺序从域名到端口概述讲完最容易出现的状态是概念都懂一遇到问题就懵。我的经验是建立一套固定的排查顺序从上层往下走每一步都有对应的命令。第一步确认域名能不能解析。用nslookup或者dig查一下看返回的IP是不是你期望的。如果解析不出来后面所有事都不用谈。这一步能排掉一大类网站打不开的问题——很多时候根本不是网络不通是DNS配错了或者缓存了旧记录。dig example.com short nslookup example.com第二步确认到目标IP的连通性。ping发的是ICMP回显请求能通说明网络层是通的。但这里有个大坑ping不通不代表服务不可用。很多服务器为了安全会禁掉ICMP但80端口照样开着。反过来ping通了也不代表端口通这是新手最容易搞混的。ping -c 4 203.0.113.10第三步确认端口通不通。telnet是个老工具但很直观或者用nc。这一层通了说明TCP握手能完成应用层至少有个进程在监听。nc -zv 203.0.113.10 80第四步看本机的连接状态。ss或者netstat能看到当前有哪些连接、处于什么状态。排查连接数打满、大量TIME_WAIT这类问题全靠它。ss -tanp | head -30 ss -s第五步看路由。traceroute或者 Windows 下的tracert能看到数据包经过的每一跳。如果在某一跳之后全部超时问题大概率出在那里。traceroute 203.0.113.10这五步走下来绝大多数连不上的问题都能定位到具体层面。关键是顺序不能乱从域名到IP到端口到连接状态正好对应着从应用层往下走的路径。4.2 抓一次自己的包tcpdump实操与观察点命令行工具能看到结果但看不到过程。想真正理解封装抓一次包是最快的途径。在Linux上tcpdump基本是标配。假设我要抓一次对本机某端口的访问可以这样sudo tcpdump -i any -nn -s 0 -w capture.pcap port 8080参数的含义-i any监听所有网卡-nn不做域名和端口名的解析避免额外的DNS查询干扰-s 0抓完整包不截断-w写入文件方便后面用图形工具看。抓够了自己按 CtrlC 停掉。如果只是想快速看一眼不加-w直接输出到终端也行sudo tcpdump -i any -nn -A port 8080-A会把包内容按ASCII打印出来能看到HTTP报文长什么样。我第一次看到自己的HTTP请求头和响应头就这么明文躺在终端里时对应用层数据被封装进传输层这句话才算有了实感。抓下来的包可以用图形化工具打开分析也可以用tcpdump -r回读。回读时加上-X能以十六进制加ASCII的形式显示方便看头部字段。tcpdump -r capture.pcap -nn -X | head -604.3 抓包时该盯哪几个字段打开一个包字段几十个新手容易看花眼。我给自己的习惯是先看四个地方第一看帧头的类型字段判断上层是IPv4还是IPv6还是ARP。如果抓到的是ARP包说明此时还在做地址解析连接根本没开始。第二看IP头的TTL和协议号。TTL能大致推断包走了多远协议号能确认上层是TCP6还是UDP17还是ICMP1。第三看TCP的端口和标志位。三次握手的过程在抓包里非常清晰第一个包是SYN第二个是SYN加ACK第三个是ACK。如果只看到SYN没有回应说明对方没开端口或者被拦了如果SYN发出后收到RST说明端口没在监听。第四看应用层内容。HTTP是明文的直接能读。如果是HTTPS看到的就是加密后的字节这时候只能看握手阶段的协商信息。还有一个观察点经常被忽略时间戳。两个包之间的时间差能反映很多问题。比如握手第一个包发出去到收到回应花了800毫秒说明网络往返延迟不低如果重传的间隔是明显的1秒、2秒、4秒递增那就是典型的超时重传。提示抓包时先设过滤条件再开始不要抓全量。一次抓几万个包回读的时候光筛选就够你喝一壶。常用的过滤写法直接在命令里加比如port 80、host 203.0.113.10、tcp[tcpflags] tcp-syn ! 0。5. 新手最容易拧巴的五组概念5.1 IP与MAC一个是终点站一个是下一跳这两个地址经常被混为一谈因为都叫地址都是数字串。区别在于它们服务的范围不一样。IP地址是逻辑地址它的作用是在整个互联网范围内标识一台主机让数据能从源头找到终点。它是可以变的换网络环境就会变也可以手工配置。MAC地址是物理地址烧在网卡里理论上全球唯一作用是在同一段链路上把帧从一台设备送到另一台设备。它不关心最终目的地是哪里只关心下一跳交给谁。一个类比IP地址像收件地址写的是最终要送到哪个城市哪条街MAC地址像每一段运输的交接单快递从仓库到分拣中心、从分拣中心到网点、从网点到快递员每一次交接都换一个人但收件地址始终不变。这也解释了为什么跨网段通信时目的MAC不是最终服务器的MAC而是网关的MAC。你的机器判断出目标IP不在本网段就把包发给网关帧头的目的MAC填网关的MAC。到了网关它再重新封装换一个新的目的MAC指向下一跳。整个过程中IP头基本不变除了TTLMAC头跳跳都换。MAC地址靠ARP协议获取。你的机器要发给某个IP先在本网段广播一个ARP请求问谁是这个IP对方回应自己的MAC。这个结果会缓存一段时间可以用arp -a或者ip neigh查看。缓存过期或者条目缺失就会出现IP能ping通但网页打不开这种诡异现象本质是ARP没解析出来。5.2 端口与进程门牌号和屋里的人IP地址定位到主机端口定位到主机上的具体服务。这个概念本身不难难的是几个细节。第一个细节端口号范围是0到65535其中0到1023是知名端口需要管理员权限才能绑定。HTTP是80HTTPS是443SSH是22DNS是53。1024到49151是注册端口49152以上是动态端口通常由系统在建立连接时临时分配。第二个细节一个端口同一时刻只能被一个进程监听除非用了特殊的复用选项。这就是为什么你启动服务时经常遇到端口已被占用。查谁占用了端口sudo ss -tlnp | grep 8080 sudo lsof -i :8080第三个细节监听地址的选择很关键。绑定127.0.0.1只有本机能访问绑定0.0.0.0所有网卡都能访问。我见过不少人本地测试没问题一部署到服务器就外部访问不了最后发现是代码里写死了127.0.0.1。第四个细节客户端的源端口是系统随机分配的一般不用管。但如果你的程序要发起大量连接可能会把本地端口耗尽这时候需要调整系统的端口范围或者复用参数。这个坑在做压力测试时特别容易踩。5.3 TCP与UDP可靠不是免费的概述阶段讲这两个协议往往只给一句TCP可靠、UDP不可靠然后就没了。这个说法不算错但没说清楚代价导致很多人无脑选TCP。TCP的可靠是靠一整套机制堆出来的建立连接要三次握手传输过程要序号确认、超时重传、流量控制、拥塞控制断开要四次挥手。这些机制带来了正确性也带来了延迟和开销。一次简单的请求响应TCP至少要经历握手的一个往返加上数据传输的一个往返稳妥但慢。UDP什么都不保证发出去就不管了不建连接、不重传、不排序。听起来很糟糕但在某些场景下恰恰是优点DNS查询就一个包一问一答为它建连接纯属浪费实时音视频宁可丢几帧也不愿意等重传因为等来的数据已经过期了游戏的位置同步也是同样道理。对比项TCPUDP连接方式面向连接需握手无连接直接发可靠性确认加重传保证送达不保证送达顺序性保证按序交付不保证顺序头部开销最少20字节8字节传输效率相对低相对高典型场景网页、文件传输、数据库连接DNS、实时音视频、游戏同步选型的判断标准其实就一句话你能否容忍丢数据以及能否自己在应用层处理丢数据。如果两者都不能用TCP如果能容忍或者能自己处理UDP往往更合适。现在很多实时传输方案在UDP之上自己实现了一套可靠性机制就是为了在完全可靠和完全不管之间找个平衡点。5.4 网关、子网掩码与为什么我ping不通邻居这三个词单独看都懂凑一起就容易糊涂。我用一个具体场景说明。假设你的机器IP是192.168.1.10子网掩码是255.255.255.0网关是192.168.1.1。现在你要访问192.168.1.20。系统先用掩码做与运算算出自己的网络号是192.168.1.0再算目标的网络号也是192.168.1.0。两者相同说明在同一个网段于是直接用ARP问192.168.1.20的MAC直接把帧发过去不经过网关。如果目标变成192.168.2.20网络号算出来是192.168.2.0跟自己不一样说明跨网段。这时候不能直接发得交给网关。于是ARP问网关192.168.1.1的MAC把帧交给它由它继续转发。这个判断逻辑解释了两种常见故障。第一种掩码配错了。比如你的掩码写成255.255.255.192那192.168.1.10的网络号变成192.168.1.0但192.168.1.100的网络号变成192.168.1.64两者不同网段你就得走网关而网关可能不认识这个目标于是不通。第二种网关配错了或者没配。跨网段的包发不出去现象就是能访问同网段的其他机器访问外网全失败。还有一种情况是网关本身不通。你的包发出去了但网关那台设备没开转发、或者回程路由没配好包能出去回不来。这时候用traceroute看往往第一跳之后就没动静了。排查这类问题的顺序我一般是这样先ip addr看自己的IP和掩码再ip route看路由表里默认网关在不在然后ping网关看二层通不通最后traceroute看外部路径。这四步基本能定位到是配置问题还是链路问题。5.5 localhost、127.0.0.1、0.0.0.0的区别这三个写法在配置里天天见但含义完全不同混淆了会出大问题。localhost是一个主机名它通常被解析到127.0.0.1但严格来说它只是一个名字具体解析成什么由 hosts 文件和解析器决定。理论上你可以把它改成别的地址虽然没人这么干。127.0.0.1是回环地址属于127.0.0.0/8这个网段。发往这个地址的数据不会经过物理网卡直接在协议栈内部绕一圈就回来了。它的作用是本机自测即使网线拔了也能用。0.0.0.0在监听场景下表示所有本机地址绑定了它意味着任何网卡上收到的发往本机端口的请求都会接受。在路由场景下它表示默认路由或者任意地址含义要看上下文。最容易出错的是第一个和第三个的混用。比如某个服务配置文件里写了listen 127.0.0.1:8080你在本机用浏览器访问一切正常但从另一台机器访问就超时。原因就是它只监听了回环地址外部请求根本到不了。改成0.0.0.0:8080就好了。反过来也有风险把只该内部访问的服务绑到0.0.0.0等于暴露给了整个网络。所以这不是个纯技术问题配置时想清楚这个服务该让谁访问比记住这三个写法的区别更重要。6. 概述学完之后怎么不还给老师三个能落地的练法6.1 用一台机器模拟一张小网看完概念不动手过两周就忘光。我建议的第一个练法是用一台机器造出两个网络让它们互相通信观察每一层的表现。具体做法是建两个虚拟网卡分别配上不同网段的地址然后用策略路由让它们互通。或者更简单一点起两个容器各自配一个网段中间用一个转发规则连起来。这个过程里你会被迫去理解路由表、转发开关、地址规划这些概念比看十遍书管用。操作完之后可以验证几件事从A网段ping B网段的地址能不能通把转发开关关掉会怎样把路由表里的某条删掉会怎样。每次改动都抓包看看发生了什么观察ARP请求、观察TTL的变化、观察ICMP的错误类型。这种改一下、看一看的循环建立起来的理解最牢固。6.2 自己写一个最小可用的收发程序第二个练法是自己写一个最简单的客户端和服务端不要用现成的框架直接调用socket接口。哪怕只有几十行你也会被迫面对几个问题服务端要不要绑定0.0.0.0listen的 backlog 参数是什么accept之后拿到的地址是什么客户端要不要显式关闭连接关闭的时候会不会产生TIME_WAIT。写完之后把服务端换成UDP版本你会直观感受到两者的差别不需要listen、不需要accept、没有连接状态、一次recvfrom就能拿到数据和对方地址。这种对比比任何表格都深刻。再进一步可以故意制造一些异常。比如服务端处理到一半直接退出看客户端收到的是什么比如把发送的数据调大超过MSS看TCP怎么拆分比如在中间加一个人为的延迟看超时重传的间隔规律。这些实验做下来概述里那些抽象描述就都变成了你能观察到的事实。6.3 建立故障分层排查的肌肉记忆第三个练法是刻意训练排查顺序。我给自己定了个规矩遇到网络问题先不猜原因先按层走一遍。物理和链路层网线插了没网卡状态是不是UPip link看一眼。同一网段的机器能不能ping通能通说明链路和二层没问题。网络层ip addr看地址掩码ip route看路由ping网关看能不能出去traceroute看路径在哪断。传输层nc探端口ss看连接状态看有没有大量SYN_RECV或者TIME_WAIT。应用层前面都通了还不 work那就是应用自己的问题去看日志、看配置、看代码。这套流程走熟了之后排查速度会快很多因为你不会在错误的层面上浪费时间。我最开始犯的错就是不管什么现象都先重启服务重启完有时候好了有时候没好根本没定位到原因下次还会犯。最后分享一个我自己的体会。学网络概述这类基础内容最大的误区是把它当成入门前的准备工作想着快点看完去学更酷的东西。实际上这一章建立的是整个知识体系的坐标系后面每学一个协议你都要把它往这个坐标系里放。坐标系歪了后面学得越多越乱。所以宁可在这里多花点时间把分层、封装、寻址这三件事想透后面会省下大量返工。我自己到现在还保留一个习惯遇到一个新的网络现象先在纸上画一遍数据流向从哪台机器的哪个端口出发经过哪几层封装中间跨了几个网段每一跳的目的地址是什么。画完往往问题就清楚了。这个习惯不高级但好用。
