1.计算机⽹络
 
1.1 OSI与TCP/IP各层的结构与功能,都有哪些协议?
 
计算机网络体系结构
 

 
 应⽤层  
 
 应⽤层 (application-layer )的任务是通过应⽤进程间的交互来完成特定⽹络应⽤。 应⽤层协议定  
 
 义的是应⽤进程(进程:主机中正在运⾏的程序)间的通信和交互的规则。对于不同的⽹络应⽤  
 
 需要不同的应⽤层协议。在互联⽹中应⽤层协议很多,如 域名系统 DNS ,⽀持万维⽹应⽤的  
 
 HTTP 协议 ,⽀持电⼦邮件的  SMTP 协议 等等。我们把应⽤层交互的数据单元称为报⽂。 
 
 
 域名系统 
 
 域名系统 (Domain Name System 缩写  DNS , Domain Name 被译为域名 ) 是因特⽹的⼀项核⼼服务,它作为可以将域名和 IP 地址相互映射的⼀个分布式数据库,能够使⼈更⽅便的访问互联⽹,⽽不⽤去记住能够被机器直接读取的IP 数串。例如:⼀个公司的 Web ⽹站可看作是它在⽹上的⻔户,⽽域名就相当于其⻔牌地址,通常域名都使⽤该公司的名称或简称。例如上⾯提到的微软公司的域名,类似的还有:IBM  公司的域名是  www.ibm.com 
 
 
 HTTP 协议 
 
 超⽂本传输协议( HTTP , HyperText Transfer Protocol) 是互联⽹上应⽤最为⼴泛的⼀种⽹络协议。所有的 WWW (万维⽹) ⽂件都必须遵守这个标准。设计  HTTP  最初的⽬的是为了提供⼀种发布和接收 HTML  ⻚⾯的⽅法。 
 
 
 运输层  
 
 运输层 (transport layer) 的主要任务就是负责向两台主机进程之间的通信提供 通⽤的数据传输 服  
 
 务 。应⽤进程利⽤该服务传送应⽤层报⽂。 “ 通⽤的 ” 是指并不针对某⼀个特定的⽹络应⽤,⽽是  
 
 多种应⽤可以使⽤同⼀个运输层服务。由于⼀台主机可同时运⾏多个线程,因此运输层有复⽤和  
 
 分⽤的功能。所谓复⽤就是指多个应⽤层进程可同时使⽤下⾯运输层的服务,分⽤和复⽤相反,  
 
 是运输层把收到的信息分别交付上⾯应⽤层中的相应进程。  
 
 运输层主要使⽤以下两种协议 :  
 
 1.  传输控制协议  TCP ( Transmission Control Protocol ) -- 提供 ⾯向连接 的, 可靠的 数据传输  
 
 服务。  
 
 2.  ⽤户数据协议  UDP ( User Datagram Protocol ) -- 提供 ⽆连接 的,尽最⼤努⼒的数据传输服  
 
 务( 不保证数据传输的可靠性 )。 
 
 
 ⽹络层  
 
         在计算机⽹络中进⾏通信的两个计算机之间可能会经过很多个数据链路,也可能还要经过很多通信⼦⽹。⽹络层的任务就是选择合适的⽹间路由和交换结点, 确保数据及时传送。 在发送数据时,⽹络层把运输层产⽣的报⽂段或⽤户数据报封装成分组和包进⾏传送。在 TCP/IP  体系结构  
 
 中,由于⽹络层使⽤  IP  协议 ,因此分组也叫  IP  数据报  ,简称 数据报 。  
 
         这⾥要注意:不要把运输层的 “ ⽤户数据报  UDP ” 和⽹络层的 “ IP  数据报 ” 弄混 。另外,⽆论是哪⼀层的数据单元,都可笼统地⽤“ 分组 ” 来表示。  
 
         这⾥强调指出,⽹络层中的“ ⽹络 ” ⼆字已经不是我们通常谈到的具体⽹络,⽽是指计算机⽹络体系结构模型中第三层的名称.  
 
         互联⽹是由⼤量的异构⽹络通过路由器 相互连接起来的。互联⽹使⽤的⽹络层协议是⽆连接的⽹际协议 和许多路由选择协议,因此互联⽹的⽹络层也叫做⽹际层 或 IP 层 
 
 
  数据链路层  
          数据链路层(data link layer) 通常简称为链路层。两台主机之间的数据传输,总是在⼀段⼀段的链 路上传送的,这就需要使⽤专⻔的链路层的协议。  在两个相邻节点之间传送数据时, 数据链路层 将⽹络层交下来的  IP  数据报组装成帧 ,在两个相邻节点间的链路上传送帧。每⼀帧包括数据和必要的控制信息(如同步信息,地址信息,差错控制等)。  
          在接收数据时,控制信息使接收端能够知道⼀个帧从哪个⽐特开始和到哪个⽐特结束。这样,数据链路层在收到⼀个帧后,就可从中提出数据部分,上交给⽹络层。  
          控制信息还使接收端能够检测到所收到的帧中有误差错。如果发现差错,数据链路层就简单地丢弃这个出了差错的帧,以避免继续在⽹络中传送下去⽩⽩浪费⽹络资源。如果需要改正数据在链路层传输时出现差错(这就是说,数据链路层不仅要检错,⽽且还要纠错),那么就要采⽤可靠  
  性传输协议来纠正出现的差错。这种⽅法会使链路层的协议复杂些。  
   物理层  
          在物理层上所传送的数据单位是⽐特。  
          物理层(physical layer) 的作⽤是实现相邻计算机节点之间⽐特流的透明传送,尽可能屏蔽掉具 体传输介质和物理设备的差异。  使其上⾯的数据链路层不必考虑⽹络的具体传输介质是什么。  
  “ 透明传送⽐特流 ” 表示经实际电路传送后的⽐特流没有发⽣变化,对传送的⽐特流来说,这个电  
  路好像是看不⻅的。  
  在互联⽹使⽤的各种协中最重要和最著名的就是  TCP/IP  两个协议。现在⼈们经常提到的 TCP/IP  
  并不⼀定单指 TCP 和 IP 这两个具体的协议,⽽往往表示互联⽹所使⽤的整个 TCP/IP 协议族。 
 
  
