计算机网络常用知识总结！（二）

计算机网络常用知识总结！（一）https://developer.aliyun.com/article/1624409

报文段

TCP虽面向字节流，但传送的数据单元为报文段

报文段 = 首部 + 数据2部分

TCP的全部功能体现在它首部中各字段的作用

❝

0. 首部前20个字符固定、后面有4n个字节是根据需而增加的选项
1. 故 TCP首部最小长度 = 20字节

❞

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c6gjlcyl-1651310391022)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

「端口」：

源端口号和目地端口各占16位两个字节，也就是端口的范围是2^16=65535

另外1024以下是系统保留的，从1024-65535是用户使用的端口范围

「seq序号」：占4字节，TCP连接中传送的字节流中的每个字节都按顺序编号。

例如：一段报文的序号字段值是107，携带的数据是100个字段，下一个报文段序号从107+100=207开始。

「ack确认号」：4个字节，是期望收到对方下一个报文段的第一个数据字节的序号。

例如：B收到A发送的报文，其序号字段是301，数据长度是200字节，表明B正确收到A发送的到序号500为止的数据（301+200-1=500），B期望收到A下一个数据序号是501，B发送给A的确认报文段中把ack确认号置为501。

「数据偏移」：头部有可选字段，长度不固定，指出TCP报文段的数据起始处距离报文段的起始处有多远。

「保留」：保留今后使用的，被标为1。

「控制位」：由8个标志位组成。每个标志位表示一个控制功能。

其中主要的6个：

• 「URG紧急指针标志」，为1表示紧急指针有效，为0忽略紧急指针。
• 「ACK确认序号标志」，为1表示确认号有效，为0表示报文不含确认信息，忽略确认号字段，上面的确认号是否有效就是通过该标识控制的。
• 「PSH标志」，为1表示带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将该报文段交给应用程序，而不是在缓冲区排队。
• 「RST重置连接标志」，重置因为主机崩溃或其他原因而出现错误的连接，或用于拒绝非法的报文段或非法的连接。
• 「SYN同步序号」，同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。。
• 「FIN终止标志」，用于释放连接，为1时表示发送方没有发送了。

「窗口」：滑动窗口大小，用来告知发送端接收端缓存大小，以此控制发送端发送数据的速率，从而达到流量控制。

「校验和」：奇偶校验，此校验和是对整个的TCP报文段（包括TCP头部和TCP数据），以16位进行计算所得，由发送端计算和存储，接收端进行验证。

「紧急指针」：只有控制位中的URG为1时才有效，指出本报文段中的紧急数据的字节数。

「选项」：其长度可变，定义其他的可选参数。

粘包与拆包

TCP是面向字节流的协议，把上层应用层的数据看成字节流，所以它发送的不是固定大小的数据包，TCP协议也没有字段说明发送数据包的大小。

而且TCP不保证接受方应用程序收到的数据块和发送应用程序发送的数据块具有对应的大小关系

比如发送方应用程序交给发送方TCP 10个数据块，接受方TCP可能只用了4个数据块就完整的把接受到的字节流交给了上层应用程序。

TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题

「TCP粘包/拆包解决策略」

由于TCP无法理解上一层的业务数据特点，所以TCP是无法保证发送的数据包不发生粘包和拆包，这个问题只能通过上层的协议栈设计来解决，解决思路有一下几种：

• 消息定长：每个发送的数据包大小固定，比如100字节，不足100字节的用空格补充，接受方取数据的时候根据这个长度来读取数据
• 消息末尾增加换行符来表示一条完整的消息：接收方读取的时候根据换行符来判断是否是一条完整的消息，如果消息的内容也包含换行符，那么这种方式就不合适了。
• 将消息分为消息头和消息尾两部分，消息头指定数据长度，根据消息长度来读取完整的消息，例如UDP协议是这么设计的，用两个字节来表示消息长度，所以UDP不存在粘包和拆包问题。

三次握手

「第一次握手」：

客户端将TCP报文标志位SYN置为1，随机产生一个序号值seq=J，保存在TCP首部的序列号字段里，指明客户端打算连接的服务器的端口，并将该数据包发送给服务器端，发送完毕后，客户端进入SYN_SENT状态，等待服务器端确认。

「第二次握手」：

