东北某不知名双非本，四面成功上岸阿里巴巴，在这里把自己整理的面经分享出来，欢迎大家阅读。

---

补：前段时间面阿里，学习操作系统和计网时，感觉CSDN上貌似没有很系统的，关于二者的面经。因此总结了一下自己的经验，也算是小小的回馈一下一直帮助自己的CSDN。

恰个饭——>《阿里巴巴 Java 开发手册》，业界普遍遵循的开发规范

---

序号	文章名	超链接
1	操作系统面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门1
2	计算机网络面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门2
3	Java并发编程面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门3
4	Java虚拟机(JVM)面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门4
5	MySQL数据库面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门5
6	Java集合面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门6
5	面试阿里，你必须知道的背景知识——双非上岸阿里巴巴系列	2021最新版面经——>传送门7

本博客内容持续维护，如有改进之处，还望各位大佬指出，感激不尽！

---

二更：2021年6月2日
新增字数：3127字
更新内容
1、HTTP与HTTPS增加了更详细解析
2、新增TCP粘包与拆包问题
3、优化了目录结构

---

---

1. 网络篇

1. 公钥和私钥

公钥和私钥是通过一种算法得到的一个密钥对，公钥是秘钥对中公开的部分，私钥是非公开的部分。如果用其中一个密钥加密一段数据，必须用另一个密钥解密。比如用公钥加密数据就必须用私钥解密，如果用私钥加密也必须用公钥解密，否则解密将不会成功。

原则：公钥公开，私钥只有自己拥有。

---

2. 对称加密与非对称加密

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；

​ 非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

​ 由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

总结一下：通过非对称加密的方式把秘钥发送过去，接下来用这个秘钥一直进行对称加密。

即：第一次通信采用非对称加密，接下来的通信采用对称加密

---

3. HTTP的相关问题

3.1 HTTP概念

HTTP协议：超文本传输协议。是应用层协议，是基于TCP协议的，明文传输，客户端与服务器端都无法验证对方的身份；

超文本：广义上的文本，包括图片、视频、压缩包、超链接等。

3.2 HTTP的特点

1、简单、灵活：HTTP头部的各类字段组成都没有固定要求，允许开发人员自定义和补充。

2、无状态：服务器不会记录HTTP的状态，减轻了服务器的开销。 但是在完成关联性操作时不方便（如玩4399小游戏，不能换一个游戏就重新登一次账户）

解决办法：使用Cookie技术，通过在请求和响应报文中写入Cookie信息来来控制客户端的状态。

当客户端第一次请求后，服务器会下发一个装有客户信息的Cookie，后续客户端请求服务器时，带上Cookie，服务器就能识别出是谁。

3、不安全

• HTTP传输文本时采用明文传输，不加密，可以直接看见信息。
• 通信时不会验证双方身份，可能访问虚假用户
• 传输过程中的报文可能遭到无疑篡改。

3.3 HTTP的状态码

写法	类别	解释
1xx	Information（信息状态码）	接受的请求正在处理
2xx	Success（成功状态码）	请求正常处理完毕
3xx	Redirection（重定向状态码）	需要进行附加操作以完成请求
4xx	Client Error（客户端错误状态码）	服务器无法处理请求
5xx	Server Error（服务端错误状态码）	服务器处理请求出错

---

4. HTTPS相关问题

1. HTTPS概念

HTTPS协议是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。

2. HTTPS为什么安全？

1、混合加密

作用：防窃听

混合加密：即同时采用公钥和私钥加密，更安全，更高效，更不易被破解。 具体操作方法见问本文章的第一个问题。

• HTTPS采用对称加密和非对称加密结合的混合加密方式
• 在通信建立前采用非对称加密的方式交换秘钥，后续就不在使用非对称加密
• 在通信过程中全部使用对称加密的会话秘钥方式，加密明文数据。

2. 摘要算法

作用：防止数据被篡改。

摘要算法：实现数据完整性，能够为数据生成独一无二的指纹，指纹用于校验数据的完整性，解决了被篡改的风险。

过程
1、客户端发送明文前，会通过摘要算法算出明文的指纹，发送时明文和指纹一同加密，发送给服务器。

2、服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的指纹和当前指纹做比较，若相同，则说明数据是完整的。

3. 数字证书

作用：解决身份认证问题。

过程：借助第三方权威机构CA（数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构办法）中，只要证书是可信的，公钥就是可信的。

3. 采用HTTPS加密的具体流程：

假设电脑A要向电脑B发送数据

