计算机网络——chapter2 应用层

2.1应用层协议原理

• 研发网络应用程序的核心是写出能够运行在不同端系统和通过网络彼此通信的程序。
• 不需要写在网络核心设备如路由器或链路层交换机上运行的软件，也无法做到。
• 网络核心设备不在应用层上起作用，而是在较低层尤其是位于网络层及下面层次。

2.2.1 网络应用程序体系结构

• 不同于固定的网络体系结构，应用程序体系结构（application architectures）由应用程序研发者设计，规定了如何在各终端系统上组织该应用程序。

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

  server：

  1. always-on host总是在线
  2. 具有固定的、周知的地址——IP地址
  3. 典型程序：web、FTP、Telnet和电子邮件

  client：

  1. 与服务器通信
  2. 可能间歇性链接
  3. IP可能是动态的
  4. 客户互相之间不直接通信

• P2P体系结构（P2P architecture）

  1. 在间断连接的主机对（称为，对等方）之间使用直接通信
  2. 自扩展性/可收缩性（self-scalability）：每个新对等方由于请求带来新工作量，但通过向其他对等方发文件也可以增加系统服务能力
  3. 通常不需要庞大的服务器基础设施和服务器带宽
  4. 典型：BitTorrent、eMule、Skpye、PPTV、Thunder
  5. 三个应用主要挑战：ISP友好、安全性、激励

• hybrid of client-server and P2P

  1. 即时消息传递应用程序（Instant messaging applications）

     ​ 集中式服务：客户端状态检测/位置

     ​ 用户在其在线时向中央服务器注册其IP地址

     ​ 用户联系中央服务器以查找好友的IP地址

  2. 网络电话（Skype）

     • ​ 集中式服务器：查找远程参与方地址

     ​ 客户端-客户端连接：直接（非通过服务器）

2.1.2 进程通信

• 运行在相同端系统上的进程使用进程间通信机制（inter-process communication /IPC）相互通信

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

• 发送进程：创建并发送到网络

  接收进程：接收这些消息，并可能通过发送消息进行响应

• 客户和服务器进程

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

  2. web中浏览器是client，web服务器是server

  3. P2P中下载文件的对等方是client，上传文件的对等方是server

  4. client：发起通信的进程

     server：在会话开始时等待联系的进程

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

  1. 俩进程间发送报文必须通过下层的网络，进程通过一个称为套接字（socket）的软件接口从网络中发送和接收报文（进程是房子，socket是门）
  2. 发送进程把报文推出门（socket），假定该门到另外一侧之间有运输的基础设施，该设施把报文传送到接收进程门口，通过对应的门（socket)传递，然后接收进程处理报文
  3. 套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface,API)
  4. 应用程序开发者可以控制套接字在应用层的一切，但是对该套接字的运输层几乎没有控制权（物理层到运输层由操作系统控制）

• 进程寻址（addressing processes)

  1. 标识接收进程需要两种信息：①主机地址②目的主机中接收进程的标识符

  2. IP地址（IP address）：32bit 唯一标识主机

     端口号（port number）：区分相同主机不同进程

  3. HTTP server：80 mail server（SMTP）：25

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

• 运输层协议负责使报文进入接收进程的套接字。

• 很多网络提供了不止一种运输层协议，必须选择一种可用的运输层协议。

• 从四个方面对应用程序服务要求分类：可靠数据传输、吞吐量、定时和安全性。

• 可靠数据传输（reliable data transfer）/数据完整性（data integrity）

  1. 当运输协议提供该服务，发送进程只要将其数据传递进套接字，就可以完全信任数据能无差错到达接收进程（电子邮件、文件传输、远程主机访问等）
  2. 容忍丢失的应用（loss-tolerant application）：多媒体应用，如交谈式音频/视频，能够承受一定量的数据丢失。

• 吞吐量（Throughput）

  1. 可用吞吐量就是发送进程能够向接收进程交付比特的速率。
  2. 具有吞吐量要求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application)（许多多媒体）
  3. 弹性应用（elastic application）：能够根据情况或多或少地利用可供使用的吞吐量。（电子邮件、文件传输、Web传送，吞吐量越多越好）

• 定时/及时性（Timing）

  1. 定时保证能够以多种形式实现，例如：发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。
  2. 交互式实时应用程序（因特网电话、虚拟环境、电话会议、多方游戏）为了有效性而要求数据交付有严格时间限制。

• 安全性（Security）

  ​ 加密、数据完整性和端点鉴别。

2.1.4 因特网提供的运输服务（Internet transport protocols services）

• TCP service
  1. （reliable transport）可靠传输：确保数据完整性，没有字节的丢失和冗余。
  2. （flow control）流量控制：避免发送方太快接收方忙不过来。
  3. （congestion control）拥塞控制：避免发送方太快造成网络拥堵。
  4. （connection-oriented）面向连接：数据报文交换前，TCP让客户和服务器互相交换运输层控制信息，完成握手过程，建立TCP connection；应用程序结束报文发送时必须拆除连接。
  5. 不提供：及时性、最小吞吐量保证和安全性。
