# 应用层原理

# 网络应用体系结构

  • 客户 - 服务器模式(C/S:client/server)
  • 对等模式(P2P:Peer To Peer)
  • 混合体:客户 - 服务器和对等体系结构

# 客户 - 服务器体系结构

# 服务器

  • 一直运行
  • 固定的 IP 地址和周知的端口号
  • 扩展性,数据中心进行扩展,扩展性差

# 客户端

  • 主动与服务器通信
  • 与互联网有间歇性的连接
  • 可能是动态 IP
  • 不直接与其他客户端通信

# 对等体(P2P)体系结构

  • 没有一直运行的服务器
  • 任意端系统之间可以进行通信
  • 每一个节点既是客户端又是服务器
  • 参与的主机间歇性连接且可以改变 IP 地址

# C/S 和 P2P 体系结构混合体

# Napster

  • 文件搜索:集中
    • 主机在中心服务器上注册其资源
    • 主机向中心服务器查询资源位置
  • 文件传输:P2P
    • 任意 Peer 节点之间

# 即使通信

  • 在线检测:集中
    • 当用户上线,向中心服务器注册其 IP 地址
    • 用户与中心服务器联系,以找到其他在线好友位置
  • 两个用户之间聊天:P2P

# 进程通信

# 进程

​ 在主机上运行的应用程序

  • 在用一个主机内,使用进程间的通信机制通信(操作系统定义)

  • 不同主机通过交换报文(Message)来通信

  • 使用OS提供的通信服务
    
  • 按照应用协议交换报文,借助传输层提供的服务
    
  • P2P架构的应用也有客户端进程和服务器进程之分
    

# 分布式进程通信需要解决的问题

  1. 进程标识和寻址问题

  2. 传输层 - 应用层提供服务是如何
    - 位置:层间界面的 SAP(TCP/IP:socket)
    - 形式:应用程序接口 API(TCP/IP:socket API)

  3. 如何使用传输层提供的服务,实现应用进程间的报文交换,实现应用
    - 定义应用层协议:报文格式,解释,时序
    - 编制程序,使用 OS 提供的 API,调用网络基础设施提供通信服务传报文,实现应用时序

# TCP 之上的套接字(socket)

  • 对于使用面向连接服务(TCP)的应用而言,套接字是 4 元组的一个具有本地意义的标识
    • 4 元组:(源 IP,源 port,目的 IP,目标 port)
    • 唯一的制定了一个会话(进程之间)
    • 应用使用这个标识,与远程应用进程通信
    • 不必在每一个报文的发送都要指定这 4 元组

# UDP 之上的套接字(socket)

  • UDP 服务,两个进程之间的通信需要之前无需要建立连接
    • 每个报文都是独立传输的
    • 以后报文可能给不同的分布式进程
  • 因此只能用一个整数表示本应用实体的标示
    • 因为这个报文可能传给另外一个分布式进程
  • 穿过层间接口的信息大小最小
  • UDP socket:本 IP,本端口
  • 传输报文时,必须要提供对方 IP,port
    • 接收报文时,传输层需要上传对方的 IP,port

# 应用层协议

  • 定义了运行在不用端系统上的应用进程如何相互交换报文
    • 交换的报文类型:请求和应答的报文
    • 各种报文类型的语法:报文中各个字段及其描述
    • 字段的语义:即字段取值的含义
    • 进程何时,如何发送报文及对报文进行响应的规则
  • 应用协议仅仅是应用的一个组成部分
    • Web 应用:HTTP 协议,web 客户端,web 服务器,HTML

# 应用需要传输层提供的服务

# 数据丢失率

  • 有些应用则要求 100% 的可靠数据传输
  • 有些应用能容忍一定比例以下的数据丢失

# 延迟

  • 一些应用处于有效性考虑,对数据传输有严格的时间限制

# 吞吐

  • 一些应用必须需要最小限速的吞吐,从而使得应用能够有效运转
  • 一些应用能充分利用可提供的吞吐

