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
请求则是没有大小限制的。
