E-mail
Web
文本消息
远程登录
P2P文件共享
即时通信
多用户网络游戏
流媒体(YouTube, Hulu, Netflix)
可能的应用架构:
客户-服务器模式(C/S:client/server)
对等模式(P2P:Peer To Peer)
混合体:客户-服务器和对等体系结构
对于使用面向连接服务(TCP)的应用而言,套接字是4元组的一个具有本地意义的标示
4元组:(源IP,源port,目标IP,目标port)
唯一的指定了一个会话(2个进程之间的会话关系)
应用使用这个标示,与远程的应用进程通信
不必在每一个报文的发送都要指定这4元组
就像使用操作系统打开一个文件,OS返回一个文件句柄一样,以后使用这个文件句柄,而不是使用这个文件的目录名、文件名
简单,便于管理
数据丢失率
有些应用则要求100%的可靠数据传输(如文件)
有些应用(如音频)能容忍一定比例以下的数据丢失
延迟
一些应用 出于有效性考虑,对数据传输有严格的时间限制
Internet 电话、交互式游戏
延迟、延迟差
吞吐
一些应用(如多媒体)必须需要最小限度的吞吐,从而使得应用能够有效运转
一些应用能充分利用可供使用的吞吐(弹性应用)
安全性
机密性
完整性
可认证性(鉴别)
TCP 服务:
可靠的传输服务
流量控制:发送方不会淹没接受方
拥塞控制:当网络出现拥塞时,能抑制发送方
不能提供的服务:时间保证、最小吞吐保证和安全
面向连接:要求在客户端进程和服务器进程之间建立连接
UDP 服务:
不可靠数据传输
不提供的服务:可靠,流量控制、拥塞控制、时间、带宽保证、建立连接
Q: 为什么要有 UDP?
UDP存在的必要性
能够区分不同的进程,而IP服务不能 在IP提供的主机到主机端到端功能的基础上,区分了主机的应用进程
无需建立连接,省去了建立连接时间,适合事务性的应用
不做可靠性的工作,例如检错重发,适合那些对实时性要求比较高而对正确性要求不高的应用 因为为了实现可靠性(准确性、保序等),必须付出时间代价(检错重发)
没有拥塞控制和流量控制,应用能够按照设定的速度发送数据
而在TCP上面的应用,应用发送数据的速度和主机向网络发送的实际速度是不一致的,因为有流量控制和拥塞控制
TCP & UDP
都没有加密
明文通过互联网传输,甚至密码SSL
在TCP上面实现,提供加密的TCP连接
私密性
数据完整性
端到端的鉴别
SSL在应用层
应用采用SSL库,SSL库使用TCP通信SSL socket API
应用通过API将明文交给socket,SSL将其加密在互联网上传输
一些术语
Web页:由一些对象组成
对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
Web页含有一个基本的HTML文件,该基本HTML文件又包含若干对象的引用(链接)
通过URL对每个对象进行引用 访问协议,用户名,口令字,端口等;
URL格式
非持久HTTP
最多只有一个对象在TCP连接上发送
下载多个对象需要多个TCP连接
HTTP/1.0使用非持久连接
持久HTTP
多个对象可以在一个(在客户端和服务器之间的)TCP连接上传输
HTTP/1.1 默认使用持久连接
HTTP响应状态码
200 OK
请求成功,请求对象包含在响应报文的后续部分
301 Moved Permanently
请求的对象已经被永久转移了;新的URL在响应报文的Location:
首部行中指定
客户端软件自动用新的URL去获取对象
400 Bad Request
一个通用的差错代码,表示该请求不能被服务器解读
404 Not Found
请求的文档在该服务上没有找到
505 HTTP Version Not Supported
大多数主要的门户网站使用 cookies
4个组成部分:
缓存既是客户端又是服务器
通常缓存是由ISP安 装 (大学、公司、居民区ISP)
为什么要使用Web缓存?
降低客户端的请求响应时间
可以大大减少一个机构内部网络与Internent接入链路上的流量
互联网大量采用了缓存:可以使较弱的ICP也能够有效提供内容
解决缓存不一致的问题
命令样例:
在控制连接上以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
使用TCP在客户端和服务器之间传送报文,端口号为25
直接传输:从发送方服务器到接收方服务器
传输的3个阶段
握手、传输报文、关闭
命令/响应交互
命令:ASCII文本
响应:状态码和状态信息
报文必须为7位ASCII码
简单的SMTP交互
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: alice@crepes.fr
S: 250 alice@crepes.fr… Sender ok
C: RCPT TO: bob@hamburger.edu
S: 250 bob@hamburger.edu … Recipient ok
C: DATA
S: 354 Enter mail, end with “.” on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
SMTP使用持久连接
SMTP要求报文(首部和主体)为7位ASCII编 码 SMTP服务器使用
CRLF.CRLF决定报文的尾部
HTTP比较:
HTTP:拉(pull) SMTP:推(push) 二者都是ASCII形式的命令/
响应交互、状态码
HTTP:每个对象封装在各自的响应报文中
SMTP:多个对象包含在一个报文中
DNS(Domain Name System)
DNS的必要性
IP地址标识主机、路由器
但IP地址不好记忆,不便人类使用(没有意义) 人类一般倾向于使用一些有意义的字符串来标识Internet上的设备
例如:qzheng@ustc.edu.cn 所在的邮件服务器
www.ustc.edu.cn 所在的web服务器
存在着“字符串”—IP地址的转换的必要性
人类用户提供要访问机器的“字符串”名称
由DNS负责转换成为二进制的网络地址
问题1:如何命名设备
用有意义的字符串:好记,便于人类用使用
解决一个平面命名的重名问题:层次化命名
问题2:如何完成名字到IP地址的转换
分布式的数据库维护和响应名字查询
问题3:如何维护:
增加或者删除一个域,需要在域名系统中做哪些工作
ARPANET的名字解析解决方案
主机名:没有层次的一个字符串(一个平面)
存在着一个(集中)维护站:维护着一张 主机名-IP地址的映射文件:Hosts.txt
每台主机定时从维护站取文件
ARPANET解决方案的问题
当网络中主机数量很大时 没有层次的主机名称很难分配 文件的管理、发布、查找都很麻烦
DNS的主要思路
分层的、基于域的命名机制
若干分布式的数据库完成名字到IP地址的转换
运行在UDP之上端口号为53的应用服务
核心的Internet功能,但以应用层协议实现
在网络边缘处理复杂性
DNS主要目的:
实现主机名-IP地址的转换(name/IP translate)
其它目的
主机别名到规范名字的转换:Host aliasing
邮件服务器别名到邮件服务器的正规名字的转换:Mail server
aliasing
负载均衡:Load Distribution
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)
树叶是主机
从本域往上,直到树根
中间使用“.”间隔不同的级别
例如:ustc.edu.cn
auto.ustc.edu.cn
www.auto. ustc.edu.cn
域的域名:可以用于表示一个域
主机的域名:一个域上的一个主机
域名的管理
一个域管理其下的子域
.jp 被划分为 ac.jp co.jp
.cn 被划分为 edu.cn com.cn
创建一个新的域,必须征得它所属域的同意
域与物理网络无关
域遵从组织界限,而不是物理网络
一个域的主机可以不在一个网络
一个网络的主机不一定在一个域
域的划分是逻辑的,而不是物理的
一个名字服务器的问题
可靠性问题:单点故障
扩展性问题:通信容量
维护问题:远距离的集中式数据库
区域(zone)
区域的划分有区域管理者自己决定
将DNS名字空间划分为互不相交的区域,每个区域都是树的一部分
名字服务器:
每个区域都有一个名字服务器:维护着它所管辖区域的权威信息(authoritative record)
名字服务器允许被放置在区域之外,以保障可靠性
顶级域(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
Value 值:可以是数字,域名或ASCII串
Type 类别:资源记录的类型—见下页
并不严格属于层次结构
每个ISP (居民区的ISP、公司、大学)都有一个本地DNS服务器
也称为“默认名字服务器”
当一个主机发起一个DNS查询时,查询被送到其本地DNS服务器
起着代理的作用,将查询转发到层次结构中
提高性能:缓存
一旦名字服务器学到了一个映射,就将该映射缓存起来
根服务器通常都在本地服务器中缓存着
使得根服务器不用经常被访问
目的:提高效率
可能存在的问题:如果情况变化,缓存结果和权威资源记录不一致
解决方案:TTL(默认2天)
在上级域的名字服务器中增加两条记录,指向这个新增的子域的域名 和 域名服务器的地址
在新增子域 的名字服务器上运行名字服务器,负责本域的名字解析: 名字->IP地址
例子:在com域中建立一个“Network Utopia”
到注册登记机构注册域名networkutopia.com
需要向该机构提供权威DNS服务器(基本的、和辅助的)的名字和IP地址
登记机构在com TLD服务器中插入两条RR记录: (networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)
在networkutopia.com的权威服务器中确保有
用于Web服务器的www.networkuptopia.com的类型为A的记录
用于邮件服务器mail.networkutopia.com的类型为MX的记录
DDoS 攻击
对根服务器进行流量轰炸攻击:发送大量ping
没有成功
原因1:根目录服务器配置了流量过滤器,防火墙
原因2:Local DNS 服务器
缓存了TLD服务器的IP地址, 因此无需查询根服务器
**向TLD服务器流量轰炸攻击:发送大量查询 **
可能更危险
效果一般,大部分DNS缓存了TLD
重定向攻击
中间人攻击
截获查询,伪造回答,从而攻击某个(DNS回答指定的IP)站点
DNS中毒
发送伪造的应答给DNS服务器,希望它能够缓存这个虚假的结果
技术上较困难:分布式截获和伪造
利用DNS基础设施进行DDoS
伪造某个IP进行查询, 攻击这个目标IP
查询放大,响应报文比查询报文大
效果有限
没有(或极少)一直运行的服务器
任意端系统都可以直接通信
利用peer的服务能力
Peer节点间歇上网,每次IP地址都有可能变化
例子:
文件分发 (BitTorrent)
流媒体(KanKan)
VoIP (Skype)
问题: 从一台服务器分发文件(大小F)到N个peer需要多少时间?
Peer节点上下载能力是有限的资源
文件被分为一个个块256KB
网络中的这些peers发送接收文件块,相互服务
请求块:
在任何给定时间,不同peer节点拥有一个文件块的子集
周期性的,Alice节点向邻居询问他们拥有哪些块的信息
Alice向peer节点请求它希望的块,稀缺的块
发送块:一报还一报tit-for-tat
Alice向4个peer发送块,这些块向它自己提供最大带宽的服务
其他peer被Alice阻塞 (将不会从Alice处获得服务)
每10秒重新评估一次:前4位
每个30秒:随机选择其他peer节点,向这个节点发送块
“优化疏通” 这个节点
新选择的节点可以加入这个top 4
BitTorrent: tit-for-tat
(1) Alice “优化疏通” Bob
(2) Alice 变成了Bob的前4位提供者; Bob答谢Alice
(3) Bob 变成了Alice的前4提供者
例子
Alice在其笔记本电脑上运行P2P客户端程序
间歇性地连接到Internet,每次从其ISP得到新的IP地址
请求“双截棍.MP3”
应用程序显示其他有“双截棍.MP3” 拷贝的对等方
Alice选择其中一个对等方,如Bob.
文件从Bob’s PC传送到Alice的笔记本上:HTTP
当Alice下载时,其他用户也可以从Alice处下载
Alice的对等方既是一个Web客户端,也是一个瞬时Web服务器
所有的对等方都是服务器= 可扩展性好!
两大问题:
如何定位所需资源
如何处理对等方的加入与离开
可能的方案
集中
分散
半分散
P2P:集中式目录中存在的问题
单点故障
性能瓶颈
侵犯版权
文件传输是分散的,而定位内容则是高度集中的
全分布式 没有中心服务器
开放文件共享协议
许多Gnutella客户端实现了Gnutella协议
类似HTTP有许多的浏览器
覆盖网络:图
如果X和Y之间有一个TCP连接,则二者之间存在一条边
所有活动的对等方和边就是覆盖网络
边并不是物理链路
给定一个对等方,通常所连接的节点少于10个
Gnutella:对等方加入
KaZaA:查询
每个文件有一个散列标识码和一个描述符
客户端向其组长发送关键字查询
组长用匹配进行响应:
对每个匹配:元数据、散列标识码和IP地址
如果组长将查询转发给其他组长,其他组长也以匹配进行响应
客户端选择要下载的文件
向拥有文件的对等方发送一个带散列标识码的HTTP请求
Kazaa小技巧
请求排队
限制并行上载的数量
确保每个被传输的文件从上载节点接收一定量的带宽
激励优先权
鼓励用户上载文件
加强系统的扩展性
并行下载
从多个对等方下载同一个文件的不同部分
HTTP的字节范围首部
更快地检索一个文件
视频流量:占据着互联网大部分的带宽
Netflix, YouTube: 占据37%, 16% 的ISP下行流量
• ~1B YouTube 用户, ~75M Netflix用户
挑战:规模性-如何服务者 ~1B 用户?
• 单个超级服务器无法提供服务(为什么)
挑战:异构性
不同用户拥有不同的能力(例如:有线接入和移动用户;带宽丰富和受限用户)
解决方案: 分布式的,应用层面的基础设施
CBR: (constant bit rate): 以固定速率编码
VBR: (variable bit rate): 视频编码速率随时间的变化而变化
例子:
MPEG 1 (CD-ROM) 1.5 Mbps
MPEG2 (DVD) 3-6 Mbps
MPEG4 (often used in Internet, < 1 Mbps)
DASH: Dynamic, Adaptive Streaming over HTTP
服务器:
将视频文件分割成多个块
每个块独立存储,编码于不同码率(8-10种)
告示文件(manifest file): 提供不同块的URL
客户端:
先获取告示文件
周期性地测量服务器到客户端的带宽
查询告示文件,在一个时刻请求一个块,HTTP头部指定字节范围
如果带宽足够,选择最大码率的视频块
会话中的不同时刻,可以切换请求不同的编码块 (取决于当时的可用带宽)
“智能”客户端: 客户端自适应决定
什么时候去请求块 (不至于缓存挨饿,或者溢出)
请求什么编码速率的视频块 (当带宽够用时,请求高质量的视频块)
哪里去请求块 (可以向离自己近的服务器发送URL,或者向高可用带宽的服务器请求)
挑战: 服务器如何通过网络向上百万用户同时流化视频内容 (上百万视频内容)?
选择1: 单个的、大的超级服务中心“mega-server”
服务器到客户端路径上跳数较多,瓶颈链路的带宽小导致停顿
“二八规律”决定了网络同时充斥着同一个视频的多个拷贝,效率低(付费高、带宽浪费、效果差)
单点故障点,性能瓶颈
周边网络的拥塞
评述:相当简单,但是这个方法不可扩展
选项2: 通过CDN,全网部署缓存节点,存储服务内容,就近为用户提供服务,提高用户体验
enter deep: 将CDN服务器深入到许多接入网
更接近用户,数量多,离用户近,管理困难
Akamai, 1700个位置
bring home: 部署在少数(10个左右)关键位置,如将服务器簇安装于POP附近(离若干1stISP POP较近)
采用租用线路将服务器簇连接起来
Limelight
CDN: 在CDN节点中存储内容的多个拷贝
• e.g. Netflix stores copies of MadMen
用户从CDN中请求内容
• 重定向到最近的拷贝,请求内容
• 如果网络路径拥塞,可能选择不同的拷贝
案例学习: Netflix
应用进程使用传输层提供的服务才能够交换报文,实现应用协议,实现应用
TCP/IP:应用进程使用Socket API访问传输服务
地点:界面上的SAP(Socket) 方式:Socket API
目标: 学习如何构建能借助sockets进行通信的C/S应用程序
socket: 分布式应用进程之间的门,传输层协议提供的端到端
2种传输层服务的socket类型:
TCP: 可靠的、字节流的服务
UDP: 不可靠(数据UDP数据报)服务
套接字:应用进程与端到端传输协议(TCP或UDP)之间的门户
TCP服务:从一个进程向另一个进程可靠地传输字节流
C/S模式的应用样例:
sockaddr_in
IP地址和port捆绑关系的数据结构(标示进程的端节点)
struct sockaddr_in {
short sin_family; //AF_INET
u_short sin_port; // port
struct in_addr sin_addr ;
// IP address, unsigned long
char sin_zero[8]; // align
};
hostent
域名和IP地址的数据结构
struct hostent
{ char *h_name;
char **h_aliases;
int h_addrtype;
int h_length; /地址长度/
char **h_addr_list;
#define h_addr h_addr_list[0];
}
作为调用域名解析函数时的参数
返回后,将IP地址拷贝到 sockaddr_in的IP地址部分
UDP: 在客户端和服务器之间没有连接
• 没有握手
• 发送端在每一个报文中明确地指定目标的IP地址和端口号
• 服务器必须从收到的分组中提取出发送端的IP地址和端口号
UDP: 传送的数据可能乱序,也可能丢失
进程视角看UDP服务
UDP 为客户端和服务器提供不可靠的字节组的传送服务