《计算机网络自顶向下》读书笔记第二章—

《计算机网络自顶向下》读书笔记第二章——应用层（1）

阅读量：5097 次

发布时间：2019-06-13

本文共 8893 字，大约阅读时间需要 29 分钟。

2.1应用层协议原理

网络应用是计算机网络存在的理由。

研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通信的程序。

Web应用程序中，有两个互相通信的不同的程序：一个是运行在用户主机上的浏览器程序，另一个是运行在web服务器主机上的web服务器程序。

P2P文件共享系统中，在各台主机中的这些程序可能都是类似或相同的。

编写应用程序时，不需要写在网络核心设备如路由器或链路层交换机上运行的软件。

网络核心设备并不在应用层起作用，而在较低层起作用，特别是位于网络层级下面层次。

这种基本设计，也即将应用软件限制在端系统的方法，促进了大量网络应用程序的迅速研发和部署。

2.1.1网络应用程序体系架构

应用程序的体系结构明显不同于网络的体系结构。

应用体系结构（application architecture）由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。

现代网络应用程序中有两种主流体系结构：客户-服务器体系结构和对等（P2P）体系结构。

①客户-服务器体系结构（client-server architecture）

1.特征：

（1）有一个总是打开的主机，称为“服务器”，它服务于来气许多其他称为“客户”的主机的请求。

（2）当web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为相应。

（3）web服务器具有固定的、周知的地址，该地址称为IP地址。正因如此，客户总是能够通过向该服务器的IP地址发送分组来与之联系。

2.代表应用程序：

web，ftp，telnet和电子邮件。

3.常见问题和解决方案：

（1）常见问题：常常会出现一台单独的服务器主机跟不上它所有客户请求的情况。

（2）解决方式：

因特网服务提供商会将配备大量主机的数据中心（通常有数十万台服务器，他们必须要供电和维护），这些数据中心常被用于创建强大的虚拟服务器。服务提供商必须支付不断出现的互联和带宽费用，以发送和接收到达/来自数据中心的数据。

②P2P体系结构（P2P architecture）

1.特征：

（1）该应用程序体系结构对位于数据中心的专用服务器有着最小的（或者没有）依赖。

（2）应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。

（3）有自拓展性（self-scalability）。例如在一个P2P文件共享系统中，尽管每个对等方都由于请求文件产生工作量，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

（4）P2P体系结构管是成本有效的，因为他们通常不需要庞大的服务器基础设施和服务器带宽。

2.代表应用程序：

许多目前流行的、流量密集的应用都是P2P体系结构的。这些应用包括文件共享（例如BitTorrent）、对等方协助下载加速器（例如迅雷）、因特网电话（例如Skype）和IPTV（例如“迅雷看看”和PPstream）。

（附加：某些应用具有混合的体系结构，结合了客户-服务器和P2P的元素。例如许多即时讯息应用，服务器被用来跟踪用户的IP地址，但用户到用户的报文在用户主机之间（无需通过中间服务器）直接发送。）

3.P2P应用面临的三个主要挑战：

（1）ISP友好。大多数住宅ISP因受制于“非对称”的带宽应用，也就是说，下载比上传要慢得多。但是P2P视频流和文件分发应用改变了从住宅ISP到服务器的上载流量，因而给ISP带来了巨大压力。

（2）安全性。因为它们的高度分布和开放特性，P2P应用给安全带来挑战。

（3）激励。未来P2P应用的成功也取决于说服用户自愿向应用提供带宽、存储和计算资源，这对激励设计带来挑战。

2.1.2进程通信

在操作系统的术语中，进行通信额实际上是进程（process）而不是程序。

一个进程可以被认为是运行在端系统中的一个程序。

当进程运行在相同的端系统时，他们使用进程间相互通信机制相互通信，该机制由端系统上的操作系统确定。

在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）而相互通信。

1、客户和服务器进程

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

无论是对于客户-服务器应用程序还是P2P应用程序，都可以用下面的思想概括：

在给定的一对进程的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。

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

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

套接字也被称为应用程序和网络之间的应用程序编程接口（Application programing interface，API）。

应用程序开发者可以控制套接字在应用层端的一切，但是对于该套接字的运输层段几乎没有控制权。

应用程序开发者对运输层的控制仅限于：

①选择运输层协议 ②也许可以设定几个运输层参数，如最大缓存和最大报文段长度等。

3、进程寻址

在因特网中，两个进程之间发送报文，除了要知道报文送往的目的地主机地址外，还要指定运行在接收主机上的接收进程。

主机由其IP地址（IP address）标识，端口号（port address）用来指定接收进程。

常见的应用程序端口号：web服务器用端口号80来标识，邮件服务器用端口号25来标识。

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

在发送端的应用程序将报文推进套接字。在套接字的另一端，运输层协议负责使该报文进入接收进程的套接字。

