应用层

1 网络应用模型

1 客户/服务器模型

• 客户/服务器模型概述
  • 客户/服务器模型也称为C/S（Client/Server）模型
  • 有一个总是打开的主机称为服务器，它服务于许多来自其他称为客户机的主机请求
  • 客户程序必须提前知道服务器程序的地址，客户机一般不需要特殊的硬件和复杂的操作系统

而服务器上运行的软件则是专门用来提供某种服务的程序，可同时处理多个远程或本地客户的请求
服务器系统启动后即自动调用并一直不断地运行着，被动地等待并接收来自各地客户的请求，因此服务器不需要提前知道客户程序的地址

• C/S模型工作流程

  • 服务器处于接收请求的状态
  • 客户机发出服务请求，并等待接收结果
  • 服务器收到请求后，处理请求，得到结果并发送给客户机

• C/S模型的特点

  • 网络中各计算机的地位不平等，整个网络的管理工作由少数服务器担当
  • 客户机之间相互不直接通信
  • 可扩展性不佳。受服务器硬件和网络带宽的限制，服务器支持的客户机数有限

• C/S模型的应用

Web、FTP、远程登录、电子邮件等

2 P2P模型

• P2P模型概述
  • 在C/S模型中，服务器性能的好坏决定了整个系统的性能

P2P模型的思想是整个网络中的传输内容不再被保存在中心服务器上，每个网络节点都同时具有下载、上传的功能，其权利和义务都是大体对等的

• P2P模型中，各计算机没有固定的客户和服务器划分，任意一对计算机直接相互通信。
• P2P模型从本质上来看依然使用C/S方式，但是每个节点既作为客户访问其他节点的资源，也作为服务器提供资源给其他节点访问

• P2P模型相比C/S模型的优缺点

优点

• 减轻了服务器的计算压力，可以将任务分配到各个节点上，大大提高了系统效率和资源利用率
• 可扩展性好
• 网络健壮性强，单个节点的失效不会影响其他节点

缺点

• 节点在获取服务的同时，还需要给其他节点提供服务，因此会占用较多的内存，影响整机速度

2 域名系统（DNS）

• 域名系统概述
  • 域名系统（Domain Name System, DNS）是因特网使用的命名系统，用来把人们方便记忆的具有特定含义的主机名（如www.baidu.com）转换为便于机器处理的IP地址
  • DNS采用C/S模型，基于传输层的UDP协议，端口号为53
  • 从概念上可将DNS分为：层次域名、域名服务器、解析器

1 层次域名

• 域名概述
  • 任何一个连接到因特网上的主机，都有一个唯一的层次结构名称，即域名
  • 一般一个域名由三个子域组成，分别是顶级域、二级域、三级域

每个子域都由字符序列组成，而各子域之间用.隔开

实际上每个子域都可以继续划分，例如百度就可以将baidu划分为image.baidu、tieba.baidu等

• 百度用于提供WWW服务的计算机（Web服务器）的域名为www.baidu.com，其中com是顶级域名，baidu是二级域名，www是三级域名
• 级别最低的域名写在最左边，级别最高的顶级域名写在最右边
• 域名系统中，每个域分别由不同的组织进行管理，每个组织都可以将它的域再分成一定数目的子域，并将这些子域委托给其他组织去管理，例如管理cn域的中国将edu.cn子域授权给中国教育和科研计算机网来管理

• 顶级域名（Top Level Domain, TLD）可分为三类
  1. 国家顶级域名

国家顶级域名表示国家和某些地区的域名，如.cn表示中国、.us表示美国等
国家顶级域名下注册的二级域名均由国家自行决定

1. 通用顶级域名

常见的有.com表示公司、.net表示网络服务机构、.org表示非盈利组织等

1. 基础结构域名

只有一个.arpa，用于反向域名解析

2 域名服务器

