计算机网络 第二章 应用层协议及网络编程

回顾 TCP/IP 体系结构

对等层通信，执行相关协议

接口层包括数据链路层和物理层

从上往下介绍

2-1 应用层协议与进程通信模型

应用与应用层协议

应用：可进行通信的，分布式进程

• 运行于主机的用户空间
• 通过交换**消息（Message）**实现应用之间的交互
• 例如：Email、Web 等

应用层协议：应用层实体之间的通信规范

• 定义应用交换的消息和收到消息后采取的行动
• 使用下层协议（TCP、UDP）提供的通信服务

在不同层数据叫法：消息、段、数据报、数据帧、比特

进程间通信

进程：主机中运行的程序

• 同一台主机中，两个进程之间按照进程间通信方式进行交互通信（OS定义）
• 不同的主机上的进程通信，需要通过交换消息来完成

客户/服务器（C/S）模型

• 客户向服务器发出服务请求，并接收服务器的响应；服务器等待客户的请求并为客户提供服务
• 例如：Web 浏览器/ Web 服务器；Email 客户端 / Email 服务器

对等计算（P2P模型）

• 最小化（或不同）专用服务器
• 例如：Skype、BitTorrent

客户/服务器进程交互模型

服务器进程

• 被动等待
• 长久在线
• 固定 IP 地址
• 利用云/集群提供扩展性

客户进程

• 启动与服务器的通信
• 可能为间歇性连接
• 可能使用动态 IP 地址
• 不与其它客户进行直接通信

纯 P2P 进程交互模型

• 无长久在线的服务器
• 任意的终端系统之间都可能进行直接通信
• 端系统之间可能间歇性地进行连接
• 端系统可能使用动态的 IP 地址
• 高扩展性但维护困难

客户/服务器 与 P2P 的结合

Skype

• VoIP P2P 应用
• 中心服务器：远程客服的地址发现
• 端-端连接：直连（不通过服务器）

即时消息

• 用户间利用 P2P 模式进行消息发送与聊天
• 中心服务器：用户呈现探测与位置发现
  • 当在线时，用户向消息中心服务器注册其 IP 地址
  • 用户利用中心服务器搜索对方用户的 IP 地址

进程的地址表示

• 为了发送和接受消息，进程必须具有一个标识符
• 主机拥有一个唯一的 32 位 IPv4 地址（或128位 IPv6 地址）
• 利用主机的 IP 地址表示主机中的进程是否可以？（不可以）
• 进程标识符：包括 IP 地址和端口号
• 端口号举例：
  • Web 服务进程：80
  • Email（SMTP）服务器进程：25
• 为了向 Web 服务器发送消息，Web 浏览器需要使用进程标识符
  • IP 地址：202.113.16.33
  • 端口号：80

应用层协议定义的内容

• 消息类型，如请求request、响应response
• 消息的语法，如消息包含哪些字段，字段之间如何分割等（how to do）
• 消息的语义，如字段中信息代表的具体含义（what to do）
• 消息的处理，进程何时发送消息、收到消息后的动作等（when to do）
• 公共协议
  • RFC 中定义的协议
  • 可相互兼容
  • 如：HTTP、SMTP等
• 专有协议
  • 公司或组织拥有
  • 例如：Skype、QQ等

2-2 传输层服务对应用的支持

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

数据丢失率

• 音视频等应用可以容忍一定的数据丢失
• 文件传输、远程登录等应用要求100%的数据可靠

时延

• 网络电话、交互游戏等应用对时延有一定要求

带宽

• 多媒体等应用需要一定的带宽保证
• 有些应用是弹性的

常见应用对传输层的要求（教材上P61）

互联网传输层提供的服务

TCP 服务（书上 P60）

• 面向连接：客户与服务器之间需要建立连接
• 可靠传输：可保证传递数据无差错
• 流量控制：发送数据不会超过接受端的容纳容量
• 拥塞控制：提供拥塞解决方案
• 不能提供：时延和带宽保证

UDP 服务（书上 P62）

• 不可靠：不可靠的数据投递
• 不能提供：连接建立、可靠性、流量控制、拥塞控制、时延和带宽保证

为什么需要 UDP？

设计简单，容易实现。

常见应用使用的传输层服务（书上 P62 下方）

趋势：UDP 应用逐渐增多

2-3 Socket 编程

网络编程界面

