计算机网络（自顶而下方法）第二章——应用层

参考书目：《计算机网络（自顶而下方法）第八版》

参考原文：https://blog.csdn.net/qq_39326472/article/details/88089747

第二章—— 应用层

• 网络应用协议的概念和实现（传输层服务模型，客户与服务器，P2P模式）
• 流行的应用层（HTTP，FTP，SMTP等）
• 创建网络应用程序（套接字编程）

2.1  应用层协议原理

 1.应用层功能：

• 向网络发送数据
• 从网络接收数据
• 对数据进行处理

2.网络应用特点：

• 可以运行在不同端系统
• 可以通过网络交流（如网页浏览器和网页服务器）
• 快速开发和部署
• 不需要运行在网络核心上，只在网络边缘运行（事实上，网络核心一般处于网络层及以下层）

---

2.1.1  网络应用程序体系结构

应用程序的体系结构不同于网络的体系结构。从应用程序研发者的角度来看，网络体系结构是固定的，并为应用程序提供特定的服务集合。

应用程序体系结构是由应用程序开发者设计的，它规定了在端系统上如何组织应用程序。两种常见的现代网络应用程序所采用的体系结构为：客户-服务器体系结果和对等体系结构

• 客户—服务器服务体系结构：Client/Server，简称C/S

在该体系结构中，有一个总是打开的主机，即服务器。它接收和服务来自其他许多被称为客户的主机请求。值得注意的是，在该体系结构中，客户之间是不能直接通信的。

该服务器具有固定的、周知的地址，并且总是打开的，所以任何主机都可以与服务器取得联系。

客户-服务器体系结构的著名应用有：Web、FTP、Telnet和电子邮件。

通常，如果仅有一台服务器处理所有的请求，那么服务器系统将很快变得不堪重负，为此，配备大量主机的数据中心常被用于创建强大的虚拟的服务器，一个数据中心可以有数十万台服务器，它们需要供电和维护，同时服务提供商还需要支付不断出现的互联和带宽费用，以及发送和接收到达/来自数据中心的数据。

• 对等网：Peer-To-Peer，简称P2P

在P2P体系结构中，对位于数据中心的专用服务器有着最小（或者没有）依赖。应用程序在间断连接的主机之间使用直接通信，这些主机被称为对等方。对等方并不为服务提供商所拥有，因为这种对等方通信不需要通过专门的服务器，所以该体系结构也被称为对等方到对等方结构。

结点（对等方主机）的地址及他们之间的连接可能随时会发生变化（没有固定IP），因此管理会变得非常复杂。

自扩展性：新的结点加入可能会引发额外的服务需求，但是也会为其他对等方带来新的服务能力。

P2P面临着以下三个问题：

•     ISP友好。大多数住宅ISP受制于非对称带宽应用，也就是下载比上传要多得多。但是P2P视频和文件分发应用改变了从服务器到住宅ISP的上载流量，因而给ISP带来压力；
•     安全性。因为其高度的分布和开放式，P2P应用也可能给安全带来挑战；
•     激励。如何说服用户资源向应用提供带宽、存储和计算资源？

目前，流量密集型应用都是P2P体系结构的，包括文件共享软件（例如BitTorrent）。

• 混合体系：C/S + P2P

即时通信软件QQ就是使用的混合体系。服务器用来跟踪用户IP地址，但是用户之间的通信则使用P2P模式直接发送。

---

2.1.2  进程通信

进程：可以看作运行在端系统中的一个程序，在操作系统中，实际进行通信的是进程而不是应用程序，一个应用程序也可能会产生多个进程。

同一台主机上的多个进程间的相互通信采用的是内部进程通信方式，不同主机间的进程通信采用报文交换的方式。

（1）客户进程和服务器进程

对于两对相互通信的进程，我们通常将这两个进程之一标识为客户，而另一个进程标识为服务器。

