HTTP-点开浏览器输入网址背后发生的那点事

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
简介: 前言 Internet最早来源于美国国防部ARPANet,1969年投入运行,到现在已有很长一段路了,各位想要了解发展史可以百度下,这里就不多说了。 现如今当我们想要获取一些资料,首先是打开某个浏览器,在地址栏输入地址,想要的信息出现在你的面前。

 

前言

Internet最早来源于美国国防部ARPANet,1969年投入运行,到现在已有很长一段路了,各位想要了解发展史可以百度下,这里就不多说了。

现如今当我们想要获取一些资料,首先是打开某个浏览器,在地址栏输入地址,想要的信息出现在你的面前。

大家有没有想过输入地址就能返回给你想要的信息是怎么实现的呢?

下面就来简单说下它的实现流程,不过在这之前先来了解下HTTP基本概念如下

HTTP基本概念

在这引用http://www.zsythink.net/archives/76

这是一篇为初学者准备的文章,所以作者会尽量从基础出发,尽量细致的描述每一个细节,以求让初学者不会一头雾水,有一定基础的同学就不用看了,以免浪费你的时间。

 

假设博主今天春心荡漾,想要访问一些不可描述的小网站,于是,博主悄悄的打开了浏览器,在浏览器的地址栏中输入了一个小网站的网址,

此处假设这个小网站的网址为 www.zsythink.net ,当博主输入了这个网址以后,浏览器中就显示了博主想要看到的内容,整个过程如下图所示。

   201803

那么,浏览器返回给我们的内容是怎么产生的呢?

这些内容肯定不是凭空产生的,而是有人为我们准备了这些内容,当我们在浏览器的地址栏中输入网址以后,

这些提前准备好的内容即可返回到浏览器中,以便有需要的人能够查看到这些内容,

而查看这些内容的人就是我们平常所说的"客户",客户往往会通过"客户端程序"去请求、查看这些内容,

我们最常使用的客户端程序就是浏览器了,所以,在之后的http相关的文章中,

如果没有特别说明,我们所说的"客户端"就是指"浏览器",我们使用客户端去查看我们想要的内容,

而提供内容的一端被称为"服务端",当作为客户时,我们需要在电脑上安装客户端软件(即浏览器),

通过客户端软件查看我们想要的内容,而作为提供内容的人,也需要在服务端的计算机上安装对应的软件,

才能为我们提供服务,而服务端的计算机就是我们常说的"服务器",安装在服务器上的、为我们提供内容的软件被称之为"web服务器软件"。

 

所以,综上所述,我们可以了解到如下名词

注:如下名词的解释均针对http而言,在后面的文章中我们会解释什么是http,此处不用纠结

客户端:客户端通常是指浏览器,比如谷歌浏览器、火狐浏览器、IE等,浏览器安装在客户使用的电脑上,所以,在描述http时,客户端通常也代指那些安装了浏览器的电脑。

服务端:服务端通常是指那些安装了"web服务软件"的计算机,这些服务端的计算机被称为服务器。

 

没错,聪明如你一定想到了,说白了,客户端与服务端就是两台电脑,分别安装了不同的软件,服务端提供内容,客户端查看内容。201801

 

所以,当我们访问网页时,大致的过程如下图所示。

 

201802

 

客户端与服务端既然能够通讯,那么证明它们之间一定是通过某种方法进行沟通的,就像你我之间能够进行沟通一样。

举例说明

你和我都说汉语,所以,当我说"苹果"这个词的时候,你就会想到一种水果,或者想到一个手机品牌,

但是当我对一个美国人说"苹果"两个字时,他可能并不能理解我在说什么,因为他可能听不懂汉语,

如果我想要对他表达"苹果"这个词,我需要说"Apple",他才会明白我说的是什么,当我跟你聊天时,我们都说汉语,

当两个美国人聊天时,他们都说英语,这样,才能有效的沟通,总之,如果想要能够顺畅的沟通,

沟通双方都必须遵守相同的协议,我们可以把汉语理解成一种协议,把英语也理解成一种协议,

