本文共 1150 字，大约阅读时间需要 3 分钟。
转载：
TCP采用下面的方式来提供传输的性能
滑动窗口 快速重传 延迟应答 捎带应答
首先介绍一下TCP的发送缓冲区和接收缓冲区，这是TCP面向字节流的保障 创建一个TCP的socket，同时会在内核中创建一个发送缓冲区和接收缓冲区 调用write时，数据会先写入发送缓冲区中 如果发送的字节数太长，会被拆分成多个TCP的数据包发出 如果发送的数据太短，就会先在缓冲区里等待，等待缓冲区长度差不多了，或者其他合适的时机发送出去 接收数据的时候，数据也是从网卡驱动程序到达内核的接收缓冲区 然后应用程序可以调用read从接收缓冲区拿数据 TCP的一个连接，既有发送缓冲区，又有接收缓冲区，这叫全双工 粘包问题 粘包问题中的包，指的是应用层的数据包 在TCP协议头中，没有UDP一样的报文长度的字段，但有一个序号 站在传输层的角度，TCP是一个报文一个报文传过来的，按照序号排好放在缓冲区中 站在应用层的角度，看到的只是一串连续的字节数据 那么应用层看到这么一串字节数据，就不知道从哪个部分开始到哪个部分是一个完整的应用层数据包 避免粘包问题——明确两个包的边界 对于定长的包, 保证每次都按固定大小读取即可, 从缓冲区从头开始按sizeof()依次读取即可; 对于变长的包，可以在包头位置，约定一个包总长度的字段，从而就知道了包结束的位置（比如HTTP协议中在头部字段中有一个描述body部分长度的字段Content-Length） 对于变长的包，还可以再包和包之间使用明确的分隔符（应用层协议，是程序员自己决定，只要保证分隔符不和正文冲突，比如HTTP协议对于头部和body部分就用一个空行分隔） UDP并不会出现粘包的问题，它是一个一个发送数据包的，不会半个半个这样发。 ———————————————— 版权声明：本文为CSDN博主「TLpigff」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/lvyibin890/article/details/80264655
=============================================================
TCP采用的下面的方式来实现可靠性
确认应答机制（ACK）
超时重传机制
校验和
序列号
连接管理（三次握手四次挥手）
流量控制
拥堵控制
确认应答（ACK）机制
连接成功之后，发送的每条数据都可能丢失，因此就需要确认应答。
TCP将每个字节的数据都进行了编号，即为序列号
每一个ACK都带有对应的确认序列号，意思是告诉之前发送这个数据的发送者，我已经收到了哪些数据，下一次你从哪里开始发