《计算机网络：自顶向下方法》应用层 读书笔记

Computer Network : A up-down Approach

Chapter 2 应用层

2.1 网络应用原理

2.1.1 网络应用体系结构

在 客户-服务器体系结构 中, 有一个总是打开的主机, 称为 服务器 , 它服务于来自所有其他称为 客户 的主机的请求

当Web服务器接收到来自于某客户的对某对象的请求时, 它向该客户发送所请求的对象作为相应

在客户-服务器体系结构中, 客户之间不直接通信

服务器具有固定的, 周知的地址, 称为 IP地址 , 因为该服务器具有固定的, 周知的地址, 并且服务器是一直打开的, 所以客户总是能够通过向该服务器的IP地址发送分组来与其联系

在 P2P体系结构 中, 对位于数据中心的专用服务器有最小的依赖, 相反, 应用程序在间断连接到主机对之间使用直接通信, 这些主机对被称为 对等方

P2P体系结构最引人入胜的特性之一就是 自拓展性 , P2P体系结构也是有成本效率的, 因为它通常不需要庞大的服务器基础设施和服务器带宽

2.1.2 进程通信

进行通信的实际上是 进程 而不是程序, 当多个进程运行在相同的端系统上时, 它们通过进程间相互通信机制进行通信. 进程间通信规则由端系统上的操作系统决定.

在两个不同端系统上的进程, 通过计算机网络交换 报文 而相互通信

1. 客户和服务器进程

网络应用程序由成对的进程组成, 这些进程通过网络相互发送报文. 对每对通信进程, 我们通常将这两个进程之一标记为 客户 , 另一个进程标识为 服务器

在一对进程之间的通信会话场景中, 发起通信的进程称为客户, 会话开始前等待通信的进程是服务器

2. 进程与计算机网络之间的接口

进程通过一个称为 套接字 的软件接口向网络发送报文和从网络接收报文

由于该套接字是建立网络应用程序的可编程接口, 因此套接字也称为应用程序和网络之间的 API

3. 进程寻址

在因特网中, 主机由其 IP地址 标识

在主机中用端口号标识进程

2.1.4 因特网提供的运输服务

1. TCP服务

TCP服务模型包括面向连接服务和可靠数据传输服务

• 面向连接的服务 在应用层数据报文开始流动之前, TCP让客户机和服务器相互交换运输层控制信息, 这个所谓的握手过程提醒客户机和服务器为大量分组的到来做好准备. 在握手之后一条 TCP连接 就在两个进程的套接字之间建立. 在应用程序结束报文发送时, 必须拆除该连接
• 可靠的数据传输服务 通信进程能够依靠TCP, 无差错, 按适当顺序交付所有发送到数据

当发送方和接收方的网络出现拥塞时, TCP拥塞控制机制会抑制发送进程, 同时也试图抑制每个TCP连接, 使它们达到公平共享网络带宽的目的

2. UDP服务

UDP是不提供不必要服务的轻量级运输协议, 仅提供最低限度的服务. UDP是无连接的, 因此在两个进程通信前没有握手过程, UDP也不保证该报文将到达接收进程, 不仅如此, 到达接收进程的报文也可能是乱序的

UDP不包括拥塞控制机制, 所以UDP的发送端可以用它选定的任何速率向其下层注入数据

2.1.5 应用层协议

应用层协议定义了以下内容

• 交换的报文类型, 例如请求报文和响应报文
• 各种报文类型的语法, 如报文中各个字段以及这些字段是如何描述的
• 字段的语义, 即这些字段中信息的含义
• 确定一个进程何时以及如何发送报文, 对报文进行响应的规则

2.2 Web和HTTP

2.2.1 HTTP概述

Web的应用层协议是 超文本传输协议(HTTP) , 它是Web的核心

HTTP由两个程序实现 : 一个客户程序和一个服务器程序, 客户程序和服务器程序分别运行在不同的端系统上, 通过交换HTTP报文进行会话

