计算机网络《自顶向下方法》学习笔记

第二章 应用层

  • 网络应用是计算机存在的理由，若我们不能构想出有意思的应用，也就失去了设计支持它们（应用）的网络协议。

2.1 应用层协议原理

  • 多端通信; 只关注应用层 -> 应用程序 BOOM !!!
2.1.1 网络应用程序体系结构
  • 应用程序体系结构 ！== 网络体系结构
  • 应用程序程序员视角: 网络体系结构是固定的；它（网络体系结构）为应用程序提供特定的服务集合。
  • 应用程序体系结构由应用程序研发者设计：规定如何在多端组织该应用程序
  • 应用程序的两种主流体系结构
    1. 客户端 - 服务器 ： 服务器总是打开的，服务于请求它的客户；具有这种体系结构的应用程序包括 Web, FTP, Telnet, 电子邮件。（服务器不单是一台主机，而是一个或多个数据中心[Data Center]分布式提供服务。）
    2. P2P（Peer-To-Peer） ： 用户到用户的报文用于对等主机之间（无须通过中间服务器）直接发送。P2P 的特性之一 自扩展性（self-calability）相当引人入胜。
2.1.2 进程通信
  • 跨端进程（程序）通信过程：发送进程生成并向网络中发送报文 --> 接收进程接收这些报文并可能通过会送报文进行响应。
1. 客户和服务器进程
  • 网络应用程序由成对的进程组成，这些进程通过网络互相发送报文。
  • 将其一表示为客户（client）， 另一进程标识为服务器（server）。
2. 进程与计算机网络之间的接口
  • 进程向进程发送报文必须通过下面的网络。
  • 进程通过一个称为套接字（socket）的软件接口向网络发送/接收报文。
  • 可以将进程比作房子，套接字比作房子的门。（假定门与门之间有运输的基础设施）
  • 套接字是同一台主机内应用层与传输层之间的接口。
  • 套接字被称为应用程序和网络之间的应用程序编程接口（API）。
  • 应用程序开发者可以控制套接字在应用端的一切；对套接字的运输层端几乎没有控制权。
  • 应用程序开发者对运输层的控制仅限于：1. 选择运输层协议 2. 也许能设定几个运输层参数：最大缓存和最大报文长度等。
  • 应用程序开发者选择一个运输层协议（若提供选择），则应用程序就建立在由该协议提供的运输层服务之上。
3. 进程寻址
  • 主机由 IP地址 (IP address) 标识。 IP 地址是一个 32 bit（比特）的量。
  • 一台能够运行多个网络应用。端口号(Port Number) 用于这个目的。
  • web: 80 smtp: 25
2.1.3 可供应用程序使用的运输服务器
  • 一个运输层协议能为调用它的应用程序提供：可靠数据传输/ 吞吐量/ 定时/ 安全。
1. 可靠数据传输
  • 分组在计算机网络中可能丢失：分组能使路由器中缓存溢出； 分组中的某些比特损坏后可能被丢弃。
  • 确保进程发送的数据正确，完全交付到另一进程。如果一个协议提供了这种服务时，就认为提供了可靠数据传输（reliable data transfer）
2. 吞吐量
  • 吞吐量——发送进程能向接收进程交付比特的速率
3. 定时
  • 运输层协议也能提供定时保证
4. 安全性
  • 运输层协议能够为应用程序提供一种或多种安全性服务。
2.1.4 因特网提供的运输服务
  • TCP/IP网络为应用程序提供了连个运输层协议—— TCP 和 UDP
1. TCP 服务
  • TCP服务模型包括面向连接服务和可靠数据传输服务。
  • 面向连接的服务——在应用层数据报文开始流动之前，TCP 让客户和服务器互相交换运输层控制信息。这个所谓握手过程提醒客户端和服务器为大量分组的到来做好准备。在握手阶段后，一个TCP链接（TCP connection） 就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该链接。
  • 可靠数据的传送服务——通信进程能够依靠 TCP , 无差错，按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能依靠 TCP 将相同的字节流交付给接收方的套接字，没有字节的丢失和冗余。
  • TCP协议还具有拥塞控制机制，它可以为因特网带来整体好处—— 当发送方和接受放之间的网络出现拥塞时，TCP 的拥塞控制机制会抑制发送进程（客户或服务器）。

