网络编程深度专题：从 TCP/IP 到 HTTP/3 的全栈指南 on PlumePHP

网络安全：TLS/SSL、证书与加密通信

Fri, 14 Aug 2026 10:48:00 +0800

TLS（Transport Layer Security）及其前身 SSL（Secure Sockets Layer）是保障网络通信安全的核心协议。理解 TLS 的握手流程、证书体系和密码学基础，是设计安全系统的必备知识。

负载均衡算法与高可用架构

Fri, 14 Aug 2026 10:47:00 +0800

负载均衡是分布式系统的核心组件，它将请求合理地分发到多个后端服务器，实现水平扩展、故障转移和高可用。

一、负载均衡层次

1.1 L4 vs L7

┌────────────────────────────────────────────┐
│ L7 负载均衡（应用层） │
│ - 基于 URL、Host、Header、Cookie │
│ - SSL 终止、HTTP 路由、内容缓存 │
│ - 代表：Nginx、HAProxy、Envoy、Traefik │
├────────────────────────────────────────────┤
│ L4 负载均衡（传输层） │
│ - 基于 IP + Port │
│ - TCP/UDP 流量分发，不解包应用层 │
│ - 代表：LVS、HAProxy、AWS NLB │
├────────────────────────────────────────────┤
│ DNS 负载均衡 │
│ - 基于地理位置、轮询返回不同 IP │
│ - 代表：Cloudflare、Route53 │
└────────────────────────────────────────────┘

1.2 对比

特性	L4	L7
性能	更高（不解包）	较低（解析 HTTP）
灵活性	低	高（路由规则丰富）
功能	仅转发	SSL、Rewrite、限流、缓存
延迟	微秒级	毫秒级
适用场景	数据库、TCP 服务	Web 应用、API 网关

二、负载均衡算法

2.1 轮询（Round Robin）

public class RoundRobinLoadBalancer {
 
 private final List<String> servers;
 private final AtomicInteger counter = new AtomicInteger(0);
 
 public RoundRobinLoadBalancer(List<String> servers) {
 this.servers = servers;
 }
 
 public String next() {
 int index = counter.getAndIncrement() % servers.size();
 return servers.get(index);
 }
}

// 加权轮询
public class WeightedRoundRobin {
 
 private final List<Server> servers;
 private final AtomicInteger currentIndex = new AtomicInteger(-1);
 private final AtomicInteger currentWeight = new AtomicInteger(0);
 private final int maxWeight;
 private final int gcdWeight;
 
 public String next() {
 while (true) {
 int index = currentIndex.incrementAndGet() % servers.size();
 
 if (index == 0) {
 int weight = currentWeight.decrementAndGet();
 if (weight <= 0) {
 currentWeight.set(maxWeight);
 }
 }
 
 Server server = servers.get(index);
 if (server.weight >= currentWeight.get()) {
 return server.address;
 }
 }
 }
}

2.2 最少连接（Least Connections）

public class LeastConnectionsBalancer {
 
 private final Map<String, AtomicInteger> connections = new ConcurrentHashMap<>();
 
 public String next() {
 return connections.entrySet().stream()
 .min(Map.Entry.comparingByValue())
 .map(Map.Entry::getKey)
 .orElseThrow();
 }
 
 public void acquire(String server) {
 connections.computeIfAbsent(server, k -> new AtomicInteger()).incrementAndGet();
 }
 
 public void release(String server) {
 connections.get(server).decrementAndGet();
 }
}

2.3 一致性哈希（Consistent Hashing）

public class ConsistentHashBalancer {
 
 private final TreeMap<Long, String> ring = new TreeMap<>();
 private final int virtualNodes; // 虚拟节点数
 
 public ConsistentHashBalancer(List<String> servers, int virtualNodes) {
 this.virtualNodes = virtualNodes;
 for (String server : servers) {
 addServer(server);
 }
 }
 
 public void addServer(String server) {
 for (int i = 0; i < virtualNodes; i++) {
 long hash = hash(server + "#" + i);
 ring.put(hash, server);
 }
 }
 
 public void removeServer(String server) {
 for (int i = 0; i < virtualNodes; i++) {
 long hash = hash(server + "#" + i);
 ring.remove(hash);
 }
 }
 
 public String getNode(String key) {
 if (ring.isEmpty()) return null;
 
 long hash = hash(key);
 Map.Entry<Long, String> entry = ring.ceilingEntry(hash);
 if (entry == null) {
 entry = ring.firstEntry();
 }
 return entry.getValue();
 }
 
 private long hash(String key) {
 // MurmurHash 或 MD5
 return Hashing.murmur3_128().hashString(key, StandardCharsets.UTF_8).asLong();
 }
}

// 使用场景：
// - 分布式缓存（Redis Cluster）
// - 分布式存储（MinIO）
// - 有状态服务路由

2.4 算法选型

算法	优点	缺点	适用场景
轮询	简单、均匀	不考虑负载差异	服务器性能相近
加权轮询	考虑性能差异	需手动配置权重	异构服务器集群
最少连接	动态适应	需维护连接计数	长连接服务
一致性哈希	节点增减影响小	可能不均匀	缓存、有状态服务
IP 哈希	会话保持	热点风险	需要会话粘性
随机	实现简单	不够均匀	简单场景

三、Nginx 负载均衡配置

# HTTP 负载均衡（L7）
upstream backend {
 # 加权轮询（默认）
 server 192.168.1.10:8080 weight=5;
 server 192.168.1.11:8080 weight=3;
 server 192.168.1.12:8080 backup; # 备用
 
 # 最少连接
 least_conn;
 
 # IP 哈希（会话保持）
 # ip_hash;
 
 # 一致性哈希（基于变量）
 # hash $request_uri consistent;
 
 # 健康检查
 server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
 
 keepalive 32; # 连接池
}

server {
 listen 80;
 
 location /api/ {
 proxy_pass http://backend;
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
 # 超时配置
 proxy_connect_timeout 5s;
 proxy_read_timeout 30s;
 proxy_send_timeout 30s;
 }
 
 # 静态资源，基于 URL 路由
 location /static/ {
 proxy_pass http://static-backend;
 }
}

