计算机网络面试大总结(计算机网络面试八股文)

推荐整理分享计算机网络面试大总结(计算机网络面试八股文)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:计算机网络面试题及答案,计算机网络面试自我介绍,计算机网络面试基础知识,计算机网络面试题及答案,计算机网络面试八股文,计算机网络面试题,计算机网络面试题,计算机网络面试常见问题,内容如对您有帮助，希望把文章链接给更多的朋友！

本文分文五大部分，第一部分总纲说明计算机网络层次划分的三种模型，一到四部分以TCP/IP协议模型作为划分标准，分别说明各层作用和最常见的面试题，最后总结网络综合面试题，历时六天全文一千字。其他经典面试题参考程序员田同学

写过代码的同学就多多少少接触过GET、POST、HTTP、TCP等名词，很多基础不扎实的同学并不知道它们都是什么东西，其实这些名词都是计算机网络中各层的协议，计算机网络分层主要是三种分法，OSI七层模型、TCP\IP四层模型、学习型五层协议。

OSI 的七层协议体系结构的概念清楚，理论也较完整，但它既复杂又不实用。

TCP/IP 体系结构则不同，但它现在却得到了非常广泛的应用。TCP/IP 是一个四层体系结构，它包含应用层，运输层，网际层和网络接口层（用网际层这个名字是强调这一层是为了解决不同网络的互连问题），不过从实质上讲，TCP/IP 只有上面的三层，因为下面的网络接口层并没有什么具体内容。

因此在学习计算机网络的原理时往往采用折中的办法，即综合 OSI 和 TCP/IP 的优点，采用 一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚，有时为了方便，也可把底下两层称为网络接口层。

TCP（传输控制协议）和IP（网际协议） 是先定义的两个核心协议，所以才统称为TCP/IP协议族

七层网络体系结构各层的主要功能：

应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等。

表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。

会话层：负责在网络中的两节点之间建立、维持和终止通信，如服务器验证用户登录便是由会话层完成的。

运输层：有时也译为传输层，向主机进程提供通用的数据传输服务。该层主要有以下两种协议：

网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议、路由器。

数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧，包括交换机。

物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和通信手段的差异。

本章节是学习下面章节的基础，只有明白网络分层中各层的作用才能准备判断TCP、HTTP位于网络协议中的哪一层。

应用层的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程间的通信和交互的规则。

对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。

①请求行，请求方法字段、URL字段、HTTP协议版本（例如：GET /index.html HTTP/1.1）

②请求头，key-value形式（User-Agent：产生请求的浏览器类型，Accept：客户端可识别的内容类型列表，Host：主机地址）

③请求数据，POST请求中key-value形式发送。

HTTP 协议有 HTTP/1.0 版本和 HTTP/1.1 版本。HTTP1.1 默认保持长连接（当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。）数据传输完成了保持 TCP 连接不断开（不发 RST 包、不四次握手），等待在同域名下继续用这个通道传输数据。

在 HTTP/1.0 中，默认使用的是短连接（浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接）。也就是说，浏览器和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。从 HTTP/1.1 起，默认使用的是长连接，用以保持连接特性。

HTTP 1.0

HTTP 2.0

​ 1.头部压缩，双方各自维护一个header的索引表，使得不需要直接发送值，通过发送key缩减头部大小

​ 2.多路复用，使用多个stream，每个stream又分帧传输，使得一个tcp连接能够处理多个http请求

​ 3.可以使用服务端推送

HTTP3.0

在学习HTTPS原理之前我们先学习两个计算机网络中加密的概念。

对称加密：通信双方都使用同一个秘钥进行加密和解密。无法解决首次把秘钥发送给对方时，很容易被截获的问题。

非对称加密：公钥和私钥组成一个密钥对，用私钥加密的数据，只有对应的公钥才能解密，用公钥加密的数据，只有对应的私钥才能解密。通信双方的手里都有一套自己的密钥对，通信之前双方会先把自己的公钥都发送给对方，然后 对方拿这个公钥来加密要发送的数据，接收方用自己的私钥对其解密。问题是速度慢。

将HTTP变成HTTPS时，这时候需要一个 证书颁发机构（CA），证书中包括签发者、证书用途、使用者的公钥私钥和 Hash 算法、证书到期时间等。另外使用 数字签名 这一技术：使用 CA 自带的 Hash 算法对证书内容进行 Hash 得到一个摘要（指纹），再用 CA 的私钥加密，生成数字签名。接收者收到证书时，使用同样的 Hash 算法再次生成消息摘要，然后用 CA 的公钥对数字签名解密，将它和消息摘要对比，就知道有没有被篡改。

