第2讲: 应用层 本讲目标: 深层次目标 网络应用层的概念和实现 特定协议: 客户端-服务器范式 服务模型 通过对常用应用层协议的探讨和分析来学习网络协议 深层次目标 特定协议: http ftp smtp pop dns 第2讲:应用层

应用程序和应用层协议 应用程序:沟通, 分布式的进程 应用层协议： 运行在网络主机中的 “用户空间” 在应用程序间交换报文 e.g., email, ftp, Web 应用层协议： 应用层的一个“组成部分” 定义应用程序需交换的报文 和所需采取的动作 使用较低层次所提供的通信服务 (TCP, UDP) application transport network data link physical 第2讲:应用层

网络应用程序: 一些术语 进程(Process): 主机中运行中的程序. 在某些主机中, 两个进程使用进程间通信 (由 OS管理). 而运行在不同主机上的进程则使用应用层协议进行通信 用户代理（User agent）: 软件进程, 是介于用户（ above ）和网络（ below ）之间的接口 实现应用级协议 Web: 浏览器 E-mail: OE、Foxmail 流媒体: media player 第2讲:应用层

典型的网络应用都是由两个部分组成: 客户端 和 服务器 客户端-服务器范式 典型的网络应用都是由两个部分组成: 客户端 和 服务器 application transport network data link physical reply request 客户端: 发起同服务器的联系 (“speaks first”) 一般都从服务器请求服务, Web: 客户端由浏览器实现; e-mail: 通过OE、Foxmial实现 服务器: 向客户端提供所请求的服务 e.g., Web 服务器发送被请求的 Web 页面, 邮件服务器传递 e-mail 第2讲:应用层

应用层协议(续) 应用程序接口（API: application programming interface） 定义应用层和传输层间的接口 插口（socket: Internet API） 两个进程间的通信， 将数据送入 socket, 或从socket 读出数据 Q: 某个进程如何“认定”另一个 需要与之通信的进程? IP 地址-运行另一个进程的主机所拥有的 “端口号（PORT #）” – 允许接收主机来确定的一个标识，本地进程将报文发送给它 第2讲:应用层

应用进程需要怎样的传输服务? 数据丢失（Data loss） 带宽（Bandwidth） 某些应用 (e.g., audio) 可以容忍某种程度上的数据丢失 其他应用 (e.g., 文件传输, telnet) 要求 100% 可靠的数据传输 带宽（Bandwidth） 某些应用(e.g., 多媒体) 对最低带宽有要求 其他应用(“弹性应用”) 则可灵活应用所能得到的带宽 实时性（Timing） 某些应用(e.g., IP 电话, 交互式游戏) 要求较低的时延 第2讲:应用层

常用应用程序对传输功能的要求 应用程序 数据丢失 带宽 实时性 文件传输 e-mail Web 网页 实时音频/视频 存储音频/视频 交互式游戏 金融应用 数据丢失 不丢失 允许丢失 带宽 弹性 音频: 5Kb-1Mb 视频:10Kb-5Mb 同上 几 Kb/s 以上 实时性 无 100’s msec few secs yes and no 第2讲:应用层

Internet 的传输协议服务 UDP服务: TCP 服务: 在客户端和服务器进程之间实现“不可靠的”数据传输 面向连接: 在客户端和服务器进程之间需要建立连接（setup ） 可靠传输 : 在发送和接受进程之间 流量控制: 发送数据的速度决不超过接收的速度 拥塞控制: 当网络超负荷时，束紧发送端口，减缓发送速度 不提供: 实时性, 最小带宽承诺 UDP服务: 在客户端和服务器进程之间实现“不可靠的”数据传输 不提供:连接建立, 可靠性保证,流量控制,拥塞控制,实时性, 最小带宽承诺 Q: 既生喻，何生亮? Why is there a UDP? 第2讲:应用层

