“ 食物链 “ 顶端的 《应用层》原理总结

应用层协议原理

创建一个新的网络应用

（1）$编程$

• 能够在不同的端系统上运行
• 通过网络基础设施提供的服务，使应用进程间彼此通信
• 如 Web：
  • Web服务器软件与浏览器软件间的通信

（2）$网络核心中没有应用层软件$

• 网络核心设备并不在应用层起作用，即网络核心没有应用层功能
• 网络应用被限制在端系统上
  • 加速了网络应用的开发和部署

$核心$：编写出能够在 不同端系统 和 通过网络彼此通信 的应用

应用程序体系结构

• 从研发者角度来看，网络体系结构是固定的，并为应用程序提供特定的服务集合
• 由应用程序研发者设计，规定如何在各种端系统上组织该应用程序

（1）$C/S体系结构$

• 服务器：
  • 一个一直运行的主机
  • 固定的IP地址、周知的端口号（约定）
  • 服务客户主机的请求
  • 常出现一台单独的服务器主机跟不上所有客户请求情况（宕机）
  • 拓展性：通过建立服务器场
    • 数据中心（配置大量的主机）进行拓展
    • 拓展性差
• 客户端
  • 主动与服务器进行通信
  • 与互联网有间歇性的连接
  • 可能是动态的IP地址
  • 不直接与其他客户端进行通信

（2）$P2P体系结构$

• （几乎）没有一直运行的服务器

• 任意端系统之间可以直接进行通信

• 每一个节点既可以是客户端又可以是服务器

  • $自拓展性$：

    新的 peer（对等）节点带来服务请求，但也带来新的服务能力

• 参与通信的主机间歇性连接且可以动态改变IP地址

  • $难以管理$

• 例子：Gnutella，迅雷

（3）$C/S和P2P体系结构的混合体$

• Napster

  • 文件搜索：集中
    • 主机在中心服务器上注册其资源
    • 主机向中心服务器查询资源的地址
  • 文件传输：P2P
    • 任意对等节点之间进行通信传输

• 即时通行

  • 在线检测：集中
    • 当有用户上线时，就会中心服务器注册其IP地址
    • 用户与中心服务器进行联系，以找到器在线好友的位置
  • 两个用户之间的聊天：P2P

进程通信

$进程$：在主机上运行的应用程序

• 在同一个主机内，使用$进程间通信机制$进行通信（操作系统定义）
• 不同主机，通过交换$报文$来进行通信
  • 使用OS（操作系统）提供的通信服务
  • 按照应用协议交换报文
    • 借助传输层提供的服务

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

问题 1： 进程标识和寻址问题（服务用户）

• 进程为了接受报文，必须有一个 $标识$

  即 SAP（发送也需要标识）

  • 主机：有唯一的32位的 $IP地址$
    • 但是仅仅有IP地址并不能唯一标识一个进程，因为一般而言一台端系统上有很多应用进程在运行
  • 所采用的传输层协议：TCP or UDP
  • $端口号$（Port Number）：发送的进程被指定运行在接收主机上的接收进程

• 一些知名的端口号例子： 所有因特网标准协议的周知端口号列表

  • HTTP：TCP 80
  • Mail：TCP 25
  • ftp ： TCP 2

• 一个进程：用 IP + port标识端节点

• 本质上：一对主机进程之间的通信有2个端节点构成

问题 2：传输层-应用层是如何提供服务（服务）

$1.传输层提供的服务--需要穿过层间的信息$

• 层间接口必须要携带必要信息
  • 要传输的报文：对于本层来说：SDU
  • 谁传的：对方的应用进程的标识： IP + TCP（UDP）的端口号
  • 传给谁：对方的应用进程的标识：对方的IP + TCP（UDP）的端口号
• 传输层实体：TCP 或者 UDP实体（硬件/软件），根据这些信息进行TCP报文段（UDP数据报）的封装
  • 源端口号，目标端口号，数据等
  • 将 IP 地址往下交给IP实体，用于封装IP数据报文：源IP，目标IP

$2.传输层提供的服务--层间信息的代表$

​    ~ ~   对于传输的货物来说，每次都传输货物，IP + TCP（UDP）的端口号这三个信息，太繁琐易错，不便于管理，为了减少层间传输的信息量，可以采用Socket

• 用个代号标识通信的双方或者单方：TCP Socket（是一个本地的标号，对方并不知道）

  • 例如：建立一个TCP socket，实际上操作系统会返回一个整数，这个整数就可以代表 <我的IP，我的端口号，他的IP，他的端口号>这个四元组，以后当我通过这个socket去发送传输报文的时候，直接调用这个标识加速报文的传输

  

• 就像对OS打开文件返回的句柄一样

  • 对句柄的操作，就是对文件的操作

• $TCPsocket$：

  • TCP 服务，两个进程之间的通信之前需要建立连接
    • 两个进程通信通常会持续一段时间，通信关系稳定
  • 可以用一个整数表示两个应用实体之间的通信关系
    • $本地$的标识
  • 穿过层间接口的信息量 $最小$
  • TCP socket：源IP，源端口，目标IP，目标端口

• $TCP之上的套接字（socket）$

  ​ 对于使用面向连接服务（TCP）的应用而言，套接字是 4 元组的一个具有本地意义的标识

  • 4元组：< 源IP，源port，目标IP，目标port>

  • 唯一的指定了一个会话（2 个进程之间的会话关系）

  • 不必在每一个报文的发送都要指定这个4元组，而是直接操作这个整数

  • 就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名，文件名

  • 简单，便于管理

• $UDPsocket$：

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

