网络协议相关面试题及解答_网络协议面试，2024年最新某大厂开发者对于Golang多线程的总结

最新推荐文章于 2024-05-23 15:49:46 发布

2401_84254177

最新推荐文章于 2024-05-23 15:49:46 发布

阅读量604

点赞数 9

分类专栏： 2024年程序员学习文章标签：网络协议面试 golang

本文链接：https://blog.csdn.net/2401_84254177/article/details/137999099

版权

2024年程序员学习专栏收录该内容

90 篇文章 0 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Golang全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注go）

正文

2.10 HTTP的握手是什么样的

HTTP协议本身并不包括握手过程，但它通常是在底层的传输层协议（如TCP）上进行握手的。以下是基于TCP的HTTP握手过程：

建立TCP连接：HTTP通常在传输层使用TCP协议。客户端首先与服务器的IP地址和端口建立TCP连接。这是一个三步握手的过程，包括客户端发送一个SYN包（请求建立连接），服务器回应SYN-ACK包（确认并同意建立连接），最后客户端发送ACK包（确认连接建立）。
客户端发送HTTP请求：一旦TCP连接建立，客户端可以发送HTTP请求。HTTP请求由HTTP方法（如GET、POST、PUT等）、请求头（包括主机名、User-Agent等信息）和请求体（如果有的话）组成。
服务器接收和处理请求：服务器接收到客户端的HTTP请求后，会根据请求中的信息进行处理。这可能包括查找请求的资源、执行相关操作或生成HTTP响应。
服务器发送HTTP响应：服务器生成HTTP响应，包括响应状态码、响应头和响应体。响应状态码指示请求的结果，如200表示成功，404表示资源未找到，500表示服务器内部错误等。
客户端接收HTTP响应：客户端接收到服务器的HTTP响应后，会解析响应，处理响应头和响应体，并采取相应的行动，例如渲染网页内容或执行其他操作。
关闭TCP连接：一旦HTTP事务完成，TCP连接可以被关闭。关闭TCP连接是一个四步挥手的过程，包括客户端发送FIN包（请求关闭连接），服务器回应ACK包（确认关闭请求），服务器发送FIN包（请求关闭连接），最后客户端回应ACK包（确认关闭请求）。这个过程是为了确保数据的完整性和可靠性。

总结：
HTTP握手是建立在TCP连接之上的，它包括建立TCP连接、发送HTTP请求、接收HTTP响应和关闭TCP连接的步骤。这些步骤使客户端能够与服务器进行通信并交换数据。握手过程的细节可能会因使用的HTTP版本、传输层协议（如HTTPS）、安全性协议等而有所不同。

2.11 Websocket协议和HTTP的关系是什么？

WebSocket（WS）协议和HTTP（Hypertext Transfer Protocol）协议是两种不同的协议，但它们之间存在一定的关系。以下是它们之间的一些关键区别和联系：

协议类型：

HTTP是一种请求-响应协议，通常用于在客户端和服务器之间传输文本和二进制数据。它是无状态的，每个请求和响应之间是独立的。
WebSocket是一种全双工通信协议，允许在客户端和服务器之间建立持久连接，实现实时的双向通信。它是建立在HTTP基础上的协议，通过HTTP/1.1协议的升级机制实现。

握手过程：

HTTP协议是基于请求-响应模型的，每次通信都需要进行握手，发送请求并等待服务器的响应。这种模式适用于单次请求的场景。
WebSocket则是通过HTTP握手建立连接，之后就可以在已建立的连接上进行双向通信，无需重新握手。WebSocket握手通常使用HTTP协议的升级头（Upgrade Header）来切换协议。

持久连接：

HTTP是一种短连接协议，每次请求和响应之间都会关闭连接，需要重新建立连接。
WebSocket是一种长连接协议，通过在握手时建立的连接，保持连接的状态，使得客户端和服务器可以在连接上进行实时的双向通信。

数据格式：

HTTP数据的传输通常使用明文的文本或者二进制格式，如JSON或XML。
WebSocket允许在已建立的连接上直接发送二进制数据，同时也支持文本数据的传输。

端口：

HTTP默认使用端口80，而HTTPS使用端口443。
WebSocket则通常使用与HTTP相同的端口，例如，如果你的网站使用HTTPS，WebSocket就使用端口443。

虽然WebSocket协议和HTTP协议是不同的协议，但由于WebSocket握手是通过HTTP协议进行的，因此它们在某种程度上关联在一起。WebSocket协议的引入主要是为了解决 HTTP协议在实时双向通信方面的限制，使得Web应用能够更有效地实现实时通信。

3 HTTPS

参考1：HTTP和HTTPS协议，看一篇就够了

3.1 HTTP和HTTPS的区别

HTTP（Hypertext Transfer Protocol）和HTTPS（Hypertext Transfer Protocol Secure）是两种用于在客户端和服务器之间传输数据的协议，它们之间的主要区别在于安全性和数据传输方式：

安全性

HTTP：HTTP是一种不安全的协议，数据在传输过程中以明文形式传输。这意味着如果恶意方在网络中截取HTTP通信，他们可以轻松地读取和修改传输的数据，包括敏感信息，如用户名、密码、信用卡号等。因此，HTTP不适合用于传输敏感信息的应用程序。
HTTPS：HTTPS是HTTP的安全版本，使用SSL/TLS协议进行数据加密和身份验证。通过HTTPS传输的数据被加密，因此即使被截取，也无法轻松读取或修改。HTTPS通信使用公钥和私钥，确保客户端和服务器之间的通信是安全的。这使得HTTPS非常适合用于处理敏感信息的应用程序，如在线支付、网上银行、电子邮件等。

URL前缀

HTTP：HTTP网站的URL通常以"http://"开头，例如：http://www.example.com。
HTTPS：HTTPS网站的URL通常以"https://"开头，例如：https://www.example.com。

端口

HTTP：HTTP默认使用端口80进行通信。
HTTPS：HTTPS默认使用端口443进行通信。

证书

HTTP：HTTP不需要使用数字证书，因为它不提供加密和身份验证。
HTTPS：为了建立HTTPS连接，服务器需要使用数字证书来验证其身份。客户端会验证证书的有效性，并确保与服务器的通信是加密的。证书通常由受信任的第三方机构颁发，以确保服务器的身份。

性能

HTTP：HTTP通信速度较快，因为不需要加密和解密数据，但不安全。
HTTPS：HTTPS通信速度较慢，因为需要加密和解密数据，但更安全。

总结：
HTTP和HTTPS之间的主要区别在于安全性。HTTP是一种不安全的协议，适用于不涉及敏感信息的普通网站，而HTTPS通过加密和身份验证提供了更高的安全性，适用于需要保护敏感信息的应用程序。在现代互联网中，推荐在处理用户数据时使用HTTPS以提供更高的安全性。

3.2 HTTPS实现原理

HTTPS（Hypertext Transfer Protocol Secure）实现了HTTP协议的安全版本，其主要原理是通过加密和身份验证来确保通信的机密性和完整性。HTTPS的实现原理涉及以下关键概念和步骤：

加密通信

对称加密：在HTTPS通信开始时，客户端和服务器之间建立一个对称密钥，该密钥用于加密和解密通信中的数据。对称密钥是一种快速加密和解密数据的方法，但必须在通信开始时安全地传输。
非对称加密：在对称密钥协商期间，服务器会向客户端发送自己的CA证书，证书里包含公钥，客户端使用该公钥加密对称密钥，然后将其发送回服务器。服务器使用其私钥解密对称密钥。这个过程称为非对称加密，其中公钥用于加密，私钥用于解密。

数字证书

服务器通常需要通过数字证书来验证其身份。数字证书由受信任的第三方证书颁发机构（Certificate Authority，CA）签发，包含了服务器的公钥和与服务器相关的信息，同时也包含CA的数字签名。客户端可以使用CA的公钥来验证服务器证书的有效性，确保连接到的服务器是合法的。

握手过程：当客户端尝试连接到HTTPS服务器时，会发生一个握手过程，其中包括以下步骤：
客户端向服务器发送一个随机数和支持的加密算法列表。
服务器选择一个加密算法和使用自己的私钥生成一个随机数，然后将这些信息与数字证书一起发送给客户端。
客户端使用服务器的公钥解密服务器发送的信息，并验证证书的有效性。如果一切正常，客户端生成一个会话密钥（对称密钥），然后使用服务器的公钥加密该密钥并发送回服务器。
服务器使用其私钥解密会话密钥，然后双方都具备了相同的对称密钥，用于加密和解密通信数据。
加密通信：一旦握手成功，客户端和服务器之间的通信将使用对称密钥进行加密和解密。这确保了数据在传输过程中的机密性和完整性，使第三方无法轻松地读取或修改数据。

总结：
HTTPS的实现原理涉及使用对称和非对称加密，数字证书以及握手过程来确保通信的安全性。客户端和服务器之间的通信在加密的环境下进行，同时服务器的身份也得到验证，以防止中间人攻击和数据泄漏。这使得HTTPS成为保护敏感信息和确保通信隐私的重要工具。

3.3 CA的数字证书中包括哪些信息

参考：查看google浏览器里的证书

颁发者（Issuer）：证书颁发机构（CA）的名称和相关信息，用于标识颁发该证书的机构。
颁发对象：证书持有者的相关信息。
主题（Subject）：证书持有者（通常是网站）的名称和相关信息，用于标识该证书所属实体。
公钥（Public Key）：证书持有者的公钥，用于加密通信和验证数字签名。
有效期（Validity）：证书的生效日期和失效日期，指示证书的有效期限。
序列号（Serial Number）：证书的唯一序列号，用于标识该证书的唯一性。
签名算法（Signature Algorithm）：用于生成证书签名的算法类型，例如RSA、DSA、ECDSA等。
签名（Signature）：由证书颁发机构使用其私钥对证书数据进行签名生成的数字签名，用于验证证书的完整性和真实性。
扩展字段（Extensions）：包含一些额外的信息，如证书用途、密钥用法、颁发者信息等。

这些信息组成了证书数据的主要内容，用于验证证书的有效性和真实性。浏览器和其他应用程序使用这些信息来建立信任链，确认证书的合法性，并确保安全的通信。

3.4 SSL建立连接过程

SSL（Secure Sockets Layer，安全套接字层）是一种用于在网络上建立安全连接的协议，它的后续版本被称为TLS（Transport Layer Security，传输层安全性）。SSL/TLS协议的建立连接过程通常包括以下步骤：

客户端Hello：客户端向服务器发送一个ClientHello消息，其中包含以下信息：
客户端支持的SSL/TLS协议版本。
一个随机数，该随机数将用于生成会话密钥。
支持的密码套件列表，包括加密算法、哈希算法等。
服务器Hello
服务器从客户端发送的ClientHello消息中选择一个支持的SSL/TLS协议版本。
服务器生成一个随机数，将其发送给客户端。
服务器选择一个密码套件，通知客户端使用哪种加密算法和哈希算法。
服务器发送其数字证书，证书包含服务器的公钥以及与证书相关的信息。
身份验证和密钥交换
客户端验证服务器的证书有效性。包括检查证书是否过期、证书颁发机构是否可信任，证书的颁发机构（CA）的信任链，以确保服务器的身份。
客户端生成一个预主密钥（Pre-Master Secret），并使用数字证书的公钥加密它，然后发送给服务器。
服务器使用其私钥解密客户端发送的预主密钥，然后双方都使用预主密钥生成主密钥（Master Secret）。
会话密钥的生成
客户端和服务器使用各自的随机数以及主密钥生成会话密钥。
会话密钥是对称密钥，用于加密和解密通信中的数据。
完成握手
客户端发送一个Finished消息，该消息包含前面握手消息的哈希值，以验证握手消息的完整性。
服务器发送一个Finished消息，同样包含前面握手消息的哈希值。
一旦客户端和服务器都收到对方的Finished消息，握手过程完成。
安全通信
现在，客户端和服务器都使用会话密钥加密和解密通信中的数据。通信过程中的数据都会使用这个密钥进行保护。

