1 前言

有三个原因促使我回过头来整理，学习。

1.1 SYN攻击

作为DDOS攻击中的一种，syn攻击利用TCP建立连接三次握手的缺陷，利用伪造的syn包来消耗服务器的内存空间和半开连接数，这就可以使服务器的内存或者半开连接数耗尽而拒绝服务。

1.1.1 三次握手

三次握手

如图所示，黑客通过瞬间伪造大量ip，发送SYN包到服务器，当服务器B处于SYN-RCVD状态时，黑客停止发送确认消息，导致服务端缓存大量的半连接。

1.2 服务调度中心

1.2.1 黑客无处不在

微服务架构，搭配负载均衡，能有效实现服务的水平扩展，而保持高可用。这一点阿里云的ESS比较强大，它能够在已有ECS挂掉或者资源耗尽的情况下，弹性伸缩创建一台新的ECS，并自动将ip加到RDS和redis的白名单中，并自动挂到SLB后面。

但有时问题不是出在微服务的集群规模上面。而是出在负载均衡的设备上。

排除有效流量对服务器的压力，来自黑客的攻击，更容易导致服务器瘫痪。

比如上面DDOS攻击，直接打负载设备，导致负载被拉黑洞。如果客户端直接用的ip连接，则需要黑洞清洗完了，才能正常访问。等待时间1-24小时不等。

如果客户端用的域名访问，可以新创建一台负载，加上配置时间，域名解析时间，30分钟-1小时不等。

如果负载做了集群，客户端缓存了负载的集群地址，只能减少等待时间，还是会导致黑洞期间，所有用户不可访问。

1.2.2 调度中心原理

高仿过滤/调度中心+ SLB集群 + ECS集群

在正常情况下，客户端请求全部走高仿过滤，能够有效拦击大部分DDOS和CC攻击。

由于海外运营商线路的问题，导致高仿不稳定，会出现部分用户掉线，连接不上。

这种情况下，需要切换线路。根据客户端级别，所需服务类型等，由调度中心返回可用的SLB地址。

这里有几个点需要注意：

• 专门的SLB集群映射到ECS集群，多对多。

• 对于级别较低，活跃度，或者注册时间较短的用户，只返回SLB集群中的固定几个地址。

1.2.3 Tomcat原理

早些时候写过一篇博文:《为什么拦截器不能获取RequestBody的数据》，里面说到RequestBody的数据是从流中读取的。这个流其实就是TCP中的"流"，tomcat接受输入流，并转换为Http协议能够识别的数据。

2 运输层原理

运输层为相互通信的应用进程提供逻辑通信，在网上找了一幅图：

运输层原理图

从上图可以看出来，运输层指存在网络通信的两端的应用进程，而通信的中间节点为IP协议作用范围。

高层的应用层不关心下面网络核心的细节，看到的只是一条两个运输层实体中间的通信线路。当运输层采用TCP协议时，这条逻辑通信相当于全双工的可靠信道。当采用UDP协议时，这条通道是不可靠的通道。

采用UDP协议的应用层协议有：DNS,NFS
采用TCP协议的应用层协议有：SMTP,HTTP,FTP,TELNET等

2.1 运输层端口

整个运输层的原理，即IP：端口的方式。IP表示终端的位置，端口标识哪个应用程序处理。

好比现实生活中写信的双方，信封有三部分组成：

收件人地址：相当于IP

收件人： 相当于端口

信封中的内容：则是运输协议数据单元TPDU(Transport Protocol Data Unit)。
如果是TCP,则称为TCP报文段，如果是UDP,则称UDP用户数据包。

2.1.1 默认端口

运输层用一个16位的端口号来标志一个端口，所以可允许有65535个不同端口。

例如常用应用程序的端口：

应用程序	默认端口
mysql	3306
oracle	1521
nginx	80
ftp	21
tomcat	8005, 8080, 8009
ssh	22
qq	1080 4000 8000

2.1.2 端口分类

• 系统端口号：

  数值为0~1023，默认指派给TCP/IP最重要的应用程序，例如上面的ftp,ssh