Internet应用: 应用, 传输协议 应用协议 应用 所依赖的传输协议 smtp [RFC 821] telnet [RFC 854] http [RFC 2068] ftp [RFC 959] 专有协议 (e.g. RealNetworks) NSF (e.g., Vocaltec) 应用 e-mail 远程终端访问 Web 文件传输 流媒体 远程文件服务器 IP电话 所依赖的传输协议 TCP TCP or UDP typically UDP 第2讲:应用层

http 协议 http: TCP 传输服务: http 是 “无状态（stateless）”的 http 报文(应用层协议报文) 在浏览器 (http client) 和Web服务器(http server)之间进行交换 关闭TCP 连接 http 是 “无状态（stateless）”的 服务器不保留任何访问过的请求信息 小评论 保留状态的协议很复杂哟! 过去的历史 (状态) 需要保留 一旦浏览器/服务器崩溃, 它们各自的状态视图就会发生分歧，还需要重新核对 第2讲:应用层

Web: http 协议 超文本传输协议（http: hypertext transfer protocol） 万维网应用协议 客户端/服务器模式 客户端: 浏览器请求、接收、展示 Web对象（ objects） 服务器: Web 服务器发送对象对请求进行响应 http1.0: RFC 1945 http1.1: RFC 2068 http request PC running Explorer http response http request Server running NCSA Web server http response Mac running Navigator 第2讲:应用层

http 举例 假设用户键入了一个 URL www.someSchool.edu/someDepartment/home.index (该网页包含文本并引用了10 jpeg 图片) 1a. http 客户端启动 TCP 连接到www.someSchool.edu上的http 服务器 (进程). Port 80 是 http 服务器的默认端口. 1b. 在www.someSchool.edu 上的http 服务器在 port 80 等待 TCP 的连接请求. “接受” 连接并通知客户端 2. http客户端发送 http 请求报文 (包括URL) 进入 TCP 连接插口（socket） 3. http 服务器接收到请求报文, 形成 响应报文（ 包含了所请求的对象 ，someDepartment/home.index), 将报文送入插口（ socket） time 第2讲:应用层

http 举例 (续.) 4. http 服务器关闭 TCP 连接. 5. http 客户端接收到了包含html文件的响应报文。 分析 html 文件, 发现 10 个引用的 jpeg 对象 time 6. 对10 jpeg objects 逐个重复1-5 步 第2讲:应用层

非持续和持续连接 http/1.1的默认设置 http/1.0: 服务器分析请求、响应、关闭 TCP 连接 （非持续连接）Non-persistent http/1.0: 服务器分析请求、响应、关闭 TCP 连接 取对象需要2 RTTs TCP 连接 对象请求/传送 每次传送都要受到TCP连接初始化时的慢启动影响 许多浏览器同时打开多个并行的连接来改善性能 （持续连接）Persistent http/1.1的默认设置 在同一TCP 连接上: 服务器分析请求、响应请求，分析新的请求、.. 客户端一旦下载到了基本的html文件（ base HTML ）马上发送对所有引用对象的请求. 较少的 RTTs, 较少的慢启动. 第2讲:应用层

http 报文格式: request（请求） two types of http报文: request, response http 请求报文: ASCII (可读格式) GET /somedir/page.html HTTP/1.0 User-agent: Mozilla/4.0 Accept: text/html, image/gif,image/jpeg Accept-language:fr (额外的 carriage return, line feed) 请求行 (GET, POST, HEAD 命令) 首部 诸行 回车、换行表示 报文结束 第2讲:应用层

http 请求报文: 一般格式 第2讲:应用层

http 报文格式: response（响应） 状态行 (协议状态码 状态短语) HTTP/1.0 200 OK Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ... 首部 诸行 数据, e.g., 被请求的html文件 第2讲:应用层

http 响应状态码和短语 位于（服务器->客户端）响应报文的第一行. 样例: 200 OK 请求成功, 被请求的对象在报文中 301 Moved Permanently 被请求的对象被移动过, 新的位置在报文中有说明 (Location:) 400 Bad Request 服务器不懂请求报文 404 Not Found 服务器上找不到请求的对象 505 HTTP Version Not Supported 第2讲:应用层

GET /~j1010/hello.htm HTTP/1.0 1. 用Telnet 连接测试用的服务器（需要预先登录UNIX）: $telnet 202.117.35.70 80 打开 TCP 连接到 port 80 (默认的http 服务器端口) 位于 202.117.35.70 后续键入的内容将发送到202.117.35.70 的 80 号端口 2. 键入一条 http请求报文: 将该指令键入后 (按两次回车键), 就将此最短之 (但是完整的) GET 请求发到了 http 服务器 GET /~j1010/hello.htm HTTP/1.0 3. 请注意观察http服务器发回的响应报文! 第2讲:应用层

用户-服务器的交互: 认证（authentication） 认证 : 控制对服务器内容的访问 信用认证: 一般通过用户名, 口令进行 无状态: 客户端必须在每次请求前进行认证 authorization: 就是要求在每个请求报文中提交认证的首部行 如果客户端没有提交 authorization: 首部行, 服务器将拒绝访问, 只是在响应报文首部中发送 WWW authenticate: client server 普通 http 请求报文 401: 认证要求 WWW authenticate: 普通 http 请求报文 + Authorization: <cred> 普通 http响应报文 普通 http 请求报文 + Authorization: <cred> time 普通 http响应报文 第2讲:应用层

Cookies: 保存 “状态” client server 服务器产生一个 # , 服务器认识这个 #, 以备不时之需: 认证 记忆用户的前序访问, 先前的选择 服务器在响应报文中发送 “cookie” 给客户端 Set-cookie: 1678453 客户端可以在后继的请求中发送“cookie” cookie: 1678453 client server 普通 http 请求报文 普通 http响应报文+ Set-cookie: # 普通 http 请求报文 cookie: # cookie- 特定的 普通 http响应报文 普通 http 请求报文 cookie: # cookie- 特定的 普通 http响应报文 第2讲:应用层

Conditional GET: 客户端缓存机制 目的: 如果客户端缓存了最新的请求对象，则服务器不必重复发送 客户端: 在http请求报文中声明所缓存拷贝的生成日期 If-modified-since: <date> 服务器: 如果客户端缓存的拷贝是最新的，则在响应报文中不发请求的对象: HTTP/1.0 304 Not Modified client server http请求报文 If-modified-since: <date> 对象未经修改 http响应报文 HTTP/1.0 304 Not Modified http请求报文 If-modified-since: <date> 对象已 经修改 http响应报文 HTTP/1.1 200 OK <data> 第2讲:应用层

Web 缓存：代理服务器 (proxy server) 目的: 满足客户端的请求而无需烦扰原始服务器 用户设置浏览器: Web 访问经由代理服务器 客户端发送所有的 http 请求到代理服务器 代理服务器保存了请求的对象: 代理服务器返回请求的对象 否则代理服务器从原始服务器请求对象,再将其返回给客户端 origin server Proxy server http request http request client http response http response http request http response client origin server 第2讲:应用层

为何Web缓存? 前提: 缓存与客户端比较“接近 “(e.g., 在同一网络中) 响应时间较短:缓存与客户端比较“接近 “ 减少了往来与远程服务器间的数据流量 因为从学校或本地ISP 通往外部的链路往往是网络瓶颈 origin servers public Internet 1.5 Mbps access link institutional network 10 Mbps LAN institutional cache 第2讲:应用层

ftp: 文件传输协议 传输文件往来与远程主机 客户端/服务器模式 客户端: 启动传输 (无论与往来远程主机) 服务器: 远程主机 file transfer FTP server user interface client local file system remote file at host 传输文件往来与远程主机 客户端/服务器模式 客户端: 启动传输 (无论与往来远程主机) 服务器: 远程主机 ftp: RFC 959 ftp 服务器: 端口 21 第2讲:应用层

