计算机网络基础+HTTP知识点总结

1.什么是DHCP？执行流程？

DHCP就是动态主机配置协议。作用就是为新加入网络中的主机分配一个合法的ip地址。

当一台主机新加入网络中时，它只持有自身的MAC地址，还没有ip地址，此时它会发出一个DHCP Discover，具体的做法就是发送一个广播包，源IP地址是0.0.0.0，目的IP地址是255.255.255.255，并且使用UDP进行传输。

DHCP server接受到这个请求后，就会为当前主机分配一个ip地址，并且同样通过UDP进行回传，这个过程叫做DHCP offer

主机收到DHCP offer后，还需要发起一次确认。因为有可能不止一个DHCP为它分配ip，所以它完全有可能收到多个offer，那么主机一般来说会选择第一个到达的DHCP offer来使用。然后会给这些DHCP server分别发送一个DHCP request，用来表明自己将要接受的ip。提供此ip的DHCP server就会发送DHCP ACK消息包来确认。那么主机就成功分配到一个ip地址，加入到网络之中了。

2.说一下TCP的三次握手？为什么是三次？二次不行嘛？

大写：xx控制块 seq：初始序号 ack：确认序号

因为TCP是面向连接的可靠传输，所以在传输之前必须经过三次握手建立连接，具体的流程就是：

建立连接就需要有客户端和服务端嘛，一开始的时候客户端处于CLOSED状态，而服务端处于LISTEN状态等待客户端的连接

1）客户端发送一个连接请求，其中包含同步控制位SYN=1，挑选一个随机的传输数据信号seq=x。然后客户端从CLOSED态转为SYN_SENT态，等待服务端的回应

2）服务端收到连接请求后，如果同意连接，就会给客户端发回一个确认请求，其中就包括同步控制位SYN=1和确认控制位ACK=1，请求信号ack=x+1,随机挑选一个传输数据信号=y。且服务端从LISTEN状态转化为SYN_RCVD状态。

3）客户端收到服务端的确认请求，然后发送二次确认，请求中包含ACK确认控制位，以及请求信号ack=y+1。然后客户端转为ESTABLISHED状态

4）服务端接受到客户端发来的二次请求。于是也转为ESTABLISHED状态，连接正式建立了

之所以是三次握手，是因为防止某个已经过期的连接请求突然又到达服务端，造成资源浪费的现象。

比如说客户端向服务端发送一个连接请求，但这个连接请求因为种种原因比如说网络堵塞，没有按时到达服务端，此时客户端等待一个超时重传时间后便会重新开始发送连接请求，然后连接成功进行数据传输，然后再断开连接。此时最开始的连接请求终于到达了服务端，若没有客户端的二次确认也就是第三次握手的话，此时服务端就会直接打开连接，这个资源就被白白浪费了。

3.说一下TCP的四次挥手？最后为什么要等待一个超时时间？

TCP四次挥手是TCP断开连接的过程。

首先在断开连接之前，客户端和服务端都是处于ESTABLISHED状态。

1）客户端发送一个断开连接的请求，请求包含一个结束控制位FIN=1，随机选取一个值作为数据发送信号seq=x，然后客户端从ESTABLISHED状态转化为FIN_WAIT的第一状态。客户端发出这个请求的语义就是：自己已经没有其他数据要传输了，即将准备关闭连接，但是服务端还可以进行传输，客户端也可以进行接受

2）服务端接受到请求后，发送一个确认信号，其中包含了一个ACK确认控制位=1，随机选取一个数据发送信号seq=y，ack请求信号=x+1。然后从ESTABLISHED态转化为CLOSE_WAIT状态。

3）客户端接受到这个确认信号后，从FIN_WAIT的第一状态转化为第二状态。然后此时服务端可以完成剩下的数据发送，客户端进行接受

4）当服务端传送完所有数据后，此时就真的可以准备关闭连接了。服务端发送一个断开连接请求，其中包含FIN控制位=1，确认控制位ACK=1，再随机选取一个数作为数据传输信号seq=v，请求字段ack=x+1，并且自身进入LAST_ACK状态，等待客户端的确认信号

