中科大郑烇、杨坚 《计算机网络》第二章

1、应用层协议原理

1.1 网络应用的体系结构：

可能的应用架构:
1）客户-服务器模式（C/S:client/server)
2）对等模式(P2P:Peer To Peer)
3）混合体:客户-服务器和对等体系结构

1.1.1 客户-服务器模式（C/S:client/server)

服务器端：

• 一直运行
• 固定IP地址和周知的端口号
• 扩展性：服务器短的扩展性较差

客户端：

• 主动与服务器通信
• 与互联网有间歇性的连接)
• 可能是动态IP地址
• 不直接与其它客户端通信

缺点：可拓展性差 达到一定能限（阈值），性能暴跌 可靠性差

1.1.2 对等模式(P2P:Peer To Peer)

• (几乎）没有一直运行的服务器
• 任意端系统之间可以进行通信
• 每一个节点既是客户端又是服务器
  • 自扩展性-新peer节点带来新的
  • 服务能力，当然也带来新的服务请求

1.2、进程通信

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

• 在同一个主机内，使用进程间通信机制通信（操作系统定义）

• 不同主机，通过交换报文（message）来通信

客户端进程：发起通信的进程
服务器进程：等待连接的进程

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

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

应用进程如何使用传输层提供的服务交换报文

1.3.1、问题1：进程标识和寻址问题（对于进程 谁发/谁收，对等层实体之间）

• 进程为了接收报文，必须有一个标识

  • 主机：唯一的32位IP地址
  • 端口号(Port Numbers) 用来区分不同的应用进程
    所采用的的传输层协议：TCP/UDP

• 一个进程：用IP + port 标识端节点

• 本质上，一对主机进程之间的通信由2个端节点构成

1.3.2、问题2：传输层-应用层提供服务是如何 (上下层间)

• 位置：层间界面的SAP （TCP/IP ：socket）
• 形式：应用程序接口API （TCP/IP ：socket API）

传输层提供的服务-需要穿过层间的信息
层间接口必须要携带的信息

• 要传输的报文(对于本层来说:SDU) (SDU——未经本层封装的) （发的什么）
• 谁传的:对方的应用进程的标示:IP+TCP(UDP)端口 （谁发的）
• 传给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号 （发给谁）

传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段(UDP数据报)的封装
源端口号，目标端口号，数据等
将IP地址往下交给IP实体，用于封装IP数据报：源IP,目标IP

如果Socket API（原语）每次传输报文（穿过层间），都携带如此多的信息，太繁琐易错，不便于管理
用个代号标示通信的双方或者单方: socket
就像OS打开文件返回的句柄一样
对句柄的操作，就是对文件的操作

1.3.2.1 TCP socket

1、TCP服务，两个进程之间的通信需要之前建立连接，两个进程通信会持续一段时间，通信关系稳定。
2、可以用一个整数（socket）表示两个应用实体之间的通信关系,本地标识
3、用一个整数标识传输，穿过层间接口的信息量最小
4、TCP socket：源IP,源端口，目标IP，目标IP,目标

TCP socket 是一个整数（类似文件描述符）代表一个四元组（我的IP和端口号 对方的IP和端口号）
便于管理 使得穿过层间的信息量最小
是应用层和传输层的一个约定 本地会话的标识

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

• 4元组: (源IP，源port，目标IP，目标port)

• 唯一的指定了一个会话（2个进程之间的会话关系)o应用使用这个标示，与远程的应用进程通信

• 不必在每一个报文的发送都要指定这4元组

• 就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名

• 简单，便于管理

穿过层间接口的包括 ICI 和 SDU

1.3.2.2 UDP socket

1.3.3、问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用 （本层间）

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

1.4 应用层协议

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

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

应用协议仅仅是应用的一个组成部分
Web应用:HTTP协议，web客户端，web服务器，HTML(超文本标记语言)

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

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

如何描述传输层的服务？

1、数据丢失率
有些应用则要求100%的可靠数据传输（如文件)
有些应用(如音频)能容忍一定比例以下的数据丢失

2、延迟
一些应用出于有效性考虑，对数据传输有严格的时间限制
Internet电话、交互式游戏o延迟、延迟差

3、吞吐
一些应用(如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转一些应用能充分利用可供使=用的吞吐(弹性应用)

4、安全性
机密性完整性
可认证性（鉴别)

