HTTP协议基础知识

URI和URL：

URI用字符串标识某一互联网资源，而URL标识资源的地点（互联网上所处的位置）。可见URL是URI的子集。

HTTP支持的方法：

GET               获取资源

POST            传输实体主体

PUT               传输文件

HEAD            获取报文首部

DELETE         删除文件

OPTIONS      询问支持的方法

TRACE          追踪路径

CONNECT    要求用隧道协议连接代理

持久连接：

HTTP keep-alive，只要任意一端没有明确提出断开连接，则保持TCP连接状态。好处在于减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。

管线化：pipelining

同时并行发送多个请求，而不需要一个接一个地等待响应。

Cookie技术：

通过请求和相应报文中写入Cookie信息来控制客户端的状态。Cookie会根据从服务器发送的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。

服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

分块传输编码：

在HTTP通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面，在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。这种把主体分块的功能称为分块传输编码Chunked Transfer Coding.

内容协商机制：

用户端和服务器就响应的资源内容进行交涉，然后提供给用户端最为合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。

包含在请求报文中的某些首部字段：

Accept

Accept-Charset

Accept-Encoding

Accept-Language

Content-Language

三种类型：

服务器驱动协商 Server-driven Negotiation：

由服务器进行内容协商，以请求的首部字段作为参考，在服务器端自动处理。但对用户来说，以浏览器发送的信息作为判断的依据，并不一定能筛选出最优内容。

客服端驱动协商 Agent-driven Negotiation：

由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用JavaScript脚本在Web页面上进行自动上述选择。比如按OS的类型或浏览器类型，自行切换成PC版或手机页面。

透明协商 Transparent Negotiation:

服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。

HTTP状态码：

1XX     Informational     信息性状态码               接收的请求正在处理

2XX     Success            成功状态码                   请求正常处理完毕

3XX     Redirection        重定向状态码               需要进行附加操作以完成请求

4XX     Client Error        客户端状态错误码        服务器无法处理请求

5XX     Server Error       服务器错误状态码        服务器处理请求出错    

204 No Content 

代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。比如，当从浏览器发出请求处理后，返回204响应，那么浏览器显示的页面不发生更新。

一般在只需从客户端往服务器发送消息，而对客户端不需要发送新信息内容的情况下使用。

206 Partial Content

表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range制定范围的实体内容。

301 Moved Permanently

永久性重定向，表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。也就是说，如果已经把资源对应的URI保存为书签了，这是应该按Location首部字段提示的URI重新保存。

302 Found

临时性重定向，表示请求的资源已被分配了新的URI，希望用户（本次）能使用新的URI访问。

303 See Other

表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。302状态码和303状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。

304 Not Modified

表示客户端发送附带条件的请求，服务器端允许请求访问资源，但发生请求未满足条件的情况后，直接返回304 Not Modified（服务器端资源未改变，可直接使用客户端未过期的缓存）。

307 Temporary Redirect 

临时重定向。与302 Found有着相同的含义，307不会从POST变成GET。

400 Bad Request

表示报文中存在语法错误，当错误发生时，需修改请求的内容再次发送请求。

401 Unauthorized

表示发送的请求需要有通过HTTP认证（BASIC认证、DIGEST认证）的认证信息。另外若之前已进行过一次请求，则表示用户认证失败。当浏览器初次接收到401响应，会弹出认证用的对话窗口。

403 Forbidden

表示请求资源的访问被服务器被拒绝了。未获得文件系统的访问授权，访问权限出现某些问题（未授权的发送源IP地址试图访问）等列举的情况都可能发生403的原因。

404 Not Found

表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求且不想说明理由时使用。

500 Internal Server Error

表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时的故障。

503 Service Unavailable

表明服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求。

通信数据转发程序：

代理：

代理是一种有转发功能的应用程序，它扮演了位于服务器和客户端中间人的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。

使用代理服务器的理由有：利用缓存技术减少网络带宽的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要目的。

