HTTP协议
一、HTTP 请求的组成
1、状态行
2、请求体
3、消息主体
二、HTTP 响应的组成
1、状态行
2、响应头
3、响应正文
三、HTTP 常见状态码
1、1** 信息。服务器收到请求，需要请求者继续执行操作
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols |
切换协议。服务器根据客户端的请求切换协议。 只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议 |
2、2** 成功。操作被成功接收并处理
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 200 | OK | 请求成功。一般用于 GET 和 POST 请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的 meta 信息不在原始的服务器，而是一个副本 |
| 204 | No Content |
无内容。服务器处理成功，但未返回内容。 在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content |
重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。 可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分 GET 请求 |
3、3** 重定向。需要进一步操作完成请求
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 300 | Multiple Choices |
多种选择。 请求的资源可包括多个位置， 相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently |
永久移动。 请求的资源已被永久的移动到新 URL，返回信息会包括新的 URL，浏览器会自动定向到新 URL。 今后任何新的请求都应使用新的 URL 代替 |
| 302 | Found | 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有 URL |
| 303 | See Other | 查看其它地址。与 301 类似。使用 GET 和 POST 请求查看 |
| 304 | Not Modified |
未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。 客户端通常会缓存访问过的资源， 通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。 |
| 305 | Use Proxy | 使用代码。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的 HTTP 状态码 |
| 307 | Temporary Redirect | 临时重定向。与 302 类似。使用 GET 请求重定向 |
4、4** 客户端错误。请求有语法错误或者无法完成请求
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Request | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found |
服务器无法根据客户端的请求找到资源（网页）。 通过此代码，网址设计人员可设置 “您所请求的资源无法找到” 的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与 401 类似，但请求者应当使用代理进行授权 |
| 408 | Request Tiume-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-URL Too Large | 请求的 URL 过长（URL 通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足 Expect 的请求头信息 |
5、5** 服务器错误。服务器在处理请求的过程中发生错误
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器收到了一个无效的响应 |
| 503 | Service Unavailable |
由于超载或系统维护，服务器暂时的无法处理客户端的请求。 延时的长度可包含在服务器的 Retry-After 头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的 HTTP 协议的版本，无法完成处理 |
四、HTTP GET/POST 区别
1、HTTP GET vs POST
(1) Restful 语义上一个是获取，一个是创建
(2) GET 是幂等的，POST 是非幂等的
(3) GET 请求参数放到 url(明文)，长度限制；POST 放在请求体，更安全
2、什么事幂等性？
(1) 幂等方法是无论调用多少次都得到相同结果的 HTTP 方法
(2) 例如：a = 4 是幂等的，但是 a += 4 是非幂等的
(3) 幂等的方法客户端可以安全地重发请求，不会对服务器上的数据造成影响
| HTTP Method | Idempotent | Safe |
|---|---|---|
| OPTIONS | yes | yes |
| GET | yes | yes |
| HEAD | yes | yes |
| PUT | yes | no |
| POST | no | no |
| DELETE | yes | no |
| PATCH | no | no |
注意：幂等是指多次请求的结果和请求一次的结果一样；安全指的是是否会修改数据。
五、HTTP 长连接
我们都知道 HTTP 是基于 TCP 的一个应用层协议，每一个 HTTP 请求都需要进行三步握手。如果一个页面对某一个域名有多个请求，就会进行频繁的建立连接和断开连接。所以 HTTP 1.0 中出现了 Connection: keep-alive，用于建立长连接，即我们所说的 Keep-Alive 模式。下图是普通模式和长连接模式的请求对比：
HTTP/1.0 中默认使用 Connection: close。在 HTTP/1.1 中已经默认使用 Connection: keep-alive。
1、HTTP持久连接，HTTP 1.1
(1) 短连接：建立连接...传输数据...关闭连接（连接的建立和关闭开销大）
(2) 长连接：Connection: Keep-alive。保持 TCP 连接不断开，多个 HTTP 请求发到同一个 TCP 连接 中
(3) 长连接中如何区分不同的 HTTP 请求？
a、Content-Length
Content-Length 表示实体内容的长度。浏览器通过这个字段来判断当前请求的数据是否已经全部接收。
所以，当浏览器请求的是一个静态资源时，即服务器能明确知道返回内容的长度时，可以设置 Content-Length 来控制请求的结束。
b、Transfer-Encoding
当服务器并不知道请求结果的长度时，如一个动态的页面或者数据， Content-Length 就无法解决上面的问题，这个时候就需要用到 Transfer-Encoding 字段。
Transfer-Encoding 是指传输编码，还有一个类似的字段叫做：Content-Encoding。
两者的区别：
. Content-Encoding 是用于对实体内容的压缩编码，比如Content-Encoding: gzip；
. Transfer-Encoding 则改变了报文的格式，比如上面的问题中，当服务端无法知道实体内容的长度时，就可以通过指定 Transfer-Encoding: chunked 来告知浏览器当前的编码是将数据分成一块一块传递的。
当然, 还可以指定Transfer-Encoding: gzip， chunked 表明实体内容不仅是 gzip 压缩的，还是分块传递的。
最后，当浏览器接收到一个长度为 0 的 chunked 时， 表明当前请求内容已全部接收。
六、cookie 和 session
1、cookie 详解
(1) 什么是 cookie?
cookie，有时也用其复数形式 cookies。类型为 “小型文本文件”，是某些网站为了辨别用户身份，进行 Session 跟踪而存储在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。
(2) 为什么要使用 cookie？解决了什么问题？
web 程序是使用 HTTP 协议传输的，而 HTTP 协议是无状态的协议，对于事物处理没有记忆能力。就是说网页一关闭，浏览器和服务端的连接就会断开，下次打开网页又要重新连接，服务器无法从你一打开的连接上恢复上一次的会话，服务器不知道是你又回来了。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
cookie 的出现就是为了解决这个问题。
第一次登陆后服务器返回一些数据（cookie）给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动把上次请求存储的 cookie 数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。
特点：cookie 存储的数量有限，不同的浏览器有不同的存储大小，但一般不超过 4KB。因此使用 cookie 只能存储一些小量的数据。
(3) cookie 什么时候产生？
a、cookie 的使用需要具体情况具体分析。因为浏览器可以禁用 cookie，同时服务端也可以不 Set-Cookie。
b、客户端向服务器发送一个请求时，服务端向客户端发送一个 cookie 然后浏览器将 cookie 保持。
通过设置 HTTP 的 Set-Cookie 消息头，Web 服务器可以指定存储一个 cookie。Set-Cookie 消息的格式如下面所示，括号中的部分都是可选的：
Set-Cookie:value [ ;expires=date][ ;domain=domain][ ;path=path][ ;secure]
消息头的第一部分，value 部分，通常是一个 name=value 格式的字符串。服务端向客户端发送的 HTTP 响应中设置 HTTP 的 Set-Cookie 消息头，一个具体的例子如下：
在这个例子中，服务端向客户端发送的 HTTP 消息头中，设置了 “Set-Cookie: user=ZhangSan”，客户端浏览器将接收到字符串“user=ZhangSan”作为 cookie。
c、cookie 有两种保存方式：浏览器将 cookie 保存在内存中；保存在客户端的硬盘中。之后每次 HTTP 请求浏览器都会将 cookie 发送给服务器端。
当一个 cookie 存在，并且条件允许的话，该 cookie 会在接下来的每个请求中被发送至服务器。cookie 的值被存储在名为 Cookie 的 HTTP 消息头中，并且只包含了 cookie 的值，其它的选项全部被去除。
客户端向服务端发送的 HTTP 请求中设置 Cookie 消息头，一个具体的例子如下：
在这个例子中，客户端向服务器端发送的 HTTP 消息头中，设置了“Cookie: user=ZhangSan”，服务端接收字符串“user=ZhangSan”作为 cookie，从而确认此次请求对应的用户。
(4) cookie 的工作原理？
a、浏览器端第一次发送请求到服务器端；
b、服务器端创建cookie，该 cookie 中包含用户的信息，然后将该 cookie 发送到浏览器端；
c、浏览器端再次访问服务器端时会携带服务器端创建的 cookie；
d、服务器端通过 cookie 中携带的数据区分不同的用户。
(5) cookie 的生存周期？
cookie 在生成时就会被指定一个 Expire 值，这就是 cookie 的生存周期，在这个周期内 cookie 有效，超出周期 cookie 就会被清除。
有些页面将 cookie 的生存周期设置为“0”或 负值，这样在关闭浏览器时，就马上清除 cookie，不会记录用户信息，更加安全。
(6) cookie 有哪些缺陷？
a、数量受到限制。一个浏览器能创建的 cookie 数量最多为 300 个，并且每个不能超过 4KB，每个 web 站点能设置的 cookie 总数不能超过 20 个。
b、安全性无法得到保障。通常跨站点脚本攻击往往利用网站漏洞在网站页面中植入脚本代码或网站页面引入第三方脚本代码，均存在跨站点脚本攻击的可能，在受到跨站点脚本攻击时，脚本指令将会读取当前站点的所有 cookie内容（已不存在 cookie 作用于限制），然后通过某种方式将 cookie 内容提交到指定的服务器（如：ajax）。一旦 cookie 落入到攻击者手中，它将重现其价值。
c、浏览器可以禁用 cookie。禁用 cookie 后，也就无法享有 cookie 带来的方便。
(7) cookie 的应用场景
2、session 详解
(1) web 中什么是会话？
用户打开一个浏览器，点击多个超链接，访问服务器多个 web 资源，然后关闭浏览器，整个过程称之为一个会话。
(2) 什么是 session?
session，在计算机中，尤其是在网络应用中，称为“会话控制”。session 对象存储特定用户会话所需的属性及配置信息。
session 是浏览器和服务器会话过程中，服务器分配的一块储存空间。服务器默认为浏览器在 cookie 中设置 sessionid，浏览器在向服务器请求过程中传输 cookie 包含 sessionid ，服务器根据 sessionid 获取出会话中存储的信息。
(3) session 什么时候产生？
当用户请求来自应用程序的 web 页时，如果该用户还没有会话，则 web 服务器将自动创建一个 session 对象。
这样，当用户在应用程序的 web 页之间跳转时，存储在 session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。
服务器会向客户浏览器发送一个每个用户特有的会话编号 sessionID，让它进入到 cookie 里。
服务器同时把 sessionID 和对应的用户信息、用户操作记录在服务器上，这些记录就是 session。
客户端浏览器再次访问服务器时，会发送 cookie 给服务器，其中就包含 sessionID。
服务器从 cookie 里找到 sessionID，再根据 sessionID 找到以前记录的用户信息就可以知道该用户之前的操作记录、访问历史。
(4) session 的生命周期？
根据需求设定。一般来说，半小时。举个例子，登录一个服务器，服务器返回一个 sessionID，登录成功之后的半小时之内没有对该服务器进行任何 HTTP 请求，半小时后进行一次 HTTP 请求，会提示需要重新登录，因为该 session 的生命周期已完结。
3、cookie 和 session 的区别
(1) Cookie可以存储在浏览器或者本地，Session只能存在服务器；
(2) Session比Cookie更具有安全性（Cookie有安全隐患，通过拦截或本地文件找得到你的cookie后可以进行攻击）
(3) Session占用服务器性能，Session过多，增加服务器压力
(4) 单个Cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie，Session是没有大小限制和服务器的内存大小有关。
4、cookie 和 session 的联系
(1) session是通过cookie来工作的。
(2) session和cookie之间是通过$_COOKIE['PHPSESSID']来联系的。
(3) 通过$_COOKIE['PHPSESSID']可以知道session的id，从而获取到其他的信息。
5、cookie 和 session 的联合使用
(1) 存储在服务端：通过cookie存储一个session_id，然后具体的数据则是保存在session中。如果用户已经登录，则服务器会在cookie中保存一个session_id，下次再次请求的时候，会把该session_id携带上来，服务器根据session_id在session库中获取用户的session数据。就能知道该用户到底是谁，以及之前保存的一些状态信息。这种专业术语叫做server side session。
(2) 将session数据加密，然后存储在cookie中。这种专业术语叫做client side session。flask采用的就是这种方式，但是也可以替换成其他形式。