Web页面 是由对象组成的, 一个 对象 只是一个文件, 多数Web页面含有一个 HTML基本文件 以及几个引用对象

HTTP使用TCP作为他的支撑运输协议

HTTP客户首先发起一个与服务器的TCP连接, 一旦连接建立, 该浏览器和服务器进程就可以通过套接字接口访问TCP

一旦客户向它的套接字接口发送了一个请求报文, 这个报文就脱离了客户控制并进入TCP控制

服务器向客户发送被请求的文件, 而不存储客户的状态信息. 因为HTTP服务器并不保存关于客户的任何信息, 所以我们说HTTP是一个 无状态协议

2.2.2 非持续连接和持续连接

请求可以以规则的间隔周期性地或者间断性地一个接一个发出

采用前一种方法, 该应用程序称为使用 非持续连接 , 后一种方法则被称为采用 持续连接

1. 使用非持续连接的HTTP

往返时间(RTT) : 一个短分组从客户到服务器然后再返回客户所花费的时间, RTT包括分组传播时延, 分组在中间路由器和交换机的排队时延以及分组处理时延

三次握手的前两个部分所用的时间占用了一个RTT

一旦该请求报文到达服务器, 服务器就在该TCP连接上发送HTML文件, 该HTTP请求/相应用去了另一个RTT

总的响应时间等于两个RTT加上服务器传输HTML文件的时间

2. 使用持续连接的HTTP

在采用HTTP1.1的持续连接的情况下, 服务器在发送响应之后保持该TCP连接打开, 在相同的客户和服务器之间, 后续的请求和响应报文能够通过相同的连接进行传送.

2.2.3 HTTP报文格式

HTTP报文分为两种: 请求报文和响应报文

1. HTTP请求报文

下面是一个比较典型的HTTP请求报文

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Acccept-language: Fr

HTTP请求报文的第一行叫做 请求行 , 后续的行称为 首部行

请求行包括三个字段: 方法字段, URL字段, HTTP字段

方法字段可以取不同的值: GET POSED HEAD PUT DELETE

绝大多数HTTP请求报文使用GET方法

首部行"Host: www.someschool.edu" 指明了对象所在的主机

“Connection: close” 该客户机告诉服务器不要使用持续连接, 要求发送完请求的对象之后就关闭连接

"User-agent: " 首部行用于指明用户代理, 即向服务器发送请求的浏览器的类型

"Accept-language: " 首部行表示用户想要得到的语言版本

在首部行后面有一个实体体, 使用GET方法时实体体为空, 使用POST方法时才使用实体体, 当用户提交表单时, HTTP用户常常使用POST方法, 如果方法字段为POST, 则实体体内包含的就是用户在表单字段填写的值

2. HTTP响应报文

下面是一个比较典型的HTTP响应报文

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-length: 6821
Content-type: text/html

(data data data data ...)

HTTP响应报文由三个部分组成: 一个初始状态行, 6个首部行, 然后是实体体

实体体部分是报文段主要部分, 包括了请求的对象本身

状态行有三个字段, 协议版本字段 状态码 状态信息

“Connection: close” 首部行告诉客户, 发送完报文后将关闭TCP连接

"Date: " 首部行指示服务器产生并发送该响应报文的日期和时间

"Server: " 首部行指示该报文是由Apache Web服务器产生的, 运行的操作系统是CentOS, 类似于请求报文里的"User-agent: "字段

"Last-Modified: " 首部行指示该对象创建或最后修改的时间与日期

"Content-length: " 首部行指示了被发送对象中的字节数

"Content-type: " 首部行指示了实体体中的对象是HTML文本

---

常见状态码

200 OK : 请求成功

301 Moved Permanently : 请求的对象已永久转移, 客户软件会自动获取新的URL

客户机问题:

400 Bad Request : 差错通用代码, 表示请求不能被服务器理解

