TCP/IP四层模型

同一局域网：主机A要给主机B发送数据，已知B的IP，未知MAC → A发送ARP广播（全网段），询问"IP为X的设备MAC是多少" → 只有主机B响应ARP单播，返回自己的MAC → A缓存B的IP-MAC映射（ARP缓存表，默认存活120秒），后续通信直接使用MAC。
跨局域网：主机A要给外网主机C发送数据，已知C的IP，未知MAC → A发送ARP广播，询问网关的MAC（因为跨网段通信必须经过网关） → 网关响应MAC → A将数据封装成帧，发送给网关，由网关转发到外网。

ARP缓存表老化时间为什么是120秒？

平衡"效率"和"准确性"------老化时间太短，会频繁发送ARP广播，占用网络带宽；老化时间太长，若设备IP-MAC映射发生变化（如设备更换、IP重新分配），会导致通信失败，120秒是行业默认的最优平衡值，可根据网络规模调整。

为什么链路层只做差错检测，不做纠错？

纠错需要额外的冗余数据（如校验码、重传机制），会增加帧的体积，降低传输效率；链路层传输距离短（相邻设备），出错概率低，将纠错交给上层（传输层TCP），既保证可靠性，又兼顾效率（分层解耦的体现）。

MAC地址和IP地址的区别？

作用范围：MAC是链路层标识，用于同一局域网内寻址；IP是网络层标识，用于跨局域网（全网）寻址。
稳定性：MAC地址固化在网卡上，不可更改（软件可伪造）；IP地址可动态分配（如DHCP），可更改。
寻址方式：MAC是广播寻址（同一网段内广播）；IP是路由寻址（跨网段通过路由转发）。

第二层：网络层（核心层，负责"全网寻址"）

1. 核心职责

负责跨局域网的路由转发，将传输层的段（Segment）封装成"IP数据报（Datagram）"，通过IP地址实现全网寻址，选择最优路由，处理数据报的分片与重组、差错检测（不纠错）。

核心重点：网络层是"无连接、不可靠"的------无连接（发送方不与接收方建立连接，直接发送数据）；不可靠（只检测数据报头部差错，出错则丢弃，不重传、不纠错，可靠性由传输层TCP保证）。

2. 核心协议与组件

IP协议（Internet Protocol）：核心中的核心，定义IP地址格式，负责数据报的封装、寻址、路由转发，目前主流是IPv4（32位），逐步过渡到IPv6（128位）。
IP地址：全网唯一标识一台主机/设备，由网络位+主机位组成（通过子网掩码划分），分为A、B、C、D、E类。
路由协议：负责选择最优路由，分为静态路由（手动配置，适用于小型网络）和动态路由（自动学习，适用于大型网络，如RIP、OSPF、BGP）。
ICMP协议（Internet控制消息协议）：辅助IP协议，用于传递差错报告（如目标不可达、超时）和控制消息（如ping命令），注意：ICMP不传输用户数据。
IP分片与重组：因为链路层帧的最大长度（MTU，最大传输单元）有限（如以太网MTU=1500字节），若IP数据报大于MTU，则网络层会将其分片，每个分片携带分片标识、偏移量，接收方在网络层重组后，再交给传输层。

3. 高频问题

IP协议为什么是无连接、不可靠的？设计思路是什么？

无连接：无需建立连接，发送方直接封装数据报发送，减少连接建立/释放的开销，提升传输效率（适合对实时性要求高、可容忍少量丢包的场景，如视频通话）。
不可靠：只检测数据报头部差错（校验和），出错则丢弃，不重传、不纠错------因为网络层的核心职责是"寻址和转发"，若在网络层实现重传、纠错，会增加路由器的负担，降低全网转发效率；可靠性交给传输层TCP（面向连接、可靠），分层解耦，各司其职。

ping命令的工作原理？

ping命令是通过ICMP协议实现的，流程如下：

发送方发送ICMP Echo Request（回声请求）报文，携带一个随机数据块；
接收方收到后，返回ICMP Echo Reply（回声响应）报文，携带相同的数据块；
发送方计算"发送时间-接收时间"，得到往返时延（RTT），若未收到响应，则提示"请求超时"（可能是目标不可达、网络中断）。

补充：ping命令无法检测端口是否开放（检测端口用telnet、netstat），因为ICMP协议不涉及端口。

IP分片的细节？为什么分片后只能在接收方重组，而不是中间路由器重组？

