1. 从一次前后端联调失败说起为什么Java后端必须懂网络我印象很深刚带团队那会儿有个刚入职的同事调接口前端说连不上后端后端说我明明启动了两边都是新手在群里吵了半小时。最后我去看了一眼后端服务监听的是127.0.0.1而前端在另一台机器上访问当然不通。这其实不是代码逻辑问题纯粹是网络基础没打牢。很多初学JavaEE的人有个误区觉得网络是运维或者网络工程师的事自己写业务代码用不到。但实际做项目你会发现接口超时了你要能判断是DNS解析慢还是带宽不够还是对方服务挂了两台服务器的服务调不通你要会用命令一步步定位是网络不通还是防火墙拦截还是端口没监听写Socket通信、做HTTP调用、配置Nginx反向代理桩桩件件都离不开网络基础。这篇文章就是写给JavaEE初学阶段的朋友用够用、实用的标准把网络这层窗户纸捅破。不背概念不堆术语全部围绕Java后端开发实际会遇到的场景来拆解网络分层到底怎么分、IP和端口是怎么回事、TCP和UDP该怎么选、HTTP协议在工作里长什么样以及一个手写的Java网络通信实例。学完你能达到的水平是能看懂网络相关的报错、能自己排查简单的连通性问题、能理解接口调用的底层流程。2. 网络分层开发时不需要背七层但必须懂四层的分工逻辑刚接触网络的人最容易在OSI七层模型上犯迷糊面试也总被问但坦白讲日常写Java代码真正用到的思维模型是四层——应用层、传输层、网络层、链路层。理解这套分层逻辑比死记七层的名字有用得多。2.1 分层到底在解决什么问题你可以把网络通信想象成寄快递。你写代码调用一个HTTP接口这个动作发生在应用层相当于你在包裹单上写了收件人信息运输层传输层负责选择运输方式是走普通快递还是顺丰加急对应TCP和UDP的选择网络层负责规划包裹怎么从北京到上海走哪条高速公路对应IP地址的路由寻址链路层则是实际在高速公路上跑的货车对应网卡、交换机这些物理传输设备。每一层只关心自己该管的事不需要知道其他层的实现细节。这就是分层最大的价值解耦。就好比你寄快递不需要关心货车烧的什么油开车的司机也不需要知道包裹里装的是衣服还是电子产品。2.2 Java开发最需要关注的两层应用层和传输层是写代码时打交道最多的两层。应用层就是你的Java代码——SpringMVC接收到的HTTP请求、你写的WebSocket通信、用Netty写的自定义协议都属于应用层的范畴。这一层管的是数据怎么组织和表达所以会有各种协议HTTP、HTTPS、WebSocket、FTP、SMTP。传输层管的是数据怎么可靠地送达两个核心协议就是TCP和UDP。这里有个很多人忽略的关键点HTTP协议本身是建立在TCP之上的。也就是说当你用HttpClient发一个GET请求底层其实是先建立了一条TCP连接然后在这条连接上用HTTP的格式传输数据。网络层和链路层对Java开发来说更多是排障时需要用到的知识。比如ping命令看网络通不通traceroute看数据包走了哪些路由节点这时候你需要理解IP地址和路由的概念。提示如果你面试被问到OSI七层可以说出七层名称但更重要的是能讲清楚数据从应用层到链路层逐层封装接收端逐层解封装这个过程这才体现你真的理解了分层思想。2.3 一个Http请求经过的完整链路结合一个实际的HttpClient调用来看分层的作用你的Java代码 - HTTP协议(应用层) - TCP协议(传输层) - IP协议(网络层) - 网卡发送(链路层)每一层在发送数据时都会加上自己的头信息——HTTP加HTTP头TCP加TCP头IP加IP头。接收端拿到数据后从下往上逐层剥掉头信息最终还原出原始数据。这就是封装和分用的过程。理解了这条链路你就明白为什么前端说请求超时时问题可能出现在任何一个环节DNS解析失败应用层、TCP连接不上传输层、IP路由不通网络层、网线断了链路层。排查的方向自然就有了。3. IP、端口和DNS你敲下URL之后发生了什么网络通信的三要素是IP地址、端口、协议。这三个概念单独看都不难但组合在一起再掺上DNS解析和IPv4/IPv6的细节就有很多容易踩的坑。3.1 IP地址不是随便配的IP地址标识一台主机在网络中的位置相当于你家的门牌号。IPv4是32位的形如192.168.1.100分网络号和主机号两部分。子网掩码就是用来划分这两部分的255.255.255.0代表前三段是网络号最后一段是主机号。这里有个做开发必须懂的常识127.0.0.1是回环地址代表本机。0.0.0.0代表本机的所有IP地址。开头那个联调失败的故事问题就出在服务只监听了127.0.0.1外部机器自然访问不到。所以SpringBoot项目如果要在局域网被别人访问server.address要配成0.0.0.0或者干脆不配。还有几个特殊的IP段要记住10.0.0.0/8、172.16.0.0/12、192.168.0.0/16私有IP地址只能在局域网内使用不能直接在公网路由。169.254.x.xDHCP分配失败时自动生成的临时地址看到这个地址通常意味着网卡没拿到IP。IPv6是128位的主要解决IPv4地址枯竭的问题。现在云服务器基本都支持IPv6了但很多内部系统还在用IPv4短期内不会完全切换。3.2 端口一台机器上怎么跑多个服务一台服务器上可以同时跑MySQL3306、Redis6379、SpringBoot8080、Nginx80它们是怎么区分的靠的就是端口号。端口号范围是0到65535其中0到1023知名端口通常需要管理员权限才能绑定比如HTTP的80、HTTPS的443、FTP的21。1024到49151注册端口常见的MySQL 3306、Redis 6379、Tomcat 8080都在这个范围。49152到65535动态/私有端口客户端主动发起连接时系统会随机分配一个这个范围的端口作为源端口。IP地址加端口号组合起来就是Socket地址形如192.168.1.100:8080。这才完整地标识了一个通信端点。踩坑经验很多人部署项目时遇到端口被占用在Linux上可以用netstat -tlnp | grep 8080查看哪个进程占用了8080端口然后用kill -9加上进程PID清理。Windows上对应的是netstat -ano | findstr 8080和taskkill /PID xxx /F。3.3 DNS解析你访问www.example.com浏览器需要先把这个域名解析成IP地址才能发起连接。这个过程就是DNS解析。完整的解析流程是这样的浏览器先查自己的DNS缓存没有就去查操作系统缓存还没有就请求本地配置的DNS服务器比如你路由器或者运营商给的本地DNS服务器如果也没有就会向根域名服务器、顶级域名服务器、权威域名服务器逐级查询。作为开发你至少要知道这三个命令nslookup example.com查询域名对应的IP地址。dig example.com更详细的DNS查询工具能看到解析用了多长时间、走了哪些服务器。ping example.com不仅能测连通性第一行也会显示解析出来的IP。遇到域名解析不了的报错先确认是不是DNS问题——用nslookup查一下如果解析正常那就是应用层的问题如果解析失败可能要换DNS服务器比如改成8.8.8.8或者114.114.114.114。注意修改/etc/hosts文件可以绕过DNS解析直接指定域名对应的IP。这在开发环境联调、测试环境切换时特别有用。改完之后通常不需要重启但浏览器缓存可能需要刷新Chrome里访问chrome://net-internals/#dns手动清一下。4. TCP和UDP核心机制知道这些才能跟人聊明白可靠传输TCP和UDP是传输层的两个核心协议Java的Socket和DatagramSocket就是分别基于它们实现的。很多人在学校学过三次握手、四次挥手但到了实际项目里就只剩一个模糊印象。这里不背概念讲清楚它们各自解决什么问题、什么时候用谁。4.1 TCP的三次握手和四次挥手TCP是面向连接的、可靠的、基于字节流的传输协议。三次握手建立连接四次挥手断开连接。三次握手的过程用大白话讲就是客户端说喂我要跟你建立连接你能听到吗发送SYN包服务端回应听到了我也准备好跟你连接了。发送SYNACK包客户端再确认收到那咱俩开始传数据吧。发送ACK包为什么非要三次而不是两次核心原因是需要确认双方的收发能力都正常。第一次握手服务端确认了客户端的发送能力没问题第二次握手客户端确认了服务端的收发能力都没问题但此时服务端还不知道客户端的接收能力是否正常所以需要第三次握手客户端通知服务端我的接收能力也OK。这是一个经典的双方状态确认问题。四次挥手断开连接的过程则是主动关闭方比如客户端说我这边数据发完了准备关闭连接。发送FIN包被动关闭方回应收到你的关闭请求。发送ACK包被动关闭方把自己这边的数据也发完后说我这也发完了可以关了。发送FIN包主动关闭方回应知道了。发送ACK包然后等待一段时间TIME_WAIT后彻底关闭。这里有个实际开发会遇到的坑大量TIME_WAIT。主动关闭连接的一方在收到对方的FIN包并回复ACK后会进入TIME_WAIT状态持续大约2分钟。如果你的服务端频繁主动关闭连接比如用了短连接且连接池配置不当就可能积累大量TIME_WAIT导致端口被占满新连接无法建立。排查命令是netstat -ant | grep TIME_WAIT | wc -l。4.2 TCP的可靠传输机制TCP保证数据不丢、不乱序、不重复靠的是一整套机制确认应答ACK每收到一个数据段接收方都要回复确认。超时重传发送方如果在一定时间内没收到ACK就重新发送数据。滑动窗口允许发送方在收到ACK之前连续发送多个数据段提高效率。流量控制根据接收方的处理能力动态调整发送窗口大小避免接收方来不及处理。拥塞控制通过慢启动、拥塞避免、快重传、快恢复等算法避免网络过载。这些机制对Java开发的实际意义在于TCP把这些复杂性都封装好了你只管往流里写数据底层会确保可靠性。但代价是效率比UDP低而且如果是长连接还可能遇到TCP粘包、拆包问题——后面会详细说。4.3 UDP无连接快但不保证到达UDP是面向无连接的、不可靠的、基于数据报的传输协议。它不建立连接直接把数据包发出去不保证到达、不保证顺序、不保证不重复。既然TCP这么可靠为什么还需要UDP因为有些场景宁可丢数据也不愿意等。最典型的就是视频直播、语音通话——你正在看直播如果某个画面丢了顶多卡顿一下但如果因为重传机制等半天体验反而更差。再比如DNS查询、DHCP获取IP用的也是UDP。选择TCP还是UDP核心判断标准是这个数据丢了能不能容忍如果不能容忍用TCP如果更在意实时性用UDP。Java里TCP用Socket/ServerSocketUDP用DatagramSocket/DatagramPacket。4.4 Java开发者最容易踩的TCP粘包拆包坑用TCP传输数据时你调用outputStream.write()写入的每个消息TCP底层面板不知道消息边界在哪。它只按照自己的缓冲区大小来切分数据这就可能导致发送方连发两个消息接收方一次性读到两个消息粘包或者发送一个很大的消息接收方分多次才读完拆包。这个问题的解决方案在Java框架里已经很成熟了给消息加上长度字段或者用特殊分隔符。Netty里有LengthFieldBasedFrameDecoder和DelimiterBasedFrameDecoder可以直接用。如果自己写原生Socket就得手动处理——在消息头里放4字节的长度信息接收方先读长度再按长度读完整消息体。我见过不少新手直接用read(byte[])读数据结果数据不完整然后疯狂怀疑是网络问题。实际上这就是没处理粘包拆包。5. HTTP协议Java后端天天打交道的应用层约定HTTP是Web开发最核心的应用层协议Java后端写接口、调接口都离不开它。但很多人对HTTP的理解停留在发个请求、收个响应的层面真出了问题不知道怎么排查。这里把关键点梳理一遍。5.1 请求报文和响应报文的结构一个HTTP请求报文由三部分组成请求行、请求头、请求体。响应报文由状态行、响应头、响应体组成。请求行长这样POST /api/users HTTP/1.1包含请求方法、URI、协议版本。请求头是键值对比如Content-Type: application/json、Authorization: Bearer xxx。请求体就是实际传输的数据POST请求通常在这里。响应状态行HTTP/1.1 200 OK其中200是状态码OK是原因短语。响应头包含Content-Type、Content-Length、Set-Cookie等信息。响应体就是返回的数据。这里最容易踩的坑是状态码语义理解错误。举几个典型例子200成功这个没问题。301永久重定向浏览器会自动跳转到新的地址并且会缓存跳转结果。302临时重定向浏览器也会自动跳转但不会缓存。403服务器拒绝了请求通常是权限不足。404资源不存在。500服务器内部错误通常是代码抛异常没处理。502网关或代理服务器收到上游服务器的无效响应典型场景是Nginx后面的Java服务挂了。503服务不可用通常是服务过载或正在维护。实际排查时看到4xx先查请求参数和权限看到5xx直接去查后端日志别在前端瞎找。5.2 HTTP和HTTPS的区别HTTPS就是在HTTP和TCP之间加了一层TLS/SSL加密层。它能解决三个问题防窃听加密传输内容、防篡改有完整性校验、防冒充有证书认证。Java后端对接HTTPS接口时最常见的坑是证书问题。比如你在本地调试访问一个自签名证书的HTTPS接口直接调用会报PKIX path building failed或者SSLHandshakeException。解决方式有几种把自签名证书导入JDK的cacerts证书库。让HttpClient信任所有证书仅限本地开发环境生产千万别这么干。用-Djavax.net.ssl.trustStore...指定信任库。5.3 HTTP的发展HTTP/1.1是现在最常用的版本它的核心特性是持久连接Keep-Alive同一个TCP连接上可以发送多个请求。但它有个问题——队头阻塞同一个连接上的请求必须按顺序处理前一个请求没响应完后面的就得等着。HTTP/2引入了多路复用一个TCP连接上可以同时并行多个请求和响应队头阻塞问题得到了很大改善。它还有头部压缩、服务器推送等特性。HTTP/3则更进一步把传输层从TCP换成了基于UDP的QUIC协议解决了TCP层面的队头阻塞和连接建立慢的问题。但对Java后端来说目前主要还是对接HTTP/1.1和HTTP/2HTTP/3在实际生产中还比较少。5.4 用抓包工具看清HTTP请求排查接口问题最好的方式就是抓包看真实报文。Wireshark是通用的抓包工具但很多Java开发者更习惯用Charles或者Fiddler这类HTTP抓包工具。这里分享一个真实排查案例有一个同事反馈说接口偶发性报错时好时坏。用Charles抓包后发现请求头里的Content-Type偶尔会丢导致服务端解析不到参数。最后定位到是同事在代码里用HashMap存请求头而HashMap不保证顺序某些情况下头字段被覆盖了。这种问题不看真实报文永远找不到原因。提示如果你是远程服务器上排查问题不方便装图形化抓包工具可以用tcpdump -i eth0 port 8080 -w /tmp/capture.pcap抓包然后把抓包文件下载到本地用Wireshark分析。6. 常用网络排查命令一套体检流程解决八成联调问题学网络基础理论再熟不会排障等于白学。很多时候前后端联调报错问题既不在前端代码也不在后端代码就是网络层面的问题。掌握下面这套体检流程能解决大部分联调问题。6.1 一套标准的排查流程遇到网络通信问题我习惯按顺序执行以下命令第一步确认对方主机通不通ping 目标IP。通说明网络链路和IP配置没问题不通看是Request timed out还是Destination Host Unreachable。前者可能是对方防火墙拦截了ICMP后者通常是路由不通。第二步确认目标端口是否开放telnet 目标IP 端口。连接成功说明端口开放连接失败说明端口没开放或者被防火墙拦截。Windows 10以上版本默认没开telnet客户端可以用Test-NetConnection -ComputerName IP -Port 端口测试。第三步查看路由路径traceroute 目标IPWindows下是tracert。可以看到数据包经过了哪些路由节点哪一跳超时帮助定位是哪个环节的问题。第四步查看本机网络配置ipconfigWindows或ifconfig/ip addrLinux。确认IP、子网掩码、网关是否正确。第五步查看本机路由表route printWindows或ip routeLinux。确认数据包该走的网关对不对。6.2 监听和连接状态的查看netstat是在服务器上用得最多的命令之一。netstat -ant查看所有TCP连接的详细状态状态包括LISTEN监听中、ESTABLISHED已建立连接、TIME_WAIT、CLOSE_WAIT等。netstat -anp | grep 8080Linux需要加p参数显示进程查看8080端口被谁占用。ss -ant比netstat更快更现代的工具推荐优先用。实际项目里CLOSE_WAIT状态过多是一个经典问题。CLOSE_WAIT表示对方发了FIN包要求关闭连接但本机还没调用close()关闭Socket。如果CLOSE_WAIT过多通常是代码里没有正确关闭连接。排查方式和修复方案用lsof -i :端口找PID再用jstack PID看线程状态定位到是哪个连接没关。6.3 排查防火墙Linux上排查网络不通别忘了查防火墙。很多云服务器的坑都是安全组没放行端口或本地防火墙拦截了端口。检查当前生效的防火墙规则iptables -L -n -v。临时放行某个端口iptables -I INPUT -p tcp --dport 8080 -j ACCEPT。如果是firewalld用firewall-cmd --list-all查看firewall-cmd --add-port8080/tcp --permanent放行端口后记得firewall-cmd --reload。云服务器还有个容易忽略的地方——安全组。阿里云、腾讯云、AWS这些云厂商的安全组相当于云环境里的防火墙即使你本机防火墙全关了安全组没放行端口一样不通。遇到明明把防火墙关了还是连不上的现象第一反应就去查安全组。7. 一个Java网络通信实例从Socket到HTTP的完整手写过程前面讲的都是理论这里写一段真实可运行的Java代码把网络通信的一整个流程跑通。这个例子用的是JDK原生的ServerSocket和Socket不引入任何框架目的是让你看清底层机制。7.1 写一个TCP服务端服务端代码的核心逻辑创建ServerSocket绑定端口循环接收客户端连接为每个连接创建独立线程处理请求。import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.io.OutputStream; import java.net.ServerSocket; import java.net.Socket; import java.nio.charset.StandardCharsets; public class TcpServer { public static void main(String[] args) throws IOException { // 监听本机的9999端口 ServerSocket serverSocket new ServerSocket(9999); System.out.println(服务器已启动监听端口9999); while (true) { // accept()会阻塞直到有客户端连接进来 Socket socket serverSocket.accept(); System.out.println(收到客户端连接 socket.getRemoteSocketAddress()); // 每个连接单独开一个线程处理 new Thread(() - handleClient(socket)).start(); } } private static void handleClient(Socket socket) { try (BufferedReader in new BufferedReader(new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); OutputStream out socket.getOutputStream()) { // 读取客户端发送的一行数据 String line in.readLine(); System.out.println(收到消息 line); // 回传响应 String response Server received: line \n; out.write(response.getBytes(StandardCharsets.UTF_8)); out.flush(); } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { e.printStackTrace(); } } } }注意细节用additionalStream包裹的流在try-with-resources里会自动关闭Socket最好也手动关。accept()是阻塞方法收到连接才返回所以主线程通过while(true)循环持续接客。生产环境不会这样每连接一个线程而是用线程池或者Netty。因为每连接一个线程在大量连接下会耗尽系统资源。7.2 写一个TCP客户端客户端代码核心逻辑创建Socket连接服务端通过输出流发数据通过输入流接收响应。import java.io.*; import java.net.Socket; public class TcpClient { public static void main(String[] args) throws IOException { // 连接本机9999端口 Socket socket new Socket(127.0.0.1, 9999); System.out.println(已连接到服务器); BufferedWriter writer new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), StandardCharsets.UTF_8)); BufferedReader reader new BufferedReader(new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); // 发送数据 writer.write(Hello, TCP Server!\n); writer.flush(); // 读取服务端响应 String response reader.readLine(); System.out.println(服务端响应 response); socket.close(); } }跑这段代码的流程是先启动TcpServer再启动TcpClient服务端控制台会打印收到消息客户端控制台会打印服务端响应。你会发现服务端那边accept()阻塞等待客户端一连接就返回双方通过Socket这个抽象来交换数据。7.3 用curl模拟HTTP请求上面的TCP例子是自定义的文本协议。实际的HTTP请求报文其实也是文本只是格式固定。你完全可以用Socket发送一段HTTP报文curl -v http://127.0.0.1:9999/用-v参数可以看到完整的请求和响应报文。如果你访问的是这个Java服务服务端收到的是一
1. 从一次前后端联调失败说起为什么Java后端必须懂网络我印象很深刚带团队那会儿有个刚入职的同事调接口前端说连不上后端后端说我明明启动了两边都是新手在群里吵了半小时。最后我去看了一眼后端服务监听的是127.0.0.1而前端在另一台机器上访问当然不通。这其实不是代码逻辑问题纯粹是网络基础没打牢。很多初学JavaEE的人有个误区觉得网络是运维或者网络工程师的事自己写业务代码用不到。但实际做项目你会发现接口超时了你要能判断是DNS解析慢还是带宽不够还是对方服务挂了两台服务器的服务调不通你要会用命令一步步定位是网络不通还是防火墙拦截还是端口没监听写Socket通信、做HTTP调用、配置Nginx反向代理桩桩件件都离不开网络基础。这篇文章就是写给JavaEE初学阶段的朋友用够用、实用的标准把网络这层窗户纸捅破。不背概念不堆术语全部围绕Java后端开发实际会遇到的场景来拆解网络分层到底怎么分、IP和端口是怎么回事、TCP和UDP该怎么选、HTTP协议在工作里长什么样以及一个手写的Java网络通信实例。学完你能达到的水平是能看懂网络相关的报错、能自己排查简单的连通性问题、能理解接口调用的底层流程。2. 网络分层开发时不需要背七层但必须懂四层的分工逻辑刚接触网络的人最容易在OSI七层模型上犯迷糊面试也总被问但坦白讲日常写Java代码真正用到的思维模型是四层——应用层、传输层、网络层、链路层。理解这套分层逻辑比死记七层的名字有用得多。2.1 分层到底在解决什么问题你可以把网络通信想象成寄快递。你写代码调用一个HTTP接口这个动作发生在应用层相当于你在包裹单上写了收件人信息运输层传输层负责选择运输方式是走普通快递还是顺丰加急对应TCP和UDP的选择网络层负责规划包裹怎么从北京到上海走哪条高速公路对应IP地址的路由寻址链路层则是实际在高速公路上跑的货车对应网卡、交换机这些物理传输设备。每一层只关心自己该管的事不需要知道其他层的实现细节。这就是分层最大的价值解耦。就好比你寄快递不需要关心货车烧的什么油开车的司机也不需要知道包裹里装的是衣服还是电子产品。2.2 Java开发最需要关注的两层应用层和传输层是写代码时打交道最多的两层。应用层就是你的Java代码——SpringMVC接收到的HTTP请求、你写的WebSocket通信、用Netty写的自定义协议都属于应用层的范畴。这一层管的是数据怎么组织和表达所以会有各种协议HTTP、HTTPS、WebSocket、FTP、SMTP。传输层管的是数据怎么可靠地送达两个核心协议就是TCP和UDP。这里有个很多人忽略的关键点HTTP协议本身是建立在TCP之上的。也就是说当你用HttpClient发一个GET请求底层其实是先建立了一条TCP连接然后在这条连接上用HTTP的格式传输数据。网络层和链路层对Java开发来说更多是排障时需要用到的知识。比如ping命令看网络通不通traceroute看数据包走了哪些路由节点这时候你需要理解IP地址和路由的概念。提示如果你面试被问到OSI七层可以说出七层名称但更重要的是能讲清楚数据从应用层到链路层逐层封装接收端逐层解封装这个过程这才体现你真的理解了分层思想。2.3 一个Http请求经过的完整链路结合一个实际的HttpClient调用来看分层的作用你的Java代码 - HTTP协议(应用层) - TCP协议(传输层) - IP协议(网络层) - 网卡发送(链路层)每一层在发送数据时都会加上自己的头信息——HTTP加HTTP头TCP加TCP头IP加IP头。接收端拿到数据后从下往上逐层剥掉头信息最终还原出原始数据。这就是封装和分用的过程。理解了这条链路你就明白为什么前端说请求超时时问题可能出现在任何一个环节DNS解析失败应用层、TCP连接不上传输层、IP路由不通网络层、网线断了链路层。排查的方向自然就有了。3. IP、端口和DNS你敲下URL之后发生了什么网络通信的三要素是IP地址、端口、协议。这三个概念单独看都不难但组合在一起再掺上DNS解析和IPv4/IPv6的细节就有很多容易踩的坑。3.1 IP地址不是随便配的IP地址标识一台主机在网络中的位置相当于你家的门牌号。IPv4是32位的形如192.168.1.100分网络号和主机号两部分。子网掩码就是用来划分这两部分的255.255.255.0代表前三段是网络号最后一段是主机号。这里有个做开发必须懂的常识127.0.0.1是回环地址代表本机。0.0.0.0代表本机的所有IP地址。开头那个联调失败的故事问题就出在服务只监听了127.0.0.1外部机器自然访问不到。所以SpringBoot项目如果要在局域网被别人访问server.address要配成0.0.0.0或者干脆不配。还有几个特殊的IP段要记住10.0.0.0/8、172.16.0.0/12、192.168.0.0/16私有IP地址只能在局域网内使用不能直接在公网路由。169.254.x.xDHCP分配失败时自动生成的临时地址看到这个地址通常意味着网卡没拿到IP。IPv6是128位的主要解决IPv4地址枯竭的问题。现在云服务器基本都支持IPv6了但很多内部系统还在用IPv4短期内不会完全切换。3.2 端口一台机器上怎么跑多个服务一台服务器上可以同时跑MySQL3306、Redis6379、SpringBoot8080、Nginx80它们是怎么区分的靠的就是端口号。端口号范围是0到65535其中0到1023知名端口通常需要管理员权限才能绑定比如HTTP的80、HTTPS的443、FTP的21。1024到49151注册端口常见的MySQL 3306、Redis 6379、Tomcat 8080都在这个范围。49152到65535动态/私有端口客户端主动发起连接时系统会随机分配一个这个范围的端口作为源端口。IP地址加端口号组合起来就是Socket地址形如192.168.1.100:8080。这才完整地标识了一个通信端点。踩坑经验很多人部署项目时遇到端口被占用在Linux上可以用netstat -tlnp | grep 8080查看哪个进程占用了8080端口然后用kill -9加上进程PID清理。Windows上对应的是netstat -ano | findstr 8080和taskkill /PID xxx /F。3.3 DNS解析你访问www.example.com浏览器需要先把这个域名解析成IP地址才能发起连接。这个过程就是DNS解析。完整的解析流程是这样的浏览器先查自己的DNS缓存没有就去查操作系统缓存还没有就请求本地配置的DNS服务器比如你路由器或者运营商给的本地DNS服务器如果也没有就会向根域名服务器、顶级域名服务器、权威域名服务器逐级查询。作为开发你至少要知道这三个命令nslookup example.com查询域名对应的IP地址。dig example.com更详细的DNS查询工具能看到解析用了多长时间、走了哪些服务器。ping example.com不仅能测连通性第一行也会显示解析出来的IP。遇到域名解析不了的报错先确认是不是DNS问题——用nslookup查一下如果解析正常那就是应用层的问题如果解析失败可能要换DNS服务器比如改成8.8.8.8或者114.114.114.114。注意修改/etc/hosts文件可以绕过DNS解析直接指定域名对应的IP。这在开发环境联调、测试环境切换时特别有用。改完之后通常不需要重启但浏览器缓存可能需要刷新Chrome里访问chrome://net-internals/#dns手动清一下。4. TCP和UDP核心机制知道这些才能跟人聊明白可靠传输TCP和UDP是传输层的两个核心协议Java的Socket和DatagramSocket就是分别基于它们实现的。很多人在学校学过三次握手、四次挥手但到了实际项目里就只剩一个模糊印象。这里不背概念讲清楚它们各自解决什么问题、什么时候用谁。4.1 TCP的三次握手和四次挥手TCP是面向连接的、可靠的、基于字节流的传输协议。三次握手建立连接四次挥手断开连接。三次握手的过程用大白话讲就是客户端说喂我要跟你建立连接你能听到吗发送SYN包服务端回应听到了我也准备好跟你连接了。发送SYNACK包客户端再确认收到那咱俩开始传数据吧。发送ACK包为什么非要三次而不是两次核心原因是需要确认双方的收发能力都正常。第一次握手服务端确认了客户端的发送能力没问题第二次握手客户端确认了服务端的收发能力都没问题但此时服务端还不知道客户端的接收能力是否正常所以需要第三次握手客户端通知服务端我的接收能力也OK。这是一个经典的双方状态确认问题。四次挥手断开连接的过程则是主动关闭方比如客户端说我这边数据发完了准备关闭连接。发送FIN包被动关闭方回应收到你的关闭请求。发送ACK包被动关闭方把自己这边的数据也发完后说我这也发完了可以关了。发送FIN包主动关闭方回应知道了。发送ACK包然后等待一段时间TIME_WAIT后彻底关闭。这里有个实际开发会遇到的坑大量TIME_WAIT。主动关闭连接的一方在收到对方的FIN包并回复ACK后会进入TIME_WAIT状态持续大约2分钟。如果你的服务端频繁主动关闭连接比如用了短连接且连接池配置不当就可能积累大量TIME_WAIT导致端口被占满新连接无法建立。排查命令是netstat -ant | grep TIME_WAIT | wc -l。4.2 TCP的可靠传输机制TCP保证数据不丢、不乱序、不重复靠的是一整套机制确认应答ACK每收到一个数据段接收方都要回复确认。超时重传发送方如果在一定时间内没收到ACK就重新发送数据。滑动窗口允许发送方在收到ACK之前连续发送多个数据段提高效率。流量控制根据接收方的处理能力动态调整发送窗口大小避免接收方来不及处理。拥塞控制通过慢启动、拥塞避免、快重传、快恢复等算法避免网络过载。这些机制对Java开发的实际意义在于TCP把这些复杂性都封装好了你只管往流里写数据底层会确保可靠性。但代价是效率比UDP低而且如果是长连接还可能遇到TCP粘包、拆包问题——后面会详细说。4.3 UDP无连接快但不保证到达UDP是面向无连接的、不可靠的、基于数据报的传输协议。它不建立连接直接把数据包发出去不保证到达、不保证顺序、不保证不重复。既然TCP这么可靠为什么还需要UDP因为有些场景宁可丢数据也不愿意等。最典型的就是视频直播、语音通话——你正在看直播如果某个画面丢了顶多卡顿一下但如果因为重传机制等半天体验反而更差。再比如DNS查询、DHCP获取IP用的也是UDP。选择TCP还是UDP核心判断标准是这个数据丢了能不能容忍如果不能容忍用TCP如果更在意实时性用UDP。Java里TCP用Socket/ServerSocketUDP用DatagramSocket/DatagramPacket。4.4 Java开发者最容易踩的TCP粘包拆包坑用TCP传输数据时你调用outputStream.write()写入的每个消息TCP底层面板不知道消息边界在哪。它只按照自己的缓冲区大小来切分数据这就可能导致发送方连发两个消息接收方一次性读到两个消息粘包或者发送一个很大的消息接收方分多次才读完拆包。这个问题的解决方案在Java框架里已经很成熟了给消息加上长度字段或者用特殊分隔符。Netty里有LengthFieldBasedFrameDecoder和DelimiterBasedFrameDecoder可以直接用。如果自己写原生Socket就得手动处理——在消息头里放4字节的长度信息接收方先读长度再按长度读完整消息体。我见过不少新手直接用read(byte[])读数据结果数据不完整然后疯狂怀疑是网络问题。实际上这就是没处理粘包拆包。5. HTTP协议Java后端天天打交道的应用层约定HTTP是Web开发最核心的应用层协议Java后端写接口、调接口都离不开它。但很多人对HTTP的理解停留在发个请求、收个响应的层面真出了问题不知道怎么排查。这里把关键点梳理一遍。5.1 请求报文和响应报文的结构一个HTTP请求报文由三部分组成请求行、请求头、请求体。响应报文由状态行、响应头、响应体组成。请求行长这样POST /api/users HTTP/1.1包含请求方法、URI、协议版本。请求头是键值对比如Content-Type: application/json、Authorization: Bearer xxx。请求体就是实际传输的数据POST请求通常在这里。响应状态行HTTP/1.1 200 OK其中200是状态码OK是原因短语。响应头包含Content-Type、Content-Length、Set-Cookie等信息。响应体就是返回的数据。这里最容易踩的坑是状态码语义理解错误。举几个典型例子200成功这个没问题。301永久重定向浏览器会自动跳转到新的地址并且会缓存跳转结果。302临时重定向浏览器也会自动跳转但不会缓存。403服务器拒绝了请求通常是权限不足。404资源不存在。500服务器内部错误通常是代码抛异常没处理。502网关或代理服务器收到上游服务器的无效响应典型场景是Nginx后面的Java服务挂了。503服务不可用通常是服务过载或正在维护。实际排查时看到4xx先查请求参数和权限看到5xx直接去查后端日志别在前端瞎找。5.2 HTTP和HTTPS的区别HTTPS就是在HTTP和TCP之间加了一层TLS/SSL加密层。它能解决三个问题防窃听加密传输内容、防篡改有完整性校验、防冒充有证书认证。Java后端对接HTTPS接口时最常见的坑是证书问题。比如你在本地调试访问一个自签名证书的HTTPS接口直接调用会报PKIX path building failed或者SSLHandshakeException。解决方式有几种把自签名证书导入JDK的cacerts证书库。让HttpClient信任所有证书仅限本地开发环境生产千万别这么干。用-Djavax.net.ssl.trustStore...指定信任库。5.3 HTTP的发展HTTP/1.1是现在最常用的版本它的核心特性是持久连接Keep-Alive同一个TCP连接上可以发送多个请求。但它有个问题——队头阻塞同一个连接上的请求必须按顺序处理前一个请求没响应完后面的就得等着。HTTP/2引入了多路复用一个TCP连接上可以同时并行多个请求和响应队头阻塞问题得到了很大改善。它还有头部压缩、服务器推送等特性。HTTP/3则更进一步把传输层从TCP换成了基于UDP的QUIC协议解决了TCP层面的队头阻塞和连接建立慢的问题。但对Java后端来说目前主要还是对接HTTP/1.1和HTTP/2HTTP/3在实际生产中还比较少。5.4 用抓包工具看清HTTP请求排查接口问题最好的方式就是抓包看真实报文。Wireshark是通用的抓包工具但很多Java开发者更习惯用Charles或者Fiddler这类HTTP抓包工具。这里分享一个真实排查案例有一个同事反馈说接口偶发性报错时好时坏。用Charles抓包后发现请求头里的Content-Type偶尔会丢导致服务端解析不到参数。最后定位到是同事在代码里用HashMap存请求头而HashMap不保证顺序某些情况下头字段被覆盖了。这种问题不看真实报文永远找不到原因。提示如果你是远程服务器上排查问题不方便装图形化抓包工具可以用tcpdump -i eth0 port 8080 -w /tmp/capture.pcap抓包然后把抓包文件下载到本地用Wireshark分析。6. 常用网络排查命令一套体检流程解决八成联调问题学网络基础理论再熟不会排障等于白学。很多时候前后端联调报错问题既不在前端代码也不在后端代码就是网络层面的问题。掌握下面这套体检流程能解决大部分联调问题。6.1 一套标准的排查流程遇到网络通信问题我习惯按顺序执行以下命令第一步确认对方主机通不通ping 目标IP。通说明网络链路和IP配置没问题不通看是Request timed out还是Destination Host Unreachable。前者可能是对方防火墙拦截了ICMP后者通常是路由不通。第二步确认目标端口是否开放telnet 目标IP 端口。连接成功说明端口开放连接失败说明端口没开放或者被防火墙拦截。Windows 10以上版本默认没开telnet客户端可以用Test-NetConnection -ComputerName IP -Port 端口测试。第三步查看路由路径traceroute 目标IPWindows下是tracert。可以看到数据包经过了哪些路由节点哪一跳超时帮助定位是哪个环节的问题。第四步查看本机网络配置ipconfigWindows或ifconfig/ip addrLinux。确认IP、子网掩码、网关是否正确。第五步查看本机路由表route printWindows或ip routeLinux。确认数据包该走的网关对不对。6.2 监听和连接状态的查看netstat是在服务器上用得最多的命令之一。netstat -ant查看所有TCP连接的详细状态状态包括LISTEN监听中、ESTABLISHED已建立连接、TIME_WAIT、CLOSE_WAIT等。netstat -anp | grep 8080Linux需要加p参数显示进程查看8080端口被谁占用。ss -ant比netstat更快更现代的工具推荐优先用。实际项目里CLOSE_WAIT状态过多是一个经典问题。CLOSE_WAIT表示对方发了FIN包要求关闭连接但本机还没调用close()关闭Socket。如果CLOSE_WAIT过多通常是代码里没有正确关闭连接。排查方式和修复方案用lsof -i :端口找PID再用jstack PID看线程状态定位到是哪个连接没关。6.3 排查防火墙Linux上排查网络不通别忘了查防火墙。很多云服务器的坑都是安全组没放行端口或本地防火墙拦截了端口。检查当前生效的防火墙规则iptables -L -n -v。临时放行某个端口iptables -I INPUT -p tcp --dport 8080 -j ACCEPT。如果是firewalld用firewall-cmd --list-all查看firewall-cmd --add-port8080/tcp --permanent放行端口后记得firewall-cmd --reload。云服务器还有个容易忽略的地方——安全组。阿里云、腾讯云、AWS这些云厂商的安全组相当于云环境里的防火墙即使你本机防火墙全关了安全组没放行端口一样不通。遇到明明把防火墙关了还是连不上的现象第一反应就去查安全组。7. 一个Java网络通信实例从Socket到HTTP的完整手写过程前面讲的都是理论这里写一段真实可运行的Java代码把网络通信的一整个流程跑通。这个例子用的是JDK原生的ServerSocket和Socket不引入任何框架目的是让你看清底层机制。7.1 写一个TCP服务端服务端代码的核心逻辑创建ServerSocket绑定端口循环接收客户端连接为每个连接创建独立线程处理请求。import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; import java.io.OutputStream; import java.net.ServerSocket; import java.net.Socket; import java.nio.charset.StandardCharsets; public class TcpServer { public static void main(String[] args) throws IOException { // 监听本机的9999端口 ServerSocket serverSocket new ServerSocket(9999); System.out.println(服务器已启动监听端口9999); while (true) { // accept()会阻塞直到有客户端连接进来 Socket socket serverSocket.accept(); System.out.println(收到客户端连接 socket.getRemoteSocketAddress()); // 每个连接单独开一个线程处理 new Thread(() - handleClient(socket)).start(); } } private static void handleClient(Socket socket) { try (BufferedReader in new BufferedReader(new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); OutputStream out socket.getOutputStream()) { // 读取客户端发送的一行数据 String line in.readLine(); System.out.println(收到消息 line); // 回传响应 String response Server received: line \n; out.write(response.getBytes(StandardCharsets.UTF_8)); out.flush(); } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { e.printStackTrace(); } } } }注意细节用additionalStream包裹的流在try-with-resources里会自动关闭Socket最好也手动关。accept()是阻塞方法收到连接才返回所以主线程通过while(true)循环持续接客。生产环境不会这样每连接一个线程而是用线程池或者Netty。因为每连接一个线程在大量连接下会耗尽系统资源。7.2 写一个TCP客户端客户端代码核心逻辑创建Socket连接服务端通过输出流发数据通过输入流接收响应。import java.io.*; import java.net.Socket; public class TcpClient { public static void main(String[] args) throws IOException { // 连接本机9999端口 Socket socket new Socket(127.0.0.1, 9999); System.out.println(已连接到服务器); BufferedWriter writer new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), StandardCharsets.UTF_8)); BufferedReader reader new BufferedReader(new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)); // 发送数据 writer.write(Hello, TCP Server!\n); writer.flush(); // 读取服务端响应 String response reader.readLine(); System.out.println(服务端响应 response); socket.close(); } }跑这段代码的流程是先启动TcpServer再启动TcpClient服务端控制台会打印收到消息客户端控制台会打印服务端响应。你会发现服务端那边accept()阻塞等待客户端一连接就返回双方通过Socket这个抽象来交换数据。7.3 用curl模拟HTTP请求上面的TCP例子是自定义的文本协议。实际的HTTP请求报文其实也是文本只是格式固定。你完全可以用Socket发送一段HTTP报文curl -v http://127.0.0.1:9999/用-v参数可以看到完整的请求和响应报文。如果你访问的是这个Java服务服务端收到的是一
