Network - 01.Application Layer

  • 为用户应用程序提供网络服务，并定义应用程序之间通信的规则。
  • 定义数据交换的格式（例如，Web 浏览器如何向服务器请求页面）。
  • 提供各种网络应用协议 。
  • 示例协议：  HTTP（万维网）、SMTP（电子邮件）、DHCP（地址配置）、DNS（域名解析） 以及 YouTube、Google、Netflix 等服务 。

应用层核心原理

网络应用程序的体系结构 (Application Architectures)

  • 客户端-服务器 (Client-Server) 结构
    • 服务器 (Server):
      • 通常是“永远在线”的主机。
      • 拥有固定的、永久性的IP地址。
      • 为了应对大量请求，通常以数据中心或服务器集群 (Server farms) 的形式存在以实现扩展。
    • 客户端 (Client):
      • 与服务器进行通信，但客户端之间不直接通信。
      • 可能是间歇性地连接到网络。
      • 其IP地址可能是动态分配的。
  • 对等 (Peer-to-Peer, P2P) 结构
    • 几乎没有或完全不使用永远在线的服务器。
    • 任意的终端系统（称为对等方/Peers）之间可以直接通信。
    • 对等方可以间歇性地连接到网络，并且每次连接的IP地址都可能改变。
    • 这种结构具有很高的可扩展性，因为每个对等方既是信息的请求者也是提供者，但管理起来较为困难。
  • 混合 (Hybrid) 结构
    • 这是客户端-服务器和P2P结构的结合体。
    • 详细说明: 以即时通信 (Instant Messaging) 为例，它利用中心化的服务器来追踪用户的在线状态和IP地址（这部分是C/S结构），但用户之间的聊天报文是直接发送的（这部分是P2P结构）。Skype也是一个典型例子，它使用中心化服务器来寻找你要呼叫的用户，但一旦找到，语音数据流就直接在两个用户之间传输。

进程通信与寻址

  • 进程 (Process): 是在主机上运行的程序实例。不同主机上的进程通过网络交换报文 (messages) 来进行通信。
  • 套接字 (Socket):
    • 详细说明: 套接字可以被看作是应用程序进程的“门”。进程通过这个门向网络中发送报文，并从网络中接收报文。它是由操作系统控制的、应用程序与传输层协议之间的编程接口 (API)，应用程序开发者可以通过它来选择传输协议（如TCP或UDP）并设置一些参数。
  • 进程寻址 (考点):
    • 为了让报文能准确送达某个特定进程，仅有IP地址是不够的，因为一台主机上可能同时运行着多个需要网络的进程。
    • 因此，一个进程的唯一标识符由两部分组成：主机的IP地址 和 端口号 (Port Number)。
    • 一些知名应用有默认的端口号，例如HTTP服务器使用80端口，SMTP邮件服务器使用25端口。

IP地址 (Internet Protocol Address):
可以把它想象成互联网上每台设备的家庭住址。它是一个独一无二的数字标识（例如 166.111.4.100），分配给连接到网络的每一台计算机、手机或其他设备。网络中的其他设备使用这个地址来找到它，并向它发送数据。目前主要有32位的IPv4地址和更长的IPv6地址两种格式。

应用所需的传输服务与Internet协议

  • 应用需求:
    • 可靠性 (Reliability): 文件传输、电子邮件等应用要求100%可靠的数据传输，不能有任何数据丢失。而实时音视频等应用则可以容忍一定程度的数据丢失。
    • 带宽 (Bandwidth): 多媒体应用通常需要一个最低的带宽保障才能有效工作。而像电子邮件这样的弹性应用 (elastic apps) 则会利用任何可用的带宽。
    • 延迟 (Delay): 交互式应用，如网络电话和在线游戏，对延迟非常敏感，要求较低的延迟。
  • Internet提供的传输协议:
    • TCP (传输控制协议, Transmission Control Protocol):
      • 提供面向连接 (Connection-Oriented) 的服务，在传输数据前必须先建立连接。
      • 提供可靠的数据传输 (Reliable Data Transfer) 服务，保证数据不丢失、不冗余、按序到达。
      • 包含流量控制 (Flow Control)，确保发送方不会压垮接收方。
      • 包含拥塞控制 (Congestion Control)，在网络拥塞时会限制发送方的速率。
      • 不提供: 延迟保证或最小带宽保证。
    • UDP (用户数据报协议, User Datagram Protocol):
      • 提供不可靠 (Unreliable) 的数据传输服务。
      • 不提供任何TCP所具有的服务，如连接建立、可靠性、流控或拥塞控制等。
      • 为何存在UDP?: 因为它简单、开销小，能够提供更低的延迟，非常适合对延迟敏感且能容忍丢包的应用。

