【八股文整理Day01计网】01-06

计算机网络

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

简略版

参考资料：B站视频；知识星球作业（精简版）

根据域名，进行DNS域名解析，得到IP地址—>根据IP地址，发起TCP的3次握手，建立TCP连接—>发送HTTP请求—>服务器处理HTTP请求，将响应结果返回给浏览器—>通过4次挥手释放TCP连接—>浏览器解析html代码—>浏览器对页面进行渲染呈现给用户。

1. URL输入

2. DNS解析

3. 建立TCP连接

4. 发送http/https请求

5. 服务器端响应请求

6. 浏览器解析渲染页面

7. http请求结束，断开TCP连接

详细版

参考资料：公众号文章（知识星球提供的参考资料）

• 导航阶段

• 浏览器主进程

01 用户输入URL并回车

1. 浏览器进程检查URL，组装协议，构成完整的URL

2. 浏览器进程通过进程间通信（IPC）把URL请求发送给网络进程

• 网络进程

02 URL请求过程

1. 网络进程接收到URL请求后检查本地缓存是否缓存了该请求资源，如果有则将该资源返回给浏览器进程

如果没有，网络进程向web服务器发起http请求（网络请求），请求流程如下：

1. 准备IP地址和端口：

   1. 先查找缓存，

   2. 没有缓存：进行DNS解析，获取服务器ip地址，端口

   3. 浏览器用一个随机的端口号向服务器80端口发起TCP连接请求

利用ip地址和服务器建立tcp连接

1. 等待TCP队列

2. 通过三次握手建立TCP连接

3. 构建并发送HTTP请求信息

4. 服务器端处理请求

   1. 浏览器和web服务器建立连接后，浏览器会发送一个初始的HTTP GET请求，请求目标通常是一个html文件

   2. 服务器收到请求后，将发回一个HTTP的响应报文

5. 客户端处理响应，首先检查服务器响应报文的状态码

   1. 如果是301/302表示服务器已更换域名需要重定向，这时网络进程会从响应头的Location字段里面读取重定向的地址，然后再发起新的HTTP或者HTTPS请求，跳回第4步

   2. 如果是200，就检查Content-Type字段，值为text/html说明是HTML文档，是application/octet-stream说明是文件下载

6. 请求结束，当通用首部字段Conection不是Keep-Alive时，即不为TCP长连接时，通过四次挥手断开TCP连接

03 准备渲染进程

1. 准备渲染进程

   1. 浏览器进程检查当前url是否和之前打开的渲染进程根域名是否相同，如果相同，则复用原来的进程，如果不同，则开启新的渲染进程

04 提交文档

1. 传输数据、更新状态

   1. 渲染进程准备好后，浏览器向渲染进程发起“提交文档”的消息，渲染进程接收到消息后与网络进程建立传输数据的“管道”

   2. 渲染进程接收完数据后，向浏览器发送“确认提交”

   3. 浏览器进程接收到确认消息后更新浏览器界面状态：安全状态、地址栏url、前进后退的历史状态、更新web页面

1. 渲染阶段（略）

在渲染阶段通过渲染流水线在渲染进程的主线程和合成线程配合下，完成页面的渲染；

1. 渲染进程

05 构建DOM树

06 构建CSSOM

07 样式计算

08 布局阶段

09 分层

10 图层绘制

11 切分图快

1. GPU进程

12 栅格化操作

1. 浏览器主进程

13 合成与显示

2. 三次握手的过程，以及为什么是三次，而不是四次，两次？

一般这种问题呢，是最容易扩展，也是最适合展现自己计算机基础的题，面试官通过扩展，可以问出来你是不是背八股，或者只是简单的了解，而我们呢，也能通过这类问题引导面试官下一步的问题。 比如： 1. 三次握手过程中可以携带数据嘛？ 2.如果第一次/第二次/第三次握手丢失了，会发生什么？ 大家也可以看一下网上的博客，把自己写的作业整理一下放到自己的笔记库中，到时候方便回顾（以后面试的时候也会需要） ------------------------------------------------------- 网上的答案很多，大家可以参考：面试官，不要再问我三次握手和四次挥手 - 掘金

答案

1. 为什么不是两次握手

   1. 三次刚好可以让服务端确定客服端和服务端自己都有正常的接收和发送能力

   2. 两次握手可能导致资源的浪费，由于没有第三次握手，服务端就无法确认客户端是否收到了自己的回复，所以每收到一个SYN，服务器都会主动去建立一个连接。

2. 为什么不是四次握手

   1. 三次握手已经能够保证双方的接收和发送能力了，四次的话会浪费一次连接资源

参考一（知识星球@💥zhutouasa*答案）

关于TCP为什么是三次握手，主要是有三个原因。

其中的一个原因是因为三次刚好可以让客服端与服务端能保证具有接受能力和发送能力：

