4.1请求网络过程分析
目录介绍
- 01.在浏览器里面输入链接
- 02.请求的大概流程介绍
- 03.域名解析查找ip地址
- 04.传输层的流程分析
- 05.网络层的流程分析过程
- 07.熟知Http请求的过程
01.在浏览器里面输入链接
- 先思考几个问题
- 在浏览器中输入了一个链接,为什么会打开网页,然后看到图片,文字,这些东西是哪里来的?
- 在浏览器中输入非http类型链接,为何有的可以打开,有的打不开,对链接有何要求?
- 为什么打开购物网站后,本来是打开我的收藏,但是去重定向到了首页登陆页面?
- 然后简述一下问题
- 第一个问题:打开网页,会去请求服务器数据,然后返回response数据后,会渲染到网页上进行展示。
- 第二个问题:浏览器输入链接,必须要求访问的链接scheme是受支持的,也就是支持的协议。否则未知的协议链接肯定打不开。
- 第三个问题:针对购物网站,会有身份校验(token)的环节,如果过期了则会重定向到登陆页面进行登陆。
02.请求的大概流程介绍
- 大概流程如下所示
- 域名解析
- TCP的三次握手
- 建立TCP连接后发起HTTP请求
- 服务器响应HTTP请求
- 浏览器解析html代码
- 同时请求html代码中的资源(如js、css、图片等)
- 最后浏览器对页面进行渲染并呈现给用户
- 重点说一下
- 三次握手
03.域名解析查找ip地址
- 域名解析
- 浏览器只知道名字是“www.taobao.com”,但是不知道具体的地点,所以不知道应该如何访问。于是,它打开地址簿去查找。可以使用一般的地址簿协议DNS去查找,还可以使用另一种更加精准的地址簿查找协议HTTPDNS。
- 无论用哪一种方法查找,最终都会得到这个地址:108.114.138.24,这也就是所说的域名解析。这个是IP地址,是互联网世界的“门牌号”。
- Http或者Https协议
- 知道了目标地址,浏览器就开始打包它的请求。
- 对于普通的浏览请求,往往会使用HTTP协议;但是对于购物的请求,往往需要进行加密传输,因而会使用HTTPS协议。无论是什么协议,里面都会写明“你要买什么和买多少”。
- 为何输入非http链接打不开
- 因为这是一种传输协议
04.传输层的流程分析
- 应用层到传输层
- DNS、HTTP、HTTPS 所在的层我们称为应用层。经过应用层封装后,浏览器会将应用层的包交给下一层去完成,通过 socket 编程来实现。
- 传输层分析
- 下一层是传输层。传输层有两种协议,一种是无连接的协议UDP,一种是面向连接的协议TCP。
- 对于有支付来讲,往往使用 TCP 协议。所谓的面向连接就是,TCP 会保证这个包能够到达目的地。如果不能到达,就会重新发送,直至到达。
- TCP 协议里面会有两个端口,一个是浏览器监听的端口,一个是电商的服务器监听的端口。操作系统往往通过端口来判断,它得到的包应该给哪个进程。
image
05.网络层的流程分析过程
- 网络层处理逻辑
- 传输层封装完毕后,浏览器会将包交给操作系统的网络层。网络层的协议是 IP 协议。在 IP 协议里面会有源 IP 地址,即浏览器所在机器的 IP 地址和目标地址,也即电商网站所在服务器的 IP 地址。
image - 操作系统知道了目标 IP 地址,就开始根据这个门牌号找到目标机器。操作系统往往会判断,这个目标 IP 地址是本地人,还是外地人。如果是本地人,从门牌号就能看出来,但是显然电商网站不在本地,而在遥远的地方。
- 操作系统知道要离开本地去远方。虽然不知道远方在何处,但是可以这样类比一下:好比去国外要去海关,去外地就要去网关。而操作系统启动的时候,就会被 DHCP 协议配置 IP 地址,以及默认的网关的 IP 地址 192.168.1.1。
- 操作系统将 IP 地址发给网关的时候,如果在本地通信基本靠吼,于是操作系统大吼一声,谁是 192.168.1.1 啊?网关会回答它,我就是,我的本地地址在那里。这个本地地址就是MAC地址,而大吼的那一声是ARP协议。
image
- MAC层处理逻辑
- 于是操作系统将 IP 包交给了下一层,也就是MAC 层。网卡再将包发出去。由于这个包里面是有 MAC 地址的,因而它能够到达网关。
- 网关
- 网关收到包之后,会根据自己的知识,判断下一步应该怎么走。网关往往是一个路由器,到某个 IP 地址应该怎么走,这个叫作路由表。路由器有点像玄奘西行路过的一个个国家的一个个城关。每个城关都连着两个国家,每个国家相当于一个局域网,在每个国家内部,都可以使用本地的地址 MAC 进行通信。一旦跨越城关,就需要拿出 IP 头来,里面写着贫僧来自东土大唐(就是源 IP 地址),欲往西天拜佛求经(指的是目标 IP 地址)。路过宝地,借宿一晚,明日启行,请问接下来该怎么走啊?
image
- 路由协议
- 城关往往是知道这些“知识”的,因为城关和临近的城关也会经常沟通。到哪里应该怎么走,这种沟通的协议称为路由协议,常用的有OSPF和BGP。
image - 城关与城关之间是一个国家,当网络包知道了下一步去哪个城关,还是要使用国家内部的 MAC 地址,通过下一个城关的 MAC 地址,找到下一个城关,然后再问下一步的路怎么走,一直到走出最后一个城关。
- 最后一个城关知道这个网络包要去的地方。于是,对着这个国家吼一声,谁是目标 IP 啊?目标服务器就会回复一个 MAC 地址。网络包过关后,通过这个 MAC 地址就能找到目标服务器。
- 目标服务器发现 MAC 地址对上了,取下 MAC 头来,发送给操作系统的网络层。发现 IP 也对上了,就取下 IP 头。IP 头里会写上一层封装的是 TCP 协议,然后将其交给传输层,即TCP层。在这一层里,对于收到的每个包,都会有一个回复的包说明收到了。这个回复的包绝非这次下单请求的结果,例如购物是否成功,扣了多少钱等,而仅仅是 TCP 层的一个说明,即收到之后的回复。当然这个回复,会沿着刚才来的方向走回去,报个平安。因为一旦出了国门,西行路上千难万险,如果在这个过程中,网络包走丢了,例如进了大沙漠,或者被强盗抢劫杀害怎么办呢?因而到了要报个平安。
- 如果过一段时间还是没到,发送端的 TCP 层会重新发送这个包,还是上面的过程,直到有一天收到平安到达的回复。这个重试绝非你的浏览器重新将下单这个动作重新请求一次。对于浏览器来讲,就只发送了一次下单请求,TCP 层不断自己闷头重试。除非 TCP 这一层出了问题,例如连接断了,才轮到浏览器的应用层重新发送下单请求。
- 当网络包平安到达 TCP 层之后,TCP 头中有目标端口号,通过这个端口号,可以找到电商网站的进程正在监听这个端口号,假设一个 Tomcat,将这个包发给电商网站。博客
- 电商网站处理逻辑
image - 电商网站的进程得到 HTTP 请求的内容,知道了要买东西,买多少。往往一个电商网站最初接待请求的这个 Tomcat 只是个接待员,负责统筹处理这个请求,而不是所有的事情都自己做。例如,这个接待员要告诉专门管理订单的进程,登记要买某个商品,买多少,要告诉管理库存的进程,库存要减少多少,要告诉支付的进程,应该付多少钱,等等。
- 那么,如何告诉相关的进程呢?往往通过 RPC 调用,即远程过程调用的方式来实现。远程过程调用就是当告诉管理订单进程的时候,接待员不用关心中间的网络互连问题,会由 RPC 框架统一处理。RPC 框架有很多种,有基于 HTTP 协议放在 HTTP 的报文里面的,有直接封装在 TCP 报文里面的。
- 当接待员发现相应的部门都处理完毕,就回复一个 HTTPS 的包,告知下单成功。这个 HTTPS 的包,会像来的时候一样,经过千难万险到达你的个人电脑,最终进入浏览器,显示支付成功。
07.熟知Http请求的过程
- HTTP通信机制是在一次完整的HTTP通信过程中,Web浏览器与Web服务器之间将完成下列7个步骤:
- 建立TCP连接
- 在HTTP工作开始之前,Web浏览器首先要通过网络与Web服务器建立连接,该连接是通过TCP来完成的,该协议与IP协议共同构建 Internet,即著名的TCP/IP协议族,因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议,根据规则, 只有低层协议建立之后才能,才能进行更层协议的连接,因此,首先要建立TCP连接,一般TCP连接的端口号是80。
- Web浏览器向Web服务器发送请求行
- 一旦建立了TCP连接,Web浏览器就会向Web服务器发送请求命令。例如:GET /sample/hello.jsp HTTP/1.1。
- Web浏览器发送请求头
- 浏览器发送其请求命令之后,还要以头信息的形式向Web服务器发送一些别的信息,之后浏览器发送了一空白行来通知服务器,它已经结束了该头信息的发送。
- Web服务器应答
- 客户机向服务器发出请求后,服务器会客户机回送应答, HTTP/1.1 200 OK ,应答的第一部分是协议的版本号和应答状态码。
- Web服务器发送应答头
- 正如客户端会随同请求发送关于自身的信息一样,服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。
- Web服务器向浏览器发送数据
- Web服务器向浏览器发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
- Web服务器关闭TCP连接
- 一般情况下,一旦Web服务器向浏览器发送了请求数据,它就要关闭TCP连接,然后如果浏览器或者服务器在其头信息加入了这行代码:Connection:keep-alive。TCP连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。
- 总结:建立TCP连接->发送请求行->发送请求头->(到达服务器)发送状态行->发送响应头->发送响应数据->断TCP连接