403 Forbidden : 请求被服务器拒绝

404 Not Found : 被请求的对象不在服务器上

服务器问题:

502 Bad Gateway : 作为网关的服务器试图向上游服务器传送请求时得到无效相应

504 Gateway Timeout : 作为网关或代理的服务器尝试执行请求时未能及时从上游服务器或DNS服务器获得相应

505 HTTP Version Not Suppoted : 服务器不支持该HTTP版本

---

2.2.4 cookie

cookie允许站点对用户进行追踪

cookie技术有四大组件: 1. 在HTTP响应报文中的一个cookie首部行 2. 在HTTP请求报文中的一个cookie首部行 3. 在用户端系统存储的一个cookie文件, 并由用户的浏览器进行管理 4. 位于Web服务器的一个后端数据库

2.2.5 Web缓存

Web缓存服务器 又称为 代理服务器 , 它是能够代表初始Web服务器来满足HTTP请求的网络实体

一旦某浏览器被配置, 每个对某对象的浏览器请求首先会被发送到该缓存服务器

过程如下

1. 浏览器创建一个到Web缓存服务器的TCP连接, 并向Web缓冲器中的对象发送一个TCP请求
2. Web缓存器进行检查, 查看本地是否保存了该对象副本, 如果有, Web缓存器就向客户浏览器用HTTP响应报文返回该对象
3. 如果Web缓存器中没有该对象, 它就打开一个与该对象的初始服务器的TCP连接. Web缓存器则在这个缓存器和服务器的TCP连接之间发送一个对该对象的TCP请求, 服务器收到请求之后就向该Web缓存器发送具有该对象的HTTP相应
4. 当Web缓存器接收到该对象时, 它在本地空间存储一份副本, 并向客户的浏览器用HTTP响应报文发送该副本

Web缓存器既是服务器又是客户

部署Web缓存器的原因: 1. Web缓存器可以大大减少对客户请求的响应时间 2. Web缓存器可以大大减少一个机构的接入链路到因特网的通信量

总的响应时间 : 从浏览器请求一个对象开始到接收到该对象为止的时间, 是局域网时延, 接入时延和因特网时延之和

+++

条件GET方法

HTTP有一种机制, 允许缓存器证实它的对象是最新的, 这个机制就是 条件GET . 如果HTTP请求报文使用条件GET方法, 并且请求报文中包含"If-modified-since: "首部行, 那么这个HTTP请求就是一个条件GET请求报文

2.3 因特网中的电子邮件

因特网邮件系统由三部分组成: 用户代理 , 邮件服务器 , 简单邮件传输协议(SMTP)

2.3.1 SMTP

假设Alice向Bob发送邮件

1. Alice调用邮件代理程序并提供Bob的邮件地址, 撰写报文然后指示代理发送报文
2. Alice的用户代理将报文发送到她的邮件服务器
3. 允许在Alice的邮件服务器上的SMTP客户发现了报文队列中的报文, 它创建一个运行在Bob的邮件服务器上SMTP服务的TCP连接
4. 经过TCP握手之后, SMTP通过TCP将报文发送到Bob的邮件服务器上
5. 在Bob的邮件服务器上, SMTP的服务i去接受该报文, Bob的邮件服务器然后将该报文放入Bob的邮箱
6. 在Bob方便的时候, 他通过调用邮件代理阅读报文

SMTP一般不通过中间的邮件服务器发生邮件

客户SMTP在25号端口建立一个到服务器SMTP的TCP连接, 如果服务器没有开机, 那么会稍后再尝试连接. 一旦连接建立, 服务器和客户就会进行应用层上的握手. 在SMTP握手的阶段, SMTP指示发送方的邮件地址和接收方的邮件地址, 一旦该SMTP服务器和客户彼此介绍之后, 客户发送该报文, SMTP能够依靠TCP提供的可靠数据传输无差错地将邮件传输到服务器. 如果有另外的报文需要发送到该服务器, 就在重复的TCP连接上进行处理, 否则将关闭连接

