**程序员：**因为UDP把数据传输过去就不管了，就假定接收方一定能接收到，可惜真实的网络环境不会如此单纯，甚至是复杂、残酷的。
在网络环境中无时无刻出现着丢包、阻塞、乱序的情况，一个不小心，数据可能就传输不到目的地了，这个时候就只能轮到TCP了
**面试官：**为什么TCP就可靠了呢？
**程序员：**就是因为它的“三次握手”和“四次挥手”哇！
**面试官（邪魅一笑）：**那你来讲讲吧！
**程序员：**那您且细听分说
三次握手
**程序员：**这个“三次握手”就是通信建立链接的一个过程，看下图
通俗点讲就是：
客户端：你好，我是客户端
服务端：你好，客户端，我是服务端
客户端：你好，服务端
也经常把这个过程叫做“请求->响应->响应的响应”
**面试官：**打断一下，问个问题，为什么不是两次或者四次，非得是三次呢？
**程序员：**嗯，不错，是个称职的面试官！
试想一下，客户端发送一个连接，由于丢包、超时，或是服务端根本就不想建立连接，那这个时候客户端怎么办？
客户端并不能知道结果，就只有重复的发送连接请求，虽然这个时候服务端接收到了，但客户端仍不知道这事，只能继续发请求。
此时此刻，服务端接收了客户端的请求，当然知道了客户端的存在，如果服务端不同意建立连接，客户端重试几次后就会放弃，没问题。
**如果服务端愿意建立连接呢？**这个时候就会发送响应给客户端（好了，你别叫唤了，客户端我知道你了）
到了这一步，就已经进行了两次握手！理论上，这个时候已经可以进行连接了，但是问题来了：
因为对于服务端来说，这个响应的过程也可能会丢包，不一定会达到客户端，甚至客户端完全挂了都是可能的。
对于另外的情况，在第一次握手的时候，由于网络问题，客户端向服务端发送了多个建立连接的请求，假设其中某一个建立成功，做了简单的通信，然后结束了连接，本来很正常，但是另外一些请求由于网络的延迟又到了服务端，服务端会认为这是一个正常的请求，接下来又建立连接。
因此两次握手会有着种种问题。
为了保证服务端的响应能正确接收，客户端还是需要告诉给服务端，我收到了服务端的响应，也就是给服务端一个**“响应的响应”，这样就是三次握手了**。
**面试官：**要是这个“响应的响应”要是也出现了丢包等问题没有送到呢？
**程序员：**你存心找麻烦的吧？那照你这样说你就是手握烂了，也没办法保证消息100%可靠。三次握手，保证服务端、客户端双方都确认了对方存在就足够了。
四次挥手
**面试官：**嗯，不错，来说说“四次挥手”又是什么吧！
**程序员：**建立完连接后就可以传输数据了，传输完成后则需要四次挥手来告别，过程看下图
**面试官：**这你TMD没有上一张清晰啊！
**程序员：**哎呀~面试时间有限，将就着看看啦！
通俗来讲就是…
客户端：服务端啊，我要和你拜拜了
服务端：好的，我知道了
这个时候，客户端说了拜拜，也不会向服务端发送数据了，这个时候服务端是否能马上关闭呢？
总结
总的来说，面试是有套路的，一面基础，二面架构，三面个人。
最后，小编这里收集整理了一些资料，其中包括面试题（含答案）、书籍、视频等。希望也能帮助想进大厂的朋友，点击这里即可免费获取
50)]
[外链图片转存中…(img-eASSdv3M-1628420590651)]
[外链图片转存中…(img-wNPicIs0-1628420590651)]