TCP 是面向连接的可靠字节流协议。三次握手用于建立双方传输状态并同步初始序列号：客户端 SYN，服务端 SYN+ACK，客户端 ACK。双方在连接状态中跟踪发送与接收序列空间，便于后续确认、重传和有序交付。握手不是验证应用账号，也不保证应用服务健康；连接成功只说明传输层建连完成。
TCP 是全双工的，双方发送方向可以独立关闭。典型四次挥手是主动关闭方发送 FIN，对端 ACK；对端处理完剩余数据后发送 FIN，主动关闭方再 ACK。若对端也已准备关闭，ACK 与 FIN 可能合并在一个报文中，所以抓包不一定总看到四个独立报文。FIN 表示发送方不再发送数据，不代表另一方向立即不能继续发送。
可靠传输依靠序列号、确认、校验和及重传等机制。接收方按序列号确认已收到的字节；发送方若在超时前没有收到确认，会根据重传计时器重发未确认数据。出现重复 ACK 等信号时，某些算法会更早重传。网络丢包和乱序可能引起重传及吞吐下降，但应用通常仍看到有序字节流；TCP 不保留应用消息边界。
可靠不等于“永远送达”。网络长期不可达、连接被重置、主机崩溃或重试超出策略后，TCP 会报告失败或超时；应用要处理错误和重连。TCP ACK 也只确认传输层接收情况，不代表对端业务已经提交事务。业务层需要自己的请求 ID、确认语义和幂等设计。不同系统的重传次数与超时参数会变化，不宜背固定秒数。
常见追问
为什么建立 TCP 连接需要三次握手？
双方需要互相确认收发能力并交换初始序列号。第三次 ACK 使服务端确认客户端收到自己的 SYN，减少旧请求等异常状态造成的误建连。
TCP 握手时 SYN 绝对不能带数据吗？
不能如此绝对概括。普通建连通常不依赖 SYN 数据，但扩展和实现可以支持 SYN 数据，例如 TCP Fast Open；数据接受与交付受具体机制约束。第三次 ACK 也可带数据。
为什么挥手常见四次？
双方分别关闭自己的发送方向；收到 FIN 的一侧可以先确认，但仍继续发送剩余数据，之后再发 FIN。某些情况下 ACK 和 FIN 可合并。
TCP 重传成功是否说明业务一定成功？
不是。重传成功说明传输层获得确认，不代表应用完成了业务处理或持久化。客户端超时时也可能出现服务端已执行但响应未到的情况。