也谈HTTP协议

HTTP（HyperText Transfer Protocol，超文转移协议，超文本传输协议的译法并不严谨。）

1、网络基础 TCP/IP

1.1 TCP/IP 协议族

TCP/IP 协议族是互联网相关联的协议的集合。从电缆的规格到IP地址的选定方法、寻找异地用户的方法、双方创建通讯的顺序，以及Web页面显示须要处理的步骤，等等。而HTTP是属于它内部的一个子集。

1.2 TCP/IP 的分层管理

TCP/IP 协议族按层次分别分为如下 4 层：应用层、传输层、网络层和数据链路层。 分层的好处：把各层之间的接口部分规划好以后，每一个层次内部的设计就可以自由改动了。并且，层次化以后，设计也变得相对简单。处于应用层上的应用能够只考虑分派给本身的任务，而无需弄清对方在地球上哪一个地方、对方的传输路线、是否能确保传输送达等问题。

• 应用层：决定了向用户提供应用服务时通讯的活动。 TCP/IP 协议族预存了各种通用的应用服务。如 FTP（File Transfer Protocol）、DNS（Domain Name System）和 HTTP。
• 传输层：该层对上层应用层，提供处于网络链接中的两台计算机之间的数据传输。TCP（Transmission Control Protocol）和 UDP（User Data Protocol，用户数据报协议）。
• 网络层：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了经过怎么样的路径到达对方计算机，并把数据包传送给对方。
• 链路层：用来处理网络的硬件部分。

1.3 TCP/IP 通讯传输流

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

用HTTP 举例来讲：首先做为发送端的客户端在应用层（HTTP协议）发出一个HTTP请求。 接着，在传输层（TCP协议）把从应用层处收到的数据（HTTP请求报文）进行分隔，并在各个报文上打上标记序号及端口号后转发给网络层。 在网络层（IP协议），增长做为通讯目的地的MAC地址后转发给链路层。这就让发往网络的通讯请求准备齐全了。 接收端的服务器在链路层接收到数据后，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到客户端发送过来的HTTP请求。

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

2、与HTTP关系密切的协议：IP、TCP和DNS

2.1 负责传输的 IP 协议

IP（网际协议）位于网络层。该协议的做用是把各类数据包传送给对方。而要保证确实传送到对方那里，则须要知足各种条件。其中最重要的两个条件是 IP 地址和 MAC地址。 IP 地址指明了节点被分配到的地址，MAC地址是指网卡所属的固定地址。IP地址能够和MAC地址进行配对。

使用ARP协议凭借MAC地址进行通讯 IP间通讯通讯依赖MAC地址。通讯的双方一般会通过多台计算机和网络设备中转才能链接到对方，而在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时，会采用ARP协议。该协议是一种用以解析地址的协议，根据通讯方的IP地址就能够反查出对应的MAC地址。

2.2 确保可靠性的TCP协议

TCP属于传输层，提供可靠的字节流服务。 字节流服务是指：为了方便传输，将大块数据分割成以报文段为单位的数据包进行管理。 这就是为何下载高清大图时，图片会一块一块地加载。

三次握手 为了准确无误地将数据送达目标处，TCP协议在发送数据的准备阶段采用了三次握手策略（若在握手过程当中某个阶段中断，TCP协议会再次以相同的顺序发送相同的数据包）。

固然，除了三次握手，TCP还有其它各类手段确保通讯的可靠性。

2.3 负责域名解析的 DNS 服务

DNS服务提供域名到IP 地址之间的解析服务。 便可经过域名查找IP，或逆向从IP地址反查域名服务。

由于域名解析也须要时间，因此能够 提早获取DNS来提高网页加载速度。

3、URI和URL

 

URI（uniform Resource Identifier） Uniform：规定统一的格式可方便处理多种不一样类型的资源。 Resource：可标识的任何东西 Identifier：标识符

URL(Uniform Resource Locator)：统一资源定位符，正是使用 Web 浏览器访问 Web 页面时须要输入的网页地址。

URI就是某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称，如http、ftp。

URI 用字符串标识某一个互联网资源，而URL表示资源的地点。URL是URI的子集。

表示指定的URI，要使用涵盖所有必要信息的绝对URI、绝对URL以及相对URL。相对URL是指从浏览器中基本URI处指定的URL，如 /image/logo.gif。

绝对URI的格式以下：

4、HTTP协议

HTTP协议规定，先从客户端开始创建通讯，服务端在没有接收到请求以前不会发送响应。

请求报文由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的。

响应报文基本上由协议版本、状态码、用以解释状态码的缘由短语、可选的响应首部字段以及实体主体构成。

4.1 HTTP是不保存状态的协议

HTTP是无状态协议。自身不对请求和响应之间通讯状态进行保存（即不作持久化处理）。 HTTP之因此设计得如此简单，是为了更快地处理大量事物，确保协议的可伸缩性。 HTTP/1.1 随时无状态协议，但可经过 Cookie 技术保存状态。

4.2 告知服务器意图的HTTP方法

• GET：获取资源

 

• POST：传输实体主体

• PUT：传输文件

• HEAD：得到报文首部，与GET方法同样，只是不返回报文主体内容。用于确认URI的有效性及资源更新的日期时间等。

• DELETE：删除文件，与PUT相反（响应返回204 No Content）。

• OPTIONS：询问支持的方法，查询针对请求URI指定的资源支持的方法（Allow:GET、POST、HEAD、OPTIONS）。

一种应用的场景 发送非简单的cors请求时 浏览器会首先发送options方法来询问服务器支持的方法。参见https://segmentfault.com/a/11...

• TRACE：追踪路径
• CONNECT：要求用隧道协议链接代理（主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通讯内容加密后经网络隧道传输）。

向请求URI指定的资源发送请求报文时，采用称为方法的命令。方法名区分大小写，主要要用大写字母。

4.3 持久链接节省通讯量

HTTP1.1和HTTP1.0相比较而言，最大的区别就是增长了持久链接支持(貌似最新的 http1.0 能够显示的指定 keep-alive),但仍是无状态的，或者说是不能够信任的。在http1.0中使用Connection:keep-alive来标记此次请求是长链接的请求。
因此 若是web服务器端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久链接），它就能够利用持久链接的优势，当页面包含多个元素时（例如Applet，图片），显著地减小下载所须要的时间。
长链接vs短链接
所谓长链接指创建SOCKET链接后无论是否使用都保持链接，但安全性较差， 
所谓短链接指创建SOCKET链接后发送后接收完数据后立刻断开链接，通常银行都使用短链接

