计算机网络面经（一）

计算机网络面经（一） 说说OSI 七层、TCP/IP 四层的关系和区别？ OSI 七层从下往上依次是：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

  TCP/IP 四层从下往上依次是：网络接口层、网络层、传输层、应用层。

 

特点：

• 层与层之间相互独立又相互依靠
• 上层依赖于下层，下层为上层提供服务

 TCP/IP 四层是 OSI 七层的简化版，已经成为实事国际标准。 说说TCP 与 UDP 的区别？

总结：

1. TCP 向上层提供面向连接的可靠服务 ，UDP 向上层提供无连接不可靠服务。
2. UDP 没有 TCP 传输可靠，但是可以在实时性要求高的地方有所作为。
3. 对数据准确性要求高，速度可以相对较慢的，可以选用TCP。

 TCP 是如何实现数据的可靠性？

 一句话：通过校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制等机制来保证可靠性。

校验和：

• 在数据传输过程中，将发送的数据段都当做一个16位的整数，将这些整数加起来，并且前面的进位不能丢弃，补在最后，然后取反，得到校验和。
• 发送方：在发送数据之前计算校验和，并进行校验和的填充。接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方进行比较。

序列号：

• TCP 传输时将每个字节的数据都进行了编号，这就是序列号。序列号的作用不仅仅是应答作用，有了序列号能够将接收到的数据根据序列号进行排序，并且去掉重复的数据。

确认应答：

• TCP 传输过程中，每次接收方接收到数据后，都会对传输方进行确认应答，也就是发送 ACK 报文，这个 ACK 报文中带有对应的确认序列号，告诉发送方，接收了哪些数据，下一次数据从哪里传。

超时重传：

• 在进行 TCP 传输时，由于存在确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的 ACK 报文，并解析 ACK 报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟都没有接收到接收方传来的 ACK 报文，那么就对刚刚发送的数据进行重发。

连接管理：

• 就是指三次握手、四次挥手的过程。

流量控制：

• 如果发送方的发送速度太快，会导致接收方的接收缓冲区填充满了，这时候继续传输数据，就会造成大量丢包，进而引起丢包重传等等一系列问题。TCP 支持根据接收端的处理能力来决定发送端的发送速度，这就是流量控制机制。
• 具体实现方式：接收端将自己的接收缓冲区大小放入 TCP 首部的『窗口大小』字段中，通过 ACK 通知发送端。

拥塞控制：

• TCP 传输过程中一开始就发送大量数据，如果当时网络非常拥堵，可能会造成拥堵加剧。所以 TCP 引入了慢启动机制，在开始发送数据的时候，先发少量的数据探探路。

 说说 TCP 协议如何提高传输效率？

一句话：TCP 协议提高效率的方式有滑动窗口、快重传、延迟应答、捎带应答等。

滑动窗口

• 如果每一个发送的数据段，都要收到 ACK 应答之后再发送下一个数据段，这样的话我们效率很低，大部分时间都用在了等待 ACK 应答上了。
• 为了提高效率我们可以一次发送多条数据，这样就能使等待时间大大减少，从而提高性能。 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。

快重传

• 快重传也叫高速重发控制。
• 那么如果出现了丢包，需要进行重传。一般分为两种情况：
• 情况一：数据包已经抵达，ACK被丢了。这种情况下，部分ACK丢了并不影响，因为可以通过后续的ACK进行确认；
• 情况二：数据包直接丢了。发送端会连续收到多个相同的 ACK 确认，发送端立即将对应丢失的数据重传。

延迟应答

• 如果接收数据的主机立刻返回ACK应答，这时候返回的窗口大小可能比较小。
• 假设接收端缓冲区为1M，一次收到了512K的数据；如果立刻应答，返回的窗口就是512K；
• 但实际上可能处理端处理速度很快，10ms之内就把512K的数据从缓存区消费掉了；
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
• 如果接收端稍微等一会在应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M；
• 窗口越大，网络吞吐量就越大，传输效率就越高；我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。

捎带应答

