IP协议详解
本屌今天可算是累坏了,一大早起来本来寻思赶快centOS虚拟机玩玩吧,那天刚装了系统,本来的虚拟机没了,今天想着先把centOS装上,结果给个系统不停的给我扯淡啊,显示虚拟机上不去网,好不容易上去网了,ping不通主机,主机ping不通虚拟机,各种办法都试了,最后我吧VMware8那块网卡禁用了,卧槽!!啥都好了,本屌一直鼓捣到晚上八点,从早晨10点多.服了我自己了.
在前面的学习中,我们简单地IP接力和IP地址后,咱们今天具体的说说IP协议的具体细节和设计哲学.
我们已经在IP接力中介绍过,一个IP包分为头部和数据两部分.头部是为了实现IP通信必须的附加信息,数据是IP通信所要传送的信息:
我们看到,三个黄色区域跨越了IPV4和IPV6.Version(4位)用来表明IP协议版本,是IPV4还是IPV6(IPV4的Version=0100,,IPV6的Version=0110).Source Address和Destination Address分别为发出地和目的地的IP地址.
Time to Live存活时间(Hop Limit in IPV6).Time to Live最初数表示一个IP包的最大存活时间,如果IP包在传输过程中超过Time to Live,那么IP包就作废.后来IPV4的这个区域记录一个整数(比如30),表示在IP包接力过程最多经过30个路由接力,如果超过了30个路由接力,那么这个IP包就作废.IP包每经过一个路由器,路由器就给Time to Live减一.当一个路由器发现Time to Live 为0时,就不再发送该IP包了.IPV6中的Hop Limit区域记录的也是最大路由接力数,与IPV4的功能相同,Time to Live/Hop Limit避免了IP包在互联网中无限接力.
Type of Service 服务类型(Traffic Class in IPV6).Type of Service最初是用来给IP包分优先级,比如语音通话需要实时性,所以它的IP包应该比web服务的IP包邮更高的优先级.然而,这个最初不错的想法没有被微软采纳.在Windows下生成的IP包都是相同的最高优先级,所以在当时造成Linux和Windows混合网络中,Linux的IP传输会慢于windows(仅仅是因为Linux更加守规矩).后面Type of Service被实际分成两部分,Differentiated Service Field (DS,前6位)和Explicit Congestion Notification(ECN,后两位),前者依然用来区分服务类型,而后者用于表明IP包途径路由的交通状况.IPV6的Traffic Class也被分成了这样的两部分.通过IP包提供不同服务的想法,并针对服务进行不同的优化想法已经产生很久了,但具体做法并没有形成公认的协议.比如ECN区域,它用来表示IP包经过路径的交通状况.如果接受者收到的ECN区域显示路径上的很拥挤,那么接受者应该作出调整.但是实际上,许多接受者都会忽略ECN所包含的信息.交通状况的控制往往由更高层的比如TCP协议来实现.
Protocol协议(Next Header in IPV6).Protocol用来说明IP包Payload部分所遵循的协议,也就是IP包之上的协议是什么,它说明了IP包封装的是一个怎样的高层协议包(TCP?UDP?).
Total Length 以及IPV6中Payload Length的讨论以后说.
我们看一下IPV4和IPV6的长度信息,IPV4头部的长度,在头部的最后是options,每个options由32位,是选填性质的区域.一个IPV4头部可以完全没有options区域,不考虑options的话,整个IPV4的头部有20 bytes(上面每行为4bytes).但是由于由options的存在,整个头部的总长度总是变动的,我们用IHL(Internet Header Length)来记录头部的总长度,用Total Length记录整个IP包的长度.IPV6没有options区域,它的头部固定为40 bytes,所以IPV6并不需要IHL区域.Payload Length用来表示IPV6的数据部分的长度.整个IP包的长度为:40 bytes+Payload Length
IPV4中还有一个Header Checksum区域,这个Checksum用于校验IP包的头部信息.Checksum与之前在小喇叭中提到CRC算法并不相同.IPV6则没有Checksum区域.IPV6包的校验依赖高层的协议来完成,这样的好处是免去了执行Checksum校验所需要的时间,减少了网络延迟(lateecy).
Identification,flags和fragment offest,这三个包都是为碎片化(framentation)服务的.碎片化是指一个路由器将接收到的IP包分拆成多个IP包传送,而接受这些”碎片”的路由器或者主机需要将”碎片”重新组合(fragmentation)成一个IP包.不同的局域网所支持的最大传输单元(MTU,Maximum Transportation Unit)不同.如果一个IP包的大小超过了局域网支持的MTU,就需要在进入该局域网时碎片化传输(就好像方便面面饼太大,必须掰碎了才能放进碗里),碎片化会给路由器和网络带来很大的负担.最好在IP包发出之前探测整个路径上的最小MTU,IP包的大小不超过该最小MTU,就可以避免碎片化.IPV6在设计上避免碎片化.每一个IPV6局域网的MTU都必须大于等于1280 bytes.IPV6的默认发送IP包大小为1280 bytes.
Flow Label是IPV6中新增的区域.它被用来提醒路由器来重复使用之前的接力路径.这样IP包可以自动保持出发时的顺序.这对于流媒体之类的应用有帮助Flow label的仅以使用还在开发中.
IP协议在产生时是一个松散的网络,这个网络由各个大学局域网相互连接成的,由一群蓬头垢面的极客维护这.所以IP协议认为自己所处的环境是不可靠的(unreliable):诸如路由器坏掉,实验室失火,某人不小心踢掉电缆之类的事情经常发生.
这样凶险的环境下,IP协议提供的传送只能是”我尽力(best effort)”式的.所谓的”我尽力”,其潜台词就是,如果事情出错不要怪我,我只是答应了尽力,可没保证啥.所以,如果IP包传输过程中出现错误(比如checksum对不上,比如交通太繁忙,比如超过Time to Live),根据IP协议,你的IP包会直接被丢掉.Game Over!不会再有进一步的努力来修正错误.Best effort让IP协议保持很简单的形态.更多的质量控制交给高层协议处理,IP协议只负责有效率的传输.
由此可见,IP协议其实并不是很不负责....
“效率优先”也体现在IP包的顺序(order)上.即使出发地和目的地保持不变,IP协议也不保证包的到达先后顺序.我们已经知道,IP接力是根据routing table来决定接力路线的.如果在连续的IP包发送过程中,routing table 更新(比如有一条新建的捷径出现),那么后出发的IP包选择走不一样的接力路线.如果新的路径传输速度更快,那么后发出的IP包可能先到达.这就好像是多车道的公路上,每辆车都在不停的变道,最终所有的车道都塞满汽车.这样可以让公路的利用率达到最大.
IPV6中Flow Label可以建议路由器将一些IP包保持一样的接力路径.但这只是”建议”,路由器可能不接受建议.
Header Checksum区域有16位.它是这样获得的,从header取得除checksum之外的0/1序列,比如:
9194 8073 0000 4000 4011 C0A8 0001 C0A8 00C7 (十六进制hex,这是一个为演示运算过程而设计的eheader)
按照十六位(也就是4位hex)分割整个序列.将分割后的各个4位hex累积相加.如果有超过16位的进位出现,则将进位加到后16位结果的最后一位:
Binary Hex
1001000110010100 9194
+ 1000000001110011 8073
----------------
1 0001001000000111 11207
+ 1
----------------
0001001000001000 1208
上面的计算叫做one‘s complement sum。求得所有十六位数的和，one’s complement sum(4500, 0073, 0000, 4000, 4011, C0A8, 0001, C0A8, 00C7) = 1433
然后,将1433的每一位取反(0->1,1->0),就得到
checksum : EBCC
这样,我们的header就是:
9194 8073 0000 4000 4011 EBCC C0A8 0001 C0A8 00C7
IP包的接受方在接收到IP包之后,可以求上面各个16位数的one’s complete sum,应该得打FFFF. 如果不是FFFF,那么header是不正确的,整个IP包会被丢弃.
注意:实例所用的IP head而不是真实的header,它只是起到一个算法的演示作用.
每个网络协议的形成都有其历史原因。比如IP协议是为了将各个分散的实验室网络连接起来。由于当时的网络很小，所以IPv4(IPv4产生与70年代)的地址总量为40亿。尽管当时被认为是很大的数字，但数字浪潮很快带来了地址耗尽危机。IPv6的主要目的是增加IPv4的地址容量，但同时根据IPv4的经验和新时代的技术进步进行改进，比如避免碎片化，比如取消checksum (由于高层协议TCP的广泛使用)。网络协议技术上并不复杂，更多的考量是政策性的。
IP协议是"Best Effort"式的，IP传输是不可靠的。但这样的设计成就了IP协议的效率。
版权声明：本文为博主原创文章，未经博主允许不得转载。
原文地址：http://blog.csdn.net/shanyongxu/article/details/48109507
