前言
TCP面向连接的特性:三次握手,四次挥手
链接: 三次握手,四次挥手.
可靠传输
确保数据能够安全到达对端,并且保证有序交付
确保数据完整有序到达对端
- 面向连接:确保通信双方都具有数据收发的能力
- 确认应答机制:发送的每一条数据都要求对方进行确认回复,收到确认回复则认为数据安全到达
- 超时重传机制:等待超时后都没有收到数据的确认回复,则认为数据丢失,对这条数据进行重传
- 包序管理:协议字段中的序号和确认序号实现
三次握手阶段,双方都会告诉对方自己的起始序号是多少
序号:告诉对方本条数据起始序号是多少?
确认序号:接收方告诉发送方,确认序号之前的数据都已经收到了,下次就从这个确认序号开始发送数据
数据不一定会按序到达,但是接收方会根据序号进行数据排序,保证有序交付
- 数据一致性校验:基于协议字段中的校验和字段实现,不一致则丢弃要求重传
避免丢包机制
1. 避免因为发送方发送数据过快过多,导致接收方接收缓冲区溢出,数据无处存放直接丢弃的丢包
解决方案:滑动窗口机制—流量控制
滑动窗口机制:接受方每接收到一条数据,就会通过协议字段中的窗口大小字段,告诉发送方最大继续发送多少数据(如果为0表示不要在发送数据)
通常协议字段中窗口大小字段中的值,不会大于当前接收缓冲区中剩余空间大小
滑动窗口机制的实现:通过序号的管理,基于发送窗口后沿序号,发送窗口前沿序号,接收窗口后沿序号,接收窗口前沿序号
后沿移动:
发送窗口:后沿是发送的数据起始序号处,因此收到后沿数据的确认回复,则后沿会向前移动
接收窗口:后沿是接收数据的起始序号处,因此收到了后沿序号的数据,则后沿向前移动
前沿移动:
发送窗口:前沿减去后沿不大于接收方窗口的大小,因此发送窗口的前沿的移动随着接收方的回复的窗口大小而定
接收窗口:前沿减后沿不大于缓冲区剩余空间大小,因此接收窗口的前沿的移动随着缓冲区剩余空间大小而定
滑动窗口机制中的协议:
停等协议:每一条数据收到回复后才会发送下一条,应用于网络状况极差的情况
回退N步协议:从丢包位置开始,往后的数据重新进行传输,用于一般的网络状况
选择重传协议:哪个包丢重传哪一个,用于网络较好的情况
2. 拥塞机制
避免发送数据的时候,一开始,不知道网络情况,万一网络状况不好,发的越多丢的越多--------一种慢启动快增长(指数级的增长)的形式进行数据传输(慢启动就是为了在起始阶段进行网络探测)
提高性能
1.快速重传机制
任意一条数据丢失,发送方都需要等待一个超时之后才会进行重传,效率较低;因此接收方若是在前边数据没有收到的情况下,收到了后边的数据,则认为前边的数据有可能丢失,则直接要求发送方对前边的数据进行重传.将前边数据的重传请求连续发送三次,发送方收到三次连续的重传请求,则对数据进行重传
连续三次重传请求才会重传:为了避免数据并没有丢失,只是延迟到达
2.捎带应答机制
接收方会为每一次收到的数据进行确认回复,但是每一条确认回复都只是报头中的一些信息(有可能每一次回复都是一个单纯tcp报头的传输),如果在进行确认回复的时候,刚好有数据要发送给对方,那就顺便把确认回复信息与发送的数据集成为一条数据进行发送
3.延迟应答机制
当接收方为每一个收到的数据进行回复的时候,大概率这个数据缓冲区中,没有被取出,则窗口会变小,传输吞吐量降低
思想:收到数据之后,稍微延迟一小会,有可能这一小会,上层就取出了数据,这时候窗口大小不变,保持传输吞吐量
面向字节流
提供字节流传输服务-----有序,可靠,基于连接,双向的一种以字节为单位进行传输的方式
区别于面向数据报:数据传输是整条收发,按条交付
优点:传输比较灵活
缺点:会存在粘包问题-----有可能将多条数据当一条数据进行处理
粘包问题
本质:tcp在传输层对数据没有边界管理
影响:上层有可能会将多条请求,当做一条请求进行处理
解决方案:
1.特殊字符间隔:必须对数据中的特殊字符进行转义操作,否则会造成二义
2.数据定长:实际数据较小则需要补位
3.在应用层头部中定义数据长度(先取头部,根据头部中的数据长度取出数据)