Application Layer

Zhang Zhang Lv2
  2025-03-22 2025-03-22 Created   2025-04-14 10:38:08 2025-04-14 10:38:08 Updated      

创建网络应用程序 => 网络应用程序在端系统（网络边缘）运行，网络核心设备并不运行用户的应用.

接下来介绍应用程序的体系结构

网络应用程序体系结构

客户机 / 服务器体系结构

服务器

  • 总是开机
  • 固定的、可以周知的IP地址

客户机

  • 和服务器通信
  • 间歇性链接
  • 动态IP地址
  • 不直接和其他客户机通信

P2P

  • 不存在总是开机的服务器
  • 任何端系统之间可以直接通信

C / S & P2P混合结构

进程通信

进行通信的不是程序而是进程. 在同一台主机上也存在进程间通信（由操作系统定义）；不同主机上的进程之间通过报文（message）进行

客户进程

服务器进程

在P2P架构中，一个进程可能即是客户机也是服务器

套接字（Sockets）：进程通过它的套接字发送 / 接受报文

API：1）选择运输层协议；2）设定运输层参数

进程寻址

进程如何识别另外一个通信的进程

  • 进程的标识符 identifier
  • 主机上全球唯一的32位IP地址
  • 主机的端口号，比如HTTP -> 80

Socket = IP Address + Port

应用层协议

交换报文的类型

  • 报文格式
  • 报文语义
  • 进程发送和接受报文的规则

公开协议和专有协议

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

应用层 => 运输层

常见网络应用的传输服务需求

可靠、吞吐量、定时、安全性

应用层协议：

TCP：

  • 面向连接的
  • 可靠传递
  • 流量控制：发送方不淹没接收方
  • 拥塞控制：当网络过载的时候已知发送方
  • 不提供：实时性和最小带宽的保证

UDP：

  • 发送和接受进程之间不可靠的数据传递
  • 不提供：上面那些都不提供

有可能导致报文乱序

Web 和 HTTP

Web的应用层协议是超文本传输协议（HTTP）

Web页面由对象组成，对象包括HTML文件等

每一个对象可以通过一个URL进行寻址：主机名 + 路径名

HTTP

Web浏览器实现了HTTP的客户机短

Web服务器存储对象，由URL寻址

支撑HTTP的运输层协议是TCP

1
2
3
4
graph TD 
A[因特网三要素] --> B[设备] 
A --> C[协议] 
A --> D[服务]

Web与HTTP

HTTP

非持续链接和持续链接

  • 非持续链接：每个请求 / 响应对经过单独的TCP连接发送
  • 持续链接： 所有请求 / 相应对经过相同的TCP连接发送

目前常见的HTTP默认是持续链接. 非持续连接中，HTTP文件发送一个报文之后会立即关闭连接，这可能导致时间的损耗. 我们考虑传输过程中消耗的时间：

响应时间

我们首先考虑一个对象的传输（say, 最开始的html文件）. 如下图，总响应时间 = 2*RTT + 文件传输时间. 其中RTT(Round-Trip Time).

![[Pasted image 20250305100038.png | 800]]

非持久连接

持续链接

非持续链接为每一个请求对象建立维护全新的连接

服务器在发送出响应之后保持连接的打开状态，随后发送的报文都可以在这一个打开链接上进行发送.

  • 不带流水线：前一个响应接受之后，Client才可以发出新的请求. （相比于非持久连接，这种方式还是省去了很多建立连接的RTT时间）
  • 带流水线：Client只要遇到一个被引用对象，就可以立刻发送请求，在最好情况下，所有的引用对象只需要一个RTT就可以获得

HTTP的报文

请求报文(Request)

  • 请求行
  • 首部行
  • 附加回车换行符表示报文结束

![[Pasted image 20250305101446.png | 800]]

请求行

  • 方法字段: 例如：GET, POST, HEAD, PUT, DELETE
  • URL字段
  • HTTP协议版本字段

首部行

  • Host
  • User-agent
  • Connection: 例如close表示非持久连接
  • Accept-language

空行

(实体主体)

如果使用POST, PUT，需要向Server传递其他内容，就会放在这个部分.

Note

虽然我们在这里说可以将POST的内容（比如查找的关键字）放在实体对象里面，但是实际操作中，我们也可以使用GET方法，利用扩展的URL发送表单生成的请求报文

响应报文(Response)

  • 状态行
  • 首部行
  • 实体

状态行

  • 协议版本
  • 状态码
  • 响应状态信息
Note

一些常见的状态码

  • 200 OK
    请求成功，信息包含在返回的响应报文中。
  • 301 Moved Permanently
    请求的对象已经被永久转移了，新的URL定义在响应报文的. Location:首部行中指定。客户机软件自动用新的URL获取该对象。
  • 400 Bad Request
    一个通用差错代码，指示该请求不能被服务器理解。
  • 404 Not Found
    被请求的文档不在服务器上。
  • 505 HTTP Version Not Supported
    服务器不支持请求报文使用的HTTP协议版本

