状态码：
- 206 客户发送了一个带有Range头的GET请求，服务器完成了它
- 301 永久性转移
- 302 临时性转移
- 400 请求格式错误
- 401 被请求的页面需要用户名和密码
- 403 对被请求页面的访问被禁止
- 405 请求中指定的方法不被允许
- 500 服务器端错误
request和response区别
- request 网址栏不会变，属于内部跳转
- response 网址栏会变，会让服务器调到新的页面
cookie？
- 介绍
- HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务。HTTP/1.1 引入 Cookie 来保存状态信息。
- Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。
- 现在随着现代浏览器开始支持各种各样的存储方式，Cookie 渐渐被淘汰。新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API （本地存储和会话存储）或 IndexedDB。
- 使用场景
- 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息
- 个性化设置（如用户自定义设置、主题等）
- 浏览器行为跟踪（如跟踪分析用户行为等）
Session？
- 利用 Session 存储在服务器端，存储在服务器端的信息更加安全。但是还是要注意，SessionID——在Redis中为key 不能太简单，要进行加密处理
- 可以使用Redis来存储Session更高效
- 与cookie使用抉择？
- Cookie 只能存储 ASCII 码字符串，而 Session 则可以存取任何类型的数据，因此在考虑数据复杂性时首选 Session；
- Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；
- 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。
restful？
- 一套基于资源定位的设计风格
POST和GET？
GET
- 请求可被缓存
- 请求有长度限制
- 请求不应在处理敏感数据时使用
- 浏览器通常都会限制url长度在2K个字节，而(大多数)服务器最多处理64K大小的url
- GET产生一个TCP数据包
POST
- 请求不会被缓存
- 对数据长度没有要求
- POST产生两个TCP数据包
- 工作方式区别
- 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200(返回数据);
- 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。
- 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次