- 1SpringBoot学习之Redis下载安装启动【Mac版本】（三十七）_mac redis下载
- 2【Python入门篇】——Python中循环语句（while循环的基础语法和基础案例）_python while循环语句
- 3iOS 常用第三方库
- 4SpringCloud-搭建XXL-JOB任务调度平台教程_xxljob搭建详解
- 5【计算机视觉 | 图像分类】图像分类常用数据集及其介绍（一）_图像分类数据集
- 6python 自然语言处理 第二章_python conditionalfreqdist()
- 7git在push时non-fast-forward 或 fetch first报错解决_git push fetch first
- 8二叉树的多种建立方式
- 9职业资格题不会怎么搜答案？6个受欢迎的搜题分享了 #职场发展#微信_职测搜题
- 10HarmonyOS实战开发-如何在鸿蒙开发中使用数据库_鸿蒙开发创建的数据库在哪个位置
计算机网络chapter2——应用层
赞
踩
文章目录
第2章 应用层
章节引出——
网络应用是计算机网络存在的理由。
在本章中，我们学习有关网络应用的原理和实现方面的知识。我们从定义关键的应用层概念开始，其中包括应用程序所需要的网络服务、客户和服务器、进程和运输层接口。我们详细考察几种网络应用程序，包括Web、电子邮件、DNS、对等文件分发和视频流(第9章关注多媒体应用，包括流式视频和VoIP)。然后我们将涉及开发运行在TCP和UDP上的网络应用程序。
2.1应用层协议原理
研发新应用程序时，你需要编写将在多台端系统上运行的软件。重要的是，你不需要写在网络核心设备如路由器或链路层交换机上运行的软件。即使你要为网络核心设备写应用程序软件，你也不能做到这一点。如我们在第1章所知，以及如图1-24所显示的那样，网络核心设备并不在应用层上起作用，而仅在较低层起作用，特别是在网络层及下面层次起作用。
2.1.1 网络应用程序体系结构
规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序者很可能利用现代网络应用程序中所使用的两种主流体系结构之一:
客户-服务器体系结构或对等(P2P)体系结构。
（1）客户-服务器体系结构
在客户-服务器体系结构(client-server architecture)中，有一个总是打开的主机称服务器，它服务于来自许多其他称为客户的主机的请求。一个典型的例子是Web应厢序，其中总是打开的Web服务器服务于来自浏览器(运行在客户主机上)的请求Web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为应。值得注意的是利用客户-服务器体系结构，客户相互之间不直接通信;例如，在应用中两个浏览器并不直接通信。客户-服务器体系结构的另一个特征是该服务器具有定的、周知的地址，该地址称为PP地址)(我们将很快讨论它)。因为该服务器具有的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的址发送分组来与其联系。具有客户-服务器体系结构的非常著名的应用程序包括WFTP、Telnet和电子邮件。图2-2a中显示了这种客户-服务器体系结构。
在一个客户-服务器应用中，常常会出现一台单独的服务器主机跟不上它所有客户求的情况。例如，一个流行的社交网络站点如果仅有一台服务器来处理所有请求，将很变得不堪重负。为此，配备大量主机的数据中心(datacenter)常被用于创建强大的虚服务器。最为流行的因特网服务——如搜索引擎(如谷歌、Bing和百度)、因特网商(如亚马逊、e-Bay和阿里巴巴)、基于Web的电子邮件(如 Gmail 和雅虎邮件)、社交网络(如脸书、Instagram、推特和微信)，就应用了一个或多个数据中心。如在 1.3.3节所讨论的那样，谷歌有分布于全世界的30~50个数据中心，这些数据中心共同处理搜察YouTube、Gmail 和其他服务。一个数据中心能够有数十万台服务器，它们必须要供电维护。
（2）对等(P2P)体系结构
在一个 P2P体系结构(P2Parchitecture)中，对位于数据中心的专用服务器有最小的或者没有依赖。
相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。许多目前流行的、流量密集型应用都是P2P体系结构的。这些应用包括文件共享(例如BitTorrent)、对等方协助下载加速器(例如迅雷)、因特网电话和视频会议(例如Skype)。图2-2b中显示了P2P的体系结构。需要提及的是，某些应用具有混合的体系结构，它结合了客户-服务器和P2P的元素。例如，对于许多即时讯息应用而言，服务器被用于跟踪用户的IP地址，但用户到用户的报文在用户主机之间(无须通过中间服务器)直接发送。
P2P体系结构的最引人人胜的特性之一是它们的自扩展性(self-scalability)。例如在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。P2P体系结构也是有成本效率的，因为它们通常不需要庞大的服务器基础设施和服务器带宽(这与具有数据中心的客户-服务器设计形成鲜明对比)。然而，未来P2P应用由于高度非集中式结构，面临安全性、性能和可靠性等挑战。
2.1.2 进程通信
在构建网络应用程序前，还需要对运行在多个端系统上的程序是如何互相通信的情况有一个基本了解。
用操作系统的术语来说，进行通信的实际上是进程(process)而不是程序。一个进程可以被认为是运行在端系统中的一个程序。当多个进程运行在相同的端系统上时，它们使用进程间通信机制相互通信。进程间通信的规则由端系统上的操作系统确定。而在本书中，我们并不特别关注同一台主机上的进程间的通信，而关注运行在不同端系统(可能具有不同的操作系统)上的进程间的通信。
在两个不同端系统上的进程，通过跨越计算机网络交换报文(message)而相互通信。发送进程生成并向网络中发送报文;接收进程接收这些报文并可能通过回送报文进行响应。图2-1显示了驻留在5层协议栈的应用层进程互相通信的情况。
1.客户和服务器进程
网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。例如，在Web应用程序中，一个客户浏览器进程与一台Web服务器进程交换报文。在一个P2P文件共享系统中，文件从一个对等方中的进程传输到另一个对等方中的进程。对每对通信进程，我们通常将这两个进程之一标识为客户(client)，而另一个进程标识为服务器(server)。
对于 Web而言，浏览器是一个客户进程，Web服务器是一台服务器进程。对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方标识为服务器。你或许已经观察到，如在P2P文件共享的某些应用中，一个进程能够既是客户又是服务器。在P2P文件共享系统中，一个进程的确既能上载文件又能下载文件。无论如何，在任何给定的一对进程之间的通信会话场景中，我们仍能将一个进程标识为客户，另一个进程标识为服务器。我们定义客户和服务器进程如下:
在一对进程之间的通信会话场景中，发起通信(即在该会话开始时发起与其他进程的联系)的进程被标识为客户，在会话开始时等待联系的进程是服务器。
2.进程与计算机网络之间的接口
如上所述，多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字(Socket)的软件接口向网络发送报文和从网络接收报文。我们考虑一个类比来帮助我们理解套接字。电脑相当于一个小区，进程可类比于一座房子，里面有很多房子（65536），而它的套接字可以类比于它的门，当一个进程相位于另外一台主机上的另一个进程发送报文时，它把报文推出该门(套接字)。该进程假定该门到另外一侧之间有运输的基础设施，该设施将把报文传送到目的进程的门一旦该报文抵达目的主机，它通过接收进程的门(套接字)传递，然后接收进程对该据进行处理。
图2-3显示了两个经过因特网通信的进程之间的套接字通信(图2-3中假定由该使用的下面运输层协议是因特网的TCP协议)。如该图所示，套接字是同一台主机内层与运输层之间的接口。
由于该套接字是建立网络应用程序的可编程接口，因此套接称为应用程序和网络之间的应用程序编程接口(ApplicationProgramming Interface，API)。
应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没控制权。应用程序开发者对于运输层的控制仅限于:①选择运输层协议;②也许能设定几个运输层参数，如最大缓存和最大报文段长度等(将在第3章中涉及)。一旦应用程发者选择了一个运输层协议(如果可供选择的话)，则应用程序就建立在由该协议提供运输层服务之上。
3. 进程寻址
为了向特定目的地发送邮政邮件，目的地需要有一个地址。类似地，在一台主机上行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了识该接收进程，需要定义两种信息:①主机的地址;②在目的主机中指定接收进程的识符。
在因特网中，主机由其IP地址(IP address)标识。我们将在第4章中非常详细地讨论IP 地址。此时，我们只要知道I地址是一个32 比特的量且它能够唯一地标识该主机就够了。除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程(更具体地说，接收套接字)。因为一般而言一台主机能够运行许多网络应用这些信息是需要的。目的地端口号/pont number)用于这个目的。已经给流行的应用分配了特定的端口号。例如，Web服务器用端口号80来标识。邮件服务器进程(使用SMTP协议)用端口号25来标识。用于所有因特网标准协议的周知端口号的列表能够在htp:/www.iana.org 处找到。我们将在第3章中详细学习端口号。
2.1.3 可供应用程序使用的运输服务
课程引出——
前面讲过套接字是(应用程序进程和传输层协议之间的接口。在发送端的应用程序将报文推进该套接字。在该套接字的另一侧，运输层协议负责从接收进程的套接字得到该报文。包括因特网在内的很多网络提供了不止一种运输层协议。当开发一个应用时，必须选择一种可用的运输层协议。
一个运输层协议能够为调用它的应用程序提供什么样的服务呢?我们大体能够从四个方面对应用程序服务要求进行分类:可靠数据传输、吞吐量、定时和安全性。
注意：吞吐量、带宽、宽带的区别
1、网络带宽（bandwidth）：强调网络最大的数据传输速率，即传输数据率理论峰值。
2、网络吞吐量（throughput）：强调网络实际的数据传输速率。
带宽和宽带的区别
带宽是量词，指的是网速的大小，比如1Mbps的意思是一兆比特每秒，这个数值就是指带宽。
宽带是名词，说明网络的传输速率速很高 。宽带的标准各不相同，最初认为128kbps以上带宽的就是宽带，而以下的就是窄带。
宽带是一种业务，带宽是传输速度。
2.1.4 因特网提供的运输服务
至此，我们已经考虑了计算机网络能够提供的通用运输服务。现在我们要更为具体考察由因特网提供的运输服务类型。因特网(更一般的是TCP/IP网络)为应用程序提两个运输层协议，即UDP和TCP)当你(作为一个软件开发者)为因特网创建一个新应用时，首先要做出的决定是,(选择UDP还是选择TCP)每个协议为调用它们的应用程提供了不同的服务集合。图2-4显示了某些所选的应用程序的服务要求。
（1）TCP服务
面向连接的服务
面向连接的服务:在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组的到来做好准备。在握手阶段后，一个TCP连接(TCPconnection)就在两个进程的套接字之间建立了。这条连接是**全双工**的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。在第3章中我们将详细讨论面向连接的服务，并分析它是如何实现的。
可靠的数据传送服务
通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。
TCP协议还具有拥塞控制机制
这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程(客户或服务器)。如我们将在第3章中所见，TCP拥塞控制也试图限制每个TCP连接，使它们达到公平共享网络带宽的目的。
（2）UDP 服务
UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接进程。不仅如此，到达接收进程的报文也可能是乱序到达的。UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下(网络层)注入数据。(然而，值得注意的是实际端到端吞吐量可能小于该速率，这可是因为中间链路的带宽受限或因为拥塞而造成的。)
（3）因特网运输协议所不提供的服务
总之，今天的因特网通常能够为时间敏感应用提供满意服务，但它不能提供任何定时或带宽保证。
因特网电话应用的发者通常愿意将该应用运行在UDP上，从而设法避开TCP的拥塞控制机制和分组开。但因为许多防火墙被配置成阻挡(大多数类型的)UDP流量，所以因特网电话应用通设计成如果 UDP通信失败就使用TCP 作为备份。
2.1.5 应用层协议
应用层的一部分。
我们刚刚学习了通过把报文发送进套接字实现网络进程间的相互通信。但是如何构造这些报文?在这些报文中的各个字段的含义是什么?进程何时发送这些报文?这些问题将我们带进应用层协议的范围。应用层协议(application-layer protocol)定义了运行在不同端系统上的应用程序进程如何相互传递报文。
特别是应用层协议定义了:
- 交换的报文类型，例如请求报文和响应报文。
- 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
- 字段的语义，即这些字段中的信息的含义。
- 确定一个进程何时以及如何发送报文，对报文进行响应的规则。
有些应用层协议是由RFC文档定义的，因此它们位于公共域中。例如，Web的应用层协议HTTP(超文本传输协议[RFC2616])就作为一个RFC可供使用。如果浏览器开发者遵从HTTPRFC规则，所开发出的浏览器就能访问任何遵从该文档标准的Web服务器并获取相应Web页面。还有很多别的应用层协议是专用的，有意不为公共域使用。例如，Skype 使用了专用的应用层协议。
2.1.6 本书涉及的5种网络应用
每天都有新的公共域或者专用域因特网应用被开发出来。我们不愿像百科全书一样涉及大量的因特网应用，而是选择其中几种重要而流行的应用加以关注。在本章中我们详细讨论5种重要的应用:
Web、文件传输、电子邮件、目录服务、流式视频和P2P。我们首先讨论Web应用，不仅因为它是极为流行的应用，而且因为它的应用层协议HTTP比较简单并且易于理解。我们接下来讨论电子邮件，这是因特网上第一个招人喜爱的应用程序。说电子邮件比Web更复杂，是因为它使用了多个而不是一个应用层协议。在电子邮件之后，我们学习DNS，它为因特网提供目录服务。大多数用户不直接与DNS打交道，而是通过其他的应用(包括Web、文件传输和电子邮件)间接使用它。DNS很好地说明了一种核心的网络功能(网络名字到网络地址的转换)是怎样在因特网的应用层实现的。然后我们讨论P2P文件共享应用，通过讨论包括经内容分发网分发存储的视频在内的按需流式视频，结束应用层的学习。
2.2 Web和HTTP
2.2.1HTTP概况
Web的应用层协议是超文本传输协议)(HyperTextTransfer Protocol，HTTP)，它是 Web的核心。HTTP由两个程序实现:一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。在详细解释 HTTP之前，应当回顾某些Web 术语——
Web 页面(Web page)(也叫文档)是由对象组成的。一个对象(object)只是一个文件，诸如一个 HTML 文件、一个JPEG图形、一个 Java 小程序或一个视频片段这样的文件,且它们可通过一个 URL地址寻址。多数Web页面含有一个HTML基本文件(base HTM6le)以及几个引用对象。例如，如果一个Web页面包含HTML文本和5个JPEG图形,那么这个 Web页面有6个对象:一个HTML基本文件加5个图形。HTML基本文件通过对象的 URL地址引用页面中的其他对象。
每个URL地址由两部分组成:存放对象的服务器主机名和对象的路径名。例如，URL地址 http://www.someSchool. edu/someDepartment/picture. gif，其中的(www. someSchool. edu 就是主机名,)(someDepartment/ picture. gif 就是路径名。因为Web 浏览器(Web browser)(例如Interet Explorer 和Firefox)实现了HTTP 的客户端，所以在 Web 环境中我们经常交替使用“浏览器”和“客户”这两个术语。Web服务器(Web server)实现了 HTTP 的服务器端，它用于存储 Web 对象，每个对象由 URL地址。流行的 Web 服务器有 Apache 和 Microsoft Intermet Information Server(微软互联网信息服务器)。
HTTP 定义了 Web客户向 Web服务器请求 web页面的方式，以及服务器向客户传送 web页面的方式。我们稍后详细讨论客户和服务器的交互过程，而其基本思想在图2-6中进行了图示。当用户请求一个Web页面(如点击一个超链接)时，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应。
HTTP使用TCP作为它的支撑运输协议，而不是在UDP上运行。HTTP客户首先发起一个与服务器的 TCP 连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。如同在2.1节中描述的那样，客户端的套接字接口是客户进程与 TCP连接之间的门,在服务器端的套接字接口则是服务器进程与TCP连接之间的门。
客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收 HTTP 响应报文，类似地，服务器从它的套接子接口接收 HTTP 请求报文和向它的套接字接口发送 HTTP 响应报文。一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进人TCP的控制。2.1节讲过，TCP为HTTP提供可靠数据传输服务。这意味着，一个客户进程发出的每个HTTP请求报文最终能完整地到达服务器;类似地，服务器进程发出的每个HTTP响应报文最终能完整地到达客户。这里我们看到了分层体系结构最大的优点，即HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。
无状态协议
注意到下列现象很重要:服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。因为HTTP服务器并不保存关于客户的任何信息，所以我们说 HTTP是一个无状态协议(statelessprotocol)。
