计算机网络八股文总结

最新推荐文章于 2024-08-26 21:12:02 发布

快叫我去刷LeetCode

最新推荐文章于 2024-08-26 21:12:02 发布

阅读量5.9k

点赞数 4

文章标签：网络网络协议 http

原文链接：https://blog.csdn.net/qq_34337272/article/details/105338143?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163629014116780261927648%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=163629014116780261927648&biz_i

版权

本文基本都是阅读《Javaguide面试突击版》的总结，仅用于个人学习总结，如有侵权立刻删除。

原文链接：Javaguide面试突击版

一、OSI模型

	分层名称	功能
7	应用层	针对特定应用的协议
6	表示层	设备固有数据格式和网络标准数据格式的转换
5	会话层	通信管理，负责建立和断开通信连接
4	传输层	管理两个节点之间的数据传输。保证数据的可靠传输。
3	网络层	地址管理和路由选择
2	数据链路层	互联设备中传送和识别数据帧
1	物理层	以“0”、“1”代表电压的高低、灯光的闪灭。界定连接器和网线的规格。

五层体系结构

二、TCP/IP协议

1.TCP/IP的具体含义

TCP/IP并非仅仅特指两个协议，在很多情况下，它只是利用IP进行通信时所必须用到的协议群的统称。有时也称TCP/IP为网际协议群。

2.Tcp的三次握手和四次挥手

第一次握手：客户端发送一个连接请求（这个连接请求是一个带有SYN标志的数据包，假设SYN的序列为J）到服务端

第二次握手：服务端发送一个确认连接报文给客户端（这个确认连接是一个带有SYN和ACK标志的数据包，此时ACK=J+1，SYN假设为K）到客户端

第三次握手：客户端再给服务端发送一个确认报文（ACK=k+1）。

TCP三次握手

(1)为什么要三次握手？

三次握手是为了确认可靠的连接通道，即确认发送方和接收方的发送和接收功能都正常，三次握手缺一不可。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

（2）为什么不能时两次握手或是四次握手？

因为两次握手可能会出现这样的情况，假设发送方曾经发送了一个连接请求报文，这个报文并没有丢失，只是在某个网络节点长时间滞留了，等到连接释放完了之后这个连接请求才发送到接收方，而此时接收方误以为这个连接请求是发送方又发送了一个新的连接请求，于是向发送方发送一个确认报文，由于是两次握手，此时连接就已经确认了，但发送方并没有要发送数据，而接收方以为此时连接已经建立了，一直等待接收方的数据，这样就会导致浪费很多资源。

至于四次握手的话，三次握手已经能确认可靠的连接了，就没必要采用四次握手了。

（4）四次挥手的过程是怎样的，为什么挥手是四次？

第一次挥手：客户端发送一个FIN报文表示请求断开

第二次挥手：服务端接到FIN报文后发送一个ACK报文给客户端表示同意断开的请求

第三次挥手：服务端处理完数据和发送后，向客户端发送一个FIN报文表示请求断开

第四次挥手：客户端接收到FIN报文后发送一个ACK报文给服务端表示同意断开，然后等待2MSL后自行断开

比三次握手多一次是因为当服务端接收到客户端的FIN报文请求断开后，它只能先发送一个ACK报文给客户端表示确认，但此时服务端有可能还有数据没有处理和发送完，等服务端处理完后再向客户端发送一个FIN报文表示请求断开，所以挥手要多一次。

(5) 为什么客户端最后一次发送完ACK后要等2MSL才关闭？

保证客户端最后一次发送的ACK报文没有丢失，因为这个ACK报文可能丢失，站在服务端的角度来看：服务端已经发送了FIN报文表示请求断开了，但迟迟没收到客户端发送的ACK报文，这时服务端会认为客户端没有收到服务端发送的FIN报文，于是重新发送一个FIN报文，这个2MSL的时间就是让客户端在这种情况下能收到服务端重新发送的FIN报文并给出回应，并重新2MSL的计时
这个2MSL可以让本次连接中所有的报文失效在网络中，这样就可以保证在新连接中不会又旧连接产生的报文。

3. TCP、UDP的区别

TCP（Transmission Control Protocol）：传输控制协议

UDP（User Datagram protocol）：用户数据报协议

类型	是否面向连接	是否可靠	传输形式	性能	所需资源	应用场景	首部字节
TCP	面向连接	可靠	字节流	慢	多	要求通信数据可靠（如文件传输、邮件发送）	20-60
UDP	不面向连接	不可靠	数据段报文	快	少	要求通信速度快（如域名转换、即时通信）	8

4.TCP协议如何保证可靠性