1.2TCP 三次握⼿和四次挥⼿(⾯试常客)
 
1.TCP 三次握⼿
 
  客户端 – 发送带有  SYN  标志的数据包 ---- ⼀次握⼿ – 服务端  
  服务端 – 发送带有  SYN/ACK  标志的数据包 ---- ⼆次握⼿ – 客户端  
  客户端 – 发送带有带有  ACK  标志的数据包 ---- 三次握⼿ – 服务端 
   
  
 为什么要三次握⼿ 
 
 三次握⼿的⽬的是建⽴可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,⽽三次握  
 
 ⼿最主要的⽬的就是双⽅确认⾃⼰与对⽅的发送与接收是正常的。  
 
 |  | 客户端 | 服务端 | 
| 第一次握手 | 无 | 对方发送,自己接收正常 | 
| 第二次握手 | 自己发送对方接收正常, 对方发送自己接收正常 | 无 | 
| 第三次握手 | 无 | 自己发送,对方接收正常 | 
  
  
 第⼀次握⼿: Client  什么都不能确认; Server  确认了对⽅发送正常,⾃⼰接收正常  
 
 第⼆次握⼿: Client  确认了:⾃⼰发送、接收正常,对⽅发送、接收正常; Server  确认了:对⽅  
 
 发送正常,⾃⼰接收正常  
 
 第三次握⼿: Client  确认了:⾃⼰发送、接收正常,对⽅发送、接收正常; Server  确认了:⾃⼰  
 
 发送、接收正常,对⽅发送、接收正常  
 
 所以三次握⼿就能确认双发收发功能都正常,缺⼀不可。 
 
 
 为什么要传回  SYN 
 
         接收端传回发送端所发送的 SYN  是为了告诉发送端,我接收到的信息确实就是你所发送的信号。 
 
          SYN 是  TCP/IP  建⽴连接时使⽤的握⼿信号。在客户机和服务器之间建⽴正常的  TCP  ⽹络  
  连接时,客户机⾸先发出⼀个  SYN  消息,服务器使⽤  SYN-ACK  应答表示接收到了这个消息,最后客户机再以 ACK 消息响应。这样在客户机和服务器之间才能建⽴起可靠的TCP 连接,数据才可以在客户机和服务器之间传递。 
    传了  SYN, 为啥还要传  ACK  
  双⽅通信⽆误必须是两者互相发送信息都⽆误。传了  SYN ,证明发送⽅到接收⽅的通道没有问  
  题,但是接收⽅到发送⽅的通道还需要  ACK  信号来进⾏验证。 
   
  