一旦握手完成，SSL/TLS会话建立，双方可以安全地通信，保护数据的机密性和完整性。这个过程确保了通信双方的身份验证、密钥交换和安全通信。一旦建立了SSL/TLS连接，通信双方可以开始在加密的环境中传输数据，防止数据泄露和中间人攻击。这是安全的HTTPS连接的基础。

3.5 HTTPS的加密协议是什么

HTTPS（Hypertext Transfer Protocol Secure）的加密协议通常是TLS（Transport Layer Security，传输层安全性）协议。TLS是SSL（Secure Sockets Layer，安全套接字层）的后续版本，目前广泛用于保护网络通信的安全性。TLS协议提供了数据的加密、完整性验证和身份验证，以确保通信在传输过程中是安全的。

TLS协议的核心功能包括：

加密：TLS使用对称密钥和非对称密钥加密算法来保护数据的机密性，防止第三方截取和读取数据。
完整性验证：TLS使用哈希函数来验证数据的完整性，确保数据在传输过程中没有被篡改。
身份验证：TLS通过数字证书来验证通信双方的身份，确保客户端连接到的服务器是合法的。

总结：
HTTPS的加密协议通常是TLS，它通过加密、完整性验证和身份验证来保护网络通信的安全性。选择TLS的版本取决于安全性要求和兼容性考虑。

3.6 HTTPS怎么保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

HTTPS通过数字证书来确保客户端收到的服务器公钥是真实有效的，而不是中间人伪造的公钥。这是通过以下方式实现的：

数字证书：服务器必须获得数字证书，由受信任的第三方机构（Certificate Authority，CA）颁发。数字证书包含以下信息：
服务器的公钥。
服务器的标识信息，如域名。
CA的数字签名。
CA信任链：客户端的浏览器或操作系统内置了一组受信任的根证书颁发机构（Root Certificate Authorities）。这些根CA的公钥已被预安装在客户端设备中，并被广泛信任。服务器的数字证书必须由其中一个受信任的CA颁发，否则客户端将不信任该证书。
数字签名验证：当客户端连接到服务器时，服务器会将其数字证书发送给客户端。客户端使用预先安装的根CA的公钥来验证服务器证书的数字签名。如果数字签名验证通过，客户端就可以确信证书是由受信任的CA颁发的。
域名匹配：客户端还会检查证书中的域名信息是否与用户试图连接的域名匹配。这是为了防止中间人攻击，其中攻击者可能会伪造证书，并尝试欺骗客户端连接到错误的服务器。

总结：
HTTPS通过数字证书和CA信任链来确保服务器提供的公钥是真实有效的。只有在证书由受信任的CA颁发，并且数字签名验证通过且域名匹配时，客户端才会信任服务器的公钥。这种机制防止了中间人攻击，确保了通信的安全性和服务器的身份验证。如果数字证书无效或被篡改，客户端将拒绝建立连接。

3.7 第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？

第三方攻击者（中间人攻击者）通常无法获得合法服务器的有效数字证书，因为服务器的数字证书是由受信任的证书颁发机构（CA）颁发的，而CA通常会执行严格的验证程序来确保只有合法服务器才能获得证书。但中间人攻击者可以尝试使用自己伪造的证书来欺骗客户端，称为自签名证书，以尝试进行攻击。

中间人攻击的工作原理通常如下：

攻击者与客户端建立加密通道，同时与服务器建立另一个加密通道。攻击者同时伪装成客户端和服务器。
攻击者向客户端提供自己伪造的数字证书，宣称它是服务器的数字证书。
客户端通常会尝试验证伪造证书的有效性，但攻击者可以提供自己伪造的根证书，声称它是受信任的CA的根证书。如果客户端不对证书进行严格的验证，它可能会相信攻击者伪造的证书。
一旦客户端相信了攻击者伪造的证书，它会使用攻击者提供的公钥来加密通信数据，攻击者也可以解密这些数据，然后将其重新加密并传递给真正的服务器。
攻击者以类似的方式伪装成客户端，向服务器发送数据，然后将服务器的响应重新加密并传递给客户端。这使得攻击者可以窃听、修改或篡改通信内容。

为了防止中间人攻击，客户端应严格验证服务器的数字证书，确保它是由受信任的CA颁发的，而且证书中的信息与服务器的域名匹配。此外，服务器也可以采用一些安全措施，如公钥固定（Pin）或使用证书透明度（Certificate Transparency）来增加安全性。如果客户端在验证数字证书时发现任何问题，应立即中断连接，以防止建立不安全的通信渠道。

3.8 HTTPS优缺点

HTTPS（Hypertext Transfer Protocol Secure）是一种用于在网络上建立安全连接的协议，它通过数据加密、身份验证和完整性验证来保护通信的安全性。HTTPS具有许多优点，但也有一些缺点。

优点：

数据加密：HTTPS使用加密算法来保护数据在传输过程中的机密性。这意味着即使数据被截取，也无法轻松读取其内容，因此能够有效防止信息泄漏。
完整性验证：HTTPS使用哈希函数来验证数据的完整性，确保数据在传输过程中没有被篡改。这有助于防止中间人攻击和数据篡改。
身份验证：HTTPS通过数字证书来验证服务器的身份。客户端可以确保连接到的服务器是合法的，这防止了伪装和中间人攻击。
用户信任：HTTPS使用受信任的第三方证书颁发机构（CA）颁发的数字证书。这增加了用户对网站的信任，因为他们可以相信其连接是安全的。
SEO优化：搜索引擎（如Google）更喜欢使用HTTPS保护的网站，因此使用HTTPS可以提高网站的搜索引擎排名。
法规合规性：许多法规和合规性要求要求网站使用HTTPS来保护用户数据，特别是对于敏感信息的处理，如支付信息和个人身份信息。
Cookie安全：HTTPS可以帮助防止Cookie劫持攻击，因为Cookie在传输过程中也会被加密。

缺点：

性能开销：加密和解密数据会引入一些性能开销，使HTTPS通信相对于HTTPS略显慢一些。然而，现代硬件和TLS协议的改进已经减小了这种性能开销。
成本：获得有效的数字证书可能需要支付一些费用，尤其是如果选择使用受信任的商业CA颁发的证书。
配置和维护：配置和维护HTTPS服务器可能比HTTP更复杂，尤其是在大型网络中。
不是绝对安全：虽然HTTPS提供了很高的安全性，但它也不是绝对安全的。它仍然可能受到一些攻击，如某些类型的中间人攻击或恶意软件感染。

总结：
HTTPS在保护通信的安全性和隐私方面具有很大的优势，尤其是在处理敏感信息的应用程序中。然而，它也需要考虑性能开销和一些配置和维护工作。对于大多数Web应用程序来说，使用HTTPS是非常值得的，因为它提供了必要的保护和用户信任。

3.9 HTTPS的证书是谁验证谁

在HTTPS通信中，数字证书的验证过程如下：

证书颁发机构(CA)验证网站的身份并向其颁发证书。
网站将证书发送给访问的客户端。
客户端获取证书后，验证证书的颁发机构是否为可信的CA。
客户端验证证书的内容是否与网站地址匹配。
如果一切验证通过，客户端就可以信任该证书真实属于该网站。

所以简单来说：

CA验证网站，向网站颁发证书。
客户端验证CA是否可信任，以及证书是否与网站匹配。
最后客户端验证证书的有效性和网站的合法性。

总结：
HTTPS证书验证中，CA验证网站，而用户验证CA和证书本身。这个双向验证机制让HTTPS证书系统能够安全可靠地运行。

3.10 HTTPS单向认证时谁验证谁

在HTTPS单向认证中，一般情况下是客户端验证服务器的身份，而不是服务器验证客户端的身份。这是HTTPS的标准配置方式，也被称为单向SSL认证。

HTTPS通信中的验证通常如下：

服务器验证：服务器获得数字证书，其中包含服务器的公钥以及一些服务器相关的信息，如域名。服务器将其数字证书发送给客户端。
客户端验证（可选）：在标准的单向SSL认证中，客户端可以选择验证服务器的证书。客户端使用受信任的根CA的公钥来验证服务器证书的有效性，包括证书的签名和域名匹配。如果客户端选择验证服务器的证书并且验证通过，它可以信任服务器的身份。
连接建立：一旦服务器的证书被验证通过（如果客户端进行了验证），客户端和服务器之间建立连接，并使用服务器的公钥加密通信数据。

总结：
HTTPS的标准配置中，通常是客户端验证服务器的身份，而服务器通常不验证客户端的身份。客户端通过验证服务器的证书来确保连接到的服务器是合法的，从而防止中间人攻击。如果需要服务器验证客户端的身份，可以使用双向认证（双向SSL认证）来实现，其中客户端和服务器都会验证对方的身份。

3.11 HTTPS客户端如何验证服务端证书的合法性

在HTTPS通信中，客户端通过验证服务器证书的合法性来确认连接到的服务器的身份。这个验证过程通常包括以下步骤：

获取服务器证书：服务器在握手过程中将其数字证书发送给客户端。
验证证书的签发机构（CA）：客户端使用本地受信任的根证书颁发机构（CA）的公钥来验证服务器证书是否由受信任的CA签发。根证书通常是预装在操作系统或浏览器中的。
验证证书的有效期：客户端检查服务器证书的有效期，确保它没有过期。如果证书已过期，客户端将认为连接不安全。
验证证书的域名匹配：客户端检查服务器证书中的域名信息是否与用户试图连接的域名匹配。这是为了防止中间人攻击，其中攻击者可能会伪造证书并欺骗客户端连接到错误的服务器。
验证证书的签名：客户端使用根CA的公钥来验证服务器证书的数字签名。如果签名验证通过，客户端可以确信证书未被篡改。

如果服务器证书通过上述验证步骤，客户端就可以信任服务器的身份，并继续建立安全连接，使用服务器的公钥来加密通信数据。
注意：
客户端可以选择是否验证服务器证书。在某些情况下，如果客户端无法验证服务器的证书或不进行验证，连接仍然可以建立，但会警告用户连接不安全。然而，为了最大程度地确保安全，建议客户端始终验证服务器证书的合法性。

3.12 HTTPS信息摘要的算法是什么

HTTPS使用一种称为消息摘要算法（Message Digest Algorithm）的算法来确保数据的完整性。具体来说，HTTPS通常使用SHA-256（Secure Hash Algorithm 256位）或其他类似的消息摘要算法。

在HTTPS安全通信中，数字签名和消息摘要使用了以下几种算法：

