WebRTC源码研究（4）web服务器工作原理和常用协议基础

• Z时代
• 2024-01-10
• 分类：技术分享

#WebRTC系列文章

1. WebRTC源码研究（1）WebRTC架构
2. WebRTC源码研究（2）webrtc源码目录结构
3. WebRTC源码研究（3）webrtc运行机制
4. WebRTC源码研究（4）web服务器工作原理和常用协议基础

@[TOC]

WebRTC源码研究（4）web服务器工作原理和常用协议基础

前言

前面3篇博客分别对WebRTC框架的介绍，WebRTC源码目录，WebRTC的运行机制进行了介绍，接下来讲解一点关于服务器原理的知识。后面博客会写关于WebRTC服务器相关的开发，目前git上面有好多WebRTC相关的流媒体服务器的源码，有时间可以去深入研究一下。

做WebRTC 开发为啥要懂服务器开发知识

• 由于WebRTC技术的目标就是在浏览器上实现音视频通信，目前官网的例子也都是JS编写的，大部分后台逻辑也是JS编写的，由于安全的原因，很多浏览器例如chrome它是不允许调用本地JS文件的，所以你只能把它放在Web服务器端，通过Web服务器下载到本地，然后在运行这些程序。

• 另外一个原因是我们后面做WebRTC开发离不开信令服务器 ，而信令服务器每个公司的实现方式不同，大部分都是使用WebSocket实现通信，需要在Web服务器再加上一些库，如用socket IO来构建我们自己的信令服务器，因为这个原因，我们非常有必要理解web服务器的工作原理，这样在我们后面的学习才更加顺畅。

1. Web 服务器简介

详细在互联网时代，做IT的都应该经常听说过Web服务器，我们经常听说12306买票页面进不去拉，打开一个网页报503错误等等。这些事情经常在我们的身边发生。那么我们真的知道什么是Web服务器吗？

• 什么是Web服务器？

  Web服务器概念较为广泛，我们最常说的Web服务器指的是网站服务器，它是建立在Internet之上并且驻留在某种计算机上的程序。Web服务器可以向Web客户端(如浏览器)提供文档或其他服务，只要是遵循HTTP协议而设计的网络应用程序都可以是Web客户端。

Web服务器和HTTP服务器可以说是同一个东西，当然非得细分的话，HTTP服务器是建立在HTTP协议之上的提供文档浏览的服务器，更多的是提供静态的文件。而Web服务器涵盖了HTTP服务器(这一点可以自行百度百科), Web服务器不仅能够存储信息，还能在用户通过Web浏览器提供的信息的基础上运行脚本和程序。

Web服务器 约等于 HTTP服务器 + 其他服务

2. Web 服务器的类型

• 现在市面上有很多web服务器，比如Nodejs、Nginx、Apache，这三个是非常有名的web服务器了，其中Apache是比较老的，市场占有率大概是80%，直到Nginx的出现，从性能方面比这个Apache更高，灵活度什么的都比这个Apache要好得多，所以Nginx逐渐就把这个Apache给取代了。
• Nodejs是比较特殊的，它的特殊在于他可以通过JS开发服务端程序，也就是说你通过JS开发Web服务器，同时你又可以将这个应用程序也是JS放入服务端；这样当浏览器发送一个Http请求，然后将服务端的代码下到本地去执行。也就是说存在两个JS：一个是用于控制服务器的，一个是用于下载到客户端去运行的。
• 由于技术的发展，我们认为JS是未来的一个趋势，以后所有的程序可能都是在一个浏览器中去执行了，那这样nodeJS就显得它的特别之处了，是很有未来市场的一个web服务器。因为做前端用JS做后端也同样用JS，这样JavaScript的前端程序员就可以无缝的转化过去。
• NodeJS是个非常强大的后端开源的框架，非常值得去研究学习。

目前市场上面主流的Web服务器主要有：

• Nodejs ： Nodejs是比较特殊的服务器，可以直接用js开发服务端程序。
• Nginx : Nginx无论是灵活度还是性能方面都比Apache好很多，是目前的主流。
• Apache： 比较老的服务器，mac系统一般自带这个服务器。

3. Web 服务器的工作原理

3.1 最简单的Web服务器

先来看一张图解HTTP书籍中一张经典的图片：

