HTTP详解
HTTP协议初相识
HTTP协议(超文本传输协议),将超文本标记语言(HTML)从Web服务器传送到客户端,属于应用层协议,目前使用的HTTP协议基本都是基于TCP协议的。 超文本:文本中存在超链接可以进行跳转 HTTP协议的几次版本更迭: HTTP0.9 -> HTTP1.0 -> HTTP1.1(目前所用最多的版本) -> HTTP2.0 -> HTTP3.0(仍处于概念阶段,基于QUIC协议)
TCP的三次握手:
- 第一次连接:客户端发送带有SYN标志(同步序列编号,是TCP/IP建立连接时使用的握手信号)的连接请求报文段,然后进入SYN-SEND状态,等待服务端的确认。
- 第二次连接:服务端接收到客户端的SYN报文后会发送一个ACK信息进行确认,同时会发送一个SYN报文给客户端,SYN和ACK会放到一个报文段中,一并发送给客户端,此时服务端进入SYN_RECV状态。
- 第三次连接:客户端收到后,会向服务器端发送一个ACK确认报文段,发送完毕后,客户端和服务端都进入ESTABLISHED状态,三次握手完成。
三次握手的目的是确认双方的收发能力正常,更具体可以理解为双方都知道自己和对方的收发功能正常,三次恰好能完美地验证彼此收发功能是否正常。
HTTP处理过程概述: DNS查询以获得IP地址->三次握手建立TCP连接->发送HTTP请求
HTTP协议再入门
HTTP协议的特点:
- 使用C/S模式,由客户端向服务器发出请求,服务器做出应答
- 简单快速,客户端发送请求时,只需要传送请求方法和路径
- 灵活,可以传输多种类型的数据对象,传输内容类型由content-type标识
- 无连接,限制每次连接只处理一个请求,即服务器处理完客户的请求并收到应答后会断开连接,后续发展出长连接(keep-alive)
- 无状态,如果后续处理需要之前发送的信息,则需要重新传输,后续发展出了cookie和session部分解决了这个问题
补充一下URL和URI的区别 URI可以分为URL和URN,URN确定了东西的身份,URL提供了找到它的方式 URL是URI的一种,但并非所有URI都是URL URI和URL最大的区别在于"访问机制" www.baidu.com是URI,加上 http:// 后才能称为URL
HTTP请求报文常用参数分析
HTTP请求报文由以下四部分组成:请求行,请求头,空行,请求体(GET请求没有)
响应行由请求方法、URL和HTTP协议版本3个字段组成,它们用空格分隔。比如:GET /index.html HTTP/1.1
请求头的参数:
Accept:浏览器端可以接受的媒体类型,比如text/html表示接受html文档,如果服务器没有此类型资源可以返回,会返回406错误。ACCEPT:*/*表示浏览器可以处理所有类型
Accept-Encoding:浏览器申明自己接收的编码方式,通常指定压缩方法,是否支持压缩,支持什么压缩方法(gzip,deflate)
Accept-Language:申明自己接收的语言,比如zh-CN表示中文。
Connection:表示连接状态,当该值为keep-alive时表示底层的TCP连接不会断开,客户端再次访问时会继续使用这条已建立的连接,参数值为close时,则表示需要重新建立TCP连接
Host:表示服务器的Internet主机和端口号
Referer:告诉服务器客户端是由哪个页面链接过来的
User-Agent:告诉Http服务器,客户端使用的浏览器类型和操作系统
Content-Type:说明报文内对象的媒体类型,比如:text/html和image/png
HTTP响应报文与请求报文类似,大多数参数代表意义相同,分为响应行,响应头,空行,响应体四部分. 响应行由协议版本,状态码和状态描述三部分组成,比如:HTTP/1.1 200 OK
HTTP请求方法详解:
- GET方法:用来请求访问已被URI标识的资源,提交数据量小,提交的信息直接包含在URL当中,也可以用来提交表单等数据,但一般并不这么做
- POST方法:POST方法的主要目的一般并非获取内容,而是提交数据,提交的数据被放在报文的请求体中,克服了GET方法中无法保密和数据量太小等缺点
- PUT方法:与POST方法十分类似,用于向服务器发送数据取代指点的原有内容,因为安全性上的缺陷,基本不用
- HEAD方法:类似于GET方法,只不过返回的结果没有具体内容,用于获取报头
- DELETE方法:请求删除指定资源,因为缺少一些验证机制,现在在一个网站中发现可以使用DELETE方法基本就是发现了漏洞
- OPTIONS方法:用来查询针对请求URI指定资源支持的方法
- TRACE方法:用来回显服务器收到的请求,用于测试和诊断,易引起攻击,很少使用
- CONNECT方法:开启一个客户端与所请求资源之间的通道,用在HTTP代理
HTTP状态码详解:
- 1XX:表示请求已被接受但是需要继续处理,这类响应是临时响应,只包含响应行和部分响应头信息,以空行结束,很少使用
- 2XX:表示成功,即请求已经成功被服务器接收,理解,接受 常用的有:200 OK(接受并已处理),202 Accepted(接受但并未处理),206 Partial Content(请求部分内容)
- 3XX:表示重定向,重定向目标会在本次响应的Location域中指明 常用的有:301 Moved Permanently(永久移动),302 Found(临时跳转),304 Not Modified(资源尚未修改,请使用缓存)
- 4XX:表示请求错误 常用:400 Bad Request,401 Unauthorized,403 Forbidden,404 Not Found
- 5XX:表示服务器错误 常用:500 Internal Server Error,502 Bad Gateway(充当网关或代理服务器,从远端服务器接收到一个无效请求)
HTTP的状态管理:cookie和session
Cookie是保存在客户端的,实际上是一小段文本信息,客户端请求服务器时会将cookie发送出去,服务器检查cookie以辨认用户状态
Session则是保存在服务器端的,当用户首次访问网站时服务器会创建一个Session和相应的Session ID,并将Session ID发给用户,Session ID信息通常保存在用户本地的Cookie中
Cookie和Session都是有有效期的,Cookie的有效期一般更长
HTTP协议结构和通信原理
URL编码:
在发送GET请求时,需要将参数经过编码后发送出去,这里就用到了URL编码,即将非ASCII字符(一些具有特殊含义的保留字除外)使用UTF-8编码,并在前面加%
保留字符:
常见的URL编码字符:
- %26代表&
- %3d代表=
- %25代表%
- %20代表空格
HTTP身份认证: HTTP的身份认证方式主要有四种:BASIC认证,DIGEST认证,SSL客户端认证,以及基于表单的认证
- BASIC认证:发送base64编码的用户名和密码,基本没有安全性可言
- DIGEST认证:服务器端向客户端发送一次性的随机数(质询码),客户端发送摘要(md5)以及由质询码计算出的响应码,这种认证方式一定程度上解决了BASIC的问题,但仍然不够安全 前两种认证因为安全性较低的缘故,基本已经不再使用
- SSL认证,一般来说,SSL 客户端认证不仅依靠证书完成认证,一般会和基于表单认证组合形成一种双因素认证来使用,即认证过程中不仅需要密码这一个因素,还需要申请认证者提供其他特有信息作为另一个因素,与其组合使用的认证方式。第一个认证因素的 SSL 客户端证书用来认证客户端计算机,另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后,就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
- 基于表单验证:并非由HTTP协议中定义的,客户端会以表单的形式向服务器Web应用发送登录信息,按登录信息的验证结果认证。
HTTP的长连接和短连接:
HTTP是基于请求/响应模式的,因此只要服务端给了响应,本次连接就结束了 HTTP的长连接和短连接本质上是TCP连接的长连接和短连接,在HTTP/1.0协议下,默认使用的是短连接,而从HTTP/1.1开始,默认使用长连接,使用长连接的情况下,Connection参数值为keep-alive,可以在一定时间内保持连接
短连接:建立连接->一次传输数据->关闭连接 长连接:建立连接->保持连接进行多次数据传输->关闭连接 在现代访问一个网页时,服务器端要发送html,css,js,图片音频等等许多数据,如果每次都用短连接,无疑是消耗巨大的,这也是为什么HTTP/1.1之后默认长连接的原因
HTTP代理: HTTP代理的原理并不复杂,客户端将请求发完代理服务器,代理服务器转发请求到服务器,服务器返回响应给代理服务器,代理服务器再将响应内容发给客户端 代理的作用:
- 抓包,常见的比如Fiddler,抓包的原理就是代理
- FQ,利用代理服务器可以绕过墙
- 匿名访问,跳板
- 过滤器,拦截部分请求
HTTP中介之网关:
网关是在采用不同体系结构或协议的网络之间进行互通时,用于提供协议转换、路由选择、数据交换等网络兼容功能的设施,直白一点说就是一个翻译器 常见的网关类型:
- (HTTP/*) 服务器端Web网关 用HTTP协议与客户端进行通信,用其他协议与服务器端进行通讯
- (HTTP/HTTPS) 服务器端安全网关 将来自客户端的数据加密后发送到服务器
- (HTTPS/HTTP) 客户端安全加速器网关
- 资源网关
HTTP缓存:
HTTP中有关缓存的参数: 缓存的目标一般是css,js,image等不容易变化的资源 Cache-Control:请求/响应头,缓存控制字段,no-store所有内容不缓存,no-cache缓存但是浏览器使用缓存之前,会请求服务器判断是否为最新,max-age请求缓存后多少秒内不会再次请求,s-maxage同上但是只对cdn有效,public客户端和代理服务器(CDN)都可以缓存,private只有客户端可以缓存 Last-Modified:响应头,资源最新修改时间,由服务器告诉浏览器 if-Modified-Since:请求头,资源最新修改时间,由浏览器告诉服务器,会和Last-Modified进行对比 Etag:响应头,资源标识,由服务器告诉浏览器 if-None-Match:与Etag为一对,进行对比 优先级是Etag>Last-Modified
CDN缓存: CDN是构建在网络之上的内容分发网络,依靠部署在各地的服务器,均衡中心服务器的负载,有了它我们在请求的时候可以不直接请求中心服务器而是请求CDN服务器获取内容,大大减轻了服务器的负担,同时可以使得用户能够就近获取所需内容,提高了用户访问速度
HTTP内容协商机制:
- 客户端驱动 客户端发起请求,服务器发送可选项目,客户端做出选择后发送第二次请求
- 服务器驱动 服务器检查客户端请求头决定选择哪个版本的资源
- 透明协商 某个中间设备代表客户端进行协商 相关参数: Accept:告诉服务器需要的资源类型 Accept-Language:告知需要哪种语言的资源 Accept-Charset:告知服务器发送哪种字符集的资源 Accept-Encoding:告知服务器采用何种编码方式 Content-Type,Content-Language,Content-Type,Content-Encoding描述了服务器发送资源的参数,对应上述4个参数
HTTP断点续传和多线程下载: 断点续传过程:
- 客户端已经下载512k文件,总大小为1024k,故发送请求,请求体中Range:bytes=512000-,意为从512k位置开始到文件尾
- 服务器接收到请求,从文件512k位置开始传输,并在响应头中标识Content-Range:bytes 512000-某数字/1024000,且状态码不为200,而是206(请求部分内容)
我们在视频网站看视频的时候,就用到了断点续传功能,在看视频时点F12,可看到客户端在不断使用Ajax技术发送请求,获取一段段的视频内容并在网页上播放
HTTP和HTTPS
HTTP传输是明文的,相当于在网络上裸奔,传输信息容易被窃取,篡改 HTTPS可以理解为HTTP+TLS,其实就是在HTTP和TCP两者间加了一个中间层,将HTTP的内容进行加密后进行传输,接收方经过解密获取内容 TLS协议本身的内容十分复杂,用到了对称加密,非对称加密,数字证书等等,提供了内容加密(防止窃取),身份认证(由数字证书保证,保证用户访问的是想访问的网站),数据完整性(防止数据被篡改) TLS协议也可以用在邮件发送上,即SMTP,POP3、IMAP三个协议上
HTTPS的握手流程(首次):
建立TCP连接进行http通信->302跳转到https->再次建立tcp连接以支持https->tls第一次握手(完成加密套件的协商和CA的确认)->tls第二次握手(CA域名解析,ocsp请求响应等)->进行通信
HSTS策略: 但是当网站传输协议从 HTTP 到 HTTPS 之后,数据传输真的安全了吗?由于用户习惯,通常准备访问某个网站时,在浏览器中只会输入一个域名,而不会在域名前面加上 http:// 或者 https://,而是由浏览器自动填充,当前所有浏览器默认填充的都是http://。一般情况网站管理员会采用 302 跳转的方式由 HTTP 跳转到 HTTPS,但是这个过程总使用到 HTTP 因此容易发生劫持,受到第三方的攻击。
这个时候就需要用到 HSTS(HTTP 严格安全传输),网站可以选择使用HSTS策略,来让浏览器强制使用HTTPS与网站进行通信
HTTP的扩展与提升
HTTP协议是只能由客户端向服务端发送请求的,在一些要求低延时高刷新率的情况下需要客户端进行Ajax轮询或者长轮询,会消耗大量系统资源,为了改进这一缺陷,websocket协议便出现了
WebSocket协议在2008年诞生,2011年成为国际标准,所有浏览器都已经支持了,默认情况下,Websocket协议使用80端口,而运行在TLS之上时,默认使用443端口。与HTTP和HTTPS是一样的
WebSocket的特点:
- 真正的全双工方式,客户端和服务端地位平等,都可以发起请求
- 减少通讯量,不用发送大量重复的header
- 复用性高
流程:建立TCP连接->发送一次HTTP request要求切换协议->切换成websocket协议进行通信
SPDY协议:
针对HTTP协议的单路连接,一端请求,头部冗余等缺陷,SPDY协议出现了,这个协议在HTTP协议的基础上改进了HTTP协议,有以下优点:
- 多路复用 请求优化
- 支持服务器推送技术
- 压缩了 HTTP 头
- 强制使用 SSL 传输协议
- 增加请求优先级,优先传输重要数据
在HTTP2未推出之前,SPDY在业界内已经有一定的市场占用量,它的成绩是不可忽视的
SPDY的后续:HTTP2.0出现
HTTP/2的特点:
- 多路复用 (Multiplexing) 多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接,HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧,这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
- 二进制分帧 在二进制分帧层中, HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码 ,其中 HTTP1.x 的首部信息会被封装到 HEADER frame,而相应的 Request Body 则封装到 DATA frame 里面。
- 首部压缩
- 服务端推送 服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中,服务器可以对客户端的一个请求发送多个响应。
未来科技:HTTP/3
HTTP2的缺陷:
- 队头阻塞 当丢包发生时,HTTP2的表现甚至不如HTTP/1.1
- 握手延迟大 这是由TCP握手的繁琐导致的
由于HTTP2的缺陷大部分其实是由TCP协议的问题导致的,但是我们又无法将TCP协议做出修改(因为TCP协议一般由系统实现,且TCP的应用非常广泛),为了解决这一问题,谷歌转投UDP协议,并在UDP协议上实现了QUIC协议作为实现HTTP3的协议
HTTP3的优势:
- 来回通信延迟低
- 无队头阻塞的多路复用
- 前向纠错,丢包很少的情况下不必重传
HTTP安全机制与攻击
- 验证机制安全:用户登录,找回密码,多段登录
- 会话验证机制:cookie构造安全,cookie失效机制漏洞,cookie加密
- SQL注入漏洞,网站一般会将用户提交的用户名密码等参数构造成SQL查询语句查询数据库,用户如果发送一些特殊字符串(比如古老的’or’ 1=1)给服务器,可能在数据库查询阶段构造出特殊的查询语句引发信息泄露
- XSS(跨站脚本攻击):反射型XSS,存储型XSS,DOM型XSS(不涉及服务器,前两种则涉及服务器)
- CSRF(跨站请求伪造攻击)也被称为one-click attack,跟跨网站脚本相比,XSS 利用的是用户对指定网站的信任,CSRF 利用的是网站对用户网页浏览器的信任。