Web 和 HTTP 协议

HTTP 概述

  • HTTP (超文本传输协议, HyperText Transfer Protocol) 是Web的应用层协议。
  • 无状态协议 (Stateless Protocol):
    • 详细说明 (考点): 这是HTTP的一个核心特性，意味着服务器不保存关于客户端过去请求的任何历史信息。这样做的好处是极大地简化了服务器的设计，使其能够轻松处理数以千计的并发连接。但如果应用需要识别用户（如电商网站），就需要通过其他机制来实现状态的维持，最常见的就是 Cookies。

HTTP 连接管理 (考点)

RTT 就是一个数据包从你的电脑出发，到达目标服务器，然后服务器的响应再返回到你的电脑，这一来一回所花费的总时间。

  • 非持续连接 (Non-Persistent Connection):
    • 每个TCP连接最多只传输一个Web对象（如一个HTML文件或一张图片），然后就关闭。
    • 性能分析: 获取每个对象都需要2个RTT的开销（1个RTT用于建立TCP连接，1个RTT用于HTTP请求和响应），外加文件自身的传输时间。这导致了较高的延迟和服务器负担。这是HTTP/1.0的默认方式。
    • 举例来说，一个包含1个HTML文件和3张图片的网页，客户端总共需要发起4次HTTP请求。在使用非持续连接时，就需要建立4个独立的TCP连接，仅建立连接和请求/响应的固定开销就高达 4 * 2RTT = 8RTT，这导致了很高的延迟。
  • 持续连接 (Persistent Connection):
    • 多个Web对象可以通过同一个TCP连接进行传输。服务器在发送响应后会保持连接开启，等待后续请求。
    • 性能分析: 对于所有被引用的对象，可以省去重复建立TCP连接的开销，大大提升了效率。这是HTTP/1.1的默认方式。
    • 流水线 (Pipelining): 在持续连接的基础上，客户端可以连续发送多个请求，而无需等待前一个请求的响应，进一步减少了延迟。

HTTP 报文格式

  • 请求报文 (Request Message):
    • 请求行: 包含方法（如GET, POST）、请求的URL和HTTP版本。
    • 首部行: 包含Host（目标主机）、User-agent（浏览器信息）、Accept-language（可接受的语言）等。
    • 实体主体: 通常用于POST方法，携带提交给服务器的数据（如表单内容）。
  • 响应报文 (Response Message):
    • 状态行: 包含HTTP版本、状态码（如 200）和状态短语（如 OK）。
    • 首部行: 包含Connection（连接状态）、Date、Server（服务器软件）、Content-Type（内容类型）等。
    • (考点) 重要首部字段区分:
      • Date: 指的是该响应报文被服务器创建并发送的时间。
      • Last-Modified: 指的是所请求的对象（如HTML文件）在服务器上最后被修改的时间。这个字段主要用于缓存控制。
    • 实体主体: 包含请求的实际对象，如HTML文件。
      • 注意: 在某些情况下，响应报文的实体主体是空的。例如：
        • 对 HEAD 请求的响应: 服务器只返回首部信息。
        • 304 Not Modified 响应: 当服务器通过条件GET告知缓存其副本仍然有效时，响应报文中不包含实体主体，以节省带宽。

Cookies 与 Web 缓存

  • Cookies:
    • 作用: 通过在HTTP报文的首部中添加额外信息，并在客户端本地保存一个小文件，来帮助网站追踪用户和维持状态。
    • 应用: 用户认证、购物车、个性化推荐、Web邮箱的会话保持等。
  • Web 缓存 (Web Cache) / 代理服务器 (Proxy Server):
    • 目标: 在不访问源服务器的情况下满足客户端的请求，以降低延迟和网络流量。
    • 条件GET (Conditional GET):
      • 详细说明 (考点): 缓存为了确认自己存储的对象副本是否为最新，会在发往源服务器的请求中包含一个 If-modified-since 首部行，其值为该对象上次被获取的日期。如果源服务器上的对象在此日期之后没有被修改过，服务器会返回一个特殊的 304 Not Modified 响应，且响应报文中不包含对象主体。这样，缓存就知道自己的副本仍然有效，从而避免了不必要的网络传输。

