【复习】计算机网络

网络模型

OSI

应用层：给应用程序提供统一的接口
表示层：把数据转换成兼容另一个系统能识别的格式
会话层：负责建立、管理、终止表示层实体之间的通信会话
传输层：负责端到端的数据传输
网络层：负责数据的路由、转发、分片
数据链路层：负责数据的封帧和差错检测，以及MAC寻址
物理层：负责在物理网络中传输数据帧

TCP/IP模型

应用层：支持HTTP、SMTP等最终用户进程
传输层：处理主机到主机之间的通信
网络层：寻址和路由数据包
链路层：通过网络的物理电线或无线信道移动比特

TCP在传输层；IP在网络层

应用层

应用层的协议？

HTTP、HTTPS、CDN、DNS、FTP

HTTP报文有哪几部分？

请求报文：

请求行：请求方法、目标、HTTP版本
请求头：请求的附加信息（Host、User-Agent…）
空行：请求头和请求体之间用空行空格
请求体：请求的数据，用于POST请求需要传输数据的情况

响应报文：

状态行：HTTP协议、状态码、状态信息
响应头：响应的附加信息（Content-Type、Content-Length…）
空行：响应头和响应体之间用空行空格
响应体：包含响应的数据（服务器返回的HTML、JSON…）

HTTP常用状态码

1xx：提示信息，协议处理的中间状态，还需要后续操作（少用）
2xx：成功，报文已收到并被正确处理（200、204、206）
3xx：资源重定向，资源位置发生变动，需要客户端重新用新的URL发请求（301、302、304）
- 301 - 永久重定向，说明请求的资源已经不存在了，需要改用新的URL再次访问
- 302 - 临时重定向，说明请求的资源还在但是暂时需要用另一个URL访问
301 和 302都会在响应头指明后续要跳转的URL
4xx：客户端错误，请求报文有误，服务器无法处理（400、403、404、405）
- 404 - 无法找到此页面
- 405 - 请求的方法类型不支持
5xx：服务器错误（500、501、502、503）
- 502 - 服务器执行请求时，从上游服务器接收到无效的响应
- 504 - 服务器执行请求时，未能及时从上游服务器收到响应

nginx是代理服务器，收到客户端请求后，将请求发到后端服务器；

502：nginx收到无效的响应
503：请求超时（超过了nginx的配置时间）

GET和POST的区别

GET：从服务器获取资源，请求参数写在URL位置（URL只支持ASCII且浏览器对URL的有限制）

POST：根据body对指定的资源做处理，携带的数据写在body里。

GET是安全、幂等的（只读），可以对GET数据做缓存，可以缓存到浏览器上，也可以缓存到nginx上，在浏览器中GET请求可以保存为书签。

POST是不安全、不是幂等的（写），浏览器一般不会缓存POST请求，也不能把POST请求保存为书签

实际开发中，也会用POST方法实现查询数据的请求

HTTP长连接

HTTP协议是“请求-响应”模式，先建立TCP连接，客户端发起了HTTP请求，服务器收到后就返回响应，然后释放TCP连接。

HTTP短连接：一次连接只能请求一次资源

HTTP长连接（Keep-Alive）：使用同一个TCP连接来发送和接收多个HTTP请求，避免了连接建立和释放的开销。只要任何一段没有明确提出断开连接，则保持TCP连接状态。

HTTP怎么对请求做拆包的？

请求的拆包是通过“Content-Length”头字段来进行的。该字段指示了请求正文的长度，服务器可以根据该长度来正确接收和解析请求。

客户端发送HTTP请求，会在请求头中增加“Content-Length”字段，用来表示请求正文的字节数
浏览器根据“Content-Length”字段来确定请求的长度，并从请求中读取相应数量的字节，直到读取完整个请求的内容

HTTP为什么不安全？

HTTP是基于明文传输的，通信链路上可以获取通信内容；其他用户可以篡改内容；也可以冒充发送方。

HTTPS是在HTTP和TCP层之间引入了SSL/TLS协议，解决了上述风险。

HTTP 和 HTTPS的区别？

HTTP是超文本传输协议，存在安全风险；HTTPS解决了HTTP不安全的缺陷，在TCP和HTTP之间加入了SSL/TLS协议
HTTP建立相对简单，通过TCP三次握手后就可以进行HTTP的报文传输；HTTPS在TCP三次握手后还需要建立SSL/TLS的握手才能进行加密报文传输
HTTP默认端口80；HTTPS默认端口443
HTTPS需要向CA申请数字证书，来保证服务器的身份是可用的

