HTTP协议（超文本传送协议）

一、概念

HTTP–Hyper Text Transfer Protocol，超文本传输协议，是一种建立在TCP上的无状态连接，整个基本的工作流程是客户端发送一个HTTP请求，说明客户端想要访问的资源和请求的动作，服务端收到请求之后，服务端开始处理请求，并根据请求做出相应的动作访问服务器资源，最后通过发送HTTP响应把结果返回给客户端。
其中一个请求的开始到一个响应的结束称为事务，当一个事物结束后还会在服务端添加一条日志条目。

• TCP/IP协议
  因为HTTP协议是属于TCP/IP协议簇的，所以先简单复习一下与HTTP相关的TCP/IP知识。
  TCP/IP是一个协议簇，是由许多协议组成的。TCP/IP四层模型。按照层次从上至下分为四层：应用层，传输层，网络层，数据链路层。
  

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

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

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

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

---

• URI/URL
  统一资源标识符（英语：Uniform Resource Identifier，或URI）是一个用于标识某一互联网资源名称的字符串。 该种标识允许用户对网络中（一般指万维网）的资源通过特定的协议进行交互操作。URI的最常见的形式是统一资源定位符（URL），经常指定为非正式的网址。更罕见的用法是统一资源名称（URN），其目的是通过提供一种途径。用于在特定的名字空间资源的标识，以补充网址。统一资源名（URN）如同一个人的名称，而统一资源定位符（URL）代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。

URI格式

1. 使用 http: 或 https: 等协议方案名获取访问资源时要指定协议类型。不区分字母大小写， 最后附一个冒号（:）。也可使用 data: 或 javascript:这类指定数据或脚本程序的方案名。
2. 登录信息（认证）：指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。
3. 服务器地址： 使用绝对 URI 必须指定待访问的服务器地址。地址可以是类似hackr.jp 这种 DNS 可解析的名称，或是 192.168.1.1 这类 IPv4 地址名，还可以是 [0:0:0:0:0:0:0:1] 这样用方括号括起来的 IPv6 地址名。
4. 服务器端口号：指定服务器连接的网络端口号。此项也是可选项，若用户省略则自动使用默认端口号。
5. 带层次的文件路径：指定服务器上的文件路径来定位特指的资源。这与 UNIX 系统的文件目录结构相似。
6. 查询字符串：针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。此项可选。
7. 片段标识符：使用片段标识符通常可标记出已获取资源中的子资源（文档内的某个位置）。但在 RFC 中并没有明确规定其使用方法。该项也为可选项。

---

• HTTP的基本工作方式
  
  请求访问文本或图像等资源的一端称为客户端， 而提供资源响应的一端称为服务器端。
  无状态协议：即客户端向服务器端发送处请求时，服务器并不会存储有关客户端和请求的任何状态信息。每次的请求和响应都是独立的。

二、HTTP请求

• HTTP请求由状态行、请求头、请求正文三部分组成：
  1）状态行：包括请求方式Method、资源路径URL、协议版本Version；
  2）请求头：包括一些访问的域名、用户代理、Cookie等信息；
  3）请求正文：就是HTTP请求的数据。
  备注：请求方式Method一般有GET、POST、PUT、DELETE，含义分别是获取、修改、上传、删除，其中GET方式仅仅为获取服务器资源，方式较为简单，因此在请求方式为GET的HTTP请求数据中，请求正文部分可以省略，直接将想要获取的资源添加到URL中。

• 下图所示就是GET的请求，没有请求正文。详细的说明在下边。
  
  现在大多数协议版本为http/1.1
  下图所示为POST请求的格式，有状态行、请求头、请求正文三部分。
  

三、HTTP响应

• HTTP响应由三部分组成：状态行、响应头、响应正文；
  1）状态行：包括协议版本Version、状态码Status Code、回应短语；
  2）响应头：包括搭建服务器的软件，发送响应的时间，回应数据的格式等信息；
  3）响应正文：就是响应的具体数据。
  备注：我们主要关心并且能够在客户端浏览器看得到的是三位数的状态码，不同的状态码代表不同的含义。
  

• 具体HTTP响应实例：
  

• 常见状态码的含义

