结构:get 有请求体,post没有请求体
应用场景:get 用于获取数据,post用于提交数据;
缓存:get 的缓存保存在浏览器和web服务器日志中;
传输方式:get 使用明文传输,post请求保存在请求体中;
请求长度:get 长度限制在2kb以内。
get、post、put、delete、head
http1.0 浏览器与服务器只保持短暂的连接,每次请求都需要向,服务器建立一个TCP
连接;
http1.0 存在宽带资源浪费的现象,例如只需要某个对象的一部分,而服务器却把整个对象传输过来;
http1.1 支持长链接,默认开启了keep-alive ,弥补了http1.0每次传输都需要创建链接的问题;
http1.1 使用持久连接来时多个HTTP请求复用同一个TCP连接;
http1.1 支持管道传输 ,一个请求发出去,不必等它回来,就可以发送第二次;
http1.1 引入了更多的缓存策略 Etag 、If-Match、if-None-Match
http1.1 中新增了 host 字段,用来指定服务器的域名。
二进制分帧、多路复用、数据流、头部压缩、基于HTTPS相对安全、服务器推送
http2.0 使用二进制协议,头部信息和数据体都是二进制,统称为’帧’;
http2.0 使用多路复用TCP连接,客户端和服务端可以同时发送多个请求;
http2.0 将每个请求和回应都标记一个数据流ID;
http2.0 头部使用gzip 和 compress 压缩头部信息,在客户端和服务器之间共同维护一张头信息索引表,每次请求只发送索引号,就能找到相应的头部信息表;
http2. 0 服务端不再是被动响应,可以主动向客户端发送消息。
(1)、首先判断输入的url是一个合法的连接还是待搜索关键词,如果是个合法的url 👇;
(2)、就进行缓存判断,如果浏览器中有缓存资源,则直接访问缓存资源;如果没有,则开始👇;
(3)、DNS解析,客户端给本地DNS服务器发送一个请求,查看是否存在缓存,有就直接访问;
? 如果没有,就向根域名服务器发送请求,根域名服务器发现是.com或者.cn后缀的域名;
? 就交给顶级域名服务器,顶级域名服务器返回baidu.com域名信息;
? 并让本地DNS转向访问权威域名服务器,权威域名服务器返回www .baidu. com对应的IP地址,
? 同时本地DNS缓存该ip地址,客户端收到IP地址后进行访问。
(4)、CDN(内容分发网络)
? 如果服务器使用了CDN,DNS返回的不再是IP地址,而是CNAME别名,指向全局均衡CNAME;
? 浏览器发送url给DNS服务器,DNS进行域名解析,解析发现该url有一个CDN专用的DNS服务器;
? DNS会将解析权交给CNAME指向的CDN专用DNS服务器,CDN专用DNS服务器将IP返回给浏览器;
? 浏览器向CDN全局负载均衡服务器发起请求,CDN全局负载均衡服务器根据IP;
? 找到距离用户最近的区域负载均衡服务器,选择合适的缓存服务器响应用户的请求。
?
(5)、TCP三次握手:
? 第一次握手,客户端向服务器发送一个SYN的报文,并初始化序列 ISN;
? 第二次握手,服务端收到客户端的SYN后,将ISN+1作为自己的ACK值,并以自己的SYN作为应答;
? 第三次握手,客户端收到服务端的SYN后,向服务端发送一个ACK报文,值为ISN+1,服务器收到后双方就建立了连接。
🌰为什么是三次握手?不是两次、四次?
? 三次握手可以阻止重复 历史连接的初始化(主要原因);
? 三次握手可以同步双方的初始序列号;
? 三次握手可以避免资源浪费。
🌰SYN是什么?ACK又是什么?
(5)、页面渲染:浏览器将html解析成DOM树,将css解析成CSSOM树,结合DOM树和CSSOM树生成渲染树。接着解析
(6)、TCP四次挥手:
? 第一次挥手,客户端向服务器发送一个FIN的报文,之后进入FIN_Wait_1状态;
? 第二次挥手,服务端收到该报文后,向客户端发送ACK报文作为应答,接着服务端进入closed_wait状态;
? 第三次挥手,客户端收到服务端的ACK报文后,进入FIN_Wait_2状态,等待服务端数据处理完,继续向客户端发送一个FIN报文,之后服务端进入了Last_ack状态;
? 第四次挥手,客户端收到服务端的FIN报文后,就进入了Closed 状态,至此服务端已经完成了连接关闭。客户端在经过2msl后,自动进入closed状态,至此客户端进入了完成连接关闭。
http1.0 默认开启的长链接(keep-alive
),使用持久连接来使多个http请求复用同一个TCP连接,数据传输完成保持TCP连接不断开。
具有①减少CPU和内存的使用。②降低阻塞控制。③减小后续请求延迟。
https是为了解决http中 ①内容可能被监听②不验证通信方身份的问题 产生的,这里的s
表示TLS/SSL协议,其中SSL的实现,主要依赖于对称加密、非对称加密、摘要算法、数字签名这几种手段。
对称加密:加密和解密使用的密钥都是同一个,是对称的。
非对称加密:存在两个密钥,一个公钥,一个私钥。公钥和私钥都可以用来加密解密,公钥加密的必须使用私钥解密。
混合加密:对称加密+非对称加密,具体做法:发送密文的一方使用对方的公钥对“对称密钥”进行加密,然后对方用自己的密钥对“对称的密钥”解密;
摘要算法:把任意长度的密钥压缩成固定长度,形成了一个独一无二的的”摘要“字符串;
摘要算法可以理解为“单向"加密算法,常用的算法是 SHA-2,只有算法,没有密钥,加密后的数据无法解密;
但是不具有机密性,如果黑客把传递的消息和摘要一起改了,完整鉴别不出完整性!
数字签名:私钥对摘要的加密,可以由公钥解密后验证,把公钥私钥的用法反过来,私钥加密、公钥解密。
? 数字证书认证机构(CA): 服务端向数字证书认证机构提出公开密钥申请,数字证书认证机构确定申请者的身份后,会对已申请的公开密钥做数字签名;然后分配这个已签名的公开密钥,并将公开密钥放入公钥证书后绑定在一起;服务端会将这份数字证书发送给客户端,以进行非对称加密通信;接收到证书的客户端使用数字证书认证机构的公开密钥,对服务器发送过来的数字签名进行认证,验证通过,则证明认证服务器公开密钥是真正有效的认证机构。
状态码 | 含义 | 描述 |
---|---|---|
1xx | 信息状态码 | 接收的请求正在处理 |
2xx | 成功状态码 | 请求正常处理完毕 |
204 | 响应头没有body数据 | |
206 | 相应头的body不是资源的全部 | |
3xx | 重定向 | 客户端请求资源变动,需重新发送请求 |
301 | 永久重定向 | 请求资源不存在了,需要用新的url访问 |
302 | 临时重定向 | 请求资源还在,暂时用新的url访问 |
304 | 缓存重定向 | 重定向已缓存文件 |
4xx | 客户端错误 | |
403 | 服务器禁止访问资源 | |
404 | 请求的资源找不到 | |
5xx | 服务器内部错误 | |
501 | 客户端请求的功能还不支持 | |
502 | 服务器自身工作正常,访问后端服务器发生错误 | |
503 | 服务器很忙,暂时无法响应 |
UDP(用户数据报协议):对应用层交下来的报文,不合并、不拆分,只是在其上面加个首部就交给网络层;
TCP(传输控制协议):把上应用层交下来的数据看成无结构的字节流来发送。
①TCP是面向连接协议,建立连接3次握手,断开连接4次挥手;UDP是面向无连接,接收端从消息队列读取,发送端将数据发送到网络。
②TCP提供可靠服务,传输过程可以确保数据无差错,不丢失;UDP尽可能传递数据,但不保证数据是否安全到达。
③TCP面向字节流,将应用层报文看作无结构的字节流,芬姐为多个报文段传输后,在目的站重新装配;UDP面向报文,不合并也不拆分,只保留报文边界。
④TCP只能点对点,双工传输;UDP支持一对一、一对多、多对一和多对多传输。
⑤TCP传输效率低;UDP传输效率高。
TCP:SMTP(电子邮件)、Telnet(传输终端接入)、Http(万维网)、FTP(文件传输系统);
UDP:DNS(域名服务系统)、TFTP(文件传输)、SNMP(网络管理)、NFS(远程文件服务器);
如果一次请求发送的数据量较小,没达到缓冲区大小,TCP则会将多个请求合并为同一个请求进行发送,这就造成了TCP粘包的问题。
解决方案:①发送端将每个报封装成固定长度;
? ②发送端在每个包末尾使用固定分隔符;
? ③将消息分成头部和消息体,头部信息足够长才算读到一个完整的消息。