服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将TCP报文标志位SYN和ACK都置为1，ack=J+1，随机产生一个序号值seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。

「第三次握手」：

客户端收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

「上面写的ack和ACK，不是同一个概念：」

• 小写的ack代表的是头部的确认号Acknowledge number， 缩写ack，是对上一个包的序号进行确认的号，ack=seq+1。
• 大写的ACK，则是我们上面说的TCP首部的标志位，用于标志的TCP包是否对上一个包进行了确认操作，如果确认了，则把ACK标志位设置成1。

「TCP为什么三次握手而不是两次握手」

• 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
• 如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认

「《计算机网络》中是这样说的：」

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

❝

在书中同时举了一个例子，如下：

❞

假如client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server，本来这是一个早已失效的报文段，但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。

于是就向client发出确认报文段，同意建立连接，假设不采用**「三次握手」**，那么只要server发出确认，新的连接就建立了，由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。

但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了。

采用**「三次握手」**的办法可以防止上述现象发生，例如刚才那种情况，client不会向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接。

「什么是半连接队列」

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为**「半连接队列」**。

当然还有一个**「全连接队列」**，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

补充一点关于**「SYN-ACK 重传次数」**的问题：

服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

「三次握手过程中可以携带数据吗」

其实第三次握手的时候，是可以携带数据的，也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN  报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN  报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。

而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据没啥毛病。

四次挥手

挥手请求可以是Client端，也可以是Server端发起的，我们假设是Client端发起：

• 第一次挥手：Client端发起挥手请求，向Server端发送标志位是FIN报文段，设置序列号seq，此时，Client端进入FIN_WAIT_1状态，这表示Client端没有数据要发送给Server端了。
• 第二次挥手：Server端收到了Client端发送的FIN报文段，向Client端返回一个标志位是ACK的报文段，ack设为seq加1，Client端进入FIN_WAIT_2状态，Server端告诉Client端，我确认并同意你的关闭请求。
• 第三次挥手：Server端向Client端发送标志位是FIN的报文段，请求关闭连接，同时Client端进入LAST_ACK状态。
• 第四次挥手 ：Client端收到Server端发送的FIN报文段，向Server端发送标志位是ACK的报文段，然后Client端进入TIME_WAIT状态，Server端收到Client端的ACK报文段以后，就关闭连接，此时，Client端等待2MSL的时间后依然没有收到回复，则证明Server端已正常关闭，那好，Client端也可以关闭连接了。

「为什么连接的时候是三次握手，关闭的时候却是四次握手？」

建立连接时因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。所以建立连接只需要三次握手。

由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双工模式。

这就意味着，关闭连接时，当Client端发出FIN报文段时，只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段，表示它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会立即关闭SOCKET，直到Server端把数据也发送完毕。

当Server端也发送了FIN报文段时，这个时候就表示Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

「为什么TIME_WAIT要等待2MSL？」

MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。

有以下两个原因：

• 第一点：保证TCP协议的全双工连接能够可靠关闭：由于IP协议的不可靠性或者是其它网络原因，导致了Server端没有收到Client端的ACK报文，那么Server端就会在超时之后重新发送FIN，如果此时Client端的连接已经关闭处于CLOESD状态，那么重发的FIN就找不到对应的连接了，从而导致连接错乱，所以，Client端发送完最后的ACK不能直接进入CLOSED状态，而要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确关闭连接。
• 第二点：保证这次连接的重复数据段从网络中消失 如果Client端发送最后的ACK直接进入CLOSED状态，然后又再向Server端发起一个新连接，这时不能保证新连接的与刚关闭的连接的端口号是不同的，也就是新连接和老连接的端口号可能一样了，那么就可能出现问题：如果前一次的连接某些数据滞留在网络中，这些延迟数据在建立新连接后到达Client端，由于新老连接的端口号和IP都一样，TCP协议就认为延迟数据是属于新连接的，新连接就会接收到脏数据，这样就会导致数据包混乱，所以TCP连接需要在TIME_WAIT状态等待2倍MSL，才能保证本次连接的所有数据在网络中消失。

流量控制

「RTT和RTO」

RTT：发送一个数据包到收到对应的ACK，所花费的时间

RTO：重传时间间隔（TCP在发送一个数据包后会启动一个重传定时器，RTO即定时器的重传时间）

