SimbaChoos...：建议楼主主要考虑三个点： 1. 没有前景：所有行业的存在都是有需求才会出现的，各行业的top都是很有竞争力的，每个行业领域内也有细分，建议多了解一下未来可能的出路。 2. 待遇还行：对比的是行业内平均水平还是其他行业，待遇一部分靠行业红利，但是绝大部分因素与个人努力有关，如果待遇水平和自身努力程度相距甚远，建议考虑换份工作，树挪死，人挪活，好的公司多的是，人有本事到哪里都不会饿死。 3.辞职：没有特殊情况建议不要裸辞，如果不满意，可以骑驴找马，找工作是一件费时费力的事情，说白了就是从一个坑跳到另外一个坑的过程，它们的差别也只是坑的深浅不同。 ps：其实这个选择只能自己决定，需要考虑个人（能力，性格爱好和职业规划）和家庭因素，如人饮水，冷暖自知，自己的情况只有自己知道，没有什么工作是十全十美的，关键是看楼主所在意的点是什么，也许等这个投票帖子截止，楼主点进来看答案的那一刻，最渴望看到的就是楼主内心想遵循的选择。

七层楼：我觉得实习对工作的作用真的很大，身边去了大厂实习的童鞋基本毕业也能去大厂，反之则很少

BNDSBilly：拥塞控制：防止过多数据注入网络，保证网络中的路由器和链路不过载。对通信连接的端点来说，只有通过通信时延的增加判断是否发生拥塞。要防止过多的数据注入到网络中，一般有四种算法：慢开始算法（TCP刚连接好时，令拥塞窗口为1，每收到一个新报文段确认时，令窗口加1，逐步增大。表现在实际中，每次加倍，直到达到初始化的阈值然后开始每次加1）、拥塞控制算法（一旦网络拥塞就从1开始，但阈值变为当前拥塞窗口值的一半） ·另外两种算法是快重传算法（发送方连续收到三个冗余ACK直接重传，不必等待计时器）和快恢复算法（每次拥塞则阈值变为一半，但是窗口从新阈值开始直接每次加1，跳过了从1开始的过程）。 ·总体来说，流量控制中发送方的数据发送量由接收方决定，而拥塞控制中由发送方自己决定。发送方检测到超时就慢开始+拥塞避免，收到冗余ACK时则采取快重传和快恢复。但实际窗口是接收窗口和拥塞窗口的较小值。查看图片

肖先生~：什么是TCP粘包问题？ TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。 造成TCP粘包的原因 （1）发送方原因 TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事： 只有上一个分组得到确认，才会发送下一个分组 收集多个小分组，在一个确认到来时一起发送 Nagle算法造成了发送方可能会出现粘包问题 （2）接收方原因 TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。 什么时候需要处理粘包现象？ 如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象 如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了 如何处理粘包现象？ （1）发送方 对于发送方造成的粘包问题，可以通过关闭Nagle算法来解决，使用TCP_NODELAY选项来关闭算法。 （2）接收方 接收方没有办法来处理粘包现象，只能将问题交给应用层来处理。 （2）应用层 应用层的解决办法简单可行，不仅能解决接收方的粘包问题，还可以解决发送方的粘包问题。 解决办法：循环处理，应用程序从接收缓存中读取分组时，读完一条数据，就应该循环读取下一条数据，直到所有数据都被处理完成，但是如何判断每条数据的长度呢？ 格式化数据：每条数据有固定的格式（开始符，结束符），这种方法简单易行，但是选择开始符和结束符时一定要确保每条数据的内部不包含开始符和结束符。 发送长度：发送每条数据时，将数据的长度一并发送，例如规定数据的前4位是数据的长度，应用层在处理时可以根据长度来判断每个分组的开始和结束位置。

孙笑氚258：产品是用来满足特定人群在特定场景下的特定需求的。 如果在场景出现时，你的产品不能满足这些人的需求，那就不是好产品。 何为满足需求？粗暴一点说，可以认为利用手段（功能）解决用户的真实诉求，解决他的问题就是满足需求。 在满足需求的过程中，是否平滑，是否舒适，是不会比“满足需求”本身更重要的：沙漠中的旅行者感到口渴，恰逢绿洲，一个精致密封的空心玻璃球和一个破烂甚至拧不紧口的水壶，一定是水壶更能满足需求；即便水壶的口很小、中间有裂缝，灌水慢还灌不满，出水小还断断续续，但实现了基本功能——“存水”。 所以很明显，“基础功能”是一个产品必不可少，也是最必要的。 下面的问题就简单了：你认为旅行者希望水壶“漏水更少、存水更多”，还是“水壶能保温、能制冷”？ “亮点功能”能给用户带来惊喜，但“用户体验”更基本。如果用户连注册流程都感到长得厌烦，你的小彩蛋功能也大概率不能挽回他。 所以： 基础功能、用户体验和亮点功能。就这么排

孙笑氚258：游戏产品本质也是产品，和“11月24日店铺交易额降低”的问题没有本质区别。 问题的主体包括“时间”、“对象”，问题希望从“指标”分析： “某个时期”的长度是多久？在运营周期和现实生活中的哪个阶段？是否赶上了“学生开学”、“法定假日结束”或是特殊事件？又或是运营周期中，没有大型活动、玩家“养老”的时期？这些问题所影响的指标是“活跃度”，即“这个时期”里，是不是用户变少了？（看“日活”、“周活”） “对象”（产品）本身有没有出现问题？会是什么样的问题： 1. 用户消费的问题？ a. 买了吗？是商品不够吸引用户（商品是用户必需的吗？“值”吗）？还是缺少促销活动/力度不足？问题的表现应该是“转化率”低下，用户没有买，购买欲不足。 b. 买多少？是不是定价过低？或者消费降级，用户购买低价的商品？是玩法导致了玩家不再需要高价值商品吗？还是这一时期下玩家的购买力下降了（比如前段时间刚有过大型促销活动掏空玩家）？（比如看“单用户消费额”） c. 买不了？是不是出了bug根本不能买。低级问题，不用看指标看客诉都够了。 2. 用户运营的问题？比如： 消费得有人。是不是人跑了？游戏玩法还是运营太💩导致了流失？（看看“流失率”） 再或者没人跑，但是来的变少了？（看“新增”、“促活”） 会不会根本没有问题？比如： 这就是正常的营收，只是用来对比的时期是高营收时期（拿平峰和双十一营业额比），比如之前用来比较的对象其实是周年活动，现在活动结束了，自然玩家消费欲望、选项都减少