# TCP/UDP 负载均衡（L4，需 stream 模块）
stream {
 upstream redis_backend {
 server 192.168.1.10:6379;
 server 192.168.1.11:6379;
 
 # 健康检查
 check interval=3000 rise=2 fall=3 timeout=1000;
 }
 
 server {
 listen 6379;
 proxy_pass redis_backend;
 proxy_connect_timeout 3s;
 proxy_timeout 30s;
 }
}

四、健康检查

public class HealthChecker {
 
 private final List<Server> servers;
 private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
 
 public HealthChecker(List<Server> servers) {
 this.servers = servers;
 // 每 5 秒检查一次
 scheduler.scheduleAtFixedRate(this::checkAll, 5, 5, TimeUnit.SECONDS);
 }
 
 private void checkAll() {
 for (Server server : servers) {
 boolean healthy = checkServer(server);
 if (healthy != server.isHealthy()) {
 server.setHealthy(healthy);
 System.out.println("Server " + server.getAddress() + " is " + (healthy ? "UP" : "DOWN"));
 }
 }
 }
 
 private boolean checkServer(Server server) {
 try (Socket socket = new Socket()) {
 socket.connect(new InetSocketAddress(server.getHost(), server.getPort()), 3000);
 return true;
 } catch (IOException e) {
 return false;
 }
 }
}

五、总结

组件	层级	算法	场景
Nginx	L7/L4	轮询、加权、IP 哈希、最少连接	Web 入口、API 网关
LVS	L4	多种	极高性能场景
Envoy	L7	丰富的负载均衡策略	云原生、Service Mesh
DNS	L3	地理、轮询	多活架构、全球调度

负载均衡不仅是请求分发，更是系统高可用的核心保障。合理的算法选型、完善的监控告警、自动化的故障转移，才能构建真正可靠的服务架构。

DNS 系统与智能解析

Fri, 14 Aug 2026 10:46:00 +0800

DNS（Domain Name System）是互联网的"电话簿"，负责将人类可读的域名转换为机器可识别的 IP 地址。深入理解 DNS 的工作原理，对理解网络通信的底层逻辑至关重要。

WebSocket 协议与实时通信

Fri, 14 Aug 2026 10:45:00 +0800

WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议，它使得浏览器和服务器之间可以建立持久连接，实现低延迟、高效率的实时双向数据传输。

一、为什么需要 WebSocket

1.1 传统方案对比

方案	原理	延迟	缺点
轮询	定时 HTTP 请求	高（取决于间隔）	无效请求多，浪费带宽
长轮询	挂起请求直到有数据	中	服务器压力大，消息可能乱序
SSE	服务端单向推送	低	仅服务端→客户端，不支持二进制
WebSocket	全双工长连接	极低	协议复杂度高，需处理断线重连

1.2 适用场景

即时通讯（IM、聊天室）
在线协作（文档编辑、白板）
实时数据（股票行情、监控大盘）
在线游戏（操作同步、位置更新）
IoT 设备数据上报

二、WebSocket 握手

2.1 HTTP Upgrade 过程

客户端请求（HTTP/1.1）：

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: http://example.com