MD5(Message-Digest Algorithm 5)：MD5是一个128位长度的消息摘要算法，用于产生数据的数字签名，校验数据完整性。但MD5已被证实存在弱点，可以被碰撞攻击。
SHA-1(Secure Hash Algorithm 1)：SHA-1是160位长度输出的密码HASH算法，相比MD5更加安全可靠，但理论上也可能受到碰撞攻击。
SHA-2：SHA-2代表了一系列SHA算法，包括SHA-224、SHA-256、SHA-384、SHA-512等变种。其中SHA-256是目前广泛使用的数字签名和消息摘要算法。
SHA-3：SHA-3是最新的安全HASH算法标准，采用Keccak算法，可以产生224、256、384、512位长度的消息摘要。其安全性得到广泛认可。
HMAC：HMAC(Hash-based Message Authentication Code)是将HASH算法与密钥结合，生成包含HASH算法和密钥的消息摘要，提高了安全性。

总结：
HTTPS中常用的消息摘要和数字签名算法是SHA-2(特别是SHA-256)和HMAC，以及最新的SHA-3算法。这些算法安全性强，抗破解能力高。

SHA-256是SHA-2家族中的一种，它是一种密码学安全的哈希函数，用于生成数据的固定长度的哈希值。SHA-256会将输入数据（如HTTP报文或HTTPS数据）转换成256位（32字节）的哈希值。如果在传输过程中数据被篡改，即使是微小的更改，也会导致哈希值发生显著变化，从而使客户端能够检测到数据的篡改。

SHA-256被广泛用于HTTPS通信中的消息摘要生成，以确保传输的数据在传输过程中没有被篡改。这有助于防止中间人攻击和确保数据的完整性。同时，SHA-256也是当前广泛使用的加密哈希算法之一，具有较高的安全性和广泛的应用范围。

3.13 HTTPS交换的是什么

HTTPS通信主要交换的内容包括SSL/TLS握手信息、加密的HTTP请求和响应以及用于验证数据完整性的消息摘要。这些机制确保了HTTPS通信的安全性和隐私。

其实也就是建立连接的过程。

3.14 HTTPS数据传输用什么加密方式

HTTPS数据传输使用对称加密和非对称加密结合的方式来保障数据的安全性和保密性。

以下是HTTPS通信中常用的加密方式：

对称加密：对称加密使用相同的密钥来加密和解密数据，因此被称为"对称"。在HTTPS通信中，客户端和服务器在SSL/TLS握手过程中协商出一个对称的会话密钥（Session Key）。这个会话密钥用于加密和解密实际的HTTPS数据。常见的对称加密算法包括：

AES（Advanced Encryption Standard）：目前广泛使用的对称加密算法之一，支持不同的密钥长度，如AES-128、AES-256等。

非对称加密：非对称加密使用一对密钥，包括公钥和私钥，其中一个用于加密，另一个用于解密。在HTTPS通信中，服务器拥有一对公钥和私钥，其中公钥被包含在服务器的数字证书中，而私钥是服务器保密的。非对称加密主要用于SSL/TLS握手阶段，以安全地协商对称会话密钥。常见的非对称加密算法包括：

RSA（Rivest–Shamir–Adleman）：常用于数字证书中的非对称加密算法。

数字签名：数字签名是一种非对称加密的应用，用于验证数字证书的有效性。服务器的数字证书包含服务器的公钥和由证书颁发机构（CA）签名的信息。客户端使用CA的公钥来验证证书的签名，以确保证书是合法的。

HTTPS通信的基本过程是：在握手阶段，服务器和客户端协商出一个对称的会话密钥，该密钥用于加密和解密HTTP数据。这个对称会话密钥由服务器的非对称公钥加密传输给客户端，客户端使用私钥解密得到该密钥。之后，客户端和服务器使用对称密钥来加密和解密通信数据，保障数据的机密性和完整性。

总结：
HTTPS使用对称加密和非对称加密（包括数字签名）来保障通信数据的安全性和保密性。这种综合使用不同的加密方式，使得HTTPS通信变得安全可靠。

4 HTTP2相比HTTP1有什么优势

注意：HTTP2不是HTTPS，两者别搞成一个了。

HTTP/2是HTTP/1的后续版本，它引入了一些重要的改进，以提高性能和效率。以下是HTTP/2相比HTTP/1的一些主要优势：

多路复用（Multiplexing）：HTTP/2允许多个请求和响应同时在一个连接上进行传输，而不像HTTP/1那样需要建立多个连接。这意味着可以在一个连接上并行发送多个请求和响应，减少了连接建立和维护的开销，提高了性能。
二进制格式：HTTP/2采用了二进制传输格式，而HTTP/1使用文本格式。二进制格式更加紧凑和高效，减少了数据传输的大小，从而提高了效率。
头部压缩：HTTP/2支持头部字段的压缩，减少了请求和响应中的重复头部信息的传输，降低了带宽使用，加快了页面加载速度。
服务器推送（Server Push）：HTTP/2允许服务器在客户端请求之前主动推送资源。这使得服务器可以预测客户端可能需要的资源，并在请求之前发送，减少了往返延迟，提高了加载速度。
优化的流量控制：HTTP/2引入了更有效的流量控制机制，可以更精细地管理数据流的传输和优先级，确保关键资源能够更快地加载。
支持Header压缩算法：HTTP/2使用HPACK压缩算法来压缩头部信息，减少了数据传输的开销。这有助于提高性能，特别是在低带宽或高延迟网络环境下。
安全性：虽然不是HTTP/2的本质特性，但它鼓励网站采用加密（通过HTTPS），因为大多数现代浏览器只支持HTTP/2超过HTTPS。因此，HTTP/2可以提高通信的安全性。

总结：
HTTP/2相对于HTTP/1具有更高的性能、更低的延迟和更高的效率，可以改善网站的加载速度和用户体验。因此，许多网站和服务已经采用了HTTP/2来提供更快的性能。

4.1 GRPC是HTTP2还是HTTP1

GRPC使用HTTP/2作为其底层的传输协议，而不是HTTP/1。GRPC是一个高性能的远程过程调用（RPC）框架，它使用HTTP/2来实现通信，具有诸多优势，包括多路复用、头部压缩、流控制等特性，使其成为现代分布式系统中的常用工具。HTTP/2的性能和效率改进使得GRPC可以更高效地处理大量的并发请求，同时提供更小的延迟和更低的带宽消耗。因此，GRPC的底层协议是HTTP/2，而不是HTTP/1。

5 TCP

TCP（Transmission Control Protocol，传输控制协议）是计算机网络中的一种常用的传输层协议，它提供可靠的、面向连接、点到点的数据传输服务。

5.1 TCP和HTTP的区别

HTTP（Hypertext Transfer Protocol）和TCP（Transmission Control Protocol）是计算机网络中的两个不同的协议，它们在网络通信中扮演不同的角色，有以下主要区别：

层级关系：

TCP是传输层协议，负责在网络上可靠地传输数据，处理数据的分段、顺序控制、流量控制等网络传输的底层细节。
HTTP是应用层协议，构建在传输层之上，用于定义客户端和服务器之间的通信规则，以便请求和传输超文本（通常是网页）和其他数据。

功能：

TCP主要负责数据传输的可靠性和有序性。它确保数据能够从一个端点安全地传输到另一个端点，而不会损坏、丢失或乱序。
HTTP主要负责定义客户端和服务器之间的请求和响应的格式，以及如何处理和呈现文档或数据。

连接性：

TCP是一种面向连接的协议，它建立持久的连接来传输数据，通常使用客户端-服务器模型。
HTTP可以基于TCP连接，但它是一种无状态协议，每个请求都是独立的，服务器不会保持与客户端的持久连接。

端口：

TCP使用端口号来标识不同的网络应用程序或服务。例如，Web服务器通常使用TCP端口80或443。
HTTP通常基于TCP连接，使用HTTP默认端口80（非加密）或443（加密）。

通信内容：

TCP传输的是原始二进制数据流，它没有关于数据的上下文或语义。
HTTP传输的是基于文本的消息，这些消息包含请求或响应的元信息和数据，以及用于标识资源的URL。

应用领域：

TCP是一个通用的协议，用于支持各种应用程序和服务的可靠通信，包括HTTP。
HTTP主要用于互联网上的超文本传输，用于在Web浏览器和Web服务器之间传输网页、图像、视频、API数据等。

总结：
TCP提供了网络通信的底层基础，而HTTP构建在TCP之上，定义了用于Web数据传输的规则和语义。HTTP使用TCP作为它的传输层协议之一，但还包括其他应用层协议，如HTTPS（HTTP over TLS/SSL）等，以提供安全性和隐私保护。

5.2 HTTP是在TCP之上运行，两者的包会有什么区别

TCP的数据包包含源端口和目标端口，HTTP不包含端口信息。
TCP的包头简单，只包含源端口、目标端口、序号、确认号等信息。HTTP的数据包更复杂，包含请求方法、URL、协议版本、请求头部、消息体等信息。
TCP关注传输， packets只包含数据。HTTP关注应用信息，packets包含具体的请求或响应详情。
TCP的packets按顺序传输，HTTP的packets可以乱序。
TCP需要建立连接、流量控制和拥塞控制。HTTP运行在TCP连接上，可以忽略这些问题。
TCP对数据包的大小没有限制。HTTP一般将数据包限制在1500字节以内。
TCP的packets只有头部。HTTP的packets有头部、消息体等完整结构。
TCP是面向连接的协议。HTTP本质上是无连接的。

总结：
两者分别工作在不同层次，TCP负责底层传输，HTTP负责具体的应用数据交互，两者的包结构和功能有着明显的区别。

5.3 TCP特点

可靠性：TCP提供可靠的数据传输。它确保数据从发送端准确地传输到接收端，通过使用序号、确认和重传机制来实现数据的可靠性。如果数据包丢失、损坏或乱序，TCP将负责重新发送数据，以确保完整性和正确性。
面向连接：TCP是一种面向连接的协议，连接的建立需要经过三次握手过程，以确保双方都准备好进行数据传输。连接的关闭也需要经过四次挥手过程。
流量控制：TCP使用流量控制机制来防止数据包的积压和数据传输过程中的数据流过快。接收端可以通知发送端其可接受的数据量，从而调整发送速率，以适应接收端的处理能力。
拥塞控制：TCP具有拥塞控制机制，它可以在网络拥塞时减缓数据发送速率，以防止过度拥塞，保持网络的稳定性。拥塞控制通过检测丢失的数据包和计算往返时间来实现。
面向字节：TCP将数据视为一系列字节的流，而不是消息或数据包。这允许TCP在传输时对数据进行分段、重组和流动控制，以适应不同的网络条件。
双工通信：TCP支持全双工通信，允许双方同时发送和接收数据，这使得实时应用和互动应用能够进行高效的双向通信。
端口和套接字：TCP使用端口来区分不同的应用程序和服务。套接字是应用程序与TCP协议交互的接口，通过套接字可以进行数据的读取和写入。
可靠性和复杂性：TCP提供高度的可靠性和数据完整性，但它也引入了一些复杂性和额外的开销，如握手、确认和拥塞控制。这些机制确保了数据的可靠传输，但有时也会引入一些延迟。

总结：
TCP是一种非常可靠的协议，适用于需要可靠数据传输和连接性能的应用程序，如网页浏览、电子邮件、文件传输、实时通信等。它是互联网中的基础协议之一，确保了数据在网络中的可靠传输。

5.4 TCP使用场景

TCP（Transmission Control Protocol，传输控制协议）适用于需要可靠的、面向连接的数据传输的场景。以下是一些常见的TCP使用场景：

