南理工计算机考研笔试第二章 应用层Word格式文档下载.docx

南理工计算机考研笔试第二章 应用层Word格式文档下载.docx

《南理工计算机考研笔试第二章 应用层Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《南理工计算机考研笔试第二章 应用层Word格式文档下载.docx（47页珍藏版）》请在冰点文库上搜索。

不要求任何主机总是打开；

参与的主机每当加入时都有可能改变其IP地址。

可扩展性。

难于管理。

客户机/服务器和P2P体系结构的混合：

如：

Napster（MP3文件共享）和即时讯息应用程序。

2.1.2进程通信

进程（process）：

运行在端系统中的程序。

相同端系统中进程间通信：

由操作系统控制；

不同端系统上进程间通信：

通过跨网络交换报文（message）通信。

发送进程：

产生报文并向网络发送；

接收进程：

接收报文，并回送报文。

如图2-1。

1、客户机和服务器进程

网络应用程序由成对的进程组成，并通过网络相互发送报文。

一个客户机浏览器进程与一个服务器进程交换报文。

两个通信进程分别标示为客户机和服务器。

浏览器是一个客户机进程，Web服务器是一个服务器进程。

P2P文件共享：

下载文件的对等方标示为客户机，上载文件的对等方标示为服务器。

一个进程可以是客户机，也可能是服务器。

客户机：

发起通信（即在会话开始时，开始与其他进程联系）的进程。

服务器：

在会话开始时等待其他进程联系的进程。

如，Web中：

一个浏览器进程向某个Web服务器进程发起联系。

客户机服务器

P2P文件共享：

对等方A请求对等方B发送某个文件。

2、套接字

进程通过它的套接字在网络上发送和接收报文。

关系：

进程比作房子，套接字是进程的门户。

如图2-3。

发送进程：

把报文推出门户（套接字）。

（发送报文）

传送报文：

通过下面网络把报文传送到目的进程门口。

接收进程：

通过其门户（套接字）接收。

（接收报文）

套接字（socket）：

是同一台主机内应用层与运输层之间的接口。

是在网络上建立网络应用程序的可编程接口，也叫应用程序和网络之间的应用程序接口API（applicationprogrammer’sinterface）。

应用程序开发者可以控制套接字应用层端的全部；

对该套接字的运输层端几乎不能控制（只能选择运输层协议、设定几个运输层参数等）。

应用程序开发者选择了一个运输层协议，则应用程序就建立在由该协议提供的运输层服务之上。

3、进程寻址

主机上的进程有多个。

需要区分每一个进程。

源主机上的进程向目的主机上的进程发送报文时，应带有接收进程的识别信息。

网络中的主机有多个，每个主机上有多个进程。

进程寻址过程：

确定主机确定进程

进程识别信息：

主机名称或地址：

网络中的哪一个主机。

因特网中，主机用IP地址进行标识（32位，全球惟一）。

进程的标识：

主机中的哪一个进程。

因特网中，采用端口号（portnumber）。

常用的应用程序被指派专门的端口号（周知端口）。

例如：

Web服务进程（HTTP协议）用的是80号端口；

邮件服务进程（SMTP协议）用的是25号端口。

创建一个新的网络应用程序时，必须赋予一个新的端口号。

4、用户代理（useragent）

是用户与网络应用程序之间的接口。

例如，

Web应用的用户代理：

是一些浏览器软件。

一个通过套接字收发报文同时提供用户接口的进程。

电子邮件应用程序用户代理：

是“邮件阅读器”。

允许用户进行邮件的撰写和阅读。

2.1.3应用层协议

应用层协议：

定义了运行在不同端系统上的应用程序进程间互相传递报文的方式。

具体内容：

交换的报文类型：

如请求报文和响应报文；

各种报文类型的语法：

如报文中的各个字段及其详细描述；

字段的语义：

即字段包含信息的含义；

进程何时、如何发送报文及对报文进行响应的规则。

说明：

标准文档RFC文档定义的协议，可应用于公共领域。

如HTTP。

专用应用层协议，如P2P使用的协议。

应用层协议是网络应用的一部分。

例如，Web应用：

是一种允许客户机按照需求从Web服务器获得“文档”的网络应用。

组成包括：

HTML、Web浏览器、Web服务器程序，以及一个应用层协议HTTP（超文本传输协议）等部分。