服务端响应（101 Switching Protocols）：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Sec-WebSocket-Accept 计算：
 base64(sha1(Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"))

2.2 Spring Boot WebSocket

@Configuration
@EnableWebSocketMessageBroker
public class WebSocketConfig implements WebSocketMessageBrokerConfigurer {
 
 @Override
 public void configureMessageBroker(MessageBrokerRegistry registry) {
 registry.enableSimpleBroker("/topic", "/queue");
 registry.setApplicationDestinationPrefixes("/app");
 registry.setUserDestinationPrefix("/user");
 }
 
 @Override
 public void registerStompEndpoints(StompEndpointRegistry registry) {
 registry.addEndpoint("/ws")
 .setAllowedOriginPatterns("*")
 .withSockJS();
 }
}

@Controller
public class ChatController {
 
 @Autowired
 private SimpMessagingTemplate messagingTemplate;
 
 @MessageMapping("/chat")
 @SendTo("/topic/messages")
 public ChatMessage handleChat(ChatMessage message) {
 message.setTimestamp(System.currentTimeMillis());
 return message;
 }
 
 public void sendToUser(String userId, ChatMessage message) {
 messagingTemplate.convertAndSendToUser(userId, "/queue/notify", message);
 }
}

2.3 Netty WebSocket 服务端

public class NettyWebSocketServer {
 
 public static void main(String[] args) throws Exception {
 EventLoopGroup boss = new NioEventLoopGroup(1);
 EventLoopGroup worker = new NioEventLoopGroup();
 
 try {
 ServerBootstrap bootstrap = new ServerBootstrap();
 bootstrap.group(boss, worker)
 .channel(NioServerSocketChannel.class)
 .childHandler(new ChannelInitializer<SocketChannel>() {
 @Override
 protected void initChannel(SocketChannel ch) {
 ch.pipeline()
 .addLast(new HttpServerCodec())
 .addLast(new HttpObjectAggregator(65536))
 .addLast(new WebSocketServerProtocolHandler("/ws"))
 .addLast(new WebSocketFrameHandler());
 }
 });
 
 ChannelFuture future = bootstrap.bind(8080).sync();
 future.channel().closeFuture().sync();
 } finally {
 boss.shutdownGracefully();
 worker.shutdownGracefully();
 }
 }
}

public class WebSocketFrameHandler extends SimpleChannelInboundHandler<WebSocketFrame> {
 
 private static final ChannelGroup channels = new DefaultChannelGroup(GlobalEventExecutor.INSTANCE);
 
 @Override
 public void handlerAdded(ChannelHandlerContext ctx) {
 channels.add(ctx.channel());
 }
 
 @Override
 protected void channelRead0(ChannelHandlerContext ctx, WebSocketFrame frame) {
 if (frame instanceof TextWebSocketFrame) {
 String text = ((TextWebSocketFrame) frame).text();
 System.out.println("Received: " + text);
 
 // 广播给所有客户端
 channels.writeAndFlush(new TextWebSocketFrame(
 "[" + ctx.channel().id() + "] " + text
 ));
 }
 }
 
 @Override
 public void handlerRemoved(ChannelHandlerContext ctx) {
 channels.remove(ctx.channel());
 }
}

三、WebSocket 帧格式

WebSocket 数据帧：

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - -+
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+

FIN: 是否为最后一帧
RSV: 保留位
Opcode: 0=继续, 1=文本, 2=二进制, 8=关闭, 9=Ping, 10=Pong
MASK: 客户端必须掩码，服务端不应掩码
Payload len: 数据长度（7/16/64 bits）

四、心跳与保活

4.1 Ping/Pong 机制

// 服务端定期发送 Ping
public class HeartbeatHandler extends ChannelInboundHandlerAdapter {
 
 private static final int PING_INTERVAL = 30; // 秒
 
 @Override
 public void userEventTriggered(ChannelHandlerContext ctx, Object evt) {
 if (evt instanceof IdleStateEvent) {
 IdleStateEvent event = (IdleStateEvent) evt;
 if (event.state() == IdleState.READER_IDLE) {
 // 客户端长时间未发送消息，关闭连接
 ctx.close();
 } else if (event.state() == IdleState.WRITER_IDLE) {
 // 发送 Ping
 ctx.writeAndFlush(new PingWebSocketFrame());
 }
 }
 }
}

// Pipeline 配置
ch.pipeline()
 .addLast(new IdleStateHandler(60, 30, 0)) // 读空闲60s，写空闲30s
 .addLast(new HeartbeatHandler());

五、大规模推送架构

大规模 WebSocket 推送架构：

客户端 ←──→ CDN / WAF
 │
 ▼
┌──────────────────────────────┐
│ L7 负载均衡器 │
│ (Nginx / HAProxy / Envoy) │
│ ws://example.com/ws │
└──────────────┬───────────────┘
 │
 ┌──────────┼──────────┐
 ▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│ WS-1 │ │ WS-2 │ │ WS-3 │ WebSocket 服务集群
│ (10k) │ │ (10k) │ │ (10k) │ 每台维护 1-10 万连接
└───┬───┘ └───┬───┘ └───┬───┘
 │ │ │
 └──────────┼──────────┘
 ▼
┌──────────────────────────────┐
│ Redis Pub/Sub │ 消息总线
│ / RabbitMQ / Kafka │ 广播消息到所有 WS 节点
└──────────────────────────────┘
 ▲
 │
 业务服务发送消息

关键设计：
1. 有状态服务 → 客户端需保持连接到同一节点
2. 消息总线 → 所有节点共享消息
3. 心跳检测 → 及时清理死连接
4. 连接数限制 → 单机不超过 ulimit

六、连接管理

@Component
public class WebSocketSessionManager {
 
 private final ConcurrentHashMap<String, WebSocketSession> sessions = new ConcurrentHashMap<>();
 
 public void register(String userId, WebSocketSession session) {
 WebSocketSession old = sessions.put(userId, session);
 if (old != null && old.isOpen()) {
 try {
 old.close(); // 踢掉旧连接
 } catch (IOException e) {
 log.warn("关闭旧连接失败", e);
 }
 }
 }
 
 public void unregister(String userId) {
 sessions.remove(userId);
 }
 
 public void sendToUser(String userId, String message) {
 WebSocketSession session = sessions.get(userId);
 if (session != null && session.isOpen()) {
 try {
 session.sendMessage(new TextMessage(message));
 } catch (IOException e) {
 log.error("发送消息失败: {}", userId, e);
 }
 }
 }
 
 public void broadcast(String message) {
 sessions.values().forEach(session -> {
 if (session.isOpen()) {
 try {
 session.sendMessage(new TextMessage(message));
 } catch (IOException e) {
 log.error("广播消息失败", e);
 }
 }
 });
 }
 
 public int getOnlineCount() {
 return sessions.size();
 }
}

七、安全性考量

// Origin 校验
@Override
public boolean beforeHandshake(ServerHttpRequest request, ServerHttpResponse response,
 WebSocketHandler wsHandler, Map<String, Object> attributes) {
 String origin = request.getHeaders().getOrigin();
 if (!ALLOWED_ORIGINS.contains(origin)) {
 return false; // 拒绝非白名单 Origin
 }
 return true;
}

// JWT 认证（通过 URL 参数传递 Token）
@Override
public void afterConnectionEstablished(WebSocketSession session) {
 String token = extractToken(session);
 if (!jwtUtil.validate(token)) {
 session.close(CloseStatus.POLICY_VIOLATION);
 return;
 }
 String userId = jwtUtil.getUserId(token);
 sessionManager.register(userId, session);
}

八、总结

方面	建议
协议选择	WebSocket 适合双向实时，SSE 适合服务端推送
框架选型	Spring STOMP 快速开发，Netty 高性能定制
集群部署	Redis Pub/Sub 做消息广播，保证多节点一致
连接管理	心跳保活 + 超时清理 + 单用户单连接
安全防护	Origin 校验 + JWT 认证 + 连接数限制

WebSocket 是实现实时通信的核心技术。在生产环境中，需要重点关注连接的稳定性（心跳、重连）、扩展性（集群、消息广播）和安全性（认证、防攻击）。

Java NIO/AIO 与网络编程

Fri, 14 Aug 2026 10:44:00 +0800

Java NIO（New I/O，非阻塞 I/O）在 JDK 1.4 引入，AIO（Asynchronous I/O）在 JDK 1.7 引入。理解这些 I/O 模型是掌握 Netty 等高性能框架的基础。

Netty 高性能网络编程框架

Fri, 14 Aug 2026 10:43:00 +0800

Netty 是一个异步事件驱动的网络应用框架，用于快速开发可维护的高性能协议服务器和客户端。它是 Java 网络编程领域的事实标准，支撑了 Dubbo、RocketMQ、gRPC 等大量知名项目。

gRPC 协议原理与性能优化

Fri, 14 Aug 2026 10:42:00 +0800

gRPC 是 Google 开源的高性能 RPC 框架，基于 HTTP/2 和 Protocol Buffers，已成为微服务间通信的事实标准之一。

一、gRPC 架构概览

1.1 协议栈

┌─────────────────────────────┐
│ gRPC 层 │
│ - 四种通信模式 │
│ - 拦截器、认证、压缩 │
├─────────────────────────────┤
│ HTTP/2 层 │
│ - 头部帧、数据帧 │
│ - 流多路复用 │
├─────────────────────────────┤
│ TLS 层（可选） │
│ - 证书认证、ALPN │
├─────────────────────────────┤
│ TCP 层 │
│ - 可靠传输 │
└─────────────────────────────┘

1.2 IDL 定义（.proto）

syntax = "proto3";

package order;
option java_package = "com.example.order";
option java_outer_classname = "OrderProto";

// 定义服务
service OrderService {
 // Unary：单次请求-响应
 rpc GetOrder (GetOrderRequest) returns (Order);
 
 // Server Streaming：服务端流
 rpc ListOrders (ListOrdersRequest) returns (stream Order);
 
 // Client Streaming：客户端流
 rpc CreateOrders (stream CreateOrderRequest) returns (OrderBatchResponse);
 
 // Bidirectional Streaming：双向流
 rpc SyncOrders (stream OrderEvent) returns (stream OrderStatus);
}

message GetOrderRequest {
 string order_id = 1;
}

message Order {
 string order_id = 1;
 string user_id = 2;
 double amount = 3;
 OrderStatus status = 4;
 int64 created_at = 5;
}

enum OrderStatus {
 PENDING = 0;
 PAID = 1;
 SHIPPED = 2;
 COMPLETED = 3;
}

message ListOrdersRequest {
 string user_id = 1;
 int32 page = 2;
 int32 page_size = 3;
}

message CreateOrderRequest {
 string user_id = 1;
 repeated OrderItem items = 2;
}

message OrderItem {
 string sku_id = 1;
 int32 quantity = 2;
 double price = 3;
}

message OrderBatchResponse {
 int32 created_count = 1;
 repeated string order_ids = 2;
}

message OrderEvent {
 string order_id = 1;
 OrderStatus new_status = 2;
}

二、Java gRPC 实战

2.1 Maven 配置

<properties>
 <grpc.version>1.65.1</grpc.version>
 <protobuf.version>3.25.3</protobuf.version>
</properties>

<dependencies>
 <dependency>
 <groupId>io.grpc</groupId>
 <artifactId>grpc-netty-shaded</artifactId>
 <version>${grpc.version}</version>
 </dependency>
 <dependency>
 <groupId>io.grpc</groupId>
 <artifactId>grpc-protobuf</artifactId>
 <version>${grpc.version}</version>
 </dependency>
 <dependency>
 <groupId>io.grpc</groupId>
 <artifactId>grpc-stub</artifactId>
 <version>${grpc.version}</version>
 </dependency>
</dependencies>

<build>
 <extensions>
 <extension>
 <groupId>kr.motd.maven</groupId>
 <artifactId>os-maven-plugin</artifactId>
 <version>1.7.1</version>
 </extension>
 </extensions>
 <plugins>
 <plugin>
 <groupId>org.xolstice.maven.plugins</groupId>
 <artifactId>protobuf-maven-plugin</artifactId>
 <version>0.6.1</version>
 <configuration>
 <protocArtifact>com.google.protobuf:protoc:${protobuf.version}:exe:${os.detected.classifier}</protocArtifact>
 <pluginId>grpc-java</pluginId>
 <pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
 </configuration>
 <executions>
 <execution>
 <goals>
 <goal>compile</goal>
 <goal>compile-custom</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 </plugins>
</build>

2.2 服务端实现

@Service
public class OrderGrpcService extends OrderServiceGrpc.OrderServiceImplBase {
 
 @Autowired
 private OrderApplicationService orderService;
 
 // 1. Unary 模式
 @Override
 public void getOrder(GetOrderRequest request, StreamObserver<Order> responseObserver) {
 try {
 OrderDTO dto = orderService.getOrder(request.getOrderId());
 Order order = Order.newBuilder()
 .setOrderId(dto.getOrderId())
 .setUserId(dto.getUserId())
 .setAmount(dto.getAmount())
 .setStatus(mapStatus(dto.getStatus()))
 .setCreatedAt(dto.getCreatedAt().toEpochMilli())
 .build();
 
 responseObserver.onNext(order);
 responseObserver.onCompleted();
 } catch (OrderNotFoundException e) {
 responseObserver.onError(
 Status.NOT_FOUND.withDescription(e.getMessage()).asRuntimeException()
 );
 }
 }
 
 // 2. Server Streaming 模式
 @Override
 public void listOrders(ListOrdersRequest request, StreamObserver<Order> responseObserver) {
 Page<OrderDTO> orders = orderService.listOrders(
 request.getUserId(),
 request.getPage(),
 request.getPageSize()
 );
 
 for (OrderDTO dto : orders.getContent()) {
 responseObserver.onNext(mapToProto(dto));
 }
 responseObserver.onCompleted();
 }
 
 // 3. Client Streaming 模式
 @Override
 public StreamObserver<CreateOrderRequest> createOrders(
 StreamObserver<OrderBatchResponse> responseObserver
 ) {
 return new StreamObserver<>() {
 private final List<String> orderIds = new ArrayList<>();
 
 @Override
 public void onNext(CreateOrderRequest request) {
 String orderId = orderService.createOrder(request);
 orderIds.add(orderId);
 }
 
 @Override
 public void onError(Throwable t) {
 log.error("Client stream error", t);
 }
 
 @Override
 public void onCompleted() {
 responseObserver.onNext(OrderBatchResponse.newBuilder()
 .setCreatedCount(orderIds.size())
 .addAllOrderIds(orderIds)
 .build());
 responseObserver.onCompleted();
 }
 };
 }
 
 // 4. Bidirectional Streaming 模式
 @Override
 public StreamObserver<OrderEvent> syncOrders(StreamObserver<OrderStatus> responseObserver) {
 return new StreamObserver<>() {
 @Override
 public void onNext(OrderEvent event) {
 // 处理客户端发来的事件
 OrderStatus status = orderService.processEvent(event);
 // 实时响应
 responseObserver.onNext(status);
 }
 
 @Override
 public void onError(Throwable t) {
 log.error("Bidirectional stream error", t);
 }
 
 @Override
 public void onCompleted() {
 responseObserver.onCompleted();
 }
 };
 }
}

// 服务端启动
@Configuration
public class GrpcServerConfig {
 
 @Autowired
 private OrderGrpcService orderService;
 
 @Bean(destroyMethod = "shutdown")
 public Server grpcServer() throws IOException {
 Server server = ServerBuilder.forPort(9090)
 .addService(orderService)
 .addService(ServerInterceptors.intercept(
 orderService,
 new AuthInterceptor(),
 new LoggingInterceptor()
 ))
 .maxInboundMessageSize(1024 * 1024 * 10) // 10MB
 .maxInboundMetadataSize(1024 * 32) // 32KB
 .build();
 
 server.start();
 return server;
 }
}

2.3 客户端实现

@Service
public class OrderGrpcClient {
 
 private final OrderServiceGrpc.OrderServiceBlockingStub blockingStub;
 private final OrderServiceGrpc.OrderServiceStub asyncStub;
 
 public OrderGrpcClient() {
 ManagedChannel channel = ManagedChannelBuilder
 .forAddress("localhost", 9090)
 .usePlaintext() // 生产环境使用 TLS
 .maxRetryAttempts(3)
 .build();
 
 this.blockingStub = OrderServiceGrpc.newBlockingStub(channel);
 this.asyncStub = OrderServiceGrpc.newStub(channel);
 }
 
 // Unary 调用
 public Order getOrder(String orderId) {
 GetOrderRequest request = GetOrderRequest.newBuilder()
 .setOrderId(orderId)
 .build();
 
 return blockingStub.getOrder(request);
 }
 
 // Server Streaming
 public List<Order> listOrders(String userId) {
 ListOrdersRequest request = ListOrdersRequest.newBuilder()
 .setUserId(userId)
 .setPage(0)
 .setPageSize(100)
 .build();
 
 Iterator<Order> iterator = blockingStub.listOrders(request);
 List<Order> orders = new ArrayList<>();
 while (iterator.hasNext()) {
 orders.add(iterator.next());
 }
 return orders;
 }
 
 // Client Streaming（异步）
 public CompletableFuture<OrderBatchResponse> createOrders(List<CreateOrderRequest> requests) {
 CompletableFuture<OrderBatchResponse> future = new CompletableFuture<>();
 
 StreamObserver<OrderBatchResponse> responseObserver = new StreamObserver<>() {
 @Override
 public void onNext(OrderBatchResponse response) {
 future.complete(response);
 }
 
 @Override
 public void onError(Throwable t) {
 future.completeExceptionally(t);
 }
 
 @Override
 public void onCompleted() {}
 };
 
 StreamObserver<CreateOrderRequest> requestObserver = asyncStub.createOrders(responseObserver);
 
 for (CreateOrderRequest req : requests) {
 requestObserver.onNext(req);
 }
 requestObserver.onCompleted();
 
 return future;
 }
}

三、gRPC 与 HTTP/2 帧映射

gRPC 消息如何映射到 HTTP/2：

请求：
HEADERS 帧
 :method = POST
 :scheme = http
 :authority = localhost:9090
 :path = /order.OrderService/GetOrder
 content-type = application/grpc
 te = trailers
 grpc-timeout = 10S
 grpc-encoding = gzip

DATA 帧（Length-Prefixed Message）
 +------------------+------------------+
 | Compressed Flag | Message Length | (5 bytes 前缀)
 | (1 byte) | (4 bytes) |
 +------------------+------------------+
 | Serialized Protobuf |
 +--------------------------------------+

响应：
HEADERS 帧（初始）
 :status = 200
 content-type = application/grpc

DATA 帧（响应消息）

HEADERS 帧（结束，Trailers）
 grpc-status = 0
 grpc-message = OK

四、性能优化

4.1 连接池与通道复用

@Configuration
public class GrpcChannelConfig {
 
 @Bean
 public Map<String, ManagedChannel> grpcChannels() {
 return Map.of(
 "order-service", createChannel("order-svc", 9090),
 "inventory-service", createChannel("inventory-svc", 9091),
 "payment-service", createChannel("payment-svc", 9092)
 );
 }
 
 private ManagedChannel createChannel(String host, int port) {
 return ManagedChannelBuilder.forAddress(host, port)
 .useTransportSecurity() // TLS
 .defaultLoadBalancingPolicy("round_robin")
 .enableRetry()
 .maxRetryAttempts(3)
 .maxHedgedAttempts(1)
 .keepAliveTime(60, TimeUnit.SECONDS)
 .keepAliveTimeout(20, TimeUnit.SECONDS)
 .keepAliveWithoutCalls(true)
 .build();
 }
}

4.2 拦截器

// 认证拦截器
public class AuthInterceptor implements ClientInterceptor {
 
 private final String token;
 
 @Override
 public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
 MethodDescriptor<ReqT, RespT> method,
 CallOptions callOptions,
 Channel next
 ) {
 return new ForwardingClientCall.SimpleForwardingClientCall<>(next.newCall(method, callOptions)) {
 @Override
 public void start(Listener<RespT> responseListener, Metadata headers) {
 headers.put(Metadata.Key.of("authorization", Metadata.ASCII_STRING_MARSHALLER), "Bearer " + token);
 super.start(responseListener, headers);
 }
 };
 }
}

// 超时拦截器
public class TimeoutInterceptor implements ClientInterceptor {
 
 @Override
 public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
 MethodDescriptor<ReqT, RespT> method,
 CallOptions callOptions,
 Channel next
 ) {
 Deadline deadline = Deadline.after(10, TimeUnit.SECONDS);
 return next.newCall(method, callOptions.withDeadline(deadline));
 }
}

