计算机网络：自顶向下方法 课程学习随笔——第二章 应用层

2.1 应用层概述

本章学习路线：原理 → 实例 → 编程

1. 网络应用的原理：网络应用协议的概念和实现方面

   • 传输层的服务模型

   • 客户-服务器模式

   • 对等模式

   • 内容分发网络

2. 网络应用的实例：互联网流行的应用层协议

   • HTTP

   • FTP

   • SMTP/POP3/IMAP

   • DNS

3. 编程：网络应用程序 socket api

2.2 网络应用的原理

网络应用的体系结构

1. 可能的应用架构分为三个：

   • 客户-服务器模式

   • 对等模式

   • 混合体

• 客户-服务器体系结构

  • 服务器：

    • 一直运行

    • 固定的IP地址和周知的端口号（约定）

    • 扩展性：服务器场

      • 数据中心进行国战

      • 扩展性太差（达到某个阈值，性能会出现断崖式下降）

  • 客户端

    • 主动与服务器通信

    • 与互联网有间歇性的连接

    • 可能是动态IP地址

    • 不直接与其他客户端通信

• 对等体体系结构

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

  • 任意端系统之间可以通信

  • 每一个节点即使客户端也是服务器端

    • 自扩展性-新peer节点带来新的服务能力，当然也带来新的服务请求

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

    • 难以管理

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

  1. Napster

     • 文件搜索：集中

       • 主机在中心服务器上注册其资源

       • 主机向中心服务器查询资源位置

     • 文件传输P2P

       • 任意peer节点之间

  2. 即时通信

     • 在线检测：集中

       • 当用户上线时，向中心服务器注册其IP地址

       • 用户与中心服务器联系，以找到其在线好友的位置

     • 两个用户之间聊天：P2P

进程通信

• 进程

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

  • 客户端进程： 发起通信的进程

  • 服务器进程： 等待连接的进程

  在同一个主机内，使用进程间通信机制通信（操作系统定义）

  不同职级，通过交换报文来通信

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

  • 问题1：对进程进行编制（addressing）进程标示和寻找问题（服务用户）

    标示自己是唯一的，同时能够寻找到自己

    本质上，传输层引入了port（端口号） 解决这个问题

    • 进程为了接收报文，必须要有一个标识：

      • 主机：唯一的32位IP地址（只能区分主机，但是对主机上运行的进程无法区分）

      • 所采用的传输层协议：TCP or UDP

      • 端口号（Port Number）

    • 一堆主机进程之间的通信由2个端节点构成

  • 问题2：传输层提供的服务-需要穿过层间的信息（服务）

    • 位置：层间界面的SAP（TCP/IP： socket）

    • 形式：应用程序接口API

    

    • 层间接口必须要携带的信息（可以和快递类比）

      • 要传输的报文是什么？（即SDU）

      • 谁传的？（IP+TCP(UDP) 端口）

      • 传给谁？（对方的IP+TCP(UDP) 端口）

    • 传输层实体（TCP/UDP实体）根据这些信息进行封装（TCP报文段、UDP数据报）

      • 源端口号、目标端口号、数据等

      • 将IP地址往下交IP实体，用于封装IP数据报

    • 每次都传这三个信息很麻烦，那么怎么要减少传输的信息量呢？

      • 用个代号标示通信的双方或者单方：socket

        • TCP socket，实际上是4元祖的一个具有本地意义的表示（源IP，源port，目标IP，目标port），这样应用层和传输层之间只需要传输一个整数就好了，不需要每次传输所有的数据：

          • TCP服务需要建立连接，通信关系稳定

          • 使用一个整数表示两个应用实体之间的通信关系，本地表示

          • 穿过层间接口的信息量最小

          • 本质上代表的是一个会话关系

          

        • UDP socket

          • 两个进程之间的通信之前无需建立连接关系

            • 每个报文独立传输

            • 前后报文可能分给了不同的进程

          • 只能用一个整数表示本应用实体的标示，因此UDP socket只包含本机的IP和端口号

          • 所以，在应用层和传输层之间通信的时候，必须要提供对方的IP和端口号

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

    • 定义应用层协议：报文格式，解释，时序等

    • 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等。

应用层协议

1. 定义：运行在不同端系统上的应用进程如何相互交换报文

   • 交换的报文类型：请求和应答报文

   • 各种报文类型的语法：报文中的各个字段描述

   • 字段的语义

   • 进程何时、如何发送报文及对报文效应的规则

   需要注意：应用协议仅仅是应用的一个组成部分

2. 分类：公开协议（由RFC文档定义、允许互相操作）和私有协议

3. 应用层对传输层服务的描述与要求（性能指标）：

   • 数据丢失率

   • 延迟

   • 吞吐

   • 安全性

UDP存在的必要性