TLS的四次握手过程？

第一次握手：客户端向服务器发起加密通信请求（ClientHello），主要发送以下信息：
- 客户端支持的TLS协议版本
- 客户端生成的随机数（后边用于生成会话秘钥）
- 客户端支持的密码套件列表（RSA加密算法）
第二次握手：服务器收到客户端请求后，向客户端发出响应（ServerHello），主要回应以下信息：
- 确认TLS协议版本
- 服务器生成的随机数（后边也是用于生成会话秘钥）
- 确认的密码套件列表（RSA加密算法）
- 服务器的数字证书
第三次握手：客户端收到服务器回应后，通过浏览器或操作系统里的CA公钥，确认服务器的数字证书的真实性。整数如果没有问题，就会从数字证书里取出服务器的公钥，用它加密报文，向服务器发送以下信息：
- 一个随机数（会被服务器公钥加密）
- 加密通信算法改变通知（告知服务器随后的信息都会用“会话密钥”加密通信）
- 客户端握手结束通知（表示客户端的握手已经结束）
通过这三个随机数，接着用双方协商的加密算法，各自生成本次通信的“会话密钥”
第四次握手：服务器通过协商的加密算法，计算出本次通信的“会话密钥”，向客户端回应以下消息：
- 加密通信算法改变通知（告知客户端随后的消息都会用“会话密钥”加密通信）
- 服务器握手结束通知（表明服务器的握手已经结束）

整个TLS的握手全部结束后，服务器与客户端就会进入加密通信，完全是使用普通的HTTP协议，只不过用“会话密钥”加密内容

HTTPS如何防范中间人攻击？

加密：https握手期间会通过非对称加密方式协商出对称加密密钥
身份验证：客户端与服务器建立连接后，服务器会将CA证书发送给客户端，客户端会去校验CA整数的合法性。验证通过后，使用证书中的公钥来加密数据，并将加密后的数据传给服务器，服务器用私钥解密

中间人的攻击在于冒充服务器与客户端建立连接，但是中间人拿不到服务器的私钥，无法正确解密客户端发过来的数据。同时如果客户端校验CA证书后，证书验证失败，也会中断连接。

HTTP1.1 和 HTTP2.0的区别？

头部压缩：HTTP2会压缩头部，如果发送多个请求，他们的请求头部是一样的，协议会帮忙消除重复的部分。

HPACK算法：客户端和服务器同时维护一张头部信息表，所有的字段都存入这个表中，并生成一个索引号，以后就不会发送同样的字段，直接发送索引号即可。

二进制格式：HTTP1.1采用的是纯文本形式的报文；HTTP2全面采用了二进制格式。增加了数码据传输的效率
并发传输：多个Stream复用在同一条TCP连接上，解决了HTTP1.1队头阻塞的问题
服务器主动推送资源：服务器不再是被动的响应，可以主动向客户端发送消息

HTTP进行TCP连接之后，什么情况下会断开连接？

客户端或服务器发送一条FIN报文，就会进行四次挥手
发送方发送了一条数据给服务器，服务器超过一段时间没有响应ACK报文，发送方重传达到最大次数时，就会断开TCP连接
HTTP长时间没有进行请求和响应。

HTTP、SOCKET和TCP的区别？

HTTP：应用层协议，定义了客户端和服务器之间交换数据的规则；在客户端和服务器之间传输和显示web页面
Socket：用于描述通信链路的一端，提供了底层的通信接口，可实现不同计算机之间的数据交换
TCP：传输层协议，负责在网络中建立可靠的数据传输连接

DNS是什么？

DNS是用来将域名转化成IP地址的数据库系统，端口号53。（越靠右层级越高）

根域名服务器
顶级域名服务器
权威域名服务器

DNS底层是基于UDP协议的，因为UDP可以提供低延迟的特性，更适合DNS这种需要快速响应的域名解析服务。

虽然UDP存在丢包和数据包损坏的风险，但是DNS使用一些机制来提高可靠性（超时重传、请求重试、缓存…）

DNS域名解析流程？