开始预先算一个定时器时间，如果回复ACK，重传定时器就自动失效，即不需要重传；如果没有回复ACK，RTO定时器时间就到了，重传。

RTO是本次发送当前数据包所预估的超时时间，RTO不是固定写死的配置，是经过RTT计算出来的。

「滑动窗口」

TCP的滑动窗口主要有两个作用：

0. 保证TCP的可靠性
1. 保证TCP的流控特性

TCP报文头有个字段叫Window，用于接收方通知发送方自己还有多少缓存区可以接收数据，发送方根据接收方的处理能力来发送数据，不会导致接收方处理不过来，这便是流量控制。

发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。

发送窗口和接收窗口的序号的上下界不一定要一样，甚至大小也可以不同。

不同的滑动窗口协议窗口大小一般不同。

发送方窗口内的序列号代表了那些已经被发送，但是还没有被确认的帧，或者是那些可以被发送的帧

滑动窗口由四部分组成每个字节的数据都有唯一顺序的编码，随着时间发展，未确认部分与可以发送数据包编码部分向右移动，形式滑动窗口

0. 绿色：发送成功并已经ACK确认的数据
1. 黄色：发送成功等待ACK确认的数据(占用滑动窗口大小)
2. 紫色：滑动窗口剩余大小可以发送的字节数量(滑动窗口可用大小)
3. 灰色：后续数据编码

接收窗口的大小就是滑动窗口的最大值，数据传输过程中滑动窗口的可用大小是动态变化的。

但是还有这么一点，滑动窗口的设计仅仅是考虑到了处理方的处理能力，但是没有考虑到道路的通畅问题

就好像服务端可以处理100M数据，但是传输的数据99M都堵在路上了，这不就是导致道路阻塞了么？这就需要另外一个设计**「拥塞避免」**

「流量控制的目的」

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。

为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。

流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

「如何实现流量控制」

由滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。

主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

「流量控制引发的死锁」

当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。

但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。

为了避免流量控制引发的死锁，TCP使用了**「持续计时器」**。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。

拥塞控制

「为什么要进行拥塞控制」

假设网络已经出现拥塞，如果不处理拥塞，那么延时增加，出现更多丢包，触发发送方重传数据，加剧拥塞情况，继续恶性循环直至网络瘫痪。

拥塞控制与流量控制的适应场景和目的均不同。

拥塞发生前，可避免流量过快增长拖垮网络；拥塞发生时，唯一的选择就是降低流量。

主要使用4种算法完成拥塞控制：

0. 慢启动
1. 拥塞避免
2. 快重传算法
3. 快速恢复算法

算法1、2适用于拥塞发生前，算法3适用于拥塞发生时，算法4适用于拥塞解决后（相当于拥塞发生前）。

「rwnd与cwnd」

rwnd（Receiver Window，接收者窗口）与cwnd（Congestion Window，拥塞窗口）：

• rwnd是用于流量控制的窗口大小，主要取决于接收方的处理速度，由接收方通知发送方被动调整。
• cwnd是用于拥塞处理的窗口大小，取决于网络状况，由发送方探查网络主动调整。

同时考虑流量控制与拥塞处理，则发送方窗口的大小不超过min{rwnd, cwnd}。

「慢启动算法」

慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

这里用报文段的个数作为拥塞窗口的大小举例说明慢开始算法，实际的拥塞窗口大小是以字节为单位的。

一个传输轮次所经历的时间其实就是往返时间RTT，而且每经过一个传输轮次，拥塞窗口cwnd就加倍。

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。

❝

ssthresh的用法如下：

❞

• cwnd
• 当cwnd>ssthresh时，改用拥塞避免算法。
• 当cwnd=ssthresh时，慢开始与拥塞避免算法任意

注意，这里的慢并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，然后逐渐增大，这当然比按照大的cwnd一下子把许多报文段突然注入到网络中要慢得多。

「拥塞避免算法」

让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。

这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半（但不能小于2）。

然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。

这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

「整个拥塞控制的流程：」

假定cwnd=24时，网络出现超时（拥塞），则更新后的ssthresh=12，cwnd重新设置为1，并执行慢开始算法。

当cwnd=12=ssthresh时，改为执行拥塞避免算法