• 能够区分不同的进程，而IP服务是不能的

  • 在IP提供的主机到主机、端到端功能的基础上，区分了主机的应用进程

• 无需建立连接，省去了建立连接的时间，适合事务性的应哟红

• 不做可靠性的工作， 例如检错重发，适合那些对实时性要求比较高二队正确性要求不高的应用

• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据

2.3 WEB和HTTP

一些术语

• Web页：由一些对象组成

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

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

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

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

• URL格式：

  

HTTP

• HTTP概况

  HTTP：超文本传输协议

  • Web的应用层协议

  • 客户/服务器模式

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

    • 服务器：对请求进行响应，发送对象的Web服务器

      

  • HTTP 1.0：RFC 1945

  • HTTP 1.1：RFC 2068

  • ！！！HTTP是无状态的

    • 服务器并不维护关于客户的任何信息

• HTTP连接的分类

  • 非持久HTTP（TCP连接请求、TCP连接确认、HTTP请求、HTTP确认、TCP断开请求、TCP断开确认）

    • 最多只有一个对象在TCP连接上发送

    • 下载多个对象需要多个TCP连接

    • HTTP/1.0使用非持久连接

      

    • 往返时间RTT： 一个小分组从客户端到服务器，在回到客户端的时间（传输时间忽略）

      

    • 缺点：

      • 每个对象要2个RTT

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

  • 持久HTTP（TCP连接请求、TCP连接确认、HTTP请求、HTTP确认、HTTP请求、HTTP确认……）

    • 服务器在发送响应后，仍保持TCP连接

      • 非流水方式

        • 客户端只能在收到前一个请求的响应后才能发出新的请求

        • 每个引用对象花费一个RTT

      • 流水方式

        • HTTP/1.1默认

        • 客户端遇到一个引用对象就立即产生一个请求

        • 所有引用对象只花费一个RTT是可能的

    • 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送

    • 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求

• HTTP报文

  • 请求

    • ASCII（人工可以阅读）

      
      

    • Post方式（客户端向服务器提交信息）

      • 网页通常包括表单输入

      • 包含在实体主体（Entity Body）中的输入被提交到服务器

    • Get方式（客户端向服务器提交信息）

      • 输入通过请求航的URL字段上载

      

  • 响应

    

    ！！！所有TCP上的应用进程是自己维护自己包之间的界限（Content-Length）

    • 响应状态码：

      • 200 OK → 请求成功，请求对象包含在响应报文的后续部分

      • 301 Moved Permanently

        • 请求的对象已经被永久转移了，新的URL在响应报文的Location在首部行中指定

        • 客户端软件自动用新的URL去获取对象

      • 400 Bad Request → 一个通用的差错代码，表示该请求不能被服务器解读

      • 404 Not Found → 请求的文档在该服务上没有找到

      • 505 HTTP Version Not Supported

• 用户-服务器状态：cookies

  注意：HTTP是无状态的，无记忆的。但是对于一些门户网站，服务器需要维护用户状态，因此使用cookie

  • 组成：

    • 在HTTP响应报文中有一个cookie的首部行

    • 在HTTP请求报文含有一个cookie的首部行

    • 在用户端系统中保留有一个cookie文件，由用户的浏览器管理

    • 在Web站点有一个后端数据库

    

• Web缓存

  目标：不访问原始服务器，就满足客户的请求

  • 用户设置浏览器：通过缓存访问Web

  • 浏览器将所有的HTTP请求发给缓存

    • 在缓存中的对象：缓存直接返回对象

    • 如果对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端

  为什么使用Web缓存？

  • 降低客户端的请求响应时间

  • 可以大大减少一个机构内部网络与Internet接入链路上的流量

  • 互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容

  

2.4 FTP

1. 文件传输协议简介

   

   • 向远程主机上传输文件或从远程主机接收文件

   • 客户/服务器模式

     • 客户端：发起传输的以防

     • 远程主机

   • ftp：RFC 959

   • ftp服务器：端口号为21

2. 连接建立过程

   客户端和服务器通过TCP传输，使用端口21

   客户端通过控制连接获取身份认证

   客户端通过控制连接发送命令浏览服务器目录

   收到一个文件传输命令时，服务器打开一个到客户端的数据连接（TCP连接，端口为20）

   传输结束后，服务器关闭连接

2.5 EMAIL

• 组成

  

  • 用户代理（客户端）

    也称为“邮件阅读器”，撰写、编辑和阅读邮件，如Outlook、Foxmail等。其输出和输入邮件保存在服务器上

  • 邮件服务器

    邮箱中管理和维护发送给用户的邮件，输出报文队列保持发送邮件报文

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

    • 客户：发送方邮件服务器

    • 服务器：接收端邮件服务器

  • 简单邮件传输协议：SMTP

    • 使用TCP协议，端口号为25

    • 直接传输：从发送方服务器到接收方服务器

    • 传输3个阶段：握手、传输报文、关闭

    • 命令/响应交互

      • 命令：ASCII文本

      • 响应：状态码和状态信息

    • 报文必须为7位ASCII码

