计算机网络八股文

1. 网络分层结构

七层结构

** **TCP/IP 四层模型

2.TCP三次握手和四次挥手

建立一个 TCP 连接需要“三次握手”，缺一不可 ：

• 一次握手:客户端发送带有 SYN（SEQ=x） 标志的数据包 -> 服务端，然后客户端进入 SYN_SEND 状态，等待服务器的确认；
• 二次握手:服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态
• 三次握手:客户端发送带有 ACK(ACK=y+1) 标志的数据包 –> 服务端，然后客户端和服务器端都进入ESTABLISHED 状态，完成TCP三次握手。

3.为什么要三次握手?

• 第一次握手 ：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
• 第二次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
• 第三次握手 ：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

4.四次握手

5.四次挥手

• 第一次挥手 ：客户端发送一个 FIN（SEQ=X） 标志的数据包->服务端，用来关闭客户端到服务器的数据传送。然后，客户端进入 FIN-WAIT-1 状态。
• 第二次挥手 ：服务器收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （SEQ=X+1）标志的数据包->客户端 。然后，此时服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。
• 第三次挥手 ：服务端关闭与客户端的连接并发送一个 FIN (SEQ=y)标志的数据包->客户端请求关闭连接，然后，服务端进入LAST-ACK状态。
• 第四次挥手 ：客户端发送 ACK (SEQ=y+1)标志的数据包->服务端并且进入TIME-WAIT状态，服务端在收到 ACK (SEQ=y+1)标志的数据包后进入 CLOSE 状态。此时，如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后，客户端也可以关闭连接了。

6.第四次挥手为什么要等待2MSL?

具体来说，如果客户端发送了最后一次确认，但该确认在网络中丢失了，那么服务器端会超时并重新发送最后一次关闭请求。如果客户端已经关闭了连接，那么它无法响应这个请求，这样服务器端就会认为连接仍然存在，并继续发送数据。这种情况下，如果没有等待 2MSL，那么服务器端就可能将新连接的数据与旧连接的数据混淆，导致数据传输错误。因此，等待 2MSL 可以确保连接的可靠关闭。
如果最后一次确认没有丢失就是1MSL就可以关闭，所以两者取最大的就行。

7.为什么是四次挥手?

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
举个例子：A 和 B 打电话，通话即将结束后。

1. 第一次挥手 ： A 说“我没啥要说的了”
2. 第二次挥手 ：B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话
3. 第三次挥手 ：于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”
4. 第四次挥手 ：A 回答“知道了”，这样通话才算结束。

8.为什么不能把服务器发送的 ACK 和 FIN 合并起来，变成三次挥手？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复 ACK，表示接收到了断开连接的请求。等到数据发完之后再发 FIN，断开服务器到客户端的数据传送。

9.如果第二次挥手时服务器的 ACK 没有送达客户端，会怎样？

客户端没有收到 ACK 确认，会重新发送 FIN 请求。

10.TCP有哪些特点

TCP的主要特点是：面向连接、单播、可靠交付、全双工通讯、面向字节流、头部开销大。

11.TCP和UDP区别

• UDP 一般用于即时通信，比如： 语音、 视频 、直播等等。这些场景对传输数据的准确性要求不是特别高，比如你看视频即使少个一两帧，实际给人的感觉区别也不大。
• TCP 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。

12.HTTP协议的特点

1. 简单：HTTP协议采用请求-响应模型，客户端向服务器发送请求，服务器响应请求，因此协议设计简单。
2. 无状态：HTTP协议是一种无状态协议，即服务器不保存任何客户端请求的信息。每个请求都是相互独立的，服务器无法识别两个请求是否来自同一个客户端。
3. 可扩展：HTTP协议支持多种不同的请求方法、状态码和头部信息，因此可以根据需要进行扩展。
4. 基于TCP/IP：HTTP协议是基于TCP/IP协议簇的应用层协议，使用TCP协议保证数据传输的可靠性。
5. 明文传输：HTTP协议传输的数据是明文的，不加密，因此安全性较差。为了保证数据的安全性，需要采用HTTPS协议。
6. 请求-响应模型：HTTP协议采用请求-响应模型，客户端向服务器发送请求，服务器响应请求，因此协议设计简单。

