20TCP IP 网络协议基础入门--IP网际协议

Posted 2023-04-04

参考技术A IP 数据报：IP 协议位于网络层，它是 TCP/IP 协议族中最为核心的协议，所有的 TCP、UDP、ICMP 及 IGMP 数据都以 IP 数据报格式传输。IP 协议提供的是不可靠、无连接的数据报传送服务。

我们已经知道了 IP 协议提供的数据传送服务是不可靠和无连接的，具体表现如下：
不可靠（unreliable）：IP 协议不能保证数据报能成功地到达目的地，它仅提供传输服务。当发生某种错误时，IP 协议会丢弃该数据报。传输的可靠性全由上层协议来提供。
无连接（connectionless）：IP 协议对每个数据报的处理是相互独立的。这也说明，IP 数据报可以不按发送顺序接收。如果发送方向接收方发送了两个连续的数据报（先是 A，然后是 B），每个数据报可以选择不同的路线，因此 B 可能在 A 到达之前先到达。

我们先看一下 IP 数据报的格式，其中没有一个字段是多余的，学习 IP 协议就应从学习它的报文字段意义和作用开始。

如上图所示，普通的 IP 数据报的报头长度 20 字节(除非有选项字段)，各个部分的作用：
版本号：4 位，用于标明 IP 版本号，0100 表示 IPv4，0110 表示 IPv6。目前常见的是 IPv4。
首部长度：4 位，表示 IP 报头长度，包括选项字段。
服务类型(TOS)：分别有：最小时延、最大吞吐量、最高可靠性、最小花费 4 种服务，如下图所示。4 个标识位只能有一个被置为 1。
总长度：16 位，报头长度加上数据部分长度，便是数据报的总长度。IP 数据报最长可达 65535 字节。
标识：16 位，接收方根据分片中的标识字段相不相同来判断这些分片是不是同一个数据报的分片，从而进行分片的重组。通常每发送一份报文它的值就会加 1。
标志：3 位，用于标识数据报是否分片。其中的第 2 位是不分段（DF）位。当 DF 位被设置为 1 时，则不对数据报进行分段处理；第 3 位是分段（MF）位，除了最后一个分段的 MF 位被设置为 0 外，其他的分段的 MF 位均设置为 1。
偏移：13 位，在接收方进行数据报重组时用来标识分片的顺序。
生存时间(TTL)：8 位，用于设置数据报可以经过的最多的路由器个数。TTL 的初始值由源主机设置（通常为 32 或 64），每经过一个处理它的路由器，TTL 值减 1。如果一个数据报的 TTL 值被减至 0，它将被丢弃。
协议：8 位，用来标识是哪个协议向 IP 传送数据。ICMP 为 1，IGMP 为 2，TCP 为 6，UDP 为 17，GRE 为 47，ESP 为 50。
首部校验和：根据 IP 首部计算的校验和码。
源 IP 和目的 IP ：数据报头还会包含该数据报的发送方 IP 和接收方 IP。
选项：是数据报中的一个可变长、可选的信息，不常用，多用于安全、军事等领域。

了解了上面的理论知识过后，我们可以使用 tcpdump 这个抓包工具来实际看一下。

-n ：显示 IP 地址而非域名地址
-t ：不显示时间戳
-x ：以十六进制显示包内内容
-c ：tcpdump 将在接受到几个数据包后退出

首先看到开头的 192.168.42.3.3001 > 172.16.2.250.44632 代表的是源 ip 为 192.168.42.3，端口 3001，目的 ip 为 172.16.2.250，端口 44632。

然后看到 0x0000 那行：
协议版本： 0x4 表示的是协议版本为 IPv4；
首部长度： 0x5，5*4=20，表示 IP 报头长度为 20 字节。一个字节通常等于 8 位，所以这里可以知道 IP 报头为 4500 到 2a02；
TOS 服务类型：0x00，意味着是一般服务；
总长度：0x0136，换算下来为 310 字节；
标识：0x172a；
3bit 标志 + 13bit 片偏移：0x4000；
生存时间：0x40，值为 64；
协议：0x06，代表 TCP 协议；
首部校验和：0x88e2。

为了便于寻址以及层次化构造网络，每个 IP 地址可被看作是分为两部分，即网络号和主机号。同一个区域的所有主机有相同的网络号（即 IP 地址的前半部分相同），区域内的每个主机（包括路由器）都有一个主机号与其对应。

IP 地址被分为 A、B、C、D、E 五类：
A 类给大型网络或政府机构等；
B 类分配给中型网络、跨国企业等；
C 类分配给小型网络；
D 类用于多播；
E 类用于实验。

