计算机网络的协议介绍（三）

13 应用层：9527 (DNS协议)

 

 

在周星驰的电影《唐伯虎点秋香》中，周星驰饰演的主角一进入华府，就被强制增加了一个代号9527。从此，华府的人开始称呼主角为9527，而不是他的姓名。

域名(domain name)是IP地址的代号。域名通常是由字符构成的。对于人类来说，字符构成的域名，比如www.yahoo.com，要比纯粹数字构成的IP地址(106.10.170.118)容易记忆。域名解析系统(DNS, domain name system)就负责将域名翻译为对应的IP地址。在DNS的帮助下，我们可以在浏览器的地址栏输入域名，而不是IP地址。这大大减轻了互联网用户的记忆负担。另一方面，处于维护和运营的原因，一些网站可能会变更IP地址。这些网站可以更改DNS中的对应关系，从而保持域名不变，而IP地址更新。由于大部分用户记录的都是域名，这样就可以降低IP变更带来的影响。

从机器和技术的角度上来说，域名并不是必须的。但Internet是由机器和用户共同构成的。鉴于DNS对用户的巨大帮助，DNS已经被当作TCP/IP套装不可或缺的一个组成部分。

 

DNS服务器

域名和IP地址的对应关系存储在DNS服务器(DNS server)中。所谓的DNS服务器，是指在网络中进行域名解析的一些服务器(计算机)。这些服务器都有自己的IP地址，并使用DNS协议(DNS protocol)进行通信。DNS协议主要基于UDP，是应用层协议(这也是我们见到的第一个应用层协议)。

 

DNS服务器构成一个分级(hierarchical)的树状体系。上图中，每个节点(node)为一个DNS服务器，每个节点都有自己的IP地址。树的顶端为用户电脑出口处的DNS服务器。在Linux下，可以使用cat /etc/resolv.conf，在Windows下，可以使用ipconfig /all，来查询出口DNS服务器。树的末端是真正的域名/IP对应关系记录。一次DNS查询就是从树的顶端节点出发，最终找到相应末端记录的过程。

中间节点根据域名的构成，将DNS查询引导向下一级的服务器。比如说一个域名cs.berkeley.edu，DNS解析会将域名分割为cs, berkeley, edu，然后按照相反的顺序查询(edu, berkeley, cs)。出口DNS首先根据edu，将查询指向下一层的edu节点。然后edu节点根据berkeley，将查询指向下一层的berkeley节点。这台berkeley服务器上存储有cs.berkeley.edu的IP地址。所以，中间节点不断重新定向，并将我们引导到正确的记录。

 

在整个DNS查询过程中，无论是重新定向还是最终取得对应关系，都是用户计算机和DNS服务器使用DNS协议通信。用户计算机根据DNS服务器的反馈，依次与下一层的DNS服务器建立通信。用户计算机经过递归查询，最终和末端节点通信，并获得IP地址。

来自wikipedia

 

缓存

用户计算机的操作系统中的域名解析模块(DNS Resolver)负责域名解析的相关工作。任何一个应用程序(邮件，浏览器)都可以通过调用该模块来进行域名解析。

并不是每次域名解析都要完整的经历解析过程。DNS Resolver通常有DNS缓存(cache)，用来记录最近使用和查询的域名/IP关系。在进行DNS查询之前，计算机会先查询cache中是否有相关记录。这样，重复使用的域名就不用总要经过整个递归查询过程。

来自wikipedia

反向DNS

上面的DNS查询均为正向DNS查询：已经知道域名，想要查询对应IP。而反向DNS(reverse DNS)是已经知道IP的前提下，想要查询域名。反向DNS也是采用分层查询方式，对于一个IP地址(比如106.10.170.118)，依次查询in-addr.arpa节点(如果是IPv6，则为ip6.arpa节点)，106节点，10节点，170节点，并在该节点获得106.10.170.118对应的域名。

 

 

15 应用层：先生，要点单吗? (HTTP协议概览)

 

我们在TCP流通信中说明了，TCP协议实现了数据流的传输。然而，在实践中发现，人们往往习惯以文件为单位传输资源，比如文本文件，图像文件，超文本文档(hypertext document)。超文本文档中包含有超链接，指向其他的资源。超文本文档是万维网(World Wide Web，即www)的基础。

HTTP协议是应用层协议，它随着万维网发展起来。HTTP协议最初只是一套实践标准。其本质目的是，如何在万维网的网络环境下，更好的使用TCP协议(尽管HTTP协议也可以用UDP协议作为底层，但绝大部分都是基于TCP协议)，以实现文件，特别是超文本文件的传输。