13.HTTP报文格式

14.HTTP状态码

14.1 503 Service Unavailable状态码

服务器端临时错误

14.2 504 Gateway timeout

网关超时

14.3.POST和GET的区别?

GET
GET方法请求一个指定资源的表示形式，使用GET的请求应该只被用于获取数据
POST
POST方法用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用
本质上都是TCP链接，并无差别
但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中会体现出一些区别

1. GET方法是用于从服务器获取资源的请求，而PUT方法是用于将客户端数据存储在服务器上的请求。
2. GET请求不会更改服务器上的数据，而PUT请求会将客户端数据存储在服务器上，从而更改服务器上的数据。
3. GET方法将请求的数据作为URL的一部分发送，而PUT方法将请求的数据作为请求体发送。
4. GET请求是幂等的，即多个相同的请求产生相同的响应。PUT请求也是幂等的，因为多个相同的请求仅会更改数据一次。
5. GET请求具有缓存效果，因为相同的请求可以重复使用缓存中的响应。PUT请求不具有缓存效果，因为每个请求都会更改服务器上的数据。
6. GET请求的响应只能是只读的，而PUT请求的响应可以包含用于确认数据存储的元数据

14.4 HTTP长连接和短连接

HTTP短连接：
在HTTP短连接中，客户端和服务器之间的连接在每次请求和响应之后都会被关闭。这意味着，如果客户端需要再次请求数据，它必须重新建立连接。这种连接方式的优点是，它不会占用服务器的资源，因为连接在每次请求和响应之后都被关闭。但是，它的缺点是，它会增加连接的延迟时间，因为每次请求都需要重新建立连接。
HTTP长连接：
在HTTP长连接中，客户端和服务器之间的连接会保持打开状态，以便在未来的请求和响应中重复使用。这意味着，如果客户端需要再次请求数据，它不必重新建立连接。这种连接方式的优点是，它可以减少连接的延迟时间，因为不需要重新建立连接。但是，它的缺点是，它会占用服务器的资源，因为连接会保持打开状态，直到客户端关闭连接或服务器超时。
需要注意的是，HTTP长连接并不意味着连接会一直保持打开状态，因为服务器和客户端都可以随时关闭连接。HTTP长连接的实现方式是通过在HTTP请求和响应头中添加Connection: Keep-Alive头部信息。

14.5 HTTP1.1和 HTTP2.0的区别?

1. 多路复用：HTTP/2.0引入了多路复用，允许同时在单个TCP连接上发送多个请求和响应，从而提高了网络效率。
2. 二进制协议：HTTP/2.0使用二进制协议，取代了HTTP/1.1的文本协议，这使得协议的解析更加高效。
3. 头部压缩：HTTP/2.0使用HPACK算法对请求和响应头部进行压缩，减少了通信中的数据量。
4. 服务器推送：HTTP/2.0允许服务器在客户端请求之前就开始向客户端推送数据，从而提高了页面加载速度。
5. 流量控制：HTTP/2.0引入了流量控制机制，使得客户端可以控制服务器发送数据的速率，从而避免了网络拥塞

14.6 HTTP 和 HTTPS 有什么区别？（重要）

• 端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
• URL 前缀 ：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
• 安全性和资源消耗 ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

14.7 什么是数字证书

数字证书是一种权威性的电子文档，它提供了一种在 Internet 上验证身份的方式。 其作用类似于司机的驾驶执照或日常生活中凭证。 它是由一个权威机构——CA证书授权(Certificate Authority)中心发行的，人们可以在互联网交往中用它来识别对方的身份。

14.8 HTTPS原理

• 建立安全连接