缓存代理：代理转发响应时，缓存代理会预先将资源的副本缓存在代理服务器上，当代理再次接收到对相同资源的请求时，就可以不从源服务器哪里获取资源，而是将之前缓存的资源作为响应返回。

透明代理：转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理Transparent Proxy，反正，称为非透明代理。

网关：

网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端可能都不会察觉，自己通信的目标是一个网关。

利用网关能提高通信安全性，可以在客户端和网关之间的通信线路上加密以确保连接的安全。比如，网管可以连接数据库，使用SQL语句查询数据等。

隧道：

在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。

隧道可按要求建立起一条与其他服务器的通信线路，使用SSL等加密手段进行通信。

缓存：

缓存服务器：

是代理服务器的一种，当代理转发服务器的响应时，代理服务器将会保存一份资源的副本。优势在于利用缓存可避免多次从源服务器上转发资源，因此客户端可就近从缓存服务器上获取资源，而源服务器也不必多次处理相同的请求了。

客户端的缓存：

客户端浏览器也可以进行缓存，比如IE浏览器，缓存在临时网络文件（Temporary Internet File），浏览器缓存如果有效，就不必再向服务器请求相同的资源了，可以直接从本地磁盘内读取。

HTTP请求报文：

在请求中，HTTP报文由方法，URI，HTTP版本，HTTP首部字段等部分组成。

HTTP响应报文：

在响应中，HTTP报文由HTTP版本、状态码，HTTP首部字段三部分组成。

HTTP/1.1通用首部字段：

指请求报文和响应报文双方都会使用的首部。

Cache-Control指令：

表示是否能缓存的指令：

public :表明其他用户可以利用缓存

private：响应只能以特定的用户作为对象，缓存服务器会对特定用户提供资环缓存的服务，对于其他用户发送过来的请求，代理服务器不会返回缓存。

no-cache:指令的目的是为了防止从缓存中返回过期的资源。客户端发送的请求中如果包含no-cache指令，表示客户端将不会接受缓存过的响应，于是，中间缓存器必须把客户端请求转发给源服务器。

max-age:当客户端发送的请求包含max-age指令时，如果判定缓存资源的缓存时间数值比制定时间的数值更小，那么客户端就接收缓存的资源。当max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。

min-fresh:指令要求缓存服务器返回至少还未过指令时间的缓存资源。当制定min-fresh为60秒后，在这60秒以内如果有超过有效期的资源都无法作为相应返回了。

max-stale:使用max-stale可指示缓存资源，即使过期也照常接收。如果指令未制定参考值，那么无论经过多久，客户端都会接收相应。如果指令中制定了具体数值，那么即使过期，只要仍处于max-stale指定的时间内，仍旧会被客户端接收。

must-revalidate：代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效。

proxy-revalidate:指令要求所有的缓存服务器在接收到客户端带有该指令的请求返回响应钱，必须再次验证缓存的有效性。

Connection:

两个作用：控制不再转发给代理的首部字段，管理持久连接。

HTTP/1.1版本的默认连接都是持久连接，为此，客户端会在持久连接上连续发送请求，放服务器端想明确断开连接时，制定Connection首部字段的值为Close。

Date：

首部字段Date表明创建HTTP报文的日期和时间。

Transfer-Encoding:

规定了传输报文主体时采用的编码方式，HTTP/1.1的传输编码方式仅对分块传输编码有效。

Accept:

可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级，使用type/subtype这种形式，一次指定多种媒体类型。

文本文件：text/html， text/plain， text/css， application/xhtml+xml， application/xml

图片文件：image/jpeg ，image/gif， image/png

视频文件：video/mpeg，video/quicktime

Accept-Charset:

用来通知服务器用户代理支持的字符集，及字符集的优先顺序。可以一次性指定多种字符集，利用权重q值来表示相对优先级。

Accept-Encoding:

用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序，可以一次性指定多种内容编码。

gzip compress deflate identity

Accept-language:

用来告知服务器用户代理能够处理的自然语言集，以及自然语言集的相对优先级，可一次指定多种自然语言集。

Authorization:

用来告知服务器用户代理的认证信息（证书值），想要通过服务器认证的用户代理会在接收到返回的401状态码响应后，把首部字段Authorization加入请求中。

Host:

用来告知服务器，请求的资源所处的互联网主机名和端口号，host字段和以单台服务器分配多个域名的虚拟主机的工作机制有密切的关联。

Range：

对于只需要获取部分资源的范围请求，包含首部字段Range即可告知服务器资源的指定范围，接收附带Range首部字段请求的服务器，会在处理请求之后返回状态码为206 Partial Content的响应，无法处理该请求时，则会返回状态码200OK的响应和全部资源。

Accept-Ranges:

服务器用来告知客户端是否能处理范围请求，以指定获取服务器端某个部分的资源，可以指定的字段值有两种，可处理范围请求时指定其为bytes，反之则指定为none.

Age:

告知客户端，源服务器在多久前创建了响应，字段值的单位为秒。若创建该响应的服务器是缓存服务器，Age值是指缓存后的响应再次发起认证到认证完成的时间值，代理创建响应时必须加上首部字段Age值。

ETag：

ETag能告知客户端实体标识，它是一种可将资源以字符串形式做唯一性标识的方式，服务器会为每份资源分配对应的ETag值。当资源更新时，ETag值也会更新，生成ETag值时，并没有统一的算法规则，而仅仅是由服务器来分配。

Location:

可以将响应接收方引导至某个与请求URI位置不同的资源，基本上，该字段会配合3XX：Redirection的响应，提供重定向的URI。

Allow：

用户通知客户端能够支持Request-URI指定资源的所有HTTP方法，当服务器接收到不支持的HTTP方法时，会以状态码405 Methord Not Allow作为响应返回，与此同时，还会把所有能支持的HTTP方法写入首部字段Allow后返回。

Content-Encoding:

会告知客户端服务器对实体的主体部分选用的内容编码方式，主要采用4种编码方式：gzip,compress,defalte,identity

Content-Language:

告知客户端，实体主体使用的自然语言。

Content-Length:

表明实体主体部分的大小（单位是字节）。

Content-Location:

给出与报文主体部分相对应的URI，和首部字段Location不同，Content-Location表示的是报文主体返回资源对应的URI。

Content-MD5:

是一串MD5算法生成的值，目的在于检查报文主体在传输过程中是否保持完整，以及确认传输到达。

对报文主体执行MD5算法获得的128位二进制数，再通过Base64编码后将结果写入Content-MD5字段值。由于HTTP首部无法记录二进制值，所以要通过Base64编码处理。为确保报文的有效性，作为接受方的客户端会对报文主体再次执行一次相同的MD5算法。计算出的值与字段值做出比较后，即可判断出报文主体的准确性。

Content-Range:

针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求，字段值以字节为单位，表示当前发送部分及整个实体大小。

Content-Type:

说明了实体主体内对象的媒体类型，和首部字段Accept一样，字段值用type/subtype形式赋值，参数charset使用iso-8859-1或euc-jp等字符集进行赋值。

Expires:

会将资源失效的日期告知客户端，缓存服务器在接收到含有首部字段Expires的响应后，会以缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会一直被保存。当超过指定的时间后，缓存服务器在请求发送过来时，会转向源服务器请求资源。

Last-Modified:

指明资源最终修改的时间，一般来说，这个值就是Request-URI指定资源被修改的时间。

Cookie相关的首部字段：

Cookie的工作机制是用户识别及状态管理，Web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内，接着当用户访问该Web网站时，可通过通信方式取回之前发动的Cookie。

Set-Cookie：

当服务器准备开始管理客户端的状态时，会事先告知各种信息。

