大厂面试突击必备：“网络编程”高频八连击，扛得住吗？

面试题 1：说一下 TCP 连接的三次握手和四次挥手吧

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

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

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

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

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

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

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

面试题 1：说一下 TCP 连接的三次握手和四次挥手吧？

正经回答：

握手：TCP 连接 挥手：TCP 断开

三次握手：

首先，三次握手的本质是确认通信双方（Client 端、Server 端）收发数据的能力；

三次握手其实就是指：建立一个 TCP 连接时，需要客户端和服务器总共发送 3 个包，通过这三个请求包，来确认双方（Client、Server）的接收能力和发送能力是否正常，同时，指定自己的初始化序列号为后面的可靠性传送做准备。实质上就是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。

注：刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

三次握手（连接）流程白话文介绍：

我和女朋友养了一只信鸽来传信，今天我要试一试好不好使，不好使晚上我就准备吃烧烤。

第一次握手：我把信（第一封信）绑在鸽子腿上发给女朋友，如果女朋友收到了，就确定了我的发件能力和她的收件能力没问题；

第二次握手：然后女朋友给我回信（第二封信），我如果收到了，说明我的收件能力和她的发件能力没问题；

第三次握手：然而此时女朋友还不知道她的发件能力和我的收件能力是否正常；因此我还要给他发（第三封信）说明，收到后最终决定晚上去吃烤鱼。

信鸽：真 tm 累，你们手机都是假的吧。

​

三次握手理论流程：

第一次握手：客户端将标志位 SYN 置为 1，随机产生一个值 seq=J，并将该数据包发送给服务器端，客户端进入 SYN_SENT 状态，等待服务器端确认。

第二次握手：服务器端收到数据包后由标志位 SYN=1 知道客户端请求建立连接，服务器端将标志位 SYN 和 ACK 都置为 1，ack=J+1，随机产生一个值 seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入 SYN_RCVD 状态。

第三次握手：客户端收到确认后，检查 ack 是否为 J+1，ACK 是否为 1，如果正确则将标志位 ACK 置为 1，ack=K+1，并将该数据包发送给服务器端，服务器端检查 ack 是否为 K+1，ACK 是否为 1，如果正确则连接建立成功，客户端和服务器端进入 ESTABLISHED 状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

四次挥手：

四次挥手即终止 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 请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。

状态码的类别：

​

​

​

​

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

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

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

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

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

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

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

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

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

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

万维网：简称 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 更有效。但并不是，后来发现原来是个坑。在我看来：

GET 与 POST 都有自己的语义，不能随便混用。 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的 TCP 在验证数据包完整性上，有非常大的优点。 并不是所有浏览器都会在 POST 中发送两次包，Firefox 就只发送一次。我去年用 Chrome 浏览器测试发现也是只发送一次，所以我认为 Get、POST 性能差可以人为忽略。