自己动手创建一个公司网站,wordpress 连接池,招聘网站做销售怎么样,汽车之家车报价大全什么是HTTP协议
定义
Http协议即超文本传送协议 (HTTP-Hypertext transfer protocol) 。 它定义了浏览器#xff08;即万维网客户进程#xff09;怎样向万维网服务器请求万维网文档#xff0c;以及服务器怎样把文档传送给浏览器。从层次的角度看#xff0c;HTTP是面向即万维网客户进程怎样向万维网服务器请求万维网文档以及服务器怎样把文档传送给浏览器。从层次的角度看HTTP是面向transaction-oriented)应用层协议它是万维网上能够可靠地交换文件包括文本、声音、图像等各种多媒体文件的重要基础。并且详细地规定了客户端浏览器与服务器之间互相通信的规则。 http主要方法 http状态码
收到请求消息之后 Web 服务器会对其中的内容进行解析 通过 URI和方法来判断“对什么”“进行怎样的操作” 并根据这些要求来完成自己的工作 然后将结果存放在响应消息中。 在响应消息的开头有一个状态码它用来表示操作的执行结果是成功还是发生了错误。
HTTP 状态码由三个十进制数字组成第一个十进制数字定义了状态码的类型。
响应分为五类信息响应(100–199)成功响应(200–299)重定向(300–399)客户端错误(400–499)和服务器错误 (500–599) HTTP状态码列表: 版本变迁
1991年HTTP/0.9支持GET请求方式获取文本数据比如HTML且不支持请求头响应头无法向服务器传递太多信息。
1996年HTTP/1.0支持POST、HEAD等请求方法支持请求头、响应头等支持更多种数据类型不再局限于文本数据浏览器的每次请求都需要与服务器建立一个TCP连接请求处理完成后立即断开TCP连接。比如当前HTML在被浏览器解析时发现有一个图片资源就是再次建立TCP连接然后关闭TCP连接。
1997年HTTP/1.1 支持PUT,DELETE请求采用持久连接多个HTTP请求可以共用一个TCP连接。 这版协议使用最广泛。
2015HTTP/2.0
2018HTTP/3.0 HTTP报文格式
请求报文
HTTP请求报文第一行是请求行其后继的行叫做首部行。每行由一个回车和换行符结束最后一行再附加一个回车换行符。一个请求报文至少为一行。 请求行由请求方法、URL(包含参数)和协议版本组成 请求头部由多个key-value值组成 空行请求报文使用空行将请求头部和请求数据分隔 请求数据GET方法没有携带数据POST方法会携带一个body
例 响应报文 状态行由协议版本、状态码和状态值组成 响应头由多个key-value值组成 空行响应报文使用空行将响应头和响应体分隔 响应体响应数据在上面是一段HTML
例 HTTP传输原理
概述
以在浏览器中输入www.baidu.com为例 对www.baidu.com这个网址进行DNS域名解析得到对应的IP地址 根据这个IP找到对应的服务器发起TCP的三次握手 建立TCP连接后发起HTTP请求 服务器响应HTTP请求浏览器得到html代码 浏览器解析html代码并请求html代码中的资源如js、css、图片等先得到html代码才能去找这些资源 浏览器对页面进行渲染呈现给用户 服务器关闭关闭TCP连接
详细步骤 DNS解析
a首先会搜索浏览器自身的DNS缓存缓存时间比较短大概只有1分钟且只能容纳1000条缓存
b如果浏览器自身的缓存里面没有找到那么浏览器会搜索系统自身的DNS缓存
c如果还没有找到那么尝试从 hosts文件里面去找
d在前面三个过程都没获取到的情况下就递归地去域名服务器去查找 TCP连接建立三次握手
拿到域名对应的IP地址之后User-Agent一般指浏览器会以一个随机端口1024端口65535向服务器的WEB程序常用的有httpdnginx等的80端口。这个连接请求原始的http请求经过TCP/IP4层模型的层层封包到达服务器端后这中间有各种路由设备局域网内除外进入到网卡然后是进入到内核的TCP/IP协议栈用于识别连接请求解封包一层一层地剥开还有可能要经过Netfilter防火墙属于内核的模块的过滤最终达到WEB程序最终建立了TCP/IP的连接 发起HTTP请求(建立连接后)
HTTP请求报文由三部分组成请求行请求头、空格、请求正文 服务器响应http请求浏览器得到html代码
HTTP响应也由三部分组成状态行响应头空格消息体
状态行包括协议版本、状态码、状态码描述 浏览器解析html代码并请求html代码中的资源
浏览器拿到html文件后就开始解析其中的html代码遇到js/css/image等静态资源时就向服务器端去请求下载会使用多线程下载每个浏览器的线程数不一样这个时候就用上keep-alive特性了建立一次HTTP连接可以请求多个资源下载资源的顺序就是按照代码里面的顺序但是由于每个资源大小不一样而浏览器又是多线程请求资源所以这里显示的顺序并不一定是代码里面的顺序。 浏览器对页面进行渲染呈现给用户
最后浏览器利用自己内部的工作机制把请求的静态资源和html代码进行渲染渲染之后呈现给用户浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树然后解析CSS文件构建渲染树等到渲染树构建完成后浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂涉及到两个概念:reflow(回流)和repain(重绘)。
DOM节点中的各个元素都是以盒模型的形式存在这些都需要浏览器去计算其位置和大小等这个过程称为relow;当盒模型的位置,大小以及其他属性如颜色,字体,等确定下来之后浏览器便开始绘制内容这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的尤其是在移动设备上它会破坏用户体验有时会造成页面卡顿。所以我们应该尽可能少地减少reflow和repain。JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行JS有可能修改DOM结构意味着JS执行完成前后续所有资源的下载是没有必要的所以JS是单线程会阻塞后续资源下载。 服务器关闭关闭TCP连接
一般情况下一旦Web服务器向浏览器发送了请求数据它就要关闭TCP连接然后如果浏览器或者服务器在其头信息加入了这行代码
Connection:keep-alive
TCP连接在发送后将仍然保持打开状态于是浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间还节约了网络带宽 什么是http2 http2 二进制格式1.x是文本协议然而2.0是以二进制帧为基本单位可以说是一个二进制协议将所有传输的信息分割为消息和帧并采用二进制格式的编码一帧中包含数据和标识符使得网络传输变得高效而灵活 多路复用2.0版本的多路复用多个请求共用一个连接多个请求可以同时在一个TCP连接上并发主要借助于二进制帧中的标识进行区分实现链路的复用 头部压缩2.0版本使用HPACK算法对头部header数据进行压缩从而减少请求的大小提高效率这个非常好理解之前每次发送都要带相同的header显得很冗余2.0版本对头部信息进行增量更新有效减少了头部数据的传输 服务端推送在2.0版本允许服务器主动向客户端发送资源这样在客户端可以起到加速的作用
http2的重要改动 降低延迟多路复用使用多路复用来降低高延迟的问题多路复用指的是使用Stream让多个请求可以共享一个TCP连接解决HOL Blockinghead of line blocking的问题同时提升带宽利用率。 HTTP1.1中keep-alive用的是http pipelining本质上也是multiplexing但是具体实现方案不理想 主流浏览器都默认禁止pipelining也是因为HOL阻塞问题导致。 服务端推送HTTP1.X的推送都是半双工所以在2.0是实现真正的服务端发起请求的全双工另外在WebSocket在这一块大放异彩 请求优先级针对引入多路复用的一个兜底方案多路复用使用多个Stream的时候容易单请求阻塞问题也就是前文所说的和管道连接一样的问题SPDY通过设置优先级的方式让重要请求优先处理比如页面的内容应该先进行展示之后再加载CSS文件美化以及加载脚本互动等等实际减少用户不会在等待过程中关闭页面的几率 Header压缩HTTP1.X的header很多时候都是多余的所以2.0 会自动选择合适的压缩算法自动压缩请求加快请求和响应速度。 什么是http3
这个版本是划时代的改变在HTTP3.0中将弃用TCP协议改为使用基于UDP协议的QUIC协议实现。需要注意QUIC是谷歌提出的和2.0 的SPDY 一样QUIC指的是快速 UDP Internet 连接既然使用了UDP那么也意味着网络可能存在丢包和稳定性下降谷歌当然不会让这样的事情发生所以他们提出的QUIC既可以保证稳定性又可以保证SSL的兼容因为HTTP3上来就会和TLS1.3一起上线。 基于这些原因制定网络协议IETF的人马上基本都同意了QUIC的提案太好了又能白嫖成果于是HTTP3.0 就这样来了。但是这只是最基本的草案后续的讨论中希望QUIC可以兼容其他的传输协议最终的排序如下IP / UDP / QUIC / HTTP。另外TLS有一个细节优化是在进行连接的时候浏览器第一次就把自己的密钥交换的素材发给服务器这样进一步缩短了交换的时间。
为什么要使用http3
为什么HTTP3.0要从协议根本上动刀那是因为HTTP/2虽然解决了HTTP协议无法多路复用的问题但是没有从TCP层面解决问题具体的TCP问题体现如下 RTTRTT是Round Trip Time的缩写简单来说就是通信一来一回的时间。 队头阻塞HTTP/2 多个请求跑在一个 TCP 连接中如果此时序号较低的网络请求被阻塞那么即使序列号较高的 TCP 段已经被接收了应用层也无法从内核中读取到这部分数据从 HTTP 视角看就是多个请求被阻塞了并且页面也只是加载了一部分内容 TCP 和 TLS 握手时延缩短TCL 三次握手和 TLS 四次握手共有 3-RTT 的时延HTPT/3最终压缩到1 RTT难以想象有多快 连接迁移需要重新连接移动设备从 4G 网络环境切换到 WIFI 时由于 TCP 是基于四元组来确认一条 TCP 连接的那么网络环境变化后就会导致 IP 地址或端口变化于是 TCP 只能断开连接然后再重新建立连接切换网络环境的成本高
所以后续谷歌的研究方向转为研究QUIC实际上就是改良UDP协议来解决TCP协议自身存在的问题
为什么http3选择UDP协议
这就引出另一个问题为什么3.0有很多协议可以选择为什么使用UDP通常有下面的几个点 基于TCP 协议的设备很多兼容十分困难 TCP是Linux内部的重要组成修改非常麻烦或者说压根不敢动 UDP本身无连接的没有建立连接和断连的成本 UDP数据包本身就不保证稳定传输所以不存在阻塞问题属于爱要不要 UDP改造相对其他协议改造成本低很多 HTTP协议真的是无状态的么
仔细阅读HTTP1.x和HTTP/2以及HTTP3.0三个版本的对比其实会发现HTTP无状态的定义偷偷发生了变化的为什么这么说
我们需要弄清一个概念那就是Cookie和Session虽然让HTTP实现了“有状态”但是其实这和HTTP协议本身的概念是没有关系的。
Cookie和Session的出现根本目的是保证会话状态本身的可见性两者通过创立多种独立的状态“模拟”用户上一次的访问状态但是每一次的HTTP请求本身并不会依赖上一次HTTP的请求单纯从广义的角度看待其实所有的服务都是有状态的但是这并不会干扰HTTP1.X本身无状态的定义。
此外HTTP协议所谓的无状态指的是每个请求是完全独立的在1.0备忘录定义中也可以看出一次HTTP连接其实就是一次TCP连接到了HTTP1.1实现了一个TCP多个HTTP连接依然是可以看作独立的HTTP请求。
说了这么多其实就是说HTTP1.X在不靠Cookie和Session扶着的时候看做无状态是对的就好比游戏里面的角色本身的数值和武器附加值的对比武器虽然可以让角色获得某种状态但是这种状态并不是角色本身特有的而是靠外力借来的。
然而随着互联网发展到了HTTP/2和HTTP3之中HTTP本身拥有了“状态”定义比如2.0关于HEADER压缩产生的HPACK算法需要维护静态表和动态表3.0还对HPACK算法再次升级为QPACK让传输更加高效。
所以总结就是严谨地来说HTTP1.X是无状态的在Cookie和Session的辅助下实现了会话访问状态的保留。到了HTTP/2之后HTTP是有状态的 因为在通信协议中出现了一些状态表来维护双方重复传递的Header字段减少数据传输。