电脑A发送数据前，先通过摘要算法计算出明文的指纹，然后将明文+指纹打包成数据包，并将自己的对称加密的秘钥放入数据报， 同时向电脑B索要公钥。

电脑B将公钥发送过来后，电脑A采用非对称加密的方式，通过电脑B的公钥将自己的数据包加密（非对称加密的原理见之前的解答），加密后，发送给电脑B

电脑B收到电脑A发送过来的数据包后，发现是非对称加密的方式，于是使用自己的私钥解密， 解密后通过计算该数据包的指纹， 与数据包内指纹对比， 若指纹相同，则表示数据没有丢失。

接下来的通信，双方都将使用数据包内的秘钥以对称加密的方式通信。

---

5. HTTP与HTTPS区别

端口不同：HTTP与HTTPS使用不同的连接方式，用的端口也不一样，前者是80，后者是443；

资源消耗：和HTTP通信相比，HTTPS通信会由于加减密处理消耗更多的CPU和内存资源；

开销：HTTPS通信需要证书，而证书一般需要向认证机构购买；

---

6. 客户端在使用HTTPS方式与Web服务器通信时的步骤

​ （1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。

（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

（5）Web服务器利用自己的私钥解密出会话密钥。

（6）Web服务器利用会话密钥加密与客户端之间的通信。

---

7. 从输入URL到页面加载发生了什么

大致流程

1. DNS请求

2. HTTPs加密

3. TCP连接

4. 发送HTTP请求

5. 服务器处理请求并返回HTTP报文

6. 浏览器解析渲染页面

7. 连接结束

8. DNS解析（核心：递归、映射）

具体叙述

1. DNS概述

   如果说ARP协议是用来将IP地址转换为MAC地址，则DNS协议就是将域名转换为IP地址。（IP地址面向主机，域名面向用户）。
    
   DNS(Domain Name System，域名系统)，因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

   域名服务器是层级结构，依次分为根域名、顶级域名、权限域名、本地域名服务器

2. 域名解析过程

   1 输入域名后，先查找自己主机对应的域名服务器，域名服务器先查找自己数据库中的数据

   2 若没有，就向上级域名服务器进行查找，以此类推

   3 最多回溯到根域名服务器

   4 DNS缓存：域名服务器自身也会进行缓存，把曾经访问过的域名和IP缓存，加速查找

   5 DNS负载均衡：DNS返回的IP地址并非每次都一样，DNS可以根据每台机器的负载量、该机器离用户地理位置的距离等返回一个合适机器的IP给用户。

3. HTTPs加密

   见上一个回答

4. 建立TCP连接

   同上

5. HTTP请求

   1 http为80，https为443.

   2 请求报文：请求报文头、请求行、请求正文

   3 常用方法：get、post

6. 服务器进行HTTP响应

   响应报文头、状态码、响应报文

7. 浏览器解析渲染页面

   1 接收到响应报文后，解析HTML、css、js等文件进行解析渲染首部

   2 先解析HTML文件构建dom树，接下来解析CSS文件构建渲染树，使用JS引擎对JS进行解析

8. Web优化：对内容压缩、对一些内容缓存等。

---

8. TCP协议的六种标志

SYN：同步标志

置1表示请求进入同步状态，二者同步即可通信。

ACK：确认标志

置1表示确认号合法，为0表示数据段不包含确认信息，确认号被忽略。

RST：复位标志

用于复位某种原因引起出现的错误连接

URG：紧急标志

紧急指针，置1时，用来避免TCP数据流中断。

PSH：推送标志

置1时，请求的数据段在接收方得到后直接送到应用程序，不必等待缓冲区满再传送

FIN：完成标志

置1时，表示此为完成报文，用来释放连接，表示发送方已经没有数据发送了

---

9. IP地址分类

ABCDE五类，ABC为基本类，DE作为多播和保留使用，为特殊地址。

A类地址：以0开头

B类地址：以10开头

C类地址：以110开头

D类地址：以1110开头

E类地址：以1111开头，保留地址

---

10. 常见状态码

1**：请求已被接受，正在处理

2**：请求被成功处理 200ok

3**：重定向，要完成请求必须进一步处理（301 永久性转移，302：暂时性转移，304：已缓存）

4**：客户端错误，请求不合法（400，请求有语法问题；403:拒绝请求；404:客户端所访问的页面不存在）

5**：服务器错误（500:服务器内部错误；504:服务器不可用）

---

11. 三次握手与四次挥手

参考博客——>传送门

1.1 三次握手过程

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN。此时客户端处于 SYN_SENT 状态。

首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

1.2 为什么要三次握手，两次不行吗？