注意：拥塞避免并非完全能够避免了阻塞，而是使网络比较不容易出现拥塞。

「快重传算法」

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方，可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确认。

快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期

「快恢复算法」

快重传配合使用的还有快恢复算法，有以下两个要点：

• 当发送方连续收到三个重复确认时，就把ssthresh门限减半（为了预防网络发生拥塞）。
• 但是接下去并不执行慢开始算法

考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。

所以此时不执行慢开始算法，而是将cwnd设置为ssthresh减半后的值，然后执行拥塞避免算法，使cwnd缓慢增大。

Socket

即套接字，是应用层 与 TCP/IP 协议族通信的中间软件抽象层，表现为一个封装了 TCP / IP协议族 的编程接口（API）

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SfQqZfIi-1651310391026)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

Socket不是一种协议，而是一个编程调用接口（API），属于传输层（主要解决数据如何在网络中传输）

对用户来说，只需调用Socket去组织数据，以符合指定的协议，即可通信

UDP

「UDP协议特点」

• UDP是无连接的传输层协议；
• UDP使用尽最大努力交付，不保证可靠交付；
• UDP是面向报文的，对应用层交下来的报文，不合并，不拆分，保留原报文的边界；
• UDP没有拥塞控制，因此即使网络出现拥塞也不会降低发送速率；
• UDP支持一对一　一对多　多对多的交互通信；
• UDP的首部开销小，只有８字节

「TCP和UDP的区别」

• TCP是可靠传输，UDP是不可靠传输;
• TCP面向连接，UDP无连接;
• TCP传输数据有序，UDP不保证数据的有序性;
• TCP不保存数据边界，UDP保留数据边界;
• TCP传输速度相对UDP较慢;
• TCP有流量控制和拥塞控制，UDP没有;
• TCP是重量级协议，UDP是轻量级协议;
• TCP首部较长20字节，UDP首部较短８字节;

「基于TCP和UDP的常用协议」

HTTP、HTTPS、FTP、TELNET、SMTP(简单邮件传输协议)协议基于可靠的TCP协议。

TFTP、DNS、DHCP、TFTP、SNMP(简单网络管理协议)、RIP基于不可靠的UDP协议

报文段

UDP的报文段共有2个字段：数据字段 + 首部字段

「UDP报文中每个字段的含义如下：」

• 源端口：这个字段占据 UDP 报文头的前 16 位，通常包含发送数据报的应用程序所使用的 UDP  端口，接收端的应用程序利用这个字段的值作为发送响应的目的地址，这个字段是可选的，所以发送端的应用程序不一定会把自己的端口号写入该字段中，如果不写入端口号，则把这个字段设置为  0，这样，接收端的应用程序就不能发送响应了。
• 目的端口：接收端计算机上 UDP 软件使用的端口，占据 16 位。
• 长度：该字段占据 16 位，表示 UDP 数据报长度，包含 UDP 报文头和 UDP 数据长度，因为 UDP 报文头长度是 8 个字节，所以这个值最小为 8。
• 校验值：该字段占据 16 位，可以检验数据在传输过程中是否被损坏。

网络层

MAC地址

MAC称为物理地址，也叫硬件地址，用来定义网络设备的位置，MAC地址是网卡出厂时设定的，是固定的（但可以通过在设备管理器中或注册表等方式修改，同一网段内的MAC地址必须唯一）。

MAC地址采用十六进制数表示，长度是6个字节（48位），分为前24位和后24位。

❝

MAC地址对应于OSI参考模型的第二层数据链路层，工作在数据链路层的交换机维护着计算机MAC地址和自身端口的数据库，交换机根据收到的数据帧中的目的MAC地址字段来转发数据帧。

❞

IP地址

常见的IP地址分为IPv4与IPv6两大类，当前广泛应用的是IPv4，目前IPv4几乎耗尽，下一阶段必然会进行版本升级到IPv6；

IP地址是以网络号和主机号来标示网络上的主机的，我们把网络号相同的主机称之为本地网络，网络号不相同的主机称之为远程网络主机

本地网络中的主机可以直接相互通信；远程网络中的主机要相互通信必须通过本地网关（Gateway）来传递转发数据。