TCP 安全：
无论 TCP 还是 UDP 都没有提供任何加密机制。
因以上原因，研究人员研制了 TCP 的加强版本，称为 安全套接字层 (Secure Sockets Layer， SSL)。
用 SSL 加强后的 TCP 不仅可以做传统 TCP 能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密/ 数据完整性/ 端点鉴别。
SSL 是 TCP 的一种加强，这种强化是在应用层上实现的。
SSL 有它自己的套接字API ,这类似于传统的TCP套接字API

2. UDP 服务
  • UDP 是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
  • UDP 是无连接的，因此在两个进程通信前没有握手过程。
  • UDP 协议提供一种不可靠数据传输服务 —— UDP 协议并不保证该报文将到达接收进程。
  • 到达接收进程的报文可能是乱序到达的。
  • UDP 没有拥塞控制机制 —— 所以 UDP 的发送端可以用它选定的任何速率向其下层(网络层)注入数据。
2.1.5 应用层协议
  • 应用层协议定义了：
  1. 交换的报文类型，例如请求报文和响应报文。
  2. 各种报文类型的语法，如报文中的各个字段以及这些字段是如何描述的
  3. 字段的语义，即这些字段中的信息的含义
  4. 确定一个进程何时以及如何发送报文，对保温进行响应的规则。

2.2 Web 和 HTTP

2.2.1 HTTP 概况
  • Web 的应用层协议是 超文本传输协议(HTTP )(它是 web 的核心)
  • HTTP 由两个程序实现：一个客户程序 和 一个服务器程序
  • 客户程序和服务器程序在不同的端， 它们通过交换 HTTP 报文进行会话
  • HTTP 定义了 这些报文的结构以及客户和服务器进行报文交换的方式
  • Web 页面（Web page）（也叫文档）是由对象组成的。一个对象（object）只是一个文件。
  • Web 浏览器（Web browser）实现了 HTTP 的客户端。
  • Web 服务器（Web server ) 实现了 HTTP 服务端 —— 它用于存储 Web 对象，每个对象由 URL 寻址。
  • HTTP 定义了 Web 客户向 Web 服务器请求 Web page 的方式，以及服务器向客户传送 Web 页面的方式
  • HTTP 使用 TCP 作为它的支撑运输协议（而不是在 UDP 上运行）。
  • HTTP 客户首先发起一个与服务器的TCP链接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口来访问 TCP .
  • 服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。—— 所以我们说 HTTP 是一个无状态协议（stateless protocol）
2.2.2 非持续连接和持续连接
1. 采用非持续连接的 HTTP
  • 在非持续连接情况下，从服务器向客户传送一个 Web 页面的步骤。
  1. HTTP 客户进程在端口号 80 发起一个到 服务器 (www.XXX.XX)的TCP连接，该端口号是 HTTP 的默认端口。在客户和服务器上分别有一个套接字与该连接相关联。
  2. HTTP 客户经它的套接字向服务器发送一个 HTTP 请求报文， 该报文中包含了 路径名/目录。
  3. HTTP 服务器进程经它的套接字接收该请求报文，从其存储器（RAM 或磁盘）中检索出对象路径/目录，在一个 HTTP 响应报文中封装对象，并通过其套接字向客户发送响应报文。
  4. HTTP 服务器进程通知 TCP 断开该TCP 连接。（但是直到 TCP 确认客户端已经完整地收到响应报文为止，它才会实际中断连接）
  5. HTTP 客户接收响应报文，TCP 连接关闭。该报文指出封装的对象是一个 HTML 文件，客户从响应报文中提取出该文件，检查该HTML文件。得到他们的引用（若是图片）。
  6. 对每个引用的对象重复前4个步骤(若是图片。)
  • 当浏览器收到 Web 页面后， 向用户显示该页面。
  • 上述步骤说明了非持续连接的使用，其中每个TCP 连接在服务器发送一个对象后关闭，即该连接不为其他的对象而持续下来。
  • 值得注意的是 每个 TCP 连接只传输一个请求报文和一个响应报文。
  • 浏览器可以规定 发起 TCP 请求是串行或者是并行
  • 三次握手中前两个部分所耗时占用一个RTT(Round-Trip Time, 往返时间), 一旦该请求报文到达服务器，服务器就在该TCP 连接上发送 HTML 文件，该HTTP 请求/ 响应用去了另一个RTT， 所以，粗略的讲，总的响应时间就是 两个 RTT 加上服务器传输 HTML 文件的时间。