• 第一次握手：客户端发送网络包，服务端收到了。
  这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。
  这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。
  这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

若为两次握手，会出现如下情况：

若客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传请求，收到确认，建立连接。

但可能第一个丢失的报文段只是在某些网络节点长时间滞留了，延误到连接释放以后的某个时间才到达服务端。

此时服务端会误认为客户端又发出一次新请求，同意建立连接。会浪费资源。

1.3 三次握手过程中可以携带数据吗

第三次握手时可以携带数据，但是第一、二次不行。

原因：设想这样的场景：若第一次握手可以携带数据，有人要恶意攻击服务器，则他每次都可以在第一次握手中的SYN报文中放入大量数据，会让服务器花费很多时间、空间来处理报文。

也就是说：第一次握手无法放数据，保证了服务器的安全性。而第三次握手时，已经代表成功的建立了连接，从客户端携带数据到服务器也是被理解的。

1.4 SYN攻击是什么

概念：Client在短时间伪造大量不存在的ip地址，向Server不断发送SYN包，Server则回复确认包，并等待Client确认，这些包将长时间占用未连接队列，导致正常的SYN请求因为队列满被丢弃，从而引起网络拥塞甚至系统瘫痪（Dos/DDoS攻击）

如何检测：当看到大量半连接状态，且源地址IP为随机时，即可断定为一次SYN攻击（Linux中的netstat命令）。

解决办法：缩短SYN时间，过滤网关防护等。

2.1 四次挥手

为什么建立一个连接要三次握手，而终止需要四次呢？这是由TCP的半关闭造成的。即，TCP提供了连接的一段在结束它的发送后还能接收来自另一端数据的能力。

双方均可主动发起挥手

假设客户端先发起关闭请求：

• 第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。

  即：报文段：FIN=1，seq=u。 客户端进入FIN_WAIT1状态。

• 第二次挥手：服务器收到FIN后，会发送ACK报文，且把客户端序列号值+1作为ACK报文的序列号值，表示已经收到客户端的报文了，此时服务器处于CLOSE_WAIT状态。

  即：报文段：ACK=1，ack=u+1，seq=v。服务器进入CLOSE_WAIT状态。客户端收到服务端的确认后，进入FIN_WAIT2状态。

• 第三次握手：如果服务器也想断开连接了，发送FIN报文，并且由于这是对于回应报文，因此确认标志ACK仍需置1，服务器端处于LAST_ACK状态

  即：报文段：ACK=1，FIN=1，ack=u+1(仍算是对seq=u的回应)，seq=w。，服务器进入LAST_ACK状态。

• 第四次握手：客户端收到FIN后，发送一个ACK作为应答，此时客户端处于TIME_WAIT2状态，而服务端收到ACK报文后，就处于CLOSED状态

  即：报文段：ACK=1，seq=u+1(第一次为seq=u)，ack=w+1。客户端进入TIME_WAIT状态，此时TCP还未释放掉，需要经过时间等待计时器设置的时间2msl后，客户端才进入CLOSED状态。

2.2 挥手为什么需要四次

当服务器端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”，只有等我服务端所有的报文都发送完毕， 我才能发送FIN报文。

2.3 等待2MSL的意义

MSL译为“最长报文段寿命”，是任何报文在网络上存在的最长时间，超过这个时间，报文将被丢弃。

理由一：保证客户端发送的最后一个ACK报文段能够到达服务端。

若客户端发送的最后一个ACK报文段在传输过程丢失，服务器接受不到回应，会启动超时重传机制，超时重传FIN-ACK。接下来客户端再重传一次确认，重新启动等待计时器。最后客户端和服务器都正常关闭。

假设客户端不能带2MSL，而是在发送完ACK后直接释放关闭，一旦这个ACK丢失的话，服务器就无法正常进入关闭连接状态。

理由二：防止“已失效的连接请求报文段”出现在本连接中

---

2 TCP与UDP篇

核心：TCP安全但麻烦， 可试着从TCP首部讲起

1. 网络中各层协议

1. 应用层

典型设备：应用程序

协议

• FTP：文件传输协议<21>，减少或消除不同操作系统下处理文件的不兼容性
• SSH/TLS：安全外壳协议
• SMTP/POP3：用于发送/接收邮件
• HTTP：超文本传输协议<80>，面向事务的应用层协议

2. 传输层

典型设备：进程和端口

数据单元：数据段

协议

• TCP：面向连接、可靠、有序、无丢失、不重复
• UDP：最大努力交付

3. 网络层

典型设备：路由器、防火墙、多层交换机

数据单元：数据包