NAME=VALUE： 

赋予Cookie的名称和其值（必需项）

expire=DATE： 

Cookies的有效期，若不明确指定则默认为浏览器关闭前为止。

path=PATH： 

将服务器上的文件目录作为Cookie的适用对象，若不指定则默认文档所在的文件目录

domain=域名：

作为Cookie适用对象的域名，若不指定则默认为创建Cookie的服务器的域名

Secure： 

仅在HTTPS安全通信时才会发送Cookie

HttpOnly：

加以限制，使Cookie不能被JavaScript脚本访问

Cookie：

告知服务器，当客户端想要获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie，接收到多个Cookie时，同样可以以多个Cookie形式发送。

X-Frame-Options:

属于HTTP响应首部，用于控制网站内容在其他Web网站的Frame标签内的显示问题，其主要目的是为了防止点击劫持clickjacking攻击。

有两个可指定的字段值：

DENY：拒绝

SAMEORIGIN：仅同源域名下的页面（Top-level-browsing-context)匹配时许可。

HTTP的缺点：

通信使用明文，不加密，内容可能被窃听。

不验证通信方的身份，因此可能遭遇伪装。

无法证明报文的完整性，随意有可能已遭篡改。

通信的加密：

可以通过和SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全传输层协议）的组合使用，加密HTTP的通信内容。用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了，这种组合成为HTTPS。

内容的加密：

将参与通信的内容本身加密，为了做到有效的内容加密，前提是要求客户端和服务器同时具有加密和解密机制，这种方式不同于SSL或TLS将整个通信线路加密处理，所以内容仍有被篡改的风险。

加密技术：

共享密钥：

加密和解密同用一个密钥的方式称为共享密钥加密 Common key crypto system，也被称为对称密钥加密。以共享密钥加密时，必须将密钥也发给对方。

公开密钥加密：

使用一对非对称的密钥，一把叫做私有密钥private key，一把叫做公开密钥public key，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。

使用公开密钥加密方式，发送密文的一方使用对方公开的密钥进行加密处理，对方收到加密的信息以后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。

HTTPS=加密+认证+完整性保护

把添加了加密和认证机制的HTTP称为HTTPS。

HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信，但是公开密钥加密与共享密钥加密相比，其处理速度要慢。

HTTPS的安全通信机制：

1. 客户端 ————Handshake:ClientHello————>> 服务器

2. 客户端 <<———Handshake:ServerHello—————服务器

3. 客户端 <<———Handshake:Certificate————— 服务器

4. 客户端 <<———Handshake:ServerHelloDone——  服务器

5. 客户端 ——Handshake:ClientKeyExchange——>> 服务器

6. 客户端 ————ChangeCipherSpec————— >> 服务器

7. 客户端 ————Handshake:Finished—————>> 服务器

8. 客户端 <<———ChangeCipherSpec——————  服务器

9. 客户端 <<———Handshake:Finished—————— 服务器

10客户端 ————Application Data(HTTP)———-->>服务器

11客户端 <<———Application Data(HTTP)————— 服务器

12客户端 ————Alert:warning,close notify———>> 服务器

1.客户端通过发送ClientHello报文开始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的通信。

HTTP的瓶颈：

在Facebook和Twitter等SNS网站上，几乎能够实时观察海量用户公开发布的内容，当几百、几千万的用户发布内容时，Web网站为了保存这些新增内容，在很短的时间内就会发生大量的内容更新，为了尽可能实时显示这些更新内容，服务器上一有内容更新，就需要直接把这些内容反馈到客户端的界面上。虽然看起来挺简单的，但HTTP却无法妥善地处理好这项任务。

使用HTTP协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信。

若想在现有Web实现所需的功能，以下这些HTTP标准就会成为瓶颈。

