【计算机网络 - 自顶向下方法】应用层（HTTP、FTP）

1. Principles of network applications

创建一个网络应用

  创建一个网络应用的核心，是编写一个分布式程序，使其可以运行在不同的端系统上，并能通过网络相互通信。（例如，web服务器软件与浏览器软件）
  应用程序只运行在终端上（只在端系统上开发应用），应用程序员不需要为网络核心设备编写程序，我们默认可以调用一些API，这极大地方便了网络应用的开发和快速部署。
  我们不需要为网络核心设备编写程序的原因：一方面会浪费大量的时间与精力，另一方面网络的核心设备我们是接触不到的。

1.1 网络应用架构

  在开发一个应用程序之前，首先要决定采用什么样的网络应用架构，网络应用架构规定了在各个端系统上组织应用程序的方法，目前有两种主流的网络应用架构：

• 客户-服务器架构（Client-server） 中心化的架构
• 对等架构（Peer-to-Peer ，P2P） 没有服务器的概念

1.1.1 客户-服务器架构

服务器（server）：

• 有一台总是在线的主机，上面运行着服务器程序 （server） （有请求要及时响应请求）。
• 服务器主机 （server machine） 具有永久的、众所周知的地址。
• 服务器端会在很多地方部署大量的计算集群，且具有高速网络。

客户（client）：

• 用户终端上运行一个客户程序 （client），需要时与服务器程序通信，请求服务。
• 客户机（client machine）使用动态地址，通常不会总是在线。

  客户只与服务器通信，客户之间不通信。

1.1.2 P2P架构

• 没有总是在线的服务器主机。
• 任意一对端系统（对等方）可以直接通信。
• 对等方多为用户自己的计算机，使用动态地址。
• 每个对等方既可请求服务，也可提供服务。
• 典型的P2P应用：BT、迅雷、Skype（将P2P架构与Client-Server架构结合）、PPLive。

  客户服务器的架构的性能瓶颈在服务器端，服务器的性能决定了整个应用的访问数量与速度，在 P2P 中并没有这种瓶颈，但 P2P 架构管理起来较为困难，因为对等方的 IP 是不断变化的，资源发现较为困难。

1.1.3 两种架构的比较

客户-服务器架构		P2P架构
资源集中：	资源（服务）只在某些固定的终端上提供	资源分散：	任何终端都可以提供资源（服务）
优点：	资源发现简单	优点：	易于扩容、均衡网络流量
缺点：	集中式计算带来的问题，如服务端扩容压力、网络流量不均衡、响应延迟长	缺点：	资源发现困难，社会问题（版权、安全性等）

1.2 不同终端上的进程通信

进程： 主机上运行的程序。

在分布式应用中，不同终端上的进程需要通信，通信的方法主要有：

  在同一台主机中，由操作系统来提供进程之间的通信。在不同的主机上，通过交换报文进行通信。在一次确定的通信会话中，总能标示一方为客户进程，另一方为服务器进程（包括P2P架构）：

• 客户进程：主动发起请求的进程。
• 服务器进程：接收请求的进程。

套接字（socket）：进程与网络的接口（应用程序和网络之间的一扇门）。

• 发送报文：发送进程将报文推到门外。
• 门外的运输设施（因特网）将报文送到接收进程的门口。
• 接收报文：接收进程打开门，即可收到报文。

套接字是应用层和传输层的接口，也是应用程序和网络之间的API。

  每个进程需要一个标识，以便其它进程能够找到它，那么进程如何该如何标识自己？可以用进程所在主机的地址来标识进程吗？

答案是不能，因为同一个主机上可能运行着许多进程，我们用端口号来区分同一个主机上的不同进程

进程标识包括：

• 主机地址。
• 与该进程关联的端口号。

端口号的例子：HTTP server使用端口 80，Mail server使用端口 25。

1.3 应用需要什么样的传输服务

  在创建一个应用程序时，开发者需要选定一种传输服务。

1. Data integrity（数据完整性）
   • 有些应用（如音视频）可以容忍一定程度的数据丢失。
   • 有些应用（如加密的文件）要求完全可靠的数据传输。
2. Timing（时效性）
   • 有些应用（如网络电话，交互式网络游戏）要求延迟保证。
   • 有些应用（如邮件传输）对延迟不敏感。
3. Throughput（吞吐量）
   • 有些应用（如多媒体）要求保证最低可用带宽。
   • 有些应用（称弹性应用，微信文字信息）可以适应各种可能的带宽。
4. Security（安全性）
   • 加密，数据完整性，……

1.4 因特网能够提供的传输服务

  因特网提供2种传输服务，分别用TCP和UDP协议实现。

1. TCP service:
   • 面向连接：保证传输顺序。
   • 可靠传输：不出错。
   • 流量控制：发送进程不会 ‘‘压垮’’ 接收进程。
   • 拥塞控制： 网络超载时抑制发送进程。
   • 不提供：及时性，最低带宽保证，安全性。
2. UDP service:
   • 通过因特网接收和发送报文。
   • 不提供：顺序保证，可靠传输，流量控制，拥塞控制，及时性，最低带宽保证，安全性。
   • 相对于TCP延迟相对小一点，但可能会丢包。