在第一次握手时，客户端发送同步报文，当服务端接收到时保证了客户端具有发送能力；

在第二次握手时，服务端发送确认报文和同步保温，当客户端接收到时保证了服务端具有接收能力和发送能力；

在第三次握手时，客户端发送确认报文，当服务端接收到时保证了服务端具有接受能力。

第二个原因是，三次握手可以阻止重复历史连接的初始化。当客户端向服务端第一次发送请求同步报文，在传输中发生了阻塞，然后客户端重发报文后还是没有得到回应的前提下，客户端重新启动，重新建立连接，重新发了一个不同的请求同步报文，并且这时旧的请求同步报文先到达客户端，客户端判断这个报文的确认报文与自己期望返回的报文不一致，然后就向服务端发送一个RST报文，断开连接。然后当最新的报文返回到客户端后，客户端判断这个是自己想要的报文，并接收后完成正确的三次握手过程。

第三个原因也就是承接上一个原因的，同样也回答为什么不是两次握手这个问题，如果是两次握手创建连接的话，那么服务端在第一次收到请求同步报文后，向服务端发送确认报文和请求报文的同时，就会将自己的状态改为establish，那么在还不能确定服务端是否有接收能力的同时就创建连接，每收到一个请求同步报文就establish一次，那么只会浪费资源，并且在第二个原因盲目的创建历史连接，也是浪费资源。

第四个原因，回到为什么不是四次握手，因为三次握手已经能够保证双方的接收和发送能力了，如果采用四次握手的话只会浪费一次连接的资源。

参考二（ 知识星球@唐浮答案 ）

（一）三次握手的过程如下：

1、客户端向服务器发送SYN报文、初始化序列号ISN（seq=x），然后客户端进入SYN_SEND状态，等待服务器确认。

2、服务端发送ACK确认服务端的SYN报文（ack=x+1），同时发出一个SYN报文，带上自己的初始化序列号（seq=y），然后服务端进入SYN_RECV状态。

3、客户端接收到服务端的SYN、ACK报文，ACK确认服务端的SYNC报文（ACK=y+1），然后客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

（二）为什么不是四次握手？

因为传输效率不够高。

（三）为什么不能两次握手？

两次握手无法让通信双方数据原点的序列号一致，不能保证数据可靠传输。

参考三（最全）

原文链接

1. 请画出三次握手和四次挥手的示意图

2. 为什么连接的时候是三次握手？

3. 什么是半连接队列？

4. ISN(Initial Sequence Number)是固定的吗？

5. 三次握手过程中可以携带数据吗？

6. 如果第三次握手丢失了，客户端服务端会如何处理？

7. SYN攻击是什么？

8. 挥手为什么需要四次？

9. 四次挥手释放连接时，等待2MSL的意义?

三次握手的含义

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

三次握手的作用

确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。

连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息

三次握手的过程

图示

描述

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。 进行三次握手：

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_SEND 状态。

• 首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

• 在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

• 确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。

发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

在socket编程中，客户端执行connect()时，将触发三次握手。

三次握手相关问题

1. 为什么需要三次握手，两次不行吗？

三次握手每次分别的目的：

1. 第一次握手：确定客户端发送能力正常，服务端接收能力正常

2. 第二次握手：客户端发送和接收能力都正常，服务端发送和接收能力也都正常，但服务端无法确定客户端的接收能力是否正常

3. 第三次挥手：服务端能确定自己的发送接收能力正常，客户端的发送接收能力也正常

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

3. 四次挥手的过程，以及为什么是四次？

答案

过程

TIME_WAIT状态也成为2MSL等待状态

为什么是四次

第二次挥手只是回应客户端，表示我收到了，但可能无法立刻确认关闭请求，当服务器所有数据都发送完毕后，再同时发送FIN和ACK来确认关闭请求，所以必须是四次

参考一（ 知识星球@唐浮答案 ）

（一）四次挥手的过程：

1、客户端发送一个FIN报文给服务端，表示自己要断开数据传送，报文中会指定一个序列号 (seg=x)。然后,客户端进入FIN-WAIT-1 状态。

2、服务端收到FIN报文后，回复ACK报文给客户端，且把客户端的序列号值+1，作为ACK报文的序列号(seq=x+1)。然后，服务端进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态。

3、服务端也要断开连接时，发送 FIN 报文给客户端，且指定一个序列号(seq=y+1)，随后服务端进入LAST-ACK状态。

4、客户端收到FIN报文后，发出ACK报文进行应答，并把服务端的序列号值+1作为ACK报文序列号(seq=y+2)。此时客户端进入TIME-WAIT状态。服务端在收到客户端的ACK 报文后进入CLOSE 状态。如果客户端等待2MSL没有收到回复，才关闭连接。

（二）为什么是四次挥手？

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。

当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后才会完全关闭了 TCP 连接。

总结：两次握手可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手

参考二