常见应用对传输服务的要求

Internet 传输层提供的服务
实体：实行网络协议的软件模块或硬件模块（运行中的）

TCP服务:
可靠的传输服务
流量控制:发送方不会淹没接受方
拥塞控制:当网络出现拥塞时，能抑制发送方
不能提供的服务:时间保证、最小吞吐保证和安全面向连接:要求在客户端进程和服务器进程之间建立连接

UDP服务:
不可靠数据传输
不提供的服务:可靠,流量控制、拥塞控制、时间、带宽保证、建立连接

UDP存在的必要性

• 能够区分不同的进程，而IP服务不能
  在IP提供的主机到主机端到端功能的基础上，区分了主机的应用进程
• 无需建立连接，省去了建立连接时间，适合事务性的应用
• 不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用
  • 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发〉
• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
  • 而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制

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

安全TCP
TCP & UDP
 都没有加密
 明文通过互联网传输 ，甚至密码

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

SSL在应用层  应用采用SSL库，SSL 库使用TCP通信

SSL socket API  应用通过API将明文交 给socket，SSL将其加 密在互联网上传输  详见第8章

Https 跑在 SSL + TCP 上

2、协议

2.1 HTTP：超文本传输协议

HTTP: 超文本传输协议
 Web的应用层协议
 客户/服务器模式
 客户: 请求、接收和显示 Web对象的浏览器
 服务器: 对请求进行响应， 发送对象的Web服务器
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 206

使用TCP

• 客户发起一个与服务器的TCP连接(建立套接字)，端口号为80
• 服务器接受客户的TCP连接
• 在浏览器(HTTP客户端)与Web服务器(HTTP服务器server)
• TCP连接关闭
  HTTP是无状态的
  服务器并不维护关于客户的任何信息

2.1.1 HTTP连接

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

响应时间模型

① 往返时间RTT（round-trip time）
一个小的分组从客户端到服务器，再回到客户端的时间（传输时间忽略）

② 响应时间：
 一个RTT用来发起TCP连接
 一个 RTT用来HTTP请求并等待HTTP响应
 文件传输时间
总共：2个RTT + 一个对象的传输时间

非持久HTTP的缺点：
 每个对象要2个 RTT
 操作系统必须为每个TCP连接分 配资源
 但浏览器通常打开并行TCP连接 ，以获取引用对象

2、持久HTTP
 服务器在发送响应后，仍保持 TCP连接
 在相同客户端和服务器之间的后续请求和响应报文通过相同的连 接进行传送
 客户端在遇到一个引用对象的时 候，就可以尽快发送该对象的请求

持久HTTP分为下面两种方式：
① 非流水方式的持久HTTP
 客户端只能在收到前一个响应后 才能发出新的请求
 每个引用对象花费一个RTT

② 流水方式的持久HTTP
 HTTP/1.1的默认模式
 客户端遇到一个引用对象就立即 产生一个请求
 所有引用（小）对象只花费一个RTT是可能的

2.1.2 HTTP请求报文

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

HTTP请求报文：通用格式

HTTP请求方式
1、POST方式
 网页通常包括表单输 入
 包含在实体主体 (entity body )中的 输入被提交到服务器

2、URL方式：
 方法：GET
 输入通过请求行的 URL字段上载

例子
http: //www. baidu.com/s?wd=xx+yy+zzz&cl=3

参数：wd，cl 参数值：XX+YY+zzz，3

2.1.3 HTTP响应报文

HTTP响应状态码

位于服务器→客户端的响应报文中的首行一些状态码的例子:

200 OK
请求成功，请求对象包含在响应报文的后续部分

301 Moved Permanently
请求的对象己经被永久转移了;新的URL在响应报文的Location:首部行中指定客户端软件自动用新的URL去获取对象

400 Bad Request
一个通用的差错代码，表示该请求不能被服务器解读

404 Not Found
请求的文档在该服务上没有找到

505 HTTP version Not supported

2.1.4 用户-服务器状态：cookies

Cookies：维护状态


1、Cookies能带来什么：
用户验证
购物车
推荐
用户状态（web e-mail）

2、如何维持状态：
 协议端节点：在多个事务上 ，发送端和接收端维持状态
 cookies: http报文携带状态信息