在某些P2P应用中，一个进程可能既是客户也是服务器，因为在一个文件共享应用中，一个进程的确既能请求文件也能发送文件。所以从进程所扮演的角色来区分是客户进程还是服务器进程不够精确，所以我们从发起通信的顺序来定义它们：在给定的一对进程之间，首先发起通信的进程被标记为客户进程，在会话开始时等待联系的进程被称为服务器进程。

在C/S模式中，向服务器发起请求的主机是客户进程，接收服务请求的服务器是服务器进程。

（2）进程和计算机网络之间的接口

通信子网只负责把数据交付到主机，那么主机如何知道应该把哪段数据交付给哪段进程中呢？

解决方法是套接字（Socket） ，套接字是应用程序进程和计算机网络间（应用层和运输层）的接口，每个网络应用进程都有自己独一无二的套接字。

套接字长度为48位，包括32位的主机IP地址，和16位的端口地址。主机IP地址标识套接字在哪台主机上，端口地址在该主机上标识网络应用进程。

由于套接字是建立网络应用程序的可编程接口，因此套接字也被称为应用程序和网络之间的应用编程接口（API），程序设计者可以控制套接字在应用端的一侧，但是几乎无法控制运输端的一侧，设计者对于运输段一侧的控制权仅仅在于选择运输层协议和设定几个传输层参数。

（3）进程寻址

为了向特定目的进程发送报文，发送机进程需要知道接收进程（更为准确的说是，接收进程对应的套接字）的标记。该标记由两部分组成：接收进程所在的主机地址和接收进程在该主机中的标记。

在因特网中，主机由IP地址标记，其中IP地址是一个32位（IPV4）标记；而接收进程（或者说是其对应的套接字）使用端口号标记。

一些常用的应用程序有着固定的端口号，比如Web服务器使用80端口、邮件服务器（运行SMTP协议）使用25端口等。

---

2.1.3  可供应用程序使用的运输服务

选择合适的运输层协议的大致可以从以下这四个方面考量：可靠数据传输、吞吐量、定时和安全性。

（1）可靠数据传输

有些运输层协议（TCP）可以向用户提供完全可靠的数据传输，当应用程序使用可靠数据传输的运输层协议时，只要将要发送的数据传输进套接字就可以完全相信该数据可以完整无差错地到达接收方。

当一个运输层协议不提供可靠数据传输时，由发送方发送的数据就可能不能够到达接收进程。有些应用是允许这样的情况发生的，这些应用被称为丢失允许的应用。这类应用常见的有：交谈式音频和视频等，它们能够承担丢失一定量的数据损失。在这些应用中，如果丢失少量数据将出现小干扰，但是不会出现致命的损伤，这些应用为容忍丢失的应用。

（2）吞吐量

 可用吞吐量就是发送进程向接收进程交付比特的速率，因为会有其他会话共享该网络的路径的带宽，并且因为这些会话的到来和离开，可用吞吐量将会发生变化，这就导致另一种自然的服务，即运输层协议能够提供确切的可用吞吐量。

使用这种服务时，应用程序就能以明确的速度发送数据而不会出现丢包等现象，并且运输层应当保证可用吞吐量必须总是大于等于该速率。

对吞吐量有明确要求的应用程序被称为带宽敏感的应用。许多多媒体应用是带宽敏感的（尽管某些多媒体应用程序可能采用自适应编码技术对数字视频和音频以与当前可用带宽相匹配的速度加解码。），比如因特网电话。而弹性应用则对吞吐量没有严格的要求。这类应用包括：电子邮件、文件传输以及web传送等。

（3）定时

运输层协议可以提供定时保证，也就是说运输层可以保证接收方会在某个确切的时延以内收到分组信息。这种服务对交互式实时应用程序有吸引力，这些应用为了服务的有效性而对数据到达时间有严格的要求，例如因特网电话。

（4）安全性

运输层可以提供一些安全服务，以防止传输的数据以某种方式在这两个进程之间被察觉到。这些安全服务包括：数据的加解密、数据的完整性和端点鉴别等。

