三次握手发生在内核协议栈中，由系统调用connect(2)触发，Java层仅传递参数；四次挥手同样由内核异步完成，close()只关闭文件描述符引用。
Java里Socket连接建立时，三次握手在哪发生？
不在Java代码里显式执行，而是在调用Socket构造函数或connect()方法时由内核触发。JVM只是把参数传给系统调用connect(2)，后续所有SYN/SYN-ACK/ACK交换都发生在内核协议栈中。
常见错误现象：new Socket("example.com", 80)卡住几秒才抛ConnectException——这不是Java在“尝试连接”，是内核在重试SYN超时（默认约21秒，受/proc/sys/net/ipv4/tcp_syn_retries控制）。
- 使用场景：阻塞模式下，
Socket构造函数或socket.connect(addr, timeout)会同步等待三次握手完成；非阻塞需配合Selector和OP_CONNECT - 参数差异：不设timeout时，JVM依赖系统默认超时；设timeout后，Java层会用
poll(2)或select(2)轮询连接状态，但握手本身仍由内核完成 - 性能影响：每次新建
Socket都触发一次完整握手，高频建连（如短连接HTTP）会放大RTT和SYN队列压力
close()调用后，四次挥手为什么没立刻发生？
因为Socket.close()默认只关闭Java端的文件描述符引用，内核TCP连接状态仍可能维持在FIN_WAIT_2、TIME_WAIT等阶段——挥手动作由内核异步驱动，与Java线程无关。
常见错误现象：调用socket.close()后立刻用netstat -tn看到连接处于TIME_WAIT，误以为“没关干净”；或者服务端收到RST而非FIN，说明应用层未正确调用shutdownOutput()就直接close()。
立即学习“Java免费学习笔记（深入）”；
- 使用场景：想主动发FIN，应先调
socket.shutdownOutput()（对应发送FIN），再close()；若跳过前者，内核可能合并FIN+RST或直接丢弃未读数据 - 参数差异：
SO_LINGER设置为{on=true, linger=0}时，close()会触发RST而非FIN，跳过四次挥手 - 兼容性影响：Linux下
TIME_WAIT默认持续60秒（2×MSL），高并发短连接服务容易耗尽本地端口；可通过net.ipv4.tcp_tw_reuse缓解，但不能关tcp_tw_recycle（NAT环境下会出问题）
如何确认某次连接确实完成了三次握手或四次挥手？
Java代码无法直接观测内核的包交互，必须借助外部工具抓包或读取内核状态。靠Socket.isClosed()或isConnected()完全不可靠——它们只反映Java对象状态，不是TCP状态。
常见错误现象：用socket.isConnected() && !socket.isClosed()判断连接“还活着”，结果读到IOException: Connection reset——此时连接早已在内核里断开，Java层只是还没尝试读写。
- 实操建议：调试时用
tcpdump -i any port 8080捕获SYN/FIN包；生产环境可查/proc/net/tcp中对应连接的状态码（如01=ESTABLISHED，08=TIME_WAIT） - 性能影响：频繁调用
getInputStream().read()检测连接是否断开，不如用心跳或Socket.setSoTimeout()配合异常捕获来得轻量 - 注意点：
SocketChannel.close()行为与Socket.close()一致，但NIO的finishConnect()返回true仅表示三次握手完成，不代表对方应用层已准备好收数据
Netty或OkHttp这类框架怎么绕过手动处理握手/挥手？
它们不绕过，而是把内核行为封装成事件回调。比如Netty的channelActive()在三次握手完成后触发，channelInactive()在收到对端FIN或本地进入CLOSE_WAIT后触发——但底层依然依赖相同的connect(2)和close(2)。
常见错误现象：在channelInactive()里立即重建连接，结果遇到Address already in use——因为旧连接还在TIME_WAIT，新连接试图复用相同四元组失败。
- 实操建议：Netty应监听
userEventTriggered()中的SslHandshakeCompletionEvent而非仅靠channelActive()判断TLS就绪；OkHttp的ConnectionPool会自动复用ESTABLISHED连接，但不会强制跳过TIME_WAIT - 兼容性影响：Android 5.0+ 的OkHttp默认启用
connectionSpecs限制TLS版本，可能让某些老服务握手失败，需显式配置兼容列表 - 关键细节：所有框架的“连接池”本质都是持有已通过三次握手的
Socket对象，复用时跳过握手，但每次close()仍会触发四次挥手（除非用SO_LINGER=0）
真正难的是理解：Java里没有“TCP连接对象”，只有对内核socket fd的引用；所有“连接状态”都是内核告诉你的二手信息，且永远有延迟。
