计算机网络基础--杂项总结

网络层

IP数据包

IP数据报格式:
在这里插入图片描述
版本:有(IPV4)和(IPV6)两个版本
首部长度:IP报文首部的长度
总长度:首部+数据的长度
生存时间:TTL,防止IP环路,以路由器跳数为单位,当 TTL 为 0 时就丢弃数据报。
协议:下层使用的协议,例如 ICMP、TCP、UDP 等;
源地址,目的地址:源IP,目的IP

Ip地址编址方式

三个历史阶段:
1:分类
2:子网划分
3:无分类

分类:

由两部分组成,网络号和主机号,其中不同分类具有不同的网络号长度,并且是固定的。

IP 地址 ::= {< 网络号 >, < 主机号 >}
在这里插入图片描述

子网划分:

通过在主机号字段中拿一部分作为子网号,把两级 IP 地址划分为三级 IP 地址。

IP 地址 ::= {< 网络号 >, < 子网号 >, < 主机号 >}

要使用子网,必须配置子网掩码。

无分类:

无分类编址 CIDR 消除了传统 A 类、B 类和 C 类地址以及划分子网的概念,使用网络前缀和主机号来对 IP 地址进行编码,网络前缀的长度可以根据需要变化。

IP 地址 ::= {< 网络前缀号 >, < 主机号 >}

CIDR 的记法上采用在 IP 地址后面加上网络前缀长度的方法,例如 128.14.35.7/20 表示前 20 位为网络前缀。

CIDR 的地址掩码可以继续称为子网掩码,子网掩码首 1 长度为网络前缀的长度。

一个 CIDR 地址块中有很多地址,一个 CIDR 表示的网络就可以表示原来的很多个网络,并且在路由表中只需要一个路由就可以代替原来的多个路由,减少了路由表项的数量。把这种通过使用网络前缀来减少路由表项的方式称为路由聚合,也称为 构成超网 。

在路由表中的项目由“网络前缀”和“下一跳地址”组成,在查找时可能会得到不止一个匹配结果,应当采用最长前缀匹配来确定应该匹配哪一个。

ARP地址解析协议

ARP实现由 IP 地址得到 MAC 地址,可以理解为由IP操控,ARP为IP协议提供正确的MAX地址,ARP可以说是在数据链路层,也可以说实在网络层
每个主机都有一个 ARP 高速缓存,里面有本局域网上的各主机和路由器的 IP 地址到 MAC 地址的映射表。
先查本地缓存,没有的话就广播,然后将结果存入缓存

ICMP 网际控制报文协议

ICMP 是为了更有效地转发 IP 数据报和提高交付成功的机会。它封装在 IP 数据报中,但是不属于高层协议。
在这里插入图片描述
ICMP 报文分为差错报告报文和询问报文。
因为IP协议并不是一个可靠的协议,返回IP报文在传输过程中产生的错误,可以这么理解,ICMP用于IP连接前的探测工作,他不需要端口号,只需要IP。

ICMP的应用

Ping是ICMP的一个非常重要的应用,用来测试两台主机之间的连通性

Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文,目的主机收到之后会发送 Echo 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

传输层

TCP和UDP的特点

**UDP:用户数据包协议;**无连接,不可靠传输,尽最大努力交付数据,没有拥塞控制,面向报文(对应用层传下来的数据直接封装UDP首部传输),支持一对一,一对多,多对一,多对多多种方式
TCP:传输控制协议:面向连接,提供可靠传输,有拥塞控制,有流量控制,面向字节流(对应用层传下来的数据看成字节流,可以组成大小不等的数据块,顺序传输),仅支持一对一的传输方式。

报文格式

TCP

在这里插入图片描述

UDP

在这里插入图片描述

UDP的报文相比TCP的报文结构非常简单 ,这也就是他不可靠的原因了,TCP的首部就占了20字节,而UDP只有8字节,这也就说明UDP可以传输的数据更大,因此大数据一般都用UDP,例如QQ中的文件传输;
但是也是正是因为TCP首部的复杂,他的每一个字段都发挥着重要的作用。

TCP三次握手

在这里插入图片描述
三次握手的过程一定要理解的透彻了,包括状态的改变,每次握手的报文格式,为什么是三次?;三次握手的原因。