# 安全性

  • 机密性
  • 完整性
  • 可认证性

# Internet 传输层提供的服务

# TCP 服务

  • 可靠的传输服务
  • 流量控制:发送方不会淹没接收方
  • 拥塞控制:当网络出现拥塞,能抑制发送方
  • 不能提供的服务:时间保证,最小吞吐保证和安全
  • 面向连接:要求在客户端的进程和服务器之间建立连接

# UDP 服务

  • 不可靠数据传输
  • 不提供的服务:可靠,流量控制,拥塞控制,时间,带宽保证,建立连接

# Web 与 HTTP

# HTTP 概况

HTTP:超文本传输协议

  • Web 的应用层协议
  • 客户 / 服务器模式
    • 客户:请求,接收和显示 Web 对象的浏览器
    • 服务器:对请求进行响应,发送对象的 Web 服务器
  • HTTP 1.0:RFC 1945
  • HTTP 1.1:RFC 2068

# 非持久的 HTTP 连接

  1. HTTP 客户端在端口号 80 发起一个到服务器的连接
  2. 位于主机的 HTTP 服务器在 80 号端口下等待连接,接收连接并通知客户端
  3. HTTP 客户端向 TCP 连接的套接字发送 HTTP 请求报文,报文表示客户端需要对象
  4. HTTP 服务器接收到请求报文,检索出被请求的对象,将对象封装在一个响应报文,并通过其套接字向客户端发送
  5. HTTP 关闭 TCP 连接
  6. HTTP 客户端收到包含 html 文件的响应报文,并显示 html,然后对 html 文件进行检查,找到引用对象
  7. 对对象重复 1-5 步

# 响应时间模型

# 往返时间 RTT

一个小的分组从客户端到服务器,在回到客户端的时间

# 响应时间

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

image-20221208155829634

# 持久的 HTTP 连接

# 非持久 HTTP 的缺点

  • 每个对象需要 2 个 RTT
  • 操作系统必须为每个 TCP 连接分配资源
  • 浏览器通常打开并行 TCP 连接,以获取引用对象

# 持久 HTTP

  • 服务器在发送响应后,仍保持 TCP 连接
  • 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
  • 客户端在遇到一个引用对象的时候,就可以直接发送该对象的请求

# 非流水方式的持久 HTTP

  • 客户端只能在收到一个响应后才能发出信息请求
  • 每个引用对象花费一个 RTT

# 流水方式的持久 HTTP

  • HTTP/1.1 的默认模式
  • 客户端遇到一个引用对象就立即产生一个请求
  • 所有引用对象只花费一个 RTT 是可能的

# HTTP 请求报文

  • 两种类型的 HTTP 报文:请求响应
  • HTTP 请求报文:
  • image-20221208161059433

# HTTP 请求报文通用格式

image-20221208161351921

# HTTP 响应报文

image-20221208161953357

# HTTP 响应状态码

  • 200 OK
    • 请求成功,请求对象包含在响应报文的后续部分
  • 301 Moved Permanently
    • 请求的对象已经被永久转移了,新的 URL 在响应报文的 Location 首部行中指定
    • 客户端软件自动用新的 URL 去获取对象
  • 400 Bad Request
    • 一个通用的差错代码,表示该请求不能被服务器解读
  • 404 Not Found
    • 请求的文档在该服务上没有找到
  • 505 HTTP Version Not Supported

# 用户 - 服务器状态:cookies

# 组成部分

  1. 在 HTTP 响应报文中有一个 cookie 的首部行
  2. 在 HTTP 请求报文含有一个 cookie 的首部行
  3. 在用户端系统中保留有一个 cookie 文件,由用户的浏览器管理
  4. 在 Web 站点有一个后端数据库

# Cookie 维护状态

image-20221208163650441

# Web 缓存(代理服务器)