Web浏览：当在浏览器中访问网页时，浏览器使用HTTP协议（通常是HTTP over TCP）与Web服务器建立TCP连接来请求网页内容。TCP确保了网页数据的可靠传输，以便正确显示网页。
电子邮件：SMTP（Simple Mail Transfer Protocol）和POP3（Post Office Protocol）或IMAP（Internet Message Access Protocol）等电子邮件协议使用TCP来传输电子邮件消息，以确保邮件的可靠传输和正确接收。
文件传输：FTP（File Transfer Protocol）和SFTP（SSH File Transfer Protocol）等协议使用TCP来传输文件。这些协议需要可靠的数据传输，以防止文件损坏或丢失。
远程登录：SSH（Secure Shell）和Telnet等协议用于远程登录到计算机系统。SSH使用TCP来提供加密的、安全的远程访问。
数据库访问：许多数据库管理系统（如MySQL、PostgreSQL、Oracle）使用TCP来进行数据库查询和数据传输。可靠性对于数据库操作至关重要。
VoIP电话：Voice over Internet Protocol（VoIP）电话系统使用TCP或UDP（在某些情况下）来传输音频数据。虽然UDP在VoIP中更常见，但某些应用也使用TCP以确保更可靠的音频传输。
在线游戏：某些在线游戏使用TCP来传输游戏数据，特别是需要高度可靠性的游戏。虽然UDP更常用于实时游戏，但TCP适用于一些策略性或回合制游戏。
HTTPS安全通信：HTTPS协议使用TLS/SSL建立在TCP上，以确保加密和安全性，用于保护敏感数据的传输，如信用卡信息和登录凭据。
Web服务：当使用SOAP、RESTful API等协议进行Web服务调用时，通常会使用HTTP over TCP来进行通信。

总结：
TCP适用于需要可靠性、面向连接和数据完整性的应用场景。它确保数据的可靠传输，适用于许多互联网应用，尤其是需要高度可靠性的应用。然而，由于TCP引入了一些额外的开销，可能会引入一些延迟，因此在某些实时性要求较高的应用中，可能会使用UDP等协议。

注释："HTTP over TCP" 就是使用传输控制协议（TCP）作为HTTP协议的底层传输协议。在这种情况下，HTTP数据通过TCP连接进行传输，以确保数据的可靠性和完整性。

5.5 基于（使用）TCP的协议有哪些

HTTP（Hypertext Transfer Protocol）：HTTP是用于在Web浏览器和Web服务器之间传输超文本文档的协议。它是互联网上最常见的应用层协议之一，通常使用TCP作为传输层协议。
HTTPS（HTTP Secure）：HTTPS是HTTP的安全版本，通过在HTTP上加入TLS/SSL层来加密数据传输。它使用TCP作为底层传输协议，以确保加密的、安全的通信。
FTP（File Transfer Protocol）：FTP是用于文件传输的协议，它使用TCP来传输文件。FTP允许用户上传和下载文件到和从远程服务器。
SMTP（Simple Mail Transfer Protocol）：SMTP是用于电子邮件传输的协议，用于从发送方电子邮件客户端发送电子邮件到接收方电子邮件服务器。SMTP使用TCP来传输电子邮件消息。
POP3（Post Office Protocol version 3）和 IMAP（Internet Message Access Protocol）：这两个协议用于从电子邮件服务器上检索电子邮件。POP3和IMAP都使用TCP来建立连接并下载电子邮件。
SSH（Secure Shell）：SSH是用于安全远程登录和文件传输的协议。它使用TCP作为底层传输协议，并提供加密和认证功能，以保护远程会话的安全。
Telnet：Telnet是一种用于远程登录到远程主机的协议，但它不提供加密，因此安全性较低。它使用TCP来传输终端会话。
MySQL：MySQL是一种流行的关系型数据库管理系统，它使用TCP来建立与数据库服务器的连接并进行数据查询和操作。
RDP（Remote Desktop Protocol）：RDP用于远程桌面连接，允许用户远程控制和操作远程计算机。它使用TCP来传输桌面会话数据。
XMPP（Extensible Messaging and Presence Protocol）：XMPP是一种实时通信协议，用于即时消息传递和在线状态。它使用TCP来传输消息。

总结：
这些协议是构建互联网和计算机网络中各种应用和服务的关键组成部分，它们依赖于TCP来提供可靠的数据传输。每个协议都具有不同的用途和特性，但它们都使用TCP作为传输层协议，以确保数据的可靠性和正确性。

5.6 TCP三次握手

参考1：HTTP协议常问的面试题（吐血整理）看 16 TCP三次握手和四次挥手。

TCP的三次握手（Three-Way Handshake）是建立TCP连接的过程，用于确保通信的双方都准备好传输数据。以下是TCP三次握手的过程：

第一步 - 客户端发送连接请求：
客户端首先向服务器发送一个特殊的TCP包，称为SYN（同步）包。
这个包包含客户端随机选择的一个初始序列号（Client ISN，Initial Sequence Number），该序列号用于标识客户端发送的数据，以及一个标志位SYN=1，表示这是一个连接请求。
第二步 - 服务器确认连接请求：
服务器收到客户端的连接请求（SYN包）后，如果同意建立连接，会回复一个包，通常称为SYN-ACK包。
这个包包含了服务器分配用于标识服务器发送的数据的初始序列号（Server ISN），以及标志位SYN=1和ACK=1，表示这是对客户端请求的确认，并且服务器也准备好建立连接。
第三步 - 客户端确认服务器的确认：
客户端收到服务器的确认（SYN-ACK包）后，会向服务器发送一个确认包（ACK包）。
这个包包含标志位ACK=1，表示客户端接受了服务器的确认，并且连接已建立。
此时，双方都已确认连接的建立，可以开始传输数据。

完成了这个三次握手过程后，TCP连接就建立成功了，客户端和服务器都可以开始在连接上进行数据传输。每个数据包都会包含一个序列号，用于标识数据的顺序和完整性，以确保数据能够正确地传输和接收。

注意：
三次握手是用于建立TCP连接的过程。在连接结束后，会使用四次挥手过程来正常关闭连接。这些握手和挥手过程是TCP协议中的关键步骤，以确保数据的可靠传输和连接的正确终止。

5.7 TCP在握手完成之后，A到B发送数据，中间有个数据被篡改，它会怎处理

TCP在数据传输过程中，包括握手阶段之后，会使用一种校验和机制来检测数据是否被篡改。这个校验和通常称为TCP校验和（TCP Checksum）。

当数据从发送端A到接收端B时，TCP发送端会计算校验和并将其附加到数据包的头部。接收端B收到数据包后会进行以下处理：

校验和验证：接收端B会计算接收到的数据包的校验和，并将结果与数据包头部中的校验和进行比较。
比较校验和：如果接收端计算出的校验和与数据包头部中的校验和匹配，说明数据包在传输过程中没有被篡改，数据被接受并继续传递给上层应用程序。
校验和不匹配：如果接收端计算出的校验和与数据包头部中的校验和不匹配，说明数据包在传输过程中可能受到了篡改或损坏。接收端会丢弃这个数据包，不传递给上层应用程序，并可以选择发送一个通知给发送端A请求重新发送数据。

这种校验和机制帮助确保了TCP传输中数据的完整性。如果数据包在传输过程中被篡改或损坏，接收端会检测到这一问题，并丢弃损坏的数据包，从而保护了数据的可靠性。如果发生数据包丢失或篡改，TCP会负责重新传输数据，直到接收端确认接收到正确的数据。

总结：
TCP使用校验和机制来检测和处理数据传输中的篡改或损坏问题，以确保数据的可靠性和完整性。这是TCP协议的一个重要特性，有助于提高网络通信的可靠性。

5.8 TCP三次握手的两种队列

参考1：TCP连接三次握手中的重要数据结构：半连接队列和全连接队列
在TCP三次握手的时候，服务端会维护两个队列：监听队列（Listen Queue）和已完成队列（Completed Connection Queue）。

监听队列（Listen Queue）：

监听队列也称为“半连接队列”或“未完全建立连接的队列”。
在服务端（通常是服务器）调用listen函数后，它会等待客户端的连接请求。
当客户端发送SYN（同步）包进行连接请求时，服务器会将这个请求放入监听队列中，等待后续的第二次握手。
监听队列的大小可以通过操作系统的配置进行设置，这个设置限制了同时等待连接的数量。如果队列已满，新的连接请求会被拒绝。

已完成队列（Completed Connection Queue）：

已完成队列也称为“全连接队列”或“已建立连接的队列”。
在服务器成功进行了第二次握手，接受了客户端的连接请求后，连接就会从监听队列移动到已完成队列中。
已完成队列中的连接表示已经建立，可以进行数据传输。
服务器会从已完成队列中取出连接，分配资源，为连接提供服务，并在完成后进行释放。

总结：
监听队列用于存放等待服务器确认的连接请求，而已完成队列用于存放已经建立的连接，准备进行数据传输。这两个队列在TCP连接建立过程中起着重要的作用，确保了连接的正常建立和管理。当连接终止时，也有相应的队列来管理连接的释放。
TCP三次握手的半连接队列和全连接队列示意图

5.8.1 TCP三次握手的两种队列溢出

不管是半连接队列还是全连接队列，都有最大长度限制，超过限制时，内核会直接丢弃，或返回RST包。

半连接队列溢出：
客户端发送SYN报文和服务端进行第一次握手，此时服务端将此请求信息放在半连接队列中并回复SYN+ACK给客户端。这里也就是SYN攻击的点，攻击方要做的就是不停的建立连接，但是却不给出ACK确认，导致半连接队列满了，其他请求无法进入。

全连接队列溢出：
当服务端并发处理大量请求时，如果TCP全连接队列过小，就容易溢出。发生TCP全连接队溢出的时候，后续的请求就会被丢弃，这样就会出现服务端请求数量上不去的现象。

全连接队列满了，就只会丢弃连接吗？
实际上，丢弃连接只是Linux的默认行为，我们还可以选择向客户端发送RST复位报文，告诉客户端连接已经建立失败。
TCP三次握手的全连接队列参数配置图
tcp_abort_on_overflow 共有两个值分别是0和1，其分别表示：
0 ：表示如果全连接队列满了，那么server丢弃client发过来的ack；
1 ：表示如果全连接队列满了，那么server发送一个reset 包给 client，表示废掉这个握手过程和这个连接；

如果要想知道客户端连接不上服务端，是不是服务端TCP全连接队列满的原因，可以把tcp_abort_on_overflow设置为1，这时如果在客户端异常中可以看到很多connection reset by peer的错误，那么就可以证明是由于服务端 TCP 全连接队列溢出的问题。

通常情况下，应当把tcp_abort_on_overflow设置为0，因为这样更有利于应对突发流量。
举个例子，当TCP全连接队列满导致服务器丢掉了ACK，与此同时，客户端的连接状态却是ESTABLISHED，进程就在建立好的连接上发送请求。只要服务器没有为请求回复ACK，请求就会被多次重发。如果服务器上的进程只是短暂的繁忙造成accept队列满，那么当TCP全连接队列有空位时，再次接收到的请求报文由于含有ACK，仍然会触发服务器端成功建立连接。

5.9 TCP如何实现可靠性传输

TCP（Transmission Control Protocol，传输控制协议）通过一系列机制来实现可靠性传输，确保数据从发送端到接收端的可靠传输。

以下是TCP实现可靠性传输的主要机制：

