计算机网络原理 笔记 2

网络原理 应用层

应用层协议原理

APP是运行在端系统上，而不是诸如路由器等的网络核心设备上，因为网络核心设备基本只在网络层及以下的地方起作用

网络应用程序体系结构

两种主流体系结构：

• 客户-服务器体系
• 对等体系

客户-服务器

服务器：一个总是打开的主机，处理来自其他客户主机的请求，例如Web浏览器等
客户之间不会直接通信，而是需要经过服务器中转，并且服务器具有固定的地址（称之为IP地址）
数据中心：为了防止单一的服务器主机无法处理大量请求，部分服务商会部署数据中心，其中配备有大量主机，用于模拟服务器

对等

端系统主机之间直接通信，无需经过服务器中转，一些流量密集型应用采用的是P2P结构
P2P结构具有自扩展性，每个对等方通过请求文件产生工作负载，但是其也可以通过向其他对等方分发文件提升系统服务能力

进程通信

这里讨论的是不同端系统之间进程的通信，其通过交换报文相互通信

客户与服务器进程

对于任意一对进行通信的进程，在会话开始时等待联系的一方为服务器，发起通信的一方为客户，无论其采用的体系结构是可恶-服务器或P2P

进程与计算机网络的接口

进程间通过套接字（也被称为API）接口进行报文的发送和接收，套接字是应用层与运输层的接口，开发者可以选择运输层协议，并借助该协议进行开发

进程寻址

接收进程的地址包括：

• 主机地址
• 在目标主机中指定接收进程的标识符

主机由其IP地址确定，是一个$32bit$的量并且可以唯一标识一个主机，指定接收进程由目的地端口号保证，一个端口号只能接收一个进程的信息

可供应用程序使用的运输服务

一个运输层协议所能提供的服务分为四类：

• 可靠数据传输
• 吞吐量
• 定时
• 安全性

可靠数据传输

由于丢包、数据损坏等情况，数据可能发生丢失，因此，我们需要一种使得发送的数据一定可以正确、完全的交付给另一方的协议，称之为可靠数据运输
部分应用（例如音视频、原神等）允许一定量的数据丢失，这被称为容忍丢失的应用

吞吐量

可用吞吐量：两个进程之间发送比特的速率，由于其他会话会共享带宽，因此可用吞吐量会随着时间波动
因此，一部分协议保证了应用可用吞吐量的下界，这对于一些带宽敏感应用（具有特定的吞吐量要求）是很有必要的，与之相对，弹性应用不需要限制吞吐量

定时

定时协议可以保证时延的上界，例如可以确保发送的比特一定会在$100ms$内到达接收方，广泛应用于实时交互的应用中

安全性

协议能够提供数据的加密、解密，以保证只有进程可以直接观察到发送的的数据，同时还有数据完整性鉴别、端点鉴别等

因特网提供的运输服务

包括TCP与UDP两种

TCP

包括面向连接服务与可靠传输服务

• 面向连接服务：应用岑报文开始流动之前，TCP让客户服务器进行握手（交换运输层控制信息），握手结束后即建立了一条TCP连接，双方进程可以在该连接上进行报文的收发，结束发送至后必须拆除连接
• 可靠传输服务：同上

同时，TCP拥有拥塞控制机制，可以在适当时机抑制发送进程，并且限制每个连接使之公平共享带宽
由于其没有加密机制，因此有基于TCP的SSL，可以提供关键的安全性服务,SSL不是一种新的因特网运输协议

UDP

轻量级，仅提供最小服务，没有握手机制、拥塞控制机制、可靠传输等

因特网运输协议所不提供的服务

没有包括定时和吞吐量等，这些操作被巧妙的设计所尽量保障，但是在一些极端情况下仍然会被限制

应用层协议

应用层协议定义了进程之间传递报文的格式，如：

• 交换报文的类型
• 各种报文类型的语法
• 报文中字段的语义
• 确定进程何时、如何发送报文
• 对报文进行响应的规则

应用层协议是网络应用的重要组成部分