在 HTTPS 中，客户端与服务器之间的通信必须通过 SSL/TLS 协议进行加密。客户端首先向服务器发起请求，请求建立一个 SSL/TLS 安全连接。服务器会向客户端发送 SSL/TLS 证书，包括公钥、证书颁发机构等信息。客户端使用这些信息验证服务器的身份，并生成一个随机的对称加密密钥（session key）。

• 加密数据传输

客户端使用服务器的公钥对 session key 进行加密，然后将加密后的 session key 发送给服务器。服务器使用自己的私钥解密 session key，然后使用 session key 对通信过程中的数据进行加密。加密后的数据在传输过程中，即使被截获，黑客也无法解密其中的内容。

• 数据完整性校验

在 HTTPS 中，为了防止数据被篡改，服务器会对数据进行数字签名，并将签名随着数据一起发送给客户端。客户端使用服务器的公钥验证签名，以确保数据完整性和真实性。

14.9 SSL握手过程

1. 客户端向服务器发送一个SSL连接请求。该请求包含支持的协议版本号、加密算法、压缩方法等信息。
2. 服务器回复一个SSL握手响应。该响应包含SSL证书，以及服务器支持的协议版本号、加密算法、压缩方法等信息。
3. 客户端验证服务器证书的有效性。它将检查证书是否来自受信任的证书颁发机构（CA），证书中的主题是否与服务器域名匹配，以及证书是否在有效期内。
4. 如果证书验证成功，客户端将生成一个随机数（ClientRandom），并使用服务器证书中的公钥加密它，以便服务器后续能够解密。
5. 服务器接收到客户端的加密数据，并使用自己的私钥解密。它还生成一个随机数（ServerRandom）并发送回客户端。
6. 服务器将使用协商的加密算法和密钥生成器来生成会话密钥（Session Key）。服务器还会发送一条消息，告诉客户端会话密钥已经生成。
7. 客户端接收到服务器发来的消息，也会生成一个会话密钥。这个会话密钥和之前生成的ClientRandom和ServerRandom一起，用于后续的加密通信。
8. SSL握手过程完成后，客户端和服务器可以开始使用会话密钥进行加密通信。

14.10 常见的加密算法

1. 对称性加密算法：AES、DES、3DES. …
2. 非对称性算法：RSA、DSA、ECC. …
3. 散列算法（签名算法）：MD5、SHA1、HMAC. …
4. 其他常用算法：Base64、HTTPS、钥匙串加密（iOS）

14.11 为什么CA第三方机构是可信的

CA的可信性建立在其合规性、安全性、审计和认证程序的基础上。这些措施确保了数字证书的真实性和安全性，从而使第三方机构成为可信的机构

15.DNS的解析过程?

1. 浏览器向本地DNS服务器发起查询请求。
2. 如果本地DNS服务器缓存了该域名对应的IP地址，则直接返回查询结果，否则本地DNS服务器将向根DNS服务器发起查询请求。
3. 根DNS服务器返回指向该域名的顶级域名服务器（TLD）的IP地址。
4. 本地DNS服务器再次向TLD服务器发起查询请求。
5. TLD服务器返回指向该域名的权威域名服务器（authoritative nameserver）的IP地址。
6. 本地DNS服务器向权威域名服务器发起查询请求。
7. 权威域名服务器返回该域名对应的IP地址给本地DNS服务器。
8. 本地DNS服务器将该IP地址缓存，并将查询结果返回给用户的浏览器。
9. 浏览器使用该IP地址向目标网站的服务器发起连接请求。

16.浏览器中输入URL返回页面过程