序列号和确认号：TCP在每个数据包中包含序列号（Sequence Number）和确认号（Acknowledgment Number）。序列号用于标识数据的顺序，确认号用于确认接收到的数据。接收端会发送确认，指示它已经成功接收并准备好接收下一个数据包。
数据重传：如果发送端没有收到来自接收端的确认，或者接收端检测到丢失的数据包，TCP会触发数据重传机制。发送端会重新发送丢失的数据包，直到接收到确认为止。
流量控制：TCP使用流量控制机制，确保发送端不会以过快的速度发送数据，从而防止数据包的积压和网络拥塞。接收端可以通知发送端其可接受的数据量，以调整发送速率。
拥塞控制：TCP还具有拥塞控制机制，可以在网络拥塞时减缓数据发送速率，以防止过度拥塞并提高网络的稳定性。拥塞控制通过检测丢失的数据包和计算往返时间来实现。
有序交付：TCP确保数据按正确的顺序交付给应用层。即使数据包在传输过程中到达的顺序与发送顺序不同，TCP也会将它们按正确的顺序交给应用程序。
校验和验证：TCP使用校验和机制来检测数据包在传输过程中是否发生了损坏。如果数据包在传输过程中损坏，接收端会通知发送端丢弃损坏的数据包，并要求重新发送。
超时和重传策略：TCP使用超时和重传策略来处理丢失的数据包。如果一个数据包的确认没有及时到达，TCP将触发重传机制，重新发送该数据包。
窗口机制：TCP使用窗口机制来调整发送和接收的数据量，以提高效率。窗口大小可以根据网络条件进行动态调整。
连接建立和断开的握手过程：TCP的连接建立和断开过程也是可靠性的一部分。三次握手确保了双方都准备好建立连接，四次挥手确保了连接的正常终止。

总结：
TCP通过这些机制和策略，以及其他一些技术手段，来实现可靠性传输，确保数据在网络中的可靠传输和正确接收。这使得TCP成为一种非常可靠的协议，适用于各种需要可靠性传输的应用，如网页浏览、电子邮件、文件传输等。

5.10 TCP建立连接的时候为什么是三次握手，不是两次或四次

TCP建立连接采用三次握手的过程，而不是两次或四次，是为了确保双方都准备好进行可靠的数据传输，并且避免出现不必要的连接建立。

以下是三次握手的原因和过程：

确保双方都愿意建立连接：通过三次握手，确保了客户端和服务器都愿意建立连接。如果只有两次握手，那么可能会导致一方不知道对方是否愿意建立连接，从而引发不确定性和安全问题。
防止旧连接的问题：在网络中，已经关闭连接的数据包可能在某段时间内仍然存在，这是因为网络中的数据包可能会延迟或复制。如果只有两次握手，可能会导致在新连接中误认为是旧连接的数据包，从而引发问题。通过第三次握手，可以确保是新的连接，防止这种问题的发生。
防止连接资源浪费：如果连接建立后不进行三次握手的确认，那么服务器可能会浪费资源来处理无效的连接请求。

总结：
三次握手确保了双方都准备好建立连接，避免了可能导致数据传输问题的情况。它是TCP协议设计的一部分，旨在提供可靠性和安全性，确保通信的正常进行。虽然三次握手引入了一些额外的开销，但这个开销在大多数情况下是合理的，以确保数据传输的可靠性。

5.11 TCP四次挥手

参考：你需要知道的 TCP 四次挥手
在这里插入图片描述

TCP的四次挥手是用于正常关闭TCP连接的过程，确保数据的可靠传输和连接的正确终止。以下是TCP四次挥手的过程：

第一次挥手 - 客户端发送连接关闭请求（FIN from Client）：

客户端首先决定关闭连接，它向服务器发送一个带有FIN（Finish，结束）标志的TCP数据包给服务器，表示客户端不再发送数据给服务器，但仍然愿意接收来自服务器的数据。
客户端进入FIN_WAIT_1状态，等待服务器的确认或拒绝。

第二次挥手 - 服务器确认关闭请求（ACK from Server）：

服务器接收到客户端的FIN后，会发送一个带有确认ACK标志的TCP数据包给客户端，表示服务器已收到客户端的关闭请求。
此时服务器进入CLOSE_WAIT状态，客户端继续等待来自服务器的可能未发送完的数据。

第三次挥手 - 服务器发送连接关闭请求（FIN from Server）：

当服务器确定不再有数据要发送给客户端时，服务器发送一个带有FIN标志的TCP数据包给客户端，表示服务器也准备好关闭连接。
服务器进入LAST_ACK状态，等待客户端的确认。

第四次挥手 - 客户端确认关闭请求（ACK from Client）：

客户端收到服务器的FIN包后进入TIME_WAIT状态，会发送一个ACK包作为确认，并等待一段时间以确保可能在网络中滞留的ACK数据包到达服务器。
服务器收到这个ACK后，进入CLOSED状态，连接完全关闭。
客户端则会等一段时间再进入关闭状态，释放资源，结束TIME_WAIT状态。因为第四次挥手不一定能成功发给服务端，所以要等一下，看看服务端会不会因为没收到第四次挥手，而重发第三次挥手。

在四次挥手的过程中，双方都有机会发送FIN和ACK包，以确保连接的正常关闭。这可以防止出现连接的半关闭状态，确保数据的可靠传输和连接的正常终止。

注意：

和TCP三次握手不同。TCP关闭连接的挥手足足有四次。这是因为第二次挥手和第三次挥手之间可能有一些服务端需要发送的处理比较慢的数据要返回，所以没有将这两次挥手合并。
TIME_WAIT状态的存在是为了处理可能在网络中延迟的ACK包，以确保连接正常关闭。这个状态的持续时间相对较短，通常在几分钟内自动结束，以释放资源。

5.12 TCP前面加个防火墙，那TCP的包会在哪一步被拦截掉？

如果在TCP连接前面加上一个防火墙，那么TCP的数据包会在以下几个步骤被防火墙拦截：

三次握手建立连接时，防火墙可以拦截SYN包，导致无法建立连接。
数据传输过程中，防火墙可以拦截任何一个方向的TCP数据包。
四次挥手断开连接时，防火墙可以拦截FIN/ACK包，导致无法正常断开。
如果启用了状态检测，防火墙可以拦截不符合预期状态的TCP包。
防火墙也可以拦截重传的TCP包。
防火墙可以过滤指定端口的TCP包，直接阻止连接。

总结：
防火墙可以在TCP连接的任何一个阶段进行数据包的拦截、过滤或state检测，从而达到阻止某些连接或限制某些通信的目的。最直接的方法是直接过滤目标端口的TCP数据包。

5.13 TCP一个端口可以并发接收多少请求

TCP协议本身并没有限制一个端口能够接收的并发请求的数量，而是受限于多个因素，包括操作系统的设置、硬件资源、应用程序的设计和负载等。以下是影响一个端口能够接收多少并发请求的一些关键因素：

操作系统的资源限制：操作系统在内核级别管理网络连接，因此它会限制一个端口可以接受的并发连接数量。这个限制通常受操作系统的配置和资源限制（如文件描述符限制）的影响。不同的操作系统和版本可能会有不同的默认设置，但通常可以通过操作系统的配置来调整这些限制。
硬件资源：硬件资源如处理器、内存和网络适配器的性能也会影响一个端口能够处理的并发请求数量。更强大的硬件可以处理更多的并发连接。
应用程序的设计：应用程序的设计和实现方式对并发请求的处理有重要影响。例如，使用多线程或多进程模型可以提高并发性，或者使用事件驱动的非阻塞I/O可以有效地处理大量并发请求。
负载均衡：负载均衡器可以帮助分发来自不同客户端的请求到多个服务器端口上，从而提高整个系统的并发处理能力。
请求处理时间：请求处理的时间长度也会影响端口的并发请求处理能力。如果请求需要较长的时间来处理，那么端口可能会在某一时刻积累大量的等待请求。
网络拓扑和带宽：网络拓扑和带宽限制也可能对并发连接产生影响。如果网络连接速度较慢或带宽有限，那么可能会限制并发请求的处理速度。

需要注意的是，不同的应用场景和需求会对并发请求的要求产生不同的影响。因此，在设计和部署应用程序时，需要考虑到上述因素，并根据具体需求进行优化和配置，以确保能够满足所需的并发请求处理能力。同时，监测和性能测试也是评估系统能够处理多少并发请求的重要手段。

5.14 TCP可能有几万个、几十万个、上百万个链接都在这个端口上，怎么知道它是哪个链接，对应哪个用户，对应哪个请求？

TCP是传输层协议，可以通过上面的应用层以及以下条件获取到。

源IP地址和目标IP地址：每个TCP连接都有一个源IP地址和一个目标IP地址，通过这些IP地址，可以确定连接的两端。这可以帮助区分不同的用户或请求，特别是在多个客户端同时连接到同一个服务器端口的情况下。
源端口和目标端口：每个TCP连接都有一个源端口和一个目标端口。源端口通常是客户端随机选择的，而目标端口通常是服务器上监听的端口。通过这些端口，可以将连接与特定应用程序或服务相关联。
会话标识符：有些应用层协议在TCP连接上使用会话标识符或令牌，以将连接与特定的用户或请求相关联。例如，HTTP协议使用会话标识符来跟踪用户的会话状态。
日志记录：在服务器上，可以配置日志记录，以跟踪连接和请求的详细信息。通过查看服务器日志，可以了解哪个IP地址在哪个端口上建立了连接，以及与之相关的请求或操作。
应用层协议：有些应用层协议在其数据包中包含有关用户或请求的信息。例如，HTTP请求包括URL和HTTP头，这些信息可以帮助确定请求的内容和来源。
网络分析工具：网络分析工具可以用于监视和分析网络流量。可以使用这些工具来捕获和分析TCP数据包，以查看连接的详细信息，包括源IP、目标IP、源端口、目标端口等。
负载均衡器和代理服务器：如果有负载均衡器或代理服务器位于服务器端和客户端之间，它们通常会在处理连接时添加一些信息，以帮助将连接路由到正确的后端服务器或应用程序实例。

综合使用这些方法，可以帮助确定特定TCP连接对应哪个用户或请求。这在网络管理、安全监控和故障排除等方面都非常有用。不过，具体的方法可能因网络配置和应用程序的不同而异。

5.15 tcp粘包拆包是怎么发生的？该怎么解决？就是接到数据以后怎么解决呢？

参考1：TCP粘包现象分析及处理方式

5.15.1 为什么TCP会粘包，UDP不会粘包

TCP是面向流的的传输协议，发送端可以一次发送不定长度的数据，而接收端也可以一次提取不定长度的数据。即这种传输方式是无保护消息边界的。
UDP是面向数据报的传输协议，发送的UDP报文都被接收端视为一条消息，若消息太长被分片，UDP协议也会完成组合后才呈现在内核缓冲区；且UDP报文有消息头，对于接收端来说，易于区分处理。即这种传输方式是有保护消息边界的。

5.15.2 TCP粘包现象产生原因

发送方和接收方对数据的处理都有可能引发粘包现象。

发送方：TCP为了提高传输效率，会在收集到足够多数据后才一起发送，同时一条数据太长，TCP还会将数据进行拆分发生。这将会导致三种情况发生：

多条数据被组合成一条数据发送。
长数据被拆分成片段分别发送。
长数据被拆分的片段和短数据一起发送。

接收方：接收方收到的数据会保存在缓存中，如果应用层提取数据不够快就会导致缓存中多条数据粘在一起。

