计算机网络-传输层
作者:互联网
传输层
文章目录
一、UDP和TCP的特点
1.UDP特点
用户数据报协议是面向无连接的,尽可能大交付,没有拥塞控制,面向报文( 对于应用程序传下来的报文不合并也不拆分)支持一对一、一对多、多对多和多对一的交互通信。
2.TCP特点
传输控制协议是面向连接的,面向可靠交付,有流量控制,拥塞控制,提供双全工通信,面向字节流(把应用层传下来的报文堪称字节流,把字节流组织成大小不等数据报),每一条TCP链接只能是点对点的(一对一)。
二、UDP首部格式
首部字段只有源端口、目的端口、长度、检验和。12字节的伪首部是为了计算校验和临时添加的。
三、TCP首部格式
1. 序号:用于对字节流进行编号,例如序号301,表示第一个字节的编号为301,如果携带的数据长度为100字节,那么下个报文的编号应该是401。
2. 确定号:期望收到的下一个报文段的序号。例如B收到了A发送过来的报文段,序号为501,那么下一个报文的期待值是701,那么B会向A发送701的确认号。
3. 数据偏移:指的是数据部分距离数据报文段起始位置的长度,实际上就是首部的长度
4. 确定ack:当ACK为1 时,确认号字段有效,否则无效。TCP规定,在链接确认后所有链接传送的报文段都必须把ACK置为1
5. 同步SYN:在链接建立时用来同步序号。当SYN=1,ACK=0时表示这是一个连接请求报文段。若对方同意建立链接,那么syn=1,ACK=1.
6. 终止FIN:用来释放一个链接,当FIN=1时,表示此报文段的发送方的数据已发送完毕,并要求释放链接。
7. 窗口:窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制,是因为接收方的数据缓存空间是有限的。
四、TCP三次握手
假设A为客户端,B为服务端
- 首先B服务器处于监听状态,等待客户端链接请求
- A向B发送请求报文,SYN=1,ACK=0,选择初始序号x.
- B收到链接请求报文,如果同意链接,会向A发送链接确认报文,SYN=1,ACK=1,确认号x+1,同时也选择一个初始号y
- A 收到 B 的连接确认报文后,还要向 B 发出确认,确认号为 y+1,序号为 x+1。
- B 收到 A 的确认后,连接建立。
五 TCP三次握手原因
三次握手是为了防止失效的链接请求到达服务器,让服务器错误打开链接
客户端发送的链接请求如果在网络中滞留,且客户端等待一个超时重传时间之后会重新发送链接请求。也就是现在发送了两个链接请求,如果没有存在第三次握手,这两个链接就一直存在。如果有第三次握手,服务端其中一个链接发送给客户端时候就会建立链接,而这时客户端就会忽略服务端发送的网络滞留的链接的请求。
5.1 TCP的四次挥手释放连接
- A发送链接释放报文,FIN=1
- B收到之后发送确认,此时TCP属于半关闭状态进行CLOSE WAIT状态,B能给A发送数据但是A不能向B发送数据。
- 当B不再需要链接时,发送链接释放报文,FIN=1
- A收确认后进行time wait状态,等待2MSL(最大报文存活时间)后释放链接
- B收到A的连接确认之后释放连接
.
5.2 四次挥手的原因
客户端发送了FIN连接释放报文之后,服务器收到这个报文,就进入了CLOSE-WAIT状态。这个状态是为了让服务端发送还未传送完毕的数据,数据发送完毕之后,服务器会发送FIN连接释放报文。
TIME_WAIT
客户端收到服务端的FIN信号后,并不会立即断开连接,而是等待一个计时器的设置的时间2MSL。有两个原因:
- 确保最后一个报文能到达,如果B没收到A发送来的确认报文,那么就会重新发送释放请求报文,A等待一段时间就是为了处理这种情况的发生
- 等待一段时间是为了本链接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文
六 TCP可靠传输
TCP使用超时重传实现可靠传输:如果一个发送的数据包在超时时间还没收到确认,那么重传这个数据报文段。一个报文段从发送再到接收确认所经过的时间叫往返时间RTT,加权平均往返时间RTTS计算时间如下:
其中,0 ≤ a < 1,RTTs 随着 a 的增加更容易受到 RTT 的影响。
超时时间 RTO 应该略大于 RTTs,TCP 使用的超时时间计算如下:
其中 RTTd 为偏差的加权平均值。
七 TCP滑动窗口
- 窗口是缓存的一部分,用来暂时存放字节流,发送方和接收方各有一个窗口,接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口的大小,发送方根据这个值和其他信息设置自己的窗口大小。
- 发送窗口内的字节都允许被发送,接受窗口的所有数据都允许接受和确认。当窗口内的数据已收到已确认,这时候窗口就会移动直到左部第一个数据不是已收到已确认。接收窗口的滑动类似,接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口。
- 接收窗口只会对窗口内最后一个按序到达的字节进行确认,例如接收窗口已经收到的字节为{31,34,35}其中{31}按序到达,而34,35不是,因此只对字节31进行确认,发送方得到一个字节的确认之后就知道这个字节之前的所有字节都已经被接受。
八 TCP流量控制
流量控制是为了控制发送方发送速率,保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
九 TCP拥塞控制
如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络中拥塞成都更高。因此当出现拥塞时,应当控制发送方的速率。这和流量控制很相似,但是流量控制是为了接收方来得及接受,而拥塞控制是为了降低整个网络的拥塞程度。
- TCP主要是通过四个算法来控制:慢开始、拥塞控制、快重传、快恢复
- 发送方需要维护一个叫做拥塞窗口的状态变量,注意拥塞窗口与发送窗口的区别:拥塞窗口只是一个 状态变量,实际发送方能发送多少数据是发送方窗口。
假设:
- 接收方有足够大的接受缓存,因此不会发生流量控制
- 虽然TCP的窗口基于字节,但是这里设窗口的大小单位为报文段
9.1 慢开始与拥塞避免
- 发送的最开始,令cwnd=1,发送方只能发送一个报文段;当收到确认后,将其加倍,因此之后发送方能发送的报文段数量为:2、4、8
- 每个轮询都将cwnd加倍,这样会让其增长速度非常快,从而使得发送方发送的速度增长过快,网络拥塞的可能性也就更高。设置一个慢开始门限ssthresh,当cwnd>=ssthresh时,进入拥塞避免,每个轮询只加1。
- 如果出现了超时,则令ssthresh = cwnd / 2,然后重新执行慢开始。
9.2 快重传与快恢复
- 在接受方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经收到M1和M2,这时收到M4,应当发送M2确认。
- 在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失。此时执行快重传,立即下一个报文段,例如收到三个M2,则M3丢失,立即重传。
- 这种情况下只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。
- 慢开始和快恢复的快慢指针指的是cwnd的设定值,而不是cwnd的增长速率。慢开始cwnd设定为1,而快恢复cwnd设定为ssthresh。
标签:发送,窗口,报文,TCP,计算机网络,拥塞,传输层,链接 来源: https://blog.csdn.net/weixin_46003987/article/details/122340213