目录
问:https status code 502和504的区别?
标签属性
tabindex
网页通常使用鼠标操作,但是某些情况下,用户可能希望使用键盘,或者只有键盘可以用。因此,浏览器允许使用 Tab 键,遍历网页元素。也就是说,只要不停按下 Tab 键,网页的焦点就会从一个元素转移到另一个元素,选定焦点元素以后,就可以进行下一步操作,比如按下回车键访问某个链接,或者直接在某个输入框输入文字。
这里就有一个问题,按下 Tab 键的时候,浏览器怎么知道跳到哪一个元素。HTML 提供了tabindex属性,解决这个问题。它的名字的含义,就是 Tab 的顺序(index)。
encode
用于指定一个字符串的编码方式。
网页可以使用不同语言的编码方式,但是最常用的编码是 UTF-8。UTF-8 编码是 Unicode 字符集的一种表达方式。这个字符集的设计目标是包含世界上的所有字符,目前已经收入了十多万个字符。
每个字符有一个 Unicode 号码,称为码点(code point)。如果知道码点,就能查到这是什么字符。举例来说,英文字母a
的码点是十进制的97
(十六进制的61
)。
不是每一个 Unicode 字符都能直接在 HTML 语言里面显示:
(1)不是每个 Unicode 字符都可以打印出来,有些没有可打印形式,比如换行符的码点是十进制的10
(十六进制的A
),就没有对应的字面形式。
(2)小于号(<
)和大于号(>
)用来定义 HTML 标签,其他需要用到这两个符号的场合,必须防止它们被解释成标签。
(3)由于 Unicode 字符太多,无法找到一种输入法,可以直接输入所有这些字符。换言之,没有一种键盘,有办法输入所有符号。
(4)网页不允许混合使用多种编码,如果使用 UTF-8 编码的同时,又想插入其他编码的字符,就会很困难。
HTML 为了解决上面这些问题,允许使用 Unicode 码点表示字符,浏览器会自动将码点转成对应的字符。
字符的码点表示法是&#N;
(十进制,N
代表码点)或者&#xN;
(十六进制,N
代表码点),比如,字符a
可以写成a
(十进制)或者a
(十六进制),字符中
可以写成中
(十进制)或者中
(十六进制),浏览器会自动转换。
*Get以地址栏的形式传参 post form表单形式传输
URL 字符转义的方法
在这些字符的十六进制 ASCII 码前面加上百分号(%
)。下面是这18个字符及其转义形式。
-
!
:%21 -
#
:%23 -
$
:%24 -
&
:%26 -
'
:%27 -
(
:%28 -
)
:%29 -
*
:%2A -
+
:%2B -
,
:%2C -
/
:%2F -
:
:%3A -
;
:%3B -
=
:%3D -
?
:%3F -
@
:%40 -
[
:%5B ]
:%5D
不同状态码的差别
传输方式的改变
问:https status code 502和504的区别?
502 bad gateway 网关错误 后端服务器tomcat没有起来,应用服务的问题(前提是接入层7层正常的情况下)。
应用服务问题一种是应用本身问题;另一种是因为依赖服务问题比如依赖服务RT高,依赖的服务有大的读取(mysql慢查,http等),以至于调用方超过超时read时间;服务集群压力大时,也会出现502超时(502理解为不可响应或响应不过来,其实还是不可响应)。
504 gateway time-out 顾名思义 网关超时 一般计算机中的超时就是配置错了,此处一般指nginx做反向代理服务器时,所连接的服务器tomcat无响应导致的。
从网络角度,502已经与后端建立了连接,但超时;504与后端连接未建立,超时。
DNS原理
HTTPS
RSA密钥协商握手过程
TLS
TLS第一次握手
客户端首先会发一个「Client Hello」消息,字面意思我们也能理解到,这是跟服务器「打招呼」。
消息里面有客户端使用的 TLS 版本号、支持的密码套件列表,支持的压缩算法,以及生成的随机数(*Client Random*),这个随机数会被服务端保留,它是生成对称加密密钥的材料之一。
TLS第二次握手
当服务端收到客户端的「Client Hello」消息后,会确认 TLS 版本号是否支持,和从密码套件列表中选择一个密码套件,还有选择压缩算法(安全性原因,一般不压缩),以及生成随机数(*Server Random*)。
接着,返回「Server Hello」消息,消息里面有服务器确认的 TLS 版本号,也给出了随机数(Server Random),然后从客户端的密码套件列表选择了一个合适的密码套件。
可以看到,服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。
这个密码套件看起来真让人头晕,好一大串,但是其实它是有固定格式和规范的。基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」, 一般 WITH 单词前面有两个单词,第一个单词是约定密钥交换的算法,第二个单词是约定证书的验证算法。
小总结
就前面这两个客户端和服务端相互「打招呼」的过程,客户端和服务端就已确认了 TLS 版本和使用的密码套件,而且你可能发现客户端和服务端都会各自生成一个随机数,并且还会把随机数传递给对方。
那这个随机数有啥用呢?其实这两个随机数是后续作为生成「会话密钥」的条件,所谓的会话密钥就是数据传输时,所使用的对称加密密钥。
然后,服务端为了证明自己的身份,会发送「Server Certificate」给客户端,这个消息里含有数字证书。
随后,服务端发了「Server Hello Done」消息,目的是告诉客户端,我已经把该给你的东西都给你了,本次打招呼完毕。
客户端验证证书
在这里刹个车,客户端拿到了服务端的数字证书后,要怎么校验该数字证书是真实有效的呢?
数字证书和 CA 机构
在说校验数字证书是否可信的过程前,我们先来看看数字证书是什么,一个数字证书通常包含了:
-
公钥;
-
持有者信息;
-
证书认证机构(CA)的信息;
-
CA 对这份文件的数字签名及使用的算法;
-
证书有效期;
-
还有一些其他额外信息;
那数字证书的作用,是用来认证公钥持有者的身份,以防止第三方进行冒充。说简单些,证书就是用来告诉客户端,该服务端是否是合法的,因为只有证书合法,才代表服务端身份是可信的。
数字证书签发和验证流程
TLS第三次握手
客户端验证完证书后,认为可信则继续往下走。接着,客户端就会生成一个新的随机数 (pre-master),用服务器的 RSA 公钥加密该随机数,通过「Change Cipher Key Exchange」消息传给服务端。
服务端收到后,用 RSA 私钥解密,得到客户端发来的随机数 (pre-master)。
至此,客户端和服务端双方都共享了三个随机数,分别是 Client Random、Server Random、pre-master。
于是,双方根据已经得到的三个随机数,生成会话密钥(Master Secret),它是对称密钥,用于对后续的 HTTP 请求/响应的数据加解密。
生成完会话密钥后,然后客户端发一个「Change Cipher Spec」,告诉服务端开始使用加密方式发送消息。
然后,客户端再发一个「Encrypted Handshake Message(Finishd)」消息,把之前所有发送的数据做个摘要,再用会话密钥(master secret)加密一下,让服务器做个验证,验证加密通信是否可用和之前握手信息是否有被中途篡改过。
可以发现,「Change Cipher Spec」之前传输的 TLS 握手数据都是明文,之后都是对称密钥加密的密文。
TLS 第四次握手
服务器也是同样的操作,发「Change Cipher Spec」和「Encrypted Handshake Message」消息,如果双方都验证加密和解密没问题,那么握手正式完成。
最后,用「会话密钥」加解密 HTTP 请求和响应。