DNS

1、DNS的过程？
比如浏览器想获取www.baidu.com域名对应的ip，
1、先从本地文件缓存查找，如果查询到直接返回，否则执行2；
2、访问本地DNS服务器(一般是由ISP提供的)，如果可以在服务器缓存查询直接返回，否则执行3；
3、本地DNS服务器询问根域名服务器(全球有13个，不提供域名解析服务，而是返回*域名服务器的ip地址)，
根DNS发现域名后缀是.com,返回.com对应的*域名服务器地址，执行4；
4、*域名服务器负责二级域名的管理也就是163.com，本地DNS询问*域名服务器，发现域名是以.com后缀结尾，返回163.com对应的权威DNS服务器ip地址，执行5；
5、本地DNS询问权威DNS服务器，返回www.baidu.com对应的ip，执行6；
6、本地DNS返回www.baidu.com对应的ip给客户端，客户端缓存域名解析结果

DNS劫持：DNS服务器解析一个不正确的IP地址返回给客户端；
DNS投毒：DNS请求或者响应被篡改

根域名服务器->*域名服务器->权威域名服务器

TCP

可靠传输
流量控制
拥塞控制

可靠传输怎么保证？
1、传输前通过建立连接来确定初始字节的序列号
2、tcp首部的序列号和确认应答号
3、超时重传，重传时间考虑往返时间(RTT)和偏差
4、滑动窗口
5、差错检测，tcp首部有16位的校验和

序列号是tcp传输应用层协议每个字节的编号，不一定从1开始，由tcp创建连接时候确定号
比如序列号为1，第一次传输1000字节，那么发送端需要收到确认应答号为1001的时候才知道接收端已经成功接收这1000个字节
确认应答号是通过接收的tcp数据报首部的序列化加上数据字节长度得到

MSS-最大消息长度，指tcp数据报减去tcp首部的长度，可以在连接建立的SYN和SYN+ACK阶段确认
含义是每次发送数据时，不会超过MSS的长度

滑动窗口的出现是为了解决一次只发送一个段不能充分利用网络资源，而且性能不佳，改进是一次发送多个段，前面的段确认应答丢失了可以等待下一个段的确认应答

Nagle算法-数据长度小于MSS，延迟发送，下面条件有个=一个满足时才发送，对于响应时间敏感的系统要关闭
1、已发送的数据都已经收到确认应答时
2、可以发送最大段长度（MSS） 的数据时

TCP的延迟确认应答和捎带应答


TCP三次握手
客户端发送SYN 给服务端，服务端返回SYN+ACK给客户端，客户端再发送ACK给服务端，连接建立
三次握手状态变化：客户端发送SYN后，状态变成SYN_SENT,服务端没收到SYN之前，状态是LISTEN，
收到SYN 后，状态变成SYN_RCVD,然后服务端返回SYN+ACK给客户端，客户端收到后发送ACK给服务端，状态变成ESTABLISHED,服务端收到后ACK后，状态变成ESTABLISHED,
通信前需要建立三次握手的目的是同步序列号，用于后面的可靠传输

TCP四次挥手

HTTPS

HTTPS要求客户端(浏览器)和服务端都需要自己的公钥私钥

如何将不对称加密的公钥给对方呢？
一种是放在一个公网的地址上，让对方下载；另一种就是在建立连接的时候，传给对方。

HTTPS原理：对称加密效率高，但是解决不了密钥传输的问题，非对称加密可以解决这个问题，但是效率不高。
所以HTTPS先利用非对称加密商议确定对称加密的密钥，再利用对称加密进行通信

HTTPS过程：
1、客户端->服务端：Client Hello(TLS版本、加密套件、压缩算法套件、随机数R1)
2、服务端->客户端:Server Hello(告诉客户端选择使用哪个TLS版本、加密套件、压缩算法套件和随机数R2)
3、服务端->客户端:Server Certificate(传输证书)
4、服务端->客户端:Server Hello Done(完毕)
5、客户端验证服务端证书：从自己信任的CA仓库，比如CA1、CA2、CA3，先用CA1证书的公钥解密服务端的证书，如果成功证明证书可信，否则用CA2、CA3验证
6、客户端->服务端:前提是证书验证成功，产生随机数字Pre-master，用服务端证书的公钥加密后发送，
服务端用私钥解密获取随机数字Pre-master，用服务端证书的公钥加密后发送，服务端用私钥解密获取随机数字Pre-master
7、客户端和服务端用R1、R2、随机数字Pre-master计算出对称密钥
8、客户端->服务端:Change Cipher Spec
9、客户端->服务端:Encrypted Handshake Message
10、服务端->客户端:Change Cipher Spec
11、服务端->客户端:Encrypted Handshake Message

HTTPS可以开启双向验证

HTTPS存在的问题：
重放和篡改

HTTP

HTTP

HTTP1.0

POST

状态码

请求头

HTTP1.1

持久连接

管道

线头阻塞问题：服务端要按照请求顺序进行处理

HTTP2.0

TCP多路复用

解决了应用层的线头阻塞问题，但还存在传输层的线头阻塞问题

请求头压缩

服务端推送

HTTP3.0

QUIC

基于UDP