TCP和UDP天生就不具备安全性，但是可以通过安全的套接字层SSL完成加密的传输服务。

---

2.1.4  因特网提供的运输服务

因特网为应用程序提供两个运输服务协议，即TCP协议和UDP协议。当你作为一个软件开发者时，就需要在这两种协议中做出取舍。

（1）TCP服务 

• 面向连接的服务：在应用层数据报文开始流动之前，TCP会在客户端和服务器端相互交换传输层控制信息。这个握手过程将提示客户端和服务器端，让它们为即将到来的大量分组做好准备。握手阶段接收后将建立一个TCP连接，这条链接是全双工的，即连接双方使用该条链接可以同时进行报文的收发，这条连接将在通讯结束后拆除。
• 可靠的数据传输：应用程序使用TCP协议可实现无差错、按适当顺序交付所有发送的数据，没有字节的丢失和冗余。
• 拥塞控制机制：当发送方和接收方之间的网络出现拥塞时，TCP协议会抑制发送方的数据发送，直到网络恢复正常。

（2）UDP服务

UDP服务是一种不提供不必要服务的轻量级运输协议。它仅提供最低限度的服务。

UDP是无连接的，也就是说通信之前没有握手的阶段。

UDP不提供数据的可靠传输，UDP也没有拥塞控制机制。有些应用场景下，UDP协议将带来更多的便利和效率，比如DNS和一些因特网电话服务（为了避免拥塞控制协议的控制而使用UDP）

（3）因特网运输层协议不提供的服务

TCP和UDP都没有对吞吐量和定时做出保证，但是应用开发者可以通过应用设计，最大程度上应对这种保证的缺乏，今天的因特网能够为时间敏感的应用提供满意的服务，尽管它并不提供任何定时或者带宽保证的服务。

---

2.2  Web和HTTP

Web（万维网）是第一个引起公众注意的互联网应用，Web属于C/S模式的按需操作，当客户需要时，就能得到想要的内容。

HTML——信息表达的协议；HTTP——信息传输的协议。

 2.2.1  HTTP概述

Web的应用层协议是超文本传输协议（HTTP），HTTP由两部分实现：一个客户端程序一个服务器程序，HTTP定义了客户和服务器进行报文交换的方法，在客户端和服务器之间通过交换HTTP报文进行会话。

Web页面是由对象组成的，一个对象是一个文件（可以说HTML，JPEG等），它们通过一个URL地址进行寻址。客户和服务器交互的核心思想是客户通过HTTP请求对服务器发出对Web页面的请求报文，服务器收到该报文后将返回包含该对象的HTTP响应报文。

任何一个对象都可以通过URL来定位，每个URL由两部分构成：存放对象的服务器主机名和对象的路径名。例如 www.abcd.edu.cn/cs/pic/gif就是一段URL，其中www.abcd.edu.cn是主机名，/cs/pic/gif是对象名。

HTTP使用了TCP作为传输层协议，HTTP客户首先发起一个与服务器的TCP连接（创建套接字），服务器接受连接并向客户发送HTTP报文，需要注意的是，服务器根据请求作出响应，但是不存储任何关于该客户的状态信息，也正因为这样，HTTP被称为无状态协议。

Web服务器使用C/S体系，因此总是打开的，并且拥有固定的地址，服务于数百万计的不同浏览器的请求。

2.2.2 持续连接和非持续连接

非持续连接：当客户端和服务器持续交换报文时，每一个请求/响应对由不同的TCP连接发送。也就是说每交换一次报文就要建立一个新的连接。

持续连接：当客户端和服务器持续交换报文时，每一个请求/响应对都由同一个TCP连接发送。也就是说TCP连接会一直保持到所有报文交换完毕才会断开。

HTTP既可使用持续连接也可以使用非持续连接。尽管HTTP默认情况下使用持续连接。

 1.采用非持续连接的HTTP

使用非持续连接时，每个TCP连接在服务器发送一个对象后就会关闭，也就是每个TCP只传送一个请求报文和响应报文。

