计算机网络理论笔记 (2-1): 应用层 (Application Layer)，HTTP 和 SMTP

进程间通信 (Interprocess Communication - IPC)

进程通过进程间通信 (IPC) 相互交谈。若在单台机器上，则通过共享内存 (shared memory) 实现。若在多台机器上 (across machine)，则我们需要其他抽象，如消息传递 (message passing)。

套接字 (Socket)

进程向其套接字发送消息，也可以从套接字接收消息。套接字类似于门 (door)。
发送消息时，将消息推到门外。发送过程依赖于门另一侧的传输基础结构，在接收过程中将消息传递到套接字。应用程序有一些选项，操作系统可以处理详细信息。

要接收消息，进程必须有标识符 (identifier)。主机设备具有唯一的32位IP地址。标识符包括与主机上的进程关联的IP地址和端口号 (port number)。端口号示例：HTTP服务器 80，邮件服务器 25。

客户端-服务器 架构 (client-server architecture)

服务器

• 提供定义明确的请求/响应接口 (request/response interface)。
• 等待请求的长期进程 (long-lived process)。
• 一旦收到请求，便执行。

特点：

1. 永久IP地址。
2. 静态端口约定 static port conventions (如 http:80, email: 25, ssh: 22)。
3. 用于扩展的数据中心。
4. 可以与其他服务器通信以做出响应。

客户端

• 发出请求的短暂进程 (short-lived process)。
• 应用程序的“用户端” (user-side)。
• 启动通讯 (initiate the communication)。

特点：

1. 可能会间歇性连接 (intermittently connected)。
2. 可能具有动态IP地址 (dynamic IP addresses)。
3. 不会和其他客户端直接通讯。

点对点架构 (peer-to-peer)

P2P架构是 no always-on server。其不涉及永久汇合。任意终端系统(点)之间直接通信。有对称的责任 (symmetric responsibility)。
通常用于：文件共享，游戏，区块链和加密货币，视频分发，视频聊天等。

优点

• 点从其他点请求服务，向其他点提供服务。(自我扩展性 self scalability，新的点带来新的服务能力 service capacity 以及新的服务需求)
• 速度：并行性 (parallelism)，争用较少。
• 可靠性：冗余，容错 (fault tolerance)。
• 地理分布 (geographic distribution)。

缺点

• 去中心化控制 (decentralized control) 的基本问题 (状态不确定 state uncertainty：无共享内存或时钟)
• 行动不确定性 (action uncertainty)：相互矛盾的决定 (分布式算法 distributed algorithm 很复杂)

应用层协议需求

其定义了：

• 交换的消息类型：请求/响应
• 消息语法 (message syntax)：消息中包含哪些字段 (fields) 以及 如何划定字段。
• 消息语义 (message semantic)：字段信息的含义。
• 进程何时以及如何发送和响应消息的规则。
• 开放协议 (opening protocols): 在RFC中定义。允许互操作性。如：HTTP, SMTP。
• 专有协议 (proprietary protocols): 如Skype。

应用程序需要什么传输服务：

• 数据完整性(data integrity): 某些应用程序 (如文件传输，网络交易等)需要100%可靠的数据传输。其他应用程序 (如音频) 可以容忍某些丢失。
• 及时性 (timing)：某些应用 (如 互联网电话，互动游戏)要求低延迟 (low delay) 才能算是有效的。
• 吞吐量: 一些应用程序 (如多媒体) 需要定义最小吞吐量来保证有效性。其他应用程序 (弹性应用程序 elastic apps) 利用它们获得的任何吞吐量。
• 安全：加密 (encryption)，数据完整性。

一些通用应用程序的传输服务需求：

互联网传输协议服务

• TCP服务：发送和接受过程之间的可靠传输。
  1. 流量控制 (flow control): 发送方不会冲垮 (overwhelm) 接收方。
  2. 拥塞控制 (congestion control): 网络过载时的节流发送器 (throttle sender)。
  3. 不提供：计时 (timing)，最小吞吐量保证和安全性。
  4. 面向连接 (connection-oriented)：客户机和服务器进程之间需要进行设置。