最重要的区别就是get产生一个TCP数据包，而post产生两个TCP数据包。

对于get的请求，浏览器会把浏览器的header和data一起发送出去，服务器响应200，对于post，浏览器先发送header，浏览器响应100，浏览器再发送data，服务器响应200，也就是说get只需要汽车跑一趟就把货送到了，而post需要跑两趟，第一趟先去和服务器打个招呼告诉它我等下要送货过来，开门迎接我，第二趟就是把货送过去。

据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间查基本可以无视，而在网络环境差的情况下，两次包的TCP在验证数据包完整性上有很大的优势，所以不推荐使用get来优化性能，当然，并不是所有的浏览器都会在post中发两次tcp包，火狐浏览器就只发一次

下面我们看看get和post应用上的区别：

①get的参数通过URL传递，post放在request body（请求头）中

②get在URL中的参数是有长度限制的，而post没有。GET 方式提交的数据最多只能是 1024 字节，理论上POST 没有限制，可传较大量的数据。其实这样说是错误的，不准确的：“GET 方式提交的数据最多只能是 1024 字节"，因为 GET 是通过 URL 提交数据，那么 GET 可提交的数据量就跟URL 的长度有直接关系了。而实际上，URL 不存在参数上限的问题，HTTP 协议规范没有对 URL 长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE 对URL 长度的限制是2083 字节(2K+35)。对于其他浏览器，如Netscape、FireFox 等，理论上没有长度限制，其限制取决于操作系统的支持。

③get只能进行URL编码，而post支持多种。

④get只接受ASSIC字符，而post没有限制。

⑤post比get安全，因为get的参数暴露在URL中。

①TCP面向连接，而UDP是无连接的

②TCP可靠（HTTP、HTTPS、FTP），UDP不可靠（视频、DNS）

③TCP只支持点对点通信，而UDP支持1对1，1对多，多对1，多对多的通信模式

④TCP是面向字节流的，UDP是面向报文的

⑤TCP有拥塞控制，UDP没有拥塞控制，适合媒体通信

⑥TCP首部开销（20字节）比UDP首部开销（8个字节）要大

标志位一共有6种，分别是：

此外，还有两个序号：

Sequence number ：顺序号，发送数据包中的第一个字节的序列号，一般为小写的seq。

Acknowledge number：确认号，一般为小写的ack，响应前面的seq，值为seq+1。

在理解三次握手和四次挥手时结合图，看三到四遍便可理解

所谓三次握手，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。 三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的顺序号和确认号并交换 TCP信息。

第一次握手：客户端Client发送位码为SYN＝1，随机产生seq=x的数据包到服务器，服务器Server由SYN=1知道，客户端Client要求建立联机；

第二次握手：服务器Server收到请求后要确认联机信息，向客户端Client发送ack=(客户端Client请求连接时的seq)+1，SYN=1，ACK=1，产生seq=y的包,代表接收到连接请求并且向客户端再次确认；

第三次握手：客户端Client收到后检查ack是否正确，即第一次发送的seq+1，以及位码ACK是否为1，代表收到了服务器端发过来的确认信息。之后客户端Client会再向服务器发送ack=(服务器Server的seq+1)，ACK=1，服务器Server收到后确认ack 值与ACK=1，连接建立成功。

客户端Client进程发出连接释放报文，并且停止发送数据。其中FIN=1，顺序号为seq=m（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端Client进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

服务器Server收到连接释放报文，发出确认报文，ACK=1，ack=m+1，并且带上自己的顺序号seq=n，此时，服务器Server就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端Client向服务器的方向就释放了，这时候处于半关闭状态，即客户端Client已经没有数据要发送了，但是服务器Server若发送数据，客户端Client依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

客户端Client收到服务器Server的确认信息后，此时，客户端Client就进入FIN-WAIT-2（终止等待2）状态，等待服务器Server发送连接释放报文（在这之前还需要接受服务器Server发送的最后的数据）。

服务器Server将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=m+1，由于在半关闭状态，服务器Server很可能又发送了一些数据，假定此时的顺序号为seq=p，此时，服务器Server就进入了LAST-ACK（最后确认）状态，等待客户端Client的确认。

