应用层：HTTP/HTTPS

我用20张图，彻底征服了HTTPS！

解析HTTPS

分块传输编码：百度百科

403错误：百度百科

503错误：百度百科

腾讯云：一边制造，一边讲解http状态码502|504|499|500

204、205

HTTP结构、方法、状态码

请求报文：请求行、首部行、实体体(entity body)。请求行有3个字段：方法、URL、HTTP版本。
响应报文：状态行、首部行、实体体。状态行有3个字段：版本、状态码、响应状态信息。

常见的首部字段：

HTTP方法

1. GET 用于请求服务器发送某个资源。
2. HEAD 服务器只在响应中返回首部，不会返回实体的猪蹄部分。服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。
   这就允许客户端在未获取实际资源的情况下可以：（1）了解资源情况，如类型。（2）通过响应中的状态码，看某个对象是否存在。（3）通过查看首部，测试资源是否被修改了。
3. PUT 创建一个由URL命名的新文档，如果URL已存在，就用这个主体代替。
4. POST 向服务端发送数据
5. TRACE 查看HTTP请求是否被修改和破坏（原理：行程最后一战的服务器会弹回一条TRACE响应，并在响应猪蹄中携带它收到的原始请求报文）
   
6. OPTIONS 请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作)。
   
7. DELETE 请服务器删除URL所指定的资源。但是客户端应用程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。

HTTP状态码

1. 100~199 信息性状态码（？看不懂）
   101 Switching Protocols：当客户端请求头有Upgrade时，假如服务端能更换协议成功，返回101和实体（101和实体算一个响应报文，返回响应报文遵循新的协议）

2. 200~299 成功状态码
   200 OK：请求没问题，实体的主体部分包含了 所请求的资源。
   201 Created：用于创建服务对象的请求（如PUT），响应的主体部分包含各种引用了已创建资源的URL，Location首部包含最具体的引用。
   204 No Content：服务器执行成功，但没有主体部分，浏览器什么也不用做，不用刷新页面 也不用导向新页面。我们使用Ajax时，大多都是询问操作，只提交数据，Ajax只期待服务器返回：
   {status: 0, message:""} //status 0代表成功, 非零的时候, message中包含出错信息.

3. 300~399 重定向状态码
   300 Multiple Choices：多个资源都对应这个URL，如HTML文档的英语和法语版本。返回这个状态码时带有一个选项列表。
   301 Moved Permanently 资源被移除，响应的Location首部中应该包含资源现在所处的URL。
   302 Found 与301类似，不同就是以后的请求还用老的URL。
   304 Not Modified GET带有
   
   这个字段，如果资源在这个时间戳后没有修改 就返回304. 下面是响应头某首部行：
   

4. 400~499 客户端错误状态码
   404 Not Found
   401 Unauthorized 未经授权
   403 Forbidden 请求被服务器拒绝了。有各种原因。（比如403.9 连接的用户过多导致Web服务器很忙 403.11 密码更改导致无权查看页面 403.6 IP地址被拒绝 403.4要求客户端必须使用https等）
   408 Request Timeout 客户端完成请求所花时间过长。服务端可回送次状态码并关闭连接。

5. 500~599 服务器错误状态码
   502 Bad Gateway：并不是指网关本身出了问题，而是从上游接收响应出了问题，比如由于上游服务自身超时导致不能产生响应数据，或者上游不按照协议约定来返回数据导致网关不能正常解析。
   503 Service unavailable：服务器现在无法提供服务但之后可以。原因有：请求应用程序队列已满、CPU占用率太高自动关闭应用程序池、管理员手动关闭应用程序池等。（该站点可能正在被攻击
   504 Gateway Timeout：它表示网关没有从上游及时获取响应数据。与408类似，但这里的响应来自网关和代理。
   505 HTTP Version Not supported：服务器不支持请求报文使用的HTTP协议版本。

一些问题

