计算机网络面试题

最新推荐文章于 2022-04-15 23:58:05 发布

夜ASK

最新推荐文章于 2022-04-15 23:58:05 发布

阅读量677

点赞数 1

分类专栏：面试题

本文链接：https://blog.csdn.net/qq_43791139/article/details/115306916

版权

面试题专栏收录该内容

2 篇文章 1 订阅

订阅专栏

#### 部分内容总结自微信公众号【小林coding】，部分为别人博客，部分为面试常考

HTTP推荐阅读的文章

太细了，我真背不会

Http

HTTP文章

HTTP 传输的【超文本】，超文本是文字、图片、视频等的混合体。

HTTP 是一个在计算机世界里专门在【两点】之间【传输】文字、图片、音频、视频等【超文本】数据的【约定和规范】

HTTP常见状态码

1xx

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

3xx

3xx 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

「302 Moved Permanently」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

4xx

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

HTTP常见字段

Host字段

客户端发送请求时，用来指定服务器的域名。

Host: www.A.com

Content-Length字段

Content-Length: 1000

服务器返回数据到浏览器时，会有Content-Length字段，表面本次回应的数据长度

Connection字段

Connection 字段最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。

Connection: keep-alive

HTTP/1.1 版本的默认连接都是持久连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。（后面会总结HTTP1.0、1.1、2.0、3.0的区别）

Content-Type字段

Content-Type字段用于服务器回应时，告诉客户端，本次数据是什么格式

Content-Type: text/html; charset=utf-8

上面的类型表明，发送的是网页，而且编码是UTF-8。

客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。