Web & HTTP

HTTP概况

Web页面有对象组成，可以通过URL（由主机名+路径名构成）寻址访问Web服务器实现了HTTP服务器端，用于存储Web对象，基本通信方式如下：

HTTP是一个无状态协议，也即其不会存储有关客户的任何信息（例如短时间内连续请求信息，则服务器每次会重新发送）

持续连接与非持续连接

客户与服务器之间需要进行一系列请求，并且两个请求之间的间隔可能是随机的或是周期性的，所以不同请求可以使用不同的TCP连接或者同一个TCP连接，被分为非持续连接和持续连接两种，HTTP1.1及更高版本默认情况下使用的是持续连接，HTTP1.0采用的是非持续连接，而HTTP2.0版本更新了队列机制，不强制要求FCFS，而是可以让用户自己定义优先级

非持续连接

每一个对象需要一次TCP连接
定义往返时间：一个短分组从客户到服务器再返回客户的时间，如下：

上图中设计三次握手过程，其中前两个过程消耗了一个RTT，最后一次握手以及发送HTML文件这个响应操作消耗了一个RTT，因此总响应时间为$2*\text{RTT} +$传输文件时间

持续连接

非持续连接需要为每个请求的对象建立并维护一个连接，需要大量TCP缓冲区与变量，并且会导致相对更高的时延
持续连接即建立连接后，即使完成请求也不关闭，因此不同请求可以使用这一条连接进行，避免了反复建立连接，当连接在一定时间内没有被使用时才会被关闭

HTTP 报文格式

分为请求报文与响应报文两种

HTTP请求报文

第一行称作请求行，其后续都称为首部行

• 请求行分为方法、URL、HTTP版本三个字段
• 主机的信息提供给Web代理高速缓存
• 第三行用于关闭持续连接
• 第四行用于指明用户代理，即浏览器类型
• 第五行用于指明需要得到的语言版本

通用格式如下：

实体体在GET方法中为空，在POST等方法中包含信息，例如用户在搜索框内的输入信息等，而需要给服务器提供信息的操作不一定是POST操作，例如可以将信息附在URL中然后使用GET操作

HTTP响应报文

比请求报文多了一个实体体的部分，同时第一行称作状态行

• 状态行包括协议版本，状态码与状态信息三部分
• 第二行与请求报文相同
• 第三行表示了发送响应报文的时间
• 第四行表示服务器
• 第五行表示发送的对象被最后修改的时间，对于缓存来说非常重要
• 第六行表示发送对象的字节数
• 第七行表示对象类型

通用格式如下：

用户与服务器的交互：cookie

允许站点对用户进行跟踪，技术有如下四个组件：

• 响应报文中的cookie首部行
• 请求报文中的cookie首部行
• 端系统中的cookie文件
• 后端数据库
  用户首次访问一个站点的时候，服务器会为其建立一个
  cookie用来唯一标识这个客户，并将其发送给浏览器，后续会话中浏览器与服务器之间可以通过cookie来确定用户信息
  

Web缓存

又称代理服务器，可以理解为是客户和初始服务器之间的一个代理，可以提升用户的访问速度，用户可以往缓存中发请求，如果缓存中拥有的话则可以直接返回响应，反之则需要在初始服务器中进行寻找，因此可以有效的降低时延并且减少供应商成本

条件GET方法

用于确定缓存中的数据是最新的方法，具体来说，缓存数据会存储数据的最近修改时间，因此，如果用户在请求报文中增加了行

1

If-modified-since: xxx

则缓存与代理之间会经过一次通信确定文件在xxx时间之后是否有被修改过，这种报文称之为条件GET请求

电子邮件 & SMTP

SMTP

步骤如下：

1. 发送方代理将报文发送给自身邮件服务器，并存储在报文队列中
2. 发送方服务器SMTP与接收方服务器SMTP直接建立TCP连接
3. 握手结束后，通过该连接发送报文
4. 接收方服务器接收报文，并将其放入接收方的邮箱中