• 域名服务器概述

  • 域名到IP地址的解析是由运行在域名服务器上的程序完成的
  • 一个域名服务器（权限域名服务器）所管辖的范围称为区，区内的所有网络节点必须是能够连通的，每个区的域名服务器用来保存该区中的所有主机的域名到IP地址的映射
  • 每个域名服务器不但能够进行一些域名到IP地址的解析，而且还必须具有连向其他域名服务器的信息，当自己不能进行域名到IP地址的转换时，能够知道到什么地方去找其他域名服务器
  • DNS采用分布式设计，即使用了大量的域名服务器，它们以层次方式组织，没有一台域名服务器具有因特网上所有主机的映射，该映射分布在所有域名服务器上

• 主要有4种类型的域名服务器

根域名服务器

• 根域名服务器是最高层次的域名服务器，所有的根域名服务器都知道所有的顶级域名服务器的IP地址
• 根域名服务器也是最重要的域名服务器，不管是哪个本地域名服务器，若要对因特网上任何一个域名进行解析，只要自己无法解析，就首先要求助与根域名服务器
• 因特网上有13个根域名服务器（实际上是13个服务器集群）
• 根域名服务器用来管辖顶级域（如.com），通常它并不直接把待查询的域名直接转换成IP地址，而是告诉本地域名服务器下一步应该找哪个顶级域名服务器进行查询、

顶级域名服务器

• 顶级域名服务器负责管理在该顶级域名服务器注册的所有二级域名
• 收到DNS查询请求时，顶级域名服务器可能给出最后结果，也可能给出下一步应当查找的域名服务器的IP地址

授权域名服务器（权限域名服务器）

• 每台有域名的服务器都必须在权限域名服务器处登记，权限域名服务器总能将其管辖的主机域名转换为相应的IP地址
• 为了更可靠的工作，一台服务器可能要在两个授权域名服务器上登记
• 许多域名服务器都同时充当本地域名服务器和权限域名服务器

本地域名服务器

• 每个因特网服务提供者、一所大学或一所大学中的系，都可以拥有一个本地域名服务器
• 当一台主机发出DNS查询请求时，这个查询请求报文就发送给该主机的本地域名服务器
• 在个人电脑中配置本地连接时填写的DNS地址就是本地域名服务器地址

3 域名解析过程

• 域名解析概述

  • 域名解析是指把域名映射为IP地址或把IP地址映射成域名的过程
  • 当客户端需要域名解析时，通过本机的DNS客户端构造一个DNS请求报文，以UDP数据报方式发往本地域名服务器
  • 域名解析的方式是递归查询（替请求客户查询）和迭代查询（回答请求客户应该怎么查询）相结合的方式
  • 为了提高DNS的查询效率，在域名服务器中广泛地使用了高速缓存

• 域名解析流程如下图

• 主机向本地域名服务器发起的查询采用的是递归查询，即由本地域名服务器来完成后续的查询
• 本地域名服务器向其它域名服务器发起的查询是迭代查询

3 超文本传输协议（HTTP）

1 万维网（WWW）

• 万维网（World Wide Web, WWW）概述
  • WWW是一个资料空间，在这个空间中，一个有用的事物称为一个资源，并且由一个统一资源定位符（URL）标识
  • WWW中的资源通过HTTP协议传送给使用者，而使用者可以通过单击链接来获取资源
  • WWW以客户/服务器（C/S）方式工作，浏览器是在用户计算机上的WWW客户程序，而WWW资源所驻留的计算机则运行服务器程序
  • WWW是无数个网络站点和网页的集合，它们在一起构成了因特网最主要的部分

• WWW的内核是由三个标准构成的

统一资源定位符（URL）

• 负责标识WWW上的各种资源，并使每个资源在整个WWW的范围内具有唯一的URL
• URL是对可以从因特网上得到的资源的位置和访问方法的一种简洁表示
• URL相当于一个文件名在网络范围的扩展
• URL的一般形式是：**<协议>://<主机>:<端口>/<路径>**
  • 常见的协议有HTTP、ftp等
  • 主机是存放资源的主机在因特网中的域名，也可以是IP地址
  • 端口和路径有时可以省略
  • URL中不区分大小写

