计算机网络笔记2 应用层

应用层

1、应用层协议原理

CS模式：可扩展性差，可靠性差

p2p模式：管理起来比较困难。

napster：文件搜索用cs模式 文件传输用p2p

分布式应用进程需要解决那些问题才能通信？

问题1：进程标示和寻址问题（服务用户）

问题2：传输层-应用程提供服务是如何（服务）

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

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

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

传输层提供的服务-层间信息的代表

• 如果Socket API 每次传输报文，都携带如此多的信息，太繁琐易错，不便于管理
• 用个代号标示通信的双方或者单方：socket
• 就像OS打开文件返回的句柄一样
• • 对句柄的操作，就是对文件的操作
• TCP socket
• • TCP服务：两个进程之间的通信需要之前要建立连接
  • • 两个进程通信会持续一段时间，通信关系稳定
  • 可以用一个整数表示两个应用实体之间的通信关系，本地标识
  • 传功层间接口的信息量最下
  • TCP socket:源IP,源端口号，目标IP, 目标端口号

TCP之上的套接字（socket）

• 对于使用面向连接的服务（TCP）的应用而言，套接字是4元组的一个具有本地意义的标志
• 4元组：源IP,源端口号，目标IP, 目标端口号
• 唯一的指定了一个会话（2个进程之间的会话关系）
• 应用使用这个标志，与远程的应用进程通信
• 不必在每一个报文的发送都要指定这4元组

UDP socket

• UDP服务，两个进程之间的通信需要之前无需建立连接
• • 每个报文都是独立传输的
  • 前后报文可能给不同的分布式进程
• 只能用一个整数标识本应用的实体的标示
• 穿过层间接口的信息量大小最小
• 本IP 本端口号
• 但是传输报文时：必须要提供对方IP, port;
• • 接收报文时：传输层需要上传对方的IP, port;
• 对于使用UDP的应用而言，套接字时2元组的一个具有本地意义的标示
• • IP, port(源端指定)
  • UDP套接字指定了应用所在的一个端节点
  • 在发送数据报时，采用创建好的本地套接字（标识ID），就不必再发送每个报文中知名自己所采用的IP和port

应用层协议

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

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

应用协议仅仅是应用的组成部分

公开协议：专用协议

衡量指标

• 数据丢失率
• 延时
• 吞吐
• 安全性

Internet传输层提供的服务

TCP服务

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

UDP服务

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

安全TCP

tcp和udp都没有加密，明文通过互联网传输，甚至是密码

SSL

在TCP上面实现，提供加密的TCP连接

• 私密性
• 数据完整性
• 端到端的鉴别

SSL在应用层

• 应用采用SSL库，SSL库使用TCP通信

SSL socket API

• 应用通过API将明文交给socket,SSL将其加密在互联网上传输

2、Web and HTTP

web是应用 http是支持web的协议。

• Web页：由一些对象组成
• 通过URL可以对每个对象进行访问
• URL 格式
• • Prot://user:psw@www.someSchool.edu/someDept/pic.gir:port
  • 协议名 用户：口令 主机名 路径名 端口

HTTP：超文本传输协议

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

HTTP1.0：RFC　1945

HTTP1.1：RFC 2068

使用TCP

• 客户发起一个与服务器的TCP连接（建立套接字）

• 服务器接收客户的TCP连接

• 在浏览器（HTTP客户端）与Web服务器（HTTP服务器）交换HTTP报文

• TCP连接关闭

HTTP是无状态的

• 服务器并不维护关于客户的任何信息

非持久HTTP 1.0

• 最多只有一个对象在TCP连接上发送
• 下载多个对象需要多个TCP连接

持久HTTP 1.1

• 多个对象可以在一个TCP连接上传输

HTTP请求报文

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

HTTP请求报文

• ASCII（人能阅读）
• GET POST　　HEAD（搜索引擎）

请求行　　　GET /somedir/page.html HTTP/1.1

首部行 Host: www.saaa.com

​ User-agent: Mozilla/4.0

​ Connection : close

​ Accept-language:fr

Post方式

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

Url方式

• 方法：get
• 输入通过请求行的URL字段上载

1.1

（网络管理员用的）

put

将实体主体中的文件上载到url字段规定的路径

delete

删除url字段规定的文件

HTTP请求报文

状态行 HTTP/1.1 100 OK\r\n

首部行 Connection close\r\n

​ Data: Thu, 06

实体行

HTTP状态码

200 OK

301 Moved Permanently

400 Bad Request

404 Not Found

505 Http Version Not Supported

用户-服务器状态 cookie

大多数主要的门户网站使用cookie

4 个组成部分

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

能带来什么

• 用户验证
• 购物车
• 推荐
• 用户状态

隐私问题很严重

Web缓存（代理服务器）

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

• 用户设置浏览器：通过缓存访问Web
• 浏览器将所有的HTTP请求发送给缓存
• • 在缓存中的对象：缓存直接返回对象
  • 如对象不再缓存中，缓存请求原始服务器，然后将对象返回给用户

好处

• 提升访问速度
• 缓解服务器压力
• 减少网络载荷