早期的HTTP协议主要是传输静态文件，也就是存储在服务器上的文件。随着万维网的发展，HTTP协议被用于传输“动态文件”，这样的文件是服务器上的程序根据HTTP请求即时生成的文件。我们将HTTP的传输对象统称为资源(resource)。

 

点单

HTTP实现的是资源的订购和传送。其工作方式类似于快餐点单。

1. 请求(request): 顾客向服务员提出请求：“来个鸡腿汉堡”。
2. 回复(response):服务员根据情况，回应顾客的请求

根据情况的不同，服务员的回应可能有:

• 服务员准备鸡腿汉堡，将鸡腿汉堡交给顾客。（一切OK）
• 服务员发现自己只是个甜品站。他让顾客前往正式柜台点单。（重新定向）
• 服务员告诉顾客鸡腿汉堡没有了。(无法找到)

交易结束后，服务员就将刚才的交易抛到脑后，准备服务下一位顾客。

 

格式

HTTP协议的通信是一次request-responce交流。客户端(guest)向服务器发出请求(request)，服务器(server)回复(response)客户端。

 

 

 

HTTP协议规定了请求和回复需要遵循的格式。请求和回复需要满足下面的格式:

起始行 (start line)
头信息 (headers)

主体(entity body)

起始行只有一行。它包含了请求/回复最重要的信息。请求的起始行表示(顾客)“想要什么”。回复的起始行表示(后厨)“发生什么”。

 

头信息可以有多行。每一行是一对键值对(key-value pair)，比如:

Content-type: text/plain 

它表示，包含有一个名为Content-type的参数，该参数的值为text/plain。头信息是对起始行的补充。请求的头信息对服务器有指导意义 (好像在菜单上注明: 鸡腿不要辣)。回复的头信息则是提示客户端（比如，在盒子上注明: 小心烫）

 

主体部分包含了具体的资源。上图的请求中并没有主体，因为我们只是在下单，而不用该后厨送什么东西 (请求是可以有主体内容的)。回复中包含的主体是一段文本文字(Hello World!)。这段文本文字正是顾客所期待的，鸡腿汉堡。

 

请求

我们深入一些细节。先来看一下请求:

GET /index.html HTTP/1.1
Host: www.example.com

 

在起始行中，有三段信息:

• GET 方法。用于说明想要服务器执行的操作。
• /index.html 资源的路径。这里指向服务器上的index.html文件。
  
• HTTP/1.1 协议的版本。HTTP第一个广泛使用的版本是1.0，当前版本为1.1。

 

早期的HTTP协议只有GET方法。遵从HTTP协议，服务器接收到GET请求后，会将特定资源传送给客户。这类似于客户点单，并获得汉堡的过程。使用GET方法时，是客户向服务器索取资源，所以请求往往没有主体部分。

随着Web的发展，人们不再只满足于GET方法。新的方法被加入到HTTP协议中。最常用的是POST方法。它用于从客户端向服务器提交数据。使用POST方法时，请求的主体部分用于包含想要提交的数据。POST方法最用于提交HTML的form数据。这就像是，顾客将自带大蒜，或者一本食谱交给后厨。服务器往往会对POST方法提交的数据进行一定的处理，比如存入服务器数据库。

 

上面的请求中有一行头信息。该头信息的名字是Host。HTTP的请求必须有Host头信息。Host用于说明服务器的地址和端口。HTTP协议的默认端口是80，如果在HOST中没有说明端口，那么将默认采取该端口。在该例子中，服务器的域名为www.example.com，端口为80。域名将通过DNS服务器转换为IP地址，从而确定服务器在互联网上的地址。

(参看IP地址与TCP端口)

 

回复

服务器在接收到请求之后，会根据程序，生成对应于该请求的回复，比如:

HTTP/1.1 200 OK
Content-type: text/plain
Content-length: 12

Hello World!

回复的起始行同样包含三段信息

• HTTP/1.1 协议版本
• 200 状态码(status code)。
• OK 状态描述

OK是对状态码200的文字描述，它只是为了便于人类的阅读。电脑只关心三位的状态码(status code)，即这里的200。200表示一切OK，资源正常返回。状态码代表了服务器回应动作的类型。

其它常见的状态码还有:

• 302，重新定向(redirect): 我这里没有你想要的资源，但我知道另一个地方xxx有，你可以去那里找。
• 404，无法找到(not found): 我找不到你想要的资源，无能为力。

(重新定向时，客户端可以根据302的建议前往xxx寻找资源，也可以忽略该建议。)

 

Content-type说明了主体所包含的资源的类型。根据类型的不同，客户端可以启动不同的处理程序(比如显示图像文件，播放声音文件等等)。下面是一些常见的资源

