2023计算机网络面试题总结

OSI模型和DNS

OSI 的七层模型分别是？各自的功能是什么？

• 物理层：传输数据单位为比特流，实现节点与节点之间的比特流传输。

• 数据链路层：传输的是数据帧。定义数据的基本格式，如何传输、如何标识等。

• 网络层：**由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。**在计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，

这里要注意：不要把运输层的“用户数据报 UDP ”和网络层的“ IP 数据报”弄混。另外，无论是哪一层的数据单元，都可笼统地用“分组”来表示。

• 运输层： 传输单位是：数据段，实现端到端传输数据的基本功能；如 TCP、UDP。

• 会话层：控制应用程序之间会话能力；如不同软件数据分发给不同软件。

• 表示层：数据格式标识，基本压缩加密功能。

• 应用层：各种应用软件，包括 Web 应用。

五层模型

• 应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS、HTTP协议、SMTP协议等。
• 传输层：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。
• 网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。
• 数据链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。
• 物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。

一次完整的http请求

总：建立起客户机和服务机连接–建立连接后，客户机发送一个请求给服务器—服

务器收到请求后响应信息—客户端浏览器将返回的内容进行解析并呈现，断开连接

细：

• 域名解析，进行DNS域名解析；

• 进行DNS域名解析；发出TCP三次握手

• 建立TCP连接后，发出http请求

• 服务器收到请求并响应请求

• 四次挥手，断开连接

• 浏览器收到内容进行解析

• 浏览器对页面进行渲呈现给用户

在浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤？

1、查浏览器缓存，看看有没有已经缓存好的，如果没有

2 、检查本机host文件，

3、调用API，Linux下Scoket函数 gethostbyname

4、向DNS服务器发送DNS请求，查询本地DNS服务器，这其中用的是UDP的协议

5、如果在一个子网内采用ARP地址解析协议进行ARP查询如果不在一个子网那就需要对默认网关进行DNS查询，如果还找不到会一直向上找根DNS服务器，直到最终拿到IP地址（全球400多个根DNS服务器，由13个不同的组织管理）

6、这个时候我们就有了服务器的IP地址 以及默认的端口号了，http默认是80 https是 443 端口号，会，首先尝试http然后调用Socket建立TCP连接，

7、经过三次握手成功建立连接后，开始传送数据，如果正是http协议的话，就返回就完事了，

8、如果不是http协议，服务器会返回一个5开头的的重定向消息，告诉我们用的是https，那就是说IP没变，但是端口号从80变成443了，好了，再四次挥手，完事，

9、再来一遍，这次除了上述的端口号从80变成443之外，还会采用SSL的加密技术来保证传输数据的安全性，保证数据传输过程中不被修改或者替换之类的，

10、这次依然是三次握手，沟通好双方使用的认证算法，加密和检验算法，在此过程中也会检验对方的CA安全证书。

11、确认无误后，开始通信，然后服务器就会返回你所要访问的网址的一些数据，在此过程中会将界面进行渲染，牵涉到ajax技术之类的，直到最后我们看到色彩斑斓的网页

什么是DNS？

DNS是域名系统，它是域名和IP地址相互映射的一个分分布式数据库

通过主机名，最终得到主机名对应的IP地址的过程称为域名解析

DNS工作原理（解析过程）

1. 浏览器搜索自己的DNS缓存
2. 若没有，则搜索操作系统中的DNS缓存和hosts文件
3. 若没有，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的DNS缓存，查找成功则返回结果，否则依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求，最终返回IP地址给本地域名服务器
4. 本地域名服务器将得到的IP地址返回给操作系统，同时自己也将IP地址缓存起来
5. 操作系统将 IP 地址返回给浏览器，同时自己也将IP地址缓存起来
6. 浏览器得到域名对应的IP地址

1. 请求一旦发起，若是chrome浏览器，先在浏览器找之前有没有缓存过的域名所对应的ip地址，有的话，直接跳过dns解析了，若是没有，就会找硬盘的hosts文件，看看有没有，有的话，直接找到hosts文件里面的ip
2. 如果本地的hosts文件没有能得到对应的ip地址，浏览器会发出一个dns请求到本地dns服务器，本地dns服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动等。
3. 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询。
4. 本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址。
5. 最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。

