一、C/S结构：
服务器 - 7*24小时提供服务；永久性访问地址／域名；利用大量服务器实现可扩展性
客户机 - 与服务器通信，使用服务器提供的服务；间接性接入网络；可能使用动态IP地址；不会与其它客户机直接通信

二、P2P结构：
没有永远在线的服务器
任意端系统／节点之间可以之间通讯
节点间歇性接入网络
节点可以改变IP地址

应用：文件传输

P2P vs C/S：
优 - 高度可伸缩
劣 - 难于管理

P2P搜索信息：
P2P系统的索引：信息到节点的位置(IP地址+端口号)的映射
文件共享(电驴)：利用索引动态跟踪节点所共享的文件等位置；节点需要告诉索引它拥有哪些文件；节点搜索索引，从而获知能够得到哪些文件
即时消息(QQ):索引负责将用户名映射到位置；当用户开启IM应用时，需要通知索引它的位置；节点检索索引，确定用户的IP地址

1.集中式索引：
Napster最早采用这种设计
缺点 - 单点失效问题；性能瓶颈；版权问题

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

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

3.层次式覆盖网络
介于集中式索引和洪泛式查询之间的方法
每个节点或者是一个超级节点，或者被分配一个超级节点 - 节点和超级节点之间维持TCP连接；某些超级节点对之间维持TCP连接
超级节点负责跟踪子节点的内容

P2P案例分：Skype
本质上是P2P的：用户／节点之间直接通信
私有应用层协议
采用层次式覆盖网络架构
索引负责维护用户名与IP地址间的映射
索引分布在超级节点上

三、混合结构：
同时使用C/S与P2P，例如Napster，文件传输使用P2P，文件搜索使用C/S

进程通信：
同一主机进程通信：操作系统提供的进程间的通信机制
不同主机进程通信：消息交换

Socket：进程间通信利用Socket发送／接收消息；传输基础设施向进程提供API

寻址：区分不同的进程 - 外部IP地址 + 端口号，HTTP server，80；email server，25

网络应用对传输的要求：
数据丢失／可靠性
时间／时延
带宽

Internet提供的传输服务：

• TCP服务：
  面向连接：客户机／服务器进程间需要建立连接
  可靠的传输
  流量控制：发送方不会发送速度过快，超过接受方的处理能力
  拥塞控制：当网络负载过重时能够限制发送方的发送速度
  不提供时间／延迟保障
  不提供最小带宽保障
• UDP服务：
  无连接
  不可靠的数据传输
  不提供可靠性保障；不提供流量控制；不提供拥塞控制；不提供延迟保障；不提供带宽保障

HTTP协议：
超文本传输协议 HyperText Transfer Protocol
C/S结构：客户 - 请求、接收、展示web对象；服务器 - web server - 响应客户的请求，发送对象
版本：1.0 - RFC1945；1.1 - RFC 2068
使用TCP传输服务：使用80端口；浏览器发起到服务器的TCP连接(创建套接字Socket)；服务器接收来自浏览器的TCP连接；浏览器与服务器交换HTTP消息；关闭TCP连接
无状态stateless：服务器不维护任何有关客户端过去所发请求的信息

HTTP两种连接类型：

• 非持久连接，每个TCP连接最多允许传输一个对象
  响应时间 - 2RTT + 文件发送时间。发起建立TCP连接，1个RTT时间，发送请求消息到HTTP响应消息的前几个字节到达时间，1个RTT，响应消息中所含的文件／对象传输时间。RTT，从客户端发送一个很小的数据包到服务器并返回所经历的时间。
  缺点：每个对象需要2个RTT；操作系统需要为某个TCP连接开销资源；浏览器需要打开多个并行的TCP连接以获取网页所需对象
• 持久性连接，发送响应之后，服务器保持TCP连接的打开；后续的HTTP消息可以通过这个连接发送

HTTP消息格式：

• 请求
  method url http版本号
  header
  body
• 响应
  status ：HTTP／1.1 200 ok
  header
  body

方法类型：

• HTTP 1.0，GET，POST，HEAD
• HTTP 1.1，GET，POST，HEAD，PUT，DELETE

cookie技术：
某些网站为了辨别用户身份、进行session跟踪而存储在用户本地终端上的数据(通常经过加密)
RSC6265
cookie组件 - HTTP响应消息的cookie头部行；HTTP请求消息的cookie头部行；保存在客户端主机上的cookie文件，由浏览器管理；web服务器端端后台数据库

cookie的作用：
身份认证；购物车；推荐；web email

web缓存／代理服务器技术：
在不访问服务器的前提下满足客户端HTTP请求

web缓存的好处：
缩短客户请求的响应时间
减少机构／组织的流量
在大范围内实现有效的内容分发