一个运输层可以提供的服务，大概能从以下几个方面概括：

①可靠数据传输（reliable data transfer）：

当一个运输层协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据能够无差错地到达接收进程。

当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能不能够到达接收进程，这只适合容忍丢失的应用（loss-tolerant application）。

有很多多媒体应用就可以承受一定量的数据丢失（如音频、视频）。

②吞吐量：

运输层协议能够以某种特定的速率提供确保的可用吞吐量。

具有吞吐量要求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application）。

许多当前的多媒体应用是带宽敏感的，尽管某些多媒体应用程序可能采用自适应编码技术对数字语音或视频以与当前可用带宽相匹配的速率进行编码。

带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic application）能够根据情况或多或少地利用可供使用的吞吐量。

③定时：

运输层协议也能提供定时保证，如同具有吞吐量保证那样，定时保证能够以多种形式实现：比如，可以保证每个比特到达接收方的套接字不迟于100ms。

这种服务将对交互式实时应用程序有吸引力。

④安全性：

运输协议能够为应用程序提供一种或多种安全性服务，例如，有些发送主机中，运输协议可以加密由发送进程传输的所有数据；在接收主机中，运输层协议能够再将数据交付给接收进程之前解密这些数据。

运输协议还提供除了机密性意外的其他安全性服务，包括数据完整性和端点识别。

2.1.4因特网提供的运输服务

因特网（更一般的是TCP/IP网络）为应用程序提供两个运输层协议，即UCP和TCP。

当一个软件开发者为因特网创建一个新的应用时，首先要做出的决定是，选择UCP还是TCP。

①TCP服务

（1）面向连接的服务：

在应用层数据报文开始流动之前，其客户机程序和服务器程序之间互相交换运输层控制信息，完成握手阶段。这个过程可以让它们为大量分组的到来做好准备。

在握手阶段过后，一个TCP连接（TCP connection）就在两个进程的套接字之间建立了。

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

当应用程序结束报文发送时，必须拆除该连接。

（2）可靠的数据传送服务

（有拥塞控制机制）

②SSL（secure socket layer，安全套接字层）服务

无论TCP还是UDP都没有提供任何加密机制，因此，因特网界研制了TCP的加强版SSL。

SSL不仅可以做到传统的TCP所能够做到的一切，而且提供了加密、数据完整性和端点鉴别这些关键的进程到进程的安全性服务。

SSL有自己的套接字API，类似于传统的TCP套接字API。

发送进程（明文数据）→SSL套接字（加密后的数据）→TCP套接字（加密后的数据）→接收进程的TCP套接字（加密后的数据）→接收进程的SSL套接字（明文数据）→接收进程

③UDP服务

（1）UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。

（2）UDP是无连接的，因此在两个进程通信前没有握手过程。

（3）UDP协议提供一种不可靠数据运输服务。

（4）UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

④因特网运输协议所不提供的服务

今天的因特网不能为应用提供任何定时或带宽保证。

时间敏感的应用通常是靠应用程序的设计，来最大程度的适应这种服务的缺乏。

因特网电话应用通常能够容忍某些数据丢失，但要求要达到一定的最小速率才能有效工作，所以通常会选择UDP来绕开TCP的拥塞控制机制。

2.1.5应用层协议（application-layer protocol）

应用层协议定义了对报文的构建和发送方式：

①交换的报文类型，如请求报文和响应报文。

②各种报文类型的语法，如报文中的各个字段和这些字段是如何描述的。

③字段的语义，即这些字段中包含的信息的含义。

④一个进程何时以及如何发送报文，对报文进行响应的规则。

有些应用层协议室友RFC文档定义的，因此它们位于公共域中。

还有很多别的应用层协议是专用的，例如Skype就使用了专用的应用层协议。

应用层协议是网络应用的非常重要的一部分。

应用层协议例子：

web的应用层协议就是HTTP，它定义了在浏览器和web服务器之间传输的报文格式和序列。

2.2 Web和HTTP

90年代初期，一个新型应用即万维网（world wide web）登上了舞台，web是第一个引起公众关注的因特网应用，它极大的改变了人们与工作环境内外交流的方式，它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。

对于大多数用户来说，web最有吸引力的就是它的按需操作。

2.2.1HTTP概况

web的应用层协议是超文本传输协议（hypertext transfer protocol，HTTP），它是web的核心。

HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。

HTTP默认使用80号端口。

HTTP的作用：

当运行在不同端系统的客户程序和服务器程序，通过交换HTTP报文进行会话时，HTTP定义了这些报文的结构以及用户和服务器进行报文交换的方式。

HTTP的客户程序是浏览器。

web页面（Web page）（也叫文档）是由对象（object）组成的。

一个对象只能是一个文件。

多数web页面含有一个html基本文件（base HTML file）以及几个应用对象。

