OSI 七层模型：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

osi七层模型.png

TCP/IP 四层模型：应用层、传输层、网络层、网络接口层
应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。
传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务
网络层负责为路由和寻址。
运输层主要使用以下两种协议：
传输控制协议 TCP（Transmisson Control Protocol）--提供面向连接的，可靠的数据传输服务。
用户数据协议 UDP（User Datagram Protocol）--提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）

HTTP 协议 全称超文本传输协议 HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80

HTTPS协议是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用SSL/TLS 协议用作加密和安全认证。默认端口号是 443。SSL/TLS 的核心要素是非对称加密。

HTTP和HTTPS有什么区别？

1、端口不同：HTTP使用的是80端口，HTTPS使用443端口；
2、HTTP（超文本传输协议）信息是明文传输，HTTPS运行在SSL之上，添加了加密和认证机制，更加安全；
3、HTTPS由于加密解密会带来更大的CPU和内存开销
4、HTTPS通信需要证书，一般需要向证书颁发机构（CA）购买

HTTPS数据传输流程:

1、客户端发起https请求，连接到服务端的443端口
2、服务端采用的https有一套CA机构的数字证书，证书的本质是公钥（发给任何人）和私钥（服务端保留）
3、服务端将含有公钥的证书传递给客户端，证书中包含了很多信息
4、客户端解析证书，由客户端的TLS完成，首先会验证公钥是否有效，比如颁发机构，过期时间等。如果有异常，就会弹出警告信息。证书没问题后会随机生成随机值（这个很重要，用于对称加密），然后使用第三步中的证书对这个随机值进行非对称加密
5、将证书非对称加密后的随机值传到服务器
6、服务器使用私钥对其进行非对称解密后，得到客户端的随机值，然后把内容通过该随机值进行对称加密
7、服务端将对称加密后的信息发给客户端
8、客户端用之前的生成的随机值来进行对称解密，获取内容明文

HTTP响应状态码

1xx             接受的请求正在处理
2xx             请求正常处理完毕
3xx             需要进行附加操作以完成请求
4xx             客户端请求出错，服务器无法处理请求
5xx             服务器处理请求出错

常见状态码：

200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
204 No Content：表示客户端发送给客户端的请求得到了成功处理,没有资源可以返回
301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
400 Bad Request：表示请求报文中存在语法错误；
401 Unauthorized：未经许可，需要通过HTTP认证；
403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
404 Not Found：表示服务器上无法找到请求的资源
500 Inter Server Error：表示服务器在执行请求时发生了错误
503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求

200：“好的”，
204:“无内容”，
301:“永久移动”，
302:“找到”，
307:“临时重定向”，
400:“错误请求”
401:“未授权”，
403:“禁止”，
500:“内部服务器错误”
503:“服务不可用”

HTTP1.0、 HTTP1.1、HTTP2.0 区别：

HTTP1.0：
浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接

HTTP1.1：
1、Http1.1增加了host字段
2、引入了持久连接，即TCP连接默认不关闭，可以被多个请求复用
在同一个TCP连接里面，客户端可以同时发送多个请求
虽然允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的，服务器只有处理完一个请求，才会接着处理下一个请求。如果前面的处理特别慢，后面就会有许多请求排队等着
3、新增了一些请求方法
4、新增了一些请求头和响应头

HTTP2.0：
1、采用二进制格式而非文本格式
2、完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行
3、使用报头压缩，降低开销
4、服务器推送

SMTP 协议只负责邮件的发送，真正负责接收的协议是POP3/IMAP

FTP 协议 主要提供文件传输服务，基于 TCP 实现可靠的传输

TCP 3 次握手

三次握手.png

TCP 为什么需要 3 次握手, 为什么 2 次不行, 4 次呢?

TCP 的三次握手是为了保证数据的可靠传输的，TCP 是全双工的协议，也就是说通过 TCP 协议发送的消息是要得到回复的，所以说对于需要建立 TCP 连接的两端来说，每一端都需要进行一来一回的确认，这就进行三次握手。
1、A 给 B 发送需要建立连接的请求;
2、B 给 A 发送可以建立连接的回复；
3、A 给 B 发送确认收到回复的信息；
如果只进行二次握手：
1、A 给 B 发送需要建立连接的请求;
2、B 给 A 发送可以建立连接的回复；
这样看似没有什么问题，但是这样还是不行的，因为第二次握手的时候 B 不知道自己发送给 A 的应答包是否可以到达 A；B 只知道了 A 能发，并不知道 A 是否能收；所以这样的连接还是不可靠的。
如果进行四次握手：
1、A 给 B 发送需要建立连接的请求;
2、B 给 A 发送可以建立连接的回复；
3、A 给 B 发送确认收到回复的信息；
4、B 给 A 发送确认收到确认的信息；
当进行到第二步的时候 B 在等待 A 的确认信息，只有等到这个消息，B 才能确认建立连接，这样其实就够了，多了反而会浪费资源。