风险

• 本地缓存下来了，服务器端内容边了

条件Get

if-modified-since;

如果服务器没有改变，就返回304

如果服务器端改了，就返回200ok及修改后的内容

3、FTP*文件传输协议

• 向远程主机上传文件或者从远程主机接收文件
• ftp：RFC 959
• port：21号端口

FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议

• 客户端通过控制连接获得身份确认
• 客户端通过控制连接发送命令，浏览远程目录
• 服务器打开第二个TCP数据连接用来传输一个文件
• 受到一个文件传输命令时，服务器打开一个到客户端的数据连接
• 一个文件传输完成后，服务器关闭连接
• 控制连接，带外的
• 有状态的

4、Email SMTP POP3 IMAP

邮件服务器

• 邮箱中管理和维护发送给用户的邮件
• 输出报文队列保持待发送邮件报文
• 邮件服务器之间 是通过SMTP协议发送email报文
• • 客户：发送方邮件服务器
  • 服务器：接收端邮件服务器

SMTP

使用TCP在客户端和服务器之间传输报文，端口为25

• 直接传输：从发送方服务器发送到接收端服务器
• 传输的3个阶段
• • 握手
  • 传输报文
  • 关闭
• 命令/响应交互
• • 命令：ASCII文本
  • 响应：状态码和状态信息
• 报文必须为7为ASCII码

持续的

MIME:报文扩展

多媒体文件扩展（mulitmedia mail extension）

RFC 2045 2056

在报文首部用额外的行申明MIME内容类型

POP3

邮局访问协议（Post Office Protocol) [RFC 1939]

• 用户身份确认（代理------服务器）并下载
• 无状态

IMAP

Internet邮件访问协议（Internet Mail Access Protocol）[RFC 1730]

• 更多特性（更复杂）
• 在服务器上处理存储的报文
• 有状态

HTTP等

5、DNS（域名解析）（Domain Name System）

必要性

• IP地址标识主机、路由器
• 但IP地址不好记忆，不便人类使用（没有意义）
• 人类一般倾向于使用一些有意义的字符串来标识Internet上的设备
• 存在着“字符串”–IP地址的转换的必要性
• 人类提供字符串，用dns进行转换

问题1：如何命名设备

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

一个层面命名设备会有很多崇明

Internet被划分为几百个顶级域（top level domains）TLD

• 通用的（generic)
• • com edu gov int mil
• 国家的
• • cn us nl jp

每个子域下面可划分为若干个子域

树叶是主机

根名字服务器：有13个根服务器。

域名

从本域网上，直到树根

中间使用“."间隔不同级别

域的域名：可以用于标识一个域

主机的域名：一个域上的一个主机

域名的管理

• 一个域管理其下的子域

域与物理网络无关

• 域遵从组织界限，而不是物理网络

区域

• 区域的划分由区域管理者自己决定
• 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
• 名字服务器
• • 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息
  • 名字服务器允许被放置在区域之外，以保障可靠性

问题2：如何完成名字到IP地址的转化

• 分布式的数据库维护和响应名字查询

DNS主要思路

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

DNS主要目的

• 实现主机----IP地址的转换
• 其他目的
• • 主机的别名到规范名字的转换
  • 负载均衡的作用

顶级域（TLD）服务器：负责顶级域名和所有国家域名

区域名字服务器维护资源记录

资源记录

作用：维护域名—IP地址（其他）的映射关系

位置：Name Server的分布式数据库中

RR格式：（domain_name, ttl, type, class, Value)

• Domain_name:域名
• Ttl: time to live:生存时间（权威，缓冲记录）如果是权威的，则永久， 如果是缓存的，则日后再删除
• Class类别：对于Internet, 值为IN
• Value值：可以是数字，域名或者ASCII串
• Type类别：资源记录的类型

Type = A

Name 为主机

Value 为IP地址

Type = NS

Name 为域名（如foo.com)

Value 为该域名的权威服务器域名

Type = CNAME

Name 为规范服务器的别名

value 为规范名字

Type = MX

Value 为name 对应的邮件服务器的名字

缓冲为了性能，删除为了一致性

DNS大致工作过程

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

本地名字服务器（Local Name Server）

• 并不严格属于层次结构
• 每个ISP（居民区的ISP, 工资， 大学）都有一个本地DNS服务器
• 当一个主机发起一个DNS查询时，查询被送到本地DNS服务器
• • 起着代理作用，将查询转发到层次结构中

递归查询

• 名字解析负担都放在当前联络的名字服务器上

问题：根服务器负担太重

解决：迭代查询

迭代查询

一个一个DNS问

本地先问根，本地再问TLD

提高性能：缓存

问题3：维护问题：新增一个域

6、P2P应用

纯P2P架构

• 没有（或极少）一直运行的服务器
• 任意端系统都可以直接通信
• 利用peer的服务能力
• Peer节点简写上网，每次IP地址都可能变化

非结构化P2P

无序的

集中化目录

• 单点故障
• 性能瓶颈
• 侵犯版权

完全分布式

• 没有中心服务器