• UDP服务：发送和接受之间的数据传输不可靠。
  1. 不提供：可靠性，流量控制，拥塞控制，定时，最小吞吐量保证，安全性和连接设置。

Web 和 HTTP

网页由对象组成。对象可以是HTML文件，JPEG图像，Java applet，音频文件等。网页由基本HTML文件组成，其中包含多个引用的对象。每个对象均可通过URL寻址。

统一资源定位符 (Uniform Resource Locator - URL)

• 通讯协议：http, ftp, https, smtp等。
• 主机名：DNS名，IP地址。
• 端口：默认为协议的标准端口，如 http：80, https: 443
• 目录路径：分层的 (hierarchical)，反映文件结构。
• 资源：标识所需的资源。

超文本传输协议 (Hypertext transfer protocol - HTTP)

网页应用层协议。客户端/服务器模型：

• 客户端：请求，接收 (使用HTTP协议) 并显示web对象的浏览器。
• 服务器：web服务器发送 (使用HTTP协议) 对象以响应请求。

HTTP使用TCP：

1. 客户端启动与服务器端口80的TCP连接 (套接字)。
2. 服务器接受来自客户端的TCP连接。
3. 浏览器 (HTTP客户端) 和 web服务器 (HTTP服务器)之间交换 HTTP消息 (应用层协议消息 application-layer protocol messages)。
4. 最后，TCP连接关闭。

HTTP是无状态的 (stateless)。

• 服务器不维护有关过去的客户端请求的信息。
• 维持状态的协议很复杂。
• 如果 服务器/客户端 崩溃，则它们对“状态”的视角可能不具有一致性，必须调和。

HTTP的内容都是文本。

• 这使得协议简单，易于描述消息且是人类可读的。
• 没有关于编码和格式化数据的问题。
• 可变长度的数据 (variable length data)。
• 但同时，他不是最高效的。大多数协议使用了二进制字段 (用字符串发送“12345678”需要8个字节，但是以整数发送，只需要4个字节)
• 报头可以按任何顺序排列。
• 需要字符串的解析和处理。

HTTP请求信息

HTTP响应信息

HTTP响应状态码

状态码显示在服务器到客户端响应消息的第一行。

• 200：OK。请求成功，请求对象被包含在该信息后面。
• 301：moved permanently。请求的对象已移动，此消息后面将指定新位置。
• 400：bad request。服务器无法解析消息。
• 404：not found。请求的文件无法在服务器中被找到。
• 505：HTTP版本不支持。
• 451：由于法律原因而无法使用。
• 429：太多请求。

请求方法类型 (Request Method Type)

HTTP/1.0:

• GET: 请求页面。
• POST: 将用户响应上传到表单。
• HEAD: 要求服务器将请求的对象 (requested object) 置于响应之外。

HTTP/1.1:

• GET, POST, HEAD
• PUT: 将实体主体中的文件上传到URL字段中指定的路径。
• DELETE: 将URL字段中指定的文件删除。
• TRACE, OPTIONS, CONNECT, PATCH: 为了维持连接。

POST方法：网页通常包含表单输入。输入被上传到实体主体中的服务器。
GET(URL中)方法：输入被上传到请求行的URL字段中，如 http://www.somesite.com/animalsearch?monkeys&banana

用户的服务器状态：Cookies

许多网站使用cookie的四个组成部分：

1. HTTP响应消息的cookie报头行。
2. 下一条HTTP请求消息的cookie报头行。
3. cookie文件保存在用户的主机上，由用户的浏览器管理。
4. 网站上的后端数据库。

如: Leo 经常使用 PC 访问互联网。他首次访问一个特定的电商网站。当初始的HTTP请求到达站点时，站点创建: 唯一ID (unique ID) 和 后端数据库中的ID条目 (entry in backend database for ID)。

第三方Cookies

第三方Cookies (来自广告网站) 可以在多个网站上追踪你。

HTTP性能