协议

• IP：网络之间互连的协议
• ARP：地址解析协议，实现通过IP地址得知其物理地址
• ICMP：Internet控制报文协议，在IP主机、路由器之间传递控制消息
• RIP：路由信息协议
• BGP：边界网关协议

4. 数据链路层

典型设备：网卡、网桥、交换机

数据单元：帧

协议

• ARQ：自动重传请求协议，错误纠正协议（停止等待ARQ协议和连续ARQ协议）
• 停止等待协议：CSMA/CD：总线型网络，载波监听、碰撞检测
• PPP：点对点协议

校验方法：循环冗余校验CRC

5. 物理层

典型设备：中继器、集线器、网线等

数据单元：比特bit

---

2. TCP与UDP

1. TCP首部

源端口号/目标端口号：表示数据从哪个进程来，到哪个进程去。

32位序号：由于TCP面向字节流，将大文件拆分成多个字节传输，序号的作用是为字节排序。

确认序号：告诉对方，要从第几个字节开始发数据，起到确认收到的作用。

首部长度：表示首部长度

保留位：无作用

6个标志

窗口：告诉对方本人的接收窗口有多大，你的发送窗口不得大于我的接收窗口，否则会出现大量的包被丢弃

校验和：对信息进行验证，防止信息在传送过程中丢失

紧急指针：紧急发送数据的方式

---

2. UDP首部

---

3. 特点与区别

• TCP面向连接：传递数据前，有三次握手建立连接，传递数据时，有确认、窗口、重传和拥塞控制机制，数据传完后，还会通过四次握手断开连接

• UDP无连接：知道对端的IP和端口号就可以发送，尽最大努力交付，无需建立连接，不可靠

---

• TCP面向字节流：把数据看成一连串无结构的字节流
• UDP面向报文：没有拥塞控制

---

• TCP的通信：点对点
• UDP通信：支持一对一、一对多、多对一、多对多通信

---

• TCP首部开销20字节
• UDP首部开销8字节。

---

4. TCP如何保证传输数据的可靠性

1. 对失序数据包重排序（序号字段）：由于TCP面向字节流，因此当TCP报文段到达时，会根据序号字段对数据重排序

2. 数据包校验（校验字段）：若数据在传输过程中出错or丢失，则直接丢弃，启动超时重传；若发送了重复数据，则丢弃重复数据

3. 超时重传：当TCP发送一个段后，会启动一个定时器，等待目的端确认收到这个报文段，若不能及时收到一个确认，将重发这个报文段

4. 流量控制：TCP连接的每一方都有固定大小的缓存空间，TCP接收端只允许另一端发送接收端缓冲区所能接纳的数据，可以防止较快主机使较慢主机的缓冲区溢出。

   流量控制协议是：滑动窗口协议

5. 拥塞处理

---

5. TCP的拥塞处理

拥塞窗口cwnd

其值取决于网络的拥塞程度，且动态变化。

维护原则：只要网络没有出现拥塞，就增大一些，出现了，就减小一些。

判断是否出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生重传）

慢开始门限ssthresh

cwnd < ssthresh：使用慢开始算法

cwnd > ssthresh：使用拥塞避免算法

cwnd = ssthresh：既可以使用慢开始算法，也可使用拥塞避免算法

拥塞处理概念

若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能会变坏，这种情况叫拥塞。

拥塞控制就是：防止过多的数据注入网络，可以使网络中的路由器或链路不至过载。

拥塞控制的方法主要有以下四种：

1 慢开始：每个传输轮次，拥塞窗口cwnd能传输的报文段都扩大一倍。当cwnd等于慢开始门限后，改用拥塞避免算法。

2 拥塞避免：让拥塞窗口缓慢增长，传输轮次，cwnd能传输的报文段数量+1。

若发生重传，则cwnd置1，ssthresh减半，并重新开始慢开始算法。

3 快重传：使发送方尽快进行重传。报文段都是按顺序传送的，若收到了失序的报文段，要发出对已收到报文段的重复确认。

发送方一旦受到三个连续的重复确认，就将相应的报文段立即上传。而不是等报文段的超时重传计时器超时在重传。

并直接执行快恢复算法。

4 快恢复：将慢开始门限ssthresh值和拥塞串钩cwnd值调整为当前窗口的一半，开始执行拥塞避免算法。

---

6. TCP粘包和拆包

1. 什么是TCP粘包？

TCP粘包是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓存区来看，后一包的数据头紧接着前一包的数据尾，出现粘包的原因是多方面的，可能来自发送方，也可能来自接收方。

