网络概述
-
TCP协议、IP协议、HTTP协议分别在哪一层？
运输层，网络层，应用层。
王道网络P15 ISO/OSI参考模型和TCP/IP模型
OSI参考模型：物理层、数据链路层、网络层、运输层、会话层（会话管理）、表示层（数据格式转换）、应用层
TCP/IP模型：网络接口层、网际层、传输层、应用层
学习计算机网络：物理层、数据链路层、网络层、传输层、应用层
https://snailclimb.gitee.io/javaguide/#/docs/network/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C
物理层
在物理层上所传送的数据单位是比特。 物理层(physical layer)的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。 使其上面的数据链路层不必考虑网络的具体传输介质是什么。“透明传送比特流”表示经实际电路传送后的比特流没有发生变化，对传送的比特流来说，这个电路好像是看不见的。
数据链路层
数据链路层(data link layer)通常简称为链路层。两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提出数据部分，上交给网络层。 控制信息还使接收端能够检测到所收到的帧中有误差错。如果发现差错，数据链路层就简单地丢弃这个出了差错的帧，以避免继续在网络中传送下去白白浪费网络资源。如果需要改正数据在链路层传输时出现差错（这就是说，数据链路层不仅要检错，而且还要纠错），那么就要采用可靠性传输协议来纠正出现的差错。这种方法会使链路层的协议复杂些。
网络层
在 计算机网络中进行通信的两个计算机之间可能会经过很多个数据链路，也可能还要经过很多通信子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。 在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报 ，简称 数据报。
这里要注意：不要把运输层的“用户数据报 UDP ”和网络层的“ IP 数据报”弄混。另外，无论是哪一层的数据单元，都可笼统地用“分组”来表示。
这里强调指出，网络层中的“网络”二字已经不是我们通常谈到的具体网络，而是指计算机网络体系结构模型中第三层的名称.
互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Protocol）和许多路由选择协议，因此互联网的网络层也叫做网际层或IP层。
运输层
运输层(transport layer)的主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务。 应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个线程，因此运输层有复用和分用的功能。所谓复用就是指多个应用层进程可同时使用下面运输层的服务，分用和复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。
运输层主要使用以下两种协议:
传输控制协议 TCP（Transmission Control Protocol）–提供面向连接的，可靠的数据传输服务。
用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。
应用层
应用层(application-layer）的任务是通过应用进程间的交互来完成特定网络应用。 应用层协议定义的是应用进程（进程：主机中正在运行的程序）间的通信和交互的规则。对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如域名系统DNS，支持万维网应用的 HTTP协议，支持电子邮件的 SMTP协议 等等。我们把应用层交互的数据单元称为报文。
网络层
-
arp协议和arp攻击
地址解析协议。
ARP协议
ARP协议是一个年代相当“久远”的网络协议。ARP协议制定于1982年11月，英文全称：Address Resolution Protocol，即“地址解析协议”。
我们知道，虽然终端设备想要上网必须具有公有IP地址，但是在Internet的TCP/IP协议中，IP地址的作用是标识一台主机或路由器与一条链路的接口，也就是说IP地址指明了数据由一个网络传输到另一个网络的路径，但是我们知道，为了节约IP地址，通常情况下，在一个内部网络中，主机常常使用RFC规定的三种私有IP地址作为局域网中主机的IP地址，而且主机的IP地址是由该网络的路由器动态分配的，如果数据的传输仅仅依赖于IP地址，那么当数据到达一个内部网络中时就可能因为目标主机的IP地址发生改变而将数据传输到了错误的目标主机。但是不同设备的物理地址（MAC）是全网唯一的，而且一般也不会被改变（MAC地址是写入网卡的，固定的），因此使用MAC地址作为信息的标识，定位目标网络设备就可以保证信息能够正确抵达目标主机。而通过目标设备的IP地址查找目标设备的MAC地址就是ARP协议的基本功能。
ARP协议的工作过程
由于内部网络中主机的IP地址往往是动态分配的，因此，在主机中是有ARP缓存的，记录着本网络中IP地址与MAC地址的对应关系。那么，这个ARP缓存是怎么生成的呢？首先，当网络中的主机A需要向主机B发送信息时，会将包含目标IP地址的ARP请求广播到该网络中的所有主机上，网络中的其他主机在收到主机A的ARP请求后可以自主的发送ARP应答报文，应答中包含自己的IP和自己的MAC地址，主机B也会发送这样的应答报文给主机A。这样主机A就知道了主机B的MAC地址与IP地址了。
ARP协议的工作是建立在网络中各个主机之间相互信任的基础上的，一台主机在收到其他主机的ARP应答报文时并不会采取措施校验该报文的真实性，而是直接就记录到了自己的ARP缓存中以备下次使用。
ARP攻击
ARP攻击的第一步就是ARP欺骗。由上述“ARP协议的工作过程”我们知道，ARP协议基本没有对网络的安全性做任何思考，当时人们考虑的重点是如何保证网络通信能够正确和快速的完成——ARP协议工作的前提是默认了其所在的网络是一个善良的网络，每台主机在向网络中发送应答信号时都是使用的真实身份。不过后来，人们发现ARP应答中的IP地址和MAC地址中的信息是可以伪造的，并不一定是自己的真实IP地址和MAC地址，由此，ARP欺骗就产生了。
ARP欺骗
ARP的应答报文是可以伪造的。假设一个网络中有3台主机，分别为A、B和C。当主机A向网络中发送了ARP请求时，用于攻击的主机C可以假装是B，然后向主机A发送一个伪造的ARP应答报文，由于A并不会采取措施验证该报文真伪，而是直接存入自己的ARP缓存并在需要时使用（ARP缓存分两种，一种是静态ARP缓存，该类缓存只要主机不关机就一直存在。另一类是动态ARP缓存，该类缓存是有时效限制的，一般ARP动态缓存的最长生命周期是10分钟，如果一个动态缓存项目在2分钟内没有被使用，则删除，如果在两分钟内被使用了，则增加两分钟的生命周期，直到达到10分钟的最长生命周期后进行更新），由此，C就成功的欺骗了A。那么来自主机B的正确的应答报文去哪了？如果A收到了来自B的正确的应答报文，更新了自己的ARP缓存，那么C的ARP欺骗不就失败了吗？确实会发生这种情况，但是如果C不断的向网络中的各台主机大量发送伪造的ARP应答报文，直到同时欺骗了A和B，C就成功的对主机A和B进行了ARP欺骗。接下来C就可以监听A和B之间的流量，伪造A和B的通信内容或者阻止A和B的通信。
王道网络P149 地址解析协议ARP
无论网络层使用什么协议，在实际网络的链路上传送数据帧时，最终必须使用硬件地址。所以需要一种方法来完成IP地址到MAC地址的映射，这就是地址解析协议ARP。每个主机都设有一个ARP高速缓存，存放本局域网上各主机和路由器的IP地址到MAC地址的映射表，称ARP表，使用ARP协议来动态维护此ARP表。
ARP工作在网络层，其工作原理：当主机A欲向本局域网上的某个主机B发送IP数据报时，就先在其ARP高速缓存中查看有无主机B的IP地址。如有，就可查出其对应的硬件地址，再将此硬件地址写入MAC帧，然后通过局域网将该MAC帧发往此硬件地址。如果没有，就通过使用目的MAC地址为FF-FF-FF-FF-FF-FF的帧来封装并广播ARP请求分组，可以使同一个局域网里的所有主机收到ARP请求。当主机B收到该ARP请求后，就会向主机A发出响应ARP分组，分组中包含主机B的IP与MAC地址的映射关系，主机A再收到后将此映射写入ARP缓存中，然后按查询到的硬件地址发送MAC帧。
-
什么是icmp协议，它的作用是什么？
它是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。
王道网络P151 网络控制报文协议ICMP
为了提高IP数据报交付成功的机会，在网络层使用了网际控制报文协议(ICMP)来允许主机或路由器报告差错和异常情况。ICMP协议是IP层协议。ICMP报文的种类有两种，即ICMP差错报告报文（包括源点抑制）和ICMP询问报文。
-
DHCP协议
王道网络P150 动态主机配置协议DHCP
动态主机配置协议(DHCP)常用于给主机动态地分配IP地址，它提供了即插即用联网的机制，这种机制允许一台计算机加入新的网络和获取IP地址而不用手工参与。DHCP是应用层协议，它是基于UDP的。
-
路由器和交换机的区别
1、工作层次不同：交换机比路由器更简单，路由器比交换器能获取更多信息
交换机工作在数据链路层，而路由器工作在网络层
2、数据转发所依据的对象不同
交换机的数据转发依据是利用物理地址或者说MAC地址来确定转发数据的目的地址
而路由器是依据ip地址进行工作的
3、传统的交换机只能分割冲突域，不能分割广播域；而路由器可以分割广播域
传输层
-
为什么tcp为什么要建立连接？
保证可靠传输。
-
解释一下TCP为什么可靠一些
三次握手，超时重传，滑动窗口，拥塞控制。
王道网络P218
TCP连接管理：三次握手、四次挥手
TCP可靠传输：累计确认、超时和冗余ACK重传导致重传
TCP流量控制：接收端控制发送端速率（发送窗口的实际大小是接受窗口和拥塞窗口的最小值）
TCP拥塞控制：慢开始（指数规律增长）、拥塞避免（加法增大）、快恢复（j，乘法减小）
https://snailclimb.gitee.io/javaguide/#/docs/network/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C
TCP 协议如何保证可靠传输
- 应用数据被分割成 TCP 认为最适合发送的数据块。
- TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
- 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
- TCP 的接收端会丢弃重复的数据。
- 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
- 拥塞控制： 当网络拥塞时，减少数据的发送。
- ARQ协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
- 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
-
哪种应用场景会使用TCP协议，使用它的意义
当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议
-
TCP,UDP 协议的区别
https://snailclimb.gitee.io/javaguide/#/docs/network/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C
UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
-
TCP的连接和释放过程
三次握手的过程
1）主机A向主机B发送TCP连接请求数据包，其中包含主机A的初始序列号seq(A)=x。（其中报文中同步标志位SYN=1，ACK=0，表示这是一个TCP连接请求数据报文；序号seq=x，表明传输数据时的第一个数据字节的序号是x）；
2）主机B收到请求后，会发回连接确认数据包。（其中确认报文段中，标识位SYN=1，ACK=1，表示这是一个TCP连接响应数据报文，并含主机B的初始序列号seq(B)=y，以及主机B对主机A初始序列号的确认号ack(B)=seq(A)+1=x+1）
3）第三次，主机A收到主机B的确认报文后，还需作出确认，即发送一个序列号seq(A)=x+1；确认号为ack(A)=y+1的报文；
四次挥手过程
假设主机A为客户端，主机B为服务器，其释放TCP连接的过程如下： 1） 关闭客户端到服务器的连接：首先客户端A发送一个FIN，用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位FIN=1，序列号seq=u。 2） 服务器收到这个FIN，它发回一个ACK，确认号ack为收到的序号加1。 3） 关闭服务器到客户端的连接：也是发送一个FIN给客户端。
4） 客户段收到FIN后，并发回一个ACK报文确认，并将确认序号seq设置为收到序号加1。 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
王道网络P213 TCP协议
TCP连接的建立
连接的建立经历以下3个步骤，通常称为“三次握手”。
第一步：客户机的TCP首先向服务器的TCP发送一个连接请求报文段。这个特殊的报文段重不含应用层数据，起首部中的SYN标志位被置为1。另外，客户机会随机选择一个起始序号seq=x（连接请求报文不携带数据，但要消耗掉一个序号）
第二步：服务器的TCP收到连接请求报文段后，如同意连接，就像客户机发回确认，并为该TCP连接分配TCP缓存和变量。在确认报文段中，SYN和ACK位都被置为1，确认号字段的值为x+1，并且服务器随机产生其实序号seq=y（确认报文不携带数据，但也要消耗掉一个序号）。确认报文段同样不包含应用层数据。
第三步：当客户机收到确认报文段后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的ACK标志位被置为1，序号字段为x+1，确认号字段ack=y+1。该报文段可以携带数据，如果不携带数据则不消耗序号。
TCP连接的释放
TCP连接释放的过程通常称为“四次挥手”。
第一步：客户机打算关闭连接，就向其TCP发送一个连接释放报文段，并停止再发送数据，主动关闭TCP连接，该报文段的FIN标志位被置为1，seq=u，它等于前面已传送过的数据的最后一个字节的序号加1（FIN报文段即使不携带数据，也要消耗一个序号）。TCP是全双工的，即可以想象成是一条TCP连接上有两条数据通路。当发送FIN报文时，发送FIN的一端就不能再发送数据，也就是关闭了其中一条数据通路，但对方好可以发送数据。
第二步：服务器收到连接释放报文段后即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于它前面已传送过的数据的最后一个字节的序号加1。此时，从客户机到服务器这个方向的连接就释放了，TCP连接处于半关闭状态。但服务器若发送数据，客户机仍要接收，即从服务器到客户机这个方向的连接并未关闭。
第三步：若服务器已经没有要向客户机发送的数据，就通知TCP释放连接，此时它发出FIN=1的连接释放报文段。
第四步：客户机收到连接释放报文段后，必须发出确认。在确认报文段中，ACK字段被置为1，确认号ack=w+1，序号seq=u+1。此时TCP连接还没有释放掉，必须经过时间等待计时器设置的时间2MSS后，A才进入到连接关闭状态。
https://snailclimb.gitee.io/javaguide/#/docs/network/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C
为什么要三次握手
三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常
第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常
第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常
所以三次握手就能确认双发收发功能都正常，缺一不可。
为什么要传回 SYN
接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。
SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ]）消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。
传了 SYN,为啥还要传 ACK
双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。
为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。
计算机网络 P225 三次握手
为什么A还要发送一次确认呢？这主要是为了防止已经失效的连接请求报文段突然有传送到了B，因而产生错误。
所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况，A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。
现假定一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。
由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的数据连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。
计算机网络 P226 四次挥手
CLOSE-WAIT：发送第二次挥手到发送第三次挥手之间服务端的状态。
这是TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接受。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。
TIME-WAIT：发送第四次挥手到关闭之间客户端的状态。
时间MSL叫做最长报文段寿命，建议设为2分钟。
为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
第一，为了保证A发送的最后一个ACK报文段能够到达B。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN-ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。
第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
为什么要三次握手
为什么要四次挥手
-
TIME_WAIT和CLOSE_WAIT
为什么需要四次握手
因为客户端发送FIN连接请求释放连接后，服务器接受请求后进入CLOSE_WAIT状态，这个状态就是为了让服务段发送还没有发送完的数据，发送完成后再发送FIN信号。
TIME_WAIT
客户端收到服务的释放连接的请求后，不是立马进入CLOSE状态，而是还要再等待2MSL。理由是：
确保最后一个确认报文能够到达。如果没能到达，服务端就会会重发FIN请求释放连接。等待一段时间没有收到重发就说明服务的已经CLOSE了。如果有重发，则客户端再发送一次LAST ack信号
等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文
-
滑动窗口的作用
https://www.zhihu.com/question/32255109
滑动窗口实现面向流的可靠性
1）最基本的传输可靠性来源于“确认重传”机制。
2）TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
3）发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，m 左边界。
4）接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
滑动窗口的流控特性
TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。
应用程序在需要（如内存不足）时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。
应用层
-
SSL四次握手的过程
-
负载均衡 反向代理模式的优点、缺点
-
DNS的寻址过程
王道网络P242 DNS系统
域名系统DNS是因特网使用的命名系统，用来把便于人们记忆的含有特定含义的主机名转换为便于机器处理的IP地址。DNS系统采用客户/服务器模型，其协议运行在UDP之上，使用53号端口。
递归查询（比较少用）、迭代查询
本地域名服务器分别请求根域名服务器、顶级域名服务器、权限域名服务器
https://snailclimb.gitee.io/javaguide/#/docs/network/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C
-
在浏览器中输入url地址 -» 显示主页的过程(面试常客)
总体来说分为以下几个过程:
- DNS解析
- TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析渲染页面
- 连接结束
-
各种协议与HTTP协议之间的关系
-
状态码
-
HTTP是不保存状态的协议,如何保存用户状态?
HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。
在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。
Cookie 被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。
-
Cookie的作用是什么?和Session有什么区别？
Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。
Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。
Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。
-
session原理
为了记录session，在客户端和服务器端都要保存数据，客户端记录一个标记，服务器端不但存储了这个标记同时还存储了这个标记映射的数据。好吧，还是说点白话吧，在客户端记录的其实是一个sessionid，在服务器端记录的是一个key-value形式的数据结构，这里的key肯定是指sessionid了，value就代表session的详细内容。用户在做http请求的时候，总是会把sessionid传递给服务器，然后服务器根据这个sessionid来查询session的内容（也就是上面说到的value）。
现在我们重点关注一下sessionid，他是今天问题的关键所在。sessionid在客户端（http的客户端一般就是指浏览器了）是存储在cookie中，当然也有例外（书本上肯定会提到也有保存在url中的，我做程序员这么多年也没有见过这种方式，这难道就是现实和实际的差距吗，好残酷）。
-
session 生命周期
-
HTTP长连接,短连接
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
-
HTTP 1.0和HTTP 1.1的主要区别是什么?
HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：
长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式 。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用 :HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
-
URI和URL的区别是什么?
URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。
-
HTTP 和 HTTPS 的区别？
端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。
-
HTTPS原理和流程
HTTPS通信过程
HTTPS协议 = HTTP协议 + SSL/TLS协议，在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。
SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明，后来各个浏览器均支持SSL，其最新的版本是3.0
TLS的全称是Transport Layer Security，即安全传输层协议，最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同，但是在我们理解HTTPS的过程中，我们可以把SSL和TLS看做是同一个协议。
HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输，总的来说，对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。
HTTPS在传输的过程中会涉及到三个密钥：
服务器端的公钥和私钥，用来进行非对称加密
客户端生成的随机密钥，用来进行对称加密
一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。
-
客户端向服务器发起HTTPS请求，连接到服务器的443端口
-
服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
-
服务器将自己的公钥发送给客户端。
-
客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
-
客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
-
服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
-
然后服务器将加密后的密文发送给客户端。
-
客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
-
-
XML和JSON优缺点
https://www.cnblogs.com/sanmaospace/p/3139186.html
(1).XML的优缺点
<1>.XML的优点
A.格式统一，符合标准；
B.容易与其他系统进行远程交互，数据共享比较方便。
<2>.XML的缺点
A.XML文件庞大，文件格式复杂，传输占带宽；
B.服务器端和客户端都需要花费大量代码来解析XML，导致服务器端和客户端代码变得异常复杂且不易维护；
C.客户端不同浏览器之间解析XML的方式不一致，需要重复编写很多代码；
D.服务器端和客户端解析XML花费较多的资源和时间。
(2).JSON的优缺点
<1>.JSON的优点：
A.数据格式比较简单，易于读写，格式都是压缩的，占用带宽小；
B.易于解析，客户端JavaScript可以简单的通过eval()进行JSON数据的读取；
C.支持多种语言，包括ActionScript, C, C#, ColdFusion, Java, JavaScript, Perl, PHP, Python, Ruby等服务器端语言，便于服务器端的解析；
D.在PHP世界，已经有PHP-JSON和JSON-PHP出现了，偏于PHP序列化后的程序直接调用，PHP服务器端的对象、数组等能直接生成JSON格式，便于客户端的访问提取；
E.因为JSON格式能直接为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，且完成任务不变，并且易于维护。
<2>.JSON的缺点
A.没有XML格式这么推广的深入人心和喜用广泛，没有XML那么通用性；
B.JSON格式目前在Web Service中推广还属于初级阶段。
-
HTTP 2.0
HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？
HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；
-
HTTPS和HTTP的区别
http协议和https协议的区别：传输信息安全性不同、连接方式不同、端口不同、证书申请方式不同
一、传输信息安全性不同
1、http协议：是来超文本传输协议，信息是明文传输。如果攻击者截取了Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息。
2、https协议：是自具有安全性的ssl加密传输协议，为浏览器和服务器之间的通信加密，确保数据传输的安全。
二、连接方式不同
1、http协议：http的连接很简单，是无状态的。
2、https协议：是由SSL＋HTTP协议构建的可进行加密传输、身份认证的网络协议。
三、端口不同
1、http协议：使用的端口是80。
2、https协议：使用的端口是443．
四、证书申请方式不同
1、http协议：免费申请。
2、https协议：需要到ca申请证书，一般免费证书很少，需要交费。
-
HTTP请求/响应报文结构
字符编码集、语言、内容长度、服务器的域名和端口号
一、请求报文的结构：
- 请求行：请求方法GET/POST、URL、协议版本HTTP1.0/HTTP1.1
- 请求头部
- 请求主体
1.请求报文中方法的介绍： GET 请求获取一个Web页面 POST 主要作用是执行操作，比如向服务器提交一个表单 DELETE 请求删除一个Web界面 MOVE 请求移动某个页面到指定位置 HEAD 与GET方法类似区别在于获取Web页面首部，不获取主体 也就是说只获得一个页面的Head部分，而不获得BODY主体 PUT 请求向服务器上传指定资源。 TRACE 用于测试，要求服务器返回收到的请求 OPTION请求服务器支持哪些方法
2.请求消息头 字段名 说明
Host 消息头用于指定出现在被访问的完整URL中的主机名称 （被访问的完整URL主机名，也就是目的地址）
User-Agent 这个消息头用于提供与浏览器或生成请求的客户端软件有关的消息
Accept 这个消息头用于告诉服务器客户端接收那些内容，如图片类型，办公文档格式等
Accept-Language 用于声明服务器，浏览器支持哪些语言
Accept-Encoding 这个消息头用于告诉服务器 客户端接受那些内容编码
Referer 这个消息头用于指示提出当前请求的原始URL
Cookie
Connection 通知通信的另一方，是否在完成HTTP传输后关闭TCP连接
二、响应报文的结构
- 响应行：版本、状态码、短语
- 响应头部
- 响应主体
1.有关状态码的介绍 状态码是响应报文状态行中包含的一个三位数字 指明请求是否被满足，如果没有被满足，原因是什么，状态码可以分为以下五大类
状态码 含义 例子 1XX 表示请求已被接收，继续处理 100：服务器正在处理客户请求 2XX 表示请求已被成功接收，理解，接受 200：请求成功 3XX 客户端被重定向到其他资源 301：表示本网页永久性跳转到另一个地址 302：重定向，浏览器自动跳转到新连接 304：上次文档已经缓存，还可以继续使用 4XX 请求有语法错误或请求无法实现 400：请求有语法错误 403：拒绝提供服务 404：请求资源不存在 5XX 服务器执行请求时遇到错误。 500：服务器错误 503：服务器不能处理，请稍后再试
2.响应头部字段说明 date 响应返回的时间，GMT代表格林威治时间（北京位于东八区，所以北京时间要加8小时） server 这个消息头提供所使用的Web服务器软件的相关信息 set-Cookie 这个消息头用于向浏览器发布Cookie，浏览器会在随后的请求中将其返回给服务器 Content-type 这个消息头用于规定消息主题的内容类型 例如html文档的类型为：text/html， Content-Length 这个消息头用于规定消息主体的字节长度 Connection 通知通信的另一方，是否在完成HTTP传输后关闭TCP连接
-
状态码
图解HTTP
https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin
- 200 OK：表示从客户端发来的请求在服务端被正常处理了。
- 201 Created：请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。
- 202 Accepted：服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。
- 204 No Content：代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。
-
206 Partial Content：表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。
- 301 Moved Permanently：永久性重定向。表示请求的资源已被分配了新的URL，以后应使用资源现在所指的URL。
- 302 Found：临时性重定向。表示请求的资源已被分配了新的URL，希望用户能使用新的URL访问。和301状态码相似，但302状态码代表资源不是被永久移动，只是临时性质的。
-
304 Not Modified：表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回304.
- 400 Bad Request：表示请求报文中存在语法错误。
- 401 Unauthorized：表示发送的请求需要有通过HTTP认证的认证信息。
- 403 Forbidden：对请求资源的访问被服务器拒绝了。
-
404 Not Found：表明服务器上无法找到请求的资源。
- 500 Internal Server Error：表示服务器端在执行请求时发生了错误。
- 503 Service Unavailable：表明服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求。
-
HTTP/1.1 首部字段一览
图解HTTP P80
通用首部字段
- Cache-Control：控制缓存的行为
- Connection：逐跳首部、连接的管理
请求首部字段
- Accept：用户代理可处理的媒体类型
- Accept-Charset：优先的字符集
- Accept-Encoding：优先的内容编码
- Accept-Language：优先的语言（自然语言）
- Host：请求资源所在服务器
- Range：实体的字节范围请求
- Referer：对请求中URL的原始获取方
- User-Agent：HTTP客户端程序的信息
响应首部字段
实体首部字段
- Content-Encoding：实体主体适用的编码方式
- Content-Language：实体主体的自然语言
- Content-Length：实体主体的大小
- Content-Type：实体主体的媒体类型
非HTTP/1.1首部字段
- Cookie
- Set-Cookie
-
为什么tcp三次握手的时候的seq初始化时随机地，而不是从0开始
如果TCP在建立连接时每次都选择相同的、固定的初始序号，那么设想以下的情况：
(1)假定主机A和B频繁地建立连接，传送一些TCP报文段后，再释放连接，然后又不断地建立新的连接、传送报文段和释放连接。
(2)假定每一次建立连接时，主机A都选择相同的、固定的初始序号，例如，选择1。
(3)假定主机A发送出的某些TCP报文段在网络中会滞留较长的时间，以致造成主机A超时重传这些TCP报文段。
(4)假定有一些在网络中滞留时间较长的TCP报文段最后终于到达了主机B，但这时传送该报文段的那个连接早已释放了．而在到达主机B时的TCP连接是一条新的TCP连接。
这样，工作在新的TCP连接下的主机B就有可能会接受在旧的连接传送的、已经没有意义的、过时的TCP报文段(因为这个TCP报文段的序号有可能正好处在现在新的连接所使用的序号范围之中)。结果产生错误。
因此，必须使得迟到的TCP报文段的序号不处在新的连接中所使用的序号范围之中。
这样，TCP在建立新的连接时所选择的初始序号一定要和前面的一些连接所使用过的序号不一样。因此，不同的TCP连接不能使用相同的初始序号。
-
get请求和post请求的区别
GET请求把参数包含在URL中，将请求信息放在URL后面，POST请求通过request body传递参数，将请求信息放置在报文体中。
GET
“读取“一个资源。比如Get到一个html文件。反复读取不应该对访问的数据有副作用。比如”GET一下，用户就下单了，返回订单已受理“，这是不可接受的。没有副作用被称为“幂等“（Idempotent)。
因为GET因为是读取，就可以对GET请求的数据做缓存。这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），或者做到server端（用Etag，至少可以减少带宽消耗）
POST
在页面里<form> 标签会定义一个表单。点击其中的submit元素会发出一个POST请求让服务器做一件事。这件事往往是有副作用的，不幂等的。
不幂等也就意味着不能随意多次执行。因此也就不能缓存。比如通过POST下一个单，服务器创建了新的订单，然后返回订单成功的界面。这个页面不能被缓存。试想一下，如果POST请求被浏览器缓存了，那么下单请求就可以不向服务器发请求，而直接返回本地缓存的“下单成功界面”，却又没有真的在服务器下单。那是一件多么滑稽的事情。
GET和POST携带数据的格式也有区别。当浏览器发出一个GET请求时，就意味着要么是用户自己在浏览器的地址栏输入，要不就是点击了html里a标签的href中的url。所以其实并不是GET只能用url，而是浏览器直接发出的GET只能由一个url触发。所以没办法，GET上要在url之外带一些参数就只能依靠url上附带querystring。但是HTTP协议本身并没有这个限制。
浏览器的POST请求都来自表单提交。每次提交，表单的数据被浏览器用编码到HTTP请求的body里。浏览器发出的POST请求的body主要有有两种格式，一种是application/x-www-form-urlencoded用来传输简单的数据，大概就是”key1=value1&key2=value2”这样的格式。另外一种是传文件，会采用multipart/form-data格式。采用后者是因为application/x-www-form-urlencoded的编码方式对于文件这种二进制的数据非常低效。
浏览器在POST一个表单时，url上也可以带参数，只要<form action="url" >里的url带querystring就行。只不过表单里面的那些用 等标签经过用户操作产生的数据都在会在body里。
因此我们一般会泛泛的说“GET请求没有body，只有url，请求数据放在url的querystring中；POST请求的数据在body中“。但这种情况仅限于浏览器发请求的场景。
-
HTTP GET、DELETE、PUT、POST四种主要方法的幂等性的理解
- GET:GET请求是幂等的，多次的GET请求，不应该修改数据状态，只是查询。
- DELETE：Delete请求也具有幂等性，执行一次请求，删除id=1的记录，多次请求与一次请求的结果应该是一样的，最终的结果都是把id=1的记录删除。
- PUT：Put意为修改记录，也具有幂等性，执行一次请求，将记录修改为特定状态，多次请求结果也应该是一样的。
- POST：Post请求不具有幂等性，通常为增加记录。每执行一次请求，都会增加一条记录。
-
幂等
在一个典型的订单交易系统中，防重和幂等设计是重要而又非常基本的概念。防重是指重复多次提交同样的交易指令或者订单请求到后台，系统必须能够去重，防止重复执行；而幂等，则是在多个同样的交易指令或请求同时或者先后到达后台，即使重复执行，系统也必须始终提供与一致的状态，而不能有其他的副作用。看起来，防重与幂等似乎在说同一件事情，但其实又有不同的概念区分。例如幂等其实可以通过防重设计来达到提供一致的系统状态，而防重却不如幂等那样开放承诺，允许被执行多次而达到一致状态，这其实要求在防重的基础上做出更多的设计工作，特别是在分布式环境中。
为了更深入地理解幂等，我们先来看看HTTP/1.1协议中对幂等性的定义：
Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
这里不讨论学术上如何定义幂等性，而是重点在于如何在分布式环境中提供对外幂等性的接口。对外提供的接口承诺幂等性，其要表达的含义是：只要调用接口成功，外部对接口的多次调用得到的结果是相同的。即执行多次和一次的效果是一样的。
方法还具有“幂等性”的特性(除了错误或过期问题)，即N > 0相同请求的副作用与单个请求相同。
其实我们也可以从服务端架构分层上来理解，如果幂等设计放在越前端，那么提供的其实是一种防重方案；越往后端，随着业务逻辑的深入，幂等的设计方案也就更加复杂。这其实取决于相关交易系统的业务场景以及部署架构的特点。
在实际的生产环境中，我们不时还是会遇到防重或者幂等问题。例如有些老的订单系统，可能因为某个中间节点阻塞超时，触发了重发机制，最终导致多个相同ID的交易请求同时到达系统后台。由于老订单系统只提供了简单的串行防重，并没有充分考虑高并发幂等，结果将同一个用户的交易请求执行了多次，导致该用户的前后端的资产份额不一致，最终不得不人工介入解决。
常见的幂等实现方案，有这么几种:
1.最简单的，需要通过唯一的业务单号来保证幂等。也就是说相同的业务单号，认为是同一笔业务。使用这个唯一的业务单号来确保，后面多次的相同的业务单号的处理逻辑和执行效果是一致的。以支付为例，在不考虑并发的情况下，实现幂等很简单：①先查询一下订单是否已经支付过，②如果已经支付过，则返回支付成功；如果没有支付，进行支付流程，修改订单状态为‘已支付’。
2、上述的保证幂等方案是分成两步的，第②步依赖第①步的查询结果，无法保证原子性的。在高并发下就会出现下面的情况：第二次请求在第一次请求第②步订单状态还没有修改为‘已支付状态’的情况下到来。既然得出了这个结论，余下的问题也就变得简单：把查询和变更状态操作加锁，将并行操作改为串行操作。
3、但是，在某些场景，你可能又想提供无锁的高并发幂等，那么你可以选择为业务单号加上唯一的索引或者组合索引，在并发的场景中，只有第一笔插入的交易请求能够成功，后续的请求哪怕是慢1ms或者更短时间，都会触发数据库的唯一索引异常而失败，那么你可以捕获这个异常。
4、又或者你想把幂等放在服务的最前端，减少实际服务处理的资源浪费，在请求一到达时就提前去重，不让他有执行的机会，那么你可以考虑引入一个redis或类似的组件，将业务请求单号缓存在这个分布式锁的组件内。那么，每当订单发起交易请求，交易系统会去Redis缓存中查询是否存在该订单号的Key，如果不存在，则向Redis增加Key为订单号。查询订单是否已经执行，如果没有则转发到交易系统，执行完成后删除该订单号的Key。当然，Redis是提供分布式节点下的原子事务操作的。
-
DNS的寻址过程
1、在浏览器中输入www.qq.com域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2、如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4、如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。
6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。
DNS解析（域名解析服务器） a）首先会搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存）
b）如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的DNS缓存
c）如果还没有找到，那么尝试从 hosts文件里面去找
d）在前面三个过程都没获取到的情况下，就递归地去域名服务器去查找，具体过程如下
DNS优化两个方面：DNS缓存、DNS负载均衡
-
请你简单讲解一下，负载均衡 反向代理模式的优点、缺点
（1）反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。
（2）反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
（3）反向代理负载均衡能以软件方式来实现，如apache mod_proxy、netscape proxy等，也可以在高速缓存器、负载均衡器等硬件设备上实现。反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起，提升静态网页的访问速度，提供有益的性能；由于网络外部用户不能直接访问真实的服务器，具备额外的安全性（同理，NAT负载均衡技术也有此优点）。
（4）其缺点主要表现在以下两个方面
反向代理是处于OSI参考模型第七层应用的，所以就必须为每一种应用服务专门开发一个反向代理服务器，这样就限制了反向代理负载均衡技术的应用范围，现在一般都用于对web服务器的负载均衡。
针对每一次代理，代理服务器就必须打开两个连接，一个对外，一个对内，因此在并发连接请求数量非常大的时候，代理服务器的负载也就非常大了，在最后代理服务器本身会成为服务的瓶颈。
一般来讲，可以用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，如search等。
爬虫
-
防爬
- 后台对访问进行统计，如果单个IP访问超过阈值，予以封锁。
- 后台对访问进行统计，如果单个session访问超过阈值，予以封锁。
- 后台对访问进行统计，如果单个userAgent访问超过阈值，予以封锁。
- 用JavaScript混淆
-
模拟浏览器提交。
简单的，使用 webkit 来提交数据，这个基本可以过大多数浏览源检测的反爬系统了。
但是有的反爬系统检测浏览源的时候，会根据大众浏览器的一些特性，比如 IE，Firefox，Chrome 等的私有 js 函数来判定浏览器，这样 webkit ，以及一些封装好的 无界面浏览器 也被当成爬虫了。当然，你也可以利用调用 chromuim 来爬取数据，但是这个资源开销就更大了。
-
控制单 ip/账号 频率。
挂私有代理来爬的就不说了，大家都会用，但是对于一般人来说，几万 ip 差不多是极限了，所以一个 ip 还是得多次请求，账号同理。而控制了爬取速度，则意味着爬完一圈需要更多时间。时间都是成本。
-
控制爬取策略。
如果简单的只对目标数据进行爬取，那么如果反爬系统对访问概况和用户行为进行分析，其实很简单就能判定爬虫的那堆 ip : 你除了这堆数据什么都没访问，一看就不是正常用户。
当然策略这个东西，就需要更多的博弈了。爬虫要增加迷惑度，需要去访问一些无关的东西，最后是研究正常用户的访问流程，然后模拟一遍。再者，控制速度。毕竟反爬系统的统计区间是肯定有限制的，不可能拿一个月的数据都分析一遍找出爬虫。
