每日一问22——HTTP

简介

超文本传输协议（Hypertext Transfer Protocol，简称HTTP）是应用层协议。HTTP 是一种请求/响应式的协议，即一个客户端与服务器建立连接后，向服务器发送一个请求；服务器接到请求后，给予相应的响应信息。

首先我们要知道HTTP协议的工作是建立在TCP协议之上的，所以理解报文结构对我们学习http协议非常重要。

HTTP请求报文

http请求报文由请求行，请求头部，空行以及请求包体组成，如下图所示：

20150126110657264.png

1.请求头

由请求方法，URL以及协议版本三部分组成，每个部分以空格分隔。常用的请求方法有：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT；

• GET：当客户端要从服务器中读取某个资源时，使用GET 方法。GET 方法要求服务器将URL 定位的资源放在响应报文的数据部分，回送给客户端，即向服务器请求某个资源。使用GET 方法时，请求参数和对应的值附加在 URL 后面，利用一个问号（“?”）代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。
• POST：当客户端给服务器提供信息较多时可以使用POST 方法，POST 方法向服务器提交数据，比如完成表单数据的提交，将数据提交给服务器处理。GET 一般用于获取/查询资源信息，POST 会附带用户数据，一般用于更新资源信息。POST 方法将请求参数封装在HTTP 请求数据中，以名称/值的形式出现，可以传输大量数据；

2.请求头部

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

• User-Agent：产生请求的浏览器类型；
• Accept：客户端可识别的响应内容类型列表；星号 “ ” 用于按范围将类型分组，用 “ / ” 指示+ 可接受全部类型，用“ type/ ”指示可接受 type 类型的所有子类型；
• Accept-Language：客户端可接受的自然语言；
• Accept-Encoding：客户端可接受的编码压缩格式；
• Accept-Charset：可接受的应答的字符集；
• Host：请求的主机名，允许多个域名同处一个IP 地址，即虚拟主机；
• connection：连接方式（close 或 keepalive）；
• Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie；

3.空行

最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头；

4.请求包体

请求包体不在 GET 方法中使用，而是在POST 方法中使用。POST 方法适用于需要客户填写表单的场合。与请求包体相关的最常使用的是包体类型 Content-Type 和包体长度 Content-Length；

HTTP响应报文

HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成，如下图所示：

20150126110634828.png

1.状态行

状态行由 HTTP 协议版本字段、状态码和状态码的描述文本 3 个部分组成，他们之间使用空格隔开；

状态码由三位数字组成，第一位数字表示响应的类型，常用的状态码有五大类如下所示：

• 1xx：表示服务器已接收了客户端请求，客户端可继续发送请求；
• 2xx：表示服务器已成功接收到请求并进行处理；
• 3xx：表示服务器要求客户端重定向；
• 4xx：表示客户端的请求有非法内容；
• 5xx：表示服务器未能正常处理客户端的请求而出现意外错误；
  状态码描述文本有如下取值：
• 200 OK：表示客户端请求成功；
• 400 Bad Request：表示客户端请求有语法错误，不能被服务器所理解；
• 401 Unauthonzed：表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用；
• 403 Forbidden：表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因；
• 404 Not Found：请求的资源不存在，例如，输入了错误的URL；
• 500 Internal Server Error：表示服务器发生不可预期的错误，导致无法完成客户端的请求；
• 503 Service Unavailable：表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常；

2.响应头部

响应头可能包括：

• Location：Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源；
  Server：Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。
• Vary：指示不可缓存的请求头列表；
• Connection：连接方式； 对于请求来说：close（告诉 WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不等待本次连接的后续请求了）。 keepalive（告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求）； 对于响应来说：close（连接已经关闭）； keepalive（连接保持着，在等待本次连接的后续请求）； Keep-Alive：如果浏览器请求保持连接，则该头部表明希望WEB 服务器保持连接多长时间（秒）；例如：Keep-Alive：300；
• WWW-Authenticate：WWW-Authenticate响应报头域必须被包含在401 (未授权的)响应消息中，这个报头域和前面讲到的Authorization 请求报头域是相关的，当客户端收到 401 响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了Authorization 报头域的请求；

