计算机网络（二）

第二章 应用层

应用层协议原理

网络应用的体系结构

• 客户-服务器模式（C/S）
  • 服务器
    • 一直运行
    • 固定的IP地址和周知的端口号
    • 扩展性：服务器场
      • 数据中心进行扩展
      • 扩展性差
  • 客户端
    • 主动与服务器通信
    • 与互联网有间歇性的连接
    • 可能是动态IP地址
    • 不直接与其他客户端通信
• 对等模式（P2P:peer to peer）
  • （几乎）没有一直运行的服务器
  • 任意端系统之间可以进行通信
  • 每一个节点既是客户端又是服务器
    • 自扩展性-新peer节点带来新的服务能力，当然也带来新的服务请求
  • 参与的主机间歇性连接且可以改变ip地址
    • 难以管理
• 混合体：客户-服务器和对等体系结构
  • Napster
    • 文件搜索：集中
      • 主机在中心服务器上注册其资源
      • 主机向中心服务器查询资源位置
    • 文件传输：P2P
      • 任意Peer节点之间

进程通信

进程：在主机上运行的应用程序

• 在同一主机内，使用进程间通信机制通信
• 不同主机，通过交换报文（Message）来通信
  • 使用OS提供的通信服务
  • 按照应用协议交换报文
    • 借助传输层提供的服务

分布式进程通信需要解决的问题

1. 进程标示和寻址问题
   • 进程为了接收报文，必须有一个标识
     • 主机：唯一的32位IP地址
     • 端口号
   • 一个进程：用IP+PORT标示端节点
   • 本质上，一对主机进程之间的通信由两个端节点构成
2. 传输层-应用层提供服务
   • 位置：层间界面的SAP （socket）
   • 形式：应用程序接口API (socket API)
   • 层间接口必须要携带的信息
     • 要传输的报文
     • 谁传的：发送方的应用进程标示
     • 传给谁：对方的应用进程标示
   • 传输层实体（tcp或udp）根据这些信息进行报文的封装
     • 源端口号，目标端口号，数据
     • 将IP地址往下交给IP实体，用于封装IP数据报
   • 如果socket API每次传输报文，都携带如此多的信息，太繁琐易错，不便于管理
     • 用代号标示通信的双方或者单方
     • TCP socket:
       • TCP服务：两个进程之间的通信需要之前建立连接，两个进程通信会持续一段时间，通信关系稳定，可以用一个整数表示两个应用实体之间的通信关系，本地标示，使得穿过层间接口的信息量最小
3. 如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用
   • 定义应用层协议：报文格式，解释，时序等
   • 编制程序，使用OS提供的API ，调用网络基础设施提供通信服务传报文，实现应用时序等

TCP之上的套接字

对于使用面向连接服务（TCP）的应用而言，套接字是4元组的一个具有本地意义的标示

• 四元组：（源IP,源port,目标IP,目标port）
• 唯一的指定了一个会话
• 应用使用这个标示，与远程的应用进程通信
• 不必再每一个报文的发送都要指定这4元组
• 简单，便于管理

UDP之上的套接字

UDP服务，两个进程之间的通信之前无需建立连接，每个报文都是独立传输的，前后报文可能给不同的分布式进程，因此只能用一个整数表示本应用实体的标示

• 2元组：IP,port
• UDP socket指定了应用所在的一个端节点（end point）
• 发送数据报时，采用创建好的本地套接字（标示ID），就不必再发送每个报文中指明自己所采用的IP和port
• 传输报文时，必须要提供对方的IP和端口号，接收报文，传输层需要上传对方的IP,port

应用层协议

定义了运行在不同端系统上的应用进程如何相互交换报文

• 交换的报文类型：请求和应答报文
• 各种报文类型的语法：报文中各个字段及其描述
• 字段的语义：字段取值的含义
• 进程何时、如何发送报文及对报文进行响应的规则

应用协议仅仅是应用的一个组成部分