分片细节：IP数据报头部有"分片标识（ID）""标志位（DF=1表示不分片，MF=1表示还有后续分片，MF=0表示最后一个分片）""偏移量（表示当前分片在原数据报中的位置）"，接收方通过ID识别同一数据报的分片，通过偏移量重组。
为什么不在中间路由器重组？------ 中间路由器的核心职责是"快速转发"，重组需要消耗路由器的CPU、内存资源，会降低转发效率；且若某一分片丢失，重组就会失败，中间路由器重组后，若后续分片丢失，还需重新转发整个数据报，浪费带宽；接收方重组，可避免中间路由器的额外开销，提升全网效率。

IPv4和IPv6的区别？

地址长度：IPv4是32位（4个字节，点分十进制），IPv6是128位（16个字节，冒分十六进制），解决IPv4地址耗尽问题。
寻址方式：IPv4支持广播、单播、组播；IPv6取消广播，只支持单播、组播、任播（任播：一个数据包发送到一组设备中最近的一个）。
头部结构：IPv4头部复杂（20-60字节），有校验和；IPv6头部简化（固定40字节），无校验和（校验由链路层、传输层负责），提升转发效率。
即插即用：IPv6支持自动配置（无需DHCP），IPv4需要手动配置或DHCP分配。

子网划分的目的？如何划分？

目的：将一个大的网络划分为多个小的子网，减少网络广播域，降低广播风暴的影响，提升网络安全性和管理效率。
划分方法：通过子网掩码将IP地址的"网络位"延长，"主机位"缩短，例如：C类地址192.168.1.0/24（默认子网掩码255.255.255.0），划分为2个子网，子网掩码改为255.255.255.128（/25），两个子网分别是192.168.1.0-127、192.168.1.128-255，每个子网可用主机数126（减去网络地址和广播地址）。

路由转发的原理？

路由器通过"路由表"转发数据报，路由表包含"目标网络地址、子网掩码、下一跳地址、出接口"，转发流程：

路由器收到IP数据报，提取目标IP地址；
用目标IP地址与路由表中的子网掩码逐一匹配，找到"最长前缀匹配"的路由条目（最长前缀匹配：确保转发路径最精准）；
根据路由条目，将数据报转发到下一跳路由器，直至到达目标网络，最后交付给目标主机。

第三层：传输层（负责"端到端可靠传输"）

1. 核心职责

负责端到端的通信控制，将应用层的数据流封装成"段（Segment）"，提供两种核心服务：TCP（面向连接、可靠传输）和UDP（无连接、不可靠传输），处理端口寻址、流量控制、拥塞控制、差错恢复。

核心重点：传输层的"端到端"是指源主机的应用程序到目标主机的应用程序，区别于网络层的"主机到主机"（只负责主机寻址），通过"端口号"实现应用程序的区分。

2. 核心协议

对比维度	TCP（传输控制协议）	UDP（用户数据报协议）
连接性	面向连接（三次握手建立连接，四次挥手释放连接）	无连接（直接发送，无需建立/释放连接）
可靠性	可靠（保证数据有序、不丢失、不重复，通过ACK确认、重传机制实现）	不可靠（不确认、不重传、不排序，丢包由应用层处理）
流量控制	有（滑动窗口机制）	无（发送方无节制发送，可能导致接收方过载）
拥塞控制	有（慢启动、拥塞避免、快重传、快恢复）	无（不感知网络拥塞，可能加剧拥塞）
端口	使用知名端口（如80、443）和动态端口	同上，端口号用于区分应用程序
开销	高（头部20-60字节，包含序列号、确认号等字段）	低（头部固定8字节，无额外字段）
适用场景	对可靠性要求高的场景（HTTP/HTTPS、FTP、SSH、邮件）	对实时性要求高、可容忍丢包的场景（视频通话、语音通话、DNS、直播）

3. TCP核心细节

（1）TCP三次握手

核心目的：建立连接，同步双方的序列号（SEQ）和确认号（ACK），确保双方都能正常接收和发送数据（避免因序列号混乱导致数据丢失、重复）。

三次握手流程（假设客户端主动发起连接）：

第一次握手（SYN）：客户端发送SYN报文，携带自己的初始序列号（SEQ=x），SYN=1（表示发起连接），ACK=0（无确认信息）；此时客户端进入SYN_SENT状态。
第二次握手（SYN+ACK）：服务器收到SYN报文后，回复SYN+ACK报文，携带自己的初始序列号（SEQ=y），确认号ACK=x+1（表示已收到客户端的SEQ=x，下一次期望接收x+1），SYN=1、ACK=1；此时服务器进入SYN_RCVD状态。
第三次握手（ACK）：客户端收到SYN+ACK报文后，回复ACK报文，携带确认号ACK=y+1（表示已收到服务器的SEQ=y，下一次期望接收y+1），SEQ=x+1，ACK=1；此时客户端进入ESTABLISHED（连接建立）状态，服务器收到ACK后，也进入ESTABLISHED状态，连接建立完成。