5）客户端收到信号后，最后发送一个确认信号，包含ACK确认控制位=1，，然后等待一个超时时间后，进入CLOSED状态。

6）服务端收到客户端的确认信号，然后就进入CLOSED状态，连接断开。

最后客户端等待一个超时时间主要有两个原因：

• 为了防止确认信号丢失，导致服务端无法关闭：如果客户端发送完确认信号就直接进入CLOSED状态的话，如果这个确认信号丢失了，那么服务端就无法接收到，所以服务端就无法被关闭。等待一个超时时间就是为了避免这样的情况发生
• 使本次连接产生的一些请求尽可能在网络中耗尽，防止干扰下一次连接的请求传递。

4.TCP协议如何保证传输的可靠性？

因为网络层并没有提供可靠传输，所以数据正确性要在传输层中得到保证。

• 数据包检验：TCP接受端在接受数据包时需要对数据包的正确性进行检验，若发现有错误发生，则把该数据包丢弃然后什么都不做，发送端等待一个超时重传时间后就会重新发送该数据包。
• 丢失重复数据：每个数据包都会有一个编号，如果接受端发现收到的编号有重复的话。
• 超时重传机制：因为TCP接受端在成功接受到数据块之后必须向发送端发出一个确认信号，来通知传输的成功。所以说发送端如果在一个时间内没有接受到接受端的确认信号，就会认为此次发送失败，进行重传
• 流量控制和拥塞控制：流量控制主要是协调发送端和接受端的发送窗口大小，让接受端传回receive windows信号来限制发送端的窗口大小。而拥塞控制是用来协调发送端接受端的发送窗口要根据网络情况进行调整。分为慢开始-拥塞避免，和快重传-快开始

5.说一下TCP的流量控制？

TCP的流量控制主要是为了协调发送端和接受端的传输速度，避免出现发送太快而来不及接收，导致大量数据块丢失的情况发生。

TCP主要是通过滑动窗口来解决这个问题的。

对于发送端来说，滑动窗口的实现由三个指针构成，其中两个指针就划定了窗口的范围，而中间一个指针指示的是已发送字节与未发送字节的一个界限。那随着字节发送，这个指针会不断向右边移动，直到它和窗口边缘重合时，就无法继续发送了，此时如果接受端发回一个确认信号，整个窗口才可以向右移动

对于接受端来说，同样有一个接受窗口，并且和传统的停止等待方法不一样的是，接受端并不需要对每一个成功接受的字节都发回一个确认信号，只需要发送成功接受的所有字节中的最后一个字节就可以了。比如发回的确认信号中确认序号ack=201，说明201之前的所有字节都已经成功接受了，下一次从201开始发送就可以。另外信号中还会有一个receive window序号，它就是真正用来控制发送端窗口大小的，比如说这个字段为300，那么发送端接受到之后就会把自己窗口大小调整为300.

6.说一下TCP的拥塞控制？

TCP的拥塞控制主要是从网络拥塞情况的角度去协调发送端和接受端的窗口值。TCP拥塞控制主要有两种，一种是叫慢开始-拥塞避免算法 一种是叫快重传-快开始算法

慢开始-拥塞避免算法：这个算法会设置一个慢开始门限，默认值为16，初始窗口大小设为1；当窗口大小小于慢开始门限时，窗口大小是指数级增长的。而在超过慢开始门限后，增长速度变慢，开始使用拥塞避免算法了，也就是每次只增长1，但是一直增长下去，也总有发生网络阻塞的时候，当发生网络阻塞时；窗口值又被重新设为1，然后慢开始门限被更新为发生阻塞时窗口值的一半，然后继续进行增长；之所以说慢开始，是因为发生阻塞之后，窗口被初始化为了1.