客户端发送DNS请求，发送给本地域名服务器
本地域名服务器先去查询缓存，如果查到，直接返回IP地址；如果没有查到，就进行迭代查询
- 本地域名服务器去访问他的根域名服务器，根域名服务器并不会进行域名解析，而是告诉它顶级域名服务器的IP地址
- 本地域名服务器又去访问顶级域名服务器，顶级域名服务器也不会进行域名解析，而是告诉它权威域名服务器的IP地址
- 本地域名服务器又去访问权威域名服务器，权威域名服务器是域名解析结果的原出处，将该域名对应的IP地址告诉本地域名服务器，随后本地域名服务器将IP地址返回给客户端，成功建立连接。

HTTP是无状态的吗？

HTTP是无状态的，服务器不会在多个请求中保留客户端状态的信息，在每个HTTP请求中，服务器不会记住之前的请求和会话状态，每个请求都是独立的。

可以通过一些机制来实现状态保持，例如：使用Cookie和Session来跟踪用户的状态。

通过在客户端存储会话信息，服务器可以识别和跟踪特定用户的状态。

携带Cookie的HTTP是有状态的，Cookie是用来在客户端存储会话信息和状态信息的，通过使用Cookie可以实现一定程度的状态保持功能。

Cookie是HTTP协议簇的一部分，只是无状态协议下的一种补充，用来在客户端存储状态信息以实现状态保持。

Cookie和Session的区别

存储位置：Cookie存储在客户端，浏览器向服务器发请求时，会自动携带Cookie；Session存在服务器，服务器为每个用户分配一个SessionId，通过Cookie的方式发送给客户端，客户端的后续请求都会携带SessionId，服务器根据SessionId找到对应的数据
数据容量：单个Cookie大小限制在4KB左右；Session存储在服务器上，主要受限于服务器内存大小
安全性：Cookie存储在客户端，相对不安全；Session存储在服务器，比Cookie安全
生命周期：Cookie可以设置过期时间，过期后自动删除，也可以设置会话Cookie，浏览器关闭后自动删除；Session在默认情况下，用户关闭浏览器时Session结束，服务器也可以设置Session的超时时间。

token、session、cookie的区别？

session：存储在服务器，拥有一个唯一的SessionId，这个SessionId一般存放在Cookie中。服务器收到Cookie后会解析SessionId，再去Session列表中查找，找到对应的Session。
Cookie：类似于一个令牌，装有SessionId，存储在客户端，浏览器一般会自动添加
Token：类似一个令牌，无状态，用户信息都被加密到Token中，服务器收到Token后解密就可以知道是哪个用户，需要开发者手动添加。

客户端如果禁用了Cookie，Session也无法正常使用，因为大部分的服务器都是依赖Cookie来传递sessionId。

数据存储在localStorage和Cookie有什么区别？

存储容量：Cookie的存储容量小；LocalStorage的存储容量通常较大（存储大量数据时，LocalStorage更合适）
数据发送：Cookie在每次请求时都会自动发送到服务器，适合在服务器和浏览器中传输数据；LocalStorage不会自动发送数据，只在浏览器中存储数据，更适合于同一个域名下不同页面之间共享数据
生命周期：Cookie可以设置过期时间；LocalStorage的数据将永远存在浏览器中，除非通过js代码手动删除
安全性：Cookie的安全性低，因为Cookie每次请求都会发送给服务器，存在监听和篡改的风险；LocalStorage的数据只存储在浏览器中，相对更安全。

JWT和传统方式的区别？

无状态：JWT时无状态的令牌，不需要在服务器存储会话信息。JWT令牌中包含了所有必要的信息。
安全性：JWT使用秘钥对令牌进行签名，保证令牌的完整性和真实性。
跨域：JWT令牌可以在不同域之间传递，可以实现无需Cookie的跨域身份验证。

JWT令牌由：头部、载荷、签名三部分组成。

头部、载荷：JSON格式，使用Base64编码进行序列化

签名：对头部、载荷、秘钥进行签名后的结果

JWT的缺点？

JWT一旦派发出去，在失效之前都是有效的，没法即使撤销JWT

解决：在业务层增加判断逻辑，比如：添加黑名单机制。使用Redis维护一个黑名单，如果让某个JWT失效就直接把这个JWT加入黑名单中，每次使用前就判断这个JWT是否存在黑名单中。

前端如何存储JWT？

传统方式：

