8.11字节跳动面试

8.11面试题

• jwt是什么，应用场景有哪些

jwt介绍：

• jwt全称json web token，由Header，Payload，Signature三部分组成。

• Header主要存放令牌的类型和签名的生成算法（比如：HS256、RSA等等），payload存放token携带的信息（用户名，过期时间），signature是以header和payload加密生成的签名（过程不可逆，保证信息无法被篡改）。

• 注意：只能保证信息不能被篡改，但是可以被解析出来，一般不要存放密码。

jwt适用场景：

• 一次性校验：用户注册后邮件**，邮件中有一个链接，用来标识用户，具有时效性，不可被篡改，非常适合使用jwt；

• resuful api的无状态认证，token自身包含了身份验证所需要的所有信息，服务端不需要存储session信息，减轻服务器压力；

• 单点登录，如果用session，就需要把用户的session信息在多台服务上面进行同步；

无状态和有状态：

• 无状态：服务端没有保存客户端的状态信息，所以客户端的每个请求都必须带着自己的状态信息，所以可以被任意服务器应答（便于实现负载均衡。）

• 有状态：服务端保存了客户端的状态信息，服务端会通过客户端传递的sessionID在server中的session作用域涨到之前交互的信息，并以此来实现应答，所以客户端只能由某一个服务器进行应答。

优缺点

• 优点：

• 无状态，单点登录

• 避免csrf攻击，客户端把token放在local storage中间，

• 缺点：

• 注销登录等场景下token还有效，相关场景（退出登录，修改密码，修改了用户的权限或角色，账户被删除、被注销），token只有过期了才会失效。可以把token存入redis中，一旦退出登录，直接删除就可以。

• 续签，校验时如果发现快要过期了，就刷新token，并返回给客户端。但是客户端每次请求都需要检查新旧token，不一样则替换。

• 有哪些和jwt差不多的机制？

cookie和session机制。由于http是一种无状态协议，服务器无法单从网络连接上确定客户身份，所以就需要cookie和session来记录客户信息。Cookie保存在客户端浏览器中，而Session保存在服务器上。

• 讲讲cookie？

cookie是客户端记录用户信息的解决方案。

cookie机制:

• 首先当客户端访问一个支持cookie的网站时，客户端会把自己的信息提交给服务器，

• 接着服务器会给客户端颁发一个cookie，客户端会把cookie保存起来，

• 然后客户端再次请求时会把相应的cookie发送给服务器。

• #####说明：http头部由set-cookie和cookie两个字段，用于颁布cookie和携带cookie

cookie不可跨域名性：

• cookie在客户端是通过浏览器来管理的，浏览器能够保证，浏览器能够保证Google只会操作Google的Cookie而不会操作Baidu的Cookie，从而保证用户的隐私安全。浏览器判断一个网站是否能操作另一个网站Cookie的依据是域名。

cookie的有效期

• cookie的maxAge决定着cookie的有效期，单位为秒；

• 如果maxAge为正数，表示会在多少秒后过期，浏览器会将maxAge为正数的cookie持久化，也就是写道对应的cookie文件中；

• 如果为负数则表示仅在本窗口和本窗口打开的子窗口内有效，关闭窗口立马失效，是临时性cookie，不会被持久化，不会被写入文件，只会存在浏览器内存中。

• 如果为0，这表示删除该cookie，cookie机制没有提供删除cookie的操作，所以使该cookie立即过期达到删除的效果。

cookie实现永久登录：

• 把用户名和密码都保存到cookie中，下次访问时检查，与数据库中进行比对；

• 把密码加密后保存到cookie或者把登录的时间戳保存到cookie和数据库中，与数据库中进行比对，验证用户名和登录时间戳；

• 把账号按照一定规则加密，连同帐号一起保存到cookie中，下次访问判断账号加密规则是否正确即可，需要保管好**不外泄；

• 讲讲session？

session是服务端用来记录用户信息的解决方案

session含义：

• session指会话，客户端浏览器和服务器之间一系列的交互