IP地址对应于OSI参考模型的第三层网络层，工作在网络层的路由器根据目标IP和源IP来判断是否属于同一网段，如果是不同网段，则转发数据包。

「IP地址格式和表示」

IP地址(IPv4)由32位二进制数组成，分为4段（4个字节），每一段为8位二进制数（1个字节）

每一段8位二进制，中间使用英文的标点符号.隔开

由于二进制数太长，为了便于记忆和识别，把每一段8位二进制数转成十进制，大小为0至255。

IP地址的这种表示法叫做**「点分十进制表示法」**。

IP地址表示为：xxx.xxx.xxx.xxx

举个栗子：210.21.196.6就是一个IP地址的表示。

计算机的IP地址由两部分组成，一部分为网络标识，一部分为主机标识，同一网段内的计算机网络部分相同，主机部分不能同时重复出现。

**「路由器」连接不同网段，负责不同网段之间的数据转发，「交换机」**连接的是同一网段的计算机。

通过设置网络地址和主机地址，在互相连接的整个网络中保证每台主机的IP地址不会互相重叠，即IP地址具有了唯一性。

「IP地址分类详解」

IP地址分A、B、C、D、E五类，其中A、B、C这三类是比较常用的IP地址，D、E类为特殊地址。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yOdowKUa-1651310391026)(data:image/gif;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVQImWNgYGBgAAAABQABh6FO1AAAAABJRU5ErkJggg==)]

子网掩码

「子网掩码的概念及作用」

通过子网掩码，才能表明一台主机所在的子网与其他子网的关系，使网络正常工作。

子网掩码和IP地址做与运算，分离出IP地址中的网络地址和主机地址，用于判断该IP地址是在本地网络上，还是在远程网络网上。

子网掩码还用于将网络进一步划分为若干子网，以避免主机过多而拥堵或过少而IP浪费。

「子网掩码的组成」

同IP地址一样，子网掩码是由长度为32位二进制数组成的一个地址。

子网掩码32位与IP地址32位相对应，IP地址如果某位是网络地址，则子网掩码为1，否则为0。

举个栗子：如：11111111.11111111.11111111.00000000

❝

左边连续的1的个数代表网络号的长度，（使用时必须是连续的，理论上也可以不连续），右边连续的0的个数代表主机号的长度。

❞

「为什么要使用子网掩码」

两台主机要通信，首先要判断是否处于同一网段，即网络地址是否相同。

如果相同，那么可以把数据包直接发送到目标主机，否则就需要路由网关将数据包转发送到目的地。

❝

可以这么简单的理解：A主机要与B主机通信，A和B各自的IP地址与A主机的子网掩码进行And与运算，看得出的结果：

1、结果如果相同，则说明这两台主机是处于同一个网段，这样A可以通过ARP广播发现B的MAC地址，B也可以发现A的MAC地址来实现正常通信。

2、如果结果不同，ARP广播会在本地网关终结，这时候A会把发给B的数据包先发给本地网关，网关再根据B主机的IP地址来查询路由表，再将数据包继续传递转发，最终送达到目的地B。

❞

❝

计算机的网关（Gateway）就是到其他网段的出口，也就是路由器接口IP地址。

路由器接口使用的IP地址可以是本网段中任何一个地址，不过通常使用该网段的第一个可用的地址或最后一个可用的地址，这是为了尽可能避免和本网段中的主机地址冲突。

❞

在如下拓扑图示例中，A与B，C与D，都可以直接相互通信（都是属于各自同一网段，不用经过路由器）

但是A与C，A与D，B与C，B与D它们之间不属于同一网段，所以它们通信是要经过本地网关，然后路由器根据对方IP地址，在路由表中查找恰好有匹配到对方IP地址的直连路由，于是从另一边网关接口转发出去实现互连

「子网掩码和IP地址的关系」

子网掩码是用来判断任意两台主机的IP地址是否属于同一网络的依据

拿双方主机的IP地址和自己主机的子网掩码做与运算，如结果为同一网络，就可以直接通信

「如何根据IP地址和子网掩码，计算网络地址：」

将IP地址与子网掩码转换成二进制数。

将二进制形式的 IP 地址与子网掩码做与运算。

将得出的结果转化为十进制，便得到网络地址。

计算机网络常用知识总结！（三）https://developer.aliyun.com/article/1624411