首先我们通过上图看出有个人通过浏览器敲入http，点回车那么这个请求就被浏览器发送给力web服务，就发送 了一个Http Request，这个时候后端服务一般是挂着一个数据库，它需要做很多的逻辑处理，处理完之后，会给浏览器一个响应，就是Http Response。拿到这个响应之后实际是一个HTML的页面，就会将这个Hello World显示出来。

现在的前端不可能是简简单单的一个页面了，还有可能是风格类型 、用什么样的字体如何展现等 ，会有一个css文件 ，还会又一个JavaScript文件 ，来控制整个页面的行为，那用户拿到这个页面之后，在里面点击一些鼠标事件等等就会改变这个页面不同的行为，这就是一个完整的web服务的工作原理。是不是so easy!!!

3.2 Web服务器工作流程

上面讲的就是一个最简单的Web服务器工作原理了。上面讲的是面对非IT认识，非常粗浅的讲解。

接下来我们站在IT认识的角度，用专业的流程图去看看，Web服务器的工作流程：

上图的工作流程大致如下：

上图的工作流程大致如下：

1. 用户做出了一个操作，可以是填写网址敲回车，可以是点击链接，可以是点击按键等，接着浏览器获取了该事件。
2. 浏览器与对端服务程序建立TCP连接。
3. 浏览器将用户的事件按照HTTP协议格式**打包成一个数据包，其实质就是在待发送缓冲区中的一段有着HTTP协议格式的字节流。
4. 浏览器确认对端可写，并将该数据包推入Internet，该包经过网络最终递交到对端服务程序。
5. 服务端程序拿到该数据包后，同样以HTTP协议格式解包，然后解析客户端的意图。
6. 得知客户端意图后，进行分类处理，或是提供某种文件、或是处理数据。
7. 将结果装入缓冲区，或是HTML文件、或是一张图片等。
8. 按照HTTP协议格式将(7)中的数据打包
9. 服务器确认对端可写，并将该数据包推入Internet，该包经过网络最终递交到客户端。
10. 浏览器拿到包后，以HTTP协议格式解包，然后解析数据，假设是HTML文件。
11. 浏览器将HTML文件展示在页面

作为一个服务器，其根本的工作无非有三个：

• 接收数据
• 发送数据
• 数据处理

而Web服务器的本质就是： 接收数据 ⇒ HTTP解析 ⇒ 逻辑处理 ⇒ HTTP封包 ⇒ 发送数据

高级的服务器无非就是将这三个部分更加细致的设计了。

4. Nodejs 服务器的工作原理

接下来我们再看nodeJS的工作原理。

我们先来看一张经典的NodeJS的运行原理图：

• 首先是APPLICATION，也就是我们自己开发的JavaScript程序，它首先会输出给V8引擎，
• 这个V8引擎大家都非常清楚了，是从Google浏览器Chrome的项目中抽取出来的，主要对JS进行一些解析工作，解析完之后生成一个二进制代码；
• 接下来是NodeJS本身他自己的一些API,解析后的二进制代码去调用NodeJS API，这里称为NODE BINDINGS,调用之后NodeJS 还会调用LIBUV的事件处理库。

• NodeJS它的工作原理是一直循环等待事件处理，请求过来的时候会首先插入到事件队列当中去，事件循环就不断的从事件队列里面去拿一个个事件，最后去做相应的处理。这个就是NodeJS的工作原理，重点是他有这个V8引擎 。

4.1 Nodejs 事件处理原理

此外，我们还可以从另外一个角度去看看NODEJS是如何去处理事件。

下图是就是NODEJS在收到事件之后处理的一个大体逻辑：

• 首先有很多请求到NODEJS的应用上来，拿到这个请求之后会生成一个个事件，插入到这个事件队列当中去，也就是我们上面讲的LIBUV做的管理的这个事件队列，LIBUV同时启动这个事件循环，不停的从这个事件队列中取出一个个事件去做相应的处理，过程非常简单，直接就 callback回去了。

• callback回去之后直接返回一个response,假如说我们只是HTML的一个页面，当你请求网址的时候就返回一个Hello，非常的简单，直接就返回了。

