当你在浏览器输入www.xxx.com的时候会发生什么？

最近记录了一些java中常踩的坑、设计思路和小知识点，大家可以看看
详细记录一次接入xxl-job的踩坑路径
30s快速解决循环依赖
idea中一个小小的操作竟能解决如此多的问题
docker中的服务接入xxljob需要注意的一点
关于一次fullgc的告警分析
mysql中的int类型竟变成了它？
jpa中的字段总是自己莫名更新？
获取不到类上的注解？空指针？
学会这招，再也不怕依赖冲突！
redis的热点key还能这么处理？
领导让我设计一个任务系统
当服务重启时，大部分人没考虑这点
参数还能这么优雅校验？
文件上传报错，全局异常处理！
常见的点赞功能如何实现，如何防止刷赞

HTTP和HTTPS区别

• http(80端口):超文本传输协议，明文传输，不安全，免费的，无状态的
• https(443端口):加密安全版的http，通过在http下层加入ssl协议，ssl协议依靠CA证书，证书需要一定的费用，有身份认证的，不是无状态的

http协议的基础构成

http协议的基础构成.

https的访问流程

在了解https的访问流程之前，有几个小知识需要先简单了解一下

加密

• 对称加密:加密解密用的都是一个秘钥
• 非对称加密：私钥加密的内容只有公钥才能解开，公钥加密的内容只有私钥才能解开
  详见我的另一篇博客链接: 对称加密和非对称加密的区别和场景.

CA证书

CA证书中一般包含以下信息

1. 证书颁发机构
2. 使用机构
3. 公钥
4. 有效期
5. 签名算法
6. 签名hash算法
7. 指纹算法
8. 指纹

TCP三次握手、四次分手

详见我的另一篇博客链接: TCP的三次握手和四次分手.

OSI七层模型和TIC/IP模型

• 应用层包括http、https、dns、ftp等协议
• 传输层包括tcp协议
• 网络层ip协议
• 数据链路层(MAC地址)和物理层(比特流)其实就是硬件层面了

模型传输过程

请求发起，装包的过程

数据链路层的目标mac地址是通过ARP协议(用目标ip去广播，等待对应ip的机器发来它的mac地址)获得的

请求收到，拆包的过程(中途包含了负载均衡)

nginx监听这块放到另一篇文章去讲。

整体的流程

1. 发送请求：用户在浏览器的地址栏中输入url，按下回车键发送请求，这个请求还包含着浏览器支持的协议、加密算法等
2. 本地host解析：请求先被本地host拦截，看下是否有配置，有的话把请求中的url转为对应的ip地址
3. DNS服务器解析：请求到达dns服务器(如果这个时候是ip的话就不用)，dns解析成对应的ip，然后客户端连上服务端的443端口，将请求发给服务端
4. 服务器验证加密算法：服务端查看请求中发来的加密算法，自己是否支持
5. 服务器发送证书：支持的话就把CA证书发给客户端(这个过程中公钥有泄漏的风险，所以不会用它来进行最后的通信)，否则断开连接
6. 客户端验证证书：客户端收到证书，验证证书是否合法(发布机构是否合法，使用机构、访问网址等是否一致)
7. 客户端生成并加密会话秘钥：证书验证通过/接受了不信任的证书后，客户端生成一个随机数(后面统称会话秘钥，这是一个对称性加密)，并使用服务端传来的公钥加密这个会话秘钥，这样的话，要获取会话秘钥就只能靠服务端的私钥解密了。
8. TCP第一次握手：客户端用证书中的签名hash算法获取TCP握手信息(就是那些SYN标志位啥的)的hash值，用刚刚生成的会话秘钥加密TCP握手信息和它的hash值。hash值的作用是保证传输过程中握手信息没有被篡改。
9. 将第7步中生成并加密的会话秘钥，第8步中加密的握手信息和hash值发送给服务端
10. 服务端验证：服务端收到客户端发来的信息，首先用自己的私钥解密得到客户端发来的会话秘钥，然后用这个会话秘钥去解密TCP握手信息和它的hash值，最后用自己证书中的签名hash算法计算TCP握手信息得到一个hash值，与客户端传来的hash值做对比，来验证握手信息是否经过篡改。
11. TCP二次握手：上述验证无误后，服务端把它自己的握手信息也生成一个hash值，并用会话秘钥加密二者，传给客户端
12. TCP三次握手：客户端用会话秘钥解密、验证hash无误后，把第三次握手信息与它的hash值用会话秘钥加密后，发送给服务端，握手完毕，两台机器建立连接。
13. 之后客户端和服务端就可以通过会话秘钥进行通信了。