• TCP/IP 协议通常在操作系统的内核中实现
• 编程界面：由操作系统提供的功能调用，可以使应用程序方便地使用内核的功能
• 最常用的就是 Socket（套接字）：支持 TCP/IP 的操作系统为网络程序开发提供的典型网络编程界面

Sockets 套接字

• 进程通过套接字发送消息和接受消息
• 套接字可以看成一道“门”
  • 发送进程把消息从“门”推出去
  • 发送进程推出去的消息利用下层通信设施传递到接收进程的“门”
  • 接收进程再从“门”把消息拉进来
• API：选择使用的传输层协议；对套接字的一些参数进行修改

套接字分为两种

• 数据报套接字（datagram sockets）：使用 UDP 协议，支持主机之间面向非连接，不可靠的数据传输
• 流式套接字（stream sockets）：使用 TCP 协议，支持主机之间面向连接的、顺序的、可靠的、全双工的字节流传输服务
• 支持 socket 的操作系统：Windows、UNIX、Linux、iOS、Android等
• 支持 socket 的编程语言：C、C++、Python、Java、VB等

利用 UDP 服务的应用程序编写步骤

socket->bind(绑定端口，客户端可以不用)->sendto/receivefrom->close

利用 TCP 服务的应用程序编写步骤

麻烦，复杂。上层必须保障可靠性

Socket 编程—— C 中常用的 Socket 函数

//WSAStartup
int WSAAPI WSAStartup(//成功返回0，否则错误代码
    WORD wVersionRequested,//调用者希望使用的版本
    LPWSADATA lpWSAData//可用Socket的详细信息
)

• 功能：初始化 Socket DLL，协商使用的Socket版本
• WSADATA：
  • wVersion：推荐调用者使用的Socket版本号
  • wHighVersion：系统实现的Socket最高版本号
• 如果调用成功，不在使用时需要调用WSACleanup释放Socket的DLL资源

……见PPT

作业：

下层使用 TCP（流式套接字），聊天程序。

最基本的：客户端和服务器端的聊天。

互相发送的信息能正确显示，要能显示正确的日期时间

• 应用层协议设计
• 程序设计
• 程序的实现
• 程序如何使用

要求：必须要完成一对一聊天，可选群聊

参考代码：孙一丁学长的代码

https://emanual20.github.io/2020/12/08/计算机网络lab1-TCPsocket聊天室/

2-4 电子邮件服务与协议

• 电子邮件系统的三个主要组件

  • 用户代理（接口）

    • 编辑和发送邮件
    • 接受、读取和管理邮件
    • 管理地址薄
    • 无统一标准

  • 邮件服务器

    • 邮箱：保存用户收到的消息
    • 消息输出队列：消息的发送队列
    • SMTP 协议：邮件服务器之间传递邮件使用的协议
      • smtp 客户：发送邮件端
      • smtp 服务器：接收邮件端

  • 简单邮件传输协议：SMTP

邮件客户/服务器模型（SMTP/POP）

• 用户接口: 编辑和阅读邮件

• 邮件传输进程 (SMTP客户): 向SMTP服务器发起连接与传递邮件

• 邮件服务进程 (SMTP服务器): 从SMTP客户接收邮件和转发邮件，并将邮件分发至用户邮箱

• POP****客户: 连接POP服务器, 发起读取邮件请求

• POP****服务器: 接收POP客户请求，从用户邮箱读取邮件

SMTP：简单邮件传输协议

• 利用TCP可靠地从客户向服务器传递邮件

• 直接投递: 发送端直接到接收端

• SMTP的3个阶段：连接建立、邮件传送、连接关闭

• 命令/响应

  • 命令: ASCII字符串
  • 响应: 状态码+短语

• 消息为7位ASCII

• RFC 821: SMTP

SMTP

• SMTP服务器在TCP的25端口进行监听

• SMTP客户与SMTP服务器的25端口建立TCP连接，并等待服务器的响应

• 如果服务希望接收邮件，邮件客户端会告知邮件的发件人和邮件的收件人

• 如果服务器可以处理收件人的邮件，服务器通知客户发送邮件内容

• 客户发送邮件内容，服务器对其进行响应

• 所有交互完成后，关闭连接

邮件访问协议

• SMTP: 向服务器传递邮件