• 还有一种就非常复杂，可能要通过调用数据库 ，去做一些查询工作，做数据统计，这时候它会从线程池取一个线程，执行固定的function方法，最后会callback，有可能这个结果是一个中间结果，它会再插入到事件队列中，也有可能是最终的结果，直接就返回了一个Response。
• 上面就是一个NODEJS事件的一个大体的过程，当然线程用完了之后还要回收，直接返回到这个线程池，这就是NODEJS的一个事件处理过程。

5. JavaScript解析过程

如下图是JS的解析过程：

• 首先我们看看JS解析是怎么解析的，首先是这个V8引擎它会收到JS的源程序。
• 我们在服务端要实现服务的流程如下：

1. 首先是写一个JS的小的脚本，通过V8之后生成这个parser，解析之后生成JS的函数，最终交给这个解析器，解析成bytecode,就是这个支撑代码，还有可能先进行优化，
2. 然后形成优化后的代码.
3. 最后在转换成optimized code。

6. V8 引擎简介

• 两个V8 引擎

上面介绍了NodeJS的运行原理，在NodeJS运行原理中有介绍到V8引擎。

接下来我们重点再介绍一下V8引擎，实际在我们使用NODEJS之后，有时候会给大家一种困扰，我的服务端也是JS，客户端也是JS，什么时候是服务端的运行什么时候是客户端的运行，那实际是有两个V 8引擎。

如下图所示：

• 实际上在NODEJS里面有个V8引擎，同时在JS里面也有个V8引擎。
• 当我们发送一个Http请求到NodeJS的时候，那实际在请求之前，NodeJS这个服务它要运行起来。
• 首先它有自己的服务端的这个JS，它通过解析将整个web服务运行起来了。
• 它这个JS给V8进行解析，通过调用中间的Libuv将整个服务运行起来。
• 这时候客户端浏览器发送一个请求过来，说我要请求 某某某文件，解析完了之后通过这个libuv以后去到这个磁盘上，拿到这个JS文件，返回给浏览器，那浏览器这时就收到了服务端的JS，它又交给V8来进行解析。
• 然后在做后面的中间操作，调网卡也好读取文件也好去显示也好，那么这个就是客户端所要执行的。

注意：这里大家一定要区分开，一个JS是NODEJS自己的V8引擎去解析启动的服务 ，另外一种是客户端发起的请求，NODEJS返回这个JS，然后在通过V8去解析，然后渲染出结果，大家这个千万不能混乱了。

7. Web服务器中常用的协议

7.1 HTTP协议

7.1.1 HTTP协议简介

• HTTP协议（超文本协议）

（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。

HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。

我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。

7.1.2 HTTP协议的特点

• HTTP协议的特点：

1. 支持客户/服务器模式。
2. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

7.1.3 HTTP原理

• HTTP原理

  HTTP是一个基于TCP/IP通信协议来传递数据的协议，传输的数据类型为HTML 文件,、图片文件, 查询结果等。

  HTTP协议一般用于B/S架构（）。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。

7.1.4 HTTP的一些基本概念

• URI和URL的区别

  HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。

  URI：Uniform Resource Identifier 统一资源标识符

  URL：Uniform Resource Location 统一资源定位符

  URI 是用来标示 一个具体的资源的，我们可以通过 URI 知道一个资源是什么。

  URL 则是用来定位具体的资源的，标示了一个具体的资源位置。互联网上的每个文件都有一个唯一的URL。

URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：

www.aspxfans.com:8080/news/index.…

从上面的URL可以看出，一个完整的URL包括以下几部分：

1. 协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符
2. 域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也可以使用IP地址作为域名使用
3. 端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口
4. 虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”
5. 文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名
6. 锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分
7. 参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

• URI和URL的区别

1. URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

   Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的

   URI一般由三部组成：

   ①访问资源的命名机制

   ②存放资源的主机名

   ③资源自身的名称，由路径表示，着重强调于资源。

2. URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

   URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。

   采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：

   ①协议(或称为服务方式)

   ②存有该资源的主机IP地址(有时也包括端口号)

   ③主机资源的具体地址。如目录和文件名等

3. URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:java-net@java.sun.com。

   URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

7.1.5 HTTP报文格式

7.1.5.1 HTTP请求报文格式

http请求由三部分组成，分别是：请求行、消息报头、请求正文

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

• GET ： 请求获取Request-URI所标识的资源

• POST ： 在Request-URI所标识的资源后附加新的数据

• HEAD ： 请求获取由Request-URI所标识的资源的响应消息报头

