2.应用层

• 网络应用是计算机网络 存在的理由，没有应用也就没必要设计支持它们的网络协议了。
• 这章主要介绍了传输层协议TCP、UDP和应用层协议的关系，其中包括HTTP、SMTP、DNS、P2P，还简单介绍了这些协议的工作流程，还有CDN相关的原理，最后介绍了socket的使用。

应用协议原理：

• 主流 应用程序体系结构：客户-服务器结构；对等（P2P）体系结构。
• 客户-服务器结构：服务端响应所有接入客户端，配备大量主机的数据中心用于分压，很常见的体系结构，如电商阿里巴巴、亚马逊等，如搜索引擎百度、Google等都属于这种结构。
• P2P体系结构：服务端依赖较小，主要靠用户主机间直接通讯，这些主机称为对等方，生活最常见的迅雷就是使用这种技术进行下载，后续详细介绍。
• 进程：可以被认为是运行在端系统的一个程序，细化后通信实际上是在进程间进行的，而不是程序。端系统上的进程跨越网络交换报文相互通讯。
• 客户端&服务端：在客户-服务器结构中能很容易分清这两个概念，在P2P结构中，客户端就是发起通信的一方。
• 套接字：向网络发送报文和接收报文的 软件接口，位于应用层和运输层之间，也称为应用程序和网络之间的 应用程序接口（Application Programming Interface API）。
• 寻址：为了进程间发送分组，需要定义两个信息，目标主机的地址 IP地址和该主机接收程序的标识符 端口。
• 运输层协议能为应用程序提供什么：一共有四个标准，可靠的数据传输、吞吐量、定时和安全性。
  • 可靠数据传输：确保数据完整、无差错的交付。
  • 吞吐量：发送进程向接收进程交付比特的速率。比如网络波动就会影响吞吐量。
  • 定时：提供定时保证。
  • 安全性：安全性服务，如数据加密等机制。
• TCP简述（后续在传输层章节会具体分析）：
  • 面向连接：传输分组前会有握手的动作，提醒准备接收分组。传输完成后需断开。
  • 可靠的数据传输：TCP可提供无差错、按顺序的数据交付。
  • 拥塞控制：网络繁忙时会限制发送。
  • 安全：TCP和UDP本身都不提供加密机制，所以后续研制了SSL（secure socket layer）提供加密、数据完整性等机制，
  • SSL：SSL工作在应用层。发送方应用程序把明文数据发送到SSL套接字，加密后传递给TCP套接字，接收方解析获取数据。
• UDP简述：
  • 没有连接握手，所以无连接，没有可靠性保证，上面tcp提到的机制都没有，轻量级传输协议，因为没有各种机制所以相对TCP会快很多。
• 运输层协议主要是TCP/UDP，他们都没有对吞吐量和定时的限定，所以这两个标准也是研发人员自行根据场景规定、优化的方向。
• 应用层协议主要是为了定义：
  • 交换报文的类型，响应或请求报文。
  • 报文的语法。
  • 定义字段。
  • 确定何时发送。
• 后面小结主要分别介绍HTTP、邮件、DNS、P2P文件共享几个方向。

HTTP（超文本传输协议）：

• 多数web页面含有一个HTML基本文件以及几个引用对象（如图片、视频等等），通过URL地址引用对象，URL地址由主机名+路径构成，WEB浏览器实现了HTTP客户端，上面提到的客户-服务器结构。
• HTTP使用TCP作为支撑传输协议。使用HTTP前需要先建立TCP连接。
• HTTP是无状态协议，服务端不保存任何用户信息。
• HTTP允许持续连接，不用每个请求都创建单独的TCP连接，可以复用。
• 非持续连接流程：
  • 客户端在80端口（默认）发起一个TCP连接到服务端，并建立连接。
  • 客户端通过TCP连接发送HTTP请求报文。
  • 服务端接收报文，然后做出相应处理，返回响应报文。
  • 服务端通知TCP断开连接。
  • 客户端接收响应报文，确认后TCP连接断开，完成一个非持续HTTP连接流程。
• 持续连接：
  • HTTP1.1默认是持续连接。
  • 连接一定时间（可配置）未使用，服务器就会关闭该连接。
