SOA（面向服务的架构）：Service Oriented Architecture面向服务的架构。也就是把工程拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。这样做的好处就是，系统之间的调用很方便，A系统要用到B系统，直接调用B系统的服务层就可以了。
集群就是多台服务器跑的都是一套完整的代码，这就叫集群（水平拆分）；
分布式就是多台服务器合起来跑的才是一套完整代码，这就叫分布式（垂直拆分）
SOA （面向组件>>面向接口>>面向对象>>面向方法）
分布式服务器之间如何解决通信的问题
-全部都是基于socket
分布式系统通信流程：
1、七层网络协议
tcp/udp协议（）
2、源主机找到目标主机
3、源主机和目标主机之间如何建立联系
tcp：面向连接（保存状态）的一种协议
优点：可靠
缺点：速度慢
三次握手四次挥手图解
udp：面向数据报（无连接，五状态）
优点：速度快
缺点：不可靠
3.1tcp协议
3.1.1 通过3此握手协议
客户端发起（syn）服务器响应（ack）
3.1.2 syn攻击
网络崩溃
3.1.3 通过4次回收协议、
客户端发起（fin）服务器响应（ack）
网络协议概念模型
1.OSI 七层网络模型包含（应用层、表示层、会话层、传输层、网络层、数据链路层、物理层）
2.TCP/IP 四层概念模型包含（应用层、传输层、网络层、数据链路层）
TCP/IP和UDP/IP简介
1.TCP/IP协议是一种可靠的协议,源于通过三次握手协议去建立连接;
2.UDP/IP协议是一种不可靠的协议,数据包有可能丢失,有可能没有被接收;
请求发起过程，在 tcp/ip 四层网络模型中所做的事情
1.应用层:主要是我们访问某个连接,发起某个http请求
2.传输层:http应用协议是基于tcp/udp协议进行传输,头信息中tcp标示协议类型
3.网路层:头信息ip头,ip地址是一个网卡在网络中的通讯地址,相当于门牌号;
4.数据链路层:mac头,标示数据发送到网卡地址;全局唯一;
5.最后一个就是数据传输的过程中,会转换为比特码的形式传输;
客户端如何找到目标服务
1.在客户端发起请求的时候， 我们会在数据链路层去组装目标机器的 MAC 地址， 目标机器的mac 地址怎么得到呢？
2.这里就涉及到一个 ARP 协议，这个协议简单来说就是已知目标机器的 ip，需要获得目标机器的mac 地址。
(发送一个广播消息，这个 ip 是谁的，请来认领。认领 ip 的机器会发送一个 mac 地址的响应),有了这个目标 MAC 地址，
数据包在链路上广播， MAC 的网卡才能发现，这个包是给它的。
3.MAC 的网卡把包收进来，然后打开 IP 包，发现 IP 地址也是自己的，再打开 TCP 包，发现端口是自己，也就是 80 端口，
而这个时候这台机器上有一个 nginx 是监听 80 端口。
4.于是将请求提交给 nginx， nginx 返回一个网页。然后将网页需要发回请求的机器。然后层层封装，最后到 MAC 层。
因为来的时候有源 MAC 地址，返回的时候，源 MAC 就变成了目标 MAC，再返给请求的机器。
5.为了避免每次都用 ARP 请求，机器本地也会进行 ARP 缓存。当然机器会不断地上线下线，IP 也可能会变，所以 ARP
的 MAC 地址缓存过一段时间就会过期。
接收端收到数据包以后的处理过程
1.当目的主机收到一个以太网数据帧时，数据就开始从协议栈中由底向上升，
同时去掉各层协议加上的报文首部。每层协议都要去检查报文首部中的协议标识，以确定接收数据的上层协议。
2.物理层:当数据经过网卡的时候,通过下面数据链路层判断,是否需要接收
3.数据链路层:拿到数据后,就先从数据中摘到第二层的头,检查一下MAC地址和当前网卡的MAC地址是否匹配
4.网络层:拿到ip头,判断ip是不是自己的,若果不是就转发,如果是,继续给上一层处理
5.传输层:TCP头中会携带端口,将报文给指定的端口的进程进行处理;
为什么有了 MAC 层还要走 IP 层呢？
1.MAC是全局唯一的,理论上来讲,在任何两个设备之间,我们可以通过mac地址来发送数据,但是为啥还要IP?
2.可以这样理解,MAC地址如同人的身份证,是全局唯一的,
但是身份证所在位置和人所在的位置实时不一定是一致的,有可能身份证在家里,人在公司;
mac一样,知道mac不一定知道ip,ip有可能变了;
TCP三次握手协议
1.客户端A 首先发起建立联机[SYN]请求,同时会带一个随机的顺序号码[seqnum=x];
客户端A 发起建立联机的请求之后,即进入建立联机已发送的状态[SYN_SENT];
2.客户端B 在接收到客户端A发起的建立联机[SYN]请求之后,开始确认,确认成功,客户端会发送确认[ACK]建立联机
[SYN]请求,同时发送确认号码acknum[acknum=x+1,这里的x是客户端发送请求的时候传递过来的seqnum=x,
即我们是对客户端发送的内容的确认];
客户端B确认之后,会进入已经建立联机接收的状态[SYN_RCVD];
3.客户端A 在接收成功之后,客户端A发送确认[ACK=1],同时发送随机顺序编码x+1(因为在第一次发起请求的时候是x)
同时发送对客户端B发送的seqnum=y的确认[acknum=y+1]
为啥还要进行第三次握手
这里注意下,为啥客户端A发起了请求(第一次握手),客户端B也进行了确认(第二次握手),为啥还要进行第三次握手呢? 主要是基于,第二次握手客户端B发起确认之后,客户端A已经正常接收了;
SYN 攻击
在三次握手过程中， Server 发送 SYN-ACK 之后，收到 Client 的 ACK 之前的 TCP 连接称为
半连接（half-open connect），
此时 Server 处于 SYN_RCVD 状态，当收到 ACK 后， Server转入 ESTABLISHED 状态。
SYN 攻击就是 Client 在短时间内伪造大量不存在的 IP 地址，并向Server 不断地发送 SYN 包，
Server 回复确认包，并等待 Client 的确认，由于源地址是不存在的，因此， Server 需要不断重发直至超时，
这些伪造的 SYN 包将产时间占用未连接队列，导致正常的 SYN 请求因为队列满而被丢弃，
从而引起网络堵塞甚至系统瘫痪。 SYN 攻击时一种典型的 DDOS 攻击，检测 SYN 攻击的方式非常简单，
即当 Server 上有大量半连接状态且源 IP 地址是随机的，则可以断定遭到 SYN 攻击了、
TCP 四次挥手协议
1.第一次挥手(FIN=1， seqnum=x)
假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为 1 的包，表示自己已经没有数据
可以发送了，但是仍然可以接受数据。 发送完毕后，客户端进入 FIN_WAIT_1 状态。
2.第二次挥手(ACK=1， ACKnum=x+1)
服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，
但还没有准备好关闭连接。 发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这
个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。
3.第三次挥手(FIN=1， seqnum=w)
服务器端准备好关闭连接时，向客户端发送结束连接请求， FIN 置为 1。 发送完毕后，服务器
端进入 LAST_ACK 状态，等待来自客户端的最后一个 ACK。
4.第四次挥手(ACK=1， ACKnum=w+1)
客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT 状态，等待
可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。
客户端等待了某个固定时间（两个最大段生命周期， 2MSL， 2 Maximum Segment Lifetime）
之后，没有收到服务器端的 ACK，认为服务器端已经正常关闭连接，于是自己也关闭连接，进入 CLOSED 状态。
通俗易懂的话描述
```java
假设 Client 端发起中断连接请求，也就是发送 FIN 报文。
Server 端接到 FIN 报文后，意思是说"我 Client 端没有数据要发给你了"，
但是如果你还有数据没有发送完成，则不必急着关闭Socket，可以继续发送数据。
所以你先发送 ACK， "告诉 Client 端，你的请求我收到了，但是我还没准备好，请继续你等我的消息"。
这个时候 Client 端就进入 FIN_WAIT 状态，继续等待Server 端的 FIN 报文。
当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文， "告诉 Client 端，好了，
我这边数据发完了，准备好关闭连接了"。 Client 端收到 FIN 报文后， "就知道可以关闭连接了，
但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送 ACK 后进入 TIME_WAIT 状态，
如果 Server 端没有收到 ACK 则可以重传。 “， Server 端收到 ACK 后，
"就知道可以断开连接了"。 Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已
正常关闭，那好，我 Client 端也可以关闭连接了。 Ok， TCP 连接就这样关闭了！
为什么连接的时候是三次握手，关闭的时候却是四次握手？
三次握手是因为因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送SYN+ACK 报文。
其中 ACK 报文是用来应答的， SYN 报文是用来同步的。但是关闭连接时，当 Server 端收到 FIN 报文时，
很可能并不会立即关闭 SOCKET（因为可能还有消息没处理完），所以只能先回复一个 ACK 报文，告诉 Client 端，
"你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。
故需要四步握手。