网易游戏面试
c内存布局
- BSS（为初始化数据段 uninitialized data segment）未初始化数据是在程序中声明，但是没有初始化的变量，这些变量在程序运行之前不需要占用存储器的空间。Block Started by Symbol，BSS段的变量只有名称和大小却没有值
- RW read write 已初始化读写数据段
- RO read only 只读数据段，即常量区
- 堆和栈区只在程序运行时出现。堆内存一般由程序员分配和释放。如果程序没有释放，操作系统会在程序结束时回收。栈由编译器自动分配和释放。
| 段空间 | 地址空间 | 存储变量 |
|---|---|---|
| stack | 栈stack | 局部变量和常量 |
| heap | 堆heap | 动态分配的数据 |
| BSS | 为初始化数据段BSS | 为初始化的全局变量以及静态变量 |
| RW DATA | 已初始化读写数据段RW DATA | 已初始化的全局变量和静态变量 |
| RO DATA | 只读文本段中的数据段RO DATA | 全局常量或者字符串变量 |
| code | 只读文本段的程序代码段code | 程序的代码 |
c函数参数入栈顺序
- 由于C支持函数可变长参数，也正是这个原因，所以C语言函数参数的入栈顺序为从右至左。
- 从右至左入栈的好处就是可以动态变化参数的个数。如果从左向右入栈，则最前面的参数被压在栈底，除非知道参数个数，否则无法通过栈指针的相对位移找到最左边的参数，这样就变成了最左边的参数个数不确定。
https非对称加密方式，非对称加密算法
- RSA就是常用的非对称加密算法
- 非对称加密详细过程
- 浏览器发送一个请求给服务器。服务器将自己的证书（包含服务器公钥S_PuKey）、对称加密算法种类及其他信息返回给客户端
- 客户端浏览器检查服务器发来的CA证书是否由自己信赖的CA中心签发。若是，执行步骤4，否则，给用户一个警告，询问是否继续访问
- 客户端浏览器比较证书里的信息，如证书有效期、服务器域名和公钥S_PuKey，与服务器传回的信息是否一致，如果一致，则浏览器完成对服务器的身份认证
- 服务器要求客户端发送客户端证书（包括客户端公钥C_PuKey）、支持的对称加密方式及其他相关信息。收到后，服务器进行相同的身份认证，若没有通过认证，则拒绝连接
- 服务器根据客户端浏览器发送的密码种类，从中选择一种加密程度最高的方案，用客户端公钥加密后通知到浏览器
- 客户端通过私钥C_PrKey解密后，得知服务器选择的加密方式，并选择一个通话密钥Key，接着用服务器的公钥加密后发送给服务器
- 服务器收到浏览器传送到的信息，用私钥解密，获得通话密钥Key
- 接下来的数据传送都用该对称密钥进行加密
单点登录
注意sso穿件授权令牌后，会将令牌发送给系统1，然后系统1需要再向sso校验令牌。我感觉这是为了确保系统1收到的令牌的确是sso发送的。校验完系统1发送来的令牌后，sso需要注册系统1，表示用户已在该系统登录。之后用户再访问系统1，应该不用再去sso验证了，因为用户的令牌已保存在了系统1处
单点登出
用户在一个子系统中注销，则所有子系统的会话都将注销
JWT
JWT（json web token）的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。
jwt与传统的session cookie验证方式不同，它由服务端生成token，客户端保存这个token后，每次请求携带这个token，服务端解析认证token即可，省去了服务器存储session这样的操作。
JWT编码的样子
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
JWT的构成
jwt一共由三部分组成，分别为header头部，payload载荷，signature签证
header
jwt的头部承载两部分信息：
- 声明类型，这里是JWT
- 声明加密算法 通常直接使用HMAC SHA256
完整的头部就像下面这样的JSON：
{
'typ': 'JWT',
'alg': 'HS256'
}然后将头部进行base64编码，构成了第一部分
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
payload
载荷就是存放有效信息的地方。这些有效信息包含三个部分
- 标准中注册的声明
- 共有的声明
- 私有的声明
标准中注册的声明（建议但不强制使用）：
- iss：jwt签发者
- sub：jwt所面向的用户
- aud：接收jwt的一方
- exp：jwt的过期时间，这个过期时间必须要大于签发时间
- nbf：定义在什么时间之前，该jwt都是不可用的
- iat：jwt的签发时间
- jti：jwt的唯一身份标识，主要用来作为一次性token，从而回避重放攻击
公共的声明
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.
私有声明
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息
比如下面这个 Payload，用到了 iss 发行人，exp 过期时间，另外还有两个自定义的字段，一个是 name ，还有一个是 admin 。
{
"iss" : "csdn.net",
"exp" : "201511205211314",
"name" : "维C果糖",
"admin" : true
}使用 Base64 编码以后就变成了这个样子：
eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ
signature
JWT 的最后一部分是 Signature ，这部分内容有三个部分，先是用 Base64 编码的 header 和 payload ，再用加密算法加密一下，加密的时候要放进去一个 Secret ，这个相当于是一个密码，这个密码秘密地存储在服务端。
- header
- payload
- secret
var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload);
HMACSHA256(encodedString, 'secret');处理完成以后看起来像这样：
SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc
服务端验证
服务端接收到 token 之后，会逆向构造过程，decode 出 JWT 的三个部分，这一步可以得到 sign 的算法及 payload，结合服务端配置的 secretKey，可以再次进行 Signature的生成得到新的 S i g n a t u r e 的 生 成 得 到 新 的 Signature，与原有的 $Signature 比对以验证 token 是否有效，完成用户身份的认证，验证通过才会使用 payload 的数据
jwt的优点
- 可以实现跨域请求 因为JWT不依赖于Cookie，它可以添加在请求的Header,body,参数中，因此只要服务器允许跨域请求，那么带有授权Token的客户端，可以任意访问不同服务器下的服务，因此，非常适合SSO单点登录系统。
- 减少服务器消耗 服务器在生成Token之后，就将Token返回给客户端，客户端保存Token用于下次请求。服务端不进行储存Token，只验证Token，减少了服务器的消耗。同时，带有Token的请求在请求不同服务时，不用考虑是与哪台服务器生成的Session问题，非常适用于云服务。
- 通用性 因为JSON的通用性，所以JWT可以在Nodejs，JAVA，PHP等不同平台使用。
重放攻击
重放攻击
session一般存储在哪里
- file
- redis、memcache
- 数据库
python装饰器
python装饰器
syn队列
tcp半连接与完全连接队列
web如何实现并发的（同时服务多个用户）
- 每个客户端请求分配一个连接
- 线程池
- 事件驱动，非阻塞IO
nginx事件驱动
here
非阻塞IO
here
epoll
here