2. 采用持续连接的 HTTP
  • 非持续连接有一些缺点
  1. 必须为每一个请求的对象建立和维护一个全新的连接——对于每个这样的连接，在客户和服务器中都要分配 TCP 缓冲区和保持 TCP 变量，这给Web服务器带来了严重的负担（服务器和客户是一对多的关系）
  2. 每一个对象经受两倍 RTT 交付时延，即一个 RTT 用于创建 TCP, 另一个 RTT 用于请求和接收一个对象。
  • 再采用 HTTP 1.1 持续连接的情况下， 服务器在发送接收响应后保持该 TCP 连接打开。—— 在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。
  • 最新HTTP 2 是在 HTTP 1.1 基础上构建的，它允许在相同连接中多个请求和回答交错，并增加了该连接中优化 HTTP 报文 请求和回答的机制。
2.2.3 HTTP 报文格式
  • HTTP 规范 包含了对 HTTP 报文格式的定义。 HTTP 报文有两种： 请求报文和响应报文。
1. HTTP 请求报文

在这里插入图片描述

HTTP 请求报文的 第一行为请求行（request line），后继的行叫做首部行（header line）
请求行有三个字段： 方法字段 URL字段 和HTTP版本字段
方法字段可以取 GET POST HEAD PUT DELETE
HEAD 类似于 GET方法：当服务器收到一个使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。
PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径（目录）PUT方法也被那些需要向 Web 服务器上传对象的应用程序使用。
DELETE 方法允许用户或者应用程序删除 Web 服务器上的对象
首部行中 Host 指明了对象所在的之际
User-agent: 首部行用来指明用户代理，即向服务器发送请求的浏览器类型。

2. HTTP 响应报文

在这里插入图片描述

我们观察这个响应报文
它有三个部分： 一个初始的状态行（status line）， 余下为首部行（header line）然后是实体(entity body)
实体部分是报文的主要部分，它包含了所有请求的对象本身。
状态行有三个字段： 协议版本字段 状态码 状态信息

2.2.4 用户与服务端的交互 Cookie
  • 我们之前提到 HTTP 服务器是无状态的。
  • 这允许工程师去开发同时处理数以千计的 TCP 连接和高性能的 Web 服务器
  • 然而一个 Web 站点常常希望能识别用户 —— cookie
  • cookie 允许站点对用户进行跟踪。
  • cookie技术有四个组件
    1. 在 HTTP 响应报文中的一个 cookie 首部行
    2. 在 HTTP 请求报文中的一个 cookie 首部行
    3. 在用户端系统中保留有一个 cookie 文件，并由用户的浏览器进行管理。
    4. 位于 Web 站点的一个后端数据库
2.2.5 Web 缓存
  • Web 缓存器（Web cache） 也叫 代理服务器（Proxy server），它是能够代表初始 Web 服务器来满足 HTTP 请求的的网络实体。
2.2.6 条件 GET 方法
  • 尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新问题，即存放在缓存器中的对象副本可能是陈旧的。
  • 幸运的是 HTTP 协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是 条件 GET(conditional GET)方法。
  • 如果 ① 请求报文使用 GET 方法；并且 ②请求报文中包含一个 “If-Modified-Since:” 首部行。那么 HTTP 请求报文就是一个条件 GET 请求报文。
  • 服务器的响应报文的首部行会有 Last-Modified
  • 如果这俩相等，则服务器会返回304 代表资源没有被修改过