1. 重定向与转发的区别
   转发:发生在服务器内部的跳转，所以，对于客户端来说，至始至终就是一次请求，所以这期间，保存在request对象中的数据可以传递。
   重定向:发生在客户端的跳转，所以，是多次请求，这个时候，如果需要在多次请求之间传递数据，就需要用session对象。(客户浏览器收到301or302后，客户端重新发一个http请求，是新的url)
   面试官的问题:在后台程序，想跳转到百度，应该用转发还是重定向? 答案:重定向，因为转发的范围限制在服务器内部。

---

HTTP版本

HTTP1.1

默认开启持久连接、引入HTTP管道、分块传输编码、增强的缓存机制。但HTTP首部以纯文本形式发送(没有首部压缩)

HTTP管道

HTTP管道概念：client不需要等待前一个请求响应到达后才能发出第二个请求，可以同时发出多个请求，但接受响应的顺序应该严格的按着发出的顺序。

队首阻塞：服务器处理完成了一个请求但这个响应却不能发出去，还要等顺序比他早的处理完。造成服务器缓冲开销，不充分利用网络。

HTTP管道的缺点：

1. 一个慢响应就会阻塞所有后续请求﹔
2. 并行处理请求时，服务器必须缓冲管道中的响应，从而占用服务器资源，如果有个响应非常大，则很容易形成服务器的受攻击面;
3. 响应失败可能终止TCP连接，从页强迫客户端重新发送对所有后续资源的请求，导致重复处理;
4. 由于可能存在中间代理，因此检测管道兼容性，确保可靠性很重要;
5. 如果中间代理不支持管道，那它可能会中断连接，也可能会把所有请求串联起来。

实践中部署HTTP管道的最佳途径，就是在客户端和服务器间使用安全通道(HTTPS)。这样就能可靠地避免那些不理解或不支持管道的中间代理的干扰。（那中间代理还有什么用？可以翻墙丫

分块传输编码

优点：之前服务器在开始发送消息体之前要发生Content-Length消息头字段，但是对于动态生成的内容，这个长度要等在内容创建完之前才能知道。分块传输编码允许最后发送消息头，动态生成一个块就可以发出去。这样服务端向传输层写入就是流式传输而不是缓冲完成后传输。加快了服务端向传输层交付的速度。

HTTP1.1部分优化

1. 连接与拼合
   连接：把多个JavaScript或CSS文件组合为一个文件。
   拼合：把多张图片组合为一个更大的复合的图片。
   也有很多坏处：
   （1）资源包中可能含有当前页面不需要的内容
   （2）对资源包中任何文件的更新，都要求重新下载整个资源包
   （3）整个资源包传输完成后才能被解析和指向，因而会拖慢应用的执行速度。

HTTP 2.0

支持首部压缩、二进制分帧server不须串行响应、支持server到client主动推送。

怎么升级至HTTP2.0?

还有，如果客户端因为自己保存有或通过其他手段（如DNS记录、手工配置等）获得了关于HTTP 2.0的支持信息，它也可以直接发送HTTP 2.0分帧，而不必依赖Upgrade机制。

二进制分帧

可以并行交错地发送响应，响应之间互不干扰。把HTTP每个流也可以带个优先级。

服务器推送

为什么需要这样一个机制呢?通常的 Web应用都由几十个资源组成，客户端需要分析服务器提供的文档才能逐个找到它们。 那为什么不让服务器提前就把这些资源推送给客户端，从而减少额外的时间延迟呢?服务器已经知道客户端下一步要请求什么资源了，这时候服务器推送即可派上用场。
客户端可以缓存、拒绝推送过来的资源。服务器可以按照优先级推送资源。

首部压缩

HTTP 2.0在客户端和服务器端使用 “首部表” 来跟踪和存储之前发送的键-值对，对于相同的数据，不再通过每次请求和响应发送﹔首部表在HTTP 2.0的连接存续期内始终存在,由客户端和服务器共同渐进地更新;。每个新的首部键―值对要么被追加到当前表的末尾，要么替换表中之前的值。于是，HTTP 2.0连接的两端都知道已经发送了哪些首部，这些首部的值是什么，从而可以针对之前的数据只编码发送差异数据。