五、总结

方面	要点
通信模式	Unary、Server Stream、Client Stream、Bidirectional
序列化	Protocol Buffers，高效紧凑
传输层	HTTP/2，流多路复用
优势	高性能、强类型、流支持、跨语言
劣势	浏览器支持有限（需 gRPC-Web）、调试复杂

优化手段	效果
连接复用	减少 TCP/TLS 握手开销
消息复用	通过流模式减少往返
压缩	gzip/deflate 减少传输量
拦截器	统一处理认证、日志、超时
负载均衡	round_robin / least_request

gRPC 的设计充分利用了 HTTP/2 的多路复用和流特性，配合 Protocol Buffers 的高效序列化，为微服务间通信提供了企业级的解决方案。

HTTP/3 与 QUIC 协议深度解析

Fri, 14 Aug 2026 10:41:00 +0800

HTTP/3 是 HTTP 协议的最新主要版本，它最大的变革是放弃了基于 TCP 的传输，转而使用 Google 开发的 QUIC 协议（Quick UDP Internet Connections）。这一改变从根本上解决了 HTTP/2 中 TCP 队头阻塞和连接迁移的难题。

HTTP 协议演进

Fri, 14 Aug 2026 10:40:00 +0800

HTTP（HyperText Transfer Protocol）是 Web 的基石。从 HTTP/1.0 到 HTTP/2，每一次演进都解决了前一代的核心痛点。