首部行

  • Connection: 例如close表示非持续链接，服务器在响应之后已经关闭了TCP连接
  • Date
  • ……

四个组成部分

  • HTTP响应报文中有一个cookie首部行
  • HTTP请求报文中有一个cookie首部行
  • 用户端系统中保留一个cookie文件，由浏览器管理
  • Web站点的后端数据库存储用户的cookie

cookie可以保持用户状态：

![[Pasted image 20250305102713.png | 800]]

HTTP协议本身是一个无状态的协议，cookie在发送方 / 接受方之间的多次交互维持状态，在无状态的HTTP上建立了一个用户对话层

Note

第三方cookie? 看书

Web缓存器（代理服务器）

为了加速访问（?），可以使用Web服务器

Web缓存器（代理服务器）（Cache）: 能够代表初始Web服务器来满足HTTP请求的网络实体

用户设置将HTTP请求指向Cache，如果cache有对应对象，直接返回；如果没有，像初始服务器请求，并把得到的对象进行返回.

为什么cache是重要的？这里有一个例子，没有太看懂

缓存哪些文档？请求率 / 更新率 >> 1

条件GET

cache在发送GET请求的时候指明当前缓存的对象拷贝的日期，如果cache存储的拷贝是最新的，server就发不含具体对象的响应：304 Not Modified

HTTP/2与HTTP/3

HTTP/2

目的：降低多对象HTTP请求延迟

HTTP1.1的缺陷

因为服务器按序响应GET请求. 大对象之后的小对象可能等待很长时间（head-of-line blocking 线路前部阻塞）

HTTP/2在服务器端给客户发送对象的过程中增加了灵活性：

  • 按照用户指定的对象优先级，传输被请求的对象
  • 推送未被请求的对象给客户（服务器推）
  • 将对象可以拆分为帧，缓解HOL阻塞==?==

HTTP/3

?

FTP

FTP：文件传输协议，在本地和远程站点之间传递文件

ftp serve: 控制连接端口21，数据连接端口20

FTP client通过21端口连接FTP server，TCP作为传输协议.

带外传输

HTTP是带内传输：请求、响应在一个连接中进行

明文传输用户名和密码

电子邮件

三个组成部分：

  • 用户代理
  • 邮件服务器
  • 简单邮件传输协议：SMTP

用户代理

用户代理完成：阅读、回复、转发、保存和撰写功能.

发送出去和接收到的报文都存储在服务器上

邮件服务器
SMTP协议在邮件服务器之间发送邮件报文的协议

简单邮件传输协议

采用TCP端口25把邮件报文从客户端传递到服务器端.

  • 握手
  • 报文传送
  • 关闭连接

发送用户 -(SMTP)-> 发送方服务器 -(SMTP)-> 接收方服务器 --> 接收用户

SMTP与HTTP比较:

HTTP：pull SMTP:pus

HTTP使用ASCII命令 / 响应交互表示状态码

SMTP使用ASCII命令 / 响应交互表示状态码报文中非ASCII字符或者二进制数据按照7bitASCII码进行编码

收文件使用的不是SMTP，接下来会讲

尝试SMTP交互命令

sniffer

邮件报文格式和MIME（Multiperpose Internet Mail Extension）

首部行包含环境信息

邮件访问协议：

POP3 没有文件目录结构
IMAP 因特网邮件访问协议
HTTP

POP3协议

  • 特许阶段：
    Client命令：user, pass
    Server响应：

  • 处理阶段 Client
    list
    retr
    dele(只是打了个标签)
    quit

  • 更新阶段
    POP3服务器删除标记为删除的报文

POP3是无状态的

IMAP协议

所有邮件报文放置在服务器

允许用户在文件目录中组织整理邮件报文

IMAP是一个有状态的协议：可以浏览文件目录名，在目录名和报文序号之间建立映射

允许只获得邮件报文首部

基于HTTP的邮件访问

域名系统DNS

Domain Name System: 因特网的目录服务

  • 具有分层体系结构的许多名字服务器构成的分布式数据库
  • DNS是一个应用层协议，它提供的服务可以被同层的协议使用

DNS服务：主机名到IP地址的翻译.
主机别名
邮件服务器别名
负载分配：互为备份的一组Web服务器，为一个规范名字设置一组IP地址

DNS的分布式、层次化

根DNS服务器

顶级域（TLD）DNS服务器

权威DNS服务器

本地DNS服务器

www.amazon.com

root server -> com DNS服务器

com server -> amazon DNS服务器

