总结计算机网络相关面试点

1、OSI与TCP/IP各层的结构与功能，都有哪些协议?

OSI七层网络模型

TCP/IP四层网络模型

2、三次握手和四次挥手

2.1、三次握手

• 在初始时，客户端、服务端都处于CLOSED状态，客户端发起请求建立TCP连接，服务器端被动建立TCP连接，并进行监听，进入到LISTEN状态；
• 第一次握手：客户端发送，服务器接收。客户端Client将标志位SYN设置为1，并随机产生一个值seq=x，并将该数据包发送给服务器Server，Client进入SYN_SENT状态，等待服务器的确认；
• 第二次握手：服务器收到了客户端的请求，客户端接收到确认信息。服务器收到数据包后由标志位 SYN=1 知道客户端请求建立连接，Server将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值 seq=y，并将该数据包发送给Client以确认连接请求，Server进入 SYN_RCVD 状态。
• 第三次握手：客户端告知服务器它收到了你的确认消息，三次握手完毕。Client收到确认后，检查ack是否为x+1，ACK是否为1。如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给Server，Server检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。

TCP握手为什么是三次，不能是两次？不能是四次？

不能是两次？

如果是两次，少了最后一次的话，服务器端并不能确认客户端的接受是否正常（有没有接收到服务器端的回复信息）。

不能是四次？

因为三次已经够了，三次已经能确保双方的发送、接收正常，而四次就多余了。

三次握手的异常情况

问题1：第一次握手的「SYN」包丢了

如果客户端第一个「SYN」包丢了，也就是服务端根本就不知道客户端曾经发过包，那么处理流程主要在客户端。

而在 TCP 协议中，某端的一组「请求-应答」中，在一定时间范围内，只要没有收到应答的「ACK」包，无论是请求包对方没有收到，还是对方的应答包自己没有收到，均认为是丢包了，都会触发超时重传机制。

所以此时会进入重传「SYN」包。根据《TCP/IP详解卷Ⅰ：协议》中的描述，此时会尝试三次，间隔时间分别是 5.8s、24s、48s，三次时间大约是 76s 左右，而大多数伯克利系统将建立一个新连接的最长时间，限制为 75s。

也就是说三次握手第一个「SYN」包丢了，会重传，总的尝试时间是 75s

问题2：服务端收到「SYN」并回复的「SYN,ACK」包丢了

此时服务端已经收到了数据包并回复，如果这个回复的「SYN,ACK」包丢了，站在客户端的角度，会认为是最开始的那个「SYN」丢了，那么就继续重传，就是我们前面「问题1」 的流程。

而对服务端而言，如果发送的「SYN,ACK」包丢了，在超时时间内没有收到客户端发来的「ACK」包，也会触发重传，此时服务端处于 SYN_RCVD 状态，会依次等待 3s、6s、12s 后，重新发送「SYN,ACK」包。

而这个「SYN,ACK」包的重传次数，不同的操作系统下有不同的配置，例如在 Linux 下可以通过 tcp_synack_retries 进行配置，默认值为 5。如果这个重试次数内，仍未收到「ACK」应答包，那么服务端会自动关闭这个连接。

同时由于客户端在没有收到「SYN,ACK」时，也会进行重传，当客户端重传的「SYN」被收到后，服务端会立即重新发送「SYN,ACK」包。

问题3 ：第三次握手回复「SYN,ACK」的「ACK」包丢了

如果最后一个「ACK」包丢了，服务端因为收不到「ACK」会走重传机制，而客户端此时进入 ESTABLISHED 状态。

多数情况下，客户端进入 ESTABLISHED 状态后，则认为连接已建立，会立即发送数据。但是服务端因为没有收到最后一个「ACK」包，依然处于 SYN-RCVD 状态。

那么这里的关键，就在于服务端在处于 SYN-RCVD 状态下，收到客户端的数据包后如何处理?

当客户端在 ESTABLISHED 状态下，开始发送数据包时，会携带上一个「ACK」的确认序号，所以哪怕客户端响应的「ACK」包丢了，服务端在收到这个数据包时，能够通过包内 ACK 的确认序号，正常进入 ESTABLISHED 状态。

2.2、四次挥手

在socket编程中，四次挥手这一过程由客户端或服务端任一方执行close来触发，首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。下面以客户端主动断开连接为例：

