面试系列之-http与https（JAVA基础）
面试系列之-http与https（JAVA基础）
http的请求结构
请求方法
GET：传递参数长度受限制，因为传递的参数是直接表示在地址栏中，而特定的浏览器和服务器对URL的长度是有限制的。因此GET请求不适合用来传递私密数据，也不太适合拿来传递大量数据；
POST：传递的数据封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，对数据量没有限制，也不会显示在URL中；
HEAD：跟GET相似，不过服务端收到HEAD请求时只返回响应头，不发送响应内容。所以，如果只需要查看某个页面的状态时，用HEAD更高效，因为省去了传输页面内容的时间；
DELETE：删除某一资源；
OPTIONS：用于获取当前URL所支持的方法。若请求成功，会在HTTP头中包含一个名为“Allow” 的头，值是所支持的方法，如“GET”、“POST”；
PUT：把一个资源存放在指定位置上。与POST相似，但PUT通常指定了资源的存放位置，而POST则没有；
TRACE：回显服务器收到的请求，主要用于测试或诊断；
CONNECT：是HTTP1.1预留的，能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信；
HTTP协议版本
- HTTP 1.0
支持GET、POST、HEAD三种HTTP请求方法。HTTP1.0 每次请求都需要建立新的TCP连接，连接 不能复用。
- HTTP1.1
该版本默认采用持久连接，并能很好地配合代理服务器工作。还支持以管道方式同时发送多个请求，以降低线路负载，提高传输速度；HTTP1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五种HTTP请求方法；
报文头
请求头部由关键字/值对组成，每行一对：
User-Agent : 产生请求的浏览器类型
Accept : 客户端希望接受的数据类型，比如 Accept：text/xml（application/json）表示希望接受到的是xml（json）类型；
Content-Type：发送端发送的实体数据的数据类型；
Content-Type | 解释 |
|---|---|
text/html | html格式 |
text/plain | 纯文本格式 |
text/css | CSS格式 |
text/javascript | js格式 |
image/gif | gif图片格式 |
image/jpeg | jpg图片格式 |
image/png | png图片格式 |
application/x-www-form-urlencoded | POST专用：普通的表单提交默认是通过这种方式，form表单数据被编码为key/value格式发送到服务器。 |
application/json | POST专用：用来告诉服务端消息主体是序列化后的 JSON 字符串 |
text/xml POST专用 | 发送xml数据 |
multipart/form-data | POST专用：用以支持向服务器发送二进制数据，以便可以在 POST 请求中实现文件上传等功能 |
比如，Content-Type：text/html（application/json）表示发送的是html类型；Host : 请求的主机名，允许多个域名同处一个IP地址，即虚拟主机；
报文体
GET没有请求数据，POST有；
http响应结构
状态码：由3位数字组成，第一个数字定义了响应的类别
- 1xx：这一类型的状态码，代表请求已被接受，需要继续处理，这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束；
- 2xx:这一类型的状态码，代表请求已成功被服务器接收、理解、并接受；
- 3xx:这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明；
- 4xx:这类的状态码代表客户端类的错误；
- 5xx:服务器类的错误；
HTTP状态码分为5种类型：
- 信息，服务器收到请求，需要请求者继续执行操作；
- 成功，操作被成功接收并处理；
- 重定向，需要进一步的操作以完成请求；
- 客户端错误，请求包含语法错误或无法完成请求；
- 服务器错误，服务器在处理请求过程中发生了错误；
区别
- HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输；
- HTTP连接建立相对简单， TCP三次握手之后便可进行HTTP的报文传输，而HTTPS在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输；
- HTTP的端口号是80，HTTPS的端口号是443；
- HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器?的身份是可信的；
- HTTP页面响应速度比HTTPS快，由于HTTPS是建构在SSL/TLS之上的HTTP协议，所以要比HTTP更耗费服务器资源；
三次握手与四次挥手
三次握手
- 第一次握手：客户端向服务器发送报文段1，其中的 SYN 标志位 (表示请求建立新连接)的值为 1，表示这是一个用于请求发起连接的报文段，其中的序号字段 (Sequence Number，图中简写为seq)被设置为初始序号x (Initial Sequence Number，ISN)，TCP 连接双方均可随机选择初始序号。发送完报文段1之后，客户端进入 SYN-SENT 状态，等待服务器的确认。
- 第二次握手：服务器在收到客户端的连接请求后，向客户端发送报文段2作为应答，其中 ACK 标志位设置为1，表示对客户端做出应答，其确认序号字段 (Acknowledgment Number，图中简写为小写 ack) 生效，该字段值为x+1，也就是从客户端收到的报文段的序号加一，代表服务器期望下次收到客户端的数据的序号。此外报文段2的SYN标志位也设置为1，代表这同时也是一个用于发起连接的报文段，序号 seq 设置为服务器初始序号y。发送完报文段2后，服务器进入 SYN-RECEIVED 状态。
- 第三次握手：客户端在收到报文段2后，向服务器发送报文段3，其 ACK 标志位为1，代表对服务器做出应答，确认序号字段 ack 为 y + 1，序号字段 seq 为 x + 1。此报文段发送完毕后，双方都进入 ESTABLISHED 状态，表示连接已建立。
TCP 建立连接为什么要三次握手而不是两次？
- 防止已过期的连接请求报文突然又传送到服务器，因而产生错误在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段，客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到 确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。
- 三次握手才能让双方均确认自己和对方的发送和接收能力都正常，第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。
- 告知对方自己的初始序号值，并确认收到对方的初始序号值TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，也就是图中的 seq 和 ack，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。
TCP 建立连接为什么要三次握手而不是四次？
因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。
四次挥手
- 客户端发送关闭连接的报文段，FIN 标志位1，请求关闭连接，并停止发送数据。序号字段 seq = x (等于之前发送的所有数据的最后一个字节的序号加一)，然后客户端会进入 FIN-WAIT-1 状态，等待来自服务器的确认报文。
- 服务器收到 FIN 报文后，发回确认报文，ACK = 1， ack = x + 1，并带上自己的序号 seq = y，然后服务器就进入 CLOSE-WAIT 状态。服务器还会通知上层的应用程序对方已经释放连接，此时 TCP 处于半关闭状态，也就是说客户端已经没有数据要发送了，但是服务器还可以发送数据，客户端也还能够接收。
- 客户端收到服务器的ACK报文段后随即进入FIN-WAIT-2状态，此时还能收到来自服务器的数据，直到收到FIN报文段。
- 服务器发送完所有数据后，会向客户端发送FIN报文段，各字段值如图所示，随后服务器进入LAST-ACK状态，等待来自客户端的确认报文段。
- 客户端收到来自服务器的FIN报文段后，向服务器发送ACK报文，随后进入TIME-WAIT状态，等待 2MSL(2 * Maximum Segment Lifetime，两倍的报文段最大存活时间) ，这是任何报文段在被丢弃前能在网络中存在的最长时间，常用值有30秒、1分钟和2分钟。如无特殊情况，客户端会进入CLOSED状态。
- 服务器在接收到客户端的ACK报文后会随即进入CLOSED状态，由于没有等待时间，一般而言，服务器比客户端更早进入CLOSED 状态。
为什么TCP关闭连接为什么要四次而不是三次？
服务器在收到客户端的FIN报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回ACK报文段，接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送FIN报文，表示数据已经发送完毕，请求关闭连接，然后客户端再做出应答，因此一共需要四次挥手。
客户端为什么需要在TIME-WAIT状态等待2MSL时间才能进入CLOSED状态？
网络并不总是可靠的，如果客户端发送的ACK报文段丢失，服务器在接收不到ACK的情况下会一直重发FIN报文段，这显然不是我们想要的。因此客户端为了确保服务器收到了ACK，会设置一个定时器，并在TIME-WAIT状态等待2MSL的时间，如果在此期间又收到了来自服务器的FIN报文段，那么客户端会重新设置计时器并再次等待2MSL的时间，如果在这段时间内没有收到来自服务器的FIN报文，那就说明服务器已经成功收到了ACK报文，此时客户端就可以进入CLOSED状态了。
加密算法
对称加密：DES、3DES 和 AES等
- 优点：算法公开、计算量小、加密速度快、加密效率高，适合加密比较大的数据。
- 缺点：
- 交易双方需要使用相同的密钥，也就无法避免密钥的传输，而密钥在传输过程中无法保证不被截获，因此对称加密的安全性得不到保证。
- 每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信双方所拥有的钥匙数量急剧增长，密钥管理成为双方的负担。对称加密算法在分布式网络系统上使用较为困难，主要是因为密钥管理困难，使用成本较高。
非对称加密： RSA算法
客户端在拿到服务器的公钥后，会生成一个随机码 (用 KEY 表示，这个 KEY 就是后续双方用于对称加密的密钥)，然后客户端使用公钥把 KEY 加密后再发送给服务器，服务器使用私钥将其解密，这样双方就有了同一个密钥 KEY，然后双方再使用 KEY 进行对称加密交互数据。在非对称加密传输 KEY 的过程中，即便第三方获取了公钥和加密后的 KEY，在没有私钥的情况下也无法破解 KEY (私钥存在服务器，泄露风险极小)，也就保证了接下来对称加密的数据安全。
HTTPS过程详解
- 客户端请求HTTPS网址，然后连接到server的443端口 (HTTPS默认端口，类似于HTTP的80端口)。
- 采用HTTPS协议的服务器必须要有一套数字CA (Certification Authority)证书，证书是需要申请的，并由专门的数字证书认证机构(CA)通过非常严格的审核之后颁发的电子证书 (当然了是要钱的，安全级别越高价格越贵)，颁发证书的同时会产生一个私钥和公钥。私钥由服务端自己保存不可泄漏。公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
- 服务器响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书有效期等，Chrome浏览器点击地址栏的锁标志再点击证书就可以看到证书详细信息。
- 客户端解析证书并对其进行验证，如果证书不是可信机构颁布，或者证书中的域名与实际域名不一致，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。 如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A，然后客户端还会生成一个随机码KEY，并使用公钥A将其加密。
- 客户端把加密后的随机码KEY发送给服务器，作为后面对称加密的密钥。
- 服务器在收到随机码KEY之后会使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美解决了对称加密的密钥泄露问题，接下来就可以用对称加密愉快地进行通信了。
- 服务器使用密钥 (随机码KEY)对数据进行对称加密并发送给客户端，客户端使用相同的密钥 (随机码 KEY)解密数据。
- 双方使用对称加密愉快地传输所有数据。