4.3.1 持久链接

HTTP协议的初始版本中，每进行一次HTTP通讯就要断开一次TCP链接。

发送请求一份包含多张图片的HTML文档对应的Web页面，会产生大量通讯开销。

为了解决上述TCP链接的问题，HTTP/1.1和一部分的HTTP/1.0想出了持久链接（HTTP Persistent Connections，也称为HTTP keep-alive 或 HTTP Connection resue）的方法。 持久链接的特色是，只要任意一端没有明确提出断开链接，则保持TCP链接状态。

持久链接的好处在于减小了TCP链接的重复创建和断开所形成的额外开销，减轻了服务器端的负载。另外，减小开销的那部分时间，使HTTP请求和响应可以更早地结束，这样Web页面的显示速度也相应提升了。

在HTTP/1.1中，全部链接默认都是持久链接，但在HTTP/1.0内并未标准化。 毫无疑问，除了服务器端，客户端也须要支持持久链接。

4.3.2 管线化

持久链接使得多数请求以管线化方式发送成为可能。之前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求（并行发送多个请求）。

注意：尽管HTTP管线化能够克服同域并行请求限制带来的阻塞， 但HTTP/1.x 有严格的串行返回响应机制，服务器经过 TCP 链接返回响应时，就是必须 按照客户端的请求顺序进行响应 ，前一个响应没有完成，下一个响应就不能返回。因此使用“ HTTP 管道”技术时，万一第一个响应时间很长，那么后面的响应处理完了也没法发送，只能被缓存起来，占用服务器内存，这就是传说中的“队首阻塞”。

• 每一个浏览器支持的请求并发数不一样，但可在页面中使用多个域名加大并发量（由于浏览器是基于domain的并发控制，而不是page），不过过多的散布会致使DNS解析上付出额外的代价。

4.4 使用Cookie的状态管理

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

若是您在cookie中设置了HttpOnly属性，那么经过js脚本将没法读取到cookie信息，这样能有效的防止XSS攻击。

• Cookie-free Domains：用户在请求静态资源时，也会发送cookie信息。对于一个拥有多个静态资源的网站，这无疑会产生没必要要的流量。所以咱们能够启用与主站不一样的域名（包括子域名）来放置静态资源。

浏览器第一次向服务器发起请求

 

浏览器第二次向该服务器发送请求

下面是步骤1 2 3分别对应的报文
一、请求报文
GET /reader/HTTP/1.1
HOST:hackr.jp
二、响应报文
HTTP/1.1 200 OK
Date:Tur,12 jul 2012 07:12:20 GMT
Server Apache
<set-cookie:sid=12211212121 ;path=/ expires=wed,10-0ct-12 >
Content-Type:text/plain charset=UTF-8
三、请求报文 
GET /image /http/1.1
Host : hacker.jsp
Cokkie:sid=12211212121

4.4.1 http中为cookie设置的首部

一、set-cookie：响应报文中 服务器向客户端设置cookie
set-cookie有如下的属性值：
[1]expires：date
指定cookie的过时时间，若是没有为cookie的expire赋值的话 cookie的有效期仅限于会话期间
[2]secure 没有值
限制web网页仅在https安全链接时 才能够发送cookie
[3]httpOnly 没有值
这个属性会使js没法更改cookie

4.5 Session 技术

• 概念： Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据能够保存在集群、数据库、文件中。
• 如何工做：session 由服务端存储，在一次登录操做后，服务器将登录的帐户信息等做为一个session 写入在特定等文件里，在回包报文中使用set-cookies为客户端设置sessionId，最终，客户端在发送下一次请求的时候，会带上session信息，从而达到状态保存的目的。因此，当客户端禁用了cookie，sessoin也没法工做。

4.6 其余的认证技术-token

• token验证的大体过程是：客户端和服务器端约定了一种特定的加密方式，好比以cookie中的某个字段经过特定的位运算，加密编码成一串字符串。最终在请求中做为参数传递给服务器，服务器在收到请求时，再使用一样的加密方式，获取加密串，与传过来的参数进行对比。从而达到身份认证的关系。因为同源的关系，cookie没法被盗取，而加密手段也是自定义的，从而保证了安全性。

5、HTTP报文内的HTTP信息

用于HTTP协议交互的信息被称为HTTP报文。请求端的HTTP报文叫作请求报文，响应端的叫作响应报文。HTTP报文自己是由多行（用CR+LF作换行符）数据构成的字符串文本。

HTTP报文大体可分为报文首部和报文主体两部块。二者由最初出现的空行（CR+LF、回车符+换行符）来划分。一般，并不必定要有报文主体。

5.1 编码提高传输速率

HTTP在传输数据时能够按照数据原貌直接传输，但也能够在传输过程当中经过编码提高传输速率，但这会消耗更多的CPU等资源。

5.1.1 报文主体和实体主体的差别

报文：是HTTP通讯中的基本单位，由8位组字节流组成，经过HTTP通讯传输。 实体：做为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

HTTP报文的主体用于传输请求或响应的实体主体。 一般，报文主体等于实体主体。只有当传输中进行编码操做时，实体主体的内容发生变化，才致使它和报文主体产生差别。

5.1.2 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。 常见的内容编码有：gzip（GNU zip）、compress（UNIX系统的标准压缩）、deflate（zlib）、identity（不进行编码）

5.1.3 分隔发送的分块传输编码

在HTTP通讯过程当中，请求的编码实体资源还没有所有传输完成以前，浏览器没法显示请求页面。在传输大容量数据时，经过把数据分割成多块，可以让浏览器逐步显示页面。 这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。

分块传输编码会将实体主体分红多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0（CR+LF）”来标记。

使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

5.2 发送多种数据的多部分对象集合

HTTP协议中采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。一般是在图片或文本文件等上传时使用。

5.3 获取部份内容的范围请求