往返时间（RTT）：从客户开始请求HTML文件到客户收到整个文件所花费的时间。RTT包括分组的传播时延、排队时延、处理时延（因为是短分组，所以其传输时延可不计）

客户端和服务器建立TCP连接的时候，会通过一个三次握手的过程来交换传输控制信息。三次握手的前两次（请求TCP连接）占用了一个RTT，客户还要向服务器发送一个HTTP请求报文，HTTP请求/响应占用了另一个RTT，一旦该分组到达服务器，服务器便开始使用TCP传输HTML对象。因此，粗略地说，响应时间是两个RTT加上传输HTML的时间。考虑到无数台客户端的需求，许多浏览器同时打开多个并行连接来改善性能。

2.采用持续连接的HTTP

从上面可以看出，非持续连接必须为每个请求新建一个TCP连接，而每个TCP连接将占用系统资源，包括缓冲区和变量等，这样服务器的负担就会很重。第二，一个对象将通过两个RTT的时延才能交付，时间很慢。

如果使用持续连接，那么服务器在发送响应报文后将保持该TCP打开，后续客户端可以使用该连接来向服务器发出请求。不但一个完整的页面可以通过同一个连接传送，同一台服务器上的多个页面也可以通过同一个连接发送，这就提高了效率（省略了TCP建立产生的1个RTT）。

一般来说，如果一条连接在一定的时间间隔后没被使用的话，就会被关闭。HTTP默认使用的是带流水线的持续连接（客户端一次性发送所有请求，再慢慢接收）。

2.2.3  HTTP报文格式

（1）HTTP请求报文

 一个请求报文具有至少一行的内容。请求报文的第一行称为请求行，其后继的各行被称为首部行。请求行包含三个字段：方法字段、URL字段、HTTP版本字段。其中方法字段可为：GET、POST、PUT、DELETE、HEAD等；URL字段里带有请求对象的标志，本例中为/index.html;HTTP版本字段显示版本，本例中为HTTP/1.1版本。

Host行中指明了对象所在的主机，Connection行中表明了期望的连接方式——持续连接。

在首部行之后一个空行，之后便是请求的“实体体”。该实体体可以在POST方法里传递Form表单内容或者传递其它一些二进制流数据等。值得注意的是，表单也不一定必须使用POST方法。如果使用GET，实体部分为空，会显示在url中。

Head类似于GET方法，将会用一个http报文进行响应，但是不返回请求对象，经常用作调试跟踪。PUT方法允许用户上传对象到指定的Web服务器上指定的路径。Delete方法允许用户或应用程序删除Web服务器上的对象。

（2）HTTP响应报文 

 响应报文总体上也分三个部分，第一部分是状态行，包含HTTP版本、状态码以及相应状态信息三个字段；第二部分是首部行，包含发送日期、服务器类型、上一次修改请求资源的时间、内容的类型等内容。第三部分是实体体，实体体包含请求对象本身。

这里的Date是从文件系统中检索到该对象，插入到响应报文，并发送该响应报文的时间。Keep-alive表示建立的持续连接。

常见状态码：

• 200 OK：请求成功被请求的对象在报文中。
• 301 Moved Permanently：被请求的对象被移动过，新的位置会在报文Location中有说明。
• 400 Bad Request：服务器不懂请求报文。
• 404 Not Found：服务器上找不到请求对象。
• 505 HTTP Version Not Supported：服务器不支持请求报文使用的HTTP协议版本。

---

2.2.4  用户与服务器的交互：Cookie

cookie为站点识别用户提供了支持。

使用Cookie的目的：

•  限制用户的访问
• 把内容和用户身份关联起来

Cookie技术的组成部分：

• HTTP响应报文里增加一个关于Cookie的首部行；
• HTTP请求报文里增加一个关于Cookie的首部行；
• 用户端系统保留一个Cookie文件，由浏览器保存维护；
• Web站点建立Cookie和用户身份的关联的数据库；

