TCP协议
传输控制协议（Transmission Control Protocol）:即对数据的传输进行详细控制
特点：
1·有链接
2·可靠运输
3·面向字节流
TCP最核心的机制：
1·可靠传输
2·尽量提高传输效率
（注意两者无法同时兼顾）
一·确认应答（可靠性的核心机制）
序号：按照每个字节的方式来编号
确认序号：当前序号之前的数据已经确认收到，接下来对端该发 送确认序号开始的数据
二·超时重传（可靠的核心机制）和确认应当相辅相成 如果对方没有确认应答，此时间隔一定时间之后就需要重复传输 线同数据，重传是为了进一步降低丢包的可能性重传的间隔时间 采取的是一定的悲观态度，等待时间越来越长。 如果到达一定的次数对方无响应，就断开和对方的连接。 若应答数据包丢失（ACK），同样会超时重传，此时会导致接收方 收到两份相同数据，TCP会根据信号来自东去重。
三·连接管理（可靠性的一部分）（三次握手建立连接） 建立连接的意义 双方先相互试探对方是否适合通信 双方可以协商一些重要数据：序号从几开始
三次握手中(主要)涉及的状态变化：
- List item
LISTEN状态（服务器）：手机开机，信号良好
- ESTABLISHED状态
（客户端/服务器）:电话拨通后对方接听
四次挥手的过程：双方各自向对方发送FIN，再各自向对方发送ACK
中间的两次交互可能合并成一个
状态转换：
- 1·CLOSE_WAIT:
受到第一个FIN的一方进入CLOSE_WAIT，是为了等待代码中调用关闭方法。
- 2·TIME_WAIT：
主动断开连接的一方进入该状态
存在意义：防止最后一个ACK丢包，还有机会重传
TIME_WAIT会存在一定的时间（2MSL），在超出这个时间后，TIME_WAIT才会真正消失，释放对应连接。
MSL表示互联网上任何两点之间传输数据的最大时间（1min）.
四·滑动窗口（提高传输效率）
在确认应答中，一发一收的方式性能较低，一次传输多条数据可以提高性能（将等待时间重叠在一起）
滑动窗口大小：
无需等待确认应答而可以继续发送数据的最大值.即不需要等待任何ACK, 直接发送;
在收到第一个ACK后, 滑动窗口向后移动, 继续发送接下来的数据; 依次类推;
维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据才能从缓冲区删掉;
窗口越大，吞吐率就越高;
窗口不能无限大，否则会影响到可靠性
在这里插入图片描述
五·流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control);
六·拥塞控制
滑动窗口的大小不能无限大，即使接收端处理速度很快，也可能因为网络环境不佳导致数据丢包
最终的滑动窗口是由流量控制和拥塞控制共同决定的
拥塞窗口：拥塞控制机制所建议的窗口大小，从一个比较小的数字开始，若网络通畅，放大窗口大小，如果网络丢包，缩小窗口大小。
滑动窗口的最终值就是流量控制和拥塞控制的较小值
慢开始：刚开始窗口大小较小
七·延迟应答（提高传输效率）;
假设接收端缓冲区为1M. 一次收到了500K的数据; 如果立刻应答, 返回的窗口就是500K;但实际上可能处理端处理的速度很快, 10ms之内就把500K数据从缓冲区消费掉了;在这种情况下, 接收端处理还远没有达到自己的极限, 即使窗口再放大一些, 也能处理过来;如果接收端稍微等一会再应答, 比如等待200ms再应答, 那么这个时候返回的窗口大小就是1M;
不是所有的包都可以延迟应答
八·捎带应答（提高传输效率）
建立在延时应答的基础之上
内核反馈ACK的时机和程序反馈响应的时机合二为一，通过同一个数据报同
时带上两方面信息
九·面向字节流
创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;
调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做全双工。
由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次;
十·粘包问题
由于面向字节流读取数据的方式没有具体的约定，很难从接受缓存区中直接获取到一个完整的应用层数据报。
如何避免粘包问题？
明确两个包之间的边界
TCP最终目标：
1·可靠性（主）
确认应答/超时重传/连接管理/
2·传输效率（次）
滑动窗口/快速重传（流量控制/拥塞控制：保证可靠性不受到影响）
延时应答—捎带应答
粘包问题不是TCP自身的问题，而是面向字节流导致的问题，和应用层代码直接相关。