2.3.3 邮件访问协议

邮件服务器具有HTTP接口和SMTP接口, 或者使用由RFC 3501定义的 因特网邮件访问协议

2.4 DNS

主机的一种标识方法是用 主机名

主机名可能由不定长的字母数字组成, 路由难以处理. 因此主机也可以使用所谓的 IP地址 进行标识

2.4.1 DNS提供的服务

域名系统(DNS) 的主要任务: 提供主机名到IP地址的转换

DNS是: 1.一个由分层的 DNS服务器 实现的分布式数据库 2. 一个使得主机能够查询分布式数据库的应用层协议

DNS协议运行在UDP之上, 使用53号端口

假设用户机想要发送HTTP请求报文到服务器www.someschool.edu上, 该用户机必须获得服务器的IP地址

做法如下

1. 浏览器从URL中抽取主机名www.someschool.edu, 把主机名传给本地DNS客户端
2. DNS客户端向DNS服务器发送一个包含主机名的请求
3. DNS客户最终会得到一个响应报文, 其中含有对应该主机名的IP地址
4. DNS客户端将IP地址传回浏览器, 浏览器向位于该IP地址80端口的Web服务器进程发起一个TCP连接

除了进行主机名到IP地址的转换外, DNS还提供了以下重要的服务

1. 主机别名 应用程序可以通过调用DNS获得主机别名对应的规范主机名以及对应的IP地址
2. 邮件服务器别名 电子邮件应用程序可以调用DNS, 对提供的主机别名进行解析, 获得规范主机名和IP地址
3. 负载均衡 DNS也用于冗余的服务器之间进行负载均衡

2.4.2 DNS工作机理概述

DNS的简单设计是在因特网上只使用一台DNS服务器, 该服务器包含所有的映射, 但是这种集中式设计带来的问题很多, 包括

1. 单点故障 如果该DNS服务器崩溃, 因特网也会随之瘫痪
2. 通信容量 单个DNS服务器不得不处理所有的DNS查询
3. 远距离的集中式数据库 这将导致严重的时延
4. 维护 单个DNS服务器部分不为所有的因特网主机保留记录. 这不仅将使这个中央数据库无比庞大, 而且它还不得不为新添加的主机记录而频繁更新

在单一DNS服务器上运行集中式数据库没有可拓展能力

1. 分布式, 层次数据库

为了解决拓展性问题, DNS使用了大量的DNS服务器, 以层次方法组织, 并分布在全世界范围内

大致有三种DNS服务器: 根DNS服务器, 顶级域DNS服务器, 权威DNS服务器

• 根DNS服务器 根服务器提供顶级域DNS服务器的IP地址
• 顶级域DNS服务器 对于每个顶级域(如.com, .edu, .gov)和所有国家的顶级域(如uk, fr, cn, jp), 都有顶级域服务器
• 权威DNS服务器 在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的DNS记录, 这些记录将这些主机的名字映射为IP地址, 一个组织机构的权威DNS服务器收藏了这些DNS记录

2. DNS缓存

为了改善时延性能并减少在因特网上传输的DNS报文数量, 在一个请求链中, 当某DNS服务器接受一个DNS回答时, 它就能将该映射缓存在本地存储器中, 由于主机名和IP地址之间的映射并不是永久的, DNS服务器在一段时间后会丢弃缓存的信息

2.4.3 DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了 资源记录(RR) , RR提供了主机名到IP地址的映射, 每个DNS回答报文包含了一条或多条资源记录

资源记录是一个包含了下列字段的四元组

{Name, Value, Type, TTL}

TTL是该记录的生存时间, 它决定了资源记录应当从缓存中删除的时间