200—OK/请求已经正常处理完毕
301—/请求永久重定向
302—/请求临时重定向
304—/请求被重定向到客户端本地缓存
400—/客户端请求存在语法错误
401—/客户端请求没有经过授权
403—/客户端的请求被服务器拒绝，一般为客户端没有访问权限
404—/客户端请求的URL在服务端不存在
500—/服务端永久错误
503—/服务端发生临时错误

四、HTTP报文

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

4.1 报文结构

HTTP 报文大致可分为报文首部和报文主体两块。 两者由最初出现的空行（CR+LF） 来划分。 通常， 并不一定要有报文主体。
HTTP请求头提供了关于请求，响应或者其他的发送实体的信息。HTTP的头信息包括通用头、请求头、响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。

通用头标：即可用于请求，也可用于响应，是作为一个整体而不是特定资源与事务相关联。
请求头标：允许客户端传递关于自身的信息和希望的响应形式。
响应头标：服务器和于传递自身信息的响应。
实体头标：定义被传送资源的信息。即可用于请求，也可用于响应。

4.2 请求报文

请求报文的起始由请求行构成（有些资料称为状态行，名字不一样而已，都是指的一个东西），由Method、URL、Version三个字段组成，注意每个字段之间都有一个空格。

• 请求行
  1、其中Method字段有不同的值：
  
  2、URL字段表示服务器的资源目录定位；
  3、Version字段表示使用的http协议版本；

• 首部字段
  首部部分由多个请求头（也叫首部行）构成，那些首部字段名有如下，不全：
  Accept 指定客户端能够接收的内容格式类型
  Accept-Language 指定客户端能够接受的语言类型
  Accept-Ecoding 指定客户端能够接受的编码类型
  User-Agent 用户代理，向服务器说明自己的操作系统、浏览器等信息
  Connection 是否开启持久连接（keepalive）
  Host 服务器域名
  …

• 实体主体：主体部分就是报文的具体数据

• 实例
  

4.3 响应报文

响应报文的起始由状态行构成，用来说明服务器做了什么，由Version、Status-Code、Phrase三个字段组成，同样的每个字段之间留有空格；

• 请求行
  1、Version字段表示使用的http协议版本；
  2、Status-Code 状态码，上边已经说明；
  3、Phrase状态短语；
• 首部字段
  首部由多个响应头(也叫首部行)组成， 首部字段名如下，不全：
  Server 服务器软件名，Apache/Nginx
  Date 服务器发出响应报文的时间
  Last-Modified 请求资源的最后的修改时间
  …
• 主体部分是响应报文的具体数据。
• 实例
  
  补充：HTTP请求头和响应头

五、HTTP的Cookie 和 Session

5.1 Cookie

1. 基本概念

因为HTTP协议是无状态的，对于一个浏览器发出的多次请求，Web服务器无法区分是不是来源于同一个浏览器。所以，需要额外的数据用于维护会话。 Cookie 正是这样的一段随HTTP请求一起被传递的额外数据。 Cookie 是一小段文本信息，伴随着用户请求和页面在 Web 服务器和浏览器之间传递。Cookie 包含每次用户访问站点时 Web 应用程序都可以读取的信息。
Cookie能做什么？ Cookie只是一段文本，所以它只能保存字符串。而且浏览器对它有大小限制以及它会随着每次请求被发送到服务器，所以应该保证它不要太大。
备注：大多数浏览器支持最大为 4096 字节的 Cookie。由于这限制了 Cookie 的大小，最好用 Cookie 来存储少量数据，或者存储用户 ID 之类的标识符。用户 ID随后便可用于标识用户，以及从数据库或其他数据源中读取用户信息。 浏览器还限制站点可以在用户计算机上存储的 Cookie的数量。大多数浏览器只允许每个站点存储 20 个Cookie ；如果试图存储更多 Cookie，则最旧的 Cookie便会被丢弃。有些浏览器还会对它们将接受的来自所有站点的 Cookie 总数作出绝对限制，通常为 300 个。

2. 属性

set-cookie字段 #### 3. 工作机制 Cookie的工作机制是用户识别及状态管理。Web网站为了管理用户的状态会通过Web浏览器，把一些数据临时写入用户的计算机内，接着用户访问该Web网站的时候，可通过通信方式取回之前存的Cookie。 Cookie 会根据 从服务器端发送的响应报文内的一个叫做 **Set-Cookie 的首部字段信息** ， 通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。 服务器端发现客户端发送过来的 Cookie 后， 会去检查究竟是从哪一个客户端发来的连接请求， 然后对比服务器上的记录，最后得到之前的状态信息。