好像还可以这样：比如method:GET就是1，method:PUT就是2 这样。

HTTP2.0撤销HTTP1.1的部分优化

1. 并不需要像HTTP1.x一样开启多个TCP连接优化，开启多个TCP链接会使网络更拥塞、受到TCP慢启动地影响。
2. 也要杜绝文件拼接、图片精灵等不良习惯，因为在HTTP2.0完全没有必要。

---

HTTP优化

减少DNS查找、减少HTTP重定向、去掉不必要的资源、在客户端缓存资源、传输压缩后的内容、消除不必要的请求开销。

---

HTTPS

HTTP存在的风险(主要有3个)

1. 窃听风险：比如我告诉我男朋友我密码是******，然后被窃听了，完蛋。
2. 篡改风险
   
3. 冒充风险

由此可以看出安全通信需要保证机密性(不被窃听)、完整性(不被篡改)、身份认证(不被冒充)。

---

对称加密/非对称加密

对称加密：

如上图所示：使用对称加密的通信双方使用同意把密钥进行加解密。
问题来了：这个密钥怎么协商呢？假如密钥是明文，那不是在裸奔。

对称加密解决不了如何协商对称加密中密钥的问题，只能另求他法。

---

非对称加密：加解密双方使用不同的密钥，一把作为公钥，可以公开的，一把作为私钥，不能公开，公钥加密的密文只有私钥可以解密，私钥加密的内容，也只有公钥可以解密。这样的话对于 server 来说，保管好私钥，发布公钥给其他 client，其他 client 只要把对称加密的密钥加密传给 server 即可。
问题来了：server怎么把公钥安全地传输给client呢？如何保证不被篡改呢？
介个就要用了数字证书了。

---

数字证书

server向CA申请证书，在证书中附上公钥，然后将证书传给client，证书由站点管理者向CA申请，申请的时候会提交 DNS 主机名等信息，CA 会根据这些信息生成证书。server将证书交给client，client从证书中得到公钥。
所以通过证书的办法来获得公钥要保证：证书不会被篡改。这里要提一下，证书肯定是会被窃听的，所以第三方能得到公钥，但是只得到公钥是没用的。

如何保证证书不被篡改：（也就是clien能识别这是server的证书且没被修改）

消息摘要 是把任意长度的输入揉和而产生长度固定的伪随机输入的算法，无论输入的消息有多长，计算出来的消息摘要的长度总是固定的。签名 就是前几项生成的摘要通过server的私钥加密得到的。
客户端如何知道这是不是没被篡改的证书？
先看clinet的验签过程：

图上的第三方机构公钥是内置在操作系统上的，无需传输。

1. 假如公钥被修改，客户端通过第三方机构公钥解密后得到摘要，对证书明文计算得到摘要，将这两个摘要对比就知道是不是被篡改。
2. 假如坏蛋也向第三方权威机构申请了证书，这样证书就是包含了第三方公钥。这样有可能吗？
   
   答案是不行的，因为证书上带有主机名，坏蛋申请的证书上的主机名不是server，会被client发现。

---

到这里看起来完美了，那我问几个小问题把！

• 为什么要先生成摘要在加密呢？不能直接加密？
  把内容很长的明文压缩成小得多的定长字符串，客户端验签会快很多。说白了字越多加密解密越耗时。

---

HTTPS通信过程

1. 客户端通过发送ClientHello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表(所使用的加密算法及密钥长度等)。（ClientHello也可能会包含ProtocalNameList：自己支持的应用层协议，这样可以不需要HTTP的Upgrade机制，省去一次往返延迟。）
2. 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。（ServerHello可能包含ProtocolName表示选中的协议）
3. 之后服务器发送Certificate报文。报文中包含密钥证书。
4. 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
5. SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含Pre-master secret的随机密码串。该报文用步骤3的公钥进行加密。
6. 客户端继续发送Change Cipher Spec报文。该报文提示服务器，在此报文之后的通信会用Pre-master secret密钥加密。客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
7. 服务器同样发送 Change Cipher Spec报文和Finished报文。

