Java面试之计算机网络

1.网络七层模型：发快递的例子

1. 应用层
   应用层（application-layer）的任务是通过应用进程间的交互来完成特定网络应用。应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统 DNS，支持万维网应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。我们把应用层交互的数据单元称为报文。

2. 运输层
   运输层（transport layer）的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
   由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

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

4. 数据链路层
   数据链路层（data link layer）通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如：同步信息，地址信息，差错控制等）。
   在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。控制信息还使接收端能够检测到所收到的帧中有无差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。

5. 物理层
   在物理层上所传送的数据单位是比特。物理层（physical layer）的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。

2.tcp/ip四层协议：

3.tcp和udp的区别？

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

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

基于TCP的协议：HTTP FTP SMTP
基于UDP的协议：RIP DNS SNMP

• TCP 一般用于文件传输（FTP HTTP 对数据准确性要求高,速度可以相对慢）,发送****或接收邮件（POP IMAP SMTP对数据准确性要求高,非紧急应用）,远程登录 （TELNET SSH 对数据准确性有一定要求,有连接的概念）等等；
• UDP 一般用于即时通信（QQ 聊天对数据准确性和丢包要求比较低,但速度必须快）,在线视频（RTSP速度一定要快,保证视频连续,但是偶尔花了一个图像帧, 人们还是能接受的）,网络语音电话（VoIP 语音数据包一般比较小,需要高速发送,偶尔断音或串音也没有问题）等等.

4.TCP头结构/报文结构

• TCP 包头的固定长度为 20bytes
• 数据偏移：表示 tcp 包头的总长度
• URG：代表这个包是否含有紧急数据
• ACK：确认号，在 tcp 三次握手之后的 ACK 值在传输成功的情况下是保持为 1 的
• PSH：表示收到的 tcp 包是否要直接上传到上层应用层，0 表示放在缓存区中，1代表直接上传***可以利用发送大量 PSH=0 的tcp 包来破坏传输过程
• RST：如果收到一个 RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应，带RST 标志的 TCP 报文段称为复位报文段
• SYN：在建立连接时使用，第一二次握手时为 1
• FIN：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果 FIN=1，即告诉对方：“我的数据已经发送完毕，你可以释放连接了”，带FIN 标志的
• TCP 报文段称为结束报文段在传输的过程中，ack=seq+segment segment 就是传多少个包，这个值受到窗口的限制

5.三次握手

5.1 过程

5.2 为什么三次

• 为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
• 由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了 SYN=1创建连接的请求(第一次握手)。如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。客户端可能设置了一个超时时间，时间到了就关闭了连接创建的请求。再重新发出创建连接的请求，而服务器端是不知道的，如果没有第三次握手告诉服务器端客户端收的到服务器端传输的数据的话，服务器端是不知道客户端有没有接收到服务器端返回的信息的。
  
  

5.3 两次行不行

• 防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源
• 两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输， TCP 协议的通信双方， 都必须维 护一个序列号，以标识发送出去的数据包中， 哪些 是已经被对方收到的。三次握手的过程即是通信双方 相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手， 至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认

5.4 最后一次ACK包丢失

• Server端：第三次的 ACK 在网络中丢失，那么 Server 端该 TCP 连接的状态为SYN_RECV,并且会根据 TCP 的超时重传机制，会等待3 秒、6 秒、12 秒后重新发送 SYN+ACK 包，以便 Client 重新发送 ACK 包。而 Server 重发SYN+ACK包的次数，可以通过设置 /proc/sys/net/ipv4/tcp_synack_retries 修改，默认值为5.如果重发指定次数之后，仍然未收到 client 的 ACK 应答，那么一段时间后，Server 自动关闭这个连接。
• client端：在 linux c 中，client 一般是通过 connect() 函数来连接服务器的，而 connect()是在 TCP 的三次握手的第二次握手完成后就成功返回值。也就是说 client 在接收到 SYN+ACK 包，它的 TCP 连接状态就为established （已连接），表示该连接已经建立。那么如果第三次握手中的 ACK 包丢失的情况下，Client 向 server 端发送数据，Server 端将以 RST 包响应，方能感知到 Server 的错误。

