手把手教你如何玩转面试（计算机网络）

        本篇是讲解关于JavaWeb岗位面试方面的一些对于计算机网络知识的整理，当然，不只是需要知道这个方面的内容，还需要掌握其他方面的知识，我都根据自己的经历来进行了整理，方便大家进行系统化的学习，只有多复习多研究，才能对技术有更好的掌握，才能拿到更好的offer。（基于博主真实的企业面试题哦~）

下面是其他方面的知识点，欢迎大家进行浏览

Java基础：https://blog.csdn.net/Cs_hnu_scw/article/details/79635874

数据结构：https://blog.csdn.net/Cs_hnu_scw/article/details/79896717

Web方向：https://blog.csdn.net/Cs_hnu_scw/article/details/79896165

数据库：https://blog.csdn.net/Cs_hnu_scw/article/details/79896384

操作系统：https://blog.csdn.net/Cs_hnu_scw/article/details/79896500

其他方面的知识：https://blog.csdn.net/Cs_hnu_scw/article/details/79896876

1：UDP和TCP的区别？

答：TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。 TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。

UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击…… UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。 基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
有些应用场景对可靠性要求不高会用到UPD，比如长视频，要求速率

它们两者之间的区别：

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

（2）、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
（3）、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
    UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
（4）、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
（5）、TCP首部开销20字节;UDP的首部开销小，只有8个字节

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

参考博文：TCP和UDP之间的区别

2：UDP应用的场景？UDP的大小？UDP在什么时候容易丢包？丢包会丢一个字节的内容吗？

答：应用场景：1.面向数据报方式

  2.网络数据大多为短消息 
  3.拥有大量Client
  4.对数据安全性无特殊要求

  5.网络负担非常重，但对响应速度要求高

比如，QQ语音，QQ视频，TFTP

大小：UDP是由首部和数据部组成，而首部占8个字节，UDP总长度不能超过65535字节，刚好可以放进到一个IP数据包中；

丢包的原因：1、接收端处理时间过长导致丢包：调用recv方法接收端收到数据后，处理数据花了一些时间，处理完后再次调用recv方法，在这二次调用间隔里,发过来的包可能丢失。对于这种情况可以修改接收端，将包接收后存入一个缓冲区，然后迅速返回继续recv。
2、发送的包巨大丢包：虽然send方法会帮你做大包切割成小包发送的事情，但包太大也不行。例如超过50K的一个udp包，不切割直接通过send方法发送也会导致这个包丢失。这种情况需要切割成小包再逐个send。
3、发送的包较大，超过接受者缓存导致丢包：包超过mtu size数倍，几个大的udp包可能会超过接收者的缓冲，导致丢包。这种情况可以设置socket接收缓冲。以前遇到过这种问题，我把接收缓冲设置成64K就解决了。
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、发送的包频率太快：虽然每个包的大小都小于mtu size 但是频率太快，例如40多个mut size的包连续发送中间不sleep，也有可能导致丢包。这种情况也有时可以通过设置socket接收缓冲解决，但有时解决不了。所以在发送频率过快的时候还是考虑sleep一下吧。
5、局域网内不丢包，公网上丢包。这个问题我也是通过切割小包并sleep发送解决的。如果流量太大，这个办法也不灵了。总之udp丢包总是会有的，如果出现了用我的方法解决不了，还有这个几个方法： 要么减小流量，要么换tcp协议传输，要么做丢包重传的工作。

不会丢一字节的内容，因为UDP的首部是8字节，都是以8的倍数内容，所以不存在丢一字节的内容；

点击：关于UDP丢包的详解文章

3：TCP应用的场景？TCP的大小？

答：场景：主要是用在对网络质量有要求的情况下，需要准确无误的进行传输，比如：（1）浏览器，用的HTTP

（2）FlashFXP，用的FTP
（3）Outlook，用的POP、SMTP
（4）Putty，用的Telnet、SSH
（5）QQ文件传输

大小：TCP的首部字节占20个字节，而在以太网中，最大的传输字节为1518字节，而还需要出去18字节的以太网帧头，所以最大就只能是1500字节，另外IP的头还有20个字节，所以TCP传输最大只能是1500-20-20=1460字节；

4：TCP和UDP应用的场景？

