【81-100】计算机网络基础知识（非常详细）从零基础入门到精通，看完这一篇就够了

以下是本文参考的资料 欢迎大家查收原版 本版本仅作个人笔记使用

• https://interviewguide.cn/notes/03-hunting_job/02-interview/03-05-net.html

• https://interviewguide.cn/notes/03-hunting_job/02-interview/03-06-net.html

• 《TCP 拥塞控制算法简介》：https://yq.aliyun.com/articles/691978

• 《TCP快速重传为什么是三次冗余ack，这个三次是怎么定下来的？》：https://blog.csdn.net/u010202588/article/details/54563648

• 《TCP新手误区–数据校验的意义》：https://blog.csdn.net/bjrxyz/article/details/75194716

• 《TCP数据段格式+UDP数据段格式详解》：https://www.cnblogs.com/love-jelly-pig/p/8471181.md

• 《OSI七层模型与TCP/IP五层模型》：https://www.cnblogs.com/qishui/p/5428938.md

• 《TCP协议中的窗口机制------滑动窗口详解》：https://blog.csdn.net/m0_37962600/article/details/79951780

• https://www.zhihu.com/question/34873227/answer/518086565

• https://www.cnblogs.com/wqhwe/p/5407468.md

81、对于FIN_WAIT_2，CLOSE_WAIT状态和TIME_WAIT状态？你知道多少?

• FIN_WAIT_2：

  • 半关闭状态。

  • 发送断开请求一方还有接收数据能力，但已经没有发送数据能力。

• CLOSE_WAIT状态：

  • 被动关闭连接一方接收到FIN包会立即回应ACK包表示已接收到断开请求。

  • 被动关闭连接一方如果还有剩余数据要发送就会进入CLOSE_WAIT状态。

• TIME_WAIT状态：

  • 又叫2MSL等待状态。
  • 如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，所以服务端就不会收到ACK而是收到RST。所以TIME_WAIT状态目的是防止最后一次握手数据没有到达对方而触发重传FIN准备的。
  • 在2MSL时间内，同一个socket不能再被使用，否则有可能会和旧连接数据混淆（如果新连接和旧连接的socket相同的话）。

82、你了解流量控制原理吗？

• 目的是接收方通过TCP头窗口字段告知发送方本方可接收的最大数据量，用以解决发送速率过快导致接收方不能接收的问题。所以流量控制是点对点控制。

• TCP是双工协议，双方可以同时通信，所以发送方接收方各自维护一个发送窗和接收窗。

  • 发送窗：用来限制发送方可以发送的数据大小，其中发送窗口的大小由接收端返回的TCP报文段中窗口字段来控制，接收方通过此字段告知发送方自己的缓冲（受系统、硬件等限制）大小。

  • 接收窗：用来标记可以接收的数据大小。

• TCP是流数据，发送出去的数据流可以被分为以下四部分：

  • 已发送且被确认部分 | 已发送未被确认部分 | 未发送但可发送部分 | 不可发送部分
  • 其中发送窗 = 已发送未确认部分 + 未发但可发送部分。

• 接收到的数据流可分为：

  • 已接收 | 未接收但准备接收 | 未接收不准备接收。
  • 接收窗 = 未接收但准备接收部分。

• 发送窗内数据只有当接收到接收端某段发送数据的ACK响应时才移动发送窗，左边缘紧贴刚被确认的数据。接收窗也只有接收到数据且最左侧连续时才移动接收窗口。

84、TCP 协议如何保证可靠传输？

• 确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就会重传。
• 数据校验：TCP报文头有校验和，用于校验报文是否损坏。
• 数据合理分片和排序：tcp会按最大传输单元(MTU)合理分片，接收方会缓存未按序到达的数据，重新排序后交给应用层。而UDP：IP数据报大于1500字节，大于MTU。这个时候发送方的IP层就需要分片，把数据报分成若干片，是的每一片都小于MTU。而接收方IP层则需要进行数据报的重组。由于UDP的特性，某一片数据丢失时，接收方便无法重组数据报，导致丢弃整个UDP数据报。
• 流量控制：当接收方来不及处理发送方的数据，能通过滑动窗口，提示发送方降低发送的速率，防止包丢失。
• 拥塞控制：当网络拥塞时，通过拥塞窗口，减少数据的发送，防止包丢失。