客户端Client收到服务器Server的连接释放报文后，必须发出确认，ACK=1，ack=p+1，而自己的顺序号是seq=m+1，此时，客户端Client就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，当客户端Client撤销相应的TCB（保护程序）后，才进入CLOSED状态。TIME_WAIT 需要等待 2MSL，在大量短连接的情况下，TIME_WAIT会太多，这也会消耗很多系统资源。对于服务器来说，在 HTTP 协议里指定 KeepAlive（浏览器重用一个 TCP 连接来处理多个 HTTP 请求），由浏览器来主动断开连接，可以一定程度上减少服务器的这个问题。

服务器Server只要收到了客户端Client发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器Server结束TCP连接的时间要比客户端Client早一些。

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上关闭连接，但是会做出应答，返回 ACK 报文段.

接下来可能会继续发送数据，在数据发送完后，服务器会向客户单发送 FIN 报文，表示数据已经发送完毕，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，因此一共需要四次挥手。

（1）为了防止已经失效的连接请求报文突然又传送到了服务器端（网络堵塞的原因）

如果客户端发出的连接请求报文并未丢失而是在某个网络结点长时间堵塞了，导致延误到连接释放以后的某个时间才到达服务器，这时服务器误以为是客户端发出了一个新的连接请求，于是就向客户端发送确认数据包，同意建立连接。

如果不采用三次握手，那么只要服务器端发送确认数据包，连接就建立成功了，由于客户端并未发出连接请求，所以不会理睬服务器的确认，也不与服务器通信，而这个时候服务器一直在等待客户端发送数据，这样服务器就白白浪费了资源，如果采用三次握手，那么服务器端密钥收到来自客户端的确认，就知道客户端并没有请求建立连接，就不会建立连接。

（2）三次握手才能让双方均确认自己和对方的发送和接收能力都正常。

第一次握手：客户端只是发送处请求报文段，什么都无法确认，而服务器可以确认自己的接收能力和对方的发送能力正常；

第二次握手：客户端可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

第三次握手：服务器可以确认自己发送能力和接收能力正常，对方发送能力和接收能力正常；

可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常，这样就可以愉快地进行通信了。

（3）告知对方自己的初始序号值，并确认收到对方的初始序号值。

TCP 实现了可靠的数据传输，原因之一就是 TCP 报文段中维护了序号字段和确认序号字段，通过这两个字段双方都可以知道在自己发出的数据中，哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增，如果是两次握手，只有发起方的初始序号可以得到确认，而另一方的初始序号则得不到确认。

三次和四次的区别就在于服务器连续给客户端发了两个报文，那把这两个报文合并成一个不可以吗？为什么呢？答案是不可以，首先客户端发来请求断开连接的报文，假设这个时候服务器端仍然在发送报文（因为是全双工），如果是三次挥手，那么服务器只会确认客户的断开请求，客户端不会说我还有数据没有发送完，你要等等我，这样会导致客户端接收的数据不完整。

如果是四次挥手，那么服务器接收到客户的断开请求，会先说可以断开，但是你要先等我发送完剩余的数据，然后说我剩余的数据发送完了，我要和你断开连接

挥手过程之所以比握手过程多一次，就是因为握手过程只需要处理连接，而挥手过程需要处理连接和数据。

TCP主要提供了数据表检验和、序列号/确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现了可靠性传输。

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据。

序列号/确认应答：

序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据。

TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是发送ack报文，这个ack报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。

滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理的异常。

超时重传：超时重传是指发送出去的数据包到接收到确认包之间的时间，如果超过了这个时间会被认为是丢包了，需要重传。最大超时时间是动态计算的。

拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。

流量控制：TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

在进行数据传输时，如果传输的数据比较大，就需要拆分为多个数据包进行发送。TCP 协议需要对数据进行确认后，才可以发送下一个数据包。这样一来，就会在等待确认应答包环节浪费时间。

为了避免这种情况，TCP引入了窗口概念。窗口大小指的是不需要等待确认应答包而可以继续发送数据包的最大值。

滑动窗口（Sliding window）是一种流量控制技术。早期的网络通信中，通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况，同时发送数据，导致中间节点阻塞掉包，谁也发不了数据，所以就有了滑动窗口机制来解决此问题

滑动窗口协议是用来改善吞吐量的一种技术，即容许发送方在接收任何应答之前传送附加的包。接收方告诉发送方在某一时刻能送多少包（称窗口尺寸）。

TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新