[读书笔记]HTTP协议基础
一 HTTP协议
- HTTP协议用于客户端和服务器端之间的通信。通过请求和响应的交换达成通信。
- HTTP协议规定,请求从客户端发出,最后服务器端响应该请求并返回。即,肯定是先从客户端开始建立通信的,服务器端在没有接收到请求之前不会发送响应。
- 请求报文是由请求方法,请求URI,协议版本,可选的请求首部字段和内容实体构成的。
- 响应报文由协议版本,状态码,用以解释状态码的原因短语,可选的响应首部字段以及实体主体构成。
二 HTTP是不保存状态的协议
- HTTP是一种不保存状态,即无状态协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。即,在HTTP这个级别,协议对于发送给的请求和响应都不做持久化处理。
- 使用HTTP协议,每当有新的请求发送时,就会有对应的新响应产生。协议本身并不保留之前一切的请求和响应报文的信息。这是为了更快地处理大量的事物,确保协议的可伸缩性,而特意把HTTP协议设计成如此简单的。
- 然而,随着Web的不断发展,因无状态而导致业务处理变得棘手的情况增多了。比如,用户登录到一家购物网站,即使他跳转到该站的其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能够掌握是谁发出的请求,需要保存用户的状态。
- HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能,于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管理状态了。
三 告知服务器意图的HTTP方法
- GET,获取资源(1.0和1.1)
GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。一般来说GET方法应该只用于数据的读取,而不应当用于会产生副作用的非幂等的操作中。它期望的应该是而且应该是安全的和幂等的。这里的安全指的是,请求不会影响到资源的状态。
- POST,传输实体主体(1.0和1.1)
POST请求会 向指定资源提交数据,请求服务器进行处理,如:表单数据提交、文件上传等,请求数据会被包含在请求体中。POST方法是非幂等的方法,因为这个请求可能会创建新的资源或/和修改现有资源。
- PUT,传输文件(1.0和1.1)
PUT请求会身向指定资源位置上传其最新内容,PUT方法是幂等的方法。通过该方法客户端可以将指定资源的最新数据传送给服务器取代指定的资源的内容。但是,由于HTTP/1.1的PUT方法自身不带验证机制,任何人都可以上传文件,存在安全性问题,因此一般的Web网站不使用该方法。
- HEAD,获取报文首部(1.0和1.1)
HEAD方法与GET方法一样,都是向服务器发出指定资源的请求。但是,服务器在响应HEAD请求时不会回传资源的内容部分,即:响应主体。这样,我们可以不传输全部内容的情况下,就可以获取服务器的响应头信息。HEAD方法常被用于客户端查看服务器的性能。
- DELETE,删除文件(1.0和1.1)
DELETE请求用于请求服务器删除所请求URI所标识的资源。DELETE请求后指定资源会被删除,DELETE方法也是幂等的。但是,HTTP/1.1的DELETE方法本身与PUT方法一样不带验证机制,所以一般的Web网站也不使用DELETE方法。
- OPTIONS,询问支持的方法(1.1)
OPTIONS请求与HEAD类似,一般也是用于客户端查看服务器的性能。 这个方法会请求服务器返回该资源所支持的所有HTTP请求方法,该方法会用'*'来代替资源名称,向服务器发送OPTIONS请求,可以测试服务器功能是否正常。JavaScript的XMLHttpRequest对象进行CORS跨域资源共享时,就是使用OPTIONS方法发送嗅探请求,以判断是否有对指定资源的访问权限。
- TRACE,追踪路径(1.1)
TRACE请求服务器回显其收到的请求信息,该方法主要用于HTTP请求的测试或诊断。但是TRACE方法本来就不怎么常用,再加上它容易引发XST(Cross-Site Tracing,跨站追踪)攻击,通常就更不会用到了。
- CONNECT,要求用管道方式连接代理(1.1)
CONNECT方法是HTTP/1.1协议预留的,能够将连接改为管道方式的代理服务器。主要使用SSL(Secure Sockets Layer,安全套接字)和TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经管道传输。
- PATCH,资源更新(1.1)
PATCH方法出现的较晚,它在2010年的RFC 5789标准中被定义。PATCH请求与PUT请求类似,同样用于资源的更新。二者有以下两点不同:1.PATCH一般用于资源的部分更新,而PUT一般用于资源的整体更新。2.当资源不存在时,PATCH会创建一个新的资源,而PUT只会对已在资源进行更新。

四 持久连接节省通信量
- HTTP协议的初始版本中,每进行一次HTTP通信就要断开一次TCP连接。以当年的通信情况来看,因为都是些容量很小的文本传输,所以即使这样也没有多大问题。
- 可随着HTTP的普及,文档中包含大量图片的情况多了起来。每次的请求都会造成无谓的TCP连接和断开,增加通信量的开销。
- 为了解决上述TCP连接的问题,HTTP/1.1和一部分的HTTP/1.0想出了持久连接(HTTP keep-alive或HTTP connection reuse)的方法。持久连接的特点是,只要任意一端没有明确提出断开连接,则保持TCP连接状态。
- 持久连接的好处在于减少了TCP连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载。另外, 减少开销的那部分时间,使HTTP请求和响应能够尽早的结束,这样web页面的显示速度也就相应的提高了。
- 在HTTP/1.1中,所有的连接默认都是持久连接,但在HTTP/1.0内并未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接,但服务器端不一定能够支持持久连接。毫无疑问,除了服务器端,客户端也需要支持持久连接。
五 管道技术
- 持久连接使得多数请求以管道方式发送成为可能。从前发送请求后需要等待并收到响应,才能发送下一个请求。管道技术出现后,不用等待响应亦可直接发送下一个请求。这样就能够做到同时并行发送多个请求,而不需要一个接一个地等待响应了。
- 当请求一个包含10张图片的HTML web页面,与挨个连接相比,用持久连接可以让请求更快结束。而管道技术则比持久连接还要快。请求数越多,时间差就越明显。
六 使用cookie的状态管理
- HTTP协议是无状态协议,他不对之前发生过的请求和响应的状态进行管理。也就是说,无法根据之前的状态进行本次的请求处理。
- 假设要求登录认证的web页面本身无法进行状态管理,那么每次跳转新的页面就要再次登录,或者要在每次请求报文中附加参数来管理登录状态。
- 无状态协议也有他的优点。由于不必保存状态,自然可减少服务器的CPU以及内存资源的消耗。从另一侧面来说,也正是因为HTTP协议本身是非常简单的,所以才会被应用在各种场景里。
- 保留无状态协议这个特征的同时又要解决类似的矛盾问题,于是引入了cookie技术。cookie技术通过在请求和响应报文中写入cookie信息来控制客户端的状态。
- cookie会根据从服务器端发送的响应报文内的一个叫做Set-Cookie的首部字段信息,通知客户端保存cookie。当下次客户端再往服务器发送请求的时候,客户端会自动在请求报文中加入cookie值后发送出去。服务器端发现客户端发送过来的cookie后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前的状态信息。