6.四次挥手以及为什么四次挥手：全双工模式

6.1 过程

6.2 为什么四次

• 因为 tcp是全双工通信，客户端向服务端发送一个释放连接请求，说明客户端的数据已经发送完了，但是服务端的数据可能还没有发送完，所以需要一个time_wait时间，确保客户端与服务端的数据能够完成传输，才向客户端发送一个 fin=1 的报文，进行连接释放。

6.3 第四次挥手服务端收不到确认消息怎么办？

1. 客户端没有关闭，重新发送ACK；
2. 客户端炸了，服务端超时重传一定次数后关闭。默认是5.
3. 客户端关闭，服务端收到RST包后关闭。Client 向 server 端发送数据，Server 端将以 RST 包响应，方能感知到 Server 的错误**。

6.4 CLOSE-WAIT

为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

6.5 TIME-WAIT（2MSL（2倍的最大报文时间））

1. 为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段，而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。

2. 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

6.6 如何查看 TIME-WAIT 状态的链接数量？

netstat -an |grep TIME_WAIT|wc -1 查看连接数等待 time_wait 状态连接数

6.7 为什么会 TIME-WAIT 过多？解决方法是怎样的？

• 可能原因： 高并发短连接的 TCP 服务器上，当服务器处理完请求后立刻按照主动正常关闭连接
• 解决：负载均衡服务器；Web 服务器首先关闭来自负载均衡服务器的连接

7.TCP可靠性

7.1 停止等待协议（ARQ自动重传请求）

在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。连续ARQ协议可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。

连续ARQ缺点：

• 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

7.2选择确认（SACK）

能清楚的知道到底是哪个包的数据缺失

7.3 流量控制：滑动窗口（rwnd）

如果发送端发送的数据过多或者数据发送速率过快，导致接收端来不及处理就会造成数据在接收端的丢弃，为了避免这种现象的的发生。

发送端的发送窗口，由接收端设置其大小

• 当滑动窗口为 0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

7.3.1滑动窗口是什么：数据不可能一次发送完，通过滑动窗口的方式一批批的发送

7.3.2滑动窗口的意义：（1）可靠性(超时重传) （2）提高传输效率

7.3.3滑动窗口大小会变吗？当然可以，不然怎么流量控制

7.4快速重传机制/滑动窗口的丢包情况

三次冗余 Ack，所谓的快重传就是不用等到超时器才进行重传。

7.5 拥塞控制（cwnd拥塞窗口）

1. 为了防止过多的数据注入到网络中，避免网络中的路由器、链路过载。
2. 拥塞窗口设置：发送端的发送窗口
3. 发送窗口=min（接收窗口，发送窗口）
4. 慢开始：即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
   
5. 拥塞避免算法：当达到慢开始门限的时候，每次递增1.当网络拥堵时，将慢开始门限下降到拥堵时的一半，从1开始递增。
   
   快重传与快恢复：
   
   

7.5 流量控制和拥塞控制区别

1. 拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或者链路不致过载。
2. 流量控制所要做的就是抑制发送端的发送速率，使得接收端来得及接收。
3. 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
4. 流量控制往往指点对点的通信量控制，即接收端控制发送端，是端到端的问题。

8.浏览器从接收一个url，到展出界面经历了哪些过程

9.Tcp短连接和长连接的关系

1. 在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。
2. 而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive
   在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

10.ping的原理

• Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文，目的主机收到之后会发送 Echo 回答报文。Ping会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

11.UDP如何实现可靠传输

• 添加 seq/ack 机制，确保数据发送到对端
• 添加发送和接收缓冲区，主要是用户超时重传。
• 添加超时重传机制。

12.为什么udp不会粘包？

• TCP协议是面向流的协议，UDP是面向消息的协议
  UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据