DNS负载均衡是什么策略？

​ 当一个网站有足够多的用户的时候，假如每次请求的资源都位于同一台机器上面，那么这台机器随时可能会崩掉。处理办法就是用DNS负载均衡技术，它的原理是在DNS服务器中为同一个主机名配置多个IP地址,在应答DNS查询时,DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果,将客户端的访问引导到不同的机器上去,使得不同的客户端访问不同的服务器,从而达到负载均衡的目的｡例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等。

将主机域名解析成ip地址（域名解析）属于IOS中哪一层的协议，采用什么方式传输

属于应用层协议，使用的是UDP传输

为什么域名解析要使用UDP协议？

• 因为UDP速度快，UDP的DNS只需要一次请求一次应答，位移不好的就是UDP协议内容不能超过512字节，但是客户端像DNS服务器查询域名，一般返回的内容不会超过512字节
• 入股哦采用TCP需要进行三次握手、发送数据、四次挥手。速度较慢

HTTP长链接和端连接的区别

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

为什么服务器会缓存这一项功能?如何实现的？

• 原因：
  1. 缓解服务器压力
  2. 降客户端获取资源的延迟
• 实现：
  1. 代理服务器缓存
  2. 浏览器缓存

三次握手和四次挥手

讲一下三次握手的流程

1. 第一次握手是客户端发起的，客户端会随机生成一序列号x，客户端向服务端发起的报文中包含：标记位SYN=1，和序列位seq=x的请求报文
2. 服务器收到请求后就会生成一个随机序列为y，向服务端发送的报文中包含发送标记位：ACK=1和SYN=1，序列位syn=y，确认位ack=x+1报文。此时对于客户端来说，他知道服务器能收和能发，但是对于服务器来说，并不知道客户端是否能收到。此时就需要第三次握手
3. 客户端收到服务器发送的报文后，会回复一个标记位ACK=1，序列为序列号seq=x+1，确认号ack=y+1的报文，此时三次握手完成，

为什么要三次握手，两次可以吗？

• 三次握手目的是保证可靠的通信信道
• 如果只进行第二次握手，对于客户端来说它知道服务器收发正常，但是对于服务器来说，并不知道客户端是否能正常收到，因此需要进行第三次握手，保证客户端接受正常。
• 也就是说，需要三次握手才能确定双方收发功能正常
• 比如：客户端A发送请求，由于某些原因阻塞了，A重新请求，这次请求收到了B的确认报文进行数据传输，传输完成后。第一次请求在某个时间到达服务器B，服务器B以为A又要建立链接，此时就会发出确认报文，但是一直等不到A的数据传输，就会一直等待，浪费资源。（也就是说如果两次握手，只要服务器发出确认报文后就会一直等待）

第 2 次握手传回了 ACK，为什么还要传回 SYN？

• 回传ACK消息响应是为了告诉浏览器，已经收到了客户端所发送的信号。
• 回传SYN是为了建立从服务端到客户端的通信，第三次握手客户端返回了ACK确认信息，此时从服务端到客户端的通信建立

三次握手可以携带数据吗？

• 三次握手是可以携带数据的，但是第一次第二次握手不可以，只有第三次握手ACK中可以携带数据
• 这样的目的是为了防止服务器受到攻击，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。
• 而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

SYN攻击是什么？

• 服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

什么是半连接队列？

• 服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

• 当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

讲一下四次握手流程

1. 第一次挥手：第一次挥手是客客户端发起的，是客户端发送FIN=1表示的报文
2. 第二次挥手：服务端收到FIN=1之后，会发送ACK=1的报文客户端，表明已经收到客户端的报文了。此时，客户端不能再发送数据给服务端，此时的TCP处于半关闭状态，客户端到服务端的连接释放
3. 第三次挥手：如果服务器想断开连接，服务端FIN=1，ACK=1的连接释放报文
4. 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，此时，客户端并不立马关闭连接，他会等待服务器收到ACK=1后才会关闭，而服务端收到ACK=1的确认报文后，悔立马关闭连接。有一个 2 MSL 的延迟等待。