1.5 应用层协议

应用进程之间交换的报文是什么样的？

1. 应用层协议定义：
   • 报文类型：request，response
   • 报文语法：报文中的字段及其描述。
   • 报文语义：各字段中信息的含义。
   • 发送/响应报文应遵循的规则。
2. 公共域协议:
   • 在RFC文档中定义。
   • 允许互操作。
   • e.g.， HTTP, SMTP
3. 专用协议:
   • e.g.， Skype

1.6 小结

1. 为创建一个新的网络应用，需要：
   • 选择一种网络应用架构：客户 - 服务器 or P2P
   • 选择一种网络服务：TCP or UDP
   • 确定一个端口号（主机进程的唯一标识）
   • 定义应用层协议（可以用已有的协议，如HTTP、SMTP…）
   • 编写客户程序和服务器程序（调用套接字接口）
2. 网络应用和应用层协议：
   • 应用层协议只是网络应用的一部分
   • 网络应用还包括客户程序、服务器程序等
3. 要求掌握的概念：
   • 客户-服务器模型
   • 网络应用编程接口

2. Web and HTTP

Web应用画像

1. 应用层资源：网页（web pages）
2. 网络应用架构：客户-服务器架构
   • 客户：浏览器
   • 服务器：web服务器
3. 要求的网络服务：TCP服务
4. 端口号：80
5. 应用层协议：HTTP（Hyper Text Transfer Protocol）HTTPS(在安全性能上做了优化)

一些术语

• Web page由一些对象（object）组成。
• 对象简单来说就是文件，可以是HTML文件、图像、Java小程序、音频文件，…
• 每个对象通过一个URL (Uniform Resource Locator) 获取，例如：
  
• HTML（Hyper Text Markup Language）是一种格式语言，用于描述页的内容和显示方式。
• HTML文件是用HTML语言编写的超文本文件，需要通过专门的浏览器软件进行展示。
• Web页通常包含一个HTML基本文件和若干引用对象，每个引用对象在文档中用其URL给出。
• 超文本文件：包含超链接的文件，超链接中的文字包含有连接到文档中其他位置或者其它文档的链接，允许从当前阅读位置直接切换到超链接所指向的位置。
• 超文本（Hyper text）：一种信息组织方式，通过超链接将各种不同空间的文字信息组织成网状文本。

2.1 超文本传输协议–HTTP 概述

Web采用客户-服务器模式：

• client: 浏览器请求、接收和显示web对象。
• server: Web服务器应客户请求发送对象。

HTTP协议：定义了浏览器和web服务器之间的通信规则。

HTTP的主要版本：HTTP 1.0（RFC 1945）和 HTTP 1.1（RFC 2068）

HTTP为什么要使用TCP服务：Web服务器并不保留客户所请求的信息，HTTP协议是无状态的，为了发送文件的稳定。

HTTP使用TCP服务过程：

• 客户发起到服务器 80 端口的 TCP 连接（客户端创建一个套接字）
• 服务器接受（服务器端监听80端口）来自客户的TCP连接（服务器端创建一个套接字）
• 浏览器和服务器交换HTTP报文 （通过各自的套接字）
• 关闭TCP 连接（关闭各自的套接字）

2.2 非持久连接和持久连接

主要区别：在一个TCP连接上只能传输一个对象还是能传输多个对象。

2.2.1 非持久 HTTP

• 在一个TCP连接上最多发送一个对象。
• HTTP/1.0 使用非持久连接。

内容获取过程：

  假设用户输入以下URL：http://www.someSchool.edu/someDepartment/home.index (包含文本及10个Jpeg图像)

1. HTTP客户发起到以下HTTP 服务器进程的连接 www.someSchool.edu on port 80。
2. www.someSchool.edu上的HTTP服务器在端口80等待TCP连接，接受连接，并通知客户。(建立连接)
3. HTTP客户将一个HTTP请求报文（包含URL）写入它的套接字，报文指示希望获取以下对象：someDepartment/home.index
4. HTTP服务器接收请求报文，构造包含所请求对象的响应报文，将报文写入它的套接字中。(请求对象)
5. HTTP 服务器关闭TCP连接。(关闭连接)
6. HTTP 客户接收包含HTML文件的响应报文，显示HTML文件，解析文件发现有10个引用的jpeg对象。
7. 对于每个jpeg对象，重复步骤 1-6（进行十次）。

非持久HTTP的响应时间：

  RTT (Round-Trip Time)：一个小分组从客户发送到服务器，再返回客户的时间。

相应的时间主要包括：

• 建立TCP连接用时一个RTT。
• 发送HTTP请求至收到响应的前几个字节用时一个RTT。
• 传输文件的时间。

  请求一个对象用时2RTT（忽略对象传输时间），则上面题目中请求一个完整的网页用时22RTT（11个对象）

非持久HTTP 的问题：

  获取每个对象需要一次TCP连接，每个TCP连接需要消耗操作系统资源，浏览器需要打开多个TCP连接来获取一个网页。

2.2.2 持久 HTTP