应用需要传输层提供什么样的服务？如何描述传输层的服务

数据丢失率

延迟

吞吐

安全性

• 机密性
• 完整性
• 可认证性

Internet传输层提供的服务

TCP服务：

• 可靠的传输服务
• 流量控制
• 拥塞控制
• 不能提供的服务：时间保证性、最小吞吐保证和安全
• 面向连接

UDP服务：

• 不可靠数据传输
• 不提供的服务：可靠，流量控制，拥塞控制，时间，贷款保证，建立连接

UDP存在的必要性

• 能够区分不同的进程，而IP服务不能
• 无需建立连接，省去了建立连接时间，适合事务性的应用
• 不做可靠性的工作，适合那些对实时性要求比较高的而对正确性要求不高的应用
• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
  • 由于存在流量控制和拥塞控制，建立在TCP之上的应用发送数的速度和主机向网络发送的实际速度是不一致的

Internet应用及其应用层协议和传输协议

安全TCP

TCP & UDP

• 都没有加密
• 通过互联网传输明文，甚至密码

SSL

• 在TCP上面实现，提供加密的TCP连接
• 私密性
• 数据完整性
• 端到端的鉴别

SSL在应用层

SSL socket API

• 应用通过API将明文交给socket，SSL将其加密在互联网上传输

Web and HTTP

概念

web页：有一些对象组成

对象：可以是HTML文件，JPEG图像，Java小程序，声音剪辑文件等

web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（非实体）

通过==URL==行引用

HTTP概况

HTTP:超文本传输协议

• web的应用层协议
• C/S模式
• HTTP1.0 : RFC 1945
• HTTP1.1 : RFC 2068

HTTP建立在TCP协议之上，使用TCP：

• 客户发起一个与服务器的TCP连接 (建立套接字) ，端口号为 80
• 服务器接受客户的TCP连接
• 在浏览器(HTTP客户端) 与 Web服务器(HTTP服务器 server)交换HTTP报文 (应用层协议报文)
• TCP连接关闭

HTTP是无状态的：服务器不维护关于客户的任何信息，即服务器并不知道是谁访问了自己，这对于需要用户注册，获取用户操作的服务器是十分不友好的

HTTP连接

非持久HTTP

• 最多只有一个对象在TCP连接上发送
• 下载多个对象需要多个TCP连接
• HTTP/1.0使用非持久连接

持久HTTP

• 多个对象可以在一个TCP连接上传输
• HTTP/1.1默认使用持久连接

响应时间模型

往返时间RTT（round-trip time）:一个分组从客户端到服务器，再回到客户端的时间

响应时间：

• 一个RTT用来发起TCP连接
• 一个RTT用来HTTP请求并等待HTTP响应
• 文件传输时间

非持久HTTP的缺点：

• 每个对象要2个RTT
• 操作系统必须为每个TCP连接分配资源

持久HTTP:

• 服务器再发送响应后，仍保持TCP连接
• 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
• 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求
• 非流水方式的持久HTTP
  • 客户端只能在收到前一个响应后才能发出新的请求
  • 每个引用对象花费一个RTT
• 流水方式的持久HTTP
  • HTTP/1.1的默认模式
  • 客户端遇到一个引用对象就立即产生一个请求
  • 所有引用（小）对象只花费一个RTT是可能的

HTTP请求报文

两种类型的HTTP报文：请求、响应

HTTP请求报文：ASCII展示

通用格式：包含，请求行，请求头，空行，请求实体

方法类型

HTTP/1.0 : GET,POST,HEAD

HTTP/1.1 : GET,POST,HEAD,PUT,DELETE

HTTP响应报文

HTTP响应状态码

状态码大全

用户-服务器状态：cookies

四个组成部分

• 在HTTP响应报文中有一个cookie的首部行
• 在HTTP请求报文中含有一个cookie的首部行
• 在用户端系统中保留由一个cookie文件，由用户的浏览器管理
• 在Web站点有一个后端数据库