1. A的应用进程先向其TCP发出连接释放报文段（FIN=1，seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
2. B收到连接释放报文段后即发出确认报文段（ACK=1，ack=u+1，seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
3. A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
4. B发送完数据，就会发出连接释放报文段（FIN=1，ACK=1，seq=w，ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
5. A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL（最大报文段生存时间）后，A才进入CLOSED状态。B收到A发出的确认报文段后关闭连接，若没收到A发出的确认报文段，B就会重传连接释放报文段。

挥手为什么需要四次

• 因为当客户端数据已经发送完，它就发起断开连接请求，但是此时服务端可能数据还在传输，也就是说数据还没有传输完成，此时就先断开客户端到服务端的连接（第一次、第二次挥手）。等到服务端数据传输完成后断开连接，就断开从服务端到客户端的连接（第三次、第四次挥手）

四次挥手释放连接时，等待2MSL的意义?

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

1. 保证客户端发送的最后一个ACK报文段能够到达服务端。。这个ACK报文段有可能丢失，B收不到这个确认报文，就会超时重传连接释放报文段，然后A可以在2MSL时间内收到这个重传的连接释放报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到CLOSED状态，若A在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的连接释放报文段，所以不会再发送一次确认报文段，B就无法正常进入到CLOSED状态。
2. 防止“已失效的连接请求报文段”出现在本连接中。 A在发送完最后一个ACK报文段后，再经过2MSL，就可以使这个连接所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现旧的连接请求报文段。

为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

对应这样一种情况，最后客户端发送的ACK = 1给服务端的过程中丢失了，服务端没收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL。

客户端给服务端发送的ACK = 1丢失，服务端等待 1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方都关闭的连接，TCP 四次分手完毕

TCP和UDP

TCP有哪些特点

• TCP是面向连接的运输层协议。
• 每一条TCP连接只能有两个端点。
• TCP提供可靠交付的服务。
• TCP提供全双工通信。好处——降低延迟(通信方式：单工通信、半双工通信、全双工通信)
• 面向字节流。

TCP和UDP的区别？

1. TCP面向连接；UDP是无连接的，即发送数据之前不需要建立连接。
2. TCP提供可靠的服务；UDP不保证可靠交付。
3. TCP面向字节流，把数据看成一连串无结构的字节流；UDP是面向报文的。
4. TCP有拥塞控制；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如实时视频会议等）。
5. 每一条TCP连接只能是的；UDP支持一对一、一对多、多对一和多对多的通信方式。
6. TCP首部开销20字节；UDP的首部开销小，只有8个字节。

什么是TCP粘包/拆包？发生的原因？

• 一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题。

• 原因：

  1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.

  2、进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)

  3、以太网的payload大于MTU进行IP分片。（ MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。）

• 解决：

  1、消息定长。

  2、在包尾部增加回车或者空格符等特殊字符进行分割

  3、将消息分为消息头和消息尾。

  4、使用其它复杂的协议，如RTMP协议等。

GET和POST的区别

• GET相对于POST安全，GET将参数写在URL，POST是将数据存在请求体内。

• GET的请求数据量最大是2k，POST没有限制

• GET只需要一个包，POST需要传两个包，GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200(返回数据); POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)

• GET请求会被浏览器主动缓存，而POST不会，除非手动设置。

• 本质区别：GET是幂等的，而POST不是幂等的

  这里的幂等性：幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。

  正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。

一个TCP连接可以对应几个HTTP请求？

如果维持连接，一个TCP可以发送多个TTTP请求

一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？

HTTP1.2之前不可以，在1.2之后是可以的

HTTP/1.1 存在一个问题，单个 TCP 连接在同一时刻只能处理一个请求，意思是说：两个请求的生命周期不能重叠，任意两个 HTTP 请求从开始到结束的时间在同一个 TCP 连接里不能重叠。

那HTTP1.1人如何提升页面加载效率的？

• 维持和服务器建立的TCP连接，在同一连接上处理多个请求
• 和服务器建立多个TCP连接

浏览器对同一 Host 建立 TCP 连接到的数量有没有限制？

有，chrome允许同一个Host建立六个TCP连接，不同浏览器会有点区别。

滑动窗口机制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 TCP会话的双方都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制。发送窗口则取决于对端通告的接收窗口。接收方发送的确认报文中的window字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将接收方的确认报文window字段设置为 0，则发送方不能发送数据。

TCP头包含window字段，16bit位，它代表的是窗口的字节容量，最大为65535。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。接收窗口的大小是约等于发送窗口的大小。

详细讲一下拥塞控制？

防止过多的数据注入到网络中。 几种拥塞控制方法：慢开始( slow-start )、拥塞避免( congestion avoidance )、快重传( fast retransmit )和快恢复( fast recovery )。

慢开始

把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。每经过一个传输轮次，拥塞窗口 cwnd 就加倍。 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。

当 cwnd < ssthresh 时，使用慢开始算法。

当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。

当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。

拥塞避免

让拥塞窗口cwnd缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长。

无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。

快重传

有时个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而降低了传输效率。

快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认，使发送方及早知道有报文段没有到达对方。

发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

快恢复

当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半，接着把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。 采用这样的拥塞控制方法使得TCP的性能有明显的改进。

ARP协议

ARP解决了同一个局域网上的主机和路由器IP和MAC地址的解析。

• 每台主机都会在自己的ARP缓冲区中建立一个ARP列表，以表示IP地址和MAC地址的对应关系。
• 当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP列表中是否存在该 IP地址对应的MAC地址，如果有，就直接将数据包发送到这个MAC地址；如果没有，就向本地网段发起一个ARP请求的广播包，查询此目的主机对应的MAC地址。此ARP请求数据包里包括源主机的IP地址、硬件地址、以及目的主机的IP地址。
• 网络中所有的主机收到这个ARP请求后，会检查数据包中的目的IP是否和自己的IP地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的MAC地址和IP地址添加到自己的ARP列表中，如果ARP表中已经存在该IP的信息，则将其覆盖，然后给源主机发送一个 ARP响应数据包，告诉对方自己是它需要查找的MAC地址。
• 源主机收到这个ARP响应数据包后，将得到的目的主机的IP地址和MAC地址添加到自己的ARP列表中，并利用此信息开始数据的传输。
• 如果源主机一直没有收到ARP响应数据包，表示ARP查询失败。

HTTP和HTTPS

HTTP请求方法有多少种

两个JAVA程序，给你一个4核8G的服务器，需要怎么进分配

HTTP协议的特点？

1. HTTP允许传输任意类型的数据。传输的类型由Content-Type加以标记。
2. 无状态。对于客户端每次发送的请求，服务器都认为是一个新的请求，上一次会话和下一次会话之间没有联系。
3. 支持客户端/服务器模式。

HTTP报文格式

HTTP请求由请求行、请求头部、空行和请求体四个部分组成。

• 请求行：包括请求方法，访问的资源URL，使用的HTTP版本。GET和POST是最常见的HTTP方法，除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE。
• 请求头：格式为“属性名:属性值”，服务端根据请求头获取客户端的信息，主要有cookie、host、connection、accept-language、accept-encoding、user-agent。
• 请求体：用户的请求数据如用户名，密码等。

请求报文示例：

POST /xxx HTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=dabin 请求体

• HTTP响应也由四个部分组成，分别是：状态行、响应头、空行和响应体。

• 状态行：协议版本，状态码及状态描述。
• 响应头：响应头字段主要有connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires。
• 响应体：服务器返回给客户端的内容。

响应报文示例：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <body>响应体</body>
</html>

HTTP有哪些状态码

POST和GET的区别？

• GET请求参数通过URL传递，POST的参数放在请求体中。
• GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把请求头和请求体一并发送出去；而对于POST，浏览器先发送请求头，服务器响应100 continue，浏览器再发送请求体。
• GET请求会被浏览器主动缓存，而POST不会，除非手动设置。
• GET请求只能进行url编码，而POST支持多种编码方式。
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

HTTP长连接和短连接？

HTTP1.0默认使用的是短连接。浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

HTTP/1.1起，默认使用长连接。要使用长连接，客户端和服务器的HTTP首部的Connection都要设置为keep才能支持长连接。

HTTP长连接，指的是复用TCP连接。多个HTTP请求可以复用同一个TCP连接，这就节省了TCP连接建立和断开的消耗。

HTTP1.1和 HTTP2.0的区别？