3、Cookies与隐私：
 Cookies允许站点知道许多关于 用户的信息
 可能将它知道的东西卖给第三方
 使用重定向和cookie的搜索引 擎还能知道用户更多的信息
 如通过某个用户在大量站点 上的行为，了解其个人浏览方式的大致模式
 广告公司从站点获得信息

2.1.5 Web缓存（代理服务器）

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

 用户设置浏览器： 通过缓存访问Web
 浏览器将所有的HTTP 请求发给缓存
 在缓存中的对象：缓存直接返回对象
 如对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端
 缓存既是客户端又是服务器
 通常缓存是由ISP安装 (大学、公司、居民区ISP)

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

2.2 FTP:文件传输协议

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

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

 服务器打开 第二个TCP 数据连接用来传输另一个文件（服务器主动）
 控制连接： 带外（ “out of band” ）传送
 FTP服务器维护用户的状态信息： 当前路径、用户帐户与控制连接对应
有状态的协议

FTP命令、响应
命令样例：
 在控制连接上以ASCII文本方式传送
 USER username
 PASS password
 LIST：请服务器返回远程主 机当前目录的文件列表
 RETR filename：从远程主 机的当前目录检索文件 (gets)
 STOR filename：向远程主 机的当前目录存放文件 (puts)
返回码样例：
 状态码和状态信息 (同HTTP)
 331 Username OK, password required
 125 data connection already open; transfer starting
 425 Can’t open data connection  452 Error writing file

FTP协议与HTTP协议的差别
FTP协议是有状态的，FTP协议的控制命令和数据传输分别在两个TCP上进行

2.3 DNS

主要功能：从域名到IP地址的转换

2.3.1 DNS的必要性

​  IP地址标识主机、路由器
​  但IP地址不好记忆，不便人类使用(没有意义)
​  人类一般倾向于使用一些有意义的字符串来标识 Internet上的设备
​ 例如：qzheng@ustc.edu.cn
​ 所在的邮件服务器 www.ustc.edu.cn 所在的web服务器

 存在着“字符串”—IP地址的转换的必要性
​  人类用户提供要访问机器的“字符串”名称
​  由DNS负责转换成为二进制的网络地址

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

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

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

2.3.2 DNS(Domain Name System)总体思路和目标

DNS的主要思路
 分层的、基于域的命名机制
 若干分布式的数据库完成名字到IP地址的转换
 运行在UDP之上端口号为53的应用服务
 核心的Internet功能，但以应用层协议实现
 在网络边缘处理复杂性 （互联网最核心的功能（DNS）在边缘系统实现的）

DNS主要目的：
 实现主机名-IP地址的转换(name/IP translate) （主要功能）
其它目的
 主机别名到 规范名字 的转换：Host aliasing
 邮件服务器别名到邮件服务器的 正规名字 的转换：Mail server aliasing
 负载均衡：Load Distribution（分配具体的服务器提供服务）

2.3.3 问题1：DNS名字空间

 DNS域名结构
 一个层面命名设备会有很多重名
 NDS采用层次树状结构的 命名方法
 Internet 根被划为几百个顶级域(top lever domains)
 通用的(generic) .com; .edu ; .gov ; .int ; .mil ; .net ; .org .firm ; .hsop ; .web ; .arts ; .rec ;
国家的(countries) .cn ; .us ; .nl ; .jp
 每个(子)域下面可划分为若干子域(subdomains)
 树叶是主机

DNS名字空间(The DNS Name Space)

从本域往上，直到树根
中间使用“.”间隔不同的级别
域的域名：可以用于表示一个域
主机的域名：一个域上的一个主机

 域名的管理
 一个域管理其下的子域
.jp 被划分为 ac.jp co.jp
.cn 被划分为 edu.cn com.cn

问题2：解析问题-名字服务器(Name Server)
 一个名字服务器的问题
 可靠性问题：单点故障
 扩展性问题：通信容量
 维护问题：远距离的集中式数据库

 区域(zone)
 区域的划分有区域管理者自己决定
 将DNS名字空间划分为互不相交的区域，每个区域都是 树的一部分

 名字服务器：
 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息 (authoritative record)
 名字服务器允许被放置在区域之外，以保障可靠性

名字空间划分为若干区域：Zone
generic：通用的
countries:国家

