美团校招面经与TCP连接解析
我们最近分享了 小红书开奖 、影石开奖 、菜鸟开奖 ，秋招进行到现在，已经有不少同学收到了 offer。
美团这两天也在开奖了。不过目前观察下来，今年白菜比例似乎比去年要多一些，sp 和 ssp 的爆料并不多。给大家整理了一下目前爆料的各岗位开奖情况：
- 产品，18k*15.5
- 后端开发，23k*15.5
- 后端开发，30k*15.5，ssp
- 前端开发，23k
- 数据开发，，23k*15.5
- 算法，48k，无签字费，有股票
鸭鸭看了一些爆料帖，在已经开奖的部门里，酒旅大白菜开的比较多，点评听说有同学开了，但大部分同学反馈都还没开；闪购、骑行、金服等部门陆陆续续有同学反馈开奖。
不过目前观察下来，今年白菜比例似乎比去年要多一些，sp 和 ssp 的爆料并不多。
从已经开奖的爆料来看，今年校招薪资和去年整体差别不大。**不过今年邮件是连薪资一起发的，不能议价。**有些同学觉得薪资不符合预期，加上美团需要 7 天内签三方，毁约就得等明年才能解约，所以直接拒了。
也有听到小道消息说，越晚开奖的可能薪资越高。所以还没消息的同学也不用太着急。特别是已经接到保温电话的同学，基本这两周就会有结果。
美团对新人还是比较友好的。有不少培训，内部技术文档能学到不少东西，工作强度尚可，节假日该发的礼盒也不少。还有一些零星的小福利，像是外卖券、单车券。开水里加的“糖”也不少。
鸭鸭也刷到不少还在犹豫要不要接美团 offer 的同学，开水加糖，甜不甜，既看“糖”给没给够，也看你渴不渴。
对于有的的同学来说，美团的大厂光环，加上相对融洽的团队氛围，让它甜得恰到好处；但对手握其他 offer 和意向的卷王来说，这杯“水”可能就有些寡淡了。
……
今天分享一篇 Java 美团一面（校招） 面经：
篇幅有限，完整答案可以进入 面试鸭 进行查阅。
TCP 如何建立连接？
具体流程文字描述就是：客户端首先发送一个SYN（同步序列编号）消息给服务器，服务器收到后回复一个SYN-ACK（同步序列编号-确认）消息，最后客户端再发送一个ACK（确认）消息确认服务器已经收到SYN-ACK消息，从而完成三次握手，建立起一个可靠的TCP连接。
来看下这个图：
三次握手可以减少么？减少一次会怎么样？最终导致的结果是什么？
RFC 793 明确指出了使用三次握手的首要原因是：为了阻止历史的重复连接初始化导致的混乱。
因为网络情况比较复杂，发送方第一次发送请求后，可能由于网络原因被阻塞住了，此时发送方可能又会再次发送请求。
如果握手只有两次，那么接收方应对发送方的请求只能拒绝或者接受，但是它无法识别当前的请求是旧的请求还是新的请求。
并且如果网络阻塞时间较长，发送方可能多次发送请求，且接收方还可能全部接受这些连接（它不清楚，以为都是有效的），这就造成了不必要的资源的浪费。
如果要避免这种情况发生，两次通信是不够的。发送方需要知晓接收方到底接受了哪个连接，如果接受的是老连接，那么发送方需要告知接收方，这个连接不对！也就是 RST 通知。如果对，那么就返回 ACK 告诉接收方 OK！这就使得一次握手至少需要 3 次。
因此三次握手，多了一次发送方确认接收方接受的连接是否正确的验证过程，所以避免了历史重复连接的错误情况。
四次挥手如果没有最后一次会怎么样？会导致什么后果？
四次挥手主要是为了确保数据完整性。
TCP 是一个全双工协议，也就是说双方都要关闭，每一方都向对方发送 FIN 和回应 ACK。
客户端发起连接断开，代表客户端没数据要发送的，但是服务端可能还有数据没有返回给客户端。
就像我对你说我数据发完了，然后你回复好的你收到了。然后你对我说你数据发完了，然后我向你回复我收到了。这样才能保证数据不会丢失。
所以一个 FIN + ACK 代表一方结束数据的传输，因此需要两对 FIN + ACK，加起来就是四次通信。
如果 Client 发送 FIN 给 server 的时候 server 已经没数据发送给 Client 了，那么 Server 就可以将 ACK 和它的 FIN 一起发给 Client ，这样一来不就变成三次挥手了吗？
服务端可以断开连接么？
可以。
1）RST标志：
- 使用 TCP RST 标志可以强制立即终止连接。发送方可以直接发送带有 RST 标志的 TCP 报文，通知对方立即断开连接。
2）超时：
- 如果连接一段时间内没有任何数据包传输，连接双方可以依据设定的超时时间自动断开连接。
3）四次挥手
扫一扫
551
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
