输入网址后,会经历哪几个步骤

2023-11-16

1、面试官问输入网址后,会经历哪几个步骤？

DNS HTTPS(TCP).......就知道这两个

DNS解析
TCP连接
发送http请求
1. HTTP请求报文的方法是 get ，如果浏览器存储了该域名下的 Cookies，那么会把 Cookies放入 HTTP请求头里发给服务器，用于识别用户信息
2. 两种 HTTP 请求方法：GET 和 POST
  
  在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET 和 POST。
3. GET - 从指定的资源请求数据。
4. POST - 向指定的资源提交要被处理的数据
服务器处理请求
1. 服务器端WEB程序接收到http请求以后，就开始处理该请求，处理之后就返回给浏览器html文件。
浏览器解析 html 代码，并请求 html 代码中的相关资源
1. 浏览器拿到 index.html 文件后，就开始解析其中的 html 代码，遇到 js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这个时候就用上 keep-alive 特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里的顺序。
浏览器解析渲染页面
1. 最后，Chrome 浏览器利用自己内部的工作机制，把请求到的静态资源和 html 代码进行渲染，渲染之后呈现给用户。
连接结束

应用层：为用户提供各种服务，比如我们浏览网页时用到的HTTP，收发邮件时用的SMTP，登录远程主机用的SSH。
传输层：提供端到端的传输服务。更具体地讲，提供进程到进程的传输服务。
网络层：和传输层一样，可以概括为提供端到端的传输服务。更具体地讲，网络层提供主机到主机的传输服务。
网络接口层（链路层）：为直接连接的设备提供传输服务，将数据帧转换为比特流，并将比特流转换为物理电路的电压高低信号。

解析：

    第一步应该是浏览器对用户输入的网址做初步的格式化检查，只有格式通过才会进入下一步。
    那么浏览器使用的是http还是https访问服务器呢？
    浏览器默认使用http协议，除非可以加上https，所以浏览器先进行URL补齐。
    浏览器请求本地DNS服务发出请求查询zhihu.com的IP地址，DNS则先查看自己的DNS 缓存，如没有，再查看本地硬盘里的host文件，也没有！
    于是，主机DNS模块充当DNS客户向本地域名服务器发出查询请求，传输DNS报文使用的是UDP协议。UDP在报头加上源端口号和目的端口号等信息将其封装成UDP数据报，然后传递给IP协议单元，IP将该数据封装成IP数据报，其目的地址为本地DNS服务器的IP地址。查看路由表，如果要出网关得到网关的IP，向数据链路层交付。发送时在ARP缓存中查看其对应的MAC地址，如果没有就发送ARP广播，网关收到广播后回应，于是将IP地址与网关的MAC地址对应写入ARP缓存表，之后以数据帧的形式进行转发。
    经过几次转发之后，本地域名服务器收到数据帧后，逐层向上交付，给目的端口为53的DNS服务，于是DNS服务程序将其回复。
    如果本地DNS服务没有其IP地址的话，本地域名服务器就以DNS客户的身份去查询根域名服务器，根域名服务器向其回应域名对应的IP或下一次查询的顶级域名服务器的IP地址。
    以这样迭代查询的方式，终于得到域名所对应的IP地址，就立马回应给本地主机。
    第二步：与目的主机进行TCP连接(进行三次握手)。
    第三步：建立连接之后，则发送http请求，然后接收请求数据
    主要过程如下：
    建立连接之后，浏览器生成HTTP GET报文，并交付给HTTP服务器
    HTTP服务器从TCP套接字读取HTTP报文，生成一个HTTP的响应报文，将Web页面内容放入报文主体中，发回主机。
    浏览器收到HTTP响应报文之后，抽取出Web页面的内容。之后进行渲染，显示Web页面。
    第四步：与目的主机断开TCP连接。
————————————————

浏览器所在的主机向本地DNS服务器发送一个含有知乎域名的DNS查询报文。本地DNS服务器把查询报文转发到根DNS服务器，该根DNS服务器注意到其com后缀并向本地DNS服务器返回com的顶级域名服务器的IP地址。该本地DNS服务器再次向comDNS服务器发送查询请求，comDNS服务器注意到其http://zhihu.com后缀并用负责该域名的权威DNS服务器的IP地址作为回应。最后，本地域名服务器将含有http://zhihu.com的IP地址的响应报文发送给客户端主机。

