计算机网络自顶向下方法第二章——应用层 Summary after reading

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

• 应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序中所使用的两种主流体系结构之一：客户—服务器体系结构或对等(P2P)体系结构。

• 利用客户—服务器体系结构，客户相互之间不直接通信。具有客户—服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet和电子邮件。

• 在一个P2P体系结构中，对位于数据中心的专用服务器有最小的(或者没有)依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。P2P体系结构的最引人入胜的特性之一是它们的自扩展性。例如，在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

• 多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文。

• 套接字是同一台主机内应用层与运输层之间的接口。套接字也称为应用程序和网络之间的应用程序编程接口。应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。应用程序开发者对于运输层的控制仅限于：

  • 选择运输层协议。
  • 也许能设定几个运输层参数，如最大缓存和最大报文段长度等。一旦应用程序开发者选择了一个运输层协议(如果可供选择的话)，则应用程序就建立在由该协议提供的运输层服务之上。

• 除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程(接收套接字)。因为一般而言一台主机能够运行许多网络应用，这些信息是需要的。目的地端口号用于这个目的。已经给流行的应用分配了特定的端口号。

• 我们大体能够从四个方面对应用程序服务要求进行分类：

  • 可靠数据传输：必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用所接受，最值得注意的是多媒体应用，如交谈式音频/视频，它们能够承受一定量的数据丢失。在这些多媒体应用中，丢失的数据引起播放的音频/视频出现小干扰，而不是致命的损伤。
  • 吞吐量：在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。即运输层协议能够以某种特定的速率提供确保的可用吞吐量。使用这种服务，该应用程序能够请求r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是为至少r比特/秒。具有吞吐量要求的应用程序被称为带宽敏感的应用。而弹性应用能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。电子邮件、文件传输以及Web传送都属于弹性应用。
  • 定时：为了有效性而要求数据交付有严格的时间限制。
  • 安全性：运输协议能够为应用程序提供一种或多种安全性服务。运输协议还能提供除了机密性以外的其他安全性服务，包括数据完整性和端点鉴别。

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

  • 面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组到来做好准备。在握手阶段后，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。
  • 可靠的数据传送服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。
  • TCP协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程，TCP拥塞控制也试图限制每个TCP连接，使它们达到公平共享网络带宽的目的。

• 无论TCP还是UDP都没有提供任何加密机制，所以因特网界已经研制了TCP的加强版本，称为安全套接字层(Secure Sockets Layer，SSL)。用SSL加强后的TCP不仅能够做传统的TCP所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别。我们强调SSL不是与TCP和UDP在相同层次上的第三种因特网运输协议，而是一种对TCP的加强，这种强化是在应用层上实现的。当一个应用使用SSL时，发送进程向SSL套接字传递明文数据；在发送主机中的SSL则加密该数据并将加密的数据传递给TCP套接字。加密的数据经因特网传送到接收进程中的TCP套接字。该接收套接字将加密数据传递给SSL，由其进行解密。最后，SSL通过它的SSL套接字将明文数据传递给接收进程。

• UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层注入数据。

• 对于定时和安全性，这些服务目前的因特网运输协议并没有提供。它们已经被设计成尽最大可能对付这种保证的缺乏。无论如何，在时延过大或端到端吞吐量受限时，好的设计也是有限制的。总之，今天的因特网通常能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。

• 但因为许多防火墙被配置成阻挡UDP流量，所以因特网电话应用通常设计成如果UDP通信失败就使用TCP作为备份。

• 说电子邮件比Web更复杂，是因为它使用了多个而不是一个应用层协议。在电子邮件之后，我们学习DNS，它为因特网提供目录服务。大多数用户不直接与DNS打交道，而是通过其他的应用(包括Web、文件传输和电子邮件)间接使用它。

• HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文。类似地，服务器从它的套接字接口接收HTTP请求报文和向它的套接字接口发送HTTP响应报文。服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。所以我们说HTTP是一个无状态协议。我们同时也注意到Web使用了客户—服务器应用程序体系结构。

• 应用程序的研制者就需要做一个重要决定，即每个请求/响应对是经一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送呢？采用前一种方法，该应用程序被称为使用非持续连接；采用后一种方法，该应用程序被称为使用持续连接。HTTP既能够使用非持续连接，也能够使用持续连接。尽管HTTP在其默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接。

• 非持续连接的每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。事实上，用户能够配置现代浏览器来控制连接的并行度。在默认方式下，大部分浏览器打开5~10个并行的TCP连接，而每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置为1，这样10条连接就会串行建立，使用并行连接可以缩短响应时间。三次握手中前两个部分所耗费的时间占用了一个往返时间RTT。完成了三次握手的前两个部分后，客户结合三次握手的第三部分(确认)向该TCP连接发送一个HTTP请求报文。非持续连接有一些缺点：

  • 必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计不同的客户的请求。
  • 就像我们刚描述的那样，每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP，另一个RTT用于请求和接收一个对象。

• 在采用HTTP1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。可以用单个持续TCP连接进行传送。更有甚者，位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行。对对象的这些请求可以一个接一个地发出，而不必等待对未决请求(流水线)的回答。一般来说，如果一条连接经过一定时间间隔(一个可配置的超时间隔)仍未被使用，HTTP服务器就关闭该连接。HTTP的默认模式是使用带流水线的持续连接。最近，HTTP/2是在HTTP1.1基础上构建的，它允许在相同连接中多个请求和回答交错，并增加了在该连接中优化HTTP报文请求和回答的机制。

• 用表单生成的请求报文不是必须使用POST方法，相反，HTML表单经常使用GET方法，并在(表单字段中)所请求的URL中包括输入的数据。例如，一个表单使用GET方法，它有两个字段，分别填写的是monkeys和bananas，这样，该URL结构为www. somesite. com/animalsearch? monkeys&bananas。

• Date：首部行指示服务器产生并发送该响应报文的日期和时间。这个时间不是指对象创建或者最后修改的时间，而是服务器从它的文件系统中检索到该对象，将该对象插入响应报文，并发送该响应报文的时间。Last-Modified：首部行指示了对象创建或者最后修改的日期和时间。

• Cookie组成：

  • 在HTTP响应报文中的一个cookie首部行。
  • 在HTTP请求报文中的一个cookie首部行。
  • 在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理。
  • 位于Web站点的一个后端数据库。

• Cookie可以在无状态的HTTP之上建立一个用户会话层。例如，当用户向一个基于Web的电子邮件系统注册时，浏览器向服务器发送Cookie信息，允许该服务器在用户与应用程序会话的过程中标识该用户。

• Web缓存器也叫代理服务器，它是能够代表初始Web服务器来满足HTTP请求的网络实体。

• Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此。如果在客户与Web缓存器之间有一个高速连接，并且如果用户所请求的对象在Web缓存器上，则Web缓存器可以迅速将该对象交付给用户。Web缓存器能够大大减少一个机构的接入链路到因特网的通信量。通过减少通信量，该机构就不必急于增加带宽，因此降低了费用。此外，Web缓存器能从整体上大大减低因特网上的流量，从而改善了所有应用的性能。

• 通过使用内容分发网络(CDN)，Web缓存器正在因特网中发挥着越来越重要的作用。CDN公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化。有多个共享的CDN和专用的CDN。

• 因特网电子邮件系统有3个主要组成部分：用户代理、邮件服务器和简单邮件传输协议(SMTP)。一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。如果发送方的服务器不能将邮件交付给接收方的服务器，发送方的邮件服务器在一个报文队列中保持该报文并在以后尝试再次发送。通常每30分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方。