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 |
| 1080 4000 8000 |
2.1.2 端口分类
-
系统端口号：
数值为0~1023，默认指派给TCP/IP最重要的应用程序，例如上面的ftp,ssh
-
等级端口号
数值范围1024-49151，提供给次重要的服务端程序使用。比如tomcat的8080，oracle的1521
-
客户端端口号
短暂端口号，范围：49152~65535，客户端运行应用程序，动态占用一个端口。当客户端发送信息时，报文头中会带着这个端口号。当服务端回复信息，能够通过该端口发送给客户端应用程序进程。
3 可靠传输原理
理想情况下，传输的信道不会产生差错。不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。
然而实际的网络不具备上面的理想条件。那么，就需要使用一些可靠的传输协议，比如出现差错时，发送方能够重发；接收方来不及处理收到的数据时，可以通知发送方降低发送数据的频率。
3.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协议的博文中阐述。
网友评论