目录
1. HTTP协议的介绍：
H TTP 协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写，是用于从万维网服务器传输文本到本地浏览器的传送协议。HTTP是基于TCP/IP通信协议来传送数据。
2. HTTP工作原理：
- HTTP协议工作与客户端-服务端（C/S)架构上浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
- Web服务器有：Apache服务器，IIS服务器。
- Web服务器接收到请求后，向服务端发送响应消息。
- HTTP的默认端口是80.
3.HTTP三点注意事项：
（1）HTTP是面向连接的，但是它本身是无连接的：面向连接的意思是，HTTP协议是基于TCP/IP协议来传送数据，它本身是无连接指的是HTTP限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。--用keep-alive保持连接
(2) HTTP是无状态的：HTTP协议是无状态协议。无状态指的是协议对于事物处理没有记忆能力。缺少状态意味着如果后续处理前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大 。--解决方式：session，cookie，token
Cookie、Session和Token的作用于区别
（a）Cookie:一个具体的文本文件，由服务器生成，但保存在客户端。在客户端第一次请求后，服务器会下发一个装有客户信息的“小贴纸”，后续客户端请求服务器的时候，带上这个“小贴纸”，服务器就知道客户端的信息了。
（b）Session:服务器用于保存客户端的“一堆数据”，每个session都有一个session id,这个id会被发送给客户端进行保存。session具有失效性，过期就失效了。
（c）Token:服务器保存的session多了，资源有限的情况下必须做扩展。（类似于令牌）
·用户通过用户名和密码进行登录校验；
·服务器验证，如果验证通过则返回一个服务器端签名的token给客户端；
·客户端存储token，并且每次用于发送请求；
·服务端验证token并返回数据
（3）HTTP是媒体独立的：即只要客户端和服务器知道如何处理数据内容，并且任何类型的数据都可以通过HTTP发送。
4.HTTP请求和响应的格式:
（1）HTTP协议的请求包括【请求行、请求报头、空行、正文】
其中请求报头有一些常用的字段:
a) Content-Type：正文的数据类型
b) Content-Length:正文的长度
Content-Length及截尾操作
每条http响应都应该有精确地Content-length首部，用以描述响应主体的尺寸。一些老的HTTP服务器会省略Content-Length首部，或者包含错误的长度指示，这样就要以来服务器发出的连接关闭来说明数据的真是末尾。
客户端或代理收到一条岁连接关闭而结束的http 响应，且实际传输的实体长度与Content-Length并不匹配时，接受段就应该之一长度的正确性。如果接收端是个缓存代理，接收端就不应该缓存这条响应（以降低今后潜在的错误报文混合起来的可能）。代理应该将有问题的报文原封不动的转发出去，而不应该试图去校正Content-Length，以维护语义的透明性。
c) Host:客户端告知服务器，所有的资源是在哪个主机的哪个端口上；
d) User-Agent:声明用户的操作系统和浏览器版本信息
e) Referer：当前页面是从哪个页面跳转过来的；
f) Location：搭配3xx状态码使用，告诉客户端接下来要去哪里访问；
g) Cookie: 用于在客户端存储少量信息。
（2）HTTP协议的8种请求介绍：
a) GET:向特定的资源发出请求。
b) POST:向指定资源提交数据进行处理请求（例如提交表单或上传文件），数据被包含在请求体中。Post请求可能会导致新的资源的创建或已有的资源的修改。
c) OPTIONS:返回服务器针对特定资源所支持的HTTP请求方法。
d）HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以不必传输整个响应内容的情况下，就可以获取包含在响应报头中的元信息。
e) PUT:向指定资源位置上传最新的内容。
f）DELETE：请求服务器删除Request-URL所识的资源
g) TRACE: 回显服务器收到的请求，主要用于测试或诊断。
h) CONNECT:HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
在以上的请求方式中，最长用的是GET和POST方法。
（3）HTTP响应的格式【包括 状态行、响应包头、空行、响应正文】：
（4）HTTP常见的状态码：
5.HTTPS协议的简单介绍：
HTTPS：安全套接字层超文本传输协议，HTTPS协议在HTTP的基础上加入了SSL/TLS协议。SSL/TLS协议是依靠证书来验证服务器的身份并未浏览器和服务器之间的通信加密，相较于HTTP更安全。
6.HTTPS的作用：
（1）建立一个信息安全通道，来保证数据传输的安全；
（2）确认网站的真实性；
7.HTTS方式与Web服务器通信的步骤：
（1）客户端使用HTTPS的URL访问Web服务器，请求与服务器之间建立SSL连接；
（2）Web服务器收到客户端请求后，会将网站的证书信息（证书包含公钥）传送给客户端；
（3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，即就是信息加密的等级；
（4）客户端的浏览器根据双发同意的安全等级建立会话密钥，然后利用网站的公钥将会话密钥加密，并发送给网站；
（5）Web服务器利用会话密钥加密与客户端之间通信；
8.HTTP与HTTPS的区别：
（1）HTTPS协议需要到CA申请证书，一般免费证书比较少，因此需要一定的费用；
（2）HTTP是超文本传输协议，信息是明文传输，HTTPS是具有安全性的SSL/TSL加密传输协议；
（3）HTTP的默认端口号是80，HTTPS默认的端口号是443；
（4）HTTP的连接方式是无状态的，HTTPS协议是由SSL/TSL+HTTP协议构成的，可进行加密传输。
9.HTTPS的缺点：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长，增加电量的消耗；
（2）SSL证书需要钱，功能越强大的证书费用越高；
（3）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此受到影响；
（4）SSL证书通常需要和IP绑定，不能在同一IP是上绑定多个域名；
（5）HTTPS协议 的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到作用，而且SSL的信用链接体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
补充：
1.持久连接
Web客户端京城会打开同一个站点的连接。比如一个Web页面上的大部分内嵌图片通常都是来自同一个Web站点，而且相当一部分只想其他对象的超链接通常都是指向同一个站点。因此初始化了对某服务器HTTP请求的应用程序很可能会在不久后的将来对那台服务器发起更多的请求（比如，获取在线图片）。这种性质被称为站点本地性。
HTTP/1.1(以及HTTP/1.0的各种增强版本)允许HTTP设备在事务处理结束之后将TCP连接保持在打开状态，以便为未来的HTTP请求的重用的连接。在食物处理之后仍然保持在打开状态的TCP连接被称为持久连接。非持久连接会在每个事务结束之后关闭。持久连接会在不同事务之间保持打开状态，直到客户端或服务器决定将其关闭为止。重用一堆目标服务器打开的空闲持久连接，就可以避免缓慢的连接建立阶段。而且，已经打开的连接还可以避免慢启动的拥塞适应阶段，以便更快地进行数据的传输。
2.持久以及并行连接
并行连接可以提高复合页面的传输速度。但是并行连接也有一些缺点：
（1）每个事务都会打开或关闭一条新的连接，会耗费时间和带宽；
（2）由于TCP慢启动特性的存在，每条新连接的性能都会有所降低；
（3）可打开的并行连接数量实际上是有限的。
持久连接有一些比并行连接好的地方：
（1）持久连接降低了时延和连接建立的开销，将连接保持在已调谐的状态；
（2）减少了打开连接的潜在数量；
但是管理持久连接时要特别小心，不然就会累积出大量的空闲连接，耗费本地以及远程客户端和服务器上的资源。
2.1持久连接
持久连接与并行连接配合使用可能是最搞笑的方式。现在很多Web应用程序都会 打开少量的并行连接，其中的每一个都是持久连接。持久连接有两种类型：比较老的HTTP/1.0+"keep-alive"连接，，以及现代的HTTP/1.1 "persistent"连接：
2.1.2 HTTP/1.0+“keep-alive”连接
（1）keep-alive操作
keep-alive已经不再使用了，而且在当前的HTTP/1.1规范中也没有对它的说明了但浏览器和服务器对keep-alive握手的使用仍然相当广泛，因此，HTTP的实现者应该做好与之交互操作的准备。
实现HTTP/1.0 keep-alive连接的客户端可以通过包含Connection：Keep-alive首部请求将一条连接保持在打开状态，如果服务器愿意为下一条请求将连接保持在打开状态，就在响应中包含相同的首部，如果响应中，如果响应中没有Connection：keep-alive首部，客户端就认为服务器不支持keep-alive，会在发回响应报文之后关闭连接。
Keep-Alive选项
注意，keep-alive首部只是请求将连接保持在活跃状态。发出keep-alive请求之后，客户端和服务器并不一定会同意进行keep-alive会话。它们可以再任意时刻关闭空闲的keep-alive连接，并可随意限制keep-alive连接所处理事务的数量。
可以用Keep-alive通用首部中指定的、由逗号分隔的选项来调节keep-alive的行为。
（1）参数timeout是在keep-alive响应首部发送的。它估计了服务器希望将连接保持在活跃状态的时间。这并不是一个承诺值。
（2）参数max是在响应首部发送的。它估计了服务器还希望为多少个事务保持此连接的活跃状态。这并不是一个承诺值。
（3）keep-alive首部还可以支持任意未经处理的属性，这些属性主要用于诊断和调试。语法为name[=value]
2.1.3 Keep-alive连接的限制和规则
（1）在HTTP/1.0中，keep-alive并不是默认使用的。客户端必须发送一个Connection：keep-alive请求首部来激活keep-alive连接。
（2）Connection：keep-alive首部必须随所有保持持久连接的报文一起发送。如果客户端没有发送Connection：keep-alive首部，服务器就会在那条请求之后关闭连接。
（3）客户端探明响应中没有Connection：keep-alive响应首部，就可以知道服务器发出响应之后是否关闭连接了。
（4）只有在无需检测到联机的关闭即可确定报文实体主体部分长度的情况下，才能将连接保持在打开状态--也就是说实体的主体部分必须有正确的Content-Length，有多部件媒体类型，或者用分块传输编码的方式进行了编码。在一条Keep-alive信道中回送错误的Content-Length是很糟糕的事，这样的话，事务处理的另一端就无法精确地检测出一条报文的结束和一条波报文的开始了。
（5）代理和网关必须执行Connection首部的规则。代理或网关必须在将报文转发出去或将其告诉缓存之前，删除在Connection首部中命中的所有首部字段以及Connection首部自身，严格来说，不应该与无法确定是都支持Connection首部的代理服务器建立keep-alive连接。
（6）从技术上来讲，应该忽略所有赖在HTTP/1.0设备的Connection首部字段（包括Connection：keep-alive）,因为它们可能是由比较老的代理服务器误转发的。但实际上，金瓜可能会有在老代理上挂起的危险，有些客户端和服务器还是会违反这条规则。
（7）除非重复发送请求会产生其他一些副作用，否则如果在客户端收到完整的额响应之前连接就关闭了，客户端就一定要做好重试请求的准备。
2.1.4 Keep-alive和哑代理
Keep-Alive和哑代理比较微妙的问题。Web客户端的Connection：keep-alive首部应该只会对这条离开客户的端的TCP链路产生影响。这就是将其称作“连接”首部的原因。如果客户端正在与一台Web服务器对话，客户端可以发送一个Connection:keep-alive首部来告知服务器它希望保持连接的活跃状态。如果服务器支持keep-alive，就会送一个Connection：keep-alive首部，否则就不回送。
（1）Connection首部和盲中继
问题出在代理上：----尤其是那些不理解Connection首部，而且不知道在沿着转发链路将其发送出去之前，应该将首部删除的代理。很多老的或简单的代理都是盲中继，它们只是将字节从一个连接转发到另一个连接中去，不对Connection首部进行特殊的处理。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