• text/plain 普通文本
• text/html HTML文本
• image/jpeg jpeg图片
• image/gif gif图片

Content-length说明了主体部分的长度，以字节(byte)为单位。

 

回应的主体部分为一段普通文本，即

Hello World!

 

无状态

根据早期的HTTP协议，每次request-reponse时，都要重新建立TCP连接。TCP连接每次都重新建立，所以服务器无法知道上次请求和本次请求是否来自于同一个客户端。因此，HTTP通信是无状态(stateless)的。服务器认为每次请求都是一个全新的请求，无论该请求是否来自同一地址。

想象高级餐厅和快餐店。高级餐厅会知道客人所在的位置，如果新增点单，那么服务员知道这和上一单同一桌。而在快餐店中，不好意思，服务员并不记录客人的特征。想再次点单？请重新排队……

 

随着HTTP协议的发展，HTTP协议允许TCP连接复用，以节省建立连接所耗费的时间。但HTTP协议依然保持无状态的特性。

 

总结

HTTP协议实现了万维网上的资源传输，采用request-response的工作方式。

GET， POST

无状态

 

 

 

 

 

14 综合：逆袭 (CIDR与NAT)

 

 

IPv4由于最初的设计原因，长度只有32位，所以只提供了大约40亿个地址。这造成了IPv4地址的耗尽危机。随后，IPv6被设计出来，并可以提供足够多的IP地址。但是IPv4与IPv6并不兼容，IPv4向IPv6的迁移并不容易。一些技术，比如说这里要说的CIDR和NAT，相继推广。这些技术可以缓解IPv4的稀缺状态，成就了IPv4一时的逆袭。

 

CIDR

CIDR(Classless Inter Domain Routing)改进了传统的IPv4地址分类。传统的IP分类将IP地址直接对应为默认的分类，从而将Internet分割为网络。CIDR在路由表中增加了子网掩码(subnet masking)，从而可以更细分网络。利用CIDR，我们可以灵活的将某个范围的IP地址分配给某个网络。

1) IP地址分类

在IP接力赛中，我提到，IP地址可以分为如下几类：

IP class    From          To                 Subnet Mask

A           1.0.0.0       126.255.255.255    255.0.0.0

B           128.0.0.0     191.255.255.255    255.255.0.0

C           192.0.0.0     223.255.255.255    255.255.255.0

这是最初的IPv4地址分类设计。一个IPv4地址总共有32位，可以分为网络(network)和主机(host)两部分。子网掩码(subnet mask)是用于表示哪些位代表了网络部分。比如如下subnet mask 255.0.0.0的二进制表示为：

11111111 00000000 00000000 00000000

它的前八位为1，所以表示IP地址的前八位为网络部分。而后面的24位代指该网络的各个主机。一个A类网络可以有2²⁴台主机，也就是16777216。由于IPv4地址已经分好了类，所以当我们拿到一个IP地址，我们就可以通过上面查到它的子网掩码。(B类，2¹⁶; C类，2⁸)

 

2) 传统路由表

IP分类的方便了IP包的接力。IP包到达某个路由器后，会根据该路由器的路由表(routing table)，来决定接力的下一站。一个传统的路由表看起来是这样的：

Destination        Gateway             Iface

199.165.145.0      0.0.0.0             eth0

199.165.146.0      0.0.0.0             eth1

0.0.0.0            199.165.146.8       eth1

该路由表代表的网络拓扑如下：

 

由于IP分类，我们不需要记录subnet mask。当我们要前往199.165.146.17时，我们已经知道这台主机位于一个C类地址，所以它的子网掩码是255.255.255.0，也就是说199.165.146代表了网络，17代表了主机。

 

3) CIDR路由表

然而，由于默认分类，造成了网络只能按照A、B、C的方式存在。假设一个网络(比如MIT的网络)分配了一个A类地址，那么该网络将容许16777216个主机。如果该网络无法用完这些IP地址，这些IP地址将无法被其他网络使用。再比如上面的网络，199.165.145必须作为一个整个的网络存在。如果我们只有10台主机，那么将会有200多个IP地址被浪费。CIDR的本质是在路由表中加入子网掩码，并根据该列信息对网络进行分割，而不是根据默认的A，B，C进行分割。比如：

Destination        Gateway             Genmask             Iface

199.165.145.254    0.0.0.0             255.255.255.254     eth2

199.165.145.0      0.0.0.0             255.255.255.0       eth0

199.165.146.0      0.0.0.0             255.255.255.0       eth1

0.0.0.0            199.165.146.8       0.0.0.0             eth1

 

根据路由表的第一条记录，

199.165.145.254 (IP address) : 11000111 10100101 10010001 11111110

