企业官网建设流程全解析

最近在帮朋友整理内部服务器之间的日志同步方案时，遇到一个非常典型的场景：两台机器在同一内网里，需要把几个GB的数据包从一台传到另一台，FTP服务没搭、专门的HTTP上传服务也没人维护，临时装个网盘工具又不现实。最后又绕回老路子——直接用TCP通信自己写一个文件上传工具。这篇文章就把这个综合案例完整拆开讲清楚，从应用层协议设计、服务端实现、客户端实现，到实测过程中踩过的坑和进阶思路，覆盖到Socket编程里最容易被忽略、但实际开发又一定会遇到的细节。无论你是刚开始学网络编程的学生，还是工作中突然要处理内网文件传输的开发者，照着这套逻辑都能快速落地一套可靠的方案。

1. 动手前先想清楚：这个案例到底在解决什么问题

1.1 既要"传得对"，又要"传得完"

文件上传这件事听上去很简单，但放到TCP通信的场景里，难点立刻浮出水面。TCP本身只保证字节流是可靠有序的，它并不理解"文件"这种业务概念。你往Socket里写一段字节，对端读到的可能是半段数据，也可能是两段数据黏在一起。所以这个综合案例真正要解决的，是在TCP提供的原始字节流之上，设计一套能让双方都理解的消息协议，把文件的名字、大小、内容、校验信息完整地送达对端。

另一个容易忽略的痛点是"传得完"。小文件一次性读进内存再write很快就完事，但到了几个GB的日志文件，内存根本扛不住，必须用缓冲流分块读取、分块发送。再加上网络抖动、客户端断线、服务端磁盘写入失败这些情况，一个看起来简单的上传工具，实际上要把连接管理、流处理、异常恢复、资源释放全部串起来。

1.2 为什么这个场景必须选TCP而不是UDP

文件上传在传输层几乎没有选择的余地，必须用TCP。UDP虽然发送快、没有连接维护成本，但它不保证数据包的到达顺序，也不保证不丢包。如果基于UDP做文件传输，要么自己实现一套复杂的确认重传机制，要么接受文件内容可能损坏的后果。相比之下，TCP把拥塞控制、超时重传、顺序校验这些机制全部内置了，你要做的只是在流上面划分消息边界，已经省去了最麻烦的部分。

不过这也引出一个很多新手会犯的错误：觉得TCP可靠，就可以把文件名、文件大小、文件内容一次性write出去，然后以为对端一定能原样收到。这个理解是错的——TCP的可靠是字节层面的可靠，不是"消息"层面的可靠。发送方一次write（比如write 1MB数据），接收方可能分好几次read才能读完；发送方连续write两次，接收方可能一次read就把两段数据一起读出来了。这就是后面要重点处理的粘包、拆包问题，也是整个协议设计的最核心动机。

1.3 边界判断：什么时候该自研，什么时候该用现成方案

在做这个工具之前，我也认真想过是不是直接用成熟方案更省事。如果只是偶尔在内网传几个文件，SFTP、NFS、HTTP文件服务，甚至直接挂个网盘都比自己写Socket要快。但如果你面对的是批量机器之间的程序化传输、需要在传输过程中嵌入特殊的业务校验（比如上传后触发后续任务）、或者处于一个不允许额外安装服务的受限环境，自己实现一个轻量TCP上传通道反而是更理智的选择。

自研方案的边界也很明确：单机吞吐、并发连接数、断点续传这些能力都取决于你自己的设计和代码质量，出了问题没有现成文档能查，全靠对TCP机制的理解。所以这个案例的定位不是"替代FTP"，而是一种在可控场景下灵活定制的技术方案。理解清楚这一点，你才知道哪些协议字段要考虑、哪些异常分支要处理，程序才不会写到一半失控。

2. 应用层协议设计：先把"字节流"翻译成"消息"

2.1 协议头结构：固定头部加变长字段

TCP是流协议，没有天然的消息边界，所以应用层必须自己定义"帧"。我的做法是设计一个固定长度的协议头，后面跟着文件名和文件内容。固定头部长度的好处是，接收方可以先读固定字节，解析出各个字段的宽度，再按需读取后续内容。

我设计的协议头格式如下：

固定头部一共40字节。文件名是变长字段，跟在固定头部之后，随后才是文件内容。接收方拿到前40字节后，解析出文件名长度，再精确读取文件名，最后根据文件大小循环读取剩余内容。