SMTP可以通过可靠数据传输将邮件完整的发送到接收方，并且其采用的是直接连接的方式
SMTP有一条特殊规则是：只包含$n$个句点符号的单行，表示的是$n-1$个句点，因为单个句点是指示报文结束，对话形式如下图：

由用户端发送的、全大写的字符串代表特殊命令，其含义可以直接翻译理解

与HTTP比较

同：

• 都用于在两台主机之间传送文件
• 都是持续连接

异：

• HTTP是拉协议，即此时连接由接收方向发送方发起；TCP是推协议，即此时连接由发送方向接收方发起
• SMTP要求发送数据必须编码为ASCII字符，但是HTTP没有限制
• 对于多对象（例如包含图片、视频、音频等）文档，HTTP将每个对象分别封装，但是SMTP将其全部封装在一起

报文格式

使用的是RFC 5322定义，其中的From, To两行是必选的

访问协议

由于SMTP是一个推协议，因此用户是无法通过自己设备上的代理向服务器请求邮件的，因此我们没有办法实时读取到存储在服务器中的邮件，为了解决这个问题引入了邮件访问协议，如POP3, IMAP, HTTP

POP3

由RFC 1939定义，极其简单，首先用户向服务器提出建立TCP连接，建立之后依次分为三个阶段：特许，事务处理与更新

• 鉴权（特许）阶段：客户端使用命令user 与pass 鉴别身份信息（明文发送）
• 事务处理：客户端允许使用list, retr , dele 三条命令，分别代表：列出所有邮件长度，接收id号邮件，删除id邮件
• 更新：当用户使用了quit命令之后进入更新阶段，服务器删除被标记的斑纹，POP3会话结束

每次客户端发来一个命令之后，服务端的回复是+OK 或-ERR

IMAP

允许用户可以在远程服务器上操作邮件，包括创建文件夹、移动邮件、在远程文件夹上查询邮件等，更加方便，并且允许用户获取报文的部分，以避免大量信息造成网络负担过重

邮件中的HTTP

在代理和服务器直接发送信息的时候采用HTTP协议，在服务器之间传输的时候采用SMTP，也即将浏览器当成用户代理

DNS：因特网的目录

用于转换主机在主机名与IP地址之间的一种系统，主机名方便人类记忆，而IP更容易被计算机处理

DNS的服务

DNS是指：

• 由分层的DNS服务器实现的分布式数据库
• 使主机能够查询分布式数据库的应用层协议

DNS服务器运行BIND软件，协议运行在UDP之上，使用53号端口
DNS通常是一种被其他应用层协议使用的应用程协议，用于将它们请求报文中的主机名转换为IP地址，而并不常与用户直接通信
除了转换外还有其他服务：

• 主机别名，部分主机拥有多个主机名，而其中有一个成为规范主机名，而别名的存在是为了更方便的记忆，因此DNS可以识别别名
• 邮件服务器别名：电子邮件的后缀可以是别名，由邮件app调用DNS进行处理
• 负载分配：部分站点有多个服务器，也即一个规范主机名会对应多个IP地址，因此DNS用于调配这些地址之间的负载，用户向这个主机名发送请求等效于向当前队列中最前方的IP发送请求

工作机理概述

从用户来看，DNS是一个提供转换服务的黑盒，但是其内部是由大量DNS服务器及应用层协议组成的
简单设计：全球仅有一台DNS服务器，会有诸多问题

• 单点故障导致全球故障
• 通信容量巨大
• 远距离的集中式数据库导致高时延
• 维护复杂

因此采用了分布式的设计方案

分布式层次数据库

从上到下依次为：根服务器，顶级域服务器与权威服务器，访问一个主机名的时候从上至下访问服务器，从右至左依次匹配

• 根服务器：全球有$400$多个
• 顶级域：例如.com, .edu等
• 权威：每个公共可访问主机的组织需要提供公共可访问的DNS记录，这些记录被记录在权威服务器中
• 本地DNS服务器：属于ISP，起到的是代理、加速作用