---

好了，看到这里是不是觉得疑问很多呢！哭了哭了。

1. 为什么客户端和服务端都要发送Finished报文？
   Finished报文是对至今全部报文的整体校验值然后用公钥加密。Finished报文是用来校验双方身份的。
   客户端发送Finished报文：假如server收到了一个坏蛋发送的Client Key Exchange，不是该当前的client的Client Key Exchange报文，这样的话server可能跟这个坏蛋握手协商成功。（虽然协商成功了，坏蛋交了自己的用公钥加密后的pre-master secret就和sever统一了对称加密的密钥，坏蛋看得懂server的，但是看不懂client的，因为不知道client的pre-master secret(被公钥了，只有私钥才可解密)。相当于坏蛋与server直接交流也窃取不到消息没啥用，但是server肯定为这个坏蛋分配资源了)
   服务端发送Finished报文：
   服务端发送Finished报文后，客户端才可以发送要通信的数据。因为就像上面说的那样，Client Key Exchange被掉包后，这个时候客户端肯定不能发送数据，因为服务端没有得到真正的pre-master secret，所以这算一个客户端可以开始传输数据的信号。肯定这个信号发送过来，我们客户端要看看他是不是服务端发的鸭。通过Finished报文校验一下就好啦。
2. 说下https里面对称加密的过程
   客户端：生成一个Pre-master secret，结合原来的A、B的随机数，用DH算法计算一个master secret，根据这个master secret得到hash secret和session secret。
   服务端：通过私钥解密获得了Pre-master secret之后，结合原来的A、B的随机数，用DH算法计算master secret，根据这个master secret得到hash secret和session secret。
   MAC(Message Authentication Code)称为报文摘要，能够查知报文是否遭到篡改，从而保护报文的完整性。
   1 ）发送发用hash secret对HTTP报文做一次运算生成一个MAC，附在HTTP报文后面。然后用session-secret加密所有数据(HTTP+MAC)，
   2）接收方则先用session-secret解密数据，然后得到HTTP+MAC，再用相同的算法计算出自己的MAC，如果两个MAC相等，证明数据没有被篡改。
3. 为什么要用三个随机数
   SSL协议不信任每个主机都能产生完全随机的随机数，所以只用pre-master secret是不靠谱的。
4. 假如ClientHello或者ServerHello被掉包，选择了一个安全性较低的加密组件怎么办
   Pre-master secret前两个字节是TSL版本号，服务端用私钥机密后得到版本号与之前的Client Hello阶段的版本号如果变低说明被篡改，立刻停止发送任何消息。
5. HTTPS为什么可以被charles抓包
   客户端安装charles证书即可。

什么是 SSL TSL？

SSL 百度百科 我看不懂
SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密。

TLS会话恢复

1. 会话标识符
   服务器为每个客户端保存一个会话ID和协商后的会话参数。相应的，客户端也可以保存会话ID信息，并将该ID包含在后续会话的ClientHello消息中，从而告诉服务器自己还记着上次握手协商后的加密套件和密钥呢，这些都可以重用。 假设客户端和服务器都可以在自己的缓存中找到共享的会话ID参数，那么就可以进行简短握手。否则就要重新启动一次全新的会话协商，生成新的会话ID。
   
   优点：（1）节省一次往返。（2）省掉 用于协商共享加密密钥 的公钥加密私钥解密计算。
   缺点：显然每个打开的TLS连接都要占用内存，因此需要一套会话ID缓存和清楚策略。

2. 会话记录单
   该机制不用服务器保存每个客户端的会话状态。如果客户端表明其支持会话记录单，则服务器可以在完整TLS握手的最后一次交换中添加一条“新会话记录单”记录，包含只有服务器知道的安全密钥加密过的所有会话的数据。 然后，客户端将这个会话记录单保存起来，在后续会话 ClientHello消息中，可以将其包含在SessionTicket扩展中。这样所有会话数据只保存在客户端，而由于数据被加密过，且密钥只有服务器知道，因此仍然是安全的。