HTTP定义了在浏览器程序和Web服务器程序间传输的报文格式和序列。

2.1.4应用所需要的服务

套接字：

是应用程序进程和运输协议之间的接口（门户）。

发送端的应用程序通过该门户发出报文，由运输协议跨越网络将报文传输到接收进程的门户。

网络应用需要使用运输协议所提供的服务。

运输协议有多种，提供的服务不同，需适当选择。

应用程序服务要求：

可靠的数据传输

即无数据丢失。

数据不能丢失的应用：

如文件传输、电子邮件及金融事务等。

能容忍数据丢失的应用（loss-tolerantapplication）：

如多媒体应用。

带宽

有些应用必须以特定的速率传输数据。

带宽敏感的应用（bandwidth-sensitiveapplication）：

需要特定的带宽才能正常工作。

如，因特网电话、其他多媒体应用；

弹性应用（elasticapplication）：

使用的带宽多或少影响不大。

如电子邮件、文件传输以及Web传输。

定时

有些应用对数据传输有严格的时间限制。

交互式实时应用：

对时间敏感，要求端到端时延在几百毫秒或更小。

如，因特网电话、虚拟环境、视频会议以及多方游戏等。

非实时应用：

端到端时延无约束，时延低更好。

图2-4总结了一些流行的和新兴的因特网应用三方面的要求。

2.1.5因特网运输协议提供的服务

两个运输层协议：

用户数据报协议UDP（UserDatagrameProtocol）和传输控制协议TCP（TransmissionControlProtocol）。

每个协议为调用它们的应用程序提供不同的服务模型。

在创建一个新的因特网应用时，要选择其中一个。

1、TCP服务

提供的服务：

面向连接的服务：

三阶段

建立连接（握手过程）：

客户机程序和服务器程序之间互相交换控制信息，在两个进程的套接字之间建立一个TCP连接。

传输报文：

连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。

拆除连接：

应用程序报文发送结束。

可靠的传输服务：

通信进程以无差错、按适当顺序交付发送的数据。

拥塞控制：

当发送方和接收方之间的网络出现拥塞时，会抑制发送进程速率。

TCP协议不适合实时应用。

未提供的服务：

没有确保最小传输速率：

发送进程受拥塞控制机制制约；

不提供时延保证：

数据传输的时间不确定。

结论：

TCP协议能保证交付所有的数据，但并不保证这些数据传输的速率以及期待的传输时延。

2、UDP服务

提供最小服务模式运行。

无连接：

两个进程通信前没有握手过程；

不可靠数据传输：

不保证报文能够被接收，或收到的报文是乱序到达。

没有拥塞控制机制：

发送进程可以任何速率发送数据；

不提供时延保证：

适于实时应用。

图2-5列出一些因特网应用及所用的协议。

2.1.6本书介绍的网络应用

Web、文件传输、电子邮件、目录服务、对等文件共享等五个。

2.2Web应用和HTTP协议

Web产生于20世纪90年代初期。

改变了人们与工作环境内外的交流方式；

提升因特网地位；

生活和工作发生变化；

方便、快捷得到所需要的信息；

任何人在Web上发布信息；

超链接和搜索引擎帮助人们浏览Web站点。

2.2.1HTTP概况

HTTP（超文本传输协议）：

应用层协议，是Web的核心。

组成：

客户机程序和服务器程序，分别运行在不同的端系统中，通过交换HTTP报文进行会话。

HTTP协议定义了报文的格式以及客户机和服务器进行报文交换的方式。

Web常用术语：

Web页（文档）：

由对象组成。

对象：

是文件。

通过一个URL地址来寻址。

如HTML文件、JPEG图形文件、Java小程序等。

Web页含有一个基本的HTML文件及几个引用对象。

例如，一个Web页包含HTML文本和5个JPEG图形文件（即有6个对象）。

在基本的HTML文件中，通过对象的URL地址来引用。

URL地址组成：

存放对象的服务器主机名和对象的路径名

如http:

//www.someSchool.edu/somedepartment/picture.gif

主机名路径名

浏览器（客户机）：

是Web应用的用户代理，用于显示所请求的Web页，提供导航功能和配置属性。

实现了HTTP协议的客户机端。

Web服务器：

