计算机网络笔记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传送的数据可能乱序，有可能丢失