• HTTP请求报文格式：
  • 如图，第一行叫请求行，后面的叫首部行，请求行第一个值是方法字段，包括GET/POST/HEAD/PUT/DELETE；后面是请求对象和HTTP版本号。
  • HOST：指定目标所在主机。
  • Connect：close：声明使用非持续连接，不写默认就是长连接了。
  • User-agent：声明用户代理，即发送浏览器的类型。

  • Accept-language：响应报文的语法版本。

    
    
    请求报文样例
  • 使用POST方法时会多一个实体体，GET方法该位置为空，如图。
    
    请求结构
• HTTP响应报文格式：
  • 状态行、6个首部行、还有实体体。状态行分别是版本、状态码、状态信息。
  • Date：报文响应时间。
  • Server：服务器信息。
  • Last-Modified：对象创建或者最后修改的日期。
  • Content-Length：发送对象字节数。
  • Content-Type：实体体的类型。
• 常见状态码：200 - 成功，301 - 消息转发，404 - 请求的对象不存在等等。

响应结构

• Cookie：无状态协议下识别用户的方式：
  • 在HTTP响应的首部行中第一次出现。
  • 后面的请求通过把cookie加入首部行。
  • cookie保存在客户端。

Cookie

• web缓存（代理服务器）：通过客户端和服务端之间增加一个中间层，缓存请求对象，提高处理效率，如CDN，后面具体分析。

因特网中的电子邮件（简单描述）：

• 主要有三部分组成用户代理、邮件服务器、简单邮件传输协议。

• 从发送方用户代理开始，传输到发送方邮件服务器，在传输到接收方邮件服务器，最后分发到接收方邮箱中。

  
  
  电子邮件
• SMTP和HTTP：
  • HTTP主要是拉协议，在web服务区上装载信息，用户从服务器上拉取信息。
  • SMTP主要是推协议，发送邮件服务器把文件推到接收邮件服务器。
    
    image.png

DNS：因特网的目录服务：

• DNS主要是将域名转换成IP，方便人们记忆网站地址。
• DNS本质是一个分层的DNS服务器实现的分布式数据库，使主机能查询分布式数据库的应用层协议，DNS协议运行在UDP之上。
• 从主机web浏览器的角度观察DNS流程：
  • 主机上运行着DNS客户端。
  • 浏览器抽取出主机名类似www.xxx.com，传给DNS客户端。
  • DNS客户端向DNS服务端发送一个请求，其中包含主机名。
  • 响应的报文中包含转换后的IP
  • 向该IP的80端口发送HTTP协议前置的TCP连接请求，开始HTTP协议的流程。
• DNS还提供一些其他的服务，例如主机别名，负载分配等等。
• DNS服务大体分三类：根DNS服务器、顶级DNS服务器、权威DNS服务器。
  • 根DNS服务器：全世界一共400多个根DNS服务器，分别由13个不同组织管理，提供顶级DNS服务器的IP地址。
  • 顶级DNS服务器（TLD）：顶级域（如com、org、edu）和国家顶级域都有TLD，提供权威DNS服务器的IP地址。
  • 权威DNS服务器：存储着具体的域名和IP对应关系，公网访问的主机会在这里提供DNS记录。
  • 本地DNS服务器：这个不在DNS结构层次中，属于ISP（互联网服务供应商），离主机比较近，一般就是主机上配置的DNS服务器地址，作为DNS查询的代理。

DNS层次

• DNS内部工作机理描述：
  • 主机获取域名后，向本地DNS发送查询报文。
  • 本地DNS将报文转发到根DNS服务器，根DNS根据域名后缀（如com）返回TLD的IP列表。
  • 本地DNS再将报文转发到TLD，根据域名后缀（如aaa.com）返回权威DNS服务器IP。
  • 本地DNS再向权威DNS查询，就会查到用户最终想要域名的IP了（中间可能还会有深层的DNS服务器，多次查询流程一致）。
  • 本地DNS最终返回给主机。
• DNS流程并不是每次都会经历这样的流程，第一次请求后映射关系会缓存在DNS服务器本地，绝大部分请求都会命中缓存，直接返还给主机，这个缓存一段时间后会失效（通常是两天）。
• 共同实现DNS分布式数据库的所有DNS服务器存储了资源记录，提供了主机名和IP的映射。
• 资源记录包括四个字段（name，value，type，TTL），TTL是超时时间，主要分析type和name，value的关系。
  • type = A：name是主机名，value是主机名对应的IP。
  • type = NS：name是域（如foo.com），value是知道域中主机IP映射的权威DNS服务器的主机名，用于查询链路由。
  • type = CNAME：用于多域名映射某一域名，name是别名，value是规范域名。
  • type = MX：和CNAME类似，用于邮件服务。

