计网

1.TCP/IP OSI网络模型 +2

TCP/IP四层协议（应用层、传输层、网络层、数据链路层）

OSI （应用层表示层会话层 / 传输层 /网络层 /数据链路层物理层)

HTTP

√1.从输入URL 到页面展示到底发生了什么？

浏览器解析URL，生成HTTP请求报文
通过DNS服务获得服务器域名对应的IP地址
TCP 连接
发送 HTTP / HTTPS 请求（建立 TLS 连接）
服务器处理请求并返回 HTTP 报文
浏览器解析渲染页面
连接结束

√2.HTTP 状态码有哪些？ +2

1xx Informational（信息性状态码）

2xx Success（成功状态码）

200 OK ：请求被成功处理。比如我们发送一个查询用户数据的HTTP 请求到服务端，服务端正确返回了用户数据。这个是我们平时最常见的一个 HTTP 状态码。
201 Created ：请求被成功处理并且在服务端创建了一个新的资源。比如我们通过 POST 请求创建一个新的用户。
202 Accepted ：服务端已经接收到了请求，但是还未处理。
204 No Content ：服务端已经成功处理了请求，但是没有返回任何内容。

3xx Redirection（重定向状态码）

301 Moved Permanently ：资源被永久重定向了。比如你的网站的网址更换了。
302 Found ：资源被临时重定向了。比如你的网站的某些资源被暂时转移到另外一个网址。

4xx Client Error（客户端错误状态码）

400 Bad Request ：发送的HTTP请求存在问题。比如请求参数不合法、请求方法错误。
401 Unauthorized ：未认证却请求需要认证之后才能访问的资源。
403 Forbidden ：直接拒绝HTTP请求，不处理。一般用来针对非法请求。
404 Not Found ：你请求的资源未在服务端找到。比如你请求某个用户的信息，服务端并没有找到指定的用户。
409 Conflict ：表示请求的资源与服务端当前的状态存在冲突，请求无法被处理。

5xx Server Error（服务端错误状态码）

500 Internal Server Error ：服务端出问题了（通常是服务端出Bug了）。比如你服务端处理请求的时候突然抛出异常，但是异常并未在服务端被正确处理。
502 Bad Gateway ：我们的网关将请求转发到服务端，但是服务端返回的却是一个错误的响应。

√3.HTTP 和 HTTPS 有什么区别？（重要） +2

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

√https安全性如何实现？ +2

混合加密（对称+非对称）方式实现信息的机密性，解决了窃听的风险。
1. 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
2. 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
HTTPS使用数字签名技术来防止数据被篡改。在传输数据时，服务端会对数据进行数字签名，客户端收到数据后会进行验证，确保数据未被篡改。
将服务器公钥放入到数字证书中，解决了冒充的风险。

√ssl/tls协议怎么实现加密的？

客户端向服务器索要并验证服务器的公钥。
双方协商生产「会话秘钥」。
双方采用「会话秘钥」进行加密通信。

非对称加密有两个秘钥

公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

（chatGPT）证书信任链，CA了解吗

证书信任链是指用于验证数字证书有效性的一组数字证书链。数字证书用于加密和保护网络通信，同时确保通信的安全性和可靠性。在数字证书中，数字签名由证书颁发者（CA）签署，证书链连接着服务器证书和根证书，从而形成证书信任链。

证书颁发机构（CA）是一个可信的第三方实体，它负责签署和颁发证书，以验证证书的真实性和有效性。每个 CA 都有自己的证书链，证书链的顶部是一个根证书，用于验证服务器证书是否可信。如果根证书无效或被篡改，则会影响证书链中的所有其他证书的有效性。

√HTTP 1.0 和 HTTP 1.1 有什么区别？

连接方式 : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
状态响应码 : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。
缓存处理 : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用 :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
Host头处理 : HTTP/1.1在请求头中加入了Host字段。