• 在延迟应答的基础上，很多情况下，客户端服务器在应用层也是一发一收的。这时候常常采用捎带应答的方式来提高效率，而ACK响应常常伴随着数据报文共同传输。如：三次握手。

你知道 TCP 如何处理拥塞吗？

网络拥塞现象是指到达通信网络中某一部分的分组数量过多，使得该部分网络来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿，即出现死锁现象。拥塞控制是处理网络拥塞现象的一种机制。

拥塞控制的四个阶段：

1. 慢启动
2. 拥塞避免
3. 快速重传
4. 快速恢复

 讲一下三次握手和四次挥手全过程

序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。

确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。

确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效

 同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。

终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接

    PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。

三次握手 

 

第一次握手：

客户端将TCP报文标志位SYN置为1，随机产生一个序号值seq=n，保存在TCP首部的序列号(Sequence Number)字段里，指明客户端打算连接的服务器的端口，并将该数据包发送给服务器端，发送完毕后，客户端进入SYN_SENT状态，等待服务器端确认。

第二次握手：

服务器端收到数据包后由标志位SYN=1知道客户端请求建立连接，服务器端将TCP报文标志位SYN和ACK都置为1，ack=n+1，随机产生一个序号值seq=k，并将该数据包发送给客户端以确认连接请求，服务器端进入SYN_RCVD状态。

第三次握手：

客户端收到确认后，检查ack是否为n+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=k+1，并将该数据包发送给服务器端，服务器端检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器端进入ESTABLISHED状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

• 为什么需要三次握手？

我们假设client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。

本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。

所以，采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

四次挥手 

第一次挥手： Client端发起挥手请求，向Server端发送标志位是FIN报文段，设置序列号seq，此时，Client端进入FIN_WAIT_1状态，这表示Client端没有数据要发送给Server端了。

第二次分手：Server端收到了Client端发送的FIN报文段，向Client端返回一个标志位是ACK的报文段，ack设为seq加1，Client端进入FIN_WAIT_2状态，Server端告诉Client端，我确认并同意你的关闭请求。

第三次分手： Server端向Client端发送标志位是FIN的报文段，请求关闭连接，同时Client端进入LAST_ACK状态。

第四次分手 ： Client端收到Server端发送的FIN报文段，向Server端发送标志位是ACK的报文段，然后Client端进入TIME_WAIT状态。Server端收到Client端的ACK报文段以后，就关闭连接。此时，Client端等待2MSL的时间后依然没有收到回复，则证明Server端已正常关闭，那好，Client端也可以关闭连接了。

• 为什么连接的时候是三次握手，关闭的时候却是四次握手？

建立连接时因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。所以建立连接只需要三次握手。

由于TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，TCP是全双工模式。

这就意味着，关闭连接时，当Client端发出FIN报文段时，只是表示Client端告诉Server端数据已经发送完毕了。当Server端收到FIN报文并返回ACK报文段，表示它已经知道Client端没有数据发送了，但是Server端还是可以发送数据到Client端的，所以Server很可能并不会立即关闭SOCKET，直到Server端把数据也发送完毕。

当Server端也发送了FIN报文段时，这个时候就表示Server端也没有数据要发送了，就会告诉Client端，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

 为什么 TCP 链接需要三次握手，两次不可以么，为什么？

两次握手只能保证单向连接是畅通的

1. 第一步，客户端给服务端发送一条消息：你好，服务端。 第二步，服务端收到消息，同时给客户端回复一条消息：收到！你好客户端。
2. 这样的两次握手过程， 客户端给服务端打招呼，服务端收到了，说明客户端可以正常给服务端发送数据。但是服务端给客户端打招呼，服务端没有收到反馈，也就不能确保服务端是否能正常给客户端发送消息。

只有经过第三次握手，才能确保双向都可以接收到对方的发送的数据 第三步，客户端收到服务端发送的消息，回复：收到！这样就证明了客户端能正常收到服务端的消息。

 IP地址是怎样分类的，你知道吗？

先说一下 IP 的基本特点：