• 报文格式

  1. 首部行，如：To、From、Subject、CC等

  2. 主体，只能包含ASCII码字符的报文

  3. 多媒体扩展

     • MIME：多媒体邮件扩展

     • 在报文首部用额外的行申明MIME内容类型

       

• 邮件访问协议

  • SMTP：传送到接收方的邮件服务器

  • 邮件访问协议：从服务器访问邮件

    • POP：邮局访问协议

      • 用户身份确认（代理 服务器）并下载

    • IMAP：Internet邮件访问协议

      • 在服务器上处理存储的报文

    • HTTP： Hotmail、 Yahool Mail等（比较方便）

  • POP3协议：

    

    • 用户确认阶段

      • 客户端命令：

        • user：用户名

        • pass：口令

      • 服务器响应

        • +OK

        • -ERR

    • 事务处理阶段（客户端）

      • list：报文号列表

      • reterr：根据报文号检索报文

      • dele：删除

      • quit

2.6 DNS

1. 必要性

IP地址标识主机、路由器，但是IP地址不好记忆，不便于人类使用（没有意义）。人类一般倾向于使用一些有意义的字符串来标识Internet上的设备。因此需要有一套系统提供域名到IP地址的转换。

2. 需要解决的问题

• 问题1：如何命名设备？

  • 用有意义的字符串

  • 解决一个平面命名的重名问题：层次化命名

• 问题2：如何完成名字到IP地址的转换

  • 分布式的数据库维护和响应名字查询

• 问题3：如何维护？即增加或者删除一个域，需要在域名系统中做哪些工作？

总体思路和目标

• DNS的主要思路

  • 分层的、基于域的命名机制

  • 若干分布式的数据库完成名字到IP地址的转换

  • 运行在UDP之上端口号为53的应用服务

  • 核心的Internet功能，但是以应用层协议实现（在网络边缘处理复杂性）

• 目的：

  • 实现主机名-IP地址的转换（最主要！！！）

  • 主机别名到规范名字的转换（Host aliasing）、邮件服务器别名到邮件服务器正规名字的转换（Mail server aliasing）、负载均衡（Load distribution）

DNS名字空间

1. 域名结构

   • 一个层面命名设备会有很多的重名，DNS采用层次树状结构的命名方法

   • Internet根被划分为几百个顶级域

     • 通用的：.com .edu .gov .int .mil . net等

     • 国家的：.cn .us .nl .jp等

   • 每个（子）域下面可划分为若干子域

   • 树叶是主机

     

   • 域名

     • 从本域往上，直到树根，中间使用“.”间隔不同的级别

     • 域的域名：可以用于表示一个域

     • 主机的域名：一个域上的一个主机

2. 域名的管理

   • 一个域管理其下的子域（如.jp被划分为ac.jp co.jp，.cn被划分为edu.cn com.cn）

   • 创建一个新的域，必须征得他所属域的同意

3. 域与物理网络无关

   • 域遵从组织界限，而不是物理网络

     • 一个域的主机可以不在一个网络

     • 一个网络的主机不一定在一个域

   • 域的划分是逻辑的，而不是物理的

解析问题-名字服务器

• 一个名字服务器的问题

  • 可靠性问题：单点故障

  • 扩展性问题：通信容量

  • 维护问题：远距离的集中式数据库

• 区域

  • 区域的划分由区域管理者自己决定

  • 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分

  • 名字服务器：

    • 每个区域都有一个名字服务器：维护着其所管辖区域的权威信息

    • 名字服务器允许被放置在区域之外，以保障可靠性

    

  • TLD服务器

    • 顶级域（TLD） 服务器：负责顶级域名和所有国家级的顶级域名

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

  • 资源记录

    • 作用：维护 域名-IP地址（其他）的映射关系

    • 位置：Name Server的分布式数据库中

  • RR格式：

    • Domain name：域名

    • TTL：生存时间（如果是有限的，那么会在一定时间后被删掉：缓冲是为了性能和效率，删除是为了一致性）

    • Class列表：对于Internet，值为IN

    • Value：可以是数组，域名或者ASCII串

    • Type类别：资源记录的类型

      • A：Name为主机，Value为IP地址

      • NS：Name为域名，Value为该域名的权威服务器的域名（子域）

      • CNAME：Name为规范名字的别名，Value为规范名字

      • MX：Value为Name对应的邮件服务器的名字

• DNS工作过程

  • 应用调用解析器（resolver）

  • 解析器作为客户向Name Server发出查询报文（封装在UDP段中）

  • Name Server返回响应报文（name/IP）

    