FTP, 电子邮件, DNS

FTP (文件传输协议, File Transfer Protocol)

  • 核心特点 (考点): FTP使用两个并行的TCP连接来工作。
    • 控制连接 (Control Connection) (Port 21): 用于传输命令和响应，如用户登录、改变目录等。它在整个会话期间保持开启。这种带外 (out-of-band) 控制方式是其特点。
    • 数据连接 (Data Connection) (Port 20): 用于实际的文件传输。每传输一个文件，就会建立一个新的数据连接。
  • 状态: FTP是一个有状态 (stateful) 的协议，服务器会记录用户的当前目录、认证状态等信息。

电子邮件 (SMTP)

  • 三大组件: 用户代理 (User Agent)、邮件服务器 (Mail Servers) 和 SMTP 协议。
  • SMTP (简单邮件传输协议, Simple Mail Transfer Protocol):
    • 作用: 负责将邮件从发送方的邮件服务器推送 (push) 到接收方的邮件服务器。
    • 与HTTP对比: HTTP是一个拉取 (pull) 协议，由客户端主动从服务器拉取信息。而SMTP是服务器到服务器的推送过程。

DNS (域名系统, Domain Name System)

  • 功能: 一个庞大的、分布式 (distributed)、层次化 (hierarchical) 的数据库，用于将用户友好的主机名（如www.google.com）解析为机器可读的IP地址（hostname到IP的映射）。是应用层协议

  • 层级化结构

  • 解析过程详解:

    1. 本地DNS服务器 (Local DNS Server): 用户的查询请求首先发送到其ISP(Internet Service Provider) 或机构的本地DNS服务器。
    2. 迭代查询 (Iterated Query): 如果本地服务器没有缓存该记录，它会启动一个迭代查询过程。它首先查询一个根DNS服务器 (Root DNS Server)。
    3. 根服务器不会直接给出IP，而是返回负责相应顶级域 (Top-Level Domain, TLD)（如.com）的TLD服务器的地址。
    4. 本地服务器接着查询该TLD服务器，TLD服务器会返回负责目标域（如amazon.com）的权威DNS服务器 (Authoritative DNS Server) 的地址。
    5. 最后，本地服务器查询该权威DNS服务器，从而获得最终的IP地址。
    6. 本地服务器将结果返回给用户主机，并缓存 (Caching) 该记录以备后续查询。

  • DNS 记录 (Resource Records, RR):

    • A记录: 将主机名映射到IPv4地址。
    • AAAA记录: 将主机名映射到IPv6地址。
    • NS记录: 指定域的权威DNS服务器。
    • CNAME记录: 为一个主机名创建别名。
    • MX记录: 指定域的邮件服务器。

  • 递归查询 (Recursive Query)

    • 特点: “请帮我查到底，给我最终答案。”
    • 过程: 客户端向 DNS 服务器发起请求，该服务器必须返回最终的 IP 地址或“找不到”的错误。解析的全部负担都在被请求的服务器上。
    • 常见于: 你的电脑 -> 本地 DNS 服务器。

  • 迭代查询 (Iterated Query)

    • 特点: “我不知道，但你可以去问它。”
    • 过程: 服务器不会直接返回最终答案，而是返回它所知道的、更接近答案的下一个 DNS 服务器的地址。请求方需要自己继续向下一个服务器查询。
    • 常见于: 本地 DNS 服务器 -> 根/TLD/权威 DNS 服务器。

