图解HTTP读书笔记
图解HTTP读书笔记(二)
通过请求和响应的交换达成通信
请求由客户端发出,而服务器回复响应。
请求报文:由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成,如下图所示。
响应报文:由协议版本、状态码(表示请求成功或失败的数字代码)、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成,如下图所示。
以空行分隔响应首部字段和资源实体的主体。
HTTP是不保存状态的协议
- HTTP是无状态协议,自身不对请求和响应之间的通信状态进行保存。对于HTTP而言,协议对于发送过的请求或响应都不做持久化处理。
- 优点:更快速地处理大量事务,确保协议的可伸缩性。
- 缺点:也会因无状态而导致业务处理变得棘手。如,用户登录到一家购物网站,即使他跳转到该站的其他页面后,也需要能继续保持用户登录状态。
- 因而引进Cookie技术,来实现保持状态的功能。
请求URI定位资源,当客户端请求访问资源而发送请求时,URI需要将做为请求报文中的请求URI包含在内,指定请求URI的方式有很多种,可以为完整的请求URI也可以在首部字段中写明网络域名或IP地址。可以使用*来代替URI,OPTIONS * HTTP/1.1 :查询HTTP服务器支持的HTTP方法中类。
HTTP方法
客户端向请求URI指定的资源发送请求报文时,第一行为请求行,包含了方法字段。
方法的作用在于,可以指定请求的资源按期望产生某种行为,方法中有GET、POST和HEAD等。
方法名区分大小写,注意要用大写字母。
GET:获取资源
GET方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。如果请求的是文本,则保持原样返回;如果是类似CGI(通用网关接口)那样的程序,则返回经过执行后的输出结果。
POST:传输实体主体
POST方法用来传输实体的主体。虽然用GET方法可以传输实体的主体,但一般不用GET方法进行传输,而是用POST方法。
POST 主要目的不是获取资源,而是传输存储在内容实体中的数据。
GET与POST的区别
标准答案:
- GET在浏览器回退时是无害的,而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark,而POST不可以。
- GET请求会被浏览器主动cache,而POST不会,除非手动设置。
- GET请求只能进行url编码,而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的,而POST么有。
- 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
- GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
- GET参数通过URL传递,POST放在Request body中。
GET 和 POST 的请求都能使用额外的参数。但是 GET 的参数是以查询字符串(名称/值对)出现在 URL 中,且只请求一次;而 POST 的参数存储在HTTP request body中,请求两次。
GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
GET 的传参方式相比于 POST 安全性较差,因为 GET 传的参数在 URL 中是可见的,可能会泄露私密信息。并且 GET 只支持 ASCII 字符,如果参数为中文则可能会出现乱码,而 POST 支持标准字符集。
下图比较了GET 与 POST方法。
PUT:传输文件
用来传输文件。它要求在请求报文的主体中包含文件内容,然后保存到请求URI指定的位置。
由于PUT方法自身不带验证机制,任何人都可以上传文件,存在着安全性问题,因此一般WEB网站不适用该方法。
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16
<p>New File</p>
HEAD:获得报文首部
与GET方法一样,只是不返回报文主体部分。
用于确认URI的有效性及资源更新的日期时间等。
DELETE:删除文件
用来删除文件,与PUT的功能相反。
按请求URI删除指定的资源。
DELETE方法与PUT方法一样不带验证机制,因此存在安全问题。
DELETE /file.html HTTP/1.1
OPTIONS:询问支持的方法
用来查询针对请求URI指定的资源支持的方法,即查询指定的 URL 能够支持的方法。
会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。
TRACE:追踪路径
让Web服务器端将之前的请求通信环回给客户端,即服务器会将通信路径返回给客户端。。
发送请求时,在Max-Forwards首部字段中填入数值,每经过一个服务器就将该数字减1,当数值刚好减为0时就停止继续传输,最后接收的请求的服务器则返回状态码200 OK的响应。
客户端可以通过TRACE方法查询发送出去的请求是怎样被加工修改/篡改的。
通常不会使用 TRACE,并且它容易受到 XST 攻击(Cross-Site Tracing,跨站追踪),因此更不会去使用它。
CONNECT:要求用隧道协议链接代理
要求在与代理服务器通信时建立隧道,实现用隧道协议进行TCP通信。主要使用SSL(Secure Sokets Layer,安全套接字)和TLS(Transport Layer Security,传输层安全)协议把通信内容加密后经网络隧道传输。
CONNECT 方法的格式:
CONNECT 代理服务器名:端口号 HTTP版本
持久连接节省通信量
持久连接
为了解决HTTP初始版本中,每进行一次HTTP通信就要断开一次TCP连接,HTTP/1.1和部分HTTP/1.0提出了持久连接(或HTTP keep-alive),特点是:只要通信双方任意一端没有明确提出断开连接,则继续保持TCP连接状态。
优点:减少了 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载。
在 HTTP/1.1 中,所有的连接默认都是持久连接,在HTTP的头部信息中会有Connection: Keep-alive属性
管线化
背景:持久连接使得多数请求以管线化的方式发送成为可能。
特点:管线化技术出现后,不用等待响应亦可直接发送下一个请求(从前发送请求后需要等待并接收响应)。
这样就可以做到同时并行发送多个请求,而无需一个接一个的等待响应。
使用Cookie管理状态
1、引入原因:
- 无状态优点:减少服务器cpu及内存资源的消耗;
- 缺点:HTTP是无状态协议,无法根据之前的状态进行本次的请求处理。登录认证的web页面不能管理状态,每次跳转需要在请求报文添加参数来管理信息;
- 如果让服务器管理全部客户端状态则会成为负担,保留无状态协议这个特征的同时又要解决类似的矛盾问题,于是引入了 Cookie 技术。
2、Cookie特点:
Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。
- Cookie会根据从服务器端发送的响应报文内的一个叫Set-Cookie的首部字段,通知客户端保存Cookie,当下次客户端再次往该服务器发送请求时,客户端会自动在请求报文中加入Cookie值后发送出去。
- 服务器收到客户端发送过来的Cookie后,会去检查是从哪个客户端发来的请求,然后对比服务器上的记录,得到之前的状态信息。