计算机网络的八股文自述（持续更新）

计算机网络的八股文自述

1.1、三次握手和四次挥手过程，以及为什么需要三次握手，两次不行吗？为什么需要四次挥手呢？为什么需要等待 2MSL ，客户端才会处于关闭状态呢？

三次握手的过程：

1. 首先由客户端发送请求连接的信号，SYN=1，并进入Syn-Sent状态；
2. 此时服务端收到了连接请求信号后，发送SYN=1，ACK=1的连接确认报文，进入SYN-RCVD状态；
3. 客户端收到服务端的信号后，进入Established状态，并再次发送确认信号ACK=1；
4. 服务器收到后也转为established状态；
5. 连接完成建立。

三次握手的原因：

三次握手的主要目的就是双方确认自己与对方的发送与接收是正常的。

防止失效的连接请求到达服务器，让服务器建立错误的连接。

四次挥手的过程：

1. 首先客户端向服务器发送Fin=1的请求释放连接的信号，进入FIN-Wait-1状态
2. 服务器收到后发送ACK=1的确认收到释放连接信号，并进入CLOSE-WAIT状态
3. 客户端收到后进入FIN-Wait-2状态，等待服务器继续发送最后的一些数据
4. 服务器发送完成后发送一个FIN=1，ACK=1的请求释放连接信号，并进入LAST-ACK状态
5. 客户端收到后发送最后的ACK=1的释放连接信号，进入TIME-Wait状态
6. 服务器收到后关闭
7. 客户端等待2MSL后关闭

四次挥手的原因：

当客户端申请关闭连接的时候，可能服务器还有没有传输完成的数据，所以要在传输完所有的数据后，再发送一个FIN=1的数据。

TIME_WAIT：

1. 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。

2. 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

1.2、Time_wait 过多怎么办？

解决TIME_WAIT过多造成的问题

遇到该问题的时候，可以先从time_wait 的作用开始讲起，然后再讲讲大量的time_wait 造成了什么影响。

TIME_WAIT状态存在的理由：
1）可靠地实现TCP全双工连接的终止
在进行关闭连接四次挥手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN，因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息，那么客户端将响应RST分节，服务器将此分节解释成一个错误（在java中会抛出connection reset的SocketException)。

因而，要实现TCP全双工连接的正常终止，必须处理终止序列四个分节中任何一个分节的丢失情况，主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。

2）允许老的重复分节在网络中消逝
TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个原来的迷途分节就称为lost duplicate。
在关闭一个TCP连接后，马上又重新建立起一个相同的IP地址和端口之间的TCP连接，后一个连接被称为前一个连接的化身（incarnation)，那么有可能出现这种情况，前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身。
为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝。

1.3、udp如何保证可靠性呢？

参考博客：udp如何实现可靠性传输？

UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

实现确认机制、重传机制、窗口确认机制。

如果你不利用Linux协议栈以及上层socket机制，自己通过抓包和发包的方式去实现可靠性传输，那么必须实现如下功能：

发送：包的分片、包确认、包的重发

接收：包的调序、包的序号确认

目前有如下开源程序利用udp实现了可靠的数据传输。分别为RUDP、RTP、UDT。

1.4、Http 短连接和长连接的区别，以及各自使用的场景，以及长连接的缺点有哪些？

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

**短连接：**就是说，浏览器和服务器每进行一次Http操作，就会建立一次连接，但是任务结束后就会中断连接；

**长连接：**在使用长连接的情况下，当打开一个网页完成后，客户端和服务器之间用于HTTP数据的Tcp 连接不会关闭。

区别：

① 服务器端空间管理上：

Keep-Alive不会永久保持连接，因为TCP连接将会越来越多，直到把服务器的TCP连接数量撑爆到上限为止，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间；

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。

② 时间上：

在客户请求频繁的情况下：若使用短连接，将在TCP的建立和关闭操作上浪费时间和带宽；

若使用长连接，就可以节省很多这样的消耗；

使用场景：

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接好。

长连接的缺点：

在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，从而导致服务器崩溃。

1.5、 你的一个网站如果使用到长连接，那你会怎么做呢？

这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

1.6 TCP真的可靠吗？

TCP可以通过序列号和超时重传保证了端到端的可靠，但是它无法保证应用层面的可靠。

主要的故障有两类：

① 收不到FIN的故障，比如网络掉线，或者主机崩溃都是这种情况；

② 能收到FIN的故障，比如对方应用程序崩溃。

1.7 TCP粘包问题怎么解决？

参考博客：TCP粘包问题分析和解决（全）

**TCP粘包问题：**指发送方发送的若干数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾。

粘包出现的原因：

① 发送端需要等到缓冲区满才发送出去，造成粘包；

发送方引起的粘包是由TCP协议本身造成的，TCP为了提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次性发送出去，这样接收方就收到了粘包数据。

② 接收方不及时接收缓冲区的包，造成多个包接收。

接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。

解决粘包问题的方案：

① 发送固定长度的消息；

② 把消息的尺寸与消息一块发送；

③ 使用特殊标记来区分消息间隔。

拓展–UDP会不会出现粘包的问题呢？

TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

1.8 你所了解的状态码说一下

200：ok 204：No content 206：Partial content

301：永久性重定向 302：临时性重定向 304：Not modified

400：bad request 403：forbidden 404：Not found

500：Internet Serve Error 503：service unavailable