1. 初识HTTPJavaEE开发绕不开的“快递协议”1.1 先搞清楚HTTP到底在做什么不管你用Servlet、Spring MVC还是Spring BootJavaEE项目最终对外提供服务的方式几乎都是HTTP接口。换句话说别人写的前端页面、手机App、第三方系统都是通过HTTP协议把你的后端代码“叫醒”的。我在带新人时经常说一句话HTTP不是你写代码时要背的八股文而是你每天都在用的东西只不过你写业务代码时没意识到它的存在。举个例子。你在浏览器里输入一个网址按下回车到页面显示出来这中间发生的事就是一次HTTP请求和响应。你的浏览器作为客户端组装一个请求发出去服务器收到之后做一堆事情再把结果通过响应返回来。HTTP就是客户端和服务器之间约定好的“说话格式”——大家都按这个格式说彼此才听得懂。那HTTP和TCP是什么关系很多面试题爱问这个其实一句话就能说清TCP是传输层协议负责把数据可靠地从A传到BHTTP是应用层协议负责规定这段数据长什么样、有什么含义。HTTP跑在TCP之上就像快递员TCP负责把包裹送到而包裹上面的面单HTTP写着寄件人、收件人、物品名称。TCP不管包裹里装的是不是衣服HTTP则规定面单怎么填、包裹怎么打包。对于JavaEE初学者我的建议是先不要一头扎进Spring源码把HTTP的请求结构、响应结构、状态码、头信息这四样吃透后面所有框架层面的东西都迎刃而解。因为框架再花哨底层还是在帮你拼HTTP报文、解析HTTP报文。1.2 HTTP请求和响应到底长什么样一个HTTP请求表面上你看不到但它的结构可以用四个部分组成请求行、请求头、空行、请求体。请求行在最上面写的是请求方法、请求路径、HTTP版本。请求头是一堆键值对用冒号分隔每一行一个。空行是一个约定表示头部结束了。请求体是可选的GET一般没有POST通常会有。响应也是对称的状态行、响应头、空行、响应体。状态行里有HTTP版本、状态码、状态描述。我用抓包工具打开一个真实请求给你看。假设你访问了一个登录接口POST请求大概长这样POST /api/login HTTP/1.1 Host: example.com Content-Type: application/json User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: */* Content-Length: 46 {username:admin,password:123456}服务器返回的响应长这样HTTP/1.1 200 OK Content-Type: application/json;charsetUTF-8 Date: Mon, 15 May 2025 12:00:00 GMT Content-Length: 52 {code:0,message:登录成功,data:{token:abc123}}很多初学者容易忽略Content-Type这个头但它恰恰是关键。你发JSON和发表单Content-Type不一样服务器解析方式也不一样。Spring MVC里如果忘记写RequestBody或者前端没设置application/json就会出现参数接不到的问题。这些坑多半是对请求头理解不到位造成的。1.3 状态码一眼定位问题在哪端状态码是面试最爱问、实际排查最常用的一类知识。我习惯把它分为五类1xx是信息2xx是成功3xx是重定向4xx是客户端问题5xx是服务器问题。200成功最常见。301永久重定向旧的地址废弃了以后用新地址。302临时重定向比如未登录时跳转到登录页。304资源没变直接用浏览器缓存的就行。400请求格式有问题后端看不懂你发的报文。401未认证也就是没登录。403已登录但没权限访问了不该访问的资源。404路径不存在。405请求方法不对比如接口只允许POST你发了GET。500服务器内部异常代码炸了。502网关错误往往是上游服务挂了。503服务不可用比如线程池满了或者正在重启。明白这些状态码之后联调时你就不会瞎猜了。看到502先别怀疑自己代码可能是对方服务挂了看到401先检查Token有没有带上看到405先看请求方法。这些判断几秒钟就能完成比按F12看半天控制台有效得多。1.4 请求方法别只会GET和POSTGET和POST是最高频的两个方法但HTTP还定义了其他方法。GET是获取资源POST是提交数据让服务器处理。这两者的本质区别不在于“参数放在URL里还是放在Body里”而在于语义GET是幂等的不管调多少次服务器的状态不变POST是非幂等的每次调用都可能创建新资源。PUT通常表示整体更新DELETE表示删除PATCH表示局部更新HEAD只取响应头不看响应体OPTIONS用来探测服务器支持哪些方法。在JavaEE项目里Spring MVC用注解就能区分这些方法GetMapping、PostMapping、PutMapping、DeleteMapping。但很多老项目为了方便全部用POST再把操作类型写在URL里比如/api/order/delete。这种做法不算错但不规范。RESTful风格的价值在于方法和操作的语义对齐别人接手项目时看路径和动词就能猜出接口行为。顺便说一句GET参数放在URL里有长度限制实际开发中如果要传很长一段文本或者敏感数据别用GET。比如搜索接口传关键词关键词短没事但如果你把一个几百字的JSON放在URL里大概率会被服务器拒绝。2. 连接管理从短连接到连接复用的演进2.1 一次HTTP请求的完整旅程很多人知道HTTP是“请求-响应”模型但不知道这背后还涉及连接的建立和断开。一次最简单的HTTP请求实际上经历了TCP三次握手、发送请求、服务器处理、返回响应、TCP四次挥手这几个阶段。如果用老式的HTTP/1.0每请求一次资源就要建立一次TCP连接请求完就断开。你可以想象成你每点一个按钮就像去便利店买一瓶水但每次买完必须走出便利店再从门口重新进来才能买下一瓶。一个网页有几十个资源——图片、CSS、JavaScript、接口数据——那就意味着要进出便利店几十次。开销大不大大得很。这就是为什么HTTP/1.1引入了Keep-Alive机制。连接建立之后不立即断开而是复用这条TCP连接继续发下一个请求。就像进了一家便利店可以在里面连续买好几样东西再出门。这个机制在JavaEE里体现得特别明显。你在Spring Boot里配置的Tomcat默认就开启了Keep-Alive并且有连接超时时间。2.2 Keep-Alive与连接复用到底怎么用Keep-Alive的配置参数看过Tomcat配置的人应该不陌生keepAliveTimeout一个连接最多空闲多久就关闭单位是毫秒。maxKeepAliveRequests一个连接最多服务多少次请求后关闭。maxConnections最多同时维持多少个TCP连接。为什么要有这些参数因为连接不是越多越好。每一条TCP连接都要占用服务器资源——文件描述符、内存、端口。如果你不限制maxConnections在高并发场景下服务器可能因为连接数过多而崩溃。连接复用对性能的提升非常明显。假设一个页面要发100个请求使用HTTP/1.0短连接就要经历100次三次握手和100次四次挥手光握手挥手的时间就占了很大比重。使用Keep-Alive之后同一个连接上可以串行发请求省掉了大量握手开销。再到HTTP/2还引入了多路复用一条TCP连接可以同时并行跑多个请求效率更进一步。在JavaEE开发中你不仅要在服务器端配置连接客户端发HTTP请求时同样要注意连接复用。比如用Apache HttpClient或者OkHttp默认就有连接池。如果你每次请求都new一个HttpClient那连接池形同虚设每次都在重新建立连接。正确做法是复用同一个HttpClient实例让连接池发挥作用。这一点在高并发场景下差别非常大新手最容易在这里踩坑。2.3 连接池参数怎么算出来的连接池配置不是拍脑袋定的我以Apache HttpClient为例说说估算逻辑。HttpClient的连接管理器有几个关键参数最大连接数setMaxTotal、每个路由的最大连接数setDefaultMaxPerRoute、连接存活时间setTimeToLive。假设你的应用部署了4台机器每天峰值QPS是2000平均每个请求耗时200毫秒。那么每台机器每秒要处理的请求大概是500个。一条TCP连接同时只能处理一个请求HTTP/1.1所以理论上每台机器需要的连接数就是峰值并发数。粗略计算200ms处理一个请求1秒内一条连接最多处理5个请求500 QPS就需要100条连接。两个CPU核心以上的机器单条连接的吞吐还能再高一些但保险起见我会把maxPerRoute设成150左右maxTotal设成600。连接存活时间也很关键。TCP连接存在太久可能被中间设备中断。设得太短又频繁重新建连。实践下来一般设成30到60秒比较合适。比如PoolingHttpClientConnectionManager cm new PoolingHttpClientConnectionManager(60, TimeUnit.SECONDS); cm.setMaxTotal(600); cm.setDefaultMaxPerRoute(150); HttpClient httpClient HttpClients.custom() .setConnectionManager(cm) .evictExpiredConnections() .evictIdleConnections(30, TimeUnit.SECONDS) .build();这里的evictIdleConnections是在清理空闲过久的连接不然你建了500条连接实际只用50条剩下的在那占着资源。加上清理逻辑连接池才健康。3. 会话状态与缓存写业务代码前必须懂的HTTP细节3.1 Cookie和Session是怎么配合的HTTP协议本身是无状态的。服务器处理完你的请求不会记得你是谁。但业务上我们需要“记住登录状态”怎么办办法就是在客户端留一个标识每次请求带上它服务器看到标识就知道你是谁。这个标识在JavaEE里通常是Session ID。流程是这样的用户第一次访问服务器创建一个Session对象生成一个唯一的Session ID通过响应头的Set-Cookie告诉浏览器浏览器存下来。之后浏览器每次请求都自动带上Cookie: JSESSIONIDxxx服务器根据这个ID找到对应的Session数据。在Spring Boot中如果你直接用HttpSession这些逻辑框架都帮你处理好了。但要注意几个问题Session默认存在内存里服务重启就没了多实例部署时用户的请求如果被负载均衡分到另一台机器Session就找不到了。解决办法一个是用Spring Session把Session数据存到Redis里另一个是改用JWT之类的Token方案把用户信息放在客户端服务器不做状态存储。Token方案和CookieSession完全不一样。Token是服务器签发的一段加密字符串客户端每次请求放在请求头里服务器验证Token合法即可不需要在服务器端存Session。对分布式系统来说Token方案更友好。但Token也有缺点比如难以主动失效——用户修改密码后已经签发的Token理论上还能用一段时间。3.2 浏览器缓存被很多人忽略的HTTP头缓存是一个很有意思的话题。很多JavaEE开发者在接口设计时完全不考虑缓存相关的HTTP头结果前端浏览器反复请求同一个接口服务器白白扛了大量压力。HTTP缓存相关的主要有这几个头Cache-Control指定缓存策略比如max-age3600表示缓存1小时no-cache表示使用前必须验证no-store表示完全不缓存。Expires一个绝对过期时间点是HTTP/1.0时代的写法现在基本被Cache-Control替代。ETag资源的标识符服务器返回资源时带上下次请求时浏览器带着If-None-Match服务器判断资源没变就返回304省流量。Last-Modified资源最后修改时间配合If-Modified-Since使用。实际项目中静态资源适合长缓存接口数据适合按需设置。比如图片、CSS、JS可以设置Cache-Control: max-age31536000缓存一年。但要注意如果资源内容更新了而URL不变用户的浏览器还在用旧缓存。解决办法是给资源文件名加版本号或内容哈希比如app.8f3d2a.js内容变了文件名就变浏览器自然请求新资源。接口方面比如商品列表、公告这类不常变的数据可以设置一个较短的缓存时间。而那些带用户信息的接口比如“我的订单”一定不能缓存要设置Cache-Control: no-store不然别人登录同一台电脑可能看到上一个用户的数据。3.3 字符编码乱码问题的根源JavaEE开发里中文乱码是一个高频问题。乱码的本质很简单编码和解码用了不同的字符集。举个例子前端页面是UTF-8编码把“你好”按UTF-8编码成字节发出去后端如果用GBK去解码解出来的就是乱码。反过来也一样。HTTP报文在传输时用Content-Type头里的charset参数声明编码。请求发出的编码格式和服务器解析时用的编码格式必须一致。在Spring MVC中你可以在配置里统一设置server: servlet: encoding: charset: UTF-8 enabled: true force: trueforce: true的意思是强制所有请求和响应都用UTF-8不管请求头里写的是什么。这个配置能解决大部分乱码问题。但还有一个隐蔽的坑读取POST请求体时如果InputStream先被读取了一遍后面再想读就读不到了。Filter如果包装了Request里面的编码逻辑写得不对也会导致中文乱码。另外一个常见场景是URL传参。GET请求的参数放在URL里浏览器会对中文做百分号编码也就是URL encoding。服务器解析时自动解码。如果你在前端把参数encode了后端又encode了一次就会出现双重编码看到的就是一串乱七八糟的%E4%BD%A0%E5%A5%BD。排查这类问题时先看浏览器Network面板里的实际请求内容再确认前后端各自处理编码的次数基本就能定位。4. HTTPS给HTTP加上一层加密盔甲4.1 为什么说HTTP是明文传输的HTTP协议本身是明文协议所有数据在网络传输过程中都是裸奔的。你把用户名密码通过HTTP发出去沿途经过的每一个路由器、交换机、运营商设备理论上都能看到这些内容。用什么工具抓包能直观看到明文Wireshark就可以。在HTTP协议下Wireshark抓到包之后直接把请求体里的字符串原样显示出来登录密码一目了然。这就是为什么现在几乎所有正式环境都要求用HTTPS——它就是HTTP加上TLS/SSL加密层能让传输内容变成密文。但这里要说个容易被误解的点HTTPS只加密传输过程不保证服务器安全。如果服务器本身有漏洞或者代码写得烂数据到了服务器端该泄露还是泄露。HTTPS解决的是“传输过程中被人偷听、篡改”的问题。4.2 加密方案对称加密和非对称加密怎么配合要理解HTTPS先要理解两种加密方式。对称加密比如AES特点是一个密钥既用来加密也用来解密速度快但问题是怎么把密钥安全地传给对方。如果把密钥也通过网络传过去那被中间人截获了后面的加密就形同虚设。非对称加密比如RSA有两个密钥公钥和私钥。公钥可以公开给任何人私钥只有自己知道。用公钥加密的内容只能用私钥解密用私钥签名的内容可以用公钥验证。非对称加密解决了密钥分发问题但速度比较慢。HTTPS的聪明之处是把两者结合起来。首先用非对称加密安全地协商出一个临时的对称密钥后续的数据传输全部用这个对称密钥加密。这样既解决了密钥分发问题又保证了传输效率。4.3 TLS握手流程一步一步拆解TLS握手过程不同版本略有差异我以最常见的TLS 1.2为例来讲。第一步客户端发送ClientHello告诉服务器自己支持的TLS版本、支持的加密套件列表以及一个随机数。第二步服务器回复ServerHello选定加密套件和TLS版本附带服务器的证书证书里有公钥和域名等信息以及另一个随机数。第三步客户端验证服务器证书。验证逻辑有三条证书是否由受信任的CA签发证书域名是否和访问的域名一致证书是否过期。如果验证失败浏览器会给出安全警告让用户选择是否继续访问。这也是为什么有时候你访问一个HTTPS网站会看到“您的连接不是私密连接”的提示。第四步验证通过后客户端再生成一个随机数用服务器公钥加密后发给服务器。到这里客户端和服务器各自拥有了三个随机数通过约定的算法生成相同的对称密钥。后续传输就用这个对称密钥加密。第五步双方互相发送Finished消息确认密钥协商完成然后开始正常的加密通信。这个过程里证书验证是最关键的一环。如果证书是自签名的客户端无法验证其合法性。所以企业内部调试环境用自签名证书时客户端需要手动信任这个证书。而公开环境的证书都是向CA机构申请的。4.4 HTTPS的性能代价与优化很多人担心HTTPS影响性能确实有影响但没有想象中那么大。影响主要来自两部分握手多出来的几次网络往返以及加解密消耗的CPU资源。握手的额外开销在每次建立新连接时都会发生这就是为什么HTTP连接复用对HTTPS更重要。TLS握手一次大约产生2个RTT的额外延迟在局域网里感觉不到但在跨运营商、跨国网络里可能多出几十毫秒。针对这个开销行业里有几个优化手段一种是TLS会话恢复技术客户端和服务器在短时间内复用之前的协商结果免去完整握手另一种是TLS 1.3把握手压缩到1个RTT。加解密方面现代CPU大多支持AES-NI指令集AES对称加密几乎不消耗什么CPU。所以实际生产环境中HTTPS带来的性能损耗通常可以控制在5%以内完全值得为安全买单。还有一个实践细节如果你的JavaEE应用使用了HTTP请求转发比如Nginx到Tomcat之间的通信理论上也可以走HTTPS。但内网通信为了简化证书管理很多团队选择在Nginx层终止HTTPS然后用HTTP转发到后端。这样做能通过对外端口的安全检查同时降低后端证书管理的复杂度。5. JavaEE项目里的HTTP实操从原生到框架5.1 Java原生发起HTTP请求的方法在Java里发一个最简单的HTTP请求最基础的方式是HttpURLConnection。虽然它的API有点啰嗦写起来不如OkHttp舒服但了解一下它的原理是值得的因为很多框架底层就是在它之上封装。一个典型的POST请求长这样URL url new URL(https://api.example.com/login); HttpURLConnection conn (HttpURLConnection) url.openConnection(); conn.setRequestMethod(POST); conn.setRequestProperty(Content-Type, application/json;charsetUTF-8); conn.setDoOutput(true); String json {\username\:\admin\,\password\:\123456\}; try (OutputStream os conn.getOutputStream()) { os.write(json.getBytes(StandardCharsets.UTF_8)); } int code conn.getResponseCode(); if (code 200) { try (InputStream is conn.getInputStream(); BufferedReader reader new BufferedReader(new InputStreamReader(is, StandardCharsets.UTF_8))) { StringBuilder sb new StringBuilder(); String line; while ((line reader.readLine()) ! null) { sb.append(line); } System.out.println(sb.toString()); } } conn.disconnect();从这个代码可以看出HTTP请求的每一步设置请求方法、设置请求头、写请求体、读响应。HttpURLConnection默认也支持Keep-Alive底层会缓存TCP连接。但HttpURLConnection有个坑如果响应码是4xx或5xx调用getInputStream()会抛异常你需要改用getErrorStream()去读错误信息。很多初学者在这里卡住以为服务器挂了其实服务器已经把错误信息返回了只是你在读的地方不对。5.2 框架级HTTP客户端怎么选在JavaEE项目里常用的HTTP客户端有Apache HttpClient、OkHttp以及Spring框架自带的RestTemplate和WebClient。Apache HttpClient历史最悠久文档齐全适合需要精细控制连接池和重试策略的服务端到服务端调用。OkHttp是Square出品API友好支持HTTP/2Android和Java都能用性能很不错。Spring的RestTemplate是老牌选手用起来简单。但要注意RestTemplate在Spring 5之后官方推荐用WebClient替代。WebClient支持响应式编程也支持传统的同步调用灵活性更高。选型上我的建议是如果是新项目用WebClient或者OkHttp如果是维护老项目RestTemplate也不是不能用。关键不是哪个库更高级而是你是否理解了连接复用和超时配置。一个很常见的失误是超时时间设置不当。RestTemplate默认的底层连接没有超时时间如果对端服务卡住你的线程会一直挂在那里。通过SimpleClientHttpRequestFactory可以设置SimpleClientHttpRequestFactory factory new SimpleClientHttpRequestFactory(); factory.setConnectTimeout(3000); factory.setReadTimeout(5000); RestTemplate restTemplate new RestTemplate(factory);连接超时设成3秒读取超时设成5秒这套参数在小规模项目里很实用。超时时间不是越长越好也不是越短越好。设得太短接口正常处理需要8秒你5秒就报超时前端看到的就是失败设得太长对端挂了你的线程池也会被拖垮。需要你根据业务接口的实际耗时来权衡。5.3 JMeter录制HTTPS脚本的口诀测试阶段用JMeter压测接口是JavaEE开发者的基本功。录制HTTPS脚本有一个麻烦HTTPS是加密的JMeter要能看到请求内容就必须先信任服务器的证书。操作流程是这样的把服务器的HTTPS证书导出成cer文件导入到JMeter的JVM信任库中。常见的做法是用Java的keytool命令keytool -import -alias example.com -keystore $JAVA_HOME/lib/security/cacerts -file example.cer导完之后重启JMeter录制的时候才不会被证书拦截。还有一个更省事的方法不想动系统信任库就使用JMeter自带的HTTP(S)测试脚本记录器并开启HTTPS代理支持。浏览器把代理指向JMeter的端口同时信任JMeter生成的证书。这个方法不用动系统配置测试机上就能完成所有操作。录制出来的脚本通常需要手动清理。JMeter录下来的请求里往往带着很多无关的请求头比如Cache-Control、Referer、Accept-Language这些在压测时可以删掉只保留必要的请求头和请求体。载荷过多的请求头会影响压测的准确性。5.4 JavaEE项目里的HTTP细节注意点在实际项目开发中有几点我会反复跟团队成员强调。第一对外接口要统一设置字符编码。所有接口请求和响应的Content-Type统一使用application/json;charsetUTF-8避免因为编码问题导致线上出乱码。第二服务间调用要设置合理的超时和重试策略。重试要谨慎POST请求重试可能导致重复下单。如果接口本身是幂等的重试是安全的如果不是幂等的重试前要确认业务上能不能接受。比如支付接口宁可失败让用户手动操作也不能自动重试造成重复扣款。第三日志里不要打印完整请求体和响应体。请求体里可能有密码、Token、身份证号响应体里可能有关键业务数据。线上排查问题需要日志但要脱敏后再打。像密码打码、Token截断这种小事能避免很多安全事件。第四HTTP接口的参数校验一定要做。Spring的Validated注解配合NotNull、Size这些校验注解可以少写很多if-else。但校验逻辑不止是检查参数非空还要检查格式、长度、取值范围。后端接口是给前端用的但也是给恶意攻击者用的参数校验是第一道防线。6. 高频问题排查实录6.1 中文乱码先从哪一端查起乱码问题有一点像玄学但其实按顺序排查是能定位的。第一步打开浏览器开发者工具看Network面板里实际发出的请求检查Content-Type看里面charset是不是UTF-8。第二步确认后端解析时的编码。Spring Boot的话看一下server.servlet.encoding配置是否开启了force。第三步排查是不是重复编码。比如前端已经用encodeURIComponent加密了参数后端获取请求参数时又做了一次URL解码就会导致乱码。这种问题最麻烦的地方是直接请求后端接口没问题但通过前端页面上传就有问题。第四步检查数据库连接串。如果数据到数据库里变成乱码可能不是HTTP的问题而是JDBC连接串少了characterEncodingutf8。在MySQL的JDBC URL里一定要加上useUnicodetruecharacterEncodingutf8否则即使HTTP层编码是对的存到数据库还是乱。6.2 连接超时和连接池耗尽经典现场还原线上经常出现的一种情况是接口突然响应变慢然后大量502或超时报错。查日志发现一堆ConnectionPoolTimeoutException这种问题十有八九是连接池被占满了。连接池被占满的常见原因有两个一是连接池配置太小二是请求处理太慢线程都堵在等待响应上。我之前遇到过的一个真实案例是A服务调用B服务的接口B服务因为数据库慢查询导致接口耗时从200ms涨到10秒同时A服务的连接池设置只有50于是大量请求在连接池里排队超过1秒就报超时。但真正的问题不在连接池而在B服务的数据库。所以排查的时候要一路追下去找到根源而不是只看表象。解决办法分两步第一步确认下游服务是否健康数据库有没有慢SQL垃圾回收有没有问题这是根本第二步合理调大连接池并设置超时让等待的请求快速失败而不是无限挂起。顺便提醒一下连接池用完了一定要归还。在Java中连接池框架一般会自动管理只要你不在finally里把连接Close就行了。有些人用try-with-resources关闭之后连接不是真的断开而是归还给连接池这是正确的用法。6.3 HTTPS证书报错常见的三种场景场景一浏览器访问HTTPS网站提示“证书无效”。可能原因是证书过期、域名不匹配、证书链不完整。排查时先用浏览器查看证书详情看有效期和颁发者。场景二Java代码调用HTTPS接口报javax.net.ssl.SSLHandshakeException。这说明JVM不信任这个证书。解决方法取决于环境生产环境应该使用正规CA签发的证书测试环境可以手动导入信任库或者临时创建一个信任所有证书的SSLContext。场景三HTTP和HTTPS混用。页面是HTTPS的但里面引用了HTTP的资源浏览器会拦截报Mixed Content。解决方法是把所有资源都改成HTTPS协议或者用相对路径让浏览器自动继承当前协议。我在本地开发时经常用自签名证书每次被这个报错折腾。后来干脆写了一个小工具类里面创建一个跳过证书校验的HttpClient只在本地开发环境用线上代码绝对不碰它。这个做法要谨慎因为线上如果跳过证书校验等于HTTPS白做了中间人可以随意伪造服务器。6.4 前后端联调抓包F12和Wireshark怎么配合前端和后端联调意见不统一是常事。前端说“我发的是正确的”后端说“我收到的是错的”。这时候别争直接抓包看事实。最方便的工具是浏览器F12的Network面板。它能看到的请求头、请求体、响应体足够解决大多数问题。注意在面板上勾选“Preserve log”否则页面跳转后之前的请求记录就没了。如果问题出在非浏览器环境比如App端调用接口或者某个定时任务调接口需要用Charles或者Fiddler抓包。这类代理工具能捕获所有HTTP/HTTPS流量还能对请求和响应做断点、修改。HTTPS流量需要先安装代理工具签发的证书抓包前设置一下。更底层的情况比如怀疑是TCP层的问题才需要用到Wireshark。Wireshark抓的是整个网络数据包能看到TCP握手是否完成、重传情况、连接是否被RST重置等等。普通业务联调用不到这个级别但排查网络层面的疑难问题时会派上大用场。还有一种情况要注意HTTPS明文捕获。有些时候你抓包抓到的HTTPS内容显示不出来但代理工具装了证书之后就可以看到明文。这个功能只建议在自己可控的环境里使用不要用在生产环境或者别人的系统上。抓包的目的是排查问题不是窥探数据。我个人在实际操作中的体会是HTTP和HTTPS的很多知识光看书是记不住的。最有效的方式是写一个简单的JavaWeb项目用它自己给自己发HTTP请求同时开着抓包工具看报文明文长什么样然后再申请一个免费的HTTPS证书让项目跑在HTTPS下对比看看请求内容是不是已经加密不可读了。这样实操一轮比你背十遍协议文档都管用。最后再分享一个小技巧排查HTTP问题时可以把请求和响应原文直接复制出来贴到文本对比工具里看一眼差异。很多时候前端和后端争论半天的问题对比一下报文内容一眼就能看出是字段名拼错了、大小写不一致还是编码不对。协议这东西就是要落实到报文字节上才有说服力。