email应用的构成：
邮件客户端
邮件服务器 - 邮箱，存储发给该用户的email；消息队列，存储等待发送的email
SMTP协议 - RFC2821，邮件服务器之间传递信息所使用的协议；端口25；传输过程的三个阶段，握手，消息传输，关闭；命令／响应交互模式，命令是ASCII文本，响应是状态代码和语句；email消息只能包含7位ASCII

SMTP协议：
使用持久性连接
要求消息必须由7位ACSII码构成
SMTP服务器利用CRLF.CRLF确定消息的结束

SMTP vs HTTP
HTTP：拉式pull，每个对象都封装在独立的响应消息中
SMTP：推式push，多个对象在由多个部分构成的消息中发送
都使用命令／响应交互模式
命令和状态码都是ASCII码

email消息格式：多媒体扩展
MIME，多媒体邮件扩展RFC2045，2056
通过在邮件头部增加额外的行以声明MIME的内容类型

邮件访问协议：从服务器获取邮件

• POP
  Post Office Protocol，RFC1939。认证／授权(客户端<->服务器)和下载，无状态
  认证过程：
  客户端命令 - user，password
  服务器命令 - +OK，-ERR
  事务阶段：
  List - 列出消息数量
  Retr - 用编号获取消息
  Dele - 删除消息
  Quit
  模式：
  下载并删除模式，换了客户端软件，无法重读邮件
  下载并保持模式，不同客户端都可以保留消息端拷贝

• IMAP
  Internet Mail Access Protocol，RFC1730。更多功能，更加复杂，能够操纵服务器上存储的消息，有状态
  所有消息统一保存在一个地方，服务器；允许用户利用文件夹组织消息；IMAP支持跨会话(session)等用户状态，文件夹的名字，文件夹与消息之间的映射

• HTTP
  163，QQ email等

DNS：Domain Name System
Internet 上主机／路由器的识别问题：IP地址；域名，www.baidu.com

IP与域名之间如何映射？
-> 域名解析系统DNS
1.多层命名服务器构成的分布式数据库
2.应用层协议：完成名字的解析。Internet核心功能，用应用层协议实现；网络边界复杂

DNS服务：
域名向IP地址的翻译
主机别名
邮件服务器别名
负载均衡：web服务器

为什么DNS不使用集中式的？-> 不可伸缩
1.单点失败问题
2.流量问题
3.距离问题
4.维护性问题

DNS根域名服务器
本地域名解析服务器无法解析域名时，访问根域名服务器
根域名服务器如果不知道映射，访问权威域名服务器；获得映射；向本地域名服务器返回映射

TLD和权威域名解析服务器
顶级域名服务器TLD(top-level domain)：负责com，org，net，edu等顶级域名和国家顶级域名，例如cn，uk，fr等
Network Solutions维护com顶级域名服务器
Educause维护edu顶级域名服务器

权威域名服务器：组织等域名解析服务器，提供组织内部服务器等解析服务
组织负责维护
服务提供商负责维护

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

DNS查询：
迭代查询
递归查询

DNS记录缓存和更新：
只要域名解析服务器获得域名--IP映射，即缓存这一映射。
一段时间过后，缓存条目失效(删除)；本地域名服务器一般会缓存顶级域名服务器的映射，因此根域名服务器不经常被访问

DNS记录：
资源记录 RR resource records
格式：(name，value，type，ttl)
Type = A: name - 主机域名，value - IP地址
Type = NS：name - 域 edu.cn，value - 该域权威域名解析服务器的主机域名
Type = CNAME：name - 某一真实域名的别名 www.ibm.com - servereast.backup2.ibm.com, value - 真实域名
Type = MX：value是与name相对应的邮件服务器

DNS协议与消息
DNS协议：查询和回复；消息格式相同
消息头部：Identification - 16位查询编号，回复使用相同的编号；flags - 查询或回复，期望递归，递归可用，权威回答

如何注册域名？
1.在域名管理机构(Network Solutions)注册域名networkutopia.com
向管理机构提供你的权威域名解析服务器的名字和IP地址
域名管理机构向com顶级域名解析服务器中插入两条记录
(networkutopia.com，dns1.networkutopia.com，NS)
(dns1.networkutopia.com，212.212.212.1，A)
2.在权威域名解析服务器中为 www.networkutopia.com 加入Type A记录，为networkutopia.com加入Type MX记录

socket套接字：
典型的应用编程接口：
套接字接口(套接字)；微软的WINSOCK(Windows socket Interface)；uinx系统的TLI(Transport Layer Interface)

标识通信端点(对外)：IP地址+端口号
操作系统／进程如何管理套接字(对内)：套接字描述符socket descriptor，小整数

socket抽象：
类似于文件的抽象
当应用进程创建套接字时，操作系统分配一个数据结构存储该套接字相关信息
返回套接字描述符

