目录
应用层->人机交互界面,曹某将“你好”两个字输入电脑微信软件;
表示层->计算机将“你好”翻译成二进制;
会话层->找到接收方马某,建立会话关系;
传输层->曹某用微信发的消息,马某只能在微信上看;
网络层->网络中有许多用户,要想让这两个人准确的发送和接受,曹某需要知道马某的网络层IP;
数据链路层->网络层往下继续传输需要数据链路层的网卡;
物理层->数据变成信号传输,马某在自己微信看到了曹某发的“你好”;
目的是为了简化网络各层的操作,提供标准接口便于实现和维护;
是七层模型的简化版,分为:应用层(应用层,表示层,会话层)->传输层->网络层->网络接口层(数据链路层,物理层);
当客户端向服务端发起连接时,会先发一包连接请求数据(SYN)->syn=1,ack=0,询问服务端能否建立连接,如果服务端同意建立连接,会回复客户端一个(SYN+ACK)->syn=1,akc=1包数据,客户端收到之后,回复一包(ACK)->syn=0,ack=1包,连接建立。
为了防止已失效的请求报文,突然又传到服务器引起错误。
假设用两次握手建立连接,客户端向服务器端发送了一个(SYN)A包,来请求建立连接,因为一些未知的原因A包未到达服务器,在中间某个网络结点产生了滞留,为了建立连接,客户端会重发(SYN)B包,这次B包正常送达,服务端回复(SYN+ACK)之后建立连接,两次握手完成。但是这时候A包阻塞的网络结点突然恢复,A包又送达到服务端,服务端以为客户端又发送了一次连接,在发送完(SYN+ACK)包之后进入等待数据状态。客户端认为是一个连接,但是服务端认为是两个连接,造成了状态不一致问题。
如果用四次握手建立连接,就会导致资源的浪费;
1,客户端主动发起连接关闭请求,它需要向服务端发送一包(FIN)->FIN=1,ACK=0包,表示要关闭连接,自己进入终止等待1状态,这就是第一次挥手。
2,服务端收到(FIN)包,发送一包(ACK)->FIN=0,ACK=1包,表示自己进入了关闭等待状态,客户端进入终止等待2状态,这就是第二次挥手。
3,服务端此时还可以发送未发送的数据,客户端也可以接收数据,等服务端发送完数据之后,发送一包(FIN)->FIN=1,ACK=1包,进入最后确认状态,这就是第三次挥手。
4,客户端收到之后,回复一包(ACK)包,进入超时等待状态,经过超时时间后关闭连接,服务端收到(ACK)->FIN=0,ACK=1包之后立即关闭连接,这就是第四次挥手。
流量控制是为了控制发送方发送速率,保证接收方来得及接收;
接收方每次收到数据包,可以在发送确定报文的时候,同时告诉发送方自己的缓存区还剩余多少是空闲的,我们也把缓存区的剩余大小称之为接收窗口大小,用变量win来表示接收窗口的大小。
发送方收到之后,便会调整自己的发送速率,也就是调整自己发送窗口的大小,当发送方收到接收窗口的大小为0时,发送方就会停止发送数据,防止出现大量丢包情况的发生。
滑动窗口是 TCP 协议用于实现流量控制的一种机制。 发送方和接收方分别维护各自的缓冲区,这个缓冲区就是窗口。发送方的窗口大小由接收方的 TCP 首部的窗口字段决定。
发送方将窗口内容分为:已发送并确认,已发送未确认,未发送未超出接收方窗口范 围,未发送但超出接收方窗口范围。随着接收方的确认,发送方将不断在窗口内向前滑动。
接收方将窗口内容分为:接受已确认,未收到但可以接受。接收方读取窗口内容,并不断确认通知发送方,窗口向前滑动。接收方通过改变窗口大小,可以控制发送方的速率,从而实现流量控制。
拥塞控制就是为了防止过多的数据注入到网络中,控制的目的就是避免发送方的数据填满整个网络,控制 发送方的数据发送量。
目的:用来确定网络的负载能力或拥塞程度
算法思路:由小到大呈指数增大拥塞窗口数值
两个变量:
1)拥塞窗口:
初始拥塞窗口值:2种设置方法
1至2个最大报文段(旧标准)
2至4个最大报文段(RFC 5681)
窗口值逐渐增大
2)慢开始门限
防止拥塞窗口增长过大引起网络拥塞
慢启动每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。 于是,TCP 会设置一个慢启动门限 ssthresh ,当 cwnd >= 门限时,进入拥塞避免,每个轮次 只将 cwnd 加 1 ,降低拥塞窗口的增长速度。
拥塞避免算法一直增长下去,网络也会慢慢进入了拥塞的状况,就会出现丢包现象,这时就需要对丢失的数据包进行重传。当触发了重传机制,也就进入了「拥塞发生算法」
当发生「超时重传」的拥塞发生算法:
ssthresh
设为 cwnd/2
cwnd
重置为 1
这个时候,重新进入慢启动。
当接收方发现数据包丢失的时候,会连续发送三次 ACK
确认数据包,于是发送端就会快速地重传,不必等待超时再重传。
这个时候,TCP
认为这种情况不严重,因为大部分没丢,只丢了一小部分,所以当发生「快速重传」的拥塞发生算法:cwnd = cwnd / 2 ,
ssthresh = cwnd
快速重传和快速恢复算法一般同时使用,快速恢复算法是认为,你还能收到 3
个重复 ACK
说明网络拥塞状况没有特别糟糕,所以没有必要像 RTO 超时重传直接进入慢启动,那么强烈。
拥塞窗口 cwnd = ssthresh + 3
重传丢失的数据包
如果再收到重复的 ACK
,那么 cwnd
增加 1
UDP->写信,TCP->打电话。
这两者本质的区别就是写信是基于非连接的,打电话是基于连接的。
也就是说UDP是基于非连接的,TCP是基于连接的。
可靠传输: TCP 协议通过确认应答、连接管理、流量控制、拥塞控制来确保可靠性传输; UDP 不保证可靠性传输。
性能效率: TCP 协议传输效率慢,需要较多的资源开销。 UDP 协议传输效率快,需要较 少的资源开销。
首部格式: TCP 协议的首部需要 20-60 个字节, UDP 协议需要8个字节。