3.空行

最后一个响应头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有响应头部。

4.响应包体

服务器返回给客户端的文本信息；

HTTP 工作原理

HTTP 协议采用请求/响应模型。客户端向服务器发送一个请求报文，服务器以一个状态作为响应。
以下是 HTTP 请求/响应的步骤：

• 客户端连接到web服务器：HTTP 客户端与web服务器建立一个 TCP 连接；

• 客户端向服务器发起 HTTP 请求：通过已建立的TCP 连接，客户端向服务器发送一个请求报文；

• 服务器接收 HTTP 请求并返回 HTTP 响应：服务器解析请求，定位请求资源，服务器将资+ + 源副本写到 TCP 连接，由客户端读取；

• 释放 TCP 连接：若connection 模式为close，则服务器主动关闭TCP 连接，客户端被动关闭连接，释放TCP 连接；若connection 模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求；

• 客户端浏览器解析HTML内容：客户端将服务器响应的 html 文本解析并显示；

  例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：
  1.浏览器向 DNS 服务器请求解析该 URL 中的域名所对应的 IP 地址；
  2.解析出 IP 地址后，根据该 IP 地址和默认端口 80，和服务器建立 TCP 连接；
  3.浏览器发出读取文件（URL 中域名后面部分对应的文件）的HTTP 请求，该请求报文作为 TCP 三次握手的第三个报文的数据发送给服务器；
  4.服务器对浏览器请求作出响应，并把对应的 html 文本发送给浏览器；
  5.释放 TCP 连接；
  6.浏览器将该 html 文本并显示内容;

HTTP 无状态性

HTTP 协议是无状态的（stateless）。也就是说，同一个客户端第二次访问同一个服务器上的页面时，服务器无法知道这个客户端曾经访问过，服务器也无法分辨不同的客户端。HTTP 的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP 请求。

HTTP 持久连接

我们知道 HTTP 协议采用“请求-应答”模式，当使用普通模式，即非 Keep-Alive 模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用 Keep-Alive 模式（又称持久连接、连接重用）时，Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive 功能避免了建立或者重新建立连接。

在 HTTP 1.0 版本中，并没有官方的标准来规定 Keep-Alive 如何工作，因此实际上它是被附加到 HTTP 1.0协议上，如果客户端浏览器支持 Keep-Alive ，那么就在HTTP请求头中添加一个字段 Connection: Keep-Alive，当服务器收到附带有 Connection: Keep-Alive 的请求时，它也会在响应头中添加一个同样的字段来使用 Keep-Alive 。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过 Keep-Alive 规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

在 HTTP 1.1 版本中，默认情况下所有连接都被保持，如果加入 "Connection: close" 才关闭。目前大部分浏览器都使用 HTTP 1.1 协议，也就是说默认都会发起 Keep-Alive 的连接请求了，所以是否能完成一个完整的 Keep-Alive 连接就看服务器设置情况。

由于 HTTP 1.0 没有官方的 Keep-Alive 规范，并且也已经基本被淘汰，以下讨论均是针对 HTTP 1.1 标准中的 Keep-Alive 展开的。

注意：

• HTTP Keep-Alive 简单说就是保持当前的TCP连接，避免了重新建立连接。

• HTTP 长连接不可能一直保持，例如 Keep-Alive: timeout=5, max=100
  ，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。

• HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果。

• 使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1. 判断传输数据是否达到了Content-Length 指示的大小；2. 动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked 编码来判断，chunked 编码的数据在最后有一个空 chunked 块，表明本次传输数据结束，详见这里。什么是 chunked 分块传输呢？下面我们就来介绍。

Transfer-Encoding: chunked（分块编码）

对于持久连接来讲浏览器不能通过连接是否关闭来界定请求或响应实体的边界，当我们发送完数据后，浏览器并不知道，所以无法第一时间关闭连接，当再次访问的时候就会出现等待的情况。
Transfer-Encoding 正是用来解决上面这个问题的，最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。
分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF（\r\n），也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。