一、HTTP/1.0 的问题

1.1 短连接之痛

HTTP/1.0 默认短连接：

GET /a.css ─────→
 ←───── 200 OK + 数据
 (TCP 关闭)

GET /b.js ──────→
 ←───── 200 OK + 数据
 (TCP 关闭)

GET /c.png ─────→
 ←───── 200 OK + 数据
 (TCP 关闭)

问题：每个请求需要独立的 TCP 三次握手，延迟高

1.2 队头阻塞

浏览器同时只能发 6 个并行请求（同域名）：

请求 1 ──────────────→
请求 2 ──────→
请求 3 ────────→
请求 4 ──→
请求 5 ───────────→
请求 6 ─→

第 7 个请求必须等待前 6 个之一完成
→ 即使是小资源，也可能被大资源阻塞

二、HTTP/1.1 改进

2.1 持久连接（Keep-Alive）

Connection: keep-alive

GET /a.css ─────→
 ←───── 200 OK + 数据

GET /b.js ──────→ (复用同一 TCP 连接)
 ←───── 200 OK + 数据

GET /c.png ─────→ (复用同一 TCP 连接)
 ←───── 200 OK + 数据
 (TCP 可选复用或关闭)

// Java HttpURLConnection 启用 Keep-Alive
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestProperty("Connection", "keep-alive");

