面试计算机网络八股文五问五答第一期
面试计算机网络八股文五问五答第一期
作者：程序员小白条，个人博客
相信看了本文后，对你的面试是有一定帮助的！
⭐点赞⭐收藏⭐不迷路！⭐
1.TCP和UDP的区别
TCP和UDP是两种网络传输协议，它们的主要区别在于它们的工作方式、性能和适用场景。
- 工作方式：
TCP（Transmission Control Protocol）是一种面向连接的协议，需要在客户端和服务器之间建立一个连接，然后再进行数据传输。它提供了可靠的、有序的、全双工的数据流传输，通过确认、重传、窗口控制等机制来保证数据的可靠传输。TCP是一种面向字节流的协议，数据是以数据流的形式传输的，没有数据报文的概念。
UDP（User Datagram Protocol）是一种无连接的协议，数据传输之前不需要在客户端和服务器之间建立连接。它提供了不可靠的、无序的、非全双工的数据包传输，不保证数据的可靠传输。UDP是一种面向数据报文的协议，每个数据报文都会被独立处理，不与其他报文建立任何关系。
- 性能：
TCP协议通过可靠性机制和拥塞控制来保证数据的可靠传输，因此它的传输速度相对较慢。UDP协议没有可靠性机制和拥塞控制，数据传输的速度相对较快。
- 适用场景：
TCP协议适用于需要可靠传输、数据量大、传输距离较远的场景，例如HTTP、FTP等应用层协议。UDP协议适用于实时性要求高、数据量小、传输距离短的场景，例如音视频传输、网络游戏等。
总的来说，TCP协议适用于需要数据可靠性和顺序性的场景，而UDP协议适用于对实时性要求较高、数据可靠性要求较低的场景。
需要注意的是，在实际应用中，TCP和UDP协议并不是完全对立的，它们经常被结合使用，例如在音视频传输中，使用UDP协议进行数据传输，而使用TCP协议进行控制和信令传输。
2.TCP三次握手和四次挥手，为什么不能是两次握手，三次挥手?
TCP是一种面向连接的协议，其三次握手和四次挥手的过程是为了建立和终止连接，保证通信的可靠性和完整性。
三次握手的过程是：
- 客户端向服务器发送SYN包（SYN=1，表示请求建立连接），并进入SYN_SENT状态。
- 服务器收到SYN包，返回SYN+ACK包（SYN=1，ACK=1，表示确认请求并同意建立连接），并进入SYN_RCVD状态。
- 客户端收到SYN+ACK包，发送ACK包（ACK=1，表示确认收到服务器的同意），并进入ESTABLISHED状态。
如果使用两次握手，那么会存在一种情况：客户端发送了SYN包，但是由于网络原因或其他问题导致该包延迟了一段时间到达服务器，此时服务器认为客户端要建立连接，向客户端发送了SYN+ACK包，并进入SYN_RCVD状态。但是客户端在等待服务器的ACK包时，却没有收到服务器的SYN+ACK包，认为连接未建立，所以不发送ACK包。这时，服务器一直在等待客户端的ACK包，连接也无法建立，造成资源浪费和效率低下。
四次挥手的过程是：
- 客户端向服务器发送FIN包（FIN=1，表示要关闭连接），并进入FIN_WAIT1状态。
- 服务器收到FIN包，返回ACK包（ACK=1，表示确认收到客户端的请求），并进入CLOSE_WAIT状态。
- 服务器的应用程序将所有数据发送给客户端后，向客户端发送FIN包，并进入LAST_ACK状态。
- 客户端收到FIN包后，发送ACK包（ACK=1，表示确认收到服务器的关闭请求），并进入TIME_WAIT状态，等待2MSL（最大报文段生存时间）后关闭连接。
如果使用三次挥手，那么会存在一种情况：客户端发送FIN包，服务器收到后立即返回ACK包，并进入CLOSE_WAIT状态。此时，客户端还有数据没有发送完毕，但是服务器已经关闭连接，客户端只能等待超时，才能关闭连接，造成连接的资源浪费。
因此，TCP协议采用三次握手和四次挥手的方式，以保证连接的可靠性和完整性。
3.TLS的握手过程
https的信息加密是混合加密，也就是对称加密与非对称加密。双方通通信开始前要协商密钥，密钥协商时采用的是非对称加密，进行通信时使用的对称加密。
在密钥协商阶段主要用到以下几种算法：
- RSA算法
- DH算法
- ECDHE算法
TLS第一次握手
clientHello阶段，客户端向服务器发送请求，发送SSL/TLS版本，发送客户端支持的密码套件列表，然后会产生一个随机数（Client Random），发送给服务器，这是生成对称密钥的材料。
第一次握手客户端做的事：
客户端clientHello，客户端发送请求
确定SSL/TLS版本
客户端生成的随机数，用于生成会话密钥（Client Random）
客户端支持的密码套件列表，如RSA算法TLS第二次握手
服务器会确定自己所支持的SSL/TLS版本，如果不支持，则直接关闭此次连接。在客户端发送来的密码套件中选择一套。生成一个随机数（Server Random）
serverHello阶段，服务器响应客户端的请求，发送SSL/TLS版本，发送服务器选择的密码套件，发送随机数
密码套件：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法
WITH单词前面只有一个单词RSA
密钥交换算法和签名算法都是RSA
加密对称算法采用的是AES算法，密钥长度为128位，分组模式为GCM
摘要算法为SHA256，用于消息认证和产生随机数
发送数字证书
最后会发一个Server Hello Done的信息
第二次握手服务器做的事：
服务器接收到客户端请求，进行响应
确定SSL/TLS版本，如果不支持，直接关闭
服务器生成的随机数，后面用于生成会话密钥（Server Random）
确定服务器支持的密码套件列表，如RSA加密算法
发送数字证书
客户端拿到服务器的响应后，会去验证证书的证实有效性
数字证书包含:
公钥
持有者信息
有效时间
证书认证机构（CA）的信息
其他信息
数字证书的签发流程
CA会把一些基本信息例如持有者、用途、有效信息等打包，然后运用Hash算法得到一个Hash值
CA会使用自己的私钥将这个Hash值加密，生成一个Certificate Signature（证书签名），CA对证书进行了签名
最后将签名加到证书文件，形成数字证书
客户端验证证书的流程
客户端使用同样的Hash算法，得到该证书的Hash值H1
浏览器使用CA的公钥，解密Certificate Signature中的内容，得到Hash值H2
如果H1等于H2，则证明可信
TLS的第三次握手
证书有效，客户端生成一个随机数（pre-master），用服务器的RSA公钥加密，然后通过Change Cipher Key Exchange消息发给服务器
服务器收到后，用私钥解密收到pre-master
到此阶段，客户端和服务器共享了三个数，Client Random、Server Random、pre-master，双方根据这三个数生成密钥
生成密钥后客户端再发一个Change Cipher Spec告诉服务器开始使用加密通话
最后在发送一个Encrypted HandShare Message消息，向服务器发送握手摘要，再加密一下，让服务器验证
第三次握手客户端做的事：
向服务器进行响应
发送一个随机数（密钥），该随机数会被公钥加密（pre-master）
加密算法改变的通知，表示之后的会话都将用会话密钥进行加密（Change Cipher Key Exchange）
客户端响应结束通知，握手数据的摘要（Encrypted HandShare Message）
TLS的第四次握手
服务器也是相同操作，发送Change Ciper Spec和Encrypted HandShare Message
服务器进行响应
加密算法改变通知，表示之后的信息会用加密的密钥进行加密（Change Ciper Spec）
服务器响应结束通知，握手数据的摘要（Encrypted HandShare Message）
RSA算法的缺陷
RSA算法最大的问题就是不支持前向保密，服务器的私钥一旦泄露，被第三方截获的TLS密文都会被破解
所以才有了DH算法
DH算法
客户端和服务器都各自产生一个随机数，生成一个私钥，然后根据公开的DH算法，算出自己的公钥，再把这个公钥通过TLS互换，这要有了自己的私钥和对方的公钥，就可以解密报文。
即时公钥被截取了，在不知道私钥的情况下也无法计算出密钥。
但是DH算法存在计算效率的问题，所以出现了ECDHE密钥协商算法
ECDHE算法
根据私钥的生成算法，有两种模式
DH算法（服务器的私钥是不变的）缺点是时间长了服务器的私钥有被破解的可能
DHE算法（目前常用）E（ephemeral）的意思就是临时性的
双方的私钥在每次密钥交换通信时都是临时生成的。但是这种算法的性能不佳，所以出现了ECDHE算法
ECDHE算法
在DHE算法的基础上，利用了ECC椭圆曲线的特性，可以优化计算公钥和最终会话密钥的计算量
ECDHE算法流程（实质就是通过椭圆曲线特性计算公钥）
双方事先确定好使用什么椭圆曲线，和曲线上的基点G，两个参数都是公开的
双方各自随机生成私钥d，将G乘以私钥d得到公钥Q（Q=Gd），客户端的公私钥为d1和Q1，服务器的公私钥为d2和Q2
双方交换公钥，客户端计算d1Q2，服务器计算d2Q1，由乘法交换律和结合律得d2Q1 = d2d1G = d1d2G = d1Q2,双方的坐标都是一样的，实现了共享密钥
此过程双方的私钥都是随机、临时生成的，不公开的。
4.对加密方式有了解吗?
在加密领域中，有许多不同的算法和加密方式，包括对称加密和非对称加密。下面是对这两种加密方式的介绍以及它们的使用场景、优缺点的全面介绍：
- 对称加密： 对称加密算法使用相同的密钥进行加密和解密，加密和解密的过程使用相同的密钥，因此被称为对称加密。常见的对称加密算法包括 DES、AES、RC4 等。 优点：
- 加密解密速度快，适合大数据量的加密和解密操作。
- 算法简单，实现容易，适用于嵌入式系统和资源受限的环境。 使用场景：
- 对称加密适合用于在相对安全的环境中，即通信双方共享同一密钥的情况，例如在内部网络通信、文件加密和本地数据传输等场景。
缺点：
- 密钥管理复杂，密钥需要在通信双方之间安全地共享和管理。
- 不适合在不可信的环境中使用，因为一旦密钥泄露，所有的加密数据都可能被破解。
2.非对称加密： 非对称加密算法使用一对密钥，包括公钥和私钥，公钥用于加密，私钥用于解密。公钥可以公开分享给任何人，而私钥必须保密。常见的非对称加密算法包括 RSA、DSA、ECC 等。 优点：
- 提供了更强的安全性，不需要共享密钥。
- 可以用于身份验证和数字签名等安全场景。
使用场景：
- 非对称加密适合用于在不可信的环境中进行安全通信，例如在互联网上进行数据传输、数字签名、身份验证等场景。
缺点：
- 加解密速度较慢，不适合大数据量的加密和解密操作。
- 算法复杂，实现相对较复杂。
综上所述，对称加密和非对称加密各有优点和缺点，应根据具体的业务需求、安全要求和性能要求来选择合适的加密方式。在实际应用中，通常可以结合对称加密和非对称加密，例如使用非对称加密进行身份验证和密钥协商，然后使用对称加密进行实际的数据传输。
假设有一个在线购物网站，用户需要在网站上进行购物并提交订单，然后通过支付渠道进行支付。为了保护用户的支付信息和订单数据的安全，网站需要使用加密技术来保护这些敏感信息。
- 对称加密的使用场景： 网站可以使用对称加密算法来加密用户的订单数据，例如使用 AES 加密算法。在这种情况下，网站和支付渠道之间共享相同的密钥，用于加密和解密订单数据。在用户提交订单时，网站使用密钥对订单数据进行加密，然后将加密后的数据传输给支付渠道。支付渠道收到加密的订单数据后，使用相同的密钥进行解密，从而得到原始的订单数据进行处理和支付。
- 非对称加密的使用场景： 网站可以使用非对称加密算法来保护支付信息的安全。例如，网站可以使用 RSA 算法生成一对公钥和私钥。公钥可以公开分享给任何人，用于加密用户的支付信息。在用户提交订单时，网站使用公钥对支付信息进行加密，然后将加密后的支付信息传输给支付渠道。支付渠道收到加密的支付信息后，使用私钥进行解密，从而得到原始的支付信息进行处理和支付。
总结：
- 对称加密适合在相对安全的环境中，通信双方共享相同密钥的情况，例如在内部网络通信、文件加密等场景，因其加解密速度快且实现简单。
- 非对称加密适合在不可信的环境中进行安全通信，例如在互联网上进行数据传输、数字签名、身份验证等场景，因其提供了更强的安全性和身份验证能力。
在实际应用中，可以根据具体需求和安全要求，综合考虑对称加密和非对称加密的优缺点，选择合适的加密方式来保护敏感信息的安全。
5.TLS加密的过程
TLS（Transport Layer Security）是一种网络通信协议，用于在客户端和服务器之间实现加密和认证的安全传输。TLS加密的过程可以分为以下几个步骤：
- 协商加密算法：客户端向服务器发送协议版本和支持的加密算法列表等信息。服务器选取一种加密算法，并将其发送给客户端。
- 证书认证：服务器将自己的数字证书发送给客户端。客户端会验证证书的有效性，包括证书的颁发机构和有效期等。如果证书有效，则继续下一步；否则，通信结束。
- 协商会话密钥：客户端生成一个随机的会话密钥，并使用服务器公钥进行加密，然后将加密后的密钥发送给服务器。服务器使用自己的私钥解密，并获取会话密钥。
- 加密报文传输：客户端和服务器会使用协商的加密算法和会话密钥对通信内容进行加密和解密。这样，通信内容在传输过程中是加密的，保证了数据的机密性。
- 完整性校验：TLS使用消息认证码（MAC）来保证通信内容的完整性。服务器使用会话密钥对消息进行哈希计算，生成MAC，并将其发送给客户端。客户端也使用会话密钥进行哈希计算，然后比较和校验收到的MAC，确保通信内容没有被篡改。