1. IP地址由四段组成，每个字段是一个字节，8位，最大值是255。
2. IP地址由两部分组成，即网络地址和主机地址。网络地址表示其属于互联网的哪一个网络，主机地址表示其属于该网络中的哪一台主机。

IP 地址主要分为A、B、C三类及特殊地址D、E这五类，甩一张图：

1. A类：(1.0.0.0-126.0.0.0)一般用于大型网络。
2. B类：(128.0.0.0-191.255.0.0)一般用于中等规模网络。
3. C类：(192.0.0.0-223.255.255.0)一般用于小型网络。
4. D类：是多播地址，地址的网络号取值于224~239之间，一般用于多路广播用户。
5. E类：是保留地址。地址的网络号取值于240~255之间。

 讲一下 http1.1 和 http2 有什么区别？ HTTP1.1

1. 持久连接
2. 请求管道化
3. 增加缓存处理（新的字段如cache-control）
4. 增加 Host 字段、支持断点传输等

HTTP2.0

1. 二进制分帧
2. 多路复用（或连接共享）
3. 头部压缩
4. 服务器推送

 说说 HTTP 和HTTPS 的区别？

1. HTTPS 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。
2. HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
3. HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. HTTP 的连接很简单，是无状态的；
5. HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

HTTPS加密（握手）过程 

HTTP+加密+认证+完整性保护 = HTTPS 

 

1. HTTP： 直接通过明文在浏览器和服务器之间传递信息。
2. HTTPS： 采用 对称加密 和 非对称加密 结合的方式来保护浏览器和服务端之间的通信安全。

对称加密算法加密数据+非对称加密算法交换密钥+数字证书验证身份=安全

HTTPS加密请求（一次握手）过程

 

1.  首先，客户端发起握手请求，以明文传输请求信息，包含版本信息，加密-套件候选列表，压缩算法候选列表，随机数，扩展字段等信息(这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。)
2. 服务端的配置，采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会d出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3. 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 以及证书。(这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。)
4. 客户端验证证书的合法性，包括可信性，是否吊销，过期时间和域名。(这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会d出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。)
5. 客户端使用公匙对对称密匙加密，发送给服务端。(这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。)
6. 服务器用私钥解密，拿到对称加密的密匙。(服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。)
7. 传输加密后的信息，这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
8. 客户端解密信息，客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

你知道对称加密和非对称加密的区别和原理吗？ 

1. 对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方;
2. 而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。
3. 由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它比较慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

 常见的状态码有哪些?

1×× : 请求处理中，请求已被接受，正在处理

2×× : 请求成功，请求被成功处理

• 200 OK

3×× : 重定向，要完成请求必须进行进一步处理

• 301 : 永久性转移
• 302 ：暂时性转移
• 304 ： 已缓存

4×× : 客户端错误，请求不合法

• 400：Bad Request,请求有语法问题
• 403：拒绝请求
• 404：客户端所访问的页面不存在

5×× : 服务器端错误，服务器不能处理合法请求

• 500 ：服务器内部错误
• 503 ： 服务不可用，稍等

 http中常见的header字段有哪些？

1. cookie，请求时传递给服务端的cookie信息
2. set-cookie，响应报文首部设置要传递给客户端的cookie信息
3. allow，支持什么HTTP方法
4. last-modified，资源的最后修改时间
5. expires,设置资源缓存的失败日期
6. content-language，实体的资源语言
7. content-encoding，实体的编码格式
8. content-length，实体主体部分的大小单位是字节
9. content-range，返回的实体的哪些范围
10. content-type，哪些类型
11. accept-ranges，处理的范围请求
12. age，告诉客户端服务器在多久前创建了响应
13. vary，代理服务器的缓存信息
14. location，用于指定重定向后的URI
15. If-Match，值是资源的唯一标识
16. User-Agent，将创建请求的浏览器和用户代理名称等信息传递给服务器
17. Transfer-Encoding，传输报文的主体编码方式
18. connection，管理持久连接，keep-alive , close Cache-Control，控制浏览器的强缓存。

Get与POST的区别 