这是互联网 DNS 系统的实际工作方式，它结合了递归和迭代两种查询，高效且分工明确。

  • 核心思想: 本地 DNS 服务器作为“总指挥”，主导整个查询过程。

  • 流程:

    1. 客户端 向 本地 DNS 服务器 发起 递归查询 (请求最终结果)。
    2. 本地 DNS 服务器 收到请求后，代表客户端进行一系列 迭代查询：
      • 它先问 根 DNS 服务器，根服务器回复 TLD 服务器的地址。
      • 它再问 TLD DNS 服务器，TLD 服务器回复权威服务器的地址。
      • 它最后问 权威 DNS 服务器，获得最终的 IP 地址。
    3. 本地 DNS 服务器 将最终的 IP 地址返回给 客户端，完成最初的递归请求。

  • 关键点: 整个“奔波”的工作是由本地 DNS 服务器完成的，根和 TLD 服务器只负责“指路”，因此效率非常高。

DNS Records

DNS 是一个存储资源记录 (Resource Record - RR) 的分布式数据库。

一条标准的 RR 包含四个字段：(name, value, type, ttl)

  • name: 记录所关联的域名。
  • value: 记录的值，含义由 type 决定。
  • type: 记录的类型。
  • ttl: 生存时间 (Time To Live)，该记录能在缓存中存放多久。

A 记录 (Address)

  • 用途: 将主机名映射到 IPv4 地址。
  • 格式: name 是主机名, value 是 IP 地址。
  • 示例: (servereast.backup2.ibm.com, 129.42.60.212, A)

CNAME 记录 (Canonical Name)

  • 用途: 为一个主机名设置一个别名。
  • 格式: name 是别名, value 是规范名 (真名)。
  • 示例: (ibm.com, servereast.backup2.ibm.com, CNAME)
  • 说明: 访问 ibm.com 最终会解析到 servereast.backup2.ibm.com 的 IP 地址。

NS 记录 (Name Server)

  • 用途: 指定管理某个域的权威 DNS 服务器。
  • 格式: name 是域名, value 是权威 DNS 服务器的主机名。
  • 示例: (ibm.com, dns.ibm.com, NS)
  • 说明: 这条记录告诉其他服务器，想知道 ibm.com 下的任何记录，就去问 dns.ibm.com。

MX 记录 (Mail Exchanger)

  • 用途: 指定接收该域名电子邮件的邮件服务器。
  • 格式: name 是域名, value 是邮件服务器的主机名。
  • 示例: (ibm.com, mail.backup2.ibm.com, MX)
  • 说明: 发往 @ibm.com 的邮件会被路由到 mail.backup2.ibm.com 服务器。

P2P 应用

覆盖网络是一个构建在另一个现有网络（通常称为“底层网络”）之上的虚拟网络。网络中的节点通过虚拟的逻辑链路直接相互连接，而无需关心底层网络的物理拓扑。

  • 节点: 覆盖网络的节点是运行特定应用的终端主机，不包含传统意义上的物理路由器
  • 边: 覆盖网络中的“边”是连接两个节点的逻辑链路，在底层网络中可能对应着非常复杂的物理路径。
  • P2P应用就是构建在这种覆盖网络上的典型例子。

P2P 文件共享架构

  • P2P应用的核心挑战是如何在分散的、动态的对等方网络中定位内容。
  • 中心化目录 (Centralized Directory) (以Napster为例):
    • 定位内容的过程是中心化的。用户上线时向一个中央服务器注册自己拥有的文件，查询时也向该服务器进行。
    • 文件传输本身是去中心化的P2P，直接在对等方之间进行。
    • 缺点: 中央服务器是单点故障和性能瓶颈。
  • 查询洪泛 (Query Flooding) (以Gnutella为例):
    • 是完全分布式的，没有中央服务器。
    • 当一个对等方想查找文件时，它会向所有与之相連的邻居发送查询请求，这些邻居再将查询转发给它们的邻居，以此类推，形成“洪泛”。
  • 超级对等方 (Super-peer) (以KaZaA为例):
    • 一种混合模式，利用了网络中节点的异构性（即某些节点拥有更强的计算能力和网络带宽）。
    • 这些强大的节点成为超级对等方 (Super-peer) 或组长，每个普通节点会连接到一个组长，并由组长索引其内容。
    • 查询首先发送给组长，如果组长没有，它会再将查询转发给其他组长。
Network
#Network
Network - 01.Application Layer
https://yima-gu.github.io/2026/01/14/Network/Network-01-Application-Layer/
作者
Yima Gu
发布于
2026年1月15日
许可协议