1. URL解析和DNS解析：浏览器首先解析URL中的协议、主机名和路径等信息，然后使用DNS解析器将主机名转换为对应的IP地址。如果DNS缓存中没有对应的IP地址，则浏览器会向本地DNS服务器发起请求，并依次向根DNS服务器、TLD服务器和权威DNS服务器查询，以获取IP地址。
2. 建立TCP连接：一旦获取到目标服务器的IP地址，浏览器就会通过TCP协议与该服务器建立连接。在此过程中，浏览器和服务器之间会交换一些数据包来建立稳定的连接。
3. 发送HTTP请求：一旦TCP连接建立成功，浏览器会向服务器发送一个HTTP请求，该请求包含了浏览器需要获取的资源信息，例如页面内容、图片、脚本和样式等。
4. 接收HTTP响应：服务器接收到HTTP请求后，会根据请求的内容和参数，生成一个HTTP响应，并将其返回给浏览器。该响应包含了所请求的资源的具体内容和其他相关信息。
5. 渲染页面：浏览器接收到HTTP响应后，会对响应进行解析和处理，然后使用HTML、CSS和JavaScript等技术来渲染页面，并将其显示在浏览器窗口中。
6. 断开TCP连接：一旦页面完全加载完毕，浏览器会向服务器发送一个TCP连接关闭请求，以断开与服务器的连接。此时用户就可以开始浏览页面，与页面进行交互了。

17.什么是cookie和session

Cookie是一种在用户计算机上存储小数据的技术，它由服务器在HTTP响应中发送给客户端，存储在客户端浏览器中，并在后续HTTP请求中将其发送回服务器。Cookie可以用于记录用户的偏好设置、购物车内容、登录状态和访问历史等信息。Cookie是基于域名和路径限制的，只有在同一域名和路径下的请求才能访问到相同的Cookie。Cookie还可以设置过期时间，使得它们在一定时间后自动过期，从而达到对用户隐私的保护。
Session是一种在服务器端存储用户状态的技术，它基于Cookie或URL重写来维护会话状态。当用户第一次访问服务器时，服务器会创建一个唯一的Session ID，并将其存储在Cookie中或将其添加到URL的查询参数中。随后，每次用户请求时，服务器都会检查Session ID是否存在，如果存在，则将与该Session ID相关联的数据返回给客户端。Session可以用于记录用户的登录状态、访问权限和用户数据等信息。与Cookie不同，Session数据存储在服务器端，从而保证了用户数据的安全性和隐私性。
需要注意的是，Cookie和Session都是基于HTTP协议实现的，因此它们对于其他协议或协议层（如TCP、UDP、IP等）并不适用。另外，Cookie和Session在使用过程中需要注意安全性问题，如防止跨站脚本攻击（XSS）和跨站请求伪造（CSRF）等攻击。

18.Token

Token是一种在Web应用程序中广泛使用的身份验证机制。它通常用于在客户端和服务器之间进行身份验证和授权。Token是一个包含用户身份信息的字符串，通常使用JSON Web Token（JWT）标准进行编码。
当用户登录时，服务器会生成一个Token并将其返回给客户端。客户端在后续请求中发送这个Token，以证明其身份和授权。服务器可以使用Token来验证用户身份，授权他们访问受保护的资源，并在必要时重新生成新的Token。
Token通常比Cookie和Session更安全，因为它们可以使用加密算法进行签名和加密，防止伪造和篡改。Token还可以在不同的应用程序和服务之间共享，使得单一的用户认证可以在整个系统中使用。

19.TCP如何保证传输的可靠性

1. 三次握手建立连接：在数据传输之前，发送方和接收方需要进行三次握手来建立连接。这个过程确保双方都能够通信，而且对方已经准备好接收数据。如果握手失败，TCP会尝试重新建立连接。
2. 数据包的序列号和确认应答：TCP会给每个数据包分配一个唯一的序列号，并且接收方必须发送确认应答来告诉发送方已经接收到了数据。如果发送方在一定时间内没有收到确认应答，它会重新发送数据包。
3. 滑动窗口机制：TCP使用滑动窗口机制来控制发送和接收的数据量，防止数据包的丢失和拥塞。接收方会告诉发送方自己的接收窗口大小，发送方会根据这个大小来发送数据。
4. 超时重传：如果发送方在一定时间内没有收到确认应答，它会重新发送数据包。TCP会根据网络状况和延迟情况来动态地调整超时时间。
5. 拥塞控制：TCP使用拥塞控制算法来避免网络拥塞。当网络出现拥塞时，TCP会减少发送的数据量，并且逐渐增加发送数据的速率。

