[网络协议]【计算机网络入门】二、应用层 | 科大公开课

目标

• 网络应用的原理：网络应用协议的概念和实现方面
  • 传输层的服务模型
  • 客户-服务器模式
  • 对等模式(peerto-peer)
  • 内容分发网络
• 网络应用的实例：互联网流行的应用层协议
  • HTTP
  • FTP
  • SMTP / POP3 /IMAP
  • DNS
• 编程：网络应用程序
  • Socket API

1 应用层协议原理

1.1 网络应用的体系结构

1.1.1 客户-服务器（C/S）体系结构

• 服务器:
  • 一直运行
  • 固定的IP地址和周知的端口号（约定）
  • 扩展性：服务器场
  • 数据中心进行扩展
  • 扩展性差，可靠性差
    可扩展性差：随着请求的增加，达到一定阈值之后，性能会急剧式下降，而不是合理下降
    可靠性差：完全依赖服务器，服务器宕机就完了
• 客户端:
  • 主动与服务器通信
  • 与互联网有间歇性的连接
  • 可能是动态IP地址
  • 不直接与其它客户端通信

1.1.2 对等体（P2P）体系结构

• （几乎）没有一直运行的服务器
• 任意端系统之间可以进行通信
• 每一个节点既是客户端又是服务器
  • 自扩展性：新peer节点带来新的服务能力，当然也带来新的服务请求
• 参与的主机间歇性连接且可以改变IP地址
  • 难以管理
• 例子: Gnutella，迅雷

1.1.3 C/S和P2P体系结构的混合体

Napster

• 文件搜索：集中
• 主机在中心服务器上注册其资源
• 主机向中心服务器查询资源位置
• 文件传输：P2P
• 任意Peer节点之间

即时通信：QQ

• 在线检测：集中
• 当用户上线时，向中心服务器注册其IP地址
• 用户与中心服务器联系，以找到其在线好友的位置
• 两个用户之间聊天：P2P

工作原理：Napster客户端运行起来，向服务器发出注册的命令，告诉服务器，我的ip是多少，我上线了，我拥有哪些歌曲可以跟别人共享
有些Napster客户端需要下载音乐，下载之前向服务器发送查询命令，谁有xx音乐？服务器返回拥有该音乐的客户端的IP
查询是C/S模式，文件分发是P2P模式

1.2 进程通信

应用层要想跑各种程序，需要传输层提供进程间通信

• 在同一个主机内，使用进程间通信机制通信（操作系统定义）
• 不同主机，通过交换报文（Message）来通信

注意：P2P架构的应用也有客户端进程和服务器进程之分

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

• 问题1：进程标识和寻址问题（服务用户）
• 问题2：传输层-应用层提供服务是如何（服务）
  位置：层间界面的SAP（TCP/IP：socket）
  形式：应用程序接口API（TCP/IP：socket API）
• 问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）
  定义应用层协议：报文格式，解释，时序等
  编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等；

1.2.1 对进程进行编址（addressing）

标识有三部分

1. 在哪台主机上——IP
2. 在这台主机上的TCP还是UDP上？
3. 在哪个端口？（Port Numbers）

一些知名端口号的例子：HTTP: TCP 80 Mail: TCP25 ftp:TCP 2
一个进程：用IP+port标示 （端节点）

1.2.2 传输层提供的服务

进程的信息从应用层经过端结点到传输层，穿过层间需要哪些信息？

1. 发什么——数据SDU
2. 谁发的——我方的应用进程的标示：IP+TCP(UDP)端口
3. 发给谁——对方的应用进程的标示：对方的IP+TCP(UDP)端口号

传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段或UDP数据报的封装

• 源端口号，目标端口号，数据等
• 将IP地址往下交IP实体，用于封装IP数据报：源IP,目标IP

数据是一定要传的，但是可能需要传送很多很多的数据，每传一点都要加上两个应用进程的标识，有没有办法减少层间传输的信息量呢？
办法就是采用socket