cookies:维护状态

cookies能带来什么：能够记录每个用户状态的同时会带来隐私问题

详情请见

Web缓存（代理服务器）

目标：不访问源服务器，通过缓存机制满足客户的请求

• 用户设置浏览器，通过缓存访问Web
• 浏览器将所有的HTTP请求发给缓存
  • 命中，缓存直接返回对象
  • 未命中，缓存请求源服务器，然后将对象返回给客户端，同时缓存相应对象

缓存既是客户端又是服务器，通常是由ISP安装

为什么要使用Web缓存？

• 降低客户端的请求响应时间
• 可以大大减少一个机构内部网络与Internet接入链路上的流量
• 互联网大量采用了缓存，可以使较弱的ICP也能够有效提供内容

web缓存存在的问题：数据一致性问题

引入：条件GET方法

目标：如果缓存器中的对象拷贝使最新的，就不要发送对象

方法:详情请见

FTP

FTP:文本传输协议

• 向远程主机上传输文件或从远程主机接收文件
• 客户/服务器模式
  • 客户端：发起传输的一方
  • 服务器：远程主机
• FTP:RFC 959
• FTP服务器端口号：21

FTP:控制连接和数据连接分开

数据传输过程

• FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议
• 客户端通过控制连接获得身份确认
• 客户端通过控制连接发送命令浏览远程目录
• 收到一个文件传输命令时，服务器打开一个到客户端的数据连接
• 一个文件传输完成后，服务器关闭连接

服务器打开第二个TCP数据连接用来传输另一个文件

控制连接： 带外（ “out of band” ）传送

FTP服务器维护用户的状态信息：当前路径、用户帐户与控制连接对应，天生有状态

EMail

电子邮件

3个主要组成部分

• 用户代理
• 邮件服务器
• 简单邮件传输协议：SMTP

邮件服务器

• 邮箱中管理和维护发送给用户的邮件
• 输出报文队列保持待发送邮件报文
• 邮件服务器之间的SMTP协议：发送email报文

SMTP（RFC 2821）

• 使用TCP在客户端和服务器之间传送报文，端口号为25
• 直接传输：从发送方服务器到接收方服务器
• 传输的3个阶段
  • 握手
  • 传输报文
  • 关闭
• 命令/响应交互
  • 命令：ASCII文本
  • 响应：状态码和状态信息
• 报文必须为7位ASCII码（后续打了补丁可以使用中文）

SMTP:总结

• SMTP使用持久连接

• SMTP要求报文（首部和主体）为7位ASCII编码

• SMTP服务器使用CRLF.CRLF决定报文的尾部

与HTTP比较：

• HTTP：拉（pull）
• SMTP：推（push)
• 二者都是ASCII形式的命令/响应交互、状态码
• HTTP：每个对象封装在各自的响应报文中
• SMTP：多个对象包含在一个报文中

报文格式：多媒体拓展

• MIME：多媒体邮件扩展（multimedia mail extension）, RFC 2045, 2056
• 在报文首部用额外的行申明MIME内容类型，可实现报文中可以使用中文

邮件访问协议

SMTP:传送到接收方的邮件服务器

邮件访问协议：从服务器访问邮件

• POP:邮局访问协议（Post Office Protocol）[RFC 1939]
  • 用户身份确认 (代理<–>服务器) 并下载
• IMAP：Internet邮件访问协议（Internet Mail Access Protocol）[RFC 1730]
  • 更多特性 (更复杂)
  • 在服务器上处理存储的报文
• HTTP：Hotmail , Yahoo! Mail等
  • 方便

POP3与IMAP

POP

• “下载并删除”模式
• “下载并保留”：不同客户机上为报文的拷贝
• POP3在会话中是无状态的
• 本地管理文件夹

IMAP