为什么是三次握手，不是两次？

核心是"确保双方的接收和发送能力都正常"。两次握手只能确认"客户端能发送，服务器能接收且能发送"，但无法确认"服务器发送的报文，客户端能接收"------若第二次握手的SYN+ACK报文丢失，服务器会以为客户端没收到，一直重发SYN+ACK，而客户端以为连接没建立，不会发送数据，导致服务器资源浪费；三次握手的第三次ACK，能让服务器确认"客户端能接收自己的报文"，双方都确认对方的收发能力正常，避免资源浪费。

三次握手时，第一次握手的SYN报文丢失，会发生什么？

客户端发送SYN后，会启动重传计时器（默认1秒），若超时未收到服务器的SYN+ACK，会重发SYN报文，最多重传5次（默认），若仍未收到响应，客户端会关闭连接，提示"连接超时"。

三次握手完成后，客户端突然崩溃，服务器会怎么做？

服务器会启动"保活计时器"（默认2小时），每隔一段时间（默认75秒）向客户端发送保活探测报文，若连续3次（默认）未收到客户端的响应，服务器会认为客户端已崩溃，主动关闭连接（释放资源）。

（2）TCP四次挥手

核心目的：释放连接，确保双方都已发送完所有数据，避免数据丢失（TCP是面向连接的，必须优雅释放）。

四次挥手流程（假设客户端主动发起释放）：

第一次挥手（FIN）：客户端发送FIN报文，携带SEQ=u（当前客户端的序列号），FIN=1（表示请求释放连接），ACK=v（确认服务器之前发送的数据）；此时客户端进入FIN_WAIT_1状态，不再发送数据，但仍能接收服务器的数据。
第二次挥手（ACK）：服务器收到FIN报文后，回复ACK报文，携带ACK=u+1（确认已收到客户端的FIN），SEQ=v（当前服务器的序列号）；此时服务器进入CLOSE_WAIT状态，客户端收到ACK后，进入FIN_WAIT_2状态。
第三次挥手（FIN）：服务器发送完所有剩余数据后，发送FIN报文，携带SEQ=w（当前服务器的序列号），FIN=1，ACK=u+1；此时服务器进入LAST_ACK状态，不再发送数据，等待客户端的ACK。
第四次挥手（ACK）：客户端收到FIN报文后，回复ACK报文，携带ACK=w+1，SEQ=u+1；此时客户端进入TIME_WAIT状态（等待2MSL，MSL=最大报文生存时间，默认1分钟），服务器收到ACK后，进入CLOSED状态；客户端等待2MSL后，确认服务器已收到ACK，也进入CLOSED状态，连接释放完成。

为什么是四次挥手，不是三次？

因为TCP是"全双工"通信（双方可以同时发送和接收数据），客户端发送FIN（请求释放自己的发送通道），服务器收到后，先回复ACK（确认客户端的发送通道已释放），但服务器可能还有未发送完的数据，需要等服务器发送完所有数据后，再发送FIN（请求释放自己的发送通道），客户端再回复ACK，因此需要四次挥手。

TIME_WAIT状态的作用

确保服务器能收到客户端的最后一个ACK（若第四次挥手的ACK丢失，服务器会重发FIN，客户端在TIME_WAIT状态下能收到并重发ACK）；
等待网络中所有残留的报文（已发送但未到达的报文）过期，避免这些报文被后续新连接复用，导致数据混乱（2MSL是报文在网络中能存活的最长时间，等待2MSL可确保所有残留报文都已消失）。

如何优化TIME_WAIT过多的问题？

开启tcp_tw_reuse（允许复用TIME_WAIT状态的端口，用于新的连接）；
开启tcp_tw_recycle（快速回收TIME_WAIT状态的连接，注意：NAT环境下不建议开启，会导致连接失败）；
调整TIME_WAIT超时时间（缩短2MSL，不建议默认修改，可能导致残留报文混乱）。

客户端在TIME_WAIT状态下，能否立即发起新的连接？

默认情况下，客户端在TIME_WAIT状态（2MSL）内，不能立即发起与同一服务器、同一端口的新连接（会提示"地址已在使用"），但可以通过修改系统参数（如Linux的tcp_tw_reuse、tcp_tw_recycle）优化，允许复用TIME_WAIT状态的端口，提升连接效率。

（3）TCP流量控制

核心目的：避免"发送方发送速度过快，接收方处理不过来，导致数据丢失"，由接收方控制发送方的发送速度。