快重传-快开始：快重传说的是，当发送端连续三次收到了同样的确认信号，说明有数据丢失了，此时无需等待超时等待的时间，就直接进行数据重传了，这就是快重传。而这个方法同样也需要维护一个慢开始门限，也是按照同样的增长方法；当发送端连续三次收到了同样的确认信号，就直接执行快重传，然后将慢开始门限设置为当前窗口值的一半，然后让窗口值更新为和慢开始门限一样，然后继续执行阻塞避免。快开始就体现在发生重传之后，窗口值不需要回到1，而是从慢开始门限开始继续增长

7.什么是DDos攻击？如何预防？

DDos攻击就是客户端不断地向服务端发送连接请求，并且服务端会为每一个请求创建一个连接，并且发送确认数据包，并等待客户端的二次确认。制造大量的客户端连接请求就可以加大服务端的负载，实现DDos攻击

预防：

1.限制服务端打开半连接的数目

8.如果三次握手中的第三次握手失败了，会怎么样？

如果第三次握手失败了，客户端仍然会处于ESTABLISHED，也就是连接建立的状态，而服务端会处于SYNC_RCVD状态。如果服务端等待一次超时重传时间后仍然没有接受到客户端的确认，会重新发送带有同步控制块SYN和确认控制块ACK的数据包，也就是重新进行第二次握手。当然会有重传上限次数，在Linux中可以进行参数的修改，默认的是5次。如果五次重传依然不成功，那么服务端就会关闭这个连接了。

而对客户端来说，它在进行完第二次握手后就已经处于连接状态了，只有当服务端重新发来确认数据包的时候，客户端才能意识到第三次握手失败

9.GET和POST的区别？

• 从功能上来说，GET请求一般是用来从服务器上获取资源，而POST请求是更新服务器上的资源
• 从请求参数上来说。GET请求会将请求参数拼接到URL后，也就是会将请求参数写在请求头中，以？来分割URL和请求参数。如果参数是中文或者其他字符的话，还需要使用BASE64进行加密，得出如%E4%BD%A0%E5%A5%BD这样的格式。而%后面所跟的就是该字符的ASCLL码的16进制表示。而POST请求来说，它会将请求参数包装在请求体中，所以相对于GET请求来说更加安全。
• 从大小来看。因为GET请求会将请求参数拼接到URL后，并且浏览器和服务器对URL的长度会有限制，所以GET请求发送的数据量比较小；而POST请求的参数包装在请求体中，没有大小限制
• GET请求只能支持ASCLL字符，如果传递中文字符可能会出现乱码；POST请求标准字符集，可以正确传递中文字符

10.TCP和UDP的区别？

TCP和UDP都是传输层的协议，它们的区别是：

• TCP是面向连接的，在进行数据传输的前后必须要进行连接的创建和释放；而UDP是无连接的，无需创建连接就可以直接进行数据传输
• TCP是可靠传输；TCP必须保证传输的每个数据都能准确无误地被接受，所以接受端在收到数据块之中，必须还回传一个确认信号。TCP使用像数据包检验，超时重传，流量控制，拥塞控制等方法来保证可靠传输；而UDP是不可靠传输，在接受到数据之后，不需要回传任何信息，所以发送端也不知道数据块是否被成功接收到
• TCP是面向字节流的。也就是说对于TCP来说处理的数据是字节流，自己只是把字节流划分为大小不同的各个数据块。而UDP是面向报文的，也就是说，UDP对从应用层获得的报文不会作任何处理，只是简单地加上UDP首部就可以进行传输。

11.从浏览器输入一个网址到获得页面的过程?

1）从浏览器输入一个URL，那么就会以依此从浏览器缓存，主机缓存，本地域名服务器中查看是否有对应的DNS缓存，如果有的话，就直接获得该域名对应的IP地址；否则的话就要以一个递归的方式进行DNS解析，具体的流程就是先去获取根域名地址，然后获取一级域名地址，最后一步步获得该域名对应的IP地址

2）获取到IP地址后，在传输层进行端口号的配置，然后通过三次握手建立TCP连接

3）TCP连接建立起来之后，浏览器向服务器发送HTTP请求。