20.TCP确保传输可靠性的方式

1. 重传机制：TCP会周期性地发送确认消息来确认收到的数据包，如果发送方没有收到确认消息，它将会重传数据包，以确保数据包不会丢失。
2. 滑动窗口协议：TCP使用滑动窗口协议来控制数据的传输速率，这样可以避免发送方发送太多数据而导致网络拥塞。
3. 拥塞控制：TCP会监测网络拥塞情况并相应地调整传输速率，以避免网络拥塞和数据丢失。
4. 校验和：TCP在每个数据包中添加校验和，以确保数据在传输过程中没有被篡改。
5. 数据确认：TCP要求接收方对收到的数据包进行确认，这样发送方才会知道数据已经成功到达接收方。
6. 数据分段：TCP会将数据分成较小的段进行传输，以避免网络拥塞和数据丢失。

21.TCP的校验和

TCP在数据包的头部中添加了一个校验和字段，用于验证数据在传输过程中是否被篡改。校验和是通过对TCP头部和数据部分进行计算得到的，计算方法是将头部和数据部分看作16位字的序列，每相邻两个字节相加，将结果相加并取反，最后得到的值作为校验和存储在校验和字段中。
在数据包接收方接收到数据包后，它也会计算数据包的校验和，如果计算出的校验和与接收到的校验和不相同，则说明数据包在传输过程中出现了错误，需要丢弃该数据包并请求重新传输。
TCP的校验和主要用于检测传输过程中出现的随机位错误，而不是检测有意篡改数据的攻击。因此，在保证数据的安全性方面，还需要使用其他的安全机制来保护数据的完整性和机密性。

22.TCP的确认应答与序列号

TCP（Transmission Control Protocol）是一种面向连接的可靠的传输层协议。在TCP传输过程中，每个数据包都有一个唯一的序列号，这个序列号用于区分数据包的顺序。在发送方发送数据包之后，接收方需要对接收到的每个数据包进行确认应答，确认应答中包含接收到的数据包的序列号。
TCP中的序列号和确认应答机制是用于保证数据传输的可靠性和完整性的重要机制。
当发送方发送数据包时，数据包中包含有序列号，用于标识这个数据包在整个数据流中的位置。接收方收到数据包后会发送确认应答（ACK），确认应答中包含的序列号表示接收方已经成功接收到了这个序列号对应的数据包。
如果发送方在规定的时间内没有收到确认应答，就会重新发送这个数据包。如果接收方收到的数据包的序列号不是接收方期望的序列号，接收方也会发送一个确认应答，告诉发送方需要重新发送这个数据包。
通过序列号和确认应答机制，TCP可以保证数据传输的可靠性和完整性。如果数据包在传输过程中丢失或者损坏，TCP会自动重新发送数据包，直到接收方成功接收到数据包并发送确认应答为止。

23.TCP的超时重传

TCP的超时重传指的是当发送方发送数据时，在规定的时间内没有收到确认应答或收到了冗余的确认应答，就会触发超时重传机制，即重新发送该数据。
具体来说，当发送方发送一个数据段后，会开启一个计时器，在等待时间内如果没有收到确认应答，就会认为该数据段丢失了，会立即重传该数据段。这个等待时间也就是TCP的超时时间，通常由操作系统内核根据网络环境和历史经验进行动态调整。
TCP的超时重传机制的主要作用是保证数据的可靠性和正确性，确保数据能够成功地被传输到目的地。不过过于频繁的重传也会对网络带宽造成压力，因此超时重传时间的设置需要平衡网络可靠性和效率。

24.TCP的连接管理

25.TCP的流量控制

TCP的流量控制是指通过动态调整发送方的发送速率来避免发送方过度发送数据，导致接收方无法及时处理或数据丢失的问题。
TCP的流量控制机制主要涉及两个因素：窗口和拥塞控制。