超文本传输协议（HTTP）

• HTTP是一个应用层协议，使用TCP连接进行可靠的传输
• HTTP是WWW客户程序和服务器程序之间交互所必须严格遵守的协议

超文本标记语言（HTML）

• HTML是一种文档结构的标记语言，它使用一些约定的标记对页面上的各种信息进行描述

• WWW工作流程
  1. Web用户使用浏览器（指定URL）与Web服务器建立连接，并发送浏览请求
  2. Web服务器把URL转换为文件路径，并将相应的文件返回给Web浏览器
  3. 通信完成，关闭连接

2 HTTP协议简介

• HTTP协议（HyperText Transfer Protocol）概述

  • HTTP定义了浏览器怎样向服务器请求资源，以及服务器怎样把资源传送给浏览器
  • HTTP规定了在浏览器和服务器之间的请求和响应的格式与规则，是WWW上能够可靠地交换文件的重要基础
  • HTTP有多个版本，目前广泛使用的是HTTP/1.1版本

• 访问一个URL时所发送的事情

以访问HTTP://www.tsinghua.edu.cn/chn/index.htm为例

1. 浏览器分析URL
2. 浏览器向DNS域名服务器请求解析www.tsinghua.edu.cn的IP地址
3. 域名系统DNS解析出清华大学服务器的IP地址
4. 浏览器与清华大学服务器建立TCP链接
5. 浏览器发出HTTP请求：GET /chn/index.htm
6. 服务器通过HTTP响应把文件index.htm发送给浏览器
7. TCP链接释放
8. 浏览器解释index.htm文件，并将Web页面显示给用户

• HTTP协议的特点
  • 简单快速

客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST

• 灵活

HTTP允许传输任意类型的数据对象。传输的类型由Content-Type加以标记

• 无状态

  • 无状态是指服务端没有存储客户端的状态、对于事务处理没有记忆，后续处理需要前面的信息，则必须重传
  • 为了弥补无状态的不足，产生了两项记录HTTP状态的技术，分别是Cookie和Session

    Cookie和Session结合进行HTTP状态存储

    • Cookie是客户端的解决方案，由服务器发给客户端的特殊信息会以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息
    • Session是服务器端使用的一种记录客户端状态或信息的机制
    • 通过Cookie存储一个session_id，然后具体的数据则保存在Session中

    如果用户已经登录，则客户端会在Cookie中保存一个session_id，下次再次请求的时候会把该session_id携带上来，服务器根据session_id在Session库中获取用户的session数据，就能知道该用户到底是谁，以及之前保存的一些状态信息；

• 无连接（1.0特性）

  • 无连接指的是限制每次连接只处理一个请求，服务器处理完客户端的请求并收到客户端的应答后即断开连接，无连接是为了尽快将资源释放出来给其他客户端
  • 无连接对于服务器来说处比较简单，因为存在的连接都是有用的连接，不需要额外的控制，但如果客户端连接频繁，会在tcp连接的频繁建立和关闭上浪费资源
  • HTTP/1.1提出持久连接（HTTP Keep-Alive），在持久连接中只要任意一端没有明确提出断开连接，则保持TCP连接状态，在请求首部字段中的Connection: keep-alive表明使用了持久连接

3 HTTP报文

• HTTP报文概述
  • HTTP报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。
  • HTTP有两类报文，请求报文（从Web客户端向Web服务器发送服务请求）和响应报文（从Web服务器对Web客户端请求的回答）

1 请求报文

• 请求报文格式

一个HTTP请求报文由请求行、请求头部、空行和请求体4个部分组成

1. 请求行（Request Line）

• 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。

例如GET /index.html HTTP/1.1

• 常见的请求方法有GET、POST、HEAD
  1. GET
  • GET是最常见的一种请求方式，当客户端要从服务器中读取文档、点击网页上的链接、通过在浏览器的地址栏输入网址来浏览网页时，使用的都是GET方式
  • GET方式要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。
  • 使用GET方法时，请求参数和对应的值附加在URL后面（因此参数在请求行中）