// 或通过系统属性全局配置
System.setProperty("http.keepAlive", "true");
System.setProperty("http.maxConnections", "10");

2.2 管线化（Pipelining）

HTTP/1.1 Pipelining（理想情况）：

请求 1 ──→
请求 2 ───────→
请求 3 ─────────────→

响应 1 ←── 200 OK
响应 2 ←────── 200 OK
响应 3 ←──────────── 200 OK

问题：响应必须按请求顺序返回（队头阻塞仍存在）
请求 2 的响应很小，但必须等待请求 1 的大响应先返回

2.3 分块传输（Chunked Transfer）

HTTP/1.1 200 OK
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive

1a
 ← 十六进制：26 bytes
<div>First chunk</div>
 ← 结束标记
8
 ← 8 bytes
<div>End</div>
 ← 结束标记
0
 ← 最后一个 chunk

2.4 域名分片

<!-- HTTP/1.1 的 workaround：将资源分散到多个域名 -->
<link rel="stylesheet" href="https://static1.example.com/a.css">
<script src="https://static2.example.com/b.js"></script>
<img src="https://static3.example.com/c.png">

<!-- 浏览器对每个域名可并行 6 个连接，3 个域名 = 18 个并行 -->

三、HTTP/2 革命

3.1 核心特性

特性	说明	解决的问题
二进制分帧	将数据拆分为二进制帧	解析效率更高
多路复用	单个 TCP 连接并行传输多个流	队头阻塞（应用层）
头部压缩	HPACK 算法压缩头部	冗余头部开销
Server Push	服务端主动推送资源	减少往返次数
优先级	流优先级与依赖关系	关键资源优先加载

3.2 二进制分帧层

HTTP/2 帧格式（9 bytes 头部 + 可变负载）：

+-----------------------------------------------+
| Length (24 bits) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-------------+---------------+-------------------------------+
|R| Stream Identifier (31 bits) |
+=+=============================================================+
| Payload (Length bytes) |
+---------------------------------------------------------------+

帧类型：
- HEADERS (0x1): HTTP 头部
- DATA (0x0): 应用数据
- SETTINGS (0x4): 连接配置
- PRIORITY (0x2): 流优先级
- RST_STREAM (0x3): 流终止
- PING (0x6): 保活检测
- GOAWAY (0x7): 连接关闭通知
- WINDOW_UPDATE (0x8): 流量控制

3.3 多路复用

HTTP/2 单个 TCP 连接上的多路复用：

TCP 连接
 │
 ├── Stream 1 (请求首页 HTML) ────────→
 │
 ├── Stream 3 (请求 CSS) ──────→
 │
 ├── Stream 5 (请求 JS) ─────────→
 │
 ├── Stream 7 (请求图片) ───────────────────→
 │
 ←── Stream 3 响应 (完成) ───────
 ←── Stream 1 响应 (完成) ─────────────
 ←── Stream 5 响应 (完成) ───────────
 ←── Stream 7 响应 (完成) ─────────────────────

所有流交错传输，互不影响

3.4 HPACK 头部压缩

静态表 + 动态表 + Huffman 编码

请求 1:
:method: GET → 静态表索引 2
:path: /index.html → 字面量（加入动态表）
:authority: www.example.com → 字面量（加入动态表）
accept: text/html → 字面量（加入动态表）

请求 2（复用动态表）：
:method: GET → 静态表索引 2
:path: /style.css → 字面量（加入动态表）
:authority: www.example.com → 动态表索引 62
accept: text/css → 字面量

请求 3（高度复用）：
:method: GET → 静态表索引 2
:path: /script.js → 字面量
:authority: www.example.com → 动态表索引 62
accept: application/javascript → 字面量

3.5 Server Push

客户端 服务端
 │ │
 │ ── GET /index.html ─→│
 │ │
 │ ←─ /index.html ──────│
 │ ←─ PUSH /style.css ──│ (服务端主动推送)
 │ ←─ PUSH /script.js ──│ (服务端主动推送)
 │ │
 │ 使用推送的资源 │