2.四次挥手
 
A:我要挂了
 
B:好的,我知道了
 
B:我也挂了
 
A:好的,我知道了
 

 
 1.客户端 - 发送⼀个  FIN ,⽤来关闭客户端到服务器的数据传送  
 
 2.服务器 - 收到这个  FIN ,它发回⼀ 个  ACK ,确认序号为收到的序号加 1  。和  SYN  ⼀样,⼀个  
 
 FIN  将占⽤⼀个序号  
 
 3.服务器 - 关闭与客户端的连接,发送⼀个 FIN 给客户端  
 
 4.客户端 - 发回  ACK  报⽂确认,并将确认序号设置为收到序号加 1 
 
 
 为什么要四次挥⼿ 
 
         任何⼀⽅都可以在数据传送结束后发出连接释放的通知,待对⽅确认后进⼊半关闭状态。当另⼀也没有数据再发送的时候,则发出连接释放通知,对⽅确认后就完全关闭了TCP 连接。  
 
 举个例⼦: A  和  B  打电话,通话即将结束后, A  说 “ 我没啥要说的了 ” , B 回答 “ 我知道了 ” ,但是  B  
 
 可能还会有要说的话, A  不能要求  B  跟着⾃⼰的节奏结束通话,于是  B  可能⼜巴拉巴拉说了⼀  
 
 通,最后  B  说 “ 我说完了 ” , A  回答 “ 知道了 ” ,这样通话才算结束。 
 
1.3TCP,UDP 协议的区别
 

 
          UDP  在传送数据之前不需要先建⽴连接,远地主机在收到  UDP  报⽂后,不需要给出任何确认。虽然 UDP  不提供可靠交付,但在某些情况下  UDP  确是⼀种最有效的⼯作⽅式(⼀般⽤于即时通信),⽐如: QQ  语⾳、  QQ  视频 、直播等等  
 
          TCP  提供⾯向连接的服务。在传送数据之前必须先建⽴连接,数据传送结束后要释放连接。  
 
         TCP 不提供⼴播或多播服务。由于  TCP 要提供可靠的,⾯向连接的传输服务,难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的⾸部增⼤很多,还要占⽤许多处理机资源。TCP  ⼀般⽤于⽂件传输、发送和接收邮件、远程登录等场景。 
 
