UNPv13:#附录A#IPv4、IPv6、ICMPv4和ICMPv6

IPv4首部

IP层提供无连接不可靠的数据报递送服务。它会尽最大努力把IP数据报递送到指定的目的地,然而并不保证它们一定到达,也不保证它们的到达顺序与发送顺序一致,还不保证每个IP数据报只到达一次。任何期望的可靠性(即无差错按顺序不重复地递送用户数据)必须由上层提供支持。对于TCP(或SCTP)应用程序而言,这由TCP(或SCTP)本身完成。对于UDP应用程序而言,这得由应用程序完成,因为UDP是不可靠的。 IP层最重要的功能之一是路由(routing)。每个IP数据报包含一个源地址和一个目的地址。

·4位版本(version)字段值为4。这是自20世纪80年代早期以来一直在使用的IP版本。 ·首部长度(header length)字段是包括任何选项在内的整个IP首部的32位字长度。这个4位字段的最大取值为15,因而IP首部的最大长度为60个字节。扣除首部固定部分所占据的20字节外,它最多允许40个字节的选项。 ·历史性的8位服务类型(type-of-service,TOS)字段已被替换为两个字段:6位区分服务码点(Differentiated Services Code Point,DSCP)和2位显式拥塞通知(Explicit Congestion Notification,ECN)。我们可以使用IP_TOS套接字选项设置该字段,虽然内核可能覆盖为了实施Diffserv策略或实现ECN而设置的值。 ·16位总长度(total length)字段是包括IPv4首部在内的整个IP数据报的字节长度。数据报中的数据量就是本字段减掉4乘以首部长度(回顾一下,首部长度都是32位或4字节的整数倍)。本字段是必需的,因为有些数据链路要求把帧垫补成某个最小长度(例如以太网),因而有效IP数据报的大小有可能小于数据链路的最小长度。 ·16位标识(identification)字段由IP模块为每个IP数据报设置成不同的值,用于分片和重组。该字段必须就源IPv4地址、目的IPv4地址和协议这三个字段至少在数据报的网络存活期唯一标识每个IP数据报。如果分组不会被分片(但如设置了DF位),那么就不需设置此字段。 ·DF(表示don’t fragment,不要分片)位、MF(表示more fragments,还有片段)位和13位片段偏移(fragment offset)字段也用于分片和重组。DF位还用于路径MTU发现。 ·8位存活时间(time-to-live,TTL)字段由本IP数据报的发送者设置,并由转发它的每个路由器递减(即减去1)。当被减到0时,相应路由器就丢弃该数据报。任何IP数据报的生命期限定为最多255跳。本字段的常用默认值为64,不过我们可以使用套接字选项IP_TTL和IP_MULTICAST_TTL查询和修改这个默认值。 ·8位协议(protocol)字段指定包含在本IP数据报中的数据类型。它的典型值有1(ICMPv4)、2(IGMPv4)、6(TCP)和17(UDP)。 ·16位首部检验和(header checksum)字段只对IP首部(包括任何选项)进行计算。其算法是标准的网际网校验和算法,即简单的16位反码加法(16-bit ones-complement addition)。 ·源IPv4地址(source IPv4 address)和目的IPv4地址(destination IPv4 address)都是32位字段。 ·选项(options)字段。

IPv4地址

32位长度的IPv4地址通常书写成以点号分隔的4个十进制数,称为点分十进制数记法(dotted-decimal notation),其中每个十进制数代表32位地址4个字节中的某一个。

·子网地址

网络ID和子网ID之间的界线由所分配网络地址的前缀长度确定,而这个前缀长度通常由相应组织机构的ISP赋予。然而子网ID和主机ID之间的界线却由网点选择。某个给定子网上所有主机都共享同一个子网掩码(subnet mask),它指定子网ID和主机ID之间的界线。子网掩码中值为1的位涵盖网络ID和子网ID,值为0的位则涵盖主机ID。

RFC 950建议不要使用子网ID各位全为0或全为1的那两个子网,不过如今大多数系统支持这两种格式的子网ID。主机ID各位全为1的地址是相应子网的定向广播地址。主机ID各位全为0的地址用于标识相应子网,同时避免与把0值主机ID用作子网定向广播地址的较旧系统发生冲突。然而如果能够保准子网上不存在这样的系统,那么使用0值主机ID标识一个主机也是可能的。总的来讲,网络程序无需关心子网或主机ID的指定,而应该将IP地址视作不透明的值。

·环回地址

按照约定,地址127.0.0.1赋予环回接口。任何发送到这个IP地址的分组在内部被环送回来作为IP模块的输入,因而这些分组根本不会出现在网络上。我们在同一个主机上测试客户和服务器程序时经常使用该地址。该地址通常为人所知的名字是INADDR_LOOPBACK。网络127.0.0.0/8上任何地址都可以赋予环回接口,但是127.0.0.1是其中最常用的,往往由系统自动配置。

·未指明地址

所有32位均为0的地址是IPv4的未指明地址(unspecified address)。这个IP地址只能作为源地址出现在IPv4分组中,而且是在其发送主机处于获悉自身IP地址之前的自举引导过程期间。在套接字API中该地址称为通配地址,其通常为人所知的名字是INADDR_ANY。在套接字API中绑定该地址(例如为了监听某套接字)表示会接受目的地为任何节点的IPv4地址的客户连接。