• PUT ：请求服务器存储一个资源，并用Request-URI作为其标识

• DELETE ：请求服务器删除Request-URI所标识的资源

• TRACE ：请求服务器回送收到的请求信息，主要用于测试或诊断

• CONNECT ：保留将来使用

• OPTIONS ：请求查询服务器的性能，或者查询与资源相关的选项和需求

  应用举例：

• GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，eg:GET /form.html HTTP/1.1 (CRLF)

• POST方法： 要求被请求服务器接受附在请求后面的数据，常用于提交表单。

7.1.5.2 HTTP响应报文格式

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

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

• 状态行格式如下：

  HTTP-Version Status-Code Reason-Phrase CRLF

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

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

1xx：指示信息--表示请求已接收，继续处理

2xx：成功--表示请求已被成功接收、理解、接受

3xx：重定向--要完成请求必须进行更进一步的操作

4xx：客户端错误--请求有语法错误或请求无法实现

5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK //客户端请求成功

400 Bad Request //客户端请求有语法错误，不能被服务器所理解

401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用

403 Forbidden //服务器收到请求，但是拒绝提供服务

404 Not Found //请求资源不存在，eg：输入了错误的URL

500 Internal Server Error //服务器发生不可预期的错误

503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

eg：HTTP/1.1 200 OK （CRLF）

• 响应报头

• 响应正文就是服务器返回的资源的内容

7.1.5.3 HTTP消息报头

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。

每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。

1. 普通报头

1. 在普通报头中，有少数报头域用于所有的请求和响应消息，但并不用于被传输的实体，只用于传输的消息。

2. Cache-Control : 用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制），HTTP1.0使用的类似的报头域为Pragma。

3. 请求时的缓存指令包括：no-cache（用于指示请求或响应消息不能缓存）、no-store、max-age、max-stale、min-fresh、only-if-cached;

4. 响应时的缓存指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.

5. 为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写如下：response.sehHeader("Cache-Control","no-cache");作用相当于上述代码,这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache

6. Date普通报头域表示消息产生的日期和时间

7. Connection普通报头域允许发送指定连接的选项。例如指定连接是连续，或者指定“close”选项，通知服务器，在响应完成后，关闭连接

2. 请求报头

1. 请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。
2. 常用的请求报头

3. Accept: Accept请求报头域用于指定客户端接受哪些类型的信息。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。

4. Accept-Charset:Accept-Charset请求报头域用于指定客户端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。

5. Accept-Encoding:Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。eg：Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。

6. Accept-Language:Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。eg：Accept-Language:zh-cn.如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。

7. Authorization:Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。

8. Host（发送请求时，该报头域是必需的）:

   Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的，eg：

   我们在浏览器中输入：www.guet.edu.cn/index.html

   浏览器发送的请求消息中，就会包含Host请求报头域，如下：

   Host：www.guet.edu.cn

   此处使用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号

9. User-Agent

   我们上网登陆论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所使用的浏览器的名称和版本，这往往让很多人感到很神奇，实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必需的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。

请求报头举例：

GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)

3. 响应报头

1. 响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
2. 常用的响应报头

3. Location

   Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。

4. Server

   Server响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是

5. Server响应报头域的一个例子：

   Server：Apache-Coyote/1.1

   WWW-Authenticate

   WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。

   eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服务器对请求资源采用的是基本验证机制。

4. 实体报头

1. 请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。
2. 常用的实体报头

3. Content-Encoding

   Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding这样用于记录文档的压缩方法，eg：Content-Encoding：gzip

4. Content-Language

   Content-Language实体报头域描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读

   者。eg：Content-Language:da

5. Content-Length

   Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。

6. Content-Type

   Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。eg：

   Content-Type:text/html;charset=ISO-8859-1

   Content-Type:text/html;charset=GB2312

7. Last-Modified

   Last-Modified实体报头域用于指示资源的最后修改日期和时间。

8. Expires

   Expires实体报头域给出响应过期的日期和时间。为了让代理服务器或浏览器在一段时间以后更新缓存中(再次访问曾访问过的页面时，直接从缓存中加载，缩短响应时间和降低服务器负载)的页面，我们可以使用Expires实体报头域指定页面过期的时间。eg：Expires：Thu，15 Sep 2006 16:23:12 GMT

   HTTP1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。eg：为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置为0，jsp中程序如下：response.setDateHeader("Expires","0");