这里有个经验：文件名长度用int而不是short，虽然实际场景里文件名几乎不会超过65535字节，但用int可以避免一个很隐蔽的边界问题。Java的DataInputStream.readUTF内部就是用short存长度的，文件名稍微长一点就抛UTFDataFormatException，排查起来很费劲。既然协议是自己设计的，就不要把这种限制带进来。

2.2 粘包与拆包的解决思路：定长头加变长体

粘包（接收方一次读到了两条消息的内容）和拆包（一条消息被分成多次读取）是TCP编程的经典问题。网上常看到两种解法：一种是约定固定长度消息，不足补位；另一种是使用特殊的结束符。固定长度协议浪费带宽，结束符方案又要求文件内容里不能出现结束符，都不太适合文件传输。

最实用的还是定长头加变长体的思路：接收方先把40字节的头部读完整，通过readFully保证读取的字节数恰好等于头部长度；然后根据头部里的文件名长度、文件大小，再精确读取对应字节数的数据。因为每次读取的量都有明确数字约束，即使消息在底层被拆成了多个TCP包，接收方也只需要循环读到指定字节数即可，粘包也不会影响后续解析——因为每条消息的长度是确定的，剩余缓冲区里的字节自然属于下一条消息。

在Java里实现这一点很简单，使用DataInputStream.readFully(byte[])比反复调用read()可靠得多。它内部帮你循环读取，直到读满指定长度，或者流已经结束。很多初学Socket的代码里喜欢这么写：

byte[] header = new byte[40]; in.read(header);

这个写法是有隐患的，read不保证一次读满40字节。必须改成：

byte[] header = new byte[40]; in.readFully(header);

不要小看这个差异，实测中普通局域网环境还好，跨交换机、跨网段传输时，read一次返回不满的情况非常常见，这也是"为什么我的接收数据总是缺一截"的高频根源。

2.3 三个容易被忽略的协议细节

第一个细节是文件名的编码问题。文件名在传输前用UTF-8编码成字节数组，长度是字节数组的长度，而不是字符串的字符数。接收方读出字节数组后用UTF-8解码恢复文件名。如果不统一编码，发送端用GBK、接收端按UTF-8解析，中文文件名必然乱码，服务端写出去的文件名也会出问题。

第二个细节是目录穿越。协议里收到的是客户端发来的文件名，服务端如果直接拿它拼路径，比如new File(baseDir, fileName)，一旦fileName里包含../，服务端的文件就会写到baseDir以外，这是严重的安全漏洞。服务端必须对文件名做净化处理，最简单的方式是取文件名中的最后一个路径分隔符之后的部分，或者用白名单字符集过滤。

第三个细节是响应反馈。协议不能只允许客户端向服务端发送，服务端也需要告诉客户端上传结果。所以客户端发完文件内容后，调用shutdownOutput进入半关闭状态，让服务端读到文件流的末尾，随后服务端写一个int类型的状态码（比如0表示成功，1表示失败，2表示校验错误）回送给客户端。这里的半关闭是关键，它告诉TCP"我的发送方向已经结束，但连接仍然可以用来接收数据"。

3. 服务端实现：从accept到落盘的完整链路

3.1 服务端骨架：ServerSocket加线程池

服务端要做的事情很简单：监听端口、接受连接、为每个连接分配合适的处理器。但简单的背后有几处要注意。

一是监听的端口要设置合理，过高（如65535）在生产环境容易被防火墙拦截，过低（如1024以下）又需要权限。案例里我用9999这种高位端口。二是处理方式是单线程还是多线程：如果只有一个客户端传文件，单线程也够用，但实际环境里总会有多个上传任务，所以我在最外层放ServerSocket，每拿到一个Socket就交给一个独立的线程去处理。

ServerSocket serverSocket = new ServerSocket(9999); ExecutorService pool = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors() * 2); while (!Thread.currentThread().isInterrupted()) { Socket socket = serverSocket.accept(); socket.setTcpNoDelay(true); pool.submit(() -> handleClient(socket)); }

Executors.newFixedThreadPool在线程数量上可以控制并发上限，避免因为大量上传请求导致服务端创建上千个线程，直接打爆内存。生产环境里我一般推荐用ThreadPoolExecutor手动指定核心线程数和队列容量，但在教学案例里固定线程池够用，规则也简单。

setTcpNoDelay(true)也值得说明：它关闭了Nagle算法。Nagle算法会把小的数据包攒在一起发送以减少网络报文数量，但对于文件上传这种需要频繁写入小块数据的场景，Nagle带来的延迟会让交互式确认变得拖沓。文件上传更看重吞吐，关闭Nagle后小包的发送延迟明显降低。

