笔记----就是用来日后再次学习+查看的
TCP
- tcp设计原则
网络数据传输,在保证安全的前提下,尽可能的提高传输效率
- 安全越高,效率越低
安全越低,效率越高-------->UDP效率比TCP更高
ACK:确认号是否有效
SYN:请求建立连接,把携带SYN标识的称为同步报文段
FIN:通知对方,本端要关闭了.称携带FIN表示的结束报文段
- TCP的安全机制
(1)确认应答机制
(2)超时重传机制
(3)连接管理机制
- 三次握手的流程
为什么是三次?
第二次服务端返回SYN和ACK,是可以合并的(只是标志位设置就行)
- 四次挥手的流程(关闭连接)
解释上图中四次挥手流程(右边):
CLOSE_WAIT :系统内核对tcp协议实现的方式:接收到客户端FIN后,自动返回ACK
LAST_ACK :程序手动调回close方法关闭连接
CLOSE_WAIT :
一般而言,对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成.
这是一个 BUG. 只需要加上对应的 close 即可解决问题
(1)第三步,客户端没有直接设置为CLOSED关闭连接?
第四步的ACK可能丢包,所以要等待一下(超时重传时间)
(2)为什么第二步和第三步,没有像建立连接时,合并数据包
第二步是系统对TCP协议实现时,接收FIN,自动返回ACK,不用执行程序代码
第三步是程序手动调用执行(服务端关闭连接前,需要执行一些前置工作)
- TCP提高效率的机制
- 滑动窗口
作用并行的发送数据报,提高网络数据传输效率
窗口大小无需等待确认应答而可以继续发送数据的最大值
(发送端,接收到的ack确认序号的最大值,下一个是多少)
受限于流量控制窗口大小和拥塞窗口大小=min(流量窗口大小,拥塞窗口大小)
滑动接收到ack确认序号的最大值,可以计算出多少段数据对方已经接收
到,对应的发送端滑动窗口,就向下滑动多大
客户端和服务端都存在接收缓冲区和发送缓冲区(每一端都有2个缓冲区)
发送缓冲区,记录了发送数据的序号,和接收ack应答的序号
接收缓冲区,记录了接收数据的序号,应答ack的序号
- 延迟应答
作用接收端稍等一定的时间再应答.这样程序可以有时间消费掉接收缓冲区的数据,接收缓冲区剩余区间就更大.返回的流量窗口大小就更大
延迟的条件
时间限制:超过最大延迟时间就应答一次
数量限制:每隔N个包就应答一次 - 捎带应答
- TCP安全,可靠性机制
- 流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制 - 拥塞控制
作用发送端不清楚网络状态时,采取慢启动机制,先探路,在决定发送数据的速度
拥塞窗口窗口大小,标识发送端网络状态(刚开始拥塞窗口大小=1,以先慢后快(2的指数曲线)增长方式变大,到达阈值后,变为线性增长,最终达到网络拥塞(大量丢包)后,窗口大小重置=1,重复以上过程) - 确认应答
- 超时重发
- 连接管理
- 黏包问题
黏包问题:应用层的数据包
如何避免粘包问题? 明确两个包之间的边界
类似在线编程题,多组测试用例时,输入和输出,每一组用例的输入和另一组用例输入,要分隔开
TCP是基于字节流的,多条数据报在缓冲区.UDP是一次发,一次读,不存在粘包问题
TCP小结
- TCP的特性/机制:
- 安全可靠性机制
(1)确认应答
(2)超时重发
(3)连接管理
(4)流量控制
(5)拥塞控制 - 提高效率的机制
(1)滑动窗口
(2)延迟应答
(3)捎带应答
- 基于TCP的应用层协议:HTTP HTTPS
TCP和UDP区别
没有哪个更好,只有在某个具体的业务场景中,选择更适合使用的
如果要满足安全可靠(包括次序),就可以使用TCP, 反之,可以使用UDP
(1)效率看,UDP更优.(不用等待ACK应答)
(2)UDP是无连接,不可靠的. 反之,TCP有连接,可靠的传输
(3)UDP是面向数据报,只能一次发送和一次接收.TCP是面向字节留的,可以多次收发
(4)UDP具有接收缓冲区,没有发送缓冲区,TCP则都有
(5)UDP 大小受限,TCP不限制
(6)TCP以确认应答、超时重发、连接管理、流量控住、拥塞控制等五个机制保证安全可靠传输