七、java-计算机网络-7
1.32 https支持什么加密算法？
参考回答
常见的对称加密算法有：DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES ；
常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）；
常见的Hash算法有：MD2、MD4、MD5、HAVAL、SHA；
答案解析
对称加密技术
对称加密采用了对称密码编码技术，它的特点是文件加密和解密使用相同的密钥加密。也就是密钥也可以用作解密密钥，这种方法在密码学中叫做对称加密算法，对称加密算法使用起来简单快捷，密钥较短，且破译困难，除了数据加密标准（DES），另一个对称密钥加密系统是国际数据加密算法（IDEA），它比DES的加密性好，而且对计算机功能要求也没有那么高。对称加密算法在电子商务交易过程中存在几个问题：
（1）要求提供一条安全的渠道使通讯双方在首次通讯时协商一个共同的密钥。直接的面对面协商可能是不现实而且难于实施的，所以双方可能需要借助于邮件和电话等其它相对不够安全的手段来进行协商；
（2）密钥的数目难于管理。因为对于每一个合作者都需要使用不同的密钥，很难适应开放社会中大量的信息交流；
（3）对称加密算法一般不能提供信息完整性的鉴别。它无法验证发送者和接受者的身份；
（4）对称密钥的管理和分发工作是一件具有潜在危险的和烦琐的过程。对称加密是基于共同保守秘密来实现的，采用对称加密技术的贸易双方必须保证采用的是相同的密钥，保证彼此密钥的交换是安全可靠的，同时还要设定防止密钥泄密和更改密钥的程序。
假设两个用户需要使用对称加密方法加密然后交换数据，则用户最少需要2个密钥并交换使用，如果企业内用户有n个，则整个企业共需要n×(n-1) 个密钥，密钥的生成和分发将成为企业信息部门的恶梦。
常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES
非对称加密技术
与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。
公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将其中的一把作为公用密钥向其它方公开；得到该公用密钥的乙方使用该密钥对机密信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用密钥对加密后的信息进行解密。甲方只能用其专用密钥解密由其公用密钥加密后的任何信息。
非对称加密的典型应用是数字签名。
常见的非对称加密算法有：RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）
Hash算法（摘要算法）
Hash算法
Hash算法特别的地方在于它是一种单向算法，用户可以通过hash算法对目标信息生成一段特定长度的唯一hash值，却不能通过这个hash值重新获得目标信息。因此Hash算法常用在不可还原的密码存储、信息完整性校验等。
常见的Hash算法有MD2、MD4、MD5、HAVAL、SHA
1.33 说一说HTTPS的秘钥交换过程。
参考回答
HTTPS的密钥交换过程如下：
客户端要访问一个网站，向支持https的服务器发起请求。
客户端向服务器发送自己支持的秘钥交换算法列表。
服务器选取一种秘钥交换算法加上CA证书返回给客户端。
客户端验证服务器是否合法，并生成一个随机数然后用协商好的加密算法加密生成随机秘钥，并用刚才从CA证书中拿到的公钥对其加密后发送给服务器。
服务器收到后用自己的私钥解密（中间人没有服务器的私钥，所以没有办法看到传输的数据，另外确认秘钥交换算法是在第一步，中间人是不知道秘钥交换算法（中间人是无法在第一步做手脚的，那等同于它自己就是一个真实客户端发起了一个新的请求，唯一一种情况攻击人有一个合法CA下发的证书，且客户端（一般为安卓设备）没有对CA下发的证书中的内容网站地址和当前请求地址做对比校验），就算攻击者有公钥，因为不知道协商协议，所以做不出来随机秘钥，顶多就是在传输过程中将报文拦截下来，乱改，但是给到服务器后，私钥是解不开乱改之后的密文的）。
服务器私钥解密之后，拿到对称秘钥，并且用它再加密一个信息，返回给浏览器。
注意：最关键的一步就是在客户端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master，这个随机秘钥是用来计算最终的对称秘钥的，用公钥加密之后攻击人是不知道这个这个随机秘钥的，只有服务器才能解的开。
1.34 说一说HTTPS的证书认证过程。
参考回答
HTTPS的证书认证过程如下：
浏览器将自己支持的一套加密规则发送给网站。
网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。
浏览器获得网站证书之后浏览器要做以下工作：
（1） 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。
（2）如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。
（3）使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。网站接收浏览器发来的数据之后要做以下的操作：
（1） 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。
（2） 使用密码加密一段握手消息，发送给浏览器。浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
1.35 HTTP请求头中包含什么内容？
参考回答
HTTP请求头中包含如下三个内容：
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：主机地址。
答案解析
请求报文(请求行/请求头/请求数据/空行)
（1） 请求行
求方法字段、URL字段和HTTP协议版本
例如：GET /index.html HTTP/1.1
get方法将数据拼接在url后面，传递参数受限
请求方法：
GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT
（2） 请求头(key value形式)
User-Agent：产生请求的浏览器类型。
Accept：客户端可识别的内容类型列表。
Host：主机地址
（3） 请求数据
post方法中，会把数据以key value形式发送请求
（4） 空行
发送回车符和换行符，通知服务器以下不再有请求头
响应报文(状态行、消息报头、响应正文)
状态行
消息报头
响应正文
1.36 HTTP是基于TCP还是UDP？
参考回答
HTTP是基于TCP的。
HTTP协议是建立在请求/响应模型上的。首先由客户建立一条与服务器的TCP链接，并发送一个请求到服务器，请求中包含请求方法、URI、协议版本以及 相关的MIME样式的消息。服务器响应一个状态行，包含消息的协议版本、一个成功和失败码以及相关的MIME式样的消息。
HTTP/1.0为每一次HTTP的请求/响应建立一条新的TCP链接，因此一个包含HTML内容和图片的页面将需要建立多次的短期的TCP链接。一次TCP链接的建立将需要3次握手。
另 外，为了获得适当的传输速度，则需要TCP花费额外的回路链接时间（RTT）。每一次链接的建立需要这种经常性的开销，而其并不带有实际有用的数据，只是 保证链接的可靠性，因此HTTP/1.1提出了可持续链接的实现方法。HTTP/1.1将只建立一次TCP的链接而重复地使用它传输一系列的请求/响应消 息，因此减少了链接建立的次数和经常性的链接开销。
答案解析
无
1.37 HTTP1.1和HTTP2.0有什么区别？
参考回答
HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。随着Web功能越来越复杂，每个页面产生的请求数也越来越多，导致消耗在头部的流量越来越多，尤其是每次都要传输UserAgent、Cookie这类不会频繁变动的内容，完全是一种浪费。 HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。
为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
答案解析
无
1.38 HTTP2.0和HTTP3.0有什么区别？
参考回答
HTTP2.0和HTTP3.0的区别在于前者使用tcp协议而后者使用udp协议。
答案解析
http发展历程：从http0.9 到 http3.0
HTTP0.9
最简单的只有请求行 GET index.html
HTTP1.0
（1）增加请求头、响应头，让请求和相应都更清晰
（2）增加状态码，让响应更清晰
（3）增加缓存功能，已请求过的内容再次请求时就可直接使用缓存
GET index.html HTTP/1.0 accept: application/html accept-charset: utf-8 accept-encoding: gzip accept-language: zh-CN
HTTP/1.0 200 OK <!DOCTYPE html> <html> <head></head> <body>hello world!</body> </html>
a. accept 解决文件格式问题，是json还是html，浏览器根据不同文件格式来解析文件；
b. accept-charset 解决文件编码问题，告知浏览器如何将字符流解析成字节流；
c. accept-encoding 解决大文件压缩问题，浏览器采用指定的解压方式来解压；
d. accept-language 解决国际化问题，不同国家请求不同语言的文件。
HTTP1.1
（1）持久连接，多个http请求使用同一个tcp连接，减少了tcp建立连接时的开销
（2）客户端和服务器之间可以建立多个tcp连接以解决队头阻塞的问题
（3）响应体可以分块传输，无需一次传输全部内容
（4）响应头增加content-length字段满足动态内容无法一次计算出长度和无法一次传输完成的问题
（5）增加了安全机制和cookie机制
HTTP2.0
多路复用，客户端和服务器之间只建立一条tcp，每个http请求被切分成多帧，多个http的帧混合在一起在一个tcp连接上传送HTTP3.0
不再使用tcp协议，因为tcp依然是顺序发送，顺序接收的，依然有队头堵塞问题，干掉tcp才能解决队头堵塞问题。google的QUIC就使用了udp协议。
1.39 谈谈HTTP的缓存机制，服务器如何判断当前缓存过期？
参考回答
HTTP报文
在浏览器和服务器进行Http通信时发送的数据即为Http报文，其中分为两部分：
（1）header - 报文的首部或头部，其中保存着各类请求的属性字段，关于Http的缓存相关规则信息均保存在header中；
（2）body - 请求体部分，Http请求真正传输的主体部分。
首次请求基本规则
HTTP缓存主要涉及三个角色：一是浏览器，二是浏览器的缓存数据库，三是服务器。当浏览器端向服务器发出第一次请求时的流程图如下图所示（浏览器再次执行同一的请求时，根据不同的缓存类型将会执行不同的行为）：
浏览器向服务器发出第一次请求后执行流程
缓存的类型
HTTP缓存主要分为两种：强缓存和协商缓存。
两种缓存分别通过HTTP报文头部不同的字段进行控制。服务器如何判断当前缓存过期
（1）强缓存
强缓存基本原理是：所请求的数据在缓存数据库中尚未过期时，不与服务器进行交互，直接使用缓存数据库中的数据。当缓存未命中时，则重新向服务器请求数据，其基本流程分别如下：
当缓存未过期：
当缓存未命中（基本流程与首次请求时相似）：
控制强缓存过期时间的主要有两个规则字段，如下图：
Expire： 其指定了一个日期/时间， 在这个日期/时间之后，HTTP响应被认为是过时的。但是它本身是一个HTTP1.0标准下的字段，所以如果请求中还有一个置了 “max-age” 或者 “s-max-age” 指令的Cache-Control响应头，那么 Expires 头就会被忽略。
Cache-Control：通用消息头用于在http 请求和响应中通过指定指令来实现缓存机制。其常用的几个取值有：
private：客户端可以缓存
public：客户端和代理服务器都可以缓存
max-age=xxx：缓存的内容将在xxx 秒后失效
s-max-age=xxx：同s-max-age，但仅适用于共享缓存(比如各个代理)，并且私有缓存中忽略。
no-cache：需要使用协商缓存来验证缓存数据
no-store：所有内容都不会缓存，强缓存和协商缓存都不会触发
must-revalidate：缓存必须在使用之前验证旧资源的状态，并且不可使用过期资源。（2）协商缓存
当强缓存过期未命中或者响应报文Cache-Control中有must-revalidate标识必须每次请求验证资源的状态时，便使用协商缓存的方式去处理缓存文件。
协商缓存主要原理是：从缓存数据库中取出缓存的标识，然后向浏览器发送请求验证请求的数据是否已经更新，如果已更新则返回新的数据，若未更新则使用缓存数据库中的缓存数据，具体流程如下：当协商缓存命中：
协商缓存未命中：
结合具体的请求来看，首先是第一次发送某请求后服务器的response：
两个字段etag和last-modified是用于协商缓存的规则字段。其中etag是所请求的数据在服务器中的唯一标识，而last-modifind标识所请求资源最后一次修改的时间。
在缓存时间3600秒过去之后，我们再次发起同样的请求：
可以看到，在我们的请求中有这样两个字段if-modifind-since和if-none-match，两个字段分别对应着响应中的last-Modified和etag，用来对协商缓存进行判断：
a. 首先，如果在第一次请求中有etag和last-modified时，缓存数据库会保存这两个字段，并且在再次发起同样的请求时以if-none-match和if-modified-since发送保存的last-modified和etag数据。
b. 服务器收到请求后会以优先级if-none-match > if-modifind-since的顺序进行判断，如果资源的etag和if-none-match相等，即所请求的资源没有变化，此时浏览器即可以使用缓存数据库中的数据，此时http的请求状态码为304，请求的资源未变化。
c. 如果请求字段中没有if-none-match，就使用if-modified-since来判断。如果if-modified-since的值和所请求的资源时间一致，即所请求的资源相同，浏览器即可以使用缓存数据库中的数据。http状态码304。
浏览器缓存机制流程图