HTTP2.0相比HTTP1.1支持的特性：

• 新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0采用二进制格式传输数据，解析更高效。
• 多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行的传输而不被阻塞，避免 HTTP1.1 出现的”队头堵塞”问题。
• 头部压缩，HTTP1.1的header带有大量信息，而且每次都要重复发送；HTTP2.0 把header从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求a发送了所有的头信息字段，请求b则只需要发送差异数据，这样可以减少冗余数据，降低开销。
• 服务端推送：HTTP2.0允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

HTTPS与HTTP的区别？

1. HTTP是超文本传输协议，信息是明文传输；HTTPS则是具有安全性的ssl加密传输协议。
2. HTTP和HTTPS用的端口不一样，HTTP端口是80，HTTPS是443。
3. HTTPS协议需要到CA机构申请证书，一般需要一定的费用。
4. HTTP运行在TCP协议之上；HTTPS运行在SSL协议之上，SSL运行在TCP协议之上。

什么是数字证书

服务端可以向证书颁发机构CA申请证书，以避免中间人攻击（防止证书被篡改保证安全性和完整性）。

• 数字签名制作：
  • 将明文进行hash（保证生成一个固定位数的报文）生成信息摘要——
  • 将明文和信息摘要采用CA颁发的私钥进行数字签名
• 验证过程：
  • 浏览器收到数字证书后，使用CA颁发的私钥进行解密，得到明文和信息摘要
  • 将明文进行hash计算得到的数据与服务器传过来的信息摘要进行对比
  • 相等则说明证书可行

什么是Cookie和Session

如果没有cookie就没有session，因为sessionid需要cookie携带

我们知道HTTP协议是无状态的协议，如果用户每次请求都需要验证账号和密码，会浪费服务器资源，此时需要用某种机制来识具体的用户身份，用来跟踪用户的整个会话。常用的会话跟踪技术是cookie与session。

• Coookie：Cookie存储于客户端，当用户第一次输入账号密码登录请求后，服务端后生成一个Cookie给客户端（存储在响应头中），客户端会缓存在浏览器中，客户端再向服务器发送请求的时候，都会把相应的cookie存放在HTTP请求头再次发回至服务器。服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。

  

• Session：session存在于服务器中，首先浏览器请求服务器访问web站点时，服务器首先会检查这个客户端请求是否已经包含了一个session标识、称为SESSIONID，如果已经包含了一个sessionid则说明以前已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用，如果客户端请求不包含session id，则服务器为此客户端创建一个session，并且生成一个与此session相关联的独一无二的sessionid存放到cookie中，这个sessionid将在本次响应中返回到客户端保存，这样在交互的过程中，浏览器端每次请求时，都会带着这个sessionid，服务器根据这个sessionid就可以找得到对应的session。以此来达到共享数据的目的。 这里需要注意的是，session不会随着浏览器的关闭而死亡，而是等待超时时间。

• 

Cookie和Session的区别？

• 作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
• 有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
• 隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
• 存储大小不同， 单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限，但出于对服务器的性能考虑，Session 内不要存放过多的数据，并且需要设置 Session 删除机制。

什么是对称加密和非对称加密？

对称加密：通信双方使用相同的密钥进行加密。特点是加密速度快，但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有AES和DES算法

非对称加密：它需要生成两个密钥，公钥和私钥。公钥是公开的，任何人都可以获得，而私钥是私人保管的。公钥负责加密，私钥负责解密；或者私钥负责加密，公钥负责解密。这种加密算法安全性更高，但是计算量相比对称加密大很多，加密和解密都很慢。常见的非对称算法有RSA和DSA。

如果采用算法和非对称算法结合，有什么好的想法吗？

采用非对称算法（比如公钥加密，私钥解密）

服务器A拿着非对称秘钥的公钥给客户端B，客户端拿着这个公钥对对称秘钥进行加密然后发给服务端，服务端收到后，拿着私钥进行解密得到对称秘钥，接着就拿着这个对撑秘钥对明文进行加密。

缺点：发送公钥时被截获，拿着虚假的对撑秘钥服务端，服务端收到后解密完就会拿着虚假的对撑秘钥进行加密。我们收到后，拿着这个自己的虚假秘钥进行解析。