5.15.3 粘包处理方式

不是所有时候都要去处理粘包，比如类似于文件传输这样发送的数据无结构，那么接收方正常接受存储就行，不必考虑分包问题。
只有在TCP长链接且发送不同结构数据时（数据毫不相干，或者必须分开解读），那就需要处理粘包问题了。

发送方的处理方式

可以关闭Nagle算法，通过TCP_NODELAY选项来关闭。缺点是TCP传输效率降低。

Nagle算法主要做两件事：

只有上一个分组得到确认，才会发送下一个分组；
收集多个小分组，在一个确认到来时一起发送。正是Nagle算法造成了发送方有可能造成粘包现象。

接收方的处理方式

TCP中接收方无法处理！

应用层的处理方式

应用层的处理简单易行！并且不仅可以解决接收方造成的粘包问题，还能解决发送方造成的粘包问题。
解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？

格式化数据，每条数据都要实现约定好格式（开始符、结束符），显而易见在数据内部中不能出现开始符和结束符！
发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

封包处理粘包问题

所谓封包，就是给一段数据加上包头，这样一来数据包就分为包头和包体两部分内容，包头其实上是个大小固定的结构体，其中有个结构体成员变量表示包体的长度，这是个很重要的变量，其他的结构体成员可根据需要自己定义。根据包头长度固定以及包头中含有包体长度的变量就能正确地拆分出一个完整的数据包。对于拆包，目前最常用的是以下两种方式：

动态缓冲区暂存方式

大概过程描述如下：

为每一个连接动态分配一个缓冲区，同时把此缓冲区和SOCKET关联，常用的是通过结构体关联。
当接收到数据时首先把此段数据存放在缓冲区中。
判断缓存区中的数据长度是否够一个包头的长度，如不够，则不进行拆包操作。
根据包头数据解析出里面代表包体长度的变量。
判断缓存区中除包头外的数据长度是否够一个包体的长度，如不够，则不进行拆包操作。
取出整个数据包，这里的"取"的意思是不光从缓冲区中拷贝出数据包,而且要把此数据包从缓存区中删除掉，删除的办法就是把此包后面的数据移动到缓冲区的起始地址（环形缓冲可以优化这里）。

这种方法有两个缺点：

为每个连接动态分配一个缓冲区增大了内存的使用。
有三个地方需要拷贝数据，一个地方是把数据存放在缓冲区，一个地方是把完整的数据包从缓冲区取出来，一个地方是把数据包从缓冲区中删除.第二种拆包的方法会解决和完善这些缺点。

可以采用环形缓冲（定义两个指针，分别指向有效数据的头和尾，在存放数据和删除数据时只是进行头尾指针的移动），但是还是不能解决第一个缺点以及第一个数据拷贝，只能解决第三个地方的数据拷贝(这个地方是拷贝数据最多的地方)。第2种拆包方式会解决这两个问题。

利用底层的缓冲区来进行拆包

由于TCP也维护了一个缓冲区，所以我们完全可以利用TCP的缓冲区来缓存我们的数据，这样一来就不需要为每一个连接分配一个缓冲区了。另一方面我们知道recv或者wsarecv都有一个参数，用来表示我们要接收多长长度的数据.利用这两个条件我们就可以对第一种方法进行优化。

直接用底层的缓冲区直接进行拆包，固然可以免于拷贝到缓冲区，但是这样每次接收，都要做逻辑处理，对于频繁接收数据的场景，这种方法效率并不高。而如果我们一次性接收到很多数据，然后利用动态缓冲区暂存，进行异步处理。一次接收，多次处理，效率反而会更高。

6 UDP

UDP（User Datagram Protocol，用户数据报协议）同TCP一样都是传输层协议，用于在计算机网络上传输数据。与TCP（Transmission Control Protocol）不同的是UDP是一种无连接协议，它提供的是一种简单的，但不可靠的数据传输机制。

6.1 UDP特点

无连接性：UDP是一种无连接协议，意味着在数据传输前不需要在发送端和接收端之间建立连接。这使得UDP的数据传输速度较快，因为不需要进行握手和连接管理。
不可靠性：UDP不提供数据传输的可靠性，它不保证数据的完整性和顺序性。这意味着数据包在传输过程中可能会丢失、重复、乱序或损坏，而UDP本身不提供机制来处理这些问题。因此，如果应用程序需要可靠的数据传输，它需要自行处理这些问题。
低开销：UDP的头部开销较小，相对于TCP来说，UDP头部只包含源端口、目标端口、数据长度和校验和等字段，因此UDP的开销较小，有助于降低网络传输的额外负担。这使得UDP适用于那些对传输延迟敏感且可以容忍一定数据丢失的应用，如实时音视频传输和在线游戏。
广播和多播支持：UDP支持广播和多播通信，允许一台计算机将数据包发送给多个目标计算机，而不是仅限于点对点通信。
没有流量控制（No Flow Control）：UDP不提供流量控制机制，因此发送端可以随时发送数据，而不需要等待接收端的确认。这可以在某些情况下导致网络拥塞。
应用场景：UDP通常用于那些不需要强制的可靠性和流量控制的应用，如实时音频和视频流、在线游戏、DNS（域名系统）查询、SNMP（简单网络管理协议）等。
快速响应：由于UDP的无连接性和低开销，它通常用于需要快速响应的应用，如实时通信和媒体流传输，这些应用更注重低延迟而不是数据的可靠性。

注意：
UDP的设计目标是提供一种轻量级的数据传输机制，适用于那些对速度和实时性要求较高、可以容忍一些数据丢失的应用。然而，由于它的不可靠性，对数据完整性和可靠性要求较高的应用通常会选择使用TCP。在选择UDP或TCP时，应根据应用的特性和需求做出明智的选择。

6.2 TCP和UDP区别

连接性

TCP是一种面向连接的协议，它在数据传输前需要在发送端和接收端之间建立连接，通过三次握手建立连接，然后再进行数据传输。连接建立后，数据传输是可靠的，有序的，并且会进行错误检查和重传。
UDP是一种无连接的协议，数据包的传输不需要建立连接。每个UDP数据包都是独立的，不会像TCP那样维护连接状态，因此UDP更加轻量级，但不提供连接的可靠性和状态管理。

可靠性

TCP提供可靠的数据传输，它确保数据的完整性、顺序性和可靠性。如果数据包丢失或损坏，TCP会进行重传，直到数据到达接收端。
UDP不提供可靠性保证，它不进行数据包的重传。如果数据包丢失或损坏，UDP不会主动处理，这使得UDP更适用于那些对数据可靠性要求较低的应用。

头部开销

TCP头部相对较大，包含各种控制字段，用于建立和维护连接，这增加了数据包的开销。
UDP头部相对较小，只包含基本的源端口、目标端口、数据长度和校验和字段，因此UDP的开销较小。

延迟和速度

由于TCP的连接建立和数据重传机制，它的传输速度可能较慢，尤其在高丢包率或高延迟的网络环境中。
UDP由于无连接性和较小的头部开销，通常传输速度较快，适合对延迟要求较高的应用。

应用场景

TCP适用于对数据可靠性和顺序性要求高的应用，如网页浏览、电子邮件传输、文件下载和大多数Web应用。
UDP适用于对速度和实时性要求高、可以容忍一些数据丢失的应用，如实时音视频传输、在线游戏、VoIP通信、DNS查询等。

总结：
TCP和UDP是根据不同的需求和应用场景而设计的两种不同的传输协议。选择哪种协议取决于应用的特性和要求，以及对可靠性和速度的权衡。有些应用可能需要同时使用TCP和UDP来满足不同的需求。

6.3 UDP使用场景

UDP（User Datagram Protocol，用户数据报协议）通常用于那些对数据传输速度和低延迟要求较高，可以容忍一定数据丢失的应用场景。以下是一些常见的UDP使用场景：

实时音频和视频传输：UDP适用于实时音频和视频传输，如视频会议、在线直播和实时音视频通话。虽然UDP可能会导致一些数据包的丢失，但对于这些应用来说，快速的数据传输和低延迟更为重要。
在线游戏：多人在线游戏通常使用UDP来传输游戏数据，因为游戏需要快速响应时间，且可以容忍少量的数据包丢失。UDP还允许游戏服务器向多个客户端广播游戏状态。
VoIP（Voice over IP）通信：VoIP应用使用UDP来传输语音数据，以实现实时语音通话。尽管可能会丢失一些声音样本，但低延迟对于语音通话至关重要。
DNS（域名系统）查询：DNS查询通常使用UDP进行，因为它需要快速响应查询请求，且查询结果通常可以容忍一定程度的数据丢失。
SNMP（简单网络管理协议）：SNMP是一种网络管理协议，通常使用UDP来传输管理信息。虽然SNMP可以容忍一些数据包的丢失，但它仍然提供了用于检测错误和请求重传的机制。
传感器数据传输：在物联网（IoT）和传感器网络中，UDP常用于传输传感器数据。由于传感器数据通常需要实时收集和传输，UDP是一个合适的选择。
Trivial File Transfer Protocol（TFTP）：TFTP是一个简单的文件传输协议，通常使用UDP进行文件传输。尽管TFTP不提供可靠性，但它足够用于一些简单的文件传输场景。

注意：
UDP不适用于那些对数据完整性和可靠性要求非常高的应用，如文件传输和大多数Web应用。在选择UDP时，必须权衡快速响应时间和可靠性之间的权衡，并确保应用程序能够处理可能的数据丢失情况。UDP通常用于对速度和实时性要求较高、可以容忍一些数据丢失的应用。

6.4 基于（使用）UDP的协议有哪些

DNS（域名系统）：DNS使用UDP来进行域名解析查询。DNS查询通常需要快速响应时间，因此使用UDP而不是TCP，尽管UDP可能会导致一些查询失败或超时。
DHCP（动态主机配置协议）：DHCP用于自动分配IP地址和其他网络配置参数。DHCP客户端通过UDP向DHCP服务器发送请求，以获取配置信息。
SNMP（简单网络管理协议）：SNMP用于网络设备监控和管理。SNMP通常使用UDP来传输管理信息。
TFTP（Trivial File Transfer Protocol）：TFTP是一个简单的文件传输协议，通常用于小型文件的传输。TFTP使用UDP来传输文件，但不提供可靠性。
NTP（网络时间协议）：NTP用于同步计算机和设备的时间。NTP使用UDP来进行时间同步。
RTP（实时传输协议）：RTP用于实时音频和视频传输，如视频会议和实时流媒体。RTP通常与RTCP（RTP控制协议）一起使用，二者都使用UDP来传输媒体数据和控制信息。
Syslog：Syslog是用于日志记录和远程日志传输的协议，通常使用UDP进行日志消息的传输。
NFS（网络文件系统）：NFS是一种用于在网络上共享文件系统的协议，它可以使用UDP或TCP进行文件传输。在某些情况下，NFS可能会选择使用UDP以提高性能。
Voice over IP（VoIP）通信：一些VoIP应用使用UDP来传输语音数据，以实现实时语音通话。UDP的低延迟特性对VoIP通信很有帮助。
在线游戏：多人在线游戏通常使用UDP来传输游戏数据，以实现低延迟和快速响应时间。

这些是一些使用UDP作为传输协议的常见协议和应用。UDP在这些应用中通常用于对速度和实时性要求较高、可以容忍一些数据丢失的情况。需要注意的是，UDP不提供数据的可靠性保证，因此在使用UDP的应用中，必须考虑如何处理可能的数据丢失和乱序。