• UDP具有保护消息边界，在每个UDP包中就有了消息头（消息来源地址，端口等信息），这样对于接收端来说就容易进行区分处理了。传输协议把数据当作一条独立的消息在网上传输，接收端只能接收独立的消息。接收端一次只能接收发送端发出的一个数据包,如果一次接受数据的大小小于发送端一次发送的数据大小，就会丢失一部分数据，即使丢失，接受端也不会分两次去接收

13.TCP粘包、拆包？

13.1 什么是粘包，产生原因？

• 发送方发送的若干包数据到接收方接收时粘成一包。

原因：

• 发送端为了将多个发往接收端的包，更有效的发到对方，使用了优化方法（Nagle算法），将多次间隔较小、数据量小的数据包，合并成一个大的数据包发送(把发送端的缓冲区填满一次性发送)。

• 接收端底层会把tcp段整理排序交给缓冲区，这样接收端应用程序从缓冲区取数据就只能得到整体数据而不知道怎么拆分

• 比如发送端发送了一个由2个100字节组成的200字节的数据包到接受端的缓冲区，接受端从缓冲去一次取80字节的数据，那么第一次取的就是一个不完整的数据包，第二次取就会带上第一个数据包的尾部和下一个数据包的头

• 注：一次取多少数据通过**socket.recv(80)**定义

   1）应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包。
   2）应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包。
   3）进行mss（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>mss的时候将发生拆包。
   4）接收方法不及时读取套接字缓冲区数据，这将发生粘包。
  

13.2 解决方法

• 发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
• 包尾加上\r\n 标记。FTP 协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
• 包头加上包体长度。包头是定长的 4 个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。

14.说一下http协议：背景，互联网上需要传输视频、文字、图片等信息。应用层协议。请求结构、响应结构。http1.0、http1.1、http2.0，最后在到https.

14.1 http1.0和1.1的区别？

缓存的不同

1. 长连接。HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
2. 节约带宽。HTTP1.0中存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能。HTTP1.1支持只发送header信息（不带任何body信息），如果服务器认为客户端有权限请求服务器，则返回100，客户端接收到100才开始把请求body发送到服务器；如果返回401，客户端就可以不用发送请求body了节约了带宽。
3. host域。在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname），HTTP1.0没有host域。随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都支持host域，且请求消息中如果没有host域会报告一个错误（400 Bad Request）。
4. 缓存处理。在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entitytag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
5. 错误信息状态码。在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
6. 请求方法，1.0只有get、post、head方法，1.1添加了其他方法。

14.2 http1.1和2.0的区别？

1. 多路复用。HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
2. 头部数据压缩。在HTTP1.1中，HTTP请求和响应都是由状态行、请求/响应头部、消息主体三部分组成。一般而言，消息主体都会经过gzip压缩，或者本身传输的就是压缩过后的二进制文件，但状态行和头部却没有经过任何压缩，直接以纯文本传输。HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
3. 服务器推送。服务端推送是一种在客户端请求之前发送数据的机制。网页使用了许多资源：HTML、样式表、脚本、图片等等。在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。
4. 新的传输格式：2.0 使用二进制格式，1.0 依然使用基于文本格式

14.3 http和https的区别？

1. HTTPs协议需要到 CA申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https)
2. HTTP是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL加密传输协议。
3. HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. HTTP 的连接很简单，是无状态的。HTTPS协议是由 SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比 HTTP协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)

15.https原理