注意：Push 的资源需客户端同意（SETTINGS_ENABLE_PUSH）
 且可能被缓存或拒绝

四、HTTP 版本对比

特性	HTTP/1.0	HTTP/1.1	HTTP/2
连接	短连接	持久连接	单一连接多路复用
并行	无	6 连接/域	无限流
队头阻塞	严重	存在	应用层消除
头部压缩	无	无	HPACK
服务端推送	无	无	支持
管道化	无	支持（缺陷多）	原生多路复用
二进制	否	否	是
TLS 要求	无	无	事实上必需

五、HTTP/2 的局限

5.1 TCP 层队头阻塞

HTTP/2 多路复用仍受 TCP 制约：

Stream 1 数据包 1 ─────→ (丢失!)
Stream 3 数据包 2 ─────→
Stream 5 数据包 3 ─────→
Stream 7 数据包 4 ─────→

TCP 必须按序确认，丢包后所有 Stream 都需等待重传
→ 应用层多路复用，传输层仍串行

5.2 连接迁移困难

TCP 连接由四元组标识（源IP:源Port, 目IP:目Port）

WiFi → 4G 切换时：
源 IP 改变 → TCP 连接中断 → 需重新建立 HTTP/2 连接

这催生了 HTTP/3 的设计动机

六、协议协商

6.1 ALPN（Application-Layer Protocol Negotiation）

TLS 握手时协商应用层协议：

ClientHello
 + ALPN Extension: ["h2", "http/1.1"]

ServerHello
 + ALPN Extension: "h2"

后续通信使用 HTTP/2

// Java 11+ HTTP Client 自动协商
HttpClient client = HttpClient.newBuilder()
 .version(HttpClient.Version.HTTP_2) // 优先 HTTP/2
 .build();

HttpRequest request = HttpRequest.newBuilder()
 .uri(URI.create("https://example.com"))
 .build();

HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.version()); // HTTP_2

七、总结

协议	核心改进	主要局限
HTTP/1.0	基础请求-响应	短连接，高延迟
HTTP/1.1	Keep-Alive、管线化、分块	应用层队头阻塞
HTTP/2	二进制分帧、多路复用、HPACK	TCP 层队头阻塞、连接迁移难
HTTP/3	基于 QUIC、0-RTT、连接迁移	见下一篇文章

HTTP 的演进是一个不断解决性能瓶颈的过程。HTTP/2 在应用层面消除了队头阻塞，却受制于 TCP 层的可靠性机制，这正是 HTTP/3 选择基于 QUIC（UDP 之上）重写的根本原因。

UDP 协议与组播应用

Fri, 14 Aug 2026 10:39:00 +0800

UDP（User Datagram Protocol）以其无连接、低延迟、轻量级的特性，在特定场景下比 TCP 更加高效。理解 UDP 的适用边界与工程实践，是高并发系统的必备技能。

TCP 协议：连接管理、拥塞控制与可靠性

Fri, 14 Aug 2026 10:38:00 +0800

TCP（Transmission Control Protocol）是互联网最核心的协议之一。它以面向连接、可靠传输、字节流、全双工的特性，支撑了绝大多数网络应用。深入理解 TCP，是成为优秀后端工程师的必经之路。

网络基础与 OSI/TCP-IP 协议栈

Fri, 14 Aug 2026 10:37:00 +0800

理解网络编程的起点是理解协议栈的分层思想。每一层隐藏了底层的实现细节，通过标准化的接口为上层提供服务。

一、OSI 七层模型 vs TCP/IP 四层模型

1.1 分层对照

┌──────────────┬──────────────────────────────────┬──────────────────┐
│ OSI │ 功能 │ TCP/IP │
├──────────────┼──────────────────────────────────┼──────────────────┤
│ 7 应用层 │ HTTP、FTP、SSH、gRPC、WebSocket │ │
│ 6 表示层 │ 数据格式、加密解密、压缩 │ 应用层 │
│ 5 会话层 │ 会话建立、管理、终止 │ │
├──────────────┼──────────────────────────────────┼──────────────────┤
│ 4 传输层 │ TCP、UDP、端口号 │ 传输层 │
├──────────────┼──────────────────────────────────┼──────────────────┤
│ 3 网络层 │ IP、ICMP、路由选择、子网划分 │ 互联网层 │
├──────────────┼──────────────────────────────────┼──────────────────┤
│ 2 数据链路层 │ MAC 地址、以太网、ARP、交换机 │ 网络接口层 │
│ 1 物理层 │ 网线、光纤、无线、比特流传输 │ │
└──────────────┴──────────────────────────────────┴──────────────────┘

1.2 分层数据交换逻辑

发送方 接收方
 │ ▲
 │ Application Data │ Application Data
 ▼ │
┌──────┐ ┌──────┐
│ HTTP │ ← 应用层：HTTP 请求报文 │ HTTP │
├──────┤ ├──────┤
│ TCP │ ← 传输层：Segment（段） │ TCP │
├──────┤ ├──────┤
│ IP │ ← 网络层：Packet（包） │ IP │
├──────┤ ├──────┤
│ ETH │ ← 链路层：Frame（帧） │ ETH │
└──────┘ └──────┘
 │ ▲
 ▼ 物理层传输 │

二、数据封装与解封装

2.1 封装过程

应用层数据（Payload）
 │
 ▼ + TCP Header（20-60 bytes）
传输层段（Segment）
 │
 ▼ + IP Header（20 bytes）
网络层包（Packet）
 │
 ▼ + ETH Header（14 bytes） + ETH Trailer（4 bytes）
链路层帧（Frame）
 │
 ▼ 转化为比特流发送
物理层

2.2 各层 PDU（Protocol Data Unit）

层次	名称	标识	说明
应用层	Data / Message	无	HTTP 请求/响应体
传输层	Segment	Port	TCP 段/UDP 数据报
网络层	Packet	IP 地址	IP 数据报
链路层	Frame	MAC 地址	以太网帧
物理层	Bit	电信号/光信号	比特流

2.3 Wireshark 实际观察