虽然，Cookie的使用方便了用户也方便了服务端，但是它的使用存在争议，因为使用Cookie被认为是对用户隐私的一种侵犯，因为Web站点可以通过Cookie得到很多用户的信息，并有可能将这部分信息卖给第三方等。

---

2.4  DNS：因特网的目录服务

DNS系统用于IP地址和域名之间的转换，DNS运行在端到端系统上，使用UDP协议（53号端口），C/S模式进行报文传输。但是DNS并不直接和用户打交道，而是因特网的核心功能。

 在计算机网络里，我们通过IP地址来标记某一时刻网络中唯一的主机。IP地址（IPV4）由4个字节组成（例如163.128.30.1），有着严格的层次结果，每个字节使用点号分隔。同时，为了方便记忆，我们也通过为主机提供一个便于记忆的主机名来标志主机（例如www.facebook.com），这样主机之间的通信就变得方便了。但是，同时也就产生了一个问题：主机名和IP地址的转换问题。因为在信息的发送者一端，通常使用主机名来标识主机，但是在计算机网络里是使用IP地址来标记主机。

2.4.1  DNS提供的服务

DNS是一个由分层的DNS服务器组成的分布式数据库和一个使得主机可以查询分布式数据库的应用层协议组成。

用户主机上应该运行着DNS客户端。DNS通常被其他应用层协议使用，比如：HTTP、SMTP和FTP等。这些协议在正式工作以前，首先利用DNS提供的服务，将主机名转换为IP地址，可以发现的是，DNS为用户带来方便的同时，也为网络应用带来额外的时延——查询DNS服务器的时延。

除了提供主机名到IP地址的转换外，DNS还提供一些重要服务：

• 主机别名：有时候某个主机的规范主机名非常复杂，不便于记忆，所以它可能会有多个别名，应用程序能通过调用DNS获得主机别名对应的规范主机名。
• 邮件服务器别名：DNS同样也提供邮件服务器主机名和别名的转换服务，实际上，MX记录允许一个公司的邮件服务器和Web服务器使用相同的主机名。
• 负载分配：DNS也被用在冗余的服务器之间分配负载。大型服务器集群中每个服务器有着不同的IP地址，但是它们都和同一个主机名相关联，也就是一个IP地址集合同一个规范主机名相联系。当某个DNS服务器收到DNS请求时，该服务器将使用IP地址的整个集合作为响应，但是为不同的用户分配不同的服务器（循环分配）。

2.4.2 DNS工作机理概述

DNS采用分布式的设计方案，之所以这样做是因为单一的DNS服务器面临无法解决单点故障、无法保证通信容量以及无法靠近所有的查询主机和维护困难等问题。

 （1）分布式，层次数据库

DNS服务器采用层次式组织，并且分布在全世界范围内；大致来说，存在三种DNS服务器：根DNS服务器、顶级域DNS服务器和权威DNS服务器。举例说明，其工作的普遍流程：一个DNS客户端，希望获得www.baidu.com的IP地址，DNS客户端首先和根DNS服务器取得联系，它将返回负责解析顶级域名.com的服务器的IP地址（或者其集合），客户将同这些服务器之一取得联系，然后顶级域DNS服务器建返回baidu.com的权威服务器的IP集合，客户端通过与这些服务器之一取得联系，获得www.baidu.com的IP地址。

• 根DNS服务器：因特网上有13个根DNS服务器，大部分分布在北美洲，尽管我们可以将这13个根DNS服务器视为单个的服务器，但是每台服务器实际上是一个冗余的计算机网络以提供安全性和可靠性。
• 顶级域DNS服务器：负责顶级域名（如com，org，net，edu，gov）以及各个国家的顶级域名（如uk，cn，fr）的转换。
• 权威DNS服务器：因特网上，具有公共可访问主机的每个组织机构必须提供公共可访问的DNS记录，这些记录将主机名映射为IP地址。一个组织的权威DNS服务器收藏了这些DNS记录，多数大学和大公司实现和维护它们自己的基本和辅助（备份）权威DNS服务器，当然，也可以通过付费的方式，将相关的信息插入到其它权威服务器中。

