第2章：应用层

通信方式

应用之间的通信

C/S模式
- 客户端/服务器模式
- 缺点：可靠性/可扩展性比较差
P2P模式
- 每个session都可以是客户端也可以是服务端
- 缺点：管理比较困难
混合模式
- 以上两种模式的混合
  - 在每次上线和下线的时候向服务器端发送注册命令，把地址和资源列表进行注册
  - 在客户端请求的时候在服务器进行查询后向资源拥有者发起请求

进程之间通信

进程：在主机上运行的应用程序
在同一主机内，使用进程间通信机制通信
不同主机，通过交换报文（message）来通信
- 使用OS提供的通信服务
- 按照应用协议交换报文
  - 依靠传输层提供的服务

进程间通信(IPC,Inter-Process Communication)需要解决的问题

进程标识和寻址（服务用户）
1. 标识：进程为了接收报文，必须有一个标识
  1. 主机IP
  2. 所采用的传输层协议
  3. 进程所使用的端口
2. 一个进程用一个IP+端口标识了一个端节点
3. 本质上，一对主机上进程进行通信由两个端节点构成
传输层-应用层如何提供服务（服务）
1. 位置层间界面的SAP（TCP/IP，socket）
2. 形式：应用程序接口（TCP/IP，socket API）
3. 应用层提供给传输层的信息：
  1. 哪个进程发的 IP+Port
  2. 发送给谁 IP + Port
  3. 所发送的信息是什么 Message
4. 传输层实体根据这些信息封装TCP报文段（UDP数据包）
5. 如果每次socket API传输报文都需要携带如此多的信息，不便于管理且繁琐容错
6. 用个代号标示通信的双方或单方：socket
7. 就像OS打开文件返回的句柄一样，对句柄的操作就是对文件的操作
8. TCP socket
  1. TCP服务：两个进程之间通信前要建立连接，两个连接会持续一段时间，通信关系稳定
  2. 可以用一个整数表示两个应用实体之间的通信关系，本地标识
  3. 穿过层间接口的信息量最小
  4. TCP socket（四元组）：源IP，源端口，目标IP，目标端口
  5. 唯一指定了两个进程之间的会话关系
  6. 简单，便于管理
9. UDP socket
  1. UDP服务：两个进程通信前不需要建立连接
    每个报文都是独立传输的
  2. 因此只能用一个整数标识本应用实体
  3. 传过层间接口的信息大小最小
  4. UDP socket：本机IP+本应用port
  5. 但是传输报文时必须提供对方的ip+端口
    接收报文时也需要上传ip+端口
如何使用传输层提供的服务，实现应用进程之间的报文交换（用户使用服务）
1. 定义应用层协议：时序，报文格式/解释，动作控制等
2. 编写程序：使用OS提供的API，使用网络基础设施提供通信服务传报文，实现应用时序等

web&http

![[第2章：应用层_time_1.png]]

响应时间模型

往返时间RTT(round-trip time)

一个小的分组从客户端传输到服务端，再从服务端返回到客户端的时间（传输时间忽略）

响应时间

一个RTT用来发起TCP连接
一个RTT用来HTTP请求并等待HTTP响应
文件传输时间

持久HTTP

非持久HTTP缺点：

每个对象要2个RTT
操作系统为每个TCP连接分配资源

持久HTTP：

服务器在发送响应后仍然保持TCP连接
- 非流水式的持久HTTP：
  - 客户端只能在接收一个响应后才能发送下一个请求
  - 每个对象花费一个RTT
- 流水式的持久HTTP：
  - HTTP/1.1默认模式
  - 客户端遇到一个引用对象就立即发送一个请求
  - 所有引用对象只花费一个RTT是可能的
在相同相同客户端和服务端之间的后续请求使用同一个TCP连接机械能传送
客户端在遇到一个引用对象的时候就可以快速发送该对象的请求

HTTP请求报文

两种类型的HTTP报文：请求，响应
HTTP请求报文：
- ASCII（人能阅读）

HTTP请求报文格式

HTTP请求报文用于客户端向服务器发送请求，主要由以下四个部分构成，必须按照严格顺序排列。