三次握手的过程:
在建立连接之前,客户端和服务端都处于Closed状态,当客户端要发起连接时,服务端被动进入LISTEN状态
1)(第一次握手):客户端发起连接【一定是客户端,服务端不会主动发起建立连接的】,进入SYN—SENT状态(连接发起),此时发送的TCP报文,SYN=1,Seq=X(初始序列号)
2)(第二次握手):服务端接受到请求后,发送确认报文,并请求与客户端建立连接,进入SYN-RCVD状态(回复),此时的报文:SYN=1,seq=y,ACK=1(确认tag),ack=x+1(确认序列号)
3)(第三次握手):客户端接收到报文后,发送最后的确认连接报文,并且进入到ESTABLE-LISHED(连接成功)状态,此时的报文:ACK=1(确认tag),seq=x+1;ack=y+1;服务端接受到此报文后,也进入ESTABLE-LISHEd状态
经过这三次握手后,客户端与服务端之间成功建立起TCP连接,就可以互相发送数据了

解决一些问题:

1)三次握手的意义:
首先tcp是可靠传输,传输数据必须建立在连接至上,不能不知道对方能不能接受就直接发过去,这非常不可靠
其次tcp是面向字节流的,他是分组有序的传输,他就是靠序列号来控制顺序的,所以数据传输之前需要互通序列号

2)为什么是三次,两次不行吗?
不行,tcp是全双工的,也就是说双方都会主动给对方发送数据,所以有必要都请求一下对方是否能接受我的数据,我们可以仔细分析一下上面的过程,客户端先请求,服务端回他了,并且请求,到这里我们能确定的就是服务端接受了客户端的连接请求,也就是说服务端告诉客户端我可以接受你的数据了,所以客户端进入了数据传输的状态,服务端还没进入,因为他不知道客户端接不接受,所以必须有这第三次,否则服务端无法向客户端发送数据,就不能完成数据传输,具体参考下面数据传输的过程

四次挥手

在这里插入图片描述

四次挥手的过程:

这里先说明建立连接的时候必须是客户端主动发起连接,但是关闭连接时,客户端和服务端都可以主动发起,我们这里以客户端为例说明
1)客户端主动发起关闭连接报文,从ESTABLE-LISHED状态进入FIN-WAIT1状态,发送的报文是:
FIN=1,seq=x
2)服务端接收到之后,发送确认收到报文进入CLOSED-WAIT状态,报文:ACK=1,seq=v,ack=x+1
3)服务端发送关闭连接报文给客户端,进入LAST=ACK阶段,报文:FIN=1,seq=w
4)客户端接收到这个报文后,发送确认报文,进入TIME-Wait阶段,服务端接受到之后就进入CLOSED
2MSL之后如果客户端没接收到报文就进入CLOASED状态

问题解决

1)为什么服务端接收到之后要进入CLOSE-WAIT状态,而不马上关闭连接呢?
当客户端发起关闭连接的时候只能说明客户端的数据全部发送完了,但是服务端不一定全部接受完了,他需要根据自己接收到的最后一个数据和关闭连接的报文序列号进行比较,确认最后一个数据报文都接受成功了,才会向客户端发起关闭,所以这是一个等待所有数据都传输成功的一个时间
2)客户端第四次挥手的时候为什么不直接进入CLOSED状态?
这是因为,客户端发送最后的报文后,不确定对方能不能成功的接受到,也就是说这个包可能会丢失,所以必须等待一段时间没接收到服务端的重传报文后就进入CLOSED状态(重传下面详细说明)
3)为什么是2MSL?
MSL(MAXIMUM Segment Lifetime)
最大报文的存活时间,一来一去时间足够
4)为什么是四次挥手呢?
还是因为全双工,双方必须都关闭连接

TCP的重传机制

上面介绍tcp的特点时介绍,tcp是可靠连接,怎么就是可靠连接了呢,我们不能只知道表面意思。

之所以可靠,怎么才能定义为可靠,tcp怎么就可靠了,udp就不可靠了呢,我想可靠就是说当我发送一个正确的数据时,使用tcp一定能发送成功,也就是说在没有外界干扰的情况下,不会丢包,哪怕是出现了一点问题他也可以替我解决,而udp呢,求了就丢了,不会对此行为有任何回应。

既然都知道可靠什么意思了,也就能看出tcp的可靠就体现在丢包之后的解决问题上了,这就是要说的tcp的重传机制。

tcp有两种重传机制:超时重传和快速重传机制

超时重传机制

就是他表面的意思,维护了一个计时器,当发送数据后计时器开启,时间到之后如果没收到就认为那个包丢失了,就会发起重传。这种重传机制就是完全依赖时间,一时间为驱动

快速重传机制