页面加载时间 (Page Load Time - PLT): 从点击到用户看到页面。网络性能的关键指标。这取决于许多因素，如: 页面内容/结构，涉及的协议，网络带宽和RTT。

改善性能方式：

• 减少要传输的内容大小。(较小的图像，压缩 compression)
• 更改HTTP以更好地利用可用带宽。(持久连接 persistent connections 和流水线 pipelining)
• 更改HTTP以避免重复传输相同的内容。(缓存 caching 和网络代理 web-proxies)
• 将内容移近客户端。(CDN)

非持久HTTP (non-persistent HTTP)

大多数网站都有多个对象 (如HTML文件和一堆嵌入式图像)，我们如何 (朴素地) 检索这些对象？一次一个，每个小对象都建立新的TCP连接。
非持久HTTP便是一次最多通过一个TCP连接发送对象，连接，然后关闭。这意味着下载多个对象就需要多个连接。

RTT (定义)：小数据包从客户端到服务器再返回的时间。

HTTP响应时间：

• 发起TCP连接 需要一个RTT的时间。
• HTTP请求，并返回HTTP响应的前几个字节 需要一个RTT的时间。
• 文件传输时间 (file transmission time)。
• 非持久HTTP响应时间 = 2RTT + 文件传输时间。
  

非持久性：一个TCP连接可以获取一个Web资源。
PLT (页面加载时间) 比较差。(多个TCP慢启动 slow-start 阶段)

两种场景：

• 在同一个服务器建立多个TCP连接。
• 即使资源位于不同的服务器上，也可以顺序请求/响应 (sequential request/responses)。
  

改善方式：使用并发请求和响应 (concurrent requests & responses) 。并行地使用多个连接。但是，不一定保持相应顺序。

持久化HTTP (Persistent HTTP)

在持久化HTTP中，服务器在响应后使TCP连接保持打开状态。通过相同的TCP连接发送同一个客户端/服务器之间的后续HTTP消息。
这将允许TCP学习更准确的RTT估计，也允许TCP拥塞窗口增加。

• 持久而无流水线 (persistent without pipelining): 客户端仅在收到先前的响应后才发出新请求。每个引用对象使用一个RTT。
• 持久并流水线化 (persistent with pipelining): 在HTTP/1.1中引入。客户端遇到引用对象后立即发送请求。所有引用对象使用一个RTT。
  

使用持续流水线的例子：具有一个索引页和三个嵌入式对象的网站。

缓存和网页代理 (Caching and web-proxies)

缓存目标：在不涉及原始服务器的情况下满足客户端请求。
用户设置浏览器: 通过缓存进行网页访问。
浏览器将所有HTTP请求发送至缓存。若请求对象在缓存中，则缓存将对象返回。否则，缓存从源服务器请求对象，并将对象返回给客户端。

缓存既能充当客户端又能充当服务器。通常，缓存是由ISP (大学，公司，住宅ISP) 安装的。

为什么要进行Web缓存？

• 减少客户端请求的响应时间。
• 减少机构访问链接上的流量 (traffic on an institution’s access link)。
• 缓存密集的互联网，使“不佳”的内容提供商能够有效地交付内容。

条件GET (Conditional GET)

目标：如果缓存具有最新的缓存版本，则不发送对象。(无物体传输延迟 no object transmission delay，以及有较低的链路利用率 lower link ultilization)
缓存会在HTTP请求中指定缓存副本的日期。
而服务器则会看如果高速缓存的副本是最新的，则响应不包含任何对象。

缓存检查请求 (Cache Check Request) 示例：

缓存检查响应 (Cache Check Response) 示例：

Etag: 通常用于动态内容 (dynamic content)，该值通常是内容的加密哈希(cryptographic hash of the content)。

缓存地点

• 客户端
• 正向代理 (forward proxies)
• 反向代理 (reverse proxies)
• CDN
  

复制 (Replication)

在许多机器上复制流行的网站。

• 在服务器上分散负载 (spread load)。
• 使内容更接近客户端。
• 当内容不可缓存时提供帮助。

该方法的问题：

