★ FEATURED ARTICLE 1. 为什么还要聊Socket传文件这件事文件传输这件事看起来已经被各种现成方案解决得很好了。对象存储、HTTP上传接口、消息队列附带文件通道随便挑一个都能跑通业务。但如果你真的在局域网环境里做过设备间通信、做过内网工具、做过需要自己掌控传输链路的项目就会发现一个尴尬的现实很多场景下你根本没有现成的文件服务可用或者引入了反而更重。这时候Java里最原始的那套东西——基于TCP的Socket嵌套字连接——反而是最直接、最可控的方案。我自己第一次认真写Socket传文件是给一个内网数据采集工具做配套。采集端和汇总端分别跑在两台机器上中间没有任何中间件要求就是稳定地把每天生成的日志包从A挪到B。当时试过用HTTP但服务端要额外起一个容器配置上传大小限制、超时时间折腾一圈下来代码量比Socket还多。后来换成裸TCP加自定义协议头核心逻辑不到两百行跑了大半年没出过问题。这篇文章就是把这套东西从头到尾讲清楚。TCP Socket文件传输的核心是什么、协议怎么设计、粘包怎么处理、大文件怎么分块、传输进度怎么反馈、断连怎么排查全部落到可运行的代码上。适合已经有Java基础、了解IO流、但没自己手写过完整文件传输协议的开发者。看完你至少能拿到一套可以直接改改就用的模板而不是停留在“知道有这么回事”的层面。需要提前说明的是Socket传文件本身不复杂复杂的是边界情况。网络抖动、对端提前关闭、磁盘写满、文件名带特殊字符、传输到一半进程被杀这些才是真正吃掉你调试时间的地方。所以下面的内容会花大量篇幅在这些“不优雅”的细节上而不是只给你一个能跑通demo的happy path。2. 整体设计思路与方案选型2.1 为什么选TCP而不是UDP文件传输的第一决策就是传输层协议。UDP无连接、开销小、速度快听起来很诱人但它不保证顺序、不保证到达、不重传。文件传输的本质要求是每一个字节都必须准确无误地按序到达缺一个字节整个文件就废了。用UDP你得自己在应用层实现确认、重传、排序、去重等于把TCP的活重干一遍还大概率干得不如内核好。TCP是面向连接的可靠字节流协议内核帮你处理了重传、拥塞控制、流量控制。你只需要关心“怎么把文件切成一串字节发出去对端怎么还原”。对于绝大多数文件传输场景TCP是默认正确选择。只有在极端追求低延迟、能容忍丢包的实时音视频场景UDP才有优势那跟文件传输是两码事。2.2 自定义协议头的必要性裸TCP是字节流没有消息边界。你连续发两次write对端可能一次read就读到了两段拼在一起的数据也可能一次只读到半段。这就是经典的粘包/拆包问题。如果不解决接收端根本不知道一个文件从哪开始、到哪结束。解决办法就是设计一个应用层协议头固定长度放在文件内容前面。接收端先读固定长度的头从头里解析出文件名长度、文件大小等元信息再按这些信息精确读取后续内容。这样无论TCP怎么粘怎么拆接收端都能正确还原。协议头我一般设计成这样的结构字段长度字节说明魔数4固定值用于校验连接是否合法文件名长度4UTF-8编码后的字节数文件大小8long类型文件总字节数文件名变长实际文件名字节文件内容变长实际文件字节魔数的作用是快速识别非法连接或协议错位。文件名长度和文件大小用固定4字节、8字节是为了读取时能精确定位。整个头的前16字节是定长的接收端先读16字节解析出文件名长度和文件大小再读文件名最后按文件大小循环读内容。2.3 分块传输与缓冲区设计一次性把整个文件读进内存再发小文件没问题大文件直接OOM。正确做法是分块读写用一个固定大小的缓冲区循环搬运。缓冲区大小是个需要权衡的参数太小比如1KB系统调用次数多CPU上下文切换开销大传输慢。太大比如1MB内存占用高且单次write可能被内核拆成多个TCP段意义不大。常用值8KB到64KB。我一般用32KB兼顾吞吐和内存。这里有个容易忽略的点InputStream.read(byte[])不保证一次读满整个数组它返回的是实际读到的字节数。所以循环里必须用返回值来控制写入长度不能想当然地认为每次都是缓冲区大小。2.4 长连接还是短连接一次连接传一个文件传完就关叫短连接。一次连接传多个文件叫长连接。短连接实现简单但每次都要三次握手传大量小文件时开销明显。长连接需要在协议里增加“文件结束”和“会话结束”的标识复杂度上升。我的建议是如果业务是批量传小文件用长连接如果只是偶尔传大文件短连接足够。本文的示例先用短连接把核心逻辑讲透后面再讲长连接的改造思路。3. 核心细节解析与实操要点3.1 服务端与客户端的职责划分Socket编程里服务端和客户端的角色要分清楚服务端ServerSocket绑定端口调用accept()阻塞等待连接。每来一个连接通常开一个线程处理避免阻塞主线程导致无法接收新连接。客户端Socket主动连接服务端地址和端口连接成功后拿到输入输出流。传文件的方向可以双向但为了讲清楚本文约定客户端发送文件服务端接收文件。这个方向符合大多数“上报数据”的业务场景。3.2 流的包装顺序很关键Socket的getInputStream()和getOutputStream()返回的是原始字节流。直接操作字节流读写没问题但读文件名这种文本时用DataInputStream和DataOutputStream会更方便因为它们提供了readInt()、readLong()、writeUTF()等方法能自动处理基本类型的字节转换。但这里有个坑DataOutputStream.writeUTF()写字符串时长度限制是65535字节且编码是改良版UTF-8。文件名一般不会超但如果要传更长的元信息就得自己控制。我倾向于自己写长度字节的方式可控性更强。包装顺序建议// 发送端 DataOutputStream dos new DataOutputStream( new BufferedOutputStream(socket.getOutputStream()) ); // 接收端 DataInputStream dis new DataInputStream( new BufferedInputStream(socket.getInputStream()) );Buffered系列包装是为了减少系统调用次数提升吞吐。注意BufferedOutputStream写完必须flush()否则数据可能还在缓冲区里没发出去。3.3 文件名的编码处理文件名可能包含中文、空格、特殊符号。直接用平台默认编码转字节在跨平台时会乱码。统一用UTF-8发送端filename.getBytes(StandardCharsets.UTF_8)接收端new String(bytes, StandardCharsets.UTF_8)。这是硬性规范不要偷懒用默认编码。另外接收端拿到文件名后必须做安全校验。如果文件名里包含../或绝对路径恶意发送方可能覆盖系统文件。正确做法是只取文件名部分丢弃路径String safeName new File(filename).getName();File.getName()会剥离所有路径信息只保留最后一段。这一步不能省。3.4 传输进度的计算与反馈大文件传输时用户需要知道进度。进度计算很简单已传输字节数 / 文件总大小。发送端每写一块累加已发送字节接收端每读一块累加已接收字节。但要注意发送端的“已写入Socket”不等于“对端已收到”因为数据还在内核缓冲区和网络里。所以进度条在发送端只能表示“已提交”接收端的进度才是真实的“已落盘”。如果要做精确反馈需要接收端定期回传确认那就涉及双向通信复杂度上升。一般场景下发送端进度够用了。3.5 超时设置不能忘Socket默认超时是无限等待。如果对端挂了但没发FIN包你的read()会永远阻塞线程泄漏。必须设置超时socket.setSoTimeout(30000); // 30秒读超时超时后read()抛SocketTimeoutException你可以捕获后决定重试还是放弃。注意setSoTimeout只影响读操作不影响写。写超时在Java里没有直接API需要靠TCP的发送缓冲区满来间接体现或者用NIO的Selector。提示setSoTimeout设置的是两次读操作之间的最大间隔不是整个传输的总时长。传大文件时只要数据持续到达就不会超时。4. 完整实操过程与核心代码实现4.1 协议常量定义先把协议相关的常量集中定义避免魔法数字散落各处public class FileTransferProtocol { public static final int MAGIC 0xCAFEBABE; public static final int HEADER_BASE_LENGTH 16; // 魔数4 文件名长度4 文件大小8 public static final int BUFFER_SIZE 32 * 1024; public static final int SO_TIMEOUT 30_000; }魔数用0xCAFEBABE是个习惯你也可以换成任意固定值。关键是收发两端一致。4.2 发送端完整实现发送端的流程连接服务端 - 打开文件 - 写协议头 - 循环写文件内容 - 关闭。public class FileSender { public static void sendFile(String host, int port, String filePath) throws IOException { File file new File(filePath); if (!file.exists() || !file.isFile()) { throw new IllegalArgumentException(文件不存在或不是普通文件: filePath); } String fileName file.getName(); byte[] nameBytes fileName.getBytes(StandardCharsets.UTF_8); long fileSize file.length(); try (Socket socket new Socket()) { socket.connect(new InetSocketAddress(host, port), 10_000); socket.setSoTimeout(FileTransferProtocol.SO_TIMEOUT); try (DataOutputStream dos new DataOutputStream( new BufferedOutputStream(socket.getOutputStream())); FileInputStream fis new FileInputStream(file)) { // 写协议头 dos.writeInt(FileTransferProtocol.MAGIC); dos.writeInt(nameBytes.length); dos.writeLong(fileSize); dos.write(nameBytes); // 循环写文件内容 byte[] buffer new byte[FileTransferProtocol.BUFFER_SIZE]; long sent 0; int len; while ((len fis.read(buffer)) ! -1) { dos.write(buffer, 0, len); sent len; printProgress(sent, fileSize); } dos.flush(); System.out.println(\n发送完成共 sent 字节); } } } private static void printProgress(long sent, long total) { int percent (int) (sent * 100 / total); System.out.print(\r发送进度: percent % ( sent / total )); } }几个关键点socket.connect带超时避免连不上时无限等待BufferedOutputStream包装减少系统调用循环里用len控制写入长度不能写buffer.length最后flush()确保缓冲区清空。4.3 接收端完整实现接收端流程accept连接 - 读协议头 - 校验魔数 - 读文件名 - 按文件大小循环读内容 - 落盘。public class FileReceiver { public static void start(int port, String saveDir) throws IOException { File dir new File(saveDir); if (!dir.exists()) { dir.mkdirs(); } try (ServerSocket serverSocket new ServerSocket(port)) { System.out.println(服务端启动监听端口: port); while (true) { Socket socket serverSocket.accept(); // 每个连接开一个线程处理 new Thread(() - handleConnection(socket, dir)).start(); } } } private static void handleConnection(Socket socket, File saveDir) { String remote socket.getRemoteSocketAddress().toString(); try (DataInputStream dis new DataInputStream( new BufferedInputStream(socket.getInputStream()))) { socket.setSoTimeout(FileTransferProtocol.SO_TIMEOUT); // 读协议头 int magic dis.readInt(); if (magic ! FileTransferProtocol.MAGIC) { System.err.println(非法连接魔数不匹配: Integer.toHexString(magic)); return; } int nameLen dis.readInt(); long fileSize dis.readLong(); // 读文件名 byte[] nameBytes new byte[nameLen]; dis.readFully(nameBytes); String fileName new String(nameBytes, StandardCharsets.UTF_8); // 安全校验只取文件名丢弃路径 String safeName new File(fileName).getName(); File target new File(saveDir, safeName); System.out.println(接收文件: safeName 大小: fileSize 字节来自: remote); // 循环读文件内容 try (FileOutputStream fos new FileOutputStream(target)) { byte[] buffer new byte[FileTransferProtocol.BUFFER_SIZE]; long received 0; while (received fileSize) { int toRead (int) Math.min(buffer.length, fileSize - received); int len dis.read(buffer, 0, toRead); if (len -1) { throw new IOException(连接提前关闭已接收 received 字节); } fos.write(buffer, 0, len); received len; printProgress(received, fileSize); } System.out.println(\n接收完成: safeName); } } catch (IOException e) { System.err.println(处理连接异常: e.getMessage()); } finally { try { socket.close(); } catch (IOException ignored) { } } } private static void printProgress(long received, long total) { int percent (int) (received * 100 / total); System.out.print(\r接收进度: percent % ( received / total )); } }接收端有两个细节值得强调。第一dis.readFully(nameBytes)保证读满整个文件名数组而read可能只读一部分。第二循环读内容时用received fileSize作为条件而不是依赖read返回-1因为TCP流在文件传完后连接可能还没关read会阻塞。按已知大小读读完就停干净利落。4.4 启动与测试先启动接收端public class ReceiverMain { public static void main(String[] args) throws IOException { FileReceiver.start(9999, ./received); } }再运行发送端public class SenderMain { public static void main(String[] args) throws IOException { FileSender.sendFile(127.0.0.1, 9999, ./test.zip); } }测试时建议用不同大小的文件几KB的小文件验证基本流程几百MB的大文件验证分块和进度。我实测下来局域网千兆环境下32KB缓冲区传1GB文件大约10秒左右瓶颈主要在磁盘IO。4.5 长连接改造思路如果要一次连接传多个文件协议需要增加“文件结束”和“会话结束”标识。简单做法是在每个文件传完后发送端再写一个特殊的魔数表示“本文件结束”接收端读到后准备接收下一个文件的头。会话结束时发送端写“会话结束”魔数接收端关闭连接。改造后的协议头可以加一个字段表示“是否还有后续文件”。这样接收端在一个循环里不断读头、读文件直到读到结束标识。核心逻辑不变只是外层多了一层循环。5. 常见问题与排查技巧实录5.1 粘包拆包导致的文件损坏现象接收端文件大小对不上或者解析文件名时乱码。原因没有按协议精确读取用了read的返回值当边界或者发送端两次write被合并。排查在接收端打印每次读到的字节数对比协议头里声明的长度。如果第一次读到的字节数大于16说明粘包了但你用DataInputStream按类型读就不会有问题因为它会精确读够字节数。解决坚持用DataInputStream的readInt、readLong、readFully不要自己用read(byte[])去解析定长字段。5.2 大文件传输时内存溢出现象传大文件时程序抛OutOfMemoryError。原因用了Files.readAllBytes()或者把整个文件读进ByteArrayOutputStream。解决永远用固定大小缓冲区循环读写。缓冲区不要超过64KB除非你有特殊需求。5.3 连接建立后立即被重置现象客户端connect成功但第一次write就抛Connection reset。原因服务端accept后没有及时处理或者服务端线程池满了拒绝连接或者防火墙拦截。排查检查服务端是否在accept后立即读取数据。如果服务端accept后先做耗时操作再读客户端可能已经超时。另外检查服务端ServerSocket的backlog参数默认50高并发下可能不够。5.4 传输到99%卡住现象进度条走到99%就不动了也不报错。原因发送端flush()没调用最后一块数据还在缓冲区或者接收端循环条件写错多读了一个字节导致阻塞。解决发送端确保flush()接收端循环条件用received fileSize不要用! -1。5.5 文件名乱码现象接收端文件名显示为问号或乱码。原因发送端和接收端编码不一致或者用了平台默认编码。解决两端强制StandardCharsets.UTF_8。如果历史数据已经乱码可以用new String(bytes, GBK)尝试还原但新代码必须统一UTF-8。5.6 常见问题速查表问题可能原因排查方向解决方案文件大小对不上粘包/拆包处理错误打印每次读取字节数用DataInputStream精确读取内存溢出一次性读整个文件检查是否有readAllBytes改用固定缓冲区循环连接重置服务端未及时读/backlog满检查accept后逻辑及时读取调大backlog传输卡住未flush/循环条件错检查flush和循环补flush修正循环条件文件名乱码编码不一致检查两端编码统一UTF-8读超时网络慢或对端挂检查网络和对端状态调大超时或重试5.7 几个我踩过的坑第一个坑是在循环里频繁flush()。早期为了“实时”每写一块就flush一次结果传输速度暴跌。flush会强制把缓冲区数据推出去频繁调用等于放弃了缓冲的意义。正确做法是循环结束后flush一次或者每传几MB flush一次。第二个坑是接收端没做磁盘空间检查。有一次传一个几十GB的文件接收端磁盘满了FileOutputStream.write抛异常但异常信息不直观排查了半天。后来在接收前用File.getUsableSpace()检查剩余空间不够就直接拒绝省得传一半失败。第三个坑是文件名包含特殊字符。有个文件名带:在Linux上没问题在Windows上直接创建失败。后来统一在接收端对文件名做过滤把非法字符替换成下划线。第四个坑是多线程接收时的文件名冲突。两个客户端同时传同名文件后写的覆盖先写的。解决办法是在文件名后加时间戳或UUID或者用文件锁。简单场景下加时间戳就够了。提示生产环境建议在协议头里加一个校验字段比如文件内容的MD5或CRC32。接收端传完后校验不一致就重传。TCP只保证传输可靠不保证内容没被中间环节篡改。6. 性能调优与进阶方向6.1 缓冲区大小的实测对比我在局域网环境用不同缓冲区大小传一个500MB的文件测了几组数据缓冲区大小耗时秒备注4KB18.2系统调用频繁16KB12.5明显改善32KB10.8推荐值64KB10.5提升有限256KB10.4内存浪费从16KB到32KB提升明显再往上收益递减。32KB是个甜点值。当然这跟硬件和网络有关你可以自己测一下。6.2 用NIO提升并发能力传统BIO每个连接一个线程连接数上千时线程开销大。NIO用Selector多路复用一个线程管理多个连接。但NIO的编程模型复杂ByteBuffer的flip、clear容易搞错。如果并发连接数不超过几百BIO完全够用。超过再考虑NIO或Netty。6.3 断点续传的实现思路断点续传的核心是记录已传输的偏移量。发送端在协议头里加一个offset字段接收端检查本地已存在的文件大小如果小于offset就从头传如果等于就跳过已传部分。实现时要注意文件在传输过程中可能被修改需要校验文件指纹。6.4 传输加密的考虑如果传输内容敏感可以在Socket之上加一层加密。简单做法是用CipherInputStream和CipherOutputStream包装AES对称加密。密钥交换可以用非对称加密。但加密会带来性能开销且密钥管理本身是个复杂问题。内网可信环境一般不需要公网传输必须加。7. 一些个人体会这套Socket传文件的代码我从最早的demo版本改到现在前后迭代了七八次。每次都是遇到具体问题才去补一块比如粘包是传大文件时发现的超时是半夜服务挂掉后加的文件名安全校验是看到一篇安全文章后补的。所以如果你现在写出来的版本还有漏洞很正常关键是知道问题可能出在哪以及怎么排查。我个人在实际操作中的体会是协议设计阶段多花一小时调试阶段能省一天。协议头里该有的字段一个别省魔数、长度、校验看起来冗余出问题时就是靠它们定位。另外日志要打够但别打太多。每次读写的关键节点打一行包含偏移量和长度出问题时能快速还原现场。最后分享一个小技巧测试时不要只用正常文件。故意传一个0字节的空文件、一个文件名超长的文件、一个正在被写入的文件看看你的代码怎么反应。这些边界情况才是真正考验代码健壮性的地方。
阅读完成 · 觉得有帮助？