HTTP报文的格式

这个请求里面包含了请求的方法GET，请求的路径“/”，请求的主机名，客户机的类型以及一些其他的信息。

GET / HTTP/1.1
Host: zhihu.com
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64;
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

http 80

https 443 传输数据还是80端口 443改了就不可以用了443是浏览器默认的，当我们访问http://baidu.com https://baidu.com 1、向443发请求请求加密算法 1.1 传输加密算法-》保证安全，不被拦截2、有事情（浏览器向80端口发送请求） 3、回80端口拿数据加密算法 decode

http 明文传输谁都可以看见

公钥加密只能私钥解

浏览器-----------------------服务器（私钥）生成公钥

拦截者也可以生成私钥私钥生成公钥

第三方CA：私钥->公钥服务器 CA私钥（服务端.公钥+域名+公钥的摘要） = 证书

如果说使用的不是http而是https的话呢？

如果是https的话，在TCP三次握手成功之后，不是直接交给TCP发送，而是使用SSL进行加密，使传输过程中的内容不被篡改、替换。
过程如下：
（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。客户端发送自己的版本号，还有自己支持的算法到服务器端。
（2）Web服务器收到客户请求之后，将自己的版本号，所支持的算法，还有网站的证书信息（证书中包含公钥）传送一份给客户端。
（3）客户端开始匹配对方的版本号以及算法，然后利用证书里的公钥去解密证书的数字签名，解开了则说明证书有效。然后生成一个随机的明文字符串，用网站的公钥加密，传送给服务器。
（4）Web服务器利用自己的私钥解密得到这个明文字符串，然后利用它生成会话密钥然后发送给客户端。
（5）之后双方通过会话密钥进行加密通信,传输到后，https服务返回URL主页的内容，并最终到达浏览器。

一开时是http

TLS/SSL总结：

1、对称加密服务器生成一个密钥传给客户端服务器发送数据时会用这把密钥加密客户端收到数据后会用密钥解密

所谓对称就是两边用的都是一样的密钥 //这样很不安全很容易被解密

2、非对称加密（公钥加密别人不知道私钥很安全，但是速度很慢）

所谓非对称就是两边钥匙不一样，用公钥加密的数据，只有对应的私钥才能解密；用私钥加密的数据，只有对应的公钥才能解密。

客户端把公钥明文发给服务器端

3、对称加非对称

我们可以用非对称加密的方式来传输对称加密过程中的密钥，之后我们就可以采取对称加密的方式来传输数据了。具体是这样子的：

服务器用明文的方式给客户端发送自己的公钥，客户端收到公钥之后，会生成一把密钥(对称加密用的)，然后用服务器的公钥对这把密钥进行加密，之后再把加密后的密钥传输给服务器，服务器收到之后进行解密，最后服务器就可以安全着得到这把密钥了，而客户端也有同样一把密钥，他们就可以进行对称加密了。

不安全：（只要是发送密钥就会不安全）

服务器以明文的方式给客户端传输公钥的时候，中间人截取了这把属于服务器的公钥，并且把中间人自己的公钥冒充服务器的公钥传输给了客户端。

之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥传输给服务器，这个时候中间人又把密钥给截取了，中间人用自己的私钥对这把被加密的密钥进行解密，解密后中间人就可以获得这把密钥了。

最后中间人再对这把密钥用刚才服务器的公钥进行加密，再发给服务器。如图：

数字证书：

非对称加密会不安全，是因为客户端不知道这把公钥是否是服务器的，因此，我们需要找到一种策略来证明这把公钥就是服务器的，而不是别人冒充的。

解决这个问题的方式就是使用数字证书，具体是这样的：

我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。

服务器在给客户端传输公钥的过程中，会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。如图

为了防止信息摘要被人调换，服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。如图:

并且，最后还会把原来没Hash算法之前的个人信息以及公钥和数字签名合并在一起，形成数字证书。如图

当客户端拿到这份数字证书之后，就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要，然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比，如果一样，则证明这个人是服务器，否则就不是。如图：

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)

贪心算法

TCPIP