答：

5：HTTP和Https的区别是什么？

答：相同点：

大多数情况下，HTTP 和 HTTPS 是相同的，因为都是采用同一个基础的协议，作为 HTTP 或 HTTPS 客户端——浏览器，设立一个连接到 Web 服务器指定的端口。当服务器接收到请求，它会返回一个状态码以及消息，这个回应可能是请求信息、或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式，因此资源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。

不同点：

1. HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
4. 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
5. HTTP 无需加密，而 HTTPS 对传输的数据进行加密
6. HTTP 无需证书，而 HTTPS 需要认证证书

HTTPS 如何工作?

使用 HTTPS 连接时，服务器要求有公钥和签名的证书。当使用 https 连接，服务器响应初始连接，并提供它所支持的加密方法。作为回应，客户端选择一个连接方法，并且客户端和服务器端交换证书验证彼此身份。完成之后，在确保使用相同密钥的情况下传输加密信息，然后关闭连接。为了提供 https 连接支持，服务器必须有一个公钥证书，该证书包含经过证书机构认证的密钥信息，大部分证书都是通过第三方机构授权的，以保证证书是安全的。换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。

HTTP 包含如下动作：

1. 浏览器打开一个 TCP 连接
2. 浏览器发送 HTTP 请求到服务器端
3. 服务器发送 HTTP 回应信息到浏览器
4. TCP 连接关闭

SSL 包含如下动作：

1. 验证服务器端
2. 允许客户端和服务器端选择加密算法和密码，确保双方都支持
3. 验证客户端(可选)
4. 使用公钥加密技术来生成共享加密数据
5. 创建一个加密的 SSL 连接
6. 基于该 SSL 连接传递 HTTP 请求

什么时候该使用 HTTPS?

银行网站、支付网关、购物网站、登录页、电子邮件以及一些企业部门的网站应该使用 HTTPS

6：三次握手和四次挥手的过程

答：几个概念： 
【1】seq：序号，占4个字节，范围[0,4284967296],由于TCP是面向字节流的，在一个1个TCP连接中传送字节流中国的每一个字节都按照顺序编号，此外序号是循环使用的 
【2】ACK： 仅当ACK=1时确认字段才有效，当ACK=0时确认字段无效，并且TCP规定，在连接建立后所有的传送报文段都必须要把ACK置为1 
【3】SYN：同步序列号，用来发起一个连接。当SYN=1而ACK=0时表明这是一个请求报文段；若对方同意连接，则响应报文中SYN=1，ACK=1 
【4】FIN ：用来释放一个连接，当FIN=1表示此报文段的发送方已经发送完毕。并要求释放链接

三次握手：(1)客户端向服务器端发送连接请求包SYN（syn=j），等待服务器回应；

(2)服务器端收到客户端连接请求包SYN（syn=j）后，将客户端的请求包SYN（syn=j）放入到自己的未连接队列，此时服务器需要发送两个包给客户端；
    1.向客户端发送确认自己收到其连接请求的确认包ACK（ack=j+1），向客户端表明已知道了其连接请求
　  2.向客户端发送连接询问请求包SYN（syn=k），询问客户端是否已经准备好建立连接，进行数据通信；
(3)  客户端收到服务器的ACK（ack=j+1）和SYN（syn=k）包后，知道了服务器同意建立连接，此时需要发送连接已建立的消息给服务器；
　　向服务器发送连接建立的确认包ACK（ack=k+1），回应服务器的SYN（syn=k）告诉服务器，我们之间已经建立了连接，可以进行数据通信。
    为什么不能只两次握手？
    有了三次握手的详细步骤，就可以分析为什么需要三次握手而不是两次握手了。

    三次握手的目的：消除旧有连接请求的SYN消息对新连接的干扰，同步连接双方的序列号和确认号并交换TCP 窗口大小信息。采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费

需四次挥手原因：由于TCP的半关闭特性，TCP连接时双全工（即数据在两个方向上能同时传递），因此，每个方向必须单独的进行关闭。这个原则就是：当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向上的连接。当一端收到一个FIN后，它必须通知应用层另一端已经终止了那个方向的数据传送。即收到一个FIN意味着在这一方向上没有数据流动了。

