1.为什么四次挥手之后要等2MSL?
2.服务端出现大量的timewait有哪些原因?
3.TCP和UDP区别是什么？
4.TCP为什么可靠传输
5.怎么用udp实现http？
6.tcp粘包怎么解决？
7.TCP的拥塞控制介绍一下？
8.描述一下打开百度首页后发生的网络过程
9.网页非常慢转圈圈的时候，要定位问题需要从哪些角度？
10.server a和server b，如何判断两个服务器正常连接？出错怎么办？

1.为什么四次挥手之后要等2MSL?

首先说MSL是报文在网络上的最大生存时间，如超过，就是被丢弃。之所以在客户端发送ACK报文后还要等到2MSL是因为在发送ACK报文（1MSL）丢失时，能够保证客户端在TIME_WAIT状态下接收到服务端的重发FIN报文（1MSL）。因此需要2MSL。

2.服务端出现大量的timewait有哪些原因?

参考

TIME_WAIT 状态是「主动关闭连接方」才会出现的状态。 在接收对方的FIN后产生的，而且 TIME_WAIT 状态会持续 2MSL 时间才会进入到 close 状态。
怎么会在服务端出现time_wait状态的连接？那么一定是在以下三种情况下主动进行了连接的断开：

第一个场景无论哪一方设置HTTP请求的header中Connection：close都是由服务端主动发起断开。因此可以得到当服务端出现大量的 TIME_WAIT 状态连接的时候，可以排查下是否客户端和服务端都开启了 HTTP Keep-Alive。

第二个场景在确认长连接的情况下，双方建好连接，服务端却迟迟没有收到来自客户端的请求或者下一个请求迟迟没有来（ keepalive_timeout设置等待时间）就会主动断开连接。因此，可以进一步排查网络是否异常，导致无法接收客户端请求。

第三个场景keepalive_requests 参数的默认值是 100 ，意味着每个 HTTP 长连接最多只能跑 100 次请求。对于一些 QPS 比较高的场景，比如超过 10000 QPS，甚至达到 30000 , 50000 甚至更高，如果 keepalive_requests 参数值是 100，这时候就 nginx 就会很频繁地关闭连接，那么此时服务端上就会出大量的 TIME_WAIT 状态。解决的方式也很简单，调大 nginx 的 keepalive_requests 参数就行。

出现太多的time_wait状态连接带来的问题：

3.TCP和UDP区别是什么？

4.TCP为什么可靠传输？

可靠意味着：无差错，不丢失，不重复，按序到达。
首先由完善的连接管理，确保连接本身的可靠。其次报文由序列号和确认号，确保报文的顺序与被接收。其次由超时重传机制，确保计时补上丢失包。最后，通过流量控制和拥塞控制确保对包处理和发送的正常运行。

5.怎么用udp实现http？

这是啥问题？我咋没搞懂？UDP是协议，HTTP也是协议。换个问题就是UDP该怎么实现可靠传输？
其实就是如何基于UDP协议来实现上层的HTTP，HTTP就是url，PUT，GET这个报文的规范。

6.tcp粘包怎么解决？

粘包的问题出现是因为不知道一个用户消息的边界在哪，如果知道了边界在哪，接收方就可以通过边界来划分出有效的用户消息。
一般有三种方式分包的方式：固定长度的消息；特殊字符作为边界；自定义消息结构。
第一个无需多言。第二个是HTTP报文采用的方式：换行，HTTP 协议中，通常会使用 Content-Length 头来表示消息体的长度，接收方根据 Content-Length 来解析请求体或响应体。
第三个方法：我们可以自定义一个消息结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大。

7.TCP的拥塞控制介绍一下？

拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。
拥塞窗口 cwnd是发送方维护的一个的状态变量，它会根据网络的拥塞程度动态变化的。发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的概念后，，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。


具体的算法流程

8.描述一下打开百度首页后发生的网络过程

9.网页非常慢转圈圈的时候，要定位问题需要从哪些角度？

10.server a和server b，如何判断两个服务器正常连接？出错怎么办？