2026年java计算机网络面试题附答案

2026年java计算机网络面试题附答案1.请你说说OSI七层模型和TCP/IP四层模型的区别，以及各层对应常见协议？OSI七层模型是国际标准化组织制定的理论参考模型，特点是先定义模型再设计协议，分层过于细致，很多层的功能在实际应用中极少独立使用，推广过程中没有匹配的成熟协议栈，因此实际生产中没有大规模落地。TCP/IP模型是在现有ARPANET网络协议的基础上总结出来的，更贴合实际应用场景，因此成为了当前互联网的标准模型。两者分层对应关系为：OSI七层分为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层；TCP/IP模型将会话层、表示层、应用层合并为一层应用层，把物理层和数据链路层合并为网络接口层，整体分为网络接口层、网际层、传输层、应用层四层，也有部分教材把物理层和数据链路层分开，得到五层模型，本质都是一致的。各层常见协议为：物理层定义了硬件传输的电气标准，对应设备如集线器、网线；数据链路层负责将比特流封装成帧，通过MAC地址定位局域网内的设备，对应协议有ARP、RARP，设备为二层交换机；网络层负责跨网络寻址和路由，对应协议有IP、ICMP、OSPF，设备为路由器；传输层负责端到端的连接管理和可靠性保障，对应协议TCP、UDP；应用层负责封装应用层面的业务数据，对应协议HTTP、HTTPS、DNS、FTP、SMTP等。在Java网络编程中，我们接触到的Socket编程、Netty通信，本质都是在应用层处理数据封装，底层的拆包封包、路由转发由操作系统内核和网络硬件完成，开发者只需要处理应用层的业务逻辑即可。2.TCP和UDP的核心区别是什么？分别适用于什么场景？TCP是面向连接的可靠传输协议，UDP是无连接的不可靠传输协议，核心区别可以从多个维度总结：第一，连接特性：TCP需要三次握手建立连接，四次挥手释放连接，UDP不需要建立连接，发送方直接发数据即可；第二，可靠性：TCP通过校验和、重传机制、序号保证了数据的不丢失、不重复、按序到达，UDP不做任何可靠性保证，发出去就不管了，丢包错序都不处理；第三，有序性：TCP通过序号对报文排序，接收端会按序号重组，保证应用层拿到有序的数据，UDP不保证有序，报文到达顺序和发送顺序可能不一致；第四，开销：TCP包头最小20字节，最大60字节，UDP包头固定8字节，额外开销远小于TCP；第五，流量控制和拥塞控制：TCP有滑动窗口实现流量控制，还有完整的拥塞控制机制避免网络拥堵，UDP没有这两个机制，发送速率不受限制。适用场景方面，对可靠性要求高、对实时性要求低的场景用TCP，比如文件传输、HTTP/HTTPS请求、数据库连接、邮件传输等；对实时性要求高、可以容忍少量丢包的场景用UDP，比如直播推流、实时音视频会议、在线游戏、DNS查询，当前最新的HTTP/3也是基于UDP实现的，QUIC协议在UDP基础上实现了可靠性，同时解决了TCP的队头阻塞问题，延迟更低。3.TCP建立连接为什么需要三次握手，两次或者四次不行吗？三次握手的核心目的有两个：第一，同步双方的初始序列号，确认双方的发送能力和接收能力都正常；第二，避免产生无效的半连接浪费服务器资源。如果只做两次握手，客户端发送SYN请求连接，服务器回复SYN+ACK后就直接进入连接就绪状态，会存在两个问题：第一，服务器只能确认自己的接收能力正常，客户端的发送能力正常，但是客户端无法确认服务器的接收能力是否正常，也无法确认自己的SYN请求是否成功到达服务器，如果客户端收到服务器的SYN+ACK后不发确认，连接就一直处于半打开状态，无法确认是否建立成功；第二，网络中可能存在延迟的重复SYN请求，比如客户端第一次发送的SYN因为网络阻塞滞留在网络中，客户端重新发送了SYN完成连接，传输结束后断开连接，这时候过期的SYN才到达服务器，如果是两次握手，服务器直接就建立连接了，会一直占用服务器资源，造成资源浪费。如果是三次握手，客户端收到过期SYN对应的SYN+ACK后，会发现自己没有发起这个连接请求，直接回复RST报文中断连接，不会浪费服务器资源。四次握手其实是可以的，只要把第二次握手的SYN和ACK分开发送就变成四次，但是SYN和ACK本来就可以一起发送，合并之后减少一次报文传输，提升握手效率，因此标准流程就是三次握手。4.TCP断开连接为什么需要四次挥手？TIME_WAIT状态为什么要等待2MSL？Java开发中遇到大量TIME_WAIT占用端口怎么解决？TCP是全双工通信，也就是说连接建立后双方可以同时发送和接收数据，断开连接的时候，双方都需要独立关闭自己的发送方向，因此需要四次挥手：客户端发送FIN表示自己不再发送数据了，服务器回复ACK确认客户端的关闭请求，这时候服务器可能还有数据没有发送完，需要等应用层处理完关闭逻辑后，才会发送FIN表示自己也不再发送了，客户端再回复ACK确认，因此FIN和ACK没法合并，就变成了四次挥手。TIME_WAIT状态是主动关闭连接的一方会进入的状态，需要等待2个MSL的时间才会进入CLOSED状态，MSL是最大报文生存时间，指的是一个TCP报文在网络中最大的存活时间，超过时间就会被丢弃。等待2MSL的原因有两个：第一，保证最后一个ACK报文能够成功到达服务器，如果服务器没有收到客户端最后发的ACK，服务器会超时重发FIN，客户端在TIME_WAIT状态可以重新回复ACK，如果不等2MSL直接关闭连接，服务器收不到ACK就会一直处于LAST_ACK状态无法关闭，占用连接资源；第二，让本次连接产生的所有旧报文都从网络中消失，避免后续新的同四元组的连接收到旧的残留报文，导致数据异常。在Java开发中，做网关、短链接压测的时候，经常会遇到大量TIME_WAIT状态的连接占用端口，导致新的连接无法建立，解决方法主要有两种：第一，开启SO_REUSEADDR选项，Java中可以通过调用Socket.setReuseAddress(true)开启，允许操作系统把处于TIME_WAIT状态的端口重新分配给新的连接使用，这个是开发层面最常用的方法；第二，调整操作系统内核参数，比如增大tcp_max_tw_buckets限制，或者开启tcp_tw_reuse快速回收TIME_WAIT连接，适合服务器层面优化。5.请你说说TCP滑动窗口、流量控制和拥塞控制的关系？滑动窗口是TCP实现高效传输和流量控制的核心机制，本质是发送方和接收方各自维护一个连续的窗口区间，窗口大小表示不需要等待ACK就可以连续发送的数据量，不用每发一个报文就停下来等ACK，大幅提升了传输效率。流量控制是点对点的传输控制，作用是让发送方的发送速率不超过接收方的处理能力，避免发送太快导致接收方缓存溢出，流量控制就是通过滑动窗口实现的：接收方每次回复ACK的时候都会带上自己当前的接收窗口大小，告诉发送方自己还能接收多少数据，发送方会根据接收窗口调整自己的发送窗口大小，如果接收窗口变为0，发送方就会停止发送，定期发送零窗口探测报文，等待接收方更新窗口大小。拥塞控制是全局的网络控制，作用是让发送方的发送速率不超过整个网络的承载能力，避免网络拥堵导致大量丢包。实际生产中，发送方的实际发送窗口大小是取接收窗口和拥塞窗口的最小值，也就是`发送窗口=min(接收窗口,拥塞窗口)`，拥塞窗口是发送方根据网络拥堵程度调整的窗口大小。经典的拥塞控制分为四个阶段：慢启动、拥塞避免、快重传、快恢复，当前主流的Linux内核已经开始使用BBR拥塞控制算法，BBR基于带宽和延迟调整拥塞窗口，不是基于丢包判断拥堵，更适合长距离大带宽的网络场景，当前CDN、长连接传输大多已经改用BBR算法，性能比传统的CUBIC算法提升明显。6.HTTP1.0、HTTP1.1、HTTP2.0、HTTP3.0的核心区别是什么？这四个版本的核心差异主要在连接性能和传输效率上：HTTP1.0默认使用短连接，每个请求都需要重新建立TCP连接，传输完成就断开连接，开销很大，不支持缓存，头部是明文传输，带宽利用率低；HTTP1.1默认开启长连接，一个TCP连接可以复用传输多个请求，支持缓存控制、断点续传、分块传输，但是存在应用层面的队头阻塞：同一TCP连接上的请求必须按顺序返回响应，前一个请求的响应没有返回，后面的所有请求都要等着，即使后面的请求已经处理完成也没法交付给客户端，性能仍然受限；HTTP2.0采用二进制分帧，把请求和响应拆分成多个独立的帧传输，实现了同TCP连接下的多路复用，解决了HTTP1.1的应用层队头阻塞，同时采用HPACK算法压缩请求头，大幅减少了头部传输的带宽占用，还支持服务端主动推送，但是HTTP2.0仍然基于TCP传输，存在TCP层面的队头阻塞：同一个TCP连接上如果某个报文丢包，整个TCP连接都要等这个报文重传完成才能继续交付数据，所有流都会被堵住；HTTP3.0基于QUIC协议，运行在UDP之上，彻底解决了TCP层面的队头阻塞：QUIC把每个请求对应一个独立流，每个流独立做丢包重传，一个流丢包不会影响其他流的传输，同时QUIC支持0-RTT握手，后续连接可以直接发送数据，延迟比HTTP2.0低很多，还支持连接迁移：客户端IP地址变化（比如从WIFI切到移动网络）的时候，不需要重新建立连接，因为QUIC用连接ID标识连接，不是用四元组，解决了TCPIP变更连接断开的问题，还内置了TLS1.3加密，安全性更高，是当前HTTP协议的发展方向。7.HTTPS为什么安全？请你说说HTTPS的握手过程？HTTPS是HTTP运行在TCP+TLS/SSL之上，HTTP是明文传输，HTTPS通过加密和证书验证保证传输安全，HTTPS默认端口是443，HTTP默认端口是80。HTTPS的安全机制是结合了非对称加密和对称加密，再加上CA证书验证服务器身份，具体来说：用非对称加密交换对称加密的密钥，然后用对称加密加密传输业务数据，用CA证书验证服务器身份，防止中间人攻击。常用的单向HTTPS握手过程如下：第一步，客户端发送ClientHello，把自己支持的TLS版本、加密套件、客户端随机数发给服务器；第二步，服务器回复ServerHello，确认双方使用的TLS版本和加密套件，生成服务器随机数发给客户端，然后发送服务器的CA证书，之后发送ServerHelloDone结束本轮消息；第三步，客户端验证CA证书的合法性，验证域名是否匹配、是否过期、是否是可信CA颁发，验证通过后生成预主密钥，用证书中的服务器公钥加密预主密钥发给服务器；第四步，服务器用自己的私钥解密得到预主密钥，然后双方根据客户端随机数、服务器随机数、预主密钥协商出一致的会话密钥，也就是后续对称加密用的密钥；第五步，客户端发送ChangeCipherSpec消息，告诉服务器后续所有通信都用会话密钥加密，然后发送Finished消息；第六步，服务器发送ChangeCipherSpec和Finished消息，握手完成，后续双方用会话密钥加密传输HTTP数据就可以了。不直接用非对称加密加密所有数据的原因是非对称加密运算开销大，性能远低于对称加密，不适合大量业务数据的传输，因此结合两种加密的优势，兼顾安全和性能。8.TCP粘包拆包是怎么产生的？Java开发中怎么解决？TCP是面向字节流的协议，本身没有数据包边界，发送方发送的多个数据包，可能会被TCP合并成一个大数据包发给接收方，也就是粘包，一个大的数据包也可能被TCP拆分成多个小数据包发给接收方，也就是拆包。粘包拆包产生的原因主要有三个：第一，应用层写入的数据大小超过TCP的MSS（最大报文段长度），TCP会自动拆分成多个报文发送；第二，Nagle算法会把多个小的、间隔短的数据包合并成一个大报文一起发送，减少网络报文数量，提升带宽利用率，合并之后就会产生粘包；第三，接收方读取缓存的时候，一次读取的大小小于实际数据大小，就会出现拆包。Java开发中解决粘包拆包的常用方案有四种：第一，定长分包，每个数据包的长度固定，不足的部分用空白字符填充，这种方法实现简单，但是会浪费带宽，适合固定长度报文的场景；第二，分隔符分包，用特殊的分隔符（比如换行符）作为数据包的边界，接收方读到分隔符就把之前的数据当做一个完整包，Netty中的LineBasedFrameDecoder就是这个方案的实现，适合行文本类的协议；第三，长度字段分包，在数据包头部写入当前数据包的总长度，接收方先读长度字段，再根据长度读取对应长度的内容，得到完整的数据包，Netty中的LengthFieldBasedFrameDecoder就是这个方案的实现，是当前最常用的方案，适合绝大多数自定义TCP协议的场景；第四，应用层协议本身已经处理了边界问题，比如HTTP协议本身就通过Content-Length或者分块传输标识了数据长度，不需要开发者额外处理。9.TCP队头阻塞和HTTP队头阻塞有什么区别？很多开发者容易混淆这两个概念，两者发生的层面和原因都不一样：HTTP1.1的队头阻塞是应用层的队头阻塞，HTTP1.1支持长连接，但是同一连接上的请求必须按顺序处理和返回响应，如果前面的请求处理很慢，后面的请求即使已经处理完成，也必须等前面的响应返回才能交付给客户端，因此整个连接被堵住，HTTP2通过多路复用把不同请求拆分成独立帧交叉传输，解决了应用层的队头阻塞。TCP的队头阻塞是传输层本身的问题，TCP是面向字节流的有序协议，要求所有报文按顺序交付给应用层，如果同一个TCP连接上的某个报文丢失了，即使后面的所有报文都已经到达了接收方的缓存，也必须等丢失的报文重传完成，才能把所有报文按顺序交付给应用层，因此即使HTTP2实现了应用层的多路复用，只要跑在TCP上，就仍然存在TCP层面的队头阻塞，一个报文丢包就会堵住所有流，HTTP3基于QUIC跑在UDP上，每个流独立做丢包重传和顺序交付，因此彻底解决了TCP层面的队头阻塞，性能更好。10.GET和POST的核心区别是什么？HTTP规范中定义GET用来获取资源，POST用来提交资源，两者本质都是HTTP请求，遵循相同的报文格式，但是实际开发中有很多核心区别：第一，参数位置不同：GET的参数拼接在URL中，POST的参数放在请求体中；第二，长度限制：HTTP规范本身没有对GET的长度做限制，但是浏览器和服务器会对URL的长度做限制，一般最长几KB到几MB，POST的请求体没有长度限制；第三，缓存特性：GET请求会被浏览器主动缓存，会保存在浏览器的历史记录中，POST默认不会缓存，也不会保存在历史记录中；第四，安全性：GET参数明文放在URL中，不适合传递敏感信息，POST参数放在请求体中，相对更隐蔽，但是如果不使用HTTPS，请求体也是明文，仍然不安全，敏感信息必须用HTTPS加密传输；第五，幂等性：GET是幂等的，多次请求同一个GET接口，结果是一致的，不会改变资源，POST不是幂等的，重复提交POST请求可能会产生多个资源，因此重复提交POST会有问题。11.Session和Cookie的区别是什么？为什么现在微服务架构中常用JWT替代Session？Session是服务器端保存用户会话信息的机制，Cookie是客户端保存信息的机制，核心区别是：第一，存储位置不同：Session存储在服务器端，Cookie存储在客户端浏览器中；第二，安全性：Session存在服务器，更安全，不容易被篡改，Cooki