• $UDP之上的套接字（socket）$

  ​ 对于使用无连接服务（UDP）的应用而言，套接字是 2 元组的一个具有本地意义的标识

  • 2元组：IP，port（发送源端指定）
  • UDP套接字指定应用所在的一个端节点（end point）
  • 在发送数据报文时，采用创建好的本地套接字（标识ID），这样就不必在发送每个报文中指明自己所采用的 IP和 port
  • 但是在发送报文时，必须指定对方的 IP 和 port （另一个端节点）

• $套接字$

  • 进程向套接字发送报文，或从套接字接收报文
  • 套接字 可类比为 门户
    • 发送进程时将报文推出门户（发送进程依赖于传输层设施在另一侧的门户将报文交付给接收进程）
    • 接收进程从另一侧门户收到报文（依赖于传输层设施）
  • 也被称为应用程序和网络之间的应用程序编程接口（API）

  

问题 3： 如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）

• 定义应用层协议：报文格式，解释，时序等等
• 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传输报文，实现应用时序等等

$1.应用层协议$

• 定义了：运行在不同端系统上的应用进程如何相互交换报文
  • 交换的报文类型：请求报文和应答报文
  • 各种报文类型的语法：报文中的各个字段及其描述
  • 字段的语义：即字段取值的含义
  • 何时进程，如何发送报文及报文进行应答的规则
• 应用层协议仅仅是应用的一部分
  • Web应用：HTTP协议，web客户端，web服务器，HTML
• $公开协议$：
  • 由RFC文档定义
  • 允许互操作
  • 如 HTTP，SMTP（简单邮件传输协议）
• $专用（私有）协议$：
  • 协议不公开
  • 如：Skypc

$2.应用需要传输层提供什么样的服务$

• $数据丢失率$
  • 有些应用要求100%的可靠数据传输（如文件）
  • 有些应用（如交谈式音频，视频）能容忍一定比例下的数据丢失
• $吞吐量$
  • 一些应用（如多媒体）必须需要最小限度的吞吐量，从而使得应用能够有效运转（带宽敏感应用）
  • 一些应用能够充分利用可供使用的吞吐量（弹性应用）
• $延迟$
  • 一些应用出于有效性考虑，对数据传输由严格的时间限制
    • Internet电话，交互式游戏
    • 延迟，延迟差
• $安全性$
  • 机密性
  • 完整性
  • 可认证性（端点鉴别）

$3.Internet传输层提供的服务$

• $TCP服务$
  • $可靠的传输服务$
  • $流量控制$：发送方不会淹没接收方
  • $拥塞控制$：当网络出现拥塞时，TCP的拥塞机制会抑制发送方
  • $不能提供的服务$：时间保证，最小吞吐量和安全性
  • $面向连接$：要求在客户端进程和服务器进程之间建立连接（结束报文发送时，必须拆除该连接）
• $UDP服务$
  • $不可靠的传输服务$
  • $不提供的服务$：可靠性，流量控制，拥塞控制，带宽保证，建立连接

思考 ： 为什么要有 UDP？（必要性）

• 能够区分不同的进程，而IP服务不能
  • 在IP提供的主机到主机端到端功能的基础上，区分了主机上的应用进程
• 无需建立连接：省去了建立连接的时间，适合事务性的应用
• 不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用
  • 因为如果为了实现可靠性（准确性，保序等等），必须付出时间的代价（检错重发）
• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
  • 而在TCP上的应用，应用发送数据的数据和主机向网络发送数据的实际速度是不一致的，因为有流量控制和拥塞控制

$TCP安全$

• $TCP\&UDP$
  • 都没有加密机制（发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同
  • 明文通过互联网传输，甚至密码
• $SSL(安全套接字层)$
  • 在TCP上面实现，提供加密的TCP连接
  • 私密性
  • 数据完整性
  • 端到端的鉴别
• $SSL在应用层$
  • 应用程序采用SSL库，SSL库提供TCP通信
• $SSLsocketAPI$
  • 应用通过API将明文数据交给socket，SSL将其加密在互联网上传输
  • 详细在第 8 章

应用层中的实例

$(1)Web\&HTTP$

• $Web页$：由一些$对象$组成

• 对象可以是 HTML文件，JPEG图像，Java小程序，声音剪辑文件等等

• Web页含有一个$基本的HTML文件$，该基本HTML文件又可以包含若干个对象的引用（链接）

• 通过$URL$对每个对象进行引用

• $访问协议，用户名，口令字，端口等等$

• URL格式：

• $HTTP$：超文本传输协议

• Web的应用层协议

• C/S模式（用户/服务器）

• 客户：请求，接收和显示Web对象的浏览器

• 服务器：对客户的请求做出响应，进而发送对象的Web服务器

  

• $使用TCP$ 作为运输协议（而不是在UDP上运行）

  • 客户发起一个与服务器的TCP连接（建立套接字），端口号为 80
  • 服务器接受客户的TCP连接请求
  • 在浏览器（HTTP客户端）与Web服务器（HTTP服务器server）交换HTTP报文（应用层协议报文）
  • TCP连接关闭

• HTTP是$无状态的$

  • 服务器并不维护关于客户的任何信息
    • 假如某个特定的客户在短短几秒内两次请求同一个对象，服务器并不会对刚刚已经向客户提供了该对象而不做出响应，而是重新发送该对象
  • 因为维护状态的协议是很复杂的
    • 必须维护历史信息（状态）
    • 如果 服务器 / 客户端死机，那么它们的状态信息可能不一致（但是通信过程中，我们必须保证二者的状态信息一致）
    • 无状态的服务器能够支持更多的客户端

• $FTP\ast$

• $Email，SMTP，POP3，IMAP$

• $DNS$

• $P2P应用$

• $CDN$

套接字编程

• TCP 套接字（Socket）编程

• UDP 套接字编程

以上内容尚未完全，随着今后学习的推进，我会继续对其进行补充与完善。