• 邮件访问协议: 从邮件服务器的邮箱中获取邮件

  • POP: 邮局协议[RFC 1939]
  • IMAP: Internet邮件访问协议
  • [RFC 2060]HTTP: 超文本传输协议

2-5 文件传输服务与协议

2-6 域名系统

域名系统概述

• 互联网中使用IP地址寻址主机（例如：IP数据包转发）

• 为了方便记忆，每台提供服务的主机通常会有一个或多个名字

  • 例如：访问学院网站，输入名字cc.nankai.edu.cn

    对应的IPv4地址：222.30.45.190

    对应的IPv6地址：2001:250:401:d450::190

• 如何将名字映射到地址？

  • 早期的集中式管理和发布
    • 本地存储Hosts文件，实现名字到地址的静态映射
    • 可以通过FTP服务为连入Internet的主机提供域名的发布和下载
  • 存在的问题
    • 扩展性差

• DNS（Domain Name System）：自动实现名字到地址映射的系统

• DNS基本思想

  • 名字和地址映射关系分布式存放，形成具有层次结构的分布式数据库系统（分布式管理）
  • 通过查询分布式数据库，获得名字到地址的映射，或相反

• 关键

  • 如何组织分布式数据库
  • 如何在分布式数据库中查找

DNS 域名体系

按组织类别命名、顶级域名、二级域名、按国家或区域、域名已成为互联网的重要基础性资源

优点：可以支持大规模、快速扩展，不需要中心节点支持；通过部分名字空间的授权实现非集中式管理；名字到地址的映射可以通过分布方式实现

层级命名、逐级授权、多级管理

• 顶级域名：由互联网名称与数字地址分配机构(ICANN)负责管理

  ICANN 与域名注册商签订合同， 准许其受理顶级域名.com、.net、.org 下的域名注册

DNS 域名解析

• 域名解析：名字到地址映射（通过名字查地址）
  • 分布式：层级的服务器组织，协同实现解析
  • 有效性：大多数解析可以在本地完成，一部分会产生互联网流量
  • 可靠性：通过冗余设置，避免单点失效
• 客户-服务器模式
  • 域名服务器：保存名字到地址映射关系（数据库）；接收客户端请求，并给出响应
  • 域名解析器：请求域名解析的客户进程；向域名服务器发起解析请求，并等待服务器的响应

DNS 服务器组织

• 每台域名服务器包含一个或多个区域的信息
• 父节点服务器已知子节点服务器的地址

根域名服务器对互联网发展至关重要，除IPv4时代的13个根服务器，目前在16个国家设立了25台IPv6根服务器，我国部署了4台，打破了我国无根服务器的困境

• 根域名服务器：全球13个逻辑根域名服务器（a~m），每个根服务器都有多个镜像，实际的服务器数量目前达1326个（中国：大陆13个，台湾6个，香港9个）
• 顶级域名服务器（Top-Level Domain, TLD）：负责顶级域名的解析
• 授权域名服务器
  • 对于名字与地址映射，保留其初始数据来源的服务器
  • 主要区分名字与地址映射是原始的还是被缓存的（非授权）
• 本地域名服务器（或称默认域名服务器）
  • 一般每个ISP都部署有域名服务器，其用户可将该服务器设置成本地域名服务器（或默认域名服务器）
  • 当进行域名解析时，查询请求首先发送到本地域名服务器（即查询的起点）

DNS 域名服务器缓存

• 目的：降低非本地名字查询开销及查询延时
  • 通常地址与名字的绑定变化不频繁
• 服务器缓存名字与地址映射关系
  • 服务器学习到某个名字和地址的映射关系时，便进行缓存
  • 记录名字和地址的映射从何处获取
  • 基于授权服务器中的TTL值设置超时时间，缓存的映射关系经过一定时间会超时
  • TLD服务器通常会被本地域名服务器缓存，可以有效减少根域名服务器的访问频度
• 服务器使用缓存的映射关系响应客户端的请求
  • 标记为非授权（nonauthoritative）映射
  • 给出获取映射的服务器的域名和IP地址
• 客户机接收服务器响应
  • 映射有可能过时
  • 如果注重效率，客户端接受非授权响应
  • 如果注重准确性，客户机可以再联系授权服务器，验证映射是否仍有效

主机缓存

• 基本方法
  • 在启动时从本地域名服务器下载名字-地址映射数据库
  • 定期获取新的映射
  • 缓存最近用过的名字和地址映射