用于存贮Web对象（由URL寻址），实现HTTP协议的服务器端。

HTTP协议定义Web客户机（浏览器）如何向Web站点请求Web页，以及服务器如何将Web页传送给客户机。

客户机和服务器之间交互过程：

如图2-6。

客户机：

用户请求一个Web页（如点击一个超链接），浏览器向服务器发出对该页所含对象的“HTTP请求报文”；

服务器：

接受请求，并用包含这些对象的“HTTP响应报文”响应。

HTTP版本：

HTTP1.0：

1997年前使用。

HTTP1.1：

1998年以后使用，向下兼容，目前占主导。

HTTP协议使用的底层运输协议是TCP。

HTTP客户机先与服务器建立TCP连接，然后，浏览器和服务器进程通过套接字访问TCP：

如图2-3

客户机的套接字接口是客户机进程与TCP连接之间的“门户”，客户机从该套接字接口发送“HTTP请求报文”和“接收响应报文”；

服务器的套接字接口是服务器进程与TCP连接之间的“门户”，服务器从该套接字口接收“HTTP请求报文”和“发送响应报文”。

TCP提供可靠的数据传输服务：

客户机进程和服务器进程发出的每个HTTP报文能完整地到达对方。

HTTP是无状态协议：

服务器不保存关于客户机的任何信息。

Web使用客户机／服务器结构，Web服务器总是打开，有一个固定IP地址，为多个浏览器服务。

2.2.2非持久连接和持久连接

1、非持久连接：

例，从服务器向客户机传送Web页：

设该页含有一个基本HTML文件和10个JPEG图形，11个对象位于同一个服务器上。

HTML文件的URL为：

http:

//www.someSchool.edu/someDepartment/home.index

步骤：

建立TCP连接：

客户机在端口号80（HTTP的默认端口）发起一个到指定服务器的TCP连接；

客户机发出“HTTP请求报文”（含路径名）：

通过与该TCP连接绑定的套接字向服务器发送；

服务器会送“HTTP响应报文”：

通过与该连接绑定的套接字获取请求报文，从存储器中检索出相关对象，封装成响应报文，通过其套接字向客户机发送；

断开TCP连接：

服务器通知TCP断开（在确认客户机已经收到响应报文时真正断开）；

客户机收到响应报文，TCP连接关闭。

客户机从响应报文中提取出HTML文件，得到对10个图形的引用；

对每个对象重复前4步。

浏览器收到Web页后，将该页显示给用户。

不同的浏览器显示形式可能不同，HTTP协议不负责浏览器的解释。

每个TCP连接在服务器返回对象后关闭（非持久）。

每个TCP连接只传输一个请求报文和一个响应报文；

上例中，要建立11个TCP连接。

浏览器可同时打开多个连接：

并行的TCP连接：

并行数大于1。

默认打开5～10个。

串行的TCP连接：

最大并行数为1。

请求一个HTML文件所需时间：

即从客户机请求基本HTML文件开始，到用户收到整个文件为止所花时间。

往返时延RTT：

一个小分组从客户机到服务器，再回到客户机所花时间。

包括传播时延、排队时延以及处理时延。

如图2.7。

“三次握手”过程：

客户机发送一个小TCP报文段到服务器服务器回送一个小TCP报文段做出确认和响应客户机向服务器返回确认（“请求”与“确认”结合）

总响应时间：

两个RTT时延加上服务器发送文件的时间

非持久连接缺点：

服务器负担重：

每一个请求对象建立和维护一个新的连接。

每一个对象的传输时延长：

包含两个RTT时延，一个用于TCP建立，一个用于请求和接收对象。

2、持久连接

服务器在发送响应后保持该TCP连接：

相同客户机与服务器之间的后续请求和响应报文通过相同的连接进行传送。

如，一个Web页的所有对象可以通过一个持久TCP连接传送。

或同一服务器上的多个Web页也可以通过一个持久TCP连接传送给同一个客户机。

连接经一定时间间隔（超时间隔）未被使用，服务器就关闭该连接。

持久连接两种方式：

非流水线方式（withoutpipelining）：

客户机只能在前一个响应接收到之后才能发出新的请求。

客户机为每一个引用对象的请求和接收只使用一个RTT时延。

会浪费一些服务器资源：

服务器在发送完一个对象，等待下一个请求时，会出现空闲状态。

