Shopee后端开发面经

shopee后端开发面试题

一面：前提，我是java转go，所以基本上没有问和java相关的问题。

TCP和UDP的不同？

连接
- TCP是面向连接的传输层协议，传输数据前先要建立连接。
- UDP是不需要连接的，即刻传输数据。
服务对象
- TCP是一对一的两点服务，即一条连接只有两个端点。
- UDP支持一对一、一对多、多对多的交互通信。
可靠性
- TCP是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
- UDP是尽最大努力交付，不保证可靠交付数据。
拥塞控制、流量控制
- TCP有拥塞控制和流量控制机制，保证数据传输的安全性
- UDP则没有，即使网络非常拥堵了，也不会影响UDP的发送速率。
首部开销
- TCP首部长度较长，会有一定的开销，首部在没有使用选项字段时是 20 个字节，如果使用了选项字段则会更长的。
- UDP ⾸部只有 8 个字节，并且是固定不变的，开销较⼩。
传输方式
- TCP 是流式传输，没有边界，但保证顺序和可靠。
- UDP 是⼀个包⼀个包的发送，是有边界的，但可能会丢包和乱序。
分片不同
- TCP的数据大小如果大于MSS大小，则会在传输层进行分片，目标主机收到后，也同样在传输层组装TCP数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片。
- UDP的数据大小如果大于MTU(Maximum Transmission Unit)大小，则会在IP层进行分片，目标主机收到后，在IP层组装完数据，接着再传输给传输层，但是如果中途丢了一个分片，在实现可靠传输的UDP时则就需要重传所有的数据包，这样传输效率非常差，所以通常UDP的报文应该小于MTU。

TCP粘包原因和解决方法

TCP粘包是指：发送方发送的若干包数据到接收方接收时粘成一包

发送方原因：

TCP默认使用Nagle[ˈneɪgəl]算法（主要作用：减少网络中报文段的数量）。

收集多个小分组，在一个确认到来时一起发送、导致发送方可能会出现粘包问题

接收方原因：

TCP将接收到的数据包保存在接收缓存里，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

解决粘包问题：

最本质原因在于接收方无法分辨消息与消息之间的边界在哪，通过使用某种方案给出边界，例如：

发送定长包。每个消息的大小都是一样的，接收方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收方先接收包体长度，依据包体长度来接收包体。

TCP三次握手

⼀开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端⼝，处于 LISTEN 状态；

客户端随机初始化序列号 client_isn ，将序列号置于TCP首部的序列号字段中，同时把 SYN 标制位置为 1，表示 SYN 报文。接着把第一个SYN报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN_SENT状态；
服务端收到客户端的 SYN报文后，首先服务端也随机初始化自己的序列号 server_isn，并填入 TCP 首部的序列号字段中，其次把TCP首部的确认应答号字段填入 client_isn + 1，接着把 SYN 和 ACK 标制置为 1，最后把该报文发送给客户端，该报文也不包含应用层数据，之后服务端处于 SYN_RCVD 状态；
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文TCP首部 ACK 标志位置为 1，其次确认应答号字段填入 server_isn + 1，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。

服务端收到客户端的应答报文后，也进入 ESTABLISHED 状态。

可通过 netstat -napt 命令查看TCP的连接状态

什么是TCP连接：用于保证可靠性和流量控制维护的某些状态信息，这信息的组合，包括 Socket、序列号和窗口大小称为连接。

TCP握手为什么三次

三次握手才可以避免历史连接（主要原因）；

我们来看看 RFC 793 指出的 TCP 连接使⽤三次握⼿的⾸要原因：

The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion.

简单来说，三次握⼿的⾸要原因是为了防⽌旧的重复连接初始化造成混乱。

客户端连续发送多次 SYN 建⽴连接的报⽂，在⽹络拥堵情况下：
- ⼀个「旧 SYN 报⽂」⽐「最新的 SYN 」报⽂早到达了服务端；
- 那么此时服务端就会回⼀个 SYN + ACK 报⽂给客户端；
- 客户端收到后可以根据⾃身的上下⽂，判断这是⼀个历史连接（序列号过期或超时），那么客户端就会发送 RST 报⽂给服务端，表示中⽌这⼀次连接。
三次握手才可以同步双方的初始序列号；

TCP 协议的通信双⽅，都必须维护⼀个「序列号」，序列号是可靠传输的⼀个关键因素，它的作⽤：
- 接收⽅可以去除重复的数据；
- 接收⽅可以根据数据包的序列号按序接收；
- 可以标识发送出去的数据包中，哪些是已经被对⽅收到的；
三次握手才可以避免资源浪费；

如果只有「两次握⼿」，当客户端的 SYN 请求连接在⽹络中阻塞，客户端没有接收到 ACK 报⽂，就会重新发送 SYN ，由于没有第三次握⼿，服务器不清楚客户端是否收到了⾃⼰发送的建⽴连接的 ACK 确认信号，所以每收到⼀个 SYN 就只能先主动建⽴⼀个连接，这会造成什么情况呢？

如果客户端的 SYN 阻塞了，重复发送多次 SYN 报⽂，那么服务器在收到请求后就会建⽴多个冗余的⽆效链接，造成不必要的资源浪费。

为什么需要 TIME_WAIT 状态？

首先，主动发起关闭连接的一方，才会有 TIME_WAIT 状态。

需要TIME_WAIT状态，主要有两个原因：

防止具有相同四元组的旧数据包被收到；

TCP 就设计出了这么⼀个机制，经过 2MSL 这个时间，⾜以让两个⽅向上的数据包都被丢弃，使得原来连接的数据包在⽹络中都⾃然消失，再出现的数据包⼀定都是新建⽴连接所产⽣的。
保证被动关闭连接的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；