7.1.6 HTTP状态码

HTTP状态码（英语：HTTP Status Code）是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的，但是可以提供任何可读取的替代方案。 除非另有说明，状态码是HTTP / 1.1标准（RFC 7231）的一部分。

总的来说状态码分为5大类：

• 1xx：指示信息--表示请求已接收，继续处理

• 2xx：成功--表示请求已被成功接收、理解、接受

• 3xx：重定向--要完成请求必须进行更进一步的操作

• 4xx：客户端错误--请求有语法错误或请求无法实现

• 5xx：服务器端错误--服务器未能实现合法的请求

  

具体每个分类的状态码含义详解如下：

• 消息

• 成功

  这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

• 重定向

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。

当且仅当后续的请求所使用的方法是 GET 或者 HEAD 时，用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向（例如：A->A，或者A->B->C->A），因为这会导致服务器和客户端大量不必要的资源消耗。按照 HTTP/1.0 版规范的建议，浏览器不应自动访问超过5次的重定向。

• 请求错误

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。

如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。

• 服务器错误

（5、6字头）

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。

这些状态码适用于任何响应方法。

7.1.8 各个版本区别

• HTTP 各个版本

7.1.8.1 HTTP 0.9

最初的http版本，仅支持get方法，只能传输纯文本内容，所以请求结束服务段会给客户端返回一个HTML格式的字符串，然后由浏览器自己渲染。

http0.9是典型的无状态连接（无状态是指协议对于事务处理没有记忆功能，对同一个url请求没有上下文关系，每次的请求都是独立的，服务器中没有保存客户端的状态）

7.1.8.2 HTTP1.0

这个版本后任何文件形式都可以被传输，本质上支持长连接，但是默认还是短连接，增加了keep-alive关键字来由短链接变成长连接。

HTTP的请求和回应格式也发生了变化，除了要传输的数据之外，每次通信都包含头信息，用来描述一些信息。

还增加了状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等

7.1.8.3 HTTP1.1

HTTP1.1是目前最为主流的http协议版本，从1997年发布至今，仍是主流的http协议版本。主要变化有3个方面：

• 引入了持久连接（ persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。

• 引入了管道机制（ pipelining），即在同一个TCP连接里，客户端可以同时发送多个

  请求，进一步改进了HTTP协议的效率。

• 新增方法：PUT、 PATCH、 OPTIONS、 DELETE。

具体来说：HTTP1.1最大的变化就是引入了长链接，也就是TCP链接默认是不关闭的可以被多个请求复用。客户端或者服务器如果长时间发现对方没有活动就会关闭链接，但是规范的做法是客户端在最后一个请求的时候要求服务器关闭链接。对于同一个域名，目前浏览器支持建立6个长链接。

1. HTTP1.1默认使用长连接，可有效减少TCP的三次握手开销。

2. HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接

3. 当一个网页文件中包含了很多图像的地址的时候，那就需要很多次的http请求和响应，每次请求和响应都需要一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件，CSS文件等内容时，也会出现类似上述的情况。
4. 为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。

5. HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。

6. 通过请求头中connection字段在表明是否支持长链接
7. 在HTTP 1.1中，client和server都是默认对方支持长链接的(即connection的值默认为Keep-Alive)， 如果client使用HTTP 1.1协议，但又不希望使用长链接，则需要在header中指明connection的值为closer(connection默认为Keep-Alive)；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为closer。不论request还是response的header中包含了值为closer的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

节约带宽，HTTP1.1支持只发送header头信息不带任何body信息，如果服务器认为客户端有权限请求指定数据那就返回100，没有就返回401，当客户端收到100的时候可以才把要请求的信息发给服务器。并且1.1还支持了请求部分内容，如果当前客户端已经有一部分资源了，只需要向服务器请求另外的部分资源即可，这也是支持文件断点续传的基础。RANGE:bytes是HTTP/1.1新增内容，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。RANGE:bytes=XXXX表示要求服务器从文件XXXX字节处开始传送，这就是我们平时所说的断点续传！

HTTP1.1版本中增加了host处理，在HTTP1.0中认为每台服务器都绑定一个唯一的ip地址，因此在URL中并没有传递主机名，但是随着虚拟机技术的发展，可能在一台物理机器上存在多个虚拟主机，并且他们共享了一个ip地址，HTTP1.1中请求消息和响应消息都支持host头域，如果不存在还会报出错误。

HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。由于http协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度。

HTTP1.x 版本存在以下一些问题：

1. HTTP1.x 在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，无法保证数据的安全性。

2. HTTP1.1 版本允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应，可能会造成Head-of-line blocking的问题。

3. HTTP1.x支持了keep-alive，来弥补多次创建连接产生的延迟，但是keepalive使用多了同样会给服务端带来大量的性能压力，并且对于单个文件被不断请求的服务(例如图片存放网站)， keep-alive可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间。

7.1.8.4 HTTP2.0

• HTTP2.0发布于2015年，目前应用还比较少，该版本主要有如下特点：

1. HTTP2.0是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。

2. HTTP2.0复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了队头堵塞的问题,此双向的实时通信称为多工（ Multiplexing）。多路复用：在一个连接里面并发处理请求，不像http1.1在一个tcp连接中各个请求是串行的。花销很大

3. HTTP2.0 允许服务器未经请求，主动向客户端发送资源，即服务器推送。

4. 引入头信息压缩机制（ header compression） ,头信息使用gzip或compress压缩后再发送。在1.0版本后增加了header头信息，2.0版本通过算法把header进行了压缩这样数据体积就更小，在网络上传输就更快。
5. 服务端有了推送功能，将客户端感兴趣的东西推给客户端，当客户端请求这些时，直接去缓存中取就行。

• 关于HTTP2.0使用多路复用技术(Multiplexing)

  多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。

  "HTTP1.1在同一时间对于同一个域名的请求数量有限制，超过限制就会阻塞请求"。多路复用底层采用增加二进制分帧层的方法，使得不改变原来的语义、首部字段的情况下提高传输性能，降低延迟。

  二进制分帧将所有传输信息分割为更小的帧，用二进制进行编码，多个请求都在同一个TCP连接上完成，可以承载任意数量的双向数据流。HTTP/2更有效的使用TCP连接，得到性能上的提升。

如果下图：

二进制分帧层把数据转换为二进制的同时，也把数据分成了一个一个的帧。帧是HTTP/2中数据传输的最小单位；每个帧都有stream_ID字段，表示这个帧属于哪个流，接收方把stream_ID相同的所有帧组合到一起就是被传输的内容了。而流是HTTP/2中的一个逻辑上的概念，它代表着HTTP/1.1中的一个请求或者一个响应，协议规定client发给server的流的stream_ID为奇数，server发给client的流ID是偶数。需要注意的是，流只是一个逻辑概念，便于理解和记忆的，实际并不存在。

在一个TCP链接中，可以同时双向地发送帧，而且不同流中的帧可以交错发送，不需要等某个流发送完，才发送下一个。也就是说在一个TCP连接中，可以同时传输多个流，即可以同时传输多个HTTP请求和响应，这种同时传输不需要遵循先入先出等规定，因此也不会产生阻塞，效率极高。

• 关于HTTP/2新增首部压缩（Server Push）:采用HPACK算法

在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成。一般而言，消息主体都会经过 gzip 压缩，或者本身传输的就是压缩过后的二进制文件（例如图片、音频），但状态行和头部却没有经过任何压缩，直接以纯文本传输。

随着 Web 功能越来越复杂，每个页面产生的请求数也越来越多，根据 HTTP Archive 的统计，当前平均每个页面都会产生上百个请求。越来越多的请求导致消耗在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变动的内容，完全是一种浪费。

Hapck原理,具体规则可以描述为：

1. 通信双方共同维护了一份静态表，包含了常见的头部名称与值的组合
2. 根据先入先出的原则，维护一份可动态添加内容的动态表
3. 用基于该静态哈夫曼码表的哈夫曼编码数据
4. 当要发送一个请求时，会先将其头部和静态表对照，对于完全匹配的键值对，可以直接使用一个数字表示，如method: GET，对于头部名称匹配的键值对，可以将名称使用一个数字传输，同时告诉服务端将它添加到动态表中，以后的相同键值对就用一个数字表示了。这样，像cookie这些不经常变动的值，只用发送一次就好了。

• HTTP/2新增服务端推送（Header Compression）