TCP control connection ftp: 分离的控制, 数据连接 ftp客户端在 ftp 服务器的 端口21进行联系, 使用TCP作为传输协议 打开两个并行的连接: 控制:在客户端和服务器之间交换命令, 响应。称为带外控制： “out of band control” 数据: 往来于服务器的文件 ftp 维持状态 （state）: 当前目录、先前的认证信息等 FTP client server TCP control connection port 21 TCP data connection port 20 第2讲:应用层

ftp 命令, 响应 返回码样例 样例命令: 状态码和短语 (同 http) 在控制通道上传送的ASCII文本 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file 样例命令: 在控制通道上传送的ASCII文本 USER username（登录） PASS password（登录） LIST （返回当前目录中的文件列表） RETR filename （取 (gets) 文件） STOR filename （存(puts) 文件到远程主机） 第2讲:应用层

电子邮件 四个重要组件: SMTP 用户代理 邮件服务器 简单邮件传输协议: smtp 邮局协议：pop 写作, 编辑, 阅读邮件报文 外发报文队列 四个重要组件: 用户代理 邮件服务器 简单邮件传输协议: smtp 邮局协议：pop 写作, 编辑, 阅读邮件报文 e.g., Foxmail, OE, elm, Netscape Messenger 外发, 接收的报文存储在邮件服务器中 用户邮箱 mail server user agent SMTP 第2讲:应用层

电子邮件:邮件服务器 Mail Servers 邮箱 包含了收到的用户邮件 (尚未被阅读) 报文 队列包含了外发的 邮件报文 smtp 协议用在邮件服务器之间发送邮件 客户端: 将邮件发送到邮件服务器 “服务器”: 接收和转发邮件 mail server user agent SMTP 第2讲:应用层

电子邮件: smtp [RFC 821] 邮件报文必须使用7-bit ASCII表示 使用 tcp 可靠的传送邮件报文, 端口25 直接传输: 发送服务器到接收服务器 传输的三个阶段 握手(打招呼) 报文传输 结束 命令/响应交互 命令: ASCII文本 响应: 状态码和短语 邮件报文必须使用7-bit ASCII表示 第2讲:应用层

smtp 交互样例（在UNIX中用telnet） S: 220 X1 NT-ESMTP Server ctec.xjtu.edu.cn C: HELO xqcheng@ctec.xjtu.edu.cn S: 250 hello ctec.xjtu.edu.cn C: MAIL FROM:<xqcheng@ctec.xjtu.edu.cn> S: 250 ok C: RCPT TO:<lengdou@263.net> S: 250 ok its for <lengdou@263.net> C: DATA S: 354 ok, send it; end with <CRLF>.<CRLF> C: Hi, I am in XUJI now,Where are you? C: . S: 250 Message queued C: QUIT S: 221 Goodbye 第2讲:应用层

自测 smtp 交互: $telnet 202.117.35.170 25 见到邮件服务器的 220 响应后 键入 HELO, MAIL FROM, RCPT TO, DATA, QUIT 命令 上述过程可以不使用用户代理，就能直接将电子邮件发送出去（因为目前大部分邮件服务器的交互过程趋于复杂，本试验不一定都能进行）。 第2讲:应用层

smtp: 评述 与 http的比较: smtp 使用持续连接 smtp 要求报文 (首部 & 信体) 全部使用 7-bit ASCII码 某些代码组合不允许出现在报文中 (e.g., CRLF.CRLF). 此类数据必须进行编码 (通常使用 base-64 或 quoted printable) smtp 服务器用 CRLF.CRLF 表示邮件报文的结束 与 http的比较: http: pull（拉） email: push（推） 都使用 ASCII 命令/响应交互, 状态码 http: 每个对象分装在各自的响应报文中 smtp:多个对象在一个多分部的报文中传送 第2讲:应用层