• 一条连接上只可能发送一个请求
• 请求只能从客户端开始，客户端不可以接收除响应以外的指令。
• 请求/响应首部未经压缩就发送，首部信息越多延迟越大。
• 发送冗长的首部，每次互相发送相同的首部造成的浪费较多
• 可任意选择数据压缩格式，非强制压缩发送。

Ajax的解决办法：

Ajax(Asynchronous JavaScript and XML，异步JavaScript与XML技术)是一种有效利用JavaScript和DOM（Document Object Model，文档对象模型）的操作，以达到局部Web页面替换加载的异步通信手段。和以前的同步通信相比，由于它只更新一部分页面，响应中传输的数据量会因此而减少，这一优点显而易见。

Ajax的核心技术是名为XMLHttpRequest的API，通过JavaScript脚本语言的调用就能和服务器进行HTTP通信。借用这种手段，就能从已加载完毕的Web页面上发起请求，只更新局部页面。

Comet的解决方法：

一旦服务器端有内容更新了，Comet不会让请求等待，而是直接给客户端返回响应。这是一种通过延迟应答，模拟实现服务器端向客户端推送的功能。

通常，服务器端接收到请求，在处理完毕后就会立即返回响应，但为了实现推送功能，Comet会先将响应置于挂起状态，当服务器端有内容更新时，再返回响应，因此，服务器端一旦有更新，就可以立即反馈给客户端。

内容上虽然可以做到实时更新，但为了保留响应，一次连接的持续时间也变成了，期间，为了维持连接会消耗更多的资源。

消除HTTP瓶颈的SPDY：

SPDY在TCP/IP的应用层与运输层之间通过新加会话层的形式运作。同时，会考虑到安全性问题，SPDY规定通信中使用SSL。

SPDY以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接，因此，可照常使用HTTP的GET和POST等方法，Cookie以及HTTP报文等。

使用SPDY后，HTTP协议额外获得了以下功能：

多路复用流：

通过单一的TCP连接，可以无限制处理多个HTTPHTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。

赋予请求优先级：

SPDY不仅可以无限制地并发处理请求，还可以给请求诸葛分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。

压缩HTTP首部：

压缩HTTP请求和响应的首部，这样一来，通信产生的数据包数量和发送的字节数就更少了。

推送功能：

支持服务器主动向客户端推送数据的功能，这样，服务器就可至今发送数据，而不必等待客户端的请求。

服务器提示功能：

服务器可以主动提示客户端请求所需的资源，由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

WebSocket协议：

是Web浏览器与Web服务器之间全双工通信标准，一旦Web服务器与客户端之间建立起WebSocket协议的通信连接，之后所有的通信都依靠这个专用协议进行，通信过程中可以相互发送JSON，XML，HTML或图片等任意格式的数据。

由于是建立在HTTP基础上的协议，因此连接的发起方仍是客户端，而一旦确立WebSocket通信连接，不论服务器还是客户端，任意一方都可以直接向对方发送报文。

推送功能：

支持由服务器向客户端推送数据的推送功能，这样，服务器可直接发送数据，而不必等待客户端的请求。

减少通信量：

只要建立起WebSocket连接，就希望一直保持连接状态，和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信录也相应减少了。

HTTP/2.0的特点：

HTTP/2.0的目标是改善用户在使用Web时的速度体验，由于基本上都会通过HTTP/1.1和TCP连接。

• SPDY
• HTTP Speed + Mobility
• Network-Friendly HTTP Upgrade

针对web应用的攻击模式：

以服务器为目标的主动攻击：

主动攻击 active attack是指攻击者通过直接访问Web应用，把攻击代码传入的攻击模式。由于该模式是直接针对服务器上的资源进行的攻击，因此攻击者需要能够访问这些资源。

主动攻击中具有代表性的是SQL注入攻击和OS命令注入攻击。

以服务器为目标的被动攻击：

被动攻击 passive attack是指利用圈套策略执行攻击代码的攻击模式，在被动攻击过程中，攻击者不直接对目标的web应用访问发起攻击。