只要沟通双方都遵守相同的协议,双方就能够顺畅的沟通,只要沟通双方都遵守相同的协议,双方就能够理解对方想要做什么。

当然,之所以拿汉语、英语举例,是为了让初学者能够更加容易的理解"协议"这个词,但是请不要错误的以为"协议"就是"语言",

之所以拿语言举例,是为了方便理解,说白了,"协议"可以理解为某种规则或者某种约定,

只要大家都严格按照这种约定行事,世界就会正常的运转,比如"红灯停,绿灯行"也可以理解为一种协议,

比如在马路上都要靠右行驶(在中国),也是一种协议,比如在小饭馆,你给老板人民币,老板给你对应的餐食,

也是一种协议,"协议"的概念稍微有一些抽象,稍微有一些宽泛,此处大概有一个印象即可,在学习的过程中,我们自己就会慢慢的理解它了。

 

客户端与服务端之间,也需要遵守某些相同的协议,才能够顺畅的通讯,细心如你一定注意到了,我说的是"某些"协议,也就是说,双方要遵守的协议不止有一种,它们需要同时遵守多种协议,才能够正常的完成整个通讯过程。

 

比如http协议,刚才已经说过,不同的"层面"中,需要使用不同的协议,http协议就是应用层的一种协议,http协议是什么意思呢?

http是HyperText Transfer Protocol的缩写,HyperText Transfer Protocol译为"超文本传输协议"。

从字面上理解,这种协议是用来传输"超文本"的,我们可以暂且粗暴的将"超文本"理解成我们所谓的"网页"(这样并不准确,但是方便理解),那么,我们可以将http协议理解为一种"网页传输协议"。

一次完整的HTTP请求过程

web服务请求处理步骤

image

HTTP服务通信过程

image

人性化HTTP请求相应图

图片来自:理解Http请求与响应

大致如下

域名解析 --> TCP3次握手 --> 发起http请求 --> 服务器响应http请求并传输数据 –>  浏览器解析并渲染呈现给用户 –> TCP4次挥手

域名解析

当用户在浏览器输入https://www.cnblogs.com/时,浏览器会对此域名或主机进行解析,得到对应的IP地址,那么它时怎么进行域名解析的呢?

1、首先先去本机hosts文件查找此FQDN没有没定义的指向所在的IP地址条目,如果找到,就结束解析

2、如果没有找到,回去浏览器器本身DNS缓存里去寻找,找打结束解析

3、没有找到,会去本机配置的首选DNS服务器查询,一般这是三大运营商提供的,通过UTP53端口发起请求,这个请求是递归查询,DNS服务器收到请求后,会查询自身缓存,找到条目并且没有过期,就返回给用户,结束解析。如果没有找到,它会去找根服务器,全球13个根服务器(根服务器地址本机DNS服务器内置),询问根服务器(你知不知道一个域名叫“www.cnblogs.com”的IP地址),根回复说,(我不知道此域名的IP地址,但我知道com域的IP地址,你去询问它吧),于是运行商提供的DNS服务器就去询问com这个域,(你知不知道一个叫“www.cnblogs.com”域名IP地址),com域回答你说,(我不知道此域名的IP地址,但我知道“cnblogs.com域的IP地址,你去问他吧“),这是运行商DNS服务器,对cnblogs.com域发起请求询问,(你知不知道一个叫”www.cnblogs.com“域的IP地址,它一查,发现此域,就是它负责的,就会对你说,此域是我负责的,它的IP是X.X.X.X这时运行商DNS服务器拿到地址,就会返回客户主机内核,内核再返回给浏览器,到此解析结束,进行下一步。

当然这里面还要涉及到IP –> MAC(物理地址)的解析

TCP3次握手

浏览器拿到域名对应的IP后,会拿一个随机端口向WEB服务程序80端口发起TCP请求链接

image

备注:

SYN(synchronous建立联机)

ACK(acknowledgement 确认)

PSH(push传送)

FIN(finish结束)

RST(reset重置)

URG(urgent紧急)

Sequence number(顺序号码)

Acknowledge number(确认号码)

举例

A : 你好我是A,你能听得到我说话吗?

B : 听到了,我是B,你能听到我说话吗?

A : 可以,听到了

好建立连接,开始聊天!

过程

第一次握手:建立连接,客户端将SYN标记为1,seq标记为x,并将SYN包发送到服务器,并进入SYN_SEND状态,等待服务器确认;

第二次握手:服务器收到SYN,知道客户端要建立链接,同时向客户端也发送一个SYN包(SYN=1)和一个ACK包(ACK=1),随机产生一个数seq=y,ack=x+1(客户端的seq值x加1),来确认客户端的SYN,并进入SYN_RECV;

第三次握手:客户端收到服务器发来的SYN+ACK后,确认ack值,并回复服务器端一个ACK确认,发送完毕后,双方进入ESTABLISHED状态。

三次握手成功后,开始传输数据。

一个完整的三次握手也就是 请求---应答---再次确认

链接建立成功后,就要开始下一步,传输数据

 

HTTP请求相应处理

1、建立TCP连接:

接收或拒绝连接请求

发送请求报文

image

2、接收请求:

接收客户端发来的请求报文中的信息对某资源的一次请求的过程

Web访问响应模型(Web I/O)

1)单进程I/O模型:

启动一个进程处理用户请求,而且一次只处理一个,多个请求被串行响应

2)多进程I/O模型:

并行启动多个进程,每个进程响应一个连接请求

3)复用I/O结构:

启动一个进程,同时响应N个连接请求

实现方法:    多线程模型和事件驱动

      多线程模型: 一个进程生成N个线程,每线程响应一个连接请求

      事件驱动:    一个进程处理N个请求

4)复用的多进程I/O模型:

启动M个进程,每个进程响应N个连接请求,同时接收M*N个请求

3、处理请求:

服务器对请求报文进行解析,并获取请求的资源及请求方法等相关信息,根据方法,资源,首部和可选的主体部分对请求进行处理

image

HTTP常用请求方式,Method
GET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS

4、访问资源:

服务器获取请求报文中请求的资源web服务器,即存放了web资源的服务器,负责向请求者提供对方请求的静态资源,或动态运行后生成的资源

资源放在服务端特定的目录下

备注:通过MAC地址和端口号确定具体的应用程序

5、构建响应报文:

一旦Web服务器识别除了资源,就执行请求方法中描述的动作,并返回响应报文。响应报文中 包含有响应状态码、响应首部,如果生成了响应主体的话,还包括响应主体

image

6、发送响应报文

向客户端回复报文

7、记录日志:

最后,当事务结束时,Web服务器会在日志文件中添加一个条目,来描述已执行的事务

备注:这中间还要涉及到https的建立过程

数据传输完毕就要断开链接了

四次挥手

如图

image

备注:

数据传输完毕后,双方都可释放连接。最开始的时候,客户端和服务器都是处于ESTABLISHED状态,然后客户端主动关闭,服务器被动关闭。

过程

  1. 客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
  2. 服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
  3. 客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
  4. 服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
  5. 客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过(最长报文段寿命)的时间后当客户端撤销相应的TCB后,才进入CLOSED状态。
  6. 服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。

 

问题1-为什么连接的时候是三次握手,关闭的时候却是四次握手?


答:

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,

SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,

所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,

我才能发送FIN报文,因此不能一起发送。故需要四步握手。

问题2-为什么要三次握手

答:

为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

 

网上转载的例子不错:

三次握手:

A:“喂,你听得到吗?”A->SYN_SEND

B:“我听得到呀,你听得到我吗?”应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED

A:“我能听到你,今天balabala……”B->ESTABLISHED

四次挥手:

A:“喂,我不说了。”A->FIN_WAIT1

B:“我知道了。等下,上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2

B:”好了,说完了,我也不说了。”B->LAST_ACK

A:”我知道了。”A->TIME_WAIT | B->CLOSED

A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED

 

参考链接

1、http://www.zsythink.net/archives/76