第 2 次握手传回了 ACK，为什么还要传回 SYN？

接收端传回发送端所发送的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，而回传 SYN 则是为了建立并确认由客户端发起带有SYN的连接。

为什么要四次挥手

四次挥手.png

tcp是全双工的协议、因此双发都会向对方发送协议。
四次挥手如下：
1、客户端执行主动关闭，发送 fin的包（fin），表示客户端的数据发送完毕。
2、服务端执行被动关闭，发送确认 ask 包。
3、服务端给客户端发送 fin，告诉客户端我也要关闭。
4、客户端确认服务端的ask的包。
这个因为第一次挥手表示客户端发送了一个fin的包，表示客户端已发送数据完毕，但是服务端这个时候可能还有数据没有发送完成，先发送给客户端一个ask的包，等待自己的数据发送完成才能向客户端发送一个 fin的包，表示自己的数据也已发送完成。这样中间就必须为两次来发送ask和fin。

TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

UDP 一般用于QQ 语音、 QQ 视频 、直播等等。

tcp-vs-udp.jpg

TCP 协议如何保证可靠传输

1、TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
2、校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。
3、TCP 的接收端会丢弃重复的数据。
4、流量控制：TCP 利用滑动窗口实现流量控制
5、拥塞控制： 当网络拥塞时，减少数据的发送。
6、ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
7、超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

停止等待 ARQ 协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

拥塞控制

TCP 的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

在浏览器中输入url地址->>显示主页的过程

1、在浏览器查找域名的IP地址（DNS解析）
2、浏览器会向web服务器发送一个HTTP请求（cookie会随着请求发送给服务器）
3、web服务器处理收到的请求（处理 请求、参数、cookie，然后生成一个HTML响应）
4、web服务器发回一个HTML响应
5、浏览器开始显示HTML

HTTP 是不保存状态的协议, 如何保存用户状态?

Session 的主要作用就是通过服务端记录用户的状态
Cookie 一般用来保存用户信息
Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
用Session ，将Session 存放在服务器端。通过在Cookie 中存储实现Session 跟踪

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

Cookie、Session、JWT的详解

由于 http 是无状态的协议，每个请求是独立的，服务端无法确认当前请求者的身份，因此为了实现服务器和浏览器的会话跟踪，就需要使用 cookie 或者 session 维持一个状态，该状态用于告知服务端前后的请求是否来自同一用户

Cookie

• cookie 存储在客户端
• cookie 是不可跨域的

Session

seesion 是基于 cookie 实现的，session 保存在服务端， session_id 保存在客户端的 cookie 中。

Token

• 1、用户使用用户名密码来请求服务器
• 2、服务器进行验证用户的信息
• 3、服务器通过验证发送给用户一个token
• 4、客户端存储token，并在每次请求时附送上这个token值
• 5、服务端验证token值，并返回数据（需要查数据库）

JWT

JSON WEB TOKEN , 适用于分布式站点的单点登录（SSO）场景。
JWT是由三段信息构成的，header、payload、signature

• header 指出了声明类型和加密算法
• payload 存放有效个人信息如用户信息、权限信息
• signature 由三部分组成header (base64后的)、payload (base64后的)、secret（secret 是保存在服务器端的， jwt 的签发生成也是在服务器端的，secret 就是用来进行 jwt 的签发和 jwt 的验证）

常见问题

使用 cookie

• 因为存储在客户端，容易被客户端篡改，使用前需要验证合法性
• 不要存储敏感数据，比如用户密码，账户余额
• 使用 httpOnly 在一定程度上提高安全性
• 尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
• 设置正确的 domain 和 path，减少数据传输
• cookie 无法跨域
• 一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie
• 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用session

• 将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session
• 当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。
• 当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。
• sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？ 一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现
• 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 token

如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。
token 完全由应用管理，所以它可以避开同源策略
token 可以避免 CSRF 攻击(因为不需要 cookie 了)
移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 JWT

• JWT 并不依赖 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
• JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
• JWT 不加密的情况下，不能将秘密数据写入 JWT。
• JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
• JWT 最大的优势是服务器不再需要存储 Session，使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的缺点：由于服务器不需要存储 Session 状态，因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期之前就会始终有效，除非服务器部署额外的逻辑。
• JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
• JWT 适合一次性的命令认证，颁发一个有效期极短的 JWT，即使暴露了危险也很小，由于每次操作都会生成新的 JWT，因此也没必要保存 JWT，真正实现无状态。
• 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