• 在一个TCP连接上可以发送多个对象。
• HTTP/1.1 缺省使用持久连接。
• 服务器在发送响应后保持连接。
• 同一对客户 - 服务器之间的后续HTTP报文可以在该连接上传输。

持久HTTP又分为：

• 无流水线方式：客户仅当收到前一个响应后再发送新的请求（串行）。
• 流水线方式：客户每解析到一个引用对象就可以发送请求，可在一个RTT时间内请求所有引用对象。

针对上面的问题：

• 无流水线方式：需要花费12个RTT（一次TCP连接、显示HTML文件的请求、10个文件的10次请求）。
• 流水线方式：只需花费3个RTT（一次TCP连接、显示HTML文件的请求、10个文件的1次请求）。

2.3 HTTP 报文格式

1. 请求报文：客户发往服务器
2. 响应报文：服务器发往客户

 HTTP报文由ASCII文本构成。

 HTTP请求报文：

HTTP请求报文：

报头包括：

上传表单输入：

• Post 方法
  • Web页通常包含表单输入。
  • 输入的表单内容放在报文体中上传到服务器。
• URL 方法
  • 使用 GET 方法。
  • 输入内容放在请求行的URL字段中上传，如：www.somesite.com/animalsearch?monkeys&banana。

HTTP方法：

HTTP 响应报文：

HTTP 响应状态代码：

2.4 用户与服务器交互: cookie

四个组成部分：

• HTTP响应报文中的cookie首部行。
• HTTP请求报文中的cookie 首部行。
• 保存在用户主机的cookie文件，由用户的浏览器管理。
• Web网站的后端数据库。

例子：Susan第一次访问某个电子商务网站，当HTTP请求报文到达该网站时，网站为其创建:

• 一个ID
• 在后端数据库中为该ID建立一个表项。

Cookies: 保存"状态"：

Cookies交互的两种方式：

• 服务端：信息保存在服务端的后端数据库，返回ID给客户。
• 客户端：信息发回客户端，保存在cookie文件中，并随请求报文发送给服务器。

2.5 Web缓存（代理服务器）

代理服务器: 代表原始服务器满足HTTP请求的网络实体，保存最近请求过的对象的拷贝。

用户要设置浏览器：所有HTTP请求首先发往web缓存。

浏览器将HTTP请求发送给web缓存：

• 对象在web缓存中: web缓存返回对象。
• 对象不在web缓存中：web缓存从原始服务器获取对象，缓存在本地，然后返回给客户。

Q：web缓存如何知道对象的原始服务器？
A： HTTP请求头中的 host 首部行指出了原始服务器

Web cache既是服务器又是客户：

• 对于浏览器来说是服务器。
• 对于原始服务器来说是客户。

  Web cache通常由ISP提供，多级ISP可能形成多级web缓存。

Web caching 的作用：

• 减少客户请求的响应时间。
• 减少机构接入链路上的流量。

Cache Example：
原始：

链路升级：

安装Web Cache：

2.6 条件 GET

代理服务器如何发现缓存的对象是不是最新的？

2.7 小结

• 因特网上的每个资源（对象）都可以通过URL访问
• HTTP使用TCP连接
  • 非持续HTTP
  • 持续HTTP
• 客户与服务器交互：
  • 报文请求/响应
• HTTP服务器是无状态的，利用cookie技术可以保存用户状态
• 使用web缓存提高请求-响应速度：
  • 使用条件get获得最新的对象副本

3. File Transfer and FTP

3.1 文件传输应用画像

• 应用层资源：文件
• 网络应用架构：客户 - 服务器
• 使用传输服务：TCP
• 端口号：21、20
• 应用层协议：FTP
  • 使用命令/响应交互（不是像HTTP那样使用报文交互）
  • 通常情况下，用户通过FTP用户代理与文件服务器交互

3.2 FTP用户代理

3.3 使用分离的控制连接和数据连接

• 控制连接：
  • 使用端口21，传送客户命令和服务器响应。
  • 控制连接在整个会话期间一直保持。
• 数据连接：
  • 使用端口20，传输文件。
  • 每个数据连接只传输一个文件，发送方用关闭连接表示一个文件传输结束。

3.4 建立连接

1. 服务器在端口21等待客户。
   

2. 客户使用临时端口号建立连接。
   

3. 客户选择一个临时端口号，在该端口上等待服务器的连接请求。
   

4. 客户在控制连接上用PORT命令将临时端口号发送给服务器。
   

5. 服务器使用端口20与客户机给出的端口建立连接。
   

3.5 有关控制连接与数据连接的问题

Q：为什么将控制连接与数据连接分开？
A：不会混淆数据与命令/响应，简化协议设计和实现；在传输文件的过程中可以继续执行其它的操作；便于控制传输过程（如客户可以随时终止传输）

Q：为什么用关闭数据连接的方式结束文件传输？
A：允许动态创建文件（不需预先告知文件的大小）

3.6 FTP小结

• 使用TCP协议，服务器端口号21、20
• 采用命令/响应交互方式
• 使用两条TCP连接：
  • 控制连接（端口21）：会话期间始终保持。
  • 数据连接（端口20）：每条连接仅传输一个文件，且客户与服务器角色交换。