前言
本篇博客博主将详细地介绍TCP有关知识点，坐好板凳发车啦~
一.TCP特点
1.有连接
TCP传输的过程中类似于打电话的各个过程
2.可靠传输
通过TCP自身的多种机制来保证可靠传输
3.面向字节流
内容是以字节的方式来进行发送与接收
4.缓冲区
TCP有接收缓冲区，也有发送缓冲区
全双工
5.大小不受限
二.TCP格式
1.源/目的端口号
表示数据是从哪个进程来，到哪个进程去
2.4位TCP报头长度
表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是15*4=60。
3.6位标志位
URG：紧急指针是否有效；
ACK：确认号是否有效；
PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走；
RST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段；
SYN：请求建立连接，我们把携带SYN标识的称为同文报文段；
FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段。
4.16位校验和
发送端填充，CRC校验，接收端校验不通过，则认为数据有问题，此处的检验和不光包含TCP首部，也包含TCP数据部分。
5.16位紧急指针
6.40字节头部选项
三.TCP套接字
3.1ServerSocket API
ServerSocket 是创建TCP服务端Socket的API
3.2Socket API
Socket 是客户端Socket ，或者服务端中接收到客户端建立连接（accept方法）的请求后，返回的服务端Socket。不管是客户端还是服务端Socket，都是双方建立连接以后，保存的对端信息，及时来与对方收发数据的。
四.TCP可靠与效率机制
可靠机制是不能通过代码实现的，这也是TCP最主要实现的功能之一
4.1确认应答（可靠机制）
4.2超时重传（可靠机制）
原因：网络环境非常复杂，在数据的传输过程中会经过很多交换机，路由器，网线，光纤...这些设备不但要传我们的数据，还要传别人的数据，设备的处理能力也是有上限的，如果网络上的数据太多超过了设备的处理能力就会出现拥堵，就像城市里的堵车一样
1.发送超时
2.响应超时
3.超时时间
如果超时时间设的太长，会影响整体的重传效率；
如果超时时间设的太短，有可能会频繁发送重复的包；
故TCP为了保证在任何环境下都能有比较高性能的通信，因此会动态计算这个最大超时时间；
超时重传的时间和重传的次数，是可以能过配置文件手动设置的，不必记忆。
4.3连接管理（可靠机制）
三次握手，四次挥手
4.4滑动窗口（效率机制）
确认应答是对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。存在一个比较大的缺点就是效率比较差。
在这个基础上，一次发送多条数据，然后再等待应答，也就说在等待应答的这段时间里发送发没闲着，用来连续发送数据。
所以我们这里可以考虑两种丢包情况：
1）ACK丢了
2）数据报丢了
滑动窗口与效率
1.效率的高低取决于窗口的大小；
2.窗口越大效率越高；
3.窗口越小效率越低；
4.假设窗口无穷大，此时发送方就完全不需要等待ACK，此时效率就想UDP一样。
4.5流量控制（可靠机制）
在滑动窗口的基础上，接收方对于发送方的反制，接收方根据自己的接收能力来反向影响发送方后面的发送速率，对发送效率做出限制的机制
4.6拥塞控制（可靠机制）
网络中数据传输的过程是非常复杂的，其中可能会经过很多的交换机，路由器等网络设备，每一个网络设备出现问题都会对传输造成影响
2.工作原理
4.7延迟应答（效率机制）
基于流量控制，引入的提高效率的机制
4.8捎带应答（效率机制）
4.9面向字节流
在面向字节流中的一个典型的问题就是“粘包问题”
4.10TCP异常情况
1.程序崩溃
操作系统会回收进程的资源，其中释放包括⽂件描述符表，就想当于调⽤了对应socket的close， 之后触发FIN操作，进⽽开始进⼊四次挥⼿，和普通的四次挥⼿没有区别
2.正常关机 通过开始菜单或执⾏关机命令，系统会强制结所有进程，回收资源，与程序崩溃执⾏的流程类似 3.主机掉电 ⼤多数发⽣的情况 1. 接收⽅掉电 发送⽅并不知道接收⽅挂了，继续发送数据 发送数据后收不到ACK应答，触发超时重传 多次重传都没有收到ACK应答，会尝试进⾏连接重置（RST标识位） 连接重置也失败，只能放弃连接 2. 发送⽅掉电 ⼀般出现在⻓连接中，服务器与客户端会维护⼀个⼼跳包(客户端每隔1秒给服务器发送⼀个数 据包，证明⾃⼰存活) 如果服务器⼀直收不到这个⼼跳包，⽐如过了10秒之后还没有收到，就判定为客户端挂了，⾃ ⾏断开连接 客户端⽹络恢复之后再次进⾏重连即可 4.网线断开 与主机掉电的情况相同，只不过是主机都是正常⼯作的尾语
这篇博客到这里就结束啦，希望可以给大家带来帮助~~
标签：总结,知识点,ACK,应答,TCP,发送,超时,效率 From： https://blog.csdn.net/weixin_66046886/article/details/137148726