1.Web应用与HTTP协议
1.1Web基础概念
1>Web由网页构成，而且网页可以相互链接。
2>网页包含多个对象，对象可以是HTML文件、JPEG图片、视频文件、动态脚本等，HTML文件包含对其他对象引用的链接。
3>对象如何寻址？
通过URL（统一资源定位器），URL是用来表示从互联网上得到资源位置和访问这些资源的方法。URL由四部分组成：<协议>://<主机>:<端口>/<路径>。（像HTTP的URL会省略端口号80）
1.2HTTP协议基础概念
1>web应用遵循HTTP协议（超文本传输协议）
2>HTTP协议使用的是C/S结构
客户——Browser（浏览器）：请求、接收、展示Web对象
服务器——Web Server：响应客户的请求，发送对象
3>使用TCP传输服务
服务器在80端口等待客户的请求
浏览器发起到服务器的TCP连接（创建套接字Socket）
服务器接受来自浏览器的TCP连接
浏览器（HTTP客户端）与Web服务器（HTTP服务器）交换HTTP消息
关闭TCP连接
4> HTTP协议是一个无状态协议
服务器不维护任何有关客户端过去所发请求的信息（就是说不记录之前的情况）
5>HTTP连接的两种类型
非持久性连接：每个TCP连接最多允许传输一个对象，HTTP1.0版本使用的是非持久性连接（需要两个RTT加文档传输时间，因为发送TCP建立连接和响应需要一个RTT，HTTP请求报文和请求文档作为响应报文需要一个RTT时间外加传输文档时间《计算机网络第七版》P269）
RTT(Round-Trip Time): 往返时延，在计算机网络中它也是一个重要的性能指标，它表示从发送端发送数据开始，到发送端收到来自接收端的确认
持久性连接：每个TCP连接允许传输多个对象，HTTP 1.1版本默认使用持久性连接
1.3HTTP请求消息
客户端发送一个HTTP请求信息包含四个部分：请求行、请求头部、空行、实体主体。
1.3.1 开始行
请求行用于区分请求报文还是响应报文，请求报文中开始行叫请求行，响应报文中开始行叫状态行。请求行中有请求方法、URL、协议版本、回车CR、换行LF。请求方法有GET、POST等
1.3.2请求头部（用的key:value）：
通用报头：既可以出现在请求报头，也可以出现在响应报头中
Date：表示消息产生的日期和时间
Connection：允许发送指定连接的选项，例如指定连接是连续的，或者指定“close”选项，通知服务器，在响应完成后，关闭连接
Cache-Control：用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制）
请求报头：请求报头通知服务器关于客户端请求的信息，典型的请求头有：
Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机
User-Agent：发送请求的浏览器类型、操作系统等信息
Accept：客户端可识别的内容类型列表，用于指定客户端接收那些类型的信息
Accept-Encoding：客户端可识别的数据编码
Accept-Language：表示浏览器所支持的语言类型
Connection：允许客户端和服务器指定与请求/响应连接有关的选项，例如这是为Keep-Alive则表示保持连接。
Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。
响应报头：用于服务器传递自身信息的响应，常见的响应报头：
Location：用于重定向接受者到一个新的位置，常用在更换域名的时候
Server：包含可服务器用来处理请求的系统信息，与User-Agent请求报头是相对应的
实体报头：实体报头用来定于被传送资源的信息，既可以用于请求也可用于响应。请求和响应消息都可以传送一个实体，常见的实体报头为：
Content-Type：发送给接收者的实体正文的媒体类型
Content-Lenght：实体正文的长度
Content-Language：描述资源所用的自然语言，没有设置则该选项则认为实体内容将提供给所有的语言阅读
Content-Encoding：实体报头被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。
Last-Modified：实体报头用于指示资源的最后修改日期和时间
Expires：实体报头给出响应过期的日期和时间
1.3.3实体主体
请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。
1.4HTTP请求实例
1> Get请求例子
使用Charles抓取的request：
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host img.mukewang.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept image/webp,image/,/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8
第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本.
GET说明请求类型为GET,[/562f25980001b1b106000338.jpg]为要访问的资源，该行的最后一部分说明使用的是HTTP1.1版本。
第二部分：请求头部，紧接着请求行（即第一行）之后的部分，用来说明服务器要使用的附加信息
从第二行起为请求头部，HOST将指出请求的目的地.User-Agent,服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础.该信息由你的浏览器来定义,并且在每个请求中自动发送等等
第三部分：空行，请求头部后面的空行是必须的
即使第四部分的请求数据为空，也必须有空行。
第四部分：请求数据也叫主体，可以添加任意的其他数据。
这个例子的请求数据为空。
2>POST请求例子
使用Charles抓取的request：
POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive
name=Professional%20Ajax&publisher=Wiley
第一部分：请求行，第一行明了是post请求，以及http1.1版本。
第二部分：请求头部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：请求数据，第八行。
1.5HTTP响应信息
响应信息由状态行、响应头、空行和实体主体四部分组成
1.5.1状态行由协议版本、状态码、以及解释状态码的短语组成
1>状态码：状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:
1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现
5xx：服务器端错误–服务器未能实现合法的请求
2>常见状态码以及对应短语：
200 OK //客户端请求成功
202 Accepted //接受
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
1.5.2响应头见1.3.2请求头部分
1.5.3实体主体
就是响应的正文，如果把HTTP协议比作快递箱子的话，实体主体就是箱子里面装的内容，可以空。这里是服务器传给浏览器的文本信息。
1.6HTTP响应实例
例子
HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8
第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）
第二部分：消息报头，用来说明客户端要使用的一些附加信息
第二行和第三行为消息报头，
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
第三部分：空行，消息报头后面的空行是必须的
第四部分：响应正文，服务器返回给客户端的文本信息。
空行后面的html部分为响应正文。
1.7HTTP工作原理
HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。
以下是 HTTP 请求/响应的步骤：
1、客户端连接到Web服务器
一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。例如，http://www.oakcms.cn。
2、发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和实体主体4部分组成。
3、服务器接受请求并返回HTTP响应
Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。
4、释放连接TCP连接
若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接;若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求;
5、客户端浏览器解析HTML内容
客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。
例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
1、浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址;
2、解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立TCP连接;
3、浏览器发出读取文件(URL 中域名后面部分对应的文件)的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器;
4、服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器;
5、释放 TCP连接;
6、浏览器将该 html 文本并显示内容;
参考：
https://www.cnblogs.com/ranyonsue/p/5984001.html
https://www.cnblogs.com/lexiaofei/p/6943690.html
https://www.cnblogs.com/biyeymyhjob/archive/2012/07/28/2612910.html
2.HTTPS协议
实际使用中，绝大说的网站现在都采用的是https协议，这也是未来互联网发展的趋势。
2.1HTTPS协议基本概念
2.1.1HTTP协议存在的问题及解决方法
HTTP存在的问题
1>请求信息明文传输，容易被窃听截取。
2>数据的完整性未校验，容易被篡改。
3>没有验证对方身份，存在冒充危险。
为了解决上述HTTP存在的问题，就用到了HTTPS。
HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：一般理解为HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。
那么SSL又是什么？
SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。
HTTPS可以保证数据完整性、数据私密性、提供身份认证。
2.1.2HTTPS协议通信
HTTPS协议通信：HTTPS是HTTP报文直接将报文信息传输给SSL套接字进行加密，SSL加密后将加密后的报文发送给TCP套接字，然后TCP套接字再将加密后的报文发送给目的主机，目的主机将通过TCP套接字获取加密后的报文给SSL套接字，SSL解密后交给对应进程。
2.2几种加密技术
2.2.1对称加密
1>对称加密的过程
假如由两个算法满足F1（K, data）= X; F2(K , X ) = data; 其中K是密钥，data是要传输的数据，X为实际传输的数据。如下图：
客户端想要传输data1，通过F1与K进行加密后生成X1传给服务器，服务器接收X1，通过F2与K将X1解密成data1。同样服务器也可以将data2加密成X2，客户端收到X2后解密得到data2。
2>对称加密的缺陷
由于密钥K只有一个，所以都知道这个密钥，那么这个加密相当于没加密，如下图：
当黑客获取知道密钥后，接收客户端发送过来的通过了加密的数据X1，黑客通过密钥进行解密，得到data1，然后继续将X1发给服务器，服务器解密后得到data1。服务器向客户端发送data2效果与data1一样，仍然会被黑客截获。
2.2.2非对称加密
1>非对称加密过程
假如有两组算法：
第一组：F1(pk , data) = Y, F2(sk , Y) = data;
第二组：F3(sk , data) = Y’, F4(pk , Y’) = data;
其中pk为公钥，sk为私钥，pk客户端与服务器都有，但私钥只有服务器拥有。非对称加密过程如下图：
客户端拥有公钥，将数据data1进行加密称为Y，把Y传输给服务器。服务器使用私钥解密Y，得到数据data1。由于客户端没有私钥，所以服务器想把数据data2通过公钥加密传给客户端是不可能的。所以，服务器只能通过私钥加密data2，客户端使用公钥解密得到数据data2。
2>非对称加密的缺陷
虽然私钥只有服务器有，客户端通过公钥进行加密是安全的。但是公钥是大家都有的，服务器用私钥加密传给客户端时就不安全，因为都可以通过公钥解密。
2.2.3非对称加密+对称加密
1>非对称加密+对称加密的过程
非对称加密只有客户端发送给服务器是安全的，对称加密缺陷在于密钥谁都知道，那两种加密能不能结合？如下图：
先请求公钥pk,客户端生成随机数num，将num当作只有客户端与服务器知道的密钥（弥补对称加密中密钥都知道的问题），服务器通过私钥sk解密Y得到num，这样客户端与服务器就可以把num当作密钥，进行对称加密。
2> 中间人问题
即使对称加密+非对称加密仍然并非完全安全，如下图：
黑客手里也有一对公钥与私钥pk’/sk’。所以客户端请求pk时黑客给pk‘，然后黑客假装客户端也去向服务器请求pk，此时客户端得到pk’。黑客得到pk。客户端用得到得公钥pk’加密随机数num,黑客通过sk’解密YY得到随机数num，同时用随机数num与公钥pk加密得到Y发送给服务器，服务器解密得到随机数num。此时客户端、黑客、服务器都将num作为密钥使用，之前的优势完全没有了。对了，上面返回的ok是为了方便理解，后面有提及。
2.2.4对称加密+非对称加密+CA
其实对称加密+非对称加密关键在于申请公钥pk时，pk的安全性，那么有没有什么办法可以保证pk的安全性呢？如下图：
首先是license是怎么来的？服务器有公钥pk，CA也有公钥cpk与私钥csk，CA通过F(csk,pk)=license，其实就是CA会使用自己的私钥给服务器的公钥进行加密，license就是加密后的产物。客户端得到license后，通过CA提供的公钥cpk解密license得到服务器的公钥pk。这里cpk是被内置在浏览器/操作系统中是不可修改的，所以浏览器就能通过license是否安全来判断传输是否安全。
所以，就算黑客在客户端请求license时就拦截了，也无法返回一个安全的license，也就是说安不安全就看CA了，是否能够通过认证。
2.3TLS握手机制
2.3.1数字证书
1>数字证书 (digital certificate)：在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信，这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥，具体做法就是服务器不直接向客户端发送公钥，而是要求受信任的第三方，也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。
注：这就是上面返回license的过程及其原因
2>数字证书一般包含以下内容：
证书所有者的公钥
证书所有者的专有名称
证书颁发机构的专有名称
证书的有效起始日期
证书的过期日期
证书数据格式的版本号
序列号，这是证书颁发机构为该证书分配的唯一标识符
2.3.2数字签名
1>数字签名 (digital signature)：这个概念很好理解，其实跟人的手写签名类似，是为了确保数据发送者的合法身份，也可以确保数据内容未遭到篡改，保证数据完整性。与手写签名不同的是，数字签名会随着文本数据的变化而变化。具体到数字证书的应用场景。
2>数字签名的生成和验证流程如下：
服务器对证书内容进行信息摘要计算 (常用算法有 SHA-256等)，得到摘要信息，再用私钥把摘要信息加密，就得到了数字签名，服务器把数字证书连同数字签名一起发送给客户端，客户端用公钥解密数字签名，得到摘要信息，客户端用相同的信息摘要算法重新计算证书摘要信息，然后对这两个摘要信息进行比对，如果相同，则说明证书未被篡改，否则证书验证失败
简单说：服务器会对数字证书先进行摘要算法得到摘要，再对摘要使用私钥进行非对称加密，客户端解密得到摘要，最后得到的摘要与数字证书里的摘要对比。
2.3.3摘要算法
1>消息摘要算法分为三类：
MD(Message Digest)：消息摘要
SHA(Secure Hash Algorithm)：安全散列
MAC(Message Authentication Code)：消息认证码
2.3.4握手机制
如图：
SSL / TLS 握手详细过程
1."client hello"消息：客户端通过发送"client hello"消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择，还有一个"client random"随机字符串。
2."server hello"消息：服务器发送"server hello"消息对客户端进行回应，该消息包含了数字证书，服务器选择的密码组合和"server random"随机字符串。
3.验证：客户端对服务器发来的证书进行验证，确保对方的合法身份，验证过程可以细化为以下几个步骤：
1>检查数字签名
2>验证证书链 (这个概念下面会进行说明)
3>检查证书的有效期
4>检查证书的撤回状态 (撤回代表证书已失效)
4.“premaster secret"字符串：客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)”，这个字符串是经过服务器的公钥加密过的，只有对应的私钥才能解密。
5.使用私钥：服务器使用私钥解密"premaster secret"。
6.生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
7.客户端就绪：客户端发送经过共享密钥 KEY加密过的"finished"信号。
8.服务器就绪：服务器发送经过共享密钥 KEY加密过的"finished"信号。
9.达成安全通信：握手完成，双方使用对称加密进行安全通信。