网络编程知识面试题

前言

关于网络，我想各位大兄弟是又爱又恨

爱的是各种强大的技术框架早已把网络封装的又简单又好用，天天 request，fetchData 用的飞起

恨的是每次面试的时候都要被问：

“HTTP 和 TCP 有什么区别?”

“HTTP 和 Socket 有什么区别?”

“什么是三次握手，四次挥手?”

“为什么不两次握手要三次握手?”

“为什么不三次挥手要四次挥手”

“为什么四次挥手的时候要等待 2msl?”

“http1.0 http1.1 http2.0 有什么区别?”

“http 和 https 有什么区别?”

....

？？？ 难道我每次请求数据的时候都要把这些默背一遍吗？这面试八股文呐，真真是让人头痛不已

别怕！为了让朋友们能够一劳永逸，拒绝死记硬背！小编我梳理了这份不怕忘的网络基础知识指南，供大家品尝~

本文福利， 免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

什么是 HTTP 和 TCP ？

首先，我们要知道这两个都是协议，完整的叫法是 Http 协议和 TCP/IP 协议

协议，就是双方约定的内容。比如我和你约定，我给你个苹果，你要给我香蕉。苹果换香蕉就是我们协议的具体内容

所以 HTTP 和 TCP 本质上没什么神秘的地方，只是对网络请求做了一些规范。

那么问题来了，既然都是协议，它们有什么不同呢？

具体的不同当然有很多。但如果不是专业的网络技术人员的话，只需要有个整体的了解即可。这时候就要搬出老师教我们的 TCP/IP 分层模型图。

熟不熟悉？这里我们只需要记住应用层和传输层就可以了，其他的基本很少用到

从这个模型可以知道，网络请求是一个很复杂的过程，复杂到必须分好几层，每层把自己的任务完成好才可以请求成功

传输层的任务就是建立网络连接

应用层就是在建立好的网络连接上传递各种类型数据。比如文本，图像，视频等等

既然网络请求这么复杂，指望用一个协议来描述整个网络请求过程是不可能的

所以 HTTP 对应的就是应用层协议，TCP 对应的是传输层协议

这就是 HTTP 和 TCP 的最大不同

Socket

这时候就引出一个概念，socket

什么是 socket 呢？

通过前文我们知道，HTTP 和 TCP 只是协议而已，协议本身没有是实现功能的能力的，需要一个载体实现它。

socket 就是 tcp 协议的实现。

它定义了一些建立连接的接口。比如 connect，listen，read 等等，这些接口方法的具体实现严格遵循 TCP 协议

好了，知道了是什么，接下来就是面试的重头戏

三次握手和四次挥手

我们首先明确，三次握手和四次挥手是 TCP/IP 协议的内容，它是属于运输层的，是网络请求在传输数据时建立连接和断开连接的方式

如何建立一个网络连接

在了解什么是三次握手之前，我们先探讨一个问题

现在有客户端 client 和服务端 serve，我们怎么样建立一个网络连接？

最简单的当然是客户端向服务端发送一个建立连接的请求，然后爱管不管，我就当连接已经建立了，美滋滋的原地等待，等服务端给我发送数据

这样可以吗？

当然不行了兄弟

万一服务端压根就没开机，万一人家理都不理你呢

就像给妹妹写情书一样，妹妹回应你这事才有戏。你不管妹妹回不回应一个劲给人家写，还傻傻的在那等。

那不叫爱，那是 X 骚扰和备胎

所以我们得出建立连接的一个基本准则

“请求必须要有回应”

继续往下想。既然要有回应，那我客户端向你发个请求，等接收到服务端的回应，再发下个请求。依次进行，是不是显得非常有秩序?

不愧是你，这就是“停止等待协议”

超时重传

“停止等待”就是网络请求最简单的版本

简单就意味着问题，因为网络环境是不稳定的

比如客户端的每个请求都要等收到上个请求的回复才发送，如果上个请求因为网络波动延迟了，或者干脆丢掉了，那客户端的下个请求岂不是永远发不出去了？数据就卡在这里了？

为了解决这个问题，TCP 协议里有个超时重传机制，如果长时间没收到回复就把原来的包再发一遍。还没收到再发，直到正常。

序列号

明白了网络连接建立时，“请求必须有回应”，“超时重传”，接下来我们再思考一个问题

我们知道，连接请求传输的数据是以数据包的形式传输的。也就是说，一次请求的数据是由多个数据包组成的。

如果一个数据包因为网络波动延迟了，在这延迟的期间触发了超时重传，这时候服务端就会接收到两个相同的包，服务端怎么处理呢？

处理的方法很简单。就是客户端在发送数据包的时候往里面加点“东西”，让服务端能够辨别这个包是从哪里来的

这个过程就是给数据包编号。这个号叫做数据包的序列号，这是接下来三次握手的关键

三次握手

终于到三次握手了，要不兄弟们先点个赞，换换脑子？