amazon server -> www.amazon.com

根DNS服务器

顶级域DNS服务器
权威DNS服务器
本地DNS服务器

不属于层次体系 起代理的作用

DNS名字解析

迭代查询

递归、迭代

![[Pasted image 20250305120625.png | 800]]

I don’t know this name, but ask this server.

递归查询

![[Pasted image 20250305120805.png | 800]]

现实中不使用

记录的缓存与更新

TTL

缓存的数据项可能会过期

IETF: RFC 2136

DNS 记录

资源记录格式：(Name, Value, Type, TTL)

  • Type A

Name, Value: 主机名+IP地址

  • Type NS

Name是域
Value为该域权威DNS服务器的主机名

  • Type CNAME

Name是规范名称的别名
Value是规范名字

  • Type MX

Name是别名
Value是别名为name的邮件服务器的规范主机名

DNS协议和报文

问询报文

回答报文

格式相同

???j

把记录添加到DNS

DNS与安全.性

安全性

  • DNS中间人攻击：截获主机请求，范围伪造的回答
  • DNS毒害攻击：
  • 蛮力攻击DDos：

P2P应用

之前介绍的应用都是C-S架构

Example

从一个服务器向个对等方发送一个大小为的时间.
![[Pasted image 20250312100249.png]]
在这个过程中，服务器和客户端的接入链路往往是瓶颈. 考虑下面的情况：
Client-Server机构下的文件分发时间
Missing or unrecognized delimiter for \left D_{\text{C-S}} \geq \max \left{ \frac{NF}{u_{s}}, \frac{F}{d_{min}} \right}
其中是服务器的上传速度，是客户端最慢的下载时间. 随着增大，时间近似是正比于的.
为什么下载没有N
P2P架构下的文件分发时间
此时，服务器至少必须上传一份拷贝，每个客户机必须下载一个，总体上下载，给出了下面的三个下界：
Missing or unrecognized delimiter for \left D_{\text{P2P}} \geq \max \left{ \frac{F}{u_{s}}, \frac{D}{d_{min}}, \frac{NF}{u_{s} + \sum_{i} u_{i}} \right}
注意此时，随着增大，也在增加，所以此时的文件分发时间近似是常数.

BitTorrent

  • 最稀缺优先
  • 对换算法： -> 处理搭免费车. 随机性？？

集中式目录

集中式目录所以 + P2P文件分发

Napster

问题：

  • 单点故障
  • 性能瓶颈和基础设施费用

查询洪泛

Gnutella协议

没雨中央服务器

覆盖网络

查询过程：

  • 查询报文经过现存的TCP连接发送
  • 主机转发查询报文
  • 当查询报文命中，按照反向路径发回

-> 有限范围的洪泛: TTL

Gnutella中对等方的加入

层次覆盖：单点 -> 群组领袖；群组领袖之间相互连接

Skype的P2P因特网电话

NAT: 网络地址转换 -> 对外只有一个IP，对内不同设备有不同IP. 对外隐藏了网络结构. NAT组织外部节点启动到内部单点的呼叫，但是允许内部节点呼叫外部的单点.

如果在Skype中，两个端系统都在NAT后？ => 利用两者的超级节点进行中继

视频流和内容分发网

分布式、应用层协议和基础设施

DASH(Dynamic Adaptive Streaming over HTTP)

  • server: 将视频切车工多视频段数据块；每个块按照不同比特率存储和编码；搞事文件：每个版本提供一个URL和编码
  • client: 定期测量接受带宽；请求告示文件，一次选择一个块（根据带宽选择最大比特率）

intelligence at client:

  • 何时请求块
  • 请求何种比特率
  • 去何处请求

内容分发网：将流式内容分发给大量同时请求用户（e.g. 高清直播）

在分布式站点存储视频的副本(CDN)：

  • 深入：将CDN服务器集群部署到ISP的接入网中
  • 邀请做客：在少量关键位置建造大集群，邀请ISP做客

Socket Programming

Socket API

![[Pasted image 20250312111627.png]]

TCP Socket Programming

UDP Socket Programming

On this page
Application Layer
  1. 网络应用程序体系结构
    1. 客户机 / 服务器体系结构
    2. P2P
    3. C / S & P2P混合结构
  2. 进程通信
    1. 进程寻址
    2. 应用层协议
  3. 可供应用程序使用的运输服务
  4. Web 和 HTTP
  5. Web与HTTP
    1. HTTP
    2. HTTP的报文
    3. Cookie
    4. Web缓存器（代理服务器）
    5. HTTP/2与HTTP/3
  6. FTP
  7. 电子邮件
  8. 域名系统DNS
  9. P2P应用
  10. 视频流和内容分发网
  11. Socket Programming
    1. TCP Socket Programming
    2. UDP Socket Programming