【计算机网络】应用层

更新于 2023-02-17 分类于计算机网络阅读次数：本文字数： 7.9k 阅读时长 ≈ 7 分钟

计算机网络：自顶向下方法（第五版&第七版）学习笔记，第二章应用层

逻辑：原理-五种重要应用

应用层原理

本节逻辑：网络应用程序结构-应用层协议简述-通信

网络应用程序结构

只运行在主机上
两种主流应用程序体系结构（application architecture）：客户-服务器体系结构、P2P体系结构

客户-服务器体系结构（client-server architecture）

客户之间不直接通信
客户向服务器发送请求，服务器向客户发送所请求的对象进行响应
服务器地址（IP）固定、公开
处理大量请求：拥有大量服务器的数据中心（data center）
例：Web、FTP、Telnet、电子邮件

P2P体系结构（P2P architecture）

对服务器有极小的（甚至没有）依赖，第七版中文对极小那里翻译感觉有问题，另外，第七版中文说是位于数据中心的专用服务器，第五版英文写的是infrastructure server
主机之间间断连接，直接通信，被称为对等方，一般不是服务提供商
自扩展性（self-scalability）：每个对等方请求产生工作负载，但分发文件增加服务能力，高度非集中式结构，有安全性、性能、可靠性问题
例：文件共享、对等方协助下载加速器、因特网电话视频会议

混合CS和P2P的体系结构

常见于即时讯息应用，服务器跟踪用户IP地址，主机之间的信息传递不经过服务器

应用层协议简述

网络应用程序发送的信息：报文
应用层协议（application-layer protocol）：定义运行在不同端系统上的应用程序进程如何相互传递报文
- 报文类型（请求、响应）
- 报文类型的语法（字段及其描述）
- 字段语义
- 何时发送、如何响应

通信

两个不同端系统上的进程跨越计算机网络交换报文（message） 相互通信

对象：进程

客户&服务器进程对
P2P：在一个通信会话场景中，发起通信的进程标识为客户，等待联系的为服务器

接口：套接字（socket）

应用程序编程接口（API）
同一台主机内应用层与运输层之间的接口
应用程序开发者控制套接字在应用层端的一切但不能控制运输层
选择运输层协议、设定参数（如需要）
发送端将报文推进socket，运输层协议接收
有唯一标识符，格式决定它的类型（UDP or TCP）

目标：地址

主机地址（因特网中是IP地址）
目的主机中接收进程的标识符（接收套接字）（一般是目的地端口号）

讨论：运输服务

可靠数据传输（reliable data transfer）：确保数据能完全正确到达
- 容忍丢失的应用（loss-tolerant application），如多媒体应用
吞吐量：确保可用吞吐量的下限
- 带宽敏感的应用（bandwidth-sensitive application），如多媒体应用
- 弹性应用（elastic application）
定时：到达接受方的速度，常见于交互式实时应用程序
安全性
因特网提供TCP、UDP协议，考虑安全性升级TCP为SSL
- TCP：面向连接、可靠数据传送、拥塞控制；SSL：安全套接字层（Secure Sockets Layer），在应用层强化TCP
- UDP：轻量级运输协议
因特网无法提供吞吐量和定时的保证

Web&HTTP

Web应用程序和其核心协议HTTP

Web应用

CS体系结构：Web浏览器&Web服务器
Web页面：由对象组成，多由一个HTML基本文件和引用对象组成
对象通过URL引用：存放对象的服务器主机名&对象的路径名
- Uniform Resource Locator：统一资源定位器
- protocol：//server[:port number] /path/file

HTTP

HTTP（HyperText Transfer Protocol）：超文本传输协议
HTTP请求报文&HTTP响应报文
使用TCP运输协议：为了可靠
HTTP是无状态协议（stateless protocol）：服务器不存储任何客户状态信息
识别用户的技术：cookie，初次访问提供用户名等信息，后续不再需要只需浏览器给cookie
- 响应、请求报文中的Cookie: 首部行
- 用户端，浏览器管理cookie文件
- Web站点的数据库