3.2 协议解析与文件写入的核心逻辑

每个客户端连接进来后，真正的核心逻辑是固定的几步：读固定头部、读文件名、按文件大小循环读文件体、写磁盘、校验、回送结果。

private static final int HEADER_SIZE = 40; private static final int MAGIC = 0x4D41494E; private void handleClient(Socket socket) { String filePath = null; try (DataInputStream in = new DataInputStream(new BufferedInputStream(socket.getInputStream())); DataOutputStream out = new DataOutputStream(socket.getOutputStream())) { byte[] headerBytes = new byte[HEADER_SIZE]; in.readFully(headerBytes); ByteBuffer header = ByteBuffer.wrap(headerBytes).order(ByteOrder.BIG_ENDIAN); int magic = header.getInt(); int version = header.getInt(); int nameLen = header.getInt(); long fileSize = header.getLong(); int mode = header.getInt(); byte[] expectMd5 = new byte[16]; header.get(expectMd5); if (magic != MAGIC) { out.writeInt(STATUS_PROTOCOL_ERROR); return; } byte[] nameBytes = new byte[nameLen]; in.readFully(nameBytes); String fileName = new String(nameBytes, StandardCharsets.UTF_8); String safeName = sanitizeFileName(fileName); File target = resolvePath(safeName, mode); if (target == null) { out.writeInt(STATUS_EXISTS); return; } filePath = target.getAbsolutePath(); long totalRead = 0; try (FileOutputStream fos = new FileOutputStream(target); BufferedOutputStream bos = new BufferedOutputStream(fos)) { byte[] buffer = new byte[64 * 1024]; while (totalRead < fileSize) { int need = (int) Math.min(buffer.length, fileSize - totalRead); int len = in.read(buffer, 0, need); if (len == -1) break; bos.write(buffer, 0, len); totalRead += len; } bos.flush(); } if (totalRead != fileSize) { out.writeInt(STATUS_INCOMPLETE); return; } byte[] actualMd5 = md5(Paths.get(filePath)); if (!MessageDigest.isEqual(expectMd5, actualMd5)) { out.writeInt(STATUS_MD5_ERROR); return; } out.writeInt(STATUS_OK); } catch (IOException e) { if (filePath != null) { new File(filePath).delete(); } e.printStackTrace(); } }

一定要注意文件体的读取循环。因为in.read(buffer, 0, need)在一次调用中不一定能把need个字节全部读满，所以循环条件是基于totalRead < fileSize，每个分片按剩余字节数取need，这样既避免读了下一帧的数据（如果还有的话），也保证了大文件能被完整读完。

3.3 路径处理与服务端的安全考虑

sanitizeFileName和resolvePath这两个方法虽然代码不多，却是服务端最值得花心思的地方。

sanitizeFileName的逻辑是把传入文件名的所有路径分隔符替换为下划线，或者提取最后一个分隔符后面的部分。因为文件名的来源是网络对端，永远不能信任。同时还要过滤掉Windows下不合法字符（比如<>:"/\\|?*），否则服务端落在Windows目录时文件写入会抛IOException。

resolvePath则处理上传模式。如果模式是覆盖，直接返回baseDir下的目标文件；如果是追加，返回目标文件并准备好以追加方式写入；如果是拒绝且文件已存在，就返回null，通知客户端上传被拒绝。基本逻辑是：

private File resolvePath(String fileName, int mode) { File baseDir = new File(System.getProperty("user.home"), "uploads"); if (!baseDir.exists()) baseDir.mkdirs(); File target = new File(baseDir, fileName); if (mode == MODE_APPEND) return target; if (mode == MODE_REFUSE && target.exists()) return null; return target; }

这个逻辑的好处是覆盖模式天然支持重复上传，适合批处理场景；拒绝模式则避免了不小心覆盖重要文件。你完全可以根据自己场景调整，但安全边界一定不能省。

3.4 完整性校验与异常清理

MD5校验放在文件全部写入磁盘之后执行。理论上应该在内存里边收边算摘要，节省一遍文件的完整读取，但这样对内存的占用太高（大文件场景不可行）。案例里选择的是接收完成后，对落盘文件重新计算MD5，再与协议头携带的预期MD5比较。代价是文件会被读第二遍，增加了耗时；好处是逻辑简单、可靠性高。如果文件特别大，可以折算一下耗时，能接受就用，不能接受就把校验机制降级为只校验文件大小。