不以时间为驱动,一数据为驱动,我们举个例子说明,客户端发送1,2,3,4,5,五个数据包,假如服务端第3个名没收到,所以服务端回的最后一个ack-3,当他还没收到3时,他会继续发送ack=3,当客户端收到三个ack=3的包时,就知道3这个包丢了,他就会重传3这个报,这就是快速重传机制。

快速重传机制解决了超时重传中时间等待的问题,但是两者都有一个问题就是,当知道某一个数据包丢失的时候,是选择重传这一个数据包还是之后的所有数据包,第一个节约带宽,但是速度慢,第二个速度快但是浪费带宽,下面介绍一种更好的解决办法

SACK方法,在TCP报头里添加一个SACK,SACK就是汇报收到的数据碎片

在这里插入图片描述
发送方也不能完全依赖SACK,还是要依赖ACK,并维护Time-Out,如果后续的ACK没有增长,那么还是要把SACK的东西重传,另外,接收端这边永远不能把SACK的包标记为Ack。

由此可见,tcp的过程还是挺复杂的,代价需要深入琢磨一下

TCP的流量控制

tcp是可以进行流控的协议,就是考滑动窗口协议实现的,和tcp报文中的windows字段有关系

窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。

发送方的窗口

这样一来,滑动窗口的引入从概念上将数据分成四部分
在这里插入图片描述

  1. Sent and Acknowledged:这些数据表示已经发送成功并已经被确认的数据,
  2. Send But Not Yet Acknowledged:这部分数据称为发送但没有被确认,数据被发送出去,没有收到接收端的ACK,认为并没有完成发送,这个属于窗口内的数据。
  3. Not Sent,Recipient Ready to Receive:这部分是尽快发送的数据,这部分数据已经被加载到缓存中,也就是窗口中了,等待发送,
  4. Not Sent,Recipient Not Ready to Receive: 这些数据属于未发送,同时接收端也不允许发送的,因为这些数据已经超出了发送端所接收的范围
    而对于发送方来说,窗口内的包括两部分,就是发送窗口(已经发送的,但没有收到ACK的),可用窗口,接收端允许发送的那部分称为可用窗口。

之所以叫他滑动窗口,就是因为当有数据得到回复后,窗口就可以像右滑动,更新窗口中的数据

接收方的窗口

实际上差不多,.接收端也有一个接受窗口,接收端的数据有3个分类,因为接收端并不需要等待ACK所以它没有类似的接受并确认的分类
1) Received and ACK Not Send to Process:接受了的数据,但是还没传给上层应用,还是被缓存在窗口内
2) Received Not ACK:已经接受,还没发送ACK的数据
3)Not Received:有空位,还没有被接受的数据

TCP流量控制

流量控制是为了控制发送方发送速率,保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

Zero Window:

当接收方提供的TCP Siding window为0这时候发送方就不会发送数据,用Zero Window Probe解决问题,发送方会发ZWP的包给接收方,让接收方ack他的Window尺寸,一般会发三次,如果三次都为0,一般就会中断链接。

有上面的了解,我们应该能得出一个结论,就是tcp的滑动窗口是采取的动态调整机制,因为接收端的空窗口不可能一直保持不能变,也就是在这种机制之上就产生了一个问题,就是糊涂窗口综合症。

Silly Window Syndrome

当接收方只有几个字节的空间时,也会告诉发送方,这时候发送方就会义无反顾的吧发送几个字节的数据过来,就造成了一种资源浪费的现象,解释:如果空间较小时,tcp/IP的报头就有40个字节,数据发送的更少了,网络上有一个交MTU,是1500个字节,出去报头字节就剩下1460个字节,这就是MSS(Max Segment Size),这也就是带宽的最大承受能力,所以如果你只发送几个字节,就会浪费带宽
解决这个问题很容易,只要确定一个机制,让接收方的接受能力到达某个值之前,都回复ack(0),这样就不会引起这种问题了

TCP的拥塞控制

如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四个算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。

发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量,注意拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。

为了便于讨论,做如下假设:

1)接收方有足够大的接收缓存,因此不会发生流量控制;
2)虽然 TCP 的窗口基于字节,但是这里设窗口的大小单位为报文段。

慢开始与拥塞避免

发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 …

注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。

如果出现了超时,则令 ssthresh = cwnd / 2,然后重新执行慢开始。

快重传与快恢复

在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。

在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。

在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。

猜你喜欢

转载自blog.csdn.net/LYue123/article/details/89075564
今日推荐