下载大尺寸的图片的过程当中，若是网络中断，则须要从新下载。所以须要一种可恢复的机制。 实现该功能须要指定下载的实体范围，像这样，指定范围发送的请求叫作范围请求。 执行范围请求时，会用到首部字段Range来指定资源的byte范围。响应会返回状态码206 Partial Content。

若是服务器端没法响应范围请求，则会返回状态码200 OK和完整的实体内容。

5.4 内容协商返回最合适的内容

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

5.5 返回结果的HTTP状态码

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。 状态码如200 OK，以3为数字和缘由短语组成。 数字中的第一位定义了响应类别，后两位无分类。响应类别有如下五种：

	类别	缘由短语
1XX	Informational(信息性状态码)	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	须要进行附加操做以完成请求
4XX	Client Error（客户端错误状态码）	服务器没法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

只要遵照状态码类别的定义，即便改变 RFC2616 中定义的状态码，或服务器端自行建立状态码都没问题。

5.5.1 经常使用的状态码14种：

2XX 成功

• 200 OK：请求被正常处理
• 204 No Content：通常在只需从客户端往服务器发送信息，而对客户端不须要发送新信息内容的状况下使用。
• 206 Partial Content：客户端进行范围请求

3XX 重定向

• 301 Moved Permanently：永久重定向。表示请求的资源已被分配了新的URI，之后应使用资源如今所指的URI。 也就是说，若是已经把资源对应的URI保存为书签了，这时应该按Location首部字段提示的URI从新保存。
• 302 Found：临时性重定向。表示请求的资源已被分配了新的URI，但愿用户（本次）能使用新的URI访问。 和301 Moved Permanently状态码类似，但302状态码表明的资源不是被永久移动，只是临时性质的。换句话说，已移动的资源对应的URI未来还有可能发生改变。好比，用户把URI保存成书签，但不会像301状态码出现时那样去更新书签，而是仍旧保留返回302状态码的页面对应的URI（在Chrome中，仍是会保存为重定向后的URI，不解）。
• 303 See Other：表示因为请求对应的资源存在着另外一个URI，应使用GET方法定向获取请求的资源。这与302相似，但303明确表示客户端应当采用GET方法获取资源。
• 304 Not Modified：该状态码表示客户端发送附带条件的请求（指采用GET方法的请求报文中包含If-Match,If-Modified-Since，If-None-March，If-Range，If-Unmodified-Since中任一首部。）时，服务器端容许请求访问资源，但因发生请求为知足条件的状况后，直接返回304（服务器端资源未改变，可直接使用客户端未过时的缓存）。304状态码返回时，不包含任何响应的主体部分。
  304虽被划分在3XX类别，可是和重定向没有关系。
• 307 Temporary Redirect：临时重定向。与302有相同含义。307遵照浏览器标准，不会从POST变成

就算是304，也须要发出请求与接收响应，也会耗费资源和时间。

4XX 客户端错误

4XX的响应结果代表客户端是发生错误的缘由所在。

• 400 Bad Request：表示请求报文中存在语法错误。
• 401 Unauthorized：表示发送的请求须要有经过HTTP认证（BASIC认证、DIGEST认证）的认证信息。
• 403 Forbidden：代表对请求资源的访问被服务器拒绝了。服务器端可在实体的主体部分对缘由进行描述（可选）
• 404 Not Found：代表服务器上没法找到请求的资源。除此以外，也能够在服务器端拒绝请求且不想说明理由时时用。

5XX 服务器错误

5XX的响应结果代表服务器自己发生错误。

• 500 Interval Server Error：代表服务器端在执行请求时发生了错误。也有多是Web应用存在的bug或某些临时的故障。
• 503 Service Unavailable：代表服务器暂时处于超负载或正在进行停机维护，如今没法处理请求。若是事先得知解除以上情况须要的时间，最好写入Retry-After首部字段再返回给客户端。

6、与HTTP协做的Web服务器

6.1 用单台虚拟主机实现多个域名

HTTP/1.1 规范容许一台HTTP服务器搭建多个Web站点。这是利用虚拟主机（Virtual Host，又称虚拟服务器）的功能。

在互联网上，域名经过DNS服务映射到IP地址以后访问目标网站。可见，当请求发送到服务器时，已是以IP地址形式访问了。因此，当一台托管了两个域名的服务器接收到请求时就须要弄清楚究竟要访问哪一个域名。 在相同的IP地址下，因为虚拟主机能够寄存多个不一样主机名和域名的Web网站，所以在发送HTTP请求时，必须在Host首部内完整指定主机名或域名的URI。

6.2 通讯数据转发程序：代理、网关、隧道

HTTP通讯时，除客户端和服务器之外，还有一些用于通讯数据转发的应用程序，例如代理、网关、隧道。它们能够配合服务器工做。

• 代理：是一种有转发功能的应用程序，扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。
• 网关：是转发其余服务器通讯数据的服务器，接收从客户端发送来的请求时，它就像本身拥有资源的源服务器同样对请求进行处理。
• 隧道：是在相隔甚远的客户端和服务器二者之间进行中转，并保持双方通讯链接的应用程序。

6.2.1 代理

代理不改变请求URI，会直接发送给前方持有资源的目标服务器。 持有资源实体的服务器被称为源服务器。

例如：

每次经过代理服务器转发请求或响应式，会追加写入via首部信息。

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

代理有多种使用方法，按两种基准分类。一种是是不是否使用缓存，另外一种是是否会修改报文。

• 代理缓存：代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到对相同资源的请求时，就能够不从源服务器那里获取资源，而是将以前缓存的资源做为响应返回。
• 透明代理：转发请求或响应时，不对报文作任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。

6.2.2 网关

网关的工做机制和代理十分类似。而网关能使通讯线路上的服务器提供非HTTP协议服务。 利用网关能提升通讯的安全性，由于能够在客户端与网关之间的通讯线路上加密以确保链接的安全。好比，网关能够链接数据库，使用SQL语句查询数据。另外，在Web购物网站上进行信用卡结算时，网关能够和信用卡结算系统联动。

 

6.2.3 隧道

隧道可按要求创建起一条与其余服务器的通讯线路，届时使用SSL等加密手段进行通讯。隧道的目的是确保客户端与服务器进行安全的通讯。