1.4TCP 协议如何保证可靠传输
 
 1.  应⽤数据被 分割 成  TCP  认为最适合发送的数据块。  
 
 2. TCP  给发送的每⼀个包进⾏ 编号 ,接收⽅对数据包进⾏排序,把有序数据传送给应⽤层。  
 
 3.  校验和 : TCP  将保持它⾸部和数据的检验和。这是⼀个端到端的检验和,⽬的是检测数据  
 
 在传输过程中的任何变化。如果收到段的检验和有差错, TCP  将丢弃这个报⽂段和不确认收  
 
 到此报⽂段。  
 
 4. TCP  的接收端会 丢弃重复 的数据。  
 
 5.  流量控制 :  TCP  连接的每⼀⽅都有固定⼤⼩的缓冲空间, TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收⽅来不及处理发送⽅的数据,能提示发送⽅降低发送的速率,防⽌包丢失。TCP 使⽤的流量控制协议是可变⼤⼩的滑动窗⼝协议。该协议允许发送方在停止并等待确认前发送多个数据分组。 由于发送方不必每发一个分组就停下来等待确认。 因此该协议可以加速数据的传输,提高网络吞吐量 。 
 
 6.  拥塞控制 :  当⽹络拥塞时,减少数据的发送。  
 
 7.  ARQ协议 :  也是为了实现可靠传输的,它的基本原理就是每发完⼀个分组就停⽌发送,等  
 
 待对⽅确认。在收到确认后再发下⼀个分组。  
 
 8.  超时重传 :  当  TCP  发出⼀个段后,它启动⼀个定时器,等待⽬的端确认收到这个报⽂段。  
 
 如果不能及时收到⼀个确认,将重发这个报⽂段。 
 
1.5ARQ协议
 
 ⾃动重传请求 ( Automatic Repeat-reQuest , ARQ )是 OSI 模型中数据链路层和传输层的错误纠  
 
 正协议之⼀。它通过使⽤确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。  
 
 如果发送⽅在发送后⼀段时间之内没有收到确认帧,它通常会重新发送。 ARQ 包括停⽌等待 ARQ  
 
 协议 和 连续ARQ协议。  
 
 
 停⽌等待 ARQ 协议  
 
 停⽌等待协议是为了实现可靠传输的,它的基本原理就是每发完⼀个分组就停⽌发送,等待  
 
 对⽅确认(回复 ACK )。如果过了⼀段时间(超时时间后),还是没有收到  ACK  确认,说  
 
 明没有发送成功,需要重新发送,直到收到确认后再发下⼀个分组;  
 
 在停⽌等待协议中,若接收⽅收到重复分组,就丢弃该分组,但同时还要发送确认;  
 
 优点:  简单  
 
 缺点:  信道利⽤率低,等待时间⻓  
 
 1)  ⽆差错情况 :  
 
 发送⽅发送分组 , 接收⽅在规定时间内收到 , 并且回复确认 . 发送⽅再次发送。  
 
 2)  出现差错情况(超时重传) :  
 
 停⽌等待协议中超时重传是指只要超过⼀段时间仍然没有收到确认,就重传前⾯发送过的分组  
 
 (认为刚才发送过的分组丢失了)。因此每发送完⼀个分组需要设置⼀个超时计时器,其重传时  
 
 间应⽐数据在分组传输的平均往返时间更⻓⼀些。这种⾃动重传⽅式常称为 ⾃动重传请求  ARQ  
 
 。另外在停⽌等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认 
 
 3)  确认丢失和确认迟到  
 
 确认丢失  :确认消息在传输过程丢失。当 A 发送 M1 消息, B 收到后, B 向 A 发送了⼀个 M1确 认消息,但却在传输过程中丢失。(传输消息没丢失,确认消息丢失了)⽽ A 并不知道,在超时计时过后, A 重传 M1 消息, B 再次收到该消息后采取以下两点措施:1.  丢弃这个重复的 M1 消息,不向上层交付。  2.  向 A 发送确认消息。(不会认为已经发送过了,就不再发送。A 能重传,就证明 B 的确认消息丢失)。  
 
 确认迟到  :确认消息在传输过程中迟到。 A 发送 M1 消息, B 收到并发送确认。在超时时间内 没有收到确认消息, A 重传 M1 消息, B 仍然收到并继续发送确认消息( B收到了2份M1 )。此时A 收到了 B 第⼆次发送的确认消息。接着发送其他数据。过了⼀会, A 收到了 B 第⼀次发送的对M1 的确认消息( A 也收到了 2 份确认消息)。处理如下: 1. A 收到重复的确认后,直 接丢弃。 2. B 收到重复的 M1 后,也直接丢弃重复的 M1 。 
 
 
 连续 ARQ 协议 
 
  可提⾼信道利⽤率。发送维持⼀个发送窗⼝,凡位于发送窗⼝内的分组可连续发送出去,⽽不  
  需要等待对⽅确认。接收⽅⼀般采⽤累积确认,对按序到达的最后⼀个分组发送确认,表明到这  
  个分组位置的所有分组都已经正确收到了。 
 
  
 优点: 信道利⽤率⾼,容易实现,即使确认丢失,也不必重传(不用一个消息一个消息的确认,而是对按序到达的最后一个分组发送确认 )。  
 
 缺点:  不能向发送⽅反映出接收⽅已经正确收到的所有分组的信息。 ⽐如:发送⽅发送了  5 条  
 
 消息,中间第三条丢失( 3 号),这时接收⽅只能对前两个(1,2)发送确认。发送⽅⽆法知道后三个分组(3,4,5)的下落,⽽只好把后三个全部重传⼀次。这也叫 Go-Back-N (回退  N ),表示需要退回来重传已经发送过的 N  个消息。  
 