流水线方式（withpipelining）：

客户机可一个接一个连续产生请求（只要有引用就产生），即在前一个请求接收到响应之前可以产生新的请求。

服务器一个接一个连续发送相应对象。

所有引用对象可能只花费一个RTT时延。

TCP连接空闲时间很短。

HTTP1.1默认方式：

流水线方式的持久连接。

2.2.3HTTP报文格式

两种报文：

HTTP请求报文、HTTP响应报文。

2.2.4用户与服务器交互：

Cookie

HTTP服务器是无状态的。

Cookie目的：

允许Web站点跟踪、识别用户；

服务器可以限制用户访问，或把内容与用户身份关联。

2.2.5HTTP内容

传输Web页面所含对象：

如HTML文件、JPEG文件、Java小应用程序等等。

可以传输其他类型的文件：

如传输XML（可扩充的标识语言）文件。

P2P文件共享中，作为文件传输协议使用。

用于流式存储的音频和视频。

2.2.6Web缓存

Web缓存器（Webcache）：

也叫代理服务器（proxyserver）。

是能够代表起始服务器来满足HTTP请求的网络实体。

保存最近请求过的对象的副本。

起始服务器（originserver）：

对象起始放置，并且在其中始终保持对象拷贝的服务器。

客户机通过Web缓存器请求对象：

如图2-10。

对用户浏览器进行配置，使用户的所有HTTP请求均首先指向该Web缓存器，即浏览器对每一个对象的请求首先被定向到该Web缓存器。

操作过程：

例：

假设浏览器请求对象http:

//www.someschool.edu/campus.gif

浏览器：

建立一个到该Web缓存器的TCP连接，并向Web缓存器中的该对象发送一个HTTP请求；

Web缓存器：

检查本地是否存储了该对象的拷贝。

有：

缓存器就用HTTP响应报文向客户机浏览器转发该对象；

没有：

与该对象的起始服务器打开一个TCP连接。

客户机Web缓存器起始服务器

Web缓存器在TCP连接上发送获取该对象的请求。

起始服务器收到请求，向Web缓存器发送具有该对象的HTTP响应。

Web缓存器接收该对象，存储一份在本地中，并通过HTTP响应报文向客户机浏览器转发该对象（通过已经建立的TCP连接）。

Web缓存器既可以是服务器也可以是客户机：

当它接收浏览器请求并发回响应时，是服务器；

当它向起始服务器发出请求并接收响应时，是客户机。

Web缓存器由ISP购买并安装：

例如，在大学校园网上安装。

Web缓存优点：

减少对客户机请求的响应时间：

减少机构的内部网络与因特网连接链路上的通信量：

降低开销，改善各种应用的性能。

例图2-11，包括两个网络：

机构的内部网络和因特网。

机构内部网络：

是一个高速的局域网。

其路由器与因特网上的路由器通过一条1.5Mbps的链路连接。

起始服务器：

与因特网相连，遍布全球。

假设：

对象长度为100kb，机构内浏览器对对象的平均访问速率为每秒15个请求；

机构内的HTTP报文小，可以忽略，不会在网络中以及接入链路（从机构内部路由器到因特网路由器）上产生通信量；

从因特网路由器转发HTTP请求报文，到收到其响应报文的时间平均为2s（因特网时延）。

总的响应时间（浏览器从请求一个对象到接收到的时间）：

局域网时延+接入链路时延（两个路由器之间的时延）+因特网时延

局域网流量强度：

（15请求/s）×

（100kb/请求）/（10Mbit/s）=0.15

接入链路的流量强度（从因特网路由器到机构路由器）：

（15请求/s）×

（100kb/请求）/（1.5Mbit/s）=1

局域网时延：

强度为0.15的通信量最多导致数十毫秒的时延，可以忽略。

接入链路时延：

流量强度接近1，链路时延会非常大或无限增长。

总响应时间=接入链路时延+因特网时延

造成满足请求的平均响应时间以分钟计，用户很难接受。

改进方法一：

增加接入链路的速率，如从1.5Mbps增加到10Mbps，使链路上的流量强度减少到0.15，链路时延也可以忽略了。

总响应时间=因特网时延=2秒钟

机构必须用较大投资，成本昂贵。

改进方法二：

在机构网络中安装一个Web缓存器。