浏览器向服务器发起请求
服务器在当前会话（session）里保存相关数据，并返回一个sessionId
浏览器拿到sessionId后会存入Cookie，以后每次发请求都会携带Cookie。
服务器拿到Cookie后会解析出sessionId，并通过这个sessionId找到前期保存的数据。

如果是服务器集群情况下，就需要session共享数据，使得每个服务器都可以读取到session

优化：

服务器不存储session数据，所有数据都保存在客户端，每次请求都会发回服务器，客户端收到服务器返回的JWT后，可以存储在LocalStorage里，也可以存储在Cookie里，还可以存储在SessionStorage里。

存储在LocalStorage里：提供了较大的存储空间，不会随HTTP一起发送给服务器，但是恶意脚本可能可以通过JS代码访问到JWT（XSS攻击）。
存储在Cookie里：设置HttpOnly标志来防止通过JS访问，减少XSS攻击的风险；但是单个Cookie只能存储4KB，并且每次HTTP请求都会携带Cookie
存储在SessionStorage：当窗口关闭后，数据会被清除；但是用户的体验可能会受到影响，每次刷新页面都需要重新登陆。

HTTP长连接和WebSocket的区别？

TCP协议是全双工的（HTTP1.1虽然是基于TCP的协议，但是他是半双工的；HTTP2是全双工的），HTTP1.1对于大部分需要服务器主动推送到客户端的场景都不太友好；而WebSocket是全双工的
HTTP1.1里，只要客户端不发起请求，服务器就不会给响应。对于服务器和客户端之间需要频繁交互的复杂场景，可以考虑webSocket

传输层

TCP头部

序列号（seq）：在建立连接时由计算机生成的随机数作为初始值，每发送一次数据，就累加一次该数据字节的大小。（用来解决网络包乱序的问题）
确认应答号（ack）：下次“期望”收到的数据的序列号，发送端收到这个说明在这个序列号之前的所有数据都已被正常接收（用来解决丢包问题）
控制位：
- ACK：1 - 确认应答号有效
- RST：1 - TCP连接出现异常时必须强制断开连接
- SYN：1 - 希望建立连接
- FIN：1 - 希望断开连接

TCP三次握手

在这里插入图片描述

第三次握手可以携带数据，前两次握手是不可以携带数据的

一旦完成三次握手，双方都处于established状态，此时连接就已建立完成，客户端与服务器就可以互相发送数据了。

为什么TCP需要三次握手？

三次握手主要是为了防止旧的重复连接初始化造成混乱。

客户端如果连续发送了多个SYN建立连接的报文，

在网络不好的情况下：“旧的SYN报文（seq = 90）”比“新的SYN报文（seq = 100）”早到达
此时服务器先返回一个SYN+ACK的报文给客户端，客户端收到后，发现自己期望收到的应该是（100 + 1 = 101，而不是90 + 1），就返回RST报文。
服务器收到RST报文后就会释放连接。
等到新的SYN报文（100 + 1）到达后，服务器与客户端就可以完成三次握手了

如果只有两次握手无法防止旧的重复连接初始化。

客户端先后发了两个SYN报文，服务器收到了旧的SYN报文后，也往客户端发一个SYN+ACK的报文，如果只有两次握手，此时双方都已进入established状态，连接已建立。（因为需要浏览器这里判断ack和期望的不同，才会发送RST报文。）

TCP三次握手，在第三次握手中，客户端发送的确认包丢了怎么办？

因为第三次握手的ACK是针对第二次握手的SYN的确认报文，所以当第三次握手丢失了，如果服务器一直收不到，就会触发超时重传机制，直到收到三次握手。如果达到最大重传次数，服务器就会断开连接

TCP三次握手，在第一次握手中，客户端发送SYN报文丢失了怎么办？

客户端想和服务器建立连接，向服务器发送SYN报文，如果客户端一直收不到服务器的响应，就会触发超时重传机制，重传SYN报文（重传的seq序列号是一样的）如果达到最大重传次数，客户端就不再发送SYN报文，随后断开TCP连接

TCP三次握手，在第二次握手中，服务器的SYN + ACK报文丢失了怎么办？

因为第二次握手的ACK报文代表对第一次握手的确认，如果客户端没有收到第二次握手，会认为自己第一次握手的SYN报文丢失，客户端就会触发超时重传机制，重传SYN报文。如果达到最大重传次数，客户端就会断开连接。
如果第二次握手丢失，服务器收不到第三次握手，服务器这里也会触发超时重传机制，重传SYN+ACK报文，如果达到最大重传次数，服务器就会断开连接。

