一、简介
HTTP是（hyper text transfer prototype）超文本传输协议，基于TCP/IP通信协议来传输数据，其定义了客户端与服务器端之间文本传输的规范。HTTP默认使用80端口，这个端口指的是服务器端的端口，而客户端使用的端口是动态分配的，当我们没有指定端口访问时，浏览器会默认帮我们添加80端口。当然我们也可以自己指定访问端口。如http://www.ip.138.com:80。需要注意的是，现在大多数访问都使用HTTPS协议，而HTTPS的默认端口是443端口。
- 特点
- HTTP是无连接的：意思是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省时间。
- HTTP是媒体独立的：只要客户端和服务器知道如何处理数据内容，任何类型的数据都可以通过HTTP发送，客户端以及服务器指定使用适合的MIME-type内容类型。
- HTTP是无状态的：无状态是指协议对于事务处理没有记忆能力，缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大，另一方面，服务器不需要先前信息的时候它的应答就较快。
二、请求过程
1、应用层：发送HTTP请求
浏览器接收用户输入的域名，解析之后得到对应IP地址，浏览器会开始构造一个HTTP请求报文。其中包括：
- 请求行：请求方法、请求地址、HTTP协议版本等。例如GET /index.html HTTP/1.1。请求方法详见第三节。
- 请求头部（request headers）：由关键字/值对组成，每行一对，关键字和值之间用英文":"分隔，告诉服务器关于客户端的信息。
| Header | 解释 | 示例 |
|---|---|---|
| Host | 接受请求的服务器地址，可以是IP端口号，也可以是域名 | Host: www.zcmhi.com |
| User-Agent | 包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Accept-Charset | 通知服务端可以发送给浏览器的编码格式 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 通知服务端可以发送给浏览器的数据压缩格式 | Accept-Encoding: compress, gzip |
| Accept-Language | 通知服务端可以发送给浏览器的语言 | Accept-Language: en,zh |
- 空行：告诉服务器以下不会再有请求头。
- 请求数据：请求数据不在GET方法中使用，而是在POST方法中使用。
2、传输层：TCP传输报文
传输层会发起一条到达服务器的TCP连接，为了方便传输，会对数据进行分割，并标记编号，方便服务器接收时能够准确地还原报文信息。在建立连接前，会先进行TCP三次握手。
3、网络层：IP协议查询Mac地址
将数据段打包，并加入源及目标的IP地址，并且负责寻找传输路线。
判断目标地址是否与当前地址处于同一网络中，是的话直接根据Mac地址发送，否则使用路由表查找下一条地址，以及使用ARP协议查询其Mac地址。
注意：在OSI参考模型中ARP协议位于链路层，但在TCP/IP中，它位于网络层。
4、数据链路层：以太网协议
本层除了指明上层协议外，就是给出Mac地址，本层封装称为数据帧。最后数据帧以电流的方式传输到互联网，这些就是物理层要做的了。
此过程是一步一步封装的过程，当数据到达目的地之后，其操作与本端正好相反是一步一步解封装。
三、请求方法
根据HTTP标准，HTTP请求可以使用多种请求方法。
HTTP 1.0定义了三种请求方法：GET、POST、HEAD。
HTTP 1.1 新增了五种方法：PUT、DELETE、CONNECT、OPTIONS、TRACE。
| 方法 | 描述 |
|---|---|
| GET | 请求指定的页面，并返回实体主体。 |
| POST | 向指定资源提交数据进行处理请求(例如提交表单或上传文件)，数据被包含在请求主体中，POST请求可能会导致新的资源的建立或已有资源的修改。 |
| HEAD | 类似于GET请求，只不过返回的响应中没有具体的内容，用户获取报头。 |
| PUT | 从客户端向服务器传送的数据取代指定的文档的内容。 |
| DELETE | 请求服务器删除指定的页面 |
| CONNECT | HTTP1.1协议中预留给能够将连接改为管道方式的代理服务器。 |
| OPTIONS | 允许客户端查看服务器的性能。 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断。 |
1、GET方法
GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind,这样通过GET方式传递的数据直接表示在地址中，所以我们可以把请求结果以链接的形式发送给好友。
注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url。
2、POST方法
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 使用POST方法可以允许客户端给服务器提供信息较多。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，这样POST方式对传送的数据大小没有限制，而且也不会显示在URL中。Loadrunner中对应POST请求函数：web_submit_data,web_submit_form。
3、HEAD方法
仅请求响应的首部。HEAD就像GET，只不过服务端接受到HEAD请求后只返回响应头，而不会发送响应内容。当我们只需要查看某个页面的状态的时候，使用HEAD是非常高效的，因为在传输的过程中省去了页面内容。
4、PUT方法
向指定资源位置上传其最新内容。
5、DELETE方法
请求服务器删除Request-URL所标识的资源。DELETE请求一般会返回3种状态码：
- 200 (OK) - 删除成功，同时返回已经删除的资源
- 202 (Accepted) - 删除请求已经接受，但没有被立即执行（资源也许已经被转移到了待删除区域）
- 204 (No Content) - 删除请求已经被执行，但是没有返回资源（也许是请求删除不存在的资源造成的）
6、CONNECT方法
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7、OPTIONS方法
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘’的请求来测试服务器的功能性。
允许客户端查看服务器的性能。（常见的是跨域预检Preflighted Reqeusts方法会采用该方法）。一般来说，开发中用到该方法是用来获取服务器支持的请求类型或者查看服务器类型，来确保接下来发送的请求够安全。该请求方法的响应不能缓存。如果该URI（统一资源标识符）是一个星号（“”），OPTIONS请求将试图应用于服务器，而不是某个指定资源；如果该URI不是星号，则只能用来获取该资源通信中可用的选项。
8、TRACE方法
回显服务器收到的请求，主要用于测试或诊断。
四、HTTP响应信息
HTTP响应报文由状态行（status line）、响应头部（headers）、空行（blank line）和响应数据（response body）4个部分组成。
- 状态行：状态行由3部分组成：协议版本、状态码、状态码描述。其中协议版本和请求报文版本是一致的。如HTTP/1.1 200 OK。其中状态码详见第五节。
- 响应头部：也是由多个属性组成，一堆键值对（关键字：值）。
| header | 解释 | 示例 |
|---|---|---|
| Allow | 服务器应用程序软件的名称和版本 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Content-Type | 响应正文的MIME类型(图片或二进制) | Content-Type: text/html; charset=utf-8 |
| Content-length | 响应正文长度 | Content-Length: 348 |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Content-Encoding | 响应正文使用的数据压缩格式 | Content-Encoding: gzip |
| Content-Language | 响应正文使用的语言 | Content-Language: en,zh |
- 空行：告诉客户端以下不会再有响应头。
- 响应数据：用于存放需要返回给客户端的数据信息。
五、HTTP状态码
当用户访问一个网页时，用户的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。
HTTP状态码的英文为HTTP Status Code。状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。
- 1xx：指示信息--表示请求已接收，继续处理。
- 2xx：成功--表示请求已被成功接收、理解、接受。
- 3xx：重定向--要完成请求必须进行更进一步的操作。
- 4xx：客户端错误--请求有语法错误或请求无法实现。
- 5xx：服务器端错误--服务器未能实现合法的请求。
常见状态码如下表
| 状态码 | 状态码英文 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续，客户端继续该请求。 |
| 101 | Switching Protocols | 切换协议，服务器根据客户端的请求切换协议，只能切换到更高级的协议，例如，切换到HTTP的新版本协议。 |
| 200 | OK | 请求成功，一般用于GET与POST请求。 |
| 201 | Created | 已创建。成功请求并创建了新的资源。 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成。 |
| 203 | Non-Authoritative-Information | 非授权信息。请求成功，但返回的meta信息不在原始的服务器，而是一个副本。 |
| 204 | No Content | 无内容，服务器成功处理，但未返回内容，在未更新网页的情况下，可确保浏览器继续显示当前文档。 |
| 205 | Reset Content | 重置内容，服务器处理成功，用户终端（如浏览器）应重置文档视图，可通过此返回码清除浏览器的表单域。 |
| 206 | Partial Content | 部分内容，客户发送了一个带有Range头的GET请求，服务器完成了它。 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（如浏览器） 选择。最多允许5个地址。 |
| 301 | Moved Permanently | 永久重定向。请求的资源已被永久的移动到新的URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应该使用新的URI代替。 |
| 302 | Found | 临时重定向。与301类似，但资源是临时被移动，客户端应该继续使用原有URI。 |
| 303 | See Other | 查看其他地址，所请求的页面可以在别的UTI下被找到。与301类似，使用GET和POST请求查看。 |
| 304 | Not Modified | 未修改资源，服务器返回此状态码时，不会返回任何资源，客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问。 |
| 306 | Unused | 已经被废弃的HTTP状态码。 |
| 307 | Temporary Redirect | 临时重定向，与302类似，使用GET请求重定向。hsts跳转，要求浏览器下次访问该站点时使用https来访问，而不再需要先是http再转https。这样可以避免ssl剥离攻击。 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解。 |
| 401 | Unauthorized | 未授权。请求要求用户的身份认证。 |
| 402 | Payment Required | 保留，将来使用。 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行该请求。 |
| 404 | Not Found | 页面不存在。服务器无法根据客户端的请求找到资源，通过此代码，开发人员可设置"您所请求的资源无法找的"的个性页面。 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止。 |
| 406 | Not Acceptable | 服务器生成的响应无法被客户端所接受。 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权。 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时。 |
| 409 | Conflict | 服务器完成客户端的PUT请求时可能返回此代码，服务器处理请求时发生了冲突。 |
| 410 | Gone | 客户端请求的资源已经不存在，410不同于404，如果资源以前有现在被永久删除了可使用410代码，开发人员可通过301代码指定资源的新位置。 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-length的请求信息。 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误。 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求，为防止客户端的连续请求，服务器可能会关闭连接，如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息。 |
| 414 | Request-URI Too Large | 请求的URI过长，URI通常为网址，服务器无法处理。 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式。 |
| 416 | Requested range not satisflable | 服务器不能满足客户在请求中指定的Range头。 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息。 |
| 500 | Internal Server Error | 服务器内部错误。无法完成请求。 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求。 |
| 502 | Bad Gateway | 充当网关或代理的服务器，从远端服务器接收到了一个无效的请求。 |
| 503 | Service Unavallable | 由于超载或系统维护，服务器暂时无法处理客户端的请求，延时的长度可包含在服务器的Retry-After头信息中。 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求。 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理。 |
六、HTTP请求GET和POST的区别
1、GET提交：请求的数据会附在URL之后，并且请求一次。
以？分割URL和传输数据，多个参数用&连接。如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送；如果是空格，转换为+；如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。
POST提交：把提交的数据放在request body 中，请求两次。
2、GET请求只能进行URL编码，而POST支持多种编码方式。
3、GET请求参数会被完整保留在浏览器历史记录里，而POST参数不会保留。
4、GET请求的参数长度有限，而POST没有。
5、GET请求参数的数据类型是ASCII字符，而POST没有限制。
6、GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
7、GET请求会被浏览器主动cache，而POST不会，除非手动设置。
8、GET在浏览器回退时是无害的，而POST会再次提交请求。
9、GET产生的URL地址可以被记录书签（Bookmark），而POST不可以。
10、GET提交的数据最大是2K，这个限制实际上取决于浏览器，(大多数)浏览器通常都会限制url长度在2K个字节，即使(大多数)服务器最多处理64K大小的url。也没有卵用。post理论上没有限制。实际上IIS4中最大量为80KB，IIS5中为100KB。
11、GET和POST本质上都是TCP连接。GET产生一个TCP数据包；POST产生两个TCP数据包。
对于GET来说，浏览器会把HTTP header 和 data 一起打包发出去，服务器响应返回200。
对于POST来说，浏览器会先发送header，服务器响应返回100（continue），浏览器再发送data，服务器响应返回200。
据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
七、HTTP和HTTPS的区别
HTTP（Hyper Text Transfer Protocol，超文本传输协议）被用于在web浏览器和网站服务器之间传递信息，HTTP协议以明文的方式发送内容，不提供任何方式的数据加密，如果攻击者截取了web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号，密码等支付信息。
HTTPS（Hyper Text Transfer Protocol over Secure Socket Layer，安全套接字超文本传输协议），为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL/TLS，依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。其中SSL（Secure Socket Layer，安全套接层）加密传输协议，TLS（Transport Layer Securit，传输层安全协议），SSL 3.0和TLS 1.0差别很小，在HTTPS通信中具体使用哪一个还要看客户端和服务端的支持程度，二者在网络模型中位于哪一层？
HTTP协议和HTTPS协议位于应用层。TCP协议和UDP协议位于传输层。IP协议位于网络层。
- 区别
① HTTPS协议需要到CA申请证书，一般免费证书比较少，所以需要一定费用。
② HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。
③ HTTP和HTTPS使用的是完全不同的连接方式，使用的端口号也不一样，前者是80，后者是443。
④ HTTP连接很简单，是无状态的；HTTPS协议是由HTTP+SSL协议构建的可进行加密传输，身份认证的网络协议，比较安全。
⑤ 谷歌搜索引擎算法中，比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中排名会更高。
- 客户端使用HTTPS方式与web服务器通信的步骤
- 客户使用HTTPS的URL访问web服务器，要求与web服务器建立SSL连接；
- web服务器收到客户端请求后，将网站的证书信息（证书中包含公钥）传送一份给客户端，这个证书其实是一套公钥和私钥，这里把公钥给了客户端，相当于锁头，私钥（唯一）服务器保留，相当于钥匙。
- 客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息的加密等级。
- 客户端解析证书：这部分工作由客户端的TLS（Transport Layer Securit，传输层安全协议）来完成。首先验证公钥是否有效，比如颁发机构、过期时间等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么会生成一个随机值，然后用证书对这个随机值加密，把随机值用锁头锁起来，这样除非有钥匙，否则看不到被锁住的内容。
- 传送加密信息：这部分传送的是用证书加密后的随机值，目的就是让服务器得到这个随机值，以后客户端和服务端之间的通信就可以通过这个随机值来进行加密解密了。
- 服务端解密信息：服务端用私钥解密后，得到了客户端传过来的随机值（私钥），然后把内容通过该值进行非对称加密，所谓非对称加密，就是将信息和私钥通过某种算法混合在一起，这样除非知道私钥，否则无法获取内容，而恰好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。对称加密就是使用同样的算法和密钥对密文进行解密，加密-解密过程完全对称。
- 传输加密后的信息：这部分信息是服务端用私钥加密后的信息，可以再客户端被还原。
-
客户端解密信息：客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。
https.png
- 如何从HTTP切换到HTTPS？
1、 需要将页面中所有的链接例如js、css、图片等链接都由http改为https
2、一般情况下会建议保留http，所以在切换的时候可以做http和https的兼容，具体方式是：去掉页面连接中的http头部，这样可以自动匹配http头和https头。
八、关于HTTP2.0
1、简介
简单来说，HTTP/2 超文本传输协议第2版，是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协议。HTTP 2.0的特点是：在不改动HTTP语义、方法、状态码、URI及首部字段的情况下，大幅度提高了web性能。
2、什么是SPDY协议
SPDY是Speedy 的呢音，意为“更快”。它是2012年google开发的基于TCP协议的应用层协议。目标是优化HTTP协议的性能，通过压缩、多路复用、优先级等技术，缩短网页的加载时间并提高安全性，SPDY协议的核心思想是尽量减少TCP连接数，它是对HTTP协议的一种增强。
SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议，同时可以使用已有的SSL功能。
3、HTTP1.x 的缺点
任何事物的更新都是为了弥补或修复上个版本的某些问题，我们来看看HTTP 1.x有哪些问题：
① HTTP/1.0 一次只允许在一个TCP连接上发起一个请求，HTTP/1.1 使用的流水线技术也只能部分处理请求并发，仍然会存在队列头阻塞问题，因此客户端在需要发起多次请求时，通常会采用建立多连接来减少延迟。
② 单向请求，只能由客户端发起。
③ 请求报文和响应报文首部信息冗余量大。
④ 数据未压缩，导致数据的传输量大。
4、HTTP 2.0特点
a. 二进制传输
HTTP 2.0中所有加强性能的核心是二进制传输，在HTTP 1.x中，我们是通过文本的方式传输数据，基于文本的方式传输数据存在很多缺陷，文本的表现形式有多样性，因此要做到健壮性考虑的场景必然有很多，但是二进制则不同，只有0和1的组合，因此选择了二进制传输，实现方便且健壮。
在HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。
为了保证HTTP不受影响，那就需要在应用层（HTTP 2.0）和传输层（TCP或UDP）之间增加一个二进制分帧层，在二进制分帧层上，HTTP 2.0会将所有传输的信息分为更小的信息和帧，并采用二进制格式编码，其中HTTP 1.x的首部信息会被封装在Headers 帧，而Request Body 则封装在 Data 帧。
b. 多路复用
在HTTP 1.0 中，我们经常会使用到雪碧图、使用多个域名等方式来优化，都是因为浏览器限制了同一个域名下的请求数量，当页面需要请求很多资源时，队头阻塞会导致在达到最大请求时，资源需要等待其他资源请求完成后才能继续发送。
而在HTTP 2.0中，有两个概念很重要：帧（frame）和流（stream）
帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流。
所谓多路复用，就是在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的标识知道该帧属于哪个请求。在客户端，这些帧乱序发送，到达对端后再根据每个帧首部的流标识符重新组装。通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性。
c. Header 压缩
在HTTP 1.0中，我们使用文本的形式传输header，在header中携带cookie的话，每次都需要重复传输几百到几千的字节，这着实是一笔不小的开销。
在HTTP 2.0 中，我们使用了HPACK（HTTP2 头部压缩算法）压缩格式对传输的header进行编码，减少了header的大小，并在两端维护了索引表，用于记录出现过的header，后面在传输过程中就可以传输已经记录过的header的键名，对端收到数据后就可以通过键名找到对应的值。
注：SPDY 采用的 DEFLATE头部压缩算法。
d. 服务器Push
在HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。试想，某些资源客户端是一定会请求的，这时就可以采取服务器Push的技术，提前给客户端推送它必要的资源，就可以相对减少一点延迟时间，在浏览器兼容的情况下也可以使用prefetch。
e. 更安全
HTTP 2.0 使用了TLS的拓展ALPN作为协议升级，除此之外，HTTP 2.0 对TLS的安全性做了进一步加强，通过黑名单机制禁用了几百种不再安全的加密算法。
注：HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS。
f. 请求优先级（Request prioritization）
多路复用带来一个问题，在连接共享的基础上有可能会导致关键请求被阻塞，SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的HTML内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样能保证用户能第一时间看到网页内容。
注：HTTP请求头和响应头参考对照表传送门→_→http://tools.jb51.net/table/http_header