85、UDP是什么？

提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。

86、TCP和UDP的区别

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接

2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付

3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的

UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信

5、TCP首部开销20字节;UDP的首部开销小，只有8个字节

6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

7、UDP是面向报文的，发送方的UDP对应用层交下来的报文，不合并，不拆分，只是在其上面加上首部后就交给了下面的网络层，论应用层交给UDP多长的报文，它统统发送，一次发送一个。而对接收方，接到后直接去除首部，交给上面的应用层就完成任务了。因此，它需要应用层控制报文的大小

TCP是面向字节流的，它把上面应用层交下来的数据看成无结构的字节流会发送，可以想象成流水形式的，发送方TCP会将数据放入“蓄水池”（缓存区），等到可以发送的时候就发送，不能发送就等着TCP会根据当前网络的拥塞状态来确定每个报文段的大小。

补充题：封包和拆包你听说过吗？它是基于TCP还是UDP的？

封包和拆包都是基于TCP的概念。因为TCP是无边界的流传输，所以需要对TCP进行封包和拆包，确保发送和接收的数据不粘连。

封包：封包就是在发送数据报的时候为每个TCP数据包加上一个包头，将数据报分为包头和包体两个部分。包头是一个固定长度的结构体，里面包含该数据包的总长度。
拆包：接收方在接收到报文后提取包头中的长度信息进行截取。

87、UDP的特点有哪些（附赠TCP的特点）？

• UDP是无连接的；
• UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；
• UDP是面向报文的；
• UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）；
• UDP支持一对一、一对多、多对一和多对多的交互通信；
• UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。

那么，再说一次TCP的特点：

TCP是面向连接的。（就好像打电话一样，通话前需要先拨号建立连接，通话结束后要挂机释放连接）；
每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点的（一对一）；
TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达；
TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
面向字节流。TCP中的“流”（stream）指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

88、TCP对应的应用层协议

FTP：定义了文件传输协议，使用21端口.
Telnet：它是一种用于远程登陆的端口,23端口
SMTP：定义了简单邮件传送协议，服务器开放的是25号端口。
POP3：它是和SMTP对应，POP3用于接收邮件。

89、UDP对应的应用层协议

DNS：用于域名解析服务，用的是53号端口
SNMP：简单网络管理协议，使用161号端口
TFTP(Trival File Transfer Protocal)：简单文件传输协议，69

90、数据链路层常见协议？可以说一下吗？

91、Ping命令基于什么协议？原理是什么？

ping是基于网络层的ICMP协议实现的。通过向对方发送一个ICMP回送请求报文，如果对方主机可达的话会收到该报文，并响应一个ICMP回送回答报文。

扩展：ICMP报文的介绍。ICMP报文分为两个种类：

1. ICMP差错报告报文，常见的有
   • 终点不可达
   • 时间超过
   • 参数问题
   • 改变路由
2. ICMP询问报文
   • 回送请求和回答：向特定主机发出回送请求报文，收到回送请求报文的主机响应回送回答报文。
   • 时间戳请求和回答：询问对方当前的时间，返回的是一个32位的时间戳。

92、在进行UDP编程的时候，一次发送多少bytes好?

当然,这个没有唯一答案，相对于不同的系统,不同的要求,其得到的答案是不一样的。

我这里仅对像ICQ一类的发送聊天消息的情况作分析，对于其他情况，你或许也能得到一点帮助:首先,我们知道,TCP/IP通常被认为是一个四层协议系统,包括链路层,网络层,运输层,应用层.UDP属于运输层。

下面我们由下至上一步一步来看:
以太网(Ethernet)数据帧的长度必须在46-1500字节之间，这是由以太网的物理特性决定的.这个1500字节被称为链路层的MTU(最大传输单元).但这并不是指链路层的长度被限制在1500字节,其实这这个MTU指的是链路层的数据区，并不包括链路层的首部和尾部的18个字节。