2、https://blog.csdn.net/qzcsu/article/details/72861891

3、https://zhuanlan.zhihu.com/p/21940234

4、https://www.jianshu.com/p/c1d6a294d3c0?from=jiantop.com

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
JSON JavaScript 前端开发
基于promise用于浏览器和node.js的http客户端的axios
基于promise用于浏览器和node.js的http客户端的axios
75 0
|
28天前
|
存储 缓存 网络协议
计算机网络常见面试题(二):浏览器中输入URL返回页面过程、HTTP协议特点,GET、POST的区别,Cookie与Session
计算机网络常见面试题(二):浏览器中输入URL返回页面过程、HTTP协议特点、状态码、报文格式,GET、POST的区别,DNS的解析过程、数字证书、Cookie与Session,对称加密和非对称加密
|
1月前
|
域名解析 网络协议 前端开发
浏览器输入域名网址访问后的过程详解
1、以91处理网为例,客户端浏览器通过DNS解析到www.91chuli.com,IP地址是202.108.22.5,通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到202.108.22.5,然后通过TCP进行封装数据包,输入到网络层。
51 2
|
3月前
|
缓存 安全 JavaScript
「offer来了」浏览器原理被问懵?5大知识板块巩固你的http知识体系(3.6w字)
该文章系统地整理了前端面试中有关浏览器原理的核心知识点,涵盖HTTP协议、浏览器缓存机制、请求过程及响应状态码等方面,并深入探讨了浏览器是如何解析与渲染页面的完整流程。
「offer来了」浏览器原理被问懵?5大知识板块巩固你的http知识体系(3.6w字)
|
2月前
url重写重定向所有http网址到https网址
url重写重定向所有http网址到https网址
36 4
|
3月前
|
Windows
解决浏览器被 http://www.haohao1.com 劫持问题(第2版)
解决浏览器被 http://www.haohao1.com 劫持问题(第2版)
|
3月前
|
Web App开发 存储 安全
Python编写脚本,打开浏览器输入网址,自动化登陆网站
Python编写脚本,打开浏览器输入网址,自动化登陆网站
110 4
|
4月前
|
缓存 网络协议 安全
揭秘浏览器背后的神秘之旅:一网打尽HTTP请求流程,让你网络冲浪更顺畅!
【8月更文挑战第31天】当在浏览器中输入网址并按下回车键时,一系列复杂的HTTP请求流程随即启动。此流程始于DNS解析,将域名转化为IP地址;接着是与服务器的TCP三次握手建立连接。连接建立后,浏览器发送HTTP请求,其中包含请求方法、资源及版本等信息。服务器接收请求并处理后返回HTTP响应,包括状态码、描述及页面内容。浏览器解析响应,若状态码为200则渲染页面,否则显示错误页。整个流程还包括缓存处理和HTTPS加密等步骤,以提升效率和保障安全。理解该流程有助于更高效地利用网络资源。通过抓包工具如Wireshark,我们能更直观地观察和学习这一过程。
74 4
|
4月前
|
Web App开发
Chrome浏览器导出HTTPS证书
Chrome浏览器导出HTTPS证书
56 0
Chrome浏览器导出HTTPS证书
|
4月前
|
测试技术 持续交付 开发者
Xamarin 高效移动应用测试最佳实践大揭秘,从框架选择到持续集成,让你的应用质量无敌!
【8月更文挑战第31天】竞争激烈的移动应用市场,Xamarin 作为一款优秀的跨平台开发工具,提供了包括单元测试、集成测试及 UI 测试在内的全面测试方案。借助 Xamarin.UITest 框架,开发者能便捷地用 C# 编写测试案例,如登录功能测试;通过 Xamarin 模拟框架,则可在无需真实设备的情况下模拟各种环境测试应用表现;Xamarin.TestCloud 则支持在真实设备上执行自动化测试,确保应用兼容性。结合持续集成与部署策略,进一步提升测试效率与应用质量。掌握 Xamarin 的测试最佳实践,对确保应用稳定性和优化用户体验至关重要。
66 0