HTTP是面向事务的，即它传输的数据是一个整体，要么全部收到，要么全部收不到。

每一次HTTP请求就需要建立一次TCP连接和释放TCP连接。

HTTP是无连接，无状态的。每一次请求都是作为一次新请求。

HTTP/1.0 缺点: 无连接，每一次请求都要重新建立TCP连接，所以每一次HTTP请求都要花费2倍RTT时间(一次TCP请求，一次HTTP请求)

HTTP/1.1: 使用持续连接，即保持TCP连接一段时间。

HTTP/1.1持续工作的两种工作方式 : 非流水线方式和流水线方式

    ● 非流水线方式 : 收到一个请求的响应再发下一个请求，效率低，浪费资源

    ● 流水线方式 : 能够同时发送多个请求，效率高

HTTP协议包括哪些请求？

GET：请求读取由URL所标志的信息。

POST：给服务器添加信息（如注释）。

PUT：在给定的URL下存储一个文档。

DELETE：删除给定的URL所标志的资源。

GET与POST之间的区别主要包括如下五个方面：

(1). 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；

(2). 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；

(3). 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的 请求头 中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体中。

(4). 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。

(5). 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

Session、Cookie与Application

Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

(1).Cookie

HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务。HTTP/1.1 引入 Cookie 来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。

Cookie 曾一度用于客户端数据的存储，因为当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。

Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

(2). Session

除了可以将用户信息通过Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

使用Session 维护用户登录状态的过程如下：

● 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；

● 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为Session ID；

● 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；

● 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。

应该注意Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

浏览器禁用Cookie

此时无法使用Cookie 来保存用户信息，只能使用 Session。除此之外，不能再将 Session ID 存放到 Cookie 中，而是使用 URL 重写技术，将Session ID 作为 URL 的参数进行传递。

(3).

Session 与 Cookie 的对比与选择

对比：

实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID；

大小限制：Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制，Session没有大小限制，理论上只与服务器的内存大小有关；

安全性：Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端，相对更加安全；

服务器资源消耗：Session是保存在服务器端上会存在一段时间才会消失，如果session过多会增加服务器的压力

Cookie 与 Session 选择

Cookie 只能存储 ASCII 码字符串，而 Session 则可以存取任何类型的数据，因此在考虑数据复杂性时首选 Session；

Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；

对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。

(4).Application

Application（Java Web中的ServletContext）：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。

常见状态码及原因短语

HTTP请求结构：请求方式 + 请求URI + 协议及其版本

HTTP响应结构：状态码 + 原因短语 + 协议及其版本

1×× : 请求处理中，请求已被接受，正在处理

2×× : 请求成功，请求被成功处理

200 OK

3×× : 重定向，要完成请求必须进行进一步处理

301 : 永久性转移

302 ：暂时性转移

304 ： 已缓存

4×× : 客户端错误，请求不合法

400：Bad

Request,请求有语法问题

403：拒绝请求

404：客户端所访问的页面不存在

5×× : 服务器端错误，服务器不能处理合法请求

500 ：服务器内部错误

503 ： 服务不可用，稍等

各种协议与HTTP协议之间的关系

HTTP长连接、短连接

长连接只需要建立一次TCP 连接就能进行多次 HTTP 通信。

    ● 从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；

    ● 在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次TCP连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

Http和Https的区别

HTTP 有以下安全性问题：

● 窃听风险：使用明文进行通信，内容可能会被窃听；

● 冒充风险：不验证通信方的身份，通信方的身份有可能遭遇伪装；

● 篡改风险：无法证明报文的完整性，报文有可能遭篡改。

HTTPs 并不是新协议，而是让 HTTP 先和 SSL（Secure

Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说HTTPs 使用了隧道进行通信。SSL/TLS协议就是为了解决这些风险而设计，希望达到：

（1）所有信息加密传输，防止三方窃听通信内容；

（2）具有校验机制，内容一旦被篡改，通信双方立刻会发现；

（3）配备身份证书，防止身份被冒充。

通过使用SSL，HTTPs 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

HTTPs 的加密方式

Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。也即使用非对称密钥加密用于传输对称密钥来保证传输过程的安全性，之后使用对称密钥加密进行通信来保证通信过程的效率。

SSL加密原理：

基本思路是采用公钥加密法（最有名的是RSA加密算法）。大概流程是，客户端向服务器索要公钥，然后用公钥加密信息，服务器收到密文，用自己的私钥解密。

为了防止公钥被篡改，把公钥放在数字证书中，证书可信则公钥可信。公钥加密计算量很大，为了提高效率，服务端和客户端都生成对话密钥，用它加密信息，而对话密钥是对称密钥，速度非常快。而公钥用来加密对话私钥。

Https加密过程：

http://www.mahaixiang.cn/internet/1233.html

自己简述：

客户端在浏览器中输入一个https网址，然后连接到server的443端口

采用https协议的server必须有一套数字证书（一套公钥和密钥）

首先server将证书（公钥）传送到客户端，客户端解析证书，验证成功，则生成一个随机数（私钥），并用证书将该随机数加密后传回server

server用密钥解密后，获得这个随机值，然后将要传输的信息和私钥通过某种算法混合在一起（加密）传到客户端

客户端用之前的生成的随机数（私钥）解密服务器端传来的信息

HTTPs的认证

通过使用证书 来对通信方进行认证。

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

服务器的运营人员向CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

进行HTTPs 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

HTTPs完整性保护

SSL 提供报文摘要功能来进行完整性保护。

HTTP 也提供了MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

HTTPs 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

HTTPs 的缺点

● 因为需要进行加密解密等过程，因此速度会更慢；

● 需要支付证书授权的高额费用。

HTTPS协议在HTTP协议的基础上，在HTTP和TCP中间加入了一层SSL/TLS加密层，解决了HTTP不安全的问题:冒充，篡改，窃听三大风险。Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure

Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

二者之间存在如下不同：

（1）端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；

（2）资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；

（3）开销：Https通信需要证书，而证书一般需要向认证机构购买；

（4）Http协议建立连接的过程比Https协议快。因为Https除了TCP三次握手，还要经过SSL握手。连接建立之后的数据传输速度，二者无明显区别。

（5）Http连接是无状态的，而Https采用Http+SSL构建可进行加密传输、身份认证的网络协议，更安全。