第一次握手，客户端发送SYN报文，第二次握手，服务器回复SYN+ACK报文，这个过程中服务器做了什么？

第二次握手：服务器收到客户端的SYN请求后，会把该连接存储到半连接队列，并向客户端发送SYN+ACK

第三次握手：客户端收到后，会发ACK报文给服务器，服务器收到第三次握手的ACK后，内核会把连接从半连接队列中移除，然后创建新的完全的连接，并添加到全连接队列，等待进程调用accept函数把连接从全连接队列中取出来。

如果有大量的SYN数据包从客户端发往服务器，会导致服务器那边的半连接队列满了，后续在收到SYN数据包就会丢弃。

TCP四次挥手

在这里插入图片描述

客户端主动关闭连接，发送FIN报文，代表客户端已经不会发送数据了，客户端进入FIN_WAIT_1状态
服务器收到SYN报文，回复ACK确认报文，此时服务器进入CLOSE_WAIT状态
此时服务器如果有数据要发送，就需要发送完数据才能关闭连接；如果没有数据要发送，就可以直接关闭连接。
服务器发完剩余的数据后，发送FIN报文，代表服务器也不会发送数据，此时服务器进入LAST_ACK状态
客户端收到FIN报文后，发送ACK确认报文给服务器，客户端此时进入TIME_WAIT状态
服务器收到ACK确认后，也进入CLOSE状态
客户端经过2MSL时间后，也进入CLOSE状态

为什么四次挥手中间两次不能变成一次？

因为服务器收到客户端的FIN报文时，需要立马响应ACK，但是此时服务器可能还有数据没有发完，所以不能马上发送FIN报文。因此四次挥手时，服务器的ACK和FIN一般都是分两次发送的。

第二次和第三次挥手之间，客户端不能发送数据，但是可以接收服务器还没发完的数据

断开连接时客户端FIN包丢失（第一次挥手不成功），服务器的状态是什么？

客户端向服务器发送FIN报文，如果发送的FIN报文丢失，客户端收不到服务器的ACK确认，就会触发超时重传机制，重传FIN报文，如果达到最大重传次数，客户端就会直接进入CLOSE状态，而服务器还是established状态。

为什么四次挥手要等2MSL？

MSL是报文最大生存时间，超过这个时间报文会被丢弃，因为TCP报文是基于IP协议，IP头有一个TTL字段（是IP数据包可以经过的最大路由跳数）

MSL的单位是时间，TTL是经过路由跳数，所以MSL应该大于等于TTL消耗为0的时间，保证报文已经被自然消亡。

等待2MSL，主要是因为网络中可能存在发送方的报文，这些发送方的数据包被接收方处理后，又会向对方发送响应。（一来一回需要等待2倍时间）

如果服务器没有收到客户端最后的ACK报文，那么就会触发服务器的超时重传，服务器会重新发送FIN报文，一来一回正好2MSL（相当于至少允许报文丢失一次）

TCP和UDP的区别？

TCP面向连接，UDP无连接
TCP一条链路只能由两个端点；UDP支持一对一、一对多、多对多
TCP可靠交付数据；UDP尽最大努力交付（基于UDP传输协议实现一个可靠的传输协议：QUIC协议）
TCP有流量控制和拥塞控制；UDP没有，即使网络拥堵，也不会影响UDP的发送速率
TCP首部较长（20字节），长度不固定；UDP首部只有8字节，固定不变，开销小。
TCP是流式传输，没有边界，但是要保证顺序和可靠；UDP是一个个包发送，有边界，可能会出现丢包和乱序。

TCP为什么可靠传输？

连接管理：三次握手、四次挥手建立可靠连接
序列号：既能保证可靠性，又能防止数据丢失，还能避免数据重复。
确认应答：接收方收到数据后，会发送ACK确认报文，报文中也会携带此次确认的序列号，如果未发送确认报文，就会触发超时重传机制。
超时重传：
- 数据包丢失：指定时间内，发送方未收到确认应答，就会启动超时重传
- 确认包丢失：接收方收到重复数据时丢弃，并重新回传ACK确认报文
流量控制：根据接收方处理能力，来决定发送发的发送速度（在TCP报文首部维护一个滑动窗口实现）
拥塞控制：当网络拥堵时需要减少数据发送（通过发送端维护一个拥塞窗口实现）

