Web缓存/大力服务器
用户设定浏览器通过缓存进行Web访问
浏览器向缓存/代理
如果所请求对象在缓存当中，缓存返回对象
缓存不仅充当客户端还充当服务器
一般是ISP架设
机构网络当中的浏览器平均每秒有15个到原始服务器的请求
从机构路由器到原始服务器的往延迟约2秒

Web缓存和代理服务器
客户访问如果在代理服务器上有，就直接返回，
条件性get方法
目标：
如果缓存有最新的技术，则不需要发送请求对象

缓存：在HTTP请求消息当中声明所持有的版本的日期
i-modified-since:
服务器：
如果缓存的版本是最新的，则响应消息当中不包含对象
HTTP/1.0 304 Not Modified

P26Emial的应用

emial的构成
邮件客户端
邮件服务器
SMTP协议Simple Mial Transfer protocol
emial应用的构成

邮箱：存储发给用户的emial
消息队列:存储等待发送的emial
SMTP协议：
邮件服务器之间传递消息所使用的协议
客户端：发送消息的服务器
服务器：接受消息的服务器

SMTP协议：RFC 2821
TCP进行emial消息的可靠传输
端口25
传输过程的三个阶段：
握手
消息的传输
关闭

P27：

SMTP：emial消息的传输、交换协议
RC 822:文本消息格式标准
头部行(header)
TO FROM SUBJECT
与SMTP命令是不同的

消息体(body)
消息本身
只能是SACII
MIME:多媒体邮件扩展RFC 2045,2056
通过在邮件的头部增加额外的行以声明MIME的内容类型
DNS服务
域名向IP地址的翻译

主机别名
邮件服务器的别名
负载均衡：Web服务器
为什么不使用集中式的DNS？
单点失败的问题
流量问题
距离问题
维护性的问题

分布式层次式数据库

权威域名服务器：组织的域名解析服务器：提供组织服务器的解析服务
负责维护
负责提供商的负责维护

本地域名解析服务器
不严格属于层级体系
每个iSP都有一个本地域名服务器
默认域名解析服务器
当主机进行DNS查询的时候，查询被发送到本地的域名服务器
作为代理(proxy),将查询转发给（层级式的）域名解析服务器系统

P29

资源记录（RR，RESCOURE records)
Type=A
Name:上机于命
Value:IP地址
Type=CName:
Name:某一真实域名的悲鸣
Value:真实域名
Type=MX
Value是与name相2对应的邮件服务器
DNS协议与消息的格式
DNS协议：
查询query和回复reply消息
消息格式是相同的

flags消息
numbers of questions
name,type fields
for query
RRS in response to query answers
records for authoritatative servers
如何注册一个域名？
向域名管理机构提供你的权威域名解析服务器的名字和ip地址
域名管理机构向com*域名解析服务器当中插入两条记录
networkutopia.com,dns1.networkutopoa.com,NS)
(dns1.networkutopia.com,212.212.212.1,A)
在权威域名解析服务器当中加入TypeA记录，为networkutopia.com当中加入TypeMX记录

思考题：
请查阅有关的资料，找出那些在应用层实现的Internet核心服务，调研他们的协议，消息的格式。

p30纯P2P架构

Peer-to-peer
没有服务器
任意端系统之间之间i而痛心
节点阶段性接入Internet
节点可能更换IP地址

以具体的应用为例讲解
文件分发
客户机/服务器

服务器串行地发送N个副本
时间:NF/us
客户机i需要F/di时间下载

线性增长的，
BitTorrent
tracker：跟踪参与torrent的节点
torrent:交换同一个文件的文件快的节点组

交换文件快chunk
BitTorrent
文件划分为256kb的chunk
节点加入torrent
没有chunk但是会逐渐积累
向tracker注册以获得节点清单，与某些节点建立连接
下载的同时，节点需要向其他的节点上传chunk
节点可能加入或者离开

获取chunk
给定任何时刻，不同的节点持有文件的不同chunk集合
节点alice定期查询每个邻居所持有的chunk
节点发送请求，请求获取缺失chunk
稀缺优先

发送chunk:tit-for-tat
Alice向4个邻居发送chunk
上传的速率高，则能够找打更好的交易的伙伴，从而更快的获取文件

BitTorrent技术对网络性能有哪些潜在的危害？？？

P31

