计算机网络（自顶向下）学习笔记——应用层

2.1、应用层原理

网络应用的体系结构

客服—服务器（C/S）体系结构

• 服务器

• 一直运行
• 固定的IP地址和周知的端口号
• 扩展性：服务器场，数据中心进行扩展、扩展性差

• 客户端

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

对等体（P2P）体系结构

• 几乎没有一直运行的服务器
• 任意端系统之间可以进行通信
• 每个节点即是客户端又是服务器
• 参与主机间歇性连接且可以改变IP地址

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

• Napster

• 文件搜索：集中
• 文件传输：P2P

• 即时通信

• 在线检测：集中
• 两个客户聊天：P2P

进程通信

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

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

客户端进程： 发起通信的进程

服务器进程： 等待连接的进程

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

1. 进程标示和寻址问题(服务用户)

• 对进程进行编址
• 进程为了接受报文，必须有一个标识即：SAP

• 主机：唯一的32位IP地址
• 所采用的传输层协议：TCP/UDP
• 端口号（Port Numbers）

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

2. 传输层-应用层提供服务是如何（服务）

• 位置：层间界面的SAP（TCP/IP：scoket）
• 形式：应用程序接口API（TCP/IP：scoket API）
• 层间接口必须要携带信息

• 要传输的报文
• 谁传的：对方的应用进程的标示：IP+TCP(UDP) 端口
• 传给谁：对方的应用进程的标示：对方的IP+TCP(UDP)端口号

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

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

• TCP scoket：

• TCP服务，两个进程之间的通信需要之前要建立连接
• 可以用一个整数表示两个应用实体之间的通信关系，本地标示
• TCP scoket：源IP、源端口、目标IP、目标端口

• TCP的套接字

• 4元组：（源IP、源port、目标IP、目标port）
• 唯一的指定了一个会话（2个进程之间的会话关系）
• 应用使用这个标示，与远程的应用进程通信

• UDP scoket：

• UDP服务，两个进程之间的通信需要之前无需建立连接：每个报文都是独立传输，前后报文可能分给不同的分布式进程
• UDP scoket：本IP，本端口
• 传输报文时：必须要提供对方IP，Port：传输报文时：传输层需要上传对方的IP，port

• UDP套接字

• 2元组：IP，Port
• UDP套接字指定了应用所在的一个端节点
• 在发报文时，必须要指定对方的IP和UDP port

3. 如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）

1. 定义应用层协议：报文格式，解释，时序等
2. 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文

应用层协议

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

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

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

• 数据丢失率
• 吞吐
• 延迟
• 安全性：机密性、机密性、可认证性

Internet传输层提供的服务

TCP服务：

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

UDP服务：

• 不可靠传输
• 不提供服务：可靠、拥塞控制、流量控制、时间、宽带保证、建立连接

UDP存在的必要性

• 能够区分不同的进程，而IP服务不能
• 无需建立连接，省去建立连接时间，适合事物性的应用
• 不做可靠性的工作
• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据

2.2、Web和HTTP

Web术语

Web页：由一些对象组成，对象可以是HTML文件，JPEG图像，Java程序等。其包含有一个基本的HTML文件该文件包含若干对象的链接

通过URL对每个对象进行引用

• 访问协议，用户名，口令字，端口等；

URL格式：

HTTP概况

HTTP：超文本传输协议

• Web的应用层协议
• 客户/服务模式

• 客户：请求、接收和显示Web对象的浏览器
• 服务器：对请求进行响应，发送对象的Web服务器

• 使用TCP

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

• HTTP是无状态的

• 无状态的意思是服务器并不会维护关于客户的任何信息（也就是客户发送什么请求，服务器端就给什么响应）

• 维护状态的协议和复杂

• 必须维护历史信息（状态）
• 如果服务器/客户机死机。他们的状态信息可能不一致，二者的信息是一致的
• 无状态的服务器能够支持更多的客户端

HTTP连接

1. 非持久HTTP

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

2. 持久HTTP

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

响应时间模型

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

响应时间：

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

持久HTTP

非持久HTTP的缺点：

• 每个对象要2个RTT
• 操作系统必须为每个TCP连接分配资源，但浏览器通常打开并行TCP连接，以获取引用对象

持久HTTP

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

• 客户端只能在收到前一个响应后才能发出新的请求
• 每个引用对象花费一个RTT

• 流水方式的持久HTTP

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

HTTP请求报文

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

HTTP请求报文：ASCII

在浏览器中输入www.baidu.com可以看到HTTP请求报文格式

HTTP请求报文：通用格式

HTTP有两类报文：

• 请求报文——从客户端向服务器发送请求报文
• 响应报文——从服务器到客户端的回答

提交表单输入

POST方式：网页通常包含表单输入、包含在实体主体（entity body）中的输入被提交到服务器

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

• 方法类型

• HTTP/1.0：GET、POST、HEAD（要求在服务器在响应报文中不包含请求对象——>故障跟踪）
• HTTP/1.1：GET、POST、HEAD、PUT（将实体主体中的文件上载到URL字段规定的路径）、DELETE(删除URL字段规定的文件)

HTTP响应状态码

• 200 OK：请求成功，请求对象包含在响应报文的后续部分
• 301 Moved Permanently：请求的对象已被永久转移了
• 400 Bad Request：一个通用的差错代码，表示请求不能被服务器解读（例如：在Java中前后端联调时接口写错）
• 404 Not Found：请求的文档在该服务上没有找到
• 505 HTTP Version Not Support：服务器错误

用户-服务器状态：cookies

