可靠传输，是TCP最核心的特性
可靠传输不是说数据100%传输给接收方了
1）发送方发出数据后，能过知道接收方是否收到数据
2）一旦发现对方没收到，可以通过一定的方法"补救"
1. 确认应答
发送方，把数据已发给接收方后，接收方收到数据就会给发送方返回一个 应答报文（acknowlrdge，ack）
发送方，如果接收到这个应答报文，就知道自己的数据是否发送成功了
发送数据的时候可能会出现"后发先至"的情况------>
一个数据包在进行传输的过程中，走的路径非常复杂，不同的数据包，可能走不通的路线
TCP 此事要完成两个工作：
-
确保应答报文和发出去的数据，不要出现歧义
-
确保在出现先发后至的情况下，能够让应用程序这边仍然按照正确的顺序来理解数据
序号就是一个整数，大小关系描述了数据的先后顺序
序号是按照字节编号的------>TCP是面向字节流的
TCP报头记录的序号，是这一次传输的载荷数据中第一个字节的序号，剩下的序号，都需要一次推出
如图可知，第一次序号为1，第二次为1001，
相当于是1001之前的数据都被接收到了，接下来对端开始索要1001开始的数据
此处通过特殊的ack数据包，里面携带的"确认序号"告诉对方，那些数据已经被确认了
此时发送方，就知道了自己发送的数据到没到
可靠传输------>达成的最核心机制是 确认应答
区分一个数据包是普通的数据，还是ack应答数据报
第二位 ACK
为1，当前数据包是一个应答报文，里面的"确认序号字段"生效
为0，当前数据宝是一个普通报文，里面的"确认序号字段"不生效
2. 超时重传
如果数据包太多了，就会阻塞在一些交换机/路由器上，其中大部分的数据包就被直接丢弃了
确认应答是一个理想的情况，如果网络传输过程中，出现丢包，发送方就无法收到ack
------>使用超时重传，针对确认应答，进行补充
由于丢包是一个随机事件，于是就有两种情况：
- 传输的数据丢了 2. 返回的ack丢了
站在传输方的角度，无法区分这两种情况
无论出现上述那种情况，发送方都会进行"重新传输"
此时，发送方何时重传------>
发送方，在发出数据之后，会先等一段时间，如果这个时间之内，ack来了，就是为数据到达，反之，就会触发重传
初始的等待时间，是可配置的，不同系统上的不一定一样，可以通过修改内核参数来改变
等待是时间，也会动态变化，每多经历一次超时，等待时间就会变长
等待也不是无限拉长的，重传若干次，就会放弃TCP连接（触发TCP重置连接）
等待时间变长，意味着对能正确传输数据是悲观的
如果数据丢了，不会触发ack；如果ack丢了，返回的是ack发送数据的第一个字节（滑动窗口）
返回的ack丢失时，B会收到两条一样的数据------>
TCP会有一个"接收缓冲区"（内存空间），保存当前已经接收到的数据，以及数据的序号
如果接收方发现，当前发送方发来的数据，已经在接收缓冲区中存在（收到重复的数据），接收方就会直接把这个后来的数据丢弃掉，确保应用程序进行read的时候，读到的是只有一条数据
3. 连接管理
建立连接（三次握手）+断开连接（四次挥手） handshake
handshake相当于是打个招呼，没有实际意义，比较简短，是为了引起对方注意
TCP的"握手"，也就是给对方传输一个简短的，没有业务数据的数据包
通过这个数据包，唤起对方注意，从而触发后续的操作
同步报文段------特殊的TCP数据包，没有载荷（不携带业务数据）------>应用层数据包
第五位
为1，表示这个报文是一个同步报文段
为0，则不是
TCP 的三次握手
TCP 在建立连接的过程，需要通信双方一共"打三次招呼"才能建立连接
syn 同步报文段 ack 应答数据报
此时，A和B记录了对方的信息（构成"逻辑"上的连接）
通信过程中，通信双方都要给对方发起syn，也要反馈ack
一共进行四次握手，中间两次可以合并成一次
TCP是为了实现可靠传输
进行确认应答和超时重传有个前提，当前网络环境时基本可用的，通畅的
三次握手的作用：
1）确认当前网络是否畅通
2）要让发送方和接收方都能确认自己的发送能力和接受能力均正常
3）让通信双方在握手过程中，针对一些重要参数进行协商
TCP通信过程中的序号从几开始，就是双方协商出来的（一般不是从1开始）
每次建立连接的时候，都会协商出一个比较大的，和上次不一样得值
有时候网络不太好，客户端和服务器可能
在新的连接建立好后，旧的数据又传输过来断开重连，此时应该直接丢弃------>
如果发现收到的数据序号和当前数据序号差异较大，就可以直接丢弃
此处仅对连接管理机制进行初步介绍，下节将详细介绍连接管理和其他机制