企业官网建设流程全解析

1.HTTP

1.1.HTTP 常见的状态码有哪些？

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

• 2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。
• 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

• 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
• 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

• 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
• 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
• 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
• 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

1.2.HTTP 常见字段有哪些？

Host 字段

客户端发送请求时，用来指定服务器的域名。

Host: www.A.com

Content-Length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。

Content-Length: 1000

HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题。

Connection 字段

Connection 字段最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用。

HTTP/1.1 版本的默认连接都是长连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。

Connection: Keep-Alive

Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Type: text/html; Charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。

Accept: */*

Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

Content-Encoding: gzip

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

1.3.GET 与 POST

根据 RFC 规范，GET 的语义是从服务器获取指定的资源。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII。

根据 RFC 规范，POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，POST 请求携带数据的位置一般是写在报文 body 中。

1.4.GET 和 POST 方法都是安全和幂等的吗？

先说明下安全和幂等的概念：

• 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。
POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

• 可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。
• 可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

GET 请求可以带 body 吗？

RFC 规范并没有规定 GET 请求不能带 body 的。另外，URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。

1.5.HTTP 缓存技术

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

1.5.1.什么是强制缓存？

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，们都用来表示资源在客户端缓存的有效期：

• Cache-Control， 是一个相对时间；
• Expires，是一个绝对时间；

如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires 。

Cache-control 选项更多一些，设置更加精细，所以建议使用 Cache-Control 来实现强缓存。具体的实现流程如下：

• 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
• 浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
• 服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

1.5.2.什么是协商缓存？

协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

协商缓存可以基于两种头部来实现。

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，这两个字段的意思是：

• 响应头部中的 Last-Modified：标示这个响应资源的最后修改时间；
• 请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段，这两个字段的意思是：

• 响应头部中 Etag：唯一标识响应资源；
• 请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头 If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的，相对来说后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。

注意，协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

2.HTTP 特性

2.1.HTTP/1.1 的优点有哪些？

• 简单
  HTTP 基本的报文格式就是header + body，头部信息也是key-value简单文本的形式，易于理解，降低了学习和使用的门槛。

• 灵活和易于扩展
  HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
  同时HTTP由于是工作在应用层（OSI第七层），则它下层可以随意变化，比如：

  • HTTPS就是在HTTP与TCP层之间增加了SSL/TLS安全传输层；
  • HTTP/1.1和HTTP/2.0传输协议使用的是TCP协议，而到了HTTP/3.0传输协议改用了UDP协议。

• 应用广泛和跨平台

2.2.HTTP/1.1 的缺点有哪些？

HTTP协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

• 无状态双刃剑

对于无状态的问题，解法方案有很多种，其中比较简单的方式用Cookie技术。

Cookie通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。

• 明文传输双刃剑
• 不安全
  • 明文通讯：通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
  • 无身份认证：不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
  • 无完整性检测：无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。

HTTP的安全问题，可以用HTTPS的方式解决，也就是通过引入SSL/TLS层，使得在安全上达到了极致。

2.3.HTTP/1.1 的性能如何？

• 长连接
• 队头阻塞
  因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」，好比上班的路上塞车。

3.HTTPS

3.1.HTTP 与 HTTPS 有哪些区别？

• HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
• HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输。
• 两者的默认端口不一样，HTTP默认端口号是80，HTTPS默认端口号是443。
• HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

3.2.HTTPS 解决了 HTTP 的哪些问题？

HTTP由于是明文传输，所以安全上存在以下三个风险：

• 缺乏加密导致窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
• 缺乏认证导致冒充风险，比如冒充淘宝网站，用户钱容易没。
• 缺乏完整性检测导致篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。

HTTPS在HTTP与TCP层之间加入了SSL/TLS协议，可以很好的解决了上述的风险：

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。

可见，只要自身不做「恶」，SSL/TLS协议是能保证通信是安全的。

HTTPS 是如何解决上面的三个风险的？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。非对称加密解决密钥传输，对称加密解决信息传输。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。

3.2.1.混合加密

通过混合加密的方式可以保证信息的机密性，解决了窃听的风险。

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。
• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。

3.2.2.摘要算法 + 数字签名

为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方。

对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。

那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。

通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：

• 一个是公钥，这个是可以公开给所有人的；
• 一个是私钥，这个必须由本人管理，不可泄露。

这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。

流程的不同，意味着目的也不相同：

• 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
• 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

所以非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。

私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

3.2.3.数字证书

前面我们知道：

• 可以通过哈希算法来保证消息的完整性；
• 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；

但是这还远远不够，还缺少身份验证的环节，万一公钥是被伪造的呢？

引入权威机构来管理公钥分发，在计算机里，这个权威的机构就是CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

数字证书的工作流程，我也画了一张图，方便大家理解：

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

3.3.HTTPS 是如何建立连接的？其间交互了什么？

SSL/TLS协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

TLS的「握手阶段」涉及四次通信，使用不同的密钥交换算法，TLS握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA算法 和ECDHE算法。

基于RSA算法的TLS握手过程比较容易理解，所以这里先用这个给大家展示TLS握手过程，如下图：

TLS协议建立的详细流程：

• ClientHello

首先，由客户端向服务器发起加密通信请求，也就是ClientHello请求。

在这一步，客户端主要向服务器发送以下信息：

1.客户端支持的TLS协议版本，如TLS 1.2版本。

2.客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。

3.客户端支持的密码套件列表，如RSA加密算法。

• SeverHello

服务器收到客户端请求后，向客户端发出响应，也就是SeverHello。服务器回应的内容有如下内容：

1.确认TLS协议版本，如果浏览器不支持，则关闭加密通信。

2.服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。

3.确认的密码套件列表，如RSA加密算法。

4.服务器的数字证书。

• 客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字证书的真实性。

如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

1.一个随机数（pre-master key）。该随机数会被服务器公钥加密。

2.加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

3.客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

• 服务器的最后回应

服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。

然后，向客户端发送最后的信息：

1.加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

2.服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

至此，整个TLS的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用「会话秘钥」加密内容。

不过，基于RSA算法的HTTPS存在「前向安全」的问题：如果服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

客户端校验数字证书的流程是怎样的？

接下来，详细说一下实际中数字证书签发和验证流程。

如下图图所示，为数字证书签发和验证流程：

CA 签发证书的过程，如上图左边部分：

• 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
• 然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；
• 最后将 Certificate Signature 添加在文件证书上，形成数字证书；

客户端校验服务端的数字证书的过程，如上图右边部分：

• 首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
• 最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

证书可信时，即可从证书中取得经过CA认证的公钥。

3.4.证书信任链

对于这种三级层级关系的证书的验证过程如下：

• 客户端收到baidu.com的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证baidu.com证书是否可信。于是，客户端根据baidu.com证书中的签发者，找到该证书的颁发机构是“GlobalSign Organization Validation CA - SHA256 - G2”，然后向CA请求该中间证书。
• 求到证书后发现“GlobalSign Organization Validation CA - SHA256 - G2”证书是由“GlobalSign Root CA”签发的，由于“GlobalSign Root CA”没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证“GlobalSign Organization Validation CA - SHA256 - G2”证书，如果发现验证通过，就认为该中间证书是可信的。
• “GlobalSign Organization Validation CA - SHA256 - G2”证书被信任后，可以使用“GlobalSign Organization Validation CA - SHA256 - G2”证书中的公钥去验证baidu.com证书的可信性，如果验证通过，就可以信任baidu.com证书。

在这四个步骤中，最开始客户端只信任根证书GlobalSign Root CA证书的，然后“GlobalSign Root CA”证书信任“GlobalSign Organization Validation CA - SHA256 - G2”证书，而“GlobalSign Organization Validation CA - SHA256 - G2”证书又信任baidu.com证书，于是客户端也信任baidu.com证书。

总括来说，由于用户信任GlobalSign，所以由GlobalSign所担保的baidu.com可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的GlobalSign都可被信任。

3.5.HTTPS 的应用数据是如何保证完整性的？

TLS 在实现上分为握手协议和记录协议两层：

• TLS 握手协议就是我们前面说的 TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据（即 HTTP 数据）；
• TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议；

TLS 记录协议主要负责消息（HTTP 数据）的压缩，加密及数据的认证，过程如下图：

具体过程如下：

• 首先，消息被分割成多个较短的片段,然后分别对每个片段进行压缩。
• 接下来，经过压缩的片段会被加上消息认证码（MAC 值，这个是通过哈希算法生成的），这是为了保证完整性，并进行数据的认证。通过附加消息认证码的 MAC 值，可以识别出篡改。与此同时，为了防止重放攻击，在计算消息认证码时，还加上了片段的编码。
• 再接下来，经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。
• 最后，上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据。

记录协议完成后，最终的报文数据将传递到传输控制协议 (TCP) 层进行传输。