隧道自己不会去解析HTTP请求。请求保持原样中转给以后的服务器。隧道会在通讯双方断开链接时结束。

 

6.3 保存资源的缓存

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减小对源服务器的访问，节省通讯流量和时间。

缓存服务器是代理服务器的一种。当代理转发从服务器返回的响应时，代理服务器将会保存一份资源的副本。

缓存服务器的优点在于利用缓存可避免屡次从源服务器转发资源。所以客户端可就近从缓存服务器上获取资源，而源服务器也没必要屡次处理相同的请求了。

6.3.1 缓存的有效期限

对于缓存服务器和客户端浏览器，当断定缓存过时或客户端要求，会向源服务器确认资源的有效性。若失效，浏览器会再次请求新资源。

即使缓存服务器内有缓存，也不能保证每次都会返回对同资源的请求。由于这关系到被缓存资源的有效性问题。

即便存在缓存，也会由于客户端的要求、缓存的有效期等因素，向源服务器确认资源的有效性。若判断缓存失效，缓存服务器会再次从源服务器上获取"新"资源。

 

6.3.2 客户端的缓存

缓存不只能够存在于缓存服务器内，也能够存在客户端浏览器中。

浏览器缓存若是有效，就没必要再向服务器请求相同的资源了，能够直接从本地磁盘内读取。

另外，和缓存服务器相同的一点是，当断定缓存过时后，会向源服务器确认资源的有效性。若判断浏览器缓存失效，浏览器会再次请求新资源。

7、HTTP首部

HTTP协议的请求和响应报文中一定包含HTTP首部。首部内容为客户端和服务器端分别处理请求和响应提供所须要的信息。

HTTP请求报文：由方法、URI、HTTP版本、HTTP首部字段等构成。 HTTP响应报文：由HTTP版本、状态码（数字和缘由短语）、HTTP首部字段 3 部分组成。

7.1 HTTP首部字段

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

7.1.1 4种HTTP首部字段类型

HTTP首部字段根据实际通途被分为如下4种类型：

• 通用首部字段（General Header Fileds）：请求报文和响应报文两方都会使用的首部
• 请求首都字段（Request Header Fields）：从客服端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
• 响应首部字段（Response Header Fields）：从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
• 实体首部字段（Entity Header Fields）：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

7.1.2 HTTP/1.1首部字段一览

7.1.2.1 通用首部字段

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

Cache-Control的no-cache指令表明不缓存过时的资源，而不是不缓存。no-store才是真正不进行缓存。 Connection首部字段的值为close时，表明服务器想明确断开链接（HTTP/1.1默认都是持久链接）

7.1.2.2 请求首部字段

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

该表的Accept*字段均可以指定权重q（0-1）。当服务器提供多种内容时，将会首先返回权重最高的。 If-xxx请求首部字段都称为条件请求，服务器接收到附带条件的请求后，只有判断指定条件为真时，才回执行请求。 Referer 的正确拼写应该是Referrer。当直接在浏览器的地址栏输入URI时，或处于安全考虑时，可不发该首部字段。

7.1.2.3 响应首部字段

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

几乎全部浏览器在接收到包含首部字段Location的响应后，都会强制性地尝试对已提示的重定向资源的访问。

7.1.2.4 实体首部字段

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

 

7.1.2.5 为Cookie服务的首部字段

首部字段名	说明	首部类型
Set-Cookie	开始状态管理所使用的Cookie信息	响应首部字段
Cookie	服务器接收到的Cookie信息	请求首部字段

 

7.1.2.6 Set-Cookie字段的属性

属性	说明
NAME=VALUE	赋予Cookie的名称和其值（必需项）
expires=DATE	Cookie的有效期（若不明确指定则默认为浏览器关闭前为止）
path=Path	将服务器上的文件目录做为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
domain=域名	做为Cookie适用对象的域名（若不指定则默认为建立Cookie的服务器的域名）
Secure	仅在HTTPS安全通讯时才会发送Cookie
HttpOnly	加以限制，使Cookie不能被JavaSript脚本访问

expires：一旦Cookie从服务器端发送至客户端，服务器端就不存在能够显示删除Cookie的方法。但可经过覆盖已过时的Cookie，实现对客户端Cookie的实质性删除操做。 path：用来指定cookie被发送到服务器的哪个目录路径下（即被服务器哪一个路径接收cookie），其中"/"指的是站点根目录，可在同一台服务器（即便有多个应用）内共享该cookie。

8、确保Web安全的HTTPS

8.1. 什么是HTTPS？

HTTPS是 HTTP+ SSL +TLS 的产物，用于对通讯的加密、认证、完整性保护。它并非一种新的协议，而是HTTP的某些部分由SSL和TLS代理。

8.2 HTTPS如何保证通讯安全（原理）？

8.2.1 原理

咱们先来了解一下经常使用的两种加密方式：

• 对称加密： 加密和解密都是用同一把密钥。
• 非对称加密： 加密和解密是两把不一样的密钥。

HTTPS 使用混合加密机制，即先经过非对称加密交换通讯密钥，拿到密钥后再使用对称加密的方式进行后续的通讯。可是如何保证第一步中，客户端获取到的公共密钥是正确的呢？这时候，就须要用到咱们的数字证书了。

证书是由第三方机构提供认证的，服务器先去第三方机构申请公共密钥，而后会得到公共密钥和使用第三方数字签名，在非对称加密的过程当中，将数字证签名和包含的公共密钥一块儿发给客户端，客户端经过第三方机构的公共密钥对证书上的签名进行验证，一旦经过，则说明公共密钥是正确的。

 

8.2.2 请求过程

下面看看具体的安全通讯创建过程：

 

1. 客户端发起client hello 报文， 携带客户端支持的ssl版本、加密相关的约定（密钥长度和加密算法）。
2. 服务器响应 server hello 报文， 表示能够进行ssl通讯，并携带相关加密约定。
3. 服务器发送 certificate 报文, 携带了公共密钥的证书。
4. 服务器发送 server hello done，表示最初的ssl协商部分结束。
5. 客户端发起 Client Key Exchange 报文，并携带使用第一阶段协商以后获得的Pre-master

secret加密随机串（对称密钥）。