• session指的是服务器为客户端开辟的存储空间，用来存放客户端的状态。

session机制：

• 客户端将自己的信息发送给服务端，服务端会新建一个session，并为该session分配一个唯一的session ID，

• 然后将该session ID传递给客户端，客户端会将这个id保存下来，保存的容器就是cookie，之后客户端每次发送请求是都会带上这个session Id。

• 服务端接收到请求之后会一句这个id找到对应的session，维护用户的状态。

session生命周期

• session保存在服务端，为了获取更高的存取速度，一般放在内存中，会对服务器造成压力

• 用户第一次访问服务器时自动创建，（访问静态资源不会创建，访问jsp、servlet才会创建）；

• 之后用户每次访问，服务器就会更新session最后访问时间，并维护该session，认为该session活跃了一次。

• 服务器会自动把长时间没有活跃的session从内存中删除，该时间叫做超时时间。

URL地址重写

• 当客户端不支持cookie时，可以将客户端的session ID信息重写到URL地址中，服务端能解析重写后的url，并获取session id；

• session的缺点是什么？

• session存放在服务器内存中，连接比较多的时候，服务器压力过大

• session是基于cookie来实现的，cookie如果被截获容易造成CSRF攻击；

• 扩展性不强，对于一个服务器集群，session只是保存在某一台服务器的内存中（不共享），其他服务器无法处理该请求。

• 分布式session一般采用集中存储的方式，比如说存储在分布式缓存redis中。

• 什么场景用cookie，什么时候用session？

session要存放在服务器一段时间才会过期，一般临时性网站（十分钟邮箱等）应该使用cookie；

session是基于cookie来实现的，一般有session就有cookie。

• TCP为什么要三次握手，而不是4次，不是两次？

为了使通信双方都知道自己和对方都具备收和发的能力，保证通信正常进行

• tcp和udp区别？

• tcp建立连接，有重传机制，拥塞控制，可靠传输，是全双工，只支持一对一通信；

• udp无连接，无重传机制，没有拥塞控制（实时性好），支持一对一，一对多，多对多；

• 基于udp实现一个可靠传输机制？

• 添加分包和ack回应机制

• 设置发送端和接收端缓冲区

• 添加重传机制

• 排序算法以及时间复杂度？

• 快排啥时候效率最差？如何规避这种情况？

已经是有序（然后正序，逆序）或者每个元素都相等；选择基准时每次都选在中间。

• hash表，查询插入，时间复杂度？

• hash底层是数组和链表的数据结构，查询插入时间复杂都是O(1)。

• 对一个key-value对，计算其key的hashcode，并将其作为数组的下标，把value放入其中。

• 当hashcode相同时（冲突），以开链表的形式将其存入（冲突超过8个以后会转成红黑树）

• hash表如何选择hash函数？

• 直接寻址，取key的某个线性函数值作为散列地址

• 数字分析法，找出数字的规律，尽可能利用这些数据来构造冲突几率比较小的散列地址；

• 平方取中法，取keyword平方后的中间极为作为散列地址；

• 折叠法，将key切割成位数相同的几部分（最后一部分位数可不同），然后去这几部分叠加和作为散列地址；

• 随机数法，选择随机函数，取key的随机值作为散列地址（当key长度不同时使用）

• 除留余数法，H(key) = key MOD p, p<=m。

• hash表如何解决冲突？

• 拉链法：将冲突放在一个链表中，凡是散列地址为i的节点，均插入到T[i]的单链表中（头插法）

• 开放定址法（使用某种探查技术在散列表中寻找下一个空的散列地址，只要散列表足够大，空的散列地址总能找到）

• 线性探查：先计算出hashcode，如果该位置不为空，则探测下一顺位（位置+1），直到为空的地址，将value放入；

• 二次探查：先计算出hashcode，如果该位置不为空，则探测（地址+(1^2，22，3^2，42，5^2…))

• 双重散列法：给了两个哈希函数，hi = ()h(key) + i*h1(key))/m，必须要让h1(key)的值和m互素。