6.5 UDP如何实现可靠性传输

UDP（User Datagram Protocol）本身并不提供可靠性传输，它是一种无连接、不可靠的传输层协议。然而，如果需要在UDP上实现可靠性传输，应用程序可以自行实现一些机制来处理数据的完整性、顺序性和可靠性。以下是一些常见的方法来实现在UDP上实现可靠性传输：

应用层协议：在应用层实现可靠性。这意味着在应用程序中编写代码来确保数据的完整性和顺序性。例如，在数据包中添加序列号，以确保数据包的顺序，并在接收端进行缓冲和排序。还可以在数据包中添加校验和字段，以检测数据包的损坏，并进行重传。
重传机制：实现基于时间或事件的重传机制。如果发送方在一定时间内未收到接收方的确认，它可以选择重新发送数据包。这种重传机制可以通过定时器来实现。
确认和反馈：接收方可以向发送方发送确认消息，告知发送方哪些数据包已成功接收，哪些需要重传。发送方可以根据接收方的确认来进行重传。
超时处理：发送方可以设置超时时间，如果在超时时间内未收到确认，就认为数据包丢失，然后进行重传。
流量控制：实现流量控制以防止数据包的拥塞。发送方可以根据接收方的处理能力和网络状况来控制发送速度，以避免数据包的丢失。

需要强调的是，实现可靠性传输需要额外的开销和复杂性，这可能会降低UDP的性能和简洁性。因此，使用TCP通常是更简单和可靠的选择，因为TCP已经内置了可靠性传输机制。但如果某些特定应用需要UDP的低延迟和快速响应时间，同时又需要可靠性，那么可以考虑在应用层实现可靠性传输机制。

总结：
实现可靠性传输需要根据具体的应用需求来设计和实现相应的机制，以确保数据的可靠性、完整性和顺序性。这些机制通常需要在发送端和接收端之间进行协商和协作。

6.6 利用udp实现了可靠的数据传输的协议有哪些

RDT（Reliable Data Transfer）：RDT是一种通用的可靠数据传输协议，它可以在UDP上实现可靠性数据传输。RDT使用序列号和确认消息来实现数据包的可靠性传输。有两个主要的RDT版本，分别是RDT 1.0和RDT 2.0，它们提供了不同级别的可靠性。
TFTP（Trivial File Transfer Protocol）：TFTP是一个简单的文件传输协议，通常使用UDP进行传输。虽然TFTP本身在UDP上实现了可靠性传输，但它的可靠性机制相对简单，主要是通过重传丢失的数据包来实现的。
QUIC（Quick UDP Internet Connections）：QUIC是一种基于UDP的传输协议，用于加速互联网连接。它包括了强大的可靠性和安全性特性，包括有序的数据传输、错误校验和流控制，以实现可靠的数据传输。
DTLS（Datagram Transport Layer Security）：DTLS是TLS（Transport Layer Security）的UDP版本，用于在不可靠的UDP上实现加密和可靠性传输。DTLS提供了TLS的安全性，同时通过序列号和重传来实现可靠性传输。
SCTP（Stream Control Transmission Protocol）：SCTP是一种面向消息的传输协议，可以在UDP上实现。它提供了可靠的、有序的数据传输，以及流控制和错误检测机制。
WebSocket over UDP：WebSocket是一种协议，它通常在TCP上运行，但也可以在UDP上实现。通过使用序列号和确认消息，WebSocket over UDP可以实现可靠性的数据传输。

注意：
尽管这些协议和技术可以在UDP上实现可靠性数据传输，但它们通常会增加一些开销和复杂性，以确保数据的完整性和顺序性。选择合适的协议和技术取决于应用的具体需求和性能要求。在设计和实现时，应仔细考虑网络条件、应用场景和可靠性需求。

6.7 UDP包接收的时序不一致怎么解决

当使用UDP进行数据传输时，数据包的时序可能会不一致，也就是说，数据包的顺序可能不同于它们发送的顺序。这种不一致通常是由于网络中的不同路径、拥塞或丢包等因素引起的。

要解决UDP包接收的时序不一致问题，可以考虑以下几种方法：

数据包排序：在接收端，可以维护一个缓冲区，并根据数据包的序列号（可以在数据包中添加）对数据包进行排序。通过按照序列号排序，可以确保数据包按照正确的顺序被处理。如果有数据包丢失，可以等待一段时间来等待它的重传，以确保数据包的完整性和顺序性。
时间戳：数据包可以包含时间戳信息，接收端可以根据时间戳来确定数据包的到达顺序。请注意，这种方法可能会受到时钟不同步的影响，因此需要小心处理。
缓冲和重传：在接收端，可以使用缓冲区来存储乱序的数据包，然后等待缺失的数据包到达或超时后进行重传。这可以确保数据包的顺序性。
应用层协议：可以在应用层协议中定义自己的机制来处理乱序的数据包。例如，如果正在实现自定义的实时传输协议，可以在应用层定义数据包的顺序和处理方式。
保留有限历史：在接收端，可以保留有限历史数据包，以便重新排序或处理乱序的数据包。一旦数据包到达，它可以与已缓存的数据包进行比较，以确定正确的顺序。

注意：
解决UDP包接收的时序不一致问题通常需要根据具体的应用需求来设计和实现，因为不同的应用可能有不同的容忍度和处理方式。在设计解决方案时，还需要考虑网络延迟、丢包率以及应用的实时性等因素。

7 网络七层协议

参考1：网络七层协议

记忆口诀：
物联（链）网传话，表示应用（七层）

计算机网络通常使用OSI（Open Systems Interconnection）模型或七层模型来描述不同层次的通信协议和功能。这个模型将网络通信分为七个层次，每个层次执行特定的任务，以便实现数据的传输和交换。以下是七层模型中的每个层次及其主要功能：

物理层（Physical Layer）

功能：物理层处理底层硬件传输，如电缆、光纤、物理接口和信号传输。
主要任务：数据位的传输和接收，物理介质的选择和控制，信号编码和调制。

数据链路层（Data Link Layer）

功能：数据链路层负责数据帧的传输和物理层之间的通信。
主要任务：帧的创建、帧的传输和接收、物理地址（MAC地址）的管理、错误检测和校正。

网络层（Network Layer）

功能：网络层负责数据包的路由和转发，实现不同子网之间的通信。
主要任务：IP地址分配、路由表的构建、数据包的寻址和路由选择。

传输层（Transport Layer）

功能：传输层提供端到端的通信，确保数据可靠性、流控制和差错恢复。
主要任务：端口号分配、数据分段、错误检测和重传、流控制。

会话层（Session Layer）

功能：会话层建立、管理和终止通信会话，处理会话中的同步和控制。
主要任务：会话建立和维护、对话同步和恢复。

表示层（Presentation Layer）

功能：表示层处理数据的格式和编码，确保不同设备之间的数据兼容性。
主要任务：数据加密和解密、数据压缩和解压、数据格式转换。

应用层（Application Layer）

功能：应用层是用户和应用程序之间的接口，负责应用程序的通信和交互。
主要任务：提供应用层协议、用户界面、应用程序和服务的交互。

注意：
七层模型是一个理论上的概念，实际上的网络通信通常使用TCP/IP协议栈，它将七层模型的一些层次合并在一起。TCP/IP协议栈包括四个主要层次：网络接口层（对应物理层和数据链路层）、网络层、传输层和应用层，其中的功能和任务与七层模型中的对应层次有些差异。不过，七层模型仍然是一种有用的理论框架，用于理解和描述不同层次的通信协议和功能。

7.1 TCP、UDP是在哪一层

TCP（Transmission Control Protocol）和UDP（User Datagram Protocol）是在网络协议模型中的传输层协议。传输层是计算机网络七层模型中的第四层，负责在通信实体之间提供端到端的数据传输、流控制、差错检测和重传等功能。TCP和UDP是两种常见的传输层协议，它们用于实现不同类型的数据传输服务。

具体来说：

TCP提供可靠的、面向连接的通信，确保数据的完整性和可靠性。它使用握手、确认、序列号和重传等机制来保证数据的可靠传输。
UDP提供不可靠的、面向无连接的通信，适用于需要低延迟和高吞吐量的应用。UDP不提供数据重传和流控制，因此在数据传输时速度较快，但可能会导致数据丢失或乱序。

这两种协议在传输层负责数据的可靠传输，但它们具有不同的特性，适用于不同的应用场景。

7.2 HTTP、SSH是在哪一层

HTTP（Hypertext Transfer Protocol）和SSH（Secure Shell）是在计算机网络协议模型中的不同层次：

HTTP：HTTP位于计算机网络协议模型中的应用层。它是用于在Web浏览器和Web服务器之间传输超文本文档和其他资源的协议。HTTP用于获取网页、发送表单数据、上传文件等，通常运行在TCP之上。
SSH：SSH位于计算机网络协议模型中的应用层，但它还涉及传输层的一些功能。SSH是用于安全远程访问和数据传输的协议，它提供了对终端会话和文件传输的加密和认证支持。SSH通常运行在TCP之上，并通过密码、公钥、私钥等方式进行身份验证和安全通信。

虽然HTTP和SSH都在应用层中操作，但它们有不同的目的和功能。HTTP用于传输Web内容，而SSH用于加密和安全的远程访问和文件传输。因此，它们在网络协议模型中虽然位于同一层次，但服务的性质和用途不同。

7.3 网络交换机位于网络的哪一层

网络交换机通常位于网络七层协议模型中的第二层，即数据链路层（Data Link Layer）。数据链路层主要负责物理介质的访问、数据的帧化和以太网等数据链路相关的功能。

交换机在这一层上通过物理地址（MAC地址）来决定将数据帧转发到哪个端口，以实现局域网内设备之间的通信。这与路由器位于网络七层模型中的第三层（网络层）的工作方式有所不同，路由器则更多地关注IP地址和路由表，用于实现跨网络的数据传输。

7.4 在浏览器输入一个百度地址后，它这个协议是怎么流转的？发了一个请求出来，然后它整个这个用户的这个发请求的行为到搜索端整个这个过程，它的协议是怎么流转的？能简单描述一下这个过程吗？

整理后：在浏览器上输入一个网址后，从请求发送到结果返回整个过程，它的协议是怎么流转的？

从在浏览器中输入一个网址到最终获得网页内容的过程涉及多个协议和步骤，通常涉及以下几个关键阶段：

DNS解析（Domain Name System）：当在浏览器中输入网址时，浏览器首先需要将域名解析为IP地址，以确定要访问的服务器的位置。浏览器会向本地DNS服务器发送DNS查询请求，如果本地DNS服务器没有缓存该域名的IP地址，则会递归地查询根域名服务器、顶级域名服务器和权威域名服务器，最终获取到目标服务器的IP地址。
建立TCP连接（Transmission Control Protocol）：一旦浏览器知道了目标服务器的IP地址，它将尝试建立到该服务器的TCP连接。这个过程通常涉及三次握手，其中浏览器和服务器之间互相确认并建立连接。
发起HTTP请求：一旦TCP连接建立，浏览器将发送一个HTTP请求到服务器，该请求中包含了要获取的资源的详细信息，例如请求的页面、文件、图像等。
服务器处理请求：服务器收到HTTP请求后，会根据请求中的信息，定位到相应的资源，然后进行处理。这可能涉及到在服务器上执行动态生成内容的脚本、查询数据库或其他操作。
服务器响应：服务器处理完成后，将生成一个HTTP响应，其中包含了所请求资源的数据，以及响应的元数据，例如响应状态码、头部信息等。
数据传输：一旦服务器生成响应，它将通过已建立的TCP连接将数据传输回浏览器。这是通过将数据分成小块（数据包）并通过互联网传输的方式完成的。
浏览器渲染：一旦浏览器接收到响应数据，它将解析HTML、CSS和JavaScript等内容，并将页面渲染在浏览器窗口中。这包括将HTML解析为DOM（文档对象模型）树、加载并应用CSS样式，执行JavaScript代码等操作。
呈现页面：最终，浏览器将呈现完整的页面，包括文本、图像、链接、表单和其他元素。用户可以与页面进行交互，点击链接、填写表单等操作。