一旦与对方建立通信关系，对方就返回一个整数
在TCP中，这个整数代表我的IP和端口号、对方的IP和端口号这个四元组
在UDP中，这个整数代表我的IP和端口号这个二元组
socket是一个本地意义上的标识，对方并不知道我方的socket，是应用层与传输层之间的约定。
优点：穿过层间的信息量少；便于OS管理

1.TCP socket
代表的是两个进程之间的会话关系


2.UDP socket
层间信息：数据本身、UDP socket、对方IP和端口号

3.socket套接字
进程向套接字发送报文或从套接字接收报文

• 套接字就像一个门一样
  • 发送进程将报文推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
  • 接收进程从另外一端的门户收到报文（依赖于传输层设施）
    

1.2.3 如何使用传输层提供的服务实现应用

• 定义应用层协议：报文格式，解释，时序等
• 编制程序，通过API调用网络基础设施提供通信服务传报文，解析报文，实现应用时序等

协议：在对等层的应用进程在通信过程中应当遵守的规则集合

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

应用协议分两类

1. 公开协议：
   由RFC文档定义、允许互操作，如HTTP, SMTP
2. 专用（私有）协议：
   协议不公开。如：Skype

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

1. 数据丢失率
   有些应用则要求100%的可靠数据传输（如文件）
   有些应用（如音频）能容忍一定比例以下的数据丢失
2. 延迟
   一些应用出于有效性考虑，对数据传输有严格的时间限制
   *Internet电话、交互式游戏
   *延迟、延迟差
3. 吞吐
   一些应用（如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转
   一些应用能充分利用可供使用的吞吐(弹性应用)
4. 安全性：机密性、完整性、可认证性（鉴别）

SSL在应用层
https：ssl over tcp

2 Web and HTTP

一些术语

• Web页：由一些对象组成
• 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
• Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接）
• 通过URL对每个对象进行引用
  • 访问协议，用户名，口令字，端口等；
• URL格式
  

2.1 HTTP概况

HTTP：超文本传输协议
客户/服务器模式

HTTP跑在TCP之上
HTTP是无状态的，服务器并不维护关于客户的任何信息。来什么请求给什么响应就完事，不用考虑后面还要不要通信
优点：简单，支持的用户多

2.2 HTTP连接

非持久HTTP

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

持久HTTP

• 多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输
• HTTP/1.1默认使用持久连接

2.2.1 非持久HTTP连接

2.2.2 持久HTTP连接

上面那个例子用持久连接就是HTML文本+10个对象都在一次连接中下载

• 非流水方式的持久HTTP：
  ?客户端只能在收到前一个响应后才能发出新的请求
  ?每个引用对象花费一个RTT
• 流水方式的持久HTTP：
  ? HTTP/1.1的默认模式
  ?客户端遇到一个引用对象就立即产生一个请求
  ?所有引用（小）对象只花费一个RTT是可能的

2.3 HTTP请求报文

如果是POST，需要向服务器提供一些表单信息，请求就得提供Body

2.3.1 表单提交输入的方式

1.Post方式

• 网页通常包括表单输入
• 包含在实体主体(entity body )中的输入被提交到服务器

2.URL方式

• 方法：GET
• 输入通过请求行的URL字段上载，例：www.somesite.com/animalsearch?monkeys&banana

HTTP/1.0

• GET
• POST
• HEAD
  • 要求服务器在响应报文中不包含请求对象。如：谷歌爬虫

HTTP/1.1

• GET, POST, HEAD
• PUT
  • 将实体主体中的文件上载到URL字段规定的路径
• DELETE
  • 删除URL字段规定的文件

2.4 HTTP响应报文

2.4.1 响应状态码

• 200 OK
  请求成功，请求对象包含在响应报文的后续部分
• 301 Moved Permanently
  请求的对象已经被永久转移了；新的URL在响应报文的Location:首部行中指定
  客户端软件自动用新的URL去获取对象
• 400 Bad Request
  一个通用的差错代码，表示该请求不能被服务器解读
• 404 Not Found
  请求的文档在该服务上没有找到
• 505 HTTP Version Not Supported

2.5 cookies

有些应用，服务器端需要维护客户端的状态，如：商城、论坛
cookies就是用来维护状态的