• 优点
  • 无需访问域名服务器，名字解析速度快
  • 本地服务器的故障不影响名字解析
  • 减低服务器的负载
• 缺点

DNS 资源记录

• DNS使用区域数据库存储名字与地址映射关系，区域数据库由资源记录（Resource Records，RR）组成
• 资源记录结构：名字、TTL、类型、类、值

2-7 Web 服务与 HTTP 协议

Web 客户/服务器模型

• 服务器
  • Web页面（HTML文档）：包含到多种对象的链接
  • 对象：可以是HTML文档、图像文件、视频文件、声音文件、脚本文件等
  • 对象用URL（统一资源定位符）编址：协议类型://主机名//路径和文件名
• 客户端
  • 发出请求、接收响应、解释HTML文档并显示；
  • 有些对象需要浏览器安装插件

HTTP 协议

• HTTP（ HyperText Transfer Protocol）
  • 传输层通常使用TCP协议，缺省使用TCP的80端口
  • HTTP为无状态协议，服务器端不保留之前请求的状态信息
    • 无状态协议：效率低、但简单
    • 有状态协议：维护状态相对复杂，需要维护历史信息，在客户端或服务器出现故障时，需要保持状态的一致性等
  • HTTP标准

HTTP1.0

非持久连接，一个get请求要一次tcp连接，三次握手，对象请求和传输，关闭连接

HTTP1.1

持久连接，按序响应、停等机制、流水线机制

HTTP报文类型

HTTP两种报文：请求、响应

HTTP请求报文：采用ASCII 数据部分采用MIME格式

HTTP响应报文：数据部分采用MIME格式

响应行、响应头、响应体

HTTP1.1请求方法：get post head put delete

• 典型的状态码
  • 200 OK 请求成功，被请求的对象包含在该响应的数据部分
  • 301 Moved Permanently 请求的对象被移走，新的位置在响应中通过Location: 给出
  • 400 Bad Request 服务器不能解释请求报文
  • 404 Not Found 服务器中找不到请求的文档
  • 505 HTTP Version Not Supported 服务器不支持相应的HTTP版本

用户-服务器交互：认证

• 认证：控制对服务器内容的访问
  • 认证方法：通常使用“名字-口令”
  • 无状态：客户端需要在每个请求中携带认证信息
  • 每个请求头中包含authorization:
  • 如果请求头中无authorization: 则服务器拒绝访问，并在响应头中包含WWW authenticate：

Cookies

服务器使用cookies保持状态

• HTTP响应头中使用set-cookie：选择的cookie号具有唯一性
• 后继的HTTP请求中使用cookie：
• Cookie文件保存在用户的主机中，由用户主机中的浏览器管理
• Web服务器建立后端数据库，记录用户信息

Web缓存机制：客户端缓存

目标：如果被请求的对象在客户端缓存有最近版本，则不需要发送该对象

客户端：在发送的HTTP请求中指定缓存的时间，请求头包含

服务器：如果缓存的对象是最新的，在响应时无需包含该对象，响应头包含

Web缓存机制：代理服务器缓存

目标：由代理服务器进行缓存，尽量减少原始服务器参与

用户设置浏览器：通过代理服务器进行Web访问

浏览器将所有的HTTP请求发送到代理服务器

• 如果缓存中有被请求的对象，则直接返回对象
• 否则，代理服务器向原始服务器请求对象，再将对象返回给客户端

HTTP1.1存在的问题

• HTTP1.1的问题
  • 队头阻塞问题
    • 基于文本协议的问答有序模式，先请求的必须先响应
  • 传输效率问题
    • 文本格式，冗长重复的头部
• HTTP1.1队头阻塞问题解决
  • 浏览器建立多个TCP连接
    • 一般最多建立6个TCP连接
    • 通过不同TCP连接传送请求没有响应顺序的要求
    • 耗费比较多的计算和存储资源

HTTP2.0协议基本原理

• 二进制分帧传输

  • 不改变HTTP原有的语义
  • 将HTTP请求和响应分割成帧，采用二进制编码
  • 帧为最小传输单位

• 最常用的HTTP请求/响应的帧形式