还是先上一个简单的前提

三次握手本质上其实是四次握手，只是把中间两次握手合并了而已。

因为建立连接是连续的。 服务端在第一次握手收到客户端的请求后，要马上发送回应， 同时发送自己的请求，所以把回应和请求合并成一次请求，也就是第二次握手

为什么不是两次握手而是三次握手呢？

那么问题来了，根据上面的“请求必须要有回应”基本准则

为什么不是两次握手而是三次握手呢？

谢希仁著的《计算机网络》第四版中，讲到“三次握手” 的目的是 “为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。

这句话当做面试八股文背下来也没什么问题。但其实这里面跳过了一个关键原因

还记得我们说数据包为什么要有序列号吗？

是为了让服务端能够辨别数据包的来源，区分是否是过时的数据包。

我们把眼光从数据包上升到一次网络连接。如果一个数据包延迟比较久，久到这次连接断开，下次连接建立，这时候服务端收到了旧连接的包，如何区分这两次连接呢？

答案是再加一个序列号

这个序列号叫初始序列号，用来标识一个连接。

这样结论就很清晰了。

初始序列号用来标识是否是同一个连接，数据包序列号用来标识一次连接中数据包的来源。

所以客户端需要向服务端发送表示本次连接的初始序列号

慢着，你还是不懂为什么是三次握手不是两次？

哈呀，你忘了 TCP 协议是全双工通信吗？客户端和服务端的概念是相对的，性别互换，亲妈不爱

客户端给服务端发送初始序列号是客户端建立的连接，服务端同时也可以作为客户端，也要向对方发送建立连接的初始序列号。再加上之前说的握手合并，不就是三次握手了嘛

恍然大悟了吧？ 嘿嘿

来，自我检查一下，把自己当成面试官问自己

“为什么是三次握手不是四次握手”

“为什么是三次握手不是两次握手”

本文福利， 免费领取C++音视频学习资料包、技术视频，内容包括（音视频开发，面试题，FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，编解码，推拉流，srs）↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓

四次挥手

漫漫长征走过了一半，接下来我们看断开连接的四次挥手

其实四次挥手和三次握手差不多，不同的是第二次和第三次挥手不能合并

这是为什么呢？

前面说三次握手能合并的原因是 「建立连接是连续的」，服务端收到第一次握手请求后要马上回应同时发送请求。但因为 TCP 是全双工通信，客户端断开连接后服务端可能还需要发送数据。

所以客户端一次“请求--回应”只是断开了客户端-->服务端的连接，服务端过一会后才发送请求断开服务端-->客户端的连接

为什么要等待 2MSL

这里有个小知识点，客户端在最后一次挥手发送回应后，会等待 2msl（msl 就是一个报文在网络上的最大存活时间）时间才完全关闭，这是为什么呢？

还是网络不稳定的问题。客户端最后一次挥手发出的回应报文如果延迟了或者丢了，服务端等待 1 个 MSL 没有收到的话会超时重传，重复第③次挥手的过程。

这样最多 2MSL 的时间客户端又会收到断开连接的请求，所以要最少等待 2MSL 时间再断开

好了，HTTP 和 TCP 的大部分知识点就讲完了。当然可拓展的地方还有非常多，比如“超时重传”那里，为了解决性能问题又引入了连续传输，滑动窗口，拥塞控制等等。不过这些算 HTTP 知识的枝干，只要掌握主干知识，其余枝叶还不是手到擒来

当然面试官还会问一些简单记忆就可以回答的问题，比如：

“你来说说 Http1.0 Http1.1 和 Http2.0 的区别”

Http1.0，Http1.1 和 Http2.0 的区别

刚才我们说的其实都是 Http1.0 的内容，用脚指头想 Http1.1 和 2.0 一定是做了优化。

Http1.1 的优化主要是实现了 长连接 ，同时也是目前最广泛的 Http 协议。

长连接的意思很简单。在 Http1.0 中，我们每请求一张图片就要建立一次 Tcp 连接，请求一个网页往往有几十上百次 Tcp 建立连接，断开连接，这样非常耗时，长连接的意思就是多个请求可以复用一个 Tcp 连接，提高了 Tcp 连接的利用率

如果面试官问你还有呢，你就跟他说还有断点续传

这个很容易理解吧，在 Http1.0 中，我们想知道一段视频中间的数据，必须先把整个视频下载下来。Http1.1 优化了这个逗比的场景，在请求头中加入了 range，可以只请求数据的一部分

如果问你还有呢....

你就说常用的差不多就这些了，不行我回去好好看看，等我们做了同事我再跟你好好说..

至于 Http2.0 就更牛逼了

它支持多路复用。 之前讲 Http1.1 只是复用 Tcp 连接，Http2.0 可以在一个请求上请求多个资源

类似于把两个请求合并成一个请求。服务端一次返回两次请求的资源。