各类可容纳的地址数目不同，其中我们最常见的为 A、B、C 这三类。
IP 地址用 32 位二进制数字表示的时候，A、B、C 类 IP 的网络号长度分别为 8 位、16 位、24 位：

A 类地址：
A 类地址网络号范围：1.0.0.0---127.0.0.0；
A 类 IP 地址范围：1.0.0.0---127.255.255.255；
A 类 IP 的私有地址范围：10.0.0.0---10.255.255.255 （所谓的私有地址就是在互联网上不使用，而被用在局域网络中的地址）；
127.X.X.X 是保留地址，用做循环测试用的；
因为主机号有 24 位，所以一个 A 类网络号可以容纳 2^24-2=16777214 个主机号。

B 类地址：
B 类地址网络号范围：128.0.0.0---191.255.0.0；
B 类 IP 地址范围：128.0.0.0---191.255.255.255；
B 类 IP 的私有地址范围：172.16.0.0---172.31.255.255；
169.254.X.X 是保留地址；191.255.255.255 是广播地址；
因为主机号有 16 位，所以一个 B 类网络号可以容纳 2^16-2=65534 个主机号。

C 类地址：
C 类地址网络号范围：192.0.0.0---223.255.255.0；
C 类 IP 地址范围：192.0.0.0---223.255.255.255；
C 类 IP 的私有地址范围：192.168.0.0---192.168.255.255；
因为主机号有 8 位，所以一个 C 类网络号可以容纳 2^8-2=254 个主机号。

下面使用 ifconfig 命令来查看本机 ip：

思考：这是一个几类 ip 地址？
C 类

IP 地址如果只使用 ABCDE 类来划分，会造成大量的浪费：一个有 500 台主机的网络，无法使用 C 类地址。但如果使用一个 B 类地址，6 万多个主机地址只有 500 个被使用，造成 IP 地址的大量浪费。
因此，可以在 ABC 类网络的基础上，进一步划分子网：占用主机号的前几个位，用于表示子网号。
这样 IP 地址就可看作 IP = 网络号 + 子网号 + 主机号。
子网号的位数没有硬性规定，于是我们用子网掩码来确定一个 IP 地址中哪几位是主机号，具体使用方法如图：

子网掩码中的 1 标识了 IP 地址中相应的网络号和子网号，0 标识了主机号。将 IP 地址和子网掩码进行逻辑与运算，结果就能区分网络号和子网号。
使用 ifconfig 命令也可以查看到子网掩码：

如果发送方与接收方直接相连（点对点）或都在一个共享网络上（以太网），那么 IP 数据报就能直接送达。
而大多数情况则是发送方与接收方通过若干个路由器(router)连接，那么数据报就需要经过若干个路由器的转发才能送达，它是怎么选择一个合适的路径来"送货"的呢？

IP 层在内存中有一个路由表（输入命令 route -n 可以查看路由表），当收到一份数据报并进行发送时，都要对该表进行搜索：
搜索路由表，如果能找到和目的 IP 地址完全一致的主机，则将 IP 数据报发向该主机；
搜索路由表，如果匹配主机失败，则匹配同子网的路由器(这需要子网掩码的协助)。如果找到路由器，则将该 IP 数据报发向该路由器；
搜索路由表，如果匹配同子网路由器失败，则匹配同网络号路由器，如果找到路由器，则将该 IP 数据报发向该路由器；
如果以上都失败了，就搜索默认路由，如果默认路由存在，则发报；
如果都失败了，就丢掉这个包；
接收到数据报的路由器再按照它自己的路由表继续转发，直到数据报被转发到目的主机；
如果在转发过程中，IP 数据报的 TTL（生命周期）已经被减为 0，则该 IP 数据报就被抛弃。

实验环境中可以使用 route -n 查看路由表：

另外我们可以使用 traceroute 来追踪路由过程。首先需要安装一下：

接下来使用 traceroute 追踪本机到 www.shiyanlou.com 的路由：

还有一些其他选项，比如：
设置跳数为 8

探测包个数设为 4

显示 IP 地址，不查主机名

当你用 ifconfig 查看 IP 地址时，有时你会发现自己的 IP 地址是这样的———192.168.X.X 或 172.16.X.X。这是 C 类网和 B 类网的私有地址，就是俗称的内网 IP。这是因为你的路由器采用了 NAT 技术。
NAT（Network Address Translation，网络地址转换）是 1994 年提出的。当在专用网内部的一些主机本来已经分配到了内网 IP 地址，但现在又想和因特网上的主机通信时，NAT 技术将其内网 IP 地址转换成全球 IP 地址，然后与因特网连接，也就是说，内网的数台主机使用了同一个全球 IP 地址在上网。
NAT 技术实现了宽带共享，而且有助于缓解 IP 地址空间枯竭的问题。
使用 ifconfig eth0 查看内网 ip：