校验为什么重要？我在一开始就强调TCP是可靠传输，但TCP的可靠不等于端到端的内容不变。中间设备改写、服务端磁盘坏道、程序缓存没刷干净，都可能导致落盘文件和原始文件不一致。有了MD5对比，至少能发现绝大多数数据损坏的情况。也不要忘了，totalRead != fileSize这种最基本的判断，在客户端还没发完就断开连接时，文件往往只有原始大小的一部分，这时候必须把半成品文件删除，并回送错误码。

4. 客户端实现：连接、按协议发送、等待反馈

4.1 客户端骨架与连接超时设置

客户端的实现和服务端恰好互逆，它的职责是：把本地文件转换成协议头加文件体的字节流，发送到服务端，然后等待确认。代码的第一步是建立连接。这个步骤有几个常见的坑。

用的是Socket()无参构造加上connect方法，可以在建立连接前设置超时时间：

Socket socket = new Socket(); socket.connect(new InetSocketAddress(host, port), 5000); socket.setSoTimeout(30000);

connect方法的第二个参数是连接超时（毫秒）。不设置的话，new Socket(host, port)遇到不可达地址时会卡很久，用户体验极差。setSoTimeout(30000)设置的是读超时，也就是等待服务端响应结果时的最大阻塞时间，防止服务端一直不返回导致客户端线程永久挂掉。这两个超时是网络编程里最容易漏掉、但生产环境又一定必须加的配置。

4.2 大文件分块发送：不要一次性读进内存

很多初学者的代码喜欢这样写：

byte[] data = Files.readAllBytes(file.toPath()); out.write(data);

这种写法处理几MB的小文件问题不大，但文件一旦到了几百MB甚至几GB，readAllBytes会直接把内存撑爆。正确做法是分块读取并循环发送，建议的缓冲区大小是64KB到1MB之间。

实际传输中我习惯用64KB，这是一个在性能和内存占用之间比较平衡的值。缓冲区太小，系统调用次数变多，吞吐上不去；缓冲区太大，单个TCP分片也装不下，反而增加内存压力。

try (FileInputStream fis = new FileInputStream(file); BufferedInputStream bis = new BufferedInputStream(fis)) { byte[] buffer = new byte[64 * 1024]; int len; long sent = 0; while ((len = bis.read(buffer)) != -1) { out.write(buffer, 0, len); sent += len; long percent = sent * 100 / fileSize; if (percent >= lastPercent + 5) { System.out.printf("已发送：%d / %d（%d%%）%n", sent, fileSize, percent); lastPercent = percent; } } out.flush(); }

out.write(buffer, 0, len)里的len来自bis.read的返回值，这个返回值决定了本次写入的实际字节数。绝大多数情况下，一次read返回的量不会超过64KB，所以out.write一次也会把这个缓冲区的数据尽可能推入Socket发送缓冲区。由于网络拥塞，write本身可能导致线程阻塞，但这是正常的流量控制，不需要额外处理。

4.3 半关闭连接与读取服务端响应

文件内容发送完毕后，客户端不能直接调用close关闭连接，因为如果连接直接关闭，服务端可能还没有机会把处理结果回传，客户端就收不到了。正确做法是调用shutdownOutput()，这会让TCP连接进入半关闭状态：告诉服务端"我的发送方向已经结束"，但仍然保留接收方向，可以继续等待服务端返回结果。

socket.shutdownOutput(); DataInputStream din = new DataInputStream(socket.getInputStream()); int status = din.readInt(); if (status == STATUS_OK) { System.out.println("上传成功，服务端已校验MD5一致"); } else { System.out.println("上传失败，状态码：" + status); }

这里服务端也要配合好。服务端读取到文件流末尾（read返回-1）后，才会写结果给客户端。如果数据还没读完就写结果，客户端那边会因为在同一个Socket里先收到了结果字节，而把结果误当成文件内容的一部分，导致协议错乱。所以服务端一定要保证：文件内容读取循环结束后，再调用out.writeInt(status)。

有一个小细节是客户端这边的DataInputStream也需要设置超时。我在前面设置了setSoTimeout(30000)，这样即使服务端因为异常卡在文件读取阶段，客户端最多等30秒就会收到SocketTimeoutException，不会永远阻塞下去。

4.4 进度感知与回滚提示

进度反馈并不是协议的一部分，但却是用户体感的重要部分。一个上传任务跑十分钟，没有进度提示，用户的第一反应是程序卡死了。我这边实现的方式是每发送5%就打印一次日志，同时记录最后的百分比，避免重复打印。