255.255.255.254 (subnet mask): 11111111 11111111 11111111 11111110 (31个1，1个0)

 

通过子网掩码可以知道，前31位表示网络，最后一位表示主机。子网掩码总是有连续多个1组成，比如上面的31个1。所以也可记为199.165.145.254/31，来同时表示IP地址和子网掩码。

路由器将原来的199.165.145网络中的一部分分割出来。这一网络可以容纳两台电脑，也就是199.165.145.254和199.165.145.255。这个网络对应网卡是eth2。当有IP包通向这两个IP地址时，会前往eth2，而不是eth0。

 

网络拓扑如下：

 

利用CIDR，我们可以将IP地址根据需要进行分割，从而不浪费IP地址。

 

NAT

CIDR虽然可以更加节约IP地址，但它并不能创造新的IP地址。IP地址的耗尽危机并不能因此得到解决。我们来看IPv4的第二袭，NAT(Network Address Translation)。

 

理论上，每个IP地址代表了Internet上的一个设备。但有一些IP地址被保留，用于一些特殊用途。下面三段IP地址被保留用作私有IP地址：

From          To             

10.0.0.0      10.255.255.255

172.16.0.0    172.31.255.255

192.168.0.0   192.168.255.255

私有IP地址只用于局域网内部。理论上，我们不应该在互联网上看到来自或者发往私有IP地址的IP包。与私有IP地址对应的是全球IP地址(global IP address)。

 

NAT是为私有网络(private network)服务的。该网络中的主机使用私有IP地址。当私有网络内部主机和外部Internet通信时，网关(gateway)路由器负责将私有IP地址转换为全球IP地址，这个地址转换过程就是Network Address Translation。网关路由器的NAT功能。最极端情况下，我们可以只分配一个全球IP地址给网关路由器，而私有网络中的设备都使用私有IP地址。由于私有IP地址可以在不同私有网络中重复使用，所以就大大减小了设备对IP地址的需求。

 

1) 基础NAT

NAT的一种为基础NAT，也成为一对一(one-to-one)NAT。在基础NAT下，网关路由器一一转换一个外部IP地址和一个私有IP地址。网关路由器保存有IP的NAT对应关系，比如：

上面网络中，当有IP包要前往199.165.145.1时，网关路由器会将目的地改写为10.0.0.1，并接力给私有网络中的10.0.0.1的电脑。同样，当10.0.0.1的电脑向Internet发送IP包时，它的发送地为10.0.0.1。在到达网关路由器时，会将发送地更改为199.165.145.1。此外，IP头部的checksum，以及更高层协议(比如UDP和TCP)中的校验IP的checksum也会更改。

基础NAT尽管是一对一转换IP地址，它还是可以减小内部网络对IP地址的需求。通常来说，一个局域网中只有少数的设备处于开机状态，并不需要给每个设备对应一个全球IP地址。NAT可以动态的管理全球IP地址，并将全球IP地址对应到开机设备，从而减小内部网络对IP地址的需求。

 

2) NAPT

NAT还有一种，被成为NAPT (Network Address and Port Translation)。在基础NAT中，高层协议的端口号并不会改动。NAPT下，IP地址和端口号可能同时改动。

我们在UDP和TCP中提到端口(port)的概念。在建立UDP或者TCP通信时，我们实际上是用IP:Port来代表通信的一端(正如打电话时主机:分机号一样)。NAPT就是在网关路由器处建立两个通信通道，一个通往内部网络，一个通往外部网络，然后将网关处的通道端口连接，从而让内部和外部通信。比如：

我们看到，通往IP 199.165.145.1建立了三个端口的连接：8888, 8889和8080。它们分别在NAPT处改为通往10.0.0.1:80, 10.0.0.1:8080和10.0.0.3:6000。NAPT记录有外部IP:端口和内部IP:端口的一一对应关系。在IP包经过时，网关路由器会更改IP地址，端口号以及相关的checksum。

利用NAPT我们可以使用一个(或者多个但少量的)外部IP和大量的端口号，来对应多个内部IP以及相应的端口号，从而大大减小了对全球IP地址的需求。

NAPT：多重影分身术

 

无论是基础NAT还是NAPT，它们的设置都比较复杂，并且从本质上违背了互联网最初的设计理念。但由于IPv4的使用惯性，NAT还是被广泛推广。由于NAT所处的网关服务器是理想的设置防火墙的位置，NAT还往往和防火墙共同建设，以提高私有网络的安全性。

 

总结

即使是CIDR和NAT广泛使用，IPv4还是在不可避免的耗尽。IPv6正在加紧部署。但上述的两种技术，CIDR和NAT在IPv6中同样被采用，所以了解它们依然是有意义的。