我们现在使用的 IPv4 协议版本从理论上讲，可以编址 1600 万个网络、40 亿台主机。但采用 A、B、C 三类编址方式后，可用的网络地址和主机地址的数目大打折扣，以至 IP 地址已于 2011 年 2 月 3 日分配完毕。
其中北美占有 3/4，约 30 亿个，而人口最多的亚洲只有不到 4 亿个，中国截止 2010 年 6 月 IPv4 地址数量达到 2.5 亿，落后于 4.2 亿网民的需求。地址不足，严重地制约了中国及其他国家互联网的应用和发展。
随着网络技术的发展，计算机网络将进入人们的日常生活，可能身边的每一样东西都需要连入全球因特网，在这样的环境下，IPv6 应运而生。
IPv6 的地址长度是 128 位，通常将这 128 位的地址按每 16 位划分为一个段，将每个段转换成十六进制数字，并用冒号隔开，比如：2000:0000:0000:0000:0001:2345:6789:abcd 就是一个 IPv6 地址。
单从数量级上来说，IPv6 所拥有的地址容量是 IPv4 的约 8×10^28 倍，达到 2＾128（算上全零的）个。这不但解决了网络地址资源数量的问题，同时也为除电脑外的设备连入互联网在数量限制上扫清了障碍。
随着 IPv4 不足，支持 IPv6 的网络迅速增长，现在全球已经有 5% 的网络使用 IPv6。

查看 IP 路由表。
子网划分：现有两个 C 类网，202.203.204.0 和 202.203.224.0，分别把它们平均分成 4 个和 8 个子网，写出每个子网的起始、终结 IP 和子网掩码。

[HTTP-1]-了解WEB及网络基础（下）

文章结构

---

---

与HTTP密切相关的协议：IP、TCP和DNS

---

下面我们分别针对在 TCP/IP 协议族中与 HTTP 密不可分的 3 个协议（IP、TCP 和 DNS）进行说明。

IP协议——负责传输

按层次分，IP（Internet Protocol）网际协议位于网络层。网际协议这个词会显得很夸张，但事实上确实如此，因为所有使用网络的系统都会用到IP协议。TCP/IP协议族中的IP指的就是网际协议。需要注意的是很大程度大家看到IP第一反应是IP地址，但其实IP在这里其实是指IP协议（网际协议）。

IP协议的作用就是把各类数据包都传送给对方。而要确保确实传送到对方那里，则需要满足各类条件。其中最重要的条件是 IP地址和 MAC地址。

IP地址和MAC地址进行配对。IP地址可以更换，但MAC地址基本上不会更改。

使用ARP协议凭借MAC地址进行通信

IP间的通信依赖MAC地址。在网络上，通信双方在同一局域网内（LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议。ARP是一种解析地址的协议，根据通信方的IP地址就可以反查出对应的MAC地址。

没有人能够全面掌握互联网中的传输状况

在到达通信目标前的中转过程中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。

这种机制称为路由选择（routing），有点儿像快递公司的送货过程。想要寄快递的人，只要将自己的货物送到集散中心，就可以知道快递公司是否肯收件发货，该快递公司的集散中心检查货物的送达地址，明确下站该送往哪个区域的集散中心。接着，那个区域的集散中心自会判断是否能送到对方的家中。

这个比喻是想说，无论哪台计算机、哪台网络设备，他们都无法全面掌握互联网中的细节。

TCP协议——为可靠性保驾护航

按照层次分，TCP位于传输层，提供可靠的字节流服务。

所谓的字节流服务（Byte Stream Service）是指， 为了方便传输，将大块数据分割成以报文段为单位的数据包进行管理。而可靠的传输服务是指，能够把数据准确可靠地传给对方。换句话说， TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。

确保数据能到达目标

为了准确无误地将数据送达目标处，TCP协议采用了三次握手的策略。用TCP协议把数据包送出去后，TCP不会对传送后的情况置之不理，他一定会向对方确认是否成功送达。

握手过程中使用了TCP的标志（flag）——SYN（synchronize）和ACK（acknowledgement）。

三次握手的过程：

发送端首先发送一个带SYN标志的数据包给对方。接收端收到后，回传一个带有SYN/ACK标志的数据包以示传达确认信息。最后，发送端再传回一个带ACK标志的数据包，代表握手结束。

如果这个过程中某个阶段中断了,那么TCP协议会再次以相同的顺序发送相同的数据包.除了三次握手,TCP协议还有其他各种手段来保证通信的可靠性。

DNS 服务——负责域名解析