JWT的优点

• JWT 一般不放在 cookie 中（cookie 中的话不能跨域），直接放在 HTTP 请求头信息中的 Authorization 字段内，使用 Bearer 模式添加 JWT。
• 用户状态不储存在服务端的内存中，这是一种 无状态的认证机制
• 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为
• 由于 JWT 包含了用户信息和权限信息，因此减少了需要查询数据库的需要
• 因为 JWT 并不使用 Cookie ，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）

Token 和 JWT 的区别

相同：

• 都是访问资源的令牌
• 都可以记录用户的信息
• 都是使服务端无状态化
• 都是只有验证成功后，客户端才能访问服务端上受保护的资源
  区别：
  Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
  JWT：将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

Cookie不能跨域？

由于域名不同，用户向系统A登录后，系统A返回给浏览器的Cookie，用户再请求系统B的时候不会将系统A的Cookie带过去。
针对Cookie存在跨域问题，有几种解决方案：
1、服务端将Cookie写到客户端后，客户端对Cookie进行解析，将Token解析出来，此后请求都把这个Token带上就行了
2、多个域名共享Cookie，在写到客户端的时候设置Cookie的domain。
3、将Token保存在SessionStroage中（不依赖Cookie就没有跨域的问题了）

Session和Cookie 的区别

1、Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
2、Cookie不是很安全，容易被用作cookie欺骗。
3、Session 会在一定时间存放在服务器上，当访问增多时，会占用服务器性能。
4、Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
5、单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

Session 和 Token 的区别

• Session 是记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息， token 是访问资源接口的资源凭证,每次请求都要解析，服务端无状态化，不储存会话信息。
• Session 只提供简单的认证， 而 Token 提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。

Session的认证流程

• 1、用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的SessionID
• 2、请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
• 3、浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
• 4、当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

Refresh Token

专用于刷新 access token 的 token。客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。

分布式架构下 session 的共享

session 复制：任何一个服务器上的 session 发生改变（增删改），该节点会把这个 session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 session ，以此来保证 session 同步

session 共享：使用分布式缓存方案比如 Memcached 、Redis 来缓存 session，但是要求 Memcached 或 Redis 必须是集群，把 session 放到 Redis 中存储

Post和Get的区别

1、post的参数是放在请求体的，而get参数是通过URL传递的
2、get请求只能进行url编码，而post请求支持多种编码方式
3、get请求在url中传送的参数是有长度限制的，而post没有
4、get请求在浏览器回退时是无害的，而post请求会再次提交请求

ARP地址解析协议

将IP地址转化为对应的物理地址

什么是SQL 注入？举个例子？

把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

用户的个人信息可以存储在cookie或localstorage中

什么是XSS攻击?

XSS：跨站脚本攻击。XSS的重点不在于跨站点，而在于脚本的执行。
XSS的原理是：恶意攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。

什么是 CSRF？

CSRF又称为跨站请求攻击，攻击者盗取用户Cookie信息伪造请求访问其他网站

用户登录了受信任的网站，并在本地生成了 cookie。然后访问了危险网站，由于浏览器会自动带上用户 cookie，由此盗取用户Cookie信息从而达成模拟用户操作的目的。

解决方案
1、同源检测：利用HTTP协议中的，异步请求携带的Origin/Refer Header；通过这两个请求头可以确定请求源。
2、Token：

为什么说Token可以防止CSRF攻击

token 验证的规则是，服务器从请求体（POST）或者请求参数（GET）中获取设置的 token，然后和 Cookie 中的 token 进行比较，一致之后才执行请求。
CSRF 攻击只是借用了 Cookie，并不能获取 Cookie 中的信息，所以不能获取 Cookie 中的 token，也就不能在发送请求时在 POST 或者 GET 中设置 token，把请求发送到服务器端时，token 验证不通过，也就不会处理请求了。

为什么CSRF攻击不能解析Cookie中的token？

token 校验之所以能防御 csrf，是因为相信浏览器的同源策略。为什么这么说？因为只有在同源的情况下，页面才能进行脚本操作和使用 js 获取 cookie 的操作，才能获取到 token。也就是说第三方网站是没有办法拿到 token 的。只有真正有权限的网站或页面才有办法取到 token，并将 token 传到服务端。所以服务端默认带有相应 token 的请求都是合法的请求。

跨域

1、协议，域名，端口三者其中存在不同都会形成跨域
2、跨域存在原因：浏览器的同源限制策略