大家好，我是鸭鸭！
大中午打开电脑想看看今天有什么新鲜事儿，没想到刷到美团履约团队也开始推行全栈模式了。
终端组的部分前端同学，在 11 月末的时候转到了后端组做全栈。主要是 agent 相关项目。
可能大家还有点印象，9月初的时候，菜鸟国际的后端研发转全栈，要参与前端和测试工作。
11 月的时候，剪映也传出过消息，要准备人均全栈。
这下真的是拥抱 AI，人均全能选手了。
鸭鸭也看到有人疑问，这么多公司的团队都在转全栈，全栈真的能提升效率吗？
客观上还是有提升的。
一来是不需要和人沟通需求，前后端接口自己就能对上，少了很多中间的扯皮阶段；
二来是有 AI 辅助，整体效率是提升的。
三来，也没人不让你加班对吧！
不知道除了履约团队外，美团是否还会将全栈化推行到其他部门。
另外鸭鸭也看到不少小公司，现在也开始全栈化。
目前看起来，各家大厂对 AI 辅助下的全栈化还是比较谨慎的，美团这次也会严格地把控上线的代码。
只能说，在 AI 浪潮下，大家都在做一些新的尝试。
……
今天分享一篇 Java 美团一面（校招）的面经。
篇幅有限，完整答案可以进入面试鸭 - 程序员求职面试刷题神器，高频编程题目免费刷进行查阅。
TCP 如何建立连接？
客户端首先发送一个SYN（同步序列编号）消息给服务器，服务器收到后回复一个SYN-ACK（同步序列编号-确认）消息，最后客户端再发送一个ACK（确认）消息确认服务器已经收到SYN-ACK消息，从而完成三次握手，建立起一个可靠的TCP连接。
来看下这个图：
三次握手可以减少么？减少一次会怎么样？最终导致的结果是什么？
不可以减少。有两个原因：
- 避免历史错误连接的建立，减少通信双方不必要的资源消耗
- 帮助通信双方同步初始化序列号
避免历史错误连接的建立
RFC 793 明确指出了使用三次握手的首要原因是：为了阻止历史的重复连接初始化导致的混乱。
为什么三次能阻止这个问题？
实际上很好理解。
因为网络情况比较复杂，发送方第一次发送请求后，可能由于网络原因被阻塞住了，此时发送方可能又会再次发送请求。
如果握手只有两次，那么接收方应对发送方的请求只能拒绝或者接受，但是它无法识别当前的请求是旧的请求还是新的请求。
并且如果网络阻塞时间较长，发送方可能多次发送请求，且接收方还可能全部接受这些连接（它不清楚，以为都是有效的），这就造成了不必要的资源的浪费。
如果要避免这种情况发生，两次通信是不够的。发送方需要知晓接收方到底接受了哪个连接，如果接受的是老连接，那么发送方需要告知接收方，这个连接不对！也就是 RST 通知。如果对，那么就返回 ACK 告诉接收方 OK！这就使得一次握手至少需要 3 次。
因此三次握手，多了一次发送方确认接收方接受的连接是否正确的验证过程，所以避免了历史重复连接的错误情况。
扫一扫
1718
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