日志的粒度没必要太细，5%已经足够。如果打印太频繁，大量日志输出本身也会消耗CPU和磁盘IO。实测下来，5%到10%的粒度最舒服。

进度日志的另一个作用是可以作为故障排查的线索。如果一次上传卡住了，日志停留在某个百分比位置不动，你就能判断问题出在哪个阶段：是发送过程中网络断开，还是服务端处理卡住，还是等待响应超时。看不到进度时，排查这种问题只能靠猜，体验完全不一样。

5. 实测踩坑：有些问题不跑一遍大数据根本想不到

5.1 粘包半包的真实复现

案例刚跑通的时候，我用一个100MB的文件测试，一切正常。然后换成一个1.2GB的文件，第一次传输就出了问题：服务端接收文件到一定大小后抛异常，提示文件提前结束。排查后发现，客户端在发送文件内容的同时，我把服务端的响应逻辑写在了文件内容读取完成之前。服务端一旦读了几个字节作为"响应"看待，整个消息结构就乱了。

这个坑的本质是：TCP的字节流没有边界，如果你在接收文件内容时还试图从同一个输入流里提前读"响应"，那读到的其实是文件内容的一部分。根源是因为文件内容很大，在底层会被拆成多个TCP包发送，read第一次拿到的可能只有一部分，导致代码逻辑把后面的某些字节误判为标志位。

解决方式也很简单：严格执行协议顺序。文件内容的读取循环必须跑完（totalRead == fileSize），然后才允许服务端从输入流读取后续内容。客户端也必须用shutdownOutput明确表示发送结束，才能进入等待响应阶段。顺序写对了，粘包半包问题就从设计上被压住了，剩下交给readFully去兜底。

5.2 long和int的选择：2GB限制

第一次设计协议头时，我图省事，文件大小用的是int。测试到1.8GB一切正常，但传到2.3GB时客户端报告发送了-1字节，服务端那边还没收到数据就已经报错。后来查了一下，问题就是int溢出：2.3GB换算成字节已经超过了int的最大值（约21.47亿），算出来的字节数变成了负数，整个发送循环直接崩溃。

教训很清楚：凡是和文件大小相关的字段，一律用long。Java的数组下标仍然是int限制，但你真正要写进Socket的是分片，不是整个文件的byte数组。用long记录总大小、用int记录每次的分片大小，两者组合起来就没问题了。

这个教训也提醒我，协议设计阶段最好把字段宽度一次性想清楚。文件大小、偏移量这些天然有变大趋势的字段，宁可用8字节的long，也不要为了省几个字节埋雷。

5.3 客户端断网之后，服务端留下一堆半成品

有一轮测试，我模拟了客户端中途断开：上传到一半，直接切断了网络。服务端那边没有及时感知到客户端断开，read方法在等着数据，直到TCP超时重传彻底失败后才抛出SocketException。这个过程中，服务端已经创建了目标文件并写入了一部分数据，异常发生后这部分就是残留的半成品文件。

处理方案分两步：第一步，在handleClient方法里记录本次任务的目标文件路径；第二步，在catch块中捕获所有IOException后，把记录的目标文件删除。删除动作本身也可能失败（文件被占用或权限不足），那就再想办法做一次补偿，或者至少输出一条足够显眼的日志，提醒人工介入。

另一个很实用的技巧是给服务端设置SO_TIMEOUT，也就是读超时。如果一定时间内没有字节到达，就直接抛异常结束任务，而不是无限等待。文件上传的场景里，客户端长时间不发送任何数据基本可以判定连接异常，等待没有意义。

5.4 Windows和Linux路径分隔符差异

这个坑很隐蔽：客户端在Windows下把文件路径D:\logs\access.log直接拼到协议里，服务端在Linux下按/分割路径，文件名变成了D:\logs\access.log整个字符串。Windows下执行File写入时，反斜杠会被当作转义字符的一部分，结果文件名异常，打不开目标文件。

我给的方案是在sanitizeFileName里统一过滤所有\\和/，提取最后一个分隔符之后的部分作为文件名。这样客户端传D:\logs\access.log过来，服务端写出的文件名就是access.log。如果确实需要保持目录结构，那就让协议再增加一个字段，显式表示相对路径，而不是依赖文件名里的分隔符自动解析。

6. 进阶方向：并发、续传与更高效的数据通道

6.1 多客户端并发上传的线程池参数

如果同时上传的客户端有好几个，服务端的线程池参数就不能随便写了。前面用availableProcessors() * 2只适合CPU密集型的推算，文件传输其实是IO密集型任务，线程数可以略多。

