您的位置:首页 > 理论基础 > 计算机网络

TCP/IP详解学习笔记(7)-广播和多播,IGMP协议

2016-04-14 17:07 666 查看
1.单播,多播,广播的介绍

1.1.单播(unicast)

单播是说,对特定的主机进行数据传送。例如给某一个主机发送IP数据包。这时候,数据链路层给出的数据头里面是非常具体的目的地址,对于以太网来 说,就是网卡的MAC地址(不是FF-FF-FF-FF-FF-FF这样的地址)。现在的具有路由功能的主机应该可以将单播数据定向转发,而目的主机的网 络接口则可以过滤掉和自己MAC地址不一致的数据。

1.2.广播(unicast)

广播是主机针对某一个网络上的所有主机发送数据包。这个网络可能是网络,可能是子网,还可能是所有的子网。如果是网络,例如A类网址的广播就是 netid.255.255.255,如果是子网,则是netid.netid.subnetid.255;如果是所有的子网(B类IP)则是则是 netid.netid.255.255。广播所用的MAC地址FF-FF-FF-FF-FF-FF。网络内所有的主机都会收到这个广播数据,网卡只要把 MAC地址为FF-FF-FF-FF-FF-FF的数据交给内核就可以了。一般说来ARP,或者路由协议RIP应该是以广播的形式播发的。

1.3.多播(multicast)

可以说广播是多播的特例,多播就是给一组特定的主机(多播组)发送数据,这样,数据的播发范围会小一些(实际上播发的范围一点也没有变小),多播的MAC地址是最高字节的低位为一,例如01-00-00-00-00-00。多播组的地址是D类IP,规定是224.0.0.0-239.255.255.255。

虽然多播比较特殊,但是究其原理,多播的数据还是要通过数据链路层进行MAC地址绑定然后进行发送。所以一个以太网卡在绑定了一个多播IP地址之后,必 定还要绑定一个多播的MAC地址,才能使得其可以像单播那样工作。这个多播的IP和多播MAC地址有一个对应的算法,在书的p133到p134之间。可以看到 这个对应不是一一对应的,主机还是要对多播数据进行过滤。

个人的看法:广播和多播的性质是一样的,路由器会把数据放到局域网里面,然后网卡对这些数据进行过滤,只拿到自己打算要的数据,比如自己感兴趣的多 播数据,自己感兴趣的组播数据。当一个主机运行了一个处理某一个多播IP的进程的时候,这个进程会给网卡绑定一个虚拟的多播mac地址,并做出来一个多播 ip。这样,网卡就会让带有这个多播mac地址的数据进来,从而实现通信,而那些没有监听这些数据的主机就会把这些数据过滤掉,换句话说,多播,是让主机 的内核轻松了,而网卡,对不起,您就累点吧。

一些文章也印证了这种想法,最明显的就是局域网监听的原理、实现与防范

2.一些验证性实验

这些实验并不是很复杂,我们只是要ping一下一般的ip和一个广播地址。首先我ping一下自己所在的子网的某一台主机:

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time=1ms TTL=255

可以看到,机器返回的是一台主机的回应结果,进而推测,如果我ping一个广播地址呢?结果如下

Reply from 192.168.11.9: bytes=32 time=1ms TTL=255

Reply from 192.168.11.174: bytes=32 time<1ms TTL=64

Reply from 192.168.11.174: bytes=32 time<1ms TTL=64

Reply from 192.168.11.174: bytes=32 time<1ms TTL=64

Reply from 192.168.11.218: bytes=32 time<1ms TTL=64

Reply from 192.168.11.174: bytes=32 time<1ms TTL=64

可以看到,ping返回了一些随机的ip的结果,这些ip都是与主机在同一子网内的ip。我们可以看到,广播实际上是给处于子网内的所有ip发信。

再来一个多播的例子,但是要实现这个多播并不容易,因为我不知道网络内有多少个多播组,就只好利用几个特殊的多播地址来验证了。

对于多播地址,有几个特殊的多播地址被占用,他们是

1. 224.0.0.1--该子网内所有的系统组。