利用?代表URL的结尾与请求参数的开始，利用&分隔多个参数。

• 利用GET方式传参时，参数的值可以直接在URL中看到。显然，GET方式不适合传送私密数据

另外，不同的浏览器对URL的字符限制也有所不同，一般最多只能识别1024个字符，所以如果需要传送大量数据的时候，也不适合使用GET方式

1. POST

• 对于上面提到的不适合使用GET方式的情况，可以考虑使用POST方式
• POST方法将请求参数封装在HTTP请求体中，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中
• GET多用来查询，请求参数放在URL中，不会对服务器上的内容产生作用。

POST多用来提交，如把表单内容放到Request Body中

1. HEAD

• HEAD类似于GET，不同的是服务端接受到HEAD请求后只返回响应头，而不会发送响应体。
• 当我们只需要查看某个页面的状态的时候，使用HEAD非常高效，因为在传输的过程中省去了页面内容

1. 请求头（Request Header）

• 请求头由关键字/值对组成，每行一对，关键字和值用英文冒号:分隔
• 请求头部通知服务器关于客户端请求的信息，典型的请求头有
  • User-Agent

产生请求的浏览器类型

• Host

请求的服务器套接字（1.1以后才有）

• Content-Length

Request Body中数据的长度

• Content-Type

指定Request Body中数据的编码类型（如application/json），服务器根据该类型使用特定的解析方式解析请求体

• Connection

指定是否是HTTP持久连接（即Keep-Alive）

1. 空行

• 最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器后续不再有请求头

1. 请求体（Request Body）

• 请求体不在GET方法中使用，而是在POST方法中使用，POST方法会将客户端要传送的数据封装在请求体中
• 与请求体相关的最常使用的请求头是Content-Type（如json）和Content-Length

2 响应报文

• 响应报文格式

响应报文也由三个部分组成，分别是：状态行、响应头、响应体

• 状态行（Status Line）
  • 响应报文的格式与各部分功能与请求报文基本一致，真正的区别在于第一行中用状态行代替了请求行
  • 状态行通过提供一个状态码来说明所请求的资源情况

状态行格式**HTTP-Version Status-Code Reason-Phrase CRLF**

• HTTP-Version表示服务器HTTP协议的版本；
• Status-Code表示服务器发回的响应状态代码；
• Reason-Phrase表示状态代码的文本描述

状态码
状态码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值

• 1xx：指示信息—表示请求已接收，继续处理
• 2xx：成功—表示请求已被成功接收、理解、接受
• 3xx：重定向—要完成请求必须进行更进一步的操作
• 4xx：客户端错误—请求有语法错误或请求无法实现
• 5xx：服务器端错误—服务器未能实现合法的请求

常见状态代码及状态码描述

• 200 OK：客户端请求成功。
• 400 Bad Request：客户端请求有语法错误，不能被服务器所理解，如需要的参数没传、json格式错误
• 401 Unauthorized：请求未经授权
• 403 Forbidden：服务器收到请求，但是拒绝提供服务。
• 404 Not Found：请求资源不存在
• 405 Method Not Allowed：请求方式不被允许，如服务端要求Post请求，但是却用Get方式请求
• 500 Internal Server Error：服务器发生不可预期的错误，如服务端抛异常。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，如nginx限流

4 超文本传输安全协议（HTTPS）

1 HTTP的缺点

HTTP协议主要有以下不足

1. 通信不加密，使用明文，内容可能会被窃听

• 窃听相同段的通信并非难事，只需要收集在互联网上流动的数据包即可，使用wireshark等抓包工具即可

1. 不验证通信方的身份，因此有可能遭遇伪装

• HTTP协议中的请求和响应不会对通信方进行确认
• 存在服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真的返回到实际提出请求的客户端等问题

1. 无法证明报文的完整性（也可以说是准确性），有可能遭篡改

