目录
一、什么是HTTP
HTTP是 Hyper Text Transfer Protocol(超文本传输协议)的缩写。HTTP协议位于TCP/IP协议栈的应用层。
HTTP是一个客户端和服务器端请求和应答的标准,主要用于从万维网(即WWW
,全称 World Wide Web
)服务器传输超文本到本地浏览器之间的请求数据和响应数据的协议。客户端通过使用网页浏览器或者其它的工具发起一个HTTP请求到服务器上指定端口(默认端口为80
),服务器在收到请求之后,返回响应内容(文本、图片等)。
HTTP协议是基于TCP协议来进行数据传输的。
二、HTTP的版本
HTTP协议已经演化出了很多版本,它们中的大部分都是向下兼容的。客户端在请求的开始告诉服务器它采用的协议版本号,而后者则在响应中采用相同或者更早的协议版本。现在大多使用的都是1.1
版本。
-
1.0版本: HTTP 协议非常老的标准,为了提高系统的效率,HTTP 1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接,服务器不跟踪每个客户也不记录过去的请求。正式因为这种特性造成了一些性能上的缺陷。
-
1.1版本: 克服了HTTP 1.0的缺陷,HTTP 1.1支持持长连接(HTTP/1.1的默认模式使用带流水线的持久连接),在一个TCP连接上可以传送多个HTTP请求和响应,减少了建立和关闭连接的消耗和延迟。同时还增加更多的请求头和响应头来改进和扩充HTTP 1.0的功能(如POST请求头字段等)。
-
2.0版本: 2015年5月作为互联网标准正式发布。主要新增如下特性:多路复用,二进制分帧,首部压缩,服务端推送。
三、HTTP请求报文
HTTP请求报文由3部分组成(请求行+请求头+请求体):
1、请求行
由3部分组成,分别为:请求方法、URL、协议版本。之间由空格分隔
请求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及扩展方法,当然并不是所有的服务器都实现了所有的方法,部分方法即便支持,处于安全性的考虑也是不可用的。
请求方法:
(1)GET请求: 将请求参数追加在url后面,不安全; url长度限制get请求方式数据的大小 ; 没有请求体; 一般的HTTP请求大多都是GET。
(2)POST请求: 请求参数在请求体处,较安全;请求数据大小没有显示;只有表单设置为method=“post”才是post请求,其他都是get请求;常见get请求:地址栏直接访问、<a href="">、<img src="">等;
(3)HEAD请求: HEAD跟GET相似,不过服务端接收到HEAD请求时只返回响应头,不发送响应内容。所以,如果只需要查看某个页面的状态时,用HEAD更高效,因为省去了传输页面内容的时间。
(4)DELETE请求: 删除某一个资源。
(5)OPTIONS请求:用于获取当前URL所支持的方法。若请求成功,会在HTTP头中包含一个名为“Allow”的头,值是所支持的方法,如“GET, POST”。
(6)PUT请求: 把一个资源存放在指定的位置上。本质上来讲, PUT和POST极为相似,都是向服务器发送数据,但它们之间有一个重要区别,PUT通常指定了资源的存放位置,而POST则没有,POST的数据存放位置由服务器自己决定。
(7)TRACE请求: 回显服务器收到的请求,主要用于测试或诊断。
(8)CONNECT请求:CONNECT方法是HTTP/1.1协议预留的,能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。
协议版本的格式为:HTTP/主版本号.次版本号,常用的有HTTP/1.0和HTTP/1.1
URL:文件位置。HTTP规范将更通用的概念URI作为其资源标识符,但是实际上,HTTP应用程序处理的只是URI的URL子集
2、请求头部
请求头部为请求报文添加了一些附加信息,由“名/值”对组成,每行一对,名和值之间使用冒号分隔
常见请求头如下:
请求头 | 说明 |
Host | 接受请求的服务器地址,可以是IP:端口号,也可以是域名 |
User-Agent | 发送请求的应用程序名称 |
Connection | 指定与连接相关的属性,如Connection:Keep-Alive |
Accept-Charset | 通知服务端可以发送的编码格式 |
Accept-Encoding | 通知服务端可以发送的数据压缩格式 |
Accept-Language | 通知服务端可以发送的语言 |
请求头部的最后会有一个空行,表示请求头部结束,接下来为请求正文,这一行非常重要,必不可少
3、请求正文
可选部分,比如GET请求就没有请求正文
四、HTTP响应报文:
HTTP响应报文主要由状态行、响应头部、响应正文3部分组成
1、状态行
由3部分组成,分别为:协议版本,状态码,状态码描述,之间由空格分隔
状态代码为3位数字,200~299的状态码表示成功,300~399的状态码指资源重定向,400~499的状态码指客户端请求出错,500~599的状态码指服务端出错(HTTP/1.1向协议中引入了信息性状态码,范围为100~199)
这里列举几个常见的:
状态码 | 说明 |
200 | 响应成功 |
301 | 永久重定向,搜索引擎将删除源地址,保留重定向地址 |
302 | 暂时重定向,重定向地址由响应头中的Location属性指定(JSP中Forward和Redirect之间的区别) 由于搜索引擎的判定问题,较为复杂的URL容易被其它网站使用更为精简的URL及302重定向劫持 |
304 | 缓存文件并未过期,还可继续使用,无需再次从服务端获取 |
400 | 客户端请求有语法错误,不能被服务器识别 |
403 | 服务器接收到请求,但是拒绝提供服务(认证失败) |
404 | 请求资源不存在 |
500 | 服务器内部错误 |
2、响应头部
与请求头部类似,为响应报文添加了一些附加信息
常见响应头部如下:
响应头 | 说明 |
Server | 服务器应用程序软件的名称和版本 |
Content-Type | 响应正文的类型(是图片还是二进制字符串) |
Content-Length | 响应正文长度 |
Content-Charset | 响应正文使用的编码 |
Content-Encoding | 响应正文使用的数据压缩格式 |
Content-Language | 响应正文使用的语言 |
五、HTTP协议的特点
1.支持客户/服务器模式。
2.简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小,因而通信速度很快。
3.灵活:HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type(Content-Type是HTTP包中用来表示内容类型的标识)加以标记。
4.无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
5.无状态:HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快。
六、Cookie和Session机制:无状态下的会话
产生背景:
HTTP 是一个无状态协议,无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。即我们给服务器发送 HTTP 请求之后,服务器根据请求,会给我们发送数据过来,但是,发送完,不会记录任何信息。这意味着每个请求都是独立的。
缺点:缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次请求会传输大量重复的内容信息。
优点:在服务器不需要先前信息时它的应答就较快。解放了服务器,每一次请求“点到为止”不会造成不必要连接占用。
客户端与服务器进行动态交互的 Web 应用程序出现之后,HTTP 无状态的特性严重阻碍了这些应用程序的实现,毕竟交互是需要承前启后的,简单的购物车程序也要知道用户到底在之前选择了什么商品。于是,两种用于保持 HTTP 连接状态的技术就应运而生了,一个是 Cookie,而另一个则是 Session。
Cookie:
Cookie可以保持登录信息到用户下次与服务器的会话,换句话说,下次访问同一网站时,用户会发现不必输入用户名和密码就已经登录了(当然,不排除用户手工删除Cookie)。而还有一些Cookie在用户退出会话的时候就被删除了,这样可以有效保护个人隐私。
Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再次请求该网站时,浏览器把请求的网址连同该Cookie一同发送给服务器。服务器检查该Cookie,以此来辨别用户状态。服务器还可以根据需要修改Cookie的内容。
Cookies 最典型的应用是判定注册用户是否已经登录网站,用户可能会得到提示,是否在下一次进入此网站时保留用户信息以便简化登录手续,这些都是 Cookies 的功用。另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品,这些信息都会写入 Cookies,以便在最后付款时提取信息。
Session:
Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,Session保存在服务器上。客户端浏览器访问服务器的时候,服务端把客户端信息以某种形式记录在服务器上,这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。
提示:Session的使用比Cookie方便,但是过多的Session存储在服务器内存中,会对服务器造成压力。
Session的生命周期:Session生成后,只要用户继续访问,服务器就会更新Session的最后访问时间,并维护该Session。用户每访问一次,无论是否读写Session,服务器都认为该用户的Session活跃(active)了一次。为防止内存溢出,服务器会把长时间没有活跃的Session从内存中删除。这个时间就是Session的超时时间。如果超过了超时时间没有访问过服务器,Session就自动失效。
Session需要使用Cookie作为识别标志。服务器先给客户端浏览器发送一个名为JSESSIONID的Cookie,他的值为该Session的id(也就是HTTPSession.getId()的返回值)。Session依据Cookie来识别是否为同一用户。
cookie和session的比较:
Cookie机制是通过检查客户身上的“通行证”来确定客户身份,Session机制是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案,客户来访的时候只需要查询客户档案表就可以了。
1、数据存放位置不同:
cookie数据存放在客户的浏览器上,session数据放在服务器上。
2、安全程度不同:
cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
session的sessionID是放在cookie里,要想攻破session的话,第一要攻破cookie。攻破cookie后,你要得到 sessionID,sessionID是要有人登录,或者启动session_start才会有,你不知道什么时候会有人登录。第二,sessionID是加密的,第二次session_start的时候,前一次的sessionID就没有用了,session过期时sessionid也会失效,想在短时间内攻破加了密的 sessionID很难。session是针对某一次通信而言,会话结束session也就随着消失了,而真正的cookie存在于客户端硬盘上的一个文本文件,谁安全很显然了。
3、性能使用程度不同:
session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。
4、数据存储大小不同:
单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie,而session则存储与服务端,浏览器对其没有限制。
5、会话机制不同
session会话机制:session会话机制是一种服务器端机制,它使用类似于哈希表的结构来保存信息。
cookies会话机制:cookie是服务器存储在本地计算机上的小块文本,并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端,浏览器解析cookie并将其保存为本地文件,该文件自动将来自同一服务器的任何请求绑定到这些cookie。
七、长连接和短连接:无连接下的多次请求
HTTP是无连接的,无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。(早期这么做的原因是每个客户端(即浏览器)与服务器之间交换数据的间歇性较大(即传输具有突发性、瞬时性),并且网页浏览的联想性、发散性导致两次传送的数据关联性很低,大部分通道实际上会很空闲、无端占用资源。因此 HTTP 的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接,以尽快将资源释放出来服务其他客户端。)
短连接是指HTTP每次请求都会建立TCP连接,响应结束则断开连接。
随着时间的推移,网页变得越来越复杂,里面可能嵌入了很多图片,这时候每次访问图片都需要建立一次 TCP 连接就显得很低效。
长连接是指HTTP利用TCP的保活机制,复用TCP连接,即在一次TCP连接中实现多次HTTP请求和响应。
HTTP的长连接和短连接本质上是TCP长连接和短连接。
HTTP流水线技术:在一个TCP连接内(长连接),多个HTTP请求可以并行,下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。
八、如果传输的文件过大怎么办
服务器上返回的资源文件比较大,比如有些 js 文件大小可能就有几兆。文件过大就会影响传 输的效率,同时也会带来带宽的消耗。怎么办呢?
1. 常见的手段是,对文件进行压缩,减少文件大小。那压缩和解压缩的流程怎么实现呢? 首先服务端需要能支持文件的压缩功能,其次浏览器能够针对被压缩的文件进行解压缩。浏览器可以指定 Accept-Encoding 来高速服务器我当前支持的编码类型 Accept-Encoding:gzip,deflate 那服务端会根据支持的编码类型,选择合适的类型进行压缩。常见的编码方式有:gzip/deflate
2. 分割传输 在传输大容量数据时,通过把数据分割成多块,能够让浏览器逐步显示页面。这种把实体主体分块的功能称为分块传输编码(Chunked Transfer Coding)。