大多数主要门户网站使用cookies，主要有4部分组成：

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

Web缓存（代理服务器）

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

• 用户设置浏览器：通过缓存访问Web
• 浏览器将所有的HTTP请求发给缓存

• 在缓存中的对象：缓存直接返回对象
• 如果对象不在缓存，缓存请求原始服务器，然后再将对象返回个客户端

2.3、FTP

FTP：文件传输协议

• 向远程主机上传输文件或从远程主机接收文件
• 客户/服务器模式

• 客户端：发起传输的一方
• 服务器：远程主机

• FTP服务器：端口号21

FTP：控制连接与数据连接分开

• FTP客户端与FTP服务器通过端口21连接，并使用TCP为传输协议
• 客户端通过控制连接获得身份确认
• 客户端通过控制连接发送命令浏览远程目录，收到文件传输命令时，服务器打开一个客户端的数据连接
• 一个文件传输完成后，服务器关闭连接，服务器打开第二个TCP数据连接用来传输另一个文件
• FTP服务器维护用户状态信息：当前路径、用户账户与控制连接对应状态

FTP命令、响应

命令样例：

• 在控制连接上以ASCII文本方式传送
• USER username PASS password
• LIST：请服务器返回远程主机当前目录的文件列表
• PETR filename：从远程主机当前目录检索文件
• STOR filename：向远程主机的当前目录存放文件

2.4、Email

电子邮件（Email）

主要由三个部分组成：

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

用户代理（邮件阅读器）：

• 撰写、编辑和阅读邮件
• 输入和输出邮件保存在服务器上

EMail：邮件服务器

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

• 客户：发送方邮件服务器
• 服务器：接收端邮件服务器

EMail： SMTP[RFC 2821]

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

SMTP总结与HTTP比较：

• SMTP使用持久连接
• SMTP要求报文（首部和主体）必须为7位ASCII编码
• SMTP服务器使用CRLF.CRLF决定报文的尾部
• HTTP是拉（PULL）SMTP是推（PUSH）
• 二者都是ASCII形式的命令、响应交互、状态码
• HTTP：每个对象都封装在各自的响应报文中，SMTP：多个对象包含在一个报文中

邮件报文格式

SMTP：交换Email报文的协议RFC822

文本报文格式：

• 首部行：TO、From、Subject
• 主体：报文只能是ASCII码字符
• MIME：多媒体邮件扩展RFC 2045，2056
• 在报文首部用额外的行申明MIME内容类型

邮件访问协议

POP3： 全名为“Post Office Protocol - Version 3”，即“邮局协议版本3”。是TCP/IP协议族中的一员，由RFC1939 定义。本协议主要用于支持使用客户端远程管理在服务器上的电子邮件。提供了SSL加密的POP3协议被称为POP3S

IMAP（Internet Message Access Protocol）： 一种邮件获取协议。它的主要作用是邮件客户端可以通过这种协议从邮件服务器上获取邮件的信息，下载邮件等

2.5、DNS

DNS（域名管理系统）：是互联网使用的命名系统，用来便于人们使用的机器名字转换为IP地址。

DNS的总体思路和目标

• DNS的主要思路

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

• DNS主要的目的

• 实现主机名—IP地址的转换
• 主机别名到规范名字的转换
• 邮件服务器别名到邮件服务器的正规名字的转换
• 负载均衡：Load Distribution

DNS名字空间

DNS域名结构

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

• Internet根被划为几百个*域名（top lever domains）

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

• 域名(Domain Name)
  从本域往上，直到树根、域的域名：可以用于表示一个域、主机的域名：一个域上的一个主机
• 域名的管理

• 一个域管理其下的子域
• 创建一个新的域，必须征的它所属域的同意
• 域与物理网络无关：域遵从组织界限，而不是物理网络、域划分是逻辑的，而不是物理的

域名服务器

区：一个服务器所负责管辖的（或有权限）范围，每个区应设置响应的权限域名服务器，用来保存该区中的所有主机域名到IP地址的映射

• 根域名服务器：根域名服务器是最高层次的域名服务器，也是最重要的域名服务器
• *域名服务器（TLD服务器）：负责*域名（如com、org、net、edu和gov）和所有*的*域名（如cn等），*域名服务器负责管理在该服务器注册的所有二级域名。
• 权限域名服务器： 负责一个区的域名服务器
• 本地域名服务器： 一个ISP提供者，或者一个大学，都拥有一个本地域名服务器

域名解析的过程：

第一：主机向本地域名服务器的查询一般都采用递归查询。

第二：本地域名服务器向根服务器的查询通常采用迭代查询

DNS协议和报文

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

报文首部： 标识符（ID）：16位、flags：查询应答、希望递归、递归可用、应答权威

2.6、P2P的应用

纯P2P架构

• 没有（或极少）一直运行的服务器
• 任意端系统都可以直接通信
• 利用peer的服务能力
• 例如：文件分发（BitTorrent）、流媒体（KanKan）、VoIP（Skype)

文件分发：C/S和P2P

问题: 从一台服务器分发文件（大小F）到N个peer需要多少时间？

• C/S模式：

• P2P模式：

查询洪泛：Gnutella

• 全分布式：没有中心服务器
• 开放文件共享协议
• 许多Gnutella客户端实现了Gnutella协议

Gnutella协议：

• 在已有的TCP连接上发送查询报文
• 对等方转发查询报文
• 以反方向返回查询命中报文

KaZaA：查询

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

• 向拥有文件的对等方发送一个带散列标识码的 HTTP请求

• Kazaa小技巧