每次向服务器发送请求是，得到的是下一级的服务器IP地址列表，权威服务器将会返回查询地址的IP，同时，权威服务器有可能需要用过中间服务器再次分层，也即权威->中间->权威
查询方式分为递归查询与迭代查询，上图中，请求主机与本地服务器之间为递归查询，其与全部为迭代查询，即迭代查询是接受请求后直接返回，而递归查询是接受请求后向其他服务器查询之后再返回给请求方

DNS缓存

为了改善时延并且减少报文数量，DNS服务器可以将请求/回答信息环城存在本地存储器中，以便更快返回，由于IP对应关系不永久，因此缓存信息会被定时清除

DNS记录与报文

DNS服务器存储了资源记录，其提供了主机名到IP地址的映射，形式为：

$$\text{(Name, Value, Type, TTL)}$$

其中TTL代表的是应当删除的时间，其余三个的对应如下：

• Type = A，则Name是主机名，Value是对应的IP地址
• Type = NS，则Name是一个域，Value是域中可获取主机IP的权威服务器主机名
• Type = CNAME，则Name是一个别名，Value是对应的规范主机名
• Type = MX，则Name是一个别名，Value是对应邮件服务器的规范主机名

报文

• 前$12$字节称为首部区域，标识符用于匹配，标志用于提供一些额外信息
• 问题区域包含查询信息，包括主机名、问题类型（查规范主机名还是邮件服务器等）
• 回答区域包含了资源记录，可以包含多条

在DNS数据库中插入

略

P2P文件分发

对等方直接通信，减少对服务器的依赖

P2P体系的可扩展性

• $F$：文件长度
• $N$：对等方数量
• $u_s$：服务器接入链路的上传速率
• $u_i$：第$i$个对等方接入链路的上传速率
• $d_i$：第$i$个对等方接入链路的下载速率

考虑在客户-服务端与P2P两种模式下所需要的分发时间

• 客户-服务器体系

  $$D_{cs} \geq max(\frac{NF}{u_s}, \frac{F}{d_{min}})$$

• P2P

  $$D_{P2P} \geq max(\frac{F}{u_s}, \frac{F}{d_{min}}, \frac{NF}{u_s + \sum u_i})$$

当对等方数量非常多时，采用P2P将会具有很好的效果（增长缓慢）

BitTorrent

一种P2P协议，其中，参与特定文件分发的所有对等方集合被称为一个洪流，每个洪流有一个基础设施节点称为追踪器，其中记录并追踪了每个对等方及其是否离开了洪流
新对等方向追踪器请求对等方列表，并尝试向所有对等方建立TCP连接，成功建立连接之后称为邻近对等方，并向所有的邻近对等方请求未含有的块
请求块的方法是最稀缺优先，请求其邻居中所含副本最少的块，以便尽快达到块数量的均衡
给其他对等方上传数据时，每隔一段时间选择向其发送数据最快的$4$个对等方，其集合成为疏通，并向它们上传块，同时会每隔一段时间随机寻找新对等方进行对换，也即最多会向$5$个对等方上传块，这种激励机制成为一报还一报

视频流和CDN

因特网视频

比特率决定视频质量以及对传输所需要的流量

HTTP流和DASH

常规的HTTP流为对视频进行编码后使用常规方法进行发送，在用户端有两种方式，一种为缓存字节数超过一定数目就开始播放，另一种为流式视频，即按帧缓存，从接受视频开始即播放
DASH被称为经HTTP的动态适应性流，其将视频编码为不同版本，随着带宽的变化选择不同版本，服务器中存在告示文件，提供不同版本的URL与分辨率

CDN

分布在多个地理位置上的服务器，用于帮助世界各地的用户尽快获取内容
服务器安置原则为：

• 深入：遍历接入ISP来深入其中，靠近端用户
• 邀请做客：在关键位置部署少量大集群，邀请ISP做客

CDN采用拉策略，并非将视频存储在每一个集群中，当集群缺少这个视频时则会向其他集群检索并缓存

CDN操作