• https的加密既使用了对称加密也使用了非对称加密。首先，服务器生成非对称加密算法所需的公钥和私钥，将公钥明文传给客户机，客户机在本机上生成对称加密所使用的通讯密钥，用公钥加密发送给服务器，由于公钥加密后的密文只能通过私钥解开，因此传输节点无法得知通讯密钥内容。这样后续交流双方只需要使用通讯密钥加密信息就可以实现安全通信了。
• 但是如果传输过程中存在一个中间人，他把服务器的公钥换成自己的公钥传递给客户机，这样客户机发送通讯密钥的时候中间人就能通过自己的密钥解开，得到通讯密钥，再用服务器的公钥加密后传回给服务器。此时，中间人就在客户机和服务器没有察觉的情况下成功窃听到了信息。
• 为了防止这样的情况发生，我们需要验证公钥是否真的来自于服务器。这时候我们想到可以找一个受信的第三方（也就是CA），把公钥，域名，第三方机构等信息放在一起做一次hash（做hash的目的是把这些信息变成定长的比特串，降低非对称加密所需的时间，因为如果内容很长的话加密时间也会很长），再用CA的私钥加密，得到一个对内容的签名，由于中间人无法得到CA的信任，因此即使中间人可以伪造证书，也无法伪造签名。
• 现在，服务器直接发送证书和证书签名，当客户机收到证书和签名时，他首先找到是哪个CA发行了证书，再用CA的公钥解密签名，与客户机自己对证书生成的hash对比，如果一致就说明这个公钥是可行的，可以确定是服务器传过来的公钥了！（证书）

16.http包结构

请求行 请求头 请求体

17. http请求报文组成：

1. 请求行：包含了请求方法、URL、协议版本；
2. 请求头：接下来的多行都是请求首部 Header，每个首部都有一个首部名称，以及对应的值。服务器需要知道的信息
3. 一个空行用来分隔首部和内容主体 Body
4. 请求体：最后是请求的内容主体

GET http://www.example.com/ HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cache-Control: max-age=0
Host: www.example.com
If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
If-None-Match: "3147526947+gzip"
Proxy-Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 xxx

param1=1&param2=2

18.http中请求方法

19.http的post请求中有哪些content-type

1. application/x-www-from-urlencoded，默认的类型,以键值对的形式将数据传递给服务端；
2. application/json;
3. multipart/from-data，常用于文件的上传。用边界将请求体隔开。

20.http响应报文

1. 第一行包含协议版本、状态码以及描述，最常见的是 200 OK 表示请求成功了
2. 接下来多行也是首部内容
3. 一个空行分隔首部和内容主体
4. 最后是响应的内容主体

HTTP/1.1 200 OK
Age: 529651
Cache-Control: max-age=604800
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 648
Content-Type: text/html; charset=UTF-8
Date: Mon, 02 Nov 2020 17:53:39 GMT
Etag: "3147526947+ident+gzip"
Expires: Mon, 09 Nov 2020 17:53:39 GMT
Keep-Alive: timeout=4
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Proxy-Connection: keep-alive
Server: ECS (sjc/16DF)
Vary: Accept-Encoding
X-Cache: HIT

<!doctype html>
<html>
<head>
    <title>Example Domain</title>
	// 省略... 
</body>
</html>

21.http响应头

22.http状态码

• 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。
• 200 OK
• 204 No Content：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
• 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。
• 301 Moved Permanently ：永久性重定向
• 302 Found ：临时性重定向
• 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
• 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在301、302 和 303 状态下的重定向把 POST 方法改成 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 方法。
• 400 Bad Request ：请求报文中存在语法错误。
• 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST
  认证）。如果之前已进行过一次请求，则表示用户认证失败。
• 403 Forbidden ：请求被拒绝。
• 404 Not Found
• 500 Internal Server Error ：服务器正在执行请求时发生错误。
• 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。
  
  

23.301和302的区别

• 302重定向是暂时的重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。
• 301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。

24.为什么302 重定向和网址劫持有关联