Accept: */*

上面代码中，客户端声明自己可以接受任何格式的数据。

Content-Encoding字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

Content-Encoding: gzip

上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。

客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

Accept-Encoding: gzip, deflate

GET和POST的区别

GET方法的含义就是从服务器获取资源，请求的参数暴露在URL中。由于反复读取不会对访问的数据有副作用，没有副作用被称为幂等性

POST 每次请求都会让服务器做一件事，比如重复添加某个订单，对服务器有副作用，所以没有幂等性，它向URL指定的资源提交数据，数据就放在报文的body里。

GET和POST有个重要的区别：GET产生一个TCP数据包，POST产生两个TCP数据包。对于Get请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）。而对于POST，浏览器先发送header，服务器响应100continue，浏览器再发送data，服务器响应200（返回数据）。

在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

URI与URL

一份钟速看

URI （统一资源标识符）三部分组成：1.访问资源的命名机制、2.存放资源的主机名、3.资源自身的名称，由路径表示

请求URI定位资源：HTTP协议使用URI定位互联网上的资源

URL（统一资源定位符）的格式：1.协议（或称为服务方式）、2.存有该资源的主机IP地址、3.主机资源的具体地址

个人的身份证号就是URN，个人的家庭地址就是URL，URN可以唯一标识一个人，而URL可以告诉邮递员怎么把货送到你手里。

cookie和sesssion的区别？

http是无状态地，但是有的时候服务需要识别客户端的身份，这个时候cookie出现了；浏览器在访问服务后，服务器会生成cookie或者session，浏览器均以cookie的形式存储下来（session一般是把sessionId当成cookie存在cookie中，具体的数据是保存在服务器端的，浏览器请求时会带上sessionId，服务器通过sessionId查询数据），session的默认有效期是浏览器的会话期以及服务设置的session有效期的最短时间；大部分session保存在内存中，cookie保存在用户本地电脑中。

HTTP特性和各版本区别

HTTP 基本的报文格式就是 header + body，头部信息也是 key-value。

灵活，易于扩展，HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，允许开发人员自定义和扩充。

HTTP 不安全：通信使用明文传输（不加密），内容可能会被窃听。

HTTP1.0：HTTP协议是基于TCP/IP，最大的缺点就是每次发起一个请求就要建立一次TCP连接（三次握手），而且是串行请求，做了无畏的TCP连接和断开，增加了通信开销。

HTTP1.1：发送纯文本形式的报文，为了解决1.0的缺点，HTTP1.1提出了长连接的通信方式。（引入Cookie技术，有了Cookie，和HTTP协议通信，就可以管理状态了）

由于采用长连接，这使得管道（pipeline）网络传输称为了可能，即可在一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发送第二个，减少整体的响应时间。但服务器还是按照顺序，先回应A请求，完成后再回应B请求。要是前面的回应特别慢，后面就会有许多请求排队等着，这就是【队头阻塞】（缺点）

缺点：请求/响应头部（Header）未经压缩就发送，首部信息越多延迟越大，只能压缩Body部分。发送冗长的首部，每次互相发送相同的首部造成的浪费较多。

HTTP2.0：HTTP2.0协议是基于HTTPs的，会压缩头（Header）如果你同时发出多个请求，头相似的会被协议消除重复的分。这就是HPACK算法（在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，这样就提高速度了），HTTP2不再像HTTP1.1里纯文本形式，而是全面采用二进制格式。

头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

数据流：HTTP/2的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包，称为一个数据流（Stream）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数

多路复用：HTTP2.0是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应，移除了HTTP1.1中的串行请求，不需要排队等待，也就不会再出现【队头阻塞】问题，**降低了延迟，大幅度提高了连接的利用率。**举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

服务器推送：HTTP2.0在一定程度上改善了传统的【请求-应答】工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

HTTP/2 主要的问题在于：多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。

所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
TL3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。
HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

请求消息的结构：

一个请求消息是由请求行，请求头字段，一个空行和消息主体构成。

消息主体是响应消息的承载数据。

**客户端：**发送请求

客户端发送给某个HTTP服务器端的请求报文中的内容

GET/HTTP/1.1
Host: hackr.jp

服务器：发送响应

HTTP/1.1 200 OK
Date: Tue, 10 Jul ...
Content.Length: 362
Content.Type: text/html
<html>
...

HTTP首部字段博客

general header（通用首部字段）请求报文和响应报文两方都会使用的首部.

request-header fields（请求首部字段）从客户端向服务器端发送请求报文时使用的首部.补充了请求的附加内容、客户端信息、响应内容相关优先级等信息.

response-header fields（响应首部字段）从服务器端向客户端返回报文时使用的首部.补充了响应的附加内容,也会要求客户端附加额外的内容信息.

Entity-header fields（实体首部字段）针对请求报文和响应报文的实体部分使用的首部.补充了资源内容更新时间等与实体有关的信息

请求报文是由请求方法，请求URL，协议版本，可选的请求首部字段和内容实体构成的。

响应报文由协议版本，状态码，响应的首部字段，以及实体主体构成。

HTTP与HTTPS的区别

Http是超文本传输协议，信息是明文传输，存在安全风险的问题。Https则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。

Http连接建立相对简单，TCP三次握手之后便可进行Http的报文传输。而Https在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输。

Http的端口号是80，Https的端口号是443。

Https协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS的加密方式

Https加密文章

混合加密的方式实现信息的机密性，解决了窃听的风险

摘要算法的方式来实现完整性，它能够为数据生成独一无二的【指纹】，指纹用于校验数据的完整性，解决了纂改的风险。

将服务器公钥放到数字证书中，解决了窃听的风险

混合加密（没有很安全）

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法

摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

数字证书（安全）

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

浏览器输入url加载页面，会用到计网哪层，每层是干什么的

1.查找域名对应的IP地址。（如果在缓存里面找不到IP地址，就会DNS解析域名得到IP地址）这一步会依次查找浏览器缓存，系统缓存，路由器缓存，ISPNDS缓存，根域名服务器

2.浏览器向IP对应的web服务器发送一个HTTP请求（会负载均衡，当一台服务器无法支持大量用户访问，将用户分摊两个或多个服务器上的方法叫负载均衡）

3.服务器响应请求，返回网页内容

4.浏览器解析网页内容

##### 用到计网哪层

浏览器要将URL解析成IP地址，解析域名需要用到DNS协议，首先主机会查询DNS缓存，如果没有就给本地DNS发送查询请求。DNS查询分为两种，一种是递归查询，一种是迭代查询。如果是迭代查询，本地的DNS服务器，向根服务器发送查询请求，根域名服务器告知该域名的一级域名服务器，然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址。DNS服务器是基于UDP的，因此会用到UDP协议

有了IP地址，浏览器与服务器建立http连接，用到http协议，http生成一个get请求报文，将该报文传给TCP处理，所以还会用到TCP协议。如果采用https还会使用https先对http数据进行加密。tcp的数据包然后会发送给IP层，用到IP协议。IP层通过路由选路，一跳一跳发送到到目的地址。当然在一个网段内的寻址是通过以太网协议实现，以太网协议需要直到目的IP地址的物理地址，有需要ARP协议。

IP、ARP协议是网络层，tcp、udp是传输层，http是应用层

ping命令的实现原理， ICMP协议查看远程服务器的原理。

Ping命令是基于ICMP协议工作的，

ICMP功能：确认IP包是否能成功送达目标地址、报告发送过程中IP包被废弃的原因和改善网络设置等。

ICMP报文格式：ICMP报文包含在IP数据报中，IP报头在ICMP报文的最前面。

DNS与ARP协议

DNS是域名解析为ip地址的。

ARP是地址解析协议，用于实现IP地址到MAC地址的映射，mac地址是硬件地址，用来定义网络设备的位置，主要由数据链路层负责。而IP地址是IP协议提供的一种统一的地址格式，为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异

TCP与UDP区别

TCP和UDP都是OSI模型中的运输层的协议。TCP提供可靠的通信传输，而UDP则常被用于让广播。

两者大致区别：

TCP面向连接，UDP面向非连接即发送数据前不需要建立连接

TCP提供可靠的服务（数据传输），UDP无法保证

TCP面向字节流，UDP面向报文

TCP数据传输慢，UDP数据传输快

TCP和UPD表头结构

文章可读

TCP 表头大小为20字节到60字节

首部字段很简单，只有8个字节，由4个字段组成，每个字段的长度都是2个字节。
UDP报头结构：携带数据大小长度 - 8

TCP粘包

如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；

从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。

一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。

发送方产生粘包

采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。

总结：要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。

接收方产生粘包

接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。

总结：接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

如何避免粘包

在每个包的末尾加上特殊字符，用以区分连续的两个包

在报文首部添加包的长度

TCP与UDP的应用场景

TCP：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，HTTP、HTTPS、FTP等传输文件的协议会使用到。

UDP：当强调传输性能而不是传输的完整性时，要求网络通讯速度能尽量的快，：如QQ语音，QQ视频等

TCP如何保证可靠传输

可以看一下文章理解

确认机制、重传机制、滑动窗口。

确认机制：发送的数据包二进制相加然后取反，**目的是检测数据在传输过程中的任何变化。**如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到次报文段。

超时重传：当TCP发送一个段后，它启动一个定时器，等待目的端确认和收到这个报文段，如果不能及时收到一个确认，将重发这个报文段。

流量控制：TCP连接的每一方都有固定大小的缓存空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变的滑动窗口协议。

拥塞控制：当网络拥塞时，减少数据的发送。有：慢启动、拥塞控制、快重传、快恢复

TCP流量控制

流量控制是为了控制发送端发送数据的速率，保证接收端能将本应接收的所有报文分组接收成功，否则会触发自动重传机制造成网络流量的浪费。

流量控制的具体操作是：接收端会通知发送端自己能接收的数据大小，于是发送端会发送不超过这个数据量的数据，这个大小被称为“窗口”的大小，在TCP首部中专门有一个字段表示“窗口”的大小，该值越大代表网络的吞吐量越高。

TCP拥塞控制

拥塞控制文章

慢开始：假设当前发送方拥塞窗口cwnd的值为1，发送窗口swnd等于拥塞窗口cwnd，因此发送方当前只能发送一个数据报文段，（拥塞窗口cwnd的值是几，就能发送几个数据报文段），接收方收到该数据报文段后，给发送方回复对应的一个确认报文段。发送方收到该确认报文段后，将拥塞窗口的值变为以前的2倍。

当前拥塞窗口cwnd值等于慢开始门限值，就会改用拥塞避免算法。

拥塞避免：每个传输轮次，拥塞窗口cwnd只能线性加一，而不是像慢开始算法时，每个传输轮次，拥塞窗口cwnd按值数增长。假如：发送方发送了24个报文段，接收方只收到了20个报文段，给发送方回复20个确认报文，一段时间后，丢失的4个报文段的重传计时器超时了，发送方判断可能出现拥塞，就会将拥塞cwnd窗口设为1，慢开始门限ssthresh为拥塞窗口的一半。

快重传：假如发送方按顺序发送的是1到6的六个报文段，接收方回复了1和2的确认报文段，丢失了3，接收方又收到了4号报文段，每次接收到报文段，发现不是3号报文段，就会发送前一个报文段的确认号也就是2，发送方连续收到三次2号报文段的确认报文段就会重传3号报文段。接收方收到3号报文段后，就会发送6号报文段的确认确认报文段，代表1到6号报文段都受到了。

TCP对应的协议和UDP对应的协议

TCP：

FTP：定义了文件传输协议，使用21端口

HTTP：是Web服务器传输超文本到本地浏览器的传输协议，端口默认80

SMTP：邮件传送协议，用于发送邮件。服务器开放的是25号端口

UDP：

DNS：用于域名解析服务，将域名地址转换为IP地址，DNS用的是53号端口

TFTP：简单文件传输协议，该协议在熟知端口69上使用UDP服务

面向连接与非面向连接区别

面向连接的服务，通信双方在进行通信之前，要先在双方建立起一个完整的可以彼此沟通的通道，在通信过程中，整个连接的情况一直可以被实时地监控和管理。

非面向连接地服务，不需要预先建立一个联络两个通信节点地连接，需要通信地时候，发送节点就可以往网络上发送信息，让信息自主地在网络上去传，一般在传输地过程中不再加以监控。

TCP三次握手

很好的文章

最开始客户端和服务端都是关闭状态，先打开的是客户端，被动打开的服务端，TCP服务器先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；

TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同步位SYN=1，同时初始化序列号seq=x，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段不能携带数据，但需要消耗一个序号。

TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该ACK=1，SYN=1，确认号是ack=x+1，自己初始化一个序列号seq=y，此时，TCP服务器进程进入SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但要消耗一个序号。

TCP客户进程收到确认后，还要向服务器给出确认，确认报文的ACK=1，ack=y+1，自己的序号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，如果不携带数据，就不消耗序列号。

为什么TCP客户端最后还要发送一次确认呢

主要为了防止已经失效的连接请求报文突然又传送到服务器，从而产生错误。

如果是两次握手建立连接，假设有这样的场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络节点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

TCP四次挥手

数据传输完毕后，双方都可以释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗ MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

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

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

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

为什么建立连接是三次握手，关闭连接是四次握手？

建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了，但还是可以接收数据，而自己也未必全部数据都发送对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没有反应，服务器就认为客户端出了故障，接着就关闭连接。