计算机网络笔记（三）：应用层

网络应用的体系结构

客户机/服务器结构（Client-Server，C/S）：例子 - Web

点对点结构（Peer-to-peer，P2P）：例子 - BT

• 优点：高度可伸缩
• 缺点：难于管理
  

混合结构（Hybrid）：例子 - Napster
-文件传输使用P2P结构

• 文件的搜索使用C/S结构——集中式：1. 每个节点向中央服务器登记自己的内容。2. 每个节点向中央服务器提交查询请求，查找感兴趣的内容。

网络应用进程通信

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

同一主机上运行的进程之间如何通信？

1. 进程间通信机制 2. 操作系统提供

不同主机上运行的进程间如何通信？

1. 消息交换：客户机进程与服务器进程

套接字Socket ：操作系统提供的将网络硬件设施、网络协议栈（例如将链路层、网络层、传输层）进行抽象，进行网络通信的API。

进程间通信利用Socket发送/接收消息实现。

如何寻址进程？

• 不同主机上的进程间通信，那么每个进程都必须拥有标识符。
• 如何寻址主机？—— IP地址 + 端口号
  • 主机有了IP地址后，是否足以定位进程？
  • 否。同一主机上可能同时有多个进程需要通信。
  • 端口号 / Port Number：为主机上的每个需要通信的进程分配一个端口号。

应用层协议

• 网络应用需遵循应用层协议
• 公开协议
  • 由 IETF 组织 RFC（Request For Comments）定义
  • 允许互操作
• 私有协议
  • 多数P2P文件共享应用

应用层协议的内容

• 消息的类型：请求消息、响应消息
• 消息的语法Syntax/格式：消息字段、描述符
• 字段的语义Semantics：字段中信息的含义
• 规则Rules：进程何时发送/响应消息，如何发送/响应消息

网络应用的需求与传输层服务

数据丢失（data loss）/ 可靠性（reliability）

• 某些网络应用能够容忍一定的数据丢失：网络电话，短视频
• 某些网络应用要求100%可靠的数据传输：网络银行，文件传输，telnet

时延（timing delay）

• 有些应用只有在延迟足够低时才“有效”
• 网络电话、网络

带宽（bandwidth）

• 需符合最低要求：网络视频
• 自适应任何带宽：弹性应用email

UDP提供了网络层最基本的服务，给予了应用层极大的自由空间。

C/S 架构

HTTP 协议概述

网页包含多个对象（objects）

• 对象：HTML文件、JPEG图片、视频文件、动态脚本等
• 基本HTML文件：包含对其他对象引用的链接

对象的寻址：

• URL（Uniform Resource Locator）：统一资源定位器 RFC1738

HTTP版本：

• 1.0 ：RFC1945
• 1.1 ：RFC2068

C/S结构:

• 客户——Browser：请求、接收、展示Web对象
• 服务器——Web Server：响应客户的请求，发送对象

使用TCP传输服务：

1. 服务器在80端口等待客户的请求
2. 浏览器发起到服务器的TCP连接（创建套接字Socket）
3. 服务器接受来自浏览器的TCP连接
4. 浏览器（HTTP客户端）与Web服务器（HTTP服务器）交换HTTP消息
5. 关闭TCP连接

HTTP属于无状态（Stateless）：服务器不维护任何有关客户端过去所发请求的信息。

有状态的协议更加复杂：

• 需要维护状态（历史信息）
• 如果客户或服务器失效，会产生状态的不一致，解决这种不一致代价很高

HTTP连接的两种状态：

• 非持久性连接（Nonpersistent HTTP）：每个TCP连接最多允许传输一个对象（HTTP 1.0版本使用非持久性连接），传输完一个对象立即关闭TCP等连接。
• 持久性连接（Persistent HTTP）：每个TCP连接允许传输多个对象（HTTP 1.1版本默认使用持久性连接）。

非持久性连接问题：

• 每个对象需要2个RTT（Roind Trip Time）
• 操作系统需要为每个TCP连接开销资源（OverHead）
• 浏览器会怎么做？
  • 打开多个并行的TCP连接以获取网页所需对象，但会造成服务器端计算资源请求大量增加

持久性连接：发送响应后，服务器保持TCP连接的打开，后续的HTTP消息可以通过这个连接发送

• 无流水（Pipelining）的持久性连接：客户端只有收到前一个响应后才发送新的请求。每个被引用对象耗时1个RTT
• 带流水机制的持久性连接：HTTP 1.1的默认选项。客户端只要遇到一个引用对象就尽快发出请求。理想情况下，收到所有的引用对象只需耗时约1个RTT

HTTP协议有两类消息：

• 请求消息（requst）
  • Post方法：在请求消息的消息体（entity body）中上传客户端的输入
  • URL方法：使用 Get 方法，输入信息通过request 行的 URL字段上传
    
    
• 响应消息（response）

HTTP协议无状态，但很多应用需要服务器掌握客户端的状态，如网上购物。

Cookie技术（RFC6265）：某些网站为了辨别用户身份、进行session跟踪而存储在用户本地终端上的数据（通常经过加密）。

Cookie的组件：

• HTTP响应消息/请求消息的Cookie头部行
• 保存在客户端主机的Cookie文件，由浏览器管理
• Web服务器端的后台数据库

Web缓存的对象需确保实时性：条件GET方法

• 目标：如果缓存有最新的版本，则不需要发送请求对象，HTTP/1.0 304 Not Modified
• 缓存：在HTTP请求消息中声明所持有版本的日期—— if-modified-since:
  