1. GET 一般用来从服务器上获取资源，POST 一般用来创建资源；
2. GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的。GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；
3. 从请求参数形式上看，GET 请求的数据会附在URL之后；而 POST 请求会把提交的数据则放置在是HTTP请求报文的请求体中。
4. POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而 POST 请求参数则被包装到请求体中，相对更安全。
5. GET 请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

DNS 的寻址过程你知道吗？ 

1. 在浏览器中输入www.baidu.com域名， *** 作系统会先检查自己本地的 hosts 文件是否有这个网址映射关系，如果有就先调用这个IP地址映射，完成域名解析。
2. 如果 hosts 里没有这个域名的映射，则查找本地 DNS 解析器缓存，是否有这个网址映射关系，如果有直接返回，完成域名解析。
3. 如果 hosts 与本地 DNS 解析器缓存都没有相应的网址映射关系，首先会找 TCP/IP 参数中设置的首选 DNS 服务器，在此我们叫它本地 DNS 服务器，此服务器收到查询时：
   • 如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
   • 如果要查询的域名，不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析，此解析不具有权威性。
4. 如果本地 DNS 服务器本地区域文件与缓存解析都失效，则根据本地 DNS 服务器的设置（是否设置转发器）进行查询。
   1. 如果未用转发模式，本地 DNS 就把请求发至13台根 DNS ，根 DNS 服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地 DNS 服务器收到IP信息后，将会联系负责 .com 域的这台服务器。这台负责 .com 域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(http://baidu.com)给本地 DNS 服务器。当本地 DNS 服务器收到这个地址后，就会找 百度一下，你就知道 域服务器，重复上面的动作，进行查询，直至找到 百度一下，你就知道 主机。
   2. 如果用的是转发模式，此 DNS 服务器就会把请求转发至上一级 DNS 服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根 DNS 或把转请求转至上上级，以此循环。不管是本地 DNS 服务器用是是转发，还是根提示，最后都是把结果返回给本地 DNS 服务器，由此 DNS 服务器再返回给客户机。

 在浏览器中输入一个http://www.baidu.com后执行的全部过程？

1. 域名解析
2. 建立TCP连接（三次握手）
3. 发起http请求
4. 服务器响应http请求，浏览器得到html代码
5. 浏览器解析html代码，并请求html代码中的资源（如 js、css、图片等）
6. 浏览器对页面进行渲染呈献给用户。

cookie、Session、Token、JWT的区别和实现原理 cookie

cookie 的特点

1. cookie 最开始被设计出来是为了弥补HTTP在状态管理上的不足。
2. cookie 存储在客户端： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
3. cookie 是不可跨域的： 每个 cookie 都会绑定单一的域名（包括子域），无法在别的域名下获取使用。
4. 设置 cookie
5. 服务器向客户端发送 cookie 是通过 HTTP 响应报文实现的，在 Set-cookie 中设置需要向客户端发送的cookie，cookie格式如下：
6. Set-cookie: value[; expires=date][; domain=domain][; path=path][; secure]

cookie 工作流程

 

1. 浏览器向服务器发送请求；
2. 服务器响应请求，向浏览器设置 cookie；
3. 浏览器将 cookie 存在本地，下一次请求带上该 cookie；
4. 服务器响应请求。

Session

session 翻译过来就是『会话』。用户打开一个浏览器, 点击多个超链接, 访问服务器多个web资源, 然后关闭浏览器, 整个过程称之为一个会话。

session 的特点

1. session 是另一种记录服务器和客户端会话状态的机制；
2. session 存储在服务器端，一般是文件中，也可以存在数据库或缓存中。
3. session 一般基于 cookie 实现。session 中包含敏感信息存储在服务器端，通常将 sessionId 存储在客户端的 cookie 中，客户端每次请求携带 sessionId 即可识别用户。

session 工作流程

1. 用户第一次请求，提交用户名密码等信息进行登录认证，服务器根据用户提交的信息进行鉴权，鉴权成功后创建 session 对象，并将 sessionId 塞入 cookie 中，浏览器收到响应信息将 cookie 存入本地；
2. 用户第二次请求，以查看订单信息为例，浏览器自动将当前域名下的 cookie 信息发送给服务端，服务端解析 cookie，获取到 sessionId 后再查找对应的 session 对象，如果 session 对象存在说明用户已经登录，继续下一步 *** 作。
3. 从上面的流程可知，sessionId 是 cookie 和 session 中间的一道桥梁。
4. 需要注意：如果客户端禁用了 cookie，还可以通过 url 重写等方法传递 sessionId。

Token

token 的组成

token 是验证用户身份的凭证，我们通常叫它：令牌。

最简单的token组成: uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，以哈希算法压缩成一定长的十六进制字符串）

 

token 特点

1. 无状态、可扩展
2. 支持移动端设备
3. 支持跨程序调用
4. 安全

token 工作流程

1. 客户端使用用户名密码或者扫码等形式请求登录；
2. 服务端收到请求后进行鉴权，鉴权成功后服务端会生成一个 token 并发送给客户端，客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里；
3. 客户端下一次向服务端请求资源的时候需要带着存储的 token；
4. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据。

需要注意：

1. 客户端请求时可以将 token 放到 HTTP 的 Header 里；
2. 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。
3. 用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

JWT

JWT 是标准化的 token

1. 从本质上讲 JWT 也是一种 token，只不过 JWT 是被大家广泛接受的标准。
2. JWT 即：Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准(RFC 7519)。
3. JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息。

JWT 的组成

 

JWT 共有三部分组成

• 第一部分我们称它为头部（header)
• 第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)
• 第三部分是签证（signature)