P2P;搜索信息
P2P系统的索引：信息到节点位置（IP地址+端口号）的映射
文件共享
利用索引动态跟踪节点所共享的文件的位置
节点需要告诉索引他拥有的文件
节点搜索索引，从而告知能够获得哪些文件

即时消息
QQ
索引负责将用户名映射到位置
当用户开启IM应用的时候，需要通知索引他的位置
节点检索索引的时候，确定用户的IP的地址
集中式索引
NAPSTER最早采用的这种设计
1.节点加入的时候，通知*服务器
IP地址
内容
2.Alice查找HeyJude
3.Alice从Bob出请求文件

集中式索引的问题
内容和文件传输是分布式的
但是内容的定位是高度集中式的
单点失效的问题
性能瓶颈的问题
版权问题

单调失效性能瓶颈，版权问题
内容和文件传输是分布式的，但是内容定位是高度集中式的

洪范式查询
：Query flooding
完全分布式架构
Gnutella采用的这种架构
每个节点对他共享的文件进行索引，且只对他共享的文件进行索引

覆盖网络overlay network):Graph:
节点X与Y之间如果有TCO连接，那么构成一个遍
所有的活动节点和便构成覆盖网络
边：虚拟链路
节点一般邻居数目少于10个

查询消息通过已经有的TCP连接发送
节点转发查询消息
如果查询命中，则利用反向路径发回查询节点

查询消息通过已经有的TCP连接发送
节点转发查询消息
如果查询命中，则利用反向路径发回查询节点
很简答

层次性覆盖网络
介于集中式索引和洪范查询节点之间的方法
每个节点或者是一个超级节点，或者是被分配一个超级节点
节点和超级节点之间维持TCO连接
某些超级节点对之间维持TCP连接

本质上是P2P的，用户/节点对之间直接通信
私有的应用曾协议
采用层次式覆盖网络结构

私有的应用曾协议
采用层次是覆盖网络结构
索引负责维护用户名与IP地址之间的映射
索引分布在超级节点之上

P32Socket编程 API接口

网络程序设计接口
针对端系统，，用户使用的主机上开发应用

数据链路层：直接网卡编程，硬件相关
基于Packet Deriver编程：屏蔽网卡细节，适用于所有的网卡
LibPcap/WinPcap,Libnet,Libnids,Libicmp编程
传输层：NetBIOS编程，Windows
传输岑那个：Socket编程
应用层：Application:Web/RPC/中间件编程
套接字
应用编程接口API
应用层：应用进程：应用层协议
传输层
网络层
数据链路层
物理层
应用进程
应用层：应用进程控制
接口进行交互
应用编程接口API
网络应用程序接口API：（Application Programming Interface)
就是应用进程的控制权和操作系统的控制权尽心给转换的一个系统调用的接口

几种比较典型的应用编程接口
Berkeley UNIX:操作系统定义了一种API，称为套接字接口
微软公司在其操作系统当中次啊用了套接字接口API，形成了稍有不同的接口
AT&T为其UNIX系统V定义了一种API，简写为TLI（Transport Layer Interface)

P33

最初设计
面向BSD UNIX-Berkley
面向TCP/IP的协议栈的接口
目前：
事实上的工业标准
绝大多数的操作系统都支持
Internte网络应用最典型的API接口，
通信模型
客户/服务器(C/S)
应用进程之间的通信的抽象机制
通信模型‘：
客户/服务器(C/S)
应用进程之间的通信
最常用的API的接口
客户/服务器c/s
应用进程之间的通信的抽象机制
Socket API
应用层可能会有很多应用进程
标识通信端点（对外）：
一个进程会创建多个套接字
创建套接字期望于通信的时候，怎么样明确和哪一个应用进程进行通信

客户主机IP地址
服务器的主机IP地址

端口
标识通信端点（对外）：
给编号，称之为端口号，有了IP地址可以知道对应哪一个进程上运行的套接字，有了端口号就可以知道是哪一个套接字
标识通信端点（对外）：
IP地址+端口号
应用进程
Socket抽象
类似于文件的抽象
操纵系统/进程如何管理套接字？
套接字描述符
Scket抽象
类似于文件的抽象
特殊的文件，
当应用进程创建套接字的时候，操作系统分配一个数据结构存储该套接字相关的信息
返回套接字描述符
地址结构

Soecket描述符表，每一个进程都会管理这样一个表：指针指向套接字的数据结构，套接字非常重要的信息是地址信息
地址结构
已经定义了结构sockaddr_in: