[网络协议]计算机网络常见知识点总结

前言

计算机网络学习的核心内容就是网络协议的学习。网络协议是为计算机网络中进行数据交换而建立的规则、标准或者说是约定的集合。因为不同用户的数据终端可能采取的字符集是不同的，两者需要进行通信，必须要在一定的标准上进行。

一、常见知识点

1. 计算机网络的各层协议及作用？

计算机网络体系可以大致分为一下三种，OSI七层模型、TCP/IP四层模型和五层模型。
1.OSI七层模型：大而全，但是比较复杂、而且是先有了理论模型，没有实际应用。
2.TCP/IP四层模型：是由实际应用发展总结出来的，从实质上讲，TCP/IP只有最上面三层，最下面一层没有什么具体内容，TCP/IP参考模型没有真正描述这一层的实现。
3.五层模型：五层模型只出现在计算机网络教学过程中，这是对七层模型和四层模型的一个折中，既简洁又能将概念阐述清楚。

七层网络体系结构各层的主要功能：
应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。
表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。
运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议：
TCP：提供面向连接的、可靠的数据传输服务；
UDP：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性。
网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧。
物理层 ：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。

2. TCP和UDP的区别？

两者都是传输层中非常重要的协议，他们的区别有以下几点
1.tcp是面向连接的，也就是说使用tcp协议之前要进行建立连接，数据发送完毕后要释放连接udp是无连接的，使用udp协议发送数据不需要建立连接的，数据发送完毕自然也就不用释放连接 因此udp减少了开销和发送数据前的延迟，效率相比之下较高
2.tcp能够实现可靠传输，通过使用tcp连接传输的数据能够保证，不差错，不丢失，不失序udp只是尽最大努力交付，不能保证可靠传输
3.tcp发送的数据是报文段字节流而udp是报文一次进行发送
4.tcp只能进行端对端之间的数据传输，而udp可以一对一，一对多，多对多进行数据传输
5.tcp首部20个字节相比udp首部8个字节开销大
6.tcp是全双工通信方式，而udp是单向通行方式

总结：
TCP 用于在传输层有必要实现可靠传输的情况，UDP 用于对高速传输和实时性有较高要求的通信。TCP和 UDP 应该根据应用目的按需使用。

3. 详细介绍一下 TCP 的三次握手机制？

三次握手机制：
第一次握手：客户端请求建立连接，向服务端发送一个同步报文（SYN=1），同时选择一个随机数 seq = x 作为初始序列号，并进入SYN_SENT状态，等待服务器确认。
第二次握手：：服务端收到连接请求报文后，如果同意建立连接，则向客户端发送同步确认报文 （SYN=1，ACK=1），确认号为 ack = x + 1，同时选择一个随机数 seq = y 作为初始序列号，此时服务器进入SYN_RECV状态。
第三次握手：客户端收到服务端的确认后，向服务端发送一个确认报文（ACK=1），确认号为 ack= y + 1，序列号为 seq = x + 1，客户端和服务器进入ESTABLISHED状态，完成三次握手。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

4. 为什么需要三次握手，而不是两次？

主要有三个原因：

1. 防止已过期的连接请求报文突然又传送到服务器，因而产生错误和资源浪费。
   在双方两次握手即可建立连接的情况下，假设客户端发送 A 报文段请求建立连接，由于网络原因造成 A 暂时无法到达服务器，服务器接收不到请求报文段就不会返回确认报文段。客户端在长时间得不到应答的情况下重新发送请求报文段 B，这次 B 顺利到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，客户端在收到 确认报文后也进入 ESTABLISHED 状态，双方建立连接并传输数据，之后正常断开连接。此时姗姗来迟的 A 报文段才到达服务器，服务器随即返回确认报文并进入 ESTABLISHED 状态，但
   是已经进入 CLOSED 状态的客户端无法再接受确认报文段，更无法进入 ESTABLISHED 状态，这将导致服务器长时间单方面等待，造成资源浪费。
2. 三次握手才能让双方均确认自己和对方的发送和接收能力都正常。
   第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；
   第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；
   第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。
3. 告知对方自己的初始序号值，并确认收到对方的初始序号值。
   TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

5. 为什么要三次握手，而不是四次？

因为三次握手已经可以确认双方的发送接收能力正常，双方都知道彼此已经准备好，而且也可以完成对双方初始序号值得确认，也就无需再第四次握手了。
第一次握手：服务端确认“自己收、客户端发”报文功能正常。
第二次握手：客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常，客户端认为连接已建立。
第三次握手：服务端确认“自己发、客户端收”报文功能正常，此时双方均建立连接，可以正常通信

6. TCP协议如何保证可靠性？

tcp是传输层上的协议其传输数据的主要特点就是面向连接可靠传输的全双工字节流。
其保证可靠传输的方式主要有以下几点：
1.校验和：tcp将保持他的首部和数据的校验和，这是一个端对端的校验目的是检测数据在传输过程中的任何变化。如果收到的校验和有差错，就丢弃这个报文段。
2.序列号：tcp传输数据时将每个字节的数据进行编号处理，保证接受方接受的数据不重复，不丢失，不失序
3.确认应答：tcp采用全双工的通信方式，接受方也可以是发送方，发送方发送的数据后会等待接收方接受到数据后会给发送方发送ACK=1确认信号。也就是停止等待协议
4.超时重传：如果发送方发送完数据后迟迟没有等到接受方的确认应答，有可能的两个原因1.该数据报文段在网络传输的过程中丢失2.网络延迟传输的速率太慢。所以他就会设置一个超时时间，超过超时时间发送方就可以认为这次传输是有问题的，将采取超时重传机制重新发送数据报文段。
5.连接管理：三次握手建立链接，四次挥手释放连接
6.流量控制：当接收方来不及处理发送方发送的数据时，会提醒发送方降低发送数据的速率，防止报文段丢失
7.拥塞控制：根据网络拥塞采取合适的发送数据报文段大小。防止过多的数据注入网络这样可以使网络中的路由器或者链路不至于过载。
8.以字节为单位的滑动窗口：假设发送方A向接收方发送数据，A收到了B发来的确认报文段，其窗口值20个字节而确认号ack=31表明B期望收到的下一个序列号是31，31之前的数据报我已经都受到了。(累计确认，减少应确认的系统开销)根据这两个数据A就会构造自己的发送窗口。发送窗口：在没有收到B确认的情况下，A可以连续把窗口内的数据都发送出去，发送窗口里面的序号表示允许发送的序号发送窗口越大表示一次可以发送更多的数据，提高传输效率。发送窗口的大小受到接收方B的限制，而且发送窗口大小可变

7. 详细讲一下TCP的滑动窗口？

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组，滑动窗口右边是还没有轮到的分组。滑动窗口里面也分为两块，一块是已经发送但是未被确认的分组，另一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。
可以看到滑动窗口起到了一个限流的作用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。

8. 详细讲一下拥塞控制？

TCP 一共使用了四种算法来实现拥塞控制：
1.慢开始 (slow-start)；
2.拥塞避免 (congestion avoidance)；
3.快速重传 (fast retransmit)；
4.快速恢复 (fast recovery)。
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。当cwndssthresh时，改用拥塞避免算法。
慢开始：不要一开始就发送大量的数据，由小到大逐渐增加拥塞窗口的大小。
拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性规律缓慢增长。
快重传：我们可以剔除一些不必要的拥塞报文，提高网络吞吐量。比如接收方在收到一个失序的报文 段后就立即发出重复确认，而不要等到自己发送数据时捎带确认。快重传规定：发送方只要一连收 到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
快恢复：主要是配合快重传。当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞），但接下来并不执行慢开始算法，因为如果网络出现拥塞的话就不会收到好几个重复的确认，收到三个重复确认说明网络状况还可以。

9. HTTP常见的状态码有哪些？

2xx （3种）
200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；
206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。

3xx （5种）
301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；301与302的区别：前者是永久移动，后者是临时移动（之后可能还会更改URL）
303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；302与303的区别：后者明确表示客户端应当采用GET方式获取资源
304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；
307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）；

4xx （4种）
400 Bad Request：表示请求报文中存在语法错误；
401 Unauthorized：未经许可，需要通过HTTP认证；
403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；

5xx （2种）
500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；
503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

10. 状态码301和302的区别是什么？

共同点：301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地 址A瞬间变成了另一个地址B)。
不同点：301表示旧地址A的资源已经被永久地移除了(这个资源不可访问了)，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。 SEO中302好于301。
补充，重定向原因：

1. 网站调整（如改变网页目录结构）；
2. 网页被移到一个新地址；
3. 网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

11. HTTP 常用的请求方式？

GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。

12. GET请求和POST请求的区别？

get在浏览器回退时是无害的，而post会再次提交请求。
get产生的URL地址可以被Bookmark，而post不可以。
get请求会被浏览器主动cache，而post不会，除非手动设置。
get请求只能进行url编码，而post支持多种编码方式。
get请求参数会被完整保留在浏览器历史记录里，而post中的参数不会被保留。
get请求在URL中传送的参数是有长度限制的，而post么有。
对参数的数据类型，get只接受ASCII字符，而post没有限制。
get比post更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
get参数通过URL传递，post放在Request body中。

13. 什么是Http协议无状态协议?怎么解决Http协议无状态协议?

无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息
也就是说，当客户端一次HTTP请求完成以后，客户端再发送一次HTTP请求，HTTP并不知道当前客户端是一个”老用户“。可以使用Cookie来解决无状态的问题，Cookie就相当于一个通行证，第一次访问的时候给客户端发送一个Cookie，当客户端再次来的时候
拿着Cookie(通行证)，那么服务器就知道这个是”老用户“。

14. 进程通信方式？

每个进程各自有不同的用户地址空间,任何一个进程的全局变量在另一个进程中都看不到，所以进程之间要交换数据必须通过内核,在内核中开辟一块缓冲区,进程A把数据从用户空间拷到内核缓冲区,进程B再从内核缓冲区把数据读走,内核提供的这种机制称为进程间通信。
1 匿名管道通信:管道是一种半双工的通信方式，数据只能单向流动，而且只能在具有亲缘关系的进程间使用。进程的亲缘关系通常是指父子进程
关系。
2.有名管道 (named pipe) ： 有名管道也是半双工的通信方式，但是它允许无亲缘关系进程间的通信。
3.消息队列( message queue ) ： 消息队列是由消息的链表，存放在内核中并由消息队列标识符标识。消息队列克服了信号传递信息管道只能承载无格式字节流以及缓冲区大小受限等缺点。
4.信号量( semophore ) ： 信号量是一个计数器，可以用来控制多个进程对共享资源的访问。它常作为一种锁机制，防止某进程正在访问共享资源时,其他进程也访问该资源。因此，主要作为进程间以及同一进程内不同线程之间的同步手段。
5.信号 ( sinal ) ： 信号是一种比较复杂的通信方式，用于通知接收进程某个事件已经发生。
6.共享内存( shared memory ) ：共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。
7.套接字( socket ) ： 套接口也是一种进程间通信机制，与其他通信机制不同的是，它可用于不同机器间的进程通信。

15. UDP 和 TCP 对应的应用场景是什么？

TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：
FTP文件传输
HTTP / HTTPS
UDP 面向无连接，它可以随时发送数据，再加上UDP本身的处理既简单又高效，因此经常用于：
包总量较少的通信，如 DNS 、SNMP等
视频、音频等多媒体通信

16. HTTP 与 HTTPS 的区别？

17. HTTPS 的优缺点?

优点：**
安全性：
使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
SEO方面：谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
缺点：
在相同网络环境中，HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
HTTPS 的安全是有范围的，在黑客攻击、服务器劫持等情况下几乎起不到作用。
在现有的证书机制下，中间人攻击依然有可能发生。
HTTPS 需要更多的服务器资源，也会导致成本的升高。

18. 在浏览器中输入www.baidu.com后执行的全部过程？

1. 域名解析（域名 www.baidu.com 变为 ip 地址）。
   浏览器搜索自己的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的hosts文件（维护一张域名与IP的对应表）。若都没有，则找 tcp/ip 参数中设置的首选 dns 服务器，即本地 dns 服务器（递归查询），本地 域名服务器查询自己的dns缓存，如果没有，则进行迭代查询。将本地dns服务器将IP返回给操作
   系统，同时缓存IP。 2. 发起 tcp 的三次握手，建立 tcp 连接。浏览器会以一个随机端口（1024-65535）向服务端的 web程序 80 端口发起 tcp 的连接。
2. 建立 tcp 连接后发起 http 请求。
3. 服务器响应 http 请求，客户端得到 html 代码。服务器 web 应用程序收到 http 请求后，就开始处理请求，处理之后就返回给浏览器 html 文件。
4. 浏览器解析 html 代码，并请求 html 中的资源。
5. 浏览器对页面进行渲染，并呈现给用户。