• HTTP协议无法证明通信的报文的完整性，在请求或响应送出之后直到对方接收之前的这段时间，即使请求或响应的内容遭到篡改，也没有办法获悉
• 请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack, MITM）

2 HTTPS简介

HTTP+加密通信+认证+完整性保护=HTTPS

• HTTPS概述
  • HTTPS并非是应用层的一种新协议，只是HTTP通信接口部分用SSL和TSL协议代替而已

通常HTTP直接和TCP通信，当使用SSL时，则演变成HTTP先和SSL通信，再由SSL和TCP通信了

• 在采用SSL后，HTTP就拥有了加密、证书和完整性保护的功能，因此HTTPS=HTTP+SSL
• SSL是独立于HTTP的协议，不光HTTP协议，其他运行在应用层的协议都可以配合SSL使用
• HTTP和HTTPS默认端口也不一样，HTTP是80，HTTPS是443

• SSL协议和TLS协议
  • SSL是Secure Socket Layer的简称，即安全套接字层）

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持

• TLS（Transport Layer Securit）是传输层加密协议，由网景公司1995年发布。

TLS前身是SSL协议，有时两者不区分

3 HTTPS加密机制

• 密钥

  • 现代的加密算法是公开的，但是密钥是保密的
  • 加密和解密都需要用到密钥，没有密钥就没有办法加密和解密
  • 使用公开的加密算法，只要密钥是私有的，就可以保证安全

• 非对称密钥加密

  • 非对称密钥中，一个密钥称为私钥，另一个密钥称为公钥
  • 私有秘钥不能让其他人知道，而公开密钥则可以随意发布，任何人都可以获得

非对称密钥有两类用法

1. 公钥加密，私钥解密

这种方式用于加密通信

1. 私钥签名，公钥验签

这种方式用于签名
公钥用来加密，私钥用来解密

• 使用非对称密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密
• 非对称密钥加密方式不需要发送给对方用来解密的私有密钥，因此也不必担心用来解密的密钥被窃取

私钥签名（加密），公钥验签（解密）

• 既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。

• 对称密钥加密
  • 加密和解密同用一个密钥的方式称为共享密钥加密，也叫对称密钥加密
  • 以共享密钥加密时，必须将密钥发给对方，但是怎样能保证安全的转交密钥？通过互联网转发密钥时，如果密钥被窃取，那么也就失去了加密的意义。

非对称密钥加密解决了对称密钥传输问题，可以使用非对称加密传输对称密钥来保证对称密钥的安全。

• 对称加密效率比非对称加密效率更高

• HTTPS采用混合加密机制
  • 在验证数字证书阶段使用非对称密钥加密方式
  • 在交换对称密钥环节使用非对称密钥加密方式
  • 建立通信交换报文阶段则使用对称密钥加密方式

4 HTTPS证书机制

• 证书概述

  • 数字证书是指在互联网通讯中标志通讯各方身份信息的一个数字认证，人们可以在网上用它来识别对方的身份。
  • 证书由客户端与服务器双方都可信赖的第三方机构颁发
  • 证书需要花费一定费用才能从第三方机构获得

• 证书与HTTPS

  • 在HTTPS中，证书不仅起到了验证服务器身份的功能，同时还实现了服务器公钥的安全传输
  • 我们已经知道HTTPS的加密机制首先需要服务端将公开密钥传送的客户端，但是无法证明传送到客户端的公开密钥就是原本预想的那台服务器发行的公开密钥；在公开密钥的传输途中也可能被攻击者替换掉
  • 可以使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书来解决上述问题

• 证书颁发流程

  1. 服务器的运营人员向数字证书认证机构提出证书申请，数字证书认证机构在判明申请者的身份后，为其颁发数字证书
  2. 数字证书生成时，首先是一个文件，记为P，其中包含：服务端公钥、服务端信息、签发者ID、有效期等
  3. 计算P的hash值，CA用私钥对其进行签名，得到S。数字证书就是由文件P和其签名过的Hash值组成，记为（P，S）