一个比较稳的起步配置是：

ThreadPoolExecutor pool = new ThreadPoolExecutor( 4, 16, 60, TimeUnit.SECONDS, new ArrayBlockingQueue<>(100), new ThreadPoolExecutor.CallerRunsPolicy() );

核心线程数4，最大线程数16，队列容量100。超出队列容量时，CallerRunsPolicy让提交任务的线程自己执行，这比直接抛拒绝异常更温和，至少不会让客户端瞬间收到失败。但也要注意，如果并发太高，IO和磁盘会成为瓶颈，线程再多也没有收益，反而增加上下文切换的成本。实测几GB大数据并发时，磁盘写入速度通常是第一瓶颈，并发数控制在磁盘能承受的范围内才是对的。

6.2 断点续传：协议加offset，服务端改用RandomAccessFile

断点续传的关键是让服务端知道"这次从哪里继续写"。在协议头里增加一个8字节的offset字段，客户端发送前先和服务端确认已有文件大小，然后从偏移位置开始读取并发送文件剩余部分。

服务端接收时改用RandomAccessFile，打开文件后先seek(offset)，再按循环写入文件体。这里要注意，校验策略也要跟着变：如果文件只传了一半就断了，整文件MD5还没算出来，续传后的MD5计算必须在文件补齐之后才能做。另一种做法是传输时对每个分片计算CRC32，服务端每收到一片校验一片，这样不用等整个文件送完就能及时发现损坏。代价是协议头里需要再增加分片序号和分片CRC字段，复杂度上了一个台阶。

如果只是作为学习案例，先把offset机制实现出来就够理解了。真正的生产级续传还要解决"服务端如何知道文件已有多少数据"的问题，常见做法是客户端先发一个查询请求，或者协议头里带上服务端文件的旧大小，服务端比较后决定是覆盖、跳过还是续传。

6.3 零拷贝数据通道：FileChannel.transferTo

前面的代码用的是传统InputStream/OutputStream复制，每个字节都要在用户态和内核态之间拷贝多次。如果数据量极大，这部分的CPU消耗非常明显。Java NIO提供的FileChannel.transferTo可以借助操作系统内核的sendfile机制（Linux）直接把文件内容从文件系统发送到Socket缓冲，省去用户态拷贝。

发送端的核心代码可以简化为：

FileChannel channel = FileChannel.open(file.toPath(), StandardOpenOption.READ); long position = offset; long count = fileSize - offset; while (count > 0) { long transferred = channel.transferTo(position, count, socketChannel); if (transferred <= 0) break; position += transferred; count -= transferred; }

需要留意的是，transferTo并不是每调用一次就把count全传完，它返回的是实际传输的字节数，所以必须用循环。另外，SocketChannel要设置为阻塞模式（默认就是），transferTo才能正常工作。我实测过，使用零拷贝之后，同文件传输的CPU占用几乎下降了一半，对于大批量文件同步的场景提升非常明显。

零拷贝也不是银弹：如果文件特别小、或者网络非常快而磁盘很慢，收益就无法体现。但作为一种进阶优化思路，它确实是值得了解的经典技术。

6.4 还能往哪里扩展

这个案例做完之后，可以延伸的方向很多。最容易想到的是加密：用TLS替换裸的Socket，或者对文件内容做AES加密后再传输，解决明文数据在网络上被截获的问题。其次是压缩：在客户端读文件时用GZIPOutputStream包一层，文件变小了传输自然变快，代价是CPU占用增加。再往下就是秒传：客户端先发送文件MD5，服务端如果已经有相同摘要的文件就直接返回成功，不需要真的传输数据。

还有一个值得尝试的方向是传输限速和失败自动重试。限速可以防止一个上传任务占满整个出口带宽，影响其他服务；失败重试则要和断点续传结合，才能做到断网恢复后自动接着传。把这些机制一个个加进去，一个简单的文件上传Demo就会慢慢变成一个真正能扛生产环境的小型分发系统。

这个案例本身不算复杂，核心就是一段清晰的协议、一个按部就班的接收循环、加上对异常边界的处理。但把它真正跑通、跑稳，你会发现对TCP通信的理解会扎实不少，以后再碰到消息队列、RPC框架里的传输设计和粘包处理，背后都是同一套原理。如果实际操作中遇到了奇怪的问题，优先从"消息边界是否分明""顺序是否严格""异常是否被吞掉"这三个角度排查，大概率能很快找到答案。