地址结构：socketaddr_in
使用TCP／IP协议簇的网络应用程序声明端点地址变量时，使用结构socketaddr_in

socket API函数(WinSock)：
WSAStartup 初始化Windows Sockets API -> 应用程序 ->WSACleanup 释放所使用的Windows Sockets DLL

WSAStartup：
两个参数：指明程序请求使用的winsock版本，其中高位字节指明复版本、低位字节指明主版本；返回实际的winsock的版本信息

WSACleanup：
解除与socket库的绑定，释放socket库所占用的系统资源

socket(protofamily，type，proto)：
创建套接字；操作系统返回套接字描述符
protofamily = PF_INET(TCP/IP)
type：套接字类型
proto：协议号，0为默认

CloseSocket(Socket sd)：
关闭一个描述符为sd的套接字
如果多个进程共享一个套接字，调用closesocket将套接字引用计数减1，减至0才关闭
一个进程中的多线程对一个套接字的使用无计数 - 如果进程中的一个线程调用closesocket将一个套接字关闭，该进程中的其它线程也将不能访问该套接字
返回值 - 0，成功；SOCKET_ERROR，失败

int bind(sd，localaddr，addrlen)：
绑定套接字的本地端点地址：IP地址+端口号
sd：套接字描述符
localaddr：端点地址，结构sockaddr_in
客户程序一般不必调用bind函数
服务器需要调用，地址 - 使用地址通配符，INADDR_ANY

int listen(sd, queuesize)：
置服务器端的流套接字处于监听状态，仅服务器端调用，仅用于面向连接的流套接字
设置连接请求队列大小，queuesize
返回值：成功 -> 0，失败 -> SOCKET_ERROR

connect(sd，saddr，saddrlen)：
客户程序调用connect函数来使客户套接字sd 与特定计算机的特定端口 saddr 的套接字(服务)进行连接
仅用于客户端
可用于TCP客户端也可以用于UDP客户端，TCP客户端 -> 建立TCP连接，UDP客户端 -> 指定服务器端点地址

newsock accept(sd，caddr，caddrlen)：
服务程序调用accept函数从处于检讨状态的流套接字sd 的客户连接请求队列中取出排在最前的一个客户请求，并且创建一个新的套接字来于客户套接字创建连接通道，仅用于TCP套接字，仅用于服务器
利用新创建的套接字newsock 与客户通信

send()
sendto()
send函数TCP套接字(客户与服务器)或调用了connect函数的UDP客户端套接字
sendto函数用于UDP服务器端套接字与未调用conncet函数的UDP客户端套接字

recv()
recvfrom()
recv函数从TCP连接的另一端接收数据，或者从调用了connect函数的UDP客户端套接字接收服务器发来的数据
recvfrom函数用于从UDP服务器套接字与未调用connect函数的UDP客户端套接字接收对端数据

setsockopt()
getsockop()
setsockopt函数用来设置套接字sd的选项参数
getsockopt函数用于获取任意类型、任意状态套接口道选项当前值，并把结果存入optval

网络字节顺序：
TCP/IP定义来标准的用于协议头中的二进制整数表示 ->网络字节顺序 network byte order
某些socket API函数的参数需要存储为网络字节顺序，如IP地址、端口号等
可以实现本地字节顺序与网络字节顺序间转换的函数：
htons ->本地字节顺序 转 网络字节顺序 16bits
ntohs ->网络字节顺序 转 本地字节顺序 16bits
htonl ->本地字节顺序 转 网络字节顺序 32bits
ntohl ->网络字节顺序 转 本地字节顺序 32bits

客户端软件设计：
1.解析服务器IP地址
客户端可能使用域名或IP地址标识服务器
IP协议需要使用32位二进制IP地址
需要将域名或IP地址转换为32位IP地址。
函数inet_addr()实现点分十进制IP地址到32位IP地址转换
函数gethostbyname()实现域名到32位IP地址转换，返回一个指向结构hostent的指针
2.解析服务器端口号
客户端还可能使用服务名，如HTTP标识服务器端口
需要将服务名转换为熟知端口号
函数 - getservbyname()，返回一个指向结构servent 的指针
3.解析协议号
客户端可能使用协议名指定协议，如TCP
需要将协议名转换为协议号，如6
函数 - getprotobyname()实现协议名到协议号到转换，返回一个指向结构protoent 的指针
4.TCP客户端软件流程
确定服务器IP地址与端口号
创建套接字
分配本地端点地址 - IP地址+端口号
连接服务器(套接字)
遵循应用层协议进行通信
关闭／释放连接
5.UDP客户端软件流程
确定服务器IP地址与端口号
创建套接字
分配本地端点地址 - IP地址+端口号
指定服务器端点地址，构造UDP数据报
遵循应用层协议进行通信
关闭／释放连接