第二章开始于23/7/16
目录
3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）
DHT（distributed hash table）分布式散列表（结构化）P2P：
2.1 应用层原理
网络应用的体系结构：
客户-服务器模式CS：
服务器为中心，先运行，且始终运行；固定的IP地址和周知的端口号（约定）；客户端IP地址可以变化；可扩展性比较差，达到一定阈值时候处理能力呈断崖式下降
对等模式P2P（peer）：
每个节点既向其他节点请求服务，自身又向其他节点提供服务；但是难以管理（节点上下线）
混合体模式（Napster、即时通信）：
Napster：文件搜索：集中；文件传输：P2P（美国大学生 MP3）
即时通讯：在线监测：集中；用户聊天：P2P（QQ）
进程通信：
同一主机，使用进程间通信机制通信（操作系统）
不同主机，通过交换报文进行通信
P2P模式中虽然是对等体，但是不同的会话中，也存在服务器和客户端的区别
分布式进程通信要解决的问题：
1：进程标识和寻址问题（服务用户）
进程为了接受报文，需要有标识：SAP
1.主机：唯一的32位IP地址
2.采用的传输层协议（TCP、UDP）
3.端口号（port number）
本质上一对主机进程之间的通信由两个端节点构成
2：传输层-应用层提供服务是如何（服务）
位置：层间界面的SAP
形式：应用程序接口API
层间接口要携带的信息：
要传输的报文（对本层而言：SDU）
谁传的：对方应用进程标示：IP+TCP（UDP）端口（相当于给邮政公司卖家地址）
传给谁：对方应用进程标示：对方的IP+TCP（UDP）端口号（买家地址）
传输层实体根据这些信息进行封装
TCP之上的套接字（socket）：
若Socket API每次传输报文携带这么多信息，繁琐易错，不便管理。采用socket整数管理四元组（目标、源的IP、端口），尽量减少穿过层间的信息量，是一个本地上的标示（对方和你的socket不同）。这个整数唯一指定了一个会话，反应了主机之间的会话关系，不必在每个文件发送都指定四元组
UDP socket
UDP特性：每个报文独立传输、前后报文可能给不同的分布式进程
用一个整数代表一个段节点（只代表本地IP和本地UDP端口二元组，不代表会话关系）
使用UDP，传输三个东西：数据本身、UDP socket、对方的IP和UDP端口
3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）
定义应用层协议，编制程序
应用层协议：运行在不同端系统上的应用进程如何相互交换报文（交互过程中和网络相关的部分）
应用协议仅仅是应用的一个组成部分
应用需要传输层提供什么服务？
数据丢失率：有些应用要求100%可靠
延迟
吞吐
安全性
互联网传输层提供的服务：TCP、UDP
TCP：传输控制协议Transmission Control Protocol
特性：可靠且保序的数据传输、流量控制、拥塞控制
UDP：用户数据报协议User Datagram
无连接、不可靠数据传输、无量控制、无拥塞控制
TCP和UDP都不安全，都是明文传输，但是TCL之上应用可以用SSL库进行加密（http/https）
2.2 Web和HTTP
一些术语：
Web页：由一些对象组成
对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
Web页有一个基本的HTML文件，包含若干对象的引用（链接）
通过url（通用资源定位符）对每个对象进行引用
HTTP协议：超文本（文本之间任意指向）传输协议；采用客户端-服务器模式（跑在tcp之上）
访问网站步骤如下：首先拿到base html，画出网页框架。网页中含有一系列链接，把相应的图片拉进去
1.客户发起一个TCP的连接（建立套接字），端口号默认80
2.服务器接受客户的连接
3.相互交互HTTP报文
4.TCP连接关闭
补充：HTTP是无状态的，服务器不维护关于客户的任何信息
维护状态的协议十分复杂：必须维护历史信息、c/s其中一个死机，两者状态不一致、无状态服务器能支持更多客户端
持久和非持久HTTP：
非持久HTTP：
1.最多一个对象在TCP连接上发送
2.下载多个对象需要多个TCP连接
3.HTTP/1.0使用非持久链接
进程步骤：
 |  |
响应时间模型
往返时间RTT（round trip time）：一个小分组从客户端到服务器，再回到客户端的时间（忽略传输时间，但是传播需要时间）
非持久HTTP的缺点：
1.每个对象要两个RTT
2.操作系统必须要为每个TCP链接分配资源
持久HTTP：
1.多个对象可以在一个TCP上传输
2.HTTP/1.1默认使用持久链接
特点：服务器发送响应后仍保持TCP连接；相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送；客户端遇到引用对象时候，就可以尽快发送该对象的请求
流水和非流水模式下的持久HTTP：
非流水模式：
1.客户端只能在收到前一个响应后才能发送新的请求
2.每次引用一个对象花费一个RTT
流水模式：
1.HTTP/1.1的默认模式
2.客户端遇到一个引用对象就立即产生一个请求
3.所有引用对象（小）只花费一个RTT是可能的
两种类型的HTTP报文：请求、响应
HTTP请求报文
提交表单输入
Post方式：网页通常包括表单输入；包含在实体主体中的输入被提交至服务器
URL方式：方法：GET；输入通过请求行URL字段上载
1.0常用的命令：GET\POST\HEAD
1.1常用命令：GET\POST\HEAD\PUT\DELETE
HTTP响应报文
HTTP状态响应码：
200：OK
301：moved permanently
400：bad request
404：not found
505：http version not supported
用户-服务器状态：cookies
大多数主要门户网站使用cookies，用来关联用户的访问行为
4个组成部分：
1.HTTP响应报文有一个cookie的首部行
2.HTTP请求报文有一个cookie的首部行
3.用户端系统中保留一个cookie文件，由用户的浏览器管理
4.Web站点中有一个后端数据库
cookie能带来什么
用户验证 购物车 推荐 用户状态
可能带来隐私问题
Web缓存（代理服务器）
目标：不访问原始服务器，就能满足客户请求
用户设置浏览器：通过缓存访问Web；浏览器讲所有的HTTP请求发给缓存
在缓存中的对象，直接返回；不在的话，缓存请求原始服务器，将对象返回给客户端
缓存既是客户端又是服务器，通常由ISP安装
优势：
降低客户端请求响应时间；
大大减少一个机构内部网络与Internet接入链路上的流量
互联网大量采用缓存，可以使较弱的ICP也能够提供有效内容
2.3 FTP
可以通过FTP客户端上载到服务器或者从服务器下载
是有状态的协议（区别与HTTP无状态，但是通过cookie补丁让其有状态）
FTP服务器：端口号为21
分为控制性连接（控制命令的发送）和数据性连接（数据发送和接受），分别在两个TCP上进行
2.4 EMail
主要组成：用户代理、邮件服务器、简单邮件传输协议SMTP
用户代理：即“邮件阅读器”，用于撰写、编辑、阅读邮件，输入和输出邮件保存在服务器上
邮件服务器：管理和维护发送给用户的邮件，输出报文队列，邮件服务器之间遵守SMTP协议
SMTP协议：
1.使用TCP在客户端和服务器之间传送报文，端口号25
2.直接传输：从发送方服务器到接收方服务器
3.传输的三个阶段：握手、传输报文、关闭
命令/响应交互：命令：ASCII码；响应：状态码和状态信息；
报文必须是7为ASCII码
SMTP使用持久连接
SMTP与HTTP比较：
HTTP：拉pull；SMTP：推push
都是ascii码形式的命令/相应交互/状态码
HTTP：每个对象封装在各自的响应报文中
SMTP：多个对象包含在一个报文中
POP3与IMAP
针对发邮件最后一个环节而言，收件方从邮件服务器拉回邮件的协议
pop3：分为下载并删除和下载并保留两种模式；会话中无状态
IMAP：运行用户远程在服务器建立组织目录；会话保留用户状态
2.5 DNS
DNS：domain name system，域名解析系统
DNS的必要性：
IP地址标识主机、路由器，但是IP地址不好记，不便于使用
DNS主要功能是：让域名转换为二进制的网络地址（IP）
DNS要解决的问题：
1.如何命名设备：层次化命名以解决同名问题
2.如何完成名字到IP地址的转换（解析）：分布式维护和解析
3.如何维护：增加或者删除一个域，需要在域名系统里做哪些工作
DNS的主要思路：
1.分层的、基于域的命名机制
2.若干分布式的数据库完成名字到IP地址的转换
3.运行在UDP之上，端口号为53的应用
4.核心的Internet功能，但以应用层协议实现（核心功能，但是在端系统实现）
DNS的主要目的：
1.实现主机名-IP地址的转换
2.其他目的：
主机别名-规范名字的转换（规范名字具体到某个机柜，别名是某一块服务器的总称；规范名字为了便于管理，别名是为了方便用户访问）
邮件服务器别名-邮件服务器正规名字转换
负载均衡（同一个别名，选择合理的服务器刀片向用户提供服务）
DNS名字空间：
域名结构：采用层次树状结构命名法
顶级域：通用：.edu、.com（国际化公司）、.gov、.net、.org等等
国家：.cn、.us、.jp等等
每个域下面包括若干子域，二级域下面还有三级域；类似树状图，叶子是主机
例如：www.ustc.edu.cn
其中互联网的根，一共有13个（中国没有，但是有镜像）
域名：
概念区分：域的域名和主机的域名：
域的域名是从中间开始，到树根，如ustc.edu.cn
主机的域名是从树叶开始，到树根，如auto.ustc.edu.cn
域名的管理：
一个域，管理其下的的子域
创建一个新域，必须征得它所属域的同意
域与物理网络无关：遵从组织界限，而非物理网络
域的划分是逻辑的，网络的划分是物理的
DNS名字服务器
如果只采用一个名字服务器，可靠性、扩展性、维护性都比较差；因此采用区域划分的模式
区域Zone：
区域的划分由区域管理者决定
将DNS名字空间划分互不相交的区域，每个区域都是树的一部分
名字服务器：每个区域都有一个权威名字服务器（用来维护该区域内名字-IP的对应关系），它允许被放置在区域以外，以保证可靠性
TLD服务器：即顶级域服务器，负责顶级域名和所有国家级的顶级域名
资源记录：
用于维护 域名-IP的映射关系；存在名字服务器的分布式数据库中
TTL：time to leave；如果是权威记录，该字段无限大；如果是缓冲记录，该字段为有限值
缓存：为了提高查找的效率
一旦名字服务器学到一个映射，就会缓存起来；
根服务器通常在本地服务器中缓存着；
可能存在问题：情况如变化，缓存结果和权威资源记录可能不一样
解决方案：TTL默认两天
删除：为了提高准确率
上层需要知道子域的名字服务器和IP地址
DNS大致工作过程：
应用调用 解析器（resolver）
解析器作为客户，向name server发出查询报文（UDP）
name server返回响应报文
本地名字服务器：
每个ISP都有一个本地DNS服务器，称为默认名字服务器
当一个主机发起一个DNS查询时，查询被送到本地DNS服务器
名字解析过程分类：
1.目标名字在本地名字服务器中
1.查询的名字在区域内部
2.缓存
2.本地名字服务器不能解析名字，联系根名字服务器，顺着根-TLD（顶级域服务器）一直找到权威名字服务器
递归查询：
名字解析负担都放在当前联络的名字服务器上；
如www.ustc.edu.cn，先访问cn，再去edu，最后找到权威的科大名字服务器，查询到IP
问题：根服务器的负担太重
解决方法：迭代查询
迭代查询：
根服务器返回的不是查询结果，而是下一个名字服务器的地址
最后由权威名字服务器给出结果
思路：我不知道这个名字，但我告诉你谁会知道
维护问题：新增一个域
在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
在新增子域的名字服务器上运行名字服务器，负责本域名字的解析
2.6 P2P应用
纯P2P架构： 没有（或极少）一直运行的服务器；任意端系统都可以直接通信；利用peer的服务能力；peer节点间歇上网，每次IP地址都有可能变化
如：文件分发（BitTorrent）、流媒体（KanKan）、VoIP
文件分发模式：
C/S模式：
服务器传输：都是由服务器发送给peer，服务器需要上载n个文件拷贝
客户端：每个客户端必须下载一个文件拷贝
P2P模式：
服务器传输：最少需要上载一份拷贝
客户端：每个客户端必须下载一份拷贝；除了服务器可以上载，每个peer也可以上载
但是由于P2P系统具有十分强的动态性，管理问题是主要问题
P2P管理系统：
非结构化P2P：
应用层上逻辑的网，节点和节点之间的边（覆盖网）是随意的、随机的
集中化目录：
参考Napster，美国大学一个mp3分发系统；
对等方连接时候，它告知中心服务器IP地址和查询内容；随后中心服务器告诉它有该内容的peer节点，对等方从该节点处请求文件
文件传输是分散的，内容定位是高度集中的
存在问题： 单点故障：目录服务器挂了，系统全完；服务器有瓶颈；版权问题
完全分布式：
如Guntella；全分布式，没有中心服务器；开放文件共享协议
查询时候，向覆盖网周围的邻居发起查询（通常十个左右），如果没查到，邻居向邻居的邻居发起查询（泛洪模式）；查询到后，反方向返回命中报文
存在问题：同一节点可能重复查询；主要困难是预先建立起泛洪的覆盖网络；节点退出时也需要告知邻居
理论上很优秀，实际过程出现很多技术问题
混合体模式：
每个节点要么是组员，要么是组长
组长和组长之间，按照分布式，组长和组员之间按照集中式
组长跟踪其所有组员的内容（组长在组内相当于目录服务器）；组长与其他组长联系
DHT（distributed hash table）分布式散列表（结构化）P2P：
维护树状、环状有序的拓扑网络结构；每个节点都有ID，按照大小在拓扑结构中排序，以确定指向关系（简单了解）
2.7 CDN
Content Delivery Network，内容分发网络
常用于视频流媒体传输
视频大小主要由帧率和码率决定，帧率表示一秒图片个数，码率是每一张图片的清晰度
DASH：动态自适应解析
服务器：
1.将视频文件分成多个块
2.每个块独立存储，编码于不同码率（通常8-10种）
3.告示文件（manifest file）：提供不同块的URL
客户端：
1.先获取告示文件（从原服务器处获得）
2.周期性测量服务器到客户端的带宽
3.查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围（码率取决于带宽）
客户端自适应决定：
什么时候请求块、请求何种编码速率的块、去哪里请求块（高带宽或者离自己近的服务器）
挑战：服务器如何向百万级别的用户同时提供流化视频服务？
方法：单个大型超级服务中心：maga server
问题：服务器到客户端跳数较多，瓶颈链路限制带宽、效率低（流量重复）、单点故障、不可扩展
解决方法：采用CDN（应用层），全网部署缓存节点，存储服务内容，就近为用户服务（内容加速服务）
CDN的两种方式：
1.enter deep（深入群众）
将CDN服务器深入到许多接入网，因为接近用户，效果更好但是数量多，管理、维护难
2.bring home（卡住关键少数位置）
部署在少数关键位置，如将服务器簇放在POP附近，采用租用线路将服务器簇连接在一起
如何让用户知道从哪里访问：
方法1：通过manifest文件
方法2：通过域名解析的重定向
2.8 TCP套接字编程
一些概念
socket编程：应用进程使用传输层提供的服务，才能够交换报文，实现应用协议
TCP/IP：应用进程使用socket api访问传输服务
地点：界面上的SAP
socket：分布式应用进程之间的门，传输层协议提供端到端服务接口
两种传输层服务的socket类型：TCP（可靠的字节流服务）、UDP（不可靠的数据包服务）
套接字：应用进程与端到端传输协议（TCP或UDP）之间的门户
TCP服务：一个应用进程向另一个进程可靠的传输字节流
工作过程：
服务器先运行，等待连接建立
1.服务器进程必须处于运行状态
创建欢迎socket；和本地端口捆绑；在欢迎socket上阻塞式等待接受用户连接
客户端主动和服务器建立建立
2.创建客户端本地套接字（隐式捆绑到本地端口）
指定服务器进程的IP地址和端口号，与服务器进程连接
3.当客户端连接请求到来时
服务器接收来自客户端的请求，解除阻塞式等待，返回一个新的socket（不同于欢迎socket），与客户端进行通信
允许服务器与多个客户端通信
使用源IP和源端口来区分不同的客户端
C/S模式的应用样例：
1.客户端从标准输入装置读取一串字符，发送给服务器
2.服务器从socket读取字符
3.服务器将字符转换为大写，然后返回客户端
4.客户端从socket中读取一行字符，然后打印出来
2.9 UDP套接字编程
UDP：客户端和服务器之间没有连接，传送的数据可能乱序也可能丢失（不可靠的传输服务）
没有握手，发送端在每一个报文中明确指定目标的IP地址和端口号
服务器必须从收到的分组中提取出发送端的IP地址和端口号
1970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