报文格式

首部行（header line）：第一行后的行
实体体（entity body）：在最后，包含了请求对象

请求报文

第一行是请求行（request line），方法字段 URL字段 HTTP版本字段，方法包括GET、POST、HEAD、PUT、DELETE

响应报文

第一行是状态行（status line）：协议版本字段状态码响应状态信息
状态码和响应状态信息举例：200 OK（请求成功），301 Moved Permanently（请求对象永久转移，新URL在Location: 首部行中）

请求与响应报文实例

以上一篇计网为例（F12可查）：

请求：

GET /posts/867943d6/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: Hm_lvt_4153420f060a95b406405cc219f4ce4d=1673612250,1673709999,1675057970,1675241333; Hm_lpvt_4153420f060a95b406405cc219f4ce4d=1675241412
Host: www.lyroch.site
Pragma: no-cache
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36
sec-ch-ua: "Not?A_Brand";v="8", "Chromium";v="108", "Google Chrome";v="108"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"

首部行Host: www.lyroch.site指明对象所在主机，首部行Connection: keep-alive告诉服务器使用持续连接，首部行User-Agent: 指明发送请求的浏览器类型，首部行Accept-Language: 指明浏览器想得到的语言版本，如果没有就会返回服务器默认语言

响应：

HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Wed, 01 Feb 2023 08:52:25 GMT
Content-Type: text/html
Last-Modified: Thu, 29 Dec 2022 15:20:29 GMT
Transfer-Encoding: chunked
Connection: keep-alive
ETag: W/"63adb03d-e9a1"
Content-Encoding: gzip

注意，Date: 是服务器检索对象插入响应报文并发送的时间，Last-Modified: 对象创建和最后修改的日期和时间

往返时间RTT（Round-Trip Time）

一个短分组从客户到服务器再返回客户所花时间
包括分组传播时延、分组在路由器&交换机的排队时延、分组处理时延

应用与TCP连接方式

HTTP持续连接（默认）&非持续连接皆可

非持续连接（non-persistent content）

每个TCP连接在服务器发送一个对象后关闭，即只传输一个请求报文+一个响应报文
可以并行缩短响应时间
过程：三次握手，第三部分（确认）向TCP连接发送请求报文，响应时间=2RTT+传输文件时间

持续连接（persistent content）

节省创建TCP的RTT
同一个客户在单个持续TCP完成，超过一定时间间隔未使用就关闭TCP连接

Web缓存

Web缓存器（Web cache），代理服务器（proxy server）：代理原始Web服务器回应HTTP请求的网络实体，磁盘存储空间保存最近请求过的对象副本，浏览器配置后可以先指向缓存器

步骤

浏览器创建到Web浏览器的TCP连接，发送HTTP请求
Web缓存器检查是否存储副本，有则返回HTTP响应报文
Web缓存器没有副本则向原始服务器建立TCP连接，发送HTTP请求，并将接收的对象在本地创建副本，向客户发送副本（因此Web缓存器既是服务器也是客户）

原因

减少对客户请求的响应时间，尤其是客户与原始服务器带宽瓶颈远小于客户与Web缓存器时
降低因特网上的Web流量，所有应用都能得到改善

验证缓存是否是最新的：条件GET（conditional GET）

GET方法
包含If-Modified-Since: 首部行
Web缓存器给服务器发送，若没修改发回304 Not Modified

FTP

File Transfer Protocol
远程传输文件，TCP
有权限的用户建立control connection，端口21，浏览器查看远程目录，发送指令
服务器收到指令后开启第二个TCP，data connection，传输文件，传完一个就关闭
服务器保持文件目录状态、用户认证状态

电子邮件&SMTP

电子邮件概念

**用户代理（user agent）向其邮件服务器（mail server）发送，邮件放在报文队列（message queue）中尝试发送给对方的邮件服务器，若不能发送间隔时间尝试，对方服务器收到后放在对方的邮箱（mailbox）**中，对方可通过用户代理访问邮箱
每台服务器运行SMTP简单邮件传输协议（Simple Mail Transfer Protocol），既是客户端也是服务器端，使用TCP可靠数据传输