目的：保证服务器与客户端都能完全的接受对方发送的数据。
假设客户机A向服务器B请求释放TCP/IP连接，则：
第一次挥手： 主机A向主机B发送FIN包；A告诉B，我（A）发送给你（B）的数据大小是N，我发送完毕，请求断开A->B的连接。
第二次挥手： 主机B收到了A发送的FIN包，并向主机A发送ACK包；B回答A，是的，我总共收到了你发给我N大小的数据，A->B的连接关闭。
第三次挥手： 主机B向主机A发送FIN包；B告诉A，我（B）发送给你（A）的数据大小是M，我发送完毕，请求断开B->A的连接。
第四次挥手： 主机A收到了B发送的FIN包，并向主机B发送ACK包；A回答B，是的，我收到了你发送给我的M大小的数据，B->A的连接关闭。

7：为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

8：OSI七层模型和TCP/IP四层模型

答：

https://blog.csdn.net/cwg_1992/article/details/17504343

https://blog.csdn.net/leiflyy/article/details/50096567

9：从url到页面的过程到底是如何进行的？(重点的重点)

答：这个题，在自己面百度和腾讯的时候都有被问到；

https://blog.csdn.net/mevicky/article/details/46789381

https://blog.csdn.net/samjustin1/article/details/52650520

https://blog.csdn.net/ty987654/article/details/78007319

10：网络管理应具有哪几个功能？

答：（1）配置管理（2）性能管理（3）故障管理（4）安全管理（5）计费管理

11：传输层的拥塞控制？

答：https://blog.csdn.net/u010796790/article/details/52853539

12：请说说QQ在哪些地方用的是TCP协议，哪些用的是UDP协议？

答：https://blog.csdn.net/smartsmile2012/article/details/51606430?locationNum=5&fps=1

13：从一台主机到另外一台主机发送一个数据包在传输的过程中，其IP地址和MAC地址是如何进行变化的？

答：比如：假设网络上要将一个数据包（名为PAC）由北京的一台主机（名称为A，IP地址为IP_A，MAC地址为MAC_A）发送到华盛顿的一台主机（名称为B，IP地址为IP_B，MAC地址为MAC_B）。

（1）这两台主机之间不可能是直接连接起来的，因而数据包在传递时必然要经过许多中间节点（如路由器，服务器等等），我们假定在传输过程中要经过C1、C2、C3（其MAC地址分别为M1，M2，M3）三个节点。
（2）A在将PAC发出之前，先发送一个ARP请求，找到其要到达IP_B所必须经历的第一个中间节点C1的MAC地址M1，然后在其数据包中封装（Encapsulation）这些地址：IP_A、IP_B，MAC_A和M1。
（3）当PAC传到C1后，再由ARP根据其目的IP地址IP_B，找到其要经历的第二个中间节点C2的MAC地址M2，然后再将带有M2的数据包传送到C2。
（4）如此类推，直到最后找到带有IP地址为IP_B的B主机的地址MAC_B，最终传送给主机B。
（5）在传输过程中，IP_A、IP_B和MAC_A不变，而中间节点的MAC地址通过ARP在不断改变（M1，M2，M3），直至目的地址MAC_B。

温馨提示：（1）在数据包的传输过程中，源IP地址和目的IP地址是不会发生变化的，变化的只是在传输过程中的MAC地址

（2）路由器是在OSI模型中的网络层，交换机是在OSI模型中的数据链路层，集线器是在OSI模型中的物理层

（3）Ping 发出的是ICMP协议

更多的详情可以参考：重点文章：https://blog.csdn.net/thisispan/article/details/7587998

（1）为什么需要IP地址和MAC地址https://blog.csdn.net/captain_pirate/article/details/25950545

（2）Mac和IP地址的变化：https://blog.csdn.net/xbgprogrammer/article/details/50507451 

                                      和https://blog.csdn.net/wocjj/article/details/8490397

（3）数据包传输过程的全解析：https://blog.csdn.net/u013485792/article/details/50925201

14：路由器和交换机的区别有哪些？

答：https://blog.csdn.net/xjbclz/article/details/51884359

15：

    这并不是终点，而是我刚刚的开始，我会一直不断将知识点进行更新，欢迎大家进行关注和阅读！！！