TCP粘包问题？

粘包问题主要是不知道用户消息的边界在哪，如果知道边界在哪，就可以通过边界来划分出有效的用户信息。

固定长度的消息【少用】：每个用户消息都是固定的（比如规定消息的长度是64字节，当接收方收到64个字节的数据，就会认为这个内容是一个完整的消息）
特殊字符作为边界：在两个用户的消息之间插入一个特殊字符，接收方收到数据后，读取到这个特殊字符，就认为已经读到了一个完整的消息。

如果消息里正好有这个字符，需要对消息里的字符做转义

自定义消息结构（包头 + 数据）：包头大小固定，包头里有个字段是用来说明随后的数据有多大。接收方收到包头后，先解析包头的内容，得到数据的长度，然后接下来就继续读取数据，直到读满数据长度。

TCP的拥塞控制？

在网络出现拥堵的情况，如果发送大量的数据包，会导致数据包丢失，这时TCP就会触发重传机制，导致网络的负担更重，就会进入恶性循环。

拥塞控制就是避免发送方的数据填满整个网络。

发送方会维护一个拥塞窗口，拥塞窗口会根据网络的拥塞程度动态变化。

发送窗口= min(拥塞窗口, 接收窗口)

拥塞控制的四个算法：

慢启动：发送方每收到一个ACK，拥塞窗口 + 1（指数增加）
- 当拥塞窗口达到慢启动门限，就会使用拥塞避免算法
拥塞避免：发送方每收到一个ACK，拥塞窗口 + 1/拥塞窗口（线性增长）
拥塞发生：当网络出现拥塞时（发生数据包重传时），就会触发重传机制
- 超时重传：慢启动门限设置为当前拥塞窗口的一半，拥塞窗口直接设置为1
- 快重传：拥塞窗口设置为原来的一半，慢启动门限等于当前拥塞窗口，进入快恢复
快恢复（一般和快重传同时使用）

网络场景

打开百度首页后发生了什么

解析URL：检查URL中是否出现了非法字符，对非法字符进行转义后处理
缓存判断：判断请求的资源是否在缓存里，如果在缓存里且没有失效，就会直接使用；如果失效会进行DNS解析
DNS解析：如果资源不在缓存里，就进行DNS解析，先查询本地域名服务器，如果本地域名服务器能找到对应的ip地址，就返回；如果找不到，本地域名服务器就会分别迭代查询顶级域名服务器、根域名服务器、权威域名服务器，最后在权威域名服务器中找到ip地址返回
获取MAC地址：当浏览器得到ip地址后，数据传输还需要直到主机的MAC地址。
- 因为应用层数据会往下传递给传输层
- 在传输层又会下发给网络层
- 网络层会将本机地址作为源地址，获取的ip地址作为目的地址，然后下发给数据链路层
- 数据链路层需要得到双方的MAC地址，本机的MAC地址作为源地址，目的MAC地址需要分两种情况：
  - 如果源ip地址和目的ip地址在同一个子网下，可以使用ARP协议直接获取到目的主机的MAC地址
  - 如果源ip地址和目的ip地址不在同一个子网下，就将请求交给网关，由网关代为转发，也是通过ARP协议获取网关的MAC地址，此时目的MAC地址就是网关的MAC地址
建立TCP连接：
- 使用目标IP地址和目标MAC地址发送SYN报文，请求建立TCP连接
- 然后由路由器转发到目标服务器后，目标服务器恢复SYN_ACK报文
- 客户端收到后，发送ACK包，表示收到服务器的确认，TCP连接建立完成
如果使用的是HTTPS协议，在TCP三次握手之前，还存在TLS的四次握手
发送数据：浏览器会向服务器发送HTTP请求
服务器响应数据：服务器收到请求后，会根据请求的内容做处理后响应数据
浏览器结束后，主动发送FIN报文，随后进入四次挥手。
- 浏览器主动发送FIN报文，表示要断开连接
- 服务器收到后，先返回ACK，表示收到浏览器的断开请求
- 服务器继续发送剩余的数据，发送完毕后，服务器也发送一个FIN报文，表示服务器这里也发完了，也断开连接
- 浏览器收到服务器的断开请求后，发送ACK报文，表示已收到，四次挥手结束。