所以,事实上,这个1500字节就是网络层IP数据报的长度限制。因为IP数据报的首部为20字节,所以IP数据报的数据区长度最大为1480字节.而这个1480字节就是用来放TCP传来的TCP报文段或UDP传来的UDP数据报的，又因为UDP数据报的首部8字节，所以UDP数据报的数据区最大长度为1472字节，这个1472字节就是我们可以使用的字节数。

当我们发送的UDP数据大于1472的时候会怎样呢？

这也就是说IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation). 把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组. 这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便 无法重组数据报.将导致丢弃整个UDP数据报。

因此,在普通的局域网环境下，我建议将UDP的数据控制在1472字节以下为好.

进行Internet编程时则不同,因为Internet上的路由器可能会将MTU设为不同的值. 如果我们假定MTU为1500来发送数据的,而途经的某个网络的MTU值小于1500字节,那么系统将会使用一系列的机 制来调整MTU值,使数据报能够顺利到达目的地,这样就会做许多不必要的操作.

鉴于Internet上的标准MTU值为576字节，所以我建议在进行Internet的UDP编程时. 最好将UDP的数据长度控件在548字节(576-8-20)以内

93、TCP 利用滑动窗口实现流量控制的机制？

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

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据。

例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

94、可以解释一下RTO，RTT和超时重传分别是什么吗？

1. 超时重传：发送端发送报文后若长时间未收到确认的报文则需要重发该报文。可能有以下几种情况：

   • 发送的数据没能到达接收端，所以对方没有响应。

   • 接收端接收到数据，但是ACK报文在返回过程中丢失。

   • 接收端拒绝或丢弃数据。

2. RTO：从上一次发送数据，因为长期没有收到ACK响应，到下一次重发之间的时间。就是重传间隔。

   • 通常每次重传RTO是前一次重传间隔的两倍，计量单位通常是RTT。例：1RTT，2RTT，4RTT，8RTT…

   • 重传次数到达上限之后停止重传。

3. RTT：数据从发送到接收到对方响应之间的时间间隔，即数据报在网络中一个往返用时。大小不稳定。

95、XSS攻击是什么？（低频）

跨站点脚本攻击，指攻击者通过篡改网页，嵌入恶意脚本程序，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。如何防范XSS攻击 1）前端，服务端，同时需要字符串输入的长度限制。 2）前端，服务端，同时需要对HTML转义处理。将其中的”<”,”>”等特殊字符进行转义编码。 防 XSS 的核心是必须对输入的数据做过滤处理。

96、CSRF攻击？你知道吗？

跨站点请求伪造，指攻击者通过跨站请求，以合法的用户的身份进行非法操作。可以这么理解CSRF攻击：攻击者盗用你的身份，以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件，发短信，进行交易转账，甚至盗取账号信息。

97、如何防范CSRF攻击

安全框架，例如Spring Security。 token机制。在HTTP请求中进行token验证，如果请求中没有token或者token内容不正确，则认为CSRF攻击而拒绝该请求。 验证码。通常情况下，验证码能够很好的遏制CSRF攻击，但是很多情况下，出于用户体验考虑，验证码只能作为一种辅助手段，而不是最主要的解决方案。 referer识别。在HTTP Header中有一个字段Referer，它记录了HTTP请求的来源地址。如果Referer是其他网站，就有可能是CSRF攻击，则拒绝该请求。但是，服务器并非都能取到Referer。很多用户出于隐私保护的考虑，限制了Referer的发送。在某些情况下，浏览器也不会发送Referer，例如HTTPS跳转到HTTP。 1）验证请求来源地址； 2）关键操作添加验证码； 3）在请求地址添加 token 并验证。

98、文件上传漏洞是如何发生的？你有经历过吗？

文件上传漏洞，指的是用户上传一个可执行的脚本文件，并通过此脚本文件获得了执行服务端命令的能力。 许多第三方框架、服务，都曾经被爆出文件上传漏洞，比如很早之前的Struts2，以及富文本编辑器等等，可被攻击者上传恶意代码，有可能服务端就被人黑了。

99、如何防范文件上传漏洞

文件上传的目录设置为不可执行。

1）判断文件类型。在判断文件类型的时候，可以结合使用MIME Type，后缀检查等方式。因为对于上传文件，不能简单地通过后缀名称来判断文件的类型，因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型，诱导用户执行。