1. 窗口 TCP协议中的窗口是指发送方和接收方之间的数据缓存区域，发送方会根据接收方的窗口大小动态调整发送速率。接收方会在TCP报文中设置一个接收窗口大小值（rwnd），发送方会根据该值控制发送速率，确保不会超出接收方的处理能力。
2. 拥塞控制 拥塞控制是TCP协议保证网络高效和公平性的机制，主要通过动态调整发送方的拥塞窗口来控制发送速率。发送方会根据网络的拥塞程度，即拥塞窗口的大小来动态调整发送速率。在网络拥塞时，发送方会自动减小拥塞窗口的大小，以避免继续发送数据，导致网络拥塞更加严重。在网络质量恢复时，发送方会逐渐增加拥塞窗口的大小，以提高发送速率。

总之，TCP的流量控制机制可以确保发送方不会过度发送数据，避免了网络拥塞和数据丢失的问题，从而保证了数据传输的可靠性和稳定性。

26.TCP的拥塞控制

1. 慢启动算法 当TCP连接刚建立时，发送方会以指数级别递增的速度增加拥塞窗口的大小，以确定网络的可用带宽。在每个传输循环中，拥塞窗口的大小加倍，直到网络出现拥塞。
2. 拥塞避免算法 一旦网络出现拥塞，发送方会进入拥塞避免状态。此时，拥塞窗口的大小会以线性方式增加，而不是指数方式增加，以避免继续发送数据恶化网络拥塞。
3. 快速重传算法 当接收方接收到的TCP数据包缺失时，它会立即向发送方发送一个重复确认（Duplicate ACK），并请求重传数据。发送方会尝试立即重传缺失的数据包，而不必等待定时器到期。这个过程被称为快速重传。
4. 快速恢复算法 如果发送方接收到三个重复确认，则意味着该数据包已经丢失并已经被接收方接收。在这种情况下，发送方会将拥塞窗口减半，然后从当前拥塞窗口大小重新开始。这个过程被称为快速恢复。

27.TCP的超时重传

超时重传是指在发送方发送数据后，等待一段时间（即超时时间）后，如果没有收到接收方的确认信息，就会将数据进行重传。TCP会根据网络状况和数据包的重要性来动态调整超时时间，以提高重传的效率。超时重传可以保证数据的可靠传输，但是如果超时时间设置得太长，会导致传输延迟增加，影响用户体验。

28.TCP的快速重传

快速重传是指当发送方发送数据后，接收方只收到了部分数据，并向发送方发送了确认信息，但是发送方没有收到全部的确认信息，就会认为数据包丢失，立即进行重传，而不是等待超时重传机制的触发。快速重传可以避免超时时间设置得过长，提高传输效率，但是如果网络存在乱序丢包，可能会引起不必要的重传，影响网络性能。

29.TCP如果多次超时呢?—超时时间间隔加倍

在TCP中，如果重传超过一定次数，就会采取超时时间间隔加倍的策略，以避免网络拥塞。具体而言，每次超时重传之后，TCP会将超时时间间隔加倍，直到达到一个最大重传次数或者网络恢复正常。

30.SYNC FLOOD syn洪泛攻击

SYN Flood攻击是一种常见的网络攻击，它利用TCP协议的漏洞，向服务器发送大量的伪造SYN请求，使得服务器无法处理正常的请求，从而导致拒绝服务（Denial of Service，DoS）攻击。
在正常情况下，当客户端向服务器发送SYN请求时，服务器会为每个请求分配一定的资源，并向客户端发送SYN+ACK响应。客户端再发送ACK响应，完成三次握手建立连接。而在SYN Flood攻击中，攻击者发送大量的伪造SYN请求，但不会发送ACK响应，这样服务器会一直等待客户端发送ACK，直到超时。由于服务器在等待过程中会一直分配资源，所以当伪造的请求数量达到一定程度时，服务器就会因为资源耗尽而无法处理正常的请求，导致拒绝服务攻击。
为了防止SYN Flood攻击，可以采取以下措施：