1. 客户端发起 Change Cipher Spec 报文，表示以后的请求将使用Pre-master secret进行加密通讯
2. 客户端发送 Finished 报文。该报文包含链接至今所有报文的总体校验值。此次握手协商是否可以成功，要以服务器是否可以正确解密该报文做为断定标准。
3. 服务器发送 Change Cipher Spec 报文，表示解密成功，下面将使用协商的密钥进行安全通讯。
4. 服务器发送 Finished 报文，至此，一个安全的通讯已经简历。
5. 应用层协议通讯，即发送 HTTP 响应。
6. 最后由客户端发送 close_notify 报文断开链接。

8.3 HTTPS存在的缺陷

• SSL加密致使的速度的下降和服务器负载的增大。
• 申请证书须要的开销
• 通讯使用明文可能会被窃听
• 不验证通讯方的身份就可能遭受假装
• 没法验证报文完整性，可能已遭篡改

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

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

核对的信息一般是指如下这些：

• 密码：只有本人才会知道的字符串信息
• 动态令牌：仅限本人持有的设备内显示的一次性密码
• 数字证书：仅限本人（终端）持有的信息
• 生物认证：指纹和虹膜等本人的生理信息
• IC卡等：仅限本人持有的信息

HTTP/1.1 使用的认证方式以下所示：

• BASIC认证（基本认证）
• DIGEST 认证（摘要认证）w
• SSL 客户端认证
• FormBase认证（基于表单认证）

9、基于HTTP的功能追加协议

9.1 HTTP的瓶颈

使用HTTP协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。若是服务器上没有内容更新，那么就会产生徒劳的通讯。 若想在现有Web实现所需的功能，一下这些HTTP标准就会成为瓶颈：

• 一条链接上只可发送一个请求（前面讲到，持久化可保持TCP链接状态，但仍完成一次请求/响应后才能进行下一次请求/响应，而管线化方式可以让一个TCP链接并行发送多个请求。）
• 请求只能从客户端开始。客户端不能够接收除响应之外的指令
• 请求/响应首部未经压缩就发送。首部信息越多延迟越大
• 发送冗长的首部。每次互相发送相同的首部形成的浪费较多
• 可任意选择数据压缩格式。非强制压缩发送

9.2 Comet 的解决方法

一般，服务器接收到请求，在处理完毕后就当即返回响应，但为了实现推送功能，Comet会先将响应置于挂起状态，当服务器端有内容更新时，再返回该响应。 内容上虽然能够作到实时更新，但为了保留响应，一次链接的持续时间也变长了。期间，为了维持链接会消耗更多的资源。另外，Comet仍未解决HTTP协议的自己存在的问题。

9.3 SPDY

Google 在2010年发布了 SPDY，其开发目标旨在解决HTTP的性能瓶颈，缩短Web页面的加载时间。 SPDY没有彻底改写HTTP协议，而是在TCP/IP的应用层与运输层之间经过新加会话层的形式运做。同时，考虑到安全性问题，SPDY规定通讯中使用SSL。

SPDY以会话层的形式加入，控制对数据的流动，但仍是采用HTTP创建通讯链接。所以，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP报文等。

使用 SPDY后，HTTP协议额外得到如下功能。

• 多路复用流：经过单一的TCP链接，能够无限制处理多个HTTP请求。全部请求的处理都在一条TCP链接上完成，所以TCP的处理效率获得提升。
• 赋予请求优先级：SPDY不只能够无限制地并发处理请求，还能够给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而致使响应变慢的问题。
• 压缩HTTP首部：压缩HTTP请求和响应的首部。
• 推送功能：支持服务器主动向客户端推送数据的功能。
• 服务器提示功能：服务器能够主动提示客户端请求所需的资源。因为在客户端发现资源以前就能够获知资源的存在，所以在资源已缓存等状况下，能够避免发送没必要要的请求。

9.4 使用浏览器进行全双工通讯的 WebSocket

利用Ajax和Comet技术进行通讯能够提高Web的浏览速度。但问题在于通讯若使用HTTP协议，就没法完全解决瓶颈问题。

WebSocket技术主要是为了解决Ajax和Comet里XMLHttpRequst附带的缺陷所引发的问题。

一旦Web服务器与客户端之间创建起WebSocket协议的通讯链接，以后全部的通讯都依靠这个专用协议进行。通讯过程当中可互相发送JSON、XML、HTML或图片等任意格式的数据。

WebSocket的主要特色：

• 推送功能：支持由服务器向客户端推送数据。
• 减小通讯量：和HTTP相比，不但每次链接时的总开销减小，并且因为WebSocket的首部信息很小，通讯量也相应较少。

为了实现WebSocket通讯，在HTTP链接创建以后，须要完成一次“握手”的步骤。

• 握手·请求：为了实现WebSocket通讯，须要用到HTTP的Upgrade首部字段，告知服务器通讯协议发生改变，以达到握手的目的。
• 握手·响应：对于以前的请求，返回状态码101 Switching Protocols 的响应。

成功握手确立WebSocket链接后，通讯时再也不使用HTTP的数据帧，而采用WebSocket独立的数据帧。

因为是创建在HTTP基础上的协议，所以链接的发起方还是客户端，而一旦确立WebSocket通讯链接，不论服务器端仍是客户端，任意一方均可直接向对方发送报文。

10、HTTP/2.0

10.1 历史痛点

10.1.1 HTTP1.0 时代最大的两个问题就是：

• 链接没法复用 : 每次请求都须要从新创建tcp通道，经历三次握手的过程。
• 队头阻塞：请求通道如一个独木桥，多个请求一块儿发出，只能先等第一个请求得到回包以后才能开始第二个请求，不然就只能排队等候。

10.1.2 那些年的解决之道：

10.1.2.1 解决链接没法复用：

基于tcp的长连接:

通常APP会基于TCP造一个长链接的通讯协议，门槛较高，可是一旦完成，带来的回报也是很是大的。信息的推送和更新变得及时，且在一些请求爆发点，相较于传统HTTP重复创建请求的耗时，也能减轻服务器的压力。如今业界的成熟方案如：google的protobuf。

http long-polling:

long-polling请求就是在客户端初始化的时候发起一个polling请求到服务器，而后请求一直等待中，当服务器有资源更新的时候，再返回数据，数据放回时，再次发起一个polling请求继续监听。固然，polling请求也有一些缺陷，好比 长时间的链接会增长服务器压力，复杂的业务场景下须要考虑如何才能创建健康的请求通道等。此外，这种方式有个致命的缺陷是：数据通讯是单向的，主动权在服务端这边，客户端只能根据服务端被动的接受数据，有新的业务请求的时候没法及时传送。

http streaming:

与http-polling 不一样的是， http-streaming 在初始化的的时候就发起一个不会断开的请求，持续监听服务器的回包，服务器有数据更新时就经过这个请求通道返回数据。此种方式跟http-polling同样是单向的，streaming是经过在server response的头部里增长”Transfer Encoding: chunked”来告诉客户端后续还会有新的数据到来。固然，streaming 也有缺陷: 业务数据没法按照请求来作分割，因此客户端没收到一块数据都须要本身作协议解析，也就是说要作本身的协议定制。

websocket:

WebSocket和传统的tcp socket链接类似，也是基于tcp协议，提供双向的数据通道。WebSocket优点在于提供了message的概念，比基于字节流的tcp socket使用更简单，同时又提供了传统的http所缺乏的长链接功能。websocket 通常在数据须要实时更新的场景中使用。

10.1.2.2 解决队头阻塞:

http pipelining（管线化）

管线化的前提是长链接的创建，keep-alive的多个请求使用同一个tcp链接使请求并行成为可能，pipelining与传统的请求能够形象的比喻为 串行和并行 ， 多个请求同时发起，无需等待上一个请求的回包。可是它并非救世主，也存在着缺陷：

• pipelining只适用与HTTP1.1，而且须要服务器端支持
• 队头阻塞的问题并无根本的解决，由于服务端要响应要遵循先进先出的原则，第一个请求的回包发出以后，才会响应第二个请求。

10.2 新的改变(HTTP2)

HTTP1.0和1.1的普及程度使得HTTP2必须得在不改变原有方式的状况下解决上述问题，即HTTP2 并不能像angular2那样放飞自我。因此，HTTP2的使用方式和原来的差很少，HTTP2的改变至关之多，这里主要讲一下对咱们影响较大的几点：

10.2.1 二进制

http2.0的协议解析决定采用二进制格式，实现方便且健壮。每个请求都有这些公共字段：Type, Length, Flags, Steam Identifier和frame payload。http2.0的格式定义更接近tcp层的方式，length定义了整个frame的开始到结束，type定义frame的类型（一共10种），flags用bit位定义一些重要的参数，stream id用做流控制，剩下的payload就是request的正文了。

 

10.2.2 多路复用

多路复用是HTTP2.0主要解决的一个问题，一个request对应一个stream并分配一个id，这样一个链接上能够有多个stream，每一个stream的frame能够随机的混杂在一块儿，接收方能够根据stream id将frame再归属到各自不一样的request里面。

10.2.3 头部压缩

无状态的HTTP致使每次请求都须要携带服务器所须要的参数，而一些头部信息基本上是固定的，这部分重复的信息恰好能够用于压缩，减小报文体积。

10.2.4 链接重置

HTTP 1.1的有一个缺点是：当一个含有确切值的Content-Length的HTTP消息被送出以后，你就很难中断它了。固然，一般你能够断开整个TCP连接（但也不老是能够这样），但这样致使的代价就是须要从新经过三次握手创建一个新的TCP链接。一个更好的方案是只终止当前传输的消息并从新发送一个新的。在http2里面，咱们能够经过发送RST_STREAM帧来实现这种需求，从而避免浪费带宽和中断已有的链接。

10.2.5 依赖与优先级

每一个流都包含一个优先级，优先级被用来告诉对端哪一个流更重要。从而实现资源的有效分配。

10.2.6 服务器推送

当一个客户端请求资源X，而服务器知道它极可能也须要资源Z的状况下，服务器能够在客户端发送请求前，主动将资源Z推送给客户端。这个功能帮助客户端将Z放进缓存以备未来之需。

10.2.7 流量控制

http2上面每一个流都拥有本身的公示的流量窗口，它能够限制另外一端发送数据。

11、Web攻击技术

简单的HTTP协议自己并不存在安全性问题，所以协议自己几乎不会成为攻击的对象。应用HTTP协议的服务器和客户端，以及运行在服务器上的Web应用等资源才是攻击目标。

HTTP不具有必要的安全功能，就拿远程登陆时会用到的SSH协议来讲，SSH具有协议级别的认证及会话管理等功能，HTTP协议则没有。另外在架设SSH服务方面，任何人均可以轻易地建立安全等级高的服务。而HTTP即便已假设好服务器，但开发者须要自行设计并开发认证及会话管理功能来知足Web应用的安全。而自行设计就意味着会出现各类形形色色的实现，可仍在运做的Web应用背后就会隐藏着各类容易被攻击者滥用的安全漏洞的Bug。

11.1 因输出值转义不彻底引起的安全漏洞

• 跨站脚本攻击（Cross-Site Scripting, XSS）：主要是指在用户浏览器内运行了非法的 HTML 标签或 JavaScript 脚本。好比富文本编辑器，若是不过滤用户输入的数据直接显示用户输入的HTML内容的话，就会有可能运行恶意的 JavaScript 脚本，致使页面结构错乱，Cookies 信息被窃取等问题。
• SQL注入攻击（SQL Injection）：是指针对 Web 应用使用的数据库，经过运行非法的SQL而产生的攻击。
• OS命令攻击（OS Command Injection）：是指经过 Web 应用，执行非法的操做系统命令达到攻击的目的。 只要在能调用 Shell 函数的地方就有存在被攻击的风险。
• HTTP首部注入攻击（HTTP Header Injection）：是指攻击者经过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。
• HTTP 响应截断攻击：是用在 HTTP 首部注入的一种攻击。攻击顺序相同，可是要将两个 %0D%0A%0D%0A 并排插入字符串后 发送。利用两个连续的换行就可做出 HTTP 首部与主体分隔所需的空行了，这样 就能显示伪造的主体，达到攻击的目的。
• 邮件首部注入攻击（Mail Header Injection）：是指 Web 应用中的邮件发送功能，攻击者经过向邮件首部 To 或 Subject 内任意添加非法内容发起的攻击。利用存在安全漏洞的Web网站，可对任意邮件地址发送广告邮件或 病毒邮件。
• 目录遍历攻击（Directory Traversal）：是指对本无心公开的文件目录，经过非法截断其目录路径后，达成访问目的的一种攻击。好比，经过 ../ 等相对路径定位到 /etc/passwd 等绝对路径上。
• 远程文件包含漏洞（Remote File Inclusion）： 是指当部分脚本内容须要从其余文件读入时，攻击者利用指定外部服务器的URL充当依赖文件，让脚本读取以后，就可运行任意脚本的一种攻击。