DNS定义:

DNS服务是和HTTP协议一样位于应用层的协议.它提供域名到IP地址之间的解析服务.

计算机可以被赋予IP地址,也可以被赋予主机名和域名.比如www.baidu.com。

用户通常使用主机名或域名来访问对方的计算机,而不是直接通过IP地址访问.因为与IP地址的一组纯数字相比,用字母配合数字的表示形式来指定计算机名更符合人类的记忆习惯.

但要让计算机去理解名称,相对而言就变得困难了.因为计算机更擅长处理一长串数字.

为了解决上述问题,DNS服务出现了.DNS协议提供通过域名查找IP地址,或逆向从IP地址反查域名的服务.

各种协议与HTTP协议的关系

---

对上述HTTP协议密不可分的TCP/IP协议族的交互关系用下边一张图来总结一下:

URL和URI

---

或许和URI(统一资源标识符)相比,我们更熟悉URL(统一资源定位符).URL正式使用Web浏览器等访问Web页面时需要输入的网页地址.比如,www.baidu.com就是URL.

URI(统一资源标识符)

URI定义:

URI是 Uniform Resource Identifier的缩写.RFC2396分别对这三个单词进行了如下定义.

Uniform: 规定统一的格式可方便处理多种不同类型的资源，而不用根据上下文 环境来识别资源指定的访问方式。另外，加入新增的协议方案(如 http: 或 ftp:)也更容易。

Resource: 资源的定义是“可标识的任何东西”。除了文档文件、图像或服务(例 如当天的天气预报)等能够区别于其他类型的，全都可作为资源。另 外，资源不仅可以是单一的，也可以是多数的集合体。

Identifier: 表示可标识的对象。也称为标识符。

综上所述,URI就是由某个协议方案表示的资源的定位标识符.协议方案是指访问资源所使用的协议类型名称.

IANA-Uniform Resource Identifier (URI) SCHEMES(统一资源 标识符方案):

URI 用字符串标识某一互联网资源，而URL表示资源的地点(互联网上所处的位置)。可见URL是URI的子集。

“RFC3986:统一资源标识符(URI)通用语法”中列举了几种URI例子，如下: 1、ftp://ftp.is.co.za/rfc/rfc1808.txt 2、http://www.ietf.org/rfc/rfc2396.txt 3、ldap://[2001:db8::7]/c=GB?objectClass?one 4、mailto:[e-mail] 5、news:comp.infosystems.www.servers.unix 6、tel:[phone]、telnet://192.0.2.16:80/ 8、urn:oasis:names:specification:docbook:dtd:xml:4.1.2

URI格式

表示指定的URI,要使用涵盖全部必要信息的绝对URI、绝对URL以及相对URL。相对URL，是指从浏览器中基本URI处指定的URL,形如/image/logo.gif。

绝对URI的格式:

协议方案名:使用http:或https:等协议方案名获取访问资源时要指定协议类型。不 区分字母大小写，最后附一个冒号(:)。也可使用data:或javascript:这类指定数据或脚本程序的方案名。

登录信息(认证):指定用户名和密码作为从服务器端获取资源时必要的登录信息(身份 认证)。此项是可选项。

服务器端口号:指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动 使用默认端口号。

带层次的文件路径:指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件 目录结构相似。

查询字符串:针对已指定的文件路径内的资源，可以使用查询字符串传入任意参 数。此项可选。

片段标识符:使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置)。但在RFC中并没有明确规定其使用方法。该项也为可选项。

并不是所有的应用程序都符合RFC

有一些用来制定HTTP协议技术标准的文档，它们被称为RFC(Request for Comments，征求修正意见书)。

通常，应用程序会遵照由RFC确定的标准实现。可以说,RFC是互联网的设计文档，要是不按照RFC标准执行，就有可能导致无法通信的状况。比如，有一台 Web 服务器内的应用服务没有遵照RFC的标准实现，那Web浏览器就很可能无法访问这台服务器了。

由于不遵照 RFC 标准实现就无法进行HTTP协议通信，所以基本上客户端和服务器端都会以RFC为标准来实现HTTP协议。但也存在某些应用程序因客户端或服务器端的不同，而未遵照RFC标准，反而将自成一套的“标准”扩展的情况。

不按RFC标准来实现，当然也不必劳心费力让自己的“标准”符合其他所有的客户端和服务器端。但设想一下，如果这款应用程序的使用者非常多，那会发生什么情况?不难想象，其他的客户端或服务器端必然都不得不去配合它。

实际在互联网上，已经实现了HTTP协议的一些服务器端和客户端里就存在上述情况。说不定它们会与本书介绍的 HTTP协议的实现情况不一样。