1. TCP的特点
TCP（Transmission Control Protocol，传输控制协议）是网络编程中最常用的协议之一。它有几个非常鲜明的特点：
1. 有连接：通信前必须先建立连接，就像打电话前要先拨号接通一样；
2. 面向字节流：数据像水流一样连续传输，没有明显的边界；
3. 安全可靠：通过三次握手、四次挥手、应答机制、超时重传机制等，保证数据不丢失、不重复、不乱序；
4. 机制复杂：正因为要保证可靠，所以机制比较多，实时性和效率不如UDP高。
常见的基于TCP的协议有：HTTPS（网页安全传输）、MQTT（物联网消息推送）、FTP（文件传输）等。
简单总结一句话：TCP 牺牲了一部分效率，换来了更高的安全性，它通过各种机制确保数据能完整、有序地到达对方。
2. TCP的三次握手和四次挥手
很多初学者第一次接触TCP，就被"三次握手""四次挥手"这两个词吓到了。别担心，我们一步步来理解。
三次握手（建立连接）：
TCP在建立连接时，需要通过三次握手来确认通信双方都已经准备就绪。你可以把它想象成两个人约见面：
第一次：客户端说"你好，我想和你建立连接"（发送SYN请求）；
第二次：服务端回复"好的，我收到了，我也准备好了"（发送SYN+ACK应答）；
第三次：客户端再说"收到，那我们开始通信吧"（发送ACK确认）。
这样一来，双方都确认了"你能收到我的消息，我也能收到你的消息"，连接就正式建立了。
四次挥手（断开连接）：
TCP断开连接时，需要通过四次挥手来确保双方的数据都已经收发完毕。这就像两个人结束通话：
第一次：客户端说"我要挂电话了，我这边没有数据要发了"（发送FIN请求）；
第二次：服务端回复"好的，我知道了"（发送ACK应答）；
第三次：服务端说"我这边数据也发完了，可以挂了"（发送FIN请求）；
第四次：客户端回复"收到，挂了吧"（发送ACK确认）。
为什么要分四次而不是两次？因为TCP是全双工的，数据可以双向同时传输，所以每一方向都要单独确认"我说完了"。
3. TCP编程的基本流程
了解了理论基础，我们来看看实际编程中TCP是怎么用的。其实流程非常固定，记住下面的调用顺序就可以了：
客户端流程：
socket()（创建套接字）–> connect()（发起连接）–> send()（发送数据）–> recv()（接收数据）–> close()（关闭连接）
服务端流程：
socket()（创建套接字）–> bind()（绑定端口）–> listen()（开始监听）–> accept()（接受连接）–> recv()（接收数据）–> send()（发送数据）–> close()（关闭连接）
connect：客户端发起连接
connect() 是客户端主动向服务端发起连接请求的函数。调用它时，客户端会向服务端发送一个SYN报文，触发我们前面讲到的"三次握手"过程。
简单理解：connect 就是客户端主动"敲门"的动作，告诉服务端"我想和你建立连接"。
listen：服务端开始监听
listen() 是服务端用来开启监听状态的函数。调用它之后，服务端就开始等待客户端的连接请求了。
这里有两个关键点需要初学者注意：
1. 全局只需要生成一个监听套接字，它专门负责监听网卡上的连接请求；
2. listen() 的第二个参数可以指定最大连接等待个数，也就是同时允许多少个客户端在排队等待连接。
你可以把监听套接字想象成前台接待员：他一个人坐在门口，负责登记所有来访的客人（连接请求），然后引导他们去见对应的业务员（处理线程）。
accept：服务端接受连接
accept() 是服务端用来接受客户端连接请求的函数。当有客户端通过 connect() 发起连接时，accept() 会从监听队列中取出一个连接请求，并创建一个新的套接字专门用于和这个客户端通信。
这里有个初学者容易混淆的点：监听套接字和通信套接字是两个不同的套接字。监听套接字只负责"接客"，真正收发数据用的是 accept() 返回的新套接字。
recv：接收数据
recv() 函数用于从套接字中读取对方发送过来的数据。它是阻塞的，也就是说：如果对方还没有发送数据过来，recv() 会一直等待，直到有数据到达才返回。
初学者在使用 recv() 时要注意：一次 recv() 不一定能收到对方一次 send() 发送的全部数据。因为TCP是面向字节流的，数据在传输过程中可能会被拆分或合并，这就是我们后面要讲的"粘包"问题的根源。
最重要的：TCP报文头部信息
要真正理解TCP的各种机制，我们必须先看懂TCP报文头部。TCP报文头部里有很多标志位，每个标志位都代表一个特殊含义。下面是最常用的几个：
TCP报文头部常用标志位：
SYN：请求建立连接标志位（三次握手中用到）
ACK：应答报文标志位（确认收到数据）
PSH：携带数据的报文标志位（告诉对方"这包里有数据，赶紧处理"）
FIN：请求断开连接标志位（四次挥手中用到）
URG：紧急数据标志位（有紧急数据需要优先处理）
RST：重置标志位（连接异常时强制断开）
记忆小技巧：SYN和FIN负责"建立"和"断开"连接，ACK负责"确认"，PSH负责"催收数据"。把这些标志位和前面的三次握手、四次挥手对应起来，就很好记了。
TCP的核心机制：如何确保数据安全可靠地传输
TCP之所以可靠，是因为它有一整套"保险机制"。下面我们逐个来看：
1. 三次握手机制：建立连接前，双方通过三次握手确认彼此都"在线且准备好"，避免出现"我以为你在线，其实你不在"的尴尬情况。
2. 四次挥手机制：断开连接前，双方通过四次挥手确认彼此的数据都收发完毕，避免数据丢失。
3. 应答机制（ACK）：TCP会给发送的每一段数据都编上序号。发送数据时，报文头部的"序列号"就是这包数据中第一个字节的编号；接收方收到后，需要回复一个ACK报文，ACK报文中的"确认号"等于收到的最后一个字节编号+1，表示"你发的我都收到了，下一个请从编号+1开始发"。
4. 超时重传机制：TCP每发送一包数据后，都会启动一个定时器等待对方的ACK应答。如果在超时时间内没有收到应答，TCP就认为这包数据丢了，会自动重新发送一遍。这就是"超时重传"。
5. 滑动窗口机制：TCP在发送端维护一个"窗口"，窗口里保存了三类数据：已发送并收到应答的数据、已发送但还没收到应答的数据、还没发送但对方允许发送的数据。窗口的大小会动态调整，从而实现流量控制。
6. 延迟应答机制：接收方收到数据后，不会立刻回复ACK，而是稍微等一小段时间，如果这段时间内又收到了新的数据包，就可以把多个ACK合并成一个一起回复，减少网络中的ACK报文数量，提高效率。
7. 流量控制机制：TCP会根据接收方的处理能力和缓冲区剩余空间，动态调整自己的发送速率。具体来说，就是根据ACK报文中"窗口值"的大小来调整，窗口值变小就放慢发送速度，避免把接收方"撑爆"。
8. 捎带应答机制：ACK应答报文不一定要单独发送，它可以和应用层要发送的数据一起打包发出。比如接收方在回复ACK的同时，如果正好也有数据要发给对方，就可以把ACK"捎带"在数据报文里一起发出去，节省一个报文的开销。
5. TCP粘包问题详解
终于到了很多初学者最头疼的问题——TCP粘包。别怕，我们把它彻底讲明白。
什么是粘包？
先看一个生活化的例子：假设你往河里倒了一桶水（发送数据），对方在河下游用一个桶接水（接收数据）。因为水是连续的（字节流），对方接到的水其实分不清哪些是你第一次倒的、哪些是你第二次倒的——它们混在一起了。这就是"粘包"。
用专业的话说：TCP粘包，就是发送方发送的多个数据包，在接收方看来变成了一个"粘连"在一起的数据包，导致接收方无法正确区分每一条消息的边界。
为什么会发生粘包？
粘包的根本原因在于TCP是面向字节流的协议，它本身不关心应用层消息的边界。具体来说，主要有两个原因：
1. 发送端的原因（Nagle算法）：TCP默认开启了Nagle算法，它会将多个小的数据包合并成一个大的数据包一起发送，以减少网络中的小报文数量，提高网络利用率。比如你连续调用了三次 send() 发送三条消息，TCP可能把它们合并成一个报文发出去。
2. 接收端的原因（缓冲区合并）：接收方的 recv() 是从内核缓冲区读取数据的。如果发送方连续发送了多条消息，而接收方没有及时调用 recv() 去读取，这些消息就会在接收缓冲区里"排队"，等接收方一次性读取时，多条消息就粘在一起了。
如何解决粘包问题？
既然TCP不帮我们区分消息边界，那我们就自己来定规则。常用的解决方案有以下几种：
方案一：固定长度法
发送方把每条消息都填充成固定长度（比如统一100字节），不足的部分用空格或特殊字符补齐。接收方每次就按固定长度去读取，自然就能切分消息了。缺点是比较浪费带宽，适合消息长度比较固定的场景。
方案二：特殊分隔符法
发送方在每条消息的末尾加上一个特殊的分隔符（比如 \\n 换行符），接收方读到分隔符就认为一条消息结束了。HTTP协议就是用的这种方法（用空行分隔头部和正文）。缺点是如果消息内容本身包含分隔符，就需要做转义处理。
方案三：消息头+消息体法（最常用）
发送方在每条消息前面加上一个固定长度的"消息头"，消息头里记录这条消息体的长度。接收方先读取消息头，解析出消息体长度，再按这个长度去读取消息体，就能精确地切分每一条消息了。这是目前最通用、最可靠的方案。
举个例子，假设我们要发送一条消息"Hello"，可以这样封装：
// 消息头：4字节，记录消息体长度
// 消息体：实际数据
// 发送"Hello"时，先发送 5（长度），再发送 "Hello"（内容）
总结
粘包问题并不可怕，理解了它的成因（字节流无边界 + Nagle算法合并 + 接收缓冲区堆积），再掌握上面三种解决方案，就能轻松应对。在实际项目中，推荐使用"消息头+消息体"的方案，因为它最通用、最可靠，能适应各种消息长度。
到这里，TCP的核心知识就讲完了。从特点、三次握手、四次挥手，到编程流程、核心机制，再到最后的粘包问题，希望这篇入门文章能帮你建立起对TCP的整体认识。如果还有疑问，欢迎在评论区交流讨论！