2）对上传的文件类型进行白名单校验，只允许上传可靠类型。

3）上传的文件需要进行重新命名，使攻击者无法猜想上传文件的访问路径，将极大地增加攻击成本，同时向shell.php.rar.ara这种文件，因为重命名而无法成功实施攻击。

4）限制上传文件的大小。

5）单独设置文件服务器的域名。

100、拥塞控制原理听说过吗？

拥塞控制目的是防止数据过多注入到网络中导致网络资源（路由器、交换机等）过载。因为拥塞控制涉及网络链路全局，所以属于全局控制。控制拥塞使用拥塞窗口。
TCP拥塞控制算法：
慢开始 & 拥塞避免：先试探网络拥塞程度再逐渐增大拥塞窗口。假设窗口长度为d，收到一个确认就加1，正好收到了d个确认，所以一共加d，正好是翻倍，直到达到阀值ssthresh，这部分是慢开始过程。达到阀值后每次以一个MSS为单位增长拥塞窗口大小，当发生拥塞（超时未收到确认），将阀值减为原先一半，继续执行增加，这个过程为拥塞避免。
快速重传 & 快速恢复：略。
最终拥塞窗口会收敛于稳定值。

101、如何区分流量控制和拥塞控制？

流量控制属于通信双方协商；拥塞控制涉及通信链路全局。

• 流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；
• 拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。

实际最终发送窗口 = min{流控发送窗口，拥塞窗口}。

102、常见的HTTP状态码有哪些？

1xx 信息

• 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2xx 成功

• 200 OK
• 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
• 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

3xx 重定向

• 301 Moved Permanently ：永久性重定向
• 302 Found ：临时性重定向
• 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
• 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
• 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

4xx 客户端错误

• 400 Bad Request ：请求报文中存在语法错误。
• 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
• 403 Forbidden ：请求被拒绝。
• 404 Not Found

5xx 服务器错误

• 500 Internal Server Error ：服务器正在执行请求时发生错误。
• 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

103、服务器出现大量close_wait的连接的原因是什么？有什么解决方法？

close_wait状态是在TCP四次挥手的时候收到FIN但是没有发送自己的FIN时出现的，服务器出现大量close_wait状态的原因有两种：

• 服务器内部业务处理占用了过多时间，都没能处理完业务；或者还有数据需要发送；或者服务器的业务逻辑有问题，没有执行close()方法
• 服务器的父进程派生出子进程，子进程继承了socket，收到FIN的时候子进程处理但父进程没有处理该信号，导致socket的引用不为0无法回收

处理方法：

• 停止应用程序
• 修改程序里的bug

104、一台机器能够使用的端口号上限是多少，是否可以修改？如果想要用的端口超过这个限制怎么办？

65536
因为TCP的报文头部中源端口号和目的端口号的长度是16位，也就是可以表示$2^{16}=65536$个不同端口号，因此TCP可供识别的端口号最多只有65536个。但是由于0到1023是知名服务端口，所以实际上还要少1024个端口号。

而对于服务器来说，可以开的端口号与65536无关，其实是一台机器能够使用的端口号上限取决于操作系统和网络协议栈的限制。在常见的操作系统中，如Linux、Windows等，通常情况下，端口号的上限是由一个16位的整数来表示，即最大端口号为65535，并且可以通过MaxUserPort来进行配置。

如果需要使用的端口超过了操作系统默认的端口号上限，可以考虑以下几种解决方案：

• 调整应用设计：重新设计应用程序，考虑使用已经开放的端口号或者共享端口号等技术来解决端口不足的问题。

• 使用多台机器：将应用程序部署在多台机器上，每台机器使用一部分端口，从而扩展端口的可用范围。

• 使用端口转发：在前端部署负载均衡器或者反向代理服务器，通过端口转发技术将外部请求转发到不同的端口或者不同的机器上，从而实现端口的复用和扩展。

• 修改操作系统或网络协议栈：虽然通常情况下用户无法直接修改端口号上限，但在一些特殊情况下可能可以通过修改操作系统或网络协议栈的配置或者定制内核的方式来实现。不过这种做法需要谨慎，可能会导致系统不稳定或者安全性问题。