== 目标:== 不访问原始服务器,就满足客户的需求

  • 用户设置浏览器,通过缓存访问 Web
  • 浏览器将所有 HTTP 请求发送给缓存
    • 在缓存中的对象:缓存直接返回对象
    • 如对象不存在缓存,缓存请求原始服务器,然后再将对象返回给客户端

image-20221208164147571

  • 缓存既是客户端又是服务器端
  • 通常缓存是由 ISP 安装

# FTP

# FTP 文件传输协议

image-20221208175534148

  • 向远程主机上传输文件或从远程主机接收文件
  • 客户 / 服务器模式
    • == 客户端:== 发起传输的一方
    • == 服务器:== 远程主机
  • ftp:RFC 959
  • ftp 服务器:端口号 21

# FTP 控制连接与数据连接分开

  • FTP 客户端与 FTP 服务器通过端口 21 联系,并使用 TCP 为传输协议
  • 客户端通过控制连接获得身份确认
  • 客户端通过控制连接发送命令浏览远程目录
  • 收到一个文件传输命令时,服务器打开一个到客户端的数据连接
  • 一个文件传输完成后,服务器关闭连接
  • 服务器打开第二个 TCP 数据连接来传输另一文件
  • 控制连接:== 带外(out of band)== 传送
  • FTP 服务器维护用户的状态信息:当前路径,用户账户与控制连接对应

image-20221208180948351

# 电子邮件(EMail)

# 三个主要组成部分

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

# 用户代理

  • 又名邮件阅读器
  • 撰写,编写和阅读邮件
  • 输出输入邮件保存在服务器上

image-20230421214623702

# EMail 邮件服务器

# 邮件服务器

  • 邮箱中管理和维护发送给用户的邮件
  • 输出报文队列保持待发送邮件报文
  • 邮件服务器之间的 SMTP 协议发送 email 报文
    • 客户:发送方邮件服务器
    • 服务器:接收端邮件服务器

# EMail:SMTP

  • 使用 TCP 在客户端和服务器之间传送报文,端口为 25
  • 直接传输:从发送方服务区到接收方服务器
  • 传输的三个阶段
    • 握手
    • 传输报文
    • 关闭
  • 命令 / 响应交互
    • 命令:ASCII 文本
    • 响应:状态码和状态信息
  • 报文必须为 7 位 ASCII 码
  • SATP 使用持久连接
  • SMTP 服务器使用 CRLF 决定报文的尾部

# 邮件访问协议

image-20230421214658743

  • SMTP:传送到接收方的邮件服务器
  • 邮件访问协议:从服务器访问邮件
    • POP:邮局访问协议(Post Office Protocol)
      • 用户身份确认(代理 <--> 服务器)并下载
    • IMAP:Internet 邮件访问协议
      • 更多特性
      • 在服务器上处理存储报文
    • HTTP
      • 方便

# POP3 协议

# 用户确定阶段

  • 客户端命令
    • user:声明用户名
    • pass:口令
  • 服务器响应
    • +OK
    • -ERR

# 事务处理阶段

  • list:报文号列表
  • retr:根据报文号检索报文
  • dele:删除
  • quit

# IMAP 协议(远程管理文件夹)

  • IMAP 服务器将每个报文与另一个文件夹联系起来
  • 允许用户用目录来组织报文
  • 允许用户读取报文组件
  • IMAP 在会话过程中保留用户状态
    • 目录名,报文 ID 与目录名之间的映射

# DNS

# DNS 的必要性

  • IP 地址识别主机,路由器
  • 但 IP 地址不好记忆,不便人类使用
  • 人类一般倾向于用一些有意义的字符串来标示 Internet 上的设备
  • 存在着字符串 ——IP 地址的转换必要性
  • 人类用户提供要访问机器的字符串名称
  • 由 DNS 负责转换为二进制的网络地址

# DNS 总体思路和目标

# DNS 主要思路

  • 分层的,基于域的命名机制
  • 若干分布式的数据库完成名字到 IP 地址的转换
  • 运行在 UDP 之上的端口号为 53 的应用服务
  • 核心的 Internet 功能,但以应用层协议实现在网络边缘处理的复杂性