• UDP service
  1. （unreliable data transfer）不可靠的数据传输：不保证报文会到达接收进程，到达了的也可能是乱序到达的。
  2. 不提供：可靠性、流量控制、拥塞控制、定时、吞吐量保证、安全，或连接（无连接的）。
  3. UDP和TCP相互辅助，需要快速的大量的传输数据的场景下UDP很有用。
• Securing TCP（TCP安全）
  1. TCP&UDP没有任何加密机制，明文在发送方和接收方之间的所有链路传送，不安全。
  2. SSL (Secure Sockets Layer, 安全套接层) ：提供加密、数据完整性、端到端身份验证——>增强TCP。
  3. SSL不是与TCP和UDP同一层次上的运输协议，只是一种对TCP的加强，在应用层上实现。
• 运输协议不提供任何像吞吐量或者及时性这样的保障（互联网通常可以为时间敏感的应用程序提供令人满意的服务，不能提供任何时间或吞吐量保证）

2.2 Web&HTTP

• world wide web（Web)是第一个吸引公众眼球的互联网应用程序，超链接和搜索引擎帮助我们在Web站点的海洋里导航。

2.2.1 HTTP概况

• 超文本传输协议（HTTP: hypertext transfer protocol）
  1. Web的应用层协议
  2. 由两个程序实现：client&server，运行在不同端系统，通过交换HTTP报文进行对话。
  3. HTTP定义了报文的结构以及client和server交换报文的方式。
• HTTP overview
  1. web page由对象(object)组成,一个对象是一个文件，可通过一个URL地址寻址。
  2. 多数web页面含有一个HTML基本文件及几个引用对象，HTML基本文件通过对象的URL地址引用页面中其他对象。
  3. URL：存放对象的主机名 & 对象的路径名
  4. HTTP定义了web client向web server请求web页面的方式，以及server向client传送web页面的方式。
  5. HTTP使用TCP协议，是一个“无状态协议”。

2.2.2 非持续/持续连接

• 非持久连接（non-persistent connections)
  1. 每次客户端请求使用不同TCP连接。
  2. 一个TCP链接最多发送一个对象，然后连接终止。
  3. client在端口号80发起TCP连接——server时刻监听请求——client通过其socket向server发送一个HTTP request——server经过socket接收request报文，在HTTP response报文中封装对象，通过socket发送给client——server通知TCP断开TCP连接——client接收response报文，TCP close——client检查报文中的HTML对象，得到对10个JPEG图形的引用——对JPEG图形对象重复前面的步骤（共产生11个TCP连接）。
  4. 使用TCP并行连接（parallel TCP connections）可以缩短响应时间。
  5. shortcoming:每个连接都要在client和server中分配TCP的缓冲区和保持TCP变量，给server带来严重负担。
• Round-trip Time（RTT，往返时间）
  1. 小数据包从client到server再返回client所花的时间（可以忽略传输延迟）。
  2. 包括分组传播时延（propagation delays）、排队时延（queuing delays）和处理时延（ processing delays）。
  3. HTTP响应时间：一个RTT以启动TCP连接 & 一个RTT用于HTTP请求和返回的HTTP响应 & HTML文件传输时间（HTTP response time =2RTT+ file transmission time）
• 持久连接（persistent connections）
  1. 每次请求都是通过同一个TCP链接，多个对象可以通过一个TCP连接传送。
  2. server发送response后保持TCP连接打开，相同的client和server之间的后续请求和响应报文可以通过相同连接传送。
  3. 可以在单个持续TCP连接上一个接一个发出对object的请求，不必等待对未决请求（流水线Pipelinling）的回答。
  4. HTTP的默认模式是persistent connections with pipelinling（带流水线的持续连接）。

2.2.3 HTTP报文格式

• HTTP请求报文（request message）

  1. 第一行——request line（请求行）：方法字段（GET、POST、HEAD、PUT、DELETE）& URL字段 & HTTP版本字段。

  2. 后续行——header line（首部行）：

     

  3. GET：浏览器请求一个对象，在URL字段带有请求对象的标识，实体体（entity body）为空。

  4. POST：用户可以向server请求一个web页面，内容依赖于用户在实体体表单字段中的输入值。

  5. HEAD：server会用HTTP报文进行响应，但是不返回请求对象，常用来调试跟踪。

  6. PUT：允许用户上传对象到指定的web server上指定的路径。

  7. DELETE：允许用户或应用程序删除web server上的对象。

• HTTP响应报文（response message）

  1. 第一行——初始状态行（status line）：protocol version& status code & status message

  2. 后续行——首部行（header line）：

  3. Last-Modified：对象创建或者最后修改的日期和时间。

  4. Content-Length：被发送对象中的字节数；Content-Type：实体体中的对象类型。

• 常见状态码及其短语

  1. 200 OK：请求成功
  2. 301 Moved Permanently：请求的对象已被永久转移，新的URL定义在响应报文的Location中
  3. 400 Bad Request：通用差错代码，server无法理解请求
  4. 404 Not Found：被请求的文档不在server上
  5. 505 HTTP Version Not Supported：server不支持请求使用的HTTP协议版本