• 客户端主动发起「FIN」请求准备断开连接，并设置FIN=1，并随机产生一个值seq=u。在发出「FIN」后，客户端进入 FIN-WAIT-1 状态；
• 服务端收到「FIN」消息后，回复「ACK」表示知道了，并从 ESTABLISHED 状态进入CLOSED-WAIT 状态，开始做一些断开连接前的准备工作；
• 客户端收到之前「FIN」的回复「ACK」消息后，进入FIN-WAIT-2 状态。而当服务端做好断开前的准备工作后，也会发送一个「FIN,ACK」的消息給客户端，表示我也好了，请求断开连接，并在发送消息后，服务端进入LAST-ACK 状态；
• 客户端在收到「FIN,ACK」消息后，会立即回复「ACK」，表示知道了，并进入TIME_WAIT 状态，为了稳定和安全考虑，客户端会在 TIME-WAIT 状态等待 2MSL 的时长，最终进入 CLOSED 状态。服务端收到客户端回复的「ACK」消息后，直接从 LAST-ACK 状态进入CLOSED 状态。

为什么要四次挥手？

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

四次挥手的异常情况

问题1：断开连接的 FIN 包丢了

我们前面一直强调过，如果一个包发出去，在一定时间内，只要没有收到对端的「ACK」回复，均认为这个包丢了，会触发超时重传机制。而不会关心到底是自己发的包丢了，还是对方的「ACK」丢了。

所以在这里，如果客户端率先发的「FIN」包丢了，或者没有收到对端的「ACK」回复，则会触发超时重传，直到触发重传的次数，直接关闭连接。

对于服务端而言，如果客户端发来的「FIN」没有收到，就没有任何感知。会在一段时间后，也关闭连接。

问题2：服务端第一次回复的 ACK 丢了

此时因为客户端没有收到「ACK」应答，会尝试重传之前的「FIN」请求，服务端收到后，又会立即再重传「ACK」。

而此时服务端已经进入 CLOSED-WAIT 状态，开始做断开连接前的准备工作。当准备好之后，会回复「FIN,ACK」，注意这个消息是携带了之前「ACK」的响应序号的。

只要这个消息没丢，客户端可以凭借「FIN,ACK」包中的响应序号，直接从 FIN-WAIT-1 状态，进入 TIME-WAIT 状态，开始长达 2MSL 的等待。

问题3： 服务端发送的 FIN,ACK 丢了

服务端在超时后会重传，此时客户端有两种情况（FIN,ACK重传了），要么处于 FIN-WAIT-2 状态(之前的 ACK 也丢了)，会一直等待；要么处于 TIME-WAIT 状态，会等待 2MSL 时间。

也就是说，在一小段时间内客户端还在，客户端在收到服务端发来的「FIN,ACK」包后，也会回复一个「ACK」应答，并做好自己的状态切换。

问题4：客户端最后回复的 ACK 丢了

客户端在回复「ACK」后，会进入 TIME-WAIT 状态，开始长达 2MSL 的等待，服务端因为没有收到「ACK」的回复，会重试一段时间，直到服务端重试超时后主动断开。

或者等待新的客户端接入后，收到服务端重试的「FIN」消息后，回复「RST」消息，在收到「RST」消息后，复位服务端的状态。

问题5：客户端收到 ACK 后，服务端跑路了

客户端在收到「ACK」后，进入了 FIN-WAIT-2 状态，等待服务端发来的「FIN」包，而如果服务端跑路了，这个包永远都等不到。

在 TCP 协议中，是没有对这个状态的处理机制的。但是协议不管，系统来凑，操作系统会接管这个状态，例如在 Linux 下，就可以通过 tcp_fin_timeout 参数，来对这个状态设定一个超时时间。

需要注意的是，当超过 tcp_fin_timeout 的限制后，状态并不是切换到 TIME_WAIT，而是直接进入 CLOSED 状态。

问题6：客户端收到 ACK 后，客户端自己跑路了

客户端收到「ACK」后直接跑路，服务端后续在发送的「FIN,ACK」就没有接收端，也就不会得到回复，会不断的走 TCP 的超时重试的机制，此时服务端处于LAST-ACK 状态；

那就要分 2 种情况分析：