权威DNS服务器：组织机构的DNS服务器， 提供组织机构服务器（如 Web和mail）可访问的主机和IP之间的映射
组织机构可以选择实现自己维护或由某个服务提供商来维护

TLD服务器
 顶级域(TLD)服务器：负责顶级域名（如com, org, net, edu和gov）和所有国家级的顶级域名（如cn, uk, fr, ca, jp ）
 Network solutions 公司维护com TLD服务器
 Educause公司维护edu TLD服务器

区域名字服务器维护资源记录
资源记录(resource records)
作用：维护 域名-IP地址(其它)的映射关系
位置：Name Server的分布式数据库中
 RR格式: (domain_name, ttl, type,class,Value)
Domain_name: 域名
Ttl: time to live : 生存时间(权威记录，缓冲记录) 缓冲是为了性能 删除是为了一致性
Class 类别 ：对于Internet，值为IN 说明是Internet网
Value 值：可以是数字，域名或ASCII串 对应的IP地址
Type 类别：资源记录的类型—见下页

DNS记录
DNS ：保存资源记录(RR)的分布式数据库
RR 格式：(name, value, type, ttl)

2.3.5 DNS大致工作过程

一台设备上网必备的IP信息
我的IP地址 我的子网掩码 我的local name serve 我的default getway（路由器）

​ 应用调用 解析器(resolver)
​ 解析器作为客户 向Name Server发出查询报文 （封装在UDP段中）
​ Name Server返回响应报文(name/ip)

本地名字服务器（Local Name Server）
 并不严格属于层次结构
 每个ISP (居民区的ISP、公司、大学）都有一 个本地DNS服务器
 也称为“默认名字服务器”
 当一个主机发起一个DNS查询时，查询被送到 其本地DNS服务器
 起着代理的作用，将查询转发到层次结构中

名字服务器(Name Server)
名字解析过程
目标名字在Local Name Server中
情况1：查询的名字在该区域内部
情况2：缓存(cashing)

当与本地名字服务器不能解析名字时，联系根名字服务器 顺着根-TLD 一直找到 权威名字服务器

递归查询
 名字解析负担都 放在当前联络的 名字服务器上
 问题：根服务器 的负担太重
 解决： 迭代查询 (iterated queries)

迭代查询
 主机cis.poly.edu 想知道主机 gaia.cs.umass.edu 的IP地址
 根（及各级域名）服务器返回的不是查询结果，而 是下一个NS的地址
 最后由权威名字服务器给出解析结果
 当前联络的服务器给出可以联系的服务器的名字
 我不知道这个名字，但可以向这个服务器请求

2.3.6 DNS协议、报文

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

3、套接字编程

1、应用进程通过SocketAPI的方式向下传输message消息；
2、对方应用同样是通过SocketAPI的方式向上层传输message消息

2种传输层服务的socket类型：
1）TCP：可靠地、字节流的、连接的服务
2）UDP：不可靠（数据UDP数据报）、无连接的服务

3.1 TCP套接字编程

服务端(1.1.1.1:80)
socket      IP      port     IP1       port1
 8888     1.1.1.1    80
 8899     1.1.1.1    80     2.2.2.2     777

客服端(2.2.2.2:777)
socket      IP        port     IP1     port1
 2222     2.2.2.2     777    1.1.1.1    80

1、首先服务器(1.1.1.1:80)运行socket函数，返回一个整数(8888)，这个是welcomeSocket
2、第二步建立一个bind（是第一步创建的整数）与本地的某个端口号(80)相捆绑
3、服务端等待客户端的连接请求,如果没有客服端请求，就会阻塞
consocket = accept WelComeSocket
4、在客服端创建clientSocket(整数)与本地的某个端口号(777)和IP相捆绑
5、客服端的TCP实体向服务端发送一个连接请求，此时服务端就会解除阻塞，同时服务端的TCP会返回一个应答，服务端会重新创建一个新的socket值（8899），与客服端建立连接
6、客服端调用socketAPI将第4步创建的socket值和需要发送的值通过API发送到服务端
服务端通过API来接收客服端的请求
7、最后服务端处理后，通过write返回给客服端，客服端read
最后在终端中显示服务端返回的结果
8、最后服务端close掉，表象中的连接信息删掉

3.2 UDP套接字编程