计算机网络这东西大学里基本都开课但很多人学完一学期路由协议和传输层机制背了一堆回头问自己“到底什么是计算机网络”反而说不清楚。不是大家不努力是教材和课程太喜欢把知识点切成碎片导致学完脑子里只有概念名词没有一张能串起来的地图。这篇文章就是想把这张地图补上。我用“端到端传输一条数据”作为贯穿始终的主线从宏观架构到微观细节把计算机网络的基础知识重新串一遍。适合正在学计网但觉得知识很散的初学者也适合准备面试想快速把基础框架捞回来的同学。文章不追求覆盖所有边角知识点但凡是基础框架里的关键环节都会讲清“是什么、为什么这么设计、实际怎么工作”。1. 整体认知先搞懂网络是“分层协作”不是“单点传输”学计算机网络第一件事不是背协议而是建立“分层”的思维模型。网络里参与通信的设备太多、链路太杂、应用需求又各不相同如果所有逻辑都揉在一起设计任何一个小改动都会牵一发动全身。1.1 分层的本质把复杂通信拆成可独立演进的子问题你可以把网络通信想象成寄快递。你应用层只需要写好收件地址和包裹内容剩下的交给快递公司。快递公司内部又分若干环节有人负责规划干线运输路线网络层有人负责把包裹送到本地网点链路层有人负责实际扛包裹上车物理层。每一层都只管自己这一段不用关心其他环节怎么实现。OSI七层模型就是这种思想的极致化但实际工业界跑的是TCP/IP四层模型。这四层是应用层HTTP、DNS、FTP这类面向用户的协议传输层TCP、UDP负责进程到进程的通信网络层IP、ICMP、路由协议负责主机到主机的寻址和路径选择网络接口层以太网、Wi-Fi等负责把数据变成能在物理介质上传输的信号这里有个很多初学者会问的问题既然OSI七层是国际标准为什么实际用的是TCP/IP四层答案很现实OSI模型设计太完美了但市场被TCP/IP先占领了。TCP/IP的“瘦身”设计反而成为优势——层数少实现简单迭代快。所以现实世界不会因为理论模型更优雅就采用它兼容性和生态才是王道。1.2 数据流动的完整路径从应用到网线再到应用理解了分层架构再看一条数据是怎么走完整个旅程的。假设你在浏览器输入一个网址并回车应用层浏览器构造HTTP请求报文包含请求行、请求头、请求体传输层TCP协议给这份数据加上端口号切分成合适的报文段并建立可靠连接网络层IP协议给每个报文段加上源IP和目标IP形成数据报并查询路由表决定下一跳链路层数据报被封装成帧加上源MAC和目标MAC通过ARP协议获取物理层帧被转换成电信号或光信号在网线/光纤/无线电中传输接收方收到数据后从物理层往上逐层解封装每层剥离自己的头部信息最终把原始数据交给目标进程。这个流程的核心要点是每一层只处理自己负责的头部字段其他层的数据对它是透明的。这种设计让网络协议可以独立演进——比如IPv4升级到IPv6只需要网络层的实现改动应用层完全无感知。2. 核心机制拆解IP寻址、MAC地址与ARP的工作细节分层框架搭起来了接下来要填最核心的机制——寻址。网络里每次通信本质上是回答三个问题对方在哪、怎么找到路径、数据怎么正确交付。2.1 IP地址逻辑寻址的“门牌号”体系IP地址是网络层的核心它解决的是“主机在网络中的唯一标识”问题。以IPv4为例地址长度32位通常写成点分十进制比如192.168.1.100。但光有地址还不够必须配套子网掩码才能知道哪些主机在同一个局域网内。子网掩码的作用是区分网络号和主机号。比如255.255.255.0表示前24位是网络号后8位是主机号。为什么要有这个区分因为路由决策依赖它。当一台主机要发送数据时先判断目标IP和自己是否在同一子网如果在同一个子网直接通过ARP找目标MAC二层交付如果不在同一个子网则把数据交给默认网关由路由器进行三层转发这个判断逻辑是网络通信中最基础也最容易被忽视的环节。很多网络不通的故障查到最后就是子网掩码配置错误导致主机把本应走网关的数据包在局域网里盲目广播。另外还得提一下IPv6。IPv4地址长度32位总数约43亿而IPv6长度128位地址空间几乎取之不尽。但IPv6不是简单地把地址变长还重构了报文头部结构去掉了校验和字段、把分片机制移到端节点处理整体转发效率更高。现在很多运营商已经大规模部署IPv6但校园网和企业内网依然是IPv4为主所以基础学习阶段IPv4仍然是要花最多精力的部分。2.2 MAC地址与ARP协议本地网内怎么找到具体设备MAC地址是链路层的寻址标识出厂时烧录在网卡上48位长度通常写作16进制形式比如00:1A:2B:3C:4D:5E。这里必须区分MAC地址和IP地址的职责边界。IP地址解决的是“逻辑上这台主机属于哪个网络”它是可变、分层、可规划的MAC地址解决的是“物理上这块网卡是谁”它是固定、扁平、不可跨网段路由的。那怎么根据IP地址找到对应的MAC地址靠ARP协议。这个过程很巧妙主机A要发数据给主机B发现B在同一个子网A先查自己的ARP缓存表看是否有B的IP到MAC映射如果没有A在局域网内广播一个ARP请求“谁的IP是192.168.1.50请把你的MAC地址告诉我”只有IP匹配的主机B会回复ARP应答携带自己的MAC地址A收到后把这个映射写入ARP缓存同时把数据帧封装好发送出去这里有个常见概念混淆ARP只在同一广播域内有效。不同网段的设备通信不靠ARP直接找目标MAC而是先把帧发给网关路由器由路由器在下一个网段再发起ARP查询。还有个安全层面的点值得说ARP协议本身没有任何认证机制所以局域网内任何主机都可以伪冒IP地址回复ARP应答这就是ARP欺骗攻击的原理。基础的防御手段是配置静态ARP表项或使用交换机端口安全功能。这算是网络基础里很有现实价值的一个细节。2.3 路由转发跨网段时数据怎么一步步到达目的地当目标主机不在同一个子网时数据包要经过路由器逐跳转发。路由器的核心工作有两件维护路由表、执行最长前缀匹配。路由表的来源有三类直连路由路由器自己接口所在网段自动生成静态路由管理员手动配置动态路由通过RIP、OSPF等路由协议自动学习转发决策时的匹配规则是最长前缀匹配。所谓最长前缀就是在路由表多条表项都能匹配目标IP时选择子网掩码最长的那一条。这个机制保证路由决策尽可能精细和准确。举个例子路由表里有两条表项目标网段子网掩码下一跳192.168.1.0255.255.255.0172.16.0.1192.168.1.128255.255.255.128172.16.0.2如果目标IP是192.168.1.200两条表项都能匹配此时选择第二条因为掩码更长、范围更精确。很多学网络的同学在路由这块容易钻牛角尖纠结路由器到底怎么算出路径的。其实基础阶段不需要手推路由算法只需要理解路由器之间通过路由协议交换网络可达性信息经过一段时间的收敛每台路由器都会形成一张全局的、无环的路由表。至于RIP基于跳数、OSPF基于链路状态、BGP基于路径属性这些细节是进阶内容但理解了“交换信息→计算路由→收敛稳定”这个总流程后面的学习会轻松很多。3. 传输层精讲TCP的可靠性设计、UDP的轻量哲学网络层负责把数据送到目标主机但主机上同时跑着几十个进程——浏览器、游戏客户端、即时通讯工具。数据到了主机之后怎么确定交给哪个进程这是传输层的核心问题。3.1 端口号与连接标识一个连接的四元组定位传输层用端口号来区分不同进程。HTTP默认80端口、HTTPS默认443端口、DNS使用53端口这是知名端口号。客户端这边通常使用随机分配的临时端口范围一般是1024到65535。一个完整的TCP连接是靠四元组唯一标识的——源IP、源端口、目标IP、目标端口。这四元组中任何一个元素变化都代表一个不同的连接。这也是为什么多台设备可以共享同一个公网IP上网因为内网IP和端口映射后每个连接的四元组仍然不同。这个设计在排查网络问题时特别实用。有时候两台服务器之间连接不通先用netstat查看四元组状态就能判断是客户端侧问题还是服务端侧问题是端口被防火墙拦截还是服务没监听。能理解四元组网络问题排查就多了一根很有效的拐杖。3.2 TCP可靠传输三板斧序号、确认、重传TCP和UDP最本质的区别是可靠性。TCP提供面向连接的、可靠的字节流服务核心机制可以概括成三个词序号、确认、重传。发送方给每个字节都编上序号接收方收到数据后回复确认号表示“我期望收到的下一个字节编号是多少”。如果发送方在超时时间内没有收到确认就会重传对应的数据。这里有个必须理解清楚的细节TCP的确认是累计确认。接收方不需要对每个包单独确认只需要确认最后一个连续收到的字节。例如收到1到1000字节确认号就是1001。这意味着前序任何一个字节丢失接收方的确认号都不会前进发送方只能重传丢失点之后的所有数据。这种机制简化了协议的实现但代价是在高丢包率的网络里可能造成不必要的数据重传。超时重传的时间设置也很有讲究称为RTO。RTO太短会导致大量不必要的重传把本已拥堵的网络压垮太长则让丢包后恢复过慢。TCP用采样RTT并加权平均的方式动态调整RTO这个思想理解起来不难用历史往返时间做平滑估计再加上一个安全余量。在后来的TCP演进中又出现了快速重传、选择性确认等优化机制但底层思路没有脱离“序号确认重传”这个铁三角。面试中问TCP可靠性只要按这个框架回答就已经抓住了本质。3.3 流量控制与拥塞控制千万别混为一谈TCP里最容易混淆的两个概念是流量控制和拥塞控制。虽然它们都是控制发送速率但角度完全不同。流量控制是端到端的作用于接收方和发送方之间。接收方会把自己的接收缓冲区剩余空间大小通过窗口字段告诉发送方发送方据此控制发送量不能超过对方的接收能力。拥塞控制是端到端中体现全局状态的一种策略作用于网络链路。TCP无法直接探测网络内部的拥塞程度只能通过丢包和延迟来推断。经典算法是慢启动、拥塞避免、快速重传和快速恢复。慢启动的思想很有意思发送方一开始不知道网络能承受多大速率先从一个很保守的窗口开始比如初始拥塞窗口为10个报文段每经过一个RTT窗口翻倍增长。这个“翻倍”是指数增长速度很快所以要设定一个慢启动阈值。达到阈值后进入拥塞避免阶段窗口改为线性增长每次RTT只增加一个报文段。如果检测到拥塞通常以丢包为标志慢启动阈值降为当前窗口的一半拥塞窗口重置或减半重新开始增长。这套“加性增、乘性减”的逻辑本质是在探测网络容量的同时保持对拥塞的敬畏。在现实网络中真正的主宰其实是拥塞控制流量控制只有在接收方处理不过来时才真正起作用。很多面试者会把两者混着说但只要记住“流量控制管接收方窗口拥塞控制管网络容量探测”就不会乱。3.4 UDP放弃可靠换实时UDP和TCP完全是两种哲学。没有连接建立、没有确认重传、没有拥塞控制发送方只管把数据丢出去。正因为省掉了这些开销UDP的头部只有8个字节处理延迟极低。UDP适合什么场景实时性要求高、可以容忍一定程度丢包的场景。典型如音视频通话、在线游戏、直播流媒体。这些场景里迟到且重传的数据包反而会造成画面卡顿和口型不同步用户宁愿丢了几帧也不要卡住等重传。DNS查询也是UDP的典型场景。一个请求一个响应如果响应丢了客户端会重新发起查询用TCP反而显得杀鸡用牛刀。不过UDP也不是完全不做任何保护它的头部同样包含校验和字段可以发现数据在传输过程中是否被破坏。只是发现后它选择直接丢弃而不是重传。4. 网络核心协议HTTP的演进与DNS的工作流程如果说IP和TCP是网络的物流系统那HTTP和DNS就是物流系统的业务入口。普通用户能感知到的网络行为绝大部分都发生在这一层。4.1 HTTP协议基础无状态设计与请求响应模型HTTP是应用层协议采用请求响应模型。客户端发起请求服务端返回响应。这个模型简单直接但有一个重要特性——无状态。无状态的意思是服务端不会主动保存客户端的历史请求信息。每次请求都是独立的上一次是谁发的、发过什么服务端不会自动关联。无状态设计的好处是服务器实现简单、易于横向扩展因为不必维护会话状态。但是现代应用又需要识别登录用户怎么办解决方案是在协议之上引入会话技术。经典方案是Session和Cookie。服务端保存会话数据生成一个会话ID下发到客户端的Cookie里后续请求自动携带这个Cookie服务端就能识别用户身份。还有一个近年很重要的演进值得提一下HTTP从1.1到2.0再到3.0的核心变化。HTTP/1.1存在队头阻塞问题——一个连接里前面的请求没返回后面的请求即使已经处理完也只能排队。HTTP/2引入多路复用在一个TCP连接上并发传输多个请求响应解决了应用层的队头阻塞。但HTTP/2仍然有传输层的队头阻塞隐患因为TCP保证顺序一个TCP丢包会导致后续所有请求被阻塞。HTTP/3干脆把底层换成了UDP之上的QUIC协议在用户态实现可靠传输和有序交付彻底绕开了TCP的传输层队头阻塞问题。这个演进过程很适合用来理解协议设计中的现实权衡每次协议版本更新都是在兼容性、性能、复杂度之间重新寻找平衡点。4.2 HTTPS加密流程握手阶段如何安全地协商密钥HTTPS的本质是HTTP加了一层TLS加密。为什么不能直接用对称加密因为客户端和服务端初次通信彼此不认识需要一种方式安全地协商出共享密钥。这个过程用了混合加密策略客户端向服务端发起握手请求附带客户端支持的加密套件列表服务端返回证书和选定的加密套件客户端验证证书的合法性——证书是否由受信任的CA签发、证书域名是否匹配、是否在有效期内验证通过后客户端生成一个随机密钥用服务端证书中的公钥加密后发送给服务端服务端用私钥解密得到对称加密密钥后续通信全部使用这个协商出的对称密钥加密数据为什么需要混合加密这里有很好的设计哲学。如果全程只用非对称加密性能太差非对称加密的运算量比对称加密大几个数量级如果全程只用对称加密密钥没法安全地传给对方。混合策略中非对称加密只用来安全地传输对称密钥数据通信则交给对称加密高效完成。另一个容易忽略的点是证书验证。为什么客户端能信任服务端证书因为证书链最终要追溯到信任根证书。根证书内置在操作系统或浏览器中由权威机构维护。一旦某个根证书被篡改基于它的整个信任体系就崩溃了所以根证书的保管极其严格。4.3 DNS解析过程从域名到IP的完整链路DNS可能是网络上“每天都被使用、但很少有人完全理解”的协议之一。你输入域名系统返回IP过程看起来是瞬间完成的背后却是一套精心设计的分布式缓存体系。解析过程大概是这样的浏览器先查本地DNS缓存看之前是否解析过这个域名没命中则查询操作系统层面的hosts文件和本地DNS解析器缓存还是没命中则请求本地配置的DNS服务器通常是运营商或公共DNS服务器本地DNS服务器如果也没有缓存就开始递归查询——先向根服务器询问顶级域服务器的地址再向顶级域服务器询问二级域服务器的地址最后向权威服务器获取域名对应的IP记录这套设计最关键的地方在于“缓存”和“分级”。全球DNS服务器数量非常多如果每次解析都从根节点查起延迟和负载都不可接受。通过各级缓存绝大多数域名解析在本地DNS服务器这一层就能直接命中整个互联网的解析压力因此被大幅削减。还有个值得一提的细节是DNS的TTL也就是每条DNS记录的缓存有效期。设置太短解析压力增大设置太长域名IP变更后生效慢。站在运维角度这个参数直接影响故障切换速度属于“虽然小但很关键”的配置项。5. 一个请求的完整旅程从键入网址到页面渲染前几节把各层协议拆开讲了现在把它们重新拼回去走一遍完整的请求旅程。这一部分对初学者建立全局观极有帮助。我习惯把这个过程称为“一次HTTP请求的解剖”。5.1 输入网址后DNS解析与会话建立用户在浏览器输入网址并按回车第一步不是建立TCP连接而是要拿到目标服务器的IP地址。DNS解析完成后浏览器拿到了IP开始建立TCP连接。TCP建立连接的过程是三次握手客户端发送SYN报文携带初始序号服务端收到后回复SYNACK报文同时携带自己的初始序号客户端收到后回复ACK报文连接建立为什么非要三次而不是两次核心原因是防止失效的旧连接请求突然到达服务端造成资源浪费。两次握手的情况下一个早已超时失效的SYN如果被服务端收到并回复ACK连接就建立了但客户端根本没发起这个请求资源就被白白浪费。三次握手能确保双方都确认对方具备收发能力这是可靠通信的认识前提。连接建立后浏览器才能发送HTTP请求报文。注意从输入网址这个动作来看HTTP请求的发送已经在TCP连接建立之后了因为HTTP依赖TCP的可靠性。5.2 数据传输中HTTP请求、代理与网关的角色HTTP请求报文从应用层往下传递经过传输层加TCP头、网络层加IP头、链路层加帧头和帧尾最终变成比特流通过交换机和路由器一步步转发。这里要注意一个很容易被忽视的角色——代理服务器。浏览器通常不会直接把请求发到目标服务器而是先发给代理服务器由代理决定放行还是拦截、是否有缓存、是否需要修改请求头。正向代理代表客户端发起请求隐藏真实客户端反向代理则站在服务端一侧对外表现为服务器本身背后可能负载均衡到多台真实服务器。反向代理解决了个关键问题真实服务器的IP不能轻易暴露否则容易成为攻击目标。另外一个域名背后可能有几十台服务器客户端只需要和反向代理通信由代理分发请求这就实现了负载均衡。这些在基础框架里虽然不展开细说但理解一个请求的旅程时必须意识到中间是会经过代理和网关的不能把网络理解成简单的“端到端直连”。5.3 响应返回后解封装、页面渲染与TCP拆除服务端处理完请求后返回HTTP响应报文。响应报文包含状态行、响应头和响应体。状态码是排查问题的重要抓手——200表示成功301/302是重定向403表示禁止访问404是资源不存在500是服务器内部错误。响应数据回到浏览器后浏览器开始解析HTML、CSS和JavaScript构建DOM树、CSS规则树然后进行布局计算和绘制。如果页面里有额外资源浏览器会再次发起HTTP请求。这也是为什么现代网页一次打开会产生几十甚至上百个HTTP请求的原因。连接用完之后要释放。TCP拆除连接的过程是四次挥手因为TCP是全双工的双方的数据收发通道需要分别关闭。关键点是TIME_WAIT状态——主动关闭方在收到对方的FIN并回复ACK后会进入TIME_WAIT状态持续两个最大报文段生存时间。设计这个状态是为了确保最后的ACK能送达对方同时让旧连接的重复报文自然消亡不会污染新连接。很多服务端故障排查都和TIME_WAIT相关比如高并发短连接场景下大量连接处于TIME_WAIT导致端口资源耗尽。理解了四次挥手和TIME_WAIT的必要性这类问题就很好定位了。6. 常见故障与排查思路基础网络题的分层诊断法学了协议和原理最终要落到一个能力上遇到网络不通能快速定位问题在哪一层。我个人最喜欢用的排查策略是“自底向上逐层验证”。6.1 从物理层到应用层的自检清单先确认最底层。检查网线是否松了、Wi-Fi是否已连接、网卡状态是否启用。物理层的问题最呆但发生率不低。金属外壳接触不良、网线水晶头氧化、无线网卡驱动异常都可能让你在高层排查半天。然后测试链路层和网络层连通性。最常用的命令是ping。ping基于ICMP协议能测试本机到目标主机的基础连通性。如果ping不同基本确定问题在网络层或以下如果ping通了但浏览器打不开网页问题大概率在传输层以上。再进一步测试端口连通性。可以telnet目标IP端口或使用nc命令。这一步能验证TCP连接能否建立判断是端口未监听、防火墙拦截还是访问控制列表限制。应用层的问题就靠业务日志和接口测试来观察了。常见的应用层故障包括服务进程挂了、负载均衡健康检查失败、应用代码逻辑异常、DNS解析到了错误地址。6.2 典型问题速查抓包配合分层逻辑定位真实世界中网络问题往往不是单点故障而是多个环节叠加。举两个我实际排过的例子。某次同网段内的终端访问内部服务时断时续。ping网关正常ping服务器时好时坏。用抓包工具观察后发现大量ARP广播和重复IP冲突提示。最后定位到是有人把个人设备接入了同网段且使用了相同的IP导致ARP表不停震荡。处理方式是静态绑定IP和MAC地址冲突就消失了。另一次是跨网段访问特别慢。ping延时不异常但下载文件速率上不去。抓包发现TCP窗口持续很小且伴随大量重复确认。进一步分析是链路上有设备在做流量整形限制了特定的流。这个层面的问题靠ping是看不出端倪的必须分析TCP连接状态和窗口变化。这里给初学者一个实用建议遇到问题不要跳层排查。物理层没确认好就直接改路由表很容易扩大排查范围把自己绕晕。按层逐级排查看起来慢实际是最快路径。排查层次常用命令/工具典型问题物理层检查网卡状态、网线连接网线松动、无线信号弱链路层ipconfig /all、arp -a地址冲突、ARP缓存错误网络层ping、traceroute路由丢失、防火墙拦截传输层telnet、nc、netstat端口未监听、连接超时应用层curl、浏览器开发者工具、日志DNS错误、服务异常、响应超时6.3 必须养成的排障习惯抓包看证据不要猜遇到疑难问题很多人的反应是“重启一下试试”。重启确实能解决一部分问题但无法告诉你根因。真正养成的好习惯是抓包看证据。抓包工具有很多图形界面最常用的是Wireshark命令行环境可以用tcpdump。抓包时的原则是尽量在靠近问题点的位置抓比如客户端和服务端都抓。通过对比两侧的包能判断丢包发生在哪个方向、确认是否收到了对方的响应、重传是不是因为中间链路丢包。基础阶段不需要事事都抓包但至少应该建立“用证据说话”的意识。网络协议栈是一个极其讲究逻辑的系统每个字段、每个状态转换都有明确的设计意图。当排障进入僵局时回到抓包数据里找线索往往比在脑子里空想更有效。7. 补遗与心得哪些知识看似冷门但实际很常用写到这里基础框架已经覆盖得差不多。最后补几个我实际工作中发现“教材里篇幅不大、但工程里天天遇到”的知识点。7.1 NAT与端口映射为什么内网设备能共享外网IPNAT即网络地址转换是解决IPv4地址不够用的重要机制。家庭路由器都使用NAT功能内网设备使用私有IP地址路由器对外使用运营商分配的一个公网IP。内网设备访问外部网络时路由器把源地址替换成公网IP同时记录映射关系回程数据再转换回内网IP。这个机制的细节里有一个技术点值得注意NAT不仅转换IP还转换端口。因为多个内网设备共享同一个公网IP必须靠端口号区分不同的会话。所以完整叫法是NAPT——网络地址端口转换。NAT带来的一个经典问题是外网无法主动访问内网设备。因为路由器不知道内网哪台设备想接收连接。需要内网主动建立一个到外网的连接映射关系才会存在。这也是很多家庭用户搭建外部可访问服务时需要配置端口映射的原因——手动告诉路由器“收到外网某端口的流量转发给内网某台设备的某端口”。7.2 CIDR与子网划分看起来数学实际上规划CIDR即无类别域间路由是现代IP地址规划的基础规范。用斜线表示前缀长度例如192.168.1.0/24表示前24位为网络号。实际工作中子网划分的核心能力是能快速判断两个IP是否在同一个子网、能容纳多少台主机。计算方法也不复杂可用主机数等于2的32-前缀长度次方减2去掉网络地址和广播地址。举个例子/24网段可用主机数是254/28网段只有14个可用地址很适合用来划分配置IP这样的管理网段/30网段只有2个可用地址正好用于点到点链路。这些划分技巧看似数学题实际上直接决定了网络的可扩展性和管理成本。7.3 网络基础的学习建议抓主线、多抓包、反复画图给学基础的同学三个实在的建议。第一抓主线。不要试图一开始就把所有协议背下来。先搞懂一条HTTP请求从客户端到服务器的全过程遇到不懂的协议就往这条主线上挂知识自然会形成体系。第二多抓包。用Wireshark看一次三次握手的包结构比看十页教材都管用。真实报文里的字段、序号、窗口大小比书里的示意图更有说服力。尤其是观察TCP重传时的行为能直观理解超时重传的意义。第三反复画图。画数据包经过每层的封装图画一个网络拓扑图画TCP状态迁移图。画图的过程就是整理思路的过程。等你不需要看书就能复现这些图的时候基础框架就算是真正建立了。我个人在实际操作中的体会是计算机网络是所有计算机基础课里最接近现实工程的一门课。它的理论不是空中楼阁而是贴着硬件、操作系统和应用层需求长出来的。搞懂了基础框架后面的网络安全、网络编程、分布式系统学习都会顺很多。别贪多先把一条请求理清楚你就已经超过一半还在背名词的同学了。