Java 岗大厂面试百日冲刺 - 日积月累，每日三题【Day6】 —

四次挥手即终止 TCP 连接，就是指断开一个 TCP 连接时，需要客户端和服务端总共发送 4 个包以确认连接的断开。在 socket 编程中，这一过程由客户端或服务端任一方执行 close 来触发。

由于 TCP 连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个 FIN 来终止这一方向的连接，收到一个 FIN 只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个 TCP 连接上仍然能够发送数据，直到这一方向也发送了 FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。

四次挥手理论流程

• 中断连接端可以是客户端，也可以是服务器端。

• 第一次挥手：客户端发送一个 FIN=M，用来关闭客户端到服务器端的数据传送，客户端进入 FIN_WAIT_1 状态。意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。

• 第二次挥手：服务器端收到 FIN 后，先发送 ack=M+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入 FIN_WAIT_2 状态，继续等待服务器端的 FIN 报文。

• 第三次挥手：当服务器端确定数据已发送完成，则向客户端发送 FIN=N 报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入 LAST_ACK 状态。

• 第四次挥手：客户端收到 FIN=N 报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以发送 ack=N+1 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。服务器端收到 ACK 后，就知道可以断开连接了。客户端等待了 2MSL 后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。

深入追问：

追问 1：为什么连接的时候是三次握手，关闭的时候却是四次握手？

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

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

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

若一连发送 10 个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

面试题 2：常见的 HTTP 状态码有哪些？

==================================================================================

正经回答：

HTTP 状态码表示客户端 HTTP 请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。

状态码的类别：

| 状态码 | 原因 |

| --- | --- |

| 1XX | Informational（信息性状态码） 接受的请求正在处理 |

| 2XX | Success（成功状态码） 请求正常处理完毕 |

| 3XX | Redirection（重定向状态码） 需要进行附加操作以完成请求 |

| 4XX | Client Error（客户端错误状态码） 服务器无法处理请求 |

| 5XX | Server Error（服务器错误状态码） 服务器处理请求出错 |

| 状态码 | 原因 |

| --- | --- |

| 2XX | 成功（这系列表明请求被正常处理了） |

| 200 | OK，表示从客户端发来的请求在服务器端被正确处理 |

| 204 | No content，表示请求成功，但响应报文不含实体的主体部分 |

| 206 | Partial Content，进行范围请求成功 |

| 状态码 | 原因 |

| --- | --- |

| 3XX | 重定向（表明浏览器要执行特殊处理） |

| 301 | moved permanently，永久性重定向，表示资源已被分配了新的 URL |

| 302 | found，临时性重定向，表示资源临时被分配了新的 URL |

| 303 | see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源 |

| 304 | not modified，表示服务器允许访问资源，但请求未满足条件的情况（与重定向无关） |

| 307 | temporary redirect，临时重定向，和 302 含义类似，但是期望客户端保持请求方法不变向新的地址发出请求 |

| 状态码 | 原因 |

| --- | --- |

| 4XX | 客户端错误 |

| 400 | bad request，请求报文存在语法错误 |

| 401 | unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息 |

| 403 | forbidden，表示对请求资源的访问被服务器拒绝，可在实体主体部分返回原因描述 |

| 404 | not found，表示在服务器上没有找到请求的资源 |

| 状态码 | 原因 |

| --- | --- |

| 5XX | 服务器错误 |

| 500 | internal sever error，表示服务器端在执行请求时发生了错误 |

| 501 | Not Implemented，表示服务器不支持当前请求所需要的某个功能 |

| 503 | service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求 |

面试题 3：先说说 GET 和 POST 请求有哪些区别吧？

========================================================================================

正经回答：

1. GET 请求在 URL 中传送的参数是有长度限制的，而 POST 没有。

2. GET 比 POST 更不安全，因为参数直接暴露在 URL 上，所以不能用来传递敏感信息。而 POST 数据不会显示在 URL 中。是放在 Request body 中。

3. 对参数的数据类型，GET 只接受 ASCII 字符，而 POST 没有限制。

4. GET 请求参数会被完整保留在浏览器历史记录里；相反，POST 请求参数也不会被浏览器保留。

5. GET 请求只能进行 url 编码（application/x-www-form-urlencoded），而 POST 支持多种编码方式。

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

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

深入追问：

追问 1：那 Get 请求有 Request body 么？如果有的话参数可以像 Post 请求一样放在里面么？

其实吧，GET 和 POST 在本质上没有区别，都是 HTTP 协议中的两种发送请求的方法。而 HTTP 呢，是基于 TCP/IP 的关于数据如何

【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

在万维网中如何通信的协议。

万维网：简称 WWW，是 World Wide Web 的简称，也称为 Web、3W 等

HTTP 的底层是 TCP/IP。所以 GET 和 POST 的底层也是 TCP/IP，也就是说，GET/POST都是TCP链接。

GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。

• 举个例子吧：

TCP 就像汽车，我们用 TCP 来运输数据，它很可靠，从来不会发生丢件少件的现象。

但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。

为了避免这种情况发生，交通规则 HTTP 诞生了。HTTP 给汽车运输设定了好几个服务类别，包括 GET, POST, PUT 等等，

HTTP 规定，当执行 GET 请求的时候，要给汽车贴上 GET 的标签（设置 method 为 GET），而且要求把传送的数据放在车顶上（url 中）以方便记录。

如果是 POST 请求，就要在车上贴上 POST 的标签，并把货物放在车厢里（request body 中）。

当然，你也可以在用 GET 的时往车厢内偷偷藏点货物，但这并不不光彩；也可以在 POST 的时候在车顶上也放一些数据，也会让人觉得傻乎乎的。

HTTP 只是个行为准则，而 GET 和 POST 本质上就是 TCP 链接，并无差别。但是由于 HTTP 的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

追问 2：那你刚才说的 URL 中传送参数的长度限制在 Get 和 Post 中都是怎么样的呢？

其实在 Web 中啊，还有另一个重要的角色：运输公司。

不同的浏览器 Client 端（发起 http 请求）和服务器 server 端（接受 http 请求）就是不同的运输公司。

虽然理论上，你可以在车顶上无限的堆货物（url 中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。

业界不成文的规定是：（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。

超过的部分，恕不处理。如果你用 GET 服务，在 request body 偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略。

所以，虽然 GET 可以带 request body，却不能保证一定能被接收到。

??我之前处理过一个 bug，用户反应查询没有响应，同事查了日志后才发现有几个参数都是 undefined，很奇怪，最后发现原来是因为 Get 请求第一个查询参数太长了，导致 URL 后面的部分服务器无法接收 ，后来把请求改成 post，将参数放在 request body 后就可以了。

追问 3：那么你知道 Get、Post 请求发送的数据包有什么不同吗？

嗯嗯，是这样的，GET 请求时产生一个 TCP 数据包；POST 请求时产生两个 TCP 数据包。

• GET：浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；

• POST：浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 OK（返回数据）。

就像是 GET 只需要汽车跑一趟就把货送到了，而 POST 得跑两趟，第一趟，先去和服务器打个招呼“老铁，我等下要送一批货来，你们准备接收一下哈”，然后再回头把货送过去。

因为 POST 需要两步，理论上时间上消耗的要多一点，看起来 GET 比 POST 更有效。但并不是，后来发现原来是个坑。在我看来：

1. GET 与 POST 都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的 TCP 在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在 POST 中发送两次包，Firefox 就只发送一次。我去年用 Chrome 浏览器测试发现也是只发送一次，所以我认为 Get、POST 性能差可以人为忽略。