• 将客户端定向到特定的副本。
• 在服务器副本 (server replicas) 之间负载均衡 (load balance)。
• 将客户端与附近的服务器配对。
• 价格昂贵。

常用的解决方案：DNS根据客户端的地理位置，服务器负载等返回不同的地址。

CDN

将缓存和复制当成服务。其集成了正向和反向缓存功能。通常由一个实体管理的大规模分布式存储基础架构 (large-scale distributed storage infrastructure)。

拉取(pull - 缓存)和推送 (push - 复制) 的组合：

• 拉取：客户端请求的直接结果。
• 推送：对高访问率 (high access rate) 的期待。

还需要做一些处理，如处理动态网页和转码 (transcoding)。

HTTPS

HTTP是不安全的。(其基本认证使用base64编码发送的密码，可以很容易地转换为纯文本)
HTTPS：通过传输层安全性 (Transport Layer Security - TLS) 加密的连接上的HTTP (connection encrypted HTTP)。其提供 认证 (authentication) 和 双向加密 (bidirectional encryption)。

HTTP具有以下问题：

• 行首阻止 (Head of line blocking): “慢速”对象延迟了之后的请求。(远程存储 vs 本地内存)
  
• 浏览器经常打开多个TCP连接进行并行传输 (parallel transfers)。提高吞吐量并减少行首阻止的影响。增加服务器和网络上的负载。
• HTTP的报头很大。(小对象的开销较高)
• 对象具有依赖关系和不同的优先级(javascript与图片)。“依赖”对象 (dependent object)需要额外的RTT。

未来：HTTP/2

• 二进制，而非文本。这使得高效解析，更加紧凑，更不易出错。
• 响应通过单个TCP连接进行多路复用。服务器可以随时发送响应数据。“快速”对象可以绕过“慢速”对象 (这可以用于避免HOL阻塞)。更少的握手次数，更多的流量(有助于拥塞控制)。
• 多路复用使用优先流控制方案 (prioritized flow-controlled schemes)。紧急响应可以绕过非关键响应。
• 单TCP连接。
• HTTP报头被压缩。
• 推送功能允许服务器将嵌入式对象推送到客户端，而无需等待请求。节约RTT。

SMTP (Simple Mail Transfer Protocol)

电子邮件，有三个主要组成部分：

• 用户代理 (user agent)。 又称“邮件阅读器”，可用于撰写，编辑和阅读邮件。(如outlook, thunderbird) 存储在服务器上的传出和传入消息 (ongoing, incoming messages)。
• 邮件服务器 (mail servers)。 邮箱包含用户的传入消息。传出(待发)邮件的邮件队列。邮件服务器之间的SMTP协议能够用来发送电子邮件。客户端 -> 发送邮件服务器 (sending mail server)。服务器 -> 接收邮件服务器 (receiving mail server)。
• 简单邮件传输协议: SMTP。
  使用TCP可靠地将电子邮件从客户端传输到服务器端的端口25。直接传输：从发送服务器到接收服务器。
  传输的三个阶段： 握手，消息传送，连接关闭。
  命令/响应交互(comand/response interaction 类似HTTP, FTP)。命令是ASCII文本，响应为状态代码和短语。
  消息必须为7位ASCII。

SMTP交互示例

SMTP使用持续连接。SMTP要求消息 (报头和内容) 都为 7字节ASCII。SMTP使用 CRLF.CRLF 来决定消息结束。

HTTP 和 SMTP 比较

HTTP: 拉取方式。每一个对象都封装在其响应消息中。
SMTP: 推送方式。在多部分邮件 (multipart msg) 中发送多个对象。

邮件消息格式

RFC 5322 (822, 2822): 文本消息格式 (Internet Message Format - IMF)的标准：

• 报头行 header line (包括 to:, from:, subject:)
• 正文 (body)，只能包含 ASCII 字符。
  

邮件访问协议 (Mail Access Protocols)

• POP (Post Office Protocol): 授权，下载。
• IMAP (Internet Mail Access Protocol): 更多功能，包括操纵服务器上存储的消息。
• HTTPS: Gmail, Yahoo等。