1.6滑动窗⼝和流量控制
 
 TCP  利⽤滑动窗⼝实现流量控制。流量控制是为了控制发送⽅发送速率,保证接收⽅来得及接  
 
 收。  接收⽅发送的确认报⽂中的窗⼝字段可以⽤来控制发送⽅窗⼝⼤⼩,从⽽影响发送⽅的发送  
 
 速率。将窗⼝字段设置为  0 ,则发送⽅不能发送数据。 
 
 
 拥塞控制 
 
          在某段时间,若对⽹络中某⼀资源的需求超过了该资源所能提供的可⽤部分,⽹络的性能就要变坏。这种情况就叫 拥塞 。 
          拥塞控制就是为了防⽌过多的数据注⼊到⽹络中,这样就可以使⽹络中的路由器或链路不致过载。拥塞控制所要做的都有⼀个前提,就是⽹络能够承受现有的⽹络负荷。拥塞控制是⼀个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低⽹络传输性能有关的所有因素。 
          相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。  
          为了进⾏拥塞控制,TCP  发送⽅要维持⼀个  拥塞窗⼝ (cwnd)  的状态变量。拥塞控制窗⼝的⼤⼩取决于⽹络的拥塞程度,并且动态变化。发送⽅让⾃⼰的发送窗⼝取为拥塞窗⼝和接收⽅的接受窗⼝中较⼩的⼀个。  
           TCP的拥塞控制采⽤了四种算法,即  慢开始  、  拥塞避免  、 快重传  和  快恢复 。在⽹络层也可以使路由器采⽤适当的分组丢弃策略(如主动队列管理 AQM ),以减少⽹络拥塞的发⽣。  
  慢开始:  慢开始算法的思路是当主机开始发送数据时,如果⽴即把⼤量数据字节注⼊到⽹络,那么可能会引起⽹络阻塞,因为现在还不知道⽹络的符合情况。经验表明,较好的⽅法是先探测⼀下,即由⼩到⼤逐渐增⼤发送窗⼝,也就是由⼩到⼤逐渐增⼤拥塞窗⼝数值。cwnd初始值为 1 ,每经过⼀个传播轮次, cwnd 加倍。  
  拥塞避免:  拥塞避免算法的思路是让拥塞窗⼝ cwnd 缓慢增⼤,即每经过⼀个往返时间 RTT就把发送放的cwnd 加 1. 
  快重传与快恢复:  
  在  TCP/IP  中,快速重传和恢复( fast retransmit and recovery , FRR )是⼀种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR ,如果数据包丢失了, TCP  将会使⽤定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR ,如果接收机接收到⼀个不按顺序的数据段,它会⽴即给发送机发送⼀个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并⽴即重传这些丢失的数据段。有了 FRR ,就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时,快速重传和恢复(FRR )能最有效地⼯作。当有多个数据信息包在某⼀段很短的时间内丢失时,它则不能很有效地⼯作。 
 
  