邮件报文格式

From: xxx@abc
To: yyy@def
Subject: aaaaaaa

data(ASCII格式)

flowchart LR
	A的代理 -- SMTP --> A的邮件服务器 -- SMTP --> B的邮件服务器 -- 邮件访问协议--> B的代理

SMTP

一般不使用中间邮件服务器
报文采用7比特ASCII码
命令包括HELO、MAIL FROM、RCPT TO、DATA、QUIT
过程
- MAIL FROM: <xxx@abc>
- MAIL TO: <yyy@def>
- DATA
- ...内容
- .
与HTTP对比
- HTTP是拉协议（pull protocol），SMTP是推协议（push protocol）
- HTTP对报文数据没有限制，SMTP要求必须按7比特ASCII编码
- HTTP把每个对象单独封装到报文中，SMTP所有对象都在一个报文中
- 二者都有ASCII命令/响应的交互，都有状态码
MIME协议( Multipurpose Internet Mail Extensions )，通用因特网邮件扩充协议，把非ASCII码数据转换为NVT ASCII数据，之后的工作再交给SMTP完成，在接收方再将NVT ASCII数据还原成原来的数据

邮件访问协议

POP3（Post Office Protocol—Version3）

用户代理向邮件服务器建立TCP链接
特许（authorization）：用户代理发送明文用户名&口令
事务处理（transaction）：用户代理取回报文、删除报文、统计右键
更新：结束POP3对话做出修改（比如删除）

因特网邮件访问协议IMAP（Internet Mail Access Protocol）

解决POP3的问题：用户不能创建远程文件夹
IMAP服务器可创建文件夹、移动报文、条件查询右键、维护用户状态信息、允许获取报文的一部分
（如果我没记错IOS自带的邮件关联其他邮箱就需要开启IMAP）

HTTP

基于Web的电子邮件，用户代理是浏览器，通过HTTP进行

DNS（Domain Name System）

主机通过主机名或IP地址识别
域名系统DNS（Domain Name System）：分层（hierarchy）的DNS服务器实现的分布式数据库，主机解析域名的应用层协议
被其他应用层协议使用，将用户提供的主机名解析为IP地址
- 用户运行着DNS客户端
- 应用将主机名传给DNS客户端
- DNS客户端向DNS发送包含主机名的请求，并受到包含IP地址的回复，该过程使用UDP
- 应用利用该IP地址建立TCP连接
提供别名服务，通过别名获取规范名和IP
- 主机别名（host aliasing），对应规范主机名（canonical hostname）
- 邮件服务器别名（mail server aliasing）
- 负载分配（load distribution），繁忙站点多个服务器IP映射到同一个规范主机名

分布式（distributed）、分层次（hierarchical）数据库

不可采用集中式：单点故障、通信容量、远距离、频繁维护（更新）

分类

根DNS服务器：提供顶级域服务器的IP地址
顶级域（Top Level Domain，TLD）服务器：提供权威DNS服务器的地址
权威（authoritative）DNS服务器：IP地址

graph
	根DNS服务器 --- 顶级域DNS服务器 --- 权威DNS服务器

查询

本地DNS服务器：不属于层次结构，每个ISP都有一台，主机连接ISP时ISP向其提供本地DNS服务器的IP，这个本地DNS服务器一般距离主机不超过几台路由器

实践中通常递归（recursive）+迭代（iterative）查询综合：

flowchart LR
	主机 -- 1 --> 本地DNS服务器 -- 2 -->根DNS服务器 -- 3 -->本地DNS服务器
	本地DNS服务器 -- 4 -->TLD服务器 -- 5 -->本地DNS服务器
	本地DNS服务器 -- 6 -->权威DNS服务器 -- 7 -->本地DNS服务器
	本地DNS服务器 -- 8 --> 主机

DNS缓存（caching）

在一段时间（通常2天）丢弃缓存信息
本地DNS服务器也能缓存TLD服务器的IP，绕开根DNS服务器