• IMAP服务器将每个报文与一个文件夹联系起来
• 允许用户用目录来组织报文
• 允许用户读取报文组件
• IMAP在会话过程中保留用户状态：目录名、报文ID与目录名之间映射
• 远程管理文件夹

DNS

DNS的必要性

IP地址标识主机、路由器，但IP地址不好记忆，不便人类使用(没有意义)，人类一般倾向于使用一些有意义的字符串来标识Internet上的设备，存在着“字符串”—IP地址的转换的必要性，人类用户提供要访问机器的“字符串”名称，由DNS负责转换成为二进制的网络地址

DNS系统需要解决的问题

• 如何命名设备
  • 用有意义的字符串：好记，便于人类用使用
  • 解决一个平面命名的重名问题：层次化命名
• 如何完成名字到IP地址的转换
  • 分布式的数据库维护和响应名字查询
• 如何维护：增加或者删除一个域，需要在域名系统中做哪些工作

DNS总体思路和目标

DNS的主要思路

• 分层的、基于域的命名机制
• 若干分布式数据库完成域名到IP地址的转换
• 运行在UDP之上的端口号位53的应用服务
• Internet的核心功能，但以应用层协议实现

DNS主要目的

• 实现主机名-IP地址的转换
• 其他功能：
  • 主机别名到规范名字的转换
  • 邮件服务器的别名到邮件服务器的正规名字的转换
  • 负载均衡

问题1：DNS命名空间

DNS域名结构

• DNS采用层次树状结构的命名方法

• Internet根被划为几百个顶级域

  • 通用的（.com; .edu ; .gov ; .int ; .mil ; .net ; .org；.firm ; .hsop ; .web ; .arts ; .rec ; ）
  • 国家的（.cn ; .us ; .nl ; .jp）

• 每个（子）域下面可划分为若干子域

• 树叶是主机

目前全球共有13个根名字服务器

域名

• 从本域往上，知道树根
• 域的域名：可以表示一个域
• 主机的域名：一个域上的一个主机

域名的管理

• 一个域管理其下的子域
• 创建一个新的域，必须征得它所属域的同意

域与物理网络无关

• 域遵从组织界限，而不是物理网络
  • 一个域的主机可以不在一个网络
  • 一个网络的主机不一定在同一域
• 域的划分是逻辑的，而不是物理的

问题2：解析问题—名字服务器

一个名字服务器的问题

• 可靠性问题：单点故障
• 扩展性问题：通信容量
• 维护问题：远距离的集中式数据库

区域（zone）

• 区域的划分由区域管理者自己决定
• 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
• 名字服务器
  • 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息（authoritative record）
  • 名字服务器允许被放置在区域之外，以保障可靠性

TLD服务器

顶级域服务器：负责顶级域名（如com, org, net, edu和gov）和所有国家级的顶级域名（如cn, uk, fr, ca, jp ）

区域名字服务器维护资源记录