从网址A 做一个302 重定向到网址B 时，主机服务器的隐含意思是网址A 随时有可能改主意，重新显示本身的内容或转向其他的地方。大部分的搜索引擎在大部分情况下，当收到302 重定向时，一般只要去抓取目标网址就可以了，也就是说网址B。如果搜索引擎在遇到302 转向时，百分之百的都抓取目标网址B 的话，就不用担心网址URL 劫持了。问题就在于，有的时候搜索引擎，尤其是Google，并不能总是抓取目标网址。
　　比如说，有的时候A 网址很短，但是它做了一个302 重定向到B 网址，而B 网址是一个很长的乱七八糟的URL 网址，甚至还有可能包含一些问号之类的参数。很自然的，A 网址更加用户友好，而B 网址既难看，又不用户友好。这时Google 很有可能会仍然显示网址A。由于搜索引擎排名算法只是程序而不是人，在遇到302 重定向的时候，并不能像人一样的去准确判定哪一个网址更适当，这就造成了网址URL 劫持的可能性。也就是说，一个不道德的人在他自己的网址A 做一个302 重定向到你的网址B，出于某种原因， Google 搜索结果所显示的仍然是网址A，但是所用的网页内容却是你的网址B 上的内容，这种情况就叫做网址URL 劫持。你辛辛苦苦所写的内容就这样被别人偷走了。
　　302 重定向所造成的网址URL 劫持现象，已经存在一段时间了。不过到目前为止，似乎也没有什么更好的解决方法。在正在进行的数据中心转换中，302 重定向问题也是要被解决的目标之一。从一些搜索结果来看，网址劫持现象有所改善，但是并没有完全解决。

24.重定向和转发的区别

重定向：redirect：

• 地址栏发生变化
• 重定向可以访问其他站点（服务器）的资源
• 重定向是两次请求。不能使用 request 对象来共享数据

转发：forward：

• 转发地址栏路径不变
• 转发只能访问当前服务器下的资源
• 转发是一次请求，可以使用 request 对象共享数据

25.http协议的缺点

（1）明文传输 （2）不会验证双方的身份 （3）报文被修改了也无法感知

• 客户端需要使用多个连接才能实现并发和缩短延迟；
• 不会压缩请求和响应首部，从而导致不必要的网络流量；
• 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。

26.ssl的连接过程

对称加密算法：
双方持有相同的密钥，且加密速度快，典型对称加密算法：DES、AES
非对称加密算法：
密钥成对出现（私钥、公钥），私钥只有自己知道，不在网络中传输；而公钥
可以公开。相比对称加密速度较慢，典型的非对称加密算法有：RSA、DSA

27.get 和 Post 区别

1. GET 请求在 URL 中传送的参数是有长度限制的，而 POST 没有。
2. GET 用于获取资源，而 POST 用于传输实体主体。
3. GET 比 POST 更不安全，因为参数直接暴露在 URL 上，所以不能用来传递敏感信 息。
4. GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。
5. GET 请求参数会被完整保留在浏览器历史记录里，而 POST 中的参数不会被保留。
6. GET 请求只能进行 url 编码，而 POST 支持多种编码方式。
7. GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置。
8. GET 产生的 URL 地址可以被 Bookmark，而 POST 不可以。
9. GET 在浏览器回退时是无害的，而 POST 会再次提交请求。
10. 安全的 HTTP 方法不会改变服务器状态，也就是说它只是可读的。

GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。

安全的方法除了 GET 之外还有：HEAD、OPTIONS。
不安全的方法除了 POST 之外还有 PUT、DELETE。

11. 幂等性

幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。

所有的安全方法也都是幂等的。

在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。

12. 可缓存

如果要对响应进行缓存，需要满足以下条件：

（1）请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
（2）响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
（3）响应报文的 Cache-Control 首部字段没有指定不进行缓存。

13. XMLHttpRequest

为了阐述 POST 和 GET 的另一个区别，需要先了解 XMLHttpRequest：

XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。

在使用 XMLHttpRequest 的 POST 方法时，浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做，例如火狐就不会。
而 GET 方法 Header 和 Data 会一起发送。

28.cookie和session的区别

29、HTTPS 的优缺点？

优点：

1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

2. HTTPS 协议是由 SSL + HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性；

3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

1. HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10% 到 20% 的耗电；

2. HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

3. SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用；

4. SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；

5. HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。

30、什么是数字签名？

为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

31、什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。

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

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。

非对称加密指使用一对非对称密钥，即：公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性。但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。