1.7在浏览器中输⼊url地址 ->> 显示主⻚的过程(⾯试常客)
 
 打开⼀个⽹⻚,整个过程会使⽤哪些协议 
 

 
 总体来说分为以下⼏个过程 : 
 
 1. DNS(域名系统) 解析  
 
 2. TCP 连接  
 
 3.  发送 HTTP 请求  
 
 4.  服务器处理请求并返回 HTTP 报⽂  
 
 5.  浏览器解析渲染⻚⾯  
 
 6.  连接结束 
 
1.8状态码
 

 
1.9各种协议与HTTP协议之间的关系
 

 
1.10HTTP⻓连接,短连接
 
         在HTTP/1.0 中默认使⽤短连接。也就是说,客户端和服务器每进⾏⼀次 HTTP 操作,就建⽴⼀次连接,任务结束就中断连接。当客户端浏览器访问的某个HTML 或其他类型的 Web ⻚中包含有其  
 
 他的 Web 资源(如 JavaScript ⽂件、图像⽂件、 CSS ⽂件等),每遇到这样⼀个 Web 资源,浏览  
 
 器就会重新建⽴⼀个 HTTP 会话。 
 
         ⽽从HTTP/1.1 起,默认使⽤⻓连接,⽤以保持连接特性。使⽤⻓连接的 HTTP 协议,会在响应头加⼊这⾏代码:  
 

 
         在使⽤⻓连接的情况下,当⼀个⽹⻚打开完成后,客户端和服务器之间⽤于传输HTTP 数据的  
 
 TCP 连接不会关闭,客户端再次访问这个服务器时,会继续使⽤这⼀条已经建⽴的连接。 Keep- 
 
 Alive 不会永久保持连接,它有⼀个保持时间,可以在不同的服务器软件(如 Apache )中设定这  
 
 个时间。实现⻓连接需要客户端和服务端都⽀持⻓连接。  
 
 HTTP 协议的⻓连接和短连接,实质上是 TCP 协议的⻓连接和短连接。 
 
1.11HTTP是不保存状态的协议,如何保存⽤户状态?
 
         HTTP 是⼀种不保存状态,即⽆状态( stateless )协议。也就是说  HTTP  协议⾃身不对请求和响应之间的通信状态进⾏保存。那么我们保存⽤户状态呢? 
 
         Session  机制的存在就是为了解决这个问题,Session  的主要作⽤就是通过服务端记录⽤户的状态。典型的场景是购物⻋,当你要添加商品到购物⻋的时候,系统不知道是哪个⽤户操作的,因为 HTTP  协议是⽆状态的。服务端给特定的⽤户创建特定的 Session  之后就可以标识这个⽤户并且跟踪这个⽤户了(⼀般情况下,服务器会在⼀定时间内保存这个 Session ,过了时间限制,就会销毁这个 Session )。  
 
         在服务端保存 Session  的⽅法很多,最常⽤的就是内存和数据库 ( ⽐如是使⽤内存数据库 redis 保存) 。既然  Session  存放在服务器端,那么我们如何实现  Session  跟踪呢?⼤部分情况下,我们  
 
 都是通过在  Cookie  中附加⼀个 Session ID  来⽅式来跟踪。  
 
 Cookie  被禁⽤怎么办 ?  
 
 最常⽤的就是利⽤  URL 重写把 Session ID 直接附加在URL 路径的后⾯。 
 
