1.有连接
2.可靠传输
1）确认应答：TCP的确认应答是确保TCP可靠性最核心的机制
主机B收到了 1- 1000 的字节数据后，返回一个应答报文ack，应答报文中确认序号的只就是 1001
a)1001之前的数据都已经收到了
b) 接下来从 1001 开始发送
TCP的确认应答机制是 确保 TCP可靠性的核心机制
2）超时重传----确认应答的补充
网络传输中，丢包是一个普遍的情况，无法预测哪个报文会丢，发送方如果一段时间之内，没有收到ack，就会视为是丢包----触发重传
TCP socket 在内核中有一块 接收缓冲区，发送方发送来的数据，要先放到接收缓冲区中，然后程序调用 scanner方法读取缓冲区，才能读到数据
3）自动去重
接收方如何判断是否是重复数据？
1.如果数据还存在接收缓冲区，还没被读取
此时将收到的数据的序号，和缓冲区终端所有数据的序号一一对应，查看是否有重复的，如果有重复的就可以把新收到的数据丢弃；
2.数据在接收缓冲区，已经被程序读取了
程序读取缓冲区数据时是按照 先后顺序读取的：1-100，101-200，201-300.....
此时如果新收到的数据是 1-100，但已经被读取过了，就会判定这个数据包为重复的包；
超时重传策略
超时是会重传，但重传也不是无限制的重传，
1.重传次数是有上限的，重传到一定程度，还没有收到 ack 就尝试重置连接，如果重置也失败，就直接放弃连接
2.重传的超时时间也不是固定不变的，随着重传次数的增加而增大（重传频率越来越低）
以上是 TCP可靠性传输最核心的机制；
4）连接管理
当主机之间建立TCP连接时，内核时如何建立的呢？
通过"三次握手"建立连接，目的时让通信双方保存对方的信息
syn：数据包，不懈怠载荷，没有应用层的数据，也不代表任何程序的业务逻辑，但是带有IP报头/以太网数据帧帧头/TCP报头，只是一个打招呼的作用----称为"握手"；
连接过程：通信双方各自给对方发起一个 syn 各自给对方回应一个 ack（客户端），等所有握手环节完成，服务器才会保存客户端的相关信息
网络传输过程要涉及到多次的 封装 和 分用 ，所以将syn + ack' 合并成一次，成本就降低了
三次握手的意义
1.针对通信路径初步确认一下通信链路是否通畅（可靠性的前提）
2.验证通信双方的发送和接收能力是否正常
为什么必须时三次握手？四次/两次可以吗？
四次可以，但网络IO开销大
两次不可以，服务器不能确认自己和对方的发送和接收功能是否正常；
断开连接，四次挥手
连接本质上，就是让通信双方保存对方的信息，每个客户端/服务器。都要保存很多的对端信息，一旦保存的多了，就需要使用"数据结构"断开连接的本质：把对端的信息从数据结构中删除掉；
四次挥手是建立在双方都同意的基础上，对于单方面强制，就不适用；
socket.close()触发 fin 数据报，通信双方各自给对方发起 fin 再各自给对方发送 ack；四次挥手代表"和平分手"
如果实际通信中，ack 和 第二个 fin 时间间隔比较长 此时就无法合并 fin + ack
四次挥手和三次握手比较
相同点
都是通信双方给对方发送一个 syn/fin，各自给对方返回 ack
不同点
三次握手中间两次一定能合并，四次挥手则不一定
三次挥手必须是 客户端主动，四次挥手--客户端/服务器都可以主动
fin时通过 close 触发的，主动调用，服务器挂了都会触发 四次挥手
连接管理中的 TCP状态转换过程
一.TCP连接状态
LISTEN状态：服务端一创建 serverSocket 并绑定端口，处于监听连接请求状态
ESTABLISHED状态：客户端和服务端 完成 三次握手，连接客户端与服务端已完成握手
二：TCP断开流程状态
服务端主动断开：
1.客户端发 fin -->进入 FIN_WAIT_1;
2.服务端接收 fin -->回复 ack --服务端进入 CLOSE_WAIT，客户端进入 FIN_WAIT_2
3.服务端调用 close（）发 FIN-->客户端进入 LAST_ACK
4.客户端收FIN，会ACK-->客户端进入 TIME_WAIT，服务端收 ACK 后进入 CLOSED
5.客户端 TIME_WAIT 超时-->进入CLOSED
滑动窗口
确认应答机制下
每次发送发收到一个 ack 才会发送下一条数据
导致大量的时间都消耗在等待 ack上
为了解决这样上述问题，滑动窗口就可以在保证可靠性传输的基础上，提高效率
引入了滑动窗口，批量发送数据
之前发送了一个数据等待一个ack，才发送下一个数据
现在 先发送一个数据，不等 ack，会继续发送下一条数据
连续发送了一定数据之后，统一等待 ack
只要收到一个 ack 就可以 滑动窗口，继续发送新数据
滑动窗口出现丢包怎么办
1.ack丢失
TCP累计确认机制
1.定义：接收方回复哪一条数据的确认号，就表示该确认好之前的所有数据都已经收到
2.场景：客户端向服务器发送 1-100，101-200，201-300，如果只回复了 201就说明 1-200都收到了；
2.数据丢失
数据丢失时，所有接收到的数据都会存储在 服务器 的缓冲区中，依次拍好，服务器会重复返回丢失的数据 的确认号，当客户端收到好几个相同的确认序号，就知道这一条数据丢失，进行重传，只会索要丢失的数据，这种情况称为 "快速重传"