1. 即服务器发送/user.html时，就可以主动把/user.js和style.csspush给浏览器，使资源提前达到浏览器；除了静态文件，还可以推送比较耗时的API，只是需要提前将参数和cookie等信息通过某个方式告知服务端（如和路由关联）。Apache、GO的net/http、node-spdy都实现了server push（但ngnix没有=_=）

   Server push是HTTP/2协议里面唯一一个需要开发者自己配置的功能。其他功能都是服务器和浏览器自动实现，无需开发者介入。

2. 在HTTP1.1时代，也有提前获取资源的方法，如preload和prefetch，前者是在页面解析初期就告诉浏览器，这个资源是浏览器马上要用到的，可以立刻发送对资源的请求，当需要用到该资源时就可以直接用而不用等待请求和响应的返回了；后者是当前页面用不到但下一页面可能会用到的资源，优先级较低，只有当浏览器空闲时才会请求prefetch标记的资源。从应用层面上看，preload和server push并没有什么区别，但是server push减少浏览器请求的时间，略优于preload，在一些场景中，可以将两者结合使用。

7.2 HTTPS协议

• 什么是Https

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL

• Https的作用

1. 内容加密建立一个信息安全通道，来保证数据传输的安全；
2. 身份认证确认网站的真实性
3. 数据完整性防止内容被第三方冒充或者篡改

• Https的劣势

1. 对数据进行加解密决定了它比http慢
2. 需要进行非对称的加解密，且需要三次握手。首次连接比较慢点，当然现在也有很多的优化。
3. 出于安全考虑，浏览器不会在本地保存HTTPS缓存。实际上，只要在HTTP头中使用特定命令，HTTPS是可以缓存的。Firefox默认只在内存中缓存HTTPS。但是，只要头命令中有Cache-Control: Public，缓存就会被写到硬盘上。 IE只要http头允许就可以缓存https内容，缓存策略与是否使用HTTPS协议无关。

• HTTPS和HTTP的区别

1. https协议需要到CA申请证书。
2. http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
3. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
5. http默认使用80端口，https默认使用443端口

7.3 TCP/IP 协议

• TCP/IP网络协议

TCP/IP是“transmission Control Protocol/Internet Protocol”的简写，中文译名为传输控制协议/互联网络协议）协议， TCP/IP （传输控制协议/网间协议）是一种网络通信协议，它规范了网络上的所有通信设备，尤其是一个主机与另一个主机之间的数据往来格式以及传送方式。TCP/IP 是INTERNET的基础协议，也是一种电脑数据打包和寻址的标准方法。在数据传送中，可以形象地理解为有两个信封，TCP和IP就像是信封，要传递的信息被划分成若干段，每一段塞入一个TCP信封，并在该信封面上记录有分段号的信息，再将TCP信封塞入IP大信封，发送上网。在接受端，一个TCP软件包收集信封，抽出数据，按发送前的顺序还原，并加以校验，若发现差错，TCP将会要求重发。因此，TCP/IP 在INTERNET中几乎可以无差错地传送数据。 对普通用户来说，并不需要了解网络协议的整个结构，仅需了解IP的地址格式，即可与世界各地进行网络通信。

7.4 FTP协议

• FTP协议（文件传输协议）

FTP（File Transfer Protocol，文件传输协议） 是 TCP/IP 协议组中的协议之一。FTP协议包括两个组成部分，其一为FTP服务器，其二为FTP客户端。其中FTP服务器用来存储文件，用户可以使用FTP客户端通过FTP协议访问位于FTP服务器上的资源。在开发网站的时候，通常利用FTP协议把网页或程序传到Web服务器上。此外，由于FTP传输效率非常高，在网络上传输大的文件时，一般也采用该协议。

默认情况下FTP协议使用TCP端口中的 20和21这两个端口，其中20用于传输数据，21用于传输控制信息。但是，是否使用20作为传输数据的端口与FTP使用的传输模式有关，如果采用主动模式，那么数据传输端口就是20；如果采用被动模式，则具体最终使用哪个端口要服务器端和客户端协商决定。

参考大神博客： www.cnblogs.com/li0803/arch…

www.cnblogs.com/riwang/p/12…

李超的WebRTC教学视频

以上是 WebRTC源码研究（4）web服务器工作原理和常用协议基础 的全部内容， 来源链接： utcz.com/a/33586.html