·私用地址

RFC 1918[Rekhter et al. 1996]留置了若干段地址范围供“私用网际网”(private internets)使用,这些网络不能直接接入到公用因特网中,除非中间介以NAT或代理设备。

·多宿与地址别名

多宿主机的定义是具有多个IP层可见接口(扣除回馈接口)的主机,至于这些接口是物理的还是逻辑的则不必关心。给予网络负荷极高的某个服务器主机到同一个以太网交换机的多个物理连接,并把这些连接汇聚成一个更高带宽的逻辑连接,这种做法并不鲜见。这样的主机不能因为拥有多个物理接口而被认为是多宿的,因为在IP层看来它们是单个逻辑接口。多宿也用于另一个上下文中。有多个连接通达因特网的网络也称为多宿的。举例来说,有些网点有两个而非一个通达因特网的连接,以此提供因特网接入的备份能力。SCTP传输协议能从多重连接(通过联系多宿网点)中获益。

ICMPv4和ICMPv6:网际网控制消息协议

ICMP是任何IPv4或IPv6实现都必需的有机组成部分。它通常用于在IP节点(即路由器和主机)之间互通出错消息或信息性消息,不过应用程序偶尔也会使用它们获取信息性消息或出错消息,例如ping和traceroute程序都使用ICMP。 ICMPv4和ICMPv6消息的前32位是相同的。8位类型(type)字段是ICMPv4或ICMPv6消息的类型,有些类型有一个8位代码(code)字段提供额外信息。校验和(checksum)字段是标准的网际网检验和,不过在具体校验哪些字段上ICMPv4和ICMPv6存在差异:ICMPv4检验和仅仅校验ICMP消息本身,ICMPv6检验和的校验范围还包括IPv6伪首部。

从网络编程角度看,我们需要知道哪些ICMP消息能够返送到应用进程,哪些条件导致出错以及这些出错消息如何返送到应用进程。对于TCP应用进程,这些错误只是在TCP最终放弃重传尝试时才返回。对于使用已连接套接字的UDP应用进程,这些错误由下次发送或接手操作返回,但在使用已连接套接字时是个例外。

其中端口不可达(对于ICMPv4类型为3代码为3,对于ICMPv6类型为1代码为4)仅用于自身无法通告对端某个端口上无进程在监听的传输协议。TCP为此发送RST分节,因而不需要这个ICMP出错消息。作为路由器运作(即转发分组)的系统忽略重定向(对于ICMPv4类型为5,对于ICMPv6类型为137)。记号“用户进程”意味着内核不处理这样的消息,它们由打开原始套接字的用户进程处理。我们还得注意不同的实现对于特定的消息可能有不同的处理。举例来说,尽管Unix系统通常在用户进程中处理路由器征求与路由器通告,其他实现却有可能在内核中处理这些消息。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

OVN实战二之Overlay实现

前言 上一章介绍了GNS3的使用以及OVN系统的架构,搭建了实验环境,阐述了OVN各个进程的用途、彼此之间的关系,以及产生的日志(OVN实战一之GNS3操作指南...

36112
来自专栏开源优测

RFC1945 超文本传输协议--HTTP/1.0 之二

711
来自专栏Google Dart

Dart服务器端 shelf_auth包 原

Shelf Auth提供了一个authenicate函数,它接受一个Authenticators列表和一个可选的SessionHandler(见下文)并创建Sh...

802
来自专栏偏前端工程师的驿站

CentOS6.5菜鸟之旅:安装Realtek无线网卡驱动

一、前言                                       CentOS6.5不像CentOS7和Unbuntu那样自动安装好了无线网...

1947
来自专栏大内老A

使命必达: 深入剖析WCF的可靠会话[原理揭秘篇](下)

上面一部分我们站在信道层的角度剖析了WCF为了实现可靠会话在信道层进行的一系列消息交换,或者说客户端和服务端的RS信道为了实现可靠消息传输所进行一轮又一轮的握手...

1799
来自专栏Java编程技术

Java网络编程基础篇

网络通讯在系统交互中是必不可少的一部分,无论是面试还是工作中都是绕不过去的一部分,本节我们来谈谈Java网络编程中的一些知识,本chat内容如下:

1171
来自专栏静默虚空的博客

JDK 升级问题小结

JDK8 发布很久了,它提供了许多吸引人的新特性,能够提高编程效率。 如果是新的项目,使用 JDK8 当然是最好的选择。但是,对于一些老的项目,升级到 JD...

3135
来自专栏IT笔记

Nginx学习之开启Gzip压缩提升页面加载速度

前几天有个买链接的,顺手查了下站的权重,果然又回到1了,尽管不是太在意这个东西,但是总归越高越好了。 然而重点是在爱站的最下面居然发现了居然没有开启Gizp,...

35811
来自专栏zaking's

RFC2616-HTTP1.1-Header Field Definitions(头字段规定部分—译文)

part of Hypertext Transfer Protocol -- HTTP/1.1

493
来自专栏后端技术探索

关于TCP网络通信

TCP协议在底层机制上解决了UDP协议的顺序和丢包重传问题。但相比UDP又带来了新的问题,TCP协议是流式的,数据包没有边界。应用程序使用TCP通信就会面临这些...

923

扫码关注云+社区