require('net').createServer(function(sock) {
    sock.on('data', function(data) {
        sock.write('HTTP/1.1 200 OK\r\n');
        sock.write('Transfer-Encoding: chunked\r\n');
        sock.write('\r\n');

        sock.write('b\r\n');
        sock.write('01234567890\r\n');

        sock.write('5\r\n');
        sock.write('12345\r\n');

        sock.write('0\r\n');
        sock.write('\r\n');
    });
}).listen(9090, '127.0.0.1');

上面这个例子中，我在响应头中表明接下来的实体会采用分块编码，然后输出了 11 字节的分块，接着又输出了 5 字节的分块，最后用一个 0 长度的分块表明数据已经传完了。用浏览器访问这个服务，可以得到正确结果。可以看到，通过这种简单的分块策略，很好的解决了前面提出的问题。

HTTP Pipelining（HTTP 管线化）

默认情况下 HTTP 协议中每个传输层连接只能承载一个 HTTP 请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3。

HTTP Pipelining（管线化）是将多个 HTTP 请求整批提交的技术，在传送过程中不需等待服务端的回应。使用 HTTP Pipelining 技术之后，某个连接上的消息变成了类似这样请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3。

注意下面几点：

• 管线化机制通过持久连接（persistent connection）完成，仅 HTTP/1.1 支持此技术（HTTP/1.0不支持）
• 只有 GET 和 HEAD 请求可以进行管线化，而 POST 则有所限制
• 初次创建连接时不应启动管线机制，因为对方（服务器）不一定支持 HTTP/1.1 版本的协议
• 管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变
  HTTP /1.1 要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可
• 由于上面提到的服务器端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如 Chrome 和 Firefox 默认并未开启管线化支持

会话跟踪

1.什么是会话？
客户端打开与服务器的连接发出请求到服务器响应客户端请求的全过程称之为会话。

2.什么是会话跟踪？
会话跟踪指的是对同一个用户对服务器的连续的请求和接受响应的监视。

3.为什么需要会话跟踪？
浏览器与服务器之间的通信是通过HTTP协议进行通信的，而HTTP协议是”无状态”的协议，它不能保存客户的信息，即一次响应完成之后连接就断开了，下一次的请求需要重新连接，这样就需要判断是否是同一个用户，所以才有会话跟踪技术来实现这种要求。

4.会话跟踪常用的方法:
1>URL重写
URL(统一资源定位符)是Web上特定页面的地址，URL重写的技术就是在URL结尾添加一个附加数据以标识该会话,把会话ID通过URL的信息传递过去，以便在服务器端进行识别不同的用户。

2>隐藏表单域
将会话ID添加到HTML表单元素中提交到服务器，此表单元素并不在客户端显示

3>Cookie
Cookie是Web服务器发送给客户端的一小段信息，客户端请求时可以读取该信息发送到服务器端，进而进行用户的识别。对于客户端的每次请求，服务器都会将Cookie发送到客户端,在客户端可以进行保存,以便下次使用。

客户端可以采用两种方式来保存这个Cookie对象，一种方式是保存在客户端内存中，称为临时Cookie，浏览器关闭后这个Cookie对象将消失。另外一种方式是保存在客户机的磁盘上，称为永久Cookie。以后客户端只要访问该网站，就会将这个Cookie再次发送到服务器上，前提是这个Cookie在有效期内，这样就实现了对客户的跟踪。

Cookie是可以被禁止的。

4>Session:
每一个用户都有一个不同的session，各个用户之间是不能共享的，是每个用户所独享的，在session中可以存放信息。

在服务器端会创建一个session对象，产生一个sessionID来标识这个session对象，然后将这个sessionID放入到Cookie中发送到客户端，下一次访问时，sessionID会发送到服务器，在服务器端进行识别不同的用户。

Session的实现依赖于Cookie，如果Cookie被禁用，那么session也将失效。

相关文章

HTTP协议·笔试面试知识整理
http协议
HTTP 协议中的 Transfer-Encoding