请求行（Request Line）
这是报文的第一行，包含了请求的最核心信息，由三部分按顺序组成，用空格分隔：
- 请求方法：指明操作类型，如 GET（获取资源）、POST（提交数据）、PUT（更新资源）、DELETE（删除资源）等。
- 请求目标：通常是URL的路径和查询参数部分，例如 /index.html或 /search?q=hello。
- HTTP协议版本：如 HTTP/1.1或 HTTP/2，告知服务器客户端使用的协议版本。
示例：GET /api/users?id=100 HTTP/1.1
请求头（Request Headers）
从第二行开始，是若干个键值对形式的头部字段，每行一个。这些头部用于向服务器传递关于此次请求和客户端的附加信息。常见的请求头包括：
- Host：指定请求的服务器的域名和端口号（HTTP/1.1中必须包含）。
- User-Agent：描述发起请求的客户端软件（如浏览器）的类型和版本信息。
- Accept：告知服务器客户端能够处理的内容类型，如 application/json。
- Content-Type：在POST、PUT等方法中，指定请求体的数据类型（如 application/x-www-form-urlencoded, application/json）。
- Content-Length：指明请求体的字节长度，对于POST请求尤为重要。
- Authorization：用于携带身份认证凭证，如Bearer Token 。
空行（Blank Line）
在请求头结束后，必须有一个空行（仅包含回车换行符）。这是一个关键的分隔符，用于告知服务器请求头部分已结束，接下来是请求体。如果没有这个空行，服务器可能会认为请求尚未接收完成而处于等待状态。
请求体（Request Body）
此部分是可选的，并非所有请求都有。主要用于在 POST、PUT等方法中携带需要发送给服务器的数据，例如表单提交的参数、上传的文件内容或JSON格式的API数据。
示例：username=admin&password=123456

HTTP响应报文格式

服务器在接收到请求后，会返回一个HTTP响应报文，其结构与请求报文相似，也由四部分组成。

状态行（Status Line）
这是响应报文的第一行，也由三部分组成：
- 协议版本：与请求行中的版本对应。
- 状态码：一个三位数字代码，清晰表示请求的处理结果。例如，200表示成功，404表示未找到资源，500表示服务器内部错误。
- 原因短语：对状态码的简短文字描述，如 OK, Not Found。
示例：HTTP/1.1 200 OK
响应头（Response Headers）
与请求头类似，也是键值对形式，用于传递关于响应的附加信息。常见的响应头包括：
- Server：描述服务器所用的软件信息。
- Content-Type：指定响应体的数据类型（如 text/html; charset=UTF-8）。
- Content-Length：声明响应体的长度（字节数）。
- Set-Cookie：指示客户端设置Cookie 。
- Cache-Control：指示客户端应如何缓存该响应。
空行（Blank Line）
与请求报文一样，用于分隔响应头和响应体。
响应体（Response Body）
此部分包含服务器返回的实际数据，例如客户端请求的HTML网页内容、图片数据或JSON字符串等。这是浏览器展示给用户看的主体内容。

关键细节与扩展知识

空行的关键作用：请求/响应头之后的空行是必须的，它标志着元数据部分的结束，是解析报文的边界。
HTTP的演进：HTTP/1.1是当前最广泛使用的版本，它默认使用持久连接（Connection: keep-alive），提高了效率。HTTP/2则引入了二进制分帧、头部压缩等机制来进一步提升性能，但报文的基本语义没有改变。
内容编码：当响应体较大时，服务器可能会使用 Content-Encoding: gzip等方式进行压缩以节省带宽。

POST /login HTTP/1.1␍␊
Host: www.example.com␍␊
Content-Type: application/x-www-form-urlencoded␍␊
Content-Length: 29␍␊
␍␊
username=alice&password=secret123

说明：为了清晰展示不可见字符，上例中的 ␍代表回车符（Carriage Return, CR, \r），␊代表换行符（Line Feed, LF, \n）。在标准的RFC规范中，HTTP报文的换行符必须是 CRLF（即 \r\n）。

cookie

HTTP响应报文中有一个cookie的首部行
在HTTP请求报文中有一个cookie的首部行
在用户端保留一个cookie的文件由浏览器管理
在web后端存入数据库中

用cookie值关联用户的行为和状态

web cache

目标：不访问原始服务器，就满足客户端的请求
用户设置浏览器：通过访问缓存访问web
浏览器将所有的HTTP请求发给缓存
为什么使用web缓存？
- 降低客户端的请求响应时间
- 可以大大减少一个机构内部网络与Internal接入链路上的流量
- 互联网大量采用了缓存：可以使较弱的ICP也能有效提供内容
缓存即是客户端也是服务端
通常由ISP安装
使用 If-Modified-Since 请求头解决缓存一致性问题

FTP

![[第2章：应用层_time_2.png]] ![[第2章：应用层_time_3.png]]

Email

![[第2章：应用层_time_4.png]]

![[第2章：应用层_time_5.png]]

DNS

DNS的必要性

IP标识主机、路由器
但IP地址不好记忆，不方便用户使用
存在着 “字符串” - IP地址转换的必要性
DNS负责把人类用户要访问机器的字符串名称转换为二进制的网络地址

DNS需要解决的问题

如何命名设备
1. 用有意义的字符串
2. 解决一个平面命名的重名问题：层次化命名
如何完成名字到IP地址的转换
1. 分布式的数据库维护和响应名字查询
如何维护：增加或者删除一个域，需要在域名系统中做哪些工作？