应用数据被tcp分为最合适发送的数据块
TCP给每个数据包编号，接收端收到数据后排序，按顺序传给应用层
校验和：TCP保持数据的首部和数据的校验和，如果发现段的校验和出现差错，接收端会丢弃这个报文段并不确认收到该报文段。
TCP的接收端会丢弃重复的数据包
流量控制：TCP连接的每一方都有固定大小的缓冲空间，接收端只接受缓冲区域能容纳的数据，当接收端来不及处理数据的时候会提示发送端减小发送速率，防止包丢失。
拥塞控制：当网络拥塞时，减小发送端的发送
ARQ协议(automatic repeat-request)：发送端每发送完一组数据后停止发送，等待接收端给一个确认的回应，当收到确认报文后再继续发送
超时重传：发送端每发送一个数据包，启动一个定时器，在该时间内如果没有收到接收端发送的确认报文，发送端会重新发送一个数据包。

5.ARQ协议

自动重传请求：是OSI模型中数据链路层与传输层中的纠正协议之一，它通过使用确认和超时两个机制，在不可靠的基础上实现可靠的信息传输。它包括停止等待ARQ协议和连续ARQ协议

停止等待ARQ协议：（简单，但信道利用率低，等待时间长）基本原理就是发送一组数据后停止发送，等待接收方返回一个确认信息，如果在一定时间内都没收到这个确认信息，就会重新发送，在这一过程收到的重复数据都会被丢弃。
可能出现的情况：
1. 无差错情况：发送方发送数据，接收方收到数据回复确认，发送方收到确认后继续发送
2. 出现差错（超时重传）：发送端每发送一个数据包，启动一个定时器，在该时间内如果没有收到接收端发送的确认报文，发送端会重新发送一个数据包。
3. 确认丢失和确认迟到：
  - 确认丢失：发送方发送数据，接收方收到后返回一个确认，但这个确认信息在传输过程中给丢失了，发送方以为b没收到，重新发送数据，此时接收方收到了重传的数据，采取的措施为：丢弃重传数据，重新发送确认信息，因为发送方能重传说明之前的确认信息已经丢失了。
  - 确认迟到：在上述过程中有可能确认并不是丢失了，而是迟到了，当发送方收到接收方第二份确认信息后，又收到了迟到的第一份确认信息，采取丢弃措施为：发送方丢弃重复确认信息，接收方丢弃重复数据。
连接ARQ协议：发送方维持一个持续发送的窗口，在该窗口内所有数据连续发送，接收方一般采用累计确认，通过确认按序到达的分组内最后一个数据来表示确认收到之前所有的数据。
- 优点：信道利用率高，容易实现，不需要重传
- 缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

6.滑动窗口和流量控制

利用滑动窗口实现流量控制，流量控制是为了控制发送方的发送速率，保证接收方来得及接收

7.拥塞控制

在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的部分，就会导致网络性能变坏，这种情况叫拥塞。

TCP拥塞控制的四种算法：

慢开始
拥塞避免：让拥塞窗口缓慢变大
快重传
快恢复

8.从输入URL到页面加载发生了什么？

DNS解析
TCP连接
发送HTTP请求
服务器接收请求后返回HTTP报文
浏览器解析渲染页面
连接结束

9.各种协议与HTTP协议之间的关系

各种协议与HTTP协议之间的关系

10.HTTP长连接、短连接

短连接：短连接就是客户端和服务端每建立一次HTTP请求就会建立一次连接，任务结束后断开连接，每遇到一个web资源都会发起一个HTTP会话。
长连接：当一个网页打开完成后，服务端和客户端的HTTP会话不会关闭，当客户端再次访问或者服务端的时候会继续使用这一条已经建立的连接。

11.URI和URL的区别是什么？

URI（uniform resourse identifier）统一资源标识符
URL（uniform resourse location）统一资源定位符

为什么对URL进行编码

HTTP参数传递中有一些特殊符号，比如键值对中有取地址符号，会引起歧义，所以要进行编码，编码就是把特殊符号的各个字节前加上%号

12.HTTP和HTTPS的区别

端口：HTTP的URL是以"http://"开头，默认端口为40，HTTPS的URL是以"https://"开头，默认端口为443.
安全型和资源消耗：HTTP运行在TCP上，所传输内容都是明文，客户端和服务端都无法验证对方的身份。HTTPS运行在SSL/TSL上，传输内容经过对称加密，服务端证书又经过非对称加密，（即传输内容用对称加密，而对称加密所带来的密钥传输问题用非对称加密）所以安全性更高，但资源消耗的也更多。

SSL(Secure Socket Layer):安全套接字协议

TSL(Transport Secure Layer):传输层安全协议

对称加密：通俗的来说就是加密和解密都用一个密钥

非对称加密：通俗的来说就是加密用公钥，解密用私钥

13.Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据，保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。