除了上面三种DNS服务器，还有一种不在DNS层次结构之中，但是很重要的DNS，是本地DNS服务器。本地DNS服务器通常邻近其所在网络的其他主机。当主机发出DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将请求转发到DNS服务器层次结构中。

DNS查询有两种，一种是递归查询，一种是迭代查询。实践中，查询通常满足这样的模式：从请求主机到本地DNS服务器的查询是递归的，其余查询是迭代的。

递归查询是指，如果请求的接收者不知道所请求的内容，那么接收者将扮演请求者，发出有关请求，直到获得所需要的内容，然后将内容返回给最初的请求者。也就是说，在递归查询中，一定要给请求者想要的答案。

迭代查询则是指，如果接收者没有请求者所需要的准确内容，接收者将告诉请求者如何去获得该内容，但是自己并不去发出请求。

（2）DNS缓存

 DNS缓存实际上是为了改善时延性能并且减少在因特网上传输的DNS报文数量而引入的。DNS缓存原理十分简单，每当DNS服务器发出请求且收到回答时，就将回答中的内容缓存在它自己的主机空间上。这样，如果有相同的请求到达时，就不需要再去发出请求，直接使用缓存进行回答即可。因为有了缓存，本地DNS就可以直接提供一些经常被访问的主机名所对应的IP地址，而不需要询问根DNS服务器了。缓存一般会保存两天。

---

2.4.3  DNS记录和报文

所有DNS服务器都存储了资源记录（RR），RR提供主机名到IP地址的映射。

资源记录（RR）是包含了下列字段的4元组：（name，value，type，TTL）

TTL是指该记录的生存时间，它决定了该条记录何时被删除。而name和value的意义取决于type。

• type=A：name=主机名；value=主机名对应的IP地址。
• type=NS：name为域（如foo.com）；而value是显示获取该域中主机IP地址的权威DNS服务器的主机名。
• type=CNAME：name=别名（如www.ibm.com），value=真名（如servereast.backup2.ibm.com），则value为name所对应的其他服务器的规范主机名。
• type=MX：则value为name所对应的邮件服务器的规范主机名。

所以如果一条记录为type=A，则它直接包含了需要的信息；如果是NS，需要进一步得到权威DNS服务器的IP地址（同时返回一条NS记录，并返回一条以该NS记录的value值为name的A记录）希望得到一条A记录；而type=CNAME和MX的记录则实现了主机别名到主机规范名的转换，可以通过该规范名继续构建查询链条，直到获得希望的IP地址。

（1）DNS报文

DNS报文有两种，即查询报文和回答报文，并且两种报文有着相同的结构。前12个字节是首部区域，后面是问题区域，回答区域，权威服务器的记录和附加信息区域。

• 标识符（16bit）标识该查询，便于匹配问题和回答。
• 标志位（8bit）包括查询/回答（判断报文类型），权威（回答服务器是否为权威DNS服务器），希望递归（设置模式为递归查询），递归可用（服务器是否支持递归查询），还有4个字节的数量字段（指明后续四个区域的大小）。
• 问题区域：包含了正在进行的查询信息，包括名字字段、查询类型。
• 回答区域：包含了对最初请求的名字的资源记录，回答报文的回答区域可以包含多条RR，因此一个主机名能有多个IP地址。
• 权威区域：包含了其他权威服务器的信息。
• 附加区域：包含了其它有帮助的记录，比如在对于一个MX类型的请求回答报文里，回答区域里指出了邮件服务器的规范主机名，而附加区域里就有可能包含一个类型为A的关于该规范主机名的的IP地址。

 （2）在DNS数据库中插入数据

需要在注册登记机构完成这一任务，当你注册一个域名时，需要向该机构提供你的基本和辅助权威DNS服务器的名字和IP地址，该注册机构将确保一个类型为NS和类型为A的记录输入对应的顶级域名服务器，这样就完成了插入数据。