HTTPS工作原理

 HTTPS 工作原理

1 、 首先 HTTP 请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证

书的公钥（ RSA 加密）等进行校验；

2 、 客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（ RSA

加密）；

3 、 消息体产生的后，对它的摘要进行 MD5 （或者 SHA1 ）算法加密，此时就得到了 RSA 签名；

4 、 发送给服务端，此时只有服务端（ RSA 私钥）能解密。

5 、 解密得到的随机数，再用 AES 加密，作为密钥（此时的密钥只有客户端和服务端知道）。

  三次握手与四次挥手

(1). 三次握手（我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功）

第一次握手： Client 将标志位 SYN 置为 1 ，随机产生一个值 seq=J ，并将该数据包发送给 Server ，

Client 进入 SYN_SENT 状态，等待 Server 确认。

第二次握手： Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接， Server 将标志位 SYN

和 ACK 都置为 1 ， ack=J+1 ，随机产生一个值 seq=K ，并将该数据包发送给 Client 以确认连接请求，

Server 进入 SYN_RCVD 状态。

第三次握手： Client 收到确认后，检查 ack 是否为 J+1 ， ACK 是否为 1 ，如果正确则将标志位 ACK 置为

1 ， ack=K+1 ，并将该数据包发送给 Server ， Server 检查 ack 是否为 K+1 ， ACK 是否为 1 ，如果正确则

连接建立成功， Client 和 Server 进入 ESTABLISHED 状态，完成三次握手，随后 Client 与 Server 之间

可以开始传输数据了。

(2). 四次挥手（我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧）：

微信搜索公众号： Java 专栏，获取最新面试手册 第一次挥手： Client 发送一个 FIN ， 用来关闭 Client 到 Server 的数据传送 ， Client 进入 FIN_WAIT_1

状态。

第二次挥手： Server 收到 FIN 后，发送一个 ACK 给 Client ，确认序号为收到序号 +1 （与 SYN 相同，一

个 FIN 占用一个序号）， Server 进入 CLOSE_WAIT 状态。此时 TCP 链接处于半关闭状态，即客户端已

经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。

第三次挥手： Server 发送一个 FIN ， 用来关闭 Server 到 Client 的数据传送 ， Server 进入 LAST_ACK 状

态。

第四次挥手： Client 收到 FIN 后， Client 进入 TIME_WAIT 状态，接着发送一个 ACK 给 Server ，确认序

号为收到序号 +1 ， Server 进入 CLOSED 状态，完成四次挥手。

  为什么 TCP 链接需要三次握手，两次不可以么？

“ 三次握手 ” 的目的是为了防止 已失效的链接请求报文突然又传送到了服务端 ，因而产生错误。

正常的情况： A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请

求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。 A 共发送了两个连接请求报

文段，其中第一个丢失，第二个到达了 B 。没有 “ 已失效的连接请求报文段 ” 。

现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点

长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B 。本来这是一个早已失效的报文

段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就

向 A 发出确认报文段，同意建立连接。

假设不采用 “ 三次握手 ” ，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的

请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立，并一直等待

A 发来数据。这样， B 的很多资源就白白浪费掉了。采用 “ 三次握手 ” 的办法可以防止上述现象发生。

  用现实理解三次握手的具体细节

三次握手的目的是建立可靠的通信信道，主要的目的就是双方确认自己与对方的发送与接收机能正常。

1 、 第一次握手：客户什么都不能确认；服务器确认了对方发送正常

2 、 第二次握手：客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认 了：自己接收

正常，对方发送正常

3 、 第三次握手：客户确认了：自己发送、接收正常，对方发送、接收正常；服务器确认 了：自己发

送、接收正常，对方发送接收正常 所以三次握手就能确认双发收发功能都正常，缺一不可。

  建立连接可以两次握手吗？为什么 ?

不可以。

因为可能会出现已失效的连接请求报文段又传到了服务器端。 > client 发出的第一个连接请求报文段并

没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server 。

本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发

出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “ 三次握手 ” ，那

么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理

睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待

client 发来数据。这样， server 的很多资源就白白浪费掉了。采用 “ 三次握手 ” 的办法可以防止上述现象

发生。例如刚才那种情况， client 不会向 server 的确认发出确认。 server 由于收不到确认，就知道

client 并没有要求建立连接。

两次握手无法保证 Client 正确接收第二次握手的报文（ Server 无法确认 Client 是否收到），也无法

保证 Client 和 Server 之间成功互换初始序列号。

为什么要四次挥手？

TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。 TCP 是全双工模式，这就意味

着，当 A 向 B 发出 FIN 报文段时，只是表示 A 已经没有数据要发送了，而此时 A 还是能够接受到来自 B

发出的数据； B 向 A 发出 ACK 报文段也只是告诉 A ，它自己知道 A 没有数据要发了，但 B 还是能够向

A 发送数据。

所以想要愉快的结束这次对话就需要四次挥手。

TCP 协议如何来保证传输的可靠性

TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用（通常是一

个客户和一个服务器）在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进

行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流， TCP 不在

字节流中插入记录标识符。

对于可靠性， TCP 通过以下方式进行保证：

数据包校验 ：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给

出响应，这时 TCP 发送数据端超时后会重发数据；

对失序数据包重排序 ：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此

TCP 报文段的到达也可能会失序。 TCP 将对失序数据进行重新排序，然后才交给应用层；

丢弃重复数据 ：对于重复数据，能够丢弃重复数据；

应答机制 ：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，

通常将推迟几分之一秒；

超时重发 ：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能

及时收到一个确认，将重发这个报文段；

流量控制 ： TCP 连接的每一方都有固定大小的缓冲空间。 TCP 的接收端只允许另一端发送接收端缓

冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。 TCP 使

用的流量控制协议是可变大小的滑动窗口协议。

  客户端不断进行请求链接会怎样？ DDos(Distributed Denial of

Service) 攻击？

服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认

(1). DDos 攻击：

客户端向服务端发送请求链接数据包

服务端向客户端发送确认数据包

客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

(2). DDos 预防：（没有彻底根治的办法，除非不使用 TCP ）

限制同时打开 SYN 半链接的数目

缩短 SYN 半链接的 Time out 时间

关闭不必要的服务

GET 与 POST 的区别？

GET 与 POST 是我们常用的两种 HTTP Method ，二者之间的区别主要包括如下五个方面：

1 、 从功能上讲， GET 一般用来从服务器上获取资源， POST 一般用来更新服务器上的资源；

2 、 从 REST 服务角度上说， GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等

的，因为每次请求对资源的改变并不是相同的；进一步地， GET 不会改变服务器上的资源，而 POST 会对

服务器资源进行改变；

3 、 从请求参数形式上看， GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的 请求头

中，以 ? 分割 URL 和传输数据，参数之间以 & 相连。特别地，如果数据是英文字母 / 数字，原样发送；否

则，会将其编码为 application/x-www-form-urlencoded MIME 字符串 ( 如果是空格，转换为 + ，如果是

中文 / 其他字符，则直接把字符串用 BASE64 加密，得出如： %E4%BD%A0%E5%A5%BD ，其中％ XX 中的

XX 为该符号以 16 进制表示的 ASCII) ；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体

中。

4 、 就安全性而言， POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，

而且 POST 请求参数则被包装到请求体中，相对更安全。

5 、 从请求的大小看， GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较

小，而 POST 请求则是没有大小限制的。