JWT 的特点

1. 不在 jwt 的 payload 部分存放敏感信息，因为该部分是客户端可解密的部分。
2. 保护好 secret 私钥，该私钥非常重要。
3. 如果可以，请使用 https 协议。
4. 总结
5. 在分布式微服务技术日趋流行的今天，大型网站的设计都尽量避免使用 session 实现 HTTP 状态化。
6. session简单粗暴，在服务端维护会话信息，在客户端保存session id，服务端能够轻易地把会话控制在自己的手中，但服务集群化产生了session共享的负担；
7. jwt（token）只在客户端保存会话信息，服务端通过密钥校验会话，（相比session）拿时间换空间，卸下了服务端集群共享会话信息的负担，同时也加大了服务端控制会话的难度。

cookie和Session的区别

1. 存储方式：cookie 数据存放在客户端的浏览器上，session 数据放在服务端服务器上；
2. 安全性：cookie 是本地存储，不是很安全，别人可以分析存放在本地的 cookie 并进行欺骗，用户验证这种场合一般会用 session。
3. 存储大小：很多浏览器限制单个 cookie 保存的数据不能超过4K，一个站点最多保存20个cookie，session 没有类似的限制；
4. 生存周期： cookie 可设置为长时间保持，Session 一般失效时间较短，一般客户端关闭 session 就会失效。
5. 运行依赖：session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）

有哪些 web 性能优化技术?

1. DNS查询优化
2. 客户端缓存
3. 优化TCP连接
4. 避免重定向
5. 网络边缘的缓存
6. 条件缓存
7. 压缩和代码极简化
8. 图片优化

什么是 XSS 攻击？ 

1. XSS 即（Cross Site scripting）中文名称为：跨站脚本攻击。XSS的重点不在于跨站点，而在于脚本的执行。
2. XSS的原理是：
3. 恶意攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候，那么嵌入到web页面中script代码会执行，因此会达到恶意攻击用户的目的。
4. XSS攻击最主要有如下分类：反射型、存储型、及 DOM-based型。 反射性和DOM-baseed型可以归类为非持久性XSS攻击。存储型可以归类为持久性XSS攻击。

什么是跨站攻击CSRF？ 

1. CSRF（Cross Site Request Forgery，跨站域请求伪造）是一种网络的攻击方式，它在 2007 年曾被列为互联网 20 大安全隐患之一，也被称为『One Click Attack』或者 『Session Riding』，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。
2. 听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。
3. XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。