√HTTP长短连接和TCP keep-alive选项。

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用层」(用户态）实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「传输层」（内核态）实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接。

（chat）GET请求和POST请求有哪些区别？对于大数据量的请求使用哪种更好？

对于大数据量的请求，一般建议使用POST请求，因为POST请求可以传输更大的数据量，并且POST请求的请求参数对于其他人不可见，更加安全。但是需要注意的是，如果POST请求的数据量过大，可能会导致服务器端的负担过重，因此需要根据具体情况进行调整。

√GET/ POST 有什么区别 +2

根据 RFC 规范，GET 的语义是从服务器获取指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。

根据 RFC 规范，POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。

√GET 不安全的 POST是不安全的，这种说法对吗？

GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。

POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。
可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

RESTful风格的理解: 资源操作, 提了一嘴路由的设计

RESTful风格的主要理解如下：

资源定位：RESTful Web服务使用URI（Uniform Resource Identifier）来唯一定位资源，每个资源都有一个唯一的URI，通过URI可以访问和操作资源。
使用HTTP方法：RESTful Web服务使用HTTP协议中的方法来表示对资源的操作，常用的HTTP方法包括GET、POST、PUT、DELETE等。
状态无关性：RESTful Web服务是一种无状态协议，即服务端不需要保存客户端的状态信息，每个请求都是独立的。
数据格式：RESTful Web服务使用XML或JSON格式来表示数据，可以使用HTTP的Content-Type头来指定数据格式。
缓存：RESTful Web服务支持HTTP协议中的缓存机制，可以提高性能和可伸缩性。
可扩展性：RESTful Web服务是一种轻量级、可扩展的架构，可以通过定义新的资源和HTTP方法来扩展API。

综上所述，RESTful Web服务是一种基于HTTP协议的轻量级、简单、可伸缩、可扩展和可维护的API设计风格。它采用URI定位资源，使用HTTP方法表示操作，使用HTTP状态码表示结果，使用XML或JSON格式表示数据，遵循状态无关性和缓存机制等原则，具有广泛的应用价值

Http的请求方式有哪些？

HTTP8个请求模式: +2

HTTP/1.1协议中共定义了八种方法，来表明Request-URL指定的资源不同的操作方式其中： HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

GET：请求指定的页面信息，并返回实体主体。
HEAD：类似于 GET 请求，但没有响应体，用于获取报头。
POST：向指定资源提交数据进行处理请求（例如提交表单或上传文件），数据被包含在请求体中。
PUT：将请求的主体部分存储在服务器上取代指定的资源的内容。
DELETE：请求服务器删除指定的页面。
CONNECT：用来建立到给定URI标识的服务器的隧道
OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向web服务器发送 ‘*’ 的请求来测试服务器的性能。
TRACE：回应服务器收到的请求，主要用于测试或诊断。

用RESTful风格设计一个user接口应该怎么设计:

对于上述URI，对应的HTTP请求方法和对资源的操作如下：

1. GET /users: 获取用户列表

该请求用于获取所有用户的列表。服务器返回一个包含所有用户信息的JSON数组。

2. POST /users: 创建新用户

该请求用于在服务器上创建一个新用户。请求中需要包含用户信息，服务器创建成功后返回HTTP状态码201和新创建用户的URI。

3. GET /users/:id: 获取指定id的用户

该请求用于获取指定id的用户信息。服务器返回一个包含该用户信息的JSON对象。

4. PUT /users/:id: 更新指定id的用户

该请求用于更新指定id的用户信息。请求中需要包含更新后的用户信息，服务器返回HTTP状态码204。

5. DELETE /users/:id: 删除指定id的用户

该请求用于删除指定id的用户。服务器返回HTTP状态码204。

（chat）cookie和session的区别 +2

Cookie和Session都是用来在Web应用程序中维护状态信息的机制，但它们有以下区别：

1.存储位置不同

Cookie保存在客户端浏览器上，Session保存在服务器端。

2.存储容量不同

Cookie的存储容量通常为4KB左右，而Session的存储容量可以很大，通常受到服务器内存和硬盘容量的限制。

3.存储时间不同

Cookie的存储时间可以设置，可以长时间存在客户端，即使关闭了浏览器也能够保持；Session的存储时间通常为用户打开浏览器到关闭浏览器之间的时间段，一旦关闭浏览器就会失效。

4.安全性不同

Cookie容易被窃取和篡改，而Session保存在服务器端，相对较为安全。

5.作用范围不同

Cookie的作用范围是整个域名，不同路径下的页面都可以访问同一个Cookie；Session的作用范围是当前用户与服务器之间的交互，只有在同一会话期间内的页面才能访问同一个Session。

HTTP请求结构

一个HTTP请求（Request）由三部分组成：

请求行（Request Line）：包含请求方法（GET、POST等）、请求的URI（Uniform Resource Identifier，统一资源标识符）和HTTP协议版本号。
请求头部（Request Header）：包含请求的一些附加信息，如Accept、Host、User-Agent等。
请求主体（Request Body）：一些附加的、非必须的数据，如表单提交数据等。

一个完整的HTTP请求示例：

POST /api/user HTTP/1.1 

Host: example.com 
Content-Type: application/json 
Content-Length: 123 
Authorization: Bearer xxxxxx

{   
"name": "Alice",  
"age": 25,   
"email": "alice@example.com" 
}

上面的请求行表示使用POST方法请求example.com的/api/user资源，HTTP协议版本号为1.1。请求头部包含了Content-Type、Content-Length和Authorization等信息，请求主体是一个JSON格式的数据，表示要新增一个用户信息。

需要注意的是，请求主体并不是所有请求都需要的，GET请求通常不需要请求主体。而且，请求头部也不是所有请求都需要的，比如OPTIONS请求就没有请求主体和请求头部。

√TCP 三次握手 +3

一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态

第一次握手：客户端将SYN置1，随机产生一个初始序列号seq发送给服务端，进入SYN_SENT状态；
第二次握手：服务端收到客户端的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个「确认应答号」=序列号+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；
第三次握手：客户端检查「确认应答号」是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个「确认应答号」=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查「确认应答号」为序列号+1 和ACK为1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。

√建立连接可以两次握手吗？为什么? +3

因为可能会出现已失效的连接请求报文段又传到了服务器端。
> 客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。
而且，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

√可以采用四次握手吗？为什么？

这个肯定可以。三次握手都可以保证连接成功了，何况是四次，但是会降低传输的效率。

√四次挥手

第一次挥手：客户端打算关闭连接，发送FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
第二次挥手：服务端收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
第三次挥手：服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
第四次挥手：客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态。
客户端在经过 2MSL 的时间后，自动进入 CLOSE 状态

四次挥手分别丢失的后果

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

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

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

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

√客户端TIME_WAIT状态的意义是什么？为什么 TIME_WAIT 等待的时间是 2MSL？

第四次挥手时，客户端发送给服务端的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。

如果服务端没有收到ACK，就会重发FIN，如果客户端在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止服务端没有收到ACK而不断重发FIN。

MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，客户端都没有再次收到FIN，那么客户端推断ACK已经被成功接收，则结束TCP连接。

√为什么不是 4 或者 8 MSL 的时长呢？

可以看到 2MSL时长 这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对。

为什么不是 4 或者 8 MSL 的时长呢？你可以想象一个丢包率达到百分之一的糟糕网络，连续两次丢包的概率只有万分之一，这个概率实在是太小了，忽略它比解决它更具性价比。

如果大量TCP连接处于time_wait状态的影响，怎么处理？

调整TCP参数：可以通过调整系统的TCP参数来缓解 TIME_WAIT 状态的影响。比如可以通过减少 TIME_WAIT 状态的等待时间、增加端口重用次数等方式来减少 TIME_WAIT 状态的数量。
使用连接复用技术：可以使用连接复用技术来复用已经建立的 TCP 连接，减少新建连接的数量。常用的连接复用技术有 HTTP keep-alive、TCP keepalive 等。
使用连接池技术：对于需要频繁建立连接的应用，可以使用连接池技术来复用连接，避免频繁地创建和关闭连接，从而减少 TIME_WAIT 状态的数量。
调整应用程序设计：在设计应用程序时，可以尽量避免频繁地创建和关闭连接，尽量复用连接，从而减少 TIME_WAIT 状态的数量。
升级硬件资源：如果硬件资源不足，可能会导致 TIME_WAIT 状态的数量增加。在这种情况下，可以考虑升级硬件资源，以提高系统的性能。

综上所述，可以通过调整系统参数、使用连接复用技术、使用连接池技术、调整应用程序设计和升级硬件资源等方式来缓解大量 TCP 连接处于 TIME_WAIT 状态的影响。

√tcp首部字段有哪些

源端口（Source Port）：占用 2 字节，表示源端口号；
目的端口（Destination Port）：占用 2 字节，表示目的端口号；
序列号（Sequence Number）：占用 4 字节，表示报文段中第一个字节的序列号；
确认号（Acknowledgment Number）：占用 4 字节，只有 ACK 标志位为 1 时才有效，表示接收到的序列号为 ack_num -1 的数据；
首部长度（Header Length）：占用 4 比特，表示首部长度，用于指示接收端首部的长度，以便在紧接着首部后的数据中定位有效数据的起始位置；
保留（Reserved）：占用 3 比特，保留为今后使用，目前必须设置为 0；
标志位（Flags）：占用 9 比特，包含以下 9 个标志位：URG（Urgent）：紧急指针（urgent pointer）是否有效；ACK（Acknowledgement）：确认序号是否有效；PSH（Push）：是否尽快将数据推送给应用层；RST（Reset）：重置连接；SYN（Synchronize）：同步序号，用于建立连接；FIN（Finish）：结束连接；Reserved（Reserved）：保留；NS（Nonce Sum）：ECN 的 nonce 信息；
窗口大小（Window Size）：占用 2 字节，表示接收端可以接收的数据量；
校验和（Checksum）：占用 2 字节，用于检测首部和数据的传输是否有误；
紧急指针（Urgent Pointer）：占用 2 字节，只有 URG 标志位为 1 时才有效，表示紧急数据的位置；
选项（Options）：可选，占用 0 到 40 字节，用于在首部中添加一些选项信息。

√TCP和UDP区别 +4

1. 连接

TCP 是面向连接的传输层协议，传输数据前先要建立连接,一对一的两点服务
UDP 是不需要连接，即刻传输数据,一对一、一对多、多对多

2. 可靠性

TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按序到达。
UDP 是尽最大努力交付，不保证可靠交付数据。但是我们可以基于 UDP 传输协议实现一个可靠的传输协议，比如 QUIC 协议，具体可以参见这篇文章：

3. 拥塞控制、流量控制

TCP 有拥塞控制和流量控制机制，可以根据网络状况调整数据传输的速度，避免网络拥塞
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。

4. 首部开销

TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。

5. 传输方式

TCP 是流式传输，没有边界，但保证顺序和可靠。
UDP 是一个包一个包的发送，是有边界的，但可能会丢包和乱序。

6. 分片不同

TCP 的数据大小如果大于 MSS 大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装 TCP 数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
UDP 的数据大小如果大于 MTU 大小，则会在 IP 层进行分片，目标主机收到后，在 IP 层组装完数据，接着再传给传输层。

MTU：maximum transmission unit，最大传输单元，由硬件规定，如以太网的MTU为1500字节。

MSS：maximum segment size，最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到。

√应用场景

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

√HTTP 基于 TCP 还是 UDP？

HTTP 3.0 之前是基于 TCP 协议的，而 HTTP3.0 将弃用 TCP，改用基于 UDP 的 QUIC 协议。此变化主要为了解决 HTTP/2 中存在的队头阻塞问题。由于 HTTP/2 在单个 TCP 连接上使用了多路复用，受到 TCP 拥塞控制的影响，少量的丢包就可能导致整个 TCP 连接上的所有流被阻塞。

(OpenAI)多个容器之间以及容器和外部怎么通过网络通信？

容器间通信：使用 Docker 的默认网络模式，Docker 会为每个容器创建一个虚拟网桥，容器之间可以使用容器名称或 IP 地址相互访问。例如，一个容器可以通过 "ping another_container" 的方式来访问另一个容器。如果需要将容器暴露给外部网络，则可以使用 Docker 的端口映射功能。
容器间通信：使用自定义网络模式，可以创建一个自定义的 Docker 网络，让多个容器加入到同一个网络中。这样，这些容器就可以通过容器名称或 IP 地址相互访问。自定义网络模式还支持容器间的服务发现和负载均衡。
容器和外部网络通信：使用 Docker 端口映射功能，将容器内部的端口映射到宿主机上的一个端口。这样，外部网络就可以通过宿主机的 IP 地址和映射的端口来访问容器内部的服务。
容器和外部网络通信：使用 Docker 的主机网络模式，容器直接使用宿主机的网络，容器内部的服务可以直接通过宿主机的 IP 地址访问。这种方式的缺点是，容器和宿主机共享同一个网络命名空间，可能会有安全风险。

总的来说，Docker 提供了多种网络通信方式，可以根据具体的应用场景选择适合的方式来进行容器间和容器与外部的网络通信。

TCP和IP协议的作用

TCP（传输控制协议）和IP（网络协议）是互联网协议栈中的两个基本协议，各自具有不同的作用。

TCP（传输控制协议）：TCP 是一种面向连接的、可靠的传输层协议，负责数据的可靠传输。TCP 协议通过序列号、确认号、滑动窗口、重传、拥塞控制等机制来保证数据传输的可靠性和有序性。TCP 还提供流量控制、拥塞控制等机制，以避免网络拥塞和资源浪费。
IP（网络协议）：IP 是一种无连接的、不可靠的网络层协议，负责数据包的传输。IP 协议通过数据包的源地址和目标地址来寻找数据包的下一跳路由器，并将数据包传递给下一跳路由器。IP 协议不保证数据包的可靠传输，而是提供了最好的传输努力服务，即尽可能将数据包传输到目标地址，如果数据包在传输过程中发生错误或丢失，IP 协议不会对其进行重传或其他处理。

综上所述，TCP 协议和 IP 协议在互联网协议栈中分别负责不同的任务，TCP 协议保证数据传输的可靠性和有序性，IP 协议负责数据包的传输并尽可能将其传输到目标地址。TCP 协议和 IP 协议配合使用，实现了互联网上数据的可靠传输和路由分发。

对于TCP和UDP来说，说一下对于“网络通信不可靠”这句话的理解

“网络通信不可靠”是指在数据传输过程中，由于网络环境的复杂性、传输过程中的错误等原因，可能会导致数据包的丢失、重复、延迟、乱序等问题。TCP 和 UDP 在面对网络通信不可靠的问题时表现不同：

TCP 是一种面向连接的可靠传输协议，会对数据进行分段、排序、校验等操作，以保证数据的可靠性。当数据包在传输过程中发生错误或丢失时，TCP 会通过重传、拥塞控制等机制来保证数据传输的可靠性。因此，TCP 可以在不可靠的网络环境中确保数据的可靠传输，但是会带来一定的性能损失和延迟。
UDP 是一种面向无连接的不可靠传输协议，不会对数据进行排序、校验等操作，也不提供重传和拥塞控制等机制。因此，UDP 传输数据时速度快、开销小，但是在不可靠的网络环境中容易出现数据丢失、重复、延迟、乱序等问题。

综上所述，“网络通信不可靠”意味着数据传输过程中可能会出现各种问题，这需要协议本身具有一定的容错能力。TCP 和 UDP 在面对这种情况时采取不同的方式来处理，用户应该根据具体的应用场景选择适合的传输协议。

TCP的半连接了解吗？半连接攻击怎么防护？

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

半连接队列，也称 SYN 队列；
全连接队列，也称 accept 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

半连接攻击是指攻击者通过发送大量的SYN包来占用服务器资源，导致服务器无法处理正常请求，从而造成拒绝服务的攻击行为。防范半连接攻击的方法主要有以下几种：

增加服务器资源：增加服务器资源可以提高服务器的处理能力，从而减少半连接攻击对服务器的影响。
加强防火墙的设置：设置防火墙对SYN包进行限制或过滤，例如设置SYN Cookie技术、TCP Wrapper技术等。
调整操作系统参数：调整操作系统的参数可以减少服务器受到半连接攻击的风险，例如调整服务器的最大连接数、超时时间等参数。
使用专业的防御系统：使用专业的防御系统可以有效地防范半连接攻击，例如使用防火墙、入侵检测系统等。
合理使用CDN等缓存技术：使用CDN等缓存技术可以将流量分散到不同的服务器上，从而分散半连接攻击的影响。

TCP 如何保证传输的可靠性？

基于数据块传输 ：应用数据被分割成 TCP 认为最适合发送的数据块，再传输给网络层，数据块被称为报文段或段。
对失序数据包重新排序以及去重：TCP 为了保证不发生丢包，就给每个包一个序列号，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据就可以实现数据包去重。
校验和 : TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
超时重传 : 当发送方发送数据之后，它启动一个定时器，等待目的端确认收到这个报文段。接收端实体对已成功收到的包发回一个相应的确认信息（ACK）。如果发送端实体在合理的往返时延（RTT）内未收到确认消息，那么对应的数据包就被假设为已丢失并进行重传。
流量控制 : TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议（TCP 利用滑动窗口实现流量控制）。
拥塞控制 : 当网络拥塞时，减少数据的发送。

TCP 重传

超时重传

就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据。超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。

快速重传

当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

滑动窗口、流量控制

TCP的流量控制是通过TCP协议头中的窗口字段来实现的。

窗口是操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答，而可以继续发送数据的最大值。

发送端和接收端各自维护一个滑动窗口，发送端每次发送数据时会根据接收端返回的窗口大小调整自己的发送窗口，从而达到流量控制的目的。

TCP 发送一个数据，如果需要收到确认应答，才会发送下一个数据，效率会比较低。

拥塞控制

前面的流量控制是避免「发送方」的数据填满「接收方」的缓存

当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

发送方要维持一个 拥塞窗口(cwnd) 的状态变量，大小取决于网络的拥塞程度，并且动态变化。

发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。

**慢开始：**cwnd 初始值为 1，每当收到一个 ACK ，cwnd 加倍。

拥塞避免： cwnd达到慢启动阀值 ssthresh（slow start threshold）后，每当收到一个 ACK 时，cwnd 增加 1

拥塞发生： 当网络出现拥塞，也就是会发生数据包重传

当发生了「超时重传」，则就会使用拥塞发生算法。

这个时候，ssthresh 和 cwnd 的值会发生变化：

ssthresh 设为 cwnd/2，
cwnd 重置为 1 （是恢复为 cwnd 初始化值，我这里假定 cwnd 初始化值 1）

拥塞发送 —— 超时重传

「快速重传算法」当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 ssthresh 和 cwnd 变化如下：

ssthresh = cwnd;
cwnd = cwnd/2 ，也就是设置为原来的一半;
进入快速恢复算法

快速恢复算法如下：

cwnd = sshthresh + 3
重传重复的那几个 ACK（即丢失的那几个数据包）
如果再收到重复的 ACK，那么 cwnd = cwnd +1
如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK，表明恢复过程已经结束，可以再次进入了拥塞避免的算法了。

TCP粘包，怎么解决

IP地址有哪几类

IP地址分为：IPv4 、IPv6， IPv4是用点分四组十进制的表示方法展示的

根据IP地址的分配方式和使用范围的不同，IP地址被分为以下5类：

A类地址：1.0.0.0 至 127.255.255.255，其中第一位固定为0，后面7位可用于网络地址，剩下的24位用于主机地址。
B类地址：128.0.0.0 至 191.255.255.255，其中第一位固定为10，后面14位用于网络地址，剩下的16位用于主机地址。
C类地址：192.0.0.0 至 223.255.255.255，其中前3位固定为110，后面21位用于网络地址，剩下的8位用于主机地址。
D类地址：224.0.0.0 至 239.255.255.255，用于多点广播地址。224-1110
E类地址：240.0.0.0 至 255.255.255.255，保留地址，暂时未被使用。 240-1111

其中A、B、C三类地址被广泛使用，用于分配给各个网络中的主机使用。

数据链路层

源MAC地址是什么，目的MAC地址是什么？怎么找到目的MAC地址（ARP协议）

MAC（Media Access Control Address 媒体访问控制）地址是用于网络设备之间唯一标识的硬件地址，用于在局域网中标识网络设备。源 MAC 地址是数据包的发送方的 MAC 地址，目的 MAC 地址是数据包的接收方的 MAC 地址。

ARP（地址解析协议）：ARP 协议用于解析目标设备的 IP 地址和 MAC 地址之间的映射关系。

主机会通过广播发送 ARP 请求，这个包中包含了想要知道的 MAC 地址的主机 IP 地址。
当同个链路中的所有设备收到 ARP 请求时，会去拆开 ARP 请求包里的内容，如果 ARP 请求包中的目标 IP 地址与自己的 IP 地址一致，那么这个设备就将自己的 MAC 地址塞入 ARP 响应包返回给主机。

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次直接从缓存中找到对应 IP 地址的 MAC 地址。

介绍一下socket网络编程+1

Socket网络编程是指使用Socket API进行网络通信的一种编程方式。Socket是一种抽象层，通过它我们可以使用TCP/IP协议进行网络通信。在Socket编程中，我们可以创建客户端和服务器端的Socket，然后在两者之间进行数据传输。

Socket编程需要以下步骤：

创建一个Socket对象，指定连接的IP地址和端口号。
通过Socket对象获得输入流和输出流，用于数据传输。
使用输出流向服务器端发送数据。
使用输入流从服务器端接收数据。
关闭输入流、输出流和Socket对象。

Socket编程的优点是灵活性强，可以自定义协议、自定义数据传输格式等，适用于各种场景。同时，由于使用了TCP/IP协议，传输数据稳定可靠。

但是Socket编程也有缺点，比如需要进行网络编程的各种细节处理，如数据分片、数据合并、数据传输错误处理等，这些需要开发者进行处理。同时，Socket编程在处理高并发、大流量场景下，需要处理并发请求的问题，需要进行多线程编程等。

11计网八股（自用）

计网