11.2 因设置或设计上的缺陷引起的安全漏洞

• 强制浏览（Forced Browsing）：是指，从安置在Web服务器的公开目录下的文件中，浏览那些本来非自愿公开的文件。好比，没有对那些须要保护的静态资源增长权限控制。
• 不正确的错误消息处理（Error Handling Vulerability）：指Web应用的错误信息内包含对攻击者有用 的信息。
• 开放重定向（Open Redirect）：是一种对指定的任意URL做重定向跳转的功能。而于此功能相关联的安全漏洞是指， 假如指定的重定向 URL 到某个具备恶意的 Web 网站，那么用户就会被诱导至那个 Web 网站。

11.3 因会话管理疏忽引起的安全漏洞

• 会话劫持（Session Hijiack）：是指攻击者经过某种手段拿到了用户的会话 ID，并不是法使用此会话 ID 假装成用户，达到攻击的目的。
• 会话固定攻击（Session Fixation）：对以窃取目标会话ID为主动攻击手段的会话劫持而言，会强制用户使用攻击者指定的会话 ID，属于被动攻击。
• 跨站点请求伪造（Cross-Site Request Forgeries, CSRF）：是指攻击者经过设置好陷阱，强制对已完成认证的用户进行非预期的我的信息或设定等某些状态更新，属于被动攻击。

11.4 其它安全漏洞

• 密码破解：①经过网络进行密码试错（穷举法和字典攻击）；②对已加密密码的破解（经过穷举法·字典攻击进行类推、彩虹表、拿到加密时使用的密钥、加密算法的漏洞）
• 点击劫持：是指利用透明的按钮或连接作成陷阱，覆盖在Web页面之上。而后诱使用户在不知情的状况下， 单击那个连接访问内容的一种攻击手段。这种行为又称为界面假装（UI Redressing）。
• Dos攻击：是一种让运行中的服务呈中止状态的攻击。有时也叫作服务中止攻击或拒绝服务攻击。多台计算机发起的 Dos 攻击称为 DDoS 攻击（Distributed Denial of Service attach） 。
• 后门程序：是指开发设置的隐藏入口（如开发阶段做为Debug调用的后门程序），可不按正常步骤使用受限功能。利用后门程序就可以使用本来受限的功能。

12、常见面试题

1. ]URI与URL的区别
   答：URI 用字符串（包括地址）标识某一个互联网资源，而URL表示资源的地点。所以URL是URI的子集。
2. 输入URL后，浏览器发生哪些变化
   下图须要补充：在从DNS服务器获取IP后，进行3次握手。 
   从服务器获取相应资源后，浏览器就会对这些资源进行相应的解析，具体可看Google Developers。
3. GET与POST的区别
   能够看看这篇文章 浅谈HTTP中Get与Post的区别。我我的认为主要的一点是：URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。 关于URL和queryString长度限制的相关连接：

• What is the maximum length of a URL in different browsers?
• What is the maximum possible length of a query string?
  所以对于GET请求时，URL超出浏览器或者服务器限制的状况，建议改为POST请求。

4. 301与302区别
   答：301是永久性重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向以后的网址。 302是临时性重定向，搜索引擎会抓取新的内容而保留旧的网址。由于服务器返回302代码，搜索引擎认为新的网址只是暂时的。
5. 为何三次握手，二次不能够吗？
   答：不能够，只有完成3次才能进行后续操做，若在握手过程当中某个阶段中断，TCP协议会再次以相同的顺序发送相同的数据包。并且，第三次握手是客户端为了让服务器知道它是否接收到响应，确保链接创建成功。
6. 为何有时候下载高清大图时，图片会一块一块地加载。
   答：这就是由于设置了http请求的长度，这样就能够分块的加载资源文件。 　　在请求报文中使用Range属性，在响应报文中使用Content-Type属性均可以指定必定字节范围的http请求。

7. 说一下什么是Http协议

   对器客户端和 服务器端之间数据传输的格式规范，格式简称为“超文本传输协议”。

8. 什么是Http协议无状态协议?怎么解决Http协议无状态协议?

       (1)、无状态协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息

       （2)、无状态协议解决办法： 经过一、Cookie 二、经过Session会话保存。

   9.说一下Http协议中302状态

        http协议中，返回状态码302表示重定向。这种状况下，服务器返回的头部信息中会包含一个 Location 字段，内容是要重定向到的Url

   10.Http协议由什么组成?

      请求报文包括三部分:

       (1).请求行:包含请求方法,URI,HTTP版本协议

       (2).请求首部字段

       (3).请求内容实体

     响应报文包含三部分:

       (1).状态行:包含HTTP版本,状态码,状态码缘由短语

       (2).响应首部字段

       (3).响应内容实体

    11.Http协议中有哪些请求方式?

  　　　　GET:用于请求访问已经被URI(统一资源标识符)识别的资源,能够经过URL传参给服务器

　　　　　 POST:用于传输信息给服务器,主要功能与GET方法相似,但通常推荐使用POST方式

　　　　 　PUT:传输文件,报文主体中包含文件内容,保存到对应URI位置