原理：接收方在ACK报文中，携带自己的"接收窗口（rwnd）"大小（表示接收方当前空闲的缓冲区大小），发送方的发送窗口不能超过接收方的接收窗口，发送方根据接收窗口的大小调整发送速度；若接收方缓冲区满（rwnd=0），发送方会停止发送，等待接收方发送rwnd>0的ACK后，再继续发送。

滑动窗口的大小由什么决定？

滑动窗口的最大大小 = min（接收窗口rwnd，拥塞窗口cwnd）------ 接收窗口由接收方的缓冲区大小决定（控制"接收能力"），拥塞窗口由网络拥塞程度决定（控制"网络承载能力"），取最小值，既避免接收方过载，又避免网络拥塞。

（4）TCP拥塞控制

核心目的：避免"发送方发送速度过快，导致网络拥塞（数据包丢失、延迟增加）"，由发送方根据网络状态动态调整发送速度（通过拥塞窗口cwnd控制）。

拥塞控制的四个阶段：

慢启动阶段（cwnd从1开始，指数增长）：初始cwnd=1（ MSS，最大报文段长度），每经过一个RTT（往返时延），cwnd翻倍（1→2→4→8...），直到cwnd达到"慢启动阈值（ssthresh）"（默认ssthresh=65535字节），进入拥塞避免阶段。
拥塞避免阶段（cwnd线性增长）：cwnd达到ssthresh后，每经过一个RTT，cwnd增加1（线性增长），避免快速增加导致网络拥塞，直到检测到网络拥塞（如超时、收到3个重复ACK）。
快重传阶段（检测到丢包，快速重传）：若发送方收到3个重复的ACK（表示某一个报文丢失，接收方已收到后续报文），不等待超时，立即重传丢失的报文，同时将ssthresh调整为当前cwnd的一半，进入快恢复阶段。
快恢复阶段（cwnd快速恢复，避免慢启动）：cwnd设置为调整后的ssthresh（即当前cwnd的一半），然后每经过一个RTT，cwnd增加1（线性增长），直到cwnd达到之前的ssthresh，再进入拥塞避免阶段。

为什么快重传需要收到3个重复ACK，而不是1个？

避免误判------接收方可能因为报文乱序（不是丢包），导致发送重复ACK（比如接收方收到SEQ=1、3，没收到SEQ=2，会连续发送ACK=2），收到1个或2个重复ACK，可能是乱序，收到3个重复ACK，大概率是丢包（行业默认阈值），此时快速重传，既保证及时性，又避免误判。

（5）TCP其他细节

序列号（SEQ）和确认号（ACK）的作用：SEQ是当前发送报文的数据起始序号（用于标识数据的位置），ACK是期望下一次接收的序号（用于确认已收到的数据），确保数据有序、不重复、不丢失。
TCP粘包问题：原因：TCP是面向字节流的（无边界），发送方会将小数据包合并成大数据包发送（Nagle算法），接收方会将收到的数据包缓存，导致多个数据包被"粘"在一起。解决方法：① 固定包长；② 包尾添加分隔符；③ 包头添加长度字段（最常用）。
Nagle算法和延迟确认（优化TCP传输效率）： Nagle算法：避免发送大量小数据包（减少网络开销），当发送方有未确认的数据时，会将后续的小数据包缓存，直到缓存满或收到确认，再一次性发送。延迟确认：接收方收到数据后，不立即发送ACK，而是延迟一段时间（默认200ms），若这段时间内有数据要发送给对方，就将ACK和数据一起发送，减少ACK报文的数量。

4. UDP核心细节

UDP为什么没有流量控制和拥塞控制？

UDP的设计目标是"高效、实时"，适合对实时性要求高的场景（如视频通话），若添加流量控制和拥塞控制，会增加开销、降低实时性；丢包问题由应用层处理（如视频通话会丢弃丢失的帧，不重传，避免延迟）。

DNS协议为什么用UDP？

DNS查询数据量小（通常小于512字节），UDP头部开销小，传输效率高；
DNS查询是"请求-响应"模式，无需建立连接，UDP的无连接特性更适合；
即使丢包，应用层会重新发送查询请求，无需UDP层重传。补充：若DNS查询数据量超过512字节，会使用TCP（因为UDP报文超过MTU会分片，可靠性低，TCP更稳定）。

UDP如何实现可靠传输？

UDP本身不可靠，需在应用层实现可靠传输，核心方案：

添加序列号（确保数据有序）；
添加确认机制（接收方收到数据后，回复ACK，发送方超时未收到ACK则重传）；
添加重传机制（超时重传、快速重传）；
添加校验和（检测数据是否出错）。例如：QUIC协议（基于UDP），就实现了类似TCP的可靠传输、流量控制、拥塞控制。

