简介这份PDF资料面向准备技术面试的IT从业者与计算机专业学生系统梳理计算机网络核心考点帮助读者在有限时间内建立完整的知识框架并应对面试追问。内容围绕OSI七层参考模型与TCP/IP四层模型展开逐层讲解物理层、数据链路层、网络层、传输层及应用层的职责划分并深入剖析TCP三次握手、四次挥手、状态机、TIME_WAIT、超时重传与快速重传、流量控制及拥塞控制等高频问题同时对比TCP、UDP、SCTP协议差异介绍IPv4、IPv6、ICMP、ARP、IGMP等网络层协议。资源包为1个PDF文件大小约2.08MB结构清晰、便于检索适合作为面试前的速查笔记与知识查漏补缺材料。目前已有969人学习内容覆盖从理论模型到协议细节的完整链路能帮助读者理解网络通信原理、排查网络问题并优化系统设计。1. 从一次线上故障说起为什么我把这份网络笔记翻了三遍上周排查一个服务间调用超时的问题现象很怪客户端日志显示连接已建立但请求发出去后迟迟收不到响应抓包发现大量重复 ACK服务端却像没看见一样。折腾了两个小时才定位到是中间某台机器的net.ipv4.tcp_tw_reuse配置和 NAT 环境叠加导致 TIME_WAIT 状态下的端口复用踩到了旧连接的迷途分节。这种问题翻官方手册能查到参数但很难把「为什么会有 TIME_WAIT」「为什么复用会出问题」串起来。这份计算机网络基础知识笔记恰好把 OSI 七层模型、TCP/IP 协议族、TCP 状态机、超时重传、流量控制这些面试常问、工作中常踩坑的点按「模型 → 协议 → 状态 → 机制」的脉络整理了一遍。它适合两类人准备面试需要系统梳理 TCP/IP 知识体系的开发者以及日常排查连接超时、端口耗尽、重传异常的一线工程师。笔记里没有花哨的图表但每个机制都落到了具体字段和状态迁移上这正是排查问题时最需要的东西。2. 网络模型选型OSI 七层与 TCP/IP 四层到底怎么对应2.1 为什么工程中只关注传输层和应用层OSI 七层参考模型把网络通信拆成物理层、数据链路层、网络层、传输层、会话层、表示层、应用层每一层负责不同的抽象职责。物理层处理比特流传输和数模转换数据链路层负责帧的可靠传输和 MAC 地址寻址网络层用 IP 地址做路由选择传输层提供端到端的数据传输服务。上面三层——会话层、表示层、应用层——处理的是应用业务细节差异性大下面四层实现通信细节更加通用。TCP/IP 模型把下两层合并为数据链路层上三层合并为应用层形成四层结构。这个简化不是拍脑袋决定的上三层通常处于用户进程内下四层作为 OS 内核的一部分提供。套接字作为传输层以下网络的封装为上三层提供了统一接口。所以实际工程中写应用的人只需要关注传输层用 TCP 还是 UDP、应用层协议怎么设计底层路由和帧传输交给内核和网卡。2.2 协议族速查从 IPv4 到 SCTP 的选型边界TCP/IP 协议族里传输层有三个主要协议TCP、UDP、SCTP。TCP 是面向连接的可靠全双工字节流协议有消息确认、超时重传、流量控制、拥塞控制适合文件传输、HTTP 通信这类需要可靠性的场景。UDP 是无连接协议使用数据报套接字不保证消息一定送达、不保证顺序、不保证只送一次但正因为没有这些机制它的交互分组数少——一次请求应答只需要 2 个分组而 TCP 至少需要 8 个分组3 次握手 4 次挥手 1 次发送。音视频传输、DNS 查询这类对实时性要求高、能容忍少量丢包的场景UDP 是更合适的选择。SCTP 提供可靠全双工面向连接的服务但它有两个 TCP 没有的特性多流和多宿。多流意味着一个关联里可以同时传输多个独立数据流单个流上消息丢失不会阻塞其他流多宿意味着两端可以绑定多个 IP 地址一个端点有多个冗余连接走不同基础设施网络故障时自动切换。SCTP 和 TCP 的主要区别就在这两点。网络层协议方面IPv4 使用 32 位地址可用地址有限IPv6 使用 128 位地址地址空间巨大。ICMP 处理主机和路由之间的消息通信ICMPv6 为 IPv6 提供地址解析、网络组管理等功能兼具 ICMPv4、IGMP、ARP 的功能。ARP 把 IPv4 地址映射成 MAC 地址用于广播网络RARP 反过来把 MAC 地址映射成 IPv4 地址。IGMP 用于广播通信的组管理。提示面试常问「TCP/IP 包含哪些协议、分别有什么作用」回答时按传输层、网络层、数据链路层分层说每层挑 2 到 3 个核心协议展开不要背流水账。2.3 数据报与数据流的本质区别理解 UDP 和 TCP 的差异关键要分清数据报和数据流。数据报是面向无连接的传输方式每个数据报独立、自包含有自己的目标地址和源地址可以独立通过网络传输传输不可靠可能丢包、重复、乱序。UDP 用的就是这种方式消息长度随报文传递到对端。数据流是面向连接的传输方式发送端和接收端之间建立持久、有序的字节流数据流是连续的、无边界的字节序列没有明确分割单位传输可靠确保有序、完整、无错误。TCP 用的就是这种方式本身没有消息长度需要上层应用自己设计应用层协议来界定消息边界。这个区别直接决定了应用层协议的设计方式用 UDP 时每个数据报自带边界收的时候一次收一个完整消息用 TCP 时必须自己处理粘包和拆包常见做法是在消息头里加长度字段或者用固定分隔符。3. TCP 连接管理三次握手、四次挥手与状态机排查3.1 三次握手与四次挥手的报文交互细节TCP 建链过程从服务端被动打开开始服务端调用 socket、bind、listen 三个函数启动监听进入 LISTEN 状态。客户端主动打开调用 connect 发送 SYN 分节告知客户端初始序列号进入 SYN_SENT 状态。SYN 分节不携带数据所在的 IP 数据报只包含 IP 头、TCP 头和可选的 TCP 选项。服务端收到 SYN 后发送 ACK 确认客户端 SYN同时发送自己的 SYN 告知服务端初始序列号进入 SYN_RCVD 状态。客户端收到 ACK SYN 后发送 ACK 确认服务端 SYN双方进入 ESTABLISHED 状态。服务端的初始序列号和客户端的初始序列号是两个独立字段分别代表各自发送的消息序列号。每次发送 SYN 携带当前序列号每次回复 ACK 携带下一次消息的序列号即当前序列号加一。关闭连接时主动关闭方调用 close 发送 FIN 分节进入 FIN_WAIT_1 状态。被动关闭方收到 FIN 后回复 ACK同时将接收数据作为 EOF 传递给上层应用进入 CLOSE_WAIT 状态。此时被动关闭方仍然可以向主动关闭方发送数据称为半关闭。被动关闭方上层应用收到 EOF 后调用 close发送自己的 FIN 分节进入 LAST_ACK 状态。主动关闭方收到 FIN 后回复 ACK进入 TIME_WAIT 状态等待 2MSL 后进入 CLOSED。被动关闭方收到 ACK 后进入 CLOSED。为什么三次握手时服务端可以在一个分节同时回复 ACK 和 SYN而四次挥手中被动关闭方要分两个分节发送 ACK 和 FIN因为 TCP 是全双工的四次挥手时两端的关闭是独立动作可以各自控制是否关闭自己发送消息的通道因而分为两组消息。三次握手第二步中服务端收到客户端 SYN 后已经知道客户端初始序列号同时也要发送自己的初始序列号所以可以合并 ACK 和 SYN 减少往返时间。3.2 TCP 状态机与 TIME_WAIT 的工程意义TCP 状态机覆盖了建链、数据传输、关闭的完整生命周期。服务端建链路径是 CLOSED → LISTEN → SYN_RCVD → ESTABLISHED。客户端建链路径是 CLOSED → SYN_SENT → ESTABLISHED如果等待超时未收到 ACK SYN 则回到 CLOSED。主动关闭路径是 ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED其中 FIN_WAIT_1 收到 FIN 可能进入 CLOSING 再进 TIME_WAIT。被动关闭路径是 ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED。TIME_WAIT 状态持续 2MSL建议值 2 分钟通常 1 到 4 分钟。MSL 是最长分节生命周期表示 IP 数据报能在网络中存活的最长时间超过该时间的 IP 数据报被忽略。TIME_WAIT 存在的意义有两个一是实现可靠的 TCP 全双工连接终止最后一个 ACK 丢失后可能需要重传需要 TIME_WAIT 状态进行中转二是允许老的重复分节在网络中消逝如果连接断链后马上用相同 IP 和端口建立新连接新连接可能收到旧连接的报文等待 2MSL 保证上一个连接的包全部消逝后再启用新连接。排查连接问题时ss -tan或netstat -tan看状态分布是第一步。如果 CLOSE_WAIT 大量堆积说明被动关闭方上层应用没有及时调用 close通常是代码里忘了关连接或者处理逻辑阻塞。如果 TIME_WAIT 大量堆积说明主动关闭方频繁短连接可以考虑连接池或者调整内核参数但要谨慎。# 查看 TCP 连接状态分布 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn # 查看特定端口的连接状态 ss -tan sport :8080 | awk NR1 {print $1} | sort | uniq -c # 查看内核 TIME_WAIT 相关参数 sysctl net.ipv4.tcp_tw_reuse sysctl net.ipv4.tcp_max_tw_buckets第一段命令统计所有 TCP 连接的状态分布快速定位是否有异常状态堆积。第二段过滤特定端口适合排查某个服务的连接问题。第三段查看 TIME_WAIT 复用和最大桶数参数tcp_tw_reuse控制是否允许复用 TIME_WAIT 状态的端口建立新连接tcp_max_tw_buckets控制 TIME_WAIT 套接字最大数量超过后新连接直接关闭并打印警告。注意tcp_tw_reuse在 NAT 环境下可能引发旧连接迷途分节被新连接接收的问题开启前要确认网络拓扑。3.3 端口号分配与连接数上限的误区TCP、UDP、SCTP 都有端口号概念都用 16 位整数表示范围 0 到 65535。不同协议之间的端口号不冲突可以同时开启 TCP、UDP、SCTP 的相同端口号。端口号分三段0 到 1023 是公共服务的端口号比如 SSH 的 221024 到 49151 用于登记开启的监听端口号比如 Web 服务的 808049152 到 65535 用于开启临时端口号与服务端通信。客户端与服务端建链时客户端同样需要使用一个临时端口由协议栈自动分配。一个 TCP 通信链路包含一对套接字是定义两个连接端点的四元组本地 IP 地址、本地 TCP 端口号、外地 IP 地址、外地 TCP 端口号。加上协议就是五元组。很多人误以为一台客户端机器能建立的连接上限就是可以开启的端口数实际上端口是逻辑概念建立连接的数量取决于五元组中各个元素取值的组合。对于客户端而言物理层面一个 Socket 连接被视作一个文件占用一个文件句柄逻辑层面用五元组唯一标识一个连接。假设有固定数量的客户端机器想要发起上百万个连接到同一个服务器如何突破端口限制由于机器数量固定协议、源 IP、目标 IP 已固定。对于同一个目标端口同一个客户端机器能开启的最大端口数不超过 65535因而需要提供多个目标端口每个端口承担 6 万多个客户端连接突破端口限制。常见做法是服务端监听多个端口客户端轮询连接不同端口。4. 可靠传输机制重传、流量控制与拥塞控制4.1 超时重传与快速重传的触发条件超时重传是发送方在发送数据包后设置定时器如果在规定时间内没有收到确认发送方认为数据包丢失重新发送。这种机制基于超时的假设缺点是必须等待超时时间才能重传网络传输效率低。触发条件是网络拥塞或传输延迟导致数据包丢失。快速重传是基于接收方反馈的重传机制。当接收方收到不按顺序的数据包时会发送重复确认。比如接收方已收到数据包 5 但未收到数据包 3会重复确认数据包 4连发 3 次后发送端立即重传数据包 3不必等待超时。触发条件是网络丢包引起数据包乱序接收方通过重复确认指示发送方某个数据包丢失。两种机制在不同情况下使用超时重传是兜底快速重传是优化。RTT 是往返时延从发送端发送数据开始到收到接收端确认总共经历的时延由链路传播时间、末端系统处理时间、路由器缓存中的排队和处理时间三部分组成。前两部分对一个 TCP 连接相对固定排队和处理时间随网络拥塞程度变化所以 RTT 变化在一定程度上反映网络拥塞程度。RTO 是重传超时时间根据 RTT 动态调整由协议栈自动控制一般至少为 1.5 倍 RTT。RTO 过小可能过于频繁发起重传RTO 过大则重传等待时间可能过长。# 查看当前 TCP 连接的 RTT 和重传统计 ss -tan -o state established ( sport :8080 ) | head -20 # 查看内核重传相关参数 sysctl net.ipv4.tcp_retries1 sysctl net.ipv4.tcp_retries2 sysctl net.ipv4.tcp_syn_retriesss -o输出定时器信息可以看到每个连接的 RTT 和重传计数。tcp_retries1控制底层网络层重传次数tcp_retries2控制 TCP 层重传次数tcp_syn_retries控制 SYN 重传次数。排查连接超时时先看这些参数是否被调过再结合抓包看重传间隔是否符合预期。4.2 ARQ 协议族与滑动窗口的工程实现ARQ 是自动重传请求协议位于传输层通过 ACK 确认和超时重传机制确保数据可靠传输。主要有三种模式停等 ARQ、连续 ARQ、反馈 ARQ。停等 ARQ 发送方发一个数据包就停止等待确认收到确认后才发下一个缺点是等待时间长导致传输速度低。连续 ARQ 发送方连续发送多个数据包不等待每个确认接收方发送累积确认如果发送方未收到确认或收到错误指示重传相应数据包。连续 ARQ 又分 Go-Back-N 和 Selective-Repeat。Go-Back-N 中发送方发送窗口内未经确认的分组需要重传。发送方响应三种事件上层调用 send 时检查发送窗口是否已满接收 ACK 时采取累积确认表明接收方已正确收到序号 n 以前包括 n 的所有分组等待超时时重传所有已发出但未被确认的分组。接收方若收到序号为 n 的分组且符合顺序回复 ACK 并交由上层处理否则丢弃。比如发送方发了 1、2、3、4、5序号 2 丢失即使 3、4、5 被正确接收但不合顺序发送方依然重传 2、3、4、5。缺点是窗口很大时重传区间大效率降低。Selective-Repeat 让发送方仅重传接收方丢失或损坏的分组避免不必要重传。每个分组有独立计时器。接收方若收到窗口内的分组发送 ACK若分组是以前没收到的且序号小于基序号则缓存若序号等于基序号则该分组及以前缓存的连续分组都交付上层接收窗口向前移动。TCP 基于 ARQ 协议使用了 ARQ 的确认和重传机制是 ARQ 的一种变体。滑动窗口是发送方和接收方维护的数据帧序列。发送方窗口大小由接收方确定控制发送速度以免接收方缓存溢出同时控制流量避免网络拥塞。窗口内未经确认的分组需要重传。TCP 的流量控制通过通告窗口实现接收方在 ACK 中告知当前能接收多少数据发送方据此调整发送速率。通告窗口随消息接收动态变化当为 0 时表示接收缓冲区已满需要等待应用读取数据后才能再次接收。这是 TCP 的负反馈机制通过接收端速率限制发送端速率。4.3 拥塞控制与流量控制的边界流量控制是点对点的控制发送方速率以免接收方处理不过来。拥塞控制是全局的防止过多数据注入网络导致路由器队列溢出。TCP 的拥塞控制包括慢启动、拥塞避免、快速重传、快速恢复四个阶段。慢启动时拥塞窗口从 1 个 MSS 开始每收到一个 ACK 增加 1 个 MSS指数增长。达到慢启动阈值后进入拥塞避免每个 RTT 增加 1 个 MSS线性增长。收到 3 个重复 ACK 时触发快速重传和快速恢复拥塞窗口减半后继续线性增长。超时重传时拥塞窗口重置为 1 个 MSS重新慢启动。# 查看拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 查看可用拥塞控制算法 sysctl net.ipv4.tcp_available_congestion_control # 查看当前连接的拥塞窗口和慢启动阈值 ss -tan -i state established ( sport :8080 ) | head -10ss -i输出连接的内部信息包括拥塞窗口 cwnd、慢启动阈值 ssthresh、RTT 等。排查吞吐量上不去的问题时先看 cwnd 是否被限制在很小值再看是否频繁触发重传导致 cwnd 反复重置。常见做法是根据网络环境调整拥塞控制算法比如高带宽长距离链路用 BBR传统环境用 cubic。提示流量控制和拥塞控制容易混淆记住流量控制看接收方通告窗口拥塞控制看网络丢包和 RTT 变化。5. 避坑与排查那些手册不会告诉你的细节5.1 现象连接建立后请求无响应抓包见重复 ACK原因接收方收到乱序分节发送重复 ACK 指示丢失分节但发送方未触发快速重传。常见于中间设备丢弃了 ACK 或者窗口通告为 0 后未正确恢复。解决检查net.ipv4.tcp_sack是否开启SACK 能让接收方告知发送方已收到哪些分节帮助发送方精准重传。同时确认tcp_window_scaling开启避免窗口大于 65535 时通告窗口被截断。5.2 现象服务端大量 CLOSE_WAIT连接数持续上涨原因被动关闭方上层应用没有及时调用 close。收到 FIN 后内核回复 ACK 并进入 CLOSE_WAIT等待应用关闭连接。如果应用处理逻辑阻塞、忘记关连接、或者连接池未正确释放CLOSE_WAIT 就会堆积。解决检查代码中连接释放逻辑确认异常分支也有关闭操作。用ss -tan state close-wait定位具体连接结合进程 ID 找到对应服务。5.3 现象TIME_WAIT 端口耗尽新连接无法建立原因主动关闭方频繁短连接TIME_WAIT 状态持续 2MSL端口被占用。解决优先用连接池复用连接减少短连接。如果必须短连接可以调整net.ipv4.tcp_tw_reuse允许复用 TIME_WAIT 端口但 NAT 环境下要谨慎。tcp_max_tw_buckets控制最大 TIME_WAIT 数量超过后新连接直接关闭不建议调太小。5.4 现象SYN 重传次数过多连接建立慢原因服务端 SYN 队列满或者网络丢包。解决检查net.ipv4.tcp_max_syn_backlog和net.core.somaxconn确保 SYN 队列足够大。如果服务端处理能力不足考虑增加 backlog 或者优化 accept 逻辑。客户端侧检查tcp_syn_retries默认 6 次每次间隔指数增长总超时约 127 秒。5.5 现象UDP 端口测试通但应用收不到数据原因UDP 无连接端口通只表示 ICMP 端口不可达未返回不代表应用在监听。解决用ss -ulpn确认 UDP 套接字已绑定检查应用是否在正确端口监听。如果用了 SO_REUSEADDR 或 SO_REUSEPORT多个进程可能绑定同一端口数据被其中一个进程接收。排查时先停掉其他进程只留一个测试。6. 进阶技巧用 iperf3 和 ss 验证 TCP 行为面试背得再熟不如自己抓一次包看状态迁移。我一般用 iperf3 打流配合 ss 观察验证三次握手、重传、窗口变化是否符合预期。先在一台机器起服务端# 服务端监听 5201 端口 iperf3 -s -p 5201 # 客户端打 TCP 流持续 30 秒每 1 秒报告一次 iperf3 -c 192.168.1.100 -p 5201 -t 30 -i 1 # 客户端打 UDP 流带宽 100M观察丢包和抖动 iperf3 -c 192.168.1.100 -p 5201 -u -b 100M -t 30 -i 1-s启动服务端-c指定客户端连接-t持续时间-i报告间隔-u用 UDP-b指定带宽。TCP 模式下看 Retr 列的重传次数如果持续大于 0说明网络有丢包或者拥塞。UDP 模式下看 Lost/Total 列的丢包率以及 Jitter 列的抖动音视频场景抖动比丢包更影响体验。打流的同时在服务端用 ss 观察连接状态和窗口# 每 0.5 秒刷新一次观察 cwnd 和 rtt 变化 watch -n 0.5 ss -tan -i state established ( sport :5201 ) # 统计重传次数 ss -tan -o state established ( sport :5201 ) | grep -o retrans:[0-9]*ss -i输出的 cwnd 和 rtt 能直接反映拥塞控制行为。如果 cwnd 一直上不去检查是否频繁超时重传导致重置。如果 rtt 波动大说明路径上有排队或者拥塞。我习惯在压测时开两个终端一个跑 iperf3一个跑 watch ss对比吞吐量和 cwnd 曲线基本能判断是带宽瓶颈还是拥塞控制问题。验证 TIME_WAIT 行为时用短连接反复请求然后观察状态# 发起 100 次短连接请求 for i in $(seq 1 100); do curl -s -o /dev/null http://192.168.1.100:8080/; done # 查看 TIME_WAIT 数量 ss -tan state time-wait | wc -l # 查看端口复用统计 netstat -s | grep -i -A 1 time waitnetstat -s输出协议栈统计TIME_WAIT 相关计数能看出是否有端口复用失败或者桶溢出。如果 TIME_WAIT 数量接近tcp_max_tw_buckets新连接可能被直接关闭日志里会有TCP: time wait bucket table overflow警告。从那以后我每次调整 TCP 参数前都强制走一遍「iperf3 打流 ss 观察 netstat 统计」的流程确认基线行为再改配置避免凭感觉调参把问题搞得更复杂。希望帮到你。本文还有配套的精品资源点击获取