在整个过程中，HTTP（Hypertext Transfer Protocol）是主要的应用层协议，用于定义浏览器和服务器之间的通信方式。HTTP负责在请求和响应之间传递数据，以及定义请求的方法（例如GET、POST）、状态码（例如200 OK、404 Not Found）等信息。

总结：
这个过程涉及多个协议和步骤，从DNS解析到数据传输和页面呈现，都需要按照一定的规范和协议来完成。这使得浏览器能够在用户输入网址后获取并显示网页内容。

7.5 计算机网络四层模型和七层模型有什么区别？

OSI模型更详细，分为七层，而TCP/IP模型更简洁，只有四层。
OSI模型中有更多的抽象层，以更准确地描述不同的网络功能。
TCP/IP模型是实际应用更广泛的模型，因为它是互联网协议的基础。
OSI模型是一种理论上的模型，而TCP/IP模型更加贴近实际的网络实施和运营。

7.6 TCP四层模型是哪四层？

TCP/IP四层模型：

网络接口层（Network Interface Layer）：对应于OSI模型的物理层和数据链路层，处理物理介质和数据链路的细节。
网际层（Internet Layer）：对应于OSI模型的网络层，负责路由和寻址，实现数据包的传输。
传输层（Transport Layer）：对应于OSI模型的传输层，提供端到端的数据传输和错误检测。
应用层（Application Layer）：对应于OSI模型的会话、表示和应用层，提供网络应用和服务。

8 DNS是基于哪个协议的

DNS（Domain Name System，域名系统）是基于两种主要的传输层协议之一进行通信的，这两种协议分别是：

UDP（User Datagram Protocol）：DNS通常使用UDP来进行域名解析查询。UDP是一种无连接的、不可靠的传输协议，适用于对数据传输速度和低延迟要求较高的应用场景。DNS查询通常比较小且需要快速响应，因此使用UDP作为传输协议是合适的。
TCP（Transmission Control Protocol）：尽管DNS主要使用UDP，但在某些情况下，例如对于较大的DNS响应或DNS区域传输（Zone Transfer）等，DNS服务器和客户端可以选择使用TCP来进行通信。TCP是一种可靠的传输协议，适用于需要数据可靠性和完整性的情况。

总结：
DNS主要使用UDP来进行域名解析查询，但也可以选择使用TCP来处理特定的情况。这种灵活性允许DNS在不同的应用场景中进行通信，以满足不同的需求。

9 MQTT协议

MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是一种轻量级的、基于发布/订阅模式的通信协议，用于传输低带宽、高延迟或不可靠网络环境下的消息数据。MQTT最初由IBM开发，并成为OASIS标准。

MQTT协议的一些重要特点和概念：

发布/订阅模式：MQTT采用发布/订阅模式，其中客户端可以订阅一个或多个主题（Topic），并且发布者将消息发布到特定主题。订阅了相同主题的客户端将接收到发布到该主题的消息。
主题（Topic）：主题是消息的逻辑通道，用于标识消息的内容。客户端可以订阅特定主题，以接收与该主题相关的消息。主题通常是一个字符串，可以是层次结构化的，例如"home/living-room/temperature"。
QoS（Quality of Service）：MQTT支持不同的QoS级别，用于控制消息传输的可靠性和交付保证。有三个QoS级别可供选择：0（最多一次交付，不可靠）、1（至少一次交付，可靠但可能会有重复）、2（只有一次交付，最可靠但开销较大）。
保留消息：MQTT支持保留消息，允许发布者发布一个主题的消息并将其保留，以便新的订阅者可以立即接收到最新的消息。
遗嘱消息（Last Will and Testament）：客户端可以设置一个遗嘱消息，以指定在客户端异常断开连接时，将自动发布的消息。
保持活动连接：MQTT客户端通常保持活动连接到MQTT代理（服务器），这有助于减少连接建立和断开的开销，同时提供实时消息传输能力。
适用于受限环境：MQTT设计用于受限的网络环境，如低带宽、高延迟或不稳定的网络连接。它具有较小的头部开销，并且支持保持连接和最小化数据传输的机制。
多平台支持：MQTT协议在多个平台和编程语言中都有广泛的实现和支持，使得不同设备和系统可以轻松地进行MQTT通信。

MQTT通常用于物联网（IoT）应用，传感器网络，远程监控和控制系统等需要在低带宽和高延迟环境中传输数据的场景。由于其轻量级和可靠性，它成为了一种流行的通信协议，用于连接和管理大量的设备和传感器。

9.1 MQTT的应用场景

物联网（IoT）：MQTT是物联网领域最常用的通信协议之一。它可以用于连接和管理大量的传感器、设备和物联网节点。MQTT的轻量级特性使其适用于资源有限的嵌入式设备，而其发布/订阅模式允许设备之间灵活地交换信息。
远程监控和控制：MQTT用于实时监控和控制应用，如监控设备状态、远程控制智能家居设备、远程机器控制等。通过MQTT，用户可以远程监视设备并发送指令，以实现实时响应。
传感器网络：MQTT可用于传感器网络，用于将传感器数据传输到中央数据存储或监控系统。传感器可以定期发布数据到MQTT主题，而订阅者可以实时接收并处理这些数据。
智能城市：MQTT可用于构建智能城市系统，监控交通、环境、能源等信息。它可以用于交通信号控制、垃圾桶状态监测、能源消耗监测等应用。
远程日志和故障排查：MQTT可以用于设备或应用程序的远程日志记录和故障排查。设备可以将日志数据发布到MQTT主题，以便运维人员或开发人员远程监视和分析问题。
智能农业：在农业领域，MQTT可用于监控农田中的传感器数据，例如土壤湿度、气温、光照等，以帮助农民优化农业操作。
航空航天：MQTT在航空航天领域用于飞行器、卫星和地面控制中心之间的通信，以传输实时数据和控制指令。
实时消息传递：MQTT可以用于实时消息传递应用，如即时通讯、实时位置共享和多人游戏，以提供快速的消息传递服务。

注意：
MQTT的轻量级特性和可靠性使其在各种应用场景中得到广泛应用。它提供了一种高效、可扩展和可靠的方式来连接和管理设备、传感器和应用程序，并在受限的网络条件下传输消息。因此，MQTT已经成为物联网和实时通信领域的核心通信协议之一。

10 Modbus通信协议

参考1：详解Modbus通信协议

Modbus是一种常见的通信协议，用于在自动化和控制系统中传输数据。该协议最初由Modicon（现在是施耐德电气）开发，并在1980年代广泛推广和采用。Modbus协议具有简单、轻量级和可靠的特性，适用于工业自动化、仪表控制和数据采集等领域。以下是Modbus通信协议的一些关键特点：

通信类型：Modbus支持多种通信类型，包括串行通信（如RS-232、RS-485）和以太网通信（Modbus TCP/IP）。这使得它适用于不同的物理介质和网络环境。
通信模式：Modbus支持主从模式的通信。在Modbus通信中，一个主站（通常是一个控制系统或计算机）可以与多个从站（通常是设备、传感器或仪表）进行通信。主站负责发出请求，而从站负责响应请求。
数据传输：Modbus协议可以用于读取和写入数据，包括读取寄存器、写入寄存器、读取输入状态、写入线圈等操作。这些操作允许控制系统与各种设备进行数据交换和控制。
数据格式：Modbus数据通常以16位或32位的寄存器方式组织，数据可以是整数、浮点数、布尔值等不同类型。通常，Modbus使用大端字节序（Big-Endian）来表示数据。
寄存器地址：Modbus通信中，每个数据点都有一个唯一的寄存器地址，用于标识该数据点。主站使用这些地址来指定要读取或写入的数据点。
异常处理：Modbus协议定义了一些异常代码，用于处理错误情况。如果从站无法满足请求，它可以返回异常响应。
多个变种：Modbus协议有多个变种，包括Modbus RTU（二进制传输）、Modbus ASCII（ASCII字符传输）和Modbus TCP/IP（以太网传输）。每个变种有不同的物理层和传输特性，可以根据需求选择。
广泛应用：Modbus协议在工业自动化、楼宇自动化、能源管理、电力系统监测、制造业等多个领域中得到广泛应用。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
。

10 Modbus通信协议

参考1：详解Modbus通信协议

通信类型：Modbus支持多种通信类型，包括串行通信（如RS-232、RS-485）和以太网通信（Modbus TCP/IP）。这使得它适用于不同的物理介质和网络环境。
通信模式：Modbus支持主从模式的通信。在Modbus通信中，一个主站（通常是一个控制系统或计算机）可以与多个从站（通常是设备、传感器或仪表）进行通信。主站负责发出请求，而从站负责响应请求。
数据传输：Modbus协议可以用于读取和写入数据，包括读取寄存器、写入寄存器、读取输入状态、写入线圈等操作。这些操作允许控制系统与各种设备进行数据交换和控制。
数据格式：Modbus数据通常以16位或32位的寄存器方式组织，数据可以是整数、浮点数、布尔值等不同类型。通常，Modbus使用大端字节序（Big-Endian）来表示数据。
寄存器地址：Modbus通信中，每个数据点都有一个唯一的寄存器地址，用于标识该数据点。主站使用这些地址来指定要读取或写入的数据点。
异常处理：Modbus协议定义了一些异常代码，用于处理错误情况。如果从站无法满足请求，它可以返回异常响应。
多个变种：Modbus协议有多个变种，包括Modbus RTU（二进制传输）、Modbus ASCII（ASCII字符传输）和Modbus TCP/IP（以太网传输）。每个变种有不同的物理层和传输特性，可以根据需求选择。
广泛应用：Modbus协议在工业自动化、楼宇自动化、能源管理、电力系统监测、制造业等多个领域中得到广泛应用。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Go）
[外链图片转存中…(img-8yFs006P-1713594839795)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

2401_84254177

关注

9
点赞
踩
13

收藏

觉得还不错? 一键收藏
0
评论
网络协议相关面试题及解答_网络协议面试，2024年最新某大厂开发者对于Golang多线程的总结

HTTPS使用一种称为消息摘要算法（）的算法来确保数据的完整性。具体来说，HTTPS通常使用SHA-256（Secure Hash Algorithm 256位）或其他类似的消息摘要算法。在HTTPS安全通信中，数字签名和消息摘要使用了以下几种算法：MD5是一个128位长度的消息摘要算法，用于产生数据的数字签名，校验数据完整性。但MD5已被证实存在弱点，可以被碰撞攻击。SHA-1是160位长度输出的密码HASH算法，相比MD5更加安全可靠，但理论上也可能受到碰撞攻击。SHA-2SHA-2代表了一系列。
复制链接

扫一扫