摘自百度百科:
超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
通过以上这些步骤,就完成了一次完整的http请求
当我们在浏览器中输入一个地址,按下回车后,浏览器获取到的是一个字符串。浏览器此时要对这个地址进行解析,获取协议,主机,端口,路径等信息。
URL的一般格式为(手记会自动过滤尖括号,所以只能上传图片了):
例如:
http://www.imooc.com/article/draft/id/430 这个网址缺少了一些东西,端口号,用户名,密码,query和flag都没有。这些东西都是非必须的,甚至协议、路径都可以不要,最简洁的方式为imooc.com,浏览器会对一些默认的东西进行补齐。例如:互联网url默认端口号为80,浏览器默认补齐功能会补齐协议http,有些还会直接在域名前面补上www。所以实际上,即使我们输入的是imooc.com,然而实际访问的却是http://www.imooc.com。
第一步地址解析中我们已经获取到服务器的域名。此时就需要将域名换成对应的ip地址,这就是dns解析。dns解析分为以下几个步骤:
这里面有几点需要关注:
<1>、DNS在进行区域传输的时候使用TCP协议,其它时候则使用UDP协议;
<2>、全球只有十三台逻辑根服务器,为什么是十三台,请参考https://www.zhihu.com/question/22587247?answer_deleted_redirect=true。其中任何一次解析成功就返回对应的ip地址。
第二步获取到了ip,此时直接通过ip寻址找到ip对应的服务器,然后通过arp协议找到服务器的mac地址。
这里有几点需要注意:
A类地址:一个字节(8位)的网络地址和三个字节的主机地址。地址范围为:1.0.0.0~126.255.255.255。
B类地址:二个字节的网络地址和二个字节的主机地址。地址范围为:128.0.0.0~191.255.255.255。
C类地址:三个字节的网络地址和一个字节的主机地址。地址范围为:192.0.0.0~223.255.255.255。
D类地址:D类地址用于多点广播(Multicast),D类IP地址第一个字节以“lll0”开始,它是一个专门保留的地址。地址范围为:224.0.0.0~239.255.255.255。
E类地址:E类IP地址 以“llll0”开始,为将来使用保留。地址范围为:240.0.0.0~255.255.255.254。,255.255.255.255用于广播地址。
其中缺失了两部分,一个是0开头的,“0”表示该地址是本地主机,不能传送。一个是127开头的,127开头的是网卡自身,常用于测试。这里为什么是十进制的数字,为什么中间有‘.’,其实这都是为了方便人类而人为加上去的。转化为计算机语言就是二进制的,每一个字节八位,八位二进制能表示的最大数字就是255,这样ip地址就齐全了。可能有些人还发现ip地址为 10.170.8.61/23 ,这里涉及到局域网、保留地址和子网掩码。这里的意思是,前23位表示为该台主机的网络地址,该网络有 2^(32-23) = 512台主机。具体就不展开讲了,涉及的内容太深,太多。感兴趣的可以参考https://www.zhihu.com/question/56895036
ip寻址主要有两种方式,一种是同一网段,一种是不同网段。要判断两个IP地址是不是在同一个网段,就将它们的IP地址分别与子网掩码做与运算,得到的结果一网络号,如果网络号相同,就在同一子网,否则,不在同一子网。
同一网段的情况:
主机A和主机B,首先主机A通过本机的hosts表或者wins系统或dns系统先将主机B的计算机名 转换为Ip地址,然后用自己的 Ip地址与子网掩码计算出自己所出的网段,比较目的主机B的ip地址与自己的子网掩码,发现与自己是出于相同的网段,于是在自己的ARP缓存中查找是否有主机B 的mac地址,如果能找到就直接做数据链路层封装并且通过网卡将封装好的以太网帧发送有物理线路上去:如果arp缓存中没有主机B的的mac地址,主机A将启动arp协议通过在本地网络上的arp广播来查询主机B的mac地址,获得主机B的mac地址厚写入arp缓存表,进行数据链路层的封装,发送数据。
不同网段的情况:
不同的数据链路层网络必须分配不同网段的Ip地址并且由路由器将其连接起来。和上面一样,主机A发现和主机B不在同一个网段,于是主机A将知道应该将次数据包发送给自己的缺省网关,即路由器的本地接口。主机A在自己的ARP缓存中查找是否有缺省网关的MAC地址,如果能够找到就直接做数据链路层封装并通过网卡 将封装好的以太网数据帧发送到物理线路上去,如果arp缓存表中没有缺省网关的Mac地址,主机A将启动arp协议通过在本地网络上的arp广播来查询缺省网关的mac地址,获得缺省网关的mac地址后写入arp缓存表,进行数据链路层的封装,发送数据。数据帧到达路由器的接受接口后首先解封装,变成ip数据包,对ip 包进行处理,根据目的Ip地址查找路由表,决定转发接口后做适应转发接口数据链路层协议帧的封装,并且发送到下一跳路由器,次过程继续直至到达目的的网络与目的主机。整个过程有点像dns解析,只是dns服务器换成了下一跳路由器,udp编程了tcp,其他差别不大。
简述一下,第三步我们找到了目标ip,并获得了服务器ip的mac地址。此时浏览器就会请求和服务器连接,用来传输数据。tcp 是稳定双向面向连接的,断开时也会分两边分别断开。面向连接不是说tcp一个双方一直开着的通道,而是维持一个连接的状态,让它看起来有连接。
第四步已经建立了连接,此时就要发送数据了。浏览器会对请求进行包装,包装成请求报文。请求报文的格式如下:
起始行:如 GET / HTTP/1.0 (请求的方法 请求的URL 请求所使用的协议)
头部信息:User-Agent Host等成对出现的值
主体
请求头部和主体之间有一个回车换行。如果是get请求,则没有主体部分,post请求有主体部分。当然里面还有些请求头部比较重要
浏览器请求报文到达服务器之后,服务器接口会对请求报文进行处理,执行接口对应的代码,处理完成后响应客户端。由于http是无状态的,正常情况下,客户端收到响应后就会直接断开连接,然后一次http请求就完成了。但是http1.0有一个keep-alive的请求字段,可以在一定时间内不断开连接(有时时间甚至很长)。http1.1直接就默认开启了keep-alive选项。这导致了一个后果是服务器已经处理完了请求,但是客户端不会主动断开连接,这就导致服务器资源一直被占用。这时服务器就不得不自己主动断开连接,而主动断开连接的一方会出现TIME_WAIT,占用连接池,这就是产生SYN Flood攻击的原因。
此时有三种处理方式,第一是客户端主动断开连接,第二是服务器主动断开连接,第三是对tcp连接经行设置。第一种情况,如果服务器返回的数据都有确定的content-length属性,或者客户端知道服务器返回的内容终止,则客户端主动断开连接。第二种情况,服务器可以通过设置一个最大超市时间,可以主动断开tcp连接。第三种情况,调整t三个tcp参数,第一个是:tcp_synack_retries 可以用他来减少重试次数;第二个是:tcp_max_syn_backlog,可以增大syn连接数;第三个是:tcp_abort_on_overflow 处理不过来干脆就直接拒绝连接了。
其实你心里有疑问,这一步有什么好说的。其实这里面有很多需要注意的点。浏览器发出请求时,请求报文如下:
你需要关注一个报文头--accept。accept代表发送端(客户端)希望接受的数据类型,这是浏览器自动封装的请求头。如果服务器返回的content-type是accept中的任何一个,浏览器都能解析,并直接展示在网页上。如果服务器返回的content-type是其他类型,此时浏览器有三种处理状态:
浏览器能直接处理很多种格式,并直接呈现在网页中,并不限于accept中规定的字段,具体有哪些,就需要自己亲自动手试试了。
附上一张content-type常用对照表地址:http content-type常用对照表
获取到服务器相应之后,浏览器会根据相应的content-type字段对响应字符串进行解析。能够解析并成功解析就显示,能够解析但解析错误就报错,不能解析就下载。由于浏览器采用至上而下的方式解析,所以会先解析html,直到遇到外部样式和外部脚本。这时会阻塞浏览器的解析,外部样式和外部脚本(在没有async、defer属性下)会并行加载,但是外部样式会阻塞外部脚本的执行,dom加载完毕,js脚本执行成功后dom树构建完成(DOMContentLoaded),之后就加载dom中引用的图片等静态资源。(参考文章地址:http://blog.csdn.net/u014168594/article/details/52196460)
即:
在外部样式执行完毕后,css附着于DOM,创建了一个渲染树(渲染树是一些被渲染对象的集)。每个渲染对象都包含了与之对应的计算过样式的DOM对象,对于每个渲染元素来说,位置都经过计算,所以这里被叫做“布局”。然后将“布局”显示在浏览器窗口,称之为“绘制”。
1.情况一:如果脚本是动态加载,则不会影响DOMContentLoaded时间的触发,浏览器会等css加载完成后再加载图片,因为不确定图片的样式会如何。
最后页面加载完成,页面load。
总结一下:运维人员需要处理页面缓存、cdn及keep-alive引起的连接池占用等问题;后端人员需要处理代码逻辑、缓存、传输优化、报错等问题;前段人员需要做好前端性能优化和配合运维、后端做好借口调试,缓存处理等问题。所以无论是前端、后台、运维都应该很清楚整个流程中的每一步,才能在配合时,得心应手,才能在出现问题时,快速准确的定位问题解决问题,才能在需要优化时,迅速完整的给出方案。
ps:本篇文章之介绍了http事物,如果是https事物,整个流程和http事物大致相同,唯一不同的就是在http层和tcp层多了一个ssl层,所以在发送数据前会有个ssl握手,发送数据时会有个ssl层的加密。ssl涉及到的东西也不少,例如ssl握手,加密技术,还要ssl层到底在tcp/ip四层协议哪一层的问题等等
客户端请求消息客户端发送一个HTTP请求到服务器的请求消息包括以下格式:
请求行(request line)
、请求头部(header)
、空行
和请求数据
四个部分组成
下图给出了请求报文的一般格式
HTTP响应也由四个部分组成,分别是:状态行
、消息报头
、空行
和响应正文
客户端和服务器发现对方一段时间没有活动,就可以主动关闭连接。不过,规范的做法是,客户端在最后一个请求时,发送Connection: close,明确要求服务器关闭TCP连接。客户端和服务器发现对方一段时间没有活动,就可以主动关闭连接。不过,规范的做法是,客户端在最后一个请求时,发送Connection: close,明确要求服务器关闭TCP连接
HTTP/1.1 的持久连接和管道机制允许复用TCP连接,在一个TCP连接中,也可以同时发送多个请求,但是所有的数据通信都是按次序完成的,服务器只有处理完一个回应,才会处理下一个回应。比如客户端需要A、B两个资源,管道机制允许浏览器同时发出A请求和B请求,但服务器还是按照顺序,先回应A请求,完成后再回应B请求,这样如果前面的回应特别慢,后面就会有很多请求排队等着,这称为"队头阻塞(Head-of-line blocking)"
HTTP/2以Google发布的SPDY协议为基础,于2015年发布。它不叫HTTP/2.0,因为标准委员会不打算再发布子版本了,下一个新版本将是HTTP/3。HTTP/2协议只在HTTPS环境下才有效,升级到HTTP/2,必须先启用HTTPS。HTTP/2解决了HTTP/1.1的性能问题,主要特点如下:
HTTPS可以说是安全版的HTTP,HTTPS基于安全SSL/TLS(安全套接层Secure Sockets Layer/安全传输层Transport Layer Security)层,即在传统的HTTP和TCP之间加了一层用于加密解密的SSL/TLS层。HTTP默认使用80端口,HTTPS默认使用443端口。
不使用SSL/TLS的HTTP通信,所有信息明文传播,会带来三大风险:
窃听风险:第三方可以获取通信内容;篡改风险:第三方可以修改通信内容;冒充风险:第三方可以冒充他人进行通信。SSL/TLS协议是为了解决这三大风险而设计的,以期达到:
信息加密传输:第三方无法窃听;校验机制:一旦被篡改,通信双方会立刻发现;身份证书:防止身份被冒充。
SSL/1.0:1994年NetScape公司设计,未发布;SSL/2.0:1995年NetScape公司发布,但存在严重漏洞;SSL/3.0:1996年NetScape公司发布,得到大规模应用;TLS/1.0:1999年互联网标准化组织(ISOC)接替NetScape公司,发布SSL的升级版TLS/1.0;TLS/1.1:2006年发布;TLS/1.2:2008年发布;TLS/1.2修订版:2011年发布。目前,应用最广泛的是 TLS/1.0 和 SSL/3.0,且主流浏览器已实现 TLS/1.2的支持。
SSL/TLS的基本思路是公钥加密法:客户端先向服务器索要并验证公钥,然后用公钥加密传输来协商生成“对话秘钥”(非对称加密),双方采用“对话秘钥”进行加密通信(对称加密)。
通信过程如下:
前四步称为握手阶段,用于客户端和服务端建立连接和交换参数。整个通信过程可用下图所示:
缓存:只要在HTTP头中使用特定命令,就可以缓存HTTPS;延迟:HTTP耗时 = TCP握手;HTTPS耗时 = TCP握手 + SSL握手。SSL握手耗时大概是TCP握手耗时的三倍左右。
https://www.zhihu.com/tardis/sogou/art/43787334
https://blog.csdn.net/weixin_38150378/article/details/79408886
https://www.runoob.com/http/http-tutorial.html
https://blog.csdn.net/alexwll/article/details/82287737