• TCP 连接复用：提高连接利用率，解决HTTP队头阻塞问题

  • 消息message：HTTP一次响应或请求包含一个或多个帧
  • 流stream：简单看成一次请求和应答，包含多个帧
  • 每个TCP连接中可以承载多个流，不同流的帧可以交替穿插传输
  • 流的创建与表示
    • stream ID：表示一个流。客户端创建的流，ID为奇数；服务器创建的流，ID为偶数；0x00和0x01用于特定场景；Stream ID 不能重复使用，如果一条连接上ID分配完，会新建一条连接。接收端通过Stream ID进行消息的组装。
    • 流创建：发送和接收到HEADERS帧（包括新的stream ID）时创建
    • 流优先级：可以依据重要性为流设置不同的优先级（1~256），在headers帧中承载

• 服务器推送：提高响应速度

  • 服务器在请求之前先推送响应信息到客户端，推送的响应信息可以在客户端被缓存

• HTTP头压缩（HPACK）

  • 请求头由大量的键值组成，多个请求的键值重复程度很高
  • 静态表：定义通用HTTP头域，常用键值无需重复传送，直接引用内部字典的整数索引
  • 动态表： 两边交互发现新的头域，添加到动态表
  • 自定义键值：采用Huffman编码

• HTTP 2.0协议解决的问题

  • 通过引入流机制，解决了HTTP队头阻塞问题，提高了传输效率
  • 通过二进制编码、头压缩机制提高了网络带宽利用率
  • 通过服务器推送，加快了页面响应速度

• HTTP 2.0协议没有解决的问题

  • TCP+TLS的多次交互，造成启动延迟问题
  • 对移动主机和多宿主机的连接迁移问题（从wifi切到蜂窝网络会断开）
  • TCP队头阻塞问题

2-8 内容分发网络 CDN

内容分发网络概述

• 基本思想源于MIT对Web服务瞬间拥塞问题的解决（1998）
  • 一种Web缓存系统，靠近网络边缘（用户）提供内容服务
  • 目前提供更丰富的服务，包括静态内容、流媒体、用户上传视频等
• 主要优点
  • 降低响应时延，避免网络拥塞
  • 避免原始服务器过载及防止DDoS攻击
  • 分布式架构，具有良好的可扩展性
  • 对用户透明，无需用户感知
• 关键问题
  • CDN服务器如何布局
  • 在哪里缓存、缓存哪些内容
  • 如何进行重定向，将请求调度到较近或负载较轻的CDN服务器
• CDN服务提供
  • CDN服务提供商：Akamai、蓝讯、世纪互联、网宿等
  • 互联网内容提供商（ICP）：腾讯、百度等
  • 互联网服务提供商（ISP）：移动、联通、电信等

2-9 动态自适应流媒体协议 DASH

概述

• DASH (Dynamic Adaptive Streaming over HTTP)

  • MPEG组织制定的标准（标准号ISO/IEC 23009-1）

  • 基于HTTP的流媒体传输协议

    基于HTTP渐进式下载（类流媒体）

  • 类似协议

    • HTTP Live Streaming（HLS），苹果公司
    • HTTP Dynamic Streaming（HDS），Adobe公司
    • Microsoft Smooth Streaming （MSS） ，微软公司

• 基本思想

  • 完整视频被拆分为固定时长(2s-10s)、不同码率的视频片段(segment)
  • 视频片段与媒体表示描述(Media Presentation Description, MPD) 文件一同存放于DASH服务器
  • 客户端根据自身设备性能、当前网络条件、客户端缓冲大小等自适应选择一种视频码率进行下载

基本原理

例如：HTTP服务器中保存有高中低三种质量的视频片段，DASH客户端评估网络状况，通常在保证视频流畅的前提下，获取最高质量的视频片段

• MPD (Media Presentation Description) 文件

  • 一种XML 文件，描述了DASH流媒体中视频/音频文件信息

• 自适应码率（Adaptive bitrate，ABR）规则

  • 2个主要码率切换规则

    • 基于吞吐量的算法

      例如：使用滑动窗口平均估计未来吞吐量，选择不高于估计值的最大码率视频

    • 基于缓冲的算法

      例如：使用缓冲区满的级别来决定下一个segment的请求码率

  • 放弃请求规则(AbandonRequestsRule)

    • 在下载视频块的过程中，如果算法检测到下载该视频块的过程过有卡顿，则终止当前请求，转而重新下载相应的低码率视频块。

  • 扩展：考虑多DASH服务器同时传输