DNS-Domain Name System 总体思路和目标

DNS主要思路
- 分层的、基于域的命名机制
- 若干分布式数据库完成名字到IP地址的转换
- 运行在UDP上端口号为53的应用服务
- 核心的Internet功能，但以应用层协议实现
  - 在网络边缘处理复杂性
DNS的主要目的
- 实现主机名-IP的转换
- 其他目的
  - 主机别名到规范名字的转换
  - 邮件服务器别名到邮件服务器的正规名字转换
  - 负载均衡

DNS域名结构

Internet根被划分为几百个顶级域(top level domains)
- 通用的：.com,.edu,.got...
- 国家的：.cn,.us,.jp
每个(子)域下面可以划分任意个子域
树叶是主机
域的划分是逻辑的不是物理的

解析问题-名字服务器

单名字服务器问题
- 可靠性问题：单点故障
- 扩展性问题：通信容量
- 维护问题：远距离的集中式数据库
区域（zone）
- 区服的划分由区域管理者自己决定
- 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
- 名字服务器：
  - 每个区域都有一个名字服务器：维护着它所管理的权威信息
  - 名字服务器允许被放置在区域之外，以保障可靠性

区域名字服务器维护资源记录

资源记录
- 作用：维护域名-IP地址的映射关系
- 位置：Name Server的分布式数据库中
RR格式：name value type ttl
- Domain_name：域名
- TTL：time 头live：生存时间
- Class类别：对于Internet值为IN
- Value值：可以是数字，域名或ASCII串
- Type 类别

类型

类型编号 (十进制)

主要功能

简单示例

A (Address Record)

将主机名（域名）映射到 IPv4 地址，是最基础的记录类型。

www.example.com. IN A 192.0.2.1

AAAA (IPv6 Address Record)

将主机名（域名）映射到 IPv6 地址。

www.example.com. IN AAAA 2001:db8::1

CNAME (Canonical Name Record)

为域名创建一个别名，将访问者从一个域名重定向到另一个“规范”域名。

www2.example.com. IN CNAME www.example.com.

MX (Mail Exchange Record)

指定负责接收该域名邮件的邮件服务器，并可设置优先级。

example.com. IN MX 10 mail.example.com.

NS (Name Server Record)

指定该域名由哪个权威DNS服务器来进行解析（即委托授权）。

example.com. IN NS ns1.example.com.

PTR (Pointer Record)

用于反向DNS解析，将IP地址映射回对应的域名。

1.2.0.192.in-addr.arpa. IN PTR host.example.com.

SOA (Start of Authority Record)

起始授权记录，包含域名的权威信息和管理参数，是区域文件的第一个记录。

example.com. IN SOA ...（包含序列号、刷新时间等）

TXT (Text Record)

存储任意文本信息，常用于域名所有权验证、SPF反垃圾邮件等。

example.com. IN TXT "v=spf1 include:_spf.example.com ~all"

SRV (Service Record)

指定提供特定服务（如VoIP、即时通讯）的服务器地址和端口号。

_sip._tcp.example.com. IN SRV 10 60 5060 sipserver.example.com.

CAA (Certification Authority Authorization)

257

指定允许为该域名颁发SSL/TLS证书的证书颁发机构（CA），增强安全性。

example.com. IN CAA 0 issue "letsencrypt.org"

查询方式

对比维度

递归查询 (Recursive Query)

迭代查询 (Iterative Query)

查询主体

通常是客户端（如你的浏览器）

通常是本地DNS服务器

责任归属

“请帮我搞定一切”：服务器承担全部解析责任，必须返回最终答案（IP地址或错误信息）

“我只能告诉你下一步问谁”：被查询的服务器只返回它当前能给出的最佳结果（可能是最终答案，也可能是一个指引）

服务器压力

较大，因为服务器需要完成整个查询链条的工作

较小，责任分散，各服务器只负责自己管辖的范围

典型场景

客户端向本地DNS服务器（如ISP提供的或公共DNS）发出的查询

本地DNS服务器在DNS层级结构中向根服务器、顶级域服务器等发出的查询

维护问题：新增一个域

![[第2章：应用层_time_6.png]]

CDN

通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验

enter deep：将CDN'服务器深入到许多接入网
- 更接近用户，数量多，离用户近，管理困难
bring home：部署在少数关键位置，如将服务器簇安装于POP附近
- 采用租入线路将服务器簇连接起来
CDN：在CDN节点中存储内容的多个拷贝
用户从CDN中请求内容
- 重定向到最近的拷贝，请求内容

上一页第1章：计算机网络下一页第3章：传输层

最后更新于2个月前

hashtag通信方式

hashtagweb&http

hashtagHTTP请求报文格式

hashtagHTTP响应报文格式

hashtag关键细节与扩展知识

hashtagFTP

hashtagEmail

hashtagDNS

hashtagCDN