cookies的四个组成部分
1)在HTTP响应报文中有一个cookie的首部行
2)在HTTP请求报文含有一个cookie的首部行
3)在用户端系统中保留有一个cookie文件，由用户的浏览器管理
4)在Web站点有一个后端数据库

客户端在第一次发出请求时一般不带cookie
服务器收到这个新的请求，在响应报文首部行中带上cookie，且服务器自己也保存这个cookie。
客户端收到cookie后存在本地
下次再访问服务器时带上cookie
服务器在维护的数据库中找到相应的cookie值，能根据cookie识别这个请求的用户端，是谁？在网站买了什么？购物车有什么？可以向其推荐什么？

2.6 Web缓存

目标：不访问原始服务器，就满足客户的请求

优点：
对于客户端来说：速度快
对于服务器来说：减少请求数量，负载轻
对于互联网来说：负载轻

2.7 条件GET方法

3 FTP*

FTP：文件传输协议


带内：传数据—— 20号端口
带外：传指令（控制信息）—— 21号端口

FTP与HTTP不同点：
1.FTP的控制命令的发送和数据的传输在两个不同的连接；HTTP是在同一个连接
2.FTP有状态，HTTP无状态

4 EMail

EMail包括3个主要部分：用户代理、邮件服务器、简单邮件传输协议：SMTP
协议包括发送的协议和拉取的协议，发送的协议就是SMTP，拉取的协议包括SMTP、HTTP、POP3等好几种
用户代理：发邮件的软件，如：outlook、QQ邮箱。通过软件访问电子邮件应用，因此软件就是应用的代理。谁是Web应用的用户代理？浏览器
邮件服务器：守候在25端口的服务器

4.1 SMTP

base64：把若干个不在ASCII码上的字节通过映射转化成在ASCII码上的字节

4.2 邮件访问协议

4.3 POP3

用户名和密码全都是明文，存在安全隐患

retr：拉邮件
dele：删邮件
即：下载并删除。好处：邮箱不会满
还有一种模式是下载并保留。好处：从其他终端也可以看到邮件

5 DNS

域名解析系统不是给人用的应用，而是给其他应用用的应用
域名到IP地址的转换
哪些应用会用？web应用，用户输入的是URL域名，web浏览器调用DNS得到IP地址；FTP也是

1.DNS的必要性
IP地址标识主机、路由器，但IP地址不好记忆，不便人类使用(没有意义)，人类一般倾向于使用一些有意义的字符串来标识Internet上的设备。例如：qzheng@ustc.edu.cn所在的邮件服务器、www.ustc.edu.cn所在的web服务器
存在着“字符串”—IP地址的转换的必要性。人类用户提供要访问机器的“字符串”名称，由DNS负责转换成为二进制的网络地址

2.DNS系统需要解决的问题

问题1：如何命名设备
用有意义的字符串：好记，便于人类用使用
解决一个平面命名的重名问题：层次化命名

问题2：如何完成名字到IP地址的转换
分布式的数据库维护和响应名字查询

问题3：如何维护？增加或者删除一个域，需要在域名系统中做哪些工作

5.1 DNS名字空间

1. 顶级域：
   • 通用的(generic)：.com; .edu ; .gov ; .int ; .mil ; .net ; .org；.firm ; .hsop ; .web ; .arts ; .rec ;
   • 国家的(countries)：.cn ; .us ; .nl ; .jp
2. 每个(子)域下面可划分为若干子域(subdomains)

共有13个根名字服务器，分散开来1可靠2可以寻找最近的服务器

5.2 解析问题-名字服务器(Name Server)

一个名字服务器的问题
可靠性问题：单点故障
扩展性问题：通信容量
维护问题：远距离的集中式数据库

例：

5.2.1 DNS查询过程

5.2.2 DNS协议、报文

5.2.3 提高性能：缓存

5.3 维护问题：新增一个域

5.4 攻击DNS

6 P2P应用

（感觉这门课不是很方便做笔记，先挖个坑）

7 CDN

8 TCP套接字编程

9 UDP套接字编程