4. 缺陷

• cookie会被附加在每个HTTP请求中，所以无形中增加了流量。
• 由于在HTTP请求中的cookie是明文传递的 ，所以安全性成问题。（除非用HTTPS)
• Cookie的大小限制在4KB左右。对于复杂的存储需求来说是不够用的。

5.2 Session

Session原意是会话的意思，放在Web访问中，是指用户通过浏览器进入某一网站时，就与网站之间建立了唯一的会话关系。

1. 工作机制

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息，尽可能确保各个ID的全局唯一性。
当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识- 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

2. 服务器将session id响应返回给浏览器：

• 采用Cookie方式，采用HTTP协议中的Cookie机制，当服务器产生session id后，通过Set-Cookie扩展头将session id传送到浏览器，此后Cookie头里会携带session id信息。
• 考虑到浏览器会禁止使用Cookie，所以另一种方式是采用URL重写。就是把session id直接附加在URL路径的后面。
  附加方式也有两种，一种是作为URL路径的附加信息，表现形式为http://…/xxx;jsessionid=ByOK … 99zWpBng!-145788764
  另一种是作为查询字符串附加在URL后面，表现形式为http://…/xxx?jsessionid=ByOK … 99zWpBng!-145788764
  这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。为了在整个交互过程中始终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

5.3 Cookie 和 Session的区别

1. 存取方式的不同:
   Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二进制数据，需求先进行编码。Cookie中也不能直接存取Java对象。若要存储略微复杂的信息，运用Cookie是比较艰难的。
   而Session中能够存取任何类型的数据，包括而不限于String、Integer、List、Map等。Session中也能够直接保管JavaBean乃至任何Java类，对象等，运用起来十分便当，能够把Session看做是一个Java容器类。

2. 隐私策略的不同
   Cookie存储在客户端阅读器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上，对客户端是透明的，
   不存在敏感信息泄露的风险。假如选用Cookie，比较好的方法是，敏感的信息如账号密码等尽量不要写到Cookie中。最好是像Google、Baidu那样将Cookie信息加密，
   提交到服务器后再进行解密，保证Cookie中的信息只要本人能读得懂。而假如选择Session就省事多了，反正是放在服务器上，Session里任何隐私都能够有效的保护。

3. 有效期上的不同
   使用过Google的人都晓得，假如登录过Google，则Google的登录信息长期有效。用户不用每次访问都重新登录，Google会持久地记载该用户的登录信息。
   要到达这种效果，运用Cookie会是比较好的选择。只需要设置Cookie的过期时间属性为一个很大很大的数字。
   由于Session依赖于名为JSESSIONID的Cookie，而Cookie JSESSIONID的过期时间默许为–1，只需关闭了阅读器该Session就会失效，因而Session不能完成信息永世有效的效果。
   运用URL地址重写也不能完成。而且假如设置Session的超时时间过长，服务器累计的Session就会越多，越容易招致内存溢出。

4. 服务器压力的不同
   Session是保管在服务器端的，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十分多的Session，耗费大量的内存。
   因而像Google、Baidu、Sina这样并发访问量极高的网站，是不太可能运用Session来追踪客户会话的。
   而Cookie保管在客户端，不占用服务器资源。假如并发阅读的用户十分多，Cookie是很好的选择。关于Google、Baidu、Sina来说，Cookie或许是唯一的选择。

5. 浏览器支持的不同
   Cookie是需要客户端浏览器支持的。假如客户端禁用了Cookie，或者不支持Cookie，则会话跟踪会失效。关于WAP上的应用，常规的Cookie就派不上用场了。
   假如客户端浏览器不支持Cookie，需要运用Session以及URL地址重写。需要注意的是一切用到Session程序的URL都要进行URL地址重写，否则Session会话跟踪还会失效。
   关于WAP应用来说，Session+URL地址重写或许是它唯一的选择。
   假如客户端支持Cookie，则Cookie既能够设为本浏览器窗口以及子窗口内有效（把过期时间设为–1），也能够设为一切阅读器窗口内有效（把过期时间设为某个大于0的整数）。
   但Session只能在本阅读器窗口以及其子窗口内有效。假如两个浏览器窗口互不相干，它们将运用两个不同的Session。（IE8下不同窗口Session相干）