4）接下来就是网络层的工作，网络层的主要工作就是去按照路由表去选择最佳的路由路径。当然这个工作不只会进行一次，在路由器间的每次跳转都会执行这个过程。路由选择协议一般有RIP（基于距离向量的路由选择协议）和OSPF（基于最短路径的路由选择协议。这里的最短路径综合了时延，带宽等因素的最短，而不仅仅是跳数）

5）接下来就是使用ARP协议根据IP地址获取MAC物理地址了，解析出MAC物理地址后，在链路层封装成帧，然后交付物理层进行运输

6）服务端接受到请求后，将请求的资源进行返回。

7）浏览器获取到请求的资源，根据这些资源和数据渲染页面，最后向用户呈现一个完整的页面

12.ARP协议工作原理

ARP协议是网络层的一个协议，它的作用就是完成一个局域网内IP地址与MAC物理地址的一个映射。

首先，每台主机都会维护一个ARP高速缓存，其中存放着本局域网内一部分结点的IP地址与MAC地址的映射。当源主机有一个数据包需要发送到目的主机时，首先会查看主机的ARP高速缓存下是否有对应的映射关系，如果有的话可以直接完成转化。如果没有，源主机会发起一个ARP请求的广播包，广播到当前局域网内的所有主机中，每个主机都会查看请求中的目的IP和自己的IP是否相同，如果不相同则直接忽视，如果相同，那么目的主机首先会将源主机的IP地址和MAC地址记录到自己的缓存中，然后通过单播向源主机发送ARP响应数据包，然后源主机就会记录下这个映射关系。如果源主机一直没有收到ARP响应数据包，表示ARP查询失败

13.OSI七层模型了解吗？

OSI七层模型是国际标准组织提出的一种网络参考模型，对比常见的TCP/IP五层模型，它在传输层和应用层之间多了表示层和会话层这两层。在TCP/IP五层模型中，这两层实际上是归入了应用层中。

那表示层的作用就是确保不同类型的主机可以完成通信。具体的操作包括对数据进行压缩和解压，语言翻译，在安全层面上来看，对数据进行加密和解密。比如HTTPS的安全保证就在这一层完成

会话层负责维护网络中结点之间的通信会话。

这两个再加上应用层可以称为这个网络模型中的资源子网，而下面四层可以称为通信子网

14.TCP/IP四层模型了解吗？

TCP/IP四层模型就是应用层，传输层，网络层，接口层。它和最常见的五层模型相比呢，就是将链路层和物理层合并成为了接口层

15.你知道对称加密和非对称加密吗？

对称加密就是说对数据的加密和解密使用的是同一个密钥。也就是说通信一方会生成一个密钥用于对于数据进行加密，加密完成后，会将该密钥发送给通信另一方。通信另一方接收到密钥后，就可以以此来对信息进行解密

• 优点：实现简单，而且速度快
• 缺点：对称加密最大的问题就是密钥的传输，密钥在网络中进行传输这个过程依然是有风险的，可能会被黑客拦截下来。所以说对称加密的安全性不太高

非对称加密就是说数据的加密和解密用的是不同的密钥，并且只有同一对密钥才可以对消息进行加密解密。通信一方会生成两个密钥，一个作为私钥自己报关，另外一个作为公钥发送通信另一方，通信另一方用公钥对消息进行加密后并发送，持有私钥的一方就可以使用私钥对数据进行解密

• 优点：安全性得到了很好的保障
• 缺点：速度相对于对称加密来说较慢

16.HTTP和HTTPS有什么区别？

http是超文本传输协议，并且它是明文传输，也就是说如果有第三方将http请求拦截下来，是可以直接读懂请求内容的。所以不适用于用来传输一些敏感信息。

https是安全，使用ssl来验证客户端和服务端的身份，并且可以对传输数据进行加密。具体的做法就是使用对称加密与非对称加密混合，再加上第三方证书来完成。

