#WebRTC系列文章

1. WebRTC源码研讨（1）WebRTC架构
2. WebRTC源码研讨（2）webrtc源码目录结构
3. WebRTC源码研讨（3）webrtc运转机制
4. WebRTC源码研讨（4）web服务器作业原理和常用协9 – n J T议根底

@[C ] 7TOC]

WebRTC源码研讨（4）web服务器作业原理和常用协议根底

前语

前面3篇博客分别对WebRTC框架的介绍，Web3 T t 8 { M w } bRTC源码目录，WebRTC的运转机制进行了介绍，? ` e U接下来讲解一点关于服务器原理的r X t g U常识。后边博客会写关于WebRTC服务器相关的开发，现在git上面有好多WebRTC相关的流媒体服务器的源码，有时刻能够去深化研讨一下。

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

• 由于WebRTC技能的方针便是在阅读器上完结音z I .视频通讯，现在官网的例子也都是JS编写的，大部分后台逻k – z W o j J辑也是JS编写的，由于安全的原因，许多阅读器例如chrome它是不答应调用本地JSj F ? )文件的，所以你只能把它放在Web服务器端，经过Web服务器下载到本地，O C a l v A然后在运转这些程序。

• 别的一个原因是咱们后边做WebRTC开发离不开信C 4 G 9 4 j令服务器 ，而信令服务器每个公司的完结办法不同K q u D ! i，大部分都是运用WebSocket完结通讯，需求在Web服务器再加上一些库，如用socket IO来构建咱们自己的信令服务器，由于这个原因，咱们十分有必要了解web服务器的作业原理，这样在咱们后边的学习才愈加顺利。

1. Web 服务器简介

详细在互联网时代，做IT的都应该常常听说过Web服务器，咱们常常听说12306买票页面? D L ; N ^ 4 F ^进不去拉，打开一个网页报503过错等等。这些作业常常在咱们的身边发生。那么咱们真的知道什么是Web服务器吗？

• 什么是Web服务器？
  Web服务器概念较为广泛，咱们最常说的Web服务器指的是网站服务器，它是树立在Internet之上并且驻留在某种计算机上的程序。Web服务器能够向Web客户端(如阅读器)供给文档或其他服务，只需是遵从HTTP协议而规划的网络运用程序都能够是Web客户端。

Web服务器和HTTP服务器能够说是同一个东西，当然非得细分的话，HTTP服务器是树立在HTTP协议之上的供给文档阅读的服务器，更多的是供给静态的文件。而Web% | c r w ! 5服务器涵盖了HTTP服务器z + 3 t(这一点能够自行百度百科), Web服务器不只能够存储信息，还能在用户经过Web阅读器E j [ Q供给的信息的根底上运转脚本和程序。
Web服务器 约等于 HTTP服务器 + 其他服务

2. Web 服务器的类型

• 现在市面上有许多web服务器，比方No. G A O l x D a ~dejs、Nginx、Apache，这三个对错常有名的web服务器了，其间Apache是比较老的，市场占有率大概是80%，直到Nginx的呈现，从功用; p y $ g c方面比这个Apache更高，灵敏度什么的都比这个Apache要好得多，所以Nginx逐步就把这个Apache给取代了。
• Nodejs是比较特殊的，它的特殊在于他能够经过JS开发服务端程! 6 n序，也便是说你经过JS开发Web服n V f Z y S务器，一同你d @ a = c 6 r又能u p f G ~ 1够将这个运用程序也是JS放入服务端；这样当阅读器发送一个Http恳求，然后将服务端的代码下到本地去履行。也便是说存在两个JS：一个是用于操控服务器的，一8 l n c V 7个是用于下载到客户端去运转的。
• 由于技能的开展，咱) F e C (们以为JS是未来的@ L J一个趋势，今后一切的程序或许都是在一个阅读器中去履行了，那这样nodeJS就显得它的特别之处了，是很有未来市场的一个web服务器。由于做前端用JS做后端也相同用JS，这样JavaScript的前端程序员就能够无缝的转化过去。
• NodeJS是个十分强大的后端开源的框架，十分值得去研w 8 ~ q O A讨学习。

现在市场上面干流的Web服务器首要有：

• Nodejs ： Nodejs是比较特殊的服务器，能够直接用js开发服务端程序。
• Ngi( K E [ 9nx : Nginx无论是灵敏度Z Q H ^ A d h仍是功用方面都比Apache好许多，是现在的干流。
• Apache： 比较老的服务器，mac系一致般自带这个服务器。F c !

3. Web 服务器的作业原理

3.1 最简略的Web服务器

先来看一2 w 6 ) . = * ~张图解HTTP书本中一张经典的图片：

首要咱们经过上图看出有个人经过阅读器敲入htn Y * { t 2 ^tp^ Q + . N，点回车那么这个恳求就被阅读器发送给力web服务，就发送 了一个Http Request，1 x T k ]这个时分后端服务一般是挂着E T L L ( N一个数据库，它需求做许多的逻辑处理，处理完之后，x E c ! T b J会给阅读器一个呼应，便是Http Response。拿到这个呼应之后实践是一个HTML的页面，就会将这个Hello World显现出来。

现在的前端不或许是简简略单的一个页面了，还有或许是风格类型 、用什么样的字体怎么展现等 ，会有一个css( s N V & P E V文件 ，u B o L ] w L还会又一个JavaScript文件 ，来操控整个页面t p Q r d y D b的行为，那用户拿到这个页面之后，在里边点击一些鼠标事情等等就会改动这个页面不同的行为，这便是一个完整的web服务的作业原理。是不是s@ $ % / ^o easy} : v / 3 E!!!

3.2 Web服务器作业流程

上面讲V g . Y # n A 5的便是一个最简略的Web服务器作业原理了。上面讲的是面临非IT知道，十分浅显的讲解。
接下来咱们站在IT知道的视点，用专业的流程图去9 N :看看，Web服o b l务器的作业流程：

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

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

1. 用户做出了一个操作，能够是填写网址敲回车，能够是点击链接，能够是点q b r Z 7 % # g )击按键等，接着阅读器获取了该事情。
2. 阅读器与对端服务程序树立TCP5 Y U 0 v @ D衔接。
3. 阅读器将用户的事情按照HTTP协议格局**打包k e ^ 6 x 4 {成一个数据包，其实质便是z j E 7 Z L在待发送C C _ 6 % m L缓冲区中的一段有着HTTP协议格局的字节流。
4. 阅读器承认对端可写，并将该数据包推入Interne x q o i L F (et，该包经过网络终究递交到对端服务程序。
5. 服务端程序拿到该数据包后，相同以HTTP协议格局解包，然后解析客户端的意图。
6. 得知客户端意图后，进行分类处理，或是供给某种文| 2 1件、或是处理数据。
7. 将成果装入缓冲区，或是HTML文件、或{ K } ~ _ R s是一张图片等。
8. 按[ @ e Q Q 3 A w *照HTTP协议格局将(7)中的数据打包
9. 服务器5 : ) + W –承认对端可写，并将该数据包推入Internet，该包经过网络终究递交到客户端。
10. 阅读器拿到包后，以HTTP协议格局解包，然后解析数据，假设是HTML文件。
11. 阅读器将HTML文件展现在页面

作为一个服务U I [ Z / k % s )器，其根本的作业无非有三个：

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

而Web服务器的本质便是： 接纳? w k A Z r g 0 ^数据 ⇒ HTTP解析 ⇒ 逻辑处理 ⇒ HTTP封包 ⇒ 发送数据
高档的T Z t S服务器无非便是将这三个部分愈加细致的规划了。

4. Nodejs 服t o A 务器的作业原理

接下来咱们再看nodeJS的作业原理。
咱们先来看一张经典的NodeJS的运转原理图：

• 首要是APPLICATION，也便是咱们自己开发的JavaScript程序3 6 I k l 0 o e，它首要会输出给V8引擎，
• 这个V8引擎咱们都十分清楚了，是从Google阅读器ChromT E X W % {e的项目中抽取出来的，首要对JS进行一些解析作业，解析完之后生成一个二进制代码；
• 接下来是NodeJS本身他自己的一些API,解析后的二进制代码去调用NodeJS API，这儿称为NODE BINDINGS,调用之后NodeJS 还会调用LIBUV的事情处理库。
• NodeJS它的作业原理是一直循环等候事情处理，恳求过来的时分会首要刺进到事情队列当中去，事情循环就不断的从事情队列里边去拿一个个事情，终究去做相应的处理。这个便是NodeJS的作业原理，要点是他有这个V8引擎 。

4.1 N– O F 0 I eodejs 事情处理原理

此外，咱们还A B u # e w能够从别的一个视点去看看NOD! 9 G v M 2EJS是怎么去向理事情。
下图是便是NODEJS在收到事情之后j 9 Z j处理的一个大体逻辑：

• 首要有许多恳求到NODEJS的运用上来，拿到这个恳求之后会生成一个个事情，刺进到这个事情队列当中去，也便是咱们上面讲的LIBUV做的管理的这个事情队列，LIBUV一同发动这个事情循环，不停的从这个事情q x y队列中取出一个个& H f s u J事情去做相应的处理，进程十分简略，直接就 callback回去了。
• callback回去之后直接回来一个response,假设说咱们仅仅HTML的一个页面，当你恳求网址的时分就回来一个Hello，十分的简略，直接就回来了。
• 还有一种就十a K 0 U分复杂，或许要经过调用数据库 ，去做一些查询作业，做数据计算，这时分它会从线程池取一个线程，履行固定的function办法，终究会callback，有或许这个成果是一个中心成果，它会再刺进到事情队列中，也有或许是终究的成果，直接就回来了一个Response。
• 上面便是一个NODEJS事情的一个大体的进程，当然线r : . N a I程用完了之后还要回收，直接回来到这n ^ n ( s个线程池，这便是NODEJS的一个事情处理进程。

5. JavaScriN Y B M T ; 8 [ 4pt解析进程

如下图是JS的解析进程：

• 首要咱们看看JS解析是怎么解析的，首要是这个V8引擎它会收& v [ L # z :到JS的源程序。
• 咱们在服务端要完结服务的流程如下：

1. 首要是写一个JS的小的脚本，经过V8之后生成S / 1 t这个parser，解析之后生成JS的函数，终究交给这个解析器，解析成bytecode,便是这个支撑代码，还有或许先进行优化，
2. 然后构成优化后的代码.
3. 终x N J X Y 6 p 2究在转换成optimized code。

6. V8 引擎简介

• 两个V8 引擎

上面介i z ! u绍了NodeJS的运转原理，在NodeJS运转原理中有介绍到V8引擎。
接下来咱们要点再介绍一下V8引擎，实践在咱们运用Nd zODEJS之后，有时分会给咱们一种困扰，我的服务端也是JS，客户端也是JS，什么时分是服务端的运转什么时分是客户端的运转，那实践是有两个V 8引擎。
如下) 6 Z Y m图所示：

• 实践上在NODEJS里边有个V8引擎，一同在JS 1 2 6 } q @ K .里边也有个V8引擎。
• 当咱们发送一个Http恳求到NodeJS的时分，那实践在恳求之前，NodeJS这个服务它要运转起来。
• 首要它有自己的服务端的这个JS，它经过解析将整个web? 9 {服务运转起来了。
• 它这个JS给V8进行解析，经过调用中心的Lib[ 7 Ruv将整个服务运转起来。
• 这时分客户端阅读器发送一个d E W W ~ ~ . j恳求过来，说我要恳求 某某某文件，解析完了之后经过这个libuv今后去到这个磁盘上，拿到这个JS文件，回来给阅读器，那阅读器这9 # & 4时就收到了服务端的JS，它又交给V8来进行解析。
• 然Z z = e V ]后在做后边的中心操作，调网卡也好读取文件也好去显现也好，那么这个便是客户端所要履行的。

留意：这儿咱们必定要区分开，一个JS是NODEJSc + 2 ( K [ ] ]自己的V8引擎去解析发动的服务 ，别的一种是客户端建议的恳求，NODEJS回来这个JS，然后在经过V8去解析，然后渲染出成果，咱们这个千万不能紊乱了。j & n W 7 Y

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

7.1 HTTP协t ?议

7.1U q ^ k B O k c d.1 HTTP协议简介

• HTTP协议（超文本协议_ 9 x B P F）

（/ t ! 9 e {HyperText Transfer ProtocolN Y 5 L q f e ;，超文本传输协议）是用于从WWW服务器传输超文本到本地阅读器的传输协议。它能够使阅读器愈加高效，使网络传输1 h 2削减。它不只确保计算机正确快速地传输超文v } 8 [ U ~本文档，还承认传输文档中的哪一部分，以及哪部分内容首要显现(如文本先于图形)等。
HTTP是客户端阅读器u ; 7 o或其他程序与Web服务器之间的运用层通讯协议。在Internet上的Web服务器. L G = % 3 G上寄存的都是超文本信息，客` ` 9 b G |户机需求经过HTTP协议传输所要拜访的超文本信息。HTTP包含指令和传输信息，不只可用于Web拜访，也能够用于其他因特网/内联网运用3 ] N ) @ 3 @ c Y体系之间的通讯，然后完结各类运用资源超媒体e t + F n R = % *拜访的集成。
咱们在阅读器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator，一致资源定位符)。就像每家每户都有一个门牌地址3 t % _ % ~ –相同，每个网页也都有一个Internet地址。当你在阅读器的地址框中输入一个URL或是单击一个超级链接时，URL就承认了要阅读的地址。阅读器经过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网: p K 6 5 w页。

7.1.2 HTTP协议的特色

• HTTP协议的特色：

1. 支撑客户/服务器办法。D 4 L B / # F =
2. 简U [ w * a j Y略快速：客户向服务器恳求服务时，只需传送恳求办法3 P r # j = ? ) n和途径。恳求办法常用的有GET、HEAD、POST。每种办法规矩了客户与服务器联系的类型不同。由于HTTP协议简略，使得HTTP服务器的程序规模小，因而通讯速度很快。
3. 灵敏：HTTP答应传输恣意类型的数% ` ~ 9据方针。正在传输的类型由Content-Type加以标记1 a L。Q B z j v _
4. 无衔接：无衔接的意义是约束每次衔接只处理一个恳求。服务器处理完客户的恳求，并收到客户的应对后，即断开衔接。选用这种办g K t d g J j法能够节省传输时刻。
5. 无* ! N f 7状况：HTTP协议是无状l V a况协议。无状况是指协议关于事务处理没有回忆能力{ V m 4 M y。缺少状况意味着假设后续处理需求前面的信息，则它有必要重传，这样或许导致每次衔接传送的数据量增大。另, . r s一方面，在服务器不需求先前信息时它的应对就较快。

7.1.3 HTTP原理

• HTTP原理
  HTTP是一个依据TCP/IP通讯协议来传递数A w q P n据的协议，传输的数据类型为HTML 文件,、图片[ 4 u a 1 7 X E !文件, 查询成果等。
  HTTP协议一般用于B/S架构（）。阅读器作为HTTP客户端经过URL向HTTP服务端即WEB服务器发送一切恳求。

7.1.4 HTTP的一些根本概念

• URI和URL的差异
  HTTP运用一致资源标识符（Uniform Resource Identifiers, URI）来传输数据和树立衔接。
  URI：Uniform Resource Identifier 一致资J b ^ m b 源标识符
  URL：Uniform Resource Location 一致资] V Z o ? g源定位符
  URI 是用来标示 一个详细的资源的，咱们能够经过= @ a URI 知道一个资源是什么。
  URL 则是用来定位详细的资源的，标示了一个详细? B % , D的资源方位。互联网上的每个文件都有一个仅有的URL。

URL,全称是UniformRl v _ BesourceLocator, 中文叫一致资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下一般URL的各部分组成：
www.as J /pxfans.com:8080/news/inde, K i ; a c D 6 (x.…
从上面的URL能够看出，一个完整的URL包含以下几部分：

1. 协议部分：该URL的协议部分为“http：”，这代表网页运用的是HTTP协议。在Internet中能够运用多种协议，如HTTP，FTP等等本例中运用的是HTTP协议。在”HTTP”后边的“//”为分隔符
2. 域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也能够运用IP地址作为域名运用
3. 端口= a : : P 4部分：跟在域名后边的是端口，域名和端口之间运用“:”作为分隔符。端` j $ l口不是一y D %个URL有必要的{ : r $ 5 J Y部分，假y J L 3设省掉端口部分，将选用默许端口
4. 虚拟目录部分：从域名后的第一个“/”开端到终究一个] M , u ] _ w 9“/”停止，是虚拟目录部分。虚拟目录也不是一个URL有必要的部分。本例中的虚拟目录是“/news/”
5. 文件名部分：4 R n u = R K从域名后的终究一个m ! , i y 5 c“/Q g F Q J”开端到“？”停止，是文件名部分，假设没有“?”,则是从域名后的终究一个“/”开端到“#”停止，是文件部分，假设没有“？”和“#”，那么从域名后的终究一个“/”开端到完毕，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一个URL有必要的部分，假设省掉该部分，则运用默许的文件名
6. 锚部分：从“#”开端到终究，都是锚部分。本例中的锚部分是“name”。q T 2 A w锚部分也不是一个URL有必要的部分
7. 参数部分：从“？”开端到“#”停止之间的部分为参数部分，又称查找部分、查询部分。本例中的参数部分为“boD r n 2 Y Q NardID=5&ID=2461: ( 6 : [ ? G .8&page=1”。参数能够答应有多个参数# 3 = I ,，参数与参数之间用“&amph T u ? [ / – (;”作为分隔符。

• URI和URL的差异

1. URI，是uniform resource ide6 r O n –ntifier，一! 0 3 / = . u致资源标识符，用来仅有的标识一个资源。
   Web上可用的每种资源如HTML文档、图画、视频片段、程序等都是一个来URI来定位的
   URI一G U b ! 9 U般由三部组成K Y U C P 2 Q z 0：
   ①拜访资源的命名机_ @ F ~ 3 M t制
   ②寄存资源的主机名
   ③资源本身的称号， C a u C z由途径表明，着重强调于资源。
2. URL是uniform re+ v Y / 4 } q Ksour ; v W o ? l k Uce locator，; Y O w u h一致资源定位器，它是一种详细的URI，即URL能够用来标识一个资源，并且还指明晰怎么locate这个r L – 8 i资源。
   URL是Internet上用来描绘信息资源的字符串，首要用; % Y %在各8 d B种WWW客户程序和服务器程序上，2 u l H A D V 0 P特别是闻名的Mosaic。
   选用URL能! = % B ! T够用一种一致的格局来描绘各种信息资源，包含文件、服务器的地址和目录等。Uo ~ 1RL一般由三部组成：
   ①协议(或称为服务办法)
   ②存有该资源的主机IP地址(有时也包含端口号)
   ③主机资源的详细地址。如目录和文件名等
3. URN，uniform resource name，一致资源命名，是经过姓名来标识资源，比方mailto:java-net@java.sun.com。
   URI是以一种抽象的，高层次概念界说一致资源标识，而URL和URN则是详细的资源标识的办法。URL和URN都是一种URI。抽象地说，每个 URL 都是 URI，但不必定每个 URI 都是 URL。这B S _ S t是由于 URI 还包含一个子类，即一致资源称号 (URN)，它命名资源但不指定怎么定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

7.1.5 HTTP报文格局

7.1.5.1 HTTP恳求报文格局x D T G 5 W X

http恳求由三部分组成，分别是：恳求行、音讯报头、恳求正文

恳求行以一个办法符号开始，以空格分开，后边跟着恳求的URI和协议的版别，格局如下：Method Request-URI HTTP-Version CRLF
其间 Method表明恳求办法；Request-URI是一个一致资源标识符；HTTP-Version表明恳求的HTTP协议版别；CRLF表明回车和换行（除了作为结束的CRLF外，不答应呈现独自的CR或LF字符）。p P t { X c % R T

恳求办法（一切办法全为大写）有多种，各个办法的解说如下：

• GF z F } P j * ? NET ： 恳求获取Request-URI所标识的资源
• POST ： 在Request-URI所标识的I [ + E资源后附加新的H 3 r i p 数据
• HEAD ： 恳求获取由Request-URI所标识的资源的呼应音讯报头! % _ P 3
• PUT ：恳求服务器存储一个资源r c q，并用Request-URI作为其标识
• DELETE ：恳求服务器删去Request-URI所标识的资源
• TRACE ：恳求服务器回送收到的恳求信息，首要用于测试或确诊
• CONNECT ：$ , Z Y保留将来运用
• OPTIONS ：恳求查询服务器的功用，或许查询与资源相关的选项和需求
  运用举例：
• GET办法：在阅读器的地址栏中输入网址的办法拜访网页时，阅读器选用GET办法向服务器获取资源，ep w ] W tg:GET /forE 8 ym.html HTTP/1.1 (CRLF)
• POST办法： 要求被恳求服务器承受附在恳求D B 1 3 ) Q E U 6后边的数据，常用于提交表单。

7.1.2 – h R q D5.2 HTTP呼应报文格局

在接纳和解说恳求音讯后，服务器回来一个HTTP呼应音讯。

HTTP呼应也是由三个部分组成，分别是：状况行、音讯报头、呼应正文

• 状况行格局如下：
  HTTP-Version Status-Code Reason-Phrase CRLF
  其间，HTTP-Version表明服务器HTTP协议的版别；Status-Code表明服务器发回的呼应状况代码$ O g D – T E $ F；Reason-Phrase表明状况代码的文本描绘。
  状况代码有三位X V = Q M X p w G数字组成，第一个数字界说了呼应的类别，且有五种或许取值：

1xx：指示信息–表o { r f } ;明恳求已接纳，持续处理
2xx：成功–表明恳求已被成功接纳、了解、承受
3xx：重定向–要完结恳求有必要进行更进一步的操作
4xx：客户端过错–恳求有语法过, w D错或恳求无法完结
5xx: y -：服务器端过错–服务器未能完结合法的恳求
常见状况代码、状况描绘、阐明：
200 OK //客户G Z o = % F – * t端恳求成功
400 Bad Request //客户端恳求有语法过错，不能被服务器所了解
401 Unauthoro H i J x 3 N Lized //恳求未A g _经授权，这个状况代码有必要和WWW-Authenticate报头域一同运用
403 Forbidden //服务J g 8 v J D ! ? d器收到恳求，可是回绝供给服务
404 N2 C G B ^ b J cot Found //恳求资源不存在，eg：输入了过错的URL
500 Internal Server Error //服务器发生不行预期的过错9 _ % ] J K m e
503 Server% @ ~ & D - G Unavailable //服务器当时T } y L j u R / W不能处理客户端的恳求，一段时刻后或许康复正常
eg：HTTP/1L 1 g # G P.1 200 OK （CRLF）

• 呼应报头

• 呼应正文便是服务器回来的资源的内容

7.1.5.3 HTTP音讯报头

HTTP音讯由客户端到服~ 2 }务器的恳求和服务器到客户端的呼应组成。恳求音讯和呼应音讯都是+ ? 9 b E由开端行（关于恳求音讯，开端行便是恳求行，关于呼应音讯T 3 * 0 C w w 4 |，开端行便是状况行），音讯报头（可选），空行（只需CRLF的行），音讯p Y |正文（可选）组成。

HTTP音讯报头包含一般报头、恳求报头、呼应报头、实体报头。

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

1. 一般报头

1. 在一般报头中，有少数报头域用于一切的恳求和呼应音讯，但并不必于被传输的实体，只用于传输的音讯。
2. CacP q : A E ^ r Ahe-Control : 用于指定缓存指令，缓存指令是单向的（呼应中呈现的缓存指令在恳求中未必会呈现），且是独立的（一个音讯的缓存指令不会影响另一个音讯处理的缓存机制），HTTP1.0运用p = V 5 3 y的相似的报头域为Pragma。
3. 恳求时的缓存指令包含：no-cache（用于指示恳求或呼应音讯不能缓存）、no-store、mam n l 6 ( /x-age、max-stale、min} T c & 0-fresh、only-if-cached;
4. 呼应时的缓存指令包含：public、private、no-cache、no-store、no-transform、must-revalidateY 7 [ , Q、proxy-revalidate、max-age、s-maxage.
5. 为了指示IE阅读器（客户端）不要缓存页面，服务器端的JSP程序能够编写如下：response.sehHeader("Cache-Control","no-cache9 i .")L m 3 p 5 B H C;作用相当于上述代码,这句代码将在发送的呼应音讯中设置一般报头域：Cache-Control:no-cache
6. Date一般报头域表明音讯发生的日期和时刻
7. Connection一般报头域答应发送指定衔接的选项。例如指定衔接是接连，或许指定“close”选项，奉告服务器，在呼应完结后，封闭衔接

2. 恳求报头

1. 恳求报头答应客户端向服务器端传递恳求的附加信息以及客户端本身的信息。
2. 常用的恳求报头
3. Af B * = F X ;ccept: Accept恳求报头域用于指定客户端承受哪些类型的信息。eg：Accept：imagS . , d * u w H Ke/gif，表明客户端期望承受GIF图象格局的资源；Accept：text/html，表明客户端x { g期望承受html文本。
4. Accept-Charset:Accept-Charset恳求报头域用于指定客户端承受的字符集。eg：Accept-Charset:iso-8859-1B n 1 ; U,gb231| l J W 7 1 X , ;2.假设在恳求音讯中没有设置这个域，缺省是^ . r @ M @ Y任何字符集都1 7 5能够承受。
5. Accept-Encoding:Accept-Encoding恳求报头域相似于Accept，可是它是用于指定可承受的内容编码。eg：Accept-B G 4 u [ } Q { VEncoding:gzipd J –.deflate.假设恳求音讯中没有设置这个域服务器假定客户端对各种内容编码都能够承受。
6. Accept-N L p k ~ x 9 V 2Language:Accept-Language恳求报头域相U h U * H 8似于Accept，可是Z 2 6 ;它是用于指定一种自然言语。eg：Accept-Language:zx $ l = [ – Hh-cn.假设恳求o # @ =音讯中没有设置这个报头域，服务器假定客H z o _ / l Z k户端对各种言语都能够承受。
7. Authorizy % M 6 _ 9ation:Authorization恳求报头域首要用于证明客户端有权查看某个u j V资源。当阅读器拜访一个页面时，假设收到服务器的呼应代o L 4 ` + T B码为401（未授权），能够发送一个包含Authorization恳求报头域的恳求，要求服务器对其进行g X m f C `验证。
8. Host（发送恳求时，该报头域是必需的）:
   H} D [ ! b j }ost恳求报头域首要用于指定被恳求资源的Internet主机和端口号，它通常从HTTP URL中提c K U g – w Z I取出来的，eg：
   咱们在阅读器K g A 3 #中输入：www.guet.edu.cn/index.html
   阅读器发送的恳求音Z 5 r Y讯中，就会包含H6 , / Vost恳求报头域，如下：
   Host：www.guet.edu.cn
   此处运用缺省端口号80，若指定了端口号，则变成：Host：www.guet.edu.cn:指定端口号
9. User-Agent
   咱们上网登陆论坛的时分，往往会看到一些欢迎信息，其* o & T H间列出了你的操作体系的称号和版别，你所运用的阅读器的称号和版别，这往往让许多人感到很神奇，实践上@ i { 1，服务器运用程序r 7 %便是从User-Agent这个恳求报头域中获W R p I . F $ r取到这些信息。User-+ C V @ t t d S iAgO 7 S U kent恳求报头域答应客户端将它的操作体系、W 3 n阅M | U Y i z k u读器和其它属性奉告服务器。不过，这个报头域不是必需的，假设咱们自己编写一个阅读器，不运用User-Agent恳求报头域，那么服务器端就无法得知咱们的信息了。

恳7 6 W ( ` G z L求报头举例：

GM k uET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,a* G t g 8 L cpplicaO 8 8 _ 0 R 1 Ltion/vnd.ms-powerp= n ? doint,application/msword,*/* (t O `CRLF)
AcU f [ cept-Language:zh-cn (CRLF)
Accept-Encodk 5 ting:gzip,deflate (CRLF)
If-ModifiC - ; M U K ` 4 ~ed-Since:Wed,05 Ja= u t # H r f j [n 2007 11:21:25 GMT (CRLFH 5 !)
If-+ 1 } [ f l  9None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (b O @ ACRLF)
Host:www.guet.edur { U P._ t m R 2cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)

3. 呼应报头

1. 呼应报头答应服务器传递不能放在状u k n N况行中的附加呼应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步拜访的信息。
2. 常用的呼应报头
3. LocatE . S / Y B B 4 Pion
LocatioI f -n呼应报头C Y 1域用于重定向承受者到一个新的W c 7 3 { P K . Q方位。Location呼应报头域常用在替换域名的时分。
4. Server
Server呼应报头域包含了服务器用来处理恳求的软件信息。与User-Agent恳求报头域v } C P z ` W O m是相对应的v J d y E R。下面是
5. Sero @ | ] k ] Hver呼应报头域的一个例子：
   Server：Apache-Coyote/1.1
   WWW-Authenticate
   WWW-Authenticate呼应报头域有必要被包含在401（未授权的）呼应音讯中，客户端收到401呼应音讯时分，并发送5 g I h 6Authorization报头域恳求服务器对其进行验证时，服务端呼应报头就包含该报头域。
   eg：WWW-Authenticate:Basic realm=”Basic Auth Test!” //能够看出服务器对恳求资源选用的是根本验证机制。~ z ? D W

4. 实体报头

1. 恳求和呼应音讯都能够传送一个实体。一个 [ &实体由实体报头域和实体正文组成，! % t ~ ~但并不是说实体报头域和实体正文要在一同发送，能够只发送实体报头域。实体报头界说了关于实体正文（eg：v y ( ; w 7有无实体正文）和恳求所标识的资源的元信息。
2. 常用的实体报头
3. Content-Encoding
   Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了现已被运用到实体正文的附加内容的编码，因而要取得Content-Type报头域中所引用的媒体类型E 0 u . h，有必要选用相应? 6 L的解码机制。; s ) d % J ^ mContent-Encoding这样用于记载文档的紧缩办法，eg：Content-Encoding：gzip
4. Content-La} l t p @nguage
   Content-Language实u ^ m ! Y体报头域描绘了资源所用的自然言语。没7 + A有设置该域则以为实体内容将供给给一切的言语阅读
   者。eg：Content+ 0 % 0-Language:da
5. Content-Length
   Content-Length实体报头域用于指明实体正文h 0 U %的长度，以字节办法存储的十进制数字来O y y a a 2 1 Z表明。
6. Cont3 J * 1 .ent-Type
   Content-Type实@ ^ M体报头域用语指明发送给接纳者的实体正文的媒体类型。eg：
   Content-Type:text/html;charset=ISO-8859-1
   Content-Type:text/html;charset=GB2312
7. Last-Modified
   Last-Modified实体报头域用于指示资源的终究修正日期和时刻。
8. Expires
   Expires实8 : : A y z 1体报头域给出呼应过期的日期和时刻。为了让署理服务器或阅读器在一段时刻今后更新缓存中(再次拜访曾拜访过的页面时，直接从缓存中加载，缩短呼应时刻和降低服务器负载)的页面，咱们能够运用Expires实体报头域指定页面过期的时刻。eg：Expires：Thu，15 Sep 2: L – 2006 16:2S g @3:12 GMT
   HTTP1.1的客户端和缓存有必要将其他非法的日期格局（包含0）看作现已过期。eg：为了让阅读器g P 2 u K不要缓存页面，咱们也能够运用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 等规范扩展。一切状况码的第一j . ; R p个数字代表了呼应的五种状况之一。所示的音讯短语是典型的，可是能够供给任何可读取的代替b – $ A * # ~ g计划。 除非还有阐明，状况码是HTTP / 1.1规v X V L j ~ ^范（RFC 7231）的一部分。

总的来[ l C 8 =说状况码分为5大类：

• 1xx& v h P t O 5：指示信息–表明恳求已接纳，持续处理
• 2xx：成功–表明恳求已被成功接纳、了解、承受
• 3xx：– ? b g重定向–要完结恳求有必要进行更进一步的操作
• 4xx：客户端过错–恳求有语法过错或恳求无法完结
• 5xx：服务器端过j 3 7 d Z 1错–服务器未能完结合法的恳求

  

详细每个分类的状况码意义详解如下：

• 音讯

• 成功w { V C R [ L x 8
  这一类型的状况码，代表恳4 q ? # f T X求已成功被服务器接纳、了解、并承受。! % ^

• 重定向

这类状况m ! K M {码代表需求客户端采取进一步的操作才干完结恳求。通常，这些状况码用来重定向，后续的恳求地址（重定向方针）在本次呼2 / % x % X应的 Location 域中指明。
当且仅当后续的恳求所运用的办法是 GET 或许 HEAD 时，用户阅读器才干够在没有用户介入的状况下主动提交所需求的后续恳求。客户端应当主动监测无限循环重定向（例如：A->AE b p W X，或许A-&gt@ G _;B->C->A），由于这会导致服务A | c 7 v器和x ? C g客户端许多不必要的资源耗费。按照 HTTP/e R B N q1.0 版规范的主张，阅读器4 C | X G g不该主动拜访超越5次的重定向。

• 恳求过错

这类的状况码代表了客户端看起来或许发生了过错，妨碍了服务器的处理。除非呼应的是一个 HEAD 恳求，不然服务器就应该回来一个解说当时过错状况的实体，以及这是暂时的仍是永久性的状z K i ^ i ( c }况。这些状况码适用于任何恳求办法。阅B M 6 O F读器应当向用户显现任何包含在此类过错呼应中的实体内容。
假设过错发生时客户端正在传送数据，那么运用TCP的服务器完结应当仔细确保– x y z v R #在封闭客户端与服务器之间的衔接之前，客户端现已收到了包含过错信息5 x $ ~ j $的数据包~ f R h . A S 8。假设客户端在收到过错信息后持续向服务器# W =发送数据，服务器的TCP栈将3 3 _ A : U向客户端发送一个重置数据包，以铲除该客户端一切还未辨认的输入缓冲，避免这些数据被服务器上的运用程序读取并干扰后者。

• 服务器过错

（5、6字头）
这类状况码代表了服务器在处理恳求的进程中有过错或许反常状况发生，也有或许是服务器意识到以当时的软硬件资源无法完结对恳求的处理。除非这是一个HEAD 恳求，不然服务器应当包含一个解说当时过错状况以及这个状况是暂时的仍是永久的解说信息实体g k u O。阅读器应当向用户展现任何在当时呼应中被包含的实体。
这些状况码适用于任何呼应办法。

7.1.8 各个版别差异

• HTTP 各个版别

7.1.8.15 p e ] G u : t HTTP 0.9

开始的http版别，仅支撑get办法，只能传输纯文本内容，所以恳求完毕服务段会给客户端回来一个HTML格局的字符串，然后由阅读器自己渲染。

http0.9是典型的无状况衔接（无状况是指协议关于事务处理没有回忆功f S O 1 & 6用，对同一个url恳求没有上下文关系，每次的恳求都是独立的，服务器中没有保存客户端的状况）

7.1.8.2 HTTP1.0

这个版别后任何文件办法都能够被传输，本质上支撑长衔接，: G M o {可是a d z默许仍是短衔接，增加了keep-alj v xive关键字因由短链接变成长衔接。

HTTP的恳求和回应格局也发生了改动，除了要传输的数据之外，每次通讯都包含头信息，用来描绘一些信息。

还增加了状况码（status code）、多字符集支撑、多部分发送（multiB M s & c S R q T-part type）、权限（authorization）、缓存（cachg w % ^ Ue）、内容编码（content encoding）等

7.1.8.3 HTTO I j a ( N z MP1.1

HTTP1.1是现在最为干流的http协议版别，从1# f 4 o S997年发布至今，仍是干流的http协议版别。首要改动有3个方面：& | ~

• 引进了耐久衔接（ persistent connection），即TCP衔接默许不封闭，能够被多个恳求复用，不必声明Connection: keep-alive。

• 引进了管道机制（ pipelining），即在同一个TCP衔接里，客户端能够一同发送多个
  恳求，进一步改进了HTTP协议的功率。

• 新增办法：Pd h L q a ( cUT、 PD C r ] Q P D 4 }ATCH、 OPTIONS、 DELETE。

详细来说：HTTP^ y u l G16 M 2 = F 5.1最大的改动便是引C A n 5 – F 8 e 6进了长链接，也便# ; E . }是TCP链接默许是不封闭的能够被多个恳求复用。客户端或许服务器假设长时刻发现对方没有活动就会封闭链接，可是规范的做法是客户端在终究一个恳求的时分要求服务器封闭链接。关于同一个域名，现在阅读器支撑树立6个长链接2 7 , ,。

1. HTTP1.1默许运用长衔接，可有用7 L & P F削减TCP的三次握手开销。
2. HTTP 1.0规矩阅读器与服务器只坚持短暂的衔接，阅读器的每次恳求都需求与服务器树立一个TCP衔接，服务器完结恳求处理后当即断开TCP衔接
3. 当一个网页文件中包含了许多图画的地址的时分，那就需求许屡次的http恳求和呼应，每次恳求和呼应都需求H : * ? c ! c G 7一个独自的衔接，每次衔接仅仅传输一个文档和图画，上一次和下一次恳求完全分离。即使图画文件都很小，可是客户端和服务器端每次树立和封闭衔接却是一个相对比较费时的进程，并且会u q x t I _ e K ~严重影响客户机和服务器的功用。当一个网页文件中包含JavaScript文件，CSa 6 vS文件等内容时，也会呈现相似上述的状况。
4. 为了战胜HTTP 1X W @.O a E D X I 8 G0的这个缺陷，HTTP 1.1支撑耐久衔接（HTTP/1.1的默许办法运用带流水线的耐久衔接），在一个TCP衔接上能够传送多个HTTP恳求和呼应，削减了树立和封闭衔接的耗费和推迟。一个A : ^ 0 m V Q e 5包含有许多图画的网页文件的多个恳求和应对能够在一个衔接中传输p l 7 s B ! P，但每个独自的网页文件的恳求和应对依然需求运用各自的衔接。
5. HTTP 1.1还答应客户端不必等候上一次恳h R 3 9 p求成果回来，就能够发出下一次恳求，但: 6 ! m K服务器端有必要按照接纳到客户端恳求的先后次序顺次回送呼应成果，以确保客户端能够区分出每次恳求的呼应内容，这样也显著地削减了整个下载进程所需求的时刻。
6. 经过恳求头中connection字段在表明是否支撑长链接
7. 在HTTP 1.1中，client和server都是默许对方支撑长链接的(即connection的值默以为Keep-Alive)， 假设client运用HTTP 1.1协议，但又不期望运用长链接，则需求在header中指明connection的值为closer(connection默以为Keep-Alive)；假设server方c w k i也不想支撑长链接，则在response中也需求7 – L u清晰阐明connection的值为closer。不管request仍是respog F R u 2 unse的hel V L Qader中包含了值为closer的connecA p b 0 ztion，都表明当时正在运用的tcp链接在当天恳求处理完毕后会被断掉。今后c. & Alien$ T ! S a d 4 ? (t再进行新的恳求时就有必要创立新的tcp链接了。

节省带宽，HTTP1.1支撑只发送header头信息不带任何body信息，假设服务器以为客户端有权限恳求指定数据那就回来100，% } N K没有就回来401% f ) G，当客户端收到100的时分能够才把要J t T Y z f .恳求的信息发给服务器。并且1.1还支撑了恳求部分内容，假设当时客户端现已有一部分资源了，只需求向服务器恳求别的的部分资源即可，这也是支撑文件断点续传的根底。RANGE:bytes是HTTP/1.1新增内容，HTTP/1.0每次传送文件都是从文件头8 v i l O开端，即0字节处开端。RANGE:bytes=XXXX表明要求服务器从文件XXXX字节处开端传送，这便是咱们平时所说的断点续传！

HTTP1.1版别中增加了host处理，在HTTP1.0中以为9 E U Z z 9 !每台服务器都绑定一个仅有的ip地址，因而在URL中并没有传递主机名，可是跟着虚拟机技能的开展，或许在一台物理机器上存在多个虚拟主机，并且他们同享了一个m } { i S ^ nip地址，HTTP1.1中恳求音讯和呼应音讯都支撑host头域，假设不存在还会报出过错。

HTTP 1n # l ^ f * ..1还供给了与身份认证、状况管理和Cache缓存等机制相关的恳求头和呼应头。由于http协议不带有状况，每次恳求都有必要附上一切信息。恳求的许多字段都是重复的，糟蹋带宽，影响h F ` *速度。

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

1. HTTP1.x 在传输数据时，一切传输的内容都是明文，客户端和服务器端都无法验证J x M 1 s @ f对方的身 K ` e Z P P S O份，无法确保数据的安全性。
2. HTTP1.f 3 i @1 版别答应复用TCP衔接，可是同一个TCR ! GP衔接里边，一切的数据通讯是按次序进行的。服务器只需处理完一个回应，才会进[ _ & ] K ! 1行] z Z Y M # . .下一个回应，或许会造成Head-of-linG p [e blocking的问题。
3. HTTP1.x支撑了keep-alive，来补偿屡次创立衔接发生的推迟，可是keepalive运用多了相同会给服务端带来许多的功用压力，并且关于单个{ _ U文件被不断恳求的服务(例如图片寄存网站)， keep-alive或许会极大的影响功用，由于它在文件被恳求之后还坚持了不必要的衔接很长时刻。

7I ; ! Z H & 7.1.8.4 HTTP2.0

• HTTP2.0发布于2015年，现在运用还比较少，该版别首要有如下g ( D | } r特色：

1. HTTP2.0是一个彻底的二进制协议，头信息和数据体J q p Y都是二进制，并且统称为”帧”（frame）：头信息帧和数据帧。
2. HTTP2.0复用TCP衔接，在一个衔接里Z = i M，客户端和阅读器都能够一同发送多个恳求或回应，且不必按次序一一对应，避免了队头阻塞的问题,此双向的实时通讯称为多工（ Multiplexing）。多路复用：在b @ ; d & q J一个衔接里边并发处理恳求，不像httD A n = ! i y $ Cp1.1在一A V O个tcp衔接中各个恳求是串行的。花销很大
3. HTTP2.0 答应服务器8 y p U ! m H %未经恳求，主意向客户端发送资源，即服务器推送。
4. 引进头信息紧缩机制（ header compression） ,头信息运用gzip或c? . N s X p k C vompress紧缩后再发送。在1.0版别& r I后增加了header头信息，2.0版别经过算法把header进行了紧缩这样数据体积就更小，在网络上传输就更快。
5. 服务端有了推送功用，将客户端感兴趣的东西% _ D a d K { , P推给客户端，当客户端恳求这些时，直接去缓存中取就行。o N L

• 关于HTTP2.0运用多路复用技能(Multiplexing)
  多路, i n s复用答应一同经过单一的 H; k – #TTP/2 衔接建议多重的恳求-呼应音讯。
  “HTTP1.1在同一时刻关于同一个域名的恳求数量有约束，超越约束就会阻塞恳求”。多路复用底层选用增加二进制分帧层的办法，使得不改动原来的语义M ] Y . ~ W、首部字段的状况下提高传输功用，降低推迟。
  二进制分帧将一切传输信息分割为更小的帧，用二进% % Q [ | X : X X制进行编码，多个恳p z Z g f 8 d 2 )求都在同一个TCP衔8 Z U – b j ~ }接上完结，能够承载恣意数量的双向数据流。HTTP/2更有用的运用TCP衔接，得到功用上的提升。

假设下图：

二进制分帧层把数据转换为二进制的一同，也把数据分红了一个一个的帧。帧是HTTP/2中数据传输的最小单位；每个帧都有stream_ID字段，表明这个帧归于哪个流，接纳方把stream_ID! @ 5 P ] Y相同的一切帧组合到一同便是被传输的内容了。而流是HTTP/2中的一个逻辑上的概念6 U 2 Y _ } P，它代表着HTTP/1.1中的一个恳– x L I 6 W求或许一个呼应，, F 5 ^ e w协议规矩clieW 8 { y _ ] Lnt发给serverW q b ` X $ A ) 4的流的stream_ID为奇数，server发给client% 4 ( 4 Q的流ID是偶数。需求留意的是y o =，流仅仅一个逻辑概念，便于了解和回忆的，{ L ;实践并不存在。

在一个TCP链接中，能够一同双向地W s g { / 4 E L发送帧，并且不同流中的帧能够交织发送，不需求等某个流发送完，才发送下一个。也便是说在一个TCP衔接中，能够一同传输多个流，即能够一同传输多个HTTP恳求和呼应，这种一同传输不需求遵从先入先出等规矩，因而也不会发生阻塞，功率极高。

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

在 HTTP/1 中，z _ ` = + FHTTP 恳求和呼应都是由「状况行、恳求 / 呼应头部、音讯主体」三} W `部分组成。一般来说，音讯主体都会经过 gzip 紧缩，或许本身传输的便是紧缩过后的二进制文件（例如图片、音频），但状况行和头部却没有经过任何紧缩，直接以纯文本传输。
跟着 Web 功用越来越复杂，每个页面发生的恳求数也越来越多@ , . o，依据 HTTP Archive 的计算，当时均匀每个页面都会发生上百个恳求。越来越多的恳L 0 W * q x { ?求导致耗费在头部的流量越来越多，尤其是每次都要传输 UserAgent、Cookie 这类不会频繁变化的内容，完全是一种糟蹋。
Hapck原理,详细规矩能够描绘为：~ + G b a l N A .

1. 通讯两边共同保护了一份静态表，包含了常见的头部称号与值的组合
2. 依据先入先出的准则，保护7 * # * Z , – T一份可动态增加内容, w 2 b g的动态表
3. 用依据该静Z 9 6 c d v j C k态哈夫曼码表的哈夫曼编码数据
4. 当要发送一个u Y h % ` h m 8 e恳求时，会先将其头部和静态表对照，关于完全匹配的键值对，能够直接运用一个数字表明，如method: GET，关于头部称号匹配的键值对，能够将称号运用一个数字传输，一同奉告服务端将它增加到动态表中，今后的相同键值对i H L g就用一个数字表q A Z _ /明了。N R 2 2 K这样，像cookie这些不常常变化的值，只用发送一次就好了。

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

1. 即服务器发送/user.html时，就能够主动把F Q + a T 7/us% 9 9 ] } C %er.js和style.cG A A ~ h r Nsspush给阅读器，使资源提早到达阅读器；除了静态文件，还能够推送比较耗时的API，仅仅需求提早将参数和cookie等信息经过某个办法奉告服务端（如和路由关联）。Apache、GO的net/http、node-spdy都完p – s结V I 9了server push（但ngnix没有=_=）
   Serves b ` Ir push是HTTP/2协议里边仅有一个需求开发者自己装备的功用。其他功用都是服务器和n r $阅读器主动完结，无需开发者介入` 9 H y 8 ,。
2. 在HTTP1.1时代，也有提早获取资源的办法，如` J t B v Lpreload和prefetch，前者是在页面解析初期就奉告b [ g ) C ( Y |阅读器，这个资源是阅读器立刻要用到的，能够立g + , ?刻发送对资源的恳求，当需求用到该资源时就能够直接用而不必等候恳求和呼应的回来了；后者是当时页面用不到但下一页面或许会用到的资源，优先级较低，只需当阅读器空闲时才G 7 . 2 W c w K会恳求prefetch标记的资源。从运用层面上看，preload和server push并没有什么差异，可是server push削减阅读器恳求的时刻，略优] ] `于preload，在一些场景– E r r Y {中，能够将两3 t J b A * H a者结合运用。

7.2 HTTPS协议

• 什么是Https

HTTPS（全称：Hypertext Transf* o | l : f D 9er Protocol over0 o / y P 5 K Secure Socket Layer），是以安全为方针的H] } v ~ o H BT$ xTP通道，简略讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全根底是SSL，因而加密的详细内容就需求SSL

• Https的作用

1. 内容加密树立一个信息安全y w : !通道，来确保数据传输的安全；
2. 身份认证承认网站的真实性
3. 数据完整性避免内容被第三方假充或许篡改

• Https的劣势

1. 对数据进行加解密决议了它比http慢
2. 需求进行非对称的加解密，且需v n Q求; [ 7 h F三_ e F次握手。V # f首次衔接比较慢点，当然现在也有许多的优化。
3. 出于安全考虑，阅读器不会在本地保存HTTo ? } J j J dPS缓存。实践上，只需在HTTP头中运用特定指令，HTTPS是能够缓存的。Firefox默许只在内存中缓存HTTP 4 9 V + s %PS。可是4 J Z G I g 6 } ~，只需头指令中有Cache-Control: Public，缓存就会被写到硬盘上。 I) [ * ^ P 7E只需http头答应就能够缓存, : G _ t I L 6 yh~ ~ P . L Z 7 } Https内容，缓存策略与是否运用HTTPS协议无关。

• HTTPS和HTTP的差异

1. ht^ H Q V 4 q H o Qtps协议需求到CA申请证书。
2. http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
3. http和https运用的是| & )完全不同的衔接办法，用的端口也不相同4 p V 7 H k # K _，前者是80，后者是443。
4. http的衔接很简略，是无状况的；HTTPS协议是由SSL+HTTP协议构建的可进行Q q s加密传输、身, o a P j份认证的网络协议，比http协议安全。
5. h= z 8 _ = 2 |ttp默i w b . z Q许运用80端口，https默许运用443端口

7.3 TCP/IP 协议

• TCP/IP网络协议

TCP/IP是“transmission Control Protocol/Internet Protocol”的简写，中文译名为传输操控协议/互联网络M L Z j Y U s d o协议）协议， TCP/IP （传输操控协议/网间协议）是一种网络通讯协议，它规范了网络上的一切通讯设备，尤其是一个主机与另一个主机之间的数据往来格局L x G ] 9 D . ] 2以及传送办N 6 i o c Z法。TCP/IP 是INTERNET的根底协议，也是一种电脑数据打包和寻址的规{ f M E ~ 5 %范办法。在数据传送中，能够形象地了解为有两个信封，TCP和IP就像是信封，要传递的信息被I # ( u b @划分红若干段，每一段塞入一个TG & # D , YCP信y r L # +封，并在该信封面上记载有分段号的信息，再将TCP信封塞入IP大信封，发送上网。在承受端，一个TCP软件包收集信封，抽出数据，按发送前的次序还原，并加以校验，若发现差错，TCP将会要求重发。因而，TCP/IP 在INTERNET中简直能够无差错地传送数据。 对一般用户来说，并不需b – f r . I l求了解网络协议的整个结构，仅需了解IP的地址格局，即可与世界各地进行网络通讯。

7.4 FTP协议

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

FTP（File Transfer P4 r u Frotocol，文件传输协议） 是 TCP/IP 协议组中的协议之一。FTP协议包含两* # % +个组成部分，其一为FTP服务器，其二为FTP客户端。其间FTP服务器用来存储文件，5 t H Y R用户能够运用FTP客户端经过FTP协议拜访坐落FTP服务器上的资源。在开发网站的时分，通常运用FT@ q :P协议把网页或L m U L ! 4 t程序传到Web服务器上。此外，由于FTP传输功率十分高，在网络上传输大的文件时，一般也W t (选用该协议。
默许状况下FTP协议运用TCP端口中的 20和217 Z这两个端口，其间20用于传输数据，21用于传输操控信息。可是，是否运用20作为传输数据的端口与FTP运用的传输办法有E v j E 4 h关，假设选用主动办法，那么数据传输端口便是20；假设选用! 7 M F被动办法，则详细终究运用哪个端口要服务器端和客户端洽谈决议。

参阅大神博客： www.cnblogs.com/li0803/arch…
www.cnblogs.com/Q U B priwang/p/12…
李超的WebRTC教育视频] 2 S d m k 2