DNS资源记录（Resource Record）

RR提供主机名到IP地址的映射
注：主机名通常在局域网内使用，通过hosts文件，主机名就被解析到对应IP，域名通常在INTERNET上使用，但如果本机不想使用internet上的域名解析，这时就可以更改hosts文件，加入自己的域名解析
4元组 $(Name,Value,Type,TLL)$
TLL：记录的生存时间（什么时候该被从缓存中删除）

Type	Name	Value
A	主机名	IP地址
NS	域名	能查该域名IP的权威DNS服务器主机名
CNAME	别名	规范主机名
MX	别名	邮件服务器的规范主机名

某主机的权威服务器含有该主机名的A记录
某主机的非权威服务器缓存可能含有该主机名的A记录
某主机的非权威服务器含有一条NS（指向权威服务器）+一条A（指向前面对应权威服务器的IP）

DNS报文

（待补）

P2P文件分发&BitTorrent

P2P文件分发时间

符号	含义
$u_s$	服务器接入链路的上传速率
$u_i$	第 $i$ 对等方接入链路的上传速率
$d_i$	第 $i$ 对等方接入链路的下载速率
$F$	被分发的文件长度(bit)
$N$	想要得到文件副本的对等方数量
$D$	分发时间（distribution time）：所有 $N$ 个对等方得到该文件副本所需时间

对于CS体系
- 服务器总共传 $NF$ 比特，下载速度最慢的构成第二项
- 调度方法是不停上传，下载最慢的优先下载
- 随 $N$ 增加时间线性增长

D_{cs}=\max \{\frac{NF}{u_s},\frac{F}{d_{min}}\}

对于P2P体系：
- 至少上传一份的速度（第一项），下载速度最慢的一项（第二项），系统总上传能力 $u_s+\sum_{i=1}^{N}u_i$ 上传完整 $NF$ 所需时间
- 方法是每收到一个比特就上传一个比特
- 非线性增长，缓慢

D_{P2P}=\max \{\frac{F}{u_s},\frac{F}{d_{min}},\frac{NF}{u_s+\sum_{i=1}^{N}u_i}\}

BitTorrent协议

洪流（torrent）：参与一个特定文件分发的所有对等方的集合，对等方彼此下载等长度的文件块（chunk）
追踪器（tracker）：每个torrent具有的一个基础设施节点，对等方加入torrent时向tracker注册自己
一个主机加入torrent时，tracker选取对等方子集，发送IP给主机，主机试图与这些IP创建TCP连接成为邻近对等方，主机周期性询问它们所具有的块列表并请求自己没有的
请求方式是最稀缺优先（rarest first），没有的块&邻近对等方中副本最少的，从而使得稀缺的块迅速分发，均衡块在torrent中的副本数量
响应方法：对换算法，持续测量接受比特的速率，确定提供数据最快的前4个邻居（定期更新）（这4个叫unchoked）；每30s随机选对等方传数据

视频流&DASH&CDN

DASH

经HTTP的动态适应流（Dynamic Adaptive Streaming over HTTP）：视频编码为几个版本（比特率不同），客户动态请求几秒的视频段数据块
HTTP服务器提供告示文件（manifest file）说明版本

CDN

内容分发网CDN（Content Distribution Network）：管理分布在多个地方的服务器（存储Web内容的副本）
包括专用（private）CDN和第三方（third-party）CDN，第三方CDN为多个提供商分发内容
安置原则
- 深入ISP的接入网，靠近端用户，减少端到CDN集群的链路和路由器数量，但由于分布式，维护困难
- 放在IXP，端延时高但好维护管理
存储类似缓存，若请求的内容没有从别处请求来后创造副本
CDN截获请求并确定适合的CDN服务器集群，并将请求重定向到服务器，常用DNS截获并重定向（权威DNS服务器返回CDN专用DNS的主机名，最终找到CDN的IP）
集群选择策略：地理最邻近（但可能本地DNS服务器远，或地理近网络不近）、实时测量（每个CDN集群周期性向各本地DNS服务器发送探测分组）