邮件报文格式 header body smtp: 交换邮件报文的协议 RFC 822: 文本报文格式标准: 首部诸行, e.g., 空行 To: From: Subject: 不同 于 smtp 命令! 信体 即 “报文”, ASCII characters only header 空行 body 第2讲:应用层

邮件格式: 多媒体扩展 MIME: multimedia mail extension, RFC 2045, 2056 From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data 多媒体类型, 子类型, 参数声明 数据编码方法 MIME 版本 编码后的数据 第2讲:应用层

MIME 类型声明 Content-Type: type/subtype; parameters Text 子类型样例: plain, html Image 子类型样例: jpeg, gif Audio 子类型样例: basic (8-bit mu-law encoded), 32kadpcm (32 kbps coding) Video 子类型样例: mpeg, quicktime Application 需使用其他阅读器的数据 子类型样例: msword, octet-stream 第2讲:应用层

MIME多分部类型 From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=98766789 --98766789 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Dear Bob, Please find a picture of a crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data --98766789-- 第2讲:应用层

邮件访问协议 SMTP SMTP POP3 or IMAP SMTP: 发送/存储 到接收方的服务器 邮件访问协议: 从服务器中取信 user agent user agent sender’s mail server receiver’s mail server SMTP: 发送/存储 到接收方的服务器 邮件访问协议: 从服务器中取信 POP: Post Office Protocol [RFC 1939] 认证 (agent <-->server) 和下载 IMAP: Internet Mail Access Protocol [RFC 1730] 更多功能(更为复杂) 在服务器中操作存储在那里的报文 HTTP: Hotmail , Yahoo! Mail, 263.net,etc. 第2讲:应用层

POP3 协议 认证阶段 C: list 交互阶段, 客户端: 客户端命令: user: 用户名 pass: 口令 服务器响应 +OK S: +OK POP3 server ready C: user alice S: +OK C: pass hungry S: +OK user successfully logged on 认证阶段 客户端命令: user: 用户名 pass: 口令 服务器响应 +OK -ERR 交互阶段, 客户端: list: 列出报文号码 retr: 用报文号码取信 dele:用报文号码删信 quit C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> C: dele 1 C: retr 2 C: dele 2 C: quit S: +OK POP3 server signing off 第2讲:应用层

自测 pop3交互: $telnet 202.117.35.70 110 见到+OK POP3 server ready 响应后 键入 user, pass, list, retr, quit 命令 上述过程可以不使用用户代理，就能察看邮箱中的信件。 第2讲:应用层

DNS: 域名系统 Domain Name System: 自然人: 诸多定义: 分布式数据库：由许多域名服务器按层次构成 身份证, 姓名, 护照 # 因特网主机, 路由器: IP 地址 (32 bit) – 用于数据报寻址 “域名”, e.g., ctec.xjtu.edu.cn – 帮助记忆 Q: IP 地址和域名之间如何映射(转换) ? Domain Name System: 分布式数据库：由许多域名服务器按层次构成 应用层协议： 主机、路由器、域名服务器互相通信进行域名解析 (地址/域名翻译) 注意: 因特网之核心功能, 应用层之协议 网络“边缘”上之复杂实体 第2讲:应用层

DNS name servers 没有服务器能够保存所有 Name-to-IP 地址的映射 为什么不搞集中的DNS? 单点失败的问题 数据的流通量 远程集中式的数据库 维护问题 难以与时俱进，跟不上发展! 没有服务器能够保存所有 Name-to-IP 地址的映射 本地域名服务器: 每个 ISP, 企业可拥有 本地(默认) 域名服务器 主机的 DNS 查询首先发往本地域名服务器 授权域名服务器: 每台主机必须在授权服务器上注册登记 可完成域名/地址的转换 第2讲:应用层