SMTP 协议

SMTP协议（RFC2821）：Email消息的传输 / 交换 协议

• 使用TCP进行Email消息的可靠传输
• 端口25
• 传输过程的三个阶段：握手、消息的传输、关闭
• 命令 / 响应交互模式
• 使用持久性连接
• 要求消息必须由7位ASCII码构成
• SMTP服务器利用CRLF.CRLF确定消息的结束

RFC 822：文本消息格式标准

• 头部行（Header）
• 消息体（Body）

MIME：多媒体邮件拓展 RFC 2045,2056

• 通过在邮件头部增加额外的行以声明MIME的内容类型

POP协议：

• 认证过程：客户端命令 + 服务端响应
• 事务阶段：List + Retr + Dele + Quit
• 下载并删除模式：用户如果换了客户端软件，无法重读该软件
• 下载并保持模式：不同客户端都可以保留消息的拷贝

IMAP协议：

• 所有消息统一保存在一个地方：服务器
• 允许用户利用文件夹组织消息
• 支持跨会话的用户状态

Internet上主机/路由器的识别问题

• IP地址
• 域名：www.hit.edu.cn
• 域名和IP地址之间如何映射？

DNS 协议

DNS：Domain Name System 域名解析系统DNS

• 多层命名服务器构成的分布式数据库
• 应用层协议：完成名字的解析

DNS服务

• 域名向IP地址的翻译
• 主机别名
• 邮件服务器别名
• 负载均衡：Web服务器
• 分布式层次式数据库：DNS根域名服务器、TLD和权威域名服务器(顶级域名服务器)、本地域名解析服务器
• 记录的跟新、通知机制（RFC2136）

问题：为什么不使用集中式的DNS?

• 单点失败问题
• 流量问题
• 距离问题
• 维护性问题

DNS记录（资源记录，RR，resource records）

• RR format：name，value，type，ttl
• Type = A
  • name：主机域名
  • Value：IP地址
• Type = NS
  • name：域（edu.cn）
  • Value：该域权威域名解析服务器的主机域名
• Type = CNAME
  • name：某一真实域名的别名（www.ibm.com —— serverest.backup2.ibm.com）
  • Value：真实域名
• Type = MX
  • Value是与name相对应的邮件服务器

DNS协议

• 查询（query）和回复（reply）消息
• 消息格式相同
• 消息头部
  • Identification：16位查询编号，回复使用相同的编号
  • Flags：查询与恢复、期望递归、递归可用、权威回答

P2P 架构

Peer-to-Peer

• 没有服务器
• 任意端系统之间直接通信
• 节点阶段性接入Internet
• 节点可能更换IP地址
• 架构协议较复杂，难管理

文件分发：BitTorrent

• tracker：跟踪参与torrent的节点
• torrent：交换同一文件的文件快的节点组
• 文件划分位256KB的chunk
• 节点加入torrent
  • 没有chunk，但是会逐渐积累
  • 向tracker注册以获得节点清单，与某些节点（”邻居“）建立连接
• 下载的同时，节点需要向其他节点上传chunk
• 节点可能加入或离开
• 一旦节点获得完整的文件，它可能（自私地）离开或（无私地）留下

获取Chunk

• 给定任意时刻，不同的节点持有文件的不同chunk集合
• 节点定期查询每个邻居所持有的chunk列表
• 节点发送请求，请求获取确实的chunk（稀缺有限，因为节点可能离开）
• 发送chunk：tik-for-tat
  • 向正在对自身发送chunk且速率最快的4个节点（每10秒重新评估）发送chunk
  • 每30秒随机选择一个其他节点，向其发送chunk
    • 新选择的节点可能加入Top4
    • ”optimistically unchoke“

索引技术

索引技术：信息到节点位置（IP地址+端口号）的映射

文件共享（电驴）

• 利用索引动态跟踪节点所共享的文件的位置
• 节点需要告诉索引它拥有哪些文件
• 节点搜索索引，从而获知能够得到哪些文件

即时消息（QQ）

• 索引负责将用户名映射到位置
• 当用户开启IM应用时，需要通知索引它的位置
• 节点检查索引，确定用户的IP位置

集中式索引

Napster最早采用这种设计

1. 节点加入时，通知中央服务器：IP地址、内容
2. 某个节点查找文件时，向中央服务器发起请求，中央服务器返回持有文件的节点
3. 请求节点向持有文件的节点发起获取请求

问题：内容和文件传输是分布式的，但是内容定位是高度集中式的

• 单点失效问题（中央服务器宕机）
• 性能瓶颈
• 版权问题

分布式索引

洪范式查询：Query Flooding

• 完全分布式架构
• Gnutrlla采用这种架构
• 每个节点对它共享的文件进行索引，且只对它共享的文件进行索引
• 覆盖网络（Overlay network）：Graph
  • 节点X与Y之间如果有TCP连接，那么构成一个边
  • 所有的活动节点和边构成覆盖网络
  • 边：虚拟链路
  • 节点一般邻居数少于10个
• 查询消息通过已有的TCP连接发送
• 节点转发查询节点
• 如果查询命中，则利用反向路径发回查询节点

层次式覆盖网络

介于集中式索引和洪范式查询之间的方法，每个节点或者是一个超级节点，或者被分配一个超级节点

• 节点和超级节点维持TCP连接
• 某些超级节点对之间维持TCP连接
• 超级节点负责跟踪子节点的内容