如图2-12。

Web缓存器的命中率：

缓存器满足请求的比率。

通常为0.2～0.7。

设该机构缓存器的命中率为0.4。

由于客户机和缓存器位于同一个高速局域网上，40%的请求几乎会立即得到响应，时延约在10ms以内。

剩下的60%请求需要通过访问起始服务器才能满足。

只有60%的请求对象通过接入链路传送，流量强度从1.0减小到0.6。

通常，在1.5Mbps链路上，当流量强度小于0.8时，时延很小（约几十毫秒），可忽略。

平均时延为：

0.4×

（0.010s）+0.6×

（2s+0.01s）=1.21s

响应时延低于第一种解决方案（约2s）。

Web缓存器成本低：

通过在PC机上运行公共领域软件。

2.2.7条件GET方法

高速缓存能减少用户感受到的响应时间，但存放在缓存中的对象拷贝可能是陈旧的。

即保存在服务器中的对象可能已经被修改。

条件GET方法：

允许缓存器证实其对象都是最新的。

一个代理服务器代表一个请求浏览器，向某个Web服务器发送一个请求报文：

GET/fruit/kiwi.gifHTTP/l.1

Host:

该Web服务器向该缓存器发送携带被请求对象的响应报文：

缓存器在将对象转发到其他浏览器的同时，也将该对象保存到本地缓存中（包括对象的最后修改时间）。

一个星期后，用户再次请求该对象（仍保留在缓存中），为检查位于Web服务器中的该对象是否已经被修改，缓存器发送一个条件GET：

告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。

设该对象自指定日期后未被修改，Web服务器向该缓存器发送一个响应报文：

该Web服务器发送一个响应报文，但并没有包含所请求的对象，并指出该对象未修改，缓存器可以使用该对象的拷贝。

2.3文件传输协议：

FTP

FTP会话：

位于本地主机上的用户，向远程主机上传或者下载文件。

用户通过一个FTP用户代理与FTP服务器交互，过程如图2-13。

用户提供远程主机的主机名：

在本地主机的FTP客户机进程与远程主机FTP服务器进程之间建立一个TCP连接；

提供用户标识和口令：

在该TCP连接上向服务器传送。

服务器验证通过后，进行文件传送（双向）：

将本地文件系统中的文件传送到远程文件系统；

从远程文件系统中得到文件。

FTP与HTTP共同点：

都是文件传输协议，并运行在TCP上。

主要区别：

FTP使用了两个并行的TCP连接：

控制连接（controlconnection）：

用于在两主机间传输控制信息（如用户标识、口令等）；

在用户主机与远程主机开始FTP会话前，FTP的客户机与服务器在21号端口上建立一个用于控制的TCP连接。

FTP的客户机通过该连接发送用户标识和口令，或改变远程目录的命令。

数据连接（dataconnection）：

用于准确传输文件。

当FTP的服务器从该连接上收到一个文件传输的命令后（从远程主机上读或写），就发起一个到客户机的数据连接。

在该数据连接上准确地传送一个文件并关闭连接。

控制连接是持久的：

在整个用户会话期间一直保持；

数据连接是非持久的：

会话中每进行一次文件传输，都需要建立一个新的数据连接。

FTP的控制信息是带外传送（out-of-band）：

使用分离的控制连接；

HTTP的控制信息是带内传输（in-band）：

请求和响应都是在传输文件的TCP连接中发送。

FTP协议是有状态的：

FTP服务器对每个活动用户会话的状态进行追踪，并保留；

限制同时会话的总数。

HTTP协议是无状态的：

不对用户状态进行追踪。

2.4因特网中的电子邮件

电子邮件快速，便宜，可以一次发送给多个接收方，包含附件、超链接、图像、声音、视频等等。

本节讨论电子邮件的核心，即应用层协议。

因特网电子邮件系统的总体结构：

用户代理、邮件服务器和简单邮件传输协议SMTP。

如图2-15。

1、用户代理（user　agent）

也叫邮件阅读器。

允许用户阅读、回复、发送、保存和撰写报文。

当用户完成邮件撰写时，邮件代理向其邮件服务器发送邮件，并存放在发送队列中。

当用户想读取一条报文时，邮件代理从其邮件服务器的邮箱中获取该报文。

用户代理种类：

GUI（图