在超过一定时间后，服务端主动断开。
收到「RST」后，主动断开连接。
「RST」消息是一种重置消息，表示当前错误了，应该回到初始的状态。如果客户端跑路后有新的客户端接入，会在此发送「SYN」以期望建立连接，此时这个「SYN」将被忽略，并直接回复「FIN,ACK」消息，新客户端在收到「FIN」消息后是不会认的，并且会回复一个「RST」消息。

为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime：最长报文段寿命），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止「已经失效的连接请求报文段」出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

3、TCP、UDP 协议的区别

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如：QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

4、TCP 协议如何保证可靠传输

• 应用数据被分割成 TCP 认为最适合发送的数据块；
• TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
• 校验和：TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
• TCP 的接收端会丢弃重复的数据。
• 流量控制：TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）
• 拥塞控制：当网络拥塞时，减少数据的发送。
• ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
• 超时重传：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

5、在浏览器中输入url地址 ->> 显示主页的过程

• DNS解析
• TCP连接
• 发送HTTP请求
• 服务器处理请求并返回HTTP报文
• 浏览器解析渲染页面
• 连接结束

6、URI和URL的区别是什么?

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

7、HTTP 和 HTTPS 的区别？

• 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
• 安全性和资源消耗：HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。
• 费用：https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

详细讲解，见如下总结：一文搞懂HTTPS加密机制

8、状态码

2XX——表明请求被正常处理了

200 OK：请求已正常处理。

204 No Content：请求处理成功，但没有任何资源可以返回给客户端，一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。

206 Partial Content：是对资源某一部分的请求，该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。

3XX——表明浏览器需要执行某些特殊的处理以正确处理请求

301 Moved Permanently：资源的uri已更新，你也更新下你的书签引用吧。永久性重定向，请求的资源已经被分配了新的URI，以后应使用资源现在所指的URI。

302 Found：资源的URI已临时定位到其他位置了，姑且算你已经知道了这个情况了。临时性重定向。和301相似，但302代表的资源不是永久性移动，只是临时性性质的。换句话说，已移动的资源对应的URI将来还有可能发生改变。

303 See Other：资源的URI已更新，你是否能临时按新的URI访问。该状态码表示由于请求对应的资源存在着另一个URL，应使用GET方法定向获取请求的资源。303状态码和302状态码有着相同的功能，但303状态码明确表示客户端应当采用GET方法获取资源，这点与302状态码有区别。
当301,302,303响应状态码返回时，几乎所有的浏览器都会把POST改成GET，并删除请求报文内的主体，之后请求会自动再次发送。

304 Not Modified：资源已找到，但未符合条件请求。该状态码表示客户端发送附带条件的请求时（采用GET方法的请求报文中包含If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since中任一首部）服务端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304.。

307 Temporary Redirect：临时重定向。与302有相同的含义。

4XX——表明客户端是发生错误的原因所在

400 Bad Request：服务器端无法理解客户端发送的请求，请求报文中可能存在语法错误。

401 Unauthorized：该状态码表示发送的请求需要有通过HTTP认证（BASIC认证，DIGEST认证）的认证信息。

403 Forbidden：不允许访问那个资源。该状态码表明对请求资源的访问被服务器拒绝了。（权限，未授权IP等）

404 Not Found：服务器上没有请求的资源。路径错误等。

5XX——服务器本身发生错误

500 Internal Server Error：貌似内部资源出故障了。该状态码表明服务器端在执行请求时发生了错误。也有可能是web应用存在bug或某些临时故障。

503 Service Unavailable：抱歉，我现在正在忙着。该状态码表明服务器暂时处于超负载或正在停机维护，现在无法处理请求。

9、HTTP长连接、短连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

10、HTTP是不保存状态的协议,如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？

Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。

在服务端保存Session的方法很多，最常用的就是内存和数据库(比如，使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个Session ID的方式来跟踪。

Cookie 被禁用怎么办?

最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

11、Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息，如下：

①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；

②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；

③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

12、Get与POST的区别

• 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
• 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
• 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的请求头中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的请求体中；
• 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全；
• 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

参考文章：

1、https://mp.weixin.qq.com/s/NazY5t8PWXCgU1VBhTzt-A
2、https://mp.weixin.qq.com/s/7nke-6S-5mjhqK0LewsV0w
3、https://network.51cto.com/art/202002/610542.htm
4、https://www.cnblogs.com/sxiszero/p/11133747.html