HTML基本文件通过对象的URL地址引用页面中的其他对象（html文档中的超链接）。

每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

web服务器实现了http的服务器端，用于存储web对象，每个对象由URL寻址。

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

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

HTTP服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息，所以我们说HTTP是一个无状态协议（stateless protocol）。

报文在两个套接字之间运输时，实际上脱离了客户和服务器的控制，受到运输层协议的控制。

2.2.2非持续连接和持续连接

非持续连接（non-persistant connection，又称“短连接”)：每对请求/响应由一个单独的TCP连接发送。

持续连接(persistant connection，又称“长连接”)：所有的请求和响应都经一相同的TCP连接发送。

应用程序的端口号由其采用的应用层协议决定，例如HTTP端口号为80。

浏览器和web服务器建立一个TCP连接时，会涉及到一个“三次握手”过程。

三次握手过程：

①客户向服务器发送一个小TCP报文段。

②服务器用一个小TCP报文段做出确认和响应。

③客户向服务器返回确认。

1.采用非持续连接的HTTP

每个TCP连接在服务器发送一个对象后就关闭，不为其他的对象而持续下来。

每个TCP连接之传输一个请求报文和一个响应报文。

事实上，用户可以通过配置现代浏览器以控制并行度（同时打开多少个并行的TCP连接）。

在默认配置下，大部分浏览器打开5~10个并行的TCP连接，而每条连接处理一个请求响应事务。

如果用户愿意，最大并行连接数可以设置为1，这样10条连接就会串行建立。

使用并行连接可以缩短响应时间。

往返时间（round-trip time,RTT）：往返时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。

往返时间包括分组交换网络中的结点总时延。

客户在过程③向服务器发送一个HTML请求报文，服务器接收之后，就在该TCP连接上发送HTML文件。

因此，发送一个HTML的总的响应时间，就是两个RTT加上服务器传输HTML文件的时间。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。

非持续连接有两个缺点：

①对于每个新的TCP连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给web服务器带来了严重的负担。

②每一个对象经手两倍RTT的交付时延，即一个RTT用于创建TCP，另一个RTT用来请求和接收一个对象。

2.采用持续连接的HTTP

特性：

①服务器在发送响应之后保持该TCP链接打开。在相同的客户与服务器之间的后续请求和响应报文可以通过相同的连接进行传送。

②位于同一台服务器的多个web页面从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行，可以一个接一个地发出对对象的这些请求，而不必等待对未决请求的回答。

③一般来说，如果一个连接经过一定时间间隔仍未被使用，HTTP服务器就关闭该链接。

HTTP的默认设置是使用带流水线的持续连接。

长连接的生命周期：连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接；

持续连接面临的问题：

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候。

解决方式：

server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

2.2.3HTTP报文格式

1.HTTP请求（request）报文

HTTP请求报文的第一行叫做请求行（request line），其后继的行叫做首部行（header line），首部行后面有一个“实体体（entity body）”。

请求行有3个字段：方法字段，URL字段和HTTP版本字段。

方法字段可以取几个不同的值：GET,POST,HEAD,PUT,DELETE,OPTIONS,TRACE,CONNECT。（绝大部分的HTTP请求使用GET方法）

使用GET方法时，URL字段上会有请求对象的标识。

首部行——

Host行：指明了对象所在的主机。

Connection：close/Connection：keep-alive：该浏览器告诉服务器本次TCP连接采用非持续连接/持续连接。

User-agent：说明向服务器发送请求的浏览器类型。

Accept-Language：允许客户端声明它可以理解的自然语言，以及优先选择的区域方言。服务器会优先返回该指定语言版本的对象，否则返回它的默认版本。

HTTP请求方法：

①GET方法和POST方法

使用GET方法时，实体体为空。使用POST方法时才使用该实体体。

当用户提交表单时，HTTP客户常常使用POST方法。

使用POST报文时，客户仍然可以向服务器请求一个web页面，但web页面的特定内容依赖于用户在表单字段中输入的内容。

表单数据传送也经常使用GET方法，但是表单中的内容会出现在URL字段中。

POST请求可能会导致新的资源的建立和/或已有资源的修改。

POST方式提交时，你必须通过Request.Form来访问提交的内容

②HEAD方法

HEAD方法和GET方法类似，但是返回的响应中没有具体的内容，只有报头。

③PUT方法

从客户端向服务器传送的数据取代指定的文档的内容。

④DELETE方法

请求服务器删除指定的页面。

DELETE请求一般返回3种码

200（OK）——删除成功，同时返回已经删除的资源。

202（Accepted）——删除请求已经接受，但没有被立即执行（资源也许已经被转移到了待删除区域）。

204（No Content）——删除请求已经被执行，但是没有返回资源（也许是请求删除不存在的资源造成的）。

⑤CONNECT方法

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。