Hello,我是 Alex 007,为啥是007呢?因为叫 Alex 的人太多了,再加上每天007的生活,Alex 007就诞生了。
01.HTTP是什么?(初级)
-
HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。
-
HTTP协议是一个基于TCP/IP通信协议来传递数据(HTML 文件, 图片文件, 查询结果等)。
-
HTTP协议是一个属于应用层的面向对象的协议。
-
HTTP协议工作于客户端和服务端架构上,浏览器作为HTTP客户端通过URL向HTTP服务器发送请求,服务器根据接收到的请求后,向客户端发送响应信息。
特点:
- 基于TCP/IP
双方建立通信的顺序,以及Web页面显示需要 处理的步骤,等等。
像这样把与互联网相关联的协议集合起来总称为 TCP/IP。
而HTTP协议是基于TCP/IP协议之上的应用层协议。
- 基于请求-响应模式
HTTP协议规定,请求从客户端发出,最后服务器响应该请求并返回。
- 无状态保存
HTTP是一种无状态协议。HTTP协议不对请求和响应之间的通信状态进行保存,不做持久化处理。这是为了更快地处理大量事务,确保协议的可伸缩性,而特意把HTTP协议设计成 如此简单的。
02.HTTP请求报文与响应报文格式?(初级)
请求报文包含三部分:
-
请求首行(包括请求方法、URL、HTTP版本)
-
请求首部字段
-
请求内容实体
响应报文包含三部分:
-
响应首行(包括状态码、状态信息、HTTP版本)
-
响应首部字段
-
响应内容实体
03.HTTP常见首部字段有哪些?(初级)
- 通用首部字段(请求报文与响应报文都会使用的首部字段)
字段 | 字段描述 |
---|---|
Date | 创建报文时间 |
Connection | 连接的管理 |
Cache-Control | 缓存的控制 |
Transfer-Encoding | 报文主体的传输编码方式 |
- 请求首部字段(请求报文会使用的首部字段)
字段 | 字段描述 |
---|---|
Host | 请求资源所在服务器 |
Accept | 可处理的媒体类型 |
Accept-Charset | 可接收的字符集 |
Accept-Encoding | 可接受的内容编码 |
Accept-Language | 可接受的自然语言 |
- 响应首部字段(响应报文会使用的首部字段)
字段 | 字段描述 |
---|---|
Accept-Ranges | 可接受的字节范围 |
Location | 令客户端重新定向到的URI |
Server | HTTP服务器的安装信息 |
- 实体首部字段(请求报文与响应实体部分使用的首部字段)
字段 | 字段描述 |
---|---|
Allow | 资源可支持的HTTP方法 |
Content-Type | 实体主类的类型 |
Content-Encoding | 实体主体适用的编码方式 |
Content-Language | 实体主体的自然语言 |
Content-Length | 实体主体的的字节数 |
Content-Range | 实体主体的位置范围,一般用于发出部分请求时使用 |
04.HTTP与HTTPS的区别?(初级)
-
HTTP协议传输的数据都是明文、未加密的,因此使用HTTP协议传输隐私信息非常不安全。
-
HTTPS协议是由HTTP+SSL构建的网络协议,可进行加密传输、身份认证,要比HTTP协议安全。
不同点 | HTTP | HTTPS |
---|---|---|
安全证书 | 不需要 | 需要到ca申请证书(免费/付费可选) |
是否加密 | 不加密,信息是明文传输 | 具有安全性的ssl加密传输协议 |
验证数据 | 不验证数据,可能遭到伪装 无法验证报文完整性,可能被篡改 |
验证数据且对数据完整性保护 |
连接方式 | 无状态连接 | HTTPS协议是由HTTP+SSL协议构建的 可进行加密传输、身份认证的网络协议,比HTTP协议安全。 |
默认端口 | 80 | 443 |
安全性 | 不安全 | 安全 |
05.列举HTTP请求中常见的请求方式(初级)
方法名称 | 定义 |
---|---|
GET | 向特定的路径资源发出请求 |
POST | 向指定路径资源提交数据进行处理请求(一般用于提交表单或者上传文件) |
PUT | 从客户端向服务器传送数据更新指定的资源 |
PATCH | 从客户端向服务器传送数据更新部分指定的资源 |
DELETE | 请求服务器删除指定的资源 |
HEAD | 向服务器索要与GET一样的请求,但是不返回返回体。 这个方法可以在不必传输整个响应内容的情况下,获取包含在响应消息头中的元信息 |
OPTIONS | 查询相应URL支持的HTTP方法 |
TRACE | 返回服务器收到的请求,主要用于测试或诊断 |
CONNECT | HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务 |
06.GET方法与POST方法的区别?(初级)
不同点 | GET | POST |
---|---|---|
本质 | 产生1个TCP数据包,只跑1次 浏览器会把HTTP header和data一并发送出去,服务器响应200(返回数据) |
产生2个TCP数据包,来回各1次(共2次) 浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据) |
请求形式 | 参数通过URL传递 | 把数据放在Request的body中 |
安全性 | 因为URL是可见的,可能会泄露私密信息, 如账号密码等,所以不安全 |
数据在request中,用户不可见,较get安全性较高 |
传输数据量 | 传输的数据量小,因为受URL长度最多是1024字节,但效率较高; | 可以传输大量数据,所以上传文件时只能用Post方式; |
支持编码 | 只能进行url编码 | 支持多种编码 |
字符格式 | 只能支持ASCII字符,向服务器传的中文字符可能会乱码。 | 支持标准字符集,可以正确传递中文字符。 |
浏览器处理 | 请求会被浏览器主动cache,请求参数会被完整保留在浏览器历史记录里 | 浏览器不会主动cache,参数不会被保留,除非手动设置 |
业务应用 | 常用在从服务器上获取数据 | 常用在向服务器发送数据 |
** GET只需要跑一趟就把信息送到了,而POST得跑两趟。第一趟,先去和服务器打个招呼“嗨,我等下要送一消息来,你们打开门迎接我”,然后再回头把数据送过去。**
因为POST需要两步,时间上消耗的要多一点,所以看起来GET比POST更有效,但事实上不是,在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。
而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。
而且并非所有浏览器都会在POST中发送两次包,Firefox浏览器就只发送一次。
07.常见的HTTP相应状态码(初级)
1XX:指示信息–表示请求已接收,继续处理。
2XX Success(成功状态码):成功–表示请求已被成功接收、理解、接受。
200 表示从客户端发来的请求在服务器端被正常处理
204 该状态码表示服务器接收的请求已成功处理,但在返回的响应报文中不含实体的主体部分
206 该状态码表示客户端进行了范围请求,而服务器成功执行了这部分的GET请求
3XX Redirection(重定向状态码):重定向–要完成请求必须进行更进一步的操作。
301 永久性重定向
302 临时性重定向
4XX Client Error(客户端错误状态码):客户端错误–请求有语法错误或请求无法实现。
400 该状态码表示请求报文中存在语法错误
401 该状态码表示发送的请求需要有通过HTTP认证的认证信息
403 该状态码表明对请求资源的访问被服务器拒绝了
404 该状态码表明服务器上无法找到请求的资源
5XX Server Error(服务器错误状态码):服务器端错误–服务器未能实现合法的请求。
500 该状态码表明服务器端在执行请求时发生了错误。
503 该状态码表明服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。
08.如何对HTTP进行优化?(中级)
- TCP复用
TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端的TCP连接上。
HTTP复用是指一个客户端的多个HTTP请求通过一个TCP连接进行处理。
- 内容缓存
将经常用到的内容进行缓存到浏览器中,那么客户端就可以直接在内存中获取响应的数据。
- 压缩
将文本数据进行压缩,减少带宽。
- SSL加速
使用SSL协议对HTTP协议进行加密,在通道内加密并加速。
09.TCP与UDP的区别?(初级)
TCP协议和UDP协议都是传输层协议。
- TCP(Transmission ControlProtocol,传输控制协议)提供的是面向连接,可靠的字节流服务。
客户和服务器交换数据前,必须现在双方之间建立一个TCP连接,之后才能传输数据。
并提供超时重发、丢弃重复数据,检验数据,流量控制等功能,保证数据能完整地从一端传到另一端。
简单说就是必须要建立连接后才能传输数据,确保传输完整性,类比现实当中的打电话。
- UDP(User Data Protocol,用户数据报协议)是一个简单的面向数据报的运输层协议。
它不提供可靠性,只是把应用程序传给IP层的数据报发送出去,但是不能保证它们能到达目的地。
由于UDP在传输数据报前不用再客户和服务器之间建立一个连接,且没有超时重发等机制,所以传输速度很快。
简单说就是单向把程序中的信息发送了,但也不知道对方收到没有,类比现实当中的寄信。
10.请介绍TCP的3次握手和4次挥手流程(初级)
建立双工通信,确保双方都能收到对方的信息,所以需要3次握手
第1次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入同步已发送状态,等待服务器确认;SYN:同步序列编号。
第2次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入同步已接受状态;
第3次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
全双工关闭需要客户端和服务器发送和接受都关闭,但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,只能先回复一个ACK报文,所以需要4次挥手
第1次挥手:客户端进程发出连接释放报文,并且停止发送数据。此时,客户端进入FIN-WAIT-1(终止等待1)状态。
第2次挥手:服务器收到连接释放报文,发出确认报文。服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
第3次挥手:服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
第4次挥手:客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
11.为什么TCP连接的时候是3次握手,关闭的时候却是4次握手?(初级)
因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。
其中ACK报文是用来应答的,SYN报文是用来同步的。
但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。
只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
12.TCP为什么会分包和粘包?(高级)
TCP是以段(Segment)为单位发送数据的,建立TCP链接后,有一个最大消息长度(MSS)。
如果应用层数据包超过MSS,就会把应用层数据包拆分,分成两个段来发送。
这个时候接收端的应用层就要拼接这两个TCP包,才能正确处理数据。
有时候,TCP为了提高网络的利用率,会使用一个叫做Nagle的算法。
该算法是指,发送端即使有要发送的数据,如果很少的话,会延迟发送。
如果应用层给TCP传送数据很快的话,就会把两个应用层数据包“粘”在一起,TCP最后只发一个TCP数据包给接收端.
13.HTTP和websocket的区别?(中级)
WebSocket允许服务端主动向客户端推送数据。
在WebSocket协议中,客户端浏览器和服务器只需要完成一次握手就可以创建持久性的链接,并在浏览器和服务器之间进行双向的数据传输。
-
最大的区别就是HTTP只能由客户端推送信息给被动的服务端,而websocket既可以让客户端发送消息给服务端,也可以让服务端主动推送消息到客户端,实现双工通信
-
http协议是用在应用层的协议,他是基于tcp协议的,http协议建立链接也必须要有三次握手才能发送信息。
http链接分为短链接,长链接,短链接是每次请求都要三次握手才能发送自己的信息。即每一个request对应一个response。长链接是在一定的期限内保持链接。保持TCP连接不断开。客户端与服务器通信,必须要由客户端发起然后服务器返回结果。客户端是主动的,服务器是被动的。
- WebSocket是为解决客户端与服务端实时通信。浏览器和服务器只需要做1个握手的动作,在建立连接之后,双方可以在任意时刻,相互推送信息。同时,服务器与客户端之间交换的头信息很小。
建立了WebSocket之后服务器不必在浏览器发送request请求之后才能发送信息到浏览器。这时的服务器已有主动权想什么时候发就可以发送信息到服务器。而且信息当中不必在带有head的部分信息了与http的长链接通信来说,这种方式,不仅能降低服务器的压力。而且信息当中也减少了部分多余的信息。
14.HTTP的长连接与websocket的持久连接的区别?(高级)
- HTTP1.1的连接默认使用长连接(persistent connection)
HTTP 1.1默认进行持久连接。在1次 TCP 连接中可以完成多个 HTTP 请求,但是对每个请求仍然要单独发 header,Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Nginx)中设定这个时间。这种长连接是一种“伪链接”
- WebSocket的持久连接
WebSocket 是一个持久化的协议,只需建立1次Request/Response消息对,之后都是TCP连接,避免了需要多次建立Request/Response消息对而产生的冗余头部信息。
15.什么是cookie?其特点和应用场景有哪些?其如何获取、设置?(中级)
-
cookie是一种会话跟踪技术,由服务器生成,然后通过响应发送给客户端的一个键值对。
1.cookie是一个标准的python字典,以键值对方式进行存储,键值都是字符串 2.通过浏览器访问一个网站时,浏览器会将存储该网站相关的所有cookie信息发送给该网站的服务器,request.COOKIES 3.cookie是基于域名安全的 4.cookie是有过期时间的,如果不指定,默认关闭浏览器后cookie就会过期 5.单个Cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个Cookie。
-
应用场景:记住用户名和密码,安全性要求不高
response.set_cookie("is_login",True) # 获取
request.COOKIES.get("is_login") # 设置
16.什么是session?其特点和应用场景有哪些?其如何设置、获取、清空?(中级)
-
Session是服务器端技术,它保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是 Session。客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。
1.它是以已键值对进行存储 2.它依赖cookie,唯一的标识码session ID保存在cookie中 3.它也是有过期时间,如果不指定,默认两周就会过期 4.它是用base64加密
-
应用场景:涉及到安全性要求比较高的数据,银行卡账户、密码
request.session["is_login"] = True # 设置
is_login = request.session.get("is_login") # 获取
request.session.flush() # 清空
17.session和cookie的相同点和区别?(中级)
- 相同点
cookie/session | |
---|---|
跟踪技术 | 都是追踪浏览器用户身份的会话方式 |
生成地点 | 都在服务器 |
存储形式 | 都是键值对 |
过期时间 | 都可自定义 |
- 不同点
cookie | session | |
---|---|---|
存放地点 | 浏览器 | 服务器 |
安全性 | 不安全,他人可通过分析存放在本地的cookie并进行Cookie欺骗 | 比较安全,因数据在服务器中,且用base64加密 |
依赖性 | 无 | 依赖cookie,唯一的标识码session ID保存在cookie中 |
过期时间 | 默认关闭浏览器后就会过期 | 默认两周就会过期 |
18.什么是JWT,有什么特点?(初级)
JWT 全称 JSON Web Tokens,它定义了一种以JSON 对象形式的安全通信方法。它由头部、负载和签名3部分组成。它具有2个特点:
-
简洁:可以通过URL, POST 参数或者在 HTTP header 发送,因为数据量小,传输速度快
-
自包含:负载中包含了所有用户所需要的信息,避免了多次查询数据库
19.简述JWT的工作原理(初级)
-
客户端通过Web表单将正确的用户名和密码发送到服务端的接口。这一过程一般是POST请求。建议的方式是通过SSL加密的传输(https协议),从而避免敏感信息被嗅探。
-
服务端核对用户名和密码成功后,将用户的id等其他信息作为JWT Payload(负载),将其与头部分别进行Base64编码拼接后签名,形成一个JWT。形成的JWT就是一个形同lll.zzz.xxx的字符串,并设置有效时间。
-
服务端将JWT字符串作为登录成功的返回结果返回给客户端。
-
客户端将返回的JWT以cookie的形式保存在浏览器上,并设置cookie的有效时间(建议客户端cookie和服务端JWT的有效时间设置为一致),用户登出时客户端需删除cookie。
-
客户端在每次请求时将JWT放入HTTP Header中的Authorization位。(解决XSS和XSRF问题)
-
服务端对收到的JWT进行解密和校验,如检查签名是否正确、Token是否过期、Token的接收方是否是自己等。
-
验证通过后服务端使用JWT中包含的用户信息进行其他逻辑操作,返回相应结果,否则返回401。
20.传统Session方式存储ID和JWT的区别?(初级)
-
Session是保存在服务端的,而JWT是保存在客户端的。
-
Session方式存储用户id的最大弊病在于Session是存储在服务器端的,所以需要占用大量服务器内存,对于较大型应用而言可能还要保存许多的状态。 一般而言,大型应用还需要借助一些KV数据库和缓存机制来实现Session的存储。
-
JWT方式将用户状态分散到了客户端中,可以减少服务器查询数据库的次数和减轻服务端的内存压力。除了用户id之外,还可以存储其他的和用户相关的信息。虽说JWT方式让服务器有一些计算压力,但是这些压力相比磁盘存储而言可能就不算什么了。
具体是否采用,需要在不同场景下用数据说话。