• 首先客户端用https的URL去访问服务器，请求建立SSL连接。这个请求包括用来识别身份的客户端证书，客户端支持支持的SSL版本，以及可以使用的加密算法。
• 服务端收到连接后，确认证书无误后，会生成一对非对称加密的密钥，然后第三方证书机构使用密钥对其中的公钥进行加密，然后生成一个公钥数字签名证书，服务端将这个证书发送给客户端
• 客户端接受到之后，首先要对数字签名进行检验，浏览器一般有内置的证书私钥，无需从其他地方获取，使用私钥对数字签名进行解密并验证，验证通过后（为了防止中间人将公钥进行了替换）。生成一个对称加密的密钥，然后使用传过来的公钥对这个密钥进行加密之后，发送给服务端。
• 服务端收到之后，使用非对称加密的私钥对密钥进行解密，那么就获得了双方进行通信的这个对称密钥了。此后就可以进行通信

区别：

• HTTP它是明文传输，是不安全；而HTTPS具有SSL加密传输协议
• 所使用的端口不一样，HTTP使用80端口，而HTTPS使用443端口
• HTTPS需要进行一些额外的加密解密以及验证操作，所以速度比较慢
• HTTPS需要申请CA证书，这个证书是第三方的，所以需要支付费用

17.常用的HTTP方法说一下？

• GET：用于请求资源，它的请求参数会拼接到URI上，所以有长度限制
• POST：用于向服务器传输数据，请求参数会在报文请求体上，而不会在URI上
• PUT：用于传输文件，文件内存在报文主体上，保存到对应URI位置
• DELETE：用于删除文件，和PUT方法相反。
• HEAD：和GET有点类似，但它只会获取报文首部，一般用来检查URI的有效性以及资源更新时间
• OPTION：查询对应URI所支持的一些HTTP方法，在应答报文上的首部会有一个Allow字段，后面就跟着所有支持的HTTP方法

18.HTTP1.1版本新特性

• 1.提供持久连接：在1.1之前的版本，每次连接只能进行一次请求；比如说假设我请求一个html文件，其中除了文件之外里面还有两个图片资源，那么在以前的版本就要进行三次TCP连接的创建与销毁。这是一个很浪费资源的操作。在1.1版本开始就默认持久连接，也就是一次连接可以进行多次请求，只要客户端和服务端任意一端没有明确要断开连接，连接就可以保存下去。其实1.0的版本也可以进行持久连接，但是没有在规范里面，而1.1只是将它加入了规范之中，成为了一种默认情况
• 管线化：就是连续发送多个请求，而不需要一个个等待回应。
• 断点续传：客户端从服务端中下载资源，进行到一半的时候发生了网络中断，下次重连的时候只需要继续传输剩下的片段即可。实现原理就是客户端请求报文首部会有一个Range字段，它指示了已经下载的字节数，那么服务端收到之后直接传输接下来的内容即可。当然还会有一个版本号，防止在这期间文件进行了更新。

19.Cookie和Session的区别？

Cookie和Session可以说都是对HTTP功能的一个拓展。因为HTTP是无连接的，也就是说只要连接关闭之后，是无法记忆之前发生的请求或者响应状态的，但是很多时候都需要实现这种类似于持久化的功能。所以就有了Cookie和Session。

Cookie其实就是一个文本信息，储存在客户端浏览器中。在客户端和服务端进行通信时，如果需要设置Cookie，服务端就会发回一个响应报文，它的首部就会有一个字段叫做setCookie，客户端收到此报文后就会在浏览器上设置对应的Cookie，下次连接请求时，会把Cookie信息也发送过去，服务端收到这个Cookie。Cookie的作用主要有两种吧，一种是和Session搭配使用，用来在服务器上追踪Session，然后Session追踪会话状态。还有一种是可以作一种缓存的功能，比如说像自动登陆这样的功能。可以直接在前端的js上获取Cookie的内容进行拼接到请求体中

Session它是存在于服务端上的，服务端就以一个类似于HashMap的格式去储存多个Session。当客户端发出请求时，就会去查看有没有携带着一个叫SessionId的Cookie，如果没有的话，说明这是第一次进行通信嘛，那么服务端就会生成对应的Session和SessionId来储存用户状态，然后通过在回应报文在客户端上设置对应的Cookie。那么客户端下一次访问的时候就可以直接查找到对应的Session了