# DNS 的主要目的

  • 实现主机名 - IP 地址的转换
  • 其他目的
    • 主机别名规范名字的转换
    • 邮件服务器别名到邮件服务器的正规名字的转换
    • 负载均衡

# DNS 名字空间

image-20221209164442505

# TLD 服务器

  • 顶级域(TLD)服务器:负责顶级域名和所有国家级域名

# P2P

# P2P 架构

  • 没有一直运行的服务器
  • 任意端系统都可以直接通信
  • 利用 peer 的服务能力
  • Peer 节点间歇上网,每次 IP 地址都有可能变化

# 文件分发时间:C/S 模式

  • 服务器传输:都是由于服务器发送给 peer,服务器必须顺序传输 N 个文件拷贝
  • 客户端:每个客户端必须下载一个文件拷贝

# 文件分发时间:P2P

  • 服务器传输:至少需要上载一份拷贝
  • 客户端:每个客户端必须下载一个拷贝

# 查询洪泛:Gnutella

  • 全分布式
    • 没有中心的服务器
  • 开放文件共享协议
  • 许多 Gnutella 客户端实现了 Gnutella 协议
    • 类似 HTTP 有许多的浏览器
  • 如果 X 和 Y 之间有一个 TCP 连接,则二者之间存在一条边
  • 所有活动的对等方和边就是覆盖网路
  • 边并不是物理链路

# Gnutella:协议

  • 在已有的 TCP 连接上发送查询报文
  • 对等方转发查询报文
  • 以反方向返回查询命中报文

# CDN

# 多媒体流化服务

DASH:Dynamic Adaptive Streaming over HTTP

# 服务器

  • 将视频文件切割成多块
  • 每个块独立存储,编码于不同码率
  • 告示文件(manifest file):提供不同块的 URL

# 客户端

  • 先获取告示文件
  • 周期性地测量服务器到客户端的带宽
  • 查询告示文件,在一个时刻请求一个块,HTTP 头部指定字节范围
  • 如果带宽足够,选择最大码率的视频块
  • 会话中的不同时刻,可以切换请求不同的编码块(取决于当时的带宽)

# 内容分发网络 CDN

  • 通过 CDN(Content Distribution Networks),全网部署缓存节点,存储服务内容,就近为用户提供服务,提高用户体验
  • 在 CDN 节点中存储内容的多个拷贝
  • 重定向到最近的拷贝,请求回答
  • 如果网络路径拥塞,可以选择不同的拷贝

enter deep:将 CDN 服务器神日到许多接入网,更接近用户,数量多,离用户近,管理困难

bring home:部署在少数关键位置,如将服务器簇安装于 POP 附近,采用租用线路讲服务器簇连接起来

OTT(over the top)挑战:在拥塞的互联网上复制内容

# 套接字编程

# TCP 套接字编程

# 服务器首先运行,等待连接建立

1)服务器进程必须先处于运行状态

创建欢迎 socket 和本地端口捆绑

在欢迎 socket 上阻塞式等待接收用户的连接

3)当于客户端连接请求到来时

服务器接受来自用户端的请求,解除阻塞式等待,返回一个新的 socket(与欢迎 socket 不一样),与客户端通信

允许服务器与多个客户端通信

使用源 IP 和源端口来区分不同的客户端

# 客户端主动和服务器建立连接

2)创建客户端本地套接字(隐式捆绑到本地 port)

指定服务器进程的 IP 地址和端口号,与服务器进程连接

4)连接 API 调用有效时,客户端 P 与服务器建立了 TCP 连接

TCP 在客户端和服务器进程之间

提供了可靠的,字节流(管道)服务

img

# UDP 套接字

img

更新于 阅读次数

请我喝[茶]~( ̄▽ ̄)~*

Baozi 微信支付

微信支付

Baozi 支付宝

支付宝

Baozi 微信

微信