1.12Cookie的作⽤是什么?和Session有什么区别?
 
         Cookie 和  Session 都是⽤来跟踪浏览器⽤户身份的会话⽅式,但是两者的应⽤场景不太⼀样。  
 
         Cookie ⼀般⽤来保存⽤户信息  ⽐如①我们在  Cookie  中保存已经登录过得⽤户信息,下次访问⽹站的时候⻚⾯可以⾃动帮你登录的⼀些基本信息给填了;②⼀般的⽹站都会有保持登录也就是  
 
 说下次你再访问⽹站的时候就不需要重新登录了,这是因为⽤户登录的时候我们可以存放了⼀个 Token 在  Cookie  中,下次登录的时候只需要根据  Token  值来查找⽤户即可 ( 为了安全考虑,重新  
 
 登录⼀般要将  Token  重写 ) ;③登录⼀次⽹站后访问⽹站其他⻚⾯不需要重新登录。 
 
         Session 的 主要作⽤就是通过服务端记录⽤户的状态。  典型的场景是购物⻋,当你要添加商品到购物⻋的时候,系统不知道是哪个⽤户操作的,因为 HTTP  协议是⽆状态的。服务端给特定的⽤户创建特定的 Session  之后就可以标识这个⽤户并且跟踪这个⽤户了。  
 
         Cookie 数据保存在客户端 (浏览器端) , Session  数据保存在服务器端。  
 
          相对来说  Session  安全性更⾼。如果要在Cookie 中存储⼀些敏感信息,不要直接写⼊  Cookie  中,最好能将  Cookie  信息加密然后使⽤到的时候再去服务器端解密 
 
1.13HTTP 1.0和HTTP 1.1的主要区别是什么?
 
 HTTP1.0 最早在⽹⻚中使⽤是在 1996 年,那个时候只是使⽤⼀些较为简单的⽹⻚上和⽹络请求 上,⽽HTTP1.1 则在 1999 年才开始⼴泛应⽤于现在的各⼤浏览器⽹络请求中,同时 HTTP1.1 也是  
 
 当前使⽤最为⼴泛的 HTTP 协议。 主要区别主要体现在:  
 
 1.  ⻓连接  :  在 HTTP/1.0 中,默认使⽤的是短连接 ,也就是说每次请求都要重新建⽴⼀次连接。  
 
 HTTP  是基于 TCP/IP 协议的 , 每⼀次建⽴或者断开连接都需要三次握⼿四次挥⼿的开销,如果每次请求都要这样的话,开销会⽐较⼤。因此最好能维持⼀个⻓连接,可以⽤个⻓连接来发多个请求。 HTTP 1.1 起,默认使⽤⻓连接  , 默认开启 Connection :  keep-alive 。  HTTP/1.1 的持续连接有⾮流⽔线⽅式和流⽔线⽅式  。流⽔线⽅式是客户在收到 HTTP 的响应报⽂之前就能接着发送新的请求报⽂。与之相对应的⾮流⽔线⽅式是客户在收到前⼀个响应后才能发送下⼀个请求。  
 
 2.  错误状态响应码  : 在 HTTP1.1 中新增了 24 个错误状态响应码,如 409 ( Conflict )表示请求的  
 
 资源与资源的当前状态发⽣冲突; 410 ( Gone )表示服务器上的某个资源被永久性的删除。  
 
 3.  缓存处理  : 在 HTTP1.0 中主要使⽤ header⾥的If-Modified-Since,Expires 来做为缓存判断的标  
 
 准, HTTP1.1 则引⼊了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match,  
 
 If-None-Match 等更多可供选择的缓存头来控制缓存策略。  
 
 4.  带宽优化及⽹络连接的使⽤  :HTTP1.0 中,存在⼀些浪费带宽的现象,例如客户端只是需要  
 
 某个对象的⼀部分,⽽服务器却将整个对象送过来了,并且不⽀持断点续传功能, HTTP1.1则在请求头引⼊了range 头域,它允许只请求资源的某个部分,即返回码是 206 ( PartialContent),这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。 
 
1.14URI和URL的区别是什么?
 
 URI(Uniform Resource Identifier)  是统⼀资源标志符,可以唯⼀标识⼀个资源。  
 
 URL(Uniform Resource Location)  是统⼀资源定位符,可以提供该资源的路径。它是⼀种具体的 URI ,即  URL  可以⽤来标识⼀个资源,⽽且还指明了如何 locate  这个资源。URI的作⽤像身份证号⼀样, URL 的作⽤更像家庭住址⼀样。 URL 是⼀种具体的 URI ,它不仅唯⼀标识资源,⽽且还提供了定位该资源的信息。 
 