1. 启用SYN cookies：SYN cookies是一种TCP协议的扩展机制，它可以在服务器收到SYN请求时，动态生成一个临时的cookie作为响应，而不是在服务器端分配资源。这样即使攻击者发送大量的伪造SYN请求，服务器也不会耗尽资源，从而避免拒绝服务攻击。
2. 设置防火墙规则：可以在防火墙中设置一些规则，例如限制每个IP地址发送SYN请求的数量，或者对来自特定IP地址的请求进行拦截，从而阻止SYN Flood攻击。
3. 限制连接数：可以在服务器端限制每个IP地址建立的连接数，从而防止一个IP地址使用过多的资源，影响其他用户的正常使用。
4. 加强系统安全：定期更新系统补丁，使用强密码和防病毒软件，可以减少系统被攻击的风险，从而避免SYN Flood攻击的发生。

31.Ping命令原理

Ping命令的原理是基于Internet控制消息协议（ICMP），它是一种网络协议，用于在IP网络上发送控制消息。Ping命令使用ICMP协议来发送数据包并接收响应。它通过向目标计算机发送一个特定格式的ICMP Echo请求消息来检查目标计算机是否可达。如果目标计算机可达，它将返回一个ICMP Echo响应消息。如果目标计算机不可达，它将返回一个ICMP目的地不可达消息。

32.TCP UDP相关问题

(1)服务端，TCP和UDP可以绑定相同的端口吗?

可以
在同一台服务器上，TCP和UDP可以绑定相同的端口号，因为它们是两种不同的传输层协议，它们使用不同的套接字类型和不同的传输机制。
当应用程序使用TCP或UDP套接字绑定到一个特定的端口时，这个端口就被占用了。如果应用程序同时使用TCP和UDP套接字绑定到相同的端口，那么这个端口就同时被TCP和UDP占用了
例如，如果一个应用程序需要同时使用TCP和UDP来监听同一个端口号，那么它可以创建一个TCP套接字和一个UDP套接字，并将它们都绑定到同一个端口号。在这种情况下，当TCP客户端连接到这个端口时，它将使用TCP套接字进行通信，而当UDP客户端发送数据到这个端口时，它将使用UDP套接字进行通信。

(2)服务端，多个TCP应用可以绑定同一个端口吗?

不可以

(3)重启TCP服务时候，为什么有时候会显示”address already in use’

当你尝试重新启动一个TCP服务时，如果之前绑定到该服务所使用的端口号的套接字仍然处于打开状态，那么操作系统会拒绝绑定新的套接字到该端口上并显示 “address already in use” 错误消息。
这通常发生在以下几种情况下：

1. 服务没有正确地关闭：如果TCP服务在关闭之前没有正确地释放该端口上的套接字，则该端口可能仍然处于占用状态。在这种情况下，重新启动服务之前，必须先释放该端口上的套接字。
2. 端口复用：在某些情况下，可以通过设置SO_REUSEADDR套接字选项来启用端口复用。这使得套接字可以重新绑定到已经在使用的端口上。但是，在某些情况下，端口复用可能会导致"address already in use"错误消息的出现。
3. 并发请求：当有多个并发请求尝试同时绑定到同一个端口时，可能会发生冲突，导致某些请求失败并显示 “address already in use” 错误消息。

为了解决这个问题，你可以使用一些命令行工具或者编程语言提供的方法来关闭之前的套接字并释放该端口，或者修改服务的配置，以避免出现端口冲突的情况

(4)客户端的端口可以重复使用吗?

可以，但是要分类讨论，不bind0的情况
在客户端执行connect 函数的时候，只要客户端连接的服务器不是同一个，内核允许端口重复使用。 TCP 连接是由四元组（源IP地址，源端口，目的IP地址，目的端口）唯一确认的，那么只要四元组中其中一个元素发生了变化，那么就表示不同的TCP 连接的。

(5)多个客户端可以bind同一个端口吗? 不能

在同一个操作系统中，同一时刻只能有一个进程绑定在一个特定的端口上。因此，多个客户端不能直接绑定同一个端口。
然而，有几种方法可以允许多个客户端共享同一个端口：