• DNS报文：

  
  
  DNS报文结构
• 在DNS数据库中插入记录：向域名注册机构提供权威DNS服务器地址和IP，机构会在TLD中插入一条NS记录，一条A记录，用于TLD转到权威DNS服务器，当然，在权威DNS服务器里要确保所有查询的域名和IP映射存在，其他主机就可以通过本地DNS服务器按上面提到的流程进行DNS查询了。

P2P文件分发：

• 相比于常见的客户-服务器结构对等网络结构日常就少见一些，在对等网络结构中每个对等方都能帮助服务器分发文件，使用对等主机的上传能力发送给其他对等方（如迅雷看看就是这种结构）。

  
  
  P2P
• 客户服务器结构每次都会向服务器发起一次请求，使用量大时服务器只能通过扩容等方式缓解，P2P则是通过所有对等方互相帮助的形式缓解压力。
  
  两种结构耗时对比
• BitTorrent是一种流行的P2P协议下面通过这个协议分析一下。
• 特定文件分发的所有对等方集合被称为一个洪流（Torrent）。
• 对等方彼此下载等长的文件块（文件被分割），典型长度为256KB。
• 每个洪流有一个基础设施节点追踪器，对等方加入洪流时，需要向追踪器注册自己，并周期性的通知追踪器自己还在洪流中。
• BitTorrent流程：
  • 当有新对等方加入时（例如叫A），追踪器随机的从参与对等方的集合中选一个子集，并把子集所有IP发送给A，A与所有子集简历TCP连接，随着时间的流逝也会有新的加入建立连接，旧的离开断开连接。
  • 通过互相询问的方式知道所有的邻居手中有哪些块，当然A也要告诉邻居自己有哪些，这时需要决定向邻居请求哪些块或者向邻居提供哪些块。
  • 请求块时会使用最稀缺优先技术，意思就是优先获取邻居中最稀缺的块，让稀缺快迅速重发，增加副本数量，这样整体速度就会更快。
  • 向邻居响应块时，优先响应给速率最高的几个邻居，每10秒重新计算速率最高，每30秒也会向随机其他邻居发送，除了这些其他邻居均被阻塞，当然还有很多其他的机制，直到最终完整的文件发送完成。

视频流和内容分发网（CDN）

• 视频本质是一系图像。通常以恒定的速率展现（每秒24或30张图像），未压缩、数字编码的图像有像素阵列组成，每个像素由比特编码表示颜色和亮度，视频可压缩，用比特率来权衡视频质量，比特率越高，图像质量越好，视频也就越好了。
• 对视频来说最重要的性能指标是平均吞吐量，视频质量由小于100kbps到3Mbps到大于10Mbps不等。
• 流式视频客户端周期性从服务端抓取帧，对帧解压并对用户展示，同时缓存后续部分的帧，就不会产生卡顿感。
• DASH是一种特别的HTTP，经HTTP的动态适应性流即视频分为几个不同比特率版本，客户端动态请求不同版本且长度危机秒的视频段数据块。
• 内容分发网（CDN）：分布在多个地理位置上的服务器，用于存储视频、图片、文档等文件的副本，并且试图让用户访问最近、最快的CDN服务器。
• CDN的机制：通过DSN截获（大部分情况是这样）并重定向请求，来实现对视频、图片文档等文件的获取，而不是直接访问服务器，这样可以减轻对服务器的访问压力。
• CDN流程分析：
  • 例如用户访问某视频链接www.video.NetCinema.com/1，本地DNS服务器接到链接，中继到一台该域名的权威DNS服务器。
  • 权威DNS服务器发现这个链接是用于访问该网站视频的，就将该网站专门用于CDN的DNS地址发给本地DNS服务器（有点绕，最终获取IP的DNS是专门用于CDN的DNS而不是权威DNS）。

  • 本地DNS服务器向视频专用DNS询问地址，最终返回给本地DNS服务器的是CDN服务器的地址，这样就会直接访问网站服务器了。

    
    
    DNS配合CDN完成
• 如何让用户访问到最近的CDN集群：有两种策略，一是地理位置最近，二是实时流量条件最好（通过周期性的监测）。

套接字编程：生成网络应用

• 这个对于开发人员来说很熟悉了，放两张图用于区分TCP和UDP别的就不多解释了。

  
  
  UDP
  
  
  TCP