2. TCP粘包原因

1、发送方原因：

要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

TCP默认使用Nagle算法，Nagle算法可能造出现粘包问题。

Nagle算法主要作用：减少网络中报文段的数量。而Nagle算法主要做两件事：

1. 只有上一个分组得到确认，才会发送下一个分组
2. 收集多个小分组，在一个确认到来时一起发送

2、接收方原因
接收数据端的应用层没有及时读取接收缓存区中的数据，将发生粘包。

3. 什么时候需要处理粘包现象

1. 若粘包的多组数据为同一块数据(文件)的不同部分，则无需处理。
2. 若多个分组毫无关联，则需要处理粘包现象。

4. 如何处理粘包现象？

1、发送方
可以通过关闭Nagle算法解决，使用TCP_NODELAY选项来关闭算法
2、接收方
接收方没有办法处理粘包显现，只能交给应用层处理
3、应用层
应用层解决粘包的方法非常简单，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。

解决方法：循环处理，应用程序从接受缓存中读取分组时，读完一条数据，就应循环读取下一条数据，直到所有数据都被处理完成，但如何判断每条数据的长度呢？

1. 格式化数据：每条数据都有固定格式，如开始符，结束符等。
   这种方法简单可行，但选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。
2. 发送长度：发送每条数据时，数据包中有专门的位置记录该数据的长度，当应用层读取数据包时，就可以根据数据包长度将每个分组进行拆包。

应用层处理粘包的方法叫拆包。

5. UDP会不会产生粘包问题？

TCP：为了保证可靠传输并减少额外开销，采用了基于流的传输，流传输不会把消息按个传输，而是无保护消息边界的。

保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息。

UDP：面向消息传输，有保护消息边界，接收方一次只接受一条独立的消息，因此不存在粘包问题。

---

7. get与post区别

1. get在浏览器回退时是无害的，因为其会被浏览器主动cache，而post会再次提交请求。
2. get请求只能进行url编码，在url中传送的参数有长度限制，并且参数直接暴露在url上，不安全。而post没有，post放在request body中。
3. 对参数的数据类型，get只接受ascll字符，而post没有限制

底层原理

由于Http的底层是TCP/IP、所以get/post的底层也是TCP数据包，不同的是，对于get，浏览器会把http header和data一并发送出去，服务器响应200；而对于post，浏览器先发送header，服务器响应100 continue，浏览器在发送data，服务器响应200 ok（返回数据）

GET请求如何进行URL编码

将数据解析成ASCII码表示，服务器端在接收到数据时，就可以遍历字节流。通过&，=等关键信息来确定数据之间的分割。

如果字符串本身就带有&，=这些关键字呢？

解决办法：在其前面加上%，这样服务端会把紧跟在%后的字节当成普通字节。

---

3. 缓存篇

session、cookie与Application

Session机制采用的是服务器保持状态的方案

Cookie机制采用的是客户端保持状态的方案

1 cookie及其API

Cookie实际上是一小段文本信息，客户端请求服务器，若服务器需要记录用户状态，就是用response向客户端颁发一个cookie。

当浏览器再次请求该网站时，浏览器会把请求的网址连通该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。

2 Session及其API

客户端请求服务器，若用服务器记录该用户状态，就获取session来保存状态。

这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用

若客户端请求不包含sessionid，则为此客户端创建一个session并生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。

保存sessionid的方式可以采用cookie机制。

3 Session与Cookie比较

实现机制：Session的实现常常依赖于Cookie。通过Cookie机制回传SessionID。

大小限制：Cookie有大小限制，并且浏览器对每个站点也有个数限制，session无大小限制，理论上只与服务器的内存大小有关。

安全性：Cookie存在安全隐患，通过拦截或本地文件找到cookie后可以进行攻击，而session由于保存在服务器端，相对更安全。

服务器资源消耗：Session保存在服务器端过一段时间才会消失，若session过多会增加服务器压力。

4 Application

即JavaWeb中的ServletContext：与一个Web应用程序相对于，为应用程序提供了一个全局状态，所有客户都可以使用该状态。

---

4. 攻击篇

这部分考察点很少，一般来说记住XSS就可以了

1. XSS攻击

指恶意攻击者利用网站没有对用户提交的数据进行转义处理or过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去。

使别的用户访问都会执行响应的嵌入代码，进而盗取资料、利用用户身份侵害等。如非法转账、强制发送邮件等。

主要原因：过于信任客户端提交的数据

解决办法：只要是客户端提交的数据，都应进行相应的过滤处理才能进行下一步操作。如将重要的信息设置为Http only等