1. 使用多路复用技术（例如，select、poll、epoll）：在一个进程中，可以使用这些技术同时监视多个客户端的连接，以及接收和处理这些连接上的数据。这样，多个客户端可以共享同一个端口。
2. 使用代理服务器：代理服务器是一个中间层，可以代表多个客户端与目标服务器进行通信。代理服务器绑定在一个端口上，然后将收到的数据转发到目标服务器，并将响应数据返回给相应的客户端。在这种情况下，多个客户端可以将其连接到代理服务器的相同端口，而代理服务器可以管理和分配连接和数据。

需要注意的是，在任何情况下，所有客户端都必须通过不同的源端口与目标服务器进行通信，以确保网络通信的正确性。

(6)客户端TCP 连接TIME_WAIT 状态过多，会导致端口资源耗尽而无法建立新的连接吗?

是的，客户端TCP连接处于TIME_WAIT状态过多可能会导致端口资源耗尽，从而导致无法建立新的连接。
在TCP连接中，当客户端发送FIN包结束连接时，它会进入TIME_WAIT状态，以确保所有与该连接相关的数据都已经传输完成。在此状态下，客户端将继续等待一段时间，以确保远程主机已经接收到FIN包并响应了ACK包。
如果客户端TCP连接处于TIME_WAIT状态的数量过多，这可能会导致端口资源不足，因为每个TCP连接都需要一个唯一的端口。当所有可用的端口都已被使用时，新的连接将无法建立，从而导致服务不可用的情况。
为了避免这种情况，可以通过调整客户端TCP的TIME_WAIT超时时间来减少TIME_WAIT状态的持续时间，或使用连接重用来避免频繁地建立新的TCP连接。此外，也可以通过增加可用的端口数量来扩展端口资源，以支持更多的TCP连接。

(7)如何解决客户端TCP 连接 TIME_WAIT 过多，导致无法与同一个服务器建立连接的问题?

1. 调整TIME_WAIT超时时间

可以通过修改客户端TCP的TIME_WAIT超时时间来减少TIME_WAIT状态的持续时间，从而释放端口资源以支持更多的TCP连接。这可以通过在操作系统上设置TCP的TIME_WAIT超时时间来实现。例如，在Linux中，可以使用sysctl命令修改TCP的TIME_WAIT超时时间。

2. 使用连接重用

在建立TCP连接时，可以使用连接重用来避免频繁地建立新的TCP连接。连接重用允许多个HTTP请求或RPC调用在同一TCP连接上完成，从而减少TIME_WAIT状态的数量。

3. 增加端口资源

如果TIME_WAIT状态过多，可能需要增加可用的端口数量来扩展端口资源，以支持更多的TCP连接。可以通过在操作系统上增加可用的端口范围或增加操作系统中允许的最大端口数来实现。

4. 使用连接池

使用连接池可以有效地减少TIME_WAIT状态的数量。连接池管理已经建立的TCP连接，以便在需要时重复使用它们，而不是频繁地建立和关闭连接。
总之，为了解决客户端TCP连接处于TIME_WAIT状态过多的问题，可以采取上述一些或多个措施。这些方法也适用于HTTP调用和RPC调用。

33.Http调用和RPC调用

HTTP调用和RPC调用都是用于实现分布式系统中不同节点之间的通信。
HTTP调用是一种基于HTTP协议的远程调用方式，通常使用RESTful API进行实现。HTTP调用是一种无状态的协议，每次请求都是独立的，因此每个请求都需要包含足够的信息来执行所请求的操作。
RPC调用是一种远程过程调用方式，它通过使用特定的协议和序列化方法实现节点间的通信。RPC调用通常是基于TCP或UDP协议实现的，因此相比HTTP调用具有更高的性能和效率。
相比较而言，HTTP调用通常更适用于数据传输较小、频繁的场景，例如Web应用程序的API调用。而RPC调用则更适用于数据传输较大、复杂的场景，例如分布式计算、高性能数据库等。