• 证书验证流程

  1. 客户端获得证书（P，S）
  2. 用CA的公钥（一般知名的CA的公钥会预置在浏览器中）解密S得到H1。
  3. 计算P的hash值，得到H2。
  4. 若H1=H2，证明这个证书是有签发者签发给它的证书并且可以相信P的内容。
     若H1!=H2，说明P被篡改过或者证书不是CA签发的，总之有问题。

6 HTTPS完整性校验

• 完整性校验概述

完整性校验即校验报文是否被篡改（内容是否完整、正确），是否收到中间人攻击

• 完整性校验方法

散列值校验

• 如MD5和SHA-1等计算散列值的算法
• 下载游戏客户端时，就可以根据游戏官网提供的工具，判断下载的内容是否完整

消息认证码（Message authentication code, MAC）

• 消息认证码是经过特定算法后产生的一小段信息，检查某段消息的完整性
• MAC的生成需要借助对称密钥

7 HTTPS传输流程

SSL握手阶段一

1. 客户端通过发送Client Hello报文开始SSL通信
   • Client Hello报文中包含客户端支持的SSL的指定版本、加密组件列表（客户端所使用的加密算法及密钥长度等）
2. 服务端可进行SSL通信时，会以Server Hello报文作为应答
   • 和客户端一样，在Server Hello报文中包含SSL版本以及加密组件列表
   • 服务端的发送的加密组件列表是从接收到的客户端加密组件列表中筛选出来的
3. 服务器发送Certificate报文
   • Certificate报文中包含服务端的证书
4. 服务端发送Server Hello Done报文通知客户端，第一阶段的SSL握手协议部分结束

SSL握手阶段二

1. SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应
   • Client Key Exchange报文中包含一个名为Pre-master secret的随机密码串
   • Client Key Exchange报文使用服务端证书中包含的公钥进行加密
   • 客户端此时还会根据Pre-master secret的随机密码串生成对称密钥master secret
2. 客户端继续发送Change Cipher Spec报文
   • Change Cipher Spec报文提示服务器，在此报文之后的通信会采用master secret密钥加密
3. 客户端发送Finished报文
   • Finished报文包含连接至今全部报文的整体校验值
   • 这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准
4. 服务端接收到Pre-master secret并发送Change Cipher Spec报文
5. 服务端发送Finished报文

• 服务端和客户端的Finished报文交换完毕之后，SSL连接就算建立完成，之后的通信将受到SSL的保护

开始应用层协议的通信，即HTTP…

• 应用层发送数据时，会附加MAC（Message Authentication Code）消息认证码，MAC能够查知报文是否遭到篡改，从而保护报文的完整性

8 HTTPS的缺点

• HTTPS协议多次握手，导致页面的加载时间延长近50%；
• HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗；
• 申请SSL证书需要钱，功能越强大的证书费用越高
• SSL涉及到的安全算法会消耗CPU资源，对服务器资源消耗较大

5 实时流媒体协议（RTMP）

最近直播比较火，很多人都喜欢看直播，那一个直播系统里面都有哪些组成部分，都使用了什么协议呢？
无论是直播还是点播，其实都是对于视频数据的传输。一提到视频，大家都爱看，但是一提到视频技术，大家都头疼，因为名词实在是太多了。

• 三个名词系列

我这里列三个名词系列，你先大致有个印象。

• 名词系列一：AVI、MPEG、RMVB、MP4、MOV、FLV、WebM、WMV、ASF、MKV。例如 RMVB 和 MP4，看着是不是很熟悉？
• 名词系列二：H.261、 H.262、H.263、H.264、H.265。这个是不是就没怎么听过了？别着急，你先记住，要重点关注 H.264。
• 名词系列三：MPEG-1、MPEG-2、MPEG-4、MPEG-7。MPEG 好像听说过，但是后面的数字是怎么回事？是不是又熟悉又陌生？