• 资源记录（(resource records)

  • 作用：维护 域名-IP地址(其它）的映射关系
  • 位置：Name Server的分布式数据库中

• RR格式: (domain_name, ttl, type,class,Value)

  • Domain_name: 域名

  • Ttl: time to live : 生存时间(权威，缓冲记录）

  • Class 类别 ：对于Internet，值为IN

  • Value 值：可以是数字，域名或ASCII串

  • Type 类别：资源记录的类型

    

本地名字服务器（local name server）

每个ISP都有一个本地的DNS服务器，也被成为“默认名字服务器”

当一个主机发起一个DNS查询时，查询被送到其本地DNS服务器，起到代理的作用，将查询转发到层次结构中

名字解析过程

• 域名在local name server命中
• 域名在local name server未命中
  • 联系根名字服务器顺着根-TLD一直找到权威名字服务器
  • 然后将资源记录缓存下来

递归查询

问题：根服务器的负担太重

迭代查询

DNS协议、报文

DNS协议：查询和响应的报文的报文格式相同

详情

提高性能：缓存

• 一旦名字服务器学到了一个映射，就将该映射缓存起来
• 根服务器通常都在本地服务器中缓存着，使得根服务器不用经常被访问
• 目的：提高效率
• 可能存在的问题：如果情况变化，缓存结果和权威资源记录不一致、
• 解决方案：TTL（默认2天）

问题3：维护问题：新增一个域

• 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名 和 域名服务器的地址
• 在新增子域 的名字服务器上运行名字服务器，负责本域的名字解析： 名字->IP地址

攻击DNS

P2P应用

纯P2P结构

• 没有（或极少）一直运行的服务器
• 任意端系统都可以直接通信
• 利用peer的服务能力
• Peer节点间歇上网，每次IP地址都有可能变化
• 例
  • 文件分发（BitTorrent）
  • 流媒体（KanKan）
  • VoIP (Skype)

文件分发： C/S vs P2P

C/S模式

• 服务器传输：都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝:
  • 发送一个copy: F / $U_S$
  • 发送N个copy： NF / $ U_S$
• 客户端：每个客户端必须下载一个文件拷贝
  • $d_{min}$ = 客户端最小的下载速率
• 采用C/S方法将一个F大小的文件分发给N个客户端耗时$D_{c-s}$ >= max{NF/$U_S$,F/$d_{min}$}

P2P模式

服务器传输：最少需要上传一份拷贝

• 发送一个拷贝的时间：F/$U_S$

客户端：每个客户端必须下载一个拷贝

• 最小下载带宽客户单耗时 : F/$d_{min}$

客户端：所有客户端总体下载量NF

• 最大上载带宽 ： $U_S$ + $\sum U_i$
• 除了服务器可以上载，其他的peer节点也可以上载

采用P2P方式将一个F大小的文件分发给N个客户端耗时

$D_{P2P}$ = max{ F/$U_S$ , F/$d_{min}$,NF/($U_S+\sum U_i$)}

P2P文件分发：BitTorrent

• 文件被分成一个个块256KB
• 网络中的这些peer发送接收文件块，相互服务

Peer加入torrent:

• 一开始没有块，但是将会通过其他节点处累积文件块
• 向跟踪服务器注册，获得peer列表，和部分peer节点构成邻居关系

当peer下载时，该peer可以同时向其他节点提供上载服务

peer可能会变换用于交换块的peer节点

扰动churn：peer节点可能会上线或者下线

一旦一个peer拥有整个文件，它会离开(自私)或者保留(利他)在torrent

BitTorrent:请求，发送文件块

请求块

• 在任何给定时间，不同peer节点拥有一个文件块的子集
• 周期性的，Alice节点向邻居询问他们拥有哪些块的信息
• Alice向peer节点请求它希望的块，稀缺的块

发送块：tit-for-tat

• Alice向4个peer发送块，这些块向它提供最大带宽服务（互利）
  • 其他peer被Alice阻塞（将不会从Alice处获得服务）
  • 每10秒重新评估一次前四位
• 每隔30秒：随机选择其他peer节点，像这个节点发送块
  • “优化疏通”这个节点
  • 新选择的节点可以加入这个top4

P2P文件共享

两大问题

• 如何定位所需资源
• 如何处理peer的加入和离开

可能的方案

• 集中
• 分散
• 半分散

P2P:集中式目录

最初的“Napster”设计

• 当peer连接时，它告知中心服务器
  • IP地址
  • 内容
• Alice从中心服务器查询所需数据，获取对应的peer节点的IP地址，然后请求文件

集中式目录存在的问题：

• 单点故障
• 性能瓶颈
• 侵犯版权

查询洪泛：Gnutella

• 全分布式
  • 没有中心服务器
• 开放文件共享协议
• 覆盖网络：图
  • 如果X和Y之间有一个TCP连接，则二者之间存在一条边
  • 所有活动的对等方和边就是覆盖网络
  • 边并不是物理链路
  • 给定一个对等方，通常所连接的节点少于10个

协议

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YixL5rWp-1633617832790)(https://cdn.jsdelivr.net/gh/UnderWoodse/cloudimg//img/uTools_1633486629153.png)]

对等方加入：

• 对等方X必须首先发现某些已经在覆盖网络中的其他对等方：使用可用对等方列表
  • 自己维持一张对等方列表（经常开机的对等方的IP）
  • 联系维持列表的Gnutella站点
• X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方Y建立连接
• X向Y发送一个Ping报文，Y转发该Ping报文
• 所有收到Ping报文的对等方以Pong报文响应
• X收到许多Pong报文，然后它能建立其他TCP连接

利用不匀称性：KaZaA

• 每个对等方要么是一个组长，要么隶属于一个组长
  • 对等方与其组长之间有TCP连接
  • 组长对之间有TCP连接
• 组长跟踪其所有的孩子的内容
• 组长与其他组长联系
  • 转发查询到其他组长
  • 获得其他组长的数据拷贝

查询

• 每个文件有一个散列标识码和一个描述符
• 客户端向其组长发送关键字查询
• 组长用匹配进行响应：对每个匹配：元数据、散列标识码和IP地址
• 如果组长将查询转发给其他组长，其他组长也以匹配进行响应
• 客户端选择要下载的文件：向拥有文件的对等方发送一个带散列标识码的HTTP请求

小技巧

• 请求排队
  • 限制并行上载的数量
  • 确保每个被传输的文件从上载节点接收一定量的带宽
• 激励优先权
  • 鼓励用户上载文件
  • 加强系统的扩展性
• 并行下载
  • 从多个对等方下载同一个文件的不同部分

Distributed Hash Table (DHT)

• 哈希表
• DHT方案
• 环形DHT 以及覆盖网络
• Peer波动

拓展阅读

CDN

视频流化服务和CDN：上下文

• 视频流量：占据着互联网大部分的带宽
• 挑战：规模性-如何服务者，单个超级服务器无法提供服务
• 挑战：异构性
  • 不同用户拥有不同的能力（例如：有线接入和移动用户；带宽丰富和受限用户）
• 解决方案：分布式的，应用层面的基础设施

多媒体：视频

视频：固定速度显示的图像序列

网络视频特点：

• 高码率：>10x于音频,高的网络带宽需求
• 可以被压缩
• 90%以上的网络流量是视频

数字化图像：像素的阵列，每个像素被若干bits表示

编码：使用图像内和图像间的冗余来降低编码的比特数

• 空间冗余（图像内）
• 时间冗余（相邻的图像间）

CBR(constant bit rate)：以固定速率编码

VBR（variable bit rate）：视频编码速率随时间的变化而变化

存储视频的流化服务

多媒体流化服务：DASH

DASH:Dynamic, Adaptive Streaming over HTTP

服务器：

• 将视频文件分割成多个块
• 每个块独立存储，编码于不同码率
• 告示文件（manifest file）：提供不同块的URL

客户端：

• 先获取告示文件
• 周期性的测量服务器到客户端的带宽
• 查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围
  • 如果带宽足够，选择大码率的视频块
  • 会话的不同时刻，可以切换请求不同的编码块

Content Distribution Networks

挑战: 服务器如何通过网络向上百万同时流化视频内容

选择1: 单个的、大的超级服务中心“mega-server”

• 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
• “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
• 单点故障点，性能瓶颈
• 周边网络的拥塞

选项2: 通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验

• enter deep: 将CDN服务器深入到许多接入网
  • 更接近用户，数量多，离用户近，管理困难
• bring home: 部署在少数(10个左右)关键位置，如将服务器簇安装于POP附近
  • 采用租用线路将服务器簇连接起来

CDN: 在CDN节点中存储内容的多个拷贝,用户从CDN中请求内容,重定向到最近的拷贝，请求内容,如果网络路径拥塞，可能选择不同的拷贝

案例：