计算机网络面经大全——双非上岸阿里巴巴系列

Posted 2021-06-01 来老铁干了这碗代码

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

---

序号	文章名	超链接
1	操作系统面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门1
2	计算机网络面经大全——双非上岸阿里巴巴系列	2021最新版面经——>传送门2
3	面试阿里，你必须知道的背景知识——双非上岸阿里巴巴系列	2021最新版面经——>传送门3

如有疏漏之处，还望各位大佬指出，感激不尽！内容持续更新中…

---

文章目录

• • 1. 网络篇
  • • 1. Http和Https的区别
    • 2. 公钥和私钥
    • 3. 对称加密与非对称加密
    • 4. 客户端在使用HTTPS方式与Web服务器通信时的步骤
    • 5. 从输入URL到页面加载发生了什么
    • • 大致流程
      • 具体叙述
    • 6. TCP协议的六种标志
    • 7. IP地址分类
    • 8. 常见状态码
    • 9. 三次握手与四次挥手
    • • 1.1 三次握手过程
      • 1.2 为什么要三次握手，两次不行吗？
      • 1.3 三次握手过程中可以携带数据吗
      • 1.4 SYN攻击是什么
      • 2.1 四次挥手
      • 2.2 挥手为什么需要四次
      • 2.3 等待2MSL的意义
  • 2 TCP与UDP篇
  • • 1. 网络中各层协议
    • • 1. 应用层
      • 2. 传输层
      • 3. 网络层
      • 4. 数据链路层
      • 5. 物理层
    • 2. TCP与UDP
    • • 1. TCP首部
      • 2. UDP首部
      • 3. 特点与区别
    • 4. TCP如何保证传输数据的可靠性
    • 5. TCP的拥塞处理
    • 6. get与post区别
  • 3. 缓存篇
  • • session、cookie与Application
    • • 1 cookie及其API
      • 2 Session及其API
      • 3 Session与Cookie比较
      • 4 Application
  • 4. 攻击篇
  • • 1. XSS攻击

1. 网络篇

1. Http和Https的区别

Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

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

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

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

Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

---

2. 公钥和私钥

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

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

---

3. 对称加密与非对称加密

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

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

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

---

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

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

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

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

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

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

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

---

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

大致流程

1. DNS请求

2. HTTPs加密

3. TCP连接

4. 发送HTTP请求

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

6. 浏览器解析渲染页面

7. 连接结束

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

具体叙述

1. DNS概述

   如果说ARP协议是用来将IP地址转换为MAC地址，则DNS协议就是将域名转换为IP地址。（IP地址面向主机，域名面向用户）。

   DNS是一个组织的系统管理机构，维护系统内每个主机IP和主机名的对应关系，用户输入域名时，会自动查询DNS服务器，得到对应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优化：对内容压缩、对一些内容缓存等。

---

6. TCP协议的六种标志

SYN：同步标志

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

ACK：确认标志

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

RST：复位标志

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

URG：紧急标志

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

PSH：推送标志

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

FIN：完成标志

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

---

7. IP地址分类

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

A类地址：以0开头

B类地址：以10开头

C类地址：以110开头

D类地址：以1110开头

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

---

8. 常见状态码

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

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

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

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

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

---

9. 三次握手与四次挥手

参考博客——>传送门

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. 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等