19. cookie和session的区别？

(1)cookie数据存放在客户的浏览器上，session数据放在服务器上
(2)cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,如果主要考虑到安全应当使用session
(3)session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，如果主要考虑到减轻服务器性能方面，应当使用COOKIE
(4)单个cookie在客户端的限制是3K，就是说一个站点在客户端存放的COOKIE不能3K。
(5)所以：将登陆信息等重要信息存放为SESSION;其他信息如果需要保留，可以放在COOKIE中

20. 什么是 Cookie 和 Session ?

什么是 Cookie
HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面：
会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）
什么是 Session
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

21. Cookie 和 Session 是如何配合的呢？

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。
当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

22. 如何考虑分布式 Session 问题？

在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在 A 服务器登录了，第二次请求跑到服务 B 就会出现登录失效问题。
分布式 Session 一般会有以下几种解决方案：
客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息
Nginx ip_hash 策略：服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
Session 复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。
共享 Session：服务端无状态话，将用户的 Session 等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。建议采用共享 Session的方案

23. SQL注入是什么，如何避免SQL注入？

SQL 注入就是在用户输入的字符串中加入 SQL 语句，如果在设计不良的程序中忽略了检查，那么这些注入进去的 SQL 语句就会被数据库服务器误认为是正常的 SQL 语句而运行，攻击者就可以执行计划外的命令或访问未被授权的数据。
SQL注入的原理主要有以下 4 点
1.恶意拼接查询
2.利用注释执行非法命令
3.传入非法参数
4.添加额外条件
避免SQL注入的一些方法：
1.限制数据库权限，给用户提供仅仅能够满足其工作的最低权限。
2.对进入数据库的特殊字符（’”\尖括号&*;等）转义处理。
3.提供参数化查询接口，不要直接使用原生SQL。

24. 负载均衡算法有哪些？

多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，能互相分担负载。
轮询法：将请求按照顺序轮流的分配到服务器上。大锅饭，不能发挥某些高性能服务器的优势。
随机法：随机获取一台，和轮询类似。
哈希法：通过ip地址哈希化来确定要选择的服务器编号。好处是,每次客户端访问的服务器都是同一个服务器，能很好地利用session或者cookie。
加权轮询：根据服务器性能不同加权。

25. 详细介绍一下 TCP 的四次挥手过程？

26. 为什么连接的时候是三次握手，关闭的时候却是四次 握手？

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.
接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

27. 为什么客户端的 TIME-WAIT 状态必须等待 2MSL ？

主要有两个原因：

1. 确保 ACK 报文能够到达服务端，从而使服务端正常关闭连接。
   第四次挥手时，客户端第四次挥手的 ACK 报文不一定会到达服务端。服务端会超时重传 FIN/ACK报文，此时如果客户端已经断开了连接，那么就无法响应服务端的二次请求，这样服务端迟迟收不到 FIN/ACK 报文的确认，就无法正常断开连接。MSL 是报文段在网络上存活的最长时间。客户端等待 2MSL 时间，即「客户端 ACK 报文 1MSL 超 时 + 服务端 FIN 报文 1MSL 传输」，就能够收到服务端重传的 FIN/ACK 报文，然后客户端重传一
   次 ACK 报文，并重新启动 2MSL 计时器。如此保证服务端能够正常关闭。如果服务端重发的 FIN 没有成功地在 2MSL 时间里传给客户端，服务端则会继续超时重试直到断开连接。
2. 防止已失效的连接请求报文段出现在之后的连接中。
   TCP 要求在 2MSL 内不使用相同的序列号。客户端在发送完最后一个 ACK 报文段后，再经过时间2MSL，就可以保证本连接持续的时间内产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。或者即使收到这些过时的报文，也可以不处理它。

28. TIME_WAIT 是服务器端的状态?还是客户端的状态?

TIME_WAIT 是主动断开连接的一方会进入的状态，一般情况下，都是客户端所处的状态;服务器端一般设置不主动关闭连接。
TIME_WAIT 需要等待 2MSL，在大量短连接的情况下，TIME_WAIT会太多，这也会消耗很多系统资源。对于服务器来说，在 HTTP 协议里指定 KeepAlive（浏览器重用一个 TCP 连接来处理多个 HTTP 请求），由浏览器来主动断开连接，可以一定程度上减少服务器的这个问题。