[豪の学习笔记] 计算机网络#003
3.1.1 - 网络应用(层)内容概述
网络应用体系结构
客户机/服务器
P2P
混合结构
网络应用的服务需求
可靠性
带宽
时延
Internet传输层服务模型
TCP
UDP
特定网络应用及协议
HTTP
SMTP，POP，IMAP
Socket编程
TCP
UDP
3.2.1 - 网络应用体系结构
客户机/服务器结构(Client-Server，C/S)
服务器
7*24小时提供服务
永久性访问地址/域名
利用大量服务器实现可扩展性
客户机
与服务器通信，使用服务器提供的服务
间歇性接入网络
可能使用动态IP地址
不会与其他客户机直接通信
点对点结构(Peer-to-peer，P2P)
没有永远在线的服务器
任意端系统/节点之间可以直接通讯
节点间歇性接入网络
节点可能改变IP地址
优点：高度可伸缩
缺点：难于管理
混合结构(Hybrid)
Napster
文件传输使用P2P结构
文件的搜索采用C/S结构——集中式
每个节点向中央服务器登记自己的内容
每个节点向中央服务器提交查询请求，查找感兴趣内容
3.2.2 - 网络应用进程通信
进程：主机上运行的程序
客户机进程：发起通信的进程
服务器进程：等待通信请求的进程
Q：同一主机上运行的进程之间如何通信？
进程间通信机制
操作系统提供
Q：不同主机上运行的进程间如何通信？
消息交换
套接字Socket
进程间通信利用socket发送/接收消息实现
类似于寄信：
发送方将消息送到门外邮箱
发送方依赖(门外的)传输基础设施将消息传到接收方所在主机，并送到接收方的门外
接收方从门外获取消息
传输基础设施向进程提供API
传输协议的选择
参数的设置
Q：如何寻址进程？
不同主机上的进程间通信，那么每个进程必须拥有标识符
如何寻址主机？——IP地址
Q：主机有了IP地址后，是否足以定位进程？
A：否。同一主机上可能同时有多个进程需要通信。
端口号/Port number
为主机上每个需要通信的进程分配一个端口号
HTTP Server:80
Mail Server:25
进程的标识符
IP地址+端口号
应用层协议
网络应用都需遵循应用层协议
公开协议
由RFC(Request For Comments)定义
允许互操作
HTTP，SMTP，......
私有协议
多数P2P文件共享应用
协议内容：
消息的类型(type)
请求消息
响应消息
消息的语法(syntax)/格式
消息中有哪些子段(field)？
每个字段如何描述？
字段的语义(semantics)
字段中信息的含义
规则(rules)
进程何时发送/响应消息
进程如何发送/响应消息
3.2.3 - 网络应用需求
数据丢失(data loss)/可靠性(reliability)
某些网络应用能够容忍一定的数据丢失：网络电话
某些网络应用要求100%可靠的数据传输：文件传输，telnet
时间(timing)/延迟(delay)
有些应用只有在延迟足够低时才“有效”
网络电话/网络游戏
带宽(bandwidth)
某些应用只有在带宽达到最低要求时才“有效”：网络视频
某些应用能够适应任何带宽——弹性应用email
Internet提供的传输服务
①TCP服务
面向连接
客户机/服务器进程间需要建立连接
可靠的传输
流量控制
发送方不会发送速度过快，超过接收方的处理能力
拥塞控制
当网络负载过重时能够限制发送方的发送速度
不提供：
时间/延迟保障
最小带宽保障
②UDP服务
无连接
不可靠的数据传输
不提供：
可靠性保障
流量控制
拥塞控制
延迟保障
带宽保障
3.3.1 - Web应用概述
World Wide Web：Tim Berners-Lee
网页(Web Page)包含多个对象(objects)
对象：HTML文件、JPEG图片、视频文件、动态脚本等
基本的HTML文件：包含对其他对象引用的链接
对象的寻址(addressing)
URL(Uniform Resource Locator)：统一资源定位器
Scheme://host:port/path
HTTP协议概述
超文本传输协议 HyperText Transfer Protocol
C/S结构
客户 Browser：请求、接收、展示Web对象
服务器 Web Server：响应客户的请求，发送对象
使用TCP传输服务
服务器在80端口等待客户的请求
浏览器发起到服务器的TCP连接(创建套接字Socket)
服务器接收来自浏览器的TCP连接
浏览器(HTTP客户端)与Web服务器(HTTP服务器)交换HTTP消息
关闭TCP连接
无状态(stateless)
服务器不维护任何有关客户端过去所发请求的信息
PS：有状态的协议更加复杂：
需维护状态(历史信息)
如果客户端或服务器失效，会产生状态的不一致，解决这种不一致的代价高
3.3.2 - HTTP连接类型
①非持久性连接(Nonpersistent HTTP)
每个TCP连接最多允许传输一个对象
HTTP 1.0版本使用非持久性连接
响应时间分析与建模
RTT(Round Trip Time)
从客户端发送一个很小的数据包到服务器并返回所经历的时间
响应时间(Response time)
发起、建立TCP连接：1个RTT
发送HTTP请求消息到HTTP响应消息的前几个字节到达：1个RTT
响应消息中所含的文件/对象传输时间
Total = 2RTT + 文件发送时间
非持久性连接的问题
每个对象需要2个RTT
操作系统需要为每个TCP连接开销资源(overhead)
浏览器会怎么做？
打开多个并行的TCP连接以获取网页所需对象
给服务器端造成什么影响？很大的TCP资源开销
②持久性连接(Persistent HTTP)
每个TCP连接允许传输多个对象
HTTP 1.1版本默认使用持久性连接
发送响应后，服务器保持TCP连接的打开
后续的HTTP消息可以通过这个连接发送
无流水(pipelining)的持久性连接
客户端只有收到前一个响应后才发送新的请求
每个被引用的对象耗时1个RTT
带有流水机制的持久性连接
HTTP 1.1的默认选项
客户端只要遇到一个引用对象就尽快发出请求
理想情况下，收到所有的引用对象只需耗时约1个RTT
3.3.3 - HTTP消息格式
HTTP协议有两类消息
请求消息(request)
响应消息(response)
请求消息
ASCII：人直接可读
POST方法
网页经常需要填写表格(form)
在请求消息的消息体(entity body)中上传客户端的输入
URL方法
使用GET方法
输入信息通过request行的URL字段上传
HTTP/1.0
GET,POST
HEAD(请Server不要将所请求的对象放入响应消息中)
HTTP/1.1
GET,POST,HEAD
PUT(将消息体中的文件上传到URL字段所指定的路径)
DELETE(删除URL字段所指定的文件)
3.3.4 - Cookie技术
Q：为什么需要Cookie？
HTTP协议无状态，但很多应用需要服务器掌握客户端的状态，如网上购物，如何实现？引用Cookie技术
Cookie技术
某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据(通常经过加密)
RFC6265
Cookie的组件
HTTP响应消息的cookie头部行
HTTP请求消息的cookie头部行
保存在客户端主机上的cookie文件，由浏览器管理
Web服务器端的后台数据库
Cookie原理
Cookie作用
Cookie能够用于：身份认证、购物车、推荐、Web email
3.3.5 - Web缓存/代理服务器技术
在不访问服务器的前提下满足客户端的HTTP请求
缩短客户请求的响应时间
减少机构/组织的流量
在大范围内(Internet)实现有效的内容分发
Web缓存/代理服务器
用户设定浏览器通过缓存进行Web访问
浏览器向缓存/代理服务器发送所有的HTTP请求
如果所请求对象在缓存中，缓存返回对象
否则，缓存服务器向原始服务器发送HTTP请求，获取对象，然后返回给客户端并保存该对象
缓存既充当客户端，也充当服务器
一般由ISP(Internet服务提供商)架设
Web缓存示例
条件性GET方法
目标：
如果缓存有最新的版本，则不需要发送请求对象
缓存：
在HTTP请求消息中声明所持有版本的日期
if-modified-since:
服务器：
如果缓存的版本是最新的，则响应消息中不包含对象
HTTP/1.0 304 Not Modified
3.4.1 - Email应用概述
Email应用的构成组件
①邮件客户端(user agent)
读写Email消息
与服务器交互，收、发Email消息
Outlook、Foxmail、Thunderbird
Web客户端
②邮件服务器
邮箱：存储发给该用户的Email
消息队列(message queue)：存储等待发送的Email
③SMTP协议(Simple Mail Transfer Protocol)
邮件服务器之间传递消息所使用的协议
客户端：发送消息的服务器
服务器：接收消息的服务器
RFC 2821
使用TCP进行email的可靠传输，端口25
传输过程的三个阶段
握手、消息的传输、关闭
命令/响应交互模式
命令(command)：ASCII文本
响应(response)：状态代码和语句
使用持久性连接
要求消息必须由7位ASCII码构成
SMTP服务器利用CRLF.CRLF确定消息的结束
与HTTP对比
HTTP：拉式(pull)
SMTP：推式(push)
都使用命令/响应交互模式
命令和状态代码都是ASCII码
HTTP：每个对象封装在独立的响应消息中
SMTP：多个对象在由多个部分构成的消息中发送
SMTP交互示例
3.4.2 - Email消息格式与POP协议
SMTP：email消息的传输/交换协议
RFC 822：文本消息格式标准
头部行(header)
To
From
Subject
消息体(body)
消息本身
只能是ASCII字符
MIME：多媒体邮件扩展 RFC 2045,2056
通过在邮件头部增加额外的行以声明MIME的内容类型
邮件访问协议
从服务器获取邮件
POP：Post Office Protocol [RFC 1939]
认证/授权(客户机<--->服务器)和下载
①认证过程
客户端命令
User：声明用户名
Pass：声明密码
服务器响应
+OK
-ERR
②事务阶段
List：列出消息数量
Retr：用编号获取消息
Dele：删除消息
Quit
“下载并删除”模式
用户如果换了客户端软件，无法重读该邮件
“下载并保存”模式
不同客户端都可以保留消息的拷贝
POP3是无状态的
IMAP：Internet Mail Access Protocol [RFC 1730]
更多功能、更加复杂、能够操纵服务器上存储的消息
所有消息统一保存在一个地方：服务器
允许用户利用文件夹组织消息
IMAP支持跨会话(Session)的用户状态
文件夹的名字
文件夹与消息ID之间的映射等
HTTP：163、QQ等
3.5.1 - DNS概述
DNS：Domain Name System
解决Internet上主机/路由器的识别问题
IP地址、域名
Q：域名和IP地址之间如何映射？
域名解析系统DNS
多层命名服务器构成的分布式数据库
应用层协议：完成名字的解析
Internet核心功能，用应用层协议实现
网络边界复杂
DNS服务
域名向IP地址的翻译
主机别名
邮件服务器别名
负载均衡：Web服务器
Q：为什么不使用集中式的DNS？
单点失败问题
流量问题
距离问题
维护性问题
分布式层次式数据库
客户端想要查询www.amazon.com的IP
客户端查询根服务器，找到com域名解析服务器
客户端查询com域名解析服务器，找到amazon.com域名解析服务器
客户端查询amazon.com域名解析服务器，获得www.amazon.com的IP地址
DNS根域名服务器
本地域名解析服务器无法解析域名时，访问根域名服务器
根域名服务器
如果不知道映射，访问权威域名服务器
获得映射
向本地域名服务器返回映射
TLD和权威域名解析服务器
顶级域名服务器(TLD，top-level domain)
负责com，org，net，edu等顶级域名和国家顶级域名，例如cn，uk，fr等
Network Solutions维护com顶级域名服务器
Educause维护edu顶级域名服务器
权威(Authoritative)域名服务器
组织的域名解析服务器，提供组织内部服务器的解析服务
组织负责维护
服务提供商负责维护
本地域名解析服务器
不严格属于层级体系
每个ISP有一个本地域名服务器
默认域名解析服务器
当主机进行DNS查询时，查询被发送到本地域名服务器
作为代理(proxy)，将查询转发给(层级式)域名解析服务器系统
DNS查询示例
Cis.poly.edu的主机想获得gaia.cs.umass.edu的IP地址
迭代查询
被查询服务器返回域名解析服务器的名字
“我不认识这个域名，但你可以问这个服务器”
递归查询
将域名解析的任务交给所联系的服务器
DNS记录缓存和更新
只要域名解析服务器获得域名——IP映射，即缓存这一映射
一段时间后，缓存条目失效(删除)
本地域名服务器一般会缓存顶级域名服务器的映射，因此根域名服务器不经常被访问
记录的更新/通知机制
RFC 2136
Dynamic Updates in the Domain Name System(DNS UPDATE)
3.5.2 - DNS记录和消息
DNS记录
资源记录(RR，resource，records)
RR format：(name，value，type，ttl)
Type=A
Name：主机域名
Value：IP地址
Type=NS
Name：域(edu.cn)
Value：该域权威域名解析服务器的主机域名
Type=CNAME
Name：某一真实域名的别名
Value：真实域名
Type=MX
Value是与name相对应的邮件服务器
DNS协议与消息
DNS协议
查询(query)和回复(reply)消息
消息格式相同
消息头部
Identification：16位查询编号，回复使用相同的编号
flags：查询或回复、期望递归、递归可用、权威回答
Q：如何注册域名？
在域名管理机构注册域名
向域名管理机构提供你的权威域名解析服务器的名字和IP地址
域名管理机构向com顶级域名解析服务器中插入两条记录
在权威域名解析服务器中为www.networkuptopia.com加入TypeA记录，为networkutopia.com加入TypeMX记录