1.15HTTP 和 HTTPS 的区别?
 
 1.  端⼝  : HTTP 的 URL 由 “http://” 起始且默认使⽤端⼝ 80 ,⽽ HTTPS 的 URL 由 “https://” 起始且默  
 
 认使⽤端⼝ 443 。  
 
 2.  安全性和资源消耗:   
 
         HTTP协议运⾏在 TCP 之上,所有传输的内容都是明⽂,客户端和服务器端都⽆法验证对⽅的身份。HTTPS 是运⾏在 SSL/TLS 之上的 HTTP 协议, SSL/TLS  运⾏在TCP之上。所有传输的内容都经过加密,加密采⽤对称加密,但对称加密的密钥⽤服务器⽅的证书进⾏了⾮对称加密。所以说,HTTP  安全性没有 HTTPS⾼,但是 HTTPS ⽐HTTP耗费更多服务器资源。  
 
         对称加密:密钥只有⼀个,加密解密为同⼀个密码,且加解密速度快,典型的对称加密算法有DES、 AES 等;  
 
         ⾮对称加密:密钥成对出现(且根据公钥⽆法推知私钥,根据私钥也⽆法推知公钥),加密解密使⽤不同密钥(公钥加密需要私钥解密,私钥加密需要公钥解密),相对对称加密速度较慢,典型的⾮对称加密算法有RSA、 DSA 等。 
 
2.数据结构
 
2.1线性数据结构 :数组、链表、栈、队列
 
1. 数组
 
「数组(Array)」 是一种很常见的数据结构。它由相同类型的元素(element)组成,并且是使用一块连续的内存来存储。
 
我们直接可以利用元素的索引(index)可以计算出该元素对应的存储地址。
 
数组的特点是:「提供随机访问」 并且容量有限。
 

 
2. 链表
 
「链表(LinkedList)」 虽然是一种线性表,但是并不会按线性的顺序存储数据,使用的不是连续的内存空间来存储数据。
 
链表的插入和删除操作的复杂度为 O(1) ,只需要知道目标位置元素的上一个元素即可。但是,在查找一个节点或者访问特定位置的节点的时候复杂度为 O(n) 。
 
使用链表结构可以克服数组需要预先知道数据大小的缺点,链表结构可以充分利用计算机内存空间,实现灵活的内存动态管理。但链表不会节省空间,相比于数组会占用更多的空间,因为链表中每个节点存放的还有指向其他节点的指针。除此之外,链表不具有数组随机读取的优点。
 
 链表分类
 

 
单链表
 
「单链表」 单向链表只有一个方向,结点只有一个后继指针 next 指向后面的节点。因此,链表这种数据结构通常在物理内存上是不连续的。我们习惯性地把第一个结点叫作头结点,链表通常有一个不保存任何值的 head 节点(头结点),通过头结点我们可以遍历整个链表。尾结点通常指向 null
 
循环链表
 
「循环链表」 其实是一种特殊的单链表,和单链表不同的是循环链表的尾结点不是指向 null,而是指向链表的头结点。
 
双向链表
 
「双向链表」 包含两个指针,一个 prev 指向前一个节点,一个 next 指向后一个节点。
 
双向循环链表
 
「双向循环链表」 最后一个节点的 next 指向 head,而 head 的 prev 指向最后一个节点,构成一个环。
 
应用场景
 
-  如果需要支持随机访问的话,链表没办法做到,用数组。 
-  如果需要存储的数据元素的个数不确定,并且需要经常添加和删除数据的话,使用链表比较合适。 
-  如果需要存储的数据元素的个数确定,并且不需要经常添加和删除数据的话,使用数组比较合适。 
数组 vs 链表
 
 
3. 栈