Frame 42: 1514 bytes on wire ← 链路层帧
Ethernet II, Src: aa:bb:cc:dd:ee:ff ← 以太网头部
Internet Protocol Version 4 ← IP 头部
Transmission Control Protocol ← TCP 头部
Hypertext Transfer Protocol ← HTTP 数据

三、IP 协议核心

3.1 IPv4 报文头部

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2 子网划分

// Java 中计算子网
public class SubnetUtils {
 
 public static void main(String[] args) {
 // CIDR 表示法：192.168.1.0/24
 // 网络地址：192.168.1.0
 // 子网掩码：255.255.255.0（前 24 位为 1）
 // 可用主机数：2^(32-24) - 2 = 254
 
 int prefix = 24;
 int hostBits = 32 - prefix;
 int hostCount = (1 << hostBits) - 2; // 减去网络地址和广播地址
 System.out.println("可用主机数: " + hostCount); // 254
 
 // 判断 IP 是否在同一子网
 String ip1 = "192.168.1.100";
 String ip2 = "192.168.1.200";
 String mask = "255.255.255.0";
 
 int network1 = ipToInt(ip1) & ipToInt(mask);
 int network2 = ipToInt(ip2) & ipToInt(mask);
 System.out.println("同子网: " + (network1 == network2));
 }
 
 static int ipToInt(String ip) {
 String[] parts = ip.split("\\.");
 return (Integer.parseInt(parts[0]) << 24)
 | (Integer.parseInt(parts[1]) << 16)
 | (Integer.parseInt(parts[2]) << 8)
 | Integer.parseInt(parts[3]);
 }
}

3.3 IPv6 特点

特性	IPv4	IPv6
地址长度	32 位	128 位
地址数量	约 43 亿	3.4 × 10^38
头部长度	可变（20-60 bytes）	固定（40 bytes）
安全性	IPsec 可选	IPsec 内置
表示格式	点分十进制	冒号分隔十六进制

示例 IPv6 地址：
完整：2001:0db8:85a3:0000:0000:8a2e:0370:7334
压缩：2001:db8:85a3::8a2e:370:7334

四、ARP 协议

4.1 地址解析过程

主机 A（192.168.1.10）需要发送数据给主机 B（192.168.1.20）

1. A 检查 ARP 缓存，无 B 的 MAC 地址
2. A 发送 ARP 请求（广播）:
 "谁的 IP 是 192.168.1.20？告诉 192.168.1.10（MAC: aa:bb:cc:dd:ee:ff）"
3. 所有主机收到请求，只有 B 响应（单播）:
 "我是 192.168.1.20，MAC 是 11:22:33:44:55:66"
4. A 将 B 的 IP-MAC 映射存入 ARP 缓存
5. A 发送数据帧给 B

4.2 Java ARP 操作

// 通过 InetAddress 获取 MAC 地址（平台依赖）
InetAddress addr = InetAddress.getByName("192.168.1.1");
NetworkInterface ni = NetworkInterface.getByInetAddress(addr);
byte[] mac = ni.getHardwareAddress();

// 使用 ProcessBuilder 执行 arp 命令（Linux/macOS）
Process process = new ProcessBuilder("arp", "-a").start();
BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream()));
String line;
while ((line = reader.readLine()) != null) {
 System.out.println(line);
}

五、ICMP 与 Ping

// Java 中使用 ProcessBuilder 执行 ping
public class PingTest {
 
 public static boolean ping(String host, int timeoutMs) throws Exception {
 ProcessBuilder pb = new ProcessBuilder("ping", "-c", "1", "-W", String.valueOf(timeoutMs / 1000), host);
 Process process = pb.start();
 
 boolean finished = process.waitFor(timeoutMs + 1000, TimeUnit.MILLISECONDS);
 if (!finished) {
 process.destroyForcibly();
 return false;
 }
 
 return process.exitValue() == 0;
 }
 
 // 使用 isReachable（基于 ICMP 或 TCP echo）
 public static boolean isReachable(String host, int timeoutMs) throws Exception {
 return InetAddress.getByName(host).isReachable(timeoutMs);
 }
 
 public static void main(String[] args) throws Exception {
 System.out.println(ping("baidu.com", 3000));
 System.out.println(isReachable("baidu.com", 3000));
 }
}

六、MTU 与分片

6.1 MTU（Maximum Transmission Unit）

接口类型	默认 MTU
以太网	1500 bytes
PPPoE	1492 bytes
IEEE 802.11	2304 bytes
回环接口	65536 bytes
Jumbo Frame	9000 bytes

6.2 路径 MTU 发现

发送方 接收方
 │ ─── 发送 DF=1（Don't Fragment）的包 ───→ │
 │ │
 │ ←── 收到 ICMP "Fragmentation Needed" ───│ MTU 只有 1400
 │ │
 │ ─── 发送 1400 bytes 的包 ─────────────→ │
 │ │

// Java Socket 设置 MTU
Socket socket = new Socket();
socket.setReceiveBufferSize(65536);
socket.setSendBufferSize(65536);

// NIO SocketChannel
SocketChannel channel = SocketChannel.open();
channel.socket().setReceiveBufferSize(65536);

七、常用网络工具

工具	用途	示例
ping	测试连通性	`ping -c 4 baidu.com`
traceroute	路由追踪	`traceroute baidu.com`
netstat	查看连接	`netstat -tlnp`
ss	替代 netstat	`ss -tlnp`
tcpdump	抓包	`tcpdump -i eth0 port 80`
Wireshark	图形化分析	分析 pcap 文件
telnet	测试端口	`telnet baidu.com 80`
nc	网络瑞士军刀	`nc -zv baidu.com 80`
curl	HTTP 请求	`curl -v https://api.example.com`
nmap	端口扫描	`nmap -sS 192.168.1.1`

八、总结

层次	核心协议	关键概念
应用层	HTTP/HTTPS、gRPC、DNS	请求/响应、RPC
传输层	TCP、UDP	端口、连接、可靠性
网络层	IP、ICMP、ARP	地址、路由、分片
链路层	Ethernet、Wi-Fi	MAC、帧、交换机

协议栈的分层设计体现了软件工程中"关注点分离"的核心思想。每一层专注于自己的职责，通过标准化的接口与上下层交互，使得整个网络通信系统既灵活又可靠。