DNS: 根域名服务器 当本地域名服务器不能解析时，就向根域名服务器查询 根域名服务器: 如果域名映射未知，则向授权域名服务器查询 取得映射 将映射返回本地域名服务器 b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA 遍布世界各地的13个根域名服务器 第2讲:应用层

authorititive name server 简单 DNS 举例 root name server 主机 ctec.xjtu.edu.cn 要求 gaia.cs.umass.edu 的IP 地址 1. 联系本地域名服务器, 202.117.0.20 2.如有必要202.117.0.20 会联系根域名服务器 3.如有必要根域名服务器会联系授权域名服务器, dns.umass.edu 2 4 3 5 local name server 202.117.0.20 authorititive name server dns.umass.edu 1 6 requesting host ctec.xjtu.edu.cn gaia.cs.umass.edu 第2讲:应用层

DNS 举例 根域名服务器: 可能不知道授权域名服务器的地址 可能知道中介域名服务器: 由它负责联系授权域名服务器 root name server 根域名服务器: 可能不知道授权域名服务器的地址 可能知道中介域名服务器: 由它负责联系授权域名服务器 2 6 7 3 local name server 202.117.0.20 intermediate name server dns.umass.edu 4 5 1 8 authoritative name server dns.cs.umass.edu requesting host ctec.xjtu.edu.cn gaia.cs.umass.edu 第2讲:应用层

DNS: 迭代查询 递归查询: 迭代查询: 对根域名服务器造成工作负担 如何减负? 被查询的服务器直接把可查询的服务器地址报回 root name server 递归查询: 对根域名服务器造成工作负担 如何减负? 迭代查询: 被查询的服务器直接把可查询的服务器地址报回 “不懂这个域名, 但可以从这个服务器查到” iterated query 2 3 4 7 local name server dns.eurecom.fr intermediate name server dns.umass.edu 5 6 1 8 authoritative name server dns.cs.umass.edu requesting host surf.eurecom.fr gaia.cs.umass.edu 第2讲:应用层

DNS: 缓存和更新纪录 一旦 (任何) 域名服务器得知了某个映射, 就将其 缓存 在一定的时间间隔后缓存的条目将会过期(自动消除) 更新/通知 机制由 IETF负责设计 RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html 第2讲:应用层

RR 格式: (name, value, type,ttl) DNS 纪录 DNS: 存储资源纪录 (RR)的分布式数据库 RR 格式: (name, value, type,ttl) Type=A name = 主机名 value = IP 地址 Type=CNAME Name= 别名 www.ibm.com is really servereast.backup2.ibm.com value =真名 Type=NS name = 域 (e.g. foo.com) value =该域授权域名服务器的 IP 地址 Type=MX value = 与 name相关的邮件服务器域名 第2讲:应用层

DNS 协议, 报文 DNS 协议 : 查询和应答报文, 二者格式相同 报文首部 identification: 16 bit # 用于查询, 应答报文使用同样的 # flags: 查询 或 应答 希望递归 可以递归 授权应答 第2讲:应用层

DNS 协议, 报文 Name, type fields 查询报文 RRs 响应 来自授权服务器的纪录 其他“帮助”信息 第2讲:应用层

本讲小结 Our study of network apps now complete! 应用服务的要求: 特定协议: 客户端-服务器范式 可靠性, 带宽, 延迟 客户端-服务器范式 Internet 传输服务模型 面向连接的, 可靠的: TCP 不可靠的, 数据报: UDP 特定协议: http ftp smtp, pop3 dns 第2讲:应用层

本讲小结 Most importantly: learned about protocols 典型的请求/应答报文交换: 报文格式: 客户请求信息或服务 服务器用数据, 状态码进行响应 报文格式: 首部: 说明数据的信息 数据: 进行通信的信息 控制 vs. 数据报文 in-based, out-of-band 集中式 vs. 非集中式 无状态 vs. 有状态 可靠的 vs. 不可靠的报文传输 “网络边缘上的复杂实体” 安全性: 认证 第2讲:应用层