区别：

• Cookie存放在客户端浏览器上，而Session存放在服务端上；所以Session数量过多会对服务端带来负担。
• Cookie是不安全的，有一种可能就是别人将浏览器上Cookie转移走，伪装自己的身份来访问网站。
• 如果对安全性要求较高，可以使用Session；如果是对服务端资源比较紧缺的话可以使用Cookie

20.HTTP缓存机制你了解嘛？

HTTP缓存机制有三个主体：客户端浏览器，缓存数据库，服务端。

HTTP缓存分为两类：强缓存和协商缓存

强缓存的机制很简单：客户端发出请求时首先去查看缓存数据库是否有对应的资源，如果没有的话，就直接去查询服务端，如果响应报文首部的cache-control字段是public的话，就会在缓存数据库中记录这个资源，然后响应码是200；如果缓存数据库中有对应资源且未过期的话，就会直接使用缓存数据库中的资源，并且响应码是304.

协商缓存。如果缓存数据库中对应的资源已经过期，或者报文首部明确指定每次从缓存中获取资源都需要去服务端进行验证，并且不允许使用旧数据的话，就要使用协商缓存。协商缓存的机制就是：发出请求后查看缓存数据库中对应的资源是否已过期，如果已经过期，就要发送一个HEAD请求到服务端中，查看对应资源是否已经被修改过，如果被更新过的话，就需要从服务端获取一个新值，如果没有更新过，则直接使用缓存数据库的值。

21.Token是什么？和Cookie比起来的优势？

token是一种无状态持久机制。也就是说服务端在生成token并且发送给客户端之后，服务端本身不需要做一些额外的记录。所以和Cookie比起来，token可以一定程度上降低服务端的开销。因为Cookie很多时候是配合Session一起使用的嘛，Session储存在服务端，会加大服务器压力。

那token的工作流程就是：首先客户端建立链接访问服务端的资源，服务端对客户端的权限校验通过后，就会生成一个对应的token，然后服务端使用一个私钥在token上添加一个数字签名。这样就可以防止第三方恶意制作虚假的token。客户端接收到这个token后，既可以把它存放在本地储存中，也可以存放在cookie中，之后客户端发出的每次请求都要携带这个token，服务端对这个token进行检验，通过之后客户端就可以直接访问对应的资源

对比cookie：

• token是无状态的，也就是说服务端在生成token之后不需要进行额外的处理；而使用cookie的话一般还要先在服务端生成session并储存。所以token可以减少服务端压力
• token可以在多个服务之间进行共享。而使用cookie和session的话，如果服务端使用了负载均衡的架构的话，可能还需要进行一些额外的处理，比如说用一个redis来统一管理这些session

22.HTTP如何传输大文件

有几个方法：

• 数据压缩。客户端在发出请求时，请求报文首部有一个叫做Accept-Encoding字段，上面列举着客户端支持的压缩方式，比如gzip，br。服务端接收到之后会选择其中一种方式对数据进行压缩。但缺点是这种方式只能对文本数据进行压缩，如果是音频或者图像的话，这种数据本身就已经是高度压缩了，再进行压缩效果也不明显。
• 分块传输。将大文件分割成多个块进行传输，如果服务端使用分块传输的话，响应报文首部会有一个“Transfer-Encoding: chunked”属性，这个属性就表明这次数据的传输使用了分块传输。
• 范围传输：就是说可以只将一个大文件其中的一部分进行范围传输。最直观的感受就是我们网站上看电影的时候，可以跳过片头直接看中间的片段，这就是使用了HTTP的范围传输。客户端的发出请求报文时，报文头有一个叫做Range的字段，这个字段后面跟着一个范围，比如说x-y就是表示请求x到y之间的数据。那服务器收到这个请求之后判断这个范围是否合法，如果合法的话就会将数据的其中一个片段进行回传。