链接：https://juejin.cn/post/6844903958624878606

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，"你发的FIN报文我收到了"。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

4. TCP与UDP的概念，特点，区别和对应的使用场景？

答案

我们可以将人与人之间的通信大致的分为两种:打电话和发短信。

短信的传输在意对方是否收到、收到的信息是否完整等等。

电话的通信更加在意电话能否拨通、通信是否紊乱等等。

短信的传输就更像是UDP进行传输：只管将数据发送出去，但是不确定对方是否能够接受或者已经接受，UDP尽自己的能力去发送，实现无连接的数据传输。

电话的传输就像是使用TCP进行失输：每一次数据的发送都需要得到对应的回应；数据是否接受、接受状态如何、数据顺序是否出错等等，在建立连接的基础上实现传输。

其他看参考一

参考一（知识星球@KU做人答案 ）

TCP与UDP的概念

TCP（传输控制协议）：TCP是一种面向连接的协议，它在通信前先建立连接，然后传输数据，最后再释放连接。

UDP（用户数据报协议）：UDP是一种无连接的协议，它不建立连接，直接发送数据报。

TCP与UDP的特点

1. TCP（传输控制协议）：

   1. 可靠性：确保数据在发送和接收之间没有丢失，也保证数据按照正确的顺序到达。

   2. 连接导向：TCP是面向连接的协议，在通信前需要先建立连接。（确保数据有序，可靠）

   3. 重传机制：如果数据在传输中丢失或损坏，TCP会自动进行数据的重传，确保可靠性。

   4. 流量控制：TCP采用流量控制机制，通过动态调整数据发送的速率，避免数据包的丢失和网络拥塞。

2. UDP（用户数据报协议）：

   1. 不可靠性：UDP不保证数据传输的可靠，数据在传输过程中可能丢失，重复或乱序，需要应用层自己处理数据的可靠性问题。

   2. 无连接：UDP是一种无连接的协议，不需要建立或者断开连接，可以直接发送数据包。

   3. 实时性：由于不需要等待连接，可以直接发送数据包，可以适用于一些实时性要求高的应用，如音频和视频传输。

   4. 高效性：由于没有建立连接的过程，并没有重传和流量控制的机制，所以UDP传输速度较快，系统资源消耗小。

TCP和UDP的区别

1.是否面向连接 是 否

2.是否可靠 是 否

3.是否有状态 是 否

4.传输效率 较慢 较快

5.传输形式 字节流 数据报文段

6.首部开销 20 ～ 60 bytes 8 bytes

7.是否提供广播或多播服务 否 是

TCP和UDP对应的使用场景

TCP： 用于对传输准确性要求特别高的场景，比如文件传输、发送和接收邮件、远程登录等等。

UDP：适用于即时通信，比如语音、 视频、直播等等，这些对实时性要求高。

参考二

https://juejin.cn/post/7136762246180536351

5. HTTP常见的状态码和常见的字段

答案

6. HTTP有哪些请求以及GET和POST请求的区别

答案

见参考一

补充理解

B站视频链接

关于HTTP

1. 最初是浏览器与服务器之间的通讯协议，GET用于读取资源（HTML, CSS, JS, 图片），POST用于提交表单。

2. 后来被扩充到接口格式的定义，GET 和POST作为接口的请求方式。

   • 所以从接口定义的角度去看，get和post只是请求方式不同

参考一（知识星球@星球管理-二丙答案）

GET和POST的区别

1. 作用不同

GET用于从服务端获取资源（用浏览器访问页面都是使用GET）

POST一般用来向服务器端提交数据

2. 参数传递方式不同

GET请求的参数一般写在URL中，且只接受ASCII字符

POST请求参数一般放在请求体中，对于数据类型也没有限制

3. 安全性不同

因为参数传递方式的不同，所以两者安全性不同，GET请求的参数直接暴露在URL中，所以更不安全，不能用来传递敏感信息。

4. 参数长度限制不同

GET传送的数据量较小，不能大于2KB。（因为写在URL中，URL长度受限）

POST传送的数据量较大，一般被默认为不受限制。

HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

5. 编码方式不同

GET 请求只能进行 URL 编码（application/x-www-form-urlencoded）

POST 支持多种编码方式（application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多种编码。）

6. 缓存机制不同

GET 请求会被浏览器主动cache，而 POST 不会，除非手动设置。

GET 请求参数会被完整保留在浏览器历史记录里，而 POST 中的参数不会被保留。

GET 产生的 URL 地址可以被 保存为书签，而 POST 不可以。

GET 在浏览器回退时是无害的，而 POST 会再次提交请求。

7. 时间消耗不同

GET 产生一个 TCP 数据包；

POST 产生两个 TCP 数据包。

对于 GET 方式的请求，浏览器会把 header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 POST，浏览器先发送 Header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）

8. 幂等

意思是多次执行相同的操作，结果都是「相同」的。

GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。

POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。