2. 224.0.0.2--该子网内所有的路由器。

3. 224.0.1.1--网络实现协议NTP专用IP。

4. 224.0.0.9--RIPv2专用IP

所以只要ping这几个IP,就应该能得到一些结果,比如说我ping
224.0.0.2。

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

Reply from 192.168.11.1: bytes=32 time<1ms TTL=255

我们可以看到,这回ping只返回了一个ip的回应。而这个就是我的网关的地址,这也验证了224.0.0.2是所有路由器的多播(组播)地址

3.IGMP协议

IGMP的作用在于,让其他所有需要知道自己处于哪个多播组的主机和路由器知道自己的状态。一般多播路由器根本不需要知道某一个多播组里面有多少个主机,而只要知道自己的子网内还有没有处于某个多播组的主机就可以了。只要某一个多播组还有一台主机,多播路由器就会把数据传输出去,这样,接受方就会通过网卡过滤功能来得到自己想要的数据。为了知道多播组的信息,多播路由器需要定时的发送IGMP查询,IGMP的格式可以看书,各个多播组里面的主机要根据查询来回复自己的状态。路由器来决定有几个多播组,自己要对某一个多播组发送什么样的数据。

这种查询回应数据报的TTL一般是1,而且就算是出错也不产生ICMP差错(没必要)。

TCP/IP详解学习笔记(9)-TCP协议概述

终于看到了TCP协议,这是TCP/IP详解里面最重要也是最精彩的部分,要花大力气来读。前面的TFTP和BOOTP都是一些简单的协议,就不写笔记了,写起来也没啥东西。

TCP和UDP处在同一层---运输层,但是TCP和UDP最不同的地方是,TCP提供了一种可靠的数据传输服务,TCP是面向连接的,也就是说,利用TCP通信的两台主机首先要经历一个“拨打电话”的过程,等到通信准备结束才开始传输数据,最后结束通话。所以TCP要比UDP可靠的多,UDP是把数据直接发出去,而不管对方是不是在收信,就算是UDP无法送达,也不会产生ICMP差错报文,这一经时重申了很多遍了。

把TCP保证可靠性的简单工作原理摘抄如下

· 应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同,应用程序产生的 数据报长度将保持不变。由TCP传递给IP的信息单位称为报文段或段( segment)(参见图1
- 7)。在1 8.4节我们将看到TCP如何确定报文段的长度。

· 当TCP发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能 及时收到一个确认,将重发这个报文段。在第21章我们将了解TCP协议中自适应的超时 及重传策略。

· 当TCP收到发自TCP连接另一端的数据,它将发送一个确认。这个确认不是立即发送,通常将推迟几分之一秒,这将在1
9.3节讨论。

· TCP将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输 过程中的任何变化。如果收到段的检验和有差错, T
P将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。

· 既然TCP报文段作为IP数据报来传输,而IP数据报的到达可能会失序,因此TCP报文段 的到达也可能会失序。如果必要, TCP将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层。

· TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

从这段话中可以看到,TCP中保持可靠性的方式就是超时重发,这是有道理的,虽然TCP也可以用各种各样的ICMP报文来处理这些,但是这也不是可靠的,最可靠的方式就是只要不得到确认,就重新发送数据报,直到得到对方的确认为止。

TCP的首部和UDP首部一样,都有发送端口号和接收端口号。但是显然,TCP的首部信息要比UDP的多,可以看到,TCP协议提供了发送和确认所需要的所有必要的信息。这在P171-173有详细地介绍。可以想象一个TCP数据的发送应该是如下的一个过程。

· 双方建立连接

· 发送方给接受方TCP数据报,然后等待对方的确认TCP数据报,如果没有,就重新发,如果有,就发送下一个数据报。

· 接受方等待发送方的数据报,如果得到数据报并检验无误,就发送ACK(确认)数据报,并等待下一个TCP数据报的到来。直到接收到FIN(发送完成数据报)

· 中止连接

可以想见,为了建立一个TCP连接,系统可能会建立一个新的进程(最差也是一个线程),来进行数据的传送
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: