网络应用的体系结构

客户机/服务器结构（C/S）

服务器
- 永久性访问地址/域名
- 不间断提供服务
- 利用大量服务器实现可扩展性
客户机
- 与服务器通信，使用服务器提供的功能
- 间歇性接入网络
- 可以使用动态IP
- 不会与其它客户机直接交互

点对点结构（P2P）

没有永久在线的服务器
任意端系统之间可以直接通讯
间歇性接入网络
节点可能改变IP地址

优点：高度可伸缩

缺点：难于管理

混合结构（Hybird）

Napster

文件传输用P2P结构
文件搜索采用C/S结构——集中式

网络应用进程通信

进程

同一主机上运行的进程之间：

进程舰通信机制
操作系统提供

不同主机上运行的进程舰通信：

消息交换

客户机进程：发起通信的进程

服务器进程：等待通信请求的进程

套接字

进程间利用socket发送/接收消息
socket是传输基础设施向进程提供的API

如何寻址

不同主机上的进程舰通信，每个进程都必须有标识符

我们通过IP地址寻址主机，但同一主机上可能同时有多个进程需要通信，需要为主机上每个需要通信的进程分配一个端口号，通过IP地址+端口号作为进程的标识

域名解析系统DNS

概述

Domain Name System

多层命名服务器构成的分布式数据库
应用层协议：完成名字的解析
- 提供Internet核心功能，用应用层协议实现
- 网络边界复杂

解决Internet上主机/路由器的识别问题：互联网中的主机以IP地址为唯一标识符，IP本身是数字，不利于人使用，日常使用的是域名。DNS能够将域名解析为IP地址

DNS服务

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

负载均衡就是分摊到多个操作单元上进行执行

为什么不采用集中式的DNS

单点失败问题，如果采用集中式而DNS出现问题会使整个网络瘫痪

流量问题

距离问题

维护性问题

DNS采用分布式层次式数据库

客户端想要查询www.amazon.com的IP

客户端查询根服务器，找到com域名解析服务器

客户端查询con域名解析服务器，找到amazon.com域名解析服务器

客户端查询amazon.com域名解析服务器，获得www.amazon.com的IP地址

DNS域名服务器

根域名服务器

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

顶级域名服务器（TLD）负责com，org，net，edu等顶级域名和国家级域名，例如cn，uk，fr等

由一些公司来维护

权威域名服务器：组织的域名解析服务器，提供组织内部服务器的解析服务

组织负责维护
服务提供商负责维护

本地域名解析服务器

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

迭代查询：

递归查询：

DNS记录缓存和更新

只要域名解析服务器获得域名—IP映射，即缓存这一映射，一段时间过后缓存条目失效（删除），本地域名服务器一般会缓存顶级域名服务器的映射，因此根域名服务器不经常被访问

DNS记录和消息格式

记录

资源记录（resource records）

Type=A
- name：主机域名
- value：IP地址
Type=NS
- name：域
- value：该域权威域名解析服务器的主机域名
Type=CNAME
- name：某一真是域名的别名
- value：真实域名
Type=MX
- value是与name相对应的邮件服务器

消息格式

DNS协议是查询和恢复协议，消息格式相同

identification：16位查询编号，回复使用相同的编号
flags
- 查询或恢复
- 期望递归
- 递归可用
- 权威回答

DNS占用53号端口，同时使用TCP和UDP协议。**DNS区域传输的时候使用TCP协议：辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送使用TCP而不是UDP，因为数据同步传送的数据量比一个请求应答的数据量要多得多。域名解析时使用UDP协议**：客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。不用经过三次握手，这样DNS服务器负载更低，响应更快。理论上说，客户端也可以指定向DNS服务器查询时用TCP，但事实上，很多DNS服务器进行配置的时候，仅支持UDP查询包。

如何注册域名

应用层协议概述

简介

公开的协议
- 由RFC定义
- 允许互相操作
- HTTP，SMTP ······
私有的协议
- 多数P2P文件共享应用

内容

消息的类型
- 请求消息
- 响应消息
语法格式
语义
规则

对传输层服务的需求

数据丢失/可靠性
时间/延迟
带宽

Internet提供的传输服务

TCP服务
- 面向连接
- 可靠传输
- 流量控制
- 拥塞控制
- 不提供时延服务、最小带宽保障
UDP服务
- 无连接
- 不可靠数据传输

文件传送协议

FTP与TFTP都是复制整个文件类的协议，即若要存取一个文件，就必须先获得一个本地的文件副本。如果要修改文件，只能对文件的副本进行修改，然后再将修改后的文件副本传回到原节点。另一大类是联机访问，联机访问意味着允许多个程序同时对一个文件进行存取。和数据库系统的不同之处是用户不需要调用一个特殊的客户进程，而是由操作系统提供对远地共享文件进行访问的服务，就如同对本地文件的访问一样。这就使用户可以用远地文件作为输入和输出来运行任何应用程序，而操作系统中的文件系统则提供对共享文件的透明存取。

FTP协议

FTP基于TCP，主要功能是减少或消除在不同操作系统下的处理文件的不兼容性

FTP使用C/S，一个FTP服务器可同时为多个客户进程提供服务。FTP
的服务器进程由两大部分组成：一个主进程，负责接受新的请求；另外有若干个从属进程，负责处理单个请求。

主进程的工作步骤：

打开端口21，使客户进程能够连接上
等待客户进程发出连接请求
启动从属进程处理客户进程发来的请求。从属进程对客户进程的请求处理完毕后即终止，但从属进程在运行期间根据需要还可能创建其他一些子进程
回到等待状态，继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发进行的

当客户进程向服务器进程发出建立连接请求时，要寻找连接服务器进程的熟知端口21,同时还要告诉服务器进程自己的另一个端口号码，用于建立数据传送连接。接着，服务器进程用自己传送数据的熟知端口20 与客户进程所提供的端口号建立数据传送连接

（为了简单起见，主进程没有画）

在进行文件传输时， FTP 的客户和服务器之间要建立两个并行的TCP 连接：“控制连接”和“数据连接＂。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用千传
输文件的是“数据连接＂。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。数据传送进程实际完成文件的传送，在传送完毕后关闭“数据传送连接”并结束运行。由于FTP 使用了一个分离的控制连接，因此FTP 的控制信息是带外(out of band)传送的

TFTP协议

TFTP也使用C/S模式，使用UDP。因此TFTP 需要有自己的差错改
正措施。TFTP 只支持文件传输而不支持交互。TFTP 没有一个庞大的命令集，没有列目录的功能，也不能对用户进行身份鉴别。

特点：

每次传送的数据报文中有512 字节的数据，但最后一次可不足512 字节。
数据报文按序编号，从1 开始。
支持ASCII 码或二进制传送。
可对文件进行读或写。
使用很简单的首部。

发送完一个文件块后就等待对方的确认，确认时应指明所确认的块编号。发完数据后在规定时间内收不到确认就要重发数据PDU 。发送确认PDU 的一方若在规定时间内收不到下一个文件块，也要重发确认PDU 。这样就可保证文件的传送不致因某一个数据报的丢失而告失败。
在一开始工作时。TFTP 客户进程发送一个读请求报文或写请求报文给TFTP 服务器进程，其熟知端口号码为69 。TFTP 服务器进程要选择一个新的端口和TFTP 客户进程进行通信。若文件长度恰好为512 字节的整数倍，则在文件传送完毕后，还必须在最后发送一个只
含首部而无数据的数据报文。若文件长度不是512 字节的整数倍，则最后传送数据报文中的数据字段一定不满512 字节，这正好可作为文件结束的标志。

TELNET协议

TELNET 也使用C/S方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程。

HTTP协议

HyperText Transfer Protocol

C/S结构

客户—Browser：请求、接收、展示Web对象
服务器—Web Server：响应客户的请求，发送对象

使用TCP传输服务

服务器在80端口等待客户的请求
浏览器发起到服务器的TCP连接（创建套接字Socket）
服务器接受来自浏览器的TCP连接
浏览器与Web服务器交换HTTP消息
关闭TCP连接

无状态

服务器不维护任何有关客户端过去所发送的请求的信息

有状态的协议更复杂：

需要维护状态

如果客户或服务器失效，会产生状态不一致，解决这种不一致代价高

HTTP连接的两种类型

非持久性连接（Nonpersistent HTTP）

HTTP/1.0使用

每个TCP连接最多允许传输一个对象

RTT（Round Trip Time）

从客户端发送一个很小的数据包到服务器并返回所经历的时间

简单分析响应时间：发送、建立TCP连接需要1个RTT，发送HTTP请求消息到HTTP响应消息的前几个字节到达需要1个RTT，还要加上响应消息中所含的文件传输时间

$Total = 2RTT + 文件发送时间$

非持久性连接每个对象需要2个RTT，操作系统需要为每个TCP连接开销资源（ooverhead），假如浏览器为提高效率打开多个并行的TCP连接以获取网页所需对象，又会给服务器带来很大的负担

持久性连接（Persistent HTTP）

HTTP/1.1使用（带有流水机制的持久性连接）

每个TCP连接允许传输多个对象
发送响应后，服务器保持TCP连接的打开，后续的HTTP消息可以通过这个连接发送

无流水的持久性连接

客户端只有收到前一个响应后才发送新的请求
每个被引用的对象耗时1个RTT

带有流水机制的持久性连接

客户端只要遇到一个应用对象就尽快发出请求
理想情况下，收到所有的应用对象只需要耗时约1个RTT

HTTP消息

请求消息

通用格式

上传输入的方法：

POST方法：在Entity Body中上传客户端的输入

URL方法：使用GET方法在request行的URL字段中上传，https://www.bilibili.com/video/BV1Up411Z7hC?p=23&spm_id_from=pageDriver中？后面的部分，以键值对的形式传输name=value

HTTP/1.0方法类型：

GET

POST

HEAD：请Server不要将所请求的对象放入响应消息中

HTTP/1.1：

GET、POST、HEAD

PUT：将消息体中的文件上川岛URL字段所指定的路径

DELETE：删除URL字段所指定的文件

响应消息

Date：Web服务器生成消息的时间

状态：

1xx 表示通知信息，如请求收到了或正在进行处理。
2xx 表示成功，如接受或知道了。
3xx 表示重定向，如要完成请求还必须采取进一步的行动。
4xx 表示客户的差错，如请求中有错误的语法或不能完成。
5xx 表示服务器的差错，如服务器失效无法完成请求。

Cookie技术

HTTP协议是无状态协议，但在许多情况下需要服务器掌握客户端的状态，需要引入Cookie技术

Cookie技术是某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据

Cookie组件

HTTP响应消息的cookie头部行
HTTP请求消息的cookie头部行
保存在客户端主机上的cookie文件，由浏览器管理
Web服务器端的后台数据库

原理：

作用：

身份认证
购物车
推荐
Web e-mail

Cookie技术存在隐私问题

Web缓存/代理服务器技术

在不访问服务器的前提下满足客户端的HTTP请求

优势：

缩短客户请求的响应时间
减少机构/组织的流量
在大范围内实现有效的内容分发（CDN）

用户设定浏览器通过缓存进行Web访问，浏览器向缓存/代理服务器发送所有的HTTP请求，如果所请求的对象在缓存中，缓存返回对象；否则，缓存服务器向原始服务器发送HTTP请求，获取对象，然后返回给客户端保存该对象。

缓存既充当客户端，也充当服务器，一般由ISP假设

示例：

互联网链路利用率过高

解决方案1：提高互联网接入宽带=10Mbps，但成本过高

解决方案2：（设计思想与cache类似）

使用条件性GET方法来确保缓存/代理服务器中保存的是最新的信息，在HTTP请求消息中声明所持有版本的日期（If-modified-since:<date>），如果缓存的版本是最新的，则响应消息中不包含对象（HTTP/1.0 304 Not Modified），此时只有一个空的响应，占用的带宽是很小的