6. 跨域支持上的不同
   Cookie支持跨域名访问，例如将domain属性设置为“.biaodianfu.com”，则以“.biaodianfu.com”为后缀的一切域名均能够访问该Cookie。跨域名Cookie如今被普遍用在网络中，例如Google、Baidu、Sina等。而Session则不会支持跨域名访问。Session仅在他所在的域名内有效。
   仅运用Cookie或者仅运用Session可能完成不了理想的效果。这时应该尝试一下同时运用Cookie与Session。Cookie与Session的搭配运用在实践项目中会完成很多意想不到的效果。

六、HTTP的安全协议

6.1 基本概念

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层/LS层。HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。可以理解为socket+SSL+http（https是在SSL上的http，底层用了SSL，应用层协议还是http。SSL底层用的是socket，对socket传输的数据进行加解密）。

6.2 HTTPS的工作原理

（1） HTTPS涉及到的主体：
客户端:通常是浏览器(Chrome、IE、FireFox等)，也可以自己编写的各种语言的客户端程序。
服务端:一般指支持Https的网站，比如github、支付宝。
CA(Certificate Authorities)机构:Https证书签发和管理机构，比如Symantec、Comodo、GoDaddy、GlobalSign。
（2） HTTPS工作流程

基本分为三个阶段：

1. 认证服务器。浏览器内置一个受信任的CA机构列表，并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书，如果认证该服务器证书的CA机构，存在于浏览器的受信任CA机构列表中，并且服务器证书中的信息与当前正在访问的网站（域名等）一致，那么浏览器就认为服务端是可信的，并从服务器证书中取得服务器公钥，用于后续流程。否则，浏览器将提示用户，根据用户的选择，决定是否继续。当然，我们可以管理这个受信任CA机构列表，添加我们想要信任的CA机构，或者移除我们不信任的CA机构。
2. 协商会话密钥。客户端在认证完服务器，获得服务器的公钥之后，利用该公钥与服务器进行加密通信，协商出两个会话密钥，分别是用于加密客户端往服务端发送数据的客户端会话密钥，用于加密服务端往客户端发送数据的服务端会话密钥。在已有服务器公钥，可以加密通讯的前提下，还要协商两个对称密钥的原因，是因为非对称加密相对复杂度更高，在数据传输过程中，使用对称加密，可以节省计算资源。另外，会话密钥是随机生成，每次协商都会有不一样的结果，所以安全性也比较高。
3. 加密通讯。此时客户端服务器双方都有了本次通讯的会话密钥，之后传输的所有Http数据，都通过会话密钥加密。这样网路上的其它用户，将很难窃取和篡改客户端和服务端之间传输的数据，从而保证了数据的私密性和完整性。

6.3 SSL/TSL

• SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。
• TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

6.4 加密算法

1. 对称加密
   有流式、分组两种，加密和解密都是使用的同一个密钥。
   例如：DES、AES-GCM、ChaCha20-Poly1305等
   
   缺点是：
   （1）不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高
   （2）因每个客户端、服务器的安全级别不同，密钥极易泄露
2. 非对称加密
   加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。
   例如：RSA、DSA、ECDSA、 DH、ECDHE
   
   缺点：
   （1）公钥是公开的（也就是黑客也会有公钥），所以第 ④ 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容
3. 对称与非对称综合
   
   SSL 证书中包含的具体内容有：
   （1）证书的发布机构CA
   （2）证书的有效期
   （3）公钥
   （4）证书所有者
   （5）签名
4. 哈希算法
   将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。
   例如：MD5、SHA-1、SHA-2、SHA-256 等
5. 数字签名
   签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

6.5 HTTPS 缺点：

（1）SSL 证书费用很高，以及其在服务器上的部署、更新维护非常繁琐
（2）HTTPS 降低用户访问速度（多次握手）
（3）网站改用HTTPS 以后，由HTTP 跳转到 HTTPS 的方式增加了用户访问耗时（多数网站采用302跳转）
（4）HTTPS 涉及到的安全算法会消耗 CPU资源，需要增加大量机器（https访问过程需要加解密）