• 等级端口号

  数值范围1024-49151，提供给次重要的服务端程序使用。比如tomcat的8080，oracle的1521

• 客户端端口号

  短暂端口号，范围：49152~65535，客户端运行应用程序，动态占用一个端口。当客户端发送信息时，报文头中会带着这个端口号。当服务端回复信息，能够通过该端口发送给客户端应用程序进程。

3 可靠传输原理

理想情况下，传输的信道不会产生差错。不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

然而实际的网络不具备上面的理想条件。那么，就需要使用一些可靠的传输协议，比如出现差错时，发送方能够重发；接收方来不及处理收到的数据时，可以通知发送方降低发送数据的频率。

3.1 停止等待协议

1. 正常情况，出差错

停止等待协议

图(a),A发送M1,B收到M1后，发送确认信息给A；A收到确认消息后，继续发送M2,B收到M2后发送确认消息给A，以此内推，每次A发送新的消息给B，都需要上一次B的确认信息。

图(b),A发送消息到B的过程中出现了差所，这时需要一个重传机制：

• M1发出消息，设置一个超时计时器。当超时时间过后，没有收到确认，重传刚刚的信息。只有收到确认后，才撤销计时器

• M1每次发送消息后，都需要保留已发送消息的副本。只有在收到确认时，才删除副本。

• 超时时间应该比平均接受到确认的时间长一些。但是太长，会影响重传效率。重传时间选择要考虑很多问题。

3.2 ARQ

1.确认丢失，确认延迟

确认丢失

(a),A在发送M1后，不知道M1是出错，还是确实丢失了。导致超时，
超时后，A将将继续发送M1。
假设条件如下：B成功收到了M1,只是确认信息丢失，导致A重传M1。B的处理如下：

• B丢弃重复M1
• 向A发送确认。不能认为已经发送确认就不再发送，因为A之所以重传M1,就表示A没有收到对M1的确认。

(b),B收到M1后，确认延迟了，导致A超时重传，B再次收到M1,会丢弃M1。但是B继续发送确认给A，A接着发送M2,这是B的第一次确认到了，A会丢弃该确认，什么也不做。

从上面看出，对于重复的消息和重复的确认，都采用丢弃的策略。

3.3 停止等待协议优缺点

上面的停止等待协议的优点是简单，缺点是信道利用率太低。因为每一次新的分组发送都必须等待上一次分组的确认信息到达。

信道利用率太低

信道利用率的公式如下：

U = \frac{T_{D}}{T_{D}+RTT+T_{A}}

其中，RTT为分组在网络中的运输时间。网络越差，RTT越大，信道利用率越低。

所以，需要采用更高效的流水线传输，允许发送方可以连续发送多个分组，
类似下图：

流水线传输

3.4 连续ARP协议

连续ARQ协议通常是结合滑动窗口协议来使用的，发送方需要维持一个发送窗口，如下图所示：

工作原理

连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。例如上面的图（b），当发送方收到第一个分组的确认，就把发送窗口向前移动一个分组的位置。如果原来已经发送了前5个分组，则现在可以发送窗口内的第6个分组。

接收方一般都是采用累积确认的方式。也就是说接收方不必对收到的分组逐个发送确认。而是在收到几个分组后，对按序到达的最后一个分组发送确认。如果收到了这个分组确认信息，则表示到这个分组为止的所有分组都已经正确接收到了。

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是，不能正确的向发送方反映出接收方已经正确收到的所以分组的信息。比如发送方发送了前5个分组，而中间的第3个分组丢失了，这时候接收方只能对前2个发出确认。而不知道后面3个分组的下落，因此只能把后面的3个分组都重传一次，这种机制叫Go-back-N（回退N），表示需要再退回来重传已发送过的N个分组。

可见，当网络线路质量不好时，连续ARQ协议会带来负面的影响。

3.4 滑动窗口协议

作为TCP协议的精髓，内容较多，不在本篇讲述，将在下一篇专门讲解TCP协议的博文中阐述。