文章目录
1. Http特点
1.1 支持c/s模式
Http用于客户端和服务端之间通信
HTTP 协议规定,请求从客户端发出,最后服务器端响应该请求并返回。换句话说,肯定是先从客户端开始建立通信的,服务器端在没有 接收到请求之前不会发送响应。
1.2 无状态
HTTP 是一种不保存状态,即无状态(stateless)协议。
HTTP 协议自 身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个 级别,协议对于发送过的请求或响应都不做持久化处理。
1.3 灵活
HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
1.4 持久连接
在Http1.1使用了持久连接
持久连接的特点是,只要任意一端没有明确提出断开连接,则保持 TCP 连接状态。
持久连接旨在建立1次TCP连接后进行多次请求和响应的交互。
持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销,减轻了服务器端的负载。另外,减少开销的那部分时间,使 HTTP 请求和响应能够更早地结束,这样 Web 页面的显示速度也就相 应提高了。
在 HTTP/1.1 中,所有的连接默认都是持久连接,但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接, 但服务器端不一定能够支持持久连接。毫无疑问,除了服务器端,客 户端也需要支持持久连接。
管线化 : 持久连接使得多数请求以管线化(pipelining)方式发送成为可能。从 前发送请求后需等待并收到响应,才能发送下一个请求。管线化技术 出现后,不用等待响应亦可直接发送下一个请求。
这样就能够做到同时并行发送多个请求,而不需要一个接一个地等待 响应了。
1.5 使用Cookie的状态管理
Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息,通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时,客户端会自动在请求报文中加入 Cookie 值后发送出 去。
服务器端发现客户端发送过来的 Cookie 后,会去检查究竟是从哪一 个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前 的状态信息。
2. 用户在浏览器输入地址后发生的网络访问事件
- 浏览器分析链接指向页面URL
- 浏览器向DNS请求解析www.baidu.com的IP地址
- 域名系统DNS解析出百度服务器地址IP为192.168.22.11
- 浏览器与服务器建立TCP连接(服务端的地址为192.168.22.11:80)
- 浏览器发出Get请求 : Get/chn/yxsz/index.html
- 服务器给出响应,把文件index.html发送给浏览器
- 释放TCP连接
- 浏览器解析内容,显示请求到的内容
3. URI和URL的关系
URI : 统一资源标识符,是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。采用 HTTP 协议时,协议方案就是 http。除此之外,还有 ftp、mailto、telnet、file 等。标准的 URI 协议方案有 30 种左右,由隶属于 国际互联网资源管理的非营利社团 ICANN(Internet Corporation for Assigned Names and Numbers,互联网名称与数字地址分配机构)的 IANA(Internet Assigned Numbers Authority,互联网号码分配局)管理 颁布。
URL:统一资源定位符。URI用字符串标识某一互联网资源,而 URL表示资源的地点(互联 网上所处的位置)。可见URL是URI的子集。
4. Http报文结构,首部字段说明
4.1 请求报文
4.2 响应报文
4.3 报文结构
4.3.1 通用报头
Date : 时间
Connection :
Cache-Control:
4.3.2 请求报头
Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。
User-Agent:发送请求的浏览器类型、操作系统等信息。
Accept:客户端可识别的内容类型列表,用于指定客户端接收哪些类型的信息。
Accept-Encoding:客户端可识别的数据编码。
Accept-Language:表示浏览器所支持的语言类型。
Connection:允许客户端和服务器指定与请求/响应连接有关的选项。例如,这时为Keep-Alive则表示 保持连接。
Transfer-Encoding:告知接收端为了保证报文的可靠传输,对报文采用了什么编码方式。
4.3.3 响应报头
用于服务器传递自身信息的响应。常见的响应报头如下所示。
Location:用于重定向接收者到一个新的位置,常用在更换域名的时候。
Server:包含服务器用来处理请求的系统信息,与User-Agent请求报头是相对应的。
4.3.4 实体报头
实体报头用来定义被传送资源的信息,其既可用于请求也可用于响应。请求和响应消息都可以传送一 个实体。常见的实体报头如下所示。
Content-Type:发送给接收者的实体正文的媒体类型。
Content-Lenght:实体正文的长度。 、Content-Language:描述资源所用的自然语言。
Content-Encoding:实体报头被用作媒体类型的修饰符。它的值指示了已经被应用到实体正文的附加 内容的编码,因而要获得Content-Type报头域中所引用的媒体类型,必须采用相应的解码机制。
Last-Modified:实体报头用于指示资源的最后修改日期和时间。
Expires:实体报头给出响应过期的日期和时间。
5. Http请求方法
-
Get:获取资源。GET 方法用来请求访问已被 URI 识别的资源。
-
POST:传输实体主体。POST 方法用来传输实体的主体。
-
PUT:传输文件。PUT 方法用来传输文件。就像 FTP 协议的文件上传一样,要求在请 求报文的主体中包含文件内容,然后保存到请求 URI 指定的位置。
-
HEAD:获得报文首部,HEAD 方法和 GET 方法一样,只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
-
DELETE:删除文件。DELETE 方法用来删除文件,是与 PUT 相反的方法。DELETE 方法按 请求 URI 删除指定的资源。
-
OPTIONS:询问支持的方法。OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。
-
TRACE:追踪路径。TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。
6. Http状态码
1xx 通知
2xx 请求成功
3xx 重定向
4xx 客户端错误
5xx 服务器错误
7. 提升传输速率
-
编码提升传输效率,HTTP 在传输数据时可以按照数据原貌直接传输,但也可以在传输过 程中通过编码提升传输速率。通过在传输时编码,能有效地处理大量 的访问请求。但是,编码的操作需要计算机来完成,因此会消耗更多 的 CPU 等资源。
-
压缩传输的内容编码
向待发送邮件内增加附件时,为了使邮件容量变小,我们会先用 ZIP 压缩文件之后再添加附件发送。HTTP 协议中有一种被称为内容编码 的功能也能进行类似的操作。
内容编码指明应用在实体内容上的编码格式,并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
常用的内容编码有以下几种。
gzip(GNU zip) compress(UNIX 系统的标准压缩) deflate(zlib) identity(不进行编码)
-
分割发送的分块传输编码
在 HTTP 通信过程中,请求的编码实体资源尚未全部传输完成之前, 浏览器无法显示请求页面。在传输大容量数据时,通过把数据分割成 多块,能够让浏览器逐步显示页面。
这种把实体主体分块的功能称为分块传输编码(Chunked Transfer Coding)。
分块传输编码会将实体主体分成多个部分(块)。每一块都会用十六 进制来标记块的大小,而实体主体的最后一块会使用“0(CR+LF)”来标 记。
使用分块传输编码的实体主体会由接收的客户端负责解码,恢复到编 码前的实体主体。
HTTP/1.1 中存在一种称为传输编码(Transfer Coding)的机制,它可 以在通信时按某种编码方式传输,但只定义作用于分块传输编码中。
-
获取部分内容的范围请求
指定范围发送的请 求叫做范围请求(Range Request)。
对一份 10 000 字节大小的资源,如果使用范围请求,可以只请求 5001~10 000 字节内的资源。
执行范围请求时,会用到首部字段 Range 来指定资源的 byte 范围。 byte 范围的指定形式如下。
5001~10 000 字节
Range: bytes=5001-10000
从 5001 字节之后全部的
Range: bytes=5001-
从一开始到 3000 字节和 5000~7000 字节的多重范围
Range: bytes=-3000, 5000-7000
8. Http和Https的关系
-
HTTP+ 加密 + 认证 + 完整性保护 = HTTPS
-
HTTPS 是身披 SSL 外壳的 HTTP
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)协议代 替而已。
通常,HTTP 直接和 TCP 通信。当使用 SSL时,则演变成先和 SSL通 信,再由 SSL和 TCP 通信了。简言之,所谓 HTTPS,其实就是身披 SSL协议这层外壳的 HTTP。
-
HTTPS 采用混合加密机制
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密 机制。若密钥能够实现安全交换,那么有可能会考虑仅使用公开 密钥加密来通信。但是公开密钥加密与共享密钥加密相比,其处 理速度要慢。
所以应充分利用两者各自的优势,将多种方法组合起来用于通 信。在交换密钥环节使用公开密钥加密方式,之后的建立通信交 换报文阶段则使用共享密钥加密方式。
-
证明公开密钥正确性的证书
使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书。
服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端,以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称 为证书。
接到证书的客户端可使用数字证书认证机构的公开密钥,对那张证书 上的数字签名进行验证,一旦验证通过,客户端便可明确两件事: 一,认证服务器的公开密钥的是真实有效的数字证书认证机构。二, 服务器的公开密钥是值得信赖的。
此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式 时,如何安全转交是一件很困难的事,因此,多数浏览器开发商发布 版本时,会事先在内部植入常用认证机关的公开密钥。
-
HTTPS 比 HTTP 要慢 2 到 100 倍
SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗 CPU 及内存等资源,导致处理速度变慢。
和使用 HTTP 相比,网络负载可能会变慢 2 到 100 倍。除去和 TCP 连接、发送 HTTP 请求 • 响应以外,还必须进行 SSL通信, 因此整体上处理通信量不可避免会增加。
另一点是 SSL必须进行加密处理。在服务器和客户端都需要进行 加密和解密的运算处理。因此从结果上讲,比起 HTTP 会更多地 消耗服务器和客户端的硬件资源,导致负载增强。
针对速度变慢这一问题,并没有根本性的解决方案,我们会使用 SSL加速器这种(专用服务器)硬件来改善该问题。该硬件为 SSL通信专用硬件,相对软件来讲,能够提高数倍 SSL的计算速 度。仅在 SSL处理时发挥 SSL加速器的功效,以分担负载。
9. Https建立SSL全过程
步骤 1: 客户端通过发送 Client Hello 报文开始 SSL通信。报文中包 含客户端支持的 SSL的指定版本、加密组件(Cipher Suite)列表(所 使用的加密算法及密钥长度等)。
步骤 2: 服务器可进行 SSL通信时,会以 Server Hello 报文作为应答。和客户端一样,在报文中包含 SSL版本以及加密组件。服务器的 加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3: 之后服务器发送 Certificate 报文。报文中包含公开密钥证 书。
步骤 4: 最后服务器发送 Server Hello Done 报文通知客户端,最初阶 段的 SSL握手协商部分结束。
步骤 5: SSL第一次握手结束之后,客户端以 Client Key Exchange 报 文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
步骤 6: 接着客户端继续发送 Change Cipher Spec 报文。该报文会提 示服务器,在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7: 客户端发送 Finished 报文。该报文包含连接至今全部报文的 整体校验值。这次握手协商是否能够成功,要以服务器是否能够正确 解密该报文作为判定标准。
步骤 8: 服务器同样发送 Change Cipher Spec 报文。
步骤 9: 服务器同样发送 Finished 报文。
步骤 10: 服务器和客户端的 Finished 报文交换完毕之后,SSL连接 就算建立完成。当然,通信会受到 SSL的保护。从此处开始进行应用 层协议的通信,即发送 HTTP 请求。
步骤 11: 应用层协议通信,即发送 HTTP 响应。
步骤 12: 最后由客户端断开连接。断开连接时,发送 close_notify 报 文。上图做了一些省略,这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。
在以上流程中,应用层发送数据时会附加一种叫做 MAC(Message Authentication Code)的报文摘要。MAC 能够查知报文是否遭到篡 改,从而保护报文的完整性。
10. Cookie和Session分别干嘛的,有什么区别
一般会使用 Cookie 来管理 Session(会话)。
步骤 1: 客户端把用户 ID 和密码等登录信息放入报文的实体部分, 通常是以 POST 方法把请求发送给服务器。而这时,会使用 HTTPS 通信来进行 HTML表单画面的显示和用户输入数据的发送。
步骤 2: 服务器会发放用以识别用户的 Session ID。通过验证从客户 端发送过来的登录信息进行身份认证,然后把用户的认证状态与 Session ID 绑定后记录在服务器端。
向客户端返回响应时,会在首部字段 Set-Cookie 内写入 Session ID(如 PHPSESSID=028a8c…)。
你可以把 Session ID 想象成一种用以区分不同用户的等位号。
然而,如果 Session ID 被第三方盗走,对方就可以伪装成你的身份进 行恶意操作了。因此必须防止 Session ID 被盗,或被猜出。为了做到 这点,Session ID 应使用难以推测的字符串,且服务器端也需要进行 有效期的管理,保证其安全性。
另外,为减轻跨站脚本攻击(XSS)造成的损失,建议事先在 Cookie 内加上 httponly 属性。
步骤 3: 客户端接收到从服务器端发来的 Session ID 后,会将其作为 Cookie 保存在本地。下次向服务器发送请求时,浏览器会自动发送 Cookie,所以 Session ID 也随之发送到服务器。服务器端可通过验证 接收到的 Session ID 识别用户和其认证状态。
总结:cookie用于存储用户数据,行为,比如存储用户上次登录输入的内容。可以存储在内存中,也可以序列化到本地,根据超时时间进行销毁,或者被服务端新set-cookie来覆盖。
session是一种抽象的会话,比如,只有登录了才能查看我的订单,这时候有一个sessionId来标识是否登录了,这个sessionID可以由cookie来管理。
11. Http1.0、1.1、2.0区别
Http1.0/1.1:
- 一条连接上只可发送一个请求。
- 请求只能从客户端开始。客户端不可以接收除响应以外的指 令。
- 请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较 多。
- 可任意选择数据压缩格式。非强制压缩发送。
Http SPDY
SPDY 没有完全改写 HTTP 协议,而是在 TCP/IP 的应用层与运输层之 间通过新加会话层的形式运作。同时,考虑到安全性问题,SPDY 规 定通信中使用 SSL。
SPDY 以会话层的形式加入,控制对数据的流动,但还是采用 HTTP 建立通信连接。因此,可照常使用 HTTP 的 GET 和 POST 等方 法、 Cookie 以及 HTTP 报文等。
-
多路复用流
通过单一的 TCP 连接,可以无限制处理多个 HTTP 请求。所有请求 的处理都在一条 TCP 连接上完成,因此 TCP 的处理效率得到提高。
-
赋予请求优先级
SPDY 不仅可以无限制地并发处理请求,还可以给请求逐个分配优先 级顺序。这样主要是为了在发送多个请求时,解决因带宽低而导致响 应变慢的问题。
-
压缩 HTTP 首部
压缩 HTTP 请求和响应的首部。这样一来,通信产生的数据包数量和 发送的字节数就更少了。
-
推送功能
支持服务器主动向客户端推送数据的功能。这样,服务器可直接发送 数据,而不必等待客户端的请求。
-
服务器提示功能
服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源 之前就可以获知资源的存在,因此在资源已缓存等情况下,可以避免发送不必要的请求。
12. Http Post传输数据几种格式
application/x-www-form-urlencoded
这应该是最常见的 POST 提交数据的方式了。浏览器的原生 表单,如果不设置 enctype 属性,那么最终就会以 application/x-www-form-urlencoded 方式提交数据。
POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8
title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3
- 首先,Content-Type 被指定为 application/x-www-form-urlencoded
- 其次,提交的数据按照 key1=val1&key2=val2 的方式进行编码,key 和 val 都进行了 URL 转码。
- 大部分服务端语言都对这种方式有很好的支持。
application/json
-
Content-Type 被指定为application/json
-
可以方便的提交复杂的结构化数据,特别适合 RESTful 的接口
-
各大抓包工具如 Chrome 自带的开发者工具、Firebug、Fiddler,都会以树形结构展示 JSON 数据,非常友好
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8{“title”:“test”,“sub”:[1,2,3]}
text/xml
Content-Type: text/xml
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>41</i4></value>
</param>
</params>
</methodCall>
multipart/form-data
-
使用表单上传文件时,必须让 表单的 enctype 等于 multipart/form-data
-
首先生成了一个 boundary 用于分割不同的字段,为了避免与正文内容重复,boundary 很长很复杂。
-
然后 Content-Type 里指明了数据是以 multipart/form-data 来编码,本次请求的 boundary 是什么内容
-
消息主体里按照字段个数又分为多个结构类似的部分,每部分都是以 --boundary 开始
-
紧接着是内容描述信息
-
然后是回车
-
最后是字段具体内容(文本或二进制)
-
如果传输的是文件,还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。
POST http://www.example.com HTTP/1.1 Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA ------WebKitFormBoundaryrGKCBY7qhFd3TrwA Content-Disposition: form-data; name="text" title ------WebKitFormBoundaryrGKCBY7qhFd3TrwA Content-Disposition: form-data; name="file"; filename="chrome.png" Content-Type: image/png PNG ... content of chrome.png ... ------WebKitFormBoundaryrGKCBY7qhFd3TrwA--