第三章 web阶段

什么是HTTP协议 ?
●必答内容：
HTTP协议就是 "超文本传输协议"，规定了客户端与服务器端数据通信的规则。 而HTTP协议，它的底层是基于TCP协议的，而TCP协议呢，是面向连接、安全且无状态的协议。
那在现在的Web开发中，基本上所有的请求都是基于HTTP协议 或 HTTPS协议的。
●可能追问的问题：
1). 那HTTP协议与HTTPS协议的区别是什么 ?
●那HTTP协议与HTTPS协议最大的区别，当然是数据传输的安全性了。 HTTP协议的信息是以明文传输，如果敏感信息被截取了，是可以直接获取传递的信息的。 相对之下，HTTPS协议是基于SSL加密传输的信息，可以确保数据的安全传输。
●还有呢，就是端口不同。 HTTP协议默认端口 80，而HTTPS协议默认的端口 443。
所以说，HTTP协议的安全性没有HTTPS高，但是HTTPS协议会比HTTP耗费更多的服务器资源。
HTTP协议中请求方式GET 与 POST 什么区别 ?
●必答内容：
那两种请求方式，使我们进行项目开发，最为常见的两种请求方式。 两者的区别主要有以下几点：
●传递参数的大小限制不同。GET请求参数在URL中传递，所以参数的大小会收到URL长度的限制。 而POST请求，是在请求体中传递参数，只受到服务器端的配置限制。
●安全性不同。 GET请求的参数暴露在URL中，安全性较低，不适合传递敏感信息。 而POST请求参数在HTTP消息体中传递，安全性相对较高。
●应用场景不同。 GET请求一般用于获取数据，而POST请求则用于提交数据。
●进阶回答：
那在项目开发中，现在的url风格，基本都是restful风格。所以呢，项目开发中，请求方式除了GET、POST之外，还有像PUT、POST也是非常常用的。
●可能会继续追问的问题：
你刚才提到Restful，什么是Restful，谈谈你的理解？
Restful其实就是一种软件架构风格，那既然是一种风格，就说明是可以被打破的，项目开发可以不按这套风格来。 但是我之前接触的项目，都是Restful风格的。 按照我的理解，Restful风格的两大特点：
●通过请求url地址，来定位要操作的资源。（如：http://localhost:8080/users/1，通过这个url，我就知道对1号用户资源进行操作）
●通过请求方式，来决定对资源进行什么样的操作。比如，GET 方式，就是用来查询的；POST方式，就是用来新增的；PUT方式，就是用来修改数据的；而DELETE方式就是用来删除数据的。
HTTP协议中常见的状态码 ?
HTTP协议的状态码，大的方面来说，分为5类， 分别是1xx，2xx，3xx，4xx，5xx。而在项目开发中，最为常见的状态码有这么几个：
●101：这个状态码，表示临时状态码，表示请求已经接受，服务器正在处理 （之前项目中，使用websocket时见到这个状态码）
●200：这个状态码，是最常见的，表示请求成功。
●302：表示重定向。
●401：表示此次请求需要用户身份认证，未认证就响应401。
●404：表示服务器无法找到对应的资源（请求路径找不到）。
●500：服务器内部错误。
转发 与 重定向的区别？
这个在现在的前后端分离开发中，基本上就不存在对应的转发操作 和 重定向操作了。
●转发是指服务器收到用户请求后，在服务器端将请求转发给另一个资源进行处理，然后将处理结果返回给用户，用户并不知道这个过程，是服务器内部完成的，整个过程只有一次请求。
●重定向是指当用户访问某个URL时，服务器返回一个特殊的响应码（3xx），并通过响应头（Location）告诉浏览器需要跳转到另一个URL。浏览器收到重定向响应后，会向新的URL发起新的请求，然后显示新页面的内容。整个过程对于浏览器来说是两次请求。
总的来说，重定向是在客户端发生的，浏览器需要重新发送请求；而转发是在服务器端发生的，对于客户端来说是透明的。
Cookie会话跟踪的原理？
会话跟踪的方案有很多，比如像 Cookie、Session、以及令牌技术，都可以进行会话跟踪。
Cookie是属于客户端会话跟踪方案，是存储在客户端浏览器的。 当我们第一次访问服务器的时候，服务器会创建Cookie，并在响应头 set-Cookie 中将Cookie响应给浏览器，浏览器接收到响应头之后，会自动将Cookie的值存储在浏览器中。
然后在后续的每一次请求中，浏览器都会自动的获取浏览器存储的Cookie值，并在请求头 Cookie 中将其携带到服务器，服务器就可以获取到Cookie中的数据了，从而完成会话跟踪.
所以，总的来说，Cookie会话跟踪的原理，其实就是HTTP协议中规定的两个头信息：一个是响应头 Set-Cookie，一个是请求头 Cookie。 但是由于Cookie存储在客户端浏览器，所以这种会话跟踪方案其实并不安全，因为用户是可以操作Cookie的（比如用户可以自己删除、禁用Cookie）。
帮助理解的图示：

分请求(COOKIE:NAME=VALUE)

响应(SET-COOKIE:NAME=VALUE)

REPORT

AMEVALUE

LOGIN

统一拦截

DEPT

浏览器

有效

EMP

人

Session会话跟踪的原理？
Session是服务端会话跟踪方案，具体的机制是这样的：
●首先，当用户首次访问网站的时候，服务器会为该用户创建一个会话对象Session，而每一个Session对象都有一个唯一标识ID，同一次会话中需要共享的数据，就可以存储在Session中。然后在服务器给客户端浏览器响应的时候，会将会话对象Session的ID在响应头 Set-Cookie 中响应给浏览器。（Cookie的名字为JSESSIONID，Cookie的值为服务端会话对象Session的ID值）
●浏览器接收到Cookie之后，就会自动将Cookie的值（JSESSIONID）存储起来，然后在后续访问服务器的时候，再将Cookie的值（JSESSIONID）携带到服务器。 在服务器中，就可以根据 JSESSIONID的值，找到对应的会话对象Session，从而操作会话对象Session中的数据了。
所以，总的来说，Sesssion会话跟踪的底层，其实还是基于Cookie实现的。 在Session会话跟踪的过程中，基于Cookie传递的其实就是Session会话对象的ID。
那这种方案，虽然Session存储在服务器端，用户无法操作，比较安全。 但是，在集群环境下Session的共享却是一个问题。
帮助理解的图示：

[>响应(SET-COOKIE:JSESSIONID=1)

谱求(COOKIE:JSESSIONID=1)

SESSIONID=1

REPORT

SESSION(1)

SESSION(3)

SESSION(2

LOGIN

EMP

统一拦截

DEPT

2 人点赞

2