• 如果Type = A, 则对主机名而言 Name是主机名, Value是该主机名对应的IP地址
• 如果Type = B, 则对该域内的主机而言 Name是域, Value是一个知道如何获得域中主机IP地址的权威DNS服务器的主机名
• 如果Type = CNAME, 则 Value 是主机别名 Name对应的规范主机名
• 如果Type = MX, 则Value是一个别名为Name的邮件服务器的规范主机名

如果一台DNS服务器是某特定主机名的权威DNS服务器, 那么该DNS服务器会有一条包含用于该主机的类型A记录

1. DNS报文

DNS只有请求和响应报文, 并且两种报文有相同的格式

DNS报文中各字段的语义为

• 前12字节为 首部区域 , 里面有几个字段. 标识字段是一个16比特的数, 用于标识该查询. 标识字段中有若干标志, 1比特的"查询回答"标志位指出报文是查询报文(0)还是回答报文(1); 当某DNS服务器是所请求名字的权威DNS服务器时, 1比特的"权威"标志位被置在回答中; 如果客户(主机或DNS服务器)在该DNS服务器没有某记录时希望执行递归查询, 将设置1比特的"希望递归"标志位; 如果该DNS服务器支持递归查询, 在它的回答报文中会对1比特的"递归可用"标志设置位
• 问题区域 包含了正在进行的查询信息, 包括: 1. 名字字段, 包括正在查询的主机名字; 2. 类型字段, 指出有关该名字的正被询问的问题类型, 例如主机地址是与一个名字相关联(类型A)还是与某个名字的邮件服务器相关联(类型MX)
• 来自DNS服务器的回答中, 回答区域 包含了对最初请求的名字的资源记录
• 权威区域 包含了其他权威服务器的记录
• 附加信息区域 包含了其他有帮助的记录

2.5 P2P文件分发

1. P2P体系的拓展性

假设 $u_s$ 表示服务器接入链路的上载速率, $u_i$ 表示第 $i$ 对等方接入链路的上载速率, $d_i$ 表示第 $i$ 对对等方接受链路的下载速率, $F$ 表示被分发的文件长度, $N$ 表示要获得该文件副本的对等方的数量

分发时间 是所有 $N$ 个对等方得到该文件的副本所需要的时间

下面是使用客户-服务器体系结构的情况, 分发时间表示为 $D_{cs}$

• 服务器必须向 $N$ 个对等方的每个传输该文件的一个副本. 因此该服务器必须传输 $NF$ bit. 因为该服务器的上载速率是 $u_s$ , 分发该文件的时间必定至少为 $NF/u_s$
• 令 $d_{min}$ 表示具有最小下载速率的对等方的下载速率, 即 $d_{min}=\min d_1,d_p,\cdots ,d_n$ . 具有最小下载速率的对等方不可能在小于 $F/d_{min}$ s的时间内获得该文件的所有 $F$ bit. 因此最小分发时间至少为 $F/d_{min}$

综上, $D_{cs}\ge \max NF/u_s,F/d_{min}$

对于足够大的 $N$ , 客户-服务器分发时间由 $NF/u$ 确定. 分发时间随着对等方 $N$ 的数量线性增加

下面是使用P2P体系结构的情况, 分发时间表示为 $D_{P2P}$

• 在分发的开始, 只有服务器有文件. 为了使社区的对等方获得该文件, 服务器必须经其接入链路至少发送该文件的每个比特一次. 因此最小分发时间至少为 $F/u_s$
• 与客户-服务器体系结构相同, 具有最低下载速率的对等方不能以小于 $F/d_{min}$ s的分发时间获得所有 $F$ bit, 因此最小分发时间至少为 $F/d_{min}$
• 最后, 观察到系统整体的总上载能力等于服务器的上载速率加上每个单独的对等方的上载速率, 即 $u_{total}=u_s+u_1+\cdots +u_N$ , 最小分发时间也应该至少是 $NF/u_{total}$

综上, $D_{P2P}\ge \max F/u_s,F/d_{min},NF/u_{total}$