泛洪flooding：有限泛洪

混合体（分组）

每个对等方要么时一个组长，要么隶属于一个组长

• 对等方与其组长之间有TCP连接
• 组长对之间有TCP连接

组长跟踪其所有孩子的内容

组长与其他组长联系

• 转发查询到其他组长
• 获得其他组长的数据拷贝

P2P文件分发：BitTorrent

• 文件被分为一个个块：256kb
• 及网络中的这些peer发送接收文件块，相互服务。

Peer加入torrent:

• 一开始没有块，但是将会通过其他节点处理积累文件块
• 向跟踪服务器注册，获得peer节点列表，和部分peer节点构成邻居关系

当peer下载时，该peer可以同时向其他节点提供上载服务

Peer可能回变换用于交换块的节点

扰动：peer节点可能回上线或者下线

一旦一个Peer拥有整个文件（种子），它会（自私的）离开或者保留（利他主义）再torrent中

俗称种子

DHT（结构化）P2P

有序的（了解即可）

环装，树状

7、CDN（视频流化服务和CDN：上下文）

• 视频流量：占据着互联网大部分的带宽
• 挑战：规模性—如何服务这么多用户？
• 挑战：异构性
• • 不同用户拥有不同的能力（例如：有线接入和移动用户：带宽丰富和受限用户）
• 解决方案：分布式的，应用层面的基础设施

多媒体：视频

• CBR（constant bit rate）：以固定速率编码
• VBR（variable bit rate）：视频编码速率随时间的变化而变化

存储视频的流化服务

一边下缓存一边看。大部分减少等待时间

DASH Dynamic, Adaptive Stream over HTTP

服务器

• 将视频文件分割成多个块
• 每个块独立存储，编码于不同码率（8 - 10种）
• 告示文件（manifest file）：提供不同块的URL

客户端

• 先获取告示文件
• 周期性地勘测服务器到客户端的带宽
• 查询告示文件，再一个时间刻请求一个块，HTTP头部指定字节范围
• • 如果带块足够，选择最大码率的视频块
  • 绘画种的不同时刻，可以切换请求不同的编码块（取决于当时的可用带宽）

只能客户端：客户端自适应决定

• 什么时候去请求（不至于缓存挨饿，或者溢出）
• 请求什么编码速率的视频块（当带宽够用时，请求质量的视频块）
• 哪里去请求块（可以向离自己仅的服务器发送URL， 或者向高可用带宽的服务器请求）

挑战：服务器如何通过网络向成百万的用户同时提供流化视频服务？

选择1：单个的大的超级服务中心

• 服务器到客户路径上的跳数比较多，瓶颈链路的带宽小导致停顿
• 二八定律 决定了网络同时充斥着同一个视频的多个拷贝
• 单点故障点，性能瓶颈
• 周边网络的拥塞

我的评价是：相当简单，，但这个方法不可扩展

选择2：通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验

• enter deep 将CDN服务器深入到许多接入网
• • 更加接近用户，数量多。
• bring home 部署少数的关键位置，如将服务器安装与pop附近（离若干ISP pop较近）

ICP预先把内容放在CDN运营商的缓存节点

用户点播时从源服务器获得manifest file

用户请求块的时候，决定于客户端自己。向附近的缓存节点获取。

中国 ： 中国蓝汛

8、TCP套接字（Socket）编程

应用进程使用传输层提供的服务才能够交换报文，实现应用协议，实现应用

TCP/IP:应用进程使用Socket AP访问传出服务

地点：界面上的SAP，方式：Socket API

目标：学习如何构建借助sockets进行同i性能的C/S应用程序

socket：分布式应用进程之间的门，传输层协议提供端到端服务接口。

套接字：应用进程与端到端传输协议之间的门户

TCP服务：从一个进程向另一个进程可靠的传输字节流

服务器首先运行，等待连接建立

1、服务器进程必须先处于运行状态

• 创建欢迎socket
• 和本地端口捆绑
• 在欢迎socket上阻塞式的等待用户的连接

2、客户端主动和服务器建立连接

• 指定服务器进程的IP地址和端口号、与服务器进行连接

3、当与客户端连接请求到来时

• 服务器接收来自客户端的请求，解除阻塞式等待，返回一个新的socket（与欢迎socket不一样），与客户端通信。
• • 允许服务器与多个客户端通信
  • 使用IP和源端口来区分不同的客户端

struct sockaddr_in{
    short sin_family;//地址族
    u_short sin_port;   //端口号
    struct in_addr sin_addr;	//IP地址
    char sin_zero[8]; //对齐
}

struct host_ent{
    char * h_name;   //主机域名
    char ** h_aliases;  //主机别名
    int h_addrtype;
    int h_length;   //地址长度
    char ** h_addr_list;
    #define h_addr h_addr_list[0];
}

9、UDP套接字编程

UDP：在客户端和服务器之间没有连接

• 没有握手
• 发送端在每一个报文种明确地指定目标的IP地址和端口号
• 服务器必须从受到的分组中提取出发送端的IP地址和端口号

UDP传送的数据可能乱序，有可能丢失