第四层：应用层（最上层，面向用户）

1. 核心职责

为用户提供具体的应用服务，将用户的数据（如文本、图片）封装成"应用层数据单元"，交给传输层处理，核心是"满足用户的具体需求"，不关心底层传输细节。

2. 核心协议

HTTP/HTTPS（超文本传输协议）：用于Web访问，HTTP是明文传输（不安全），HTTPS是HTTP+SSL/TLS（加密传输，安全），默认端口：HTTP 80，HTTPS 443。

HTTP和HTTPS的区别？

安全性：HTTP明文，HTTPS加密（对称加密+非对称加密）；
端口：HTTP 80，HTTPS 443；
开销：HTTPS需要握手（SSL/TLS握手），开销比HTTP大；
证书：HTTPS需要CA证书（验证服务器身份），HTTP不需要。

FTP（文件传输协议）：用于文件上传/下载，默认端口21（控制连接）、20（数据连接），面向连接（基于TCP），可靠性高。

DNS（域名系统）：用于将域名（如www.baidu.com）转换为IP地址，默认端口53，基于UDP（小查询）和TCP（大查询）。

SMTP/POP3/IMAP：用于邮件传输，SMTP（发送邮件，端口25），POP3（接收邮件，端口110），IMAP（接收邮件，端口143），均基于TCP。

SSH（安全外壳协议）：用于远程登录服务器，加密传输，默认端口22，基于TCP，替代不安全的Telnet（明文，端口23）。

3. 高频问题

HTTP协议的特点？（无状态、无连接）

无状态：服务器不保存客户端的会话信息（如登录状态），每次请求都是独立的，需要通过Cookie、Session实现会话保持；
无连接：HTTP 1.0默认是短连接（每次请求建立连接，响应后释放连接），HTTP 1.1支持长连接（Connection: keep-alive），减少连接建立/释放的开销。

HTTPS的SSL/TLS握手流程？

客户端向服务器发送SSL/TLS版本、加密套件列表；
服务器选择合适的加密套件，返回服务器证书（包含公钥）；
客户端验证证书合法性，生成随机密钥，用服务器公钥加密，发送给服务器；
服务器用私钥解密，得到随机密钥；
双方用随机密钥进行对称加密通信（后续数据均用此密钥加密）。

应用层协议如何与传输层协议关联？

通过"端口号"关联------应用层协议会绑定固定的端口号（知名端口，1-1023），传输层通过端口号识别对应的应用程序，例如：HTTP绑定80端口，TCP收到目的端口为80的段，会将数据交给应用层的HTTP协议处理；同一台主机上，不同应用程序的端口号唯一，避免混淆。

三、四层模型协同工作流程

以"客户端访问www.baidu.com"为例，完整流程（从应用层到网络接口层，再到接收方反向解析）：

应用层：用户在浏览器输入域名，HTTP协议生成HTTP请求报文（应用层数据单元），交给传输层。
传输层：HTTP选择TCP协议，将HTTP请求报文封装成TCP段（添加TCP头部，包含源端口、目的端口80、序列号、确认号等），交给网络层。
网络层：将TCP段封装成IP数据报（添加IP头部，包含源IP、目的IP（通过DNS解析域名得到百度服务器IP）、子网掩码等），交给网络接口层。
网络接口层：将IP数据报封装成以太网帧（添加MAC头部，包含源MAC、目的MAC（网关MAC，通过ARP解析得到）、FCS校验码），通过物理介质（网线、无线）发送到网关。
路由转发：网关收到帧后，解封装得到IP数据报，根据目的IP，通过路由表选择最优路由，将IP数据报转发到百度服务器所在的网络。
服务器接收流程（反向）：网络接口层接收帧，解封装得到IP数据报，交给网络层；网络层解封装得到TCP段，交给传输层；传输层解封装得到HTTP请求报文，交给应用层的HTTP协议；应用层处理请求，生成HTTP响应报文，再按照上述流程反向发送给客户端，客户端浏览器解析响应，显示网页。

整个流程中，哪些环节可能出现问题？如何排查？

域名解析失败：排查DNS（ping域名，看是否能解析出IP；检查DNS服务器配置）；
连接建立失败：排查端口（telnet 服务器IP 80，看端口是否开放）、防火墙（是否拦截了TCP 80端口）；
数据传输丢包：排查网络拥塞（查看路由器流量）、TCP重传机制（通过Wireshark抓包，看是否有大量重传报文）；
网页无法显示：排查HTTP响应码（如404（页面不存在）、500（服务器内部错误）），查看服务器日志。