• 本地名字服务器（Local Name Server）

  • 不是严格属于层次结构

  • 每个ISP都有一个本地DNS服务器

  • 当一个主机发起一个DNS查询时，查询被送到其DNS服务器（起着代理的作用，将查询转发到层次结构中）

• 名字解析过程和方法

  • 名字解析过程：

    • 如果名字在本地名字服务器中，则会出现两种情况：

      • 查询的名字在该区域的内部

      • 缓存

    • 当与本地名字服务器不能解析名字时，联系根名字服务器，然后顺着根-TLD一直找到权威名字服务器

  • 两种查询方式

    • 递归查询

      • 名字解析负担都放在当前联络的名字服务器中

      • 存在的问题：根服务器的负担太重

      

    • 迭代查询

      • 根（及各级域名）服务器返回的不是查询结果，而是下一个NS的地址

      • 最后由权威名字服务器给出解析结果

      • 当前联络的服务器给出的是可以继续联系的服务器的名字（如“我不知道你要找谁，但是你可以问他”）

      

• DNS协议、报文

  查询和响应报文的报文格式相同

  

  

维护问题：新增一个域

• 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名 和 域名服务器的地址

• 在新增子域的名字服务器上运行名字服务器，负责本域的名字解析：名字→IP地址

2.7 P2P

纯P2P架构

• 没有（或极少）一直运行的服务器

• 任意端系统都可以直接通信

• 利用peer的服务能力

• peer节点间歇上网，每次IP地址都有可能变化

文件分发

• C/S vs P2P

  • 从一台服务器分发文件（大小为F）到N个peer需要多少时间呢？

  • Peer节点上下载能力是有限的资源

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kUiuAtlE-1658113619426)(image/image_AOGQSDW3kG.png)]

  • C/S模式

    • 服务器传输：都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝

    • 客户端：每个客户端必须下载一个文件拷贝

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7NSGuN8c-1658113619426)(image/image_hqvJ4cWk3E.png)]

  • P2P模式

    • 服务器传输：最少需要上载一份拷贝（发送一个拷贝的时间为$F/U_s$）

    • 客户端：每个客户端必须下载一个拷贝；但是除了服务器可以上载外，其他所有的peer节点都可以上载

    

• P2P文件共享

  • 一个例子

    

  • 两个问题

    • 如何定位所需要的资源？

    • 如何处理对等方的加入和离开？

  • 可能的方案：

    • 集中式

    • 分散式

    • 半分散式

  • 集中式目录

    • 当对等方连接时，它告诉中心服务器：IP地址、内容

      

    • 存在问题

      • 单点故障

      • 性能瓶颈

      • 侵犯版权

  • 分布式

    • 没有中心服务器

    • 开放文件共享协议

    • 查询方式：泛洪（需要对泛洪进行范围的限制）

      • 在已有的TCP连接上发送查询报文

      • 对等方转发查询报文

      • 以反方向返回查询命中报文

    • 对等方加入

      • 对等方X必须首先发现某些已经在覆盖网络中的其他对等方：使用可用对等方列表（自己维护一张对等方列表）

      • X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方Y建立连接

      • X向Y发送一个Ping报文，Y转发该Ping报文

      • 所有收到Ping报文的对等方以Pong报文响应

      • X收到许多Pong报文，然后它能建立其他TCP连接

  • 半分布式

    • 每个对等方要么是一个组长，要么隶属于一个组长

      • 对等方与其组长之间存在TCP连接

      • 组长对之间有TCP连接

    • 组长跟踪所有的孩子的内容

    • 组长与其他组长联系

      • 转发查询到其他组长

      • 获得其他组长的拷贝数据

    • 查询

      • 每个文件有一个散列标识码和一个描述符

      • 客户端向其组长发送关键字查询

      • 组长用匹配进行响应（对每个匹配：元数据、散列标识码和IP地址）

      • 如果组长将查询转发给其他组长，其他组长也以匹配进行响应

      • 客户端选择要下载的文件（向拥有文件的对等方发送一个带散列标识码的HTTP请求）

• P2P文件分发：BitTorrent

  • 文件被分为一个个块（256KB）

  • 网络中的这些peers发送接收文件块，相互服务

2.8 CDN

• 视频流化服务和CDN：上下文

  • 挑战：

    • 规模性——如何向很多用户提供服务

    • 异构性——不同用户拥有不同的能力

  • 解决办法

    • 挑战：服务器如何通过网络向上百万用户同时流化视频内容？

      • 选择1：单个的、大的超级服务中心“megaserver”

        • 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿

        • “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）

        • 单点故障点，性能瓶颈

        • 周边网络的拥塞

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

        • enter deep：将CDN服务器深入到许多接入网

          • 更接近用户，数量多，离用户近，管理困难

        • bring home：部署在少数（10个左右）关键位置，如将服务器簇安装于POP附近