　　　   HEAD:得到报文首部,与GET方法相似,只是不返回报文主体,通常用于验证URI是否有效

       DELETE:删除文件,与PUT方法相反,删除对应URI位置的文件

       OPTIONS:查询响应URI支持的HTTP方法

    12.Http协议中Http1.0和1.1区别?

       在http1.0中，当创建链接后，客户端发送一个请求，服务器端返回一个信息后就关闭链接，当浏览器下次请求的 时候又要创建链接，显然这种不断创建链接的方式，会形成不少问题。

    13.get与post请求的区别?

       区别一:get重点在从服务器上获取资源,post重点在想服务器发送数据;

       区别二:get传输数据是经过URL请求,以filed(字段)=value的形式,置于URL后,并用"?"链接,多个请求数据之间用

            "&"链接,如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的

       区别三:get传输量小,由于受URL长度限制,但效率较低，post能够传输大量数据,因此上传文件时只能用post方式

       区别四:get是不安全的,由于URL是可见的,可能会泄露私密信息,如密码等，post较get安全

   14.常见的Http协议状态

• 200：请求被正常处理
• 204：请求被受理但没有资源能够返回
• 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中经过Content-Range指定范围的资源。
• 301：永久性重定向
• 302：临时重定向
• 303：与302状态码有类似功能，只是它但愿客户端在请求一个URI的时候，能经过GET方法重定向到另外一个URI上
• 304：发送附带条件的请求时，条件不知足时返回，与重定向无关
• 307：临时重定向，与302相似，只是强制要求使用POST方法
• 400：请求报文语法有误，服务器没法识别
• 401：请求须要认证
• 403：请求的对应资源禁止被访问
• 404：服务器没法找到对应资源
• 500：服务器内部错误
• 503：服务器正忙

  15.Http协议首部字段

• a、通用首部字段（请求报文与响应报文都会使用的首部字段）
• Date：建立报文时间
• Connection：链接的管理
• Cache-Control：缓存的控制
• Transfer-Encoding：报文主体的传输编码方式
• b、请求首部字段（请求报文会使用的首部字段）
• Host：请求资源所在服务器
• Accept：可处理的媒体类型
• Accept-Charset：可接收的字符集
• Accept-Encoding：可接受的内容编码
• Accept-Language：可接受的天然语言
• c、响应首部字段（响应报文会使用的首部字段）
• Accept-Ranges：可接受的字节范围
• Location：令客户端从新定向到的URI
• Server：HTTP服务器的安装信息
• d、实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
• Allow：资源可支持的HTTP方法
• Content-Type：实体主类的类型
• Content-Encoding：实体主体适用的编码方式
• Content-Language：实体主体的天然语言
• Content-Length：实体主体的的字节数
• Content-Range：实体主体的位置范围，通常用于发出部分请求时使用

  16.Http与Https优缺点?

     (1).通讯使用明文不加密,内容可能被窃听,也就是被抓包分析

     (2).不验证通讯方身份,可能遭到假装

     (3).没法验证报文完整性,可能被篡改

     Https就是Http加上加密处理(通常是SSL安全通讯线路)+认证+完整性保护

  16.Http优化

     利用负载均衡优化和加速HTTP应用

     利用HTTP Cache来优化网站

  17.Http协议有哪些特征?

     一、支持客户/服务器模式；二、简单快速；三、灵活；四、无链接；五、无状态；

 18.Cookie是否会被覆盖,localStorage是否会被覆盖

• Cookie是能够覆盖的，若是重复写入同名的Cookie，那么将会覆盖以前的Cookie
• 若是要删除某个Cookie，只须要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数表明其余的意义。
• localStorage存储在一个对象中. 有键值对
• 什么是localStorage,在HTML5中，新加入了一个localStorage特性，这个特性主要是用来做为本地存储来使用的，解决了cookie存储空间不足的问题(cookie中每条cookie的存储空间为4k)，localStorage中通常浏览器支持的是5M大小，这个在不一样的浏览器中localStorage会有所不一样。
• localStorage的优点
• 一、localStorage拓展了cookie的4K限制
• 二、localStorage会能够将第一次请求的数据直接存储到本地，这个至关于一个5M大小的针对于前端页面的数据库，相比于cookie能够节约带宽，可是这个倒是只有在高版本的浏览器中才支持的
• localStorage的局限
• 一、浏览器的大小不统一，而且在IE8以上的IE版本才支持localStorage这个属性
• 二、目前全部的浏览器中都会把localStorage的值类型限定为string类型，这个在对咱们平常比较常见的JSON对象类型须要一些转换
• 三、localStorage在浏览器的隐私模式下面是不可读取的
• 四、localStorage本质上是对字符串的读取，若是存储内容多的话会消耗内存空间，会致使页面变卡
• 五、localStorage不能被爬虫抓取到
• localStorage与sessionStorage的惟一一点区别就是localStorage属于永久性存储，而sessionStorage属于当会话结束的时候，sessionStorage中的键值对会被清空

 19.简述http请求的7个步骤

• 一、 创建TCP链接
• 二、 Web浏览器发送请命令
• 三、 Web浏览器发送请求头信息
• 四、 Web服务器应答,(应答第一部分是协议的版本号和应答状态码)
• 五、 Web服务器向浏览器发送应答头信息（发送被请求的文档和本身的数据）
• 六、 Web服务器向浏览器发送数据（发送头信息后，会发送一个空白行来表示头信息的发送到此结束，接着就以Content-Type应答头信息描述的格式发送用户请求的实际数据）
• 七、 Web服务器关闭TCP链接
• 注： 通常状况系，服务器在发送数据以后就会关闭TCP链接，而后若是浏览器或者服务器在其头部信息加入 Connection:keep-alive TCP链接在发送后仍然保持打开状态，因而，浏览器能够经过想用的连接发送请求，节省新创建链接所需时间，节省带宽。

 20.简述浏览器输入地址按回车键以后浏览器的执行操做

• 一、 创建tcp链接
• 二、 找到域名对应的ip
• 访问首先要找出其对应的ip地址，查找过程：在浏览器缓存中查找，而后在系统缓存查找，前面的请求发送给路由器，通常路由器会有本身的DNS缓存，系统缓存中没有就回去路由器缓存中查找，而后去ISP缓存的DNS服务器中查找，都找不到的时候
• 三、 向服务器发送http请求请求头请求体
• 四、 服务器检查处理请求
• 五、 服务器发送应答头
• 六、 服务器发送数据
• 七、 服务器关闭tcp
• 八、 浏览器读取数据
• 九、 解析成dom生成虚拟的dom树
• 十、 创建别的http请求下载css js图片其余文件
• 十一、 渲染页面
• 十二、 重绘页面