• 视频与编码
  • 这里，我想问你个问题，视频是什么？我说，其实就是快速播放一连串连续的图片。
  • 每一张图片，我们称为一帧。只要每秒钟帧的数据足够多，也即播放得足够快。比如每秒 30 帧，以人的眼睛的敏感程度，是看不出这是一张张独立的图片的，这就是我们常说的帧率（FPS）。
  • 每一张图片，都是由像素组成的，假设为 1024*768（这个像素数不算多）。每个像素由 RGB 组成，每个 8 位，共 24 位。
  • 我们来算一下，每秒钟的视频有多大？

30 帧 × 1024 × 768 × 24 = 566,231,040Bits = 70,778,880Bytes
如果一分钟呢？4,246,732,800Bytes，已经是 4 个 G 了。是不是不算不知道，一算吓一跳？
这个数据量实在是太大，根本没办法存储和传输。如果这样存储，你的硬盘很快就满了；
如果这样传输，那多少带宽也不够用啊！

• 怎么办呢？人们想到了编码，就是看如何用尽量少的 Bit 数保存视频，使播放的时候画面看起来仍然很精美。
  • 编码就是一个压缩的过程。

WebSocket协议

• HTTP存在的问题
  • HTTP是一种无状态协议，每当一次会话完成后，服务端都不知道下一次的客户端是谁，需要每次先知道对方是谁才进行相应的响应
  • HTTP需要客户端主动发，服务端被动发，也就是一次请求，一次响应，服务端不能实现主动发送，因此服务端的信息无法及时传达给客户端

• HTTP的轮询
  • 为了实现HTTP服务端及时的推送，早期一般使用轮询的方式

• 客户端发起轮询，如果服务端的数据没有发生变更会hold住请求，直到服务端的数据发生变化或者等待一定时间超时才会返回。服务端返回后，客户端又会立即再次发起下一次长轮询

• WebSocket概述
  • WebSocket通信协议于2011年被IETF定为标准RFC 6455，是HTML5下一种新的基于TCP的应用层协议
  • WebSocket实现了客户端与服务器全双工通信，以便任一方都可以通过建立的连接将数据推送到另一端，能更好的节省服务器资源和带宽并达到实时通讯的目的

• 有了WebSocket后，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接并进行双向数据传输

• WebSocket的握手

  • WebSocket是通过HTTP协议进行握手的，但是WebSocket连接建立之后是不需要HTTP协议的，通信时采用的也是WebSocket独立的数据帧

  • 为了创建Websocket连接，需要通过客户端发出特定的HTTP请求，之后服务器回应特定的HTTP响应，这个过程通常称为握手

    • 客户端申请协议升级的HTTP报文格式，主要特征是Upgrade字段

      GET / HTTP/1.1
      Host: localhost:8080
      Origin: http://127.0.0.1:3000
      Connection: Upgrade
      Upgrade: websocket
      Sec-WebSocket-Version: 13
      Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

    • 服务端响应协议升级的HTTP报文格式，状态码为101

      HTTP/1.1 101 Switching Protocols
      Connection:Upgrade
      Upgrade: websocket
      Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

• WebSocket相较于HTTP的优势

较少的控制开销（头部开销）

• 在连接创建后服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小，只有2至10字节
• 相对于HTTP请求每次都要携带完整的头部，此项开销显著减少了
• HTTP长连接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低，Websocket协议通过HTTP协议握手并建立TCP连接之后，交换的数据都不需要发送HTTP header就能交换数据

更强的实时性

• 由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。
• 相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少

保持连接状态

• 与HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息
• HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）

• 利于WebSocket传输的整体流程
  1. 客户端发起HTTP请求，经过TCP3次握手后建立起TCP连接；
  2. 客户端发送HTTP请求，请求里存放WebSocket支持的版本号等信息，如：Upgrade、Connection、WebSocket-Version等；
  3. 服务器收到客户端的握手请求后，同样采